[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: fm <email@example.com>
- Subject: [f-cpu] F-ROFS
- From: Yann Guidon <firstname.lastname@example.org>
- Date: Wed, 13 Mar 2002 00:14:42 +0100
- Delivered-To: email@example.com
- Delivered-To: firstname.lastname@example.org
- Delivered-To: email@example.com
- Delivery-Date: Tue, 12 Mar 2002 18:15:09 -0500
- Organization: http://www.f-cpu.org
- Reply-To: firstname.lastname@example.org
- Sender: email@example.com
The recent installation of the Linux From Scratch system
on my new HDD triggered a lot of question, including :
how will we get this damn CPU boot such a complex system ?
- The CPU boots at address 0. It's not a problem,
because usually the page that maps to NULL triggers
a trap and VM is not enabled during bootup. The RAM
address is detected and relocated by our boot code
so the real address of the RAM is not a problem either.
And because the addressable range is potentially
unlimited, it's not a good idea to boot with the address
MSB set to 1 because then our code couldn't boot
on different implementations.
- We have to simulate our system using a VHDL simulator
which is by definition very limited from the I/O point of
view : file open, close, read and write, that's all.
not even a file seek. All I/O will have to go through that,
before we're able to simulate more than a character input/output
(a virtual console). That's very poor : no HDD or video frame
buffer, almost nothing. All we can do is : open/read an image
of the Flash EPROM and map it to address O of our CPU.
For the "virtual console" i consider the creation of a new SR
(called something like SR_VIRTUAL_CONSOLE) which will get or
put a character with the get and put instruction. simple.
Later this could be synthesised as a port to a parallel port
or an UART for command-line debugging...
So it's a really bare system, we have a FLASH EPROM
and a console I/O, no HDD, no video (yet) and we have
to start developping stuff on this like primitive programs,
run a kernel and make a boot loading manager (multi-boot
menu etc...)... And this must be done with very, very simple
tools (not even the heavy GNU toolsuite) that are "linked"
to a static library provided in the Flash (kind of BIOS).
So i started thinking about a really simple "Read-Only File System"
(not exactly a RomFS but you get the idea). This must be handled
with simple structures and algorithms but allow the direct
execution of binaries, allow the loading of drivers and giver some
functionalities that allow a kernel to be configured and started.
I'll start writing code soon, because the idea is fresh and
juicy in my head. What i have in mind solves several problems
without requiring more tools than an assembler (and probably
another tool like mkrofs) and preserves some flexibility.
If you have pointers or ideas, i'll be interested.
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/