[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