xiaoxiang781216 commented on a change in pull request #4233:
URL: https://github.com/apache/incubator-nuttx/pull/4233#discussion_r677504311
##########
File path: include/nuttx/board.h
##########
@@ -331,6 +331,28 @@ int board_uniquekey(FAR uint8_t *uniquekey);
int board_switch_boot(FAR const char *system);
#endif
+/****************************************************************************
+ * Name: board_load_appimage
+ *
+ * Description:
+ * Load an application image from a given load address and perform the
+ * required actions for executing it (e.g. loading the Program Counter
+ * register with the application image entry point address).
+ *
+ * Input Parameters:
+ * loadaddr - Load address of the application image
+ *
+ * Returned Value:
+ * If this function returns, then it was not possible to load the
+ * application image due to some constraints. The return value in this case
+ * is a board-specific reason for the failure.
+ *
+ ****************************************************************************/
+
+#ifdef CONFIG_BOARDCTL_LOAD_APPIMAGE
+int board_load_appimage(uintptr_t loadaddr);
Review comment:
> > [...] I could like to see the possibility to identify the image
through the name not the address since the name match the file system more
natually.
>
> Just to make sure we are in sync: for **image** I am referring to a region
in the Flash storage that contains a firmware image (code+data in RAW format),
and not an update file.
>
> Basically the idea is that the platform is expected to have some MTD
partitions (e.g. `/dev/ota0` and `/dev/ota1`) that refer to booting slots.
> Initially, that `loadaddr` refers to the base address of either
`/dev/ota0` partition or `/dev/ota1` partition.
Yes, it point to a MTD partition in most case. But, why the path can't point
to nuttx.bin on SD card? It's very useful in some case. It may even point to
nuttx.elf and then board code can load the code/data to the correct location
without hardcoding the magic address number in the source file.
> So, we may change the `loadaddr` parameter to be a path to MTD partition,
but I feel that this may seen counter-intuitive, since the kernel will probably
need to once again retrieve the base address of the selected partition.
The name(string) give many possibllity here: you can even pass itoa as the
name here. The board code can:
1. If the string is actually number, it's an address
2. If the string is /dev/xxx, it's a partition
3. Otherwise, it's a file on the file system
We lose these possibility with loadaddr. The same discussion happen
internally when we design #4191. The final conclusion is that the name is more
flexible than the address, especially combine with Unix design philosophy
"everything is file".
--
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
