Boot ROM copy QuadSPI to OCRAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Boot ROM copy QuadSPI to OCRAM

Jump to solution
2,054 Views
michaeljohnson
Contributor II

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

0 Kudos
Reply
1 Solution
1,376 Views
anthony_huereca
NXP Employee
NXP Employee

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

View solution in original post

0 Kudos
Reply
8 Replies
1,376 Views
anthony_huereca
NXP Employee
NXP Employee

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

0 Kudos
Reply
1,376 Views
michaeljohnson
Contributor II

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

0 Kudos
Reply
1,376 Views
anthony_huereca
NXP Employee
NXP Employee

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

0 Kudos
Reply
1,376 Views
michaeljohnson
Contributor II

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.

0 Kudos
Reply
1,377 Views
anthony_huereca
NXP Employee
NXP Employee

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

0 Kudos
Reply
1,376 Views
michaeljohnson
Contributor II

Hi Anthony,

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

Regards

Michael

0 Kudos
Reply
1,376 Views
naoumgitnik
Senior Contributor V

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.

0 Kudos
Reply
1,376 Views
michaeljohnson
Contributor II

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

0 Kudos
Reply