From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Hammond Date: Mon, 22 Jan 2007 15:54:39 -0800 (PST) Subject: [U-Boot-Users] yet another hang after relocate Message-ID: <802881.16758.qm@web32906.mail.mud.yahoo.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de I know that this has been rehashed a thousand times, but Im still stuck on this point. Im using U-Boot 1.1.5 compiled with gcc 2.4.6 and make 3.80. The boards I have use a 405GPr cpu with 2x MT48LC4M16A2-75G mem chips (for 16MB) and an intel 2MB JS28F160C3B flash chip. I have several boards at different speeds (200-333) and different mem speeds (100-133). Some have the 405 set to the old GP mode and others are in the new 405GPr mode. They all boot and run vxworks just fine, though Im not sure if that runs from ram or not. The sdram setup for the 405 is extremely simple, just a few registers and delays. It is identical to all the other 405 sample boards in the u-boot source, which I assume boot just fine. Ive played with all the registers and delay timings involved in sdram setup without success. Ive added a simple mem test with and without the data cache, which works fine either way. Also I copy the entire 2MB flash to ram and then verify it back. Again, no problems. Here is a typical console output: U-Boot 1.1.5 (Jan 22 2007 - 17:31:18) CPU: AMCC PowerPC 405GPr Rev. B at 200 MHz (PLB=100, OPB=100, EBC=50 MHz) , PCI async ext clock used 16 kB I-Cache 16 kB D-Cache Board: xxxx DRAM: 16 MB mcopt1: 80e00000 mb0cf: 46001 sdtr1: 86400d rtr: 5f00000 status: 80000000 speed: 100000000 CFG_FLASH_BASE: ffe00000 TEXT_BASE: fffc0000 CFG_MONITOR_BASE: ffe00000 CFG_MONITOR_LEN: 40000 CFG_MALLOC_LEN: 20000 CFG_ENV_IS_IN_FLASH: 1 CFG_ENV_SIZE: 800 CFG_ENV_ADDR: ffe3f7f0 CFG_ENV_OFFSET: 3f7f0 test: 16 MB - ok Flash copy test - ok fffc0000: 27051956 27051956 fffc0004: 552d426f 552d426f fffc0008: 6f742031 6f742031 fffc000c: 2e312e35 2e312e35 Top of RAM usable for U-Boot at: 01000000 Reserving 1935k for U-Boot at: 00e1c000 Reserving 128k for malloc() at: 00dfc000 Reserving 132 Bytes for Board Info at: 00dfbf7c Reserving 48 Bytes for Global Data at: 00dfbf4c Stack Pointer at: 00dfbf28 New Stack Pointer is: 00dfbf28 Im also dumping out the sdram registers, and a few global defines which might be important. The flash test (after copying to ram) also dumps out the first few words of TEXT_BASE in flash and in memory for visual inspection. This test does not supersede the flash copy done by relocate. I use a gpio controlled LED to pin point the crash, and it is just as it tries to jump to ram. I know sdram is 99% of the time the main culprit, but I have tried many different register values for this. Also the setup is no different from the other 405 based boards already in uboot. The sdram setup for the 405 is extremely simple anyway, all the chip programming seems to be handled by the cpu. Is there any environment/global define, compilier issue, execute protection, guarded page, strange register, who knows, that might be the cause of this other than the sdram? Any tests I can run on the sdram to highlight this? Every write-verify test I have done has worked perfectly. I have a feeling the sdram is fine, and either relocate's flash copy was to the wrong destination, or the jump is going to the wrong place. thanks for the help Scott