Rep:Re: [f-cpu] spec draft about booting F-CPU

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

-----Message d'origine-----
De: Yann Guidon <whygee@f-cpu.org>
A: f-cpu@seul.org
Date: 13/10/02
Objet: Re: [f-cpu] spec draft about booting F-CPU

hi !

it was only a matter of time before this "discussion" arises :-)

nico wrote:

>On Sun, 13 Oct 2002 16:49:48 +0100
>Yann Guidon <whygee@f-cpu.org> wrote:
>
>>hi,
>>
>>cedric wrote:
>>    
>>
>>>I mean they will be really slow and not easy to 
>>>access from a kernel because it didn't exist on other architecture so
it need 
>>>a special work.
>>>
>>now imagine the mess if it is mapped in memory...
>>    
>>
>I imagine it very well. All computer/microcontrolor/DSP work like that
!
>  
>
yup. for example, a microcontroller like the 8080 evolved into a 8086 
and now,
after several generations of standards and software and hardware 
abstraction layers,
out PCs are some of the most complex things that are available on the 
free market.
How many CDROMs are required to explain how your PC works "under the OS"
?

Another example : 8086/8088 defines the interrupt table as starting at 
address 0
and spanning 1 K byte. Later, as i286 came, a "specific register" was 
created
to change this address under SW control. Yet, even today, the first 
KBytes are
reserved to IRQ and BIOS in "real mode", for "compatibility reasons". 
Wouldn't
it be better if such resources were configurable, instead of defining a 
specific address ?
This allows later implementations to not suffer from "early design
choices".

>>>Hum ! We design a cpu not a computer ! That's all the difference.
There is an interrest to be enought configurable to remove and add
peripherals but when it's on silicon such flexibility as no raison to
exist. Read the LEON documentation, maybe you will better understood...

Why do you think the PCI standard allows device enumeration ?....
If i follow your logic, it's much easier to allocate an address for
EVERY
board that is built. yeah :-)

Oh, btw, i have an answer that will probably be suitable for you :
DSP- or microcontroller-based systems don't have to evolve and have less
pressure on compatibility. This is probably why this old habit is still 
around.

>>>No, if you fixed SR mapped it's even worst than fixed memory map.
It's almost the same but SR-map is not standard at all.

>If cpu are design to use only one single bus (from the outside world)
it's to add what ever you want peripheral.
>
huh, i don't understand your english here....

>>>From tehorical point of view a cpu is seen as a black bos that speak
to the outer world thought a unique buses. If you break this universal
rules, you will cross very big theorical problem.

> For sparc, there is an "SR" to change memory map so the tlb is
accessed like that.
>  
>
can you elaborate, please ?

>>>This is a configuration register where you change the adress space of
the chip. It's not a tlb. So for some register you could access the tlb
or what ever things you want.


>A serial interface as nothing to do inside the cpu.
>
who spoke about a serial interface ? are you speaking about the 
"microconsole"'s SRs ?
this is a parallel interface, from the software point of view : you 
implement the hardware
the way you want.It's up to you. You can even decide to not implement 
it, if you like.

> It's a very slow thing,
>
the goal is not speed here. It should be obvious.
Early developpers and users need a simple, low-level access
to the boot code. On a PC, where the address map is "frozen"
for a long while, it is possible to program a link though the parallel
printer port, for example. the BIOS usually ouputs specific codes
on this port, that show the progression of the BIOS setup, before
the screen BIOS is executed. The problem here is not speed either,
just to report useful information in case the BIOS is corrupt, a HW
device doesn't work, or anything like that.

>>>What ever you say or speak you always think PC ! For typical embedded
target, you have a cpu, an eeprom or a jtag link to full the RAM of the
cpu to boot, and a link like rs232. The "printf" of the librairy used
inside knows how to use the rs232, it's like terms under linux.

On F-CPU it is not possible : F-CPU is not a PC, but a CPU core.

>>>So there is nothing to add more than jtag interface and debuging
facilities (like leon or ARM !!). Such interface are not seen at all by
the cpu and control directly it's beavior. It's not dependend on SW
runnning on the cpu.

it has no means to communicate with an external reporting device,
unless you can afford to put a logic analyser on the outside bus.

>>> :) begginner... jtag ?

Furthermore, this means must be portable across implementations
and families, so mapping the console to memory is not possible.
What would happen if several CPU want to speak at the same time ?...

>>>where is the problem ? You have one link per chip. If there many cpu
on a chip, it will happen what happen when you launch many programe on a
linux term. It will mix the output. And where is the problem ?

Using a SR solves this problem. First, the SR map is the only area
where a map is defined. Then, it is private to each CPU, so there
is no multi-CPU worries. Finally, it is very easy to implement in

>>> you don't even speak about multi-cpu !

HW and SW. You have the choice of the physical interface
and you can use this for remote debugging or troubleshooting
if your system fails. For example, if a PCB doesn't seem to work,
it's possible to just plug a JTAG probe and see if the boot code had
started, instead of plugging a logical analyzer on the bus. And what
if it is a "SOC" and there is no external bus that can be probed ?

>>>What do you think is used nowdays ? My DEA research project was about
the problem of the programmability of SOC, 2 years ago.

> can't be remapped by an os, can't directly be accessed by user
application.
>  
>
not the goal either.
but it's funny : you use arguments here, but you claim the contrary in 
your first criticisms.

>>>?

>And most of all, why complicated a so simple thing that a rs232
peripheral ?
>
RS232 is "simple" ? you have to worry about all the protocol and stuffs 
like start, stop, parity, baud rate....
On the SW side, it's complex because it needs polling or interrupt code,
 and ACK is requires even more code. And defining that each F-CPU core
must have a RS232 interface is like, huh, an overkill....

>>> ;) RSR232 is standard and used every where.

> You could even download it from opencores.com.
>  
>
yup (but it seems to be unreachable).
so you want to map a full UART in the SRs ?.........

>>>no SR. SR are for cpu stuff and stuff that is maid inside the cpu for
speed, like the memory and tlb management, that is all.

>Christophe could explain more about such thing, but from my point of
view it's unusefull, and complicate things for nothing.
>  
>
complex ? a pair of SRs with a straight-forward handshake protocol,
what did i miss ?

>>>it will add things to the cpu that have nothing to do with cpu. So
it's a bloc that increase the complexity for nothing.

>>> hello,
>>> 
>>> this is a first version.
>>> comments, enhancements, flaws... can be discussed on this list.
>>> 
>>> have a nice day,
>>> YG
>>
>I don't understand the interrest of you're "SR interface".
>
For short (but i'm sure you know this already, though you seem
to be very microcontroller-oriented), if some address or function is
defined, it should be in the SR instead of being mapped in memory
at a fixed address. If some device is memory-mapped, the mapping
address must be configured in the SR. The memory addressing area
is designed for high-speed storage, not for slow and blocking 
communications.

>>>There is no real difference between fixed SR map and fixed memory
map. SR map introduice a new adresse space that not have the same
capability than the memory interface. 

BTW the text explains more than just SR stories.
it also speaks about minimal contents of a boot code.

>To begin to boot you need a programme to read, and for you, you need
some thing to control the state of the booting cpu. What it is a humain
? An other system ?
>  
>
whatever is required. It can remain unplugged.
But if the system fails, a user or developper can connect to this "port"
to locate where the system hangs.

>>>Jtag stuff !

Furthermore, there is another implication :
As this interface is the same for SW-versions or silicon versions,
this interface can be used to run regression tests and compare results
automatically. For example, a simple program (let's say, a pocket 
calculator)
can be running on the booted CPU without any other device driver.

>>> You want to add silicon to replace sw code !!!!!! That's $^ù*!:; !

This program would be available in source code in the F-CPU source tree
and compiled and run on the simulator. Then, regression tests can use
a simple set of input patterns and errors could be detected by a "diff"
with the expected answer. Later, when a silicon or other implementation
is available, the same test can be run.

>Why don't we use a single supid ROM interface (eeprom, what ever you
want), even serial. A hw mecanisme copy the ROM to the memory and the
cpu start execute the code at a predefined adress. Why reinvented the
wheel ? If you want to check DRAM, you could start inside the cache
memory. 
>  
>
AFAIK, ALPHA does that.
however, we can't rely on the structure of the caches in the future.

>>>You want to keep compatibility between new cpu and old prom boot ?
*gni*

It also implicitly limits the size of the booted code, what would happen
if the cache is not large enough ?...

>>>boot code have very minimal things to do. He try to access DRAM. And
then use it.

It is also painful to design a cache that can be set by external HW.

>>> ?

It is so easy to simply say : initialise the instruction pointer to 0 
and let the cache do what it is meant to do.
I believe it is simpler than having to design a HW that reads the 
external ROM and plays with the cache line entries (this design would be
of course too much dependent on the external interface and the internal
features).

>So you don't want to define a memory map like a working computer should
do but you define a things sticked to the cpu silicon ?
>  
>
what do you mean by "working computer" ?.....

>>> you want to add design constraint to a cpu like it is a whole
computer. Compatibility issue is more on access to the underlaying
hardware rather than isa because the c compiler does the needed
abstraction layer. It's really true. Maybe we could define a way to be
very flexible (pci stuff) but it as nothing to do with boot process...

i'll try to answer the question that i have understood :
i try to avoid the known causes of compatibility problems.
And if it doesn't fit your needs, you can hack into the VHDL source
and make your own boot code, if you want.

>I don't understand why physical adress must be continuous ? virtual
memory management should play is roll. So why such constraints ?
>  
>
when the CPU boots, VM and paging is not yet configured.

continuous addresses are also so much simpler to manage than many 
scattered blocks,
don't you think ? it makes the address decoders easier to design.
But i'm sure you can find cases where scattered memory blocks are 
desirable :-)
Now look at the computer you're currently using. it's a PC.
I dont know how much RAM it has but mine has 288MB : one 32MB
and 2x 128MB module. don't you think it's more complex to think about
them as continuous ? Unless you want all modules to start on a gigabyte 
boundary...

>>>But for the hardware it's not continuous at all !

then, i don't think that the malloc and kernel codes will apreciate.

>Each cpu could have it's own eeprom that's not a problem at all.
>
right. but it depends on the case and the application.
For example, a dual CPU PC has only a single boot ROM.

>>> PC... quite normal they use a single chip to access the memory, so
you only need on eeprom access to the chip. FCPU have dedicated memory
interace on each chip...

Maybe you can find examples where there is more, but at least
you can find these dual CPU boards in the public stores in Paris.
The first reason is to cut costs, another is compatibility with
single-CPU systems. Now, F-CPU should have as few compatibility
problems as possible, so the reason to choose whether a single ROM
is used or not is not dependent on the CPU specification, but it
depends on the context, on the price tag, on the scalability....

> You could have a hardwire code to fixe the cpu numer.
>
> this number could be reread throught SR or memory.
>  
>
i thought about this, too.
however it's a static allocation thing and it doesn't answer all the 
questions.

>>>Sure. What happen if you add a cpu to machine.  But it's more a
system designer problem, no ? SR interface will change nothing on that.

Currently, i think about using a "scratch SR" (a classical read-write 
location in SR space) to store the CPU number in the system. This can
also be read from the PCB slot or something like that, during powerup.

But it doesn't answer the question "how much RAM does the whole
system contain" and "how is this RAM distributed", as we can't expect

>>> at the first stage of boot, the eeprom code will read this value
thought the i2c bus dedicated to that.

or assume that all CPUs have the same type and amount of RAM.
And it also depends on how the chips are connected together.

Sure, each CPU could have its own boot ROM with a dedicated code
where the base address and RAM size is stored, for every CPU.
But it can be more cost-efficient to have a single ROM, from which
all CPUs boot, and also containing a table describing the memory layout
(base address of each CPU etc).

>>>that's a more interresting question. It's : how flat is our physical
adress space ? If this should be defined by boot process, it's much more
flexible.

If there is a SR_CPU_NUMBER available, then each CPU can boot
from the same code and initialise the DRAM base address by using the
CPU number as an index in the memory layout table.

>>>Yes, it's the simple, static way.

I think it's the cleanest and simplest solutionn, because it doesn't
specify a given number of PROM and CPU. It's also a weakness
because it relies on the PROM to be up to date :-(

>>> ????

But at least it requires a single SR_CPU_NUMBER (i hope that nicO
will agree on this).

>>> i agree it's simple but as you said before, it's not really usefull
if node could be added to a system. In a chip, you will have one or more
cpu, peripheral, memory interface and one or more io interfaces, (+
debug interface and eeprom boot). Maybe some dialogue could be send
tought io interface to discover neibourghoud. Or we completly drop such
feature not really used nowadays (in fact 8 way computers are design to
have 8 cpus or ...less)

Can i update the file to include this ?
or do we want to troll a bit again before ? :-)

>>>i could troll again... What about unique cpu number that could only
be accessed in superuser mode ? Then an algorythme could be used to
discover the cpu network and assigne adress space... ok it's much more
too complicated ! This SR should be used to defined local physical
adresse space.

>I stop reading the rest of the draft, it's to much... "deconnected to a
reality".
>  
>
Maybe it's not a dirty enough hack ?

>>> It's soon too dirty. 
Boot :
- initialisation of the DRAM interface, (i think that you don't really
need the use of the internal cache as RAM for such little thing but it
could be an interresting feature.)
- use of it !
- then what ever BIOS could take the cpu, as normal code (for memory
test,...).
nicO

have fun anyway,

>nicO
>
YG

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


______________________________________________________________________
Exclusif: 75 euros remboursés sur le pack eXtense Haut Débit de Wanadoo ! 
Cliquez ici : http://www.ifrance.com/_reloc/mail.exclusif 

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