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

[Cedric BAIL <cedric.bail@free.fr>]

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

I really prefer to not put any "device" in the SR, but having their base
address in it is really a good idea. Finally why did you want a 
micro-consol ? On some actual PC mainboard we have some LED that give us
enough information about the booting process. To manage them a I2C bus
will be enough and we still have one for the all the monitor interface
(fan, temp, ...), so why defining a new interface, if some exist ?

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

Why not having an eeprom directly mapped in the memory space so that
we can directly access to it for the boot process (without copy process)?

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

Right, but they will be quickly activated when we need memory, and I hope
that we didn't need more than 1 MB for the boot process !
 
> >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....

Please, we must specify something, like the base address for boot, and
where the boot code is accessible in memory, but not on which support.

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

Your SR_CPU_NUMBER came from ? mainboard ? eeprom ? universe ? How long
is it ?

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

Hum, like the PIII ?!?

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

Isn't it possible to have a discussion ? You know all discussion are not troll !
 
A+
  Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/