Modifying compiler output to suit Tiny13 bootloader

[David Carr]

Hi all,

I've been writing a bootloader for the Tiny13 for the past few days.  At
this point, the bootloader can download, program, and execute simple
programs written in assembly.  Now I'd like to add support for programs
compiled with avr-gcc.

I wrote a very simple C program and looked at the assembly output
produced by avr-gcc.  The first line is:

00000000 <__vectors>:
   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>

My bootloader lives in the last 192 bytes of flash, so I'd like to
replace this instruction (at address 0) with an rjmp to that location.  
Where/how does this line get generated?  I assume its deep in the
architecture specific start up code somewhere.

Secondly, what assumptions does the compiler make about the state of the
machine/registers on boot?
It seems there is some initialization going on in the __ctors_end
section, such as zeroing r1.

Lastly, where do the linker scripts live now?
The avr-libc webpage mentions /usr/avr/lib, but I only have a bunch
files ending in .o there.  No files ending in .x.  Am I doing something
silly?

I really appreciate any help you can give me.  Understanding the
internals of gcc is a formidable challenge for me.
-David Carr


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Carr]

Turns out that the linker scripts are in /usr/lib/ldscripts on my
system.  One question down, two to go.

-DC

David Carr wrote:

> Hi all,
>
> I've been writing a bootloader for the Tiny13 for the past few days.  
> At this point, the bootloader can download, program, and execute
> simple programs written in assembly.  Now I'd like to add support for
> programs compiled with avr-gcc.
>
> I wrote a very simple C program and looked at the assembly output
> produced by avr-gcc.  The first line is:
>
> 00000000 <__vectors>:
>   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>
>
> My bootloader lives in the last 192 bytes of flash, so I'd like to
> replace this instruction (at address 0) with an rjmp to that
> location.  Where/how does this line get generated?  I assume its deep
> in the architecture specific start up code somewhere.
>
> Secondly, what assumptions does the compiler make about the state of
> the machine/registers on boot?
> It seems there is some initialization going on in the __ctors_end
> section, such as zeroing r1.
>
> Lastly, where do the linker scripts live now?
> The avr-libc webpage mentions /usr/avr/lib, but I only have a bunch
> files ending in .o there.  No files ending in .x.  Am I doing
> something silly?
>
> I really appreciate any help you can give me.  Understanding the
> internals of gcc is a formidable challenge for me.
> -David Carr
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Carr]

Hope everyone is enjoying this thread as much as I am ;)

For posterity and confirmation of my understanding:

It looks like the rjmp at address 0 is generated by the file
/usr/avr/lib/crttnXX.o.  This file seems to be generated during the
avr-libc build process from a file called gcrt1.S in the avr-libc
distribution.  To override this behavior it seems that I'd have to make
a custom start up assembly file and use it for my bootloader-C
projects.  That sounds messy.

After perusing this page
[http://www.nongnu.org/avr-libc/user-manual/mem_sections.html], it
appears that a better solution might be to override the weak
.init0/__init() section.  The new .init0/__init() would rjmp to my
bootloader.  My bootloader could then rjmp back to .init1 or .init2 so
long as those were placed at a fixed location.  Linker script to do that?

Lastly, the avr-libc startup code seems to zero r1, zero the status
register, and load the stack pointer.  I'm not sure if there are any
other pieces of state I should be concerned about.

-DC

David Carr wrote:

> Hi all,
>
> I've been writing a bootloader for the Tiny13 for the past few days.  
> At this point, the bootloader can download, program, and execute
> simple programs written in assembly.  Now I'd like to add support for
> programs compiled with avr-gcc.
>
> I wrote a very simple C program and looked at the assembly output
> produced by avr-gcc.  The first line is:
>
> 00000000 <__vectors>:
>   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>
>
> My bootloader lives in the last 192 bytes of flash, so I'd like to
> replace this instruction (at address 0) with an rjmp to that
> location.  Where/how does this line get generated?  I assume its deep
> in the architecture specific start up code somewhere.
>
> Secondly, what assumptions does the compiler make about the state of
> the machine/registers on boot?
> It seems there is some initialization going on in the __ctors_end
> section, such as zeroing r1.
>
> Lastly, where do the linker scripts live now?
> The avr-libc webpage mentions /usr/avr/lib, but I only have a bunch
> files ending in .o there.  No files ending in .x.  Am I doing
> something silly?
>
> I really appreciate any help you can give me.  Understanding the
> internals of gcc is a formidable challenge for me.
> -David Carr
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andrew Zabolotny]

From Sun, 25 Oct 2009 18:45:36 -0400
David Carr <dc@...> wrote:

> It looks like the rjmp at address 0 is generated by the file
> /usr/avr/lib/crttnXX.o.  This file seems to be generated during the
> avr-libc build process from a file called gcrt1.S in the avr-libc
> distribution.  To override this behavior it seems that I'd have to
> make a custom start up assembly file and use it for my bootloader-C
> projects.  That sounds messy.
If you run 'avr-gcc -dumpspecs' (or look at the 'specs' file directly)
you can see the logic that chooses startup file and linker options. At
the first look it may seem messy but in fact the syntax is simple:
every expression in curly braces is a "if", the condition
(gcc command-line option) is before a double colon and the replacement
text is after double colon. For example, "%{mmcu=attiny12:crttn12.o%s}"
means that if the "-mmcu-attiny12" option is specified at gcc command
line, the crt_binutils spec will get a "crttn12.o" in it. As a special
exception, if there's nothing after double colon, the option is copied
as-is to output spec (e.g. "%{static:}").

Now the expressions in round braces are recursive invocations of
another spec. For example, the link_command spec invokes the
%(link_libgcc) spec and so on. You can find more about specs files in
gcc manual.

Now if you understand the specs well, you can write your own .spec
file. Then you just specify your spec file during link using the
"-specs=" option. This way you can override anything anywhere.

--
Andrew


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Stefan Ernst-3]

David Carr wrote:
> I wrote a very simple C program and looked at the assembly output
> produced by avr-gcc.  The first line is:
>
> 00000000 <__vectors>:
>   0:   10 c0           rjmp    .+32            ; 0x22 <__ctors_end>
>
> My bootloader lives in the last 192 bytes of flash, so I'd like to
> replace this instruction (at address 0) with an rjmp to that location.  
> Where/how does this line get generated?

1) Why you don't simply let the bootloader replace the first two
bytes when flashing the application?

2) How does the bootloader start the app? The address of __ctors_end is
not fixed. E.g. it changes if the app uses PROGMEM. So the bootloader
needs to know where the original jump was going to. Isn't this another
reason for not changing the code generation, but to handle it in the
bootloader?


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list