Re: update firmware binary for v5.4

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