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

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

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

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.

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

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

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

On F-CPU it is not possible : F-CPU is not a PC, but a CPU core.
it has no means to communicate with an external reporting device,
unless you can afford to put a logic analyser on the outside bus.
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 ?...

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


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

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

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

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

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.

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.
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.
It also implicitly limits the size of the booted code, what would happen
if the cache is not large enough ?...

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

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

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

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.

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

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

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

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/