Re: Chipset autodetect -- pro and con

[Matthew Sullivan]

Hiya all

My two pennies worth...<G>

[e-mail] wrote:
> > Too Big. Each chipset got it's own data and specs (don't forget we're
> > talking about 386, 486, LX, BX, VX, FX chipset and they got lots of
> > differences) - combining them all together will give a binary file that
> > will probably won't fit into the flash (not mentioning other features we
> > want to have).
>
> We aren't talking about compiling in support for all and every supported
> chipsets, just making it configurable, so one could add support for more
> chipsets in one binary, of course limited by size. This would for instance be
> nice for admins having a large pool of computers with two different
> motherboards.

Compile time config on chipset support will be the answer.. I have an FX so i
need just to compile FX support... I have FX & HX boards so I'll compile both
separatly --> or compile HX & FX into the same binary.... that has to be decided
i think...
> I think this is the answer to many discussions we will probably see:
> Do we want a boot logo?

Yes i think so, even if optional...
> Should it support loading the kernel directly?

Only if the kernel is placed in a _standardised_ place, like the MBR
currently....  If people want kernel ROMs surely it will be better, _and_ SAFER
to just compile a linux kernel boot ROM and pop it onto their nearest
Net/VGA/SCSI card.... cause most are capable of holding custom boot ROMs, and
executing them.
> Should we support 16bit functions for compatibility

Again compile time ... remember you get your _generic_ Linux kernel, you then
compile it to do _exactly_ what _you_ want then you install it.

The generic BIOS is of course the current MB BIOS's, if they take on OpenBIOS,
then implementing the current Flash failsafe (which IMHO is not very well
implemented), similar to the 3Com Router BIOS/Firmware(which is implemented
beautifully <G>), should be made the default.

3Com router Firmware has 3 parts:

Boot Loader - initialises hardware can checks for valid checksum on flash.
Provides a method of re-writing boot/main code, or erasing flash - Does nothing
hardware dependant, works across platform.
Main Code - Takes into account Version/Revision/Chipset can do all functions of
Bootloader, but provides user stuff - the real BIOS as it were.....
Data Code - Settings/config - user deturmined.
> ...
>
> Make it configurable (tm) :)

tu chez!

yours

Matthew (aka Mickey)

Password protection

This is just a random thought:

Perhaps a more granular password protection level?

(I know that we can't do TOO much in this layer, but it would be nice to
have more than power-on, and setup password.)

Of course, it would be good to have the BIOS MD5 or hash the password in
some way to keep someone from reading /dev/nvram and getting said PW.