steven james pyro@linuxlabs.com writes:
Greetings,
I've been working with a tagging system so that multiple payloads in firmware can be selected from serial at boot time.
The scheme adds a 16 byte tag block in front of each payload containing a $TAG$ signature, additional block count, a payload length (optional, may be 0), and a name string.
The idea is to search for tags in the ROM, present the name strings in a list and allow selection of a particular target. The stream is then positioned just past the tag and passed to elfboot.
My memory is that tags don't rewind, because it could be something like a serial port...
changes: elfboot no longer calls stream->init(), it presumes that has been done already.
add stream methods: searchtags gettags loadtag
search tags performs the search and specifies the neded buffer size to hold the result.
gettags loads the tags into a provided buffer for presentation
loadtag positions the stream just after the selected tag index (0 based)
for backwards compatability: Where no tags are found, the stream is positioned at the beginning
where the stream->searchtags == NULL, presume the stream object doesn't support tags. Just call init and pass it to elfboot.
Yes, No, Comments?
The tags can be done as ELF notes, so an extra header is unnecessary.
Whatever happens in LinuxBIOS itself should be non interactive, and unconditional. There are a whole lot of ideas about interactive bootloaders, and accepting them all into the core opens us to all kinds of bloat and feature creep. So the interactive code needs to be a seperate payload.
If it can be done without penalizing the rest of the code it is ok to put that ELF payload into the tree. But not into the core.
Eric