[U-Boot-Users] Linux kernel startup (s3c24xx)

Harald Welte laforge at gnumonks.org
Mon Apr 7 23:25:13 CEST 2008


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.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/dd1ed9f6/attachment.pgp 


More information about the U-Boot mailing list