Re: Re: [f-cpu] more about f-romfs

[whygee@club-internet.fr]

hi,

Cedric BAIL wrote :
>I didn't agry with your vision of a bios that his really like a PC BIOS.
i think you are a bit mistaken. What i want to do (others can still
do their own thing) is a minimalistic "monitor" that provides some
utlra-basic functions and then hands the rest of the device-specific
management to other modules.

The "usual" romfs is a very simple protocol that is explained at
http://www.linuxhq.com/kernel/v2.2/doc/filesystems/romfs.txt.html
for example.  i want to do something silimar which can be easily
programmed in asm and simulated in VHDL environment.

>But first what are the possibility for a boot process actually :
>	- Stupid BIOS, who is only doing the initialisation of the needed
>peripheric and give the hand to the first code on the specified disk (it could
>be a cdrom, or whatever you wan't, but local).
There is a problem here : we don't have any HW, I/O or any protocol yet.
How can you program a BIOS if there is no IO ?

>	- A firmware, what you're wanting to do,that mean that he will
>select which kernel to boot and so on. I think, that we need to reflash
>the ROM every time we update our kernel... And it will be very complicated
>for booting OS like hurd...
???
Today's flash can be reprogrammed 10K+ times and rather quickly.
I have a bunch of 1Mb EEPROMs (coming from broken PCs)
and a single pair can give 256 K bytes with a 16-bit bus.
Controlling them is rather easy.
And if your Hurd does not fit in the EPROM, even compressed,
put a HDD setup module and a Hurd loader in EPROM.

>	- Directly boot a linux, like in the linuxBIOS project. I think, that
>not a so bad idea, but you need a big ROM to boot...
If your kernel is <1MB i see no problem (that's 8Mbits which is
still decent).

> This solution give you
>to easily boot over NFS with out having any HD. The only problem, is that we 
>need to port Linux on it first, a job that will be done a day however.

but to develop it, we need tools that allow us to "play" with it.
a simple monitor with a romfs can do the trick with negligible overhead.

>Personnaly I prefer the first solution, because more complex a bios, more
>time it take for a boot, and to be stable.

in order to boot the kernel, you have to read the HDD.
But you have to detect it and initialize it, and we're not in a PC where
most I/O have fixed addresses (ie kbd and screen) so using HW-specific
"modules" is "safe", "simple", "fast" and "configurable".

After all, if the boot routine is accessible in Flash,
then anyone can write his own version. 

> An other think is that in a lot of
>case the kernel will redo what it has been done by it...

right, so why spend time reinventing the wheel when 
the Linux team has done all the work ? ;-)

when can we meet soon ?

>A+
>  Cedric
YG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/