From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH OSSTEST v3 00/15] support for ARM32 arndale and cubietruck platforms Date: Tue, 25 Nov 2014 16:27:27 +0000 Message-ID: <1416932847.11944.16.camel@citrix.com> References: <1416505070.26869.2.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1416505070.26869.2.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2014-11-20 at 17:37 +0000, Ian Campbell wrote: > The major blocker right now is that rerunning > mg-debian-installer-update pulls in a newer kernel from backports.org > which doesn't boot on the existing midway platform. I'm investigating > that at the moment. This investigation resulted in an upstream patch: http://thread.gmane.org/gmane.linux.drivers.devicetree/100386 http://thread.gmane.org/gmane.linux.drivers.devicetree/100420 which I hope will go upstream shortly. The underlying issue was a bogus size field in the header of the DT which is burnt into these systems. When booting via the u-boot command line this can be worked around with: fdt addr $fdt_addr fdt resize which walks the FDT, recalculates the real size and updates the header. Unfortunately there is no opportunity to do this when booting via PXE, as we do for host install. Given the lack of support from the, now-defunct, manufacture of these systems I'm a bit reluctant to go poking around in the firmware to fixup the embedded FDT in case I brick it. I think the fix will go upstream shortly, then I can add it to the Debian kernel, get it uploaded, wait for it to propagate into Jessie, get it uploaded to bpo. In principal I could build us a custom kernel deb to use here (it's reasonably easy for me), but would you be happy with that? Perhaps mg-update-debian-installer should be modified to look in some locally constructed repo instead of at bpo? I'm wary of doing this, since it just makes it harder for someone else to replicate things, plus it just seems dodgy... Ian.