Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12600 Discussions

HPS DDR memory access for Preloader and UBoot

Altera_Forum
Honored Contributor II
1,179 Views

I have a Cyclone V board with 1Gbyte DDR3L memory connected up to the HPS. I am loading U-Boot through the Preloader using UART0 and YModem transfers from my PC. This all works, and I can see U-Boot at address 0x0100 0000 (start address is 0x100 0040) and all looks well in the debugger. Before it loads U-Boot it also tests the DDR3 memory with a LFSR pattern across 128MBytes of memory. It fills 128MBytes and then checks 128MBytes and there are no errors. In the preloader, I can edit the data at 0x100 0000 (I've tried editting the string at 0x100 0020 or if I've changed the op code I've put it back again afterwards), and the debugger reports that the data has changed, and all is still well. 

 

The difficulty arises when I step to U-Boot, ie to address 0x100 0040. At this point the memory window in the debugger suggests that MOST of the address space here has changed, and if I try and change the data at 0x100 0040 back to what it should be it says it can't write to it, and it reads back the value I was trying to change instead. 

 

The same thing happens if, having loaded the U-boot image I then just change the PC in the register space to 0x100 0040. 

 

What is the HPS doing that it somehow trashes all the DDR accesses that worked perfectly before it started trying to load code from the DDR memory? Is the instruction cache somehow corrupting things? Attached are screenshots of the memory window before we start executing in DDR and after. As you can see, the data has been shuffled! 

 

PS I've tried much the same steps using the GHRD on the Arrow SoCKit board and the debugger behaves perfectly well, and allows accesses to 0x100 0040 before and after the PC has jumped there, etc, so it's not just a DS-5 thing.http://www.alteraforum.com/forum/attachment.php?attachmentid=11382&stc=1 http://www.alteraforum.com/forum/attachment.php?attachmentid=11383&stc=1
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
435 Views

you are using cyclone based ghrd for cyclone board and denano ghrd for denano board?

0 Kudos
Altera_Forum
Honored Contributor II
435 Views

Not sure what you mean by that - I have my own board, similar to sockit board, with Cyclone V on it. But I think there was a fault on the board I was running, as it works on two other boards. Still not sure how memory can test ok but not run code from it - how can that be a board fault? Anyway, problem solved for now.

0 Kudos
Altera_Forum
Honored Contributor II
435 Views

Altera has a video on debugging preloader and uboot with DS-5. There's more to it than you've described doing.

0 Kudos
Reply