BeagleBoard verification image task list update

GoogleGroups
1

I thought I'd start a new thread as we are getting closer to something
that can be pounded upon and documented for validating the hardware.
The 'ec2build.sh' script is starting to finally provide some results.
There was a bug in 'oebb.sh' (that I created) that was causing it to
not update the OE source tree, which is why some fixes that had gone
into OE didn't show up in the last test image. This one should be a
bit better:

http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008051716.img/list.html

I hope that anyone testing will move to this version and apply fixes
to it. However, it doesn't currently boot automatically, so you'll
need to halt u-boot and give it the following help:
mmc init
setenv console ttyS2,115200n8
run loaduimage
run loadramdisk
run ramboot

I still need to work out the errors with user.scr, such as how to use
comparisons to ${beaglerev} in a script and why setting ${optargs}
generates a syntax error, but I'll do that after pulling in Steve
Kipisz's patches that he sent me privately for enabling the camera
port.

At the login prompt, just give 'root' as the user name.

Networking almost works, but I need to add an 'auto usb0' to make it
automatic. Here's the current behavior:
root@beagleboard:~# ifup usb0
udhcpc (v1.13.2) started
Sending discover...
[ 95.123352] usb0: link up, 100Mbps, full-duplex, lpa 0x45E1
Sending discover...
Sending select for 192.168.1.9...
Lease of 192.168.1.9 obtained, lease time 86400
adding dns 192.168.1.1
oot@beagleboard:~# ping www.google.com
PING www.google.com (209.85.225.103): 56 data bytes
64 bytes from 209.85.225.103: seq=0 ttl=52 time=44.313 ms
64 bytes from 209.85.225.103: seq=1 ttl=52 time=44.830 ms
64 bytes from 209.85.225.103: seq=2 ttl=52 time=43.580 ms
^C

Next, I'm working to add the test scripts that I promised in the ESC
classes. 'testled' and 'testaudio' don't work in the image, but they
are working in the git repo. I'll get all of these working and
include the guts of them in the wiki documentation on the board
validation. Having them in scripts will also help me quickly go back
and check everything on Rev C and Rev B. Please let me know if we
should have some more specific tests.

Finally, I need some support from Koen and others to build the demo
partition automatically (removing the manual steps), as well as a bit
more clean-up in the scripts to be sure that everyone can rebuild all
of the bits reliably. I believe that all of this will allow us to
keep an up-to-date version of this image with everyone's feedback and
help us verify things aren't broken as we push everything into the
mainlines of each project.

2

Played around with this yesterday... Try:

if test "${beaglerev}" = "xMA"; then
do_something
fi

Regards,

3

I thought I'd start a new thread as we are getting closer to something
that can be pounded upon and documented for validating the hardware.
The 'ec2build.sh' script is starting to finally provide some results.
There was a bug in 'oebb.sh' (that I created) that was causing it to
not update the OE source tree, which is why some fixes that had gone
into OE didn't show up in the last test image. This one should be a
bit better:

Bucket listing

I hope that anyone testing will move to this version and apply fixes
to it. However, it doesn't currently boot automatically, so you'll
need to halt u-boot and give it the following help:
mmc init
setenv console ttyS2,115200n8
run loaduimage
run loadramdisk
run ramboot

I still need to work out the errors with user.scr, such as how to use
comparisons to ${beaglerev} in a script and why setting ${optargs}

Played around with this yesterday... Try:

if test "${beaglerev}" = "xMA"; then
do_something
fi

Good call. I think I found that out before and forgot it somewhere
along the way. Good to have it recorded a few more places like this.

I still have the problem with booting to the ramdisk using user.scr,
so you'll still need to use the above work-around. I believe it has
something to do with me setting 'optargs' to the 'mem=' values, but
not sure what.

The image [1] *does* however have the camera patches built that I hope
Steve and Gerald can use to test now. Networking still requires 'ifup
usb0' until I edit /etc/network/interfaces to include 'auto usb0' and
the test scripts in the file system are old [3], but we are getting
there. I'm slowly editing the code.google.com
BeagleBoardDiagnosticsNext wiki page, somewhat off-line.

If anyone wants to look at the build script [2] and tell me if there
are ways to speed it up given the EC2 machine has 16+ GB of RAM, I'd
really appreciate it.

Another thing I'd really appreciate is anyone trying this on a Bx or
Cx board to document the behavior.

[1] Bucket listing
[2] http://gitorious.org/beagleboard-validation/scripts/blobs/master/ec2build.sh
[3] http://gitorious.org/beagleboard-validation/scripts

4

Here's the latest test image:
http://beagleboard-validation.s3.amazonaws.com/deploy/201008061544/list.html
For the SD card content and image, see
http://beagleboard-validation.s3.amazonaws.com/deploy/201008061544/sd/list.html

Known issues and status:
* The S-video color bar patch seems to be omitted (probably with the
orange screen init).
* boot.scr and user.scr don't work. This seems to have something to
do with the setting of 'optargs'. I plan to debug that today as well.
* Using the the ramdisk, the console prompt seems to come up very
slowly or never at all. The serial console comes up quickly.
* The kernel module for the camera is not in the ramdisk. I believe I
just need to add 'kernel-module-mt9t112' to the image.
* 'ifup usb0' is required to start the Ethernet. I already submitted
a patch to fix this and just need to wait for it to go through.
* burn-neon is included in the image to run the ARM at top CPU load.
I did test that I can run burn-neon at the same time as the camera
without any noticeable impact in performance (mplayer takes ~30% and
burn-neon takes the rest). This does bring the processor to a bit of
a warm place, but i can still put my finger on the memory above it. I
still need to add something to load at least the DSP, and perhaps the
SGX, all at the same time to figure the maximum possible power
consumption.

Speaking of the camera, I finally got one! I was able to test with
the above image by doing:
In u-boot:
# mmc init
# setenv console ttyS2,115200n8
# run loaduimage
# run loadramdisk
# run ramboot

In Linux:
# ifup usb0
udhcpc (v1.13.2) started
Sending discover...
[ 531.422454] usb0: link up, 100Mbps, full-duplex, lpa 0x45E1
Sending discover...
Sending select for 192.168.1.14...
Lease of 192.168.1.14 obtained, lease time 86400
adding dns 192.168.1.1
# cd /media/mmcblk0p1
# wget -O - http://beagleboard-validation.s3.amazonaws.com/deploy/201008061544/glibc/images/beagleboard/modules-2.6.32-r88%2Bgitra6bad4464f985fdd3bed72e1b82dcbfc004d7869-beagleboard.tgz

tar xz lib/modules/2.6.32/kernel/drivers/media/video/mt9t112.ko

Connecting to beagleboard-validation.s3.amazonaws.com (72.21.207.165:80)
- 100% |*******************************| 8222k 00:00:00 ETA
# insmod lib/modules/2.6.32/kernel/drivers/media/video/mt9t112.ko
[ 628.156982] mt9t112 2-003c: mt9t111 chip ID 2680
# mplayer tv:/// -vo fbdev

Cool!! It seems like the quality and lag-time could be greatly
improved, but it is most definitely working for me.

Lots of work left to do on the wiki page and test scripts. Has ANYONE
tried this on a Rev Bx or Rev Cx yet?!?

5

Here's the latest test image:
Bucket listing
For the SD card content and image, see
Bucket listing

Known issues and status:
* The S-video color bar patch seems to be omitted (probably with the
orange screen init).

I think the problem might be the change in the clocks. Can anyone
quickly point out where/how that gets set? Is it possible that the
clock changes are to blame here?

* boot.scr and user.scr don't work. This seems to have something to
do with the setting of 'optargs'. I plan to debug that today as well.

This seems to be a *really* freakish bug. There is a command line
size limit and some types of appending seem to hit the issue, perhaps
even before you run out of total command-line length--I'm not really
sure.

* Using the the ramdisk, the console prompt seems to come up very
slowly or never at all. The serial console comes up quickly.
* The kernel module for the camera is not in the ramdisk. I believe I
just need to add 'kernel-module-mt9t112' to the image.

I confirmed that is all that is required.

6

Here's the latest test image:
Bucket listing
For the SD card content and image, see
Bucket listing

Here's the latest I tested:
http://beagleboard-validation.s3.amazonaws.com/deploy/201008100357/sd/list.html

Features:
* It adds DSP/Link and examples because Gerald was looking to do a bit
of testing with all of the processors running to maximize the board
power consumption.
* It now boots into the ramdisk. On a board prior to xM, hold the
USER button, apply power, and then wait 5 seconds before releasing the
USER button. On an xM board, apply power, after about a second hold
the USER button for about 5 seconds before releasing it.

I ran another build with some updated scripts, but I haven't had a
chance to test it:
http://beagleboard-validation.s3.amazonaws.com/deploy/201008100459/sd/list.html

With that build you should be able to run:
* testaudio: Uses 'sox' to create a sine wave, start recording, play
the sine wave, then stop recording, and then finally plays back the
recording. This is great for a loop-back recording such that the data
can be analyzed. Without any good analysis routines yet, I'm just
using the playback to verify that recording happened.
* testcamera: Uses 'mplayer' to take video from the camera and put it
on the framebuffer display.
* testdsp: Uses the dsplink example 'loopgpp' application to verify
the ability to execute code on the DSP and perform communications.
* testedid: Uses 'i2c-tools' to read the EDID EEPROM on your
monitor--testing the I2C bus handling. Will want to eventually
include a parser.
* testled: Uses the kernel led class driver to cycle through LED
states, providing an example.
* testmem: Uses 'memtester' to run a memory test.
* testneon: Uses 'burn-neon' to fully load the ARM/NEON for 10 seconds.
* testsvideo: Dynamically switches framebuffer 0 from DVI-D to S-Video
output for a few seconds, then switches back.
* testuserbtn: Uses the kernel event driver and 'evtest' to detect
USER button press events.
* editbootscr: Edits the current boot.scr file.
* edituserscr: Edits the current user.scr file.
* readgpio: From the blog posting of the same name (forgot who to
credit currently, but it is in the comments). Good for testing the
expansion header.

Known issues and status:
* The S-video color bar patch seems to be omitted (probably with the
orange screen init).

I think the problem might be the change in the clocks. Can anyone
quickly point out where/how that gets set? Is it possible that the
clock changes are to blame here?

I still think this is the issue, but I was too busy messing with how
to build DSP/Link to get any progress.

* boot.scr and user.scr don't work. This seems to have something to
do with the setting of 'optargs'. I plan to debug that today as well.

This seems to be a *really* freakish bug. There is a command line
size limit and some types of appending seem to hit the issue, perhaps
even before you run out of total command-line length--I'm not really
sure.

I'm not sure all options will work. This really needs to be tested on
Bx and Cx boards. Please?

* Using the the ramdisk, the console prompt seems to come up very
slowly or never at all. The serial console comes up quickly.

Still need to look into this one.

* The kernel module for the camera is not in the ramdisk. I believe I
just need to add 'kernel-module-mt9t112' to the image.

I confirmed that is all that is required.

* 'ifup usb0' is required to start the Ethernet. I already submitted
a patch to fix this and just need to wait for it to go through.

Patch was applied to OE.

7

Here's the latest test image:

http://beagleboard-validation.s3.amazonaws.com/deploy/201008171955/sd/list.html

This should run on Rev Cx boards.

Issues:
* doesn't bring up a console on tty0.
* many others I hope you can help uncover.

Features:
* S-Video color bar (I hear it works, but I don't have a TV to test with)
* 128MB ramdisk
* several test* scripts
* edit(user|boot)scr scripts
* DSP/Link examples
* sox for producing a sine wave -- cannot figure out how to do an
analysis with it

8

Gerald,

The latest image with 1024x768 support is at:
http://beagleboard-validation.s3.amazonaws.com/deploy/201008192024/sd/list.html

The LEDs toggle, so you can figure out when to let go of the USER button.

Koen,

I have 'console=tty0 console=ttyS2,115200n8', but I still get no
console prompt on the monitor (tty0). :frowning:

Regards,
Jason