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
