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

[Alexander Graf]

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

> On 02/01/2012 07:49 AM, Alexander Graf wrote:
>> 
>> 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.
> 
> Fine, but to boot u-boot, the real hardware must set IP to something that's 
> most likely an offset into ROM flash.
> 
> Why can't we bootstrap semi-hosted mode by having a ROM somewhere that just 
> redirects IP?
> 
> It doesn't have to be a full blown u-boot.

That would work, yes.

> 
>> 
>> 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.
> 
> s390 is a special case because "real hardware" is not actually real hardware. 
> It's a VM.

Sure, but how would we model things there? Our model needs to be flexible 
enough to cope with these oddballs.

In fact, s390 is even more complicated. For DASD boot, the CPU is stalled at 
first and instead the DASD controller reads some instructions from memory that 
then bootstrap the bootloader. But IIUC that's only the case for DASD boot. For 
zfcp boot, you basically get semi-hosting.


Alex