BeagleBoard verification image task list

OK, time to get serious about a new verification image. There is
confusion regarding the validation process as new people are coming to
the BeagleBoard and trying to follow the many various sources of
instructions, some of which have become a bit stale. Several people
have been hacking away at the code for the BeagleBoard-xM and, now
with the camera code working for VGA and 3MP sensors, it is time to
get things cleaned up into a releasable state with instructions for
all board revisions, Bx (128MB OTG-only), C2/3 (256MB 600MHz), C4
(720MHz w/ USB fixes), and xM-Ax (512MB w/ USB hub).

The verification software is utilizing the Angstrom Distribution of
GNU/Linux with 3 non-BeagleBoard-specific open source projects having
BeagleBoard-specific updates: x-loader, u-boot, and the Linux kernel.
Branches for the git repositories of these projects are cloned on
Gitorious [1]. The x-loader upstream is on TI's Arago Project server
[2], but we've actually started from sources maintained by Steve
Sakoman from his Gitorious x-load project repository [3] and may
require a more public process before we can conclude where the
upstream will be. The u-boot upstream is on Denx's site [4] with a TI
staging area [5] we should utilize. The Linux kernel upstream is on
kernel.org [6] where Tony Lindgren has a staging area for OMAP [7].
While it would be ideal from a least-amount-of-wasted-effort
standpoint to get all of the BeagleBoard-specific updates pushed into
their upstream projects prior to any further distribution of the
working branches, we need to build up an automated test build and test
flow to make sure the code going upstream really works for people and
in a way that we can test for any significant regressions. The task
list being spelled out here will be about putting together that
verification image and, once complete, we can point the build tool to
the upstream project repositories and push our patches until
everything works directly from the upstream sources.

The primary user entry page for the verification software is the
BeagleBoard.org support page (http://beagleboard.org/support) [8].
This will point to the diagnostic/verification instructions page [9]
on the Google code project wiki. The Google code project issues list
[10] should be used to report any confirmed issue with the software or
instructions that might otherwise might get forgotten. There will be
a single diagnostic/verification page and all the obsolete
verification pages on that wiki site will get replaced with links to
the one set of instructions that should work for all revisions of the
hardware. During initial work, I'll be using the
BeagleBoardDiagnosticsNext wiki page [11].

Unlike previous sets of diagnostic/verification instructions, we will
utilize an exact MMC/SD card image (as produced with the Linux 'dd'
utility) and utilize the Ubuntu Win32DiskImager [12] (with a source
project on Launchpad [13]) to enable making a bootable card via
Windows, instead of any proprietary formatting tools. The image will
be a fixed size that requires a minimum card size of 128MB. The
BeagleBoard itself can be used to repartition the card, format the
second partition, download something like the full Angstrom
Distribution demo image [14], and configure the boot.scr for your
monitor resolution.

A 64MB ramdisk image will contain all the test scripts and data files.
The current ramdisk image is the one in the ESC Chicago demo image
[15]. The u-boot patch to read 'user.scr' when the USER button is
held will allow recovery from creating a bad 'boot.scr'. Users will
be discouraged from setting environment variables in the NAND flash to
allow distribution makers to create SD card images that simply boot
without needing to mess with the u-boot environment.

Some of the remaining tasks:
* Angstrom patch: add a recipe for the ramdisk based on minimal-image
with the test scripts and u-boot scripts
* Angstrom patch: add mplayer with tv:/// support for the camera to
the ramdisk image
* Scripts: update ec2build.sh to perform the build (uses Amazon EC2
and could even be issued from the BeagleBoard)
* Scripts: update mkcard.sh to reformat wget the LinuxTag/ESC Angstrom
demo image
* Scripts: update mkcard.sh to create a card image without an SD card
(using losetup like the ESC script [16])
* Angstrom patch: should their be a task that calls mkcard.sh?
* U-boot: only boot from ramdisk.gz if USER button is held
* U-boot: present warning on Numonyx flash on xM (warn people not to
use the flash because it won't always be there)
* Linux: create new validation branch
* Angstrom patch: add recipes to point to the beagleboard-validation
x-load, u-boot, and kernel trees and use those for the ramdisk
* Angstrom u-boot scripts: add scripts to set the flash to desired
factory conditions
* Populate the 'downloads' folder on the S3 file share to make avoid
any of the source sites going down on us

[1] http://gitorious.org/beagleboard-validation
[2] http://arago-project.org/git/projects/?p=x-load-omap3.git
[3] http://gitorious.org/x-load-omap3
[4] http://git.denx.de/?p=u-boot.git
[5] http://git.denx.de/?p=u-boot/u-boot-ti.git
[6] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
[7] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
[8] http://beagleboard.org/support
[9] http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnostics
[10] http://code.google.com/p/beagleboard/issues/list
[11] http://code.google.com/p/beagleboard/wiki/BeagleBoardDiagnosticsNext
[12] https://wiki.ubuntu.com/Win32DiskImager
[13] https://launchpad.net/win32-image-writer
[14] http://www.angstrom-distribution.org/demo/beagleboard/
[15] http://beagleboard.org/esc
[16] http://www.beagleboard.org/~arago/esc/mksdimg.sh.txt

OK, time to get serious about a new verification image. There is
confusion regarding the validation process as new people are coming to
the BeagleBoard and trying to follow the many various sources of
instructions, some of which have become a bit stale. Several people
have been hacking away at the code for the BeagleBoard-xM and, now
with the camera code working for VGA and 3MP sensors, it is time to
get things cleaned up into a releasable state with instructions for
all board revisions, Bx (128MB OTG-only), C2/3 (256MB 600MHz), C4
(720MHz w/ USB fixes), and xM-Ax (512MB w/ USB hub).

We are about to find out how well I've tracked changes on the various
projects as we've been trying to get this xM release done. I've build
MLO, u-boot.bin, and uImage and uploaded them to:

http://www.beagleboard.org/~arago/xm-testing/validation-20100720/

The source trees for each are at:

http://gitorious.org/beagleboard-validation/x-load/trees/validation-20100720
http://gitorious.org/beagleboard-validation/u-boot/trees/validation-20100720
http://gitorious.org/beagleboard-validation/kernel/trees/validation-20100720

Please reply to this thread with any issues found. I haven't yet done
*any* testing, just built with what I believe is the right patch set
outside of any build tool. I'll give it a smoke test now on the xM
and then get to working on the automated building of the ramdisk and
SD card image. Please feel free to point out errors in the patch set.

You'll note that each of git tree includes a '20100720' tag. I've was
planning to add '20100720-upstream' and '20100720-base' tags to show
how many patches we are away from upstream and how many patches we are
responsible for ourselves, but that has been a bit futile so far for
the kernel.

$ git merge-base linux-omap/master 20100720
340cc2b922219239d585da55effca94d363648fa
$ git tag 20100720-upstream 340cc2b922219239d585da55effca94d363648fa
$ git log 20100720-upstream..201000720 | grep ^commit | wc -l
713
$ git merge-base psp/master 20100720
00b5086b79e58ee8e9aa5dde15fd6a44a8d65fe3
$ git tag 20100720-base 00b5086b79e58ee8e9aa5dde15fd6a44a8d65fe3
$ git log 20100720-base..20100720 | grep ^commit | wc -l
111

It seems 70 of those 111 patches are all for the camera and will be
squashed down to 4 or 5 patches.

The u-boot situation is reasonable, but maybe it just looks that way
to me because that is actually something I worked on to get the
baseline patches upstream. Our baseline is the same as upstream.
Most of those patches are from Steve Sakoman and may already be
upstream if I find the right place to start my rebase.

$ git merge-base upstream/master 20100720
ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55
$ git merge-base sakoman/master 20100720
ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55
$ git log 20100720-upstream..20100720 | grep ^commit | wc -l
45

It also seems that the psp x-load doesn't share any common commits
with Steve Sakoman's x-load, so pushing those changes is also going to
be especially fun. Our base is Steve Sakoman's x-load.

$ git log 20100720-base..20100720 | grep ^commit | wc -l
3

I just ran this on a -xM with the Micron memory. It can't find the file system, either with or without the User button pushed. I am using the ramdisk file we used before. Is there another ramdisk file I should be using? I also need the user.scr file for the button push version.

Gerald

Weird, that only picks up the first partition...

Correct. That is all I have at the moment. I am focused on the ramdisk version. I was just saying that it boots fine up to looking for the files system.

Gerald

Correct. That is all I have at the moment. I am focused on the ramdisk
version. I was just saying that it boots fine up to looking for the files
system.

Can you provide the full log with the u-boot output as well? I
probably messed something up with the default boot command, but it
should work with the user button to load the ramdisk, even if there is
no user.scr.

Here it is.

Gerald

Here it is.

Gerald

It picked up your boot.scr. I think that means I have the user button
stuff backwards somewhere. I adjusted in u-boot the polarity of the
test condition (didn't like the button being pressed returning fail
condition rather than success condition). Looking at the code for me,
however, it all seems to work.

Here's a test:

OMAP3 beagleboard.org # if userbutton; then echo yes; else echo no; fi
The user button is currently NOT pressed.
no
OMAP3 beagleboard.org #
(hold the button and press enter)
The user button is currently PRESSED.
yes

Note on the above the association between NOT/no and PRESSED/yes.
That switched with the latest u-boot. I have the default boot command
backwards from this because Greg's original patch had the association
backwards.

If I boot without the USER button pressed, it does load the ramdisk,
but I'm still having some issues with it not mounting it as well. I
found a couple of other issues. The first is that rootfstype seems to
need to be set. By setting it manually, I was able to boot. I'm
still stuck, however, on getting the console prompt. I'll check the
user.scr to see how that was done.

FYI, if you want to use the exact SD card image I have, you can do the
below (from your BeagleBoard with a USB to microSD adapter). The
mksdimg.sh script is at http://www.beagleboard.org/~arago/xm-testing/validation-20100720/.

root@beagleboard:~# wget http://www.beagleboard.org/~arago/xm-testing/validation-20100720/beagleboard-
validation.img.gz
--2010-06-05 02:12:01--
http://www.beagleboard.org/~arago/xm-testing/validation-20100720/beagleboard-validation.img.gz
Resolving www.beagleboard.org... 75.101.156.174
Connecting to www.beagleboard.org|75.101.156.174|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6492534 (6.2M) [application/x-gzip]
Saving to: `beagleboard-validation.img.gz'

100%[============================================================>]
6,492,534 1.50M/s in 4.9s

2010-06-05 02:12:06 (1.25 MB/s) - `beagleboard-validation.img.gz'
saved [6492534/6492534]

root@beagleboard:~# zcat beagleboard-validation.img.gz | dd of=/dev/
sda bs=1M
0+3199 records in
0+3199 records out
131604480 bytes (132 MB) copied, 32.6555 s, 4.0 MB/s
root@beagleboard:~# sync

I will start working with it.

Gerald

OK. I see that it is working as you say. It loads the ramdisk but is unable to load the rootfs.

Gerald

OK. I see that it is working as you say. It loads the ramdisk but is unable
to load the rootfs.

If you grab the u-boot from
http://www.beagleboard.org/~arago/xm-testing/in-work/u-boot.bin, it'll
fix the booting issue, but I'm not getting a serial console. The
source is on the validation-20100721 branch. That version should
allow you to boot with the USER button. I'm not sure why I'm not
getting a prompt over the serial port, but you can try the additional
console=tty0 as in below if you want to boot manually:

setenv bootargs 'console=tty0 console=ttyS2,115200n8 mpurate=1000
vram=16M omapfb.mode=dvi:640x480MR-16@60 omapdss.def_disp=dvi
omapfb.vram=0:8M,1:4M,2:4M root=/dev/ram0 rw rootfstype=ext2
initrd=0x81600000,64M ramdisk_size=65536'
fatload mmc 0 0x80200000 uImage
fatload mmc 0 0x81600000 ramdisk.gz
bootm 0x80200000

I've been testing the Numonyx memory as my board with that memory
doesn't seem to want to boot the kernel.

Running mtest in u-boot seems to go fine:

OMAP3 beagleboard.org # mtest 87fff000 88001000
Testing 87fff000 ... 88001000:
Iteration: 20943

But, I don't seem to be able to boot the kernel:

OMAP3 beagleboard.org # printenv bootargs
bootargs=console=tty0 console=ttyS2,115200n8 mpurate=1000
buddy=unknown vram=12M omapfb.mode=dvi:640x480MR-16@60
omapdss.def_disp=dvi root=/dev/ram0 rw rw ramdisk_size=65536
initrd=0x81600000,64M rootfstype=ext2
OMAP3 beagleboard.org # bootm 80200000
## Booting kernel from Legacy Image at 80200000 ...
   Image Name: Linux-2.6.32-15075-g9e7bd83
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 3196712 Bytes = 3 MB
   Load Address: 80008000
   Entry Point: 80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.......................................................................................................................................................................................................................
done, booting the kernel.

I don't have a JTAG setup handy, so I'm just performing memory pokes
after resetting. Per http://elinux.org/Kernel_Debugging_Tips:

linux-2.6 $ grep __log_buf System.map
c06a7f94 b __log_buf

OMAP3 beagleboard.org # md 806a7f94 1000
806a7f94: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version
806a7fa4: 362e3220 2d32332e 37303531 39672d35 2.6.32-15075-g9
806a7fb4: 64623765 28203338 67617261 6f64406f e7bd83 (arago@do
806a7fc4: 312d556d 31332d32 2d38332d 422d3130 mU-12-31-38-01-B
806a7fd4: 35302d44 67282029 76206363 69737265 D-05) (gcc versi
806a7fe4: 34206e6f 312e322e 6f432820 6f536564 on 4.2.1 (CodeSo
806a7ff4: 65637275 53207972 6372756f 20797265 urcery Sourcery
806a8004: 202b2b47 6574694c 30303220 2d337137 G++ Lite 2007q3-
806a8014: 29293135 20342320 20646557 206c754a 51)) #4 Wed Jul
806a8024: 31203132 38313a30 2039313a 20544443 21 10:18:19 CDT
806a8034: 30313032 3e343c0a 3a555043 4d524120 2010.<4>CPU: ARM
806a8044: 50203776 65636f72 726f7373 31345b20 v7 Processor [41
806a8054: 30636633 205d3238 69766572 6e6f6973 3fc082] revision
806a8064: 28203220 764d5241 202c2937 313d7263 2 (ARMv7), cr=1
806a8074: 33356330 0a663763 433e343c 203a5550 0c53c7f.<4>CPU:
806a8084: 54504956 6e6f6e20 61696c61 676e6973 VIPT nonaliasing
806a8094: 74616420 61632061 2c656863 50495620 data cache, VIP
806a80a4: 6f6e2054 696c616e 6e697361 6e692067 T nonaliasing in
806a80b4: 75727473 6f697463 6163206e 0a656863 struction cache.
806a80c4: 4d3e343c 69686361 203a656e 50414d4f <4>Machine: OMAP
806a80d4: 65422033 656c6761 616f4220 3c0a6472 3 Beagle Board.<
806a80e4: 654d3e34 79726f6d 6c6f7020 3a796369 4>Memory policy:
806a80f4: 43434520 73696420 656c6261 44202c64 ECC disabled, D
806a8104: 20617461 68636163 72772065 62657469 ata cache writeb
806a8114: 0a6b6361 4f3e373c 6f6e206e 30206564 ack.<7>On node 0
806a8124: 746f7420 61706c61 3a736567 31333120 totalpages: 131
806a8134: 0a323730 663e373c 5f656572 61657261 072.<7>free_area
806a8144: 696e695f 6f6e5f74 203a6564 65646f6e _init_node: node
806a8154: 202c3020 61646770 30632074 36316136 0, pgdat c06a16
806a8164: 202c3033 65646f6e 6d656d5f 70616d5f 30, node_mem_map
806a8174: 36306320 30306266 373c0a30 4e20203e c06fb000.<7> N
806a8184: 616d726f 6f7a206c 203a656e 34323031 ormal zone: 1024
806a8194: 67617020 75207365 20646573 20726f66 pages used for
806a81a4: 6d6d656d 3c0a7061 20203e37 6d726f4e memmap.<7> Norm
806a81b4: 7a206c61 3a656e6f 70203020 73656761 al zone: 0 pages
806a81c4: 73657220 65767265 373c0a64 4e20203e reserved.<7> N
806a81d4: 616d726f 6f7a206c 203a656e 30303331 ormal zone: 1300
806a81e4: 70203834 73656761 494c202c 62204f46 48 pages, LIFO b
806a81f4: 68637461 0a31333a 4f3e363c 3350414d atch:31.<6>OMAP3
806a8204: 2f303336 37334d44 45203033 302e3153 630/DM3730 ES1.0
806a8214: 326c2820 68636163 76692065 67732061 (l2cache iva sg
806a8224: 656e2078 69206e6f 31207073 686d3239 x neon isp 192mh
806a8234: 6c635f7a 0a29206b 533e363c 3a4d4152 z_clk ).<6>SRAM:
806a8244: 70614d20 20646570 30206170 32303478 Mapped pa 0x402
806a8254: 30303030 6f742030 20617620 65667830 00000 to va 0xfe
806a8264: 30303034 73203030 3a657a69 31783020 400000 size: 0x1
806a8274: 30303030 363c0a30 7365523e 69767265 00000.<6>Reservi
806a8284: 3120676e 32383532 20323139 65747962 ng 12582912 byte
806a8294: 44532073 204d4152 20726f66 4d415256 s SDRAM for VRAM
806a82a4: 3e343c0a 6c697542 20312074 656e6f7a .<4>Built 1 zone
806a82b4: 7473696c 6e692073 6e6f5a20 726f2065 lists in Zone or
806a82c4: 2c726564 626f6d20 74696c69 72672079 der, mobility gr
806a82d4: 6970756f 6f20676e 20202e6e 61746f54 ouping on. Tota
806a82e4: 6170206c 3a736567 30333120 0a383430 l pages: 130048.
806a82f4: 4b3e353c 656e7265 6f63206c 6e616d6d <5>Kernel comman
806a8304: 696c2064 203a656e 736e6f63 3d656c6f d line: console=
806a8314: 53797474 31312c32 30303235 6d20386e ttyS2,115200n8 m
806a8324: 61727570 313d6574 20303030 64647562 purate=1000 budd
806a8334: 6e753d79 776f6e6b 7276206e 313d6d61 y=unknown vram=1
806a8344: 6f204d32 6670616d 6f6d2e62 643d6564 2M omapfb.mode=d
806a8354: 363a6976 34783034 524d3038 4036312d vi:640x480MR-16@
806a8364: 6f203036 6470616d 642e7373 645f6665 60 omapdss.def_d
806a8374: 3d707369 20697664 746f6f72 65642f3d isp=dvi root=/de
806a8384: 61722f76 7220306d 77722077 6d617220 v/ram0 rw rw ram
806a8394: 6b736964 7a69735f 35363d65 20363335 disk_size=65536
806a83a4: 74696e69 303d6472 36313878 30303030 initrd=0x8160000
806a83b4: 34362c30 6f72204d 7366746f 65707974 0,64M rootfstype
806a83c4: 7478653d 363c0a32 6165423e 20656c67 =ext2.<6>Beagle
806a83d4: 61707865 6f69736e 616f626e 203a6472 expansionboard:
806a83e4: 6e6b6e75 0a6e776f 503e363c 68204449 unknown.<6>PID h
806a83f4: 20687361 6c626174 6e652065 65697274 ash table entrie
806a8404: 32203a73 20383430 64726f28 203a7265 s: 2048 (order:
806a8414: 38202c31 20323931 65747962 3c0a2973 1, 8192 bytes).<
806a8424: 65443e36 7972746e 63616320 68206568 6>Dentry cache h
806a8434: 20687361 6c626174 6e652065 65697274 ash table entrie
806a8444: 36203a73 36333535 726f2820 3a726564 s: 65536 (order:
806a8454: 202c3620 31323632 62203434 73657479 6, 262144 bytes
806a8464: 363c0a29 6f6e493e 632d6564 65686361 ).<6>Inode-cache
806a8474: 73616820 61742068 20656c62 72746e65 hash table entr
806a8484: 3a736569 37323320 28203836 6564726f ies: 32768 (orde
806a8494: 35203a72 3331202c 32373031 74796220 r: 5, 131072 byt
806a84a4: 0a297365 4d3e363c 726f6d65 00003a79 es).<6>Memory:..
806a84b4: 00000000 00000000 00000000 746f7420 ............ tot
806a84c4: 000a6c61 00000000 00000000 00000000 al..............
806a84d4: 00000000 00000000 00000000 00000000 ................
806a84e4: 00000000 00000000 00000000 00000000 ................
806a84f4: 00000000 00000000 00000000 6e69204b ............K in
806a8504: 202c7469 68204b30 6d686769 0a296d65 it, 0K highmem).
806a8514: 00000000 00000000 00000000 00000000 ................
806a8524: 00000000 00000000 00000000 00000000 ................
806a8534: 00000000 00000000 00000000 6566656e ............nefe
806a8544: 20686374 31783028 29383030 20746120 tch (0x1008) at
806a8554: 66647830 30303038 000a6330 00000000 0xdf80000c......
806a8564: 00000000 00000000 00000000 00000000 ................
806a8574: 00000000 00000000 00000000 73616c3e ............>las
806a8584: 79732074 20736673 656c6966 000a203a t sysfs file: ..
806a8594: 00000000 00000000 00000000 00000000 ................
806a85a4: 00000000 00000000 00000000 00000000 ................
806a85b4: 00000000 00000000 00000000 28202064 ............d (
806a85c4: 2e362e32 312d3233 35373035 6539672d 2.6.32-15075-g9e
806a85d4: 38646237 34232033 00000a29 00000000 7bd83 #4).......
806a85e4: 00000000 00000000 00000000 00000000 ................
806a85f4: 00000000 00000000 00000000 302f6330 ............0c/0
806a8604: 30313578 0000000a 00000000 00000000 x510............
806a8614: 00000000 00000000 00000000 00000000 ................
806a8624: 00000000 00000000 00000000 00000000 ................

I can't tell much from that, but it seems to be failing in something
related to the memory initialization. Helpful hints from observers
are quite welcome here. :slight_smile:

I2C seems to be broken, again. Any chance I can get the syntax of the month?

Gerald

I2C seems to be broken, again. Any chance I can get the syntax of the
month?

I did a quick test with the latest test image
(http://www.beagleboard.org/~arago/xm-testing/validation-20100722/beagleboard-validation.img.gz):

root@beagleboard:~# i2cdump -y 0x3 0x50
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 1e 6d 4a 4b fe 95 00 00 …?mJK??..
10: 04 11 01 03 ea 22 1b 78 ea 32 31 a3 57 4c 9d 25 ???"?x?21?WL?%
20: 11 50 54 a5 6a 80 31 4f 45 4f 61 4f 81 80 01 01 ?PT?j?1OEOaO???
30: 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 ???0*.?Q.*@0p
40: 13 00 52 0e 11 00 00 1e 00 00 00 fd 00 38 4b 1e ?.R??..?..?.8K?
50: 47 0b 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c G?.? …?.L
60: 31 39 33 33 54 52 0a 20 20 20 20 20 00 00 00 fc 1933TR? …?
70: 00 20 0a 20 20 20 20 20 20 20 20 20 20 20 00 9e . ? .?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …

My monitor is an LG L1933TR, so I believe this is a proper EDID read.

This image includes 'mplayer' in the ramdisk image, but no media. I'm
thinking I will just put a tiny, cut-off version of BigBuckBunny in
the FAT partition. I'd love to get a 'testcamera' script in my
validation script repository.

By default, /dev/mmcblk0 doesn't seem to show up. A mknod operation
likely needs to be documented to make it clear how to mount an MMC/SD
card using this image. If I remove and re-insert the card, I get the
following:

root@beagleboard:~# mmc0: card 0007 removed
mmc0: new high speed SD card at address 0007
mmcblk0: mmc0:0007 SD01G 972 MiB
mmcblk0: p1
FAT: bogus number of reserved sectors
VFS: Can't find a valid FAT filesystem on dev mmcblk0.

Since the MMC/SD card is partitioned, that is actually expected, but
alarming to some people. You can see here that I can mount fine:

root@beagleboard:~# mount -t vfat /dev/mmcblk0p1 /mnt
root@beagleboard:~# ls /mnt
MLO md5sum.txt ramdisk.gz u-boot.bin uImage

One bit of very minor good news, the USER button is an event again in Linux.

root@beagleboard:~# evtest /dev/input/event0
Input driver version is 1.0.0
Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100
Input device name: "gpio-keys"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 276 (ExtraBtn)
Testing ... (interrupt to exit)
Event: time 1279809569.788788, type 1 (Key), code 276 (ExtraBtn), value 1
Event: time 1279809569.788818, -------------- Report Sync ------------
Event: time 1279809569.883148, type 1 (Key), code 276 (ExtraBtn), value 0
Event: time 1279809569.883148, -------------- Report Sync ------------
Event: time 1279809570.113186, type 1 (Key), code 276 (ExtraBtn), value 1
Event: time 1279809570.113186, -------------- Report Sync ------------
Event: time 1279809570.224854, type 1 (Key), code 276 (ExtraBtn), value 0
Event: time 1279809570.224854, -------------- Report Sync ------------
Event: time 1279809570.448181, type 1 (Key), code 276 (ExtraBtn), value 1
Event: time 1279809570.448212, -------------- Report Sync ------------
Event: time 1279809570.567871, type 1 (Key), code 276 (ExtraBtn), value 0
Event: time 1279809570.567871, -------------- Report Sync ------------

Once I get a nice set of build and test scripts, hopefully we can
avoid having as many regressions.

I'm going into a phase of finding issues with the validation tests
before doing a bit more build automation and getting out a real
release candidate. :-/

I2C seems to be broken, again. Any chance I can get the syntax of the
month?

I did a quick test with the latest test image
(http://www.beagleboard.org/~arago/xm-testing/validation-20100722/beagleboard-validation.img.gz):

root@beagleboard:~# i2cdump -y 0x3 0x50
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 ff ff ff ff ff ff 00 1e 6d 4a 4b fe 95 00 00 …?mJK??..
10: 04 11 01 03 ea 22 1b 78 ea 32 31 a3 57 4c 9d 25 ???"?x?21?WL?%
20: 11 50 54 a5 6a 80 31 4f 45 4f 61 4f 81 80 01 01 ?PT?j?1OEOaO???
30: 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 ???0*.?Q.*@0p
40: 13 00 52 0e 11 00 00 1e 00 00 00 fd 00 38 4b 1e ?.R??..?..?.8K?
50: 47 0b 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c G?.? …?.L
60: 31 39 33 33 54 52 0a 20 20 20 20 20 00 00 00 fc 1933TR? …?

...

My monitor is an LG L1933TR, so I believe this is a proper EDID read.

...

Once I get a nice set of build and test scripts, hopefully we can
avoid having as many regressions.

I'm going into a phase of finding issues with the validation tests
before doing a bit more build automation and getting out a real
release candidate. :-/

Oh, another usability issue I don't like is that because I listened to
Koen and others on the IRC channel about the behavior of ignoring
ramdisk.gz if the USER button is not pressed, you need to hold the
USER button or it won't boot. Once we have the demo image on the
second partition, that'll be fine, but I want this card image to live
as a validation/recovery disk, even enabling networking such that you
could repartition and download the latest demo (especially if the demo
has export restriction issues).

Very minor issue with u-boot:
* 'rw' is included twice in the boot arguments.

Minor issue with ramdisk image:
* Console prompt doesn't show up for a long time. The serial prompt
shows up quickly.

Also, I haven't figured out how to enable networking on this image. I
think I'm missing a kernel module for it and perhaps a few startup
scripts.

Gerald

> OK. I see that it is working as you say. It loads the ramdisk but is
> unable
> to load the rootfs.

...

I've been testing the Numonyx memory as my board with that memory
doesn't seem to want to boot the kernel.

Running mtest in u-boot seems to go fine:

OMAP3 beagleboard.org # mtest 87fff000 88001000
Testing 87fff000 ... 88001000:
Iteration: 20943

But, I don't seem to be able to boot the kernel:

...

I can't tell much from that, but it seems to be failing in something
related to the memory initialization. Helpful hints from observers
are quite welcome here. :slight_smile:

>
> Gerald
>
>>
>> I will start working with it.
>>
>> Gerald
>>
>>>
>>> > Here it is.
>>> >
>>> > Gerald
>>>

...

The bunny license doesn't allow that by the looks of it...

The i2c command I am referring to is the one in Uboot. Entering i2c dev 2 locks up the processor.

I also see the invalid VFAT on USB thumbdrives.

Gerald

I decided to test this in u-boot, but the 'i2c' command is hanging.

The probe of the default bus behaves as expected:

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

When I try to switch busses to read the EDID, I get this hang:

OMAP3 beagleboard.org # i2c dev 2
<hang>

Add this one to the u-boot to-do list. :frowning:

I also found that 'mtdparts' needs to be set and I need to test 'nand
info'. Still testing...

The i2c command I am referring to is the one in Uboot. Entering i2c dev 2
locks up the processor.

k, I'm seeing that too, as I just reported. I'll get to fixing it,
unless someone else gets to it.

I also see the invalid VFAT on USB thumbdrives.

That should also be expected.

Sounds like a great generator of a few emails from users.

Gerald

hello jason

I am Srujan from UHCL I have a new Beagle board I tried to verify it I
connected the USB-OTG cable to power it and a monitor through HDMI-DVI-
D cable I saw the LEDs glow but I did not see anything on the monitor
I waited for soo long but nothing came up, the monitor is working
though, can you tell me whats the problem or do you have any reference
that I can check in the manual or any website??

Thank you.