Preparing REV C validation software for Factory shipment

Khasim_Syed_Mohammed · January 14, 2009, 3:37pm

Hi all,

I am working on providing Gerald C with validation software to be used
in factory for Rev C.

Software Requirement:

Nishanth_Menon · January 15, 2009, 2:46am

Khasim,

Hi all,

I am working on providing Gerald C with validation software to be used
in factory for Rev C.

Software Requirement:

u-boot, x-loader, kernel, Filesystem

Validation Required:

1) Board Revision Detection (u-boot)
2) NAND Flash validation (u-boot)
3) MMC read / write / Booting validation (u-boot)
4) I2C read / write (u-boot)

<snip>

For now I have

- u-boot based on sakoman's tree, have added spash screen, pin mux
and board rev detection (along with other existing support)

It would be great to see the POST as an additional config for u-boot
build and if this could be pushed to mainline also.. This will allow
other boards
to utilize this as a board validation strategy..
dunno if you would like to add memtest capability of u-boot also to your list..

Need the following by 1st of FEB 2009:

- A Video rendering test on top of FBDEV as we don't have V4L driver in yet.
- A Simple RootFS (along with source) that has
- ALSA plugins
- A Sample test to render Video on S-Video / DVI (like MPLAYER)
- Power Measurement app (to read TPS / TWL registers over I2C)

Just an idea, not volunteering something based on lm-sensor i2cdev
access could help.. you would need MDAC configuration to enable to
monitor vbat voltages.. mebbe somethng based on busybox could be
fast.. I suspect someone would have latest busybox running on beagle?

Regards,
Nishanth Menon

Geof · January 15, 2009, 12:54pm

I'd respectfully suggest / request:

- Upgrading to X-loader 1.4.2 as well. The 1.4.1 doesn't work well
with booting from SD cards -- i.e. it requires pushing a button,
rather than detecting that the SD Card has a u-boot and using that.
You're probably already doing this.

- Setting up a stable build of Angstrom to put on the board -- so that
the cards can boot up upon delivery. I'm not sure how to make this
all happen -- as Angstrom never seems to be stable. But we should be
getting closer to a point in time that we could have a stable tree.
Users could obviously overwrite it if they don't like Angstrom. But
it gives most of the n00bs out there like me a chance of succeeding
without weeks of trials and tribulations.

- Consider including the SGX user-mode binaries -- so that people can
try the SGX capabilities.

- Is there any chance of having u-boot able to boot from ethernet (via
tftp etc)? It would be really nice to be able to boot off of an NFS
disk for example. Having to burn SD cards all the time is a pain
during development.

- Include the Big Buck Bunny Trailer -- so that the new users can run
a video right away.

Thanks very much.

Best regards,
Geof

Gerald_Coley1 · January 15, 2009, 2:22pm

If we load Angstrom on the boards at the factory, there will be a significant increase in test time that we cannot afford. I am totally against such an effort. We cannot afford to keep updating the code on the board after every release. I don’t want to be at rev C2999 by the end of the year. People will be offering ready made SD cards and this should be the solution for this.

Gerald

Syed_Mohammed_Khasi1 · January 20, 2009, 3:45pm

Hi all,

I have consolidated the beagle board validation procedure, source,
pre-built binaries, etc at a new wiki page

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

I would request you to go through the procedure, validate on your
boards (if possible), comment your findings and above all try to help
in fixing any bugs reported in future.

Thanks to all for the support.

Regards,
Khasim

Robert_Kuhn1 · January 20, 2009, 4:08pm

I have consolidated the beagle board validation procedure, source,
pre-built binaries, etc at a new wiki page

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

I would request you to go through the procedure, validate on your
boards (if possible), comment your findings and above all try to help
in fixing any bugs reported in future.

I would ad the exact git revision for the binaries under "Sources can
be found at..." as a reference so everyone is able to build the exact
same binaries very easy. And the kernel-config.

Robert

Koen_Kooi · January 20, 2009, 4:13pm

IK_CONFIG should be enabled as well so people will _always_ have access to the config.

regards,

Koen

Robert_Kuhn1 · January 20, 2009, 4:18pm

boards (if possible), comment your findings and above all try to help
in fixing any bugs reported in future.

I would ad the exact git revision for the binaries under "Sources can
be found at..." as a reference so everyone is able to build the exact
same binaries very easy. And the kernel-config.

IK_CONFIG should be enabled as well so people will _always_ have access to
the config.

...when they booted the kernel, yes. But of course you're right.

Robert

Koen_Kooi · January 20, 2009, 4:29pm

there are tools to extract it off-line

regards,

Koen

Robert_Kuhn1 · January 20, 2009, 4:32pm

IK_CONFIG should be enabled as well so people will _always_ have access
to
the config.

...when they booted the kernel, yes. But of course you're right.

there are tools to extract it off-line

Ups. Okay, I did not know that. Then you are absolutely right
Robert

jkridner · January 29, 2009, 6:55pm

If we load Angstrom on the boards at the factory, there will be a significant increase in test time that we cannot afford. I am totally against such an effort. We cannot afford to keep updating the code on the board after every release. I don’t want to be at rev C2999 by the end of the year. People will be offering ready made SD cards and this should be the solution for this.

Gerald, can you confirm that the the latest ramdisk image provided by Steve boots in sufficient time to allow it to be used for testing?

Steve, can you update the wiki or reply to this mailing list with what you did so that I can update the build sources?

I’d respectfully suggest / request:

Upgrading to X-loader 1.4.2 as well. The 1.4.1 doesn’t work well
with booting from SD cards – i.e. it requires pushing a button,
rather than detecting that the SD Card has a u-boot and using that.
You’re probably already doing this.

Please review http://code.google.com/p/beagleboard/wiki/BeagleboardRevCValidation and provide updated comments. The move to x-load 1.4.2 was done as far as I’m aware.

Setting up a stable build of Angstrom to put on the board – so that
the cards can boot up upon delivery. I’m not sure how to make this
all happen – as Angstrom never seems to be stable. But we should be
getting closer to a point in time that we could have a stable tree.
Users could obviously overwrite it if they don’t like Angstrom. But
it gives most of the n00bs out there like me a chance of succeeding
without weeks of trials and tribulations.

This won’t be done and is the responsibility of the maintainers of the Angstrom Distribution, not something for BeagleBoard production. Naturally, some of us to participate in the Angstrom Distribution community, but please work on it at that level.

Consider including the SGX user-mode binaries – so that people can
try the SGX capabilities.

Sorry, I have no intentions of getting TI into the software distribution business for Beagle. I’m far more concerned with getting support into the upstream distributions and am not concerned at all about creating our own. Work has gone into integrating SGX components coming from TI into the Angstrom Distribution and other distributions are also welcome to pick up this support. I believe that creating a TI distribution is a step backwards.

Is there any chance of having u-boot able to boot from ethernet (via
tftp etc)? It would be really nice to be able to boot off of an NFS
disk for example. Having to burn SD cards all the time is a pain
during development.

Please submit the patches or tell me from where to pull the patches. Sorry, it won’t make this window. I’m more disappointed that the musb gadget serial code looks like it won’t make this window as I am not aware of a clean patch where everyone is happy with the results. If you want to boot over USB, I recommend reviewing the musb gadget activity and providing some support there (since everyone can do this with Rev B boards). At some point, I expect u-boot to support what you are suggesting over the EHCI port on Rev C. The u-boot upgrade process will be greatly simplified by the boot-script support being put into the new u-boot.

Include the Big Buck Bunny Trailer – so that the new users can run
a video right away.

Again, this is an issue for the distribution. I’d also like to see this put into the Angstrom Distribution demo.

Thanks very much.

Best regards,
Geof

Khasim,

On Wed, Jan 14, 2009 at 9:37 AM, Khasim Syed Mohammed

Hi all,

I am working on providing Gerald C with validation software to be used
in factory for Rev C.

Software Requirement:

u-boot, x-loader, kernel, Filesystem

Validation Required:

Board Revision Detection (u-boot)

NAND Flash validation (u-boot)

MMC read / write / Booting validation (u-boot)

I2C read / write (u-boot)

For now I have

u-boot based on sakoman’s tree, have added spash screen, pin mux
and board rev detection (along with other existing support)

It would be great to see the POST as an additional config for u-boot
build and if this could be pushed to mainline also… This will allow
other boards
to utilize this as a board validation strategy…
dunno if you would like to add memtest capability of u-boot also to your list…

Just reminding everyone of the goals and Feb 1st deadline…

Need the following by 1st of FEB 2009:

A Video rendering test on top of FBDEV as we don’t have V4L driver in yet.

A Simple RootFS (along with source) that has

I believe the Arago overlay of Angstrom solves most of this problem.

ALSA plugins

This seems to be done.

A Sample test to render Video on S-Video / DVI (like MPLAYER)

I believe we have a suitable armv5te build, but I haven’t yet gotten my -nox build of the armv7a version.

Rendering to S-video is done using Tomi’s DSS2 patches as pulled from Open Embedded and applied against the 2.6.28 linux-omap kernel.

Dirk · January 29, 2009, 7:14pm

Jason Kridner wrote:

- Is there any chance of having u-boot able to boot from ethernet (via
tftp etc)? It would be really nice to be able to boot off of an NFS
disk for example. Having to burn SD cards all the time is a pain
during development.

Please submit the patches or tell me from where to pull the patches. Sorry, it won't make this window. I'm more disappointed that the musb gadget serial code looks like it won't make this window as I am not aware of a clean patch where everyone is happy with the results.

I propose to extract one overall patch from omap3-dev-usb branch and send it to this list for a first review. We then can do the prepare-for-u-boot-list clean up based on the omap3-dev-usb branch. IMHO, we will not hit 100% the taste of U-Boot maintainers But I think we have now some experience about their review topics that we would be able to do the first clean up here before 'spamming' U-Boot list.

Best regards

Dirk

jkridner · January 31, 2009, 4:13pm

Khasim and all,

I've redone the Beagle logo as a 1280x720 image, but placed the logo in the upper-left 640x480:
http://groups.google.com/group/beagleboard/web/beagle_logo.png

I used GIMP to save the file to a .h file:
http://groups.google.com/group/beagleboard/web/beagle_logo.h

I wrote a small utility to compress the logo using simple run-length encoding (compress_logo.c attached) and then generated a simple utility to uncompress the image and write back the original header file to ensure that I didn't gum things up (decompress_logo.c attached).

I used the following shell script for verification:
#!/bin/sh
echo Compiling logo...
gcc -o compress_logo compress_logo.c
echo Compressing logo...
./compress_logo > compressed_logo.h
echo Compiling compressed logo...
gcc -o decompress_logo decompress_logo.c
echo Decompressing logo...
./decompress_logo > decompressed_logo.h
echo Comparing original logo...
diff beagle_logo.h decompressed_logo.h > result.txt

The result is that beagle_logo.h and that decompressed_logo.h are identical.

The binary file savings between compress_logo and decompress_logo seems to be about 8:1. I'm not sure how much of that is currently library overhead. The PNG file is only 16k and decompress_logo is around 112k. Even if the compression really is that bad, this should make it tolerable and is somewhat simpler than using zlib.

The next step is to put this into u-boot, but I'll need a good 1280x720 configuration. I'll go back and look at the one used with 1.3.3.

decompress_logo.c (1.57 KB)

compress_logo.c (1.27 KB)

Nishanth_Menon · January 31, 2009, 4:26pm

Jason Kridner said the following on 01/31/2009 10:13 AM:

Khasim and all,

I've redone the Beagle logo as a 1280x720 image, but placed the logo
in the upper-left 640x480:
http://groups.google.com/group/beagleboard/web/beagle_logo.png

I used GIMP to save the file to a .h file:
http://groups.google.com/group/beagleboard/web/beagle_logo.h

I wrote a small utility to compress the logo using simple run-length
encoding (compress_logo.c attached) and then generated a simple
utility to uncompress the image and write back the original header
file to ensure that I didn't gum things up (decompress_logo.c attached).

I used the following shell script for verification:
#!/bin/sh
echo Compiling logo...
gcc -o compress_logo compress_logo.c
echo Compressing logo...
./compress_logo > compressed_logo.h
echo Compiling compressed logo...
gcc -o decompress_logo decompress_logo.c
echo Decompressing logo...
./decompress_logo > decompressed_logo.h
echo Comparing original logo...
diff beagle_logo.h decompressed_logo.h > result.txt

The result is that beagle_logo.h and that decompressed_logo.h are
identical.

The binary file savings between compress_logo and decompress_logo
seems to be about 8:1. I'm not sure how much of that is currently
library overhead. The PNG file is only 16k and decompress_logo is
around 112k. Even if the compression really is that bad, this should
make it tolerable and is somewhat simpler than using zlib.

The next step is to put this into u-boot, but I'll need a good
1280x720 configuration. I'll go back and look at the one used with
1.3.3.

Dumb Question: Does'nt uboot have zlib already? wont that be easier to
use? see tools directory in u-boot-v1..
would this compression algo give a better ratio? Vs: see lib_generic/zlib.c
Regards,
Nishanth Menon

jkridner · January 31, 2009, 4:28pm

It does already have zlib, but I'd have to figure out how to call it. It also has bzlib.

Nishanth_Menon · January 31, 2009, 4:43pm

Jason Kridner said the following on 01/31/2009 10:28 AM:

Jason Kridner said the following on 01/31/2009 10:13 AM:

Khasim and all,

I've redone the Beagle logo as a 1280x720 image, but placed the logo
in the upper-left 640x480:
http://groups.google.com/group/beagleboard/web/beagle_logo.png

I used GIMP to save the file to a .h file:
http://groups.google.com/group/beagleboard/web/beagle_logo.h

I wrote a small utility to compress the logo using simple run-length
encoding (compress_logo.c attached) and then generated a simple
utility to uncompress the image and write back the original header
file to ensure that I didn't gum things up (decompress_logo.c
attached).

I used the following shell script for verification:
#!/bin/sh
echo Compiling logo...
gcc -o compress_logo compress_logo.c
echo Compressing logo...
./compress_logo > compressed_logo.h
echo Compiling compressed logo...
gcc -o decompress_logo decompress_logo.c
echo Decompressing logo...
./decompress_logo > decompressed_logo.h
echo Comparing original logo...
diff beagle_logo.h decompressed_logo.h > result.txt

The result is that beagle_logo.h and that decompressed_logo.h are
identical.

The binary file savings between compress_logo and decompress_logo
seems to be about 8:1. I'm not sure how much of that is currently
library overhead. The PNG file is only 16k and decompress_logo is
around 112k. Even if the compression really is that bad, this should
make it tolerable and is somewhat simpler than using zlib.

The next step is to put this into u-boot, but I'll need a good
1280x720 configuration. I'll go back and look at the one used with
1.3.3.

Dumb Question: Does'nt uboot have zlib already? wont that be easier to
use? see tools directory in u-boot-v1..
would this compression algo give a better ratio? Vs: see lib_generic/
zlib.c

It does already have zlib, but I'd have to figure out how to call it.
It also has bzlib.

does ./fs/cramfs/uncompress.c help? looks simple ..
inflateInit()
inflateReset()
inflate
inflateEnd()

mebbe it is compatible with gzip? considering that u-boot would
uncompress the kernel during boot.. this might be equal operation?

Regards,
Nishanth Menon

jkridner · January 31, 2009, 6:48pm

It might be easy, but this was easier for me:
http://www.beagleboard.org/gitweb/?p=u-boot-arm.git;a=commitdiff;h=2d20f82ccb75b8ee2ab468ea1898476cdb1b7303

However, the frequencies set by the dss_init() function still don't work for my TV. Anyone have suggestions (code) on the way to setup the DSS?