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

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



hi,

cedric wrote:

>>hello,
>>
>>this is a first version.
>>comments, enhancements, flaws... can be discussed on this list.
>>    
>>
>
>Really interresting in did, but I don't know if it's really a good idea to add 
>so much thing in the SR.
>
It's the only place where it is suitable.
In fact it has been designed for this purpose.
Otherwise, if the configuration registers are mapped
in main memory space, each CPU core will have to manage the sharing
of this resource, because the memory space is shared
and accessed by all CPUs in the system. Imagine what
could happen if a remote CPU changes a protection bit....

The SRs are used to configure the (local) core and
provide minimum I/O. The proposition of the "microconsole"
only uses 2 SR entries and 18 bits at most. This is very few compared
to the number of existing SRs (around 30 ?) defined in the existing
source code, and we'll need even more if we want to control
the TLB, the IRQ controller, the onchip SDRAM controller(s) etc....
and i forgot about providing some SRs (8) for "scratchpad"
and performance counters...

The management of the SR map is an important work
(it must be centralised so independent modifications don't collide,
for example if you want to add a SR and another function has
been implemented at that address by someone else) but there are
at least some failesafe protections, like the availability of a 
hardwired SR.

> 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...
BTW, SRs are not meant to be fast or user-accessed
(only SR_SIZE_xxx and the performance counters
need to be accessed by the user applications in write mode).

Concerning the kernels : if an "old" kernel runs on "new" CPU,
then some functions will remain unused. If a "new" kernel
runs on an "old" CPU, then the kernel will use only the provided
functions. After all, Linux 2.4 still runs on i486, AFAIK.

If two CPUs have a different SR map (which is not wanted
but can happen), the kernel can update his SR map definition
based on the signature provided by SR_NUMBERS,
SR_FAMILY, SR_STEPPING and SR_URL.

This is more or less what happens on the latest x86 computers,
by the way (and one of the only things Intel did not completely
fail to do).

Yet, there remains many questions when using a multi-CPU
system, either multiple cores on a chip or multiple-chip systems.
Enumeration of the neighbours depends a lot on the topology
and it is obvious that none must be favored. But without topology,
no enumeration is possible, so what to do ? How can a booting
CPU recognize that there are other CPUs in the system ?

>>have a nice day,
>>YG
>>    
>>
>A+
>  Cedric
>
YG


PS :
Opencores.org seems to be down : anybody know what is going on ?


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