Re: update firmware binary for v5.4

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

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