On Wed, Sep 22, 2010 at 12:47:29PM +0200, Robert von Knobloch wrote: > I assume a .deb file is a Debian package?
Yep, sorry for the distro-ism. > I use Suse and compile the toolchain from source (so I 'know' what I'm > getting :-) Yes, I did that for a long time, and probably will again if I'm actively developing on AVR again. I just needed an avr-gcc quickly, when advising on those linker scripts. > I couldn't find the startup code as source in the sources, only as an > object file which confused me - there is be no crttn13.S, only crttn13.0. Ah, I thought I had a vague recollection of the object files being built, but it is now several years since I last built avr-gcc, so the memory must be false. Still, you don't need the source, because there is no heap code to optimise, and __stack can be set wherever you like, AFAICT. You could define __stack with a -D on the avr-gcc command line, even. To avoid a make target for each application * alternatives combination, it might be convenient to have someting like: $ make chips_are_xxx # To set up for this week's silicon. $ make my_app_42 # Build an application accordingly. > I really wanted to see what exactly occurs in the various .initx files > as the docs only describe function, not actual code and I want to see > what I can change ;-) They are an ordered sequence of initially empty initialisation sections, and you are free to link your initialisations into individual sections, to control the order of their execution. And .init9 jumps to the entry point, __start. Have a look at: $ avr-objdump -d crttn13.o > /tmp/crttn13 Because the object file is relocatable, the SP (0x3d) line doesn't have a value: 4: c0 e0 ldi r28, 0x00 ; 0 6: cd bf out 0x3d, r28 ; 61 until the linker has done its job, and $ avr-objdump -t /usr/avr/lib/crttn13.o tells us that __stack is a symbol used here, and it is a weak one. (So you can cheerfully overwrite it, if it also is weak where defined, as a default.) > It may be that there is no heap, as such, allocated, but the standard > startup puts the stack pointer in the middle of ram (expecting a heap?), > which doesn't seem right for me. Since I find no __stack in the default linker script: $ avr-gcc -Wl,-verbose > /tmp/ld_script I'm not immediately sure what it's using. But since you're using custom linker scripts, if the above simpler method doesn't appeal, you're free to plonk in something similar to what I've used. Here's one for an ATmega64: /* ATmega64 Constants */ __ramend = 0x20 + 0xE0 + 0x1000 - 1 ; /* Registers + I/O + RAM */ __stack = __ramend /* If that's what suits. */ > I also sometimes have to use 'alternative' processors due to supply > problems (the world seems still to be cathching up after throttling back > manufacturing due the financial crisis) and letting the stack pointer be > reset by hardware to top of ram (as the chips natively do) would let me > use common code for (some) different avrs. This why I don't really want > to set __stack to a value. Ah, then it might be more convenient to replace the previous suggestion with this line just before "MEMORY" in the linker script: INCLUDE chip_specifics.ld Then, at chip-specific makefile targets, [echo | cat] the __ramend and __stack guff for this week's batch of silicon into the chip_specifics.ld file, much as in the example for using -D instead. > Thanks to your help I have a linker script which could easily set this, > but I don't feel that it's the 'right' answer. No, with your 'alternative' processors, it is more convenient to set it at a make target, so it's all automatic when you build for the silicon which has rolled in the door. > I could also remove .ini1 or .init2 in this script, but forst I need > to know exactly what they contain. The ten .inits are standard linker output sections for avr-gcc. They are just like egg-carton cups in a row, into which we can link initialisation code, so that they are executed in deliberate sequence, even though the source often remains in the same file as the .text which relies on that initialisation. (i.e. it allows a degree of OO in our coding approach. Even an assembler source file can have "constructors", kept together with the "methods".) > I have no problem maintaining a non-standard avr-libc, I have already > modified parts of it to suit my needs (open source is wonderful isn't > it?). Isn't it just? :-) > Oh, BTW I use tiny 13, 24, 25, 45 etc. (VERY SMALL RAM). I have a few tiny 15s. I need to dig one out and play with it. So, in summary, there no longer seems to be a need for the crttn13.o source code. You could just define it in assembler or C ! Erik _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
