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

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

[Gerald Jackson]

 

Does anyone know what U-boot tells the kernel about memory?

 

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.

 

 

Gerald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20061007/bc3d6001/attachment.htm 

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

[Stefan Roese]

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

[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

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

[Wolfgang Denk]

Dear Gerald,

in message <A7C98E37A5710946908EEC7C796A7442012F2E@mainserver.reaonix.com> you wrote:
> 
> Thanks for your response.  Since is not a u-boot problem I am  going to
> post this on the kernel list.

Don't ignore Stefan's hint.

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

He wrote:

> IIRC you have to configure your kernel differently when you are using more 
> than 768MBytes (setup highmem...).

BTW: please read http://www.netmeister.org/news/learn2quote.html

This is probably not a bug, but a configuration issue.  Actually  the
problem  you've seen is caused by the standard configuration of Linux
on (32 bit) PowerPC systems; Normally you can use only use 0x30000000
(768MB) RAM (lowmem); if you need more you have to change your kernel
configuration, including shifting the kernel start address.

On your system, the following config options might fix the problem:

CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_CONSISTENT_START_BOOL is not set
# CONFIG_CONSISTENT_SIZE_BOOL is not set
# CONFIG_BOOT_LOAD_BOOL is not set

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.

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

[Wolfgang Denk]

In message <A7C98E37A5710946908EEC7C796A7442012F2D@mainserver.reaonix.com> you wrote:
> 
> Does anyone know what U-boot tells the kernel about memory?

Start address and size.

> 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.

Parameter passing is architecture dependent. Is this ARM, MISPS, PPC,
or what?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
C++ is the best example of second-system effect since OS/360.