i.mx RT600 changing flash base address

[DerekSnell]

This is on behalf of Discord user emh203, who wrote this post, copied below:

I am trying to find the maintainer for the RT6xx SoC port. I am working on a board port and ran into an issue with reworking the memory layout to use FlexSPI Port A. The Board for the RT685-EVK maps the base of Flash to 0x18000000. Using a QSPI device on FlexSPI a requires an address of 0x0800000. When I made the necessary changes in the device tree overlay in the board files, I noticed in the .map file that the base address of flash would always be 0x50000000. After some digging, I found the peripheral node in rt6xx.dtsi:
/ {
soc {
sram: sram@30018000 {
ranges = <0x20180000 0x30180000 0x300000>;
};

    peripheral: peripheral@50000000 {
        ranges = <0x0 0x50000000 0x10000000>;
    };
};

};
It looks like this is limiting my ability to set my base address of flash. If I make a change such as:
peripheral: peripheral@50000000 {
ranges = <0x0 0x00000000 0x60000000>;
};
};
The range allows my flash to be placed at 0x08000000

I am able to patch my device tree with an overlay but It would be nice to get this upstream. I first would like to understand any possible implications of opening up the peripheral range. I could submit a pull request once this is sorted out.

[DerekSnell]

Hi emh203.

First, I want to clarify some details about the RT600 memory map, because I don’t think this change you brought up for QSPI is required. The memory map difference between 0x1800_0000 (default flash address in Zephyr port) and 0x0800_0000 is the security mode for TrustZone. Both of these addresses map to the same physical address of external memory on the FlexSPI. The Cortex-M33 core used in RT600 has TrustZone, and the application can partition code, data and other resources between secure and non-secure access. Attached <memmap.jpg> is a snippet of the RT600 memory map. NXP’s TrustZone implementation uses bit28 of the address to differentiate between Secure and Non-Secure address. Therefore, address 0x1800_0000 is the secure address base for FlexSPI, and 0x0800_0000 is the non-secure address base.

Since you mention the FlexSPI Port A address, here is some details about the FlexSPI memory map. The FlexSPI on RT600 has two ports: A and B. The difference between them is the speed of the pins. Port A uses high-speed pads to enable higher frequencies with the external memories. Port B uses the standard pads. On the MIMXRT685-EVK board, the external octal flash is connected to Port B pins, and the external pSRAM is connected to Port A. The memory map for the external memories through the FlexSPI is configured through the FlexSPI registers. Below is a snippet from the RT600 User Manual. The memory A1 base address is always the base address of FlexSPI, which is 0x0800_0000 or 0x1800_0000 depending on security mode. The base address for the memories on Port B depend on the Port A sizes programmed in the FlexSPI registers. The Zephyr port for MIMXRT685-EVK board sets FA1_SIZE and FA2_SIZE to 0 (pSRAM is not used), so the octal flash device B1 base address is also 0x0800_0000 or 0x1800_0000. Sounds like your hardware has a QSPI device on port A, so the base address for that A1 device is also 0x0800_0000 or 0x1800_0000. Therefore, if your application is not leveraging the TrustZone separation of secure and non-secure code, then the Zephyr app on your board can also use the default base address 0x1800_0000.

Now back to what you reported. There should not be an issue changing the flash base address to use 0x0800_0000 in the device tree. I tried this and see the issue you reported, and it does seem to be a problem with how the devicetree is setup. NXP is looking into this more to see what is needed to enable the non-secure flash base address. But I don’t recommend changing the peripheral ranges binding that way. That binding describes the memory map for the peripheral registers, and the base address is 0x5000_0000 for secure mode or 0x4000_0000 for non-secure. Instead, to workaround this for now, I left the DTS file as is. But I built Zephyr app by overriding the default for Kconfig symbol CONFIG_FLASH_BASE_ADDRESS. Using this command below builds this app at 0x0800_0000, and it runs well for me. Can you try this method instead? Thanks

west build -b mimxrt685_evk_cm33 zephyrproject\zephyr\samples\hello_world -- -DCONFIG_FLASH_BASE_ADDRESS=0x8000000

[ehughes]

Hello Derek:

Thank you for the additional information regarding secure/non-secure addressing. I was planning on doing everything in non-secure context right now All of my board bring up activities have been bare metal w/ MCUXpresso where the linker has been setup to link the application to the 0x08000000 region. I had chosen to stay "non-secure" while creating a custom board in zephyr to not introduce other errors. I'll give the KCONFIG approach a try and will simply bake it into the board configuration for the time being.

On a related note, My bootheader is different from the EVK to support QSPI. I have verified correct operation, etc in the bare metal context. The EVK board pulls the boot header in from the nxp hal repository. I was assuming that this repository is reserved for NXP EVKs so I had planned on just putting my boot header in the board folder. I do plan on pushing this board upstream once everything is working.

[ehughes]

. NXP is looking into this more to see what is needed to enable the non-secure flash base address.

FYI. I did have an "enhancement" filed if we can sort out

#40084

[DerekSnell]

Sounds good, @ehughes

Yes I agree, I would put the QSPI boot header in your board folder. That is a good option for any memories not on the NXP EVKs, or any other differences with your boards.

Best regards

[dleach02]

@ehughes, I've been looking at this problem after @DerekSnell brought it to my attention.

The baseline problem is with the definition of flexspi in the board level dts file because here it is defining/establishing both the register mapping addresses and the memory map addresses to the flexspi. Typically, for platforms that can support secure/non-secure builds, the definitions would be offsets from a base where the base gets set in the parent nodes defined in the soc dts files for secure vs non-secure (see nxp_rt6xx_ns.dtsi and nxp_rtxx.dtsi). But part of the problem here is that this base value is applied for both of the reg address definitions below which is problematic because as you are probably aware, the IO mapping and memory mapping are different base addresses and can't use a single base address.

Still investigating.

&flexspi {
reg = <0x50134000 0x4000>, <0x18000000 DT_SIZE_M(64)>;
mx25um51345g: mx25um51345g@2 {

[dleach02]

@ehughes, check out the PR linked below.

Basically, we needed to clean up the DTS definition for rt6xx and make a minor extension to the tools to ensure that this works as expected. The PR is only adding the SOC definitions for secure and non-secure builds. I did not add the board level targets as I'm not sure what the use case is for non-secure unless you have TFM. But this should give you the framework to understand how to get this to generally work if you are building for non-secure.

#40228

[ehughes]

@dleach02

Thanks for the PR/Example. This was helpful.