From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 19 Oct 2020 18:45:58 -0400 Subject: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data" In-Reply-To: <38fc6118-b7d7-8455-2c05-3cbe368c4f12@denx.de> References: <20201019214026.888876-1-marex@denx.de> <669974501aec485c9263fe5127c4ccb5@4rf.com> <38fc6118-b7d7-8455-2c05-3cbe368c4f12@denx.de> Message-ID: <20201019224558.GR14816@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote: > On 10/19/20 11:50 PM, Reuben Dowle wrote: > > The alignment of 8 bytes would also work if code was expecting 4 byte alignment. So the explanation you give for reverting this does not make sense to me. > > Well, since U-Boot 2020.10-rc5, any STM32MP1 board does no longer boot > and if I revert this patch, it works again (per git bisect). But this > also applies to any other arm32 boards which load fitImage in SPL, all > of those boards are broken in U-Boot 2020.10. > > It seems that the end of the U-Boot image is at 4-byte aligned offset on > arm32, and that is where the DT is also loaded ; but your patch forces > the alignment to 8-bytes, so suddenly the DT location is 4-bytes off. I think this needs some more investigation to figure out what's going on and where the underlying bugs are. This section of the code is where U-Boot is saying it will copy the device tree to. If we're using a device tree in place that's NOT being copied (and someone else has ensured 8 byte alignment of) we need to set the address of where the device tree is, at that time. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: