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