Let's get back to the patch itself and the initialization of "FlexSPI" peripheral.
The FlexSPI is one of the "imxrt" on-chip devices that can have flash attached
to it, and that the on-chip boot ROM knows how to probe, configure, and then
boot from. The "imxrt" chips don't have on-chip flash, only a boot ROM that
knows how to look for boot devices or possible download devices (serial, USB,
CAN etc).
In particular, I'm adding support for HyperRAM as the main memory for my
application. This means that the RAM isn't visible until it is set up.
Back to FlexSPI: you can have up to four banks of FLASH attached to FlexSPI -
Port A, chip selects 1 and 2 and Port B, chip selects 1 and 2. I'll call them
A1, A2, B1, B2. I will have HyperFLASH connected to A1 and HyperRAM connected
to A2.
Memory mapping: the FlexSPI will address chips consecutively and the possible
total flash size, IMXRT_MEMORY_FLASH_SIZE, could be
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE + IMXRT_MEMORY_FLEXSPI_FLASH_A2_SIZE +
IMXRT_MEMORY_FLEXSPI_FLASH_B1_SIZE + IMXRT_MEMORY_FLEXSPI_FLASH_B2_SIZE if
there are four flashes connected to the FlexSPI.
I think only the first "A1" FLASH/RAM will be configured by the on-chip boot
loader, and anything else needs to be setup very early in boot, maybe in
"bsp_start_hook_0()". There are special cases such as when all four flash
devices are the same device, but that's special.
The on-chip boot loader supports ".sflash{A2,B1,B2}Size" members in the
"flexspi_nor_config_t" structure that it interprets, but I don't know if it
uses configuration blocks in other flashes, it seems easier to set things up in
"bsp_start_hook_0()", and the RAM won't have a configuration structure in it.
So:
- IMXRT_MEMORY_FLASH_SIZE should be set as the sum of the up to four flash
regions to support linking into the full set of flashes. Only one will be
mapped at "bsp_start_hook_0()". This isn't too important to me unless we can't
guarantee that the setup is in the boot flash. That gets to the next point.
- Do we need an IMXRT_MEMORY_FLASH_BOOT_SIZE? For FlexSPI this is
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE. This is to ensure:
-- The boot data, flash configuration, and startup code that finishes
initializing the FlexSPI need to go into the region mapped by the boot flash.
-- How early can linker sets be used? Can you have a "bsp_start_hook_0()"
linker set where you can e.g. finish setting up the FlexSPI?
- The "imxrt_boot_data.size" member should be set to
IMXRT_MEMORY_FLASH_BOOT_SIZE, which would be IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE
for FlexSPI, maybe.
- "flash-config.c" is specific to the FlexSPI peripheral. You could have a
design that boots using flash on the QSPI. "flash-config.c" should be
"flexspi-flash-config.c".
- The "imxrt_flexspi_config.sflashA1Size" should be initialized to
IMXRT_MEMORY_FLEXSPI_FLASH_A1_SIZE.
Similar comments apply to RAM. I'll be adding HyperRAM attached to FlexSPI
port A chip select 2 and it won't be setup until we get past
"bsp_start_hook_0()". So initial stack needs to be in on-chip RAM and we can't
access anything outside of on-chip RAM until after we finish setting HyperRAM
up in "bsp_start_hook_0()".
The code for the "imxrt" "_start" assigns something to the stack pointer that
isn't mapped yet if we haven't set up HyperRAM. It's not clear to me as
someone not that clear with ARM if that is ever going to be accessed.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to
interception and tampering.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
