[U-Boot] strange flash access problem with uboot

Ellwood Nonnemacher woodmeister50 at comcast.net
Sun Sep 14 19:36:22 CEST 2008


First, a the platform description is in order.  There are actually 2  
that have the same problem.
     1.  Embedded planet EP8245 eval board
     2.  My current target board which uses MPC8241 w/64 meg sdram and  
and 2 Spansion S29GL128P
          with "all" memory configured 32 bit wide.

The problem is that on either platform, any writes what so ever to the  
flash, be it CS0,CS1 or CS2
space simply appears to be ignored.  This includes just trying to get  
the flash data such as
manf ID and device ID etc.  What's strange is that on the embedded  
planet board there there are some
LEDs that you can write to that reside in CS2 that can be turned on  
and off and when code
is inserted into uboot to do this it works(LEDs go on and off).  Also,  
on my target board, I have an LED
in CS1 space and I can do the same thing.

I should note that to get uboot to come up, I manually stuffed a flash  
info structure during the flash init.

So, I inserted the following at the beginning of my flash init:

unsigned long DevID2;
unsigned long *FlashIDBase = (unsigned long*)BOOT_BASE;

//find our flash size by ID
FlashIDBase[CMD_ADDR1] = (unsigned long)AMD_CMD_UNLOCK_START;
FlashIDBase[CMD_ADDR2] = (unsigned long)AMD_CMD_UNLOCK_ACK;
FlashIDBase[CMD_ADDR1] = (unsigned long)FLASH_CMD_READ_CFI_DATA;
DevID2 = FlashIDBase[FLASH_OFFSET_DEVICE_ID2];
//restore flash to normal operation
FlashIDBase[0] = (unsigned long)AMD_CMD_RESET;
	
printf("device ID read was %x\n",DevID2);

with the following defs:
#define BOOT_BASE 0xFFC00000
#define CMD_ADDR1 0x00000555
#define CMD_ADDR2 0x000002AA

#define FLASH_CMD_READ_CFI_DATA	 0x00900090
#define AMD_CMD_UNLOCK_START   0x00AA00AA
#define AMD_CMD_UNLOCK_ACK   0x00550055
#define AMD_CMD_RESET   0x00F000F0

What I end up getting back is whatever data was stored in location  
FlashIDBase[FLASH_OFFSET_DEVICE_ID2].

In addition from within uboot, if I try to erase a sector of flash  
that has some real data in it, I get a timeout error.  If I
try to do a cp command, it appears to execute,i.e. no errors or  
protected sector messages, but when
I look at the memory that should have been changed, nothing has  
happened.

Next, a built a stand alone program that was built using the "Hello  
World" i the examples as
a template with proper links to the uboot build libs.  I start up the  
board with uboot running and at
the command prompt do a loads and load the standalone program and run  
it and it returns with the proper
value for the device ID.  In addition, using this example, I have  
written a complete standalone program that will
erase the uboot area of the flash and will write a new uboot into it  
all of which works perfectly.  I can also
use it to alter or erase data anywhere in flash space.

My stand alone program does not do any manipulation of any of the  
configuration registers (unless the
uboot start_app function does it without my knowledge, although the  
code doesn't appear to).

So, what I have been pulling my hair out over is why are uboot writes  
to flash ignored, while a
standalone program launched from uboot which does nothing to change  
configuration of the hardware
does work?  Why does uboot itself not perform any flash functions that  
require writes?




More information about the U-Boot mailing list