Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

HPS DDR memory access for Preloader and UBoot

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.

PPS Sorry I've posted this in the top level forum too, before I read BadOmen's "Readme" saying don't post there, post in proper sub-level!

http://www.alteraforum.com/forum/attachment.php?attachmentid=11406&stc=1 http://www.alteraforum.com/forum/attachment.php?attachmentid=11407&stc=1

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    A further note: once the DDR memory is "corrupted", I can restart the debug instance within DS-5 and get through the preloader as far as (and including) spl_board_init(), and then look at the 0x100 0040 memory window again, it's back to saying "U-Boot 2013.01.01 for socfpga bo" in the text string at 0x100 0020.

    So clearly the DDR memory isn't getting corrupted, but DS-5's and the ARMs ability to read it has gone once it has the program counter moved to that addresss space.

    I wondered whether it was the processor Instruction Cache that was causing the problem, so I disabled that using the control register in CP15 (as per ARM documentation), but exactly the same thing happened.

    Any help or comments would be greatly appreciated.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Just curious you managed to see any printout from U-Boot?

    Since DS-5 is suspected, can you try lowering the JTAG clock and that helps?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I don't suspect DS-5 - it works reliably the rest of the time. I'm also using a USB-Blaster rather than a Blaster-II, so can't change the clock rate, but implication is it's running at 6MHz, which shouldn't be fast.

    If JTAG was the issue, why when it jumps to the first address in U-boot does all the data change when it looked fine beforehand?

    And to answer your first question, no - if I run U-Boot the HPS just reboots, and there is no output from U-Boot at all.