Ticket #765 (closed defect: community)

Opened 9 years ago

Last modified 8 years ago

Factory Reset writes wrong environment

Reported by: jluebbe@… Owned by: michael
Priority: high Milestone:
Component: u-boot Version: current svn head
Severity: normal Keywords:
Cc: buglog@…, cm@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

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.

Attachments

uboot-menu-recovery-options.patch (720 bytes) - added by cesarb@… 9 years ago.
Add hardcoded USB/serial console and poweroff options to the boot menu
uboot-menu-recovery-options-2.patch (743 bytes) - added by cesarb@… 9 years ago.
Alternate version of the patch, also sets the usbtty environment variable in case it's incorrect

Change History

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by cm@…

  • Cc cm@… added

comment:3 Changed 9 years ago by 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).

comment:4 Changed 9 years ago by 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?

comment:5 Changed 9 years ago by 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.

Changed 9 years ago by cesarb@…

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

Changed 9 years ago by cesarb@…

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

comment:6 Changed 9 years ago by laforge@…

  • Status changed from new to assigned

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

comment:7 Changed 9 years ago by willie_chen@…

  • Owner changed from laforge@… to michael@…
  • Status changed from assigned to new

comment:8 Changed 9 years ago by roh

  • Owner changed from michael@… to michael

comment:9 Changed 8 years ago by john_lee

  • Status changed from new to closed
  • HasPatchForReview unset
  • Resolution set to community
Note: See TracTickets for help on using tickets.