update firmware binary for v5.4

update firmware binary for v5.4

[Renjiang Han]

Hi

The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:

   Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 
12:02:02 +0000)

are available in the Git repository at:

   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git 
update-video-fw-sm6150

for you to fetch changes up to 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:

   qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 15:04:09 
+0530)

----------------------------------------------------------------
Renjiang Han (1):
       qcom: venus-5.4: update firmware binary for v5.4

  WHENCE                      |   6 +-----
  qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
  qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
  3 files changed, 1 insertion(+), 5 deletions(-)
  delete mode 100644 qcom/venus-5.4/venus_s2.mbn


Best Regards,

Renjiang

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
> Hi
> 
> The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
> 
>   Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
> +0000)
> 
> are available in the Git repository at:
> 
>   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
> update-video-fw-sm6150
> 
> for you to fetch changes up to 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
> 
>   qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 15:04:09
> +0530)
> 
> ----------------------------------------------------------------
> Renjiang Han (1):
>       qcom: venus-5.4: update firmware binary for v5.4
> 
>  WHENCE                      |   6 +-----
>  qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes

And this firmware file is also going to work on SC7180, correct?

>  qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes

Vikash, Dikshita, could you please comment, what is going on here?

We have added venus_s6.mbn, then dropped it, saying that a normal
venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
(why?). Mario merged it despite my NAK, but that's a separate topic.
Now we are dropping it again.

The firmware is the ABI between userspace and the kernel. We can't
randomly add and remove files here.

Which file names are / were in use by the upstream kernel? I tried hard,
but I couldn't find any mention of venus_s2.mbn in any of the patches
on the linux-arm-msm mailing list.

>  3 files changed, 1 insertion(+), 5 deletions(-)
>  delete mode 100644 qcom/venus-5.4/venus_s2.mbn

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Vikash Garodia]

Hello Dmitry,

On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>> Hi
>>
>> The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>
>>    Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
>> +0000)
>>
>> are available in the Git repository at:
>>
>>    https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
>> update-video-fw-sm6150
>>
>> for you to fetch changes up to 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
>>
>>    qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 15:04:09
>> +0530)
>>
>> ----------------------------------------------------------------
>> Renjiang Han (1):
>>        qcom: venus-5.4: update firmware binary for v5.4
>>
>>   WHENCE                      |   6 +-----
>>   qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
> 
> And this firmware file is also going to work on SC7180, correct?

Yes, we have got this validated on SC7180 as well.

> 
>>   qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
> 
> Vikash, Dikshita, could you please comment, what is going on here?
> 
> We have added venus_s6.mbn, then dropped it, saying that a normal
> venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
> (why?). Mario merged it despite my NAK, but that's a separate topic.
> Now we are dropping it again.
> 
> The firmware is the ABI between userspace and the kernel. We can't
> randomly add and remove files here.
> 
> Which file names are / were in use by the upstream kernel? I tried hard,
> but I couldn't find any mention of venus_s2.mbn in any of the patches
> on the linux-arm-msm mailing list.

venus_s2.mbn is not used anywhere. It was earlier planned to be used on 
qcs615 while venus.mbn would continue on sc7280, but then we wanted to 
use same bins for sc7180 and qcs615.

S2 variant can be produced now by re-signing this venus.mbn itself. To 
achieve this part, there were some elf alignment fixes, which is done 
with this bin to make it re-signable with any vendor specific #.

Regards,
Vikash

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
> Hello Dmitry,
> 
> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
> > On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
> > > Hi
> > > 
> > > The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
> > > 
> > >    Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
> > > +0000)
> > > 
> > > are available in the Git repository at:
> > > 
> > >    https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
> > > update-video-fw-sm6150
> > > 
> > > for you to fetch changes up to 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
> > > 
> > >    qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 15:04:09
> > > +0530)
> > > 
> > > ----------------------------------------------------------------
> > > Renjiang Han (1):
> > >        qcom: venus-5.4: update firmware binary for v5.4
> > > 
> > >   WHENCE                      |   6 +-----
> > >   qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
> > 
> > And this firmware file is also going to work on SC7180, correct?
> 
> Yes, we have got this validated on SC7180 as well.

Thanks for the confirmation.

> 
> > 
> > >   qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
> > 
> > Vikash, Dikshita, could you please comment, what is going on here?
> > 
> > We have added venus_s6.mbn, then dropped it, saying that a normal
> > venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
> > (why?). Mario merged it despite my NAK, but that's a separate topic.
> > Now we are dropping it again.
> > 
> > The firmware is the ABI between userspace and the kernel. We can't
> > randomly add and remove files here.
> > 
> > Which file names are / were in use by the upstream kernel? I tried hard,
> > but I couldn't find any mention of venus_s2.mbn in any of the patches
> > on the linux-arm-msm mailing list.
> 
> venus_s2.mbn is not used anywhere. It was earlier planned to be used on

Ack, please split into two commits, each having a proper explanation.
Please make sure that in future we don't add completely unused files.

> qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
> same bins for sc7180 and qcs615.

What is the status of the current venus-5.4/venus.mbn file? Does it work
AS IS on Talos EVK that is being in process of upstreaming and on QCS615
ADP AIR aka RIDE boards?

> S2 variant can be produced now by re-signing this venus.mbn itself. To
> achieve this part, there were some elf alignment fixes, which is done with
> this bin to make it re-signable with any vendor specific #.

I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
is the difference between it and the new one?

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Vikash Garodia]

On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
> On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
>> Hello Dmitry,
>>
>> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
>>> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>>>> Hi
>>>>
>>>> The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>>>
>>>>     Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
>>>> +0000)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>     https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
>>>> update-video-fw-sm6150
>>>>
>>>> for you to fetch changes up to 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
>>>>
>>>>     qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 15:04:09
>>>> +0530)
>>>>
>>>> ----------------------------------------------------------------
>>>> Renjiang Han (1):
>>>>         qcom: venus-5.4: update firmware binary for v5.4
>>>>
>>>>    WHENCE                      |   6 +-----
>>>>    qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>>>
>>> And this firmware file is also going to work on SC7180, correct?
>>
>> Yes, we have got this validated on SC7180 as well.
> 
> Thanks for the confirmation.
> 
>>
>>>
>>>>    qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>>>
>>> Vikash, Dikshita, could you please comment, what is going on here?
>>>
>>> We have added venus_s6.mbn, then dropped it, saying that a normal
>>> venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
>>> (why?). Mario merged it despite my NAK, but that's a separate topic.
>>> Now we are dropping it again.
>>>
>>> The firmware is the ABI between userspace and the kernel. We can't
>>> randomly add and remove files here.
>>>
>>> Which file names are / were in use by the upstream kernel? I tried hard,
>>> but I couldn't find any mention of venus_s2.mbn in any of the patches
>>> on the linux-arm-msm mailing list.
>>
>> venus_s2.mbn is not used anywhere. It was earlier planned to be used on
> 
> Ack, please split into two commits, each having a proper explanation.
> Please make sure that in future we don't add completely unused files.
> 

Ack

>> qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
>> same bins for sc7180 and qcs615.
> 
> What is the status of the current venus-5.4/venus.mbn file? Does it work
> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
> ADP AIR aka RIDE boards?

@Renjiang ?

> 
>> S2 variant can be produced now by re-signing this venus.mbn itself. To
>> achieve this part, there were some elf alignment fixes, which is done with
>> this bin to make it re-signable with any vendor specific #.
> 
> I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
> is the difference between it and the new one?
> 

VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].

0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.

[1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual 
Address, 0x00000000, are not congruent modulo the Alignment, 0x00001000. 
(Offset % Alignment) must equal (Virtual Address % Alignment).

Regards,
Vikash

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Wed, Nov 19, 2025 at 09:49:17PM +0530, Vikash Garodia wrote:
> 
> On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
> > On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
> > > Hello Dmitry,
> > > 
> > > On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
> > > qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
> > > same bins for sc7180 and qcs615.
> > 
> > What is the status of the current venus-5.4/venus.mbn file? Does it work
> > AS IS on Talos EVK that is being in process of upstreaming and on QCS615
> > ADP AIR aka RIDE boards?
> 
> @Renjiang ?
> 
> > 
> > > S2 variant can be produced now by re-signing this venus.mbn itself. To
> > > achieve this part, there were some elf alignment fixes, which is done with
> > > this bin to make it re-signable with any vendor specific #.
> > 
> > I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
> > is the difference between it and the new one?
> > 
> 
> VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].

Commit 891a8d4fdfef ("qcom: venus-5.4: update firmware binary for sc7180
and qcs615") left me in assumption that at that point the
qcom/venus-5.4/venus.mbn has been working on QCS615. Is my assumption
incorrect?

> 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
> 
> [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual Address,
> 0x00000000, are not congruent modulo the Alignment, 0x00001000. (Offset %
> Alignment) must equal (Virtual Address % Alignment).

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Vikash Garodia]

On 11/19/2025 10:10 PM, Dmitry Baryshkov wrote:
> On Wed, Nov 19, 2025 at 09:49:17PM +0530, Vikash Garodia wrote:
>>
>> On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
>>> On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
>>>> Hello Dmitry,
>>>>
>>>> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>>>> qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
>>>> same bins for sc7180 and qcs615.
>>>
>>> What is the status of the current venus-5.4/venus.mbn file? Does it work
>>> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
>>> ADP AIR aka RIDE boards?
>>
>> @Renjiang ?
>>
>>>
>>>> S2 variant can be produced now by re-signing this venus.mbn itself. To
>>>> achieve this part, there were some elf alignment fixes, which is done with
>>>> this bin to make it re-signable with any vendor specific #.
>>>
>>> I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
>>> is the difference between it and the new one?
>>>
>>
>> VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
> 
> Commit 891a8d4fdfef ("qcom: venus-5.4: update firmware binary for sc7180
> and qcs615") left me in assumption that at that point the
> qcom/venus-5.4/venus.mbn has been working on QCS615. Is my assumption
> incorrect?

Both #60 and #62 works on QCS615, while if any OEM tries to resign #60 
with a different signature, they would not be able to do that with #60, 
while they can do that now with #62 with the ELF alignment fixed.
> 
>> 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
>>
>> [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual Address,
>> 0x00000000, are not congruent modulo the Alignment, 0x00001000. (Offset %
>> Alignment) must equal (Virtual Address % Alignment).
> 

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Wed, Nov 19, 2025 at 10:43:14PM +0530, Vikash Garodia wrote:
> 
> On 11/19/2025 10:10 PM, Dmitry Baryshkov wrote:
> > On Wed, Nov 19, 2025 at 09:49:17PM +0530, Vikash Garodia wrote:
> > > 
> > > On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
> > > > > Hello Dmitry,
> > > > > 
> > > > > On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
> > > > > qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
> > > > > same bins for sc7180 and qcs615.
> > > > 
> > > > What is the status of the current venus-5.4/venus.mbn file? Does it work
> > > > AS IS on Talos EVK that is being in process of upstreaming and on QCS615
> > > > ADP AIR aka RIDE boards?
> > > 
> > > @Renjiang ?
> > > 
> > > > 
> > > > > S2 variant can be produced now by re-signing this venus.mbn itself. To
> > > > > achieve this part, there were some elf alignment fixes, which is done with
> > > > > this bin to make it re-signable with any vendor specific #.
> > > > 
> > > > I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
> > > > is the difference between it and the new one?
> > > > 
> > > 
> > > VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
> > 
> > Commit 891a8d4fdfef ("qcom: venus-5.4: update firmware binary for sc7180
> > and qcs615") left me in assumption that at that point the
> > qcom/venus-5.4/venus.mbn has been working on QCS615. Is my assumption
> > incorrect?
> 
> Both #60 and #62 works on QCS615, while if any OEM tries to resign #60 with
> a different signature, they would not be able to do that with #60, while
> they can do that now with #62 with the ELF alignment fixed.

The commit that I mentioned had 0059, not 0060. Also, if the ODMs can't
resign the binary, how could you sign it?

Is the following correct:
- 0058 works only on SC7180 (does it work with the SM6150/Android?)
- 0058's venus_s6.mbn was signed with MBN v6 to work on QCS615
- 0059 was updated to work on both SC7180 and QCS615
- 0060 was uploaded as 'yet another binary to get it working on QCS615'
- 0062 now it's another binary, which works on QCS615 and can be
  resigned by ODMs

Is that correct? If not, then your colleagues need to start writing
better commit messages and being less shy about explaining things:
I basically wrote the summary of the commits chaning qcom/venus-5.4.

And if it is correct, what was wrong with 0059?

> > > 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
> > > 
> > > [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual Address,
> > > 0x00000000, are not congruent modulo the Alignment, 0x00001000. (Offset %
> > > Alignment) must equal (Virtual Address % Alignment).

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Vikash Garodia]

On 11/20/2025 6:33 AM, Dmitry Baryshkov wrote:
> On Wed, Nov 19, 2025 at 10:43:14PM +0530, Vikash Garodia wrote:
>>
>> On 11/19/2025 10:10 PM, Dmitry Baryshkov wrote:
>>> On Wed, Nov 19, 2025 at 09:49:17PM +0530, Vikash Garodia wrote:
>>>>
>>>> On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
>>>>>> Hello Dmitry,
>>>>>>
>>>>>> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
>>>>>>> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>>>>>> qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
>>>>>> same bins for sc7180 and qcs615.
>>>>>
>>>>> What is the status of the current venus-5.4/venus.mbn file? Does it work
>>>>> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
>>>>> ADP AIR aka RIDE boards?
>>>>
>>>> @Renjiang ?
>>>>
>>>>>
>>>>>> S2 variant can be produced now by re-signing this venus.mbn itself. To
>>>>>> achieve this part, there were some elf alignment fixes, which is done with
>>>>>> this bin to make it re-signable with any vendor specific #.
>>>>>
>>>>> I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
>>>>> is the difference between it and the new one?
>>>>>
>>>>
>>>> VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
>>>
>>> Commit 891a8d4fdfef ("qcom: venus-5.4: update firmware binary for sc7180
>>> and qcs615") left me in assumption that at that point the
>>> qcom/venus-5.4/venus.mbn has been working on QCS615. Is my assumption
>>> incorrect?
>>
>> Both #60 and #62 works on QCS615, while if any OEM tries to resign #60 with
>> a different signature, they would not be able to do that with #60, while
>> they can do that now with #62 with the ELF alignment fixed.
> 
> The commit that I mentioned had 0059, not 0060. Also, if the ODMs can't
> resign the binary, how could you sign it?

ODMs can re-sign it, if they are also using sec tools v1 based signing. 
If they need to use sec tool v2, and tries to use this binary to sign 
it, they would face the ELF alignment issue.
So, it would be like
- For  sec tool v1 - existing binary would work, no ODM have any impact 
with fused firmware.
- For sec tool v2 - *same binary* can be resigned with v2 security 
profile and can be used.

> 
> Is the following correct:
> - 0058 works only on SC7180 (does it work with the SM6150/Android?)\

No, for SM6150/Android. There is separate bin for SC7180 and SM6150, and 
hence venus_s6 was raised earlier, but later converged to use same bin 
for both SOCs.

> - 0058's venus_s6.mbn was signed with MBN v6 to work on QCS615

> - 0059 was updated to work on both SC7180 and QCS615

Precisely, at this point, both the SOCs were made to work on same SOC.

> - 0060 was uploaded as 'yet another binary to get it working on QCS615'

This was raised to make it work with sec tool v2 _only_ for QCS615, but 
later we could find a better way to use the sec tool v1 binary alone and 
if any ODM wants to resign it with sec tool v2, they can do it at their own.

> - 0062 now it's another binary, which works on QCS615 and can be
>    resigned by ODMs
> 
> Is that correct? 

Thank you for putting it up nicely, and i completely agree to have this 
in commit to keep up for future reference.

> If not, then your colleagues need to start writing
> better commit messages and being less shy about explaining things:
> I basically wrote the summary of the commits chaning qcom/venus-5.4.
> 
> And if it is correct, what was wrong with 0059?

 From 59 to 62, ELF standard alignment issue is fixed. ODM cannot use 59 
to sign with their own signature if they need with sec tool v2. There is 
nothing needed at ODM end if they are using sec tool v1 and having 
boards fused with either 59 or 62.

> 
>>>> 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
>>>>
>>>> [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual Address,
>>>> 0x00000000, are not congruent modulo the Alignment, 0x00001000. (Offset %
>>>> Alignment) must equal (Virtual Address % Alignment).
> 

Re: update firmware binary for v5.4

[Renjiang Han]

On 11/20/2025 12:19 AM, Vikash Garodia wrote:
>
> On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
>> On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
>>> Hello Dmitry,
>>>
>>> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
>>>> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>>>>> Hi
>>>>>
>>>>> The following changes since commit 
>>>>> 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>>>>
>>>>>     Merge branch 'robot/patch-0-1762826844' into 'main' 
>>>>> (2025-11-11 12:02:02
>>>>> +0000)
>>>>>
>>>>> are available in the Git repository at:
>>>>>
>>>>> https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
>>>>> update-video-fw-sm6150
>>>>>
>>>>> for you to fetch changes up to 
>>>>> 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
>>>>>
>>>>>     qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 
>>>>> 15:04:09
>>>>> +0530)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Renjiang Han (1):
>>>>>         qcom: venus-5.4: update firmware binary for v5.4
>>>>>
>>>>>    WHENCE                      |   6 +-----
>>>>>    qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>>>>
>>>> And this firmware file is also going to work on SC7180, correct?
>>>
>>> Yes, we have got this validated on SC7180 as well.
>>
>> Thanks for the confirmation.
>>
>>>
>>>>
>>>>>    qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>>>>
>>>> Vikash, Dikshita, could you please comment, what is going on here?
>>>>
>>>> We have added venus_s6.mbn, then dropped it, saying that a normal
>>>> venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
>>>> (why?). Mario merged it despite my NAK, but that's a separate topic.
>>>> Now we are dropping it again.
>>>>
>>>> The firmware is the ABI between userspace and the kernel. We can't
>>>> randomly add and remove files here.
>>>>
>>>> Which file names are / were in use by the upstream kernel? I tried 
>>>> hard,
>>>> but I couldn't find any mention of venus_s2.mbn in any of the patches
>>>> on the linux-arm-msm mailing list.
>>>
>>> venus_s2.mbn is not used anywhere. It was earlier planned to be used on
>>
>> Ack, please split into two commits, each having a proper explanation.
>> Please make sure that in future we don't add completely unused files.
>>
>
> Ack
Sure, I'll re-submit fw change with two commits.
>
>>> qcs615 while venus.mbn would continue on sc7280, but then we wanted 
>>> to use
>>> same bins for sc7180 and qcs615.
>>
>> What is the status of the current venus-5.4/venus.mbn file? Does it work
>> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
>> ADP AIR aka RIDE boards?
>
> @Renjiang ?
It is fine on ADP AIR platform. I am asking wangao to borrow EVK 
platform to verify it.
>
>>
>>> S2 variant can be produced now by re-signing this venus.mbn itself. To
>>> achieve this part, there were some elf alignment fixes, which is 
>>> done with
>>> this bin to make it re-signable with any vendor specific #.
>>
>> I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
>> is the difference between it and the new one?
>>
>
> VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
>
> 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
>
> [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual 
> Address, 0x00000000, are not congruent modulo the Alignment, 
> 0x00001000. (Offset % Alignment) must equal (Virtual Address % 
> Alignment).
>
> Regards,
> Vikash

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Thu, Nov 20, 2025 at 03:45:03PM +0530, Vikash Garodia wrote:
> 
> On 11/20/2025 6:33 AM, Dmitry Baryshkov wrote:
> > On Wed, Nov 19, 2025 at 10:43:14PM +0530, Vikash Garodia wrote:
> > > 
> > > On 11/19/2025 10:10 PM, Dmitry Baryshkov wrote:
> > > > On Wed, Nov 19, 2025 at 09:49:17PM +0530, Vikash Garodia wrote:
> > > > > 
> > > > > On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
> > > > > > > Hello Dmitry,
> > > > > > > 
> > > > > > > On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
> > > > > > > > On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
> > > > > > > qcs615 while venus.mbn would continue on sc7280, but then we wanted to use
> > > > > > > same bins for sc7180 and qcs615.
> > > > > > 
> > > > > > What is the status of the current venus-5.4/venus.mbn file? Does it work
> > > > > > AS IS on Talos EVK that is being in process of upstreaming and on QCS615
> > > > > > ADP AIR aka RIDE boards?
> > > > > 
> > > > > @Renjiang ?
> > > > > 
> > > > > > 
> > > > > > > S2 variant can be produced now by re-signing this venus.mbn itself. To
> > > > > > > achieve this part, there were some elf alignment fixes, which is done with
> > > > > > > this bin to make it re-signable with any vendor specific #.
> > > > > > 
> > > > > > I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
> > > > > > is the difference between it and the new one?
> > > > > > 
> > > > > 
> > > > > VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
> > > > 
> > > > Commit 891a8d4fdfef ("qcom: venus-5.4: update firmware binary for sc7180
> > > > and qcs615") left me in assumption that at that point the
> > > > qcom/venus-5.4/venus.mbn has been working on QCS615. Is my assumption
> > > > incorrect?
> > > 
> > > Both #60 and #62 works on QCS615, while if any OEM tries to resign #60 with
> > > a different signature, they would not be able to do that with #60, while
> > > they can do that now with #62 with the ELF alignment fixed.
> > 
> > The commit that I mentioned had 0059, not 0060. Also, if the ODMs can't
> > resign the binary, how could you sign it?
> 
> ODMs can re-sign it, if they are also using sec tools v1 based signing. If
> they need to use sec tool v2, and tries to use this binary to sign it, they
> would face the ELF alignment issue.
> So, it would be like
> - For  sec tool v1 - existing binary would work, no ODM have any impact with
> fused firmware.
> - For sec tool v2 - *same binary* can be resigned with v2 security profile
> and can be used.
> 
> > 
> > Is the following correct:
> > - 0058 works only on SC7180 (does it work with the SM6150/Android?)\
> 
> No, for SM6150/Android. There is separate bin for SC7180 and SM6150, and
> hence venus_s6 was raised earlier, but later converged to use same bin for
> both SOCs.
> 
> > - 0058's venus_s6.mbn was signed with MBN v6 to work on QCS615
> 
> > - 0059 was updated to work on both SC7180 and QCS615
> 
> Precisely, at this point, both the SOCs were made to work on same SOC.
> 
> > - 0060 was uploaded as 'yet another binary to get it working on QCS615'
> 
> This was raised to make it work with sec tool v2 _only_ for QCS615, but
> later we could find a better way to use the sec tool v1 binary alone and if
> any ODM wants to resign it with sec tool v2, they can do it at their own.
> 
> > - 0062 now it's another binary, which works on QCS615 and can be
> >    resigned by ODMs
> > 
> > Is that correct?
> 
> Thank you for putting it up nicely, and i completely agree to have this in
> commit to keep up for future reference.

Hmm, maybe I'm now misunderstanding your comment. I'm not asking to
capture this history in the commit message. I'm asking to write better
commit messages in furure, making it more obvious, what is _actually_
going on. E.g. 0060 is a definite mistake.

> 
> > If not, then your colleagues need to start writing
> > better commit messages and being less shy about explaining things:
> > I basically wrote the summary of the commits chaning qcom/venus-5.4.
> > 
> > And if it is correct, what was wrong with 0059?
> 
> From 59 to 62, ELF standard alignment issue is fixed. ODM cannot use 59 to
> sign with their own signature if they need with sec tool v2. There is
> nothing needed at ODM end if they are using sec tool v1 and having boards
> fused with either 59 or 62.
> 
> > 
> > > > > 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
> > > > > 
> > > > > [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual Address,
> > > > > 0x00000000, are not congruent modulo the Alignment, 0x00001000. (Offset %
> > > > > Alignment) must equal (Virtual Address % Alignment).

Which ProgramHeader is it? I don't see any alignment issues with the
0059 firmware.

$ strings /lib/firmware/qcom/venus-5.4/venus.mbn | grep QC_IMAGE_VERSION
QC_IMAGE_VERSION_STRING=VIDEO.VE.5.4-00059-PROD-1

$ readelf -l /lib/firmware/qcom/venus-5.4/venus.mbn

Elf file type is EXEC (Executable file)
Entry point 0xf500000
There are 5 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  NULL           0x000000 0x00000000 0x00000000 0x000d4 0x00000     0
  NULL           0x001000 0x0fa00000 0x0fa00000 0x01a98 0x02000     0x1000
  LOAD           0x003000 0x00000000 0x0f500000 0xd5de0 0xd5de0 R E 0x100000
  LOAD           0x0d8de0 0x00100000 0x0f600000 0x08468 0x3f4000 RW  0x100000
  LOAD           0x0e1248 0x004ff000 0x0f9ff000 0x00020 0x00020 RW  0x4

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Wangao Wang]

On 2025/11/20 18:28, Renjiang Han wrote:
>>> What is the status of the current venus-5.4/venus.mbn file? Does it work
>>> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
>>> ADP AIR aka RIDE boards?
>>
>> @Renjiang ?
> It is fine on ADP AIR platform. I am asking wangao to borrow EVK 
> platform to verify it.
>>
Hi Renjiang, Vikash,
It is fine on EVK board.

-- 
Best Regards,
Wangao

Re: update firmware binary for v5.4

[Renjiang Han]

On 11/20/2025 12:19 AM, Vikash Garodia wrote:
>
> On 11/19/2025 8:22 PM, Dmitry Baryshkov wrote:
>> On Wed, Nov 19, 2025 at 07:57:30PM +0530, Vikash Garodia wrote:
>>> Hello Dmitry,
>>>
>>> On 11/19/2025 4:55 PM, Dmitry Baryshkov wrote:
>>>> On Wed, Nov 19, 2025 at 05:39:43PM +0800, Renjiang Han wrote:
>>>>> Hi
>>>>>
>>>>> The following changes since commit 
>>>>> 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>>>>
>>>>>     Merge branch 'robot/patch-0-1762826844' into 'main' 
>>>>> (2025-11-11 12:02:02
>>>>> +0000)
>>>>>
>>>>> are available in the Git repository at:
>>>>>
>>>>> https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
>>>>> update-video-fw-sm6150
>>>>>
>>>>> for you to fetch changes up to 
>>>>> 0a6f987b7b07a6fec2d4fd42ac4473c0523d3af6:
>>>>>
>>>>>     qcom: venus-5.4: update firmware binary for v5.4 (2025-11-19 
>>>>> 15:04:09
>>>>> +0530)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Renjiang Han (1):
>>>>>         qcom: venus-5.4: update firmware binary for v5.4
>>>>>
>>>>>    WHENCE                      |   6 +-----
>>>>>    qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>>>>
>>>> And this firmware file is also going to work on SC7180, correct?
>>>
>>> Yes, we have got this validated on SC7180 as well.
>>
>> Thanks for the confirmation.
>>
>>>
>>>>
>>>>>    qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>>>>
>>>> Vikash, Dikshita, could you please comment, what is going on here?
>>>>
>>>> We have added venus_s6.mbn, then dropped it, saying that a normal
>>>> venus.mbn can be used on QCS615. Then Renjiang added venus_s2.mbn
>>>> (why?). Mario merged it despite my NAK, but that's a separate topic.
>>>> Now we are dropping it again.
>>>>
>>>> The firmware is the ABI between userspace and the kernel. We can't
>>>> randomly add and remove files here.
>>>>
>>>> Which file names are / were in use by the upstream kernel? I tried 
>>>> hard,
>>>> but I couldn't find any mention of venus_s2.mbn in any of the patches
>>>> on the linux-arm-msm mailing list.
>>>
>>> venus_s2.mbn is not used anywhere. It was earlier planned to be used on
>>
>> Ack, please split into two commits, each having a proper explanation.
>> Please make sure that in future we don't add completely unused files.
>>
>
> Ack

Hi Dmitry & Vikash

I have re-submitted two changes, please help check. Thanks!

The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:

   Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 
12:02:02 +0000)

are available in the Git repository at:

   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git 
update-video-fw-v5.4

for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:

   qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41 
+0530)

----------------------------------------------------------------
Renjiang Han (2):
       qcom: venus-5.4: remove unused firmware file
       qcom: venus-5.4: update firmware binary for v5.4

  WHENCE                      |   6 +-----
  qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
  qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
  3 files changed, 1 insertion(+), 5 deletions(-)
  delete mode 100644 qcom/venus-5.4/venus_s2.mbn

>
>>> qcs615 while venus.mbn would continue on sc7280, but then we wanted 
>>> to use
>>> same bins for sc7180 and qcs615.
>>
>> What is the status of the current venus-5.4/venus.mbn file? Does it work
>> AS IS on Talos EVK that is being in process of upstreaming and on QCS615
>> ADP AIR aka RIDE boards?
>
> @Renjiang ?
>
>>
>>> S2 variant can be produced now by re-signing this venus.mbn itself. To
>>> achieve this part, there were some elf alignment fixes, which is 
>>> done with
>>> this bin to make it re-signable with any vendor specific #.
>>
>> I thought that this already happened for VIDEO.VE.5.4-00060-PROD-1. What
>> is the difference between it and the new one?
>>
>
> VIDEO.VE.5.4-00060-PROD-1 had ELF 4k alignment issue [1].
>
> 0x34 % 0x1000 is not equal to 0x0 % 0x1000. This part is fixed in #62.
>
> [1]RuntimeError: Program Header's Offset, 0x00000034, and Virtual 
> Address, 0x00000000, are not congruent modulo the Alignment, 
> 0x00001000. (Offset % Alignment) must equal (Virtual Address % 
> Alignment).
>
> Regards,
> Vikash

Best Regards,

Renjiang

update firmware binary for v5.4

[Renjiang Han]

Hi

The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:

   Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 
12:02:02 +0000)

are available in the Git repository at:

   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git 
update-video-fw-v5.4

for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:

   qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41 
+0530)

----------------------------------------------------------------
Renjiang Han (2):
       qcom: venus-5.4: remove unused firmware file
       qcom: venus-5.4: update firmware binary for v5.4

  WHENCE                      |   6 +-----
  qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
  qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
  3 files changed, 1 insertion(+), 5 deletions(-)
  delete mode 100644 qcom/venus-5.4/venus_s2.mbn

-- 
Best regards,
Renjiang Han

Re: update firmware binary for v5.4

[Renjiang Han]

On 11/21/2025 6:24 AM, Dmitry Baryshkov wrote:
> Which ProgramHeader is it? I don't see any alignment issues with the
> 0059 firmware.
>
> $ strings /lib/firmware/qcom/venus-5.4/venus.mbn | grep QC_IMAGE_VERSION
> QC_IMAGE_VERSION_STRING=VIDEO.VE.5.4-00059-PROD-1
>
> $ readelf -l /lib/firmware/qcom/venus-5.4/venus.mbn
>
> Elf file type is EXEC (Executable file)
> Entry point 0xf500000
> There are 5 program headers, starting at offset 52
>
> Program Headers:
>    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>    NULL           0x000000 0x00000000 0x00000000 0x000d4 0x00000     0
>    NULL           0x001000 0x0fa00000 0x0fa00000 0x01a98 0x02000     0x1000
>    LOAD           0x003000 0x00000000 0x0f500000 0xd5de0 0xd5de0 R E 0x100000
>    LOAD           0x0d8de0 0x00100000 0x0f600000 0x08468 0x3f4000 RW  0x100000
>    LOAD           0x0e1248 0x004ff000 0x0f9ff000 0x00020 0x00020 RW  0x4
>
> -- With best wishes Dmitry
ELF spec: (Offset % Alignment) must equal (Virtual Address % Alignment).

0x3000 % 0x100000 != 0x00000000 % 0x10000
0x0d8de0 % 0x100000 != 0x00100000 % 0x100000
Therefore, the Program Header alignment in this file does not conform to
  the ELF specification.

-- 
Best regards,
Renjiang Han

Re: update firmware binary for v5.4

[Vikash Garodia]

On 11/21/2025 9:27 AM, Renjiang Han wrote:
> 
> Hi Dmitry & Vikash
> 
> I have re-submitted two changes, please help check. Thanks!
> 
> The following changes since commit 
> 6fc940781a013ad837ed8fea326d2b897467bbc3:
> 
>    Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 
> 12:02:02 +0000)
> 
> are available in the Git repository at:
> 
> https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git update- 
> video-fw-v5.4
> 
> for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:
> 
>    qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41 
> +0530)
> 
> ----------------------------------------------------------------
> Renjiang Han (2):
>        qcom: venus-5.4: remove unused firmware file
>        qcom: venus-5.4: update firmware binary for v5.4
> 
>   WHENCE                      |   6 +-----
>   qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>   qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>   3 files changed, 1 insertion(+), 5 deletions(-)
>   delete mode 100644 qcom/venus-5.4/venus_s2.mbn

It was made quite clear to put up the history from versions #58 all the 
way to #62 in the commit message, still i see commit message does not 
capture it.

Regards,
Vikash

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Fri, Nov 21, 2025 at 03:17:24PM +0530, Vikash Garodia wrote:
> 
> On 11/21/2025 9:27 AM, Renjiang Han wrote:
> > 
> > Hi Dmitry & Vikash
> > 
> > I have re-submitted two changes, please help check. Thanks!
> > 
> > The following changes since commit
> > 6fc940781a013ad837ed8fea326d2b897467bbc3:
> > 
> >    Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11
> > 12:02:02 +0000)
> > 
> > are available in the Git repository at:
> > 
> > https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git update-
> > video-fw-v5.4
> > 
> > for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:
> > 
> >    qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41
> > +0530)
> > 
> > ----------------------------------------------------------------
> > Renjiang Han (2):
> >        qcom: venus-5.4: remove unused firmware file
> >        qcom: venus-5.4: update firmware binary for v5.4
> > 
> >   WHENCE                      |   6 +-----
> >   qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
> >   qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
> >   3 files changed, 1 insertion(+), 5 deletions(-)
> >   delete mode 100644 qcom/venus-5.4/venus_s2.mbn
> 
> It was made quite clear to put up the history from versions #58 all the way
> to #62 in the commit message, still i see commit message does not capture
> it.

No, it's not required to capture old history. But it would be nice to
point out the reasons for the change (conformance to ELF ABI). BTW: what
is the actual alignment requirement for those segments? E.g. on ARM
systems code segment must be alisnged at least to 0x4. Likewise data
segments also should have some alignemnt (again, 0x4 at least, usually
0x8 or ox10), otherwise loading data from those segments becomes very
unefficient.

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Dmitry Baryshkov]

On Fri, Nov 21, 2025 at 12:11:02PM +0800, Renjiang Han wrote:
> Hi
> 
> The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
> 
>   Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
> +0000)
> 
> are available in the Git repository at:
> 
>   https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
> update-video-fw-v5.4
> 
> for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:
> 
>   qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41
> +0530)
> 
> ----------------------------------------------------------------
> Renjiang Han (2):
>       qcom: venus-5.4: remove unused firmware file
>       qcom: venus-5.4: update firmware binary for v5.4

I've set to be merged, https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/793

In future, please, write better explanations in commit messages. Target
people who will read it in attempt to understand if it should be picked
up for something like Debian stable rather than your close colleagues
who perfectly know what the issue is.

Also please coordinate your uploads with Vikash and Dikshita. The _s2
suffix was totally not in line with other suffixes used beforehand or
after.

> 
>  WHENCE                      |   6 +-----
>  qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>  qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>  3 files changed, 1 insertion(+), 5 deletions(-)
>  delete mode 100644 qcom/venus-5.4/venus_s2.mbn
> 
> -- 
> Best regards,
> Renjiang Han
> 

-- 
With best wishes
Dmitry

Re: update firmware binary for v5.4

[Renjiang Han]

On 11/23/2025 10:11 PM, Dmitry Baryshkov wrote:
> On Fri, Nov 21, 2025 at 12:11:02PM +0800, Renjiang Han wrote:
>> Hi
>>
>> The following changes since commit 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>
>>    Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11 12:02:02
>> +0000)
>>
>> are available in the Git repository at:
>>
>>    https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git
>> update-video-fw-v5.4
>>
>> for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:
>>
>>    qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41
>> +0530)
>>
>> ----------------------------------------------------------------
>> Renjiang Han (2):
>>        qcom: venus-5.4: remove unused firmware file
>>        qcom: venus-5.4: update firmware binary for v5.4
> I've set to be merged, https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/793
>
> In future, please, write better explanations in commit messages. Target
> people who will read it in attempt to understand if it should be picked
> up for something like Debian stable rather than your close colleagues
> who perfectly know what the issue is.
>
> Also please coordinate your uploads with Vikash and Dikshita. The _s2
> suffix was totally not in line with other suffixes used beforehand or
> after.
Got it. Thanks!
>>   WHENCE                      |   6 +-----
>>   qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>>   qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>>   3 files changed, 1 insertion(+), 5 deletions(-)
>>   delete mode 100644 qcom/venus-5.4/venus_s2.mbn
>>
>> -- 
>> Best regards,
>> Renjiang Han
>>
-- 
Best regards,
Renjiang Han

Re: update firmware binary for v5.4

[Renjiang Han]

On 11/21/2025 7:55 PM, Dmitry Baryshkov wrote:
> On Fri, Nov 21, 2025 at 03:17:24PM +0530, Vikash Garodia wrote:
>> On 11/21/2025 9:27 AM, Renjiang Han wrote:
>>> Hi Dmitry & Vikash
>>>
>>> I have re-submitted two changes, please help check. Thanks!
>>>
>>> The following changes since commit
>>> 6fc940781a013ad837ed8fea326d2b897467bbc3:
>>>
>>>     Merge branch 'robot/patch-0-1762826844' into 'main' (2025-11-11
>>> 12:02:02 +0000)
>>>
>>> are available in the Git repository at:
>>>
>>> https://git.codelinaro.org/clo/linux-kernel/linux-firmware.git update-
>>> video-fw-v5.4
>>>
>>> for you to fetch changes up to bb28dcbcf9867ebeda6a41d575656a737c24f32f:
>>>
>>>     qcom: venus-5.4: update firmware binary for v5.4 (2025-11-21 08:55:41
>>> +0530)
>>>
>>> ----------------------------------------------------------------
>>> Renjiang Han (2):
>>>         qcom: venus-5.4: remove unused firmware file
>>>         qcom: venus-5.4: update firmware binary for v5.4
>>>
>>>    WHENCE                      |   6 +-----
>>>    qcom/venus-5.4/venus.mbn    | Bin 922216 -> 922312 bytes
>>>    qcom/venus-5.4/venus_s2.mbn | Bin 919008 -> 0 bytes
>>>    3 files changed, 1 insertion(+), 5 deletions(-)
>>>    delete mode 100644 qcom/venus-5.4/venus_s2.mbn
>> It was made quite clear to put up the history from versions #58 all the way
>> to #62 in the commit message, still i see commit message does not capture
>> it.
> No, it's not required to capture old history. But it would be nice to
> point out the reasons for the change (conformance to ELF ABI). BTW: what
> is the actual alignment requirement for those segments? E.g. on ARM
> systems code segment must be alisnged at least to 0x4. Likewise data
> segments also should have some alignemnt (again, 0x4 at least, usually
> 0x8 or ox10), otherwise loading data from those segments becomes very
> unefficient.
Correct,the data segment needs to have proper alignment. However,
the alignment value must comply with the ELF specification, which
requires that (Offset % Alignment) equals (Virtual Address % Alignment).
After we discussion and verification, we decided to use 0x4 alignment.
So I will update new binary with 0x4 alignment.
Thank you very much for your comment.

-- 
Best regards,
Renjiang Han