Re: [Qemu-devel] [PATCH v2] arm: add device tree support

[Alexander Graf]

On 01.02.2012, at 14:44, Anthony Liguori wrote:

> On 02/01/2012 07:32 AM, Alexander Graf wrote:
>> 
>> 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.
> 
> The processor has to have a defined sequence where IP is fixed to a specific 
> value, no?
> 
> How else would the real hardware bootstrap software?

Real hardware boots u-boot which initializes lots of things and then goes into 
the actual booting of Linux. Today, we're doing semi-hosting though, without 
u-boot. We just directly boot into Linux.

That's why I'm saying things don't work out all that simple with semi-hosted 
environments. Now you could argue that semi-hosting is a bad thing, but we'll 
always have to have it. On s390 for example, semi-hosting is how real hardware 
works. Or at least the parts that are visible to end users. Especially when you 
model PV machines, you'll have a hard time with fixed reset IPs too.

However, couldn't we model some wiring that allows our dash-kernel-boot-device 
to override the reset vector on CPUs?


Alex