Re: update firmware binary for v5.4

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