Factory Reset writes wrong environment

[jluebbe@…]

When u-boot resets the environment (by detecting a wrong checksum or using
'factory reset') usb-serial stops working and the partition names are lost.

We should use the environment from the devirginator as the hardcoded u-boot
default environment.

[cm@…]

I agree that the full menu should be default. I have a bad u-boot version
(august 8 I think) and get hit with this every time I flash a new kernel. What
happens is that part of the kernel always overwrites /dev/mtdblock1

The way around it for me, since I don't have a debug board, is to boot with
"Factory Reset" (the Boot option never works) and then scp a working mtdblock1
to the neo, ssh in and do a "dd if=working_mtdblock1 of=/dev/mtdblock1".

After that I get the full boot menu and can use the USB-serial. I still can't
boot without selecting Factory Reset though. (More here:
​http://wiki.openmoko.org/wiki/Bricked)

I will try a newer u-boot. Just a bit afraid of bricking it totally.

[laforge@…]

regarding the original bug report: The problem is that the partition table _can
not_ be correct in a compile-time default. The partition table is per-unit
specific and depends on the factory-default bad block locations.

That problem cannot be resolved no matter what you put in the compile-time
default environment.

I would accept a patch that includes the default bootmenu and the
'stdin/stdout/stderr = usbtty' part into the gta01 u-boot config. Please provide
such a (tested) patch.

claes: what you describe sounds like a seriously corrupted partition table. You
seem to have erased the environment once and never properly recreated the
partition table (dypart; dynenv set u-boot_env; saveenv).

[cm@…]

I'm not sure how I can recreate the partition table. I can't get the usb serial
console up since I can no longer get the boot menu back. To dd a known working
mtdblock1 to dev/mntblock1 doesn't seem to work any more.

Can I fix this without a debug board or will I have to send it to someone who
has one?

[laforge@…]

well, straight forward there is no method without debug board.

In reality, you can try to upload (neo -> pc) the environment partition
(u-boot_env or numerically '2') using DFU. Then you can edit it on the host
(using the tools used/contained in devirginator) to add the
stdin/stderr/stdout=usbtty lines to the environment. Then download (PC->neo)
the environment into the partition again. Then power-off, and power-up while
having the AUX key pressed. At this point you should get usbtty on ttyACM0 again.

[cesarb@…]

Add hardcoded USB/serial console and poweroff options to the boot menu

[cesarb@…]

Alternate version of the patch, also sets the usbtty environment variable in case it's incorrect

[laforge@…]

So, I've now made one minor change to u-boot: Set the usbtty as default console
in the compiled-in environment
(​http://svnweb.openmoko.org/trunk/src/target/u-boot/patches/uboot-neo1973_defaultconsole_usbtty.patch?rev=3164&view=markup),
since I think this already helps quite a bit. This means if the environment
pointer (dynenv set) is not set, or set incorrectly, or the environment
partition empty or corrupted, it will fall back on usbtty.

If the environent was artificially altered to remove the menu options, or
otherwise break usbtty, then you always have the option of pressing the AUX key
and get into DFU capable mode. From there you can either erase the u-boot_env
partition, or write something useful to it - both ways making usbtty acceessible
again.

In theory I agree that the usbtty/serial options should be compiled in.
But making the menu-items compiled-in is a bit ugly, since all the existing
users, with existing environment would suddently see those options twice. So
I'm a bit reluctant to change that, unless we have a reliable and proven/tested
"environmental cleaner" script utilizing dfu-util and envedit (from
devirginator), as outlined in
​http://lists.openmoko.org/pipermail/device-owners/2007-October/000566.html