Hi, The de-init part is a bit tricky here. I think that u-boot enables clocking for various parts of the SoC and mux pins used in bootloader, so if I recall correctly the clocks are not shutted down and pins are not de-muxed to reset value state when the OS is booted. The best would be if the OS (NuttX) drivers do not assume if it is started by HW loader or SW loader, but have drivers immune to that assumption and hard reset the peripheral in driver init routine.
Best regards, Petro пн, 3 лип. 2023 р. о 13:20 Sebastien Lorquet <sebast...@lorquet.fr> пише: > > 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 > >
