• State Verified Answer
  • Replies 3 replies
  • Subscribers 76 subscribers
  • Views 1276 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 308816
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nrfutil 7.2.0 for aarch64-linux

timuritxs

Could you please open the sources of v 7.2.0 or make release of it for Raspberry Pi (aarch64-linux targets) because many companies have tests based on ARM singleboard computerrs like Raspberry Pi with Linux OS. When I try to use nrfutil 6.1.7 from your Github for generating OTA DFU packages, during DFU process it gives me an error which corresponding to nRF52840 bootloader error NRF_DFU_RES_CODE_INSUFFICIENT_RESOURCES. I am using nRF SDK v16.0.0. When I generate ota dfu packages with 7.2.0 everything is OK, but in my case I dont want to use Windows PC every time, I want to automate process.

Thanks.

Parents
  • 0

    Hello,

    I will create a feature request for aarch64 support. That said, it does not quite make sense that you get this error when creating the package with v6.1.7. To my knowledge, there have not been any changes made to the secure DFU support between these two versions. I'm also not aware of any previous issues with nrfutil that could lead to this error. 

    Did you use the exact same hex files in both cases? If so, I'd suggest you run '$ nrfutil pkg display <>.zip' on the generated zip packages to see what the differences are. 

    Best regards,

    Vidar

  • +1 in reply to Vidar Berg

    Oh, sorry, it was my mistake (I put merged hex of bootloader app and main app as input for nrfutil in Raspberry's case), you can close this issue. I checked nrf pkg display outputs for both 7.2.0 and 6.1.7, and they become equal after fixing my mistake.

    As soon as hex file is positional encoded, I think you can add Warning or Error to nrfutil pkg generate in case if theres some overlapping between bootloader address range (known by nrfutil by design) and main firmware address ranges (known from input hex), or add complete validation of main firmware address space. This could help users to catch errors early. Thanks!

Reply
  • +1 in reply to Vidar Berg

    Oh, sorry, it was my mistake (I put merged hex of bootloader app and main app as input for nrfutil in Raspberry's case), you can close this issue. I checked nrf pkg display outputs for both 7.2.0 and 6.1.7, and they become equal after fixing my mistake.

    As soon as hex file is positional encoded, I think you can add Warning or Error to nrfutil pkg generate in case if theres some overlapping between bootloader address range (known by nrfutil by design) and main firmware address ranges (known from input hex), or add complete validation of main firmware address space. This could help users to catch errors early. Thanks!

Children
Related
Terms of service