final thoughts and questions about BB "validation"

just to close off this thread and resolve any unresolved issues,
some thoughts and questions. once again, here are the original and
updated validation pages:

http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation
http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidationv2

(i'm not trying to duplicate work -- once that new page seems
adequate, i'm more than happy to move it back over the old one. or
simply link from the old one to the new one. whatever's easier.)

  and so, to work.

  first, validation should involve testing only what's necessary to
verify the basic functionality of your board -- you can boot to linux,
audio works, video works, USB works, and so on. anything beyond that
is outside the scope of simple validation. new users simply want to
confirm that their board boots and everything seems to function.
beyond that, there are countless other web pages that take it from
there. (also, the basic validation shouldn't require a massive
investment in additional hardware -- it should concentrate on what
most users have available to them but, yes, it can mention how to play
simple video if one has a display and a cable, that sort of thing.)

  next, most people seem to agree that validation should be an
entirely non-destructive process. while folks might *eventually* want
to reflash their boards (and that's certainly worth explaining
*somewhere*), the initial validation process should change *nothing*
on the board and should get everything it needs off of the SD card.
agreed?

  as for the contents of the SD card, that card should be populated
with *only* what's required for the testing. as in, unless there's a
compelling reason, there's no need to copy an MLO x-loader file if the
on-board version works just fine (as it seems to). on the other hand,
it seems like validation really *should* be using a much newer u-boot
loader than the one that comes with the C3 boards. is it reasonable
to define current validation as requiring a fairly current u-boot
loader? i think so since it just makes it easier to lead into the
eventual C4 validation down the road.

  so, proposed contents of the SD card:

  * (recent) u-boot
  * uImage.bin
  * ramdisk.gz
  * boot.scr (non-destructive)
  * files/ directory, with sample files for testing

most of this is already available at the links you can find at the
validation page, perhaps we need to start a second directory to match
version 2 of the validation page. most of the files would be the
same, except for a newer u-boot. which one should be used? is there
a downloadable new u-boot i can point at right now? or i can just
upload the one i built via OE which seems to work just fine:

  OMAP3 beagleboard.org # version

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

  regarding playing around in u-boot, it's obviously not strictly
*necessary* for validation to stop in u-boot and look around, but i
think it's educational enough that i added that section on "U-Boot
validation" to the new page. hackers are inordinately curious, so
it's worth seeing what's possible, and it makes future debugging
easier if someone isn't nervous about stopping in u-boot and running
some commands.

  to that end, i'd still like folks to help me finish off that u-boot
section. what else is worth running that's non-destructive? and what
more can i do with the "i2c" command in terms of, say, examining a
connected monitor's EDID?

  finally, once the system boots to linux, what should one run to
complete the validation process? even simple commands like "mount"
and "ps" might be useful to verify that the right things seem to be
running, etc.

  at this point, i'm out of ideas. thoughts?

rday

[snip]

next, most people seem to agree that validation should be an
entirely non-destructive process. while folks might *eventually* want
to reflash their boards (and that's certainly worth explaining
*somewhere*), the initial validation process should change *nothing*
on the board and should get everything it needs off of the SD card.
agreed?

With the version of the boot loader that's in flash on the Rev C3 boards, the end user will almost certainly need to flash newer versions as, in my experience, even booting Ubuntu doesn't work with the version that ships in flash.

On the new validation page it is mentioned "(In fact, if you're happy with your on-board X-Loader and U-Boot, you don't even need to have those on your MMC/SD card.)" I think this is slightly misleading to new users and implies that there's no compelling reason to flash new firmware whereas the opposite is more likely to be the case. This will most likely be different with the C4 boards, as they'll have newer firmware on them, but as it stands with the C3 boards, they will pretty much need to have new firmware flashed in order to continue loading current operating systems.

The errors that were occurring when trying to boot, say, Ubuntu on the beagle with an old x-loader and u-boot, were rather cryptic in that they didn't obviously point to the firmware being out of date, however flashing the current versions of each to the beagle resolved a lot of the initial issues that I was experiencing.

Cheers,
Kai

[snip]
> next, most people seem to agree that validation should be an
> entirely non-destructive process. while folks might *eventually*
> want to reflash their boards (and that's certainly worth
> explaining *somewhere*), the initial validation process should
> change *nothing* on the board and should get everything it needs
> off of the SD card. agreed?

With the version of the boot loader that's in flash on the Rev C3
boards, the end user will almost certainly need to flash newer
versions as, in my experience, even booting Ubuntu doesn't work with
the version that ships in flash.

  no, i would word it as that the user almost certainly needs to *use*
a newer u-boot, but i think we're all agreed and we know what point
i'm trying to make. whether the user wants to *flash* that newer
u-boot is a separate issue, and that can always be added as a final
section to that page.

On the new validation page it is mentioned "(In fact, if you're
happy with your on-board X-Loader and U-Boot, you don't even need to
have those on your MMC/SD card.)" I think this is slightly
misleading to new users and implies that there's no compelling
reason to flash new firmware whereas the opposite is more likely to
be the case.

  you're right, that could be worded better and i'll fix that.

The errors that were occurring when trying to boot, say, Ubuntu on
the beagle with an old x-loader and u-boot, were rather cryptic in
that they didn't obviously point to the firmware being out of date,
however flashing the current versions of each to the beagle resolved
a lot of the initial issues that I was experiencing.

  i'll change that shortly. which brings up an obvious question --
where's a good and reliable place to download a current, ready-to-go
BB u-boot image? or will i have to upload (to somewhere) such an
image? if one exists, i might as well add a reference to the
validation page.

rday

p.s. unlike with u-boot, i still don't see any reason to suggest
getting a newer x-loader. is there any reason to do that?

Op 30 nov 2009 om 09:56 heeft "Robert P. J. Day" <rpjday@crashcourse.ca> het volgende geschreven:\

i'll change that shortly. which brings up an obvious question --
where's a good and reliable place to download a current, ready-to-go
BB u-boot image? or will i have to upload (to somewhere) such an
image? if one exists, i might as well add a reference to the
validation page.

The uboot on the angstrom website is all that

ok, then, we're good.

rday