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

[Anthony Liguori]

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

Regards,

Anthony Liguori

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