* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
@ 2006-02-20 9:58 Josef Angermeier
2006-02-20 10:35 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: Josef Angermeier @ 2006-02-20 9:58 UTC (permalink / raw)
To: u-boot
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) ...
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
2006-02-20 9:58 [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ? Josef Angermeier
@ 2006-02-20 10:35 ` Wolfgang Denk
2006-02-20 12:18 ` Josef Angermeier
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2006-02-20 10:35 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Commitment, n.: Commitment can be illustrated by a breakfast
of ham and eggs. The chicken was involved, the pig was committed.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
2006-02-20 10:35 ` Wolfgang Denk
@ 2006-02-20 12:18 ` Josef Angermeier
2006-02-20 12:41 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: Josef Angermeier @ 2006-02-20 12:18 UTC (permalink / raw)
To: u-boot
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 at 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 at 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 ................
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
2006-02-20 12:18 ` Josef Angermeier
@ 2006-02-20 12:41 ` Wolfgang Denk
2006-02-20 13:02 ` Josef Angermeier
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2006-02-20 12:41 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If the hours are long enough and the pay is short enough, someone
will say it's women's work.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
2006-02-20 12:41 ` Wolfgang Denk
@ 2006-02-20 13:02 ` Josef Angermeier
2006-02-20 13:45 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: Josef Angermeier @ 2006-02-20 13:02 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ?
2006-02-20 13:02 ` Josef Angermeier
@ 2006-02-20 13:45 ` Wolfgang Denk
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2006-02-20 13:45 UTC (permalink / raw)
To: u-boot
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
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There is such a fine line between genius and stupidity."
- David St. Hubbins, "Spinal Tap"
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-20 13:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-20 9:58 [U-Boot-Users] hang after "Transferring Control to Linux": bd_info difference ? Josef Angermeier
2006-02-20 10:35 ` Wolfgang Denk
2006-02-20 12:18 ` Josef Angermeier
2006-02-20 12:41 ` Wolfgang Denk
2006-02-20 13:02 ` Josef Angermeier
2006-02-20 13:45 ` Wolfgang Denk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox