If you don’t mind, could you please submit your email using a new thread so as not to hijack this one? You will get better help solving your issue that way.
Thank you!
Gerald
It has already generated a few some time back. Not sure what we can do about it.
It has already generated a few some time back. Not sure what we can do about it.
Stop automounting or stop the errors from showing and I don't like either option 
regards,
Koen
I2C seems to be broken, again. Any chance I can get the syntax of the
month?
Tracking down the history, there seems to be a minor difference in the
two patches to enable the multibus I2C:
http://gitorious.org/beagleboard-default-u-boot/beagle_uboot_revc4/commit/9bb1c3501c8f098dac6e224c99e409ebf92b0ab9
http://gitorious.org/beagleboard-validation/u-boot/commit/d56afbe8ee8514916864979c8509e24cc206ce0e
I'm not sure why, but we may need to add the following line and try it out:
#define CONFIG_SYS_I2C_NOPROBES {0x0, 0x0}
I used Khasim's patch with the above line:
http://www.beagleboard.org/~arago/xm-testing/validation-20100723/beagleboard-validation.img.gz
It will be a bit before I can test this myself. I'd appreciate if
anyone tried the I2C commands.
I've got an updated MLO patch from Steve Kipisz that now fixes the
dual Numonyx/Micron memory support, so we can switch between suppliers
and start getting these xM boards shipping.
The test image is at:
http://www.beagleboard.org/~arago/xm-testing/validation-20100727/
$ zcat beagleboard-validation*.img.gz | dd of=/dev/your/sd/card
(Or, decompress with 7-zip and use Ubuntu's Image Writer for Windows)
I'd appreciate any effort to run that image on Bx and Cx boards,
especially around the USER button and LED behaviors in u-boot and
networking behaviors in Linux. I haven't tried implementing the new
boot concept of reading from the flash via a command (and would love
any patches to do so).
I2C hang issue still exists in u-boot, where I added a couple of debug
printfs. I don't even see any of the debug statements if I type "i2c
dev".
Sources are at:
* x-load: http://gitorious.org/beagleboard-validation/x-load/commit/a25b926ff963a1866e26b11a4dac742564618375
* u-boot: http://gitorious.org/beagleboard-validation/u-boot/commit/7626dd700534cdd14937bfccabc22c1507a3a335
* linux: http://gitorious.org/beagleboard-validation/linux/commit/9e7bd83cf0945b445905e0c34368d2b7f18040a1
* beagleboard-test-image:
http://gitorious.org/~Jadon/angstrom/jadon-openembedded/commit/b1607b7ae71f37294598571c50f9e6655bf959e9
Would it be possible to get the user.scr and boot.scr that you are using so that everyone is on the same page in their testing?
Gerald
The audio record and play is not working.
The camera is not working.
Gerald
The audio record and play is not working.
The camera is not working.
I've been focused today on the build infrastructure, rather than
fixing those bugs. The build below reflects the latest state of
Angstrom, such that it is as clear and as flexible as can be given
today's tools for people to impact the image. Unfortunately, the
image being built is bogus:
http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/beagleboard-validation-201008040532.img.gz
The individual files seem to be OK:
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/MLO
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/u-boot.bin
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/uImage
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/ramdisk.gz
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/boot.scr
* http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/user.scr
The build steps I utilized are documented in:
http://gitorious.org/beagleboard-validation/scripts/blobs/master/ec2build.sh
(http://gitorious.org/beagleboard-validation/scripts/commit/00303e7d6d0789bc371837954279be0c114b7d88)
I did roughly './ec2build.sh run-build', but I haven't run it 100%
clean yet. I'm waiting for the following patch to be applied:
http://patchwork.openembedded.org/patch/2552/
When I wake up, I'm going to try the image building bits again. The
build process is still running at about 2 hours. I'd be really
grateful if folks would look over the EC2 machine configuration and
the build scripts for feedback on the image building and on how to
speed up the builds. With running the entire build from a 'ramfs'
folder, I'm a bit surprised it takes so long. Oh, I need to add the
parts to restore the downloads folder that I've uploaded on S3 as
well.
The audio record and play is not working.
The camera is not working.I've been focused today on the build infrastructure, rather than
fixing those bugs. The build below reflects the latest state of
Angstrom, such that it is as clear and as flexible as can be given
today's tools for people to impact the image. Unfortunately, the
image being built is bogus:
http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008040532.img/beagleboard-validation-201008040532.img.gz
See Bucket listing
for the latest build out of Angstrom. My SD card image building
script (even without trying to avoid root access) is still having
problems.
Here is a simple test I did to try to figure out what was going wrong
(on Ubuntu 10.04):
$ sudo dd if=/dev/zero of=/tmp/dummy.txt bs=1 count=10
10+0 records in
10+0 records out
10 bytes (10 B) copied, 0.0538296 s, 0.2 kB/s
$ sudo losetup -v /dev/loop0 /tmp/dummy.txt
Loop device is /dev/loop0
$ sudo dd if=/dev/zero of=/dev/loop0 bs=1 count=8
dd: writing `/dev/loop0': No space left on device
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000272016 s, 0.0 kB/s
What's up with that?
$ sudo losetup -v /dev/loop0
/dev/loop0: [0801]:16726 (/tmp/dummy.txt)
Seems to tell me it is hooked up fine. Any ideas why the "No space
left on device" error?
Can you try with some more realistic sizes like a 10MB loop file?
regards,
Koen
Hi Jason,
$ sudo dd if=/dev/zero of=/tmp/dummy.txt bs=1 count=10
$ sudo dd if=/dev/zero of=/dev/loop0 bs=1 count=8
dd: writing `/dev/loop0': No space left on device
What's up with that?$ sudo losetup -v /dev/loop0
/dev/loop0: [0801]:16726 (/tmp/dummy.txt)Seems to tell me it is hooked up fine. Any ideas why the "No space
left on device" error?
Is it intended that you file is 10 bytes? Just tried the same and I get same
kind of error. Making the size larger (i.e. 10k and filling in 8k of data
afterwards) makes the error disappear. I think you hit some kind of corner
case with your small test file, since I have used the method with great luck
previously...
I'm likewise able to copy 10k of data into a 10k data file, so I think there
is a problem when having a 10 bytes file...
Best regards
Søren
Hi Jason,
$ sudo dd if=/dev/zero of=/tmp/dummy.txt bs=1 count=10
$ sudo dd if=/dev/zero of=/dev/loop0 bs=1 count=8
dd: writing `/dev/loop0': No space left on device
What's up with that?$ sudo losetup -v /dev/loop0
/dev/loop0: [0801]:16726 (/tmp/dummy.txt)Seems to tell me it is hooked up fine. Any ideas why the "No space
left on device" error?Is it intended that you file is 10 bytes? Just tried the same and I get same
kind of error. Making the size larger (i.e. 10k and filling in 8k of data
afterwards) makes the error disappear. I think you hit some kind of corner
case with your small test file, since I have used the method with great luck
previously...I'm likewise able to copy 10k of data into a 10k data file, so I think there
is a problem when having a 10 bytes file...
OK, how about this test?
$ sudo mkdir -p /mnt/dummy
$ sudo dd if=/dev/zero of=/tmp/dummy.img bs=8225280 count=16
16+0 records in
16+0 records out
131604480 bytes (132 MB) copied, 0.352835 s, 373 MB/s
$ sudo losetup -v -o 32256 /dev/loop0 /tmp/dummy.img
Loop device is /dev/loop0
$ sudo mkfs.vfat /dev/loop0 -n BEAGLE -F 32 120456
mkfs.vfat 3.0.7 (24 Dec 2009)
Warning: block count mismatch: found 128488 but assuming 120456.
Loop device does not match a floppy size, using default hd params
$ sudo mount /dev/loop0 /mnt/dummy
$ sudo touch /mnt/dummy/dummy.txt
$ sudo umount /dev/loop0
$ sudo losetup -d /dev/loop0
$ sudo losetup -v -o 32256 /dev/loop0 /tmp/dummy.img
Loop device is /dev/loop0
$ sudo mount /dev/loop0 /mnt/dummy
$ ls -l /mnt/dummy
total 0
-rwxr-xr-x 1 root root 0 2010-08-05 11:48 dummy.txt
Isn't it always this way... when I write a test, it works. Here's an
attempt to redo the real deal following the above steps a bit closer:
$ sudo losetup -v -o 32256 /dev/loop0 beagleboard-validation-201008050445.img
Loop device is /dev/loop0
$ sudo mkfs.vfat /dev/loop0 -n BEAGLE -F 32 120456
mkfs.vfat 3.0.7 (24 Dec 2009)
Warning: block count mismatch: found 128488 but assuming 120456.
Loop device does not match a floppy size, using default hd params
$ sudo mount /dev/loop0 /mnt/sd_image1
$ sudo cp -R MLO u-boot.bin uImage ramdisk.gz boot.scr user.scr
md5sum.txt /mnt/sd_image1/
$ sudo umount /dev/loop0
$ sudo losetup -d /dev/loop0
$ sudo sh -c 'gzip -c beagleboard-validation-201008050445.img >
beagleboard-validation-201008050445.img.gz'
$ sudo losetup -v -o 32256 /dev/loop0 beagleboard-validation-201008050445.img
Loop device is /dev/loop0
$ sudo mount /dev/loop0 /mnt/sd_image1
mount: you must specify the filesystem type
$ sudo mount -t vfat /dev/loop0 /mnt/sd_image1
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
DOH!!!
This is what I use in narcissus and works:
http://gitorious.org/angstrom/narcissus/blobs/master/scripts/assemble-image.sh#line52
If you prefix that with http://gitorious.org/angstrom/openembedded/blobs/org.openembedded.dev/contrib/angstrom/omap3-mkcard.sh#line16 to generate the partitions you should have a working solution.
regards,
Koen
Hi Jason,
$ sudo losetup -v -o 32256 /dev/loop0
beagleboard-validation-201008050445.img
Loop device is /dev/loop0
$ sudo mkfs.vfat /dev/loop0 -n BEAGLE -F 32 120456
mkfs.vfat 3.0.7 (24 Dec 2009)
Warning: block count mismatch: found 128488 but assuming 120456.
Loop device does not match a floppy size, using default hd params
$ sudo mount /dev/loop0 /mnt/sd_image1
$ sudo cp -R MLO u-boot.bin uImage ramdisk.gz boot.scr user.scr
md5sum.txt /mnt/sd_image1/
$ sudo umount /dev/loop0
$ sudo losetup -d /dev/loop0
$ sudo sh -c 'gzip -c beagleboard-validation-201008050445.img >
beagleboard-validation-201008050445.img.gz'
$ sudo losetup -v -o 32256 /dev/loop0
beagleboard-validation-201008050445.img
Loop device is /dev/loop0
$ sudo mount /dev/loop0 /mnt/sd_image1
mount: you must specify the filesystem type
$ sudo mount -t vfat /dev/loop0 /mnt/sd_image1
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or soDOH!!!
Not really sure - Instead of giving the 120456 parameter to mkfs.vfat I used
the --sizelimit option to losetup for limiting the size of the loop-device
to the size of the partition - Maybe this helps?
Best regards
Søren
Latest files testing:
Ethernet now works.
Camera does not work. You need to add “camera=lbcm3m1” to boot.scr and user.scr.
Gerald
Latest files testing:
Ethernet now works.
Great! Thanks Koen for the update to netbase.
Camera does not work. You need to add "camera=lbcm3m1" to boot.scr and
user.scr.
I was looking for a u-boot patch from Steve Kipisz to do that, instead
of putting it in the boot.scr.
OK. I tried stopping UBoot and entering it in manually, but that did not work. So, there may be other stuff that is not correct either. I will wait for the final solution.
Gerald
I started with a working solution with my
http://gitorious.org/beagleboard-validation/scripts/blobs/master/mksdimg.sh,
which was based on something similar I did for the ESC images a couple
years ago. It is why it broke that confused me. Here's my latest:
$ sudo dd if=/dev/zero of=/tmp/beagleboard-validation-20100805b.img
bs=8225280 count=16
16+0 records in
16+0 records out
131604480 bytes (132 MB) copied, 0.370766 s, 355 MB/s
$ sudo losetup -v -o 32256 /dev/loop0 /tmp/beagleboard-validation-20100805b.img
Loop device is /dev/loop0
$ sudo mkfs.vfat /dev/loop0 -n BEAGLE -F 32 120456
mkfs.vfat 3.0.7 (24 Dec 2009)
Warning: block count mismatch: found 128488 but assuming 120456.
Loop device does not match a floppy size, using default hd params
$ sudo mount /dev/loop0 /mnt/sd_image1
$ sudo cp -R MLO u-boot.bin uImage ramdisk.gz boot.scr user.scr
md5sum.txt /mnt/sd_image1/
$ sudo umount /dev/loop0
$ sudo losetup -d /dev/loop0
$ sudo losetup -v -o 32256 /dev/loop0 /tmp/beagleboard-validation-20100805b.img
Loop device is /dev/loop0
$ sudo mount /dev/loop0 /mnt/sd_image1
$ ls -l /mnt/sd_image1
total 18871
-rwxr-xr-x 1 root root 490 2010-08-05 14:32 boot.scr
-rwxr-xr-x 1 root root 214 2010-08-05 14:33 md5sum.txt
-rwxr-xr-x 1 root root 24296 2010-08-05 14:32 MLO
-rwxr-xr-x 1 root root 15896169 2010-08-05 14:32 ramdisk.gz
-rwxr-xr-x 1 root root 209632 2010-08-05 14:32 u-boot.bin
-rwxr-xr-x 1 root root 3190408 2010-08-05 14:32 uImage
-rwxr-xr-x 1 root root 483 2010-08-05 14:32 user.scr
Bingo!
I think it was simply the fact that I was working on top of the S3
fuse-based file system.
I fixed the script and created this output:
http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008051440.img/list.html
Lots of pointless changes in the below patch (stabbing in the dark),
as the only thing that seemed to matter was moving the image file to
/tmp:
http://gitorious.org/beagleboard-validation/scripts/commit/1705ebafbc78c5216516df583e9598b9d5ff3ba8
Now, I can stop focusing on build/release quite as much and move back
to fixing Gerald's functional issues (and know that the result will be
reproducible). The scripts likely need to be improved to be able to
run cleaner on a native Ubuntu 10.04 LTS system, rather than remotely
over such a system on Amazon EC2, but those updates can wait. Now to
bug Steve Kipisz about those u-boot patches to fix the camera...