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