[Everyone] U-Boot Testing on 03252008

[Werner Almesberger]

Allen Lin wrote:
> U-Boot Testing on 03252008

Thanks ! A few comments:

> Test Plan: http://wiki.openmoko.org/wiki/U-Boot_Test_Plan

The instructions for entering NOR can be a bit misleading. You have to
press and hold AUX before pressing POWER. Then release AUX, but keep
on holding POWER until the boot menu has been up for about 1-2 seconds.

(This is for the u-boot version you're using now. If you pick the one
with the improved vector handling, you can also release AUX later.)

For completeness, I'd also suggest to test the following two items:

- access u-boot through usbtty (ttyACM*) when starting u-boot from
  NAND (bring up the boot menu first)
- use DFU when u-boot is started from NOR

> 1. No respond from serial

That works fine for me. One gotcha:

% cu -l /dev/ttyUSB1

This may fail to open the correct device. E.g., if you connect to
ttyUSB1 and then disconnect and reconnect the debug board, it will
show up as a different ttyUSB, while the old one continues to exist.

I recommend using neocon:

% neocon /dev/ttyUSB{0,1,2}

This makes neocon try ttyUSB0, ttyUSB1, and ttyUSB2, and if one of
them gets disconnected, it will automatically switch over to the
next one. Note that you have to try to send data to make neocon
detect that a line got disconnected.

So the test sequence should be:

1) Tell u-boot to switch to serial.
2) Press [Enter] or similar in the window where neocon is running.
3) See if you get a response from u-boot.

Also, for test case #10, please use

% neocon -t 30 /dev/ttyACM{0,1,2}

The -t 30 makes sure that we don't send characters too quickly.
(u-boot's usbtty has some difficulties if it gets data sent too
quickly.)

neocon is in svn.openmoko.org/developers/werner/neocon/

> 2. There is no different after reset

This also works for me. (I guess you get to hear that a lot in QA ;-)

But perhaps you expect it to do something different from what it's
actually designed to do. What it does is that it resets the device,
i.e., like power cycling it. It does not affect any persistent
configuration.

So if you want to modify the environment or such, you have to enter
u-boot through the console and do that from there. (By the way, if
we consider this mode of operation important enough, we should also
include that in the tests. I think for almost all practical purposes,
DFU will be sufficient for recovering a system, and it has reasonably
clear semantics. But I've also added some capabilities for accessing
the environment stored in NAND.)

The expected behaviour for menu item "Reset" is that it resets the
device, which will then load u-boot from NAND and boot into the
kernel. (Condition: don't hold AUX while doing the reset. Otherwise,
you'd end up in NOR again.)

By the way, when test booting Linux (I didn't see this among the test
cases, but perhaps you're testing this somewhere else), please make
sure you wait until user space has started completely, i.e., until
you get a login prompt. Some problems in the boot environment can
manifest themselves only relatively late in the boot process.

Thanks !

- Werner