Well we resolved our DDR problem. Turns out the CAS latency on the e500 is defined in half clocks and a value of 5 gives you a CAS latency of 3. Next time I'll read the docs more carefully :)
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alden, Kevin Sent: Thursday, February 24, 2011 6:53 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Problem booting on custom board (85xx)
I am still fighting this DDR issue. Currently, I am trying to get a DDR test to run in uboot before the relocation occurs (in board_init_f). The problem is that if I write code to access memory mapped to DDR, I see no DDR activity on the logic analyzer. Unfortunately it took me a few days of analyzing memory test results before I realized this :)
It seems like any access to DDR memory actually just accesses cache. Looking at the relocate assembly code seems to verify this. It looks like that assembly loads the cache and then flushes the cache to DDR.
I tried modifying the DDR TLB entry to disable the cache, but that seems to hang my memory test before it even starts to write to memory. Does anyone know of a way to get simple memory read/write access working inside board_init_f?
Thanks, Kevin
________________________________________ From: Alden, Kevin Sent: Thursday, February 17, 2011 9:24 AM To: Jared Lewis Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] Problem booting on custom board (85xx)
I agree, it does seem like a DDR issue.
I commented out the code below because it seemed unnecessary and I was able to get into board_init_r. Problem now is that the first 3 instructions of board_init_r are all 0, so it crashes there. I looked around in memory and this problem is all over the place. Random instructions set to 0. There must be a time value that is just on the edge of working properly.
-Kevin
-----Original Message----- From: Jared Lewis [mailto:Jared.Lewis@radisys.com] Sent: Wednesday, February 16, 2011 4:57 PM To: Alden, Kevin Subject: RE: [U-Boot] Problem booting on custom board (85xx)
Hello Kevin,
In my experience (I've also worked on P2020s with U-Boot), if you can't make it to board_init_r, this is usually a DDR configuration problem. It is hard to say definitively from this output though. Are you using the default RDB project for your DDR settings?
Which emulator are you using to incorporate break points? Are you using a BDI or a different emulator? If you're using a BDI, are you configuring the memory controller of the P2020 with your configuration file or are you leaving the initialization to the U-Boot code?
Thanks, Jared
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Alden, Kevin Sent: Wednesday, February 16, 2011 8:00 AM To: u-boot@lists.denx.de Subject: [U-Boot] Problem booting on custom board (85xx)
Hello,
I have a custom board based on the Freescale P2020 RDB. I am having trouble getting through the entire boot sequence. Basically, I can't get a breakpoint to hit in board_init_r.
I can get a break point in the "in_ram" section of start.s though. This executes all the way to the following loop /* * Now adjust the fixups and the pointers to the fixups * in case we need to move ourselves again. */ li r0,__fixup_entries@sectoff@l lwz r3,GOT(_FIXUP_TABLE_) cmpwi r0,0 mtctr r0 addi r3,r3,-4 beq 4f 3: lwzu ri4,4(r3) lwzux r0,r4,r11 add r0,r0,r11 stw r10,0(r3) stw r0,0(r4) bdnz 3b
Basically, it spins through this loop for a while and eventually I get a TLB exception. Is this just a cut and dry DDR configuration problem, or should I be looking at my Uboot setup?
Thanks, Kevin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot