[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: [f-cpu] more about f-romfs
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
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
> 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 ?
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/