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

[nico <nicolas@seul.org>]

Yann Guidon a écrit :
> 
> hello !
> 
> nico wrote:
> > All this kind of thing are really to simillar to the x86 !
> 
> why are people so x86-centric ?

The critisicsm was not about people but about you whygee.

> 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 ? :-)
>

Never ! But don't forget that my work (the real one) is to develop
"calculateur" which are basicaly computers, that's how it's work.
 
> > 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.
> 

Software are written for a specific system. you can use general code but
you parameterise it.

> F-CPU has 3 things :
>  - Flash starts at address 0
>  - there is the SR address range where authorised code
>     can read / write configuration words

??? configuration word in SR. Come on ! stop with SR it's not a magic
word. Use memory maped things, it's simple and easy to use (and it soon
work !).

>  - there is a private SDRAM range that is defined in the SR space.

It's define at the TLB level.

> 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.

STOP SR ! Such general piece of SW never existe ! Build a computer is
far more than a cpu. Changing the cpu is maybe the easiest thing to do !
You just have to change the compiler ! But all other things are much
harder to change (interrupt system, io system (HD,serial,PCI,...)). From
the software point of view, it's simply fixed adress in adress space.
This kind of fixed adress and the cpu defined the computer.

> 
> > 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).
>

I really never mind. We are far from a prototype. I have seen how it's
hard to port µcLinux to Leon, so we are far from a linuxbox with linux !
 
> > 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 ?

Because ! It's not clean ! Nobody do that for interconnections
properties. And simply, because we do not need it !

> 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.
>

We don't need that at all ! You can simpli add none syntetisable
variable inside you're design to check how it's work. No need to put
that in SR.
 
> And what if there is no I/O in the system, for example when
> developping the CPU alone ?
>

;p So you can't interract with it ? So you can't see if it work or not
;p

If you doing so it's the job of JTAG or specific debug feature control
by jtag (as for PowerPC).
 
> > > 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.

??? It's not because it isn't local memory that you can't cache it
!(reread my article about distributed system ;p)

> 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.
> 

It depend on your EEPROM, sorry ! You're last sentence is a lapalissade
?

> > 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/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/