Arbitrarily Large Bootloaders

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I notice this AVR App notes for the bootloader says 

 

For this bootloader implementation, the code size is approximately 12KB, and the code is placed in the

boot loader section and the application table section. When erasing or writing a page located inside the

application section, only the boot loader section can be read while the application table section cannot be

read. So the code relating to reading binary file and memory program must be placed at the boot loader

section.

 

That statement is wrong? Only the code related to "memory program" must be in the boot loader section,

correct? The part related to "reading binary file" could be in the application table section. Correct?

 

The linker options:

Wl,--relax -Wl,--section-start=.mysection=0x1E000 -Wl,--section-start=.text=0x20000

 

Why do they specifically mention the application table in the docs? Their bootloader code could take up

half the program memory of the controller if desired, as long as the memory programming command

was up in the bootloader section? Does the fact its in the application table actually mean anything

functionally? Or is it just because it is adjacent to the bootloader section they mention it?

 

Thanks

Mike

 

 

 

Last Edited: Tue. Apr 3, 2018 - 10:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can place your code wherever you want. All that matters is the SPM instruction must reside in the bootloader area e.g. SPM, RET.
.
Quite honestly, it seems unwise to create a 12kB boot program. I would attempt to squeeze all the critical code into the boot section and protect with lock bits.
.
Many boot processes are multi-stage e.g. your PC. It boots from BIOS ROM which in turn loads the operating system from disk.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, thanks. Why is the Application Table called out as a special area of memory?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because the lock bits work differently. And SPM only works from the boot section.
Seriously. Place a 100% robust boot code in the boot section and protect with lock bits.
.
The robust boot code can upload the "monster" 12kB support program and any "actual" user application.
Compare with how the PC BIOS works.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are creating 12K bootliaders for AVR you are almost certainly doing something wrong. Even something as a USB DFU boot loader can be done in 4K. The boot loader is the only piece of code in the entire device that HAS to be 100% fault free on day one (everything else can be updated) so you stand 3 times more chance of that (simplistically speaking!) with 4K rather than 12K (in reality the interactions in 12K are probably much more than 3 times). It's the same reason why it is very, very unwise to use interrupts in a boot loader too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If you are creating 12K bootliaders for AVR you are almost certainly doing something wrong. Even something as a USB DFU boot loader can be done in 4K. The boot loader is the only piece of code in the entire device that HAS to be 100% fault free on day one (everything else can be updated) so you stand 3 times more chance of that (simplistically speaking!) with 4K rather than 12K (in reality the interactions in 12K are probably much more than 3 times). It's the same reason why it is very, very unwise to use interrupts in a boot loader too.

Never say never.

My bootloader is 14K. It's a TFTP bootloader that also has telnet, the telnet is mainly for changing the IP address in an easy way.

The system uses an ENC424J600 ethernet controller, and the tcp/ip stack is uip.

Without telnet, the bootloader is around 12K, but with an additional file in tftp, for config.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wl,--relax -Wl,--section-start=.mysection=0x1E000 -Wl,--section-start=.text=0x20000

 

So I can scoot this "mysection" down another 0x200, no big deal, and add a bit of my own OLED driver into this application table area.

 

I am guessing I will find some way each function is made to fall in one of the listed areas  ("mysection" or "text" ).

 

If you are creating 12K bootliaders for AVR you are almost certainly doing something wrong.
 

Maybe their AVR42788 bootloader so large because of the full fat library? Reading code like that is difficult for me. It's so loaded with conditional stuff related to the suite of Atmel test boards, and then more conditional stuff related to what compiler in use. 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I wrote a FAT boot loader (SD cards) that is between 1K..2K and with some of the options turned off is under 1K (so fits very small mega chips) so there's no real excuse for 12K even for card/FAT reading. For SPI or GPIO the Xmega shouldn't really be any more complex than tiny/mega.

 

It's here if interested...

 

https://spaces.microchip.com/gf/...