Hi,

I have a AT91SAM9G45 kit which has 2 DRAM banks one starting at 0x70000000 (default enabled) and one starting at 0x20000000. I modified U-Boot and initialised the bank at 0x20000000 for kernel usage by adding:

gd->bd->bi_dram[1].start = 0x20000000;
gd->bd->bi_dram[1].size = 0x8000000;

in dram_init(). After recompiling and flashing. U-Boot reports 256Mb, I also tried some memory writes/read commands from 0x20000000 and higher and seems to work so DRAM looks like it's initialised correctly.
The problem appears after booting linux (I'm using a 2.6.27 linux4sam kernel with exp patches without framebuffer compiled in) and trying to use more then 128Mb (as a single bank has) the kernel enters in a recursive OOOPS.
I'm starting the kernel with different bootargs:

1) mem=256Mb
2) Specify and exact map of the memory doesn't help either:
bootargs=mem=256M memmap=exactmap memmap=0x20000000@0x08000000 memmap=0x70000000@0x08000000 ...

Anyone has any ideea where the problem lies ? I also checked AT91BootStrap on Ulf Sammuelson suggestion and DRAM banks are both initialised as far as I can tell(and as probably the UBoot mw/md tests confirm).

Is the first bank reserved for video memory only (I'm not using framebuffer) ? Can it be used as system memory (hope it can because 128video memory is just too much even for a dev kit )?

U-Boot messages:

U-Boot 1.3.4 (Sep 4 2009 - 11:59:42)

DRAM: 256 MB
NAND: 256 MiB
DataFlash:AT45DB321
Nb pages: 8192
Page Size: 528
Size= 4325376 bytes
Logical address: 0xC0000000
Area 0: C0000000 to C00041FF (RO) Bootstrap
Area 1: C0004200 to C00083FF Environment
Area 2: C0008400 to C0041FFF (RO) U-Boot
Area 3: C0042000 to C0251FFF Kernel
Area 4: C0252000 to C041FFFF FS
In: serial
Out: serial
Err: serial
Net: macb0
macb0: Starting autonegotiation...
macb0: Autonegotiation timed out (status=0x7849)
macb0: link down (status: 0x7849)
Hit any key to stop autoboot: 0
U-Boot> printenv
ethaddr=3a:1f:34:08:54:54
bootdelay=3
baudrate=115200
stdin=serial
stdout=serial
stderr=serial
console=ttyS0,115200
root=/dev/mtdblock1
rw
rootfstype=jffs2"
bootargs=mem=256M memmap=exactmap memmap=0x20000000@0x08000000
memmap=0x70000000@0x08000000 console=ttyS0,115200 root=/dev/mtdblock1 rw
rootfstype=jffs2
bootcmd=nand read 0x72200000 0x00200000 0x0017CC38; bootm 0x72200000
ethact=macb0

Environment size: 412/131067 bytes



Thanks.

From kernel-paramters.txt:

memmap=nn[KMG]@ss[KMG]
[KNL] Force usage of a specific region of memory
Region of memory to be used, from ss to ss+nn.


So, that should be

0x08000000@0x20000000

instead of

0x20000000@0x08000000

etc.

Yes thanks, I inversed the params by mistake. Anyway it still doesn't work, and it looks like my mapping is ignored, probably uboot sends the atag struct with memory configuration overwriting my mem bootargs.

The kernel enters in recursive oops at different addresses:

Unable to handle kernel paging request at virtual address 00aa0000
...
Unable to handle kernel paging request at virtual address 40106250
...
Unable to handle kernel NULL pointer dereference at virtual address 00000000

etc

Could you solve the problem? I asked Atmel support, but no luck. They don't have any solution yet.

I pass both memory regions via U-Boot memory ATAGs. That's what I get:

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G45-EKES
Memory policy: ECC disabled, Data cache writeback
Ignoring RAM at 20000000-27ffffff (vmalloc region overlap).
Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz

The problem is that the first area 0x70000000-0x77ffffff will be mapped to 0xc0000000. It is correct.
But the second area 20000000-27ffffff will be mapped to 0x70000000, that is smaller than 0xc0000000 and thus invalid.

Any idea how to overcome this?

Have you tried to use only the first memory bank (0x20000000)? It still fails on my system.

goshik

I forgot to mention that I'm using 2.6.33 kernel.

goshik

I solved the issue by using SPARSE_MEM support in kernel. My patches are for 2.6.30 but should be easy to apply to 2.6.33.
A quick how-to here:
http://blog.linuxconsulting.ro/2010/05/using-both-memory-controller-with.html

Hi,

I have used your patch on kernel 2.6.30 and 2.6.34 and I got a kernel Panic, Could you help please?

Best regards,

RL

Hi goshik,

I'm currently stuck with 256 MB of RAM on AT91SAM9G45-EKES. And the problem I have identified matches with your description of the problem, i.e. in arch/arm/mm/mmu.c the second memory bank at 0x20000000 will be mapped at 0x70000000 which is less than PAGE_OFFSET (0xc0000000).

Did you find solution to this problem?

any inputs are welcome.

-PJ