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

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

[Thomas Huth]

On 29/10/2025 07.31, 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 Thomas,
> Is it a known thing to deal with binary updates ?

  Hi,

honestly, I can't remember clearly why we introduced these subsystem pull 
requests in the past ... Maybe it was related to some problems with binary 
patches, but I think it was rather meant as a staged approach for the case 
where the maintainer of the firmware is not the main maintainer of the 
architecture subsystem, so that the main maintainer gets another chance of 
doing tests before the final pull request to the master branch.

Conny, Alexey, do you remember?

  Thomas

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

[Cornelia Huck]

On Wed, Oct 29 2025, Thomas Huth <thuth@redhat.com> wrote:

> On 29/10/2025 07.31, 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 Thomas,
>> Is it a known thing to deal with binary updates ?
>
>   Hi,
>
> honestly, I can't remember clearly why we introduced these subsystem pull 
> requests in the past ... Maybe it was related to some problems with binary 
> patches, but I think it was rather meant as a staged approach for the case 
> where the maintainer of the firmware is not the main maintainer of the 
> architecture subsystem, so that the main maintainer gets another chance of 
> doing tests before the final pull request to the master branch.
>
> Conny, Alexey, do you remember?

Hmm... I thought subsystem pull reqs were mainly intended for the case
where there might be different maintainers, or one person handling a
subsys for that release. However, I'm not sure if I ever actually b4
am'ed a binary update (for s390, I think I usually regenerated the
binary myself, and it would get merge via a pull from whoever was
handling the main branch.)

Regardless, I think it's easiest to put a binary update into its own
separate patch?

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

[BALATON Zoltan]

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. 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?

Regards,
BALATON Zoltan

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

[Harsh Prateek Bora]

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.

regards,
Harsh

> 
> Regards,
> BALATON Zoltan
> 

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

[BALATON Zoltan]

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?

Regards,
BALATON Zoltan

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

[Harsh Prateek Bora]

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. 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.

regards,
Harsh

> 
> Regards,
> BALATON Zoltan

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

[BALATON Zoltan]

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