[FEATURE] Developing bootloaders for NuttX

[Laczen]

Is your feature request related to a problem? Please describe.

NuttX has several bootloaders that are supported in nuttx-apps. However when creating bootloaders there seem to be some basic items missing:

1. Bootloaders typically use a dedicated linker file that is optimized for its purpose. E.g. to allow ram loading of images a bootloader will use a part or ram at the "end" so that the image that is loaded can be as large as possible. For devices that are started by loading the bootloader to ram the image needs to be as small as possible and only contain the bare minimum.
2. To allow a dedicated bootloader script to be used there should be some kconfig value "IS_BOOTLOADER" or similar, this does not seem to exist in NuttX.
3. To achieve a minimal size bootloader many parts of NuttX are unnecessary, a dedicated "entry" could be used when a bootloader is created.

Describe the solution you'd like

1. Introduce a Kconfig "IS_BOOTLOADER" and allow a dedicated linker script to be associated with this config.
2. Allow the dedicated bootloader "entry" routine to skip most of the NuttX support. When this is allowed this could also result in the nuttx build system creating a almost baremetal application.

I am looking for feedback on this.

Describe alternatives you've considered

Create a bootloader for NuttX without any usage of the NuttX build system and completely separate from NuttX.

Verification

• I have verified before submitting the report.

[xiaoxiang781216]

why do you need add a new IS_BOOTLOADER option? it's more simple to select the bootloader link script automatically in your board makefile when nxboot is enabled.

[Laczen]

why do you need add a new IS_BOOTLOADER option? it's more simple to select the bootloader link script automatically in your board makefile when nxboot is enabled.

@xiaoxiang781216 thank you for replying. Is it allowed to add a bootloader link script and modify a board makefile depending on a config that is defined outside of the NuttX tree?

[acassis]

@Laczen I don't know if I clearly understood your goals. So, the idea is: you want to create a nxboot that doesn't initialize many peripherals of the NuttX?

I was thinking a different scenario could be (the other way around) since nxboot already initializes some peripherals, maybe when NuttX starts it could skip re-initializing all the peripherals that were initialized by the nxboot. @michallenc what do you think?

In fact this is a very common issue with Linux and U-Boot, normally U-Boot initializes the LCD, and then Linux re-initializes it, this is why we don't have a smooth transition on Linux devices.

[Laczen]

Hi @acassis, thanks for the reply.

My goal is twofold:
Create a decoupling between the different bootloader's in nuttx-apps and nuttx by defining a IS_BOOTLOADER config that could be accompanied by some other config values (e.g. ram_start and ram_size) that would be selected by the nuttx-apps bootloader implementation. This would allow a dedicated bootloader linker script.

Second allow creating a almost baremetal bootloader that could still use definitions from nuttx kconfig (e.g. the location and size of images). In many (all?) cases taking the approach of uboot will result in duplicate drivers in the bootloader and the NuttX application. Also bootloader's might not need any nuttx based drivers as they might just verify the image (including a signature in secure boot applications) by doing memrd from the flash region. A bootloader might not include any firmware update scheme at all, like in the case of miniboot, of the update mechanism could be delegated to a different NuttX image. All bootloader's NuttX based or not could benefit from a dedicated startup mechanism.

[michallenc]

I was thinking a different scenario could be (the other way around) since nxboot already initializes some peripherals, maybe when NuttX starts it could skip re-initializing all the peripherals that were initialized by the nxboot. @michallenc what do you think?

Yes, that could be beneficial. I already have one workaround with NXboot on SAMv7, because watchdog on this processor can't be turned off when already started. I already set it up in the bootloader, but then I skip the initialization after the jump to actual firmware - the logic expects it initializes the watchdog from off state and fails otherwise, so I can't run it. I suppose this could be beneficial for other peripherals, maybe skip clock initialization and so on?

The other possibility, which I use a lot, is to limit bootloader initialization as much as possible and initialize only the peripherals I need - serial port, some flash driver and watchdog. It requires two configuration - one minimal and one full. I think the user is usually forced to do this anyway, because he wants to keep bootloader program size as low as possible.

[Laczen]

@michallenc what is your opinion on the IS_BOOTLOADER config value and a possible dedicated linker script?

[michallenc]

@michallenc what is your opinion on the IS_BOOTLOADER config value and a possible dedicated linker script?

What parts would be unified if IS_BOOTLOADER is defined? I can think about linker script, but it would have to heavily depend on configuration (flash size, offset, ram size and so on). I am not sure if there is much benefit from the current state, because we already have linker scripts in board/ subdirectories for the boards - and bootloader script can be same as for the board itself, just with one ifdef.