Boot ROM copy QuadSPI to OCRAM

[michaeljohnson]

Hi All,

Does anyone know what changes I need to make to quadspi_boot.[ch] to get the boot ROM to copy from QuadSPI into OCRAM?

Regards

Michael

[anthony_huereca]

Hi Michael,

  I haven't confirmed on my own board, but you should be able to do this by changing the start address of the boot_data structure (that is pointed to by the IVT) in quadspi_boot.c to internal RAM instead of the QuadSPI "FLASH_BASE" like it currently is in the sample code. Also change the entry point to the RAM location instead of QuadSPI.

-Anthony

[michaeljohnson]

Hi Anthony,

"...changing the start address of the boot_data structure" do you mean the first entry in the struct?

In the boot_data struct I changed

PROG_BASE to 0x3f000000

PROG_LENGTH to 0x80000

In the image_vector_table struct I changed

ENTRY_POINT to 0x3f000000

Is this what you think is required? It's quite likely there's another problem stopping this working.

Regards

Michael

[anthony_huereca]

Hi Michael,

  The PROG_BASE should be correct.

  However the entry point needs to point to the first instruction you want to execute. So if you simply took the current hello_world QuadSPI XiP linker file, and changed the addresses to be in SRAM instead of QuadSPI, that would put the entry address at 0x3F000800. So make that change, and also make sure you modified the quadspi_xip.icf (assuming you're using IAR) linker file correctly so it's linked against SRAM address space instead of QuadSPI.

-Anthony

[michaeljohnson]

Hi Anthony,

I built the executable to load/run at 0x3f000000 (which it does via the debugger). I loaded it at 0x20000800 and put the boot stuff at 0x20000000. I can change the executable to load/run at 0x3f000800 if you think that is required?

Regards

Michael

p.s. this could be a duplicate - I pressed the wrong button last time.

[anthony_huereca · Accepted solution]

Hi Michael,

  I had some time to play around with it on a board, and have attached the modified files for the hello_world QuadSPI target to get it to work. Compile like you normally would for the QuadSPI target in hello_world project, and then use the quadspi_loader project to program the QuadSPI flash like normal.

  The basic idea is that the code is compiled against RAM addresses. Then the "entry" value in the IVT, and the "start" value in the Boot Data structure must be changed to point to RAM.  The tricky part is that the rest of QuadSPI IVT entries must still point to QuadSPI addresses.

-Anthony

[michaeljohnson]

Hi Anthony,

Thanks for that - loading/starting at 0x3f000800 makes things work for me.

Regards

Michael

[naoumgitnik]

Hello Michael,

A couple questions:

• Any reason to copy from QuadSPI into OCRAM? - Our standard approach is XIP (eXecute In Place).
• What is 'quadspi_boot.[ch]' you are referencing, please? Function, origin/location, etc.

Sincerely, Naoum Gitnik.

[michaeljohnson]

Hi Naoum

I'm working on supporting Vybrid in CrossWorks (www.rowley.co.uk).

I have the XIP working'ish - the debug story isn't too good at the moment I have to load with boot source set to sdcard (with no sdcard inserted). I can then debug the CA5 code up to the point that it turns on the CM4 then the debug port dies. If I set the boot source to the quadspi and power cycle I can attach and debug both CA5 and CM4.

The copy to SRAM can be useful for implementing in field update software i.e. the application checks which version of firmware to start executing and/or updates new firmware via some means.

The code is supplied in the Vybrid Sample Code - src/boot/quadspi.[ch]

Regards

Michael