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<anth...@codemonkey.ws> 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
