BeagleBoard verification image task list
Jason Kridner
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
Jason Kridner
> 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
Coley, Gerald
Gerald
---------------------------------------------------------------------
---------------------------------------------------------------------
NET: Registered protocol family 17
NET: Registered protocol family 15
Bluetooth: L2CAP ver 2.14
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
lib80211: common routines for IEEE802.11 drivers
ThumbEE CPU extension supported.
Power Management for TI OMAP3.
Unable to set L3 frequency (400000000)
Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/1000 MHz
IVA2 clocking rate: 800 MHz
SmartReflex driver initialized
omap3beaglelmb: Driver registration complete
usb 2-2: new high speed USB device using ehci-omap and address 2
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
registered taskstats version 1
fbcvt: 1280x1024@60: CVT Name - 1.310M4-R
mmc0: new high speed SDHC card at address 0001
mmcblk0: mmc0:0001 00000 3.67 GiB
mmcblk0: p1
Console: switching to colour frame buffer device 160x64
hub 2-2:1.0: USB hub found
regulator_init_complete: incomplete constraints, leaving VAUX3 on
hub 2-2:1.0: 5 ports detected
regulator_init_complete: incomplete constraints, leaving VDAC on
twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
Please append a correct "root=" boot option; here are the available partitions:
b300 3849216 mmcblk0 driver: mmcblk
b301 3849184 mmcblk0p1
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)
Gerald
http://www.beagleboard.org/~arago/xm-testing/validation-20100720/
http://ap-fpdsp-swapps.dal.design.ti.com/index.php/BeagleBoard
Koen Kooi
> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>
Gerald Coley
Jason Kridner
> 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.
Gerald Coley
Beagle xM Rev A
Loading u-boot.bin from mmc
OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz,
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 512 MB
NAND: 0 MiB
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Unrecognized expansion board: 0
Beagle xM Rev A
Die ID #5ce60000061000000156166b0a014024
Hit any key to stop autoboot: 3 2 1 0
mmc1 is available
The user button is currently PRESSED.
reading boot.scr
1560 bytes read
Running bootscript from mmc ...
Setting Specific Environment from MMC boot.scr
Unknown command 'xMA' - try 'help'
Unknown command 'xMA' - try 'help'
bootcmd=if mmc init ${mmcdev}; then if userbutton; then setenv bootscr boot.scr; if run loadbootscript; then run bootscript; else if run loaduimage; then run mmcboot; else run nandboot; fi; fi; else setenv bootscr user.scr;if run loaduimage; then if run loadramdisk; then run ramboot; else run mmcboot; fi; fi; fi; else run nandboot; fi
bootdelay=3
baudrate=115200
loadaddr=0x80200000
rdaddr=0x81600000
usbtty=cdc_acm
console=ttyS2,115200n8
optargs=
mmcdev=1
mmcrootfstype=ext3 rootwait
nandrootfstype=jffs2
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} ${bootscr}
ramargs=setenv bootargs console=${console} ${optargs} mpurate=${mpurate} buddy=${buddy} vram=${vram} omapfb.mode=dvi:${dvimode} omapdss.def_disp=${defaultdisplay} root=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M rootfstype=
loadramdisk=fatload mmc ${mmcdev} ${rdaddr} ramdisk.gz
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
ramboot=echo Booting from ramdisk ...; run ramargs; bootm ${loadaddr}
buddy=unknown
beaglerev=xMA
mpurate=1000
dieid#=5ce60000061000000156166b0a014024
bootscr=boot.scr
filesize=618
setbase=setenv baseargs ${memmap} console=${console} mpurate=${mpurate} buddy=${buddy} vram=${vram} musb_hdrc.fifomode=${musbfifomode} omapfb.mode=${defaultdisplay}:${dvimode} omapdss.def_disp=${defaultdisplay}
nandroot=root=/dev/mtdblock4 rw rootfstype=jffs2
nandargs=run setbase; setenv bootargs ${baseargs} ${nandroot}
nandloaduimage=nand read ${loadaddr} 280000 400000
nandboot=run nandloadimage; bootm ${loadaddr}
mmcroot=root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
mmcargs=run setbase; setenv bootargs ${baseargs} ${mmcroot}
mmcloaduimage=fatload mmc 0 ${loadaddr} uImage
mmcboot=run mmcloaduimage; bootm ${loadaddr}
musbfifomode=5
vram=16M omapfb.vram=0:8M,1:4M,2:4M
defaultdisplay=dvi
dvimode=1280x1024MR-32@60
baseargs=mem=80M mem=384M@0x88000000 console=ttyS2,115200n8 mpurate=1000 buddy=unknown vram=16M omapfb.vram=0:8M,1:4M,2:4M musb_hdrc.fifomode=5 omapfb.mode=dvi:1280x1024MR-32@60 omapdss.def_disp=dvi
bootargs=mem=80M mem=384M@0x88000000 console=ttyS2,115200n8 mpurate=1000 buddy=unknown vram=16M omapfb.vram=0:8M,1:4M,2:4M musb_hdrc.fifomode=5 omapfb.mode=dvi:1280x1024MR-32@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
reading uImage
3196776 bytes read
## 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 ...
Linux version 2.6.32-15075-g9e7bd83 (arago@domU-12-31-38-01-BD-05) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #4 Wed Jul 21 10:18:19 CDT 2010
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000
Reserving 16777216 bytes SDRAM for VRAM
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 117760
Kernel command line: mem=80M mem=384M@0x88000000 console=ttyS2,115200n8 mpurate=1000 buddy=unknown vram=16M omapfb.vram=0:8M,1:4M,2:4M musb_hdrc.fifomode=5 omapfb.mode=dvi:1280x1024MR-32@60 omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
Beagle expansionboard: unknown
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 80MB 384MB = 464MB total
Memory: 447104KB available (5912K code, 600K data, 176K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
OMAP GPIO hardware version 2.5
OMAP clockevent source: GPTIMER12 at 32768 Hz
Console: colour dummy device 80x30
Calibrating delay loop... 527.27 BogoMIPS (lpj=2060288)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
NET: Registered protocol family 16
Found NAND on CS0
Registering NAND on CS0
Unable to get DVI reset GPIO
Target VDD1 OPP = 4, VDD2 OPP = 2
OMAP DMA hardware revision 5.0
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c_omap i2c_omap.1: bus 1 rev4.0 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
regulator: VUSB1V5: 1500 mV normal standby
regulator: VUSB1V8: 1800 mV normal standby
regulator: VUSB3V1: 3100 mV normal standby
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
regulator: VMMC1: 1850 <--> 3150 mV normal standby
regulator: VDAC: 1800 mV normal standby
regulator: VPLL2: 1800 mV normal standby
regulator: VSIM: 1800 <--> 3000 mV normal standby
regulator: VAUX3: 1800 mV normal standby
regulator: VAUX4: 1800 mV normal standby
i2c_omap i2c_omap.2: bus 2 rev4.0 at 400 kHz
i2c_omap i2c_omap.3: bus 3 rev4.0 at 100 kHz
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: 00
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource 32k_counter
musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92
musb_hdrc musb_hdrc: MUSB HDRC host driver
musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 874
io scheduler deadline registered
io scheduler cfq registered (default)
OMAP DSS rev 2.0
OMAP DISPC rev 3.0
OMAP DSI rev 1.0
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
No NAND device found!!!
No NAND device found!!!
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver zd1211rw
usbcore: registered new interface driver rtl8187
usbcore: registered new interface driver rndis_wlan
usbcore: registered new interface driver zd1201
usbcore: registered new interface driver usb8xxx
usbcore: registered new interface driver rt2500usb
usbcore: registered new interface driver rt73usb
usbcore: registered new interface driver p54usb
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 2
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
input: gpio-keys as /class/input/input0
twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
twl_rtc twl_rtc: Power up reset detected.
twl_rtc twl_rtc: Enabling TWL-RTC.
i2c /dev entries driver
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Bluetooth: Broadcom Blutonium firmware driver ver 1.2
usbcore: registered new interface driver bcm203x
Bluetooth: Digianswer Bluetooth USB driver ver 0.10
usbcore: registered new interface driver bpa10x
Bluetooth: Generic Bluetooth SDIO driver ver 0.1
mmci-omap-hs mmci-omap-hs.1: err -16 configuring card detect
Registered led device: beagleboard::usr0
Registered led device: beagleboard::usr1
Registered led device: beagleboard::pmu_stat
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.21.
usbcore: registered new interface driver snd-usb-audio
ALSA device list:
No soundcards found.
oprofile: using arm/armv7
TCP cubic registered
Jason Kridner
> 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)
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
>
> read more »
Gerald Coley
--
Gerald Coley
Jason Kridner
> 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. :-)
Gerald Coley
Jason Kridner
> 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. :-/
Jason Kridner
> On Thu, Jul 22, 2010 at 8:37 AM, Gerald Coley <ger...@beagleboard.org> wrote:
>> 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
>>
>>
>> On Wed, Jul 21, 2010 at 6:46 PM, Jason Kridner <jkri...@beagleboard.org>
>> wrote:
>>>
>>> On Wed, Jul 21, 2010 at 4:59 PM, Gerald Coley <ger...@beagleboard.org>
>>> wrote:
>>> > 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. :-)
>>>
>>> >
>>> > Gerald
>>> >
>>> > On Wed, Jul 21, 2010 at 3:47 PM, Gerald Coley <ger...@beagleboard.org>
>>> > wrote:
>>> >>
>>> >> I will start working with it.
>>> >>
>>> >> Gerald
>>> >>
>>> >> On Wed, Jul 21, 2010 at 3:46 PM, Jason Kridner
>>> >> <jkri...@beagleboard.org>
>>> >> wrote:
>>> >>>
>>> >>> On Jul 21, 3:28 pm, Gerald Coley <ger...@beagleboard.org> wrote:
>>> >>> > Here it is.
>>> >>> >
>>> >>> > Gerald
>>> >>>
...
Koen Kooi
Op 22 jul 2010, om 22:31 heeft Jason Kridner het volgende geschreven:
>
> 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.
The bunny license doesn't allow that by the looks of it...
Gerald Coley
--
Jason Kridner
> On Thu, Jul 22, 2010 at 4:31 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>> On Thu, Jul 22, 2010 at 8:37 AM, Gerald Coley <ger...@beagleboard.org> wrote:
>>> 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.
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. :(
I also found that 'mtdparts' needs to be set and I need to test 'nand
info'. Still testing...
Jason Kridner
> 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.
>
> Gerald
>
Gerald Coley
--
bhaskar
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.
Gerald Coley
Jason Kridner
It has already generated a few some time back. Not sure what we can do about it.
On Jul 22, 2010 8:35 PM, "Gerald Coley" <ger...@beagleboard.org> wrote:Sounds like a great generator of a few emails from users.Gerald
On Thu, Jul 22, 2010 at 4:26 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
> > On Thu, Jul 22, 2010 at 5:19 PM, Gerald Coley <ger...@beagleboard.org> wrote: > > The i2c comman...
--> You received this message because you are subscribed to the Google Groups "Beagle Board" group. > ...
-- You received this message because you are subscribed to the Google Groups "Beagle Board" group....
Koen Kooi
Op 23 jul 2010, om 03:31 heeft Jason Kridner het volgende geschreven:
> 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
>
>
>> On Jul 22, 2010 8:35 PM, "Gerald Coley" <ger...@beagleboard.org> wrote:
>>
>> Sounds like a great generator of a few emails from users.
>>
>> Gerald
>>
>>
>>
>> On Thu, Jul 22, 2010 at 4:26 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>>
>> > > On Thu, Jul 22, 2010 at 5:19 PM, Gerald Coley <ger...@beagleboard.org> wrote: > > The i2c comman...
>>
>>
>> --
>> > You received this message because you are subscribed to the Google Groups "Beagle Board" group. > ...
>>
>> -- You received this message because you are subscribed to the Google Groups "Beagle Board" group....
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
Jason Kridner
> On Thu, Jul 22, 2010 at 4:42 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>> On Thu, Jul 22, 2010 at 4:31 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>>> On Thu, Jul 22, 2010 at 8:37 AM, Gerald Coley <ger...@beagleboard.org> wrote:
>>>> 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}
Jason Kridner
> On Thu, Jul 22, 2010 at 5:24 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>> On Thu, Jul 22, 2010 at 4:42 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>>> On Thu, Jul 22, 2010 at 4:31 PM, Jason Kridner <jkri...@beagleboard.org> wrote:
>>>> On Thu, Jul 22, 2010 at 8:37 AM, Gerald Coley <ger...@beagleboard.org> wrote:
>>>>> 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.
Jason Kridner
> On Wed, Jul 21, 2010 at 4:59 PM, Gerald Coley <ger...@beagleboard.org> wrote:
>> 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.
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
Koen Kooi
Gerald Coley
Gerald Coley
Jason Kridner
> 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.
Jason Kridner
> On Wed, Jul 28, 2010 at 4:11 PM, Gerald Coley <ger...@beagleboard.org> wrote:
>> 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 http://beagleboard-validation.s3.amazonaws.com/sd/beagleboard-validation-201008050445.img/list.html
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?
Koen Kooi
Can you try with some more realistic sizes like a 10MB loop file?
regards,
Koen
Søren Steen Christensen
> $ 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
---
SSC Solutions ApS - Denmark - www.ssc-solutions.dk
Jason Kridner
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!!!
>
> Best regards
> Søren
>
> ---
> SSC Solutions ApS - Denmark - www.ssc-solutions.dk
>
Koen Kooi
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
Søren Steen Christensen
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?
Gerald Coley
Jason Kridner
> 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.
Gerald Coley
--
Jason Kridner
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...