On 01.02.2012, at 14:25, Anthony Liguori wrote:
On 02/01/2012 07:10 AM, Peter Maydell wrote:
On 1 February 2012 13:04, Anthony Liguori<address@hidden> wrote:
How does it race? Devices normally never touch memory so a loader device
will be the only thing mucking with memory.
The obvious one is "loader reset function wants to set starting PC to
entry point of kernel/etc" vs "CPU device reset wants to set starting
PC to hardware-mandated reset vector". We have this at the moment, of
course, and I think we implicitly rely on reset handlers being called
in order of registration...
I'm a bit confused, why can't the kernel loader be implemented in terms of a
firmware blob?
This is what we do for x86 and it solves this problem robustly. Isn't it just
a matter of a few instructions to do a jmp to a known location?
Only if you have non-semi-hosted modes. For e500 for example, we don't have a bios flash
region mapped through mmio available. So we would have to write the "jump to
kernel" code into ram. But where in RAM? Linux starts at address 0, so that one's
taken.