Sorry for asking a non-beagleboard question but I am at my wits end with
a nand issue on a Omap3530 board. The board I am using is a Logic
Omap3530 SOM.
If I run u-boot version 2009-8 I get a write protect error. However if
I run and older u-boot-1.1.4 version I have no problems with the NAND
flash.
I have verified that the gpmc_nwp is set correctly (1) in the
gpmc_config (6e000050 bit 4). I also verified that indeed the pin is
high in both u-boot versions.
I have poured over the specs for the Micro nand/dram part and haven't
found anything wrong.
I loaded a Beagleboard configured version of the u-boot 2009-8 (faked
the dev id) and it exhibited the same issue.
From looking at the specs it appears that U-boot identifies the nand
correctly on startup.
NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit)
If anyone has any ideas or suggestions they would be most appreciated.
I don't want to lose any more hair (or sleep).
Ben Anderson
Infinetix
When you say that you verified the pin being high, is that an
electrical verification?
If not, perhaps you should check into the pinmux being set
appropriately for that pin
Jerry
Are you using the LOCK signal on the Micron NAND flash? If so you would need to implement
int NAND_BlockLockStatus(unsigned int offsetAddress, u16 *usReadStatus)
and
int NAND_BlockUnlock(unsigned int offsetAddressLow, unsigned int offsetAddressHigh)
Regards,
Brad Badke
Hemisphere GPS
8444 N 90th St #130
Scottsdale, AZ 85258
Direct: 480-348-6323
Fax: 480-348-6370
bbadke@hemispheregps.com
www.hemispheregps.com
Jerry,
Yes I electrically verified. I also verified that the mux is set to
drive the pin high as well.
Ben Anderson
Infinetix
Brad,
It does appear the the LOCK signal is used and is connected to a gpio.
I have verified that this gpio is the same (high) on both version of
u-boot. I have changed the pin to be low on startup just for fun but I
still get the write-protect errors.
I am also assuming that the nand_lock() and nand_get_lock_status() from
the drivers/mtd/nand/nand_utils.c work. These are the functions that my
board is using currently.
It isn't clear to me yet the block locking and write-protect are
similar. As far as I can tell the check for write-protect is separate
functionality then block-lock/block-unlock. The block-unlock code even
checks for write-protect before starting to unlock. I even tried
removing this check to see if the unlock would work but was not
successful.
Thanks for the help I sure am stuck on this issue.
Ben Anderson
The following quote is from a Micron Data sheet.
"When LOCK is HIGH during power-up, the BLOCK LOCK function is enabled.
To disable the BLOCK LOCK, connect LOCK to Vss during power-up, or leave
it disconnected (internal pulldown)."
LOCK and Write Protect are not the same thing. Whether or not
nand_lock() or nand_get_lock_status() work I do not know since I do not
use u-boot.
If you determine they don't work you can try the following. It is a
combination of stuff I got from x-loader and Micron and my own stuff. If
I did not send you something you need and you can't easily create it
yourself just ask.
My board leaves the lock pin unconnected so I can not verify that my
lock and unlock functions work either.
/*
I finally found out what was was wrong and figured I would share it with
the group. It turns out that the older u-boot-1.1.4 would assume the
nand flash was locked and unlocks the whole range. This was done during
initialization. However u-boot-2009-8 didn't make this assumptions.
The problem was when you erased/wrote to a locked block the micron nand
would then put the WP bit in the status register to 0 (write protect
bit). This is consistent with the documentation for the part. However
u-boot checks this bit and assumes that it means the flash is write
protected. From then on you are in a chicken and egg problem. Worse
then that I haven't seen a way to "clear" the WP pin without a reset of
the nand. As far as I can tell u-boot has know way of handling this.
I wonder if this is an issue with the Beagleboard as well. I think if
one:
1. locked all of the blocks
2. saved the u-boot env
There then would be no way to erase/write to the nand because one would
get a wp error first. I am making some assumptions. Not sure what the
Beagleboard does with the LOCK pin. It also assumes that the
Beagleboard use the same type of Nand. The version of u-boot that most
people use might also have this fixed (and or unlocks the nand during
init).
Ben Anderson
Infinetix
Pretty sure beagle board leaves the LOCK unconnected. This is fine
because the Micron NAND has an internal pull down resistor.
Regards,
Brad Badke
Hemisphere GPS
8444 N 90th St #130
Scottsdale, AZ 85258
Direct: 480-348-6323
Fax: 480-348-6370
bbadke@hemispheregps.com
www.hemispheregps.com