[U-Boot-Users] U-boot and kernel
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
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
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@denx.de] Sent: Saturday, October 07, 2006 1:51 PM To: u-boot-users@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
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
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
participants (3)
-
Gerald Jackson -
Stefan Roese -
Wolfgang Denk