TimJTi opened a new pull request, #3068: URL: https://github.com/apache/nuttx-apps/pull/3068
## Summary This PR has been drafted after email-list discussions mainly with with @Cynerd and @michallenc I will leave it as a draft awaiting any initial observations from interested parties in case of changes - significant or otherwise - that requested. ### Progress Reporting This was driven as a result of the inevitable time that firmware upgrades can take. The progress is reported via syslog, but not all embedded systems use this and, in the case (such as mine) where a user LCD is available, it is beneficial to allow progress to be displayed duringh booting and upgrades - especially should things go wrong. To achieve this there is a new Kconfig choice - disabled by defaiult - to allow messages to be printed to stdout. Since other users may wish to treat NXboot as a library, and perhaps handle the messages differently, the feature is implemented by calls to a specific `nxboot_progress` function using new enums to indicate the type of message: info, error, or that a potentially lengthy procedure has started, stopped or is in progress using the "." character printed periodically. A user wishing to implement this in another way would use the existing top-level public function `nxboot_main` and would only need to modify this to report errors in a different way. Enabling this feature adds approximately 1.5KiB to the size of the binary, in my case. ### RAM copy In my case, the ultimate boot_image function needs to copy the validated and bootable image to SDRAM. Although this could be handled by the board-specific logic, the NXboot header does not conatin the size of the actual image to be copied meaning an image copy can only be of the entire NXboot "slot" size. This means it is a little slower then it could be and it made sense to have that implemented by a new function `nxboot_ramcopy` before calling the board boot function via `BOARDIOC_BOOT_IMAGE` This is enabled by a new Kconfig choice that is disabled by default The address to copy the image to is also configured via Kconfig - BUT there is no way that I can see for NXboot to determine the validity or otherwise of the configured address. ## Impact Since the new features are selected via Kconfig, defaulting to off, the is no intended impact to existing implementations. Lower level functions have been edited carefully, and I can confirm that NXboot still behaves for me as it did before the changes, with the added benefit of progress messages if required. The copy-to-ram function also works, for me, as required. ## Testing This has been tested on my custom board using a SAMA5D27C-D1G processor, equipped with a partitioned 256Mbyte NOR flash that for the NXboot slots, and an 800x40 TFT for stdout courtesy of the FBCON example application -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
