On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote: > On 10/20/20 12:45 AM, Tom Rini wrote: > > 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. > > The problem is that the previous alignment was 4 byte, now it is 8 byte > and that breaks all the other assumptions. So, this patch should be > reverted to fix the platforms which used to work (or use ALIGN(...4), > which is the same as reverting it really). > > And likely the signed image which caused the breakage should be > generated with mkimage -E / -B 8, which would insure the alignment, so > then there is no need to change anything in the code itself.
4 byte alignment is wrong. -- Tom
signature.asc
Description: PGP signature
