nxpimage cannot retrieve entrypoint from ELF or SREC

[mastupristi]

Hi,

I am experiencing some problems with nxpimage. It seems that it cannot retrieve the entry point from the elf or srec files.

Note that both files (are attached) contains entry point:

my configuration file is this:

# ===========================================  HAB converted configuration  ============================================

# ======================================================================================================================
#                                                 == General Options ==                                                 
# ======================================================================================================================
# ------------------------------------------===== HAB Options [Required] =====------------------------------------------
# Description: An options block contains zero or more name/value pairs and the option settings that assign values to
# global options used by the nxpimage to control the generation of the output file.
options:
  # -----------------------------------===== HAB flags [Conditionally required] =====-----------------------------------
  # Description: HAB flags. 0x0 for unsigned, 0x08 signed, 0x0C encrypted.
  flags: 0
  # ------------------------------===== Image start address [Conditionally required] =====------------------------------
  # Description: First address of the bootable image in the target memory.
  startAddress: 0x30000000
  # ----------------------------------===== IVT Offset [Conditionally required] =====-----------------------------------
  # Description: Offset of IVT table(beginning of HAB container) from startAddress. This option can be omitted if family
  # and bootDevice are specified.
  ivtOffset: 4096
  # -------------------------------===== Initial Load size [Conditionally required] =====-------------------------------
  # Description: Size of the segments(such as IVT, BDT, DCD, XMCD) placed before the actual application image. The value
  # is specific per boot device type. This option can be omitted if family and bootDevice are specified.
  initialLoadSize: 8192
  # -------------------------------------===== Entry Point address [Optional] =====-------------------------------------
  # Description: Reset vector of the application. If not specified, the vector will be automatically detected from the
  # input image.
  entryPointAddress: 0x30002101
# ======================================================================================================================
#                                                    == HAB Input ==                                                    
# ======================================================================================================================
# ------------------------------------===== Plain application image [Required] =====------------------------------------
# Description: The input application image in plain BIN, S-REC or ELF.
inputImageFile: ./Rt117xDemo-v0.0.1-alpha.0+d9a7f7f.srec
# ======================================================================================================================
#                                                   == CSF Sections ==                                                  
# ======================================================================================================================
# -----------------------------------------===== CSF Sections [Optional] =====------------------------------------------
# Description: CSF Sections.
sections: []

the command I run is:

nxpimage hab export -c ./test.yaml -o ./out.bin

the out.bin file correctly contains the entrypoint in the IVT:

But I read this in one comment:

so I can omit the entry point of the .yaml file (i comment it), because nxpimage will be able to retrieve it from elf or srec, right?

By doing this, though, the binary file does not contain the entry point in the IVT:

Where am I going wrong?
I have attached all the files so that you can try.

regards

Max

[nxf93270]

Hi @mastupristi ,

Our team has discussed this issue and decided to update our schedule to include a fix for the 2.4 release, which is planned for the end of November.

I can prepare a fix in by the end of this week and send you a pre-release version for testing, if that's okay with you.

[mastupristi]

Hi @nxf93270 

Our team has discussed this issue and decided to update our schedule to include a fix for the 2.4 release, which is planned for the end of November.

I am happy about this

I can prepare a fix in by the end of this week and send you a pre-release version for testing, if that's okay with you.

This is great. It's absolutely okay for me

best regards

Max

[mastupristi]

Hi @nxf93270 

I can prepare a fix in by the end of this week and send you a pre-release version for testing, if that's okay with you.

This is great. It's absolutely okay for me

More than two weeks have passed, but you haven't contacted me back.

Do you have the pre-release to send me? Can you send it to me?

regards

Max

[nxf93270]

Hi @mastupristi,

SPSDK containing the fix for you is already released.

Secure Provisioning SDK 2.4:

• GitHub: https://github.com/NXPmicro/spsdk
• PyPi: https://pypi.org/project/spsdk/
• Documentation: https://spsdk.readthedocs.io/en/latest/
• Release Notes: https://spsdk.readthedocs.io/en/latest/release_notes.html

Feel free to test your workflow and contact me in case of any other questions.

[nxf93270]

Ho @mastupristi ,

Due to the infrastructure problems on our site, the fix got merged only yesterday.

I discussed the possibility of distributing the patched version to you with the legal team. It seems that the only legal way is to do it via official "release".

We have scheduled the SPSDK 2.4 release on the 15th of November.  There is a possibility that we may also release SPSDK 2.3.1 even sooner.  This is still under discussion, so I will keep you updated.

Unfortunately distributing "unverified" source code via community is prohibited.
Sorry for this inconvenience. I hope next week will be okay with you.

[nxf93270]

Hi @mastupristi ,

Thank you for reporting this issue.
When entryPointAddress is not specified, it's value is automatically taken from the raw binary as the reset vector(offset 0x4).

We use bincopy package for conversion of srec, s19 or elf to raw binary. In case of the images you attached, the reset vector of exported image is 0x0, which is definitely wrong value.

We are planning to extend the autodetection so the entryPointAddress can be taken from elf/srec metadata. It may be done in 2.5 release(planned on 12/2025).  Once this is done, you would be able to omit the entryPointAddress in your configuration. Until then it must be specified explicitly.

[mastupristi]

Hi @nxf93270 

Well, this is quite surprising.

Despite the fact that the entry point is clearly present in both .elf and .srec files, nxpimage seems incapable of retrieving it. What makes this even more puzzling is that, in a previous thread, NXP had explicitly mentioned that it should work with .srec files. Moreover, the older tools worked flawlessly in this regard, so it’s hard to understand why SPSDK has taken a step backwards.

What’s even more baffling is that retrieving the entry point from .srec or .elf is just a matter of a few lines of Python code (the same language used to develop the entire SPSDK). Yet, somehow, we have to wait over a year for this feature to be implemented—scheduled for release 2.5 in December 2025. I must say, it's quite reassuring to know that a feature that used to work perfectly in older tools will eventually return—just in time for Christmas 2025!

In all seriousness, it’s frustrating to encounter this kind of regression. I would appreciate any clarification on why this basic functionality was dropped and whether there’s any temporary workaround in the meantime. Having reliable tools is essential to keep development on track, so any feedback would be greatly appreciated.

Thanks in advance.

regards

Max

[nxf93270]

Hi @mastupristi,

When you mention the "older tools," are you referring to the elftosb and cst tools? As far as I know, the entrypointAddress must be specified explicitly when using elftosb, and I am not aware of any option to omit this setting. However, I don't have extensive experience with it, so I could be mistaken.

I also made a typo regarding the release date of SPSDK 2.5; it is December 2024, not 2025. This means that the feature should be delivered within two months. We always collect feedback from our customers and strive to incorporate it into our product as quickly as possible. I hope this will enhance your experience with SPSDK. In the meantime, there is a workaround that involves specifying the entrypointAddress in the configuration file.

[mastupristi]

hi @nxf93270 

Glad to know there was a typo.
Unfortunately, we are on a very tight schedule. Is it possible to get us an idea of code patches that we can apply locally while waiting for version 2.5 to be released?

regards

Max