GoFlex "bad flash" or "Too few good blocks..." = Red Herring?

It seems odd to me that so many of us are seeing the annoying
Too few good blocks within range
error... I find it interesting that flashing within U-Boot is perfectly/completely successful for me on the same machine that throws up this error.

Is it possible that there is some other problem, something wrong (in kernel) with a setting for a chip, or some bit value is set incorrectly somewhere else (maybe in kwbimage.cfg), and what we are seeing is actually a sporadic symptom of some other problem?

I'm game to consider and entertain any plausible idea... it just seems like a massive QC problem, otherwise.


!

=====================================================

• davy's Github Repo's rescue-dg

I have been beginning to suspect the same thing.

I found this thread (about a different device) to be an interesting read:

http://lists.infradead.org/pipermail/linux-mtd/2009-May/025712.html

Perhaps something similar is going on here. Would a significantly older kernel help us?

I'm wondering if it is a question of maker of the NAND.

Baffie, what does dmesg tell you that your NAND is, in terms of a brand or manufacturer?

==============

This looks like what we see, exactly.
http://wiki.beyondlogic.org/index.php/Seagate_FreeAgent_GoFlex_Home_MTDTests_Toshiba_TC58NVG1S3ETA00

Also
http://www.mail-archive.com/linuxkernelnewbies@googlegroups.com/msg00559.html

=====================================================

• davy's Github Repo's rescue-dg

Edited 2 time(s). Last edit at 03/27/2012 11:30PM by davygravy.

davygravy Wrote:
-------------------------------------------------------
> Baffie, what does dmesg tell you that your NAND
> is, in terms of a brand or manufacturer?
>
> ==============
>
> This looks like what we see, exactly.
> http://wiki.beyondlogic.org/index.php/Seagate_Free
> Agent_GoFlex_Home_MTDTests_Toshiba_TC58NVG1S3ETA00

Mine is exactly the same.

Is it important that the output of your mtd tests says the page size is 2048, whereas the data sheet claims it is 2112?

I notice it says "2048+64 bytes". I'm not very familiar w/ this sort of memory spec thing... I'm wondering if the 64 bytes is used for something else.

Anybody? (I _am_ interested in solving this, but I'm mid-stride in getting GoFlex Net supported in U-Boot mainline right now. ... maybe someone stumbling over this discussion will chime in w/ the definitive answer...)

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/28/2012 03:08PM by davygravy.

I think it's what the mtd tests refer to as 'OOB', which appears to be the correct size. So it's probably not important. :)

Last time I flashed something, I got the errors.
Being obstinate, I just repeated it until it finally stopped giving me errors.
I think the fourth time it finally reported success.

Of course I left myself with an unusable plug that only boots to the usb stick, but can't make a network connection.

My serial-usb cable arrived, but it puts out 4.2 volts... will it fry the board?

TJ

YES!

The issue appears to be caused by the driver.

Long story short: given that uBoot was working fine for most people (at least as far as booting), I suspected there must be some difference between uBoot and the kernel in the way they interact with the NAND.

So I started reading the relevant bits of code in both source trees and found little difference, until I saw that the chip_delay for the NAND was set to 40 in uBoot and to 25 in Linux.

I changed the value in Linux (i.e., the Arch Linux patch) to 40:

kirkwood_nand_init(ARRAY_AND_SIZE(goflexnet_nand_parts), 40);

And lo and behold! No errors at all in dmesg, and I am able to use fw_printenv without complaints about eraseblocks.

Note that, because I was unable to manipulate the uBoot environment previously, I forced Linux to use the goflexnet architecture by swapping the device ID with that of Sheevaplug's.

Boot note: the mtd layout seems to be different in the driver than in the kernel command line. Any idea why?



Edited 1 time(s). Last edit at 03/30/2012 08:13PM by baafie.

baafie Wrote:
-------------------------------------------------------
> YES!
Yes!!!!!!!!!! Indeed! You found what no one else had been able to see...
> The issue appears to be caused by the driver.
>
> Long story short: given that uBoot was working
> fine for most people (at least as far as booting),
> I suspected there must be some difference between
> uBoot and the kernel in the way they interact with
> the NAND.
>
> So I started reading the relevant bits of code in
> both source trees and found little difference,
> until I saw that the chip_delay for the NAND was
> set to 40 in uBoot and to 25 in Linux.
>
> I changed the value in Linux (i.e., the Arch Linux
> patch) to 40:
>

> kirkwood_nand_init(ARRAY_AND_SIZE(goflexnet_nand_p
> arts), 40);
>

Could you give a pointer to that patch? I don't know at all which one you are speaking of, and I'd really like to fix mine, too!
> And lo and behold! No errors at all in dmesg, and
> I am able to use fw_printenv without complaints
> about eraseblocks.
>
> Note that, because I was unable to manipulate the
> uBoot environment previously, I forced Linux to
> use the goflexnet architecture by swapping the
> device ID with that of Sheevaplug's.
>
> Boot note: the mtd layout seems to be different in
> the driver than in the kernel command line. Any
> idea why?

No, sorry, no idea.

=====================================================

• davy's Github Repo's rescue-dg

davygravy Wrote:
-------------------------------------------------------
> Yes!!!!!!!!!! Indeed! You found what no one else
> had been able to see...

Well, let's first see if it solves the problem for you too.

> Could you give a pointer to that patch? I don't
> know at all which one you are speaking of, and I'd
> really like to fix mine, too!

It is my understanding that Arch Linux maintains a patch for the GoFlex machines (mostly doing LED configuration). Shyd provided the same patch, but applied to Linux-3.1, which I used.

So here's what you do:

1. Download the 3.1.10 stock kernel.
2. Apply the Shyd patch and (probably optionally) use Shyd's .config.
3. Apply my patch (attached to this post).
4. Build, install and reboot your GoFlex.
5. Make sure the kernel claims to be running a GoFlex early in the boot process, otherwise uBoot is providing the wrong arcNumber.

Thank you, baafie! Great catch. I'm mid-stride in a u-boot problem, but eventually I'll roll a kernel 3.3 kernel .deb package for my boxes, and I'll make sure to apply your patch.

=====================================================

• davy's Github Repo's rescue-dg

Actually, I got a little wild with being able to write NAND myself, and botched the system as a result. Now, my kernel doesn't get further than

[   23.246858] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

:)

Oh, by the way: I heard of people being unable to boot a 3.2 kernel, so I'm curious whether 3.3 works.



Edited 1 time(s). Last edit at 03/31/2012 10:09AM by baafie.

I've been booting 3.3-rcN for a few months now... it boots fine if you have a u-boot that can deal w/ the new kernel L2-cache configuration, or you can configure the kernel differently and boot w/ the older u-boots.

=====================================================

• davy's Github Repo's rescue-dg

Thanks ALL! This is a big help! Could someone share a patched kernel for goflex net? I tried davygravy's 3.3.2, but it doesn't boot. I couldn't do anything within uboot because I am still waiting for the right wires to arrive to jtag. So, I am still using jeff's uboot and probably the dockstar archnumber.


Bo

(don't buy a JTAG cable, you only need serial access)

do you have netconsole capability?

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 04/23/2012 04:23PM by davygravy.

I suppose, this problem effects a lot of goflex net users. I'm trying to setup a goflex net since two days. After unboxing my device I managed to get ssh access (completely different from dockstar and no howto here :-/ ) and ran jeff's script. This failed at make fs on usb stick. I checked the script and saw that uboot was written to nand before so I decided to create the bootable usb stick on my dockstar (sda > sdb, uboot stuff removed) and boot this on goflex net. This failed also. Finally debootstrapping an a ubuntu VM (http://forum.doozan.com/read.php?2,5986) worked and I was able to boot into debian with a usb stick attached. But no sata support! I changed to kernel to 3.1.10 http://dev.shyd.de/2012/01/kernel-3-1-10-ready-to-use/ . Also no success!
With both kernel versions, I tried jeff's uboot script to rewrite the boot loader but this failed too. Four things attracted my attention:
1. jeff's boot script fails with: "Unknown uBoot detected on mtd0: 38eb11b49b828dc070270680a8a37845 … VERIFICATION FAILED! … Make a backup of /tmp/uboot-mtd0-dump someplace safe and then re-run this installer". I googled the md5 sum and it seems that I'm not the only one with this problem. (inside /tmp/uboot-mtd0-dump > only "FFFFFFFFFFFFFFFF……FFFF" )
2. dmesg output (on goflex net)
[ 1.090630] Bad eraseblock 0 at 0x000000000000
to
[ 10.756931] Bad eraseblock 2047 at 0x00000ffe0000
3. "badblocks -nvs /dev/mtdblock0" output on goflex net > "Pass completed, 1024 bad blocks found." but my dockstar shows the same output but here everything works as expected.
4. AND last but not least (how I found this thread) "fw_printenv" ended with "Too few good blocks within range" (I wanted to check the MTD partitions).

Im not familiar with all this embedded Linux stuff but for me, this all seems to be the result of the issue discussed in this thread (chip_delay).

Maybe someone could share his compiled kernel with us?

Check my sig: 2nd link

=====================================================

• davy's Github Repo's rescue-dg

correct me if Im wrong, but for this kernel version I need your new uboot version. to upgrade the uboot I need either a UART or a netconsole. to enable netconsole, fw_setenv musst work. as mentioned, "fw_printenv" produces a "Too few good blocks within range". same with fw_setenv.
any idea?

Absolutely. I understand now.

I'm going to need to check on something.... but... is it at least booting?

If so, I think I have a special kernel roll that I made just after I got my GoFlexHome. I had hacked it to put on Debian, but then the same thing happened to me. The bad block problem effectively locked me out of changing my arcNumber, or turning on my netconsole. So I was really stuck.

My solution was to roll a kernel that had the default arcNumber's udelay (in the kernel) set to that of the newer GFN/H kernels, so that the NAND was properly accessible.

Do I understand that your box does boot now.?

Do you remember if you ever changed it arcNumber?

Ping back if you are interested and I can let you know where to look for the link to the kernel image.

=====================================================

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 06/01/2012 09:52PM by davygravy.

first of all - sorry for delay and thnx for your quick replay.

it seems to be the same problem. I've never changed the arc number. the goflex net is booting, but I cannot access NAND :-/

your kernel would be my last chance

Proceed w/ caution... you can try this... https://www.dropbox.com/sh/nwt2kbvetvgvroo/3ldiPoG5iq/Kirkwood/kernel/specialGFN-H_rescue_BadBlocksWorkAround_kernel_package

but if it isn't 100% clear what the commands should be, just wait and I can walk you through it.

=====================================================

• davy's Github Repo's rescue-dg

{Edited for correct arcNumber.}

@davygravy Thank you so much. Worked like a champ on my GoFlex Home. Here's what I did (working from memory):

• Ran through the latest install procedure as described at Unlocking your Dockstar, GoFlex, or Pogoplug. This means I have the latest u-boot that supports the 3.3.2 kernel. If your u-boot is older, don't follow this procedure!
• Sure enough fw_printenv was displaying the infamous Too few good blocks within range error message. Bummer. But davygravy to the rescue!
• Clicked davygravy's link above and download the .deb file to my workstation.
• Transfered the .deb file to the root folder on my GoFlex Home using scp.
• Entered following commands on the GoFlex as root:

cd /
cp -r boot boot-backup
dpkg -i linux-image-3.3.2-sheevaesata40msnandfixforgoflexnet.deb
cd /boot
mkimage -A arm -O linux -T kernel  -C none -a 0x00008000 -e 0x00008000 -n Linux-3.3.2 -d vmlinux-3.3.2-sheevaesata40msnandfixforgoflexnet uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.3.2 -d initrd.img-3.3.2-sheevaesata40msnandfixforgoflexnet uInitrd
reboot

Upon successful reboot, ssh back into the GoFlex Home and fw_printenv/fw_setenv now work. Checked that it in fact booted davygravy's patch kernel

uname -a

Set up netconsole as described here

Set the arcNumber. In my case, 3338 for a GoFlex Home. Use 3089 for a GoFlex Net.

fw_setenv arcNumber 3338

Set the mac address. Get the address from the label on the underside of your GoFlex. Do this carefully, because once set, fw_setenv won't let you change it. (You'll have to interrupt boot and use u-boot setenv/saveenv commands instead.)

fw_setenv ethaddr XX:XX:XX:XX:XX:XX

Rebooted and verified all is still well. Now installed davygravy's latest kernel. Followed the link Linux 3.3.2 for Kirkwood Debian Package in his signature. The procedure is similar to how we installed his patch kernel.



Edited 3 time(s). Last edit at 06/10/2012 12:47PM by PhantomsDad.

Super! I'm glad it worked for you.

...and thank you for documenting the procedure... that will surely save others from some aggravation.

=====================================================

• davy's Github Repo's rescue-dg

i dont get it :-/

i build a bootable usb using this guide but my GFN does not boot into debian. instead i found my box using nmap. after login with root:root this appears:

The authenticity of host '10.168.2.5 (10.168.2.5)' can't be established.
RSA key fingerprint is 63:bd:da:99:98:fd:df:36:c7:59:dc:dd:46:db:70:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.168.2.5' (RSA) to the list of known hosts.
root@10.168.2.5's password:
/etc/ubit/images:
/etc/ubit/ubimounts:
/etc/ubit/extramounts:

No valid U-Boot environment exists.
You need to reboot once to let U-Boot set its default environment
before the ethaddr setting can be updated, either directly or
with a cached value.

To cache a value, run:
ethaddr uu:vv:ww:xx:yy:zz
UBIT v0.6 by peaslaker 2010.11-00125-ga21bcca
ubit0-6:~# uname -a
Linux ubit0-6 2.6.37-ubit-01715-g1e5cda0 #1 Mon Feb 7 01:35:47 GMT 2011 armv5tel GNU/Linux
ubit0-6:~# fw_setenv arcNumber 3089
Too few good blocks within range
Error: environment not initialized
ubit0-6:~#

hmmm... now i (tryed to) installed the necessary kernal using:

from ubuntu x86 VM

mount devpts /media/debian/dev/pts -t devpts
mount -t proc proc /media/debian/proc
chroot /media/debian/
cd /
cp -r boot boot-backup
dpkg -i linux-image-3.3.2-sheevaesata40msnandfixforgoflexnet.deb
cd /boot
mkimage -A arm -O linux -T kernel  -C none -a 0x00008000 -e 0x00008000 -n Linux-3.3.2 -d vmlinux-3.3.2-sheevaesata40msnandfixforgoflexnet uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.3.2 -d initrd.img-3.3.2-sheevaesata40msnandfixforgoflexnet uInitrd

this time i cannot access the ubit0-6 console and the GFN keeps blinking.

any ideas?

maybe someone could tar.gz me his USB stick fs with the kernel davygravy build (sheevaesata40msnandfixforgoflexnet)

big thnx !!

I have a similar problem with a GoFlex Net

1. No rescue system, no netconsole.
2. Uses older uboot
3. Boots from the USB drive, but due to the error not able to change any environment settings.

@davygravy : Will your patched kernel linked above work with older uboots?

Is there any way without using a serial adapter?

Varkey, you could try to boot kernel 3.1 or earlier, if it's patched with the nand chip delay fix in this thread. My GF Net does not have this problem with 3.1.10 home build kernel. But I could build a 3.1.10 with the chip delay patch and see if it will work the same way and upload it.

^ Thanks. Finally I just opened it and used the serial adapter to flash the new uBoot and used davegravy's new kernel! :)