On 10/20/20 1:02 AM, Reuben Dowle wrote: >> 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). > > What assumptions? Any code that assumes 4 byte alignment will also work on 8 > byte alignment. > > Reverting is not the same as assuming ALIGN(...4) if incoming data is not > already aligned to 4 bytes (as was the case when I saw crashes).
Can the incoming data _not_ be 4 byte aligned ? How can this be replicated ? >> 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. > > Interesting. I had not noticed the -B parameter previously. I had originally > fixed this issue on an older version of uboot that did not have that option, > and later rebased the fix to newer uboot. I would need to do some testing to > see if this would fix it as well. I believe this is the way to handle this if you are building a custom DT for U-Boot -- just make sure it has the correct parameters. I think this is also related to: 20a154f95b ("mkimage: fit: Do not tail-pad fitImage with external data")