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?