BB validation issues -- a couple questions

GoogleGroups
1

by way of helping me tidy up the BB validation page, some questions:

1) at this point, given that the version of u-boot that most boards
shipped with and the one that's currently used for validation is
fairly old -- 2009.01-dirty (Feb 19 2009 - 12:23:21) -- is there any
validation value in simply telling users to just update the u-boot
that's on their board and be done with it? (or at least consistently
boot from a newer version off their MMC/SD card?)

  i'm assuming that the one that's built for the beagle from the OE
dev branch for angstrom would work just fine, yes? or is there
another version that can simply be defined as the new validation
standard and everyone should use that one?

2) i'm reading the validation reset script that flashes a new x-loader
and u-boot and, regarding the x-loader, i see:

if fatload mmc 0 80200000 x-load.bin.ift
then
echo ***** Replacing x-load *****
nand unlock
nandecc hw
nand erase 0 80000
nand write 80200000 0 20000
nand write 80200000 20000 20000
nand write 80200000 40000 20000
nand write 80200000 60000 20000
fi

  first question -- is there any reason to update the x-loader? does
the current version do anything the older version doesn't? and what's
going on above? it looks like the flashable x-loader image (size
20392 bytes) is being flashed four times, one after another. is that
right? why?

3) for a truly comprehensive validation page, there should be a
standard collection of files (audio, video, etc.) that come *with* the
validation instructions so people don't have to go looking for files
for any of the tests.

  case in point: the current validation page:

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

has a section, "To Test Audio-In Interface", which has the user create
an audio file, followed by "To Test Audio-Out Interface, Playback the
recorded Audio". but if the user, for some reason, can't do that
first test, then he won't have an audio file for the second test.
that shouldn't happen -- as much as possible, the validation page
tests should be standalone and not depend on earlier tests working.
and there should be a nice collection of test files so that everyone's
tests are consistent, and the validation instructions can instruct
users to simply copy all those test files to their MMC/SD card so they
have access to them after booting.

  thoughts?

rday

2

There are a bunch of threads on this topic making the discussion a bit
difficult to follow. I don't see any replies to this one, so I'll
chime in.

by way of helping me tidy up the BB validation page, some questions:

1) at this point, given that the version of u-boot that most boards
shipped with and the one that's currently used for validation is
fairly old -- 2009.01-dirty (Feb 19 2009 - 12:23:21) -- is there any
validation value in simply telling users to just update the u-boot
that's on their board and be done with it? (or at least consistently
boot from a newer version off their MMC/SD card?)

The process for validation should point to using one known good
version downloaded onto the MMC/SD card. There is a need to update
the u-boot version used for validation for the Rev. C4 boards. One
validation process for all the boards is desired (results will vary
depending on the board).

i'm assuming that the one that's built for the beagle from the OE
dev branch for angstrom would work just fine, yes?

The end result of the validation process is that the board flash is
left in the same condition as new boards are shipped. Some of the
features, like usbtty and splash screen, aren't in the OE tree.
Desire is to actually align it with denx.de, but the usbtty code still
has some issues in relation to the kernel.

I'm curious what the input is on the splash screen. It might make
sense to remove it, but it is one of the quickest signs that the board
is ok.

or is there
another version that can simply be defined as the new validation
standard and everyone should use that one?

I'm happy if you can provide an alternative for validation that meets
all the requirements. The main requirement is that Gerald is happy
with it for validating the shipping hardware and that it doesn't
change for a long time.

2) i'm reading the validation reset script that flashes a new x-loader
and u-boot and, regarding the x-loader, i see:

if fatload mmc 0 80200000 x-load.bin.ift
then
echo ***** Replacing x-load *****
nand unlock
nandecc hw
nand erase 0 80000
nand write 80200000 0 20000
nand write 80200000 20000 20000
nand write 80200000 40000 20000
nand write 80200000 60000 20000
fi

first question -- is there any reason to update the x-loader?

To make sure you get a known version. Older versions didn't scan for
u-boot on the MMC/SD card.

does
the current version do anything the older version doesn't?

Scan for u-boot on the MMC/SD card.

and what's
going on above? it looks like the flashable x-loader image (size
20392 bytes) is being flashed four times, one after another. is that
right? why?

Yes, that is correct. In case there is an error in the flash, the
next location will be tried by the ROM code.

3) for a truly comprehensive validation page, there should be a
standard collection of files (audio, video, etc.) that come *with* the
validation instructions so people don't have to go looking for files
for any of the tests.

case in point: the current validation page:

Google Code Archive - Long-term storage for Google Code Project Hosting.

has a section, "To Test Audio-In Interface", which has the user create
an audio file, followed by "To Test Audio-Out Interface, Playback the
recorded Audio". but if the user, for some reason, can't do that
first test, then he won't have an audio file for the second test.
that shouldn't happen -- as much as possible, the validation page
tests should be standalone and not depend on earlier tests working.
and there should be a nice collection of test files so that everyone's
tests are consistent, and the validation instructions can instruct
users to simply copy all those test files to their MMC/SD card so they
have access to them after booting.

thoughts?

Makes sense to me.

3

There are a bunch of threads on this topic making the discussion a
bit difficult to follow.

  yes, i'm starting to get a bit lost myself. i hadn't planned on
this getting quite so animated. :slight_smile:

I don't see any replies to this one, so I'll chime in.

>
> by way of helping me tidy up the BB validation page, some questions:
>
> 1) at this point, given that the version of u-boot that most
> boards shipped with and the one that's currently used for
> validation is fairly old -- 2009.01-dirty (Feb 19 2009 - 12:23:21)
> -- is there any validation value in simply telling users to just
> update the u-boot that's on their board and be done with it? (or
> at least consistently boot from a newer version off their MMC/SD
> card?)

The process for validation should point to using one known good
version downloaded onto the MMC/SD card. There is a need to update
the u-boot version used for validation for the Rev. C4 boards. One
validation process for all the boards is desired (results will vary
depending on the board).

  if you can point at a publicly-available image that's appropriate,
that would be great. and i can update the page. as it stands now,
i'm referring to the angstrom beagleboard u-boot image, which is dated
oct 2009 and seems recent enough but if you have a suggested
alternative, let me know. (and while it's not critical for
validation, knowing how it was built would be handy.)

> i'm assuming that the one that's built for the beagle from the OE
> dev branch for angstrom would work just fine, yes?

The end result of the validation process is that the board flash is
left in the same condition as new boards are shipped. Some of the
features, like usbtty and splash screen, aren't in the OE tree.
Desire is to actually align it with denx.de, but the usbtty code
still has some issues in relation to the kernel.

I'm curious what the input is on the splash screen. It might make
sense to remove it, but it is one of the quickest signs that the
board is ok.

  there's no splash screen image for the newer u-boots.

http://groups.google.com/group/beagleboard/browse_thread/thread/3ad9b803a3418624?pli=1

> or is there
> another version that can simply be defined as the new validation
> standard and everyone should use that one?

I'm happy if you can provide an alternative for validation that
meets all the requirements. The main requirement is that Gerald is
happy with it for validating the shipping hardware and that it
doesn't change for a long time.

  then it sounds like gerald might be the right person to provide the
alternative. i think we can agree that the one pointed at on the
original validation page is simply too old (feb 2009).

> 2) i'm reading the validation reset script that flashes a new x-loader
> and u-boot and, regarding the x-loader, i see:
>
> if fatload mmc 0 80200000 x-load.bin.ift
> then
> echo ***** Replacing x-load *****
> nand unlock
> nandecc hw
> nand erase 0 80000
> nand write 80200000 0 20000
> nand write 80200000 20000 20000
> nand write 80200000 40000 20000
> nand write 80200000 60000 20000
> fi
>
> first question -- is there any reason to update the x-loader?

To make sure you get a known version. Older versions didn't scan
for u-boot on the MMC/SD card.

> does
> the current version do anything the older version doesn't?

Scan for u-boot on the MMC/SD card.

  ah, quite right.

> and what's
> going on above? it looks like the flashable x-loader image (size
> 20392 bytes) is being flashed four times, one after another. is
> that right? why?

Yes, that is correct. In case there is an error in the flash, the
next location will be tried by the ROM code.

  got it.

rday

4

There are a bunch of threads on this topic making the discussion a
bit difficult to follow.

yes, i'm starting to get a bit lost myself. i hadn't planned on
this getting quite so animated. :slight_smile:

This discussion is going very fast than expected and in all directions
which we avoided before. The basic principle of this test suite was to
give Factory tests which takes minimal time and covers all
peripherals.

Any thing we add interms of big ramdisk copy or multiple commands etc
will lead us spending more time in factory. I don't mind having a
detailed test suite but for factory it has to be simple, straight and
at layman terms.

I will go through all the mails in this chain and reply you back by
today, will also review the page you created.

Thanks a lot for the effort.

I don't see any replies to this one, so I'll chime in.

>
> by way of helping me tidy up the BB validation page, some questions:
>
> 1) at this point, given that the version of u-boot that most
> boards shipped with and the one that's currently used for
> validation is fairly old -- 2009.01-dirty (Feb 19 2009 - 12:23:21)
> -- is there any validation value in simply telling users to just
> update the u-boot that's on their board and be done with it? (or
> at least consistently boot from a newer version off their MMC/SD
> card?)

The process for validation should point to using one known good
version downloaded onto the MMC/SD card. There is a need to update
the u-boot version used for validation for the Rev. C4 boards. One
validation process for all the boards is desired (results will vary
depending on the board).

if you can point at a publicly-available image that's appropriate,
that would be great. and i can update the page. as it stands now,
i'm referring to the angstrom beagleboard u-boot image, which is dated
oct 2009 and seems recent enough but if you have a suggested
alternative, let me know. (and while it's not critical for
validation, knowing how it was built would be handy.)

Usually I maintain the u-boot image on code.google site for Gerald to
Pickup, if there are issues while doing factory tests then I support
him, so we need to give the image that gets supported while factory
tests are going on as well.

5

at this point, i think there really are two different validation
processes we should be talking about.

  on the one hand, there's the "factory" validation whose purpose
should be to simply, and very quickly, do a sanity test on the board.
for something like that, the perfect solution would seem to be a
pre-formatted SD card -- dd'ed with whatever's necessary -- to be
inserted, power the board up and check. and that's it.

  on the other hand, there can be a longer, more detailed "validation"
for users who have the time to do it more leisurely, accompanied by
some explanation as to what's going on. clearly, those are somewhat
conflicting goals and i'm realizing that a single validation page
isn't going to satisfy both of them.

rday

6

The validation process also validates another important part - the nut that is installed between the keyboard and the chair.
I think that the long extended validation is a great idea to introduce people to the platform and once it's completed the user in question should have a good understanding of the basics, such as using a terminal emulator to talk to the beagle, downloading software and putting it on an SD card for use by the beagle etc...

7

i might have phrased it more diplomatically :slight_smile: but, yes, i do
appreciate the distinction. i still think we're talking about two
sets of instructions: 1) the condensed, "test this board" validation
(very much like the original page) and the longer, more explanatory
"pull up a chair and let's show you how this works" validation, which
is where i think i've been going without really realizing that it
differs substantially from the original and is really more educational
than just validational.

  i'm going to give this more thought.

rday

8

Just for the record, I agree with Jason. We use test SW that talks to the board over the serial port. Speed is the most important factor. It looks for the proper responses from the board and moves to the next test. I think having two vlaidation tests as Robert mentions is the way to go. The more detailed test is as more about teaching the user what Beagle does and in essence what Linux can do than it is about checking out the HW itself.

Gerald