self-modifying bootloader

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

I am wondering if there is a pre-made self-modifying bootloader already written and in the public domain.

I have a bootloader that is used to download regular programs so I don't need to hook up an ISP programmer. But what if I want to modify the bootloader itself?!

I suppose this is solved by having a secondary bootloader which is installed closer to the end of memory than the regular bootloader.

The primary bootloade can download a program and EEPROM data. The EEPROM data is the file for the new primary bootloader, and the program simply jumps to the secondary bootloader code in the bootloader section. The secondary bootloader then uses SPM to modify the primary bootloader.

Would this work? Is there already something out there that does this?

-Tony

Last Edited: Mon. Dec 12, 2016 - 04:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you just discovered the reason why, on most systems, the bootloader is the only bit of the software you have to get totally right on day one!

An SBL/PBL split is the way to do it but it works better in Von Neumann systems where the BL flash updating stuff (the SBL) can just be copied out to RAM and executed from there - otherwise you face the classic "pull the rug from under you" kind of conundrums! Probably easiest just to make sure you got it right on day one - and another reason for keeping loaders "lean and mean" and putting all the "clever stuff" into the replaceable app.

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

The biggest deal-breaker would be that you would be unable to set the lock bits on the bootloader section.

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

curtvm wrote:
The biggest deal-breaker would be that you would be unable to set the lock bits on the bootloader section.

Do you mean that I would not be able to change the BOOTSZ fuses which control the available size of the bootloader section?

Can software running on an AVR change ANY of its fuses, ever?

-Tony

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

On bigger AVRs it might be possible. Big, as in lots of SRAM.

The idea is to use the existing bootloader to download the complete new bootloader into SRAM. Then jump into your special bootloader section at the end of the flash (preferrably fitting into one page). It's only job is to program the bootloader section with the buffer in SRAM. Tricky, but doable.

Beware!! If something goes wrong while you update your bootloader you ARE screwed.

And no, you can't change fuses from software. Although, I've somehow managed to corrupt the signature bytes on one of my mega8s. Which, supposedly, isn't possible neither ...

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

OK, by the replies, it seems that it is feasible to have a secondary loader which can load a new bootloader(but not a new secondary loader).

Lets say that my bootloader section starts at 0xFC00 as set by my fuses.

Lets say that I want to have my secondary loader start at 0xFF80 (hopefully it would be that small). I have named this section ".bootstrap"

I am programming in WinAVR. What do I name the secondary loader function to get it to be placed in the ".bootstrap" section?

Would the function prototype be something like this?

void aux_loader(void) __attribute__((section(".bootstrap")));

Then would I call that function simply by a regular function call from within the main bootloader like this:

if (something) aux_loader();
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or... you load a special application code whose sole purpose is to program a new bootloader in.
You then reload normal app code.
ISTR there is an issue with code in the non-bootloader area not being able to write to teh BL area, but this could probably be worked round by providing fixed entry points in the old bootloader to just to the writes.

Generally speaking the trick is to keep the BL as simple as possible, to minimise the risk of problems.
Where a complex comms protocol means the BL is complex, there is another approach.
Add ( or use an existing) external ee/serial flash that is big enough to hold a firmware image.
The main application ( which has all the complex comms stuff) loads a new image into the eeprom, and verifies it. When verified, it then calls the really simple bootloader that just has to copy the app code from the eeprom.

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

Mikeharrison wrote:
Or... you load a special application code whose sole purpose is to program a new bootloader in.
You then reload normal app code.

Except that on most AVRs the app code cannot SPM.

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

clawson wrote:
Except that on most AVRs the app code cannot SPM.
But you could have an spm function at a known location in the bootloader section, which the app calls (spm will be executing from the bootloader section). Make the first page in the bootloader 'untouchable', which will have the spm function and decision code (if there is a bootloader available, or need to go to bootloader update app). That first page will 'always' be there, so you will get to it on every reset 'no-matter-what'. The spm function will need to make sure its not trying to erase itself. The bootloader update app better work flawlessly. Or else.

Bootloader loads/verifies bootloader update app. Update app runs, erases bootloader section (except first page), and programs new bootloader. If it screws up, it will keep trying every time it runs. Assuming your update works, and the new bootloader works, you are back in business.

But there seem to be many ways it can all come crashing down on you.

And you still can't enable the boot lock bits for the bootloader section.

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

curtvm wrote:
But you could have an spm function at a known location in the bootloader section, which the app calls (spm will be executing from the bootloader section).

It'd need to be more than just an SPM - don't forget about the need to boot_rww_enable() after the SPM that does the programming - otherwise the RET gets back to a sea of 0xFFs!

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

Its hard to get reliable working on a changeable bootloader.

I would write the bootloader in such a way, that it must be updated never.

But if it must be changeable, I would reserve twice the size of the bootloader.
And at first there is a no changeable switcher routine, which select one of the two bootloaders.

Then a bootloader can change the other, and set a counting variable on the EEPROM.
The switcher count up this variable and if not a magic was written by the new bootloader, after 10 reboots the switcher reverse to the old bootloader again.
So you can check up to 10 times, if the new bootloader works right.

And as long the counting was in progress, the switcher routine prevents the old bootloader against overwriting.
Thus the switcher routine contain also an API-call for SPM (erase, load, write) actions after address checking.
None of the bootloaders contain SPM itself.

Peter

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

clawson wrote:
It'd need to be more than just an SPM - don't forget about the need to boot_rww_enable() after the SPM that does the programming - otherwise the RET gets back to a sea of 0xFFs!
Which is why it has to be a 'function' and not just a spm + ret. You would also want the 'function' to check if someone's trying to kill it (maybe need 2 pages by the time the function is complete, I don't know).

(Cliff, I'm going to declare you the winner for my extra credit question of the other day. What an honor.)

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

These are all great suggestions. I have been successful in creating a function in a separate section within the BL section of the M128 I am testing it on. I was able to execute code in that section by a call from elsewhere in the bootloader.

To execute this function from other code in the application code section would require that the separate application know WHERE the special section is.

I am considering placing some data at the VERY far end of flash (near 0xFFFF), I think I can place the address of the special section there.
Right now I am trying to avoid the use of EEPROM to store the image of the new bootloader because it may contain current user application data. I would rather not corrupt that data.

I agree that most likely it would be a good idea to d/l the data to sram, and be sure all the CRC's are good before executing the SPM.

I will start to get this asembled together....

-Tony

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

Tony,

I gotta know - WHY do you think it'll be necessary to ever have to update the bootloader anyway? As I said in the very first reply - just get it right on day one then forget it. It's the ONLY piece of software in the entire system that you have to be positive is totally bug free and you should try and strip out as much functionality as possible and put all that into the replaceable app.

Cliff
(who once triggered an update of a bootloader for 250,000 units in a population of devices and had a VERY sleepless night hoping nothing went wrong - thankfully it didn't!)

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

clawson wrote:
Tony,

I gotta know - WHY do you think it'll be necessary to ever have to update the bootloader anyway?

Cliff, as usual, you pose a very good question. Why is it necessary? And how USEFUL would it be?

I am "helping" development/suggesting ideas in the development of a great device. I am not sure how useful my "help" actually is!!!

The bottom line is that these devices will be used in different situations. These situations could highlight design limitations to a specific bootloader, especially if it is very lean. Modifying the bootloader might make sense. By the very nature of this type of unexpected situation one can not predict exactly what sort of shortcomings a particular bootloader would have.

I think that having a little add-on bootloader-loader might be a bit of insurance so that there can be modification of the bootloader if an unexpected situation arises.

As it is right now, there are a few hundred bytes of unused flash in the current bootloader section. I do not think it would even require a larger bootloader section to have this insurance.

Like normal insurance, I would not EXPECT to use the bootloader-loader, but it is there just in case. I am not sure that there is a downside to the code being present if unused.

I must say, after all this discussion, I wonder how VALUABLE it would be to spend the time and effort in development of this insurance.

-Tony

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

Please Tell what all pins need to be set or cleared in boot-loader programming for atxmega256a3bu micro-controller.

 

* I asked you already to be careful where you post and now you hijack this thread. Are you stupid? Stay on https://www.avrfreaks.net/forum/s...

 or risk being banned. Moderator *

Last Edited: Mon. Dec 12, 2016 - 04:40 AM
Topic locked