Serkan,
It will be a little difficult to help you debug this problem since you
have changed the one thing that you need for a reliable system - the PCB.
But here are a few questions:
How certain are you that the software that you are running is good? How
did you program the NAND flash? Make sure you are using the exact same
images that work on the EVM - and they are in the same physical
locations in NAND. Another possibility is that you are trying to use bad
blocks as part of the kernel image. Normally we see that the kernel will
not boot because of a bad CRC check, but I think you have gotten past
that point (a console print out would be helpful here). There is also a
way to use the serial port to download a kernel with zmodem - it's slow
but it does work...
Generally we use a JTAG emulator (Olimex or BDI) and download UBL/Uboot
and the kernel into memory for our first boot tests. I have also written
a a memory test based on UBL that does some simple sanity tests to make
sure the hardware can run at speed.
If your Uboot is running without modifying the DDR clocks, you can use
the built in commands to modify memory (crude sanity test), dump blocks
of NAND, tftp a kernel from the network (if you use the 10/100 PHY on
your board) etc.
So here is my suggestion. Back out all of your software changes. Boot to
the stock Uboot prompt and load a pristine kernel into memory. Boot the
kernel from the memory image and send the results. If all you see is
still the "...." then you might very well have a hardware problem.
But, as a long time PCB designer, trace impedance, length matching and
very careful layout practices are very important when dealing with DDR.
When I designed my dm355 board I was very careful to make sure that the
PCB manufacturer gave us boards that matched our impedance goals (in
addition to following the layout guidelines). Changing to a 4 layer
board, may have altered the impedance of the DDR traces to the point
where they have signal integrity issues, which may only show up at very
odd times - resulting in instability. Without seeing your PCB stackup,
layout (trace width) and other factors relating to trace impedance I
can't tell for sure if this is the issue.
At one point I worked on a design done in Taiwan with a DSP that I was
familiar with. The design was unstable at several frequencies, and I was
able to show that power/ground planes were insufficient to provide a
proper return path. The "fix" was to provide a more continuous
ground/power plane between the DSP and memory.
I hope all this information helps,
Steve
Serkan Erdogan wrote:
Hii All,
I have a realy serious problem. Our dm355 based mainboard pcb layout
was mainly copied from DM355_EVM so default UBL,Uboot and kernel was
were working well on it. But because of high cost of mainboard we
decided to redesign mainboard by reducing the pcb-layer count of
mainboard. We have designed and produced it with 4 layer pcb. It is
working with default UBL and U-BOOT without any problem. Everything to
here is perfect but...
After uboot loads kernel to memory and begins to uncompressing kernel
kernel never comes to live. It is giving the "Uncompressing
kernel........" string to console and than after a lot of ".........."
printing out on screen. It stops working. This a lot of dot printing
takes nearly 1 minite and than it is freezing.
At first we thought that it is a DDR memory layout problem but after i
reduce the CPU and DDR2 speed in UBL to 54MHz for CPU and 43MHz for
DDR2 the result is same. u-boot prints out speed information for
debugging and so i am sure that PLL clock reducing in UBL is
successfull but kernel is still not booting.
Than i have changed the default CAS and READ_LATENCY values of DDR2
controller in UBL code to make DDR2 working on slowest CLOCK speed.
The default value of CAS was 4 and READ_LATENCY was 4. I have set CAS
to 5 and READ_LATENCY to 7. These are slowest speeds that can be
selected according to DM355 DDR2 Controller user-guide. So it must
work but no no no. Kernel behaving samely after all.
As Summary; Latest configuration i am trying now is and this
configuration is still failing to bring kernel to live:(((
CPU : 54Mhz
DDR2 : 43 Mhz
CAS : 5
READ_LATENCY : 7
I have done the dm355_evm hardware modules testes with CCS 3.3 and
XDS510 and RAM and NAND-FLASH testes are passed very easly.
Additionally, ubl and u-boot are working problem-free on the board. I
think, this point signs that RAM layout is right but WHERE is the
problem???
Now, i have no debugger for linux kernel debugging. So i must find the
error by hacking and printing-out debug information to console or will
flash a led on any gpio line when kernel code execution reached to any
known point by me.
Is there any idea from anybody for this problem or any experience on
any similar problem? I am deeply in need of any idea for solution. I
am ready to consider any point that will speed-up me on the way to
solution.
LATEST NOTE : Our pcb layout has an error. It is DDR_DQGATE0 and
DDR_DQGATE1 pins are not routed like TI recommends in DDR2 design
document (SPRAAR3). They are connected to each other by shortest line
on the pcb. But the document says that they should follow the same
direction with other DDR2 signals so Dm355 will automatically
calculate the best READ_LATENCY value for current RAM layout of
special pcb. So i was edited the value of DDRPHYCR1 resigter in UBL
code to owercome this layout error. But maybe it is not necessary i
dont know.
Because of these layout error and freezing we are still considering
that it is a DDR2 problem but after thinking on uboot and ubl are
still working on 216MHz CPU and 177MHz DDR2 speed, i am really confused...
Is there any peripheral that can make kernel not-function properly in
the early-initialization of linux kernel??? Where can i follw linux
kernel boot process more easly without getting lost a very huge number
of *.c files. I just wanna learn the place of peripheral
initialization triggering file or code??? Where all drivers module
init functions are being called in kernel source tree in a defined
sequence???
Thank youvery much for reading and further help.
Best Regards,
Serkan Erdoğan...
Best Regards,
Serkan Erdoğan...
------------------------------------------------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
