the BB validation procedure: hanging out in u-boot

GoogleGroups
1

while board validation doesn't *technically* require poking around
in u-boot, i think there's some value in showing new users what
they're allowed to rummage through if they want to stop the boot
procedure in u-boot and look around. and that's why i think we need
to standardize on a single version of u-boot -- because some of the
commands have changed since the current on-board version, so we might
as well just pick a newer version and go with it. right now, i'm
using the one i built based on the OE dev branch and angstrom, and it
seems to work just fine:

  OMAP3 beagleboard.org # version

  U-Boot 2009.08 (Nov 26 2009 - 20:30:10)
  OMAP3 beagleboard.org #

but i'm open to whatever fairly new and identifiable version people
suggest.

  another reason to introduce u-boot (at least briefly) is that, if
the validation procedure fails, at least users will understand what it
means if you ask them to go to u-boot and do some debugging. (will
the upcoming C4 version have a newer u-boot? i would have assumed
so.)

  so for the above version of u-boot, i can see telling users to run
(some of which i've already listed at
http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidationv2):

  # version
  # bdinfo
  # coninfo
  # printenv
  # nand info
  # i2c probe
  # mtdparts
  # mtest
  # mmc(?)

and note that some of these commands (or their output) have changed
since the feb 2009 version. for example, "iprobe" is now "i2c probe",
which is why it would be nice to standardize on a newer u-boot for
everyone and not try to work with two different versions.

  (no one's suggesting that users *need* to run any of the above for
the purposes of validation. but people are just curious.)

  and now, the obvious questions and digging a bit deeper. first, are
there any other useful informative commands a user might want to
run? feel free to toss out suggestions.

  next, we have a curious change in the output of "nand info".
the old version of "nand info":

OMAP3 beagleboard.org # nand info

Device 0: NAND 256MiB 1,8V 16-bit, sector size 128 KiB
OMAP3 beagleboard.org #

  the new version of "nand info":

OMAP3 beagleboard.org # nand info

Device 0: nand0, sector size 128 KiB
OMAP3 beagleboard.org #

i'm curious -- why did "nand info" stop printing the device size? i
would have thought that would be useful info.

  next, i'm still working my way through i2c, so what can one do with
this output from "i2c probe"?

OMAP3 beagleboard.org # i2c probe
Valid chip addresses: 48 49 4A 4B
OMAP3 beagleboard.org #

  given that output, what *further* probing would be informative?
specifically, what's the incantation to check the EDID of a connected
flat-panel display?

  and there's perhaps poking around the MMC info:

OMAP3 beagleboard.org # mmc init
mmc1 is available
OMAP3 beagleboard.org # fatls mmc 1
    20392 mlo
   184316 u-boot.bin
  7999649 ramdisk.gz
  2578044 uimage.bin
      603 boot.scr
            files/

5 file(s), 1 dir(s)

OMAP3 beagleboard.org #

  so, again, what other u-boot commands would be educational for new
users?

rday

2

Rev C4 will indeed have a new UBoot and ALL of the older versions of UBoot will NOT work on Rev C4.

Gerald

3

does that mean that even *current* beagle builds of u-boot that work
on C3 won't work on C4? or will current builds work for both? in any
event, that's still a good argument to push people off of using the
old feb 2009 build and *strongly* promote the use of a recent build.

  and speaking of, what would be a good canonical location for a
recent beagle u-boot build?

rday

4

It means that any UBoot that was created prior to now, willl not work on C4. In other words you need some new stuff in UBoot to make it work on the C4 board. The board ID format changes, the MHZ goes up, and there is a change in the EHCI circuit. The EHCI change requires a UBoot change or the EHCI will not function at all.

Gerald

5

ok, that makes sense, thanks.

rday

6

Gerald Coley wrote:

The board ID format changes,

Could you elaborate on this a bit? Isn't it just the new revision number value in CONTROL_IDCODE and a look at PRODUCTION_ID[0:3] to see if this is a 720 MHz part? Meaning that as far as I understand, you're not looking at any new registers, perhaps just one field that used to be ignored... I'm assuming these boards will have ES 3.1.2.

Cheers

7

The board ID, GPIO pins, are read to determine the revision of the board not the processor. The key part here is the changes required to apply power to the EHCI PHY which have changed. The board will not be using ES parts, but production Rev D parts.

Gerald

8

which suggests that, once the C4 boards are out, there will be
little reason for any validation process to need to override the
on-board x-loader or u-boot, since those should be nicely up-to-date
and in no need of enhancement, at least for a while.

rday

9

At least for a while.

Gerald