On Thu, Sep 06, 2012 at 10:09:14AM +0100, Simon Horman wrote: > Hi Will, > > On Thu, Sep 06, 2012 at 10:01:28AM +0100, Will Deacon wrote: > > Hi guys, > > > > On Thu, Sep 06, 2012 at 04:29:02AM +0100, Simon Horman wrote: > > > On Wed, Sep 05, 2012 at 03:34:09PM +0100, Matthew Leach wrote: > > > > Also, I use a > > > > different segment for the dtb rather than appending it to the > > > > zImage; I think this approach would be better as it is less > > > > restrictive, however a kernel patch is required to set r2 to the > > > > appropriate address on entry to the new kernel. What are your > > > > thoughts? > > > > > > I would prefer to avoid requiring kernel changes unless necessary - > > > the kernels some of the boards I work with require DT since 3.5. > > > However, I am happy to discuss this further, there certainly is > > > merit to a clean implementation. > > > > I had a quick look at both the approaches and it looks like Matthew requires > > changes to the host kernel (to load the dtb correctly) and Simon requires > > changes to the target kernel (to pick up the dtb correctly). > > Could you explain a little why you feel my patch requires a change to > the target kernel? Sure, I may be misunderstanding something, so please shout if that's the case! Anyway, I was under the impression that you required CONFIG_ARM_APPENDED_DTB to be enabled in the target so that it can pick up the new DT. If that's not the case, then you'll need to change the host kernel to fix up r2 (rather than point it at the KEXEC_ARM_ATAGS_OFFSET, which is too small for a dtb). What am I missing? Will
