Difference between revisions of "BeagleBoardFAQ"
(→"DSS2" display driver for >= 2.6.29)
(→"DSS2" display driver for >= 2.6.29)
|Line 468:||Line 468:|
* omapfb.mode=dvi:1280x720MR-16@60 (for 720p HDTV with 1:1 pixel mapping)
* omapfb.mode=dvi:1280x720MR-16@60 (for 720p HDTV with 1:1 pixel mapping)
* omapfb.mode=dvi:1280x1024MR-16@60 (tested on revB7, actual output is
* omapfb.mode=dvi:1280x1024MR-16@60 (tested on revB7, actual output is and may not work on some devices)
* omapfb.mode=dvi:1360x768MR-16@60 (works nice on 720p HDMI TV which crops edges due to overscan)
* omapfb.mode=dvi:1360x768MR-16@60 (works nice on 720p HDMI TV which crops edges due to overscan)
Revision as of 12:54, 28 June 2011
- 1 Board revisions
- 2 BeagleBoard alternative distributors
- 3 DigiKey out of stock
- 4 Shipped hardware
- 5 Shipped software
- 6 Peripherals needed
- 7 New board, and now
- 8 Beagle reading
- 9 Serial connection #1
- 10 Serial connection #2
- 11 Serial connection #3
- 12 Serial connection #4
- 13 Serial connection #5
- 14 SD Card
- 15 User button #1
- 16 User button #2
- 17 Graphics accelerator
- 18 USB 2.0 EHCI HS connector
- 19 USB OTG connection #1
- 20 USB OTG connection #2
- 21 USB OTG connection #3
- 22 X-Loader and U-Boot version
- 23 Expansion connector #1
- 24 Expansion connector #2
- 25 Expansion connector #3
- 26 Expansion connector #4
- 27 Sound at git kernel
- 28 NEON performance
- 29 Demo videos
- 30 Windows/Cygwin #1
- 31 Windows/Cygwin #2
- 32 Windows/Cygwin #3
- 33 MacOS X / x86
- 34 TWL4030 data sheet
- 35 Pico Video Projector Kit (PVPK)
- 36 Display timings
- 37 Display resolutions #1
- 38 Root password Angstrom image
- 39 NFS
- 40 LEDs
- 41 Programming GPIO pins
- 42 ES2.1 vs. ES3.0
- 43 128MB vs. 256MB SDRAM
- 44 IRQ -33
- 45 U-Boot v1 #1
- 46 U-Boot v1 #2
- 47 U-Boot v1 unable to use mmc error
- 48 U-Boot v1 not saving environment variables
- 49 U-Boot v1 linking errors
- 50 Performance
- 51 Accessing the BeagleBoard using VNC
- 52 Power usage
- 53 Linux Distributions
- 54 omapfbplay mmap fails
- 55 Kernel ARM cross compiling
- 56 Kernel verbose user space errors
- 57 Boris
- 58 BeagleGame
Q: What is the difference between BeagleBoard revision B4 and B5?
Note: Revision A boards have capacitor C70 at the same location as rev. B layout.
Q: What is the difference between BeagleBoard revision B5 and B6?
A: Revision B6 uses better/new/different package for U9/U11. For differences see BeagleBoard revision B6 HW manual, section 2.4 (page 13). The differences betwen the various versions are documented in the system reference manual.
Q: What is the difference between revision Bx and revision Cx?
A: The primary differences are the inclusion of the USB host port and 256MB of RAM on the Cx boards. The differences betwen the various versions are documented in the system reference manual.
Q: What is the BeagleBoard-xM?
A: The BeagleBoard-xM is a major revision of the BeagleBoard to utilize a 1GHz+ processor, 512MB of RAM, an on-board USB hub with Ethernet, and no NAND flash memory. See http://beagleboard.org/hardware-xM. There is also an associated price increase and the old revision boards are therefore still available.
BeagleBoard alternative distributors
Q: Are there any alternative distributors to order BeagleBoard from?
A: No, unfortunately not. You have to order from DigiKey.
DigiKey out of stock
Q: I like to order a BeagleBoard from DigiKey. But they seem to be out of stock?
A: DigiKey is having IT issues in that they can't handle partial shipments against an order, it does not show up in their system. Currently, they are receiving > 200 boards a week from the contract manufacturer. Typically they will only show a QTY of 1 for EVMs and it is not an indication of total quantity they have.
Q: I like to buy a BeagleBoard from DigiKey, what hardware is included?
Q: I like to buy a BeagleBoard from DigiKey, what software is included?
Q: As shipped BeagleBoard doesn't contain any peripherals and adapters, what else will I need?
A: There are some adapters necessary to bring up and some are nice to have for diagnosis etc.:
- IDC10 to DB9M serial adapter (necessary)
- Serial null modem cable (optional, depends on your serial adapter and your serial PC port)
- USB serial adapter (optional, depends if your PC has still DB9M serial connector)
- SD card >= 256MB (necessary, at least for some fun with demos)
- USB-A to mini USB cable to power BeagleBoard (necessary, or optional if you have additional 5V power supply, see below)
- 5V, >= 500mA, 2,1mm/5,5mm plug, center-positive, well-regulated power supply (optional). This must be a well-regulated supply: greater than 5.5V can damage your BeagleBoard. Beware of cheap 5V bricks, as they may produce more than 5.5V with a light load and destroy your board.
- HDMI to DVI-D cable (optional) or HDMI to HDMI cable if your monitor supports HDMI (optional)
- USB Standard-A to Mini-A Adapter (optional, for USB usage external 5V power supply is necessary)
- Self powered USB hub (optional, and some USB peripherals like keyboard and mouse)
New board, and now
Q: Hurray, I got my board. And now?
Q: What pages about Beagle are available? There are so many pages, is there an overview?
A: Main BeagleBoard resources are:
Wiki article overview tries to track a list of available Beagle wiki pages.
Serial connection #1
Q: My serial connection doesn't work, has issue xxx. Where can I get more information?
A: Download BeagleBoard HW manual. It has some pictures to help you debug serial issues. See chapter 10.2 and 13.3 of revision B6 HW manual. Newer manuals might have different chapter numbering.
Serial connection #2
Q: If I power my new board, after some seconds USR1 and USR2 LEDs are switching on, but I can't get anything in terminal program (minicom, kermit, hyperterm etc,).
A: Review wiring of your IDC10 to DB9M serial adapter, try with and without NullModem cable, try to use DB9 serial port of your PC or USB serial adapter. Try all combinations.
BeagleBoard only implements RS-232 signals RX, TX, and GND. These are pins 2, 3, and 5 of BeagleBoard 5x2 header P9 and also the DB9 connector on the serial adapter. So pins 1 - 5 on IDC go to pins 1 - 5 on DB9. There appear to be 2 types of these IDC to DB9 connectors. One has 1:1 wiring which is what you want. The other seem to have IDC:1 -> DB9:1, IDC:2 -> DB9:6, IDC:3 -> DB9:2, IDC:4 -> DB9:7 etc. This is wrong and will not work with BeagleBoard. The second (wrong) type of connector might give comms in one direction only! E.g., this was reported by one user who returned a board due to serial connection problems:
I originally ordered quantity 2 of the cables from PCCables website:
- One was labeled 000-F903 and was the one I did the initial testing on both boards with.
- The second was labeled 000-F903-N and actually works (on the new one and the RMAed one). This matches the code on the pccables website.
So make sure you see the "-N", which is what is reported to be the proper version if you order from PCCables website.
To see if there is any activity at all on the serial port, use an RS-232 LED monitor or break-out box or a digital oscilloscope to see if there is a bit stream on TX.
Using an IDC10 to DB9M adapter in a draw (scavenged from some old computer), it failed to communicate with BeagleBoard. The pins were checked if they are as they should be. It seemed to be misswired as above. Opening up and resoldering the wires to correct pins made the adapter work. See pictures below for before and after.
Serial connection #3
Q: I tried everything from serial connection #1 above but still nothing. It seems that I sometimes get some random characters, though.
A: If there is a bit stream, check that you have configured your terminal program to:
- BAUD RATE: 115200
- DATA: 8 bit
- PARITY: none
- STOP: 1bit
- FLOW CONTROL: none
This will work with most PCs. However, your PC may want to see DSR before it transmits to BeagleBoard and needs to have DTR (pin 4) wrapped back to DSR (pin 6).
Serial connection #4
Q: Hurray, I got my new board, I'm quite sure that my serial connection is correct using the above two FAQs. Unfortunately, I get (boot) output, but can't type anything at U-Boot prompt.
A: Try test proposed from John: Here's a useful experiment: disconnect BeagleBoard and jumper TX (DB9 pin 3) to RX (pin 2) at the end of your serial cable. See if your jumper echoes to your terminal emulator. If not, try jumpering DTR (pin 4) to DSR (pin 6) and repeat test. You can also jumper RTS (pin7) to CTS (pin 8) if you don't trust your software to have turned off flow control.
Serial connection #5
Q: I tried all three serial FAQs above, and I'm really really sure that anything is fine with my local serial configuration. But I still can't type anything at U-Boot prompt.
A: If you get TX data from the BeagleBoard OK but do not get RX data from your terminal program to BeagleBoard, check P9 pin 2 with a digital 'scope or an LED with 1K series resistor to see if there is any activity there. If there is data and you are really, really sure that everything is correct with your serial connection, then most probably your board suffers from errata #8. Then it's time for the Beagle Hospital. Sorry, you have to replace/repair it using RMA process.
ATTENTION: One user reports that his board showed all symptoms of errata #8 but only when DC powered; when USB powered serial input was fine. It turned out that pin 5 (ground) was miswired.
...40T.........XH.H.U�..Instruments X-Loader 1.41 Starting on with MMC Reading boot sector ...
A: Some users report issues with creating proper FAT or dual boot partitions as described in above linked documents. These descriptions are known to be correct, though. Because of unknown reasons, sometimes they seem to not work. Fragmentation of files in FAT boot partition may be one issue. Therefore:
- Restart from scratch and try again to create boot partitions as described in above documents.
- Try another SD card.
- Make sure you made FAT boot partition bootable (fdisk 'a' command).
- Make sure the images at your SD card are named MLO, u-boot.bin and uImage. If you downloaded the binaries make sure you remove all file name extensions to match these names.
- Press and hold user button while powering the board to ensure that boot images are really read from SD card and not from NAND.
Note: A user reports: It is absolutely necessary that MLO starts in the first sector of the FAT32 partition. What has worked best for that user is to reformat the FAT32 partition using Windows before copying MLO, u-boot.bin, and uImage. What might have happened is that formatting the FAT32 partition under Kubuntu Linux (sudo mkfs.msdos -F 32 /dev/sdb1 -n LABEL) added standard directories "." and ".." at the beginning of the partition so that when he copied MLO it did not end up at the beginning.
Also, make sure the SD card is inserted all the way in. The socket on a new BeagleBoard may be quite stiff. A properly inserted SD card sticks out 18mm and pushes the top gold contacts aside. If you're unsure, look inside the socket from the edge of the board and see where the 9 contacts are that must mate with the SD. This tells you how far to insert the card. As always, be careful and don't force.
Q: User button doesn't seem to work for me!
A: Make sure you hold the user button down while releasing the reset. Do not release them at the same time.
Q: Pressing the user button my image at SD/MMC card isn't started! In terminal program I always get
Texas Instruments X-Loader 1.41 Starting OS Bootloader... ...
A: It seems that you don't press user button correctly. See user button #1 above. If you use user button correctly, you get
Instruments X-Loader 1.41 Starting on with MMC Reading boot sector ...
If you don't get "MMC" message, you still boot from NAND.
Q: OMAP3530 used on BeagleBoard contains a graphics accelerator (SGX) based on the SGX core from Imagination Technologies. Are Linux drivers available for this? If not, when will they be available? Will they be OpenSource?
A: See Graphics accelerator section at BeagleBoard wiki page.
USB 2.0 EHCI HS connector
Q: On my board, USB 2.0 EHCI HS connector (#8) isn't soldered? Why? How can I use USB?
A: At revision A and B boards, USB 2.0 EHCI HS is broken due to HW errata #5. Therefore revision B boards don't have this connector soldered. This will be fixed with revision C boards (expected ~February 2009). You can use full USB functionality using OTG port with something like mini A to USB A adapter and self powered USB hub instead.
USB OTG connection #1
A: Make sure that
- Your cable is plugged in while the kernel boots. At the moment, Linux only detects OTG port in host mode if cable is connected at boot time.
- You use a self-powered (externally-powered) hub to attach devices. BeagleBoard only supports devices <= 100mA, so if you have USB issues try a self-powered hub.
- Your Mini USB plug is 5-pin Mini-A. Mini-B will not work. See types of USB connectors. Mini-B can be plugged to Beagle, but they don't have ID pin wired to GND. Only Mini-A cables connect ID pin to GND. So Mini-A with ID pin to GND is necessary. Since Mini-A is not an official USB standard the connectors/cables can be extremely difficult to find (without building your own); you can find a Mini-A to Standard female A adapter here though.
- If you use a 5-pin Mini-A to Standard A male cable, be sure that you plug the Standard A cable into the host port of your hub and not one of the device ports. You will probably need a double-female Standard A adapter since most hubs either have a host cable with a Standard A male plug or have a Standard B jack for a Standard A male to Standard B male cable.
USB OTG connection #2
Q: How can I force the USB OTG port to act like a host?
A: At kernel command line do
echo host> /sys/devices/platform/musb_hdrc/mode
USB OTG connection #3
Q: When I plug a new USB device such as a Flash drive into my hub, I lose other devices such as my keyboard and/or mouse. What's going on?
A: Here's a theory as to what is going on: First of all, if you are connecting multiple devices to BeagleBoard's OTG port (in host mode) you probably need a "self-powered" USB hub, i.e., a hub with an external power supply that provides +5V power to the hub because the BeagleBoard OTG port can only supply 100mA.
When you plug a USB device into the hub, it immediately connects to the +5V supply. The hub and the device both have large capacitors on the +5V supply. Normally, large capacitors are a good thing since they keep voltages constant. However, if you suddenly connect two capacitors, one charged and one discharged, the charged capacitor will very quickly transfer a large amount charge to the discharged capacitor so that the two capacitors end up with the same voltage. This is called "charge sharing". If the previously discharged capacitor is a lot smaller than the charged one, it won't affect the voltage on the charged one much. However, if the previously discharged capacitor is large, it can cause a momentary glitch in the charged capacitor's voltage which can be quite nasty if circuitry depends on that voltage staying constant.
A well-designed USB hub should have "slow start" circuitry that charges up a plugged-in device slowly so that it doesn't glitch the hub's +5V supply. However, there may not be a standard for this. Cheap USB hubs omit "slow start" circuitry so plugging in a device with a large +5V capacitor can easily glitch the hub's +5V supply.
Normally the +5V glitch is small, maybe just a few tenths of a volt. This should not be a problem for most devices, since they probably regulate +5V down to +3.3V anyway. So it's not clear why this would cause the BeagleBoard to lose USB devices. Here is the rest of the theory: Since BeagleBoard is in host mode, it is trying to generate +5V at 100mA to the hub. Since the hub is self-powered, it doesn't need BeagleBoard's lousy 100mA but the BeagleBoard sees that USB power is indeed +5V and thinks that it's doing a fine job providing that +5V. So what happens if the hub's +5V glitches when a device is plugged in? One possibility is that BeagleBoard sees the drop in voltage, assumes its +5V generating circuitry has failed, and tells software to disconnect all devices. Software should automatically recover from this, but does not seem to do so at this time.
So what should users do about it? The easiest thing is to plug in USB devices before booting BeagleBoard's operating system. This doesn't help if you want to unplug and replug a Flash drive to transfer data, but it's better than nothing.
Any corrections or additions to this theory are more than welcome.
X-Loader and U-Boot version
Q: I use X-Loader and U-Boot shipped with BeagleBoard. These are the versions from code.google.com. Unfortunately, sometimes I have issue xxx with these. Is this known? How to fix this?
A: The X-Loader and U-Boot version at code.google.com are the official TI versions available there for reference. They are known to have some issues. Try the community versions of X-Loader and U-Boot instead.
Expansion connector #1
Q: I got my new BeagleBoard Rev. xx board. But expansion connector (#5) isn't soldered. Is this wrong?
A: No, this is correct. All boards are shipped without mounted expansion connector.
Expansion connector #2
Q: Which signals are available at expansion connector?
A: See BeagleBoard HW Reference Manual Table 17 & 18. Depending on the pin mux you have:
Expansion connector #3
Q: Should I mount expansion connector at top or bottom side?
A: Do as you like and as it fits your application. This is the reason why it isn't soldered by default
Expansion connector #4
Q: How much current can the Beagle supply to peripherals?
A: You are limited to 100mA @ 1.8V. This is referenced in the BeagleBoard HW Reference Manual in section 5.19. The 1.8V is intended to only drive level shifters connected to the expansion connector. In the event that you are powering from a DC supply, more current can be provided on the 5V rail depending on the amount of current that can be supplied by the DC supply.
Sound at git kernel
Q: I use OMAP git kernel, e.g. by Koen's demo images or I compiled it my own. Using audio or mplayer with audio output kernel crashes with something like
Unable to handle kernel NULL pointer dereference at virtual address 00000000
A: Unfortunately, ALSA sound output with current OMAP git kernel is broken. It is supposed that Beagle ASoC driver is fine, but something in ALSA together with the driver results in above error. So you can't use audio with recent git kernel, used within Koen's demo images, too. Use mplayer with -nosound option, switch to OSS
mplayer -ao oss
or use omapfbplay.
Koen provides reconfigured uImage.
Q: There is some rumor abot NEON bugs/performance issues in OMAP3?
A: Some occasional crashes were observed with Beagleboard running intensive NEON or floating-point code. This is now fully understood (ARM Erratum #621766) and there is a simple software workaround that completely fixes the problem (enable L1NEON in Cortex-A8 aux ctrl register). This requires a new u-boot on RevB boards - see Mans' U-boot git or download the u-boot.bin from the Angstrom Distribution page (use the USER switch to boot from SDcard). L1NEON enabled is required for Cortex-A8 r1pX (Beagle rev B & Rev C), but it is only the RevB u-boot that sets it incorrectly . The L1NEON setting allows the CPU to allocate NEON data into L1 D-cache on a cache miss. It can affect performance either way, depending on the amount of data being processed.
Note: Beagle RevB ships with a u-boot that disables L1NEON. This means NEON data is allocated into L2 only, and for some tight NEON kernels using a small amount of data (where L1 is of most benefit) this can give significantly reduced performance as well as being susceptible to the #621766 erratum.
There is another extremely rare NEON issue (ARM erratum #451034) that can cause deadlock; this issue is fixed in hardware in Cortex-A8 r1p3 (Beagle Rev C). This issue is so rare that we do not believe it has ever been seen in any real code.
With L1NEON enabled, all Beagle revisions are now 100% reliable for NEON development
Q: I'm using Koen's demo image. Which (demo) videos can I use to test (720p) video playback with mplayer or omapfbplay?
Q: Try 720p .avi versions of
Don't forget to disable sound, though.
Note: Don't forget to extend your kernel's bootargs in U-Boot by
Q: I'd like to do some Linux development for BeagleBoard. But because of ... I can't use Linux as OS on my development PC. I only have a Windows PC.
A: Really consider switching to Linux at your development PC for doing BeagleBoard Linux development. Yes, you can use Cygwin (see below), but most probably this will result in some issues here and there you won't have if you develop under Linux, too. If you can't switch to Linux PC, consider running Linux in a virtual machine under Windows (VMWare etc.).
Q: Can I used Windows/Cygwin as a development platform?
A: While most Beaglers use a Linux development platform, it is possible to use Windows. Cygwin is a nice environment, since it gives you Linux commands but runs as a Windows application.
CodeSourcery has a G++ Lite toolchain that runs under Windows. For most Beagle applications the best version is ARM GNU/Linux 2007g3-51. When working with Cygwin, you need to set CYGPATH to the Cygwin "cygpath" program which converts Unix path names to Windows path names. Here is a typical CYGPATH assignment you might put in .bash_profile:
Note: The Sourcery document says
but it seems necessary to change '/' to '\', with '\\' needed to escape the '\' character.
One thing that is more or less impossible to do under Windows is to copy (or better yet, untar) a root file system to an ext2 or ext3 partition of an MMC/SD card. One way to do this is to boot a version of Linux from CD ROM without installing it on the Windows machine. It's slow, but it's a safe way to run Linux. Kubuntu 8.04 has been used successfully to untar a Linux file system to an MMC/SD card with two partitions. Ubuntu 8.04.1 LTS Desktop Edition was not successful because the user could not find a way to access the second MMC/SD partition. Linux CD-ROMs are generally cheap or free.
Once you have successfully built a Linux system that runs on BeagleBoard, you can transfer future files using a FAT32 USB Flash drive or Ethernet.
Q: How can I build Angstrom X Windows applications using Windows 2000 and Cygwin?
A: It requires fooling CodeSourcery in various interesting ways.
First, to compile X Windows applications you needed to make the X11R6 include files available to CodeSourcery. It turned out the easiest way to do that was simply to copy Cygwin's /usr/X11R6/include/X11 directory to CodeSourcery's .../arm-none-linux-gnueabi/include directory. X11R6 is extremely stable (the politically-correct euphemism for "obsolete") so I don't need to worry about my include files becoming inconsistent. The compile command I use right now in gnu make is:
cc = arm-none-linux-gnueabi-gcc -O -Wunused -march=armv7-a %.o: %.c $(cc) -o $@ -c $<
(This doesn't use floating point at this time so options for this are not added)
Linking is much more interesting. It's important to link to the correct libraries. So untar the Angstrom demo root file system at your PC, and then tell CodeSourcery to link to the Angstrom demo's libraries. All or most of these are dynamic shared libraries (.so). Here are gnu make commands:
# Beagle run-time directory containing libX11.so, etc. RTdir = /cygdrive/c/John/Beagle/AngstromDemo/usr/lib GXC_OBJS = <list of object code files .o generated by $(cc)> # Beagle: need to specify RTdir both for -L and -rpath options. gboot: $(GXC_OBJS) $(cc) -o $@ $(GXC_OBJS) -L$(RTdir) \ -Xlinker -rpath -Xlinker $(RTdir) -lX11 -lm
The "-rpath" linker option tells the linker to look in $(RTdir) for .so files. The "-Xlinker" option tells gcc to pass the next string to the linker: "-Xlinker -rpath -Xlinker $(RTdir)" passes "-rpath $(RTdir)".
After linking you should end up with a reasonably small executable that contains references to dynamic shared object libraries. When you copy the executable and run under Angstrom, Angstrom very nicely finds the same .so files you used to link the programs, loads the library modules, and cheerfully runs the program.
This was tested with CodeSourcery GNU/Linux for Windows 2007q3-51.
MacOS X / x86
Q: Can I use MacOS X as a development platform?
A: Yes. Here is a link to the codesourcery toolchain compiled for MacOS X (x86):
This includes gcc, glibc, and gdbserver/gdb for debugging.
To install, untar to somewhere like /usr/local/arm.
Note: so far I've been unable to download/flash x-loader and u-boot, but I suspect that is issues with my USB->UART converter. Hopefully this gets easier when flashing over USB is working.
Q: Can I cross-compile the linux kernel on MacOS X?
A: Yes. After installing the toolchain (see above), there are a few additional steps to be taken, since the linux kernel build files tend to assume the host platform is linux:
- Install libelf; I installed this via macports, and then:
- sudo port install libelf
- sudo ln -s /opt/local/include/libelf /usr/include/libelf
- copy this elf.h (which adds a few missing #defines) to /usr/include
- Install GNU sed:
- sudo port install gsed
- Create missing /usr/include/malloc.h
- should simply contain #include <sys/malloc.h>
- Install mkimage.. I've managed to get u-boot v1.1.4 building with this patch. (This is actually the version used on LDP/SDP, not beagle.. but to just get mkimage, it seems to be fine.) Or you can download the mkimage binary from here. I hope to have updates for the "beagle" version of u-boot in the near future. (Once you build u-boot, mkimage will be in the tools directory.)
I then setup a "special" bin directory containing mkimage, and a a symlink sed -> /opt/local/bin/gsed. I put this directory, plus the directory of the cross-compilers at the front of my $PATH so the kernel makefiles and scripts find the GNU version of sed.
TWL4030 data sheet
Q: Where do I get data sheet for TWL4030 used at BeagleBoard?
A: You will probably want to look at the TPS65950 manual instead, which is functionally equivalent to the TWL4030. The TPS65950 TRM is finally public.
Pico Video Projector Kit (PVPK)
Q: What is this Pico Video Projector Kit (PVPK)?
A: You can use a tool like CVT Timings Program.
Display resolutions #1
Q: Which display resolutions are supported?
A: There are currently 2 answers to this question, depending on which display subsystem driver you are using.
linux-omap display driver
You must set the boot arguments for your kernel to use these resolution settings. The argument would be in the format "video=omapfb:mode:<name>", such as:
- video=omapfb:mode:720p60 (this one is probably the best choice for a HDMI TV)
Note: Not all of those resolutions actually work as advertised, since the pixel clock is currently limited to 72MHz. It depends on the monitor whether it the slightly lower sync rates this results in will work.
"DSS2" display driver prior to 2.6.29
For the latest Angstrom Distribution BeagleBoard demo or other kernel that uses the DSS2 patches utilized in the latest Angstrom kernels, there are different video mode settings. Please see Tomi's post to the BeagleBoard mailing list and the modedb.txt description of mode strings. Koen also posted the DSS2 documentation to the mailing list.
"DSS2" display driver for >= 2.6.29
Tomi has updated the display driver and has a clone of his tree on Gitorious. The kernel sources contain the DSS2 documentation. The syntax has been updated a bit, so it is worth re-examining. This updated driver seems to being used in Angstrom builds of the BeagleBoard kernel starting with 2.6.29.
- omapfb.mode=dvi:1280x720MR-16@60 (for 720p HDTV with 1:1 pixel mapping)
- omapfb.mode=dvi:1280x1024MR-16@60 (tested on revB7, actual output is 57MHZ and may not work on some devices)
- omapfb.mode=dvi:1360x768MR-16@60 (works nice on 720p HDMI TV which crops edges due to overscan)
Note: the M indicates the kernel will calculate a VESA mode on-the-fly instead of using modedb lookup. The R indicates reduced blanking which is for LCD monitors. Most HDTV will probably only operate with a VESA mode.
Root password Angstrom image
Q: I use Angstrom demo image. Help, what is the root password?
A: Try no password at all, i.e., just press return. The default root password is empty in Angstrom.
Q: Anyone has luck to mount NFS from BeagleBoard?
A: There are a couple of known ways to mount the BeagleBoard root filesystem over NFS. There is an article on this wiki describing how to bridge usb0 to eth0 on your Linux Host as well as the following instructions taken from Google Groups on mounting the root file system with Fedora:
1) Add file ifcfg-usb0 into /etc/sysconfig/network-scripts/
DEVICE=usb0 IPADDR=192.168.1.5 NETMASK=255.255.255.0 ONBOOT=yes TYPE=USB BOOTPROTO=none USERCTL=no IPV6INIT=no PEERDNS=yes
2) Add following line to /etc/exports
3) Create directory /data/target and copy your root file system to /data/target
4) Type following commands:
# service rpcbind restart # service nfs restart
5) On BeagleBoard console type following commands:
OMAP3 beagleboard.org # setenv bootargs console=ttyS2,115200n8 root=/dev/nfs rw nfsroot=192.168.1.5:/data/target ip=192.168.1.1::255.255.255.0 nolock,rsize=1024,wsize=1024 rootdelay=2 OMAP3 beagleboard.org # saveenv OMAP3 beagleboard.org # mmcinit OMAP3 beagleboard.org # fatload mmc 0 0x80300000 uImage OMAP3 beagleboard.org # bootm 0x80300000
Q: How can I control (switch on/off) USR0 and USR1 LEDs at BeagleBoard from user space?
A: You can do this using kernel's LED sys-fs interface. E.g
echo 1 > /sys/class/leds/beagleboard\:\:usr0/brightness
at command line enables USR0 LED and
echo 0 > /sys/class/leds/beagleboard\:\:usr0/brightness
disables it again. Same works with USR1 LED.
Programming GPIO pins
Q: How can I change the GPIO pins from user space?
A: See the discussion in this thread: GPIO - how to?
ES2.1 vs. ES3.0
Q: Upcoming ES3.0 (engineering sample) has some minor improvements (e.g. fixes extremely rare NEON errata #451034 that has not been seen outside the test lab). How can I check if I have ES2.1 or ES3.0?
A: ES3.0 is supposed to be used at BeagleBoard revision C. As long as you have an older board (e.g. rev. Bx) most probably you have ES2.1. ES2.1 uses ARM Cortex A8 version r1p1, while ES3.0 uses updated ARM Cortex A8 version r1p3. You can check this by kernel's boot messages:
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
is ES2.1 with ARM Cortex A8 r1p1, while
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=00c5387f
is ES3.0 with ARM Cortex A8 r1p3.
128MB vs. 256MB SDRAM
Q: How can I detect if my BeagleBoard has 128MB or 256MB SDRAM?
A: All BeagleBoards revision Ax and Bx have 128MB SDRAM. Rev Cx boards [est. shipping Mar-09] will be OMAP3 ES3.0 with 256MB PoP memory. Mans has some U-Boot v1 patches to check for second memory bank. There are two GPIO pins that can be used to first detect that the board is a Rev C and whether or not it has 256MB onboard. This will be published in the SRM for the Rev C board.
Q: Using recent Linux kernel, I do foo and system often stops with
irq -33, desc: c0335cf8, depth: 0, count: 0, unhandled: 0 ->handle_irq(): c00744e0, handle_bad_irq+0x0/0x22c ->chip(): 00000000, 0x0 ->action(): 00000000
I have to reboot then.
A: There is a workaround/fix making certain I/O regions Strongly Ordered instead of default MT_DEVICE. There is some discussion if this makes the system slower and if this is a workaround or real fix.
U-Boot v1 #1
Q: I use U-Boot v1 and have xxx problems. Any ideas?
U-Boot v1 #2
Q: I use latest U-Boot v1, but "nand ecc hw/sw" command doesn't work any more as described in various manuals?
(i.e. without space between nand and ecc). For latest U-Boot we had to change the command format for upstream acceptance.
U-Boot v1 unable to use mmc error
Q: I use latest U-Boot v1, but can't read uImage from MMC/SD card. Error message I get looks like:
** Unable to use mmc 0:1 for fatload ** Wrong Image Format for bootm command ERROR: can't get kernel image!
A: In recent U-Boot mmcinit command changed. It switched from mmcinit to mmc init (additional blank). Try to use
instead of mmcinit (e.g. in your environment: printenv).
U-Boot v1 not saving environment variables
Q: Why does 'saveenv' not preserve my u-boot environment variables?
A: You might be using the wrong build of u-boot. See the group discussion on the u-boot that ignores the flash environment.
Q: I use recent U-Boot (> 2009.06) and get a lot of errors while linking. E.g.
... arm-linux-ld: ERROR: <path_to>/libgcc.a(_xyz.o) foo bla arm-linux-ld: failed to merge target specific data of file <path_to>/libgcc.a(_xyz.o) ...
A: Instead of just calling make, try to additionally set USE_PRIVATE_LIBGCC environment variable to "yes":
Q: Where can I get some performance numbers of BeagleBoard? How does BeagleBoard performance compare to other ARM (PC) systems?
Accessing the BeagleBoard using VNC
Q: Can I access the BeagleBoard using VNC
A: Yes, of course! Here is how.
- Install angstrom-x11vnc-xinit on the beagle e.g. using the command "opkg install angstrom-x11vnc-xinit"
- issue the command "killall Xorg" and wait for X to restart
- start your favourite vnc client on your host and connect. If you use vncviewer the command would be something like: vncviewer 192.168.1.100:0 assuming your beagle is at 192.168.1.100 and the display port is 0
- Technically that's it but you might to see e.g. an xterm in your vnc. One way to get that is to install xterm (opkg install xterm). After that you can start an xterm. If you do this over serial the command is "DISPLAY=0:0 xterm &" Of course you can also do that in some initialisation script.
Miriam Corder from TI stated: RichardB's_notes_from_the_seminar
- Max power consumption is 360mW
- With dynamic voltage/freq scaling – averaging <100mW
Koen measured: Some powerconsumptions tests
~290mA at uboot prompt
~350mA at X desktop
~400mA using 100% cpu at 600MHz
~275mA at X desktop
Powertop reports with with 2.6.27 omap-pm-next:
C0 4.1ms ( 4.4%)
C1 0.9ms ( 0.8%)
C2 7.7ms ( 3.7%)
C3 13.1ms ( 0.9%)
C4 37.8ms (88.7%)
Q: What Linux distributions exist for the BeagleBoard and where do I get help for them?
A: If you have BeagleBoard-specific questions, then by all means ask them on the BeagleBoard mailing list. Be polite and understand that your distribution is not the only one people use on the BeagleBoard, so be sure to let people know where you got the code you are using for your query. Information on the various distributions and build systems is at BeagleBoard#Development_environments. Below is a table that alphabetically associates some of those development environments and distributions to their project page where you can find information regarding their getting started information, collaboration portal, and/or mailing list. Please add to here and BeagleBoard as necessary.
|Distribution||Project page||Mailing list||IRC channel|
omapfbplay mmap fails
Q: I'm using recent OE/Angstroem image, starting omapfbplay fails with mmap error:
root@beagleboard:/# omapfbplay sample.mpg Input #0, mpeg, from 'sample.mpg': Duration: 00:00:30.03, start: 0.223333, bitrate: 1904 kb/s Stream #0.0[0x1e0]: Video: mpeg1video, yuv420p, 640x480 [PAR 1:1 DAR 4:3], 104857 kb/s, 30 tbr, 90k tbn, 30 tbc Stream #0.1[0x1c0]: Audio: mp2, 44100 Hz, stereo, s16, 192 kb/s Using 130 frame buffers, frame_size=516096 mmap: Invalid argument
echo 4000000 > /sys/class/graphics/fb1/size
Kernel ARM cross compiling
Q: I want to compile Linux kernel for ARM with tool chain xyz. Normally I edit kernel's top level Makefile or set some environment variables to accomplish this (variables ARCH and CROSS_COMPILE). Isn't there any easier way?
A: Yes. Create a file GNUmakefile in kernel's top level directory (besides exisiting Makefile) and add (for tool chain prefix arm-linux- , adapt this to fit your tool chain):
ARCH=arm CROSS_COMPILE=arm-linux- include Makefile
Kernel verbose user space errors
Q: While running user space program xyz I get a segmentation fault, but no more info. How can I get more information from kernel what happend (besides e.g. using gdb)?
A: Two steps necessary for this:
- In kernel config enable
Kernel hacking ---> Verbose user fault messages
- In kernel command line (e.g. U-Boot) add
Q: Who is Boris?
A: You don't know Boris?
Q: What is BeagleGame?
A: Enjoy BeagleGame.