[LinuxBIOS] [PATCH] Download payload from console via XMODEM

[Ed Swierk]

The attached patch adds a new option, CONFIG_XMODEM_ROM_STREAM, that
allows LinuxBIOS to download its payload from the console via the
XMODEM file transfer protocol.

This is handy if you want to try out a payload that's too big to fit
into ROM, and you haven't yet gotten IDE or USB devices to work.

I chose to hook this into the ROM stream code so it can take advantage
of the usual compression methods, but one could imagine moving it to a
separate "serial stream" mechanism.

Comments are welcome.

--Ed

[Carl-Daniel Hailfinger]

Ed Swierk wrote:
> The attached patch adds a new option, CONFIG_XMODEM_ROM_STREAM, that
> allows LinuxBIOS to download its payload from the console via the
> XMODEM file transfer protocol.
>
> This is handy if you want to try out a payload that's too big to fit
> into ROM, and you haven't yet gotten IDE or USB devices to work.

Great! I can see yet another use for this (after some modification):
Testing LinuxBIOS code for additional devices without reflashing
the ROM every time. The flash->plug-chip-in->test->rip-chip-out->flash
cycle would become a flash->reboot->reboot cycle. As long as RAM and
serial are working, additional bringup code could be tested easily.

It would even enable us to create a "generic" ROM for a given
chipset combination, leaving all the mainboard specific code to
the serial stream. With some automation and LinuxBIOS architectural
changes, it should be entirely possible to download all the code
after RAM init via serial line, thereby geting us device bringup
and testing almost for free.
(I had once such self-writing driver stuff lying around (not for
LinuxBIOS though), but it went down the drain when my harddisk died.)
> I chose to hook this into the ROM stream code so it can take advantage
> of the usual compression methods, but one could imagine moving it to a
> separate "serial stream" mechanism.

Compression is essential for anything that has to be downloaded over
the serial line.
> --- LinuxBIOSv2.old/src/stream/rom_stream.c	2006-10-05 17:30:22.000000000 -0700
> +++ LinuxBIOSv2/src/stream/rom_stream.c	2006-10-05 17:22:47.000000000 -0700
> @@ -49,6 +49,8 @@
> unsigned char *x_start = (unsigned char *) (32 * 1024 * 1024);
> int x_len;
> printk_debug("rom_stream: start XMODEM transfer now!\n");
> if ((x_len = xmodemReceive(x_start, 8 * 1024 * 1024)) > 0) {

The ROM stream is put at 32 MB with max length 8 MB, right?
Care to use #defines for these values?

Regards,
Carl-Daniel

[Ronald G Minnich]

have not looked at this much buy why not make a rom stream in src/stream 
that is xmodem? That was the intent of that code.

i.e. your comment on serial stream is correct.
thanks

ron

[Stefan Reinauer]

* Ed Swierk  [061006 02:42]:
> The attached patch adds a new option, CONFIG_XMODEM_ROM_STREAM, that
> allows LinuxBIOS to download its payload from the console via the
> XMODEM file transfer protocol.
>
> This is handy if you want to try out a payload that's too big to fit
> into ROM, and you haven't yet gotten IDE or USB devices to work.
> I chose to hook this into the ROM stream code so it can take advantage
> of the usual compression methods, but one could imagine moving it to a
> separate "serial stream" mechanism.

Moving it into a "serial stream" (which would need to use compression,
too) would be a good idea I suppose.

the rom stream is kind of crowded already..

Stefan

[Ed Swierk]

Here's a new patch, hopefully addressing most of the feedback received so far.

I'm not thrilled with the amount of overlap between rom_stream.c and
serial_stream.c, but I tried to clean things up a bit in the latter.
If folks are happy with the changes, I can apply them to rom_stream.c
in another patch.

Another issue is that the various CONFIG_COMPRESSED_ROM_STREAM options
are now sort of misnamed, as they apply to serial streams as well.
This can be addressed separately as well.

--Ed

[Stefan Reinauer]

* Ed Swierk  [061007 01:45]:
> Here's a new patch, hopefully addressing most of the feedback received so 
> far.

looks good, committed.
> I'm not thrilled with the amount of overlap between rom_stream.c and
> serial_stream.c, but I tried to clean things up a bit in the latter.
> If folks are happy with the changes, I can apply them to rom_stream.c
> in another patch.

please
> Another issue is that the various CONFIG_COMPRESSED_ROM_STREAM options
> are now sort of misnamed, as they apply to serial streams as well.
> This can be addressed separately as well.

Yes, it should be CONFIG_COMPRESSED_STREAM instead. But please make sure
to change all occurences of it in the tree, too..

great work!

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> Ed Swierk  [061007 01:45]:
> > Another issue is that the various CONFIG_COMPRESSED_ROM_STREAM options
> > are now sort of misnamed, as they apply to serial streams as well.
> > This can be addressed separately as well.
>
> Yes, it should be CONFIG_COMPRESSED_STREAM instead. But please make sure
> to change all occurences of it in the tree, too..

Argh! Please don't! It took me long enough to find the difference between
CONFIG_COMPRESSED and CONFIG_COMPRESSED_ROM_STREAM.

Can we have CONFIG_COMPRESSED_PAYLOAD instead? That would at least
indicate what's going on.

Regards,
Carl-Daniel

[Stefan Reinauer]

* Carl-Daniel Hailfinger  [061009 19:15]:
> Argh! Please don't! It took me long enough to find the difference between
> CONFIG_COMPRESSED and CONFIG_COMPRESSED_ROM_STREAM.
>
> Can we have CONFIG_COMPRESSED_PAYLOAD instead? That would at least
> indicate what's going on.

Ok, CONFIG_COMPRESSED_PAYLOAD sounds better. Can anyone send a patch?

[Ed Swierk]

On 10/10/06, Stefan Reinauer  wrote:
> Ok, CONFIG_COMPRESSED_PAYLOAD sounds better. Can anyone send a patch?

The first patch renames CONFIG_COMPRESSED_ROM_STREAM* and
CONFIG_PRECOMPRESSED_ROM_STREAM.

The second one renames the other CONFIG_*_STREAM options.

The third one goes whole-hog and replaces every remaining instance of
"stream" with "payload" in code, filenames and directory names. The
diff is pretty huge due to the file renaming.

--Ed

[Stefan Reinauer]

* Ed Swierk  [061006 02:42]:
> I chose to hook this into the ROM stream code so it can take advantage
> of the usual compression methods, but one could imagine moving it to a
> separate "serial stream" mechanism.
>
> Comments are welcome.

I forgot to say: Very cool idea! We talked about something very similar
on the LinuxBIOS symposium for v3

Stefan