Le 01/07/2023 à 18:41, Gregory Nutt a écrit :
On 7/1/2023 10:27 AM, Tim Hardisty wrote:
Lots of work to do a full u-boot replacement, yes. But a basic one
using existing NuttX stuff such as RNDIS, dfu, mtd etc. - for MY
board at least - would not be much work. He said...naively!
You often can't know how deep the water is until you get a little wet.
One thing I would mention. A bootloader is an app alright. But it
may need to use some of internal OS interfaces to control things like
interrupts, MMU, caches, etc. it may need to reset the CPU or other
actions that normal applications would not do. That raises a few
architectural issues (and explains why those primitive loaders are in
the board src/ directory and not in apps/).
Ideally it would run in supervisor mode with a FLAT memory model.
Hi,
I see two issues to take care about in that framework, there may be
more, but that can be dealt with:
- make sure that the defconfig for the bootloader nuttx has critical
parameters in sync with the main OS
- deinitialization of all hardware blocks that were initialized by
nuttx-bootloader so the nuttx-main find them in uninitialized state.
That could be a boardctl.
On a previous stm32-based product my bootloader was using SPI flash for
update and had a small driver for it, but this driver had to
*deinitialize* some SPI registers (disable the spi, IIRC) so NuttX finds
them in the correct state for initialization.
On my stm32h7 board, I have 128K (one flash block) for the bootloader,
which currently uses libopencm3. However libopencm3 is not maintained
anymore, stm32h7 support is incomplete, and I have to integrate a SPI
littlefs with a delicate RAID-0 MTD driver that duplicates the one I
have done for NuttX.
And 128K is enough of flash for a minimal NuttX (I hope so), so a NuttX
bootloader actually makes A LOT of sense, so thanks for the idea.
Sebastien
