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

[Yann Guidon <whygee@f-cpu.org>]

hello !

nico wrote:
> All this kind of thing are really to simillar to the x86 !

why are people so x86-centric ?
there are other CPUs on Earth. Even DSP and microcontrollers,
whatever. All computing machines don't have the exact same
operating mechanisms.

> Todays, boot rom does one thing : jump to the good piece of code.
sorry, when was the last time you read the Ralph Brown Interrupt List ? :-)

> It must be really small. When need juste something to boot from somewhere
> and that's all !

it's a bit more complex than that... Simply because PCs have generally
documented I/O and memory addresses for most devices. So ANY software
can hit a specific hardcoded location and do its stuff.

F-CPU has 3 things :
 - Flash starts at address 0
 - there is the SR address range where authorised code
    can read / write configuration words
 - there is a private SDRAM range that is defined in the SR space.
that's all and there is no way to know where to send data to/from I/O.
Unless we define a SR-mapped I/O channel.

> Driver and stuff like that are in memory with the kernel.
I hope that we can get a sufficiently large EEPROM space.
Linux Magazine France (february issue) shows a uClinux
implementation with a EEPROM of 2MB (16Mb).

> Yann Guidon a écrit :
> > The boot memory also contains very low-level and primitive
> > routines for doing basic stuff, such as sending error
> > messages (to a virtual console that is mapped somewhere
> > in the CPU, probably the SR). When done, we have to
> 
> Yet an other way to get out of the cpu : beark !!! there only the
> vci/wishbone/amba interface connected to the outside world nothing else
> or it will be a lot of pain in the as !

why ?
Don't forget that during VHDL simulations, we have to debug
both the CPU and the boot code. We need a simple and safe
interface that will not change (from the SW point of view)
when FC0 is implemented. In HW, the SR can be wired to zero.
But in SW, the SR will be interpreted as a message to the user.

And what if there is no I/O in the system, for example when
developping the CPU alone ?

> > Granularity : F-CPU is a byte-addressing machine
> > but the architecture does not like unaligned instructions
> > or data access.
> > * Concerning the instructions, the code
> > blocks should be copied to the main memory and
> > the starting address must be aligned to the 256
> > bit boundary imposed by the cache lines. In fact,
> > code that is optimized for F-CPU aligns loop entries
> > to 32 byte boundaries and it would not be wise
> > to break this. Furthermore, the Flash memory is
> > a rather slow device and is likely to be uncacheable
> 
> ??? Why put it uncacheable ?

simply because the FLASH is likely to reside outside the private
addressing range. this means that all memory references are uncachable.
Trying to make exceptions to this rule of thumb will certainly make
the system more complex and slower to design.
but there's not much "loss" because EEPROM latency is
often around 100ns (?) and the data are not very wide,
the bandwidth is largely below the CPU's working point.

> > (though its contents doesn't change, but you get
> > the idea...). The SDRAM memory has much more bandwidth
> ??? It depend on the memory (for reading not writing of course)

sorry, but 16 bits with even the optimistic 50ns latency can't be compared
to 64 bits with a 10ns burst cycle (pessimistic). there's at least a 20x
bandwidth difference. Unless you are ready to pay specifc and expensive
devices for your own purpose.

> For me, all of the following are much too early. This is system designer
> problem not ours.
Not exactly : the "BIOS problem" comes back often. We have to find a
solution that allows anybody to start hacking, without creating new problems
or diverting us from our core project (CPU design, not BIOS or kernel design).

now, i have to finish debugging some code, good night everybody.

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