Re: [PATCH] hw/ppc/sam460ex: Update u-boot-sam460ex

[BALATON Zoltan <balaton@eik.bme.hu>]

On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
> On 10/29/25 16:09, BALATON Zoltan wrote:
>> On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
>>> On 10/29/25 15:28, BALATON Zoltan wrote:
>>>> On Wed, 29 Oct 2025, Harsh Prateek Bora wrote:
>>>>> + Thomas
>>>>> 
>>>>> Hi BALATON,
>>>>> 
>>>>> I am unable to fetch it with b4 am, and I do not see it appear on lore 
>>>>> also, not sure if its due to the binary size.
>>>>> 
>>>>> harshpb:patches$ b4 am 20251028151923.10DBB5972E5@zero.eik.bme.hu
>>>>> Looking up 
>>>>> https://lore.kernel.org/r/20251028151923.10DBB5972E5%40zero.eik.bme.hu
>>>>> Grabbing thread from 
>>>>> lore.kernel.org/all/20251028151923.10DBB5972E5%40zero.eik.bme.hu/t.mbox.gz
>>>>> Server returned an error: 404
>>>>> harshpb:patches$
>>>>> 
>>>>> I guess you may need to send a PULL SUBSYSTEM req like Thomas did for 
>>>>> slof:
>>>>> https://lore.kernel.org/qemu-devel/20251027074404.25758-1-thuth@redhat.com/
>>>> 
>>>> Hi Harsh,
>>>> 
>>>> You should be able to download mbox from
>>>> https://patchew.org/QEMU/20251028151923.10DBB5972E5@zero.eik.bme.hu/
>>>> and git am that. This was tested by somebody else and worked.
>>> 
>>> Yes, git fetch from there seems to work, thanks.
>>> 
>>> If needed
>>>> I could try to split the binary into another patch or send you the patch 
>>>> again. Maybe lore does not store large files?
>>> 
>>> Having only binary file update into its own separate patch may be better
>>> as a best practice, so other patch gets non-binary changes for easy 
>>> review.
>>> Also, maintaining the date stamp may also be helpful in some cases.
>>> Let me know if you think otherwise.
>> 
>> Which date stamp maintaining are you referring to? I can split the patch in 
>> two later today or tomorrow if you want and send a v2 but not right now. 
>> For that to compile and work after each patch it would need to add the new 
>> binary in one patch then remove the old one after changing its usage. Or 
>> maybe even 3 patches: first updating submodule, then adding binary rebuilt 
>> from that then changing usage and removing old one. I think this would make 
>> the series larger as git now seems to contain binary diff between old and 
>> new versions but if these are in different patch it may still add the 
>> removed binary as a binary patch. So this only works if the old and new 
>> binary is the same name or renamed in one patch but then that would break 
>> if the usage is not updated in the same patch. So maybe patch one to update 
>> submodule, patch 2 to add binary with old name and patch 3 to rename the 
>> binary could work but does that worth the hassle and any better than this 
>> single patch?
>
> I was referring to the version number in binary name as date stamp which
> is being removed, but that's fine.

As I wrote in the commit message it seems having that in binary name would 
just cause problems when updating it so I use this opportunity to get rid 
of it. Other binaries don't seem to have such version either. (Also the 
old one was named with date stamp upstream but the new one is version 
2015.c which was changed upstream so it would be changing anyway).

> I think we can take this patch as-is
> for now as split doesn't add much value and also we are close to freeze.

Thanks. I'll try the split patches when the firmware is updated next time 
in the future but not having to redo it now saves me some time.

Regards,
BALATON Zoltan