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

Latest revision as of 13:31, 1 April 2016

Q3 2011 UPDATE

As of August 29th 2011, newly patched version of u-boot for Verdex XL6P has been created; this version works around the Block Lock Protection silicon errata while still using 'buffered write' mode hence it doesn't exhibit the same slowdowns. The discussion below, excepting the notes about slow write speed, still applies. The code has been pushed to the git source link and the binary file is available here.

MD5sum: c6e9042f090818534646f6779277f583

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 showed errors when written from u-boot.

See Gumstix PKI 2010-3 posted here.

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

Gumstix Engineering developed a software fix so that the Verdex Pro XL6P COMs built with this NOR flash memory can become functional.

All verdex pro XL6P COMs shipped by Gumstix have this U-boot flashing fix, at this time.

Note that a customer planning to reflash u-boot on the NOR flash of a Verdex Pro XL6P COM with a different root file system must apply this flashing fix.

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.