Linux freezes up while booting in a custom board

[borja_mrtnz]

Hi all,

we have been working with the ML507 board for a few months and we finally get linux working on that system. Now, we have made a custom board based on the ML507, with a Virtex 5 FX70T, and we are having a problem booting linux in this board. Linux starts loading but it freezes up after a few seconds:

XilXilinx Loader:
Flash header at: 0xF8000000
Entry:     0x00400000
BSS:       0x005CE000
BSS Size:  0x0000CDDC
Load Addr: 0x00400000
Load Size: 0x001CD917
Zero BSS:
Copy text:
Launch:

zImage starting: loaded at 0x00400000 (sp: 0x005cef1c)
Allocating 0x3d4510 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040e000:0x005cd917)...done 0x3b2054 bytes

Linux/PowerPC load: console=ttyS0 ip=on noinitrd rw root=/dev/mtdblock1 rootfsty
pe=jffs2
Finalizing device tree... flat tree at 0x5db300
Xil
zImage starting: loaded at 0x00400000 (sp: 0x007a3f1c)
Allocating 0x3c6510 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040e000:0x005c8f59)...done 0x3a4054 bytes
Attached initrd image at 0x005c9000-0x007a2035
initrd head: 0x1f8b0808

Linux/PowerPC load: console=ttyS0 ip=on  rw root=/dev/ram
Finalizing device tree... flat tree at 0x7b0300

We have created more than 10 different linux images with different configurations: with ramdisk, without ramdisk, with the image burned in flash... but we have always the same result.

We have used the debugging techniques which appear in XAPP1137, about using the ppc_bt script to examine what is on the stack, and we get the symbolic back trace shown below. The trace shown below is for a linux image with ramdisk, loaded using the dow command in XPS:

This trace shows that a serious error has caused the kernel to panic().  As we understand, the approximate location of the error appears to be in the function handle_page_fault(). It seems to be a problem with the memory, because the page faults are related to the memory.

Here is the dts file:

/dts-v1/;
/ {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "xlnx,virtex440", "xlnx,virtex";
    dcr-parent = <&ppc440_0>;
    model = "testing";
    DDR2_SDRAM: memory@0 {
        device_type = "memory";
        reg = < 0x0 0x20000000 >;
    } ;
    aliases {
        ethernet0 = &xps_ll_temac_0;
        serial0 = &RS232;
    } ;
    chosen {
        bootargs = "console=ttyS0 root=/dev/ram";
        linux,stdout-path = "/plb@0/serial@83e00000";
    } ;
    cpus {
        #address-cells = <1>;
        #cpus = <0x1>;
        #size-cells = <0>;
        ppc440_0: cpu@0 {
            #address-cells = <1>;
            #size-cells = <1>;
            clock-frequency = <200000000>;
            compatible = "PowerPC,440", "ibm,ppc440";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x8000>;
            dcr-access-method = "native";
            dcr-controller ;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x8000>;
            model = "PowerPC,440";
            reg = <0>;
            timebase-frequency = <200000000>;
            xlnx,apu-control = <0x1>;
            xlnx,apu-udi-0 = <0x0>;
            xlnx,apu-udi-1 = <0x0>;
            xlnx,apu-udi-10 = <0x0>;
            xlnx,apu-udi-11 = <0x0>;
            xlnx,apu-udi-12 = <0x0>;
            xlnx,apu-udi-13 = <0x0>;
            xlnx,apu-udi-14 = <0x0>;
            xlnx,apu-udi-15 = <0x0>;
            xlnx,apu-udi-2 = <0x0>;
            xlnx,apu-udi-3 = <0x0>;
            xlnx,apu-udi-4 = <0x0>;
            xlnx,apu-udi-5 = <0x0>;
            xlnx,apu-udi-6 = <0x0>;
            xlnx,apu-udi-7 = <0x0>;
            xlnx,apu-udi-8 = <0x0>;
            xlnx,apu-udi-9 = <0x0>;
            xlnx,dcr-autolock-enable = <0x1>;
            xlnx,dcu-rd-ld-cache-plb-prio = <0x0>;
            xlnx,dcu-rd-noncache-plb-prio = <0x0>;
            xlnx,dcu-rd-touch-plb-prio = <0x0>;
            xlnx,dcu-rd-urgent-plb-prio = <0x0>;
            xlnx,dcu-wr-flush-plb-prio = <0x0>;
            xlnx,dcu-wr-store-plb-prio = <0x0>;
            xlnx,dcu-wr-urgent-plb-prio = <0x0>;
            xlnx,dma0-control = <0x0>;
            xlnx,dma0-plb-prio = <0x0>;
            xlnx,dma0-rxchannelctrl = <0x1010000>;
            xlnx,dma0-rxirqtimer = <0x3ff>;
            xlnx,dma0-txchannelctrl = <0x1010000>;
            xlnx,dma0-txirqtimer = <0x3ff>;
            xlnx,dma1-control = <0x0>;
            xlnx,dma1-plb-prio = <0x0>;
            xlnx,dma1-rxchannelctrl = <0x1010000>;
            xlnx,dma1-rxirqtimer = <0x3ff>;
            xlnx,dma1-txchannelctrl = <0x1010000>;
            xlnx,dma1-txirqtimer = <0x3ff>;
            xlnx,dma2-control = <0x0>;
            xlnx,dma2-plb-prio = <0x0>;
            xlnx,dma2-rxchannelctrl = <0x1010000>;
            xlnx,dma2-rxirqtimer = <0x3ff>;
            xlnx,dma2-txchannelctrl = <0x1010000>;
            xlnx,dma2-txirqtimer = <0x3ff>;
            xlnx,dma3-control = <0x0>;
            xlnx,dma3-plb-prio = <0x0>;
            xlnx,dma3-rxchannelctrl = <0x1010000>;
            xlnx,dma3-rxirqtimer = <0x3ff>;
            xlnx,dma3-txchannelctrl = <0x1010000>;
            xlnx,dma3-txirqtimer = <0x3ff>;
            xlnx,endian-reset = <0x0>;
            xlnx,generate-plb-timespecs = <0x1>;
            xlnx,icu-rd-fetch-plb-prio = <0x0>;
            xlnx,icu-rd-spec-plb-prio = <0x0>;
            xlnx,icu-rd-touch-plb-prio = <0x0>;
            xlnx,interconnect-imask = <0xffffffff>;
            xlnx,mplb-allow-lock-xfer = <0x1>;
            xlnx,mplb-arb-mode = <0x0>;
            xlnx,mplb-awidth = <0x20>;
            xlnx,mplb-counter = <0x500>;
            xlnx,mplb-dwidth = <0x80>;
            xlnx,mplb-max-burst = <0x8>;
            xlnx,mplb-native-dwidth = <0x80>;
            xlnx,mplb-p2p = <0x0>;
            xlnx,mplb-prio-dcur = <0x2>;
            xlnx,mplb-prio-dcuw = <0x3>;
            xlnx,mplb-prio-icu = <0x4>;
            xlnx,mplb-prio-splb0 = <0x1>;
            xlnx,mplb-prio-splb1 = <0x0>;
            xlnx,mplb-read-pipe-enable = <0x1>;
            xlnx,mplb-sync-tattribute = <0x0>;
            xlnx,mplb-wdog-enable = <0x1>;
            xlnx,mplb-write-pipe-enable = <0x1>;
            xlnx,mplb-write-post-enable = <0x1>;
            xlnx,num-dma = <0x1>;
            xlnx,pir = <0xf>;
            xlnx,ppc440mc-addr-base = <0x0>;
            xlnx,ppc440mc-addr-high = <0x1fffffff>;
            xlnx,ppc440mc-arb-mode = <0x0>;
            xlnx,ppc440mc-bank-conflict-mask = <0x1c00000>;
            xlnx,ppc440mc-control = <0xf850008f>;
            xlnx,ppc440mc-max-burst = <0x8>;
            xlnx,ppc440mc-prio-dcur = <0x2>;
            xlnx,ppc440mc-prio-dcuw = <0x3>;
            xlnx,ppc440mc-prio-icu = <0x4>;
            xlnx,ppc440mc-prio-splb0 = <0x1>;
            xlnx,ppc440mc-prio-splb1 = <0x0>;
            xlnx,ppc440mc-row-conflict-mask = <0x3fff00>;
            xlnx,ppcdm-asyncmode = <0x0>;
            xlnx,ppcds-asyncmode = <0x0>;
            xlnx,user-reset = <0x0>;
            DMA0: sdma@80 {
                compatible = "xlnx,ll-dma-1.00.a";
                dcr-reg = < 0x80 0x11 >;
                interrupt-parent = <&xps_intc_0>;
                interrupts = < 0 2 1 2 >;
            } ;
        } ;
    } ;
    plb_v46_0: plb@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,plb-v46-1.03.a", "xlnx,plb-v46-1.00.a", "simple-bus";
        ranges ;
        FLASH: flash@f8000000 {
            bank-width = <2>;
            compatible = "xlnx,xps-mch-emc-2.00.a", "cfi-flash";
            reg = < 0xf8000000 0x8000000 >;
            xlnx,family = "virtex5";
            xlnx,include-datawidth-matching-0 = <0x1>;
            xlnx,include-datawidth-matching-1 = <0x0>;
            xlnx,include-datawidth-matching-2 = <0x0>;
            xlnx,include-datawidth-matching-3 = <0x0>;
            xlnx,include-negedge-ioregs = <0x0>;
            xlnx,include-plb-ipif = <0x1>;
            xlnx,include-wrbuf = <0x1>;
            xlnx,max-mem-width = <0x10>;
            xlnx,mch-native-dwidth = <0x20>;
            xlnx,mch-plb-clk-period-ps = <0x2710>;
            xlnx,mch-splb-awidth = <0x20>;
            xlnx,mch0-accessbuf-depth = <0x10>;
            xlnx,mch0-protocol = <0x0>;
            xlnx,mch0-rddatabuf-depth = <0x10>;
            xlnx,mch1-accessbuf-depth = <0x10>;
            xlnx,mch1-protocol = <0x0>;
            xlnx,mch1-rddatabuf-depth = <0x10>;
            xlnx,mch2-accessbuf-depth = <0x10>;
            xlnx,mch2-protocol = <0x0>;
            xlnx,mch2-rddatabuf-depth = <0x10>;
            xlnx,mch3-accessbuf-depth = <0x10>;
            xlnx,mch3-protocol = <0x0>;
            xlnx,mch3-rddatabuf-depth = <0x10>;
            xlnx,mem0-width = <0x10>;
            xlnx,mem1-width = <0x20>;
            xlnx,mem2-width = <0x20>;
            xlnx,mem3-width = <0x20>;
            xlnx,num-banks-mem = <0x1>;
            xlnx,num-channels = <0x2>;
            xlnx,priority-mode = <0x0>;
            xlnx,synch-mem-0 = <0x0>;
            xlnx,synch-mem-1 = <0x0>;
            xlnx,synch-mem-2 = <0x0>;
            xlnx,synch-mem-3 = <0x0>;
            xlnx,synch-pipedelay-0 = <0x2>;
            xlnx,synch-pipedelay-1 = <0x2>;
            xlnx,synch-pipedelay-2 = <0x2>;
            xlnx,synch-pipedelay-3 = <0x2>;
            xlnx,tavdv-ps-mem-0 = <0x186a0>;
            xlnx,tavdv-ps-mem-1 = <0x3a98>;
            xlnx,tavdv-ps-mem-2 = <0x3a98>;
            xlnx,tavdv-ps-mem-3 = <0x3a98>;
            xlnx,tcedv-ps-mem-0 = <0x186a0>;
            xlnx,tcedv-ps-mem-1 = <0x3a98>;
            xlnx,tcedv-ps-mem-2 = <0x3a98>;
            xlnx,tcedv-ps-mem-3 = <0x3a98>;
            xlnx,thzce-ps-mem-0 = <0x4e20>;
            xlnx,thzce-ps-mem-1 = <0x1b58>;
            xlnx,thzce-ps-mem-2 = <0x1b58>;
            xlnx,thzce-ps-mem-3 = <0x1b58>;
            xlnx,thzoe-ps-mem-0 = <0x3a98>;
            xlnx,thzoe-ps-mem-1 = <0x1b58>;
            xlnx,thzoe-ps-mem-2 = <0x1b58>;
            xlnx,thzoe-ps-mem-3 = <0x1b58>;
            xlnx,tlzwe-ps-mem-0 = <0x88b8>;
            xlnx,tlzwe-ps-mem-1 = <0x0>;
            xlnx,tlzwe-ps-mem-2 = <0x0>;
            xlnx,tlzwe-ps-mem-3 = <0x0>;
            xlnx,twc-ps-mem-0 = <0xc350>;
            xlnx,twc-ps-mem-1 = <0x3a98>;
            xlnx,twc-ps-mem-2 = <0x3a98>;
            xlnx,twc-ps-mem-3 = <0x3a98>;
            xlnx,twp-ps-mem-0 = <0xc350>;
            xlnx,twp-ps-mem-1 = <0x2ee0>;
            xlnx,twp-ps-mem-2 = <0x2ee0>;
            xlnx,twp-ps-mem-3 = <0x2ee0>;
            xlnx,xcl0-linesize = <0x4>;
            xlnx,xcl0-writexfer = <0x1>;
            xlnx,xcl1-linesize = <0x4>;
            xlnx,xcl1-writexfer = <0x1>;
            xlnx,xcl2-linesize = <0x4>;
            xlnx,xcl2-writexfer = <0x1>;
            xlnx,xcl3-linesize = <0x4>;
            xlnx,xcl3-writexfer = <0x1>;
        } ;
        Generic_SPI: xps-spi@f3000080 {
            compatible = "xlnx,xps-spi-2.00.b", "xlnx,xps-spi-2.00.a";
            reg = < 0xf3000080 0x80 >;
            xlnx,family = "virtex5";
            xlnx,fifo-exist = <0x1>;
            xlnx,num-ss-bits = <0x6>;
            xlnx,num-transfer-bits = <0x10>;
            xlnx,sck-ratio = <0x20>;
        } ;
        RS232: serial@83e00000 {
            clock-frequency = <100000000>;
            compatible = "xlnx,xps-uart16550-2.00.b", "xlnx,xps-uart16550-2.00.a", "ns16550";
            current-speed = <9600>;
            device_type = "serial";
            reg = < 0x83e00000 0x10000 >;
            reg-offset = <0x1003>;
            reg-shift = <2>;
            xlnx,family = "virtex5";
            xlnx,has-external-rclk = <0x0>;
            xlnx,has-external-xin = <0x0>;
            xlnx,is-a-16550 = <0x1>;
        } ;
        das_0: das@f4000000 {
            compatible = "xlnx,das-1.00.a";
            reg = < 0xf4000000 0x100 >;
            xlnx,family = "virtex5";
            xlnx,include-dphase-timer = <0x0>;
        } ;
        generator_0: generator@c1e00000 {
            compatible = "xlnx,generator-1.00.a";
            reg = < 0xc1e00000 0x10000 >;
            xlnx,family = "virtex5";
            xlnx,include-dphase-timer = <0x0>;
        } ;
        miscelanea_0: miscelanea@cc600000 {
            compatible = "xlnx,miscelanea-1.00.a";
            reg = < 0xcc600000 0x10000 >;
            xlnx,family = "virtex5";
            xlnx,include-dphase-timer = <0x0>;
        } ;
        xps_intc_0: interrupt-controller@81800000 {
            #interrupt-cells = <0x2>;
            compatible = "xlnx,xps-intc-1.00.a";
            interrupt-controller ;
            reg = < 0x81800000 0x10000 >;
            xlnx,kind-of-intr = <0x0>;
            xlnx,num-intr-inputs = <0x2>;
        } ;
        xps_ll_temac_0: xps-ll-temac@81c00000 {
            #address-cells = <1>;
            #size-cells = <1>;
            compatible = "xlnx,compound";
            ethernet@81c00000 {
                compatible = "xlnx,xps-ll-temac-1.01.b", "xlnx,xps-ll-temac-1.00.a";
                device_type = "network";
                llink-connected = <&DMA0>;
                local-mac-address = [ 00 0a 35 5d 58 00 ];
                reg = < 0x81c00000 0x40 >;
                xlnx,bus2core-clk-ratio = <0x1>;
                xlnx,phy-type = <0x0>;
                xlnx,phyaddr = <0x1>;
                xlnx,rxcsum = <0x0>;
                xlnx,rxfifo = <0x1000>;
                xlnx,temac-type = <0x0>;
                xlnx,txcsum = <0x0>;
                xlnx,txfifo = <0x1000>;
            } ;
        } ;
        xps_spi_0: xps-spi@f1000000 {
            compatible = "xlnx,xps-spi-2.00.b", "xlnx,xps-spi-2.00.a";
            reg = < 0xf1000000 0x80 >;
            xlnx,family = "virtex5";
            xlnx,fifo-exist = <0x1>;
            xlnx,num-ss-bits = <0x1>;
            xlnx,num-transfer-bits = <0x8>;
            xlnx,sck-ratio = <0x20>;
        } ;
        xps_spi_1: xps-spi@f6000080 {
            compatible = "xlnx,xps-spi-2.00.b", "xlnx,xps-spi-2.00.a";
            reg = < 0xf6000080 0x80 >;
            xlnx,family = "virtex5";
            xlnx,fifo-exist = <0x1>;
            xlnx,num-ss-bits = <0x2>;
            xlnx,num-transfer-bits = <0x10>;
            xlnx,sck-ratio = <0x20>;
        } ;
        xps_spi_2: xps-spi@f2000000 {
            compatible = "xlnx,xps-spi-2.00.b", "xlnx,xps-spi-2.00.a";
            reg = < 0xf2000000 0x80 >;
            xlnx,family = "virtex5";
            xlnx,fifo-exist = <0x1>;
            xlnx,num-ss-bits = <0x1>;
            xlnx,num-transfer-bits = <0x10>;
            xlnx,sck-ratio = <0x20>;
        } ;
    } ;
}  ;

What could be the reason to our problem?

Thanks in advance.

[linnj]

Hi,

Have you ran any stand alone code on the new board to know that memory is all functioning well? 

My personal style I learned out of these systems is to start with the most basic system to get a baseline working. I wouldn't have all that extra stuff in the system, just a uart and interrupt controller, processor and memory.  The extra complexity in the system makes it hard to find the problem in getting a 1st baseline.

You don't necessarily have to take it out of the h/w system as you can just take it out of the device tree so the kernel doesn't know it's there.  But a simple h/w system could also be helpful.

You included your device tree, but I would compare it to the ML507 device tree for the minimal stuff and look at the deltas. I would try to match the ML507 system on the new board with the minimal components even going so far as to use the same memory map and addresses and that way there are minimal deltas to fight.

Keep digging, you'll get there.

[borja_mrtnz]

Hello John,

thank you for your answer.

I forgot to say that our board is based on the ML507, but the DDR2 memory configuration is different, because we are using two 256 Mbytes chips from Micron (MT47H128M16HG-3), with a 32 bit data bus (16 bit per chip), 14 bit address bus, and 3 bit bank address.

We have tested the board using the application TestApp_Memory. At first, this application was very small, so when we make dow executable.elf  XMD put it in the bram (we used a project with bram and without device tree), so we added lots of printfs to make XMD download the application to DDR2. The application worked correctly, and we have output from the console after configuring the UART16550 correctly.

We have tested that the Flash memory is also correctly set, because we could manage to burn our linux image, loader and file system inside, like we get to do with the ML507, and it booted until it freezed up in the same line.

After a week of lots of tests, we also made a reduce version of our system, removing all the cores except from DDR2, powerpc, uart, interrupt controller and flash memory, and we also have the same result. We haven't tried to use ppc_bt with this configuration, but we will do it next.

We have compared both the ML507 and our board dts many times and we think there are no changes related to the important parts of the system.

After the stack log shown in the previous message, we are guessing if there is a problem with the memory controller. We have set MIC registers in PPC440 core like that:

Mask used to determine a row conflict: 0x003FFF00

Mask used to determine a bank conflict: 0x01C00000

Control and configuration for the MC interface: 0xf850008f

We have set this values according to our board desing parameters (based on DS567 document):

- C_DDR_DWIDTH = 32

- Address offset = 2

- Column address width = 10

- Row address width = 14

- Bank address width = 3

The rest of the parameters in the PPC440 block are left like in the ML507. The same goes for the DDR2 Controller.

[linnj]

One easy thing to try is to change the size of the memory in the device tree to match the ML507 or less.

Just another data point.

[borja_mrtnz]

Ok, we will try reducing the ddr2 memory map.

I have made another test of the DDR2 memory, the results are shown below:

I have run the linux system using dow command and stopped it before it freezes. Then, I have tried to make writes and reads in two different memory positions. Our DDR2 memory map goes from 0x00000000 to 0x1FFFFFFF (512 Mbytes), so I have tried to write and read in the first 256 Mbytes (address 0x400) and in the second 256 Mbytes (0x13330400) and it works well.

Just another test, maybe it helps.

There is another thing I must tell you. I have been also trying to make an application based on the TestApp_Peripheral for the ML507 to test the SPI core, and it works well in the ML507 board, but when I use the same application in our custom board (adapted to this board), even initializing correctly the SPI device, I never get to have the control, status and FIFO registers with their default values after the reset is made (control = 0x180, status = 0x5 and FIFOS = 0x0). The XSpi_self_test function of the SPI device gives me an error, because it compares the register values with their default values and they are not the same.  I was wondering if this has something to do with the first problem...

[borja_mrtnz]

Hello,

We have launched syslog in 512 MB DDR2 memory version project and the following  is displayed:

The syslog shows a failure in " Bad page state in proccess swapper pfn: 01701". It seems that something is wrong with  paging, however, we are not able to realize  what is happening and how to solve it.

On the  other hand, we have already tried changing the size of the memory in the device tree to match the ML507. But, it doesn't work.

Thank you.

[linnj]

If your system memory map exactly matches the ML507 system I would use the ML507 device tree and see what you get.

Not clear to me what the problem is either.

Sorry.

[linnj]

That console output doesn't agree with the fact that you reduced the ram, the kernel is still showing that larger amount of memory.

[linnj]

Ok the console has some strangeness as I see the amount of memory different, top of memory vs the other sizes of memory, not sure I understand that.

[borja_mrtnz]

Hello,

The previous console output was from the 512 MB of DDR2 test. Below is the console output for the 256 MB test (we have reduced the amount of memory in the dts in order to match the ML507):

[linnj]

That data fault at D0000.... is an I/O access probably.

Look at see if you can correlate what's there.  It's early so interrupt controlller is one early device.

I'm not sure why you're back at 2.6.31 as I don't think that buys you anything.

If the memory map matches the 507 system, boot it and seen if any output of the kernel shows any device at that address since it's virtual rather than physical.

[azanetti]

Hello all,

I am facing the same issue using the same memory chipset configuration, 2 MT47H128M16 with 256MB each one of the model mentioned above to have 512MB of memory for the Linux kernel. Each chip has a data width of 16 bits. We create a memory bank of 32 bit data width. We are using the same PPC configuration. The only difference is that we use the Virtex5 FX100T and we are trying to boot using NFS.

I have a kernel working with NFS boot on ml507.

We have on our board 4 chipsets and probably we can use all 4 banks instead of 2 if we think that a burst width of 32 bits may be a problem.

Let me know if you guys have any sugestion of the direction to take to debug it.

Best regards.

[borja_mrtnz · Accepted solution]

Hello all,

PROBLEM SOLVED!!

there was a problem with the DDR2 timings assigned to the memory controller: they were too strict. First we used the timings from Micron datasheet, but it seems that these timings were very restrictive (maybe our board design is not able to attain those timing constraints) so, after a hundred of tests, we decided to relax DDR2 timings doubling them in the memory controller (for example, from 7.5 ns to 15ns), and adding additive latency to the DDR2 (additive latency = 2). After this change, linux started up properly!!

Now is time to adjust the timings to the limit, because in our case we need all the DDR2 bandwidth we can get for our Data Acquisition System.

John, thank you very much for your great help.

Regards,

Borja

[azanetti]

In addition, I would appreciate if anyone could tell me where I can download the xmd tcl/tk scripts to debug.

Best regards.

Ademir Zanetti

[borja_mrtnz]

Hello,

in the XAPP1137 project files there is folder called "xmd_tcl_scripts". The link to download them is in the first page of the XAPP1137 pdf. The scripts are inside the project folder. The way to use them is explained in the XAPP1137 pdf.

Regards,

Borja

[azanetti]

There is something still bothering me, if you ran the memory text using plain C code, without Linux and you got no error, it indicates that your memory timming were working properly.

Why would it impact only Linux and no plain C code ?

I am just trying to find out the root cause of the issue to not be surprised in near future.

Best Regards

Ademir Zanetti

[linnj]

We find that Linux really pushes the system much harder than any standalone apps as it's such a large code base.

Maybe the standalone memory test needs to be enhanced also.

Glad you got it going as I was about out of ideas.

[azanetti]

Borja,

Even doubling the DDR timing parameters, I still get the same error :-(

Would you mind to share the configuration you are using with me?

Thanks in advance

Ademir Zanetti 

[borja_mrtnz]

Hello,

at first we started doubling the DDR2 timings, but right now we have managed to boot linux correctly with the following configuration, which are the timing values specified in the datasheet + 10%:

Make sure you have changed the registers in the MCI of the ppc440 core to the appropiate values. In our case, the values are:

The previous values depend on the values of the DDR2 registers, which in our board case are:

Does your board pass the TestApp_Memory test?

Regards,

Borja

[azanetti]

It is working now :-)

Thanks a lot for you help Borja. 

Ademir Zanetti

[borja_mrtnz]

What do you think the problem was?

Borja

[azanetti]

The problem is that there was still parameters to strict. We did not double all the parameters to test.

Thanks again.

Ademir Zanetti.