RE:[U-Boot-Users] U-Boot Not Loading Successfully

Date: Wed, 31 Dec 2003 13:21:29 -0800 (PST) From: Jeff Stevens jsteve17@yahoo.com To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] U-Boot Not Loading Successfully
I am porting U-Boot over to a new product and am having some difficulty getting U-Boot to load successfully. I have placed our board on a logic analyzer and found (based on System.map) that U-Boot seems to crash in cpu/mpc8xx/cpu_init.c in function cpu_init_f at lines:
memctl->memc_br0 = CFG_BR0_PRELIM; memctl->memc_or0 = CFG_OR0_PRELIM;
Here is my board configuration: CPU: MPC855T FLASH: AMD AM29LV040B (512kB 8-bit on CS0) SDRAM: Micron MT48LC4M32 (16MB 32-bit on CS2) NVRAM: Simtek STK14C88 (32kB 8-bit on CS4)
The board is set to have the IMMR come up at 0xFF000000 (on hard reset), and that is what I have CFG_IMMR set to in my board configuration file. Could this be a problem with the placement of the IMMR. I previously had the IMMR at 0x00000000 on hard reset and then moved it to 0xFA200000 with CFG_IMMR, which had the same effect. Or, could this be an issue with my BR0 and OR0 settings?
--------------------------------------------------- Both settings on CFG_IMMR are OK.Only you set CFG_IMMR on 0xFFF80000 would have some problems.I guess your trouble don't relate with CFG_IMMR settings. ---------------------------------------------------
I read something in that file before those two lines above, which talked about CFG_OR0_REMAP, but didn't quite understand it. Should I be using this?
Here are my BRx, ORx settings: #define FLASH_BASE_PRELIM 0xFFF80000 #define CFG_PRELIM_OR_AM 0xFFFF0000 #define CFG_OR_TIMING_FLASH (OR_CSNT_SAM | OR_ACS_DIV4 | OR_BI | OR_SCY_3_CLK | OR_TRLX | OR_EHTR)
----------------------------------------------- Pls tell us the FLASH SPEED or we cannot check the OR0 configuration for you.Meanwhile,what's your reset vector prefix?0x0000 or 0xfff0? ------------------------------------------------
#define CFG_OR0_PRELIM (CFG_PRELIM_OR_AM | CFG_OR_TIMING_FLASH) #define CFG_BR0_PRELIM ((FLASH_BASE_PRELIM & BR_BA_MSK) | (BR_PS_8 & BR_PS_MSK) | BR_V)
#define SDRAM_BASE_PRELIM 0x00000000 #define SDRAM_MAX_SIZE 0x01000000
#define CFG_OR_TIMING_SDRAM (OR_G5LA | OR_G5LS) #define CFG_OR2_PRELIM (CFG_PRELIM_OR_AM | CFG_OR_TIMING_SDRAM ) #define CFG_BR2_PRELIM ((SDRAM_BASE_PRELIM & BR_BA_MSK) | BR_MS_UPMA | BR_V )
#define CFG_NVRAM_BASE 0xFA000000 #define CFG_OR4_PRELIM (CFG_PRELIM_OR_AM | CFG_OR_TIMING_FLASH) #define CFG_BR4_PRELIM ((CFG_NVRAM_BASE & BR_BA_MSK) | (BR_PS_8 & BR_PS_MSK) | BR_V | OR_EHTR)
I would appreciate anyones input, since I'm not too familiar with the U-Boot beyond the board specific files.
Thanks in advance!
------------------------------------------
Best regards,
SAM
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dear Sam Song,
please stick with the netiquette and use standard '> ' marks for quotation. DOn't quote text not relevant to your answer.
In message 20040101160217.1988.qmail@web15003.mail.bjs.yahoo.com you wrote:
Pls tell us the FLASH SPEED or we cannot check the OR0 configuration for you.Meanwhile,what's your reset
This has nothing to do with that sort of the problem. The documentation for the problem and the solution is right there in the source file.
Best regards, and a Happy New Year!
Wolfgang Denk

I am trying different OR0 register settings to try to mess with the timing. I found out that the CPU always ends on the same instruction and then reads the first four bytes of the flash (0x27, 0x05, 0x19, 0x56), which are the first four bytes of u-boot.bin, and then stops. Here is the actual C and assembly code that it fails on:
150:cpu_init.c **** defined(CONFIG_RAPTOR) || \ 151:cpu_init.c **** (defined(CONFIG_MPC860T) && defined(CONFIG_FADS)) 152:cpu_init.c **** 153:cpu_init.c **** memctl->memc_br0 = CFG_BR0_PRELIM; 330 .LM19: 331 0058 3C00FFF0 lis 0,0xfff0 333 .LM20: 334 005c 556B052A rlwinm 11,11,0,20,21 336 .LM21: 337 0060 616B0001 ori 11,11,1 339 .LM22: 340 0064 91630100 stw 11,256(3) 342 .LM23: 343 0068 60000401 ori 0,0,1025 154:cpu_init.c **** #endif 155:cpu_init.c **** 156:cpu_init.c **** #if defined(CFG_OR0_REMAP) 157:cpu_init.c **** memctl->memc_or0 = CFG_OR0_REMAP; 345 .LM24: 346 006c 3D40FFF8 lis 10,0xfff8 348 .LM25: 349 0070 90030100 stw 0,256(3) 351 .LM26: 352 0074 39230100 addi 9,3,256 354 .LM27: 355 0078 614A0FF6 ori 10,10,4086 356 007c 91490004 stw 10,4(9) 166:cpu_init.c **** /* now restrict to preliminary range */ 167:cpu_init.c **** memctl->memc_br0 = CFG_BR0_PRELIM; 358 .LM28: 359 0080 90030100 stw 0,256(3) 168:cpu_init.c **** memctl->memc_or0 = CFG_OR0_PRELIM; 361 .LM29: 362 0084 91490004 stw 10,4(9)
Instruction 0074 at line 352 is always the last instruction that it runs before reading the first four bytes from the flash. So it looks like the problem occurs as soon as it tries to write to OR0.
Thanks again for everyones help!
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

Ok, sorry for posting so much, but I was wrong before. I just found out that it really has nothing to do with the instruction, but more with the address 0x000024DF (Offset from the base of flash). It seems that is the last instruction that is run, no matter what instruction is there. To prove this, I put a bunch of in line assembly eieio instructions before that address, so that one of them fell on 0x24DF (the fourth eieio did), and sure enough after running the eieio at address 0x24DF, the processor read the first four bytes of flash and then stopped. Does this have something to do with u-boot.lds? I have just copied one from the FADS board since it is similar to ours. If that file needs altered for my board specific stuff, is there a good reference somewhere on how to do it? Again, sorry for all the posts, but I just wanted to give as much information and updates as I could.
Thanks again, Jeff Stevens
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

I have tried many settings for the BRx and ORx registers, and no matter what I do, my board seems to always crash inside cpu_init_f. It is now always crashing at address 0x24EF. I am now wondering if this is an issue with u-boot.lds. Do I need to alter this file in any way. As of right now, I stole the u-boot.lds file from the fads folder, because it also supports the same flash device I'm using (AM29LV040). If I do need to alter this file, is there any howto for this, since I don't understand the file one bit. Sorry if these are easy questions, but this is my first embedded project.
Thanks, Jeff Stevens
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

In message 20040105180625.65298.qmail@web41415.mail.yahoo.com you wrote:
I have tried many settings for the BRx and ORx registers, and no matter what I do, my board seems to always crash inside cpu_init_f. It is now always crashing at address 0x24EF. I am now wondering if this is an issue with u-boot.lds. Do I need to alter
It is not.
Wolfgang Denk
participants (3)
-
Jeff Stevens
-
SAM SONG
-
Wolfgang Denk