Difference between revisions of "VerdexPro U-Boot Flashing Fix"
Ashcharles (Talk | contribs) |
Searchworks (Talk | contribs) (update in Q1 2011) |
||
Line 1: | Line 1: | ||
== PKI 2010-3 (Product Known Issue) == | == 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 | + | 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 [http://www.gumstix.net/Hardware/cat/Known-issues/112.html#faq206 here]. | See Gumstix PKI 2010-3 posted [http://www.gumstix.net/Hardware/cat/Known-issues/112.html#faq206 here]. | ||
===Description=== | ===Description=== | ||
− | Since | + | Since Gumstix could not, and still cannot as of Q1 2011, source corrected memory modules from Numonyx NOR flash memory, all verdex pro XL6P COMs shipped by Gumstix in low and high volume orders must have this U-boot flashing fix until corrected memory modules can be sourced by Gumstix. |
− | + | Gumstix Engineering developed a software fix so that the Verdex Pro XL6P COMs built with this NOR flash memory can become functional. | |
Revision as of 11:21, 4 February 2011
Contents
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.
Description
Since Gumstix could not, and still cannot as of Q1 2011, source corrected memory modules from Numonyx NOR flash memory, all verdex pro XL6P COMs shipped by Gumstix in low and high volume orders must have this U-boot flashing fix until corrected memory modules can be sourced by Gumstix.
Gumstix Engineering developed a software fix so that the Verdex Pro XL6P COMs built with this 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).
Note | File | MD5 |
---|---|---|
Standard (katload 100000) | u-boot.bin | 8f7f905549cd3ba7f2e6a755395e7e16 |
Large Kernel (katload 160000) | u-boot.bin | 55e999c2bb21a5b963473f213c3911cc |
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.