Difference between revisions of "VerdexPro U-Boot Flashing Fix"

Revision as of 10:08, 27 January 2011

PKI 2010-3 (Product Known Issue)

Gumstix created Known Issue PKI 2010-3 in September 2010 because the Numonyx NOR flash memory that Gumstix installed on a small quantity of Verdex Pro XL6P COMs in August 2010, as well as the inventory of Numonyx NOR flash memory that Gumstix has in stock for future builds, show errors when written from u-boot.

See Gumstix PKI 2010-3 posted here.

Description

Since the lead time on this Numonyx NOR flash memory has shot out to 6 months, Gumstix could not source replacement memory modules in a timely manner from Numonyx in order to provide a rapid hardware fix.

So, Gumstix Engineering has endeavoured to develop a software fix so that the recently shipped Verdex Pro XL6P COMs and the current inventory of NOR flash memory can become functional.

Symptoms

This faulty Numonyx NOR flash memory report errors when written from u-boot; this is due to an error in the Numonyx NOR flash memory itself.

Usually, users discover this problem when trying to replace the file system image. U-boot might report any or all of these message after a copy to flash command:

GUM> cp.b a2000000 40000 ${filesize}
Flash buffer write error at address 40000
Command Sequence Error.
Block locked.
Vpp Low Error.

Affected Parts

Verdex Pro XL6P COMs of build R2635 with Numonyx NOR flash memory (U$2) marked 256PF30TF as opposed to 256PF30T likely have this fault. Note, not all memory pages in the flash memory are necessarily affected. More details about affected parts can be found here.

While any software that modifies the block protection status of the Numonyx NOR flash memory is potentially susceptible to this hardware bug, we have only noticed the issue in u-boot.

Resolution

By following the information below, a user can install a new version of u-boot to the NOR Flash memory.

Please note that this fix slows down writes to flash within u-boot by a factor of 20 Note that this fix does NOT affect write performance in Linux.

Until further testing and customer feedback is received, this resolution is NOT considered to be a final answer to PKI 2010-3 by Gumstix.

Fix Details

The manufacturer notes that the block protection status is incorrectly set when software tries to unlock a flash block. By changing the block locking command sequence as shown in this fix, the silicon behaves correctly. In addition, it is necessary to disable the buffered write mode; this slows down writes to flash within u-boot by a factor of 20. This patch applies against Verdex Pro u-boot revision 1.2.0.

As an FYI, unless you need to change the software running in flash memory, it is not necessary to apply this fix---it only affects re-flashing code in u-boot.

Usage

Caveats:

• Installing a new version of u-boot to your Flash memory is risky and, if not done correctly, can result in your Verdex Pro XL6P COM being bricked. Proceed with caution.
• This fix will slow down writes to flash within u-boot by a factor of 20

Download a patched version of u-boot. Most users will want the standard u-boot; for those using the git repository or having a kernel larger than 1MB might want the large kernel version (see for more details).

Follow the instructions here to get a serial connection to your Verdex Pro XL6P COM.

Type these commands to load the new u-boot to RAM and jump to it. This new u-boot will allow you to write to NAND:

GUM> loadb a2000000
CTRL+\, c
C-Kermit> send u-boot.bin (this should be the file you downloaded)
...tranfer for about 20 seconds...
C-Kermit> connect
GUM> go a2000000
U-Boot 1.2.0 (Oct  6 2010 - 00:42:27) - PXA270@600 MHz - 

*** Welcome to Gumstix ***

DRAM:  128 MB
Flash: 32 MB
Using default environment

Hit a key to interrupt u-boot and then proceed by testing that your new u-boot is working correctly by writing to a non-boot partitions. For example,

GUM> protect off 1:2-3
Un-Protect Flash Sectors 2-3 in Bank # 1
.. done
GUM> erase 1:2-3
Erase Flash Sectors 2-3 in Bank # 1 
.. done
GUM> loadb a2000000
CTRL+\, c
C-Kermit> send u-boot.bin (this should be the file you downloaded)
...tranfer for about 20 seconds...
C-Kermit> connect
GUM> cp.b a2000000 40000 ${filesize}
Copy to Flash... done

If everything went smoothly in the previous step, the new uboot is working. Let's carefully reflash the boot partition with the same steps but for sector 1:0-1 (0x0) rather than sector 1:2-3 (0x00040000):

GUM> protect off 1:0-1
Un-Protect Flash Sectors 0-1 in Bank # 1
.. done
GUM> erase 1:0-1
Erase Flash Sectors 0-1 in Bank # 1 
.. done
GUM> loadb a2000000
CTRL+\, c
C-Kermit> send u-boot.bin (this should be the file you downloaded)
...tranfer for about 20 seconds...
C-Kermit> connect
GUM> cp.b a2000000 0 ${filesize}
Copy to Flash... done
GUM> reset

The Verdex Pro XL6P COM should now boot into the new u-boot and the protect, erase, and cp.b commands should behave correctly albeit slowly.

Source

A git repository containing the modified Verdex u-boot source code is available on GitHub. You would fetch and compile u-boot using these commands:

$ git clone git://github.com/ashcharles/verdex-uboot.git
$ cd verdex-uboot

(assuming you are using the OE cross-compiler. Change the path as appropriate. Note: some gcc-4.5 arm cross-compilers (gnuarm, linaro and Android in my case) fail with this bug https://bugs.launchpad.net/ubuntu/+source/gcc-4.5-armel-cross/+bug/662887)

$ export PATH=/home/openembedded/tmp/sysroots/i686-linux/usr/armv5te/bin/:$PATH
$ export ARCH=arm
$ export CROSS_COMPILE=arm-angstrom-linux-gnueabi-
$ make gumstix_config
$ make -j8

You should now have u-boot.bin available.

Notes

• Please contact ash (at) gumstix.com in case of problems with this procedure.