config.bib ROMOFFSET calculation for iMX53 EC7 platform

[bdp42]

Hi,

I am attempting to build an image for NOR flash on an EC7 iMX53 based platform.

I am using the SABRE ARD BSP as the base BSP for this. The config.bib file does not appear to have support for NOR flash and my understanding is that I need to modify this file (amongs other things). Specifically in config.bib I think I need to define the ROMOFFSET variable to suit my configuration/platform. The MSDN documentation states that this is needed when the run-time image is located at a different address. This is the case here since it is stored in NOR but I want it to execute from RAM. I believe I can use XIP but I don't want to do this just yet. I have attempted to use the NAND flash section as an example of what to do but I find it confusing.

For example in config.bib here is where ROMOFFSET is defined for Nand Flash.

        ; CSP_BASE_MEM_PA_NFC+IMAGE_BOOT_NKIMAGE_NAND_OFFSET = 0x9F5F0000 + 0x80400 = 0x9F670400

        ; ROMOFFSET = (FLASH_PHYSICAL_ADDRESS - ROMSTART) % 0x100000000

        ;           = (0x9F670400 -  0x80200000) % 0x100000000 = 0x1F470400

        ROMOFFSET=0x1F470400

Here is a relevant line from the g_oalAddressTable in oemaddrtab_cfg.inc defining the virtual/physical addresses for NAND controller.

DCD 0x9F500000, CSP_BASE_MEM_PA_NFC_1MB, 5

; NFC internal buffer

The first comment in config.bib says CSP_BASE_MEM_PA_NFC+IMAGE_BOOT_NKIMAGE_NAND_OFFSET = 0x9F5F0000 + 0x80400 = 0x9F670400.

CSP_BASE_MEM_PA_NFC equals 0xF7FF0000 for an iMX53 and not 0x9F5F0000 as in the comment. 0x9F5F0000 looks like a virtual address as defined in g_oalAddressTable.

Secondly NAND virtual address start at 0x9F500000 and not 0x9F5F0000. There appears to be an offset of 0xF0000.

To confuse things further I have seen it stated that ROMOFFSET is used for Physical<->Virtual address compensation.

I am trying to use the NAND as an example of what to do with NOR but I find it totally confusing. So can someone clarify this?

• The comments state physical addresses but the actual calculations appear to use virtual addresses.
• The NAND virtual start address used (0x9F5F0000) is not the start of NAND (0x9F500000) as per the g_oalAddressTable. Where did this 0xF0000 offset come from?

Thanks in advance.

Bruno

[pawel]

Please post your oemaddrtab_cfg.inc and config.bib. As I remember NOR image is generated by default (if no IMGSDMMC and no IMGNAND is defined).

[bdp42]

I have attached config.bib and oemaddrtab_cfg.inc as requested. I was not aware that the system defaulted to NOR if both IMGSDMMC and IMGNAND were not defined and so perhaps there was no need to axplicitly define IMGNOR as I did. However another reason for doing this was to define a non zero romoffset (i.e. store in NOR but execute from RAM)  - at least initially. I'm guessing that the ROMOFFSET defaults to 0 for NOR (i.e. XIP).

Bruno

[bdp42]

Hi,

I was working on something else for a while and have come back to this. I've moved on a bit and am trying to deal with another issue. The OEMaddress table is used to map cached virtual addresses to physical addresses. The use of a cached address is, I believe, incorrect when dealing with the NOR device since the control aspects of this ( i.e. locking, unlocking, programming, etc.) may not work if this is a cached area - we have to always read/write to the device.

I looked at using the EC7 MmMapIoSpace function to map the physical address to an uncached address but I've hit another problem. The NOR flash driver (I am using the MS strataflash code) requires that the base address be aligned on block boundaries and it perform an explicit check for this. The address I get back from MmMapIoSpace is not aligned in this way and so the driver initialisation fails. I can't see how to control the alignment of the virtual addres that this function returns and so can't see how to get ensure this will work.

Has anyone else used the MS NOR strataflash driver and encountered this kind of issue? Is there an alternative approach maybe?

I have posted a question about this on the MSDN Embedded Compact platform development forum but so far I have not receives a useful reply.

Thanks,

Bruno

[YixingKong]

Bruno

Had your question got answered? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

[bdp42]

The question has not been answered but we have moved away from this approach and so it's not relevant any more.

Thanks,

Bruno

[vijayraisinghan]

Hi Bruno,

The calculations indeed look a bit suspicious - I don't have an exact answer to your questions but I will try to help you to get to where you want to be.

The first thing you need to do is indeed modify oemaddrtab_cfg.inc and add the virtual to physical address correspondence for your NOR Flash. Your NOR flash is memory mapped at a particular physical address, so you should be able to specify that one, along with the size and virtual address you want to obtain, making sure there is no overlap with the rest. The reason of this change is purely related to accessing the NOR and has nothing to do with what I am going to explain next.

The ROM offset in config.bib in that particular scenario is used to modify the header inside NK.bin and this is how EBOOT will know (after NK.bin is downloaded) that it is dealing with a NAND image and act accordingly (and suggest the option to flash it for instance). It is basically a trick to tell EBOOT what kind of image it has to deal with.

In your case, you may want to add a IMGNOR option which modifies the ROMOFFSET, then treat this in EBOOT to detect that you are dealing with a NOR image and maybe flash it to NOR after downloading it from Ethernet.

If you are currently at a stage where you want to build a NOR image and flash it to NOR, I would recommend modifying EBOOT's NAND portion (when EBOOT detects that it is dealing with a NAND image), and then flash it to NOR instead. Do you currently have NOR validated within EBOOT? Can you already read/write data from/to it already?

Let me know how this goes or if you have further questions.

Regards,

Sebastien

[bdp42]

Hi Sebastien (or is it Vijay?),

Thanks for the reply. We are currently having an issue with accessing the NOR device and so we are looking at this at the moment.

What I have done is created an IMGNOR variable and set the ROMOFFSET appropriately for NOR flash. The plan is to  program NOR after downloading the image.

I see that you recommend modifying the NAND Eboot code to deal with NOR. I have added support for NOR and am using the existing NOR code but noticed that some of this code in the Bootloader is actually commented out (the BSP is based on theSABRE  ARD platform). Do you happen to know why this is the case and why do you suggest changing the NAND code as opposed to using the NOR code or I am misunderstanding what you said.

Thanks,

Bruno

[vijayraisinghan]

Hi Bruno,

I am just using Vijay's login ID :smileyhappy:

The idea behind basing some code off of NAND in EBOOT is purely for debugging purposes - at least we know that NAND works fine and validated, and some of this code can be reused for the NOR work you are trying to do.

Any luck with accessing your NOR? After configuring the memory controller registers and setting the right mapping in your OAL address table, I would not really touch at anything else at the moment and focus on reading/writing test data in the NOR flash.

Regards,

Sebastien

[YixingKong]

Adeneo Engineering Team, can you please respond to this issue as soon as possile?

Thanks,

Yixing

[karina_valencia]

Deactivated user are you available to help on this case?