Hi,
here's a first (draft) implementation for having multiple LinuxBIOS payloads in one image, which will be executed one after the other.
This is part of my GЅoC project work; it's needed for lbmenu, the LinuxBIOS runtime config tool.
More details in the patch.
Uwe.
On 19.08.2007 20:14, Uwe Hermann wrote:
here's a first (draft) implementation for having multiple LinuxBIOS payloads in one image, which will be executed one after the other.
The current implementation has the following limitations:
- Payload files must be named 'payload[0-9]', i.e. payload0, payload1, etc. Actually, you can specify the prefix (e.g. 'payload') via Kconfig.
Can we tell the implementation in some way that we'd like it to ignore payloads with numbers before x?
- All payload files must be in the same target directory (which can be specified via Kconfig).
I'd like not to introduce/keep such limitations.
- The payloads are executed in order, i.e. first payload0 is executed. When that is done and returns control to LinuxBIOS, payload1 is executed next, then payload2 etc. etc.
Can one payload decide which payload to run next? For example, lbmenu might want to make sure the netboot payload is run instead of FILO.
What state do the stack/registers have to be in for returning control to LinuxBIOS? Do we assume anything about the state of the machine after the payload has returned control? Can we flag a payload as "terminal" in the sense that if control is ever returned from it, we should reboot? Think memtest (which overwrites RAM) etc.
Oh, and how would this mesh with Ron's current LAR extension proposal?
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070828 01:01]:
On 19.08.2007 20:14, Uwe Hermann wrote:
- Payload files must be named 'payload[0-9]', i.e. payload0, payload1, etc. Actually, you can specify the prefix (e.g. 'payload') via Kconfig.
Can we tell the implementation in some way that we'd like it to ignore payloads with numbers before x?
Seems simple, but why?
- All payload files must be in the same target directory (which can be specified via Kconfig).
I'd like not to introduce/keep such limitations.
I think this is merely a practical issue as Kconfig is not that flexible.
Can one payload decide which payload to run next? For example, lbmenu might want to make sure the netboot payload is run instead of FILO.
I suggest that LinuxBIOS decides via the CMOS or some similar mechanism (LBtable?) which payload to run next. This should be a mechanism that LinuxBIOS and the payload can modify.
Stefan
On 29.08.2007 09:21, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070828 01:01]:
On 19.08.2007 20:14, Uwe Hermann wrote:
- Payload files must be named 'payload[0-9]', i.e. payload0, payload1, etc. Actually, you can specify the prefix (e.g. 'payload') via Kconfig.
Can we tell the implementation in some way that we'd like it to ignore payloads with numbers before x?
Seems simple, but why?
Ability to modify boot order without reflashing. But this could be accomplished with the "next payload" selection via CMOS.
- All payload files must be in the same target directory (which can be specified via Kconfig).
I'd like not to introduce/keep such limitations.
I think this is merely a practical issue as Kconfig is not that flexible.
OK, as long as the lar can be populated without the help of Kconfig.
Can one payload decide which payload to run next? For example, lbmenu might want to make sure the netboot payload is run instead of FILO.
I suggest that LinuxBIOS decides via the CMOS or some similar mechanism (LBtable?) which payload to run next. This should be a mechanism that LinuxBIOS and the payload can modify.
Agreed.
Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070829 16:36]:
Actually, you can specify the prefix (e.g. 'payload') via Kconfig.
Can we tell the implementation in some way that we'd like it to ignore payloads with numbers before x?
Seems simple, but why?
Ability to modify boot order without reflashing. But this could be accomplished with the "next payload" selection via CMOS.
But if we want the boot order, lets store the indices of all payloads rather than adding lots of implicit assumptions and options like "ignore all payloads up to index". We can easily spare 16 or 32 bytes of CMOS. And that is quite a number of possible payloads to exceed. I bet we run out of flash easier (and out of payloads ;)
Stefan
Hi, Uwe, please be sure to check what I am doing and make sure we mesh. One possibility is a flag we attach on the lar command line like this: run:filename
Which will set a 'run this code' bit in the LAR. I will try to read your patch more thoroughly now.
thanks
ron
I don't see a real problem meshing uwe's work with mine.
We could do this:
normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu normal/payload0, 1, 2, 3, the actualy payload
fallback/preboot should probably not exist, as in fallback we want minimal features.
thanks
ron
On Tue, Aug 28, 2007 at 11:51:08AM -0700, ron minnich wrote:
We could do this:
normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu normal/payload0, 1, 2, 3, the actualy payload
Nak. Why do we need to create specialized functionality? Can't we keep it general?
fallback/preboot should probably not exist, as in fallback we want minimal features.
Someone will probably want it.
//Peter
Peter Stuge wrote:
On Tue, Aug 28, 2007 at 11:51:08AM -0700, ron minnich wrote:
fallback/preboot should probably not exist, as in fallback we want minimal features.
Someone will probably want it.
//Peter
Especially if the fallback requirement still stands, otherwise it would be nearly impossible to use lbmenu+kernel in flash, and I'm sure someone will want that at some point.
-Corey
On Wed, Aug 29, 2007 at 01:36:27AM -0500, Corey Osgood wrote:
Peter Stuge wrote:
On Tue, Aug 28, 2007 at 11:51:08AM -0700, ron minnich wrote:
fallback/preboot should probably not exist, as in fallback we want minimal features.
Someone will probably want it.
//Peter
Especially if the fallback requirement still stands, otherwise it would be nearly impossible to use lbmenu+kernel in flash, and I'm sure someone will want that at some point.
ACK.
I don't really see the big picture when it comes to normal/fallback. Can't this feature be implemented without any special-case code, just using a generic multi-payload mechanism? Fallback being just a normal payload like any other then?
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070829 15:27]:
I don't really see the big picture when it comes to normal/fallback. Can't this feature be implemented without any special-case code, just using a generic multi-payload mechanism? Fallback being just a normal payload like any other then?
It's not only about the payload, but also about the rest of the code. What if you need to update your HT code or RAMINIT and it goes wrong...?
I think it needs a different solution than fallback/normal as we have it in v3.
- on the one hand we want to push linux as a payload - on the other hand we want normal and fallback
there's a pair of scissors in between those two.
Fallback needs to be recovery only and the rest should be multiple payloads.
If the problem we are trying to solve is that on one of 500 nodes of a cluster flashing will go wrong, fallback could as well load a payload or anything else over serial port with ymodem only.
We need a number of real scenarios so that we can verify whether we choose the right set of requirements and whether we choose the right design.
- one requirement would be: if payload can not be loaded, attempt to load it via serial or usb console via ymodem protocol.
Others?
Stefan
On 29.08.2007 15:58, Stefan Reinauer wrote:
Fallback needs to be recovery only and the rest should be multiple payloads.
If the problem we are trying to solve is that on one of 500 nodes of a cluster flashing will go wrong, fallback could as well load a payload or anything else over serial port with ymodem only.
We need a number of real scenarios so that we can verify whether we choose the right set of requirements and whether we choose the right design.
- one requirement would be: if payload can not be loaded, attempt to load it via serial or usb console via ymodem protocol.
Agreed. That way, we could even abuse a fallback image for early porting without the need to reflash continuously.
Carl-Daniel
On Wed, Aug 29, 2007 at 03:58:56PM +0200, Stefan Reinauer wrote:
- one requirement would be: if payload can not be loaded, attempt
to load it via serial or usb console via ymodem protocol.
Only ymodem with serial - USB is already a reliable transport.
On Wed, Aug 29, 2007 at 04:38:47PM +0200, Carl-Daniel Hailfinger wrote:
Agreed. That way, we could even abuse a fallback image for early porting without the need to reflash continuously.
Yes - this has been a thought of mine all the way since the Symposium.
//Peter
Greetings,
On Wed, 29 Aug 2007, Peter Stuge wrote:
On Wed, Aug 29, 2007 at 03:58:56PM +0200, Stefan Reinauer wrote:
- one requirement would be: if payload can not be loaded, attempt
to load it via serial or usb console via ymodem protocol.
Only ymodem with serial - USB is already a reliable transport.
On Wed, Aug 29, 2007 at 04:38:47PM +0200, Carl-Daniel Hailfinger wrote:
Agreed. That way, we could even abuse a fallback image for early porting without the need to reflash continuously.
Yes - this has been a thought of mine all the way since the Symposium.
I've been thinking about that a good bit lately. Once the serial port and CAR is up, a very simple monitor program should be able to accept simple commands and programs from the serial console.
Beyond development, a small, simple and stripped down fallback that can either jump to the normal image or bring up the monitor would be a lot more likely to fit in a boot block and leave room for the normal image to have a good sized payload.
The other thought is having a real boot block that isn't erased when either the normal image or the payload are updated. Even if the image is perfect, a power failure (or someone tripping over a power cord) at the wrong time can ruin your day if the box is production rather than development (and so isn't fitted with a BIOS saviour, LPC hack or even a socketed flash). In the few commercial deployments I did, I had LinuxBIOS set the lockdown bits (intel flash) on the sectors for the fallback image so the customer could have a blessed payload update procedure that wouldn't leave them with a brick.
G'day, sjames
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
||||| |||| ||||||||||||| ||| by Linux Labs International, Inc. Steven James, CTO
55 Marietta Street Suite 1830 Atlanta, Ga 30303 866 824 9737 support
On Wed, Aug 29, 2007 at 04:43:27PM -0400, pyro wrote:
Agreed. That way, we could even abuse a fallback image for early porting without the need to reflash continuously.
Yes - this has been a thought of mine all the way since the Symposium.
I've been thinking about that a good bit lately. Once the serial port and CAR is up, a very simple monitor program should be able to accept simple commands and programs from the serial console.
Right - this is what I've called the panic room code.
The other thought is having a real boot block that isn't erased when either the normal image or the payload are updated.
Yes, this should also be done. This was one of several motivations for lar.
//Peter
On 29.08.2007 23:28, Peter Stuge wrote:
On Wed, Aug 29, 2007 at 04:43:27PM -0400, pyro wrote:
Agreed. That way, we could even abuse a fallback image for early porting without the need to reflash continuously.
Yes - this has been a thought of mine all the way since the Symposium.
I've been thinking about that a good bit lately. Once the serial port and CAR is up, a very simple monitor program should be able to accept simple commands and programs from the serial console.
Right - this is what I've called the panic room code.
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
A bit more detailed: If the BIOS fails to verify its checksum, it outputs a message telling you about it over serial, waits for signature to arrive over serial (a standard char sequence with repetitions at the beginning), reads until it has one complete signature, switches serial to ymodem and accepts a lar archive. The first member of the lar is then executed.
The "wait for signature" is there to allow people to use multiple tries getting serial speed right. OTOH, if the code outputs a continuous stream of "TESTTEXT\n" while waiting for serial input, the other side can verify serial speed settings as well.
What do you think?
Carl-Daniel
On 8/29/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
A bit more detailed: If the BIOS fails to verify its checksum, it outputs a message telling you about it over serial, waits for signature to arrive over serial (a standard char sequence with repetitions at the beginning), reads until it has one complete signature, switches serial to ymodem and accepts a lar archive. The first member of the lar is then executed.
The "wait for signature" is there to allow people to use multiple tries getting serial speed right. OTOH, if the code outputs a continuous stream of "TESTTEXT\n" while waiting for serial input, the other side can verify serial speed settings as well.
What do you think?
That's the way to go.
ron
On 30.08.2007 06:19, ron minnich wrote:
On 8/29/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
A bit more detailed: If the BIOS fails to verify its checksum, it outputs a message telling you about it over serial, waits for signature to arrive over serial (a standard char sequence with repetitions at the beginning), reads until it has one complete signature, switches serial to ymodem and accepts a lar archive. The first member of the lar is then executed.
The "wait for signature" is there to allow people to use multiple tries getting serial speed right. OTOH, if the code outputs a continuous stream of "TESTTEXT\n" while waiting for serial input, the other side can verify serial speed settings as well.
What do you think?
That's the way to go.
Can we invert the speaker line each time a byte is written out over serial? With 115200,8,N,1 we would get an inversion frequency of 11.52kHz and a tone frequency of 5.76kHz. Comparing that tone to some downloadable audio sample would allow people to find out if serial was driven with the right speed.
Regards, Carl-Daniel
On Thu, Aug 30, 2007 at 01:05:32PM +0200, Carl-Daniel Hailfinger wrote:
On 30.08.2007 06:19, ron minnich wrote:
On 8/29/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
A bit more detailed: If the BIOS fails to verify its checksum, it outputs a message telling you about it over serial, waits for signature to arrive over serial (a standard char sequence with repetitions at the beginning), reads until it has one complete signature, switches serial to ymodem and accepts a lar archive. The first member of the lar is then executed.
The "wait for signature" is there to allow people to use multiple tries getting serial speed right. OTOH, if the code outputs a continuous stream of "TESTTEXT\n" while waiting for serial input, the other side can verify serial speed settings as well.
What do you think?
That's the way to go.
Can we invert the speaker line each time a byte is written out over serial? With 115200,8,N,1 we would get an inversion frequency of 11.52kHz and a tone frequency of 5.76kHz. Comparing that tone to some downloadable audio sample would allow people to find out if serial was driven with the right speed.
Should be doable. Have a look at arch/x86/speaker.c in v3 for sample code if you want to give it a try.
Uwe.
On Thu, Aug 30, 2007 at 01:05:32PM +0200, Carl-Daniel Hailfinger wrote:
Can we invert the speaker line each time a byte is written out over serial?
Great idea!
May need some more code for polling the UART status register though.
//Peter
hello,
for some time now i have a bootloader in my howbrew rom emulator that can read / write to memory in on a byte basis and on a block basis using iHex for the block ones i have adapted it it to run on the pc in porting LB to right now. it can erase flash sectors or the whole chip. im thinking about extending it with IO read/write and pci read/write for the larger version ( i only have 8Kbyte atm and that is thight for romcc compiled code:-( )
i use single letters in the range G-Z for commands and ignore 0-9 and A-F that way if a hex download is aborted it just ignores the rest of the input
a nice addition would be to emit the welcome message over and over again with some delay in between (so the reciever is not stressed to much) until the first command
----- Original Message ----- From: "ron minnich" rminnich@gmail.com To: "Carl-Daniel Hailfinger" c-d.hailfinger.devel.2006@gmx.net Cc: linuxbios@linuxbios.org Sent: Thursday, August 30, 2007 06:19 Subject: Re: [LinuxBIOS] LinuxBIOS panic room
On 8/29/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
A bit more detailed: If the BIOS fails to verify its checksum, it outputs a message telling you about it over serial, waits for signature to arrive over serial (a standard char sequence with repetitions at the beginning), reads until it has one complete signature, switches serial to ymodem and accepts a lar archive. The first member of the lar is then executed.
The "wait for signature" is there to allow people to use multiple tries getting serial speed right. OTOH, if the code outputs a continuous stream of "TESTTEXT\n" while waiting for serial input, the other side can verify serial speed settings as well.
What do you think?
That's the way to go.
ron
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Hi,
On 30.08.2007 21:59, todthgie wrote:
for some time now i have a bootloader in my howbrew rom emulator that can read / write to memory in on a byte basis and on a block basis using iHex for the block ones i have adapted it it to run on the pc in porting LB to right now. it can erase flash sectors or the whole chip.
Nice. Can you send a patch/tarball?
im thinking about extending it with IO read/write and pci read/write for the larger version ( i only have 8Kbyte atm and that is thight for romcc compiled code:-( )
So you use romcc?
i use single letters in the range G-Z for commands and ignore 0-9 and A-F that way if a hex download is aborted it just ignores the rest of the input
a nice addition would be to emit the welcome message over and over again with some delay in between (so the reciever is not stressed to much) until the first command
Yeah, a delay between messages in wait mode would be nice.
Regards, Carl-Daniel
----- Original Message ----- From: "Carl-Daniel Hailfinger" c-d.hailfinger.devel.2006@gmx.net To: "todthgie" todthgie@hotmail.com Cc: "LinuxBIOS Mailing List" linuxbios@linuxbios.org Sent: Friday, August 31, 2007 23:55 Subject: Re: [LinuxBIOS] LinuxBIOS panic room
Hi,
On 30.08.2007 21:59, todthgie wrote:
for some time now i have a bootloader in my howbrew rom emulator that can read / write to memory in on a byte basis and on a block basis using iHex for the block ones i have adapted it it to run on the pc in porting LB to right now. it can erase flash sectors or the whole chip.
Nice. Can you send a patch/tarball?
i will make a website for the romemulator. the lb version is to big a hacke to pubish atm and im having stabilty problems with it... if you are realy interested panic.c is attached if i figure out how to make a V3 target for my board and how to enable CAR on a IBM/Cyrix 6X86MX i will port it to V3.
im thinking about extending it with IO read/write and pci read/write for the larger version ( i only have 8Kbyte atm and that is thight for romcc compiled code:-( )
So you use romcc?
yes and im having LOADS of trouble
i use single letters in the range G-Z for commands and ignore 0-9 and A-F that way if a hex download is aborted it just ignores the rest of the input
a nice addition would be to emit the welcome message over and over again with some delay in between (so the reciever is not stressed to much) until the first command
Yeah, a delay between messages in wait mode would be nice.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070830 01:51]:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
I really like the idea. BUT: The one thing that seems unclear is where would we store that lar archive? On the BIOS chip? RAM seems no option as it is not initialized yet.
Stefan
On Tue, Sep 04, 2007 at 11:38:05AM +0200, Stefan Reinauer wrote:
I really like the idea. BUT: The one thing that seems unclear is where would we store that lar archive? On the BIOS chip? RAM seems no option as it is not initialized yet.
Good point.
How usable is the CAR? I guess either the download will in fact write to flash immediately (bad idea!) or only initram would be downloaded first, and then the full lar.
//Peter
* Peter Stuge peter@stuge.se [070905 01:29]:
How usable is the CAR? I guess either the download will in fact write to flash immediately (bad idea!) or only initram would be downloaded first, and then the full lar.
Why would that be a bad idea? I think writing the flash directly (except bootblock) is an excellent idea, since this is the code that is executed when
a) the flash file is corrupt b) a new lar is sent
On 05.09.2007 01:40, Stefan Reinauer wrote:
- Peter Stuge peter@stuge.se [070905 01:29]:
How usable is the CAR? I guess either the download will in fact write to flash immediately (bad idea!) or only initram would be downloaded first, and then the full lar.
Why would that be a bad idea? I think writing the flash directly (except bootblock) is an excellent idea, since this is the code that is executed when
a) the flash file is corrupt b) a new lar is sent
I still would like to try to enable RAM first. That will allow us to verify an image after flashing instead of having to redownload it over serial. Besides that, if there is some timing critical component in the flashing process, we don't want to wait for serial input.
Carl-Daniel
Greetings,
On Wed, 5 Sep 2007, Carl-Daniel Hailfinger wrote:
On 05.09.2007 01:40, Stefan Reinauer wrote:
- Peter Stuge peter@stuge.se [070905 01:29]:
How usable is the CAR? I guess either the download will in fact write to flash immediately (bad idea!) or only initram would be downloaded first, and then the full lar.
Why would that be a bad idea? I think writing the flash directly (except bootblock) is an excellent idea, since this is the code that is executed when
a) the flash file is corrupt b) a new lar is sent
I still would like to try to enable RAM first. That will allow us to verify an image after flashing instead of having to redownload it over serial. Besides that, if there is some timing critical component in the flashing process, we don't want to wait for serial input.
Why not just load and run whatever is downloaded? If the flash is corrupt, send a flash program followed by the image. If under development, perhaps a ram init test or just something to dump registers. During production, it might be memtest or other diagnostic. The one behavior that seems to support every option (and options I haven't considered) is load and run.
That also lets you send raminit code, then a flash image and a flash program that does the verify.
The less it actually does before handing control to the serial line, the less likely it is to do the wrong thing.
I envision something like the Dragonball's bootstrap mode but not with "b-records". A b-record is just a string of hex containing an absolute address, a count and count bytes of data. When it gets a brec with a count of 0, it jumps to the address.
G'day, sjames
Carl-Daniel
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
||||| |||| ||||||||||||| ||| by Linux Labs International, Inc. Steven James, CTO
55 Marietta Street Suite 1830 Atlanta, Ga 30303 866 824 9737 support
On 04.09.2007 11:38, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070830 01:51]:
I'd say it should accept a lar archive via serial console, perhaps using ymodem, and start executing the first member of the lar.
I really like the idea. BUT: The one thing that seems unclear is where would we store that lar archive? On the BIOS chip? RAM seems no option as it is not initialized yet.
What about outputting the size of CAR and how much we have left of it over serial and then allowing to use up to 70% (arbitrary) for code download? That should be enough room to download and execute RAM init code, unless the CPU has really tiny amounts of cache. Even then we could try to split the code and use RAM-over-serial (ok, that's a real hack, but it would work).
Once RAM is running, we could use a different panic room mode as we have megabytes of main RAM for payload download.
Carl-Daniel
* Peter Stuge peter@stuge.se [070829 20:49]:
On Wed, Aug 29, 2007 at 03:58:56PM +0200, Stefan Reinauer wrote:
- one requirement would be: if payload can not be loaded, attempt
to load it via serial or usb console via ymodem protocol.
Only ymodem with serial - USB is already a reliable transport.
I thought just using ymodem might be easier, since it allows to use the same console code on top of physical layers, and people are using minicom and co on the other side.
Is there a non-error-detecting/correcting version of ymodem?
* ron minnich rminnich@gmail.com [070828 20:51]:
I don't see a real problem meshing uwe's work with mine.
We could do this:
normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu normal/payload0, 1, 2, 3, the actualy payload
Keep in mind that there might be images at some point that contain lbmenu, GRUB2, OFW and EFI at the same time.
Stefan
On Wed, Aug 29, 2007 at 09:24:22AM +0200, Stefan Reinauer wrote:
- ron minnich rminnich@gmail.com [070828 20:51]:
I don't see a real problem meshing uwe's work with mine.
We could do this:
normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu normal/payload0, 1, 2, 3, the actualy payload
Keep in mind that there might be images at some point that contain lbmenu, GRUB2, OFW and EFI at the same time.
Yep. I don't think we need or want to make a difference for "preboot" or other payloads. All payloads should be equal.
The "preboot" ones will probably be written by us anyway (e.g. lbmenu) and they can just return control to LinuxBIOS. Most existing payloads (memtest, OFW, Linux, etc.) will not ever return anyway, so they can't be "preboot" payloads in any sense, at least I don't see how.
Uwe.
-
Carl-Daniel Hailfinger -
Corey Osgood -
Peter Stuge -
pyro -
ron minnich -
Stefan Reinauer -
todthgie -
Uwe Hermann