Re: [U-Boot-Users] Linux kernel startup
Hi Harald,
Please see my other e-mail response about this. I still believe there might be some wrong memory / bus / core clock timing and or voltage issues.
We changed the memory clock to a lower frequency(90MHz to 67MHz) and the the "Bad Data CRC" error has gone. Thanks alot. Our settings are: EXTCLK = 12MHz FCLK = 271 MHz HCLK = 67.75 MHz
please try to use u-boot's built-in memory verification code to veryify your memory before trying to boot a kernel on it.
We will do this now.
We are writing the kernel image directly to the ram to 33000000. Therefore as for now it is not copied from the flash.
Is the hardware a prototype of a new board, or is it proven, verified hardware?
Yes, the hardware is a new prototype.
The output now is as follows:
U-Boot 1..3.2 (Apr 7 2008 - 17:25:31)
DRAM: 128 MB Flash: 32 MB Using default environment
In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 33000000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 4278410 Bytes = 4.1 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK
Starting kernel ...
undefined instruction pc : [<30008018>] lr : [<310117bc>] sp : 30fcfa78 ip : 30fcffb8 fp : 00000000 r10: 00000001 r9 : 30fcfe18 r8 : 30fcffdc r7 : 31012ef4 r6 : 33000040 r5 : 31019514 r4 : 31019511 r3 : 30008000 r2 : 30000100 r1 : 0000016a r0 : 00000000 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
U-Boot 1.3.2 (Apr 7 2008 - 17:25:31)
DRAM: 128 MB Flash: 32 MB Using default environment
In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 ## Booting image at 33000000 ... Image Name: Linux kernel Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 4278410 Bytes = 4.1 MB Load Address: 30008000 Entry Point: 30008000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK
Starting kernel ...
undefined instruction pc : [<30008018>] lr : [<310117bc>] sp : 30fcfa78 ip : 30fcffb8 fp : 00000000 r10: 00000001 r9 : 30fcfe18 r8 : 30fcffdc r7 : 31012ef4 r6 : 33000040 r5 : 31019514 r4 : 31019511 r3 : 30008000 r2 : 30000100 r1 : 0000016a r0 : 00000000 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ...
and it keeps on resetting. We further reduced the SDRAM frequency to 45 Mhz, but still the problem persist. Is it still the problem with the u-boot frequency or with the linux kernel?
Thanks again. Tiju
Save all your chat conversations.. Find them online at http://in.messenger.yahoo.com/webmessengerpromo.php
Hi Tiju,
On Mon, Apr 07, 2008 at 09:09:36PM +0530, Tiju wrote:
Please see my other e-mail response about this. I still believe there might be some wrong memory / bus / core clock timing and or voltage issues.
We changed the memory clock to a lower frequency(90MHz to 67MHz) and the the "Bad Data CRC" error has gone. Thanks alot.
ok, this most likely means that you have some problems with your hardware design, probably exceeding the maximum permitted capacitive bus load.
We are writing the kernel image directly to the ram to 33000000. Therefore as for now it is not copied from the flash.
well, how do you copy the image into ram? It doesn't really matter from where the image is copied. What matters is that apparently the source of the copy is not equal to the destination of the copy. Even if you copy 'directly' via JTAG there is a source and a destination. and the destination will suffer through corruption if SDRAM timing or bus clock are wrong.
Is the hardware a prototype of a new board, or is it proven, verified hardware?
Yes, the hardware is a new prototype.
Well, then I suppose most of your problems are not u-boot problems but problems related to your hardware. You should verify your u-boot version with a known-working hardware (such as a smdk development board). Only if it fails on the known-good hardware, I believe there is sufficient reason to assume that the problem is actually a u-boot problem.
and it keeps on resetting. We further reduced the SDRAM frequency to 45 Mhz, but still the problem persist. Is it still the problem with the u-boot frequency or with the linux kernel?
* there is no u-boot frequency * the pll config done by u-boot is not the source of the problem, but rather some faulty hardware. lowering the clock is merely a workaround and not a fix.
I think any further debugging would be very specific to your hardware design.
participants (2)
-
Harald Welte -
Tiju