[U-Boot-Users] U-boot and kernel

[Gerald Jackson]

Stefan and Wolfgang,

Thanks for your response.  Since is not a u-boot problem I am  going to
post this on the kernel list.

It seems initramfs doesn't like when the ocotea board as more then 512K
of memory.

checking if image is initramfs...Oops: kernel access of bad area, sig:
11 [#1]
NIP: C0251678 LR: C02515B4 CTR: 00000000
REGS: c0b81e50 TRAP: 0300   Not tainted  (2.6.18-rc2Ocotea_Reaonix)
MSR: 00029000 <EE,ME>  CR: 24464024  XER: 00000000
DAR: FFE35000, DSISR: 00000000
TASK = c0b6db70[1] 'swapper' THREAD: c0b80000
GPR00: 00000000 C0B81F00 C0B6DB70 C0B90000 000000D0 00000001 C011B1AC
C0219E74 
GPR08: C0270000 C0270000 C0270000 C026A288 42464022 30000000 C0270000
00000000 
GPR16: 00000001 FFFFFFFF 00000000 007FFF00 C0270000 3FF9E968 00000000
00000004 
GPR24: 00000000 0016877E FFE35000 007FFF56 007FFF00 C0270000 C0B80000
C0270000 
NIP [C0251678] unpack_to_rootfs+0x124/0x96c
LR [C02515B4] unpack_to_rootfs+0x60/0x96c
Call Trace:
[C0B81F00] [C02515B4] unpack_to_rootfs+0x60/0x96c (unreliable)
[C0B81F60] [C0251F80] populate_rootfs+0x7c/0x100
[C0B81F80] [C00010C8] init+0x3c/0x2dc
[C0B81FF0] [C0003FFC] kernel_thread+0x44/0x60
Instruction dump:
310c0001 7ceb0194 90e90000 91090004 3d40c027 3179ffff 7d2bc910 800aa1c8 
21000000 7c080114 7c0a4839 41820230 <881a0000> 3d60c027 392ba288
2f800030 
Kernel panic - not syncing: Attempted to kill init!
 <0>Rebooting in 1 seconds..

 
 

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Saturday, October 07, 2006 1:51 PM
To: u-boot-users at lists.sourceforge.net
Cc: Gerald Jackson
Subject: Re: [U-Boot-Users] U-boot and kernel

Gerald,

On Saturday 07 October 2006 18:13, Gerald Jackson wrote:
> Does anyone know what U-boot tells the kernel about memory?

Yes. I assume you are asking about 4xx PPC's right?

Until recently the only interface to communicate information between
U-Boot & 
Linux on PPC platforms was the bd_info structure. And this structure
included 
the memory size too.

For other cpu platforms there are other mechanisms to communicate this
kind of 
information but right now this is (still) the way to go for 4xx PPC's.

> The kernel has the same memory bug that I fix in u-boot and I don't
know
> if u-boot is telling it anything.

Are you talking about the bug in the DIMM module setup of the Ocotea
board? 
There is definitely not the same bug in the linux kernel, since the
kernel 
doesn't setup the memory controller (again).

Just a thought: Are you having problems with Linux and bigger memory
modules? 
IIRC you have to configure your kernel differently when you are using
more 
than 768MBytes (setup highmem...).

Best regards,
Stefan