From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [PATCH] ARM: zImage: Allow DTB to override broken ATAG_MEM Date: Wed, 7 May 2014 08:29:17 -0700 Message-ID: References: <1399439776-18535-1-git-send-email-bjorn.andersson@sonymobile.com> <20140507080650.GA28564@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140507080650.GA28564@pengutronix.de> Sender: linux-kernel-owner@vger.kernel.org To: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= Cc: Bjorn Andersson , Russell King , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-arm-msm , Stephen Boyd List-Id: linux-arm-msm@vger.kernel.org On Wed, May 7, 2014 at 1:06 AM, Uwe Kleine-K=C3=B6nig wrote: > On Tue, May 06, 2014 at 10:16:16PM -0700, Bjorn Andersson wrote: >> Support overriding ATAG_MEM, by specifying non-zero content of the /= memory/reg >> property in the appended DTB. This is needed to work around bootload= ers passing >> broken tags. > This feels wrong. I think it's quite usual that the device tree > specifies a non-0 /memory/reg property. I checked four more or less > random dts files[1], and three of them have this property set with > actual values. I thought u-boot did something like this, but after checking the code it seems that I was wrong. But if that's not the case then you're right; we have to continue to be bug-compatible with all those dtbs out there. > > So I wouldn't be surprised if this patch results in more damage than > it's worth. The optimal fix would be to make the bootloader do the ri= ght > thing. And if you trust your dtb more than your bootloader, disable > ARM_ATAG_DTB_COMPAT. I unfortunately have a boot loader passing information in ATAG_CMDLINE = that I need, so I can't disable ARM_ATAG_DTB_COMPAT. My problem is that the boot loader on every shipped Qualcomm MSM8x60, M= SM8960 and APQ8064 based device passes ATAG_MEM with the incorrect start addre= ss. There is no way to update the boot loader for these. =46or development I have a .init_meminfo in my board file patching the meminfo; this looks really bad so I'm hoping we can find some alternative solution. The proposed solution from some of the people working on this is to (post build) patch the zImage to inject code that corrects the ATAG_MEM before jumping to the kernel; but I am hoping we can find some sane way instead... Regards, Bjorn