Hi Marco,

Thanks for your reply. The kconfig parameters (START_(V)FLASH, FLASH_SIZE)
do not belong to boards, hence they do not describe board properties but instead
limitations that are imposed on the NuttX image.

Some examples:
rp23xx with 4MB and the 4MB is divided in 1MB for NuttX and 3MB for storage:
START_FLASH = 0x10000000 and FLASH_SIZE  = 1MB.

rp23xx with 4MB and the 4MB is divided in 1MB for NuttX v1, 1MB for NuttX v2
and 2MB for storage:
  NuttX v1: START_FLASH = 0x10000000 and FLASH_SIZE = 1MB
  NuttX v2: START_FLASH = 0x10100000 and FLASH_SIZE = 1MB

stm32h7 with both internal and external flash: here you could generate a image
for internal flash: START_FLASH = 0x08000000 or external flash (typically)
START_FLASH = 0x90000000.

Regarding any discontinuity on flash, I don't think it is supported to compile
and run NuttX from a flash area that has any gaps. Of course it would
be possible
(but rare) to assign specific routines to specific parts of flash (if
they exist), such
setups would require dedicated scripts anyway and wouldn't use the kconfig
parameters. The setup with continuous flash is valid for the majority of cases
where the NuttX image is running from flash or booting from flash. If you know
an example where this is different please share.

Regarding discontinuity on ram, my proposal has nothing to do with
ram. It is only
for flash.

Regarding the flashing for rp23xx, IMHO this is a tool error trying to
make it simpler
for the user, but ends up creating confusion.

Using the linker file to describe how the physical flash is divided
and parsing this
to provide kconfig parameters that could be used by other parts doesn't seem a
viable approach: a linker file is not fit for this. It is accustomed
to use the c preprocessor
for linker files and hence to configure the linker. Also this would
create a second
configuration path next to defconfig.

Kind regards,

Jehudi

Op di 18 aug 2026 om 22:49 schreef Marco C. <[email protected]>:


>
> Why do we want a Kconfig to replicate the constant already provided in the
> linker script?
>
> IMHO, the linker script should be the unique source of truth about the
> FLASH/RAM mapping.
>
> And it already can set symbols that are resolved in the link step.
>
> There are many complicated configurations (discontiguous flash or ram,
> special ram regions with different purposes).
>
> Why do we want to assume that flash or ram are contiguous and have just a
> start and a size?
>
> If these constants must be exported to kconfig, then they should come from
> the linker script. And it is not just a copy. Each platform has different
> translations. If we need them for flashing the board, they usually do not
> match the linker (for example in rp23xx the flash is mapped at 0x10000000,
> and the flash scripts should flash it to 0x00000000). So I circle back to
> the original question: **why** do we need Kconfig for flash start and
> length?
>
> Best Regards,
> Marco Casaroli
>
>
> On Tue, Aug 18, 2026 at 8:17 PM Alan C. Assis <[email protected]> wrote:
>
> > Hi Jehudi,
> >
> > Maybe Greg can explain better, but I think CONFIG_FLASH_SIZE/START/END and
> > CONFIG_RAM_SIZE/START/END were used in the past when the MCU were very
> > simple.
> >
> > Over the time things became more complex, there are many possible RAM
> > configurations/layouts (OCRAM, etc, etc) that these config became obsolete.
> >
> > So, instead of trying to apply it again, I suggest you analyze why it
> > became obsolete and implement something different. Maybe a defined area in
> > the linker script.
> >
> > The solution must accommodate both scenarios: users who want or need to use
> > a Bootloader, and users who neither need nor want to use one.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, Aug 18, 2026 at 1:28 PM Laczen JMS <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > NuttX has generic kconfig parameters for FLASH_(V)START and FLASH_SIZE.
> > >
> > > Many of the board linker files are not using these parameters to
> > > configure the location of
> > > the image on flash (default is 0x0).
> > >
> > > I would like to use these parameters to configure NuttX when used in
> > > combination with a
> > > bootloader. Of course I don't want to break existing defconfigs.
> > >
> > > My idea was to use the value of FLASH_SIZE as an indicator for the
> > > linker files to switch
> > > from the default settings to the configuration parameters. As long as
> > > FLASH_SIZE=0 the
> > > default setup in the linker script is used, when FLASH_SIZE != 0 the
> > > configured parameters
> > > are put into use (this of course after the linker script is changed).
> > >
> > > Do you agree with such an approach? Or is there a better alternative?
> > >
> > > Kind regards,
> > >
> > > Jehudi
> > >
> >

Reply via email to