On 10/20/20 2:27 AM, Reuben Dowle wrote:
>>> 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 ?
>
> In my case I have an offline signing process (separate from build server to
> keep secure boot keys safe), and this runs a script which also patches the
> main uboot device tree with some extra properties, then updates main uboot
> dtb with kernel signature, then finally updates the spl dtb with the uboot
> signature. I think when mkimage patches the dtb with the signatures, this
> results in the alignment issues (the unsigned bootloader direct from the
> uboot make process does not experience this issue).
>
> Possibly using mkimage to add padding would also fix the alignment issue I
> see at boot time.
>
>>> 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")
>
> I will look into this, although unfortunately I am very busy with other
> projects right now so can't retest th
In that case, I would propose to revert this to fix existing boards in
mainline, and if your tests are not successful, revisit this issue.
I am rather sure what you are hitting is related to the mkimage patch
above, there was a lengthy discussion on that topic before.
