Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Kirkwood hang on boot; possibly uninitialised bss



On 22 May 2012 15:35, Robert Swindells <rjs%fdy2.co.uk@localhost> wrote:
>
> A current kernel boots fine on my Sheevaplug with the same SoC.
>
> From what I can see on the web, the only real difference between the
> DNS-325 and a Sheevaplug is that your D-Link device only has one
> bank of DRAM fitted.
>
> You could try modifying the code in initarm() that sets up the
> bootconfig structure to just set up one dram block.
>
> Robert Swindells


I'm a bit confused by this.

This page [1] says the RAM for the DNS-325 is provided as two chips:

  2xSEC K4T1G084QF-HCF7:128Mx8 @400 CL6 (256MB total)


From dmesg of Linux on a SheevaPlug [3]
(which I presume is the same as yours):

  SDRAM_CS0 ....base 00000000, size 256MB
  SDRAM_CS1 ....base 10000000, size 256MB
  SDRAM_CS2 ....disable
  SDRAM_CS3 ....disable

And U-boot:

  DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
  DRAM CS[0] base 0x00000000 size 256MB
  DRAM CS[1] base 0x10000000 size 256MB
  DRAM Total size 512MB 16bit width


But dmesg of the Linux in the origional DNS-325 firmware [2]
confusingly shows the same:

  SDRAM_CS0 ....base 00000000, size 256MB
  SDRAM_CS1 ....base 10000000, size 256MB
  SDRAM_CS2 ....disable
  SDRAM_CS3 ....disable

And U-boot shows what I'd expect:

  DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
  DRAM CS[0] base 0x00000000   size 256MB
  DRAM Total size 256MB  16bit width

I don't understand why Linux's dmesg on both machines would report the
same configuration, yet U-boot on each machine agrees with what I
understand the hardware to be.

In any case, NetBSD on my DNS-325 configures CS0 and CS1, just as Linux
appears to. I don't understand it, but I think this is correct.


The loop you mention in initarm() skips blocks of size 0 (in my case CS2
and CS3). I modified it as you suggest to also skip CS1:

  for (cs = MARVELL_TAG_SDRAM_CS0; cs <= MARVELL_TAG_SDRAM_CS3; cs++) {
      mvsoc_target(cs, &target, &attr, &base, &size);
      if (size == 0)
          continue;

      if (cs == MARVELL_TAG_SDRAM_CS1) {
          KW_PUTS("skipping CS1\r\n");
          continue;
      }

      ...
  }

The call to consinit was made before this loop (which hints to me that
this loop isn't at fault), and so I moved the call to consinit to occur
after this loop.

consinit_called still has its static storage starting out as non-zero,
and so consinit still believes it has been called already, just as with
the loop setting up both CS0 and CS1 as it was originally.


[1] http://jamie.lentin.co.uk/devices/dlink-dns325/
[2] http://dns323.kood.org/dns-325
[3] http://nozell.com/blog/2009/05/13/sheevaplug-initial-bootlog/

-- 
Kate


Home | Main Index | Thread Index | Old Index