Re: [avr-libc-dev] Is there interest in an arm-libc?

[Erik Walthinsen]

Oops, this draft got bitbucketed a few days ago ;-(

On 11/03/2014 08:42 AM, Markus Hitter wrote:
> Maybe I expose my lack of knowledge here, but what is the point of running off 
> RAM? Chips I used so far are pretty sparse on RAM, so one couldn't do there 
> much, anyways. Would it be an option to simply ignore these paths in gcc, 
> letting the user deal with such rare(?) setups? If one really needs this, one 
> can always copy into RAM per user code and jump to it, of course.

Several basic variations:

- some older SoCs (e.g. Freescale MC13224 radio) literally glue together 
an SPI flash inside the package.  On startup the chip has a ROM that 
reads a signature+length from that flash, and loads that code into RAM. 
 It has 128KB flash, 96KB SRAM, and 80KB ROM.

- on the higher end, you have e.g. older ARM9 chips that have a fast 
*external* memory interface, but only use I2C or SPI to boot from in the 
same basic manner

- even when you can execute out of internal or external flash, sometimes 
there are significant performance limitations because of it.  Especially 
at higher clock rates, not all flash (internal or external) can actually 
keep up with a single-cycle access.  An example would be an LPC43xx with 
it's "SPIFI" interface, which can execute directly out of external 
quad-SPI flash, but still is several times slower than running from 
internal SRAM.

The other scenario involves debugging, where you can have GDB push the 
code directly into RAM and run from there without flashing first.

> One thing I couldn't find a reason for so far, is this insisting on user code 
> before main(), usually named SytemInit(). I think if there is any code before 
> main() It should be vector tables only, nothing which might change behaviour. 
> For example, it should be entirely fine to setup the PLL clock in main().

The ARM vendors *really* like to put in automagic systemclock functions 
there.  IMO that's something that belongs in main(), which should start 
executing in whatever the default clock state is.  If you *really* want 
something before main, avr-libc etc gives you the various .initN 
sections.  This is something that can rather trivially be carried over 
to ARM.

> It looks like Terry Guo, apparently ARM-employed arm-gcc maintainer, could be a 
> bit more enthusiastic about hardware support in this toolchain:
Honestly that concerns me a little bit, because he may have a vested 
[hidden] interest in *not* making this easier, as potential indirect 
competition (ARM sells to chip vendors who 'sell' toolchains to us).  I 
have no idea if it's the case, just a possibility that I'd love to see 
shown false.

> I think it might be a good idea to start with getting -mmcu into gcc. First 
> step would be to provide built in #defines for each variant, like __LPC1114__, 
> __STM32F405__ and so on. This would already allow to distinguish between 
> different HAL variants and such stuff in user code. Could also be done with a 
> user supplied -D, of course, but having this in gcc means people can rely on 
> it, code using this becomes compatible, chances that every hacker uses a 
> slightly different variant becomes low.
I'd like to find out more about this "spec" setup that was mentioned, 
and see what it's capable of.  If it provides the basis for pulling in 
all the various compiler/linker flags we need based on a single 
argument, whether that's "-mmcu" or something else, then really the 
first thing would be to determine how to arrange all these various files 
in /usr/lib/???.  That's pretty much exactly what avr-libc does anyway, 
just hardcoded (historically?).

> Third step could be to provide these vector tables.
I'd personally be interested in working on the header files, starting 
with the existing vendor-supplied headers and converting them into some 
XML/JSON/? format that can be turned back into consistent headers.  The 
vector tables and core startup code ("crt.o") would end up also being 
based on info gathered into those definition files.

> And so on ... good plan?
The next major step is probably to get this forked off onto its own 
mailing list ;-)