Hi,
Yeah, it' not simple.
At some point the stm32 spi drivers, for example, could be called
several times but only the first one initialized the spi, and it did
that only if the SPI block was not enabled yet. It seems to have been
fixed by using a priv->initialized member now.
If the bootloader enables the clock, we also have the problem of
determining how these were configured by the bootloader. An information
block passed from the bootloader to the main OS could be used.
Sebastien
On 7/3/23 22:01, Petro Karashchenko wrote:
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
