[LinuxBIOS] Concepts for LX v3

[Anton]

It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages.
Pros:
a) Test for DRAM 
b) Test for Media (HDD, CF, SD, ..) connected to the host
c) Test for Peripherals
Cons:
a) size. may not fit into 1/2/4 Mbit.

TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays.
However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. 
Where to store boot options (CMOS is a way too small for it).

Another concept to store big payloads which can't be stored in flash (even 16 Mbit is not enough) is to have
dedicated partition. On booting media. With FAT16 or use a very simple FS to avoid licensing problems (no journaling
features required).

Pros:
a) bigger and more payload sources at once from one place
b) possibility to have several linuxbios images to be flashed back in case of emergency
Cons:
a) need to prepare boot media, like SATA/IDE device, to have dedicated partition
b) need to add support lines for FS on dedicated FS (however, I see FILO can boot ext2 partition,
hope this one will be enough).

Comments are welcome.

[ron minnich]

On 12/2/06, Anton  wrote:
> It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages.
> Pros:
> a) Test for DRAM
> b) Test for Media (HDD, CF, SD, ..) connected to the host
> c) Test for Peripherals
> Cons:
> a) size. may not fit into 1/2/4 Mbit.
>
> TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays.
> However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them.
> Where to store boot options (CMOS is a way too small for it).
>
> Another concept to store big payloads which can't be stored in flash (even 16 Mbit is not enough) is to have
> dedicated partition. On booting media. With FAT16 or use a very simple FS to avoid licensing problems (no journaling
> features required).
>
> Pros:
> a) bigger and more payload sources at once from one place
> b) possibility to have several linuxbios images to be flashed back in case of emergency
> Cons:
> a) need to prepare boot media, like SATA/IDE device, to have dedicated partition
> b) need to add support lines for FS on dedicated FS (however, I see FILO can boot ext2 partition,
> hope this one will be enough).

We're trying to keep linuxbios simple. A TMS payload is fine. Linux is
the desired payload, and linux can do a very good job of testing all
this stuff, and experience shows it has the best bug-fixed drivers.
open firmware could also play this game, and OFW has a lot of drivers
too -- more every day, now that it is open source.

ron

[Stefan Reinauer]

* Anton  [061202 12:28]:
> It would be nice to have TMS (Test Monitor System) onboard. Some big vendors have it on their systems for ages.
> Pros:
> a) Test for DRAM 
> b) Test for Media (HDD, CF, SD, ..) connected to the host
> c) Test for Peripherals
> Cons:
> a) size. may not fit into 1/2/4 Mbit.
>
> TMS is a regular payload, access is done via RS232 (or USB in future), the same way as we all see printk messages nowdays.
> However, it's not yet clear to me is it possible to have multiple payloads at once and how to choose between them. 
> Where to store boot options (CMOS is a way too small for it).

It might also be interesting to put this together with another couple of
tests from : http://www.linuxfirmwarekit.org/
> a) need to prepare boot media, like SATA/IDE device, to have dedicated partition

CDROM or IDECF makes this kind of easy. You need modifications to the
machine most likely, if you want to put parts of this in flash.
Netbooting would be another alternative...

Stefan