[U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
Dear u-boot-users,
u-boot works on my custom board (MPC875, 64MB RAM, 16MB flash) but linux hangs (see debug console output below) when started with bootm-command.
I am using the ELDK 3.1.1 kernel sources (version 2.4.25) and a u-boot CVS version which is slightly newer than the 1.1.3 release. CLOCKS_IN_MHZ is not defined in my u-boot board config file and the IMMR define is in kernel and u-boot board config file identical.
I noticed, that bd_info structure in u-boot/asm-ppc/u-boot.h and eldk/ppc_8xx/ usr/src/linux/include/asm-ppc/ppcboot.h differ abit: in the kernel sources a
mon_fnc_t *bi_mon_fnc; /* Pointer to monitor functions */ } bd_t;
pointer to monitor funcs is defined, which is does not appear in u-boot.h. Is this intended or a bug ?
What else could i tryout before analyzing kernel log buffer and debugging the kernel ?
best regards,
Josef
---------------- SERIAL DEBUG OUTPUT ------------------------------
U-Boot 1.1.3 (Feb 20 2006 - 09:31:08)
CPU: MPC885ZPnn at 40 MHz: 8 kB I-Cache 8 kB D-Cache FEC present clock 40000000Hz != 100000Hz You made sure it's an ESM this is running on, right? DRAM: 64 MB Top of RAM usable for U-Boot at: 04000000 Reserving 203k for U-Boot at: 03fcd000 Reserving 2564k for malloc() at: 03d4c000 Reserving 60 Bytes for Board Info at: 03d4bfc4 Reserving 48 Bytes for Global Data at: 03d4bf94 Stack Pointer at: 03d4bf78 New Stack Pointer is: 03d4bf78 Now running in RAM - U-Boot at: 03fcd000 FLASH: 61.3 MB *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial U-Boot relocated to 03fcd000 Net: FEC ETHERNET => bootm 0xe0080000 ## Booting image at e0080000 ... Image Name: Linux-2.4.25 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 284357 Bytes = 277.7 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x03D4BCE8 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF00 bd address = 0x03D4BFC4 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xE0000000 flashsize = 0x03D4BF78 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFF000000 bootflags = 0x00000001 intfreq = 40 MHz busfreq = 40 MHz ethaddr = D6:60:1B:EF:B4:11 IP addr = 131.188.51.169 baudrate = 38400 bps No initrd ## Transferring control to Linux (at address 00000000) ...
In message 20060220095838.GA31756@false you wrote:
What else could i tryout before analyzing kernel log buffer and debugging the kernel ?
Why do you want to do other things first? Why not just take the logical next step?
Not looking at the kernel log buffer means the same like turning off your display before running the test - i. e. just ignoring the available data.
Best regards,
Wolfgang Denk
Rehi
Thanks for your quick reply.
What else could i tryout before analyzing kernel log buffer and debugging the kernel ?
Why do you want to do other things first? Why not just take the logical next step?
Just wanted to be sure, that its no bd_info-differ-bug. But you are probably right. Please be so kind and tell me, if the monitor-func-pointer difference in the two bd_info struct is of any concern.
Analyzing the kernel log revealed the following: Most of the time there is nothing in the log, sometimes the kernel version etc. can be found and a "Ooops: kern" and once i also found a "Machine ch" output.
Any hint what could go wrong ?
0009adb4: 00000000 00000000 00000000 00000000 ................ 0009adc4: 00000000 00000000 00000000 00000000 ................ 0009add4: 00000000 00000000 00000000 00000000 ................
0009adb4: 3c343e4c 696e7578 20766572 73696f6e <4>Linux version 0009adc4: 20322e34 2e323520 28616e67 65726d65 2.4.25 (angerme 0009add4: 69657240 636f6465 7369676e 34332920 ier@codesign43) 0009ade4: 28676363 2d566572 73696f6e 20332e33 (gcc-Version 3.3 0009adf4: 2e332028 44454e58 20454c44 4b20332e .3 (DENX ELDK 3. 0009ae04: 312e3120 332e332e 332d3130 29292023 1.1 3.3.3-10)) # 0009ae14: 35204d6f 6e204665 62203230 2031313a 5 Mon Feb 20 11: 0009ae24: 30323a35 32204345 54203230 30360a3c 02:52 CET 2006.< 0009ae34: 343e4f6f 70733a20 6b65726e 00000000 4>Oops: kern.... 0009ae44: 00000000 00000000 00000000 00000000 ................ 0009ae54: 00000000 00000000 00000000 00000000 ................
0009adb4: 3c343e4c 696e7578 20766572 73696f6e <4>Linux version 0009adc4: 20322e34 2e323520 28616e67 65726d65 2.4.25 (angerme 0009add4: 69657240 636f6465 7369676e 34332920 ier@codesign43) 0009ade4: 28676363 2d566572 73696f6e 20332e33 (gcc-Version 3.3 0009adf4: 2e332028 44454e58 20454c44 4b20332e .3 (DENX ELDK 3. 0009ae04: 312e3120 332e332e 332d3130 29292023 1.1 3.3.3-10)) # 0009ae14: 35204d6f 6e204665 62203230 2031313a 5 Mon Feb 20 11: 0009ae24: 30323a35 32204345 54203230 30360a3c 02:52 CET 2006.< 0009ae34: 343e4d61 6368696e 65206368 00000000 4>Machine ch.... 0009ae44: 00000000 00000000 00000000 00000000 ................
In message 20060220121837.GC31756@false you wrote:
Just wanted to be sure, that its no bd_info-differ-bug. But you are probably right. Please be so kind and tell me, if the monitor-func-pointer difference in the two bd_info struct is of any concern.
No. If this is the only difference, then it's just an absolete and unsued field at the end of the structure. But why don't you simply remove it???
Analyzing the kernel log revealed the following: Most of the time there is nothing in the log, sometimes the kernel version etc. can be found and a "Ooops: kern" and once i also found a "Machine ch" output.
Any hint what could go wrong ?
With a likelyhood of 99.93% your SDRAM initialization is broken.
[I think I should program a function key to automatically insert this text. ;-) ]
Best regards,
Wolfgang Denk
Hello Wolfgang
Just wanted to be sure, that its no bd_info-differ-bug. But you are probably right. Please be so kind and tell me, if the monitor-func-pointer difference in the two bd_info struct is of any concern.
No. If this is the only difference, then it's just an absolete and unsued field at the end of the structure. But why don't you simply remove it???
Ok, good to know!
Analyzing the kernel log revealed the following: Most of the time there is nothing in the log, sometimes the kernel version etc. can be found and a "Ooops: kern" and once i also found a "Machine ch" output.
Any hint what could go wrong ?
With a likelyhood of 99.93% your SDRAM initialization is broken.
[I think I should program a function key to automatically insert this text. ;-) ]
Oooh no, i hoped i would never have to get familiar with SDRAM initialization, of which i have no clue. But i feared that because "mtest" failes with:
=> mtest Pattern 00000000 Writing...
But how is this possible ? - u-boot gets successfully executed in SDRAM!
Thanks for your guess, at least i know in which direction to go for bug hunting.
Best regards,
Wolfgang Denk
Schoene Gruesse, Josef
In message 20060220130259.GA7009@false you wrote:
Oooh no, i hoped i would never have to get familiar with SDRAM initialization, of which i have no clue. But i feared that because "mtest" failes with:
=> mtest Pattern 00000000 Writing...
Argh.. You must never continue when you encounter such a problem. Always stop and take time to analyze and fix the problem. Even if you don't have time. Otherwise it will bite you later, usually when you have absolutely no time left to deal with it.
But how is this possible ? - u-boot gets successfully executed in SDRAM!
That does not mean much. Many systems run fine under pSOS or so and crash under UNIX systems. See the FAQ.
Thanks for your guess, at least i know in which direction to go for bug hunting.
Good hunting.
Best regards,
Wolfgang Denk
participants (2)
-
Josef Angermeier -
Wolfgang Denk