Feedback wanted - Multiboot loader development

[asmallri]

I am developing a multiboot loader for use with Microchip controllers and am soliciting feedback on the feature set. The basic idea is that PICs with large amounts of program memory can hold more than one image and a mulit-boot loader can be used to select the desired image and to load additional images into program memory.

The bootloader has three elements, the base bootloader code, a bootloader parameter block and a boot image selection mechanism. The bootloader parameter block is common to our current range of bootloaders but is extended to support multiple images. Information in the parameter block includes the image ID, image storage location in program memory, image reset vector (not applicable to PIC32) and other information depending on the type of bootloader (serial, Ethernet, SPI etc).

Application programs are compiled as per normal but with a lower defined upper Program memory limit via the linker script (e.g. Microchip compilers) or via #defines in the source (e.g. CCS Compilers). Because the bootloader and each application are effectively ships-in-the-night, all PIC resources such as RAM, peripherals, interrupts etc are completely available to the active application. All applications are compiled to execute in the same memory region. Because the bootloader code and all images are "ships-in-the-night" they can be any mix of programming languages.

The boot image selection can be made via one or more of the following approaches, external PIC pins, External/Internal EEPROM contents, PC programmer application, application modification of an entry in the PIC parameter block. When an new image selection is made, the bootloader overlays the selected image onto the program memory space where the application was originally intended to be executed.

Later PIC generations have more Program memory available. For this reason the multiboot loader would most likely be implemented in assembler for PIC18F processors (leaving more PGM Memory for the applcations) and in C for PIC24/dsPIC and PIC32 mcrocontrollers.

Some PICs have embedded EEPROMS. There are a number of ways multiboot EEPROM support could be handled. The EEPROM image associated with an application image could be stored in program memory along with the application image and stored to EEPROM when the bootloader selects the image to execute. The EEPROM could be partitioned, similar to the way program memory is partitioned, such than an application appears to have only a subset of EEPROM space available. The EEPROM could be left unchanged, a separate command could be used to instigate the overlay of the stored EEPROM image onto the EEPROM.

Feedback wanted:

1. Do you see demand for a multiboot feature?
2. Would this be a feature you would incorporate into a commercial product?
3. Would this feature be of benefit to the hobbyist?
4. What EEPROM mechanism would be most useful?
4. Do you care what programming language the bootloader is written in?
6. What is the priority of bootloader interface type you would use with this class of bootloader (Ethernet, serial, SPI, other)
7. Which image selection mechanism would you prefer?
8. General comments

Thanks for your time.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Rohit de Sa]

Hey Andrew,

My profile, so that you can put the answers in the correct perspective:
I'm a senior undergraduate doing mechanical engineering in India. Electronics is a hobby. Electronics experience - 6 years. Experience with PICs - 4 years+ (10, 12, 16, 18, 24 series).

And my answers in order:
(a) I currently don't see the need for a multiboot system. Whenever I use a bootloader, the fresh code is taken off the computer. I don't think multiple images are very necessary. Maybe storage of images on external EEPROMs would be useful.

(b) I'm still a student, so the answer is - no, not yet, at least :-) .

(c) I suppose it may. Answer (a)

(d) I have not yest come to the stage where I regularly require to use large swathes of internal EEPROM. I use the EEPROM only to store some user modifiable flags or configuration settings. So as long as at least 10 bytes of internal EEPROM are available for user application, I think the internal EE approach will work. But I guess if you would like to put multiple images then an external EE would be the way to go.

(e) Preferably well documented/commented assembly or C so that modification is possible (that is, if you are planning on making your code open source :-) )

(f) Bootloaders I have worked with, beginning with the most often used one - USB (on supported chips), Serial, SPI, Ethernet, others are just modifications of the physical layer of the serial bootloader (bluetooth, IR)

(g) Didn't get the question

(h) I don't know how easy this is going to be , but 'relocatable' images may be of use. On chips with limited resources depending on whether the user requires more program memory, or more EE, you could shift the code to either the PGM, internal EE or external EE. Maybe you could whip together a small batch file or a Python script, in which the user selects the bootloader entry mechanism (USB, Serial, SPI, etc), followed by the first image, and where he would like it located, then the next image and its location, and so on. The batch file would generate a '.hex' file with all the bootloader code, which could simply be burned onto the PIC. A help file would also be generated, telling the user which memory locations he should stay out of.

Rohit