[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] F-ROFS



g'night,

Michael Riepe wrote:
> On Wed, Mar 13, 2002 at 12:14:42AM +0100, Yann Guidon wrote:
> > Hello,
> >
> > 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 ?
> 
> By writing a decent BIOS? ;)

argh, who would believe in that ? :-P

> > Constraints :
<snip>
> >  - 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...
> 
> Better use memory mapped I/O. The real one will have to do that
> anyway.

I had thought about this but i don't really agree. I remember
of the SPIM (a MIPS simulator) which does this, but it's done
in C only. In the case of F-CPU, we have several targets
with different constraints : VHDL (really limited), C sim
(much better but some stuff may be unrealistic) and HW.
It would be nice to have our code reused without modification
on all versions and the memory mapped character I/O creates
some unanswearable questions like how to handle multiple platforms
with different memory layouts, how to intercept the memory access
if it falls in the range of some other I/O, how to handle
the timing problems in a real implementation ? using a SR
is simple, safe and easily configurable, without interfering
with the caches and can trap depending on the condition...

> > 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).
> 
> I'd rather start with something different: an instruction-level emulator
> that directs system calls to the host OS (via a syscall/trap instruction,
> or some memory mapping tricks). That way, you can use almost any system
> call of the host OS. You just can't port the kernel itself.

 I also thought about using the trap/syscall instructions but it
creates a little problem. I don't have the instruction map in hand
but syscall has an immediate data word which indicates the service
to request. So it jumps in kernel mode to service*64 + sr_syscall_base,
and does its things. So it implies that the character is present in a
previously specified register which must be read later. It also
implies that the syscall mechanism is setup but what happens if
there's an error at that time ?...

OTOH, get and put can be configured to trap, too, so we can get back
to your situation, but not the other way as easily...


mmmm i also have to update the assembler and add some features
like including immediate words (like "dd 01243567h"). that's useful.

i should sleep, sometimes, too :-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/