https://elinux.org/api.php?action=feedcontributions&user=Keesj&feedformat=atomeLinux.org - User contributions [en]2024-03-29T11:08:53ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=BeagleBone_Community&diff=315182BeagleBone Community2014-01-31T08:57:26Z<p>Keesj: Added some entries about JTAG & BeagleBone</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
[[Category: BeagleBone]]<br />
<br />
[[File:BeagleBone_256x249.jpg|320px|thumb|right|BeagleBone]]<br />
[[File:BeagleBone-Black-A5_product_detail_black_sm.jpg|320px|thumb|right|BeagleBone Black]]<br />
<br />
This page collects information about [http://beagleboard.org BeagleBoard.org]'s range of [http://beagleboard.org/bone BeagleBone] boards based on the [http://www.ti.com/am335x TI Sitara AM335x], an application processor SoC containing an [http://en.wikipedia.org/wiki/ARM_Cortex-A8 ARM Cortex-A8] core. The range currently consists of the original '''BeagleBone''' and the upgraded but lower cost '''BeagleBone Black'''.<br />
<br />
Most features are common to the two models. The differences between them are described in each section under a '''BeagleBone Black''' subheading.<br />
<br />
<br><br />
= Events =<br />
* ongoing 2009: [[BeagleBoard/contest|Beagle Sponsored Project Program]] - add a cool project and get a free BeagleBoard to realize it!<br />
<br />
= Description =<br />
The two models of BeagleBone share most features in common through employing only slightly different versions of the same TI Sitara SoC. In addition they both adhere to the same standard for expansion and interfacing through "cape" daughterboards. <br />
<br />
== BeagleBone (original) ==<br />
The '''BeagleBone''' is a low-cost, high-expansion board from the [http://beagleboard.org/ BeagleBoard] product line. It uses the [http://www.ti.com/am335x TI AM3358/9] SoC based on an [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8] processor core using the [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARMv7-A] architecture. It is similar in purpose to earlier BeagleBoards, and can be used either standalone or as a USB or Ethernet-connected expansion for a BeagleBoard or any other system. The BeagleBone is small even by BeagleBoard standards yet still provides much of the performance and capabilities of the larger BeagleBoards.<br />
<br />
BeagleBone ships with a 4GB micro-SD card preloaded with the [http://www.angstrom-distribution.org/ Angstrom] ARM Linux distribution.<br />
<br />
The board uses a [http://www.ti.com/product/tps65217b TI TPS65217B PMIC] to generate stable supply voltages regardless of input power variation. +5V DC power can be supplied to the BeagleBone through a barrel connector or from the mini-USB, both of which are located near the large RJ45 Ethernet connector.<br />
<br />
The mini-USB type-A OTG/device '''client-mode''' socket is multi-functional. In addition to providing an alternative source of power, it gives access to an on-board front-end two-port USB client-side hub. (This is not related to the separate '''host-mode''' USB socket described later). One port of the hub goes directly to the '''USB0''' port of the TI AM3358/9 SoC, while the other port connects to a dual-port [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H] USB-to-serial converter to provide board-to-external-host serial communications and/or JTAG debugging. The BeagleBone's Linux serial console is available through this USB serial connection.<br />
<br />
The SoC's '''USB0''' connection to the front-end hub works in one of two modes, and you can toggle between them at any time: it either presents the SD card as a mountable USB storage device to the host, or it provides an [http://www.linux-usb.org/usbnet/ Ethernet-over-USB] networking interface which yields a simple method of quick-start. The Ethernet-over-USB facility is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB as in some other designs. Full IPv4 and IPv6 networking is provided by the supplied Linux system out of the box.<br />
<br />
In addition to the USB OTG Device or '''client-mode''' facilities already described, BeagleBone also provides one '''host-mode''' USB type-A socket on the other end of the board. This is driven from the '''USB1''' connection on the AM3358/9 SoC, and provides access to USB host peripherals such as mice, keyboards, storage, and wifi or Bluetooth dongles, or a USB hub for further expansion.<br />
<br />
== BeagleBone Black ==<br />
On 23rd April 2013, Beagleboard officially announced '''[http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black]''' at a price approximately half that of the original BeagleBone.<br />
<br />
The new board's most important new features include a AM3359 SoC upgraded to 1GHz, doubling of memory to 512MB, use of faster DDR3 memory in contrast to the DDR2 of the original BeagleBone, and a new HDMI audio/visual output. (The original BeagleBone required an additional cape daughterboard for graphic output).<br />
<br />
= Specifications =<br />
The two boards are very similar in those features provided directly by the SoC. Despite the original BeagleBone being specified as using "AM3358/9", in practice most boards are believed to have shipped with the AM3359 generic part. BeagleBone Black has therefore upgraded only the specific device selected from the AM3359 range, and hence the differences are few. In contrast, the boards have significantly different designs but a high degree of compatibility.<br />
== BeagleBone ==<br />
* Up to 720 MHz superscalar ARM Cortex-A8 AM3358/9<br />
* 256 MB DDR2 RAM<br />
* 10/100 Ethernet RJ45 socket, IPv4 and IPv6 networking<br />
* MicroSD slot and 4GB microSD card supplied<br />
* Preloaded with Angstrom ARM Linux Distribution<br />
* Single USB 2.0 type A host port<br />
* Dual USB hub on USB 2.0 type mini-A OTG device port<br />
* On-board USB-to-serial/JTAG over one shared USB device port<br />
* Storage-over-USB or Ethernet-over-USB on other USB device port<br />
* Extensive I/O: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC<br />
* +5V DC power from barrel connector or USB device port<br />
* Power consumption of 300-500mA at 5V<br />
* Two 46-pin 3.3-V peripheral headers with multiplexed LCD signals<br />
* Board size: 3.4" × 2.1" (86.4mm x 53.3mm) -- fits in an Altoid tin<br />
<br />
== BeagleBone Black (differences) ==<br />
* 1 GHz superscalar ARM Cortex-A8 AM3359<br />
* 512 MB DDR3 RAM<br />
* On-board 2 GB eMMC flash, preloaded with Angstrom ARM Linux Distribution<br />
* MicroSD slot for additional user data or operating systems (no card supplied)<br />
* USB 2.0 type A host port<br />
* Dedicated single mini-USB 2.0 client port (no additional 2-port hub)<br />
* New micro-HDMI audio/visual output<br />
* USB-to-serial and USB-to-JTAG interfaces removed (available on expansion headers)<br />
* Power expansion header for backlight removed, battery charging moved onto pads<br />
* Lower power consumption of 210-460 mA at 5V<br />
<br />
= Expansion Connectors =<br />
The BeagleBone provides two 46-pin dual-row expansion connectors "'''P9'''" and "'''P8'''" which are also known as "'''Expansion A'''" and "'''Expansion B'''", respectively. The location and pinout of these connectors is illustrated below (click tables to enlarge). All signals on expansion headers are 3.3V except where indicated otherwise.<br />
<br />
=== P9 and P8 - Each 2x23 pins ===<br />
[[File:BeagleBone_P9_256x256.jpg|256px|left|top|border|P9 Header|link=File:BeagleBone_p9_pinout.jpg]]<br />
[[File:BeagleBone_P9_P8_256x256.jpg|256px|top|border|BeagleBone P9 + P8|link=File:BeagleBone_P9_P8_512x512.jpg]]<br />
[[File:BeagleBone_P8_256x256.jpg|256px|top|border|P8 Header|link=File:BeagleBone_p8_pinout.jpg]]<br />
<p><br><br />
In addition to the two large headers above, a small 10-pin dual-row connector "'''P6'''" provides a "'''PMIC Expansion'''" that brings out some additional signals from the TPS65217B Power Management IC, using the following pinout:<br />
<br />
=== P6 - 2x5 pins ===<br />
[[File:BeagleBone_P6_464x222.jpg|464px|left|middle|border|P6 MPIC Expansion Header]]<br />
<br />
'''NB. P6 is not available on BeagleBone Black'''<br />
<br />
'''IMPORTANT'''<br />
<br />
This diagram of P6 provides an '''UNDERSIDE PINOUT''' view.<br />
<br />
It is therefore ''' ''laterally inverted'' ''' relative to the photograph.<br />
<br />
To obtain the top-side pinout that corresponds to the physical orientation shown in the photograph, swap the two rows of pins so that odd-numbered pins are on the left of even-numbered pins.<br style="clear: both" /><br />
<br />
= USB 2.0 Powered Hubs = <br />
<br />
USB 2.0 Powered Hub connects multiple USB devices i.e. Keyboard , Mouse ,etc to the Single USB Host Port on the BBB Device. The Advantage a Powered USB Hub provide VS USB Port is the Power draw available for device connected to the Hub. <br />
<br />
* [http://www.belkin.com/us/F4U040-Belkin/p/P-F4U040/ Belkin USB 2.0 Powered Hub] <br />
:Expanded Hub Features <br />
:* 4 Port Powered USB 2.0 Hub <br />
:* Plug and Play <br />
:* includes Micro USB Cable<br />
:* Includes Power Adaptor which is Made In China and provides 5V 2.6A Power Supply<br />
:* lsusb Info - ID 05e3:0608 Genesys Logic Inc. USB-2.0 4-Port Hub <br />
:* NO LED Indicator for Activity / Plugged In Display <br />
:* Packaging indicates Part # - F4U040SA <br />
:* Packaging does not mention Linux Kernel compatibility OR Power in Amps provided by the Hub <br />
:* Packaging indicates compatibility with Windows 7 & Mac OS 9.2 and Above<br />
<br />
= Expansion Boards and Accessories =<br />
<br />
<br />
== Capes ==<br />
A '''BeagleBone Cape''' is an expansion board which can be plugged into the BeagleBone's two 46-pin dual-row '''Expansion Headers''' and which in turns provides similar headers onto which further capes can be stacked. Up to four capes at a time can be stacked on top of a BeagleBone. An expansion board which can be fitted only at the top of a stack of capes (usually for physical reasons) is a special case of "cape", but this usage is common for display expansion boards such as LCDs (see next section).<br />
<br />
Capes are required to provide a 32Kbyte I2C-addressed EEPROM which holds board information such as board name, serial number and revision, although this is typically omitted on simple prototyping capes. Capes are also expected to provide a 2-position DIP switch to select their address in the stack, although this too is often omitted in prototyping capes.<br />
<br />
The [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] seeks to index all existing capes and cape concepts, including private projects. A [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page] is available to help add capes to the list.<br />
<br />
This section lists only those capes which are available commercially or which are close to a production release, as well as open hardware designs.<br />
<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_DVID CircuitCo BeagleBone DVI-D cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breadboard CircuitCo BeagleBone Breadboard cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breakout CircuitCo BeagleBone Breakout cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus CircuitCo BeagleBone CANBus cape]<br />
* [[CircuitCo/BeagleBone_RS232|CircuitCo BeagleBone RS232 cape]]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Battery CircuitCo BeagleBone Battery cape]<br />
* [http://www.tigal.com/product/3526/ Chipsee - BeagleBone Black Expansion Capacitive]<br />
* [http://www.tigal.com/product/3528/ Chipsee - BeagleBone Black Expansion Resistive]<br />
* [http://www.adafruit.com/products/572 Adafruit Proto Cape kit for BeagleBone]<br />
* [http://www.towertech.it/en/products/hardware/tt3201-can-cape/ TowerTech TT3201 Multi-Channel CAN Cape]<br />
* [https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Special Computing Spartan-3A FPGA cape for BeagleBone] -- in development<br />
* [http://syntheticlifeforms.net/?p=43 Thinking Machines LCD-IO Expansion Cape] -- in development<br />
* [https://github.com/piranha32/FlyingBone Open Source BeagleBone Prototyping Board] -- piranha32 GitHub repository<br />
* [http://www.armkits.com/product/beaglebone-hdmicape.asp Embest BeagleBone HDMI cape]<br />
* [http://www.logicsupply.com/cbb-proto/ Logic Supply LGX BeagleBone Proto Cape]<br />
* [http://exadler.myshopify.com/products/dual-motor-controller-cape-dmcc-mk-6 DMCC (Dual Motor Controller Cape) for DC brushed motors ]<br />
* [http://www.tigal.com/product/2413/ TIGAL - BeagleBone Proto Cape]<br />
* [http://www.tigal.com/product/3651/ TIGAL - BeagleBone mikroBUS Cape]<br />
* [http://www.mikronauts.com/proto/ezasbone/ Mikronauts - EZasBone BeagleBone / BeagleBone Black stacking Prototyping Cape]<br />
<br />
== Wifi ==<br />
These USB Wifi modules have been tested and validated to work with the BeagleBone Black: <br />
* [http://www.logicsupply.com/uwn100/ Logic Supply UWN100 Compact USB Wifi Module]<br />
* [http://www.logicsupply.com/uwn200/ Logic Supply UWN200 Compact USB Wifi Module with Antenna]<br />
* D-Link DWA-121 (Version A1) Wireless N 150 Pico [Realtek RTL8188CUS] works out-of-the-box with Arch Linux (3.12.1)<br />
<br />
== Audio ==<br />
See [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/07/06/bbb--building-a-dac here] for how to use the I2S interface for audio.<br />
<br />
== Battery Power, Charging and Power Management ==<br />
The BeagleBone Black has a built-in power management IC (PMIC) which generates and controls all of the voltage levels used by the board. The PMIC contains Li-Po / Li-Ion battery charging capability which means that it is extremely simple (and low cost) to enable portable use. There is also a built-in push-button on the BBB which can be used to soft power on/power off the board. See [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system this link] for information.<br />
<br />
== Intelligent Power Switch ==<br />
The [http://www.pi-supply.com/ Pi Supply] [http://www.pi-supply.com/product/pi-supply-raspberry-pi-power-switch/ Switch v1.1] was originally designed for use as an automatic on off power supply switch for the Raspberry Pi which includes on, off and soft shutdown switches. The soft shutdown switch is fully programmable using software on the Pi to control the GPIO.<br />
<br />
However the [http://www.pi-supply.com/product/pi-supply-raspberry-pi-power-switch/ Pi Supply Switch v1.1] is also compatible with BeagleBone boards (both the classic and black) as well as the OLIMEX A13-OLINUXINO single board computer.<br />
<br />
A very useful add on to help you manage power on your BeagleBone.<br />
<br />
== LCD Displays and Other Expansions ==<br />
LCD displays for the BeagleBone are typically implemented as capes which plug in as the ''' ''top board'' ''' in a stack of capes, for reasons of visibility. Such displays are often larger than the BeagleBone itself, so the normal physical relationship in which a daughterboard is smaller than its host board is inverted. In this arrangement it is the expansion board that provides the physical support for the BeagleBone.<br />
<br />
* [[File:Beaglebone.jpg|320px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-beaglebone NAXING Electronics BeadaFrame] with BeagleBone companion board<br />
:Expanded Hardware Features:<br />
:* 7" 800x480 TFT LCD screen<br />
:* PWM Backlight control<br />
:* Resistive touch panel<br />
:* Plastic frame<br />
:* 256MB Nand flash(K9F2G08)<br />
:* RS232 serial ports(UART1 w/ CTS&RTS)<br />
:* Stereo audio out<br />
:* Micro-phone in<br />
:* 6 x USER buttons<br />
:* PWM Beeper<br />
:* RTC with Battery(DS1302)<br />
<br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD3 CircuitCo BeagleBone LCD3 cape and LCD display]<br />
: 3.5" TFT LCD screen, resolution 320x240, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 CircuitCo BeagleBone LCD4 cape and LCD display]<br />
: 4" TFT LCD screen, resolution 480x272, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD7 CircuitCo BeagleBone LCD7 cape and LCD display]<br />
: 7" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, rear mount for BeagleBone and capes.<br />
* A very low cost LCD implementation for the BeagleBone Black using the PRU-ICSS is [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--connecting-up-an-lcd here]. It requires a graphics library to be written; currently it just displays a couple of lines on the screen.<br />
* [http://www.chipsee.com/best-product/bbb-exp-c.html ChipSee BBB-EXP-C BeagleBone Black 7 inch LCD cape and expansion I/O]<br />
: 7" LCD screen, resolution 1024*600, 5 point Capacitive touchscreen, 5 user keys, audio in/out, RS232/485/CAN, 3 axis accelerometer. Available at [http://www.logicsupply.com/bbb-exp-c Logic Supply US] and [http://www.logicsupply.eu/touchscreen-displays/bbb-exp-c/ Logic Supply EU].<br />
* [http://www.4dsystems.com.au/product/22/125/Beagle_Bone_LCD_Capes/4DCAPE_43/ 4D Systems 4.3" LCD CAPE]<br />
: 4.3" TFT LCD screen, resolution 480x272, available in non-touch and 4-wire resistive touchscreen versions, with seven buttons.<br />
* [http://www.4dsystems.com.au/product/22/138/Beagle_Bone_LCD_Capes/4DCAPE_70T/ 4D Systems 7.0" LCD CAPE]<br />
: 7.0" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, with seven buttons and rear mount for an additional cape.<br />
<br />
== Cases ==<br />
* [http://www.tigal.com/product/3458 TIGAL - BeagleBone Black Case]<br />
* [http://www.adafruit.com/products/699 Adafruit Bone Box - Enclosure for Beagle Bone]<br />
* [http://en.wikipedia.org/wiki/Altoids An Altoids Tin - Beaglebone Black fits very nicely inside a regular sized Altoids tin]<br />
* [http://www.skpang.co.uk/catalog/acrylic-cover-for-beaglebone-p-1076.html SK Pang Acrylic Cover for BeagleBone]<br />
* [http://specialcomp.com/beagleboard/BB-Bone-assy2_l.jpg Special Computing Bone Acrylic Case]<br />
* [http://www.thingiverse.com/thing:19153 canadaduane's 3D-printable BeagleBone Case design]<br />
* [http://www.thingiverse.com/thing:16195 NinjaBlock's 3D-printable Beaglebone front panel design]<br />
* [http://www.thingiverse.com/thing:20122 builttospec's laser-cut design for BeagleBone Enclosure with DVI Cape]<br />
* [http://www.built-to-spec.com/blog/2012/03/01/beaglebone-case-update-and-new-kits-page/ Built to Spec BeagleBone Case Update], and [http://builttospecstore.storenvy.com/products/225603-beaglebone-enclosure final product]<br />
* [http://www.phenoptix.com/products/beagle-bone-black-case-clip-together-enclosure Phenoptix (UK) BeagleBone Black clip-together enclosure]<br />
* [http://www.logicsupply.com/bb100/ BeagleBone Black Compact Metal Enclosure in Black - Logic Supply US] [http://www.logicsupply.eu/cases/mini-pc-cases/bb100/ Logic Supply EU]. Open Source design available on [https://github.com/lgxlogic/LGX-BeagleBoneBlack-Enclosure GitHub]<br />
* [http://www.logicsupply.com/bb100-orange/ BeagleBone Black Compact Metal Enclosure in Orange - Logic Supply US] [http://www.logicsupply.eu/cases/mini-pc-cases/bb100-orange/ Logic Supply EU]<br />
<br />
= BeagleBone Operating Systems =<br />
BeagleBone's default operating system is [http://www.angstrom-distribution.org/ Angstrom], which ships with the board. This section provides basic information on Angstrom and other operating systems commonly used on BeagleBone. This information may help in making a preliminary choice, but full details should be obtained from the home sites.<br />
<br />
The latest images of the official Angstrom images for BeagleBoard.org products can be found at [http://beagleboard.org/latest-images the beagleboard.org latest images web page]<br />
<br />
=== Angstrom ===<br />
* Home site: http://www.angstrom-distribution.org/<br />
* Mailing lists: [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel angstrom-distro-devel] and [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users angstrom-distro-users]<br />
* IRC channel: irc://irc.freenode.net/#angstrom<br />
Ångström was started by a small group of people who worked on the OpenEmbedded, OpenZaurus and OpenSimpad projects to unify their effort to make a stable and user-friendly distribution for embedded devices like handhelds, set top boxes and network-attached storage devices.<br />
Ångström can scale down to devices with only 4MB of flash storage.<br />
<br />
The Angstrom community does not provide a forum, [http://www.angstrom-distribution.org/contact intentionally].<br />
<br />
Angstrom uses [http://www.busybox.net/ Busybox] for many key utilities, which has both pros and cons. Advantages include requiring less storage space and a smaller memory footprint for many common utilities, which also improves system startup time and performance. The main disadvantages stem from those utilities not mirroring exactly their full-size counterparts. These differences can be annoying if one is used to standard behavior, and may also break shell scripts that rely on portable functionality.<br />
<br />
Angstrom uses [http://connman.net/ connman] for network connection management, but no documentation is available for this currently. Also, man(1) and man pages are not provided by default, nor debugging utilities like strace(1) and tcpdump(1). Getting started may therefore present difficulties, depending on experience.<br />
<br />
=== Debian ===<br />
* See [[BeagleBoardDebian]]<br />
* Home site: [http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort]<br />
* Mailing list: http://lists.debian.org/debian-arm/<br />
* IRC channel: irc://irc.debian.org/debian-arm<br />
The ARM EABI port is the default port of the standard Debian distribution of Linux for the ARM architecture ("armel").<br />
EABI ("Embedded ABI") is actually a family of ABIs, and one of the "subABIs" is the GNU EABI for Linux which is used for this port.<br />
Starting with Debian 7.0 (Wheezy) there is a port targeted at newer (armv7 with fpu) hardware with another ABI ("armhf").<br />
<br />
The [http://www.debian.org/intro/about Debian Project] is strongly committed to software freedom, and has a long pedigree and a good reputation.<br />
<br />
=== Ubuntu ===<br />
* See [http://www.armhf.com/index.php/boards/beaglebone-black ARMhf]<br />
<br />
The vision for Ubuntu is part social and part economic: free software, available free of charge to everybody on the same terms, and funded through a portfolio of services provided by Canonical.<br />
<br />
The first version of Ubuntu was based on the GNOME desktop, but has since added a KDE edition, Kubuntu, and a server edition. All of the editions of Ubuntu share common infrastructure and software. In recent years, special emphasis has been placed on netbooks for lightweight, connected, mobile computing, and on the cloud as a new architecture for data centres.<br />
<br />
=== Fedora ===<br />
* See [[BeagleBoardFedora]].<br />
* Home site: http://fedoraproject.org/wiki/Architectures/ARM<br />
* Mailing list: http://lists.fedoraproject.org/pipermail/arm/<br />
* IRC channel: irc://irc.freenode.net/#fedora-arm<br />
The Fedora Project is sponsored by Red Hat, which invests in its infrastructure and resources to encourage collaboration and incubate innovative new technologies. Some of these technologies may later be integrated into Red Hat products. They are developed in Fedora and produced under a free and open source license from inception, so other free software communities and projects are free to study, adopt, and modify them.<br />
<br />
Red Hat has been a major player since the earliest days of Linux distributions, and has earned a good reputation for solidity which continues in Fedora. The Fedora ARM initiative is very active (see mailing list).<br />
<br />
=== ArchLinux ===<br />
* Home site: http://archlinuxarm.org/platforms/armv7/beaglebone<br />
* Source repository: https://github.com/archlinuxarm/PKGBUILDs<br />
* IRC channel: irc://irc.freenode.net/#archlinux-arm<br />
Arch Linux for BeagleBone is a version of the Arch Linux ARM distribution. This carries forward the Arch Linux philosophy of simplicity and user-centrism, targeting and accommodating ''competent'' Linux users by giving them complete control and responsibility over the system. Instructions are provided to assist in navigating the nuances of installation on the varied ARM platforms; however, the system itself will offer little assistance to the user.<br />
<br />
The entire distribution is on a rolling-release cycle that can be updated daily through small packages instead of huge updates on a defined release schedule. Most packages are unmodified from the code which upstream developers release.<br />
<br />
=== Gentoo ===<br />
* Home site: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml<br />
* IRC channel: irc://irc.freenode.net/#gentoo-embedded<br />
Gentoo is a source-based '' '''meta'''-distribution'' of Linux. Instead of distributing a standard system image built with predefined options, Gentoo gives each user the means to create their own customized system that doesn't contain unused bloat and with minimum dependencies. Upgrades are incremental and under user control, so a Gentoo system is normally always up-to-date and wholesale upgrades are avoided.<br />
<br />
Being a source-based system, the downside of Gentoo for low-power ARM systems is very long install times for large applications. Cross-compilation on x86 machines and [http://www.gentoo.org/doc/en/distcc.xml distcc] can overcome this problem, but they add complexity.<br />
<br />
=== Sabayon ===<br />
* Home site: [http://wiki.sabayon.org/index.php?title=Hitchhikers_Guide_to_the_BeagleBone_%28and_ARMv7a%29 wiki.sabayon.org/Hitchhikers Guide to the BeagleBone]<br />
* IRC channel: irc://irc.freenode.net/#sabayon<br />
Sabayon Linux uses the mechanisms of Gentoo to create a pre-configured Linux distribution that can be installed as rapidly as a normal binary distribution, but still retains the benefits of Gentoo's source-based package management. Sabayon on Intel/AMD also provides the Entropy binary package management system, which could in principle greatly ease installation of packages on resource-constrained embedded Linux devices, but this is not yet available for ARM.<br />
<br />
Although it is still early days for Sabayon on ARM (and hence on BeagleBone), there is regular progress reported on [http://lxnay.wordpress.com/2012/ lxnay's blog], and contributions from the community would probably accelerate the work.<br />
<br />
=== MINIX 3 ===<br />
* Home site: [http://wiki.minix3.org/DevelopersGuide/MinixOnARM MINIX 3 on ARM]<br />
* IRC channel: irc://irc.freenode.net/#minix<br />
MINIX 3 is a POSIX compliant, micro-kernel based, operating system with a unique set of reliability features. The MINIX 3 team considers the BeagleBone Black as it's current main target for ARM. There are no binaries available but building from scratch is very easy and fast!<br />
<br />
=== Buildroot ===<br />
* Home site: http://www.zoobab.com/beaglebone<br />
* Buildroot project site: http://buildroot.uclibc.org/<br />
Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.<br />
<br />
The resulting root filesystem is mounted read-only, but other filesystems can be mounted read/write for persistence. Although user accounts can be created, in practice almost everything is done as root. Buildroot uses no package manager. Instead, package selection is managed through '''make menuconfig'''.<br />
<br />
=== Nerves Erlang/OTP ===<br />
* Home site: http://nerves-project.org/<br />
* Source repository: https://github.com/nerves-project/bbone-erlang-buildroot<br />
* Erlang project site: http://www.erlang.org/<br />
Erlang is a programming language used to build massively scalable soft realtime systems with high availability requirements (5-9’s). Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang’s runtime system has built-in support for concurrency, distribution and fault tolerance.<br />
<br />
OTP is a set of Erlang libraries and design principles providing middle-ware to develop these systems. It includes its own distributed database, applications to interface towards other languages, debugging and release handling tools.<br />
<br />
The Nerves project provides an embedded Linux-based environment for running Erlang and an easy-to-use API to access common I/O interfaces, based on '''Buildroot''' (see above). If you are interested in running an Erlang node on a low power ARM-based board such as BeagleBone, this project can get you started.<br />
<br />
= Board recovery =<br />
* See [http://elinux.org/BeagleBoardRecovery#USB_recovery BeagleBoardRecovery] ''--- (*) Check applicability''<br />
<br />
= Software Development =<br />
Software development on the BeagleBone is normally no different to any other Linux platform, and typically varies with language and with the IDE used, if any. This section deals only with development issues that are specific to BeagleBone, or mostly so.<br />
<br />
=== Cloud9 IDE and Bonescript ===<br />
''..... description here .....''<br />
* Source repository: https://github.com/jadonk/bonescript<br />
* Language documentation: http://nodejs.org/<br />
<br />
=== BeagleBone JTAG Debugging ===<br />
''..... description here .....''<br />
<br />
The BeagleBone White is the developers paradise in terms of debugging. You just need to plug a single usb connector to get a serial + JTAG. There is the openocd package with basic support for the Cortex-A8 read [[BeagleBoardOpenOCD]] but if you want to get some work done you are probably better of using Code Composer Studio. Here is a video about using Code Composer Studio on the BeagleBone White<br />
[http://www.youtube.com/watch?v=ra8STql8pJM&list=PL2JiIx7dnbsG09NsK8Rbd9GHqoREz6hKK MINIX3 on ARM : BeagleBone White && Code Composer studio debug]<br />
<br />
===Using Netbeans to remotely compile and debug C/C++===<br />
<br />
When developing c/c++ on a linux desktop, a toolchain is available for cross-compiling the code for arm. However no such toolchain is readily available for windows. Netbeans can be used to write the code on your desktop, save it in a location accessible to the beagle, and then automatically compile it on the beagle itself using ssh and the built in compiler on the beaglebone's OS.<br />
<br />
Netbeans can also use GDB for remote debugging over ssh.<br />
<br />
Requirements:<br />
<br />
* Set up a samba / smb network share through which code can be shared between both desktop and beagle<br />
* Give netbeans the SSh login details of the beagle<br />
* Give netbeans the path mapping so it can translate between the desktop code folder and beagle code folder<br />
* Setup only takes a few minutes.<br />
<br />
====More info====<br />
<br />
* Download Netbeans (Windows/Linux/OS-X/Solaris): http://www.netbeans.org/<br />
* Example tutorial on setting this up: http://mechomaniac.com/BeagleboardDevelopmentWithNetbeans<br />
<br />
<br />
= Kernel =<br />
<br />
=== Getting the Right Kernel ===<br />
The modern BeagleBone kernels are Maintained by Koen Kooi and are available on the 3.8 branch at https://github.com/beagleboard/kernel/tree/3.8 . This repo contains a set of patches and a script which downloads a mainline kernel and then patches it appropriately. Exact steps for building it are in the README.<br />
<br />
=== Step-by-step guide to building a BBB kernel ===<br />
There is a step-by-step guide to building a BeagleBone Black (BBB) kernel at http://elinux.org/Building_BBB_Kernel<br />
<br />
=== Device Tree ===<br />
The 3.5 and newer BeagleBone kernels make use of [[Device Tree]]. A Device Tree is a text file which describes the layout of a machine, commonly the combination of a system-on-chip (SoC) and a board, so that the kernel can know at what addresses and on which buses hardware is located. The BeagleBone kernels make use of an extension called [[Capemgr|Capemgr]] which allows dynamic loading and unloading of device tree fragments both at compile time and from userspace post-boot.<br />
Learning about the Device Tree is very essential, if you wish to be able to manipulate pins and be able to use them as inputs/outputs. There is a [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 short guide to it here] (part-way down the page). In a nutshell, the device tree can be manipulated by creating a text 'fragment' file that can be converted into a .dtbo file using a program called dtc which is already installed on the BeagleBone Black. The .dtbo file can then be installed and uninstalled as desired. The procedures to install and uninstall are at that link:<br />
<br />
<tt>echo cape-bone-name > $SLOTS</tt> to install, and<br />
<br />
<br />
<tt>echo -<slotnum> > $SLOTS</tt> to uninstall,<br />
but read through the web page and comments section first to see what $SLOT is set to).<br />
<br />
= FAQ =<br />
<br />
For BeagleBoard frequently asked questions (FAQ) see [[BeagleBoardFAQ|community FAQ]] and "official" [http://beagleboard.org/support/faq BeagleBoard.org FAQ].<br />
<br />
= Projects =<br />
<br />
* [[BeagleBone 6502 RemoteProc cape]]<br />
<br />
= Links =<br />
== Home site and Community ==<br />
* [http://beagleboard.org/ beagleboard.org] -- home for BeagleBoard and BeagleBone products<br />
* [http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black] -- manufacturer's page for the second BeagleBone board<br />
* irc://irc.freenode.net/#beagle -- official combined IRC channel<br />
* [http://beagleboard.org/discuss Google Groups forums/mailing list] -- [https://groups.google.com/forum/?fromgroups#!forum/beagleboard English], [http://groups.google.com/group/pandabeagle-jp Japan], [http://groups.google.com/group/beagleboard-brasil Brasil], [https://groups.google.com/group/beagle-board-turkiye Turkey]<br />
* [http://beagleboard.org/project BeagleBoard and BeagleBone projects list]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] and its [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page]<br />
* [http://www.adafruit.com/blog/category/beaglebone/ BeagleBone articles at Adafruit blog] -- products, projects and tutorials<br />
* Use [http://www.google.de/ Google] to search beagleboard.org (including [http://www.beagleboard.org/irclogs/ IRC logs]) using ''site:beagleboard.org <search term>''<br />
* [https://www.linux.com/news/embedded-mobile/mobile-linux/715298-45-beaglebone-black-keeps-eyes-on-raspberry-pi Linux.com report on BeagleBone Black] -- with words from beagleBoard.org's cofounder Jason Kridner<br />
* [https://github.com/selsinork/beaglebone-black-pinmux github.com/selsinork/beaglebone-black-pinmux] -- pinmux data for BeagleBone Black, including extraction scripts<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 Element 14 knode blog: Working with the PRU-ICSS] -- detailed tutorial on starting with the PRU on BBB<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/01/bbb-neon-and-making-tintin-bigger BBB, NEON and making Tintin bigger] - introduction to using NEON on the BBB<br />
* [http://forum.beaglefu.com/ BeagleFu] -- BeagleBone/Board Community, News and Projects.<br />
<br />
== Tutorials and Videos ==<br />
* [http://beagleboard.org/static/bonescript/bone101/index.html ''BeagleBone: BeagleBoard-101 Intro''] -- slides (turn off Javascript for single page)<br />
* [http://www.youtube.com/watch?v=EEnOWR-GXjk ''BeagleBone Intro''], video by Jason Kridner, Texas Instruments<br />
* [http://www.youtube.com/watch?v=Y0uqRVxismQ ''How-To: Get Started with the BeagleBone''], video by Matt Richardson, MakeMagazine<br />
* [http://www.youtube.com/watch?v=z6b4zlh0IrE ''The Beaglebone - Unboxing, Introduction Tutorial and First Example''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=vFv_-ykLppo ''Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=SaIpz00lE84 ''Beaglebone: GPIO Programming on ARM Embedded Linux''], video by Derek Molloy, DCU/EE<br />
* [https://gist.github.com/4013192 ''C code for GPIO polling''], sample code by Andrew Montag<br />
* [http://borderhack.com/?p=1062 First steps with the Beaglebone], introductory HOWTO by octavio at borderhack<br />
* [http://learn.adafruit.com/beaglebone Adafruit Learning System - BeagleBone] -- web page<br />
<br />
== Manuals and resources ==<br />
* [http://beagleboard.org/static/beaglebone/a3/Docs/Hardware/BONE_SRM.pdf BeagleBone System Reference Manual (rev. A3_1.0)]<br />
* [http://www.ti.com/am335x Texas Instruments - Sitara AM335x ARM Cortex-A8 Microprocessor overview]<br />
* [http://www.ti.com/product/am3359 Texas Instruments - AM3359 Sitara ARM Cortex-A8 Microprocessor full documentation]<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARM/ARMv7-AR Architecture] -- ARM Cortex-A8 architecture overview<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8 Technical Reference Manual r2p1]<br />
* [http://www.arm.com/support/university/development-platforms/cortex-a8-development-platforms.php ARM Cortex-A Development Platforms] -- ARM page on Beagle boards<br />
* [http://www.ti.com/product/tps65217b TI TPS65217 Power Management IC], [http://www.ti.com/lit/ds/symlink/tps65217.pdf TPS65217 PMIC datasheet]<br />
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H Hi-Speed Dual USB UART/FIFO IC overview], [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf FT2232H datasheet]<br />
* [http://www.linux-usb.org/gadget/index.html Linux-USB Gadget API Framework] and [http://www.linux-usb.org/gadget/h2-otg.html USB OTG], and [http://forums.gentoo.org/viewtopic-t-843255.html kernel config] -- Ethernet-over-USB<br />
* [https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub Beaglebone and the 3.8 Kernel] Details about the 3.8 Kernel, its use of DT and the capemanager.<br />
* [https://github.com/lgxlogic/BeagleBoneBlack-3D-Model SolidWorks 3D model of the BeagleBone Black] on GitHub, includes 3D PDF.<br />
<br />
== Translations ==<br />
* 한국어:[[KR:BeagleBone]]<br />
<br />
== Errata ==<br />
<br />
= Subpages =<br />
http://elinux.org/BeagleBone_Usb_Networking<br />
http://elinux.org/BeagleBone_and_the_3.8_Kernel</div>Keesjhttps://elinux.org/index.php?title=BeagleBone_Community&diff=315176BeagleBone Community2014-01-31T08:42:42Z<p>Keesj: Added MINIX 3 a supported OS/Distro</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
[[Category: BeagleBone]]<br />
<br />
[[File:BeagleBone_256x249.jpg|320px|thumb|right|BeagleBone]]<br />
[[File:BeagleBone-Black-A5_product_detail_black_sm.jpg|320px|thumb|right|BeagleBone Black]]<br />
<br />
This page collects information about [http://beagleboard.org BeagleBoard.org]'s range of [http://beagleboard.org/bone BeagleBone] boards based on the [http://www.ti.com/am335x TI Sitara AM335x], an application processor SoC containing an [http://en.wikipedia.org/wiki/ARM_Cortex-A8 ARM Cortex-A8] core. The range currently consists of the original '''BeagleBone''' and the upgraded but lower cost '''BeagleBone Black'''.<br />
<br />
Most features are common to the two models. The differences between them are described in each section under a '''BeagleBone Black''' subheading.<br />
<br />
<br><br />
= Events =<br />
* ongoing 2009: [[BeagleBoard/contest|Beagle Sponsored Project Program]] - add a cool project and get a free BeagleBoard to realize it!<br />
<br />
= Description =<br />
The two models of BeagleBone share most features in common through employing only slightly different versions of the same TI Sitara SoC. In addition they both adhere to the same standard for expansion and interfacing through "cape" daughterboards. <br />
<br />
== BeagleBone (original) ==<br />
The '''BeagleBone''' is a low-cost, high-expansion board from the [http://beagleboard.org/ BeagleBoard] product line. It uses the [http://www.ti.com/am335x TI AM3358/9] SoC based on an [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8] processor core using the [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARMv7-A] architecture. It is similar in purpose to earlier BeagleBoards, and can be used either standalone or as a USB or Ethernet-connected expansion for a BeagleBoard or any other system. The BeagleBone is small even by BeagleBoard standards yet still provides much of the performance and capabilities of the larger BeagleBoards.<br />
<br />
BeagleBone ships with a 4GB micro-SD card preloaded with the [http://www.angstrom-distribution.org/ Angstrom] ARM Linux distribution.<br />
<br />
The board uses a [http://www.ti.com/product/tps65217b TI TPS65217B PMIC] to generate stable supply voltages regardless of input power variation. +5V DC power can be supplied to the BeagleBone through a barrel connector or from the mini-USB, both of which are located near the large RJ45 Ethernet connector.<br />
<br />
The mini-USB type-A OTG/device '''client-mode''' socket is multi-functional. In addition to providing an alternative source of power, it gives access to an on-board front-end two-port USB client-side hub. (This is not related to the separate '''host-mode''' USB socket described later). One port of the hub goes directly to the '''USB0''' port of the TI AM3358/9 SoC, while the other port connects to a dual-port [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H] USB-to-serial converter to provide board-to-external-host serial communications and/or JTAG debugging. The BeagleBone's Linux serial console is available through this USB serial connection.<br />
<br />
The SoC's '''USB0''' connection to the front-end hub works in one of two modes, and you can toggle between them at any time: it either presents the SD card as a mountable USB storage device to the host, or it provides an [http://www.linux-usb.org/usbnet/ Ethernet-over-USB] networking interface which yields a simple method of quick-start. The Ethernet-over-USB facility is additional to the BeagleBone's normal 10/100 Ethernet interface, which is directly implemented in the SoC rather than hanging off USB as in some other designs. Full IPv4 and IPv6 networking is provided by the supplied Linux system out of the box.<br />
<br />
In addition to the USB OTG Device or '''client-mode''' facilities already described, BeagleBone also provides one '''host-mode''' USB type-A socket on the other end of the board. This is driven from the '''USB1''' connection on the AM3358/9 SoC, and provides access to USB host peripherals such as mice, keyboards, storage, and wifi or Bluetooth dongles, or a USB hub for further expansion.<br />
<br />
== BeagleBone Black ==<br />
On 23rd April 2013, Beagleboard officially announced '''[http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black]''' at a price approximately half that of the original BeagleBone.<br />
<br />
The new board's most important new features include a AM3359 SoC upgraded to 1GHz, doubling of memory to 512MB, use of faster DDR3 memory in contrast to the DDR2 of the original BeagleBone, and a new HDMI audio/visual output. (The original BeagleBone required an additional cape daughterboard for graphic output).<br />
<br />
= Specifications =<br />
The two boards are very similar in those features provided directly by the SoC. Despite the original BeagleBone being specified as using "AM3358/9", in practice most boards are believed to have shipped with the AM3359 generic part. BeagleBone Black has therefore upgraded only the specific device selected from the AM3359 range, and hence the differences are few. In contrast, the boards have significantly different designs but a high degree of compatibility.<br />
== BeagleBone ==<br />
* Up to 720 MHz superscalar ARM Cortex-A8 AM3358/9<br />
* 256 MB DDR2 RAM<br />
* 10/100 Ethernet RJ45 socket, IPv4 and IPv6 networking<br />
* MicroSD slot and 4GB microSD card supplied<br />
* Preloaded with Angstrom ARM Linux Distribution<br />
* Single USB 2.0 type A host port<br />
* Dual USB hub on USB 2.0 type mini-A OTG device port<br />
* On-board USB-to-serial/JTAG over one shared USB device port<br />
* Storage-over-USB or Ethernet-over-USB on other USB device port<br />
* Extensive I/O: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC<br />
* +5V DC power from barrel connector or USB device port<br />
* Power consumption of 300-500mA at 5V<br />
* Two 46-pin 3.3-V peripheral headers with multiplexed LCD signals<br />
* Board size: 3.4" × 2.1" (86.4mm x 53.3mm) -- fits in an Altoid tin<br />
<br />
== BeagleBone Black (differences) ==<br />
* 1 GHz superscalar ARM Cortex-A8 AM3359<br />
* 512 MB DDR3 RAM<br />
* On-board 2 GB eMMC flash, preloaded with Angstrom ARM Linux Distribution<br />
* MicroSD slot for additional user data or operating systems (no card supplied)<br />
* USB 2.0 type A host port<br />
* Dedicated single mini-USB 2.0 client port (no additional 2-port hub)<br />
* New micro-HDMI audio/visual output<br />
* USB-to-serial and USB-to-JTAG interfaces removed (available on expansion headers)<br />
* Power expansion header for backlight removed, battery charging moved onto pads<br />
* Lower power consumption of 210-460 mA at 5V<br />
<br />
= Expansion Connectors =<br />
The BeagleBone provides two 46-pin dual-row expansion connectors "'''P9'''" and "'''P8'''" which are also known as "'''Expansion A'''" and "'''Expansion B'''", respectively. The location and pinout of these connectors is illustrated below (click tables to enlarge). All signals on expansion headers are 3.3V except where indicated otherwise.<br />
<br />
=== P9 and P8 - Each 2x23 pins ===<br />
[[File:BeagleBone_P9_256x256.jpg|256px|left|top|border|P9 Header|link=File:BeagleBone_p9_pinout.jpg]]<br />
[[File:BeagleBone_P9_P8_256x256.jpg|256px|top|border|BeagleBone P9 + P8|link=File:BeagleBone_P9_P8_512x512.jpg]]<br />
[[File:BeagleBone_P8_256x256.jpg|256px|top|border|P8 Header|link=File:BeagleBone_p8_pinout.jpg]]<br />
<p><br><br />
In addition to the two large headers above, a small 10-pin dual-row connector "'''P6'''" provides a "'''PMIC Expansion'''" that brings out some additional signals from the TPS65217B Power Management IC, using the following pinout:<br />
<br />
=== P6 - 2x5 pins ===<br />
[[File:BeagleBone_P6_464x222.jpg|464px|left|middle|border|P6 MPIC Expansion Header]]<br />
<br />
'''NB. P6 is not available on BeagleBone Black'''<br />
<br />
'''IMPORTANT'''<br />
<br />
This diagram of P6 provides an '''UNDERSIDE PINOUT''' view.<br />
<br />
It is therefore ''' ''laterally inverted'' ''' relative to the photograph.<br />
<br />
To obtain the top-side pinout that corresponds to the physical orientation shown in the photograph, swap the two rows of pins so that odd-numbered pins are on the left of even-numbered pins.<br style="clear: both" /><br />
<br />
= USB 2.0 Powered Hubs = <br />
<br />
USB 2.0 Powered Hub connects multiple USB devices i.e. Keyboard , Mouse ,etc to the Single USB Host Port on the BBB Device. The Advantage a Powered USB Hub provide VS USB Port is the Power draw available for device connected to the Hub. <br />
<br />
* [http://www.belkin.com/us/F4U040-Belkin/p/P-F4U040/ Belkin USB 2.0 Powered Hub] <br />
:Expanded Hub Features <br />
:* 4 Port Powered USB 2.0 Hub <br />
:* Plug and Play <br />
:* includes Micro USB Cable<br />
:* Includes Power Adaptor which is Made In China and provides 5V 2.6A Power Supply<br />
:* lsusb Info - ID 05e3:0608 Genesys Logic Inc. USB-2.0 4-Port Hub <br />
:* NO LED Indicator for Activity / Plugged In Display <br />
:* Packaging indicates Part # - F4U040SA <br />
:* Packaging does not mention Linux Kernel compatibility OR Power in Amps provided by the Hub <br />
:* Packaging indicates compatibility with Windows 7 & Mac OS 9.2 and Above<br />
<br />
= Expansion Boards and Accessories =<br />
<br />
<br />
== Capes ==<br />
A '''BeagleBone Cape''' is an expansion board which can be plugged into the BeagleBone's two 46-pin dual-row '''Expansion Headers''' and which in turns provides similar headers onto which further capes can be stacked. Up to four capes at a time can be stacked on top of a BeagleBone. An expansion board which can be fitted only at the top of a stack of capes (usually for physical reasons) is a special case of "cape", but this usage is common for display expansion boards such as LCDs (see next section).<br />
<br />
Capes are required to provide a 32Kbyte I2C-addressed EEPROM which holds board information such as board name, serial number and revision, although this is typically omitted on simple prototyping capes. Capes are also expected to provide a 2-position DIP switch to select their address in the stack, although this too is often omitted in prototyping capes.<br />
<br />
The [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] seeks to index all existing capes and cape concepts, including private projects. A [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page] is available to help add capes to the list.<br />
<br />
This section lists only those capes which are available commercially or which are close to a production release, as well as open hardware designs.<br />
<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_DVID CircuitCo BeagleBone DVI-D cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breadboard CircuitCo BeagleBone Breadboard cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Breakout CircuitCo BeagleBone Breakout cape]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_CANBus CircuitCo BeagleBone CANBus cape]<br />
* [[CircuitCo/BeagleBone_RS232|CircuitCo BeagleBone RS232 cape]]<br />
* [http://beagleboardtoys.com/wiki/index.php?title=BeagleBone_Battery CircuitCo BeagleBone Battery cape]<br />
* [http://www.tigal.com/product/3526/ Chipsee - BeagleBone Black Expansion Capacitive]<br />
* [http://www.tigal.com/product/3528/ Chipsee - BeagleBone Black Expansion Resistive]<br />
* [http://www.adafruit.com/products/572 Adafruit Proto Cape kit for BeagleBone]<br />
* [http://www.towertech.it/en/products/hardware/tt3201-can-cape/ TowerTech TT3201 Multi-Channel CAN Cape]<br />
* [https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Special Computing Spartan-3A FPGA cape for BeagleBone] -- in development<br />
* [http://syntheticlifeforms.net/?p=43 Thinking Machines LCD-IO Expansion Cape] -- in development<br />
* [https://github.com/piranha32/FlyingBone Open Source BeagleBone Prototyping Board] -- piranha32 GitHub repository<br />
* [http://www.armkits.com/product/beaglebone-hdmicape.asp Embest BeagleBone HDMI cape]<br />
* [http://www.logicsupply.com/cbb-proto/ Logic Supply LGX BeagleBone Proto Cape]<br />
* [http://exadler.myshopify.com/products/dual-motor-controller-cape-dmcc-mk-6 DMCC (Dual Motor Controller Cape) for DC brushed motors ]<br />
* [http://www.tigal.com/product/2413/ TIGAL - BeagleBone Proto Cape]<br />
* [http://www.tigal.com/product/3651/ TIGAL - BeagleBone mikroBUS Cape]<br />
* [http://www.mikronauts.com/proto/ezasbone/ Mikronauts - EZasBone BeagleBone / BeagleBone Black stacking Prototyping Cape]<br />
<br />
== Wifi ==<br />
These USB Wifi modules have been tested and validated to work with the BeagleBone Black: <br />
* [http://www.logicsupply.com/uwn100/ Logic Supply UWN100 Compact USB Wifi Module]<br />
* [http://www.logicsupply.com/uwn200/ Logic Supply UWN200 Compact USB Wifi Module with Antenna]<br />
* D-Link DWA-121 (Version A1) Wireless N 150 Pico [Realtek RTL8188CUS] works out-of-the-box with Arch Linux (3.12.1)<br />
<br />
== Audio ==<br />
See [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/07/06/bbb--building-a-dac here] for how to use the I2S interface for audio.<br />
<br />
== Battery Power, Charging and Power Management ==<br />
The BeagleBone Black has a built-in power management IC (PMIC) which generates and controls all of the voltage levels used by the board. The PMIC contains Li-Po / Li-Ion battery charging capability which means that it is extremely simple (and low cost) to enable portable use. There is also a built-in push-button on the BBB which can be used to soft power on/power off the board. See [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/08/10/bbb--rechargeable-on-board-battery-system this link] for information.<br />
<br />
== Intelligent Power Switch ==<br />
The [http://www.pi-supply.com/ Pi Supply] [http://www.pi-supply.com/product/pi-supply-raspberry-pi-power-switch/ Switch v1.1] was originally designed for use as an automatic on off power supply switch for the Raspberry Pi which includes on, off and soft shutdown switches. The soft shutdown switch is fully programmable using software on the Pi to control the GPIO.<br />
<br />
However the [http://www.pi-supply.com/product/pi-supply-raspberry-pi-power-switch/ Pi Supply Switch v1.1] is also compatible with BeagleBone boards (both the classic and black) as well as the OLIMEX A13-OLINUXINO single board computer.<br />
<br />
A very useful add on to help you manage power on your BeagleBone.<br />
<br />
== LCD Displays and Other Expansions ==<br />
LCD displays for the BeagleBone are typically implemented as capes which plug in as the ''' ''top board'' ''' in a stack of capes, for reasons of visibility. Such displays are often larger than the BeagleBone itself, so the normal physical relationship in which a daughterboard is smaller than its host board is inverted. In this arrangement it is the expansion board that provides the physical support for the BeagleBone.<br />
<br />
* [[File:Beaglebone.jpg|320px|thumb|BeadaFrame]][http://www.nxelec.com/products/hmi/beadaframe-beaglebone NAXING Electronics BeadaFrame] with BeagleBone companion board<br />
:Expanded Hardware Features:<br />
:* 7" 800x480 TFT LCD screen<br />
:* PWM Backlight control<br />
:* Resistive touch panel<br />
:* Plastic frame<br />
:* 256MB Nand flash(K9F2G08)<br />
:* RS232 serial ports(UART1 w/ CTS&RTS)<br />
:* Stereo audio out<br />
:* Micro-phone in<br />
:* 6 x USER buttons<br />
:* PWM Beeper<br />
:* RTC with Battery(DS1302)<br />
<br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD3 CircuitCo BeagleBone LCD3 cape and LCD display]<br />
: 3.5" TFT LCD screen, resolution 320x240, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD4 CircuitCo BeagleBone LCD4 cape and LCD display]<br />
: 4" TFT LCD screen, resolution 480x272, 4-wire resistive touchscreen, seven buttons at finger-friendly positions. <br />
* [http://beagleboardtoys.info/index.php?title=BeagleBone_LCD7 CircuitCo BeagleBone LCD7 cape and LCD display]<br />
: 7" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, rear mount for BeagleBone and capes.<br />
* A very low cost LCD implementation for the BeagleBone Black using the PRU-ICSS is [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/28/bbb--connecting-up-an-lcd here]. It requires a graphics library to be written; currently it just displays a couple of lines on the screen.<br />
* [http://www.chipsee.com/best-product/bbb-exp-c.html ChipSee BBB-EXP-C BeagleBone Black 7 inch LCD cape and expansion I/O]<br />
: 7" LCD screen, resolution 1024*600, 5 point Capacitive touchscreen, 5 user keys, audio in/out, RS232/485/CAN, 3 axis accelerometer. Available at [http://www.logicsupply.com/bbb-exp-c Logic Supply US] and [http://www.logicsupply.eu/touchscreen-displays/bbb-exp-c/ Logic Supply EU].<br />
* [http://www.4dsystems.com.au/product/22/125/Beagle_Bone_LCD_Capes/4DCAPE_43/ 4D Systems 4.3" LCD CAPE]<br />
: 4.3" TFT LCD screen, resolution 480x272, available in non-touch and 4-wire resistive touchscreen versions, with seven buttons.<br />
* [http://www.4dsystems.com.au/product/22/138/Beagle_Bone_LCD_Capes/4DCAPE_70T/ 4D Systems 7.0" LCD CAPE]<br />
: 7.0" TFT LCD screen, resolution 800x480, 4-wire resistive touchscreen, with seven buttons and rear mount for an additional cape.<br />
<br />
== Cases ==<br />
* [http://www.tigal.com/product/3458 TIGAL - BeagleBone Black Case]<br />
* [http://www.adafruit.com/products/699 Adafruit Bone Box - Enclosure for Beagle Bone]<br />
* [http://en.wikipedia.org/wiki/Altoids An Altoids Tin - Beaglebone Black fits very nicely inside a regular sized Altoids tin]<br />
* [http://www.skpang.co.uk/catalog/acrylic-cover-for-beaglebone-p-1076.html SK Pang Acrylic Cover for BeagleBone]<br />
* [http://specialcomp.com/beagleboard/BB-Bone-assy2_l.jpg Special Computing Bone Acrylic Case]<br />
* [http://www.thingiverse.com/thing:19153 canadaduane's 3D-printable BeagleBone Case design]<br />
* [http://www.thingiverse.com/thing:16195 NinjaBlock's 3D-printable Beaglebone front panel design]<br />
* [http://www.thingiverse.com/thing:20122 builttospec's laser-cut design for BeagleBone Enclosure with DVI Cape]<br />
* [http://www.built-to-spec.com/blog/2012/03/01/beaglebone-case-update-and-new-kits-page/ Built to Spec BeagleBone Case Update], and [http://builttospecstore.storenvy.com/products/225603-beaglebone-enclosure final product]<br />
* [http://www.phenoptix.com/products/beagle-bone-black-case-clip-together-enclosure Phenoptix (UK) BeagleBone Black clip-together enclosure]<br />
* [http://www.logicsupply.com/bb100/ BeagleBone Black Compact Metal Enclosure in Black - Logic Supply US] [http://www.logicsupply.eu/cases/mini-pc-cases/bb100/ Logic Supply EU]. Open Source design available on [https://github.com/lgxlogic/LGX-BeagleBoneBlack-Enclosure GitHub]<br />
* [http://www.logicsupply.com/bb100-orange/ BeagleBone Black Compact Metal Enclosure in Orange - Logic Supply US] [http://www.logicsupply.eu/cases/mini-pc-cases/bb100-orange/ Logic Supply EU]<br />
<br />
= BeagleBone Operating Systems =<br />
BeagleBone's default operating system is [http://www.angstrom-distribution.org/ Angstrom], which ships with the board. This section provides basic information on Angstrom and other operating systems commonly used on BeagleBone. This information may help in making a preliminary choice, but full details should be obtained from the home sites.<br />
<br />
The latest images of the official Angstrom images for BeagleBoard.org products can be found at [http://beagleboard.org/latest-images the beagleboard.org latest images web page]<br />
<br />
=== Angstrom ===<br />
* Home site: http://www.angstrom-distribution.org/<br />
* Mailing lists: [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel angstrom-distro-devel] and [http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-users angstrom-distro-users]<br />
* IRC channel: irc://irc.freenode.net/#angstrom<br />
Ångström was started by a small group of people who worked on the OpenEmbedded, OpenZaurus and OpenSimpad projects to unify their effort to make a stable and user-friendly distribution for embedded devices like handhelds, set top boxes and network-attached storage devices.<br />
Ångström can scale down to devices with only 4MB of flash storage.<br />
<br />
The Angstrom community does not provide a forum, [http://www.angstrom-distribution.org/contact intentionally].<br />
<br />
Angstrom uses [http://www.busybox.net/ Busybox] for many key utilities, which has both pros and cons. Advantages include requiring less storage space and a smaller memory footprint for many common utilities, which also improves system startup time and performance. The main disadvantages stem from those utilities not mirroring exactly their full-size counterparts. These differences can be annoying if one is used to standard behavior, and may also break shell scripts that rely on portable functionality.<br />
<br />
Angstrom uses [http://connman.net/ connman] for network connection management, but no documentation is available for this currently. Also, man(1) and man pages are not provided by default, nor debugging utilities like strace(1) and tcpdump(1). Getting started may therefore present difficulties, depending on experience.<br />
<br />
=== Debian ===<br />
* See [[BeagleBoardDebian]]<br />
* Home site: [http://wiki.debian.org/ArmEabiPort http://wiki.debian.org/ArmEabiPort]<br />
* Mailing list: http://lists.debian.org/debian-arm/<br />
* IRC channel: irc://irc.debian.org/debian-arm<br />
The ARM EABI port is the default port of the standard Debian distribution of Linux for the ARM architecture ("armel").<br />
EABI ("Embedded ABI") is actually a family of ABIs, and one of the "subABIs" is the GNU EABI for Linux which is used for this port.<br />
Starting with Debian 7.0 (Wheezy) there is a port targeted at newer (armv7 with fpu) hardware with another ABI ("armhf").<br />
<br />
The [http://www.debian.org/intro/about Debian Project] is strongly committed to software freedom, and has a long pedigree and a good reputation.<br />
<br />
=== Ubuntu ===<br />
* See [http://www.armhf.com/index.php/boards/beaglebone-black ARMhf]<br />
<br />
The vision for Ubuntu is part social and part economic: free software, available free of charge to everybody on the same terms, and funded through a portfolio of services provided by Canonical.<br />
<br />
The first version of Ubuntu was based on the GNOME desktop, but has since added a KDE edition, Kubuntu, and a server edition. All of the editions of Ubuntu share common infrastructure and software. In recent years, special emphasis has been placed on netbooks for lightweight, connected, mobile computing, and on the cloud as a new architecture for data centres.<br />
<br />
=== Fedora ===<br />
* See [[BeagleBoardFedora]].<br />
* Home site: http://fedoraproject.org/wiki/Architectures/ARM<br />
* Mailing list: http://lists.fedoraproject.org/pipermail/arm/<br />
* IRC channel: irc://irc.freenode.net/#fedora-arm<br />
The Fedora Project is sponsored by Red Hat, which invests in its infrastructure and resources to encourage collaboration and incubate innovative new technologies. Some of these technologies may later be integrated into Red Hat products. They are developed in Fedora and produced under a free and open source license from inception, so other free software communities and projects are free to study, adopt, and modify them.<br />
<br />
Red Hat has been a major player since the earliest days of Linux distributions, and has earned a good reputation for solidity which continues in Fedora. The Fedora ARM initiative is very active (see mailing list).<br />
<br />
=== ArchLinux ===<br />
* Home site: http://archlinuxarm.org/platforms/armv7/beaglebone<br />
* Source repository: https://github.com/archlinuxarm/PKGBUILDs<br />
* IRC channel: irc://irc.freenode.net/#archlinux-arm<br />
Arch Linux for BeagleBone is a version of the Arch Linux ARM distribution. This carries forward the Arch Linux philosophy of simplicity and user-centrism, targeting and accommodating ''competent'' Linux users by giving them complete control and responsibility over the system. Instructions are provided to assist in navigating the nuances of installation on the varied ARM platforms; however, the system itself will offer little assistance to the user.<br />
<br />
The entire distribution is on a rolling-release cycle that can be updated daily through small packages instead of huge updates on a defined release schedule. Most packages are unmodified from the code which upstream developers release.<br />
<br />
=== Gentoo ===<br />
* Home site: http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml<br />
* IRC channel: irc://irc.freenode.net/#gentoo-embedded<br />
Gentoo is a source-based '' '''meta'''-distribution'' of Linux. Instead of distributing a standard system image built with predefined options, Gentoo gives each user the means to create their own customized system that doesn't contain unused bloat and with minimum dependencies. Upgrades are incremental and under user control, so a Gentoo system is normally always up-to-date and wholesale upgrades are avoided.<br />
<br />
Being a source-based system, the downside of Gentoo for low-power ARM systems is very long install times for large applications. Cross-compilation on x86 machines and [http://www.gentoo.org/doc/en/distcc.xml distcc] can overcome this problem, but they add complexity.<br />
<br />
=== Sabayon ===<br />
* Home site: [http://wiki.sabayon.org/index.php?title=Hitchhikers_Guide_to_the_BeagleBone_%28and_ARMv7a%29 wiki.sabayon.org/Hitchhikers Guide to the BeagleBone]<br />
* IRC channel: irc://irc.freenode.net/#sabayon<br />
Sabayon Linux uses the mechanisms of Gentoo to create a pre-configured Linux distribution that can be installed as rapidly as a normal binary distribution, but still retains the benefits of Gentoo's source-based package management. Sabayon on Intel/AMD also provides the Entropy binary package management system, which could in principle greatly ease installation of packages on resource-constrained embedded Linux devices, but this is not yet available for ARM.<br />
<br />
Although it is still early days for Sabayon on ARM (and hence on BeagleBone), there is regular progress reported on [http://lxnay.wordpress.com/2012/ lxnay's blog], and contributions from the community would probably accelerate the work.<br />
<br />
=== MINIX 3 ===<br />
* Home site: [http://wiki.minix3.org/DevelopersGuide/MinixOnARM MINIX 3 on ARM]<br />
* IRC channel: irc://irc.freenode.net/#minix<br />
MINIX 3 is a POSIX compliant, micro-kernel based, operating system with a unique set of reliability features. The MINIX 3 team considers the BeagleBone Black as it's current main target for ARM. There are no binaries available but building from scratch is very easy and fast!<br />
<br />
=== Buildroot ===<br />
* Home site: http://www.zoobab.com/beaglebone<br />
* Buildroot project site: http://buildroot.uclibc.org/<br />
Buildroot is a set of Makefiles and patches that makes it easy to generate a complete embedded Linux system. Buildroot can generate any or all of a cross-compilation toolchain, a root filesystem, a kernel image and a bootloader image. Buildroot is useful mainly for people working with small or embedded systems, using various CPU architectures (x86, ARM, MIPS, PowerPC, etc.) : it automates the building process of your embedded system and eases the cross-compilation process.<br />
<br />
The resulting root filesystem is mounted read-only, but other filesystems can be mounted read/write for persistence. Although user accounts can be created, in practice almost everything is done as root. Buildroot uses no package manager. Instead, package selection is managed through '''make menuconfig'''.<br />
<br />
=== Nerves Erlang/OTP ===<br />
* Home site: http://nerves-project.org/<br />
* Source repository: https://github.com/nerves-project/bbone-erlang-buildroot<br />
* Erlang project site: http://www.erlang.org/<br />
Erlang is a programming language used to build massively scalable soft realtime systems with high availability requirements (5-9’s). Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang’s runtime system has built-in support for concurrency, distribution and fault tolerance.<br />
<br />
OTP is a set of Erlang libraries and design principles providing middle-ware to develop these systems. It includes its own distributed database, applications to interface towards other languages, debugging and release handling tools.<br />
<br />
The Nerves project provides an embedded Linux-based environment for running Erlang and an easy-to-use API to access common I/O interfaces, based on '''Buildroot''' (see above). If you are interested in running an Erlang node on a low power ARM-based board such as BeagleBone, this project can get you started.<br />
<br />
= Board recovery =<br />
* See [http://elinux.org/BeagleBoardRecovery#USB_recovery BeagleBoardRecovery] ''--- (*) Check applicability''<br />
<br />
= Software Development =<br />
Software development on the BeagleBone is normally no different to any other Linux platform, and typically varies with language and with the IDE used, if any. This section deals only with development issues that are specific to BeagleBone, or mostly so.<br />
<br />
=== Cloud9 IDE and Bonescript ===<br />
''..... description here .....''<br />
* Source repository: https://github.com/jadonk/bonescript<br />
* Language documentation: http://nodejs.org/<br />
<br />
=== BeagleBone JTAG Debugging ===<br />
''..... description here .....''<br />
<br />
===Using Netbeans to remotely compile and debug C/C++===<br />
<br />
When developing c/c++ on a linux desktop, a toolchain is available for cross-compiling the code for arm. However no such toolchain is readily available for windows. Netbeans can be used to write the code on your desktop, save it in a location accessible to the beagle, and then automatically compile it on the beagle itself using ssh and the built in compiler on the beaglebone's OS.<br />
<br />
Netbeans can also use GDB for remote debugging over ssh.<br />
<br />
Requirements:<br />
<br />
* Set up a samba / smb network share through which code can be shared between both desktop and beagle<br />
* Give netbeans the SSh login details of the beagle<br />
* Give netbeans the path mapping so it can translate between the desktop code folder and beagle code folder<br />
* Setup only takes a few minutes.<br />
<br />
====More info====<br />
<br />
* Download Netbeans (Windows/Linux/OS-X/Solaris): http://www.netbeans.org/<br />
* Example tutorial on setting this up: http://mechomaniac.com/BeagleboardDevelopmentWithNetbeans<br />
<br />
<br />
= Kernel =<br />
<br />
=== Getting the Right Kernel ===<br />
The modern BeagleBone kernels are Maintained by Koen Kooi and are available on the 3.8 branch at https://github.com/beagleboard/kernel/tree/3.8 . This repo contains a set of patches and a script which downloads a mainline kernel and then patches it appropriately. Exact steps for building it are in the README.<br />
<br />
=== Step-by-step guide to building a BBB kernel ===<br />
There is a step-by-step guide to building a BeagleBone Black (BBB) kernel at http://elinux.org/Building_BBB_Kernel<br />
<br />
=== Device Tree ===<br />
The 3.5 and newer BeagleBone kernels make use of [[Device Tree]]. A Device Tree is a text file which describes the layout of a machine, commonly the combination of a system-on-chip (SoC) and a board, so that the kernel can know at what addresses and on which buses hardware is located. The BeagleBone kernels make use of an extension called [[Capemgr|Capemgr]] which allows dynamic loading and unloading of device tree fragments both at compile time and from userspace post-boot.<br />
Learning about the Device Tree is very essential, if you wish to be able to manipulate pins and be able to use them as inputs/outputs. There is a [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 short guide to it here] (part-way down the page). In a nutshell, the device tree can be manipulated by creating a text 'fragment' file that can be converted into a .dtbo file using a program called dtc which is already installed on the BeagleBone Black. The .dtbo file can then be installed and uninstalled as desired. The procedures to install and uninstall are at that link:<br />
<br />
<tt>echo cape-bone-name > $SLOTS</tt> to install, and<br />
<br />
<br />
<tt>echo -<slotnum> > $SLOTS</tt> to uninstall,<br />
but read through the web page and comments section first to see what $SLOT is set to).<br />
<br />
= FAQ =<br />
<br />
For BeagleBoard frequently asked questions (FAQ) see [[BeagleBoardFAQ|community FAQ]] and "official" [http://beagleboard.org/support/faq BeagleBoard.org FAQ].<br />
<br />
= Projects =<br />
<br />
* [[BeagleBone 6502 RemoteProc cape]]<br />
<br />
= Links =<br />
== Home site and Community ==<br />
* [http://beagleboard.org/ beagleboard.org] -- home for BeagleBoard and BeagleBone products<br />
* [http://beagleboard.org/Products/BeagleBone%20Black BeagleBone Black] -- manufacturer's page for the second BeagleBone board<br />
* irc://irc.freenode.net/#beagle -- official combined IRC channel<br />
* [http://beagleboard.org/discuss Google Groups forums/mailing list] -- [https://groups.google.com/forum/?fromgroups#!forum/beagleboard English], [http://groups.google.com/group/pandabeagle-jp Japan], [http://groups.google.com/group/beagleboard-brasil Brasil], [https://groups.google.com/group/beagle-board-turkiye Turkey]<br />
* [http://beagleboard.org/project BeagleBoard and BeagleBone projects list]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0AtD7XdBlve3HdDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc&hl=en_US#gid=0 Capes Registry] and its [https://docs.google.com/spreadsheet/viewform?formkey=dDZqUk0xQ1dpV2NiNm43d0pNWmVGdmc6MQ registration page]<br />
* [http://www.adafruit.com/blog/category/beaglebone/ BeagleBone articles at Adafruit blog] -- products, projects and tutorials<br />
* Use [http://www.google.de/ Google] to search beagleboard.org (including [http://www.beagleboard.org/irclogs/ IRC logs]) using ''site:beagleboard.org <search term>''<br />
* [https://www.linux.com/news/embedded-mobile/mobile-linux/715298-45-beaglebone-black-keeps-eyes-on-raspberry-pi Linux.com report on BeagleBone Black] -- with words from beagleBoard.org's cofounder Jason Kridner<br />
* [https://github.com/selsinork/beaglebone-black-pinmux github.com/selsinork/beaglebone-black-pinmux] -- pinmux data for BeagleBone Black, including extraction scripts<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 Element 14 knode blog: Working with the PRU-ICSS] -- detailed tutorial on starting with the PRU on BBB<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/06/01/bbb-neon-and-making-tintin-bigger BBB, NEON and making Tintin bigger] - introduction to using NEON on the BBB<br />
* [http://forum.beaglefu.com/ BeagleFu] -- BeagleBone/Board Community, News and Projects.<br />
<br />
== Tutorials and Videos ==<br />
* [http://beagleboard.org/static/bonescript/bone101/index.html ''BeagleBone: BeagleBoard-101 Intro''] -- slides (turn off Javascript for single page)<br />
* [http://www.youtube.com/watch?v=EEnOWR-GXjk ''BeagleBone Intro''], video by Jason Kridner, Texas Instruments<br />
* [http://www.youtube.com/watch?v=Y0uqRVxismQ ''How-To: Get Started with the BeagleBone''], video by Matt Richardson, MakeMagazine<br />
* [http://www.youtube.com/watch?v=z6b4zlh0IrE ''The Beaglebone - Unboxing, Introduction Tutorial and First Example''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=vFv_-ykLppo ''Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse''], video by Derek Molloy, DCU/EE<br />
* [http://www.youtube.com/watch?v=SaIpz00lE84 ''Beaglebone: GPIO Programming on ARM Embedded Linux''], video by Derek Molloy, DCU/EE<br />
* [https://gist.github.com/4013192 ''C code for GPIO polling''], sample code by Andrew Montag<br />
* [http://borderhack.com/?p=1062 First steps with the Beaglebone], introductory HOWTO by octavio at borderhack<br />
* [http://learn.adafruit.com/beaglebone Adafruit Learning System - BeagleBone] -- web page<br />
<br />
== Manuals and resources ==<br />
* [http://beagleboard.org/static/beaglebone/a3/Docs/Hardware/BONE_SRM.pdf BeagleBone System Reference Manual (rev. A3_1.0)]<br />
* [http://www.ti.com/am335x Texas Instruments - Sitara AM335x ARM Cortex-A8 Microprocessor overview]<br />
* [http://www.ti.com/product/am3359 Texas Instruments - AM3359 Sitara ARM Cortex-A8 Microprocessor full documentation]<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.subset.architecture.reference/index.html#v7AR ARM/ARMv7-AR Architecture] -- ARM Cortex-A8 architecture overview<br />
* [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344d/DDI0344D_cortex_a8_r2p1_trm.pdf ARM Cortex-A8 Technical Reference Manual r2p1]<br />
* [http://www.arm.com/support/university/development-platforms/cortex-a8-development-platforms.php ARM Cortex-A Development Platforms] -- ARM page on Beagle boards<br />
* [http://www.ti.com/product/tps65217b TI TPS65217 Power Management IC], [http://www.ti.com/lit/ds/symlink/tps65217.pdf TPS65217 PMIC datasheet]<br />
* [http://www.ftdichip.com/Products/ICs/FT2232H.htm FTDI FT2232H Hi-Speed Dual USB UART/FIFO IC overview], [http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT2232H.pdf FT2232H datasheet]<br />
* [http://www.linux-usb.org/gadget/index.html Linux-USB Gadget API Framework] and [http://www.linux-usb.org/gadget/h2-otg.html USB OTG], and [http://forums.gentoo.org/viewtopic-t-843255.html kernel config] -- Ethernet-over-USB<br />
* [https://docs.google.com/document/d/17P54kZkZO_-JtTjrFuVz-Cp_RMMg7GB_8W9JK9sLKfA/pub Beaglebone and the 3.8 Kernel] Details about the 3.8 Kernel, its use of DT and the capemanager.<br />
* [https://github.com/lgxlogic/BeagleBoneBlack-3D-Model SolidWorks 3D model of the BeagleBone Black] on GitHub, includes 3D PDF.<br />
<br />
== Translations ==<br />
* 한국어:[[KR:BeagleBone]]<br />
<br />
== Errata ==<br />
<br />
= Subpages =<br />
http://elinux.org/BeagleBone_Usb_Networking<br />
http://elinux.org/BeagleBone_and_the_3.8_Kernel</div>Keesjhttps://elinux.org/index.php?title=A13_OLinuXino-MICRO&diff=252164A13 OLinuXino-MICRO2013-05-14T20:13:23Z<p>Keesj: Added some info about the expected file system layout</p>
<hr />
<div><br />
<br />
== JTAG support ==<br />
<br />
The A13 OLinuXino-MICRO has JTAG support brought out to an unpopulated 6-pin header next to the headphone jack. Solder a piece of header strip and it's ready to go.<br />
<br />
=== Cabling ===<br />
<br />
The table below shows the pinout for the proprietary JTAG header on the board. All pins are clearly silkscreened on the bottom of the board.<br />
<br />
{| class="wikitable"<br />
|-<br />
! A13 OLinuXino JTAG !! Pin !! JTAG Signal !! ARM 20-pin JTAG !! ARM 14-pin<br />
|-<br />
| GND || 1 || GND || 10 || 10<br />
|-<br />
| TDO || 2 || TDO || 13 || 11<br />
|-<br />
| TCK || 3 || TCK || 9 || 9<br />
|-<br />
| TMS || 4 || TMS || 7 || 7<br />
|-<br />
| TDI || 5 || TDI || 5 || 5<br />
|-<br />
| 3.3V || 6 || 3.3V || 1 || 1<br />
|}<br />
<br />
=== BDI-2000/3000 ===<br />
<br />
The [https://github.com/ohporter/bdi_configs/blob/master/a13-olinuxino-micro.cfg A13 OLinuXino-MICRO BDI config file] can be used with a BDI configured with the ARM11/Cortex-An firmware and the standard BDI ARM/Xscale 20-pin JTAG cable.<br />
<br />
[[File:Bdia13jtag.jpg|600px|BDI2000 to A13 OLinuXino JTAG cabling]]<br />
<br />
=== Flyswatter 2 / OpenOCD ===<br />
<br />
The [https://github.com/ohporter/openocd_configs/blob/master/a13-olinuxino.cfg A13 OLinuXino OpenOCD config file] can be used with a [[Flyswatter]], [[OpenOCD]], and the ARM 20-pin JTAG on the Flyswatter 2.<br />
<br />
Usage:<br />
<br />
openocd -f interface/flyswatter2.cfg -f /tmp/a13-olinuxino.cfg<br />
<br />
[[File:Fs2a13jtag.jpg|600px|Flyswatter 2 to A13 OLinuXino JTAG cabling]]<br />
<br />
== Boot Layout ==<br />
<br />
The device doesn't have internal storage and boots from the SD-card. The second and third stage loader (SPL and U-Boot) are loaded from the start of the MMC (not on a file system). The default configuration is to create two partitions the first is a FAT formatted one where u-boot will load files from and the second one probably a ext2 partition. But given the bootloaders are not on the FAT you need to reserve some space at the start (I leave 2048 512 byte blokcs at the start as this is the default fdisk offers).<br />
<br />
The layout looks something like this:<br />
{| class="wikitable"<br />
|-<br />
! NAME !! start block !! size<br />
|-<br />
| MBR || 0 || 1 block<br />
|-<br />
| sunxi-spl.bin || 16 || 20K<br />
|-<br />
| u-boot.bin || 64 || 170K<br />
|-<br />
| FAT || 2048 || 20M<br />
|-<br />
| EXT2 || --- || Rest<br />
|}<br />
<br />
<br />
[[Category:Flyswatter]]<br />
[[Category:HOWTOs]]</div>Keesjhttps://elinux.org/index.php?title=Android_Zygote_Startup&diff=32587Android Zygote Startup2011-01-23T20:20:51Z<p>Keesj: </p>
<hr />
<div>Here are some miscellaneous notes on Android startup of the zygote process.<br />
<br />
This information is true for eclair, as of August 2010.<br />
== Sequence of Zygote startup steps ==<br />
<br />
* init runs the C++ program /system/bin/app_process, and gives the resulting process the name "zygote"<br />
** This is based on the line from init.rc:<br />
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server<br />
* app_process executes, and executes a runtime environment for a dalvik class<br />
** app_process usage claims to be:<br />
Usage: app_process [java-options] cmd-dir start-class-name [options]<br />
** but you can specify --zygote in place of the start-class-name.<br />
** In the bootup case, --zygote is used<br />
** source for 'app_process is in frameworks/base/cmds/app_process/app_main.cpp<br />
** this is the program to debug when debugging zygote/dalvik itself<br />
* app_process does a 'runtime.start("com.android.internal.os.ZygoteInit", startSystemServer)<br />
** the startSystemServer flag is passed as a parameter on to app_process, to indicate whether to start the system server (duh)<br />
* runtime is an instance of class AppRuntime, which is sub-classed from AndroidRuntime<br />
* AndroidRuntime is the main class for starting the dalvik runtime environment<br />
** source is in frameworks/base/core/jni/AndroidRuntime.cpp<br />
** the start() method starts the virtual machine<br />
*** LOG_BOOT_PROGRESS_START is emitted, with systemTime(SYSTEM_TIME_MONOTONIC)<br />
*** startVM() is called<br />
*** eventually, callStaticVoidMethod() is called, to actually start executing the start class with method "main" in Dalvik code<br />
* com.android.internal.os.ZygoteInit:main() starts executing<br />
** source is at: frameworks/base/core/java/com/android/internal/os/ZygoteInit.java<br />
* the profiler is started<br />
* the Zygote socket is registered (for later communication to start apps)<br />
* classes and resources are preloaded<br />
* if startSystemServer is set, then the system server is started<br />
** the command line to the system server is:<br />
--setuid=1000 --setgid=1000 \<br />
--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,3001,3002,3003 \<br />
--capabilities=130104352,130104352 \<br />
--runtime-init \<br />
--nice-name=system_server \<br />
com.android.server.SystemServer<br />
** the class which starts executing is: com.android.server.SystemServer<br />
** a call is made to Zygote.forkSystemServer() to actually start this other process<br />
* zygote runs in "select loop mode", where a single process spins waiting for communication to start subsequent apps<br />
** see runSelectLoopMode()<br />
*** new connections are accepted (and put into array "peers")<br />
*** the spawn command received over the network is executed by calling the runOnce() method<br />
*** source code for this is at: frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java<br />
* eventually, a call is made to Zygote.forkAndSpecialize(), which does the actual forking<br />
<br />
== Sequence of system_server (or SystemServer) startup steps ==<br />
Source for the SystemServer is in:frameworks/base/services/java/com/android/server/SystemServer.java<br />
<br />
in the "ServerThread::run()" method, the following startup occurs:<br />
* LOG_BOOT_PROGRESS_SYSTEM_RUN is emitted<br />
* Lots of critical services are started:<br />
** Entropy Service<br />
** Power Manager<br />
** Activity Manager<br />
** Telephony Registry<br />
** Package Manager<br />
** Account Manager<br />
** Content Manager<br />
** System Content Providers<br />
** Battery Service<br />
** Hardware Service<br />
** Alarm Manager<br />
** Init Watchdog<br />
** Sensor Service<br />
** Window Manager<br />
* Additional services may be started as well:<br />
** Status Bar<br />
** Clipboard Service<br />
** Input Method Service<br />
** NetStat Service<br />
** Connectivity Service<br />
** Accessibility Manager<br />
** Notification Manager<br />
** Mount Service<br />
** Device Storage Monitor<br />
** Location Manager<br />
** Search Service<br />
** Checkin Service<br />
** Wallpaper Service<br />
** Audio Service<br />
** Headset Observer<br />
** Dock Observer<br />
** Backup Service<br />
** AppWidget Service</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=11875BeagleBoardAndOpenEmbeddedGit2009-05-25T08:15:16Z<p>Keesj: /* OpenEmbedded and Bitbake install */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs from the official guide in that we focus on the [[BeagleBoard]] as target and Ubuntu as host platform.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2 quilt<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings). <br />
<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
If your host system is amd64 based the vm.vdso_enabled flag is not supported (at least at runtime) you therefore will need to add a boot parameter called vdso32=0<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all. It will checkout the OpenEmbedded<br />
meta-data repository including the BitBake task executor.<br />
<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
Create a new git branch tracking the stable branch<br />
cd openembedded<br />
git checkout origin/stable/2009 -b stable/2009<br />
<br />
From now on "git pull" can be used to update your repository.<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/recipes/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/openembedded/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/openembedded/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes from the stable/2009 git tree. <br />
<br />
cd $OE_HOME/openembedded<br />
git checkout origin/stable/2009 -b stable/2009<br />
git pull<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours. Once this works try using the x11-image target (bitbake x11-image) this will give you a more complete distribution<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=11874BeagleBoardAndOpenEmbeddedGit2009-05-25T08:12:57Z<p>Keesj: Bitbake is now part of the OE repository, updated the docs</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
[[Category:Development Boards]]<br />
[[Category: BeagleBoard]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs from the official guide in that we focus on the [[BeagleBoard]] as target and Ubuntu as host platform.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2 quilt<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings). <br />
<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
If your host system is amd64 based the vm.vdso_enabled flag is not supported (at least at runtime) you therefore will need to add a boot parameter called vdso32=0<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/recipes/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/openembedded/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/openembedded/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes from the stable/2009 git tree. <br />
<br />
cd $OE_HOME/openembedded<br />
git checkout origin/stable/2009 -b stable/2009<br />
git pull<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours. Once this works try using the x11-image target (bitbake x11-image) this will give you a more complete distribution<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=11457BeagleBoardAndOpenEmbeddedGit2009-05-03T19:37:43Z<p>Keesj: /* Prerequisites */ Added note about vdso on amd64</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs from the official guide in that we focus on the [[BeagleBoard]] as target and Ubuntu as host platform.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2 quilt<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings). <br />
<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
If your host system is amd64 based the vm.vdso_enabled flag is not supported (at least at runtime) you therefore will need to add a boot parameter called vdso32=0<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/recipes/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes from the stable/2009 git tree. <br />
<br />
cd $OE_HOME/openembedded<br />
git checkout origin/stable/2009 -b stable/2009<br />
git pull<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours. Once this works try using the x11-image target (bitbake x11-image) this will give you a more complete distribution<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=10328BeagleBoardAndOpenEmbeddedGit2009-03-19T20:48:07Z<p>Keesj: updated the introduction a little</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs from the official guide in that we focus on the [[BeagleBoard]] as target and Ubuntu as host platform.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings).<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/recipes/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/recipes/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes in the git tree.<br />
<br />
cd $OE_HOME/openembedded<br />
git pull<br />
git checkout<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours. Once this works try using the x11-image target (bitbake x11-image) this will give you a more complete distribution<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=10305BeagleBoardAndOpenEmbeddedGit2009-03-16T19:27:03Z<p>Keesj: /* Running */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs in that the official GettingStarted uses monotone while we will be using git. The second difference is that this guide only focuses on running on Ubuntu and developing for beagle.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings).<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/packages/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes in the git tree.<br />
<br />
cd $OE_HOME/openembedded<br />
git pull<br />
git checkout<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours. Once this works try using the x11-image target (bitbake x11-image) this will give you a more complete distribution<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=10286BeagleBoardAndOpenEmbeddedGit2009-03-14T20:55:03Z<p>Keesj: /* Creating the BeagleBoard configuration and profile */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs in that the official GettingStarted uses monotone while we will be using git. The second difference is that this guide only focuses on running on Ubuntu and developing for beagle.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
Disk Space<br />
<br />
Although OpenEmbedded images for the devices are usually quite small, the development system needs significant space. Take this into account, especially when using OE within a virtual machine.<br />
<br />
* Minimum requirement: 12 GB (e.g. omap3-console-image for Gumstix Overo and BeagleBoard)<br />
* Standard requirement: 30 GB (e.g. omap3-desktop-image)<br />
* Maximum requirement: 35 GB (for full OE build, bitbake world)<br />
<br />
So the minimum free disk space is about 15 GB (no desktop images), standard would be 35 GB and a safe size is 45 GB.<br />
<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get update<br />
<br />
sudo apt-get upgrade<br />
<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev \<br />
docbook-utils gawk help2man diffstat gtk-doc-tools file g++ python-psyco minicom build-essential \<br />
libncurses5-dev python-dev python-pysqlite2<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
Ubuntu 8.04 (and ealier)<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
Ubuntu 8.10 (and later)<br />
Add settings to config directory (Prefix 60-* ensures that it overrides all other settings).<br />
sudo -s<br />
echo -e "vm.vdso_enabled = 0\nvm.mmap_min_addr = 0" > /etc/sysctl.d/60-oe-settings.conf<br />
exit<br />
<br />
And then run<br />
sudo invoke-rc.d procps start<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "openembedded" directory. The BeagleBoard configuration will be placed under "beagleboard" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
#or if you are behind a firewall<br />
git clone http://repo.or.cz/r/openembedded.git<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will both point to our own beagleboard files and openembedded.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Select angstrom-2008.1 as distro. <br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/packages/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
If you have a multicore machine, you can also add these two variables to speed up things (a value of 2 is safe in most cases), see [http://dev.openbossa.org/trac/mamona/wiki/SpeedUp here]:<br />
<br />
BB_NUMBER_THREADS = "2" # Depends on your machine<br />
PARALLEL_MAKE = "-j 2" # Depends on your cluster<br />
<br />
Now we create our profile. There are TWO CHOICES here.<br />
<br />
'''NOTE''': In the recented version BitBake, it will remove all of the environment variables, unless they are trustly declared in BitBake whitelist(BB_ENV_EXTRAWHITE), therefore, you should list the env vars you need in the BitBake whitelist and export it. This is already done when creating the profile bellow using the BB_ENV_EXTRAWHITE environment variable.<br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export BB_ENV_EXTRAWHITE="MACHINE DISTRO ANGSTROM_MODE ANGSTROMLIBC OE_HOME"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source $OE_HOME/beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes in the git tree.<br />
<br />
cd $OE_HOME/openembedded<br />
git pull<br />
git checkout<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours.<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
===Setting the video resolution:===<br />
<br />
The Angstrom kernels since 2.6.27 have used "DSS2", which is a candidate for replacing the OMAP framebuffer driver in the mainline Linux kernel. It provides greater flexibility for support of the S-Video port on the BeagleBoard and more monitor resolutions than previous mainline kernels. Documentation for the driver is in the kernel source at [Documentation/arm/OMAP/DSS http://groups.google.com/group/beagleboard/msg/4c64b2c614622053].<br />
<br />
Below is one example:<br />
<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omap-dss.def_disp=lcd omapfb.video_mode=640x480MR-16@60<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].<br />
<br />
See also Open Embedded User's Manual (these links point to nightly builds of the documentation and so should always be up to date):<br />
* [http://docs.openembedded.org/usermanual/html/ HTML Format]<br />
* [http://docs.openembedded.org/usermanual/usermanual.pdf PDF Format]<br />
and bitbake User's Manual:<br />
* [http://bitbake.berlios.de/manual/ HTML Format]<br />
<br />
==OpenEmbedded development==<br />
<br />
See [[BeagleBoardOpenEmbeddedDevelopment|OpenEmbedded development guide]] for one way how to modify and build packages contained within OpenEmbedded (OE) for the BeagleBoard.</div>Keesjhttps://elinux.org/index.php?title=GDB&diff=10073GDB2009-03-08T15:00:35Z<p>Keesj: /* Startup */</p>
<hr />
<div>The GNU Debugger GDB is the most common debug tool for Linux. It features most used features one can think of, including server-client debug architecture (so you run the heavy debug part on your host/pc machine), but lack some bits as checkpoint-restart during execution.<br />
<br />
== Documentation ==<br />
<br />
GDB ships with extensive documentation at http://www.gnu.org/software/gdb/documentation/, but there are some good [http://refcards.com/docs/peschr/gdb/gdb-refcard-a4.pdf quick reference cards] as well.<br />
<br />
== Basic Usage ==<br />
<br />
Documentation is so large that sometimes its hard to get started, so most simple tasks can be done with the following commands, but please read GDB docs as soon as possible!<br />
<br />
=== Startup ===<br />
<br />
To start a new application for debug, use:<br />
<br />
$ gdb ./binary<br />
$ gdb ./binary core.dump<br />
$ gdb --args ./binary arg1 arg2<br />
$ gdb --command=my-gdb-commands.txt --args ./binary arg1 arg2<br />
<br />
and then run it with (args just required if no --args were used):<br />
<br />
(gdb) run arg1 arg2<br />
<br />
if you need to execute a series of commands every time, consider writing them on a file and use <code>--command=file</code> (or <code>-x file</code>).<br />
<br />
It's usually a pain to run the full gdb on your device, so use gdbserver on the target and gdb on host:<br />
<br />
target/device$ gdbserver :2345 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 --attach PID<br />
<br />
host/pc$ gdb<br />
(gdb) target remote /dev/ttyS1<br />
(gdb) target remote 192.168.0.123:2345<br />
<br />
If you are using the serial method you need to make sure you have setup the serial speed correctly,<br />
On the host:<br />
(gdb) set remotebaud 115200<br />
<br />
On the target(before you issue the gdbserver command):<br />
stty speed 115200 < /dev/ttyS1<br />
<br />
If application is already running, find out its pid (ps, top, pidof, ...) and:<br />
<br />
$ gdb --pid $PID<br />
<br />
=== Breakpoints ===<br />
<br />
If you control-C (^C), it will break at that point, but you can also schedule a breakpoint with:<br />
<br />
(gdb) break function<br />
(gdb) break line<br />
(gdb) break file:function<br />
(gdb) break file:line<br />
<br />
conditional breaks are in the form:<br />
<br />
(gdb) break where if condition<br />
<br />
where <code>condition</code> is some C expression that evaluates to 1 or 0, like <code>*ptr == NULL</code><br />
<br />
One can disable or remove breakpoints with:<br />
(gdb) enable breakpoint-number<br />
(gdb) disable breakpoint-number<br />
(gdb) delete breakpoint-number<br />
(gdb) clear # removes all breakpoints<br />
<br />
=== Examining ===<br />
<br />
To list source code nearby position or specific places:<br />
(gdb) list<br />
(gdb) list line<br />
(gdb) list function<br />
(gdb) list file:line<br />
(gdb) list file:function<br />
(gdb) list *address<br />
<br />
To list execution backtrace (or <code>bt</code> for short):<br />
(gdb) backtrace<br />
<br />
To change frame to operate on:<br />
(gdb) frame frame-number<br />
<br />
To change thread to operate on:<br />
(gdb) thread thread-number<br />
<br />
To print some value or expression:<br />
(gdb) print $register<br />
(gdb) print variable<br />
(gdb) print *address<br />
(gdb) print *(int *)address<br />
(gdb) print *(char **)address<br />
(gdb) print myfunc(p1, p2) # will actually execute it and return result!<br />
(gdb) print *a = 123 # will actually change *a value and return 123!<br />
(gdb) print file::variable<br />
(gdb) print function::variable<br />
<br />
To disassembly:<br />
(gdb) disassembly<br />
(gdb) disassembly file:line<br />
<br />
Print function arguments:<br />
(gdb) info args<br />
<br />
Print locals:<br />
(gdb) info locals<br />
<br />
Print breakpoints:<br />
(gdb) info breakpoints<br />
<br />
Print threads:<br />
(gdb) info threads<br />
<br />
=== Stepping ===<br />
<br />
To go to next instruction, possible entering a function (or <code>s</code> for short):<br />
(gdb) step<br />
<br />
To go to next instruction, but avoid entering new functions (or <code>n</code> for short):<br />
(gdb) next<br />
<br />
To continue until the function returns:<br />
(gdb) finish<br />
<br />
To continue execution (or <code>c</code> for short):<br />
(gdb) continue<br />
<br />
=== Manipulating Program ===<br />
<br />
To set variable to some value:<br />
(gdb) set var name=value<br />
<br />
To force function to return:<br />
(gdb) return value<br />
(gdb) return expression<br />
<br />
=== Changing Signal Handlers ===<br />
<br />
(gdb) handle signal action<br />
<br />
debugging applications with old libC, those pre-nptl, can be really annoying due SIG32 and SIG33, one can ignore those with:<br />
(gdb) handle SIG32 nostop<br />
(gdb) handle SIG32 noprint<br />
(gdb) handle SIG33 nostop<br />
(gdb) handle SIG33 noprint<br />
<br />
=== Shared Object Paths ===<br />
<br />
Often your cross compile root is not <code>/</code>, so you might have to add new paths to the search list.<br />
<br />
Unset absolute prefix:<br />
(gdb) set solib-absolute-prefix null<br />
<br />
Add paths to search paths:<br />
(gdb) set solib-search-path /path1:/path2<br />
<br />
Alternatively you can choose to set the prefix to the root of your target file system. Specially if you are doing<br />
embedded development and already exporting your root file system from you host machine to your target machine it can <br />
be very rewarding so simply use that as root:<br />
(gdb) set solib-absolute-prefix /rootfs<br />
<br />
[[Category:Tools]]</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardJTAG&diff=9246BeagleBoardJTAG2009-02-10T20:50:47Z<p>Keesj: /* TinCanTools Flyswatter */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
The page is about [http://en.wikipedia.org/wiki/JTAG JTAG] on OMAP3530 used at [[BeagleBoard|BeagleBoard]].<br />
<br />
=Beagle JTAG connection=<br />
The [[BeagleBoard]] comes with a 14 pin [[JTAG-TI|TI JTAG]] connector. For JTAG pin out see section 8.16 of [http://www.beagleboard.org/uploads/Beagle_HW_Reference_Manual_B_5.pdf BeagleBoard HW Reference Manual (rev. B5)]. This is the same header interface as used in other TI products and is ''NOT'' the standard 14 pin ARM layout. Depending on your JTAG tool, you'd need a [[JTAG-TI|20-pin to 14-pin TI adapter]].<br />
<br />
Note: JTAG on BeagleBoard uses 1.8V!<br />
<br />
The 14-pin TI JTAG connector that is used on BeagleBoard is supported by a large number of JTAG emulation products and has been tested using Lauterbach, Spectrum Digital XDS510USB+ and TI XDS560 emulation pods. Note that it will not work with the Spectrum Digital XDS510USB (non-plus) as it does not support a target with 1.8V JTAG.<br />
<br />
The following picture is from a [http://focus.ti.com/lit/ml/sprp603/sprp603.pdf TI OMAP JTAG presentation]:<br />
<br />
[[Image:Ti arm jtag.jpg]]<br />
<br />
Beagle uses the 14-pin TI header.<br />
<br />
Note: TI uses some different pin names. Translation:<br />
* TVD => VREF at Beagle<br />
* TCLKR == RTCK<br />
* TCLKO == TCK<br />
* #### == Key (empty))<br />
* TDI => GND at Beagle<br />
<br />
== Beagle adapter ==<br />
The [[BeagleBoardJTAG#TinCanTools_Flyswatter|Flyswatter]] we plan to use has a 14 pin ARM layout, so we need to create a converter. From [http://www.tincantools.com/assets/JTAG_pin_assignments.pdf JTAG pin assignments] document:<br />
<br />
''' ARM-14-JTAG TI-14-JTAG'''<br />
<br />
VREF 1 - - 2 GND JTAG_TMS 1 - - 2 JTAG_nTRST<br />
JTAG_nTRST 3 - - 4 GND JTAG_TDI 3 - - 4 GND<br />
JTAG_TDI 5 - - 6 GND VREF 5 - x 6 KEY (empty)<br />
JTAG_TMS 7 - - 8 GND JTAG_TDO 7 - - 8 GND<br />
JTAG_TCK 9 - - 10 GND JTAG_RTCK 9 - - 10 GND<br />
JTAG_TDO 11 - - 12 JTAG_SRST_N JTAG_TCK 11 - - 12 GND<br />
VREF 13 - - 14 GND JTAG_EMU0 13 - - 14 JTAG_EMU1<br />
FlySwatter TOP Beagle<br />
<br />
See [[media:flyswatter-ti-jtag.pdf|14 pin ARM to TI adapter]] for a verified JTAG adapter from [http://www.tincantools.com/ TinCanTools].<br />
<br />
* [http://tincantools.com/product.php?productid=16144 TinCanTools BeagleBoard Adapter Kit]<br />
* Nishanth Menon's [http://www.flickr.com/photos/nishanthmenon/2814595201/in/pool-beagleboard adapter] with explanation and [http://nishanthmenon.blogspot.com/2008/08/low-cost-jtag-for-beagle.html Nishanth's blog]<br />
* Lauterbach [http://www.lauterbach.com/frames.html?ord__7748.html JTAG converter to TI Target Adapter 14] (LA-7748) ([[media:Jtag-ti-front.jpg|front]] & [[media:Jtag-ti-back.jpg|back]])<br />
* [http://www.flickr.com/photos/51025379@N00/2822556950/in/photostream/ xdaiabx adapter]<br />
<br />
= Open source JTAG software= <br />
It would be very interesting to get the JTAG working with open source tools. The main open source JTAG software is [http://openocd.berlios.de/web/ OpenOCD]. See [[BeagleBoardOpenOCD|Beagle board OpenOCD page]] about status and usage of OpenOCD for Beagle.<br />
<br />
=JTAG hardware=<br />
<br />
For BeagleBoard JTAG debugging, there are some HW interfaces available. Several can be found on the [http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=1526&toolTypeId=12&go=Go TI tools directory].<br />
<br />
==TinCanTools Flyswatter==<br />
<br />
[http://www.tincantools.com/ TinCanTools] is currently working at [http://www.tincantools.com/product.php?productid=16134&cat=0&page=1&featured Flyswatter] support for OpenOCD for OMAP3530. They also have a [http://tincantools.com/product.php?productid=16144 BeagleBoard Adapter Kit].<br />
<br />
Costs:<br />
<br />
In case you like to order Flyswatter and Adapter Kit international, here an example for Europe (Germany):<br />
<br />
* Flyswatter: US-$ 49.95<br />
* BeagleBoard Adapter Kit: US-$ 18.00<br />
* International shipping: US-$ 27.00 (select USPS, it's the cheapest!)<br />
<br />
Sum: US-$ 94.95 => EUR 65.28 + EUR 8.76 VAT (Germany) = EUR 74.04<br />
<br />
Flyswatter will use [[BeagleBoardJTAG#Open_source_JTAG_software|OpenOCD]] (Beagle (OMAP3xx) support under development).<br />
<br />
An other possibility researched is to use [http://www.urjtag.org UrJTag]. While it has no arm debugging support is allows easy programming of JTAG. <br />
The svn version (r >1428=) of [http://www.urjtag.org UrJtag] has working support for the FlySwatter. <br />
<br />
The basic ICEPick opening sequence has been tried using [http://www.urjtag.org UrJtag] and is described [http://sourceforge.net/mailarchive/message.php?msg_name=e5e16330902091450t2138127dj40bd7e69388f72c0%40mail.gmail.com Here]. What we learned from that is that we need even more control over how the commands must be executed.<br />
<br />
'''Attention''': If you use [http://tincantools.com/product.php?productid=16144 BeagleBoard Adapter Kit], make sure you plug the JTAG adapter the correct way. There are several possible ways, though. See [http://www.tincantools.com/images/D/Fly%2BBeagle-800x391.JPG?1229714946602 connection picture] how to do it the right way (in contrast to the picture EMU0 & EMU1 jumpers at JTAG adapter should be both at 1-2 position (touching J2)).<br />
<br />
==BDI 2000==<br />
<br />
===Example===<br />
<br />
[http://groups.google.com/group/beagleboard/msg/8463086de562ee00 Chuck Fleming] reports:<br />
<br />
The BDI2000 appears to work with the omap35xx.cfg and regOMAP3500.def files that come with the BDI hardware. I had to modify the 10-pin cable so that the BeagleBoard JTAG header matched the BDI target A connector:<br />
<br />
beagle>reset<br />
- TARGET: processing reset request<br />
- TARGET: BDI executes scan chain init string<br />
- TARGET: Bypass check 0x00000001 => 0x00000002<br />
- TARGET: JTAG exists check passed<br />
- Core#0: ID code is 0x0B6D602F<br />
- Core#0: DP-CSW is 0xF0000000<br />
- Core#0: DBG-AP at 0xD4011000<br />
- Core#0: DIDR is 0x15141012<br />
- TARGET: BDI removes RESET<br />
- TARGET: BDI waits for RESET inactive<br />
- TARGET: Reset sequence passed<br />
- TARGET: resetting target passed<br />
- TARGET: processing target startup ....<br />
- TARGET: processing target startup passed<br />
beagle>halt<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Debug Request<br />
Current PC : 0x40200000<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle>rdall<br />
User FIQ Superv Abort IRQ Undef<br />
GPR00: 480029fc 480029fc 480029fc 480029fc 480029fc 480029fc<br />
GPR01: 00000000 00000000 00000000 00000000 00000000 00000000<br />
GPR02: 00000001 00000001 00000001 00000001 00000001 00000001<br />
GPR03: 00000060 00000060 00000060 00000060 00000060 00000060<br />
GPR04: 00000000 00000000 00000000 00000000 00000000 00000000<br />
GPR05: 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4<br />
GPR06: 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4<br />
GPR07: 80e9ee88 80e9ee88 80e9ee88 80e9ee88 80e9ee88 80e9ee88<br />
GPR08: 80e3ffdc 34484608 80e3ffdc 80e3ffdc 80e3ffdc 80e3ffdc<br />
GPR09: 80e3fec8 26a1c132 80e3fec8 80e3fec8 80e3fec8 80e3fec8<br />
GPR10: 00000018 08040f16 00000018 00000018 00000018 00000018<br />
GPR11: 80e3fecc 3c278260 80e3fecc 80e3fecc 80e3fecc 80e3fecc<br />
GPR12: 0000006e 24200625 0000006e 0000006e 0000006e 0000006e<br />
GPR13: 00000000 00000000 80e3feb0 00000000 00000000 d1868045<br />
GPR14: 00000000 00000000 80e84f44 00000000 00000000 d55a4cc8<br />
PC : 40200000<br />
CPSR : 000001d3<br />
SPSR : 00000000 00000000 00000000 00000000 00000000<br />
beagle>md 0x40200000<br />
40200000 : e320f000 e320f000 e320f000 e320f000 .. ... ... ... .<br />
40200010 : e320f000 e320f000 e320f000 eafffffc .. ... ... .....<br />
40200020 : b6273502 e7aa052b 047694c8 91ca77d8 .5'.+.....v..w..<br />
40200030 : 12b9579e ef2eef1b 00543892 494f9bc1 .W.......8T...OI<br />
40200040 : 3f63013d 82eee656 b7adfe8d 993f1368 =.c?V.......h.?.<br />
40200050 : 51f1cf9b 0464a23e bea76e3c 3d275f5c ...Q>.d.<n..\_'=<br />
40200060 : 76554290 6776c892 a6cd088f 6dd4529a .BUv..vg.....R.m<br />
40200070 : 067261b8 e5f80e9e cb4ea075 25a9dd95 .ar.....u.N....%<br />
40200080 : 779db8c6 0496597b 7d5f8d5a 24f44cd6 ...w{Y..Z._}.L.$<br />
40200090 : 99ab46f9 9ddc06d9 fd34567a 2035bab8 .F......zV4...5<br />
402000a0 : a16b6760 fe863cf7 29046202 39fb0d49 `gk..<...b.)I..9<br />
402000b0 : dc9fd18c e50f536c 09ae66dd cad9ff91 ....lS...f......<br />
402000c0 : c46bdbdb be791808 89ff83fa 2d3bc71e ..k...y.......;-<br />
402000d0 : 43f5a3b6 0aed1747 ba3c4752 6af0573a ...CG...RG<.:W.j<br />
402000e0 : 3570da77 9a1dc961 324b876c 5d592060 w.p5a...l.K2` Y]<br />
402000f0 : b870f487 1277c035 4609dcf4 53b534c4 ..p.5.w....F.4.S<br />
beagle>ti<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Single Step<br />
Current PC : 0x40200004<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle>ti<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Single Step<br />
Current PC : 0x40200008<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle><br />
<br />
===BDI config===<br />
<br />
The [ftp://78.31.64.234/bdigdb/config/arm/cortex-a8/ BDI config files] might help getting OpenOCD to work with BeagleBoard.<br />
<br />
This configuration assumes the "default" EMU 0 and 1 configuration (both not connected/high state). In this EM setup at first only one TAP is exported. A set of commands must be run on the first tap (embedded ICE) <br />
to enable access to the core:<br />
<br />
SCANINIT t1:w1000:t0:w1000: ;toggle TRST,<br />
SCANINIT ch10:w1000: ;clock TCK with TMS high and wait<br />
SCANINIT i6=07:d8=89:i6=02: ;connect and select router<br />
SCANINIT d32=81000080: ;IP control: KeepPowered<br />
SCANINIT d32=a3002048: ;TAP3: DebugConnect, ForcePower, ForceActive<br />
SCANINIT d32=81000081: ;IP control: KeepPowered, SysReset<br />
SCANINIT d32=a3002148: ;enable TAP3<br />
SCANINIT cl10:i10=ffff ;clock 10 times in RTI, scan bypass<br />
<br />
==Lauterbach==<br />
<br />
Lauterbach Debugger supports [http://www.lauterbach.com/news_288.html OMAP3503/15/25/30].<br />
<br />
==XDS510 and CCS==<br />
<br />
XDS510 and CCS (code composer studio) can be used to debug OMAP3503/15/25/30. [http://www.magniel.com/yuli/omap3_jtag.jpg Configuration screen shot]. For CCS setup see [http://focus.ti.com/lit/ml/sprp603/sprp603.pdf TI OMAP JTAG presentation], too (start page: 16).<br />
<br />
==PEEDI==<br />
<br />
[http://www.ronetix.at/peedi.html PEEDI] JTAG/BDM Emulator and Flash Programmer of [http://www.ronetix.at Ronetix] supports OMAP3. A configuration file for the Beagleboard can be found here: [http://download.ronetix.info/peedi/cfg_examples/cortex-a8/omap3530.cfg omap3530.cfg]<br />
<br />
PEEDI has a built-in support for GNU gbd based debuggers and a built-in Flash Programmer.<br />
The Flash Programmer is capable to program:<br />
* NOR Flash devices (over 900)<br />
* NAND and OneNAND Flash devices (small page, larger page, 8/16 bit), various methods of ECC calculation, bad block management.<br />
* DataFlash devices<br />
* SPI DataFlash devices<br />
* images located on a TFTP/FTP/HTTP server or a MMC/SD card (which allows standalone mode).<br />
<br />
The PEEDI package includes also an PEEDI to TI14 adapter and an TI20 to TI14 adapter.<br />
<br />
==ARM RealView ICE==<br />
<br />
The new release of software (3.3) for the [http://www.bluewatersys.com/blog/?p=71 ARM RealView ICE] supports Texas Instruments’ range of OMAP3 processors.<br />
<br />
=Linux kernel debugging=<br />
<br />
If you like to debug Linux kernel (with one of the above JTAG tools?) using GDB have a look to [[DebuggingTheLinuxKernelUsingGdb|debugging Linux kernel using GDB]] article.</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardJTAG&diff=9245BeagleBoardJTAG2009-02-10T20:50:11Z<p>Keesj: /* TinCanTools Flyswatter */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
The page is about [http://en.wikipedia.org/wiki/JTAG JTAG] on OMAP3530 used at [[BeagleBoard|BeagleBoard]].<br />
<br />
=Beagle JTAG connection=<br />
The [[BeagleBoard]] comes with a 14 pin [[JTAG-TI|TI JTAG]] connector. For JTAG pin out see section 8.16 of [http://www.beagleboard.org/uploads/Beagle_HW_Reference_Manual_B_5.pdf BeagleBoard HW Reference Manual (rev. B5)]. This is the same header interface as used in other TI products and is ''NOT'' the standard 14 pin ARM layout. Depending on your JTAG tool, you'd need a [[JTAG-TI|20-pin to 14-pin TI adapter]].<br />
<br />
Note: JTAG on BeagleBoard uses 1.8V!<br />
<br />
The 14-pin TI JTAG connector that is used on BeagleBoard is supported by a large number of JTAG emulation products and has been tested using Lauterbach, Spectrum Digital XDS510USB+ and TI XDS560 emulation pods. Note that it will not work with the Spectrum Digital XDS510USB (non-plus) as it does not support a target with 1.8V JTAG.<br />
<br />
The following picture is from a [http://focus.ti.com/lit/ml/sprp603/sprp603.pdf TI OMAP JTAG presentation]:<br />
<br />
[[Image:Ti arm jtag.jpg]]<br />
<br />
Beagle uses the 14-pin TI header.<br />
<br />
Note: TI uses some different pin names. Translation:<br />
* TVD => VREF at Beagle<br />
* TCLKR == RTCK<br />
* TCLKO == TCK<br />
* #### == Key (empty))<br />
* TDI => GND at Beagle<br />
<br />
== Beagle adapter ==<br />
The [[BeagleBoardJTAG#TinCanTools_Flyswatter|Flyswatter]] we plan to use has a 14 pin ARM layout, so we need to create a converter. From [http://www.tincantools.com/assets/JTAG_pin_assignments.pdf JTAG pin assignments] document:<br />
<br />
''' ARM-14-JTAG TI-14-JTAG'''<br />
<br />
VREF 1 - - 2 GND JTAG_TMS 1 - - 2 JTAG_nTRST<br />
JTAG_nTRST 3 - - 4 GND JTAG_TDI 3 - - 4 GND<br />
JTAG_TDI 5 - - 6 GND VREF 5 - x 6 KEY (empty)<br />
JTAG_TMS 7 - - 8 GND JTAG_TDO 7 - - 8 GND<br />
JTAG_TCK 9 - - 10 GND JTAG_RTCK 9 - - 10 GND<br />
JTAG_TDO 11 - - 12 JTAG_SRST_N JTAG_TCK 11 - - 12 GND<br />
VREF 13 - - 14 GND JTAG_EMU0 13 - - 14 JTAG_EMU1<br />
FlySwatter TOP Beagle<br />
<br />
See [[media:flyswatter-ti-jtag.pdf|14 pin ARM to TI adapter]] for a verified JTAG adapter from [http://www.tincantools.com/ TinCanTools].<br />
<br />
* [http://tincantools.com/product.php?productid=16144 TinCanTools BeagleBoard Adapter Kit]<br />
* Nishanth Menon's [http://www.flickr.com/photos/nishanthmenon/2814595201/in/pool-beagleboard adapter] with explanation and [http://nishanthmenon.blogspot.com/2008/08/low-cost-jtag-for-beagle.html Nishanth's blog]<br />
* Lauterbach [http://www.lauterbach.com/frames.html?ord__7748.html JTAG converter to TI Target Adapter 14] (LA-7748) ([[media:Jtag-ti-front.jpg|front]] & [[media:Jtag-ti-back.jpg|back]])<br />
* [http://www.flickr.com/photos/51025379@N00/2822556950/in/photostream/ xdaiabx adapter]<br />
<br />
= Open source JTAG software= <br />
It would be very interesting to get the JTAG working with open source tools. The main open source JTAG software is [http://openocd.berlios.de/web/ OpenOCD]. See [[BeagleBoardOpenOCD|Beagle board OpenOCD page]] about status and usage of OpenOCD for Beagle.<br />
<br />
=JTAG hardware=<br />
<br />
For BeagleBoard JTAG debugging, there are some HW interfaces available. Several can be found on the [http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=1526&toolTypeId=12&go=Go TI tools directory].<br />
<br />
==TinCanTools Flyswatter==<br />
<br />
[http://www.tincantools.com/ TinCanTools] is currently working at [http://www.tincantools.com/product.php?productid=16134&cat=0&page=1&featured Flyswatter] support for OpenOCD for OMAP3530. They also have a [http://tincantools.com/product.php?productid=16144 BeagleBoard Adapter Kit].<br />
<br />
Costs:<br />
<br />
In case you like to order Flyswatter and Adapter Kit international, here an example for Europe (Germany):<br />
<br />
* Flyswatter: US-$ 49.95<br />
* BeagleBoard Adapter Kit: US-$ 18.00<br />
* International shipping: US-$ 27.00 (select USPS, it's the cheapest!)<br />
<br />
Sum: US-$ 94.95 => EUR 65.28 + EUR 8.76 VAT (Germany) = EUR 74.04<br />
<br />
Flyswatter will use [[BeagleBoardJTAG#Open_source_JTAG_software|OpenOCD]] (Beagle (OMAP3xx) support under development).<br />
<br />
An other possibility researched is to use [http://www.urjtag.org UrJTag]. While it has no arm debugging support is allows easy programming of JTAG. <br />
The svn version (r >1428=) of [http://www.urjtag.org UrJtag] has working support for the FlySwatter. <br />
<br />
The basic ICEPick opening sequence has been tried using [http://www.urjtag.org UrJtag] and is described [https://sourceforge.net/mailarchive/message.php?msg_name=e5e16330902091450t2138127dj40bd7e69388f72c0%40mail.gmail.com Here]. What we learned from that is that we need even more control over how the commands must be executed.<br />
<br />
'''Attention''': If you use [http://tincantools.com/product.php?productid=16144 BeagleBoard Adapter Kit], make sure you plug the JTAG adapter the correct way. There are several possible ways, though. See [http://www.tincantools.com/images/D/Fly%2BBeagle-800x391.JPG?1229714946602 connection picture] how to do it the right way (in contrast to the picture EMU0 & EMU1 jumpers at JTAG adapter should be both at 1-2 position (touching J2)).<br />
<br />
==BDI 2000==<br />
<br />
===Example===<br />
<br />
[http://groups.google.com/group/beagleboard/msg/8463086de562ee00 Chuck Fleming] reports:<br />
<br />
The BDI2000 appears to work with the omap35xx.cfg and regOMAP3500.def files that come with the BDI hardware. I had to modify the 10-pin cable so that the BeagleBoard JTAG header matched the BDI target A connector:<br />
<br />
beagle>reset<br />
- TARGET: processing reset request<br />
- TARGET: BDI executes scan chain init string<br />
- TARGET: Bypass check 0x00000001 => 0x00000002<br />
- TARGET: JTAG exists check passed<br />
- Core#0: ID code is 0x0B6D602F<br />
- Core#0: DP-CSW is 0xF0000000<br />
- Core#0: DBG-AP at 0xD4011000<br />
- Core#0: DIDR is 0x15141012<br />
- TARGET: BDI removes RESET<br />
- TARGET: BDI waits for RESET inactive<br />
- TARGET: Reset sequence passed<br />
- TARGET: resetting target passed<br />
- TARGET: processing target startup ....<br />
- TARGET: processing target startup passed<br />
beagle>halt<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Debug Request<br />
Current PC : 0x40200000<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle>rdall<br />
User FIQ Superv Abort IRQ Undef<br />
GPR00: 480029fc 480029fc 480029fc 480029fc 480029fc 480029fc<br />
GPR01: 00000000 00000000 00000000 00000000 00000000 00000000<br />
GPR02: 00000001 00000001 00000001 00000001 00000001 00000001<br />
GPR03: 00000060 00000060 00000060 00000060 00000060 00000060<br />
GPR04: 00000000 00000000 00000000 00000000 00000000 00000000<br />
GPR05: 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4<br />
GPR06: 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4 80f2f2f4<br />
GPR07: 80e9ee88 80e9ee88 80e9ee88 80e9ee88 80e9ee88 80e9ee88<br />
GPR08: 80e3ffdc 34484608 80e3ffdc 80e3ffdc 80e3ffdc 80e3ffdc<br />
GPR09: 80e3fec8 26a1c132 80e3fec8 80e3fec8 80e3fec8 80e3fec8<br />
GPR10: 00000018 08040f16 00000018 00000018 00000018 00000018<br />
GPR11: 80e3fecc 3c278260 80e3fecc 80e3fecc 80e3fecc 80e3fecc<br />
GPR12: 0000006e 24200625 0000006e 0000006e 0000006e 0000006e<br />
GPR13: 00000000 00000000 80e3feb0 00000000 00000000 d1868045<br />
GPR14: 00000000 00000000 80e84f44 00000000 00000000 d55a4cc8<br />
PC : 40200000<br />
CPSR : 000001d3<br />
SPSR : 00000000 00000000 00000000 00000000 00000000<br />
beagle>md 0x40200000<br />
40200000 : e320f000 e320f000 e320f000 e320f000 .. ... ... ... .<br />
40200010 : e320f000 e320f000 e320f000 eafffffc .. ... ... .....<br />
40200020 : b6273502 e7aa052b 047694c8 91ca77d8 .5'.+.....v..w..<br />
40200030 : 12b9579e ef2eef1b 00543892 494f9bc1 .W.......8T...OI<br />
40200040 : 3f63013d 82eee656 b7adfe8d 993f1368 =.c?V.......h.?.<br />
40200050 : 51f1cf9b 0464a23e bea76e3c 3d275f5c ...Q>.d.<n..\_'=<br />
40200060 : 76554290 6776c892 a6cd088f 6dd4529a .BUv..vg.....R.m<br />
40200070 : 067261b8 e5f80e9e cb4ea075 25a9dd95 .ar.....u.N....%<br />
40200080 : 779db8c6 0496597b 7d5f8d5a 24f44cd6 ...w{Y..Z._}.L.$<br />
40200090 : 99ab46f9 9ddc06d9 fd34567a 2035bab8 .F......zV4...5<br />
402000a0 : a16b6760 fe863cf7 29046202 39fb0d49 `gk..<...b.)I..9<br />
402000b0 : dc9fd18c e50f536c 09ae66dd cad9ff91 ....lS...f......<br />
402000c0 : c46bdbdb be791808 89ff83fa 2d3bc71e ..k...y.......;-<br />
402000d0 : 43f5a3b6 0aed1747 ba3c4752 6af0573a ...CG...RG<.:W.j<br />
402000e0 : 3570da77 9a1dc961 324b876c 5d592060 w.p5a...l.K2` Y]<br />
402000f0 : b870f487 1277c035 4609dcf4 53b534c4 ..p.5.w....F.4.S<br />
beagle>ti<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Single Step<br />
Current PC : 0x40200004<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle>ti<br />
Core number : 0<br />
Core state : debug mode (ARM)<br />
Debug entry cause : Single Step<br />
Current PC : 0x40200008<br />
Current CPSR : 0x000001d3 (Supervisor)<br />
beagle><br />
<br />
===BDI config===<br />
<br />
The [ftp://78.31.64.234/bdigdb/config/arm/cortex-a8/ BDI config files] might help getting OpenOCD to work with BeagleBoard.<br />
<br />
This configuration assumes the "default" EMU 0 and 1 configuration (both not connected/high state). In this EM setup at first only one TAP is exported. A set of commands must be run on the first tap (embedded ICE) <br />
to enable access to the core:<br />
<br />
SCANINIT t1:w1000:t0:w1000: ;toggle TRST,<br />
SCANINIT ch10:w1000: ;clock TCK with TMS high and wait<br />
SCANINIT i6=07:d8=89:i6=02: ;connect and select router<br />
SCANINIT d32=81000080: ;IP control: KeepPowered<br />
SCANINIT d32=a3002048: ;TAP3: DebugConnect, ForcePower, ForceActive<br />
SCANINIT d32=81000081: ;IP control: KeepPowered, SysReset<br />
SCANINIT d32=a3002148: ;enable TAP3<br />
SCANINIT cl10:i10=ffff ;clock 10 times in RTI, scan bypass<br />
<br />
==Lauterbach==<br />
<br />
Lauterbach Debugger supports [http://www.lauterbach.com/news_288.html OMAP3503/15/25/30].<br />
<br />
==XDS510 and CCS==<br />
<br />
XDS510 and CCS (code composer studio) can be used to debug OMAP3503/15/25/30. [http://www.magniel.com/yuli/omap3_jtag.jpg Configuration screen shot]. For CCS setup see [http://focus.ti.com/lit/ml/sprp603/sprp603.pdf TI OMAP JTAG presentation], too (start page: 16).<br />
<br />
==PEEDI==<br />
<br />
[http://www.ronetix.at/peedi.html PEEDI] JTAG/BDM Emulator and Flash Programmer of [http://www.ronetix.at Ronetix] supports OMAP3. A configuration file for the Beagleboard can be found here: [http://download.ronetix.info/peedi/cfg_examples/cortex-a8/omap3530.cfg omap3530.cfg]<br />
<br />
PEEDI has a built-in support for GNU gbd based debuggers and a built-in Flash Programmer.<br />
The Flash Programmer is capable to program:<br />
* NOR Flash devices (over 900)<br />
* NAND and OneNAND Flash devices (small page, larger page, 8/16 bit), various methods of ECC calculation, bad block management.<br />
* DataFlash devices<br />
* SPI DataFlash devices<br />
* images located on a TFTP/FTP/HTTP server or a MMC/SD card (which allows standalone mode).<br />
<br />
The PEEDI package includes also an PEEDI to TI14 adapter and an TI20 to TI14 adapter.<br />
<br />
==ARM RealView ICE==<br />
<br />
The new release of software (3.3) for the [http://www.bluewatersys.com/blog/?p=71 ARM RealView ICE] supports Texas Instruments’ range of OMAP3 processors.<br />
<br />
=Linux kernel debugging=<br />
<br />
If you like to debug Linux kernel (with one of the above JTAG tools?) using GDB have a look to [[DebuggingTheLinuxKernelUsingGdb|debugging Linux kernel using GDB]] article.</div>Keesjhttps://elinux.org/index.php?title=OMAP3530_ICEPICK&diff=9179OMAP3530 ICEPICK2009-02-01T10:47:02Z<p>Keesj: /* Adding TAPs to the Scan Chain */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
The page is about [http://wiki.davincidsp.com/index.php?title=OMAP3_Overview OMAP3530] ICEPICK. See [[BeagleBoardJTAG|BeagleBoard JTAG page]] for more info about JTAG on OMAP3530 used at [[BeagleBoard|BeagleBoard]].<br />
<br />
== Adding TAPs to the Scan Chain ==<br />
<br />
The TAP router must be programmed to add additional TAPs to the scan chain. The following JTAG scans must be completed before the CoreSight DAP is added to the scan chain.<br />
<br />
<pre><br />
## Function : Update the JTAG preamble and post-amble counts.<br />
Parameter : The IR pre-amble count is '0'.<br />
Parameter : The IR post-amble count is '0'.<br />
Parameter : The DR pre-amble count is '0'.<br />
Parameter : The DR post-amble count is '0'.<br />
Parameter : The IR main count is '6'.<br />
Parameter : The DR main count is '1'.<br />
<br />
## Function : Do a send-only JTAG IR/DR scan.<br />
Parameter : The route to JTAG shift state is 'shortest transition'.<br />
Parameter : The JTAG shift state is 'shift-ir'.<br />
Parameter : The JTAG destination state is 'pause-ir'.<br />
Parameter : The bit length of the command is '6'.<br />
Parameter : The send data value is '0x00000007'.<br />
Parameter : The actual receive data is 'discarded'.<br />
<br />
## Function : Do a send-only JTAG IR/DR scan.<br />
Parameter : The route to JTAG shift state is 'shortest transition'.<br />
Parameter : The JTAG shift state is 'shift-dr'.<br />
Parameter : The JTAG destination state is 'pause-dr'.<br />
Parameter : The bit length of the command is '8'.<br />
Parameter : The send data value is '0x00000089'.<br />
Parameter : The actual receive data is 'discarded'.<br />
<br />
## Function : Do a send-only JTAG IR/DR scan.<br />
Parameter : The route to JTAG shift state is 'shortest transition'.<br />
Parameter : The JTAG shift state is 'shift-ir'.<br />
Parameter : The JTAG destination state is 'pause-ir'.<br />
Parameter : The bit length of the command is '6'.<br />
Parameter : The send data value is '0x00000002'.<br />
Parameter : The actual receive data is 'discarded'.<br />
<br />
## Function : Embed the port address in next command.<br />
Parameter : The port address field is '0x0f000000'.<br />
Parameter : The port address value is '3'.<br />
<br />
## Function : Do a send-only JTAG IR/DR scan.<br />
Parameter : The route to JTAG shift state is 'shortest transition'.<br />
Parameter : The JTAG shift state is 'shift-dr'.<br />
Parameter : The JTAG destination state is 'pause-dr'.<br />
Parameter : The bit length of the command is '32'.<br />
Parameter : The send data value is '0xa3002108'.<br />
Parameter : The actual receive data is 'discarded'.<br />
<br />
## Function : Do a send-only all-ones JTAG IR/DR scan.<br />
Parameter : The JTAG shift state is 'shift-ir'.<br />
Parameter : The JTAG destination state is 'run-test/idle'.<br />
Parameter : The bit length of the command is '6'.<br />
Parameter : The send data value is 'all-ones'.<br />
Parameter : The actual receive data is 'discarded'.<br />
<br />
## Function : Wait for a minimum number of TCLK pulses.<br />
Parameter : The count of TCLK pulses is '10'.<br />
<br />
## Function : Update the JTAG preamble and post-amble counts.<br />
Parameter : The IR pre-amble count is '0'.<br />
Parameter : The IR post-amble count is '6'.<br />
Parameter : The DR pre-amble count is '0'.<br />
Parameter : The DR post-amble count is '1'.<br />
Parameter : The IR main count is '4'.<br />
Parameter : The DR main count is '1'. <br />
<br />
</pre><br />
<br />
Once the DAP is added to the scan chain, the debugger can communicate with the CortexA8 processor.<br />
<br />
[http://www.bluewatersys.com/blog/wp-content/uploads/2008/12/ti_jtag.jpg Screen shot] of OMAP3530 scan chain from ARM's RealView ICE.<br />
<br />
<br />
== ICEPICK instructions ==<br />
<br />
The following log shows a IR discovery scan of the icepick using urjtag and a jtagkey.<br />
<br />
<pre><br />
jtag> cable JTAGkey<br />
Connected to libftd2xx driver.<br />
jtag> detect<br />
IR length: 6<br />
Chain length: 1<br />
Device Id: 0 (0x0000000000000000)<br />
chain.c(133) Part 0 without active instruction<br />
chain.c(184) Part 0 without active instruction<br />
chain.c(133) Part 0 without active instruction<br />
jtag> idcode<br />
Reading 0 bytes if idcode<br />
Read 00101111 11100000 01111010 00001011 00000000 00000000 00000000 00000000<br />
jtag> discovery<br />
Detecting IR length ... 6<br />
Detecting DR length for IR 111111 ... 1<br />
Detecting DR length for IR 000000 ... 1<br />
Detecting DR length for IR 000001 ... 1<br />
Detecting DR length for IR 000010 ... 1<br />
Detecting DR length for IR 000011 ... 1<br />
Detecting DR length for IR 000100 ... 32<br />
Detecting DR length for IR 000101 ... 32<br />
Detecting DR length for IR 000110 ... 1<br />
Detecting DR length for IR 000111 ... 8<br />
Detecting DR length for IR 001000 ... 32<br />
Detecting DR length for IR 001001 ... 1<br />
Detecting DR length for IR 001010 ... 1<br />
Detecting DR length for IR 001011 ... 1<br />
Detecting DR length for IR 001100 ... 1<br />
Detecting DR length for IR 001101 ... 1<br />
Detecting DR length for IR 001110 ... 1<br />
Detecting DR length for IR 001111 ... 1<br />
Detecting DR length for IR 010000 ... 1<br />
Detecting DR length for IR 010001 ... 1<br />
Detecting DR length for IR 010010 ... 1<br />
Detecting DR length for IR 010011 ... 1<br />
Detecting DR length for IR 010100 ... 1<br />
Detecting DR length for IR 010101 ... 1<br />
Detecting DR length for IR 010110 ... 1<br />
Detecting DR length for IR 010111 ... Warning: TDO seems to be stuck at 0<br />
-1<br />
Detecting DR length for IR 011000 ... Warning: TDO seems to be stuck at 0<br />
-1<br />
...(even more DTO seems stucked)...<br />
Detecting DR length for IR 011100 ... Warning: TDO seems to be stuck at 0<br />
-1<br />
Detecting DR length for IR 011101 ... Warning: TDO seems to be stuck at 0<br />
Detecting DR length for IR 011111 ... 1<br />
Detecting DR length for IR 100000 ... Warning: TDO seems to be stuck at 0<br />
-1<br />
Detecting DR length for IR 100100 ... Warning: TDO seems to be stuck at 0<br />
-1<br />
.... (The rest gets the same error codes)<br />
</pre></div>Keesjhttps://elinux.org/index.php?title=GDB&diff=9044GDB2009-01-14T13:58:20Z<p>Keesj: /* Startup */</p>
<hr />
<div>The GNU Debugger GDB is the most common debug tool for Linux. It features most used features one can think of, including server-client debug architecture (so you run the heavy debug part on your host/pc machine), but lack some bits as checkpoint-restart during execution.<br />
<br />
== Documentation ==<br />
<br />
GDB ships with extensive documentation at http://www.gnu.org/software/gdb/documentation/, but there are some good [http://refcards.com/docs/peschr/gdb/gdb-refcard-a4.pdf quick reference cards] as well.<br />
<br />
== Basic Usage ==<br />
<br />
Documentation is so large that sometimes its hard to get started, so most simple tasks can be done with the following commands, but please read GDB docs as soon as possible!<br />
<br />
=== Startup ===<br />
<br />
To start a new application for debug, use:<br />
<br />
$ gdb ./binary<br />
$ gdb ./binary core.dump<br />
$ gdb --args ./binary arg1 arg2<br />
$ gdb --command=my-gdb-commands.txt --args ./binary arg1 arg2<br />
<br />
and then run it with (args just required if no --args were used):<br />
<br />
(gdb) run arg1 arg2<br />
<br />
if you need to execute a series of commands every time, consider writing them on a file and use <code>--command=file</code> (or <code>-x file</code>).<br />
<br />
It's usually a pain to run the full gdb on your device, so use gdbserver on the target and gdb on host:<br />
<br />
target/device$ gdbserver 0.0.0.0:2345 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 --attach PID<br />
<br />
host/pc$ gdb<br />
(gdb) target remote /dev/ttyS1<br />
(gdb) target remote 192.168.0.123:2345<br />
<br />
If you are using the serial method you need to make sure you have setup the serial speed correctly,<br />
On the host:<br />
(gdb) set remotebaud 115200<br />
<br />
On the target(before you issue the gdbserver command):<br />
stty speed 115200 < /dev/ttyS1<br />
<br />
If application is already running, find out its pid (ps, top, pidof, ...) and:<br />
<br />
$ gdb --pid $PID<br />
<br />
=== Breakpoints ===<br />
<br />
If you control-C (^C), it will break at that point, but you can also schedule a breakpoint with:<br />
<br />
(gdb) break function<br />
(gdb) break line<br />
(gdb) break file:function<br />
(gdb) break file:line<br />
<br />
conditional breaks are in the form:<br />
<br />
(gdb) break where if condition<br />
<br />
where <code>condition</code> is some C expression that evaluates to 1 or 0, like <code>*ptr == NULL</code><br />
<br />
One can disable or remove breakpoints with:<br />
(gdb) enable breakpoint-number<br />
(gdb) disable breakpoint-number<br />
(gdb) delete breakpoint-number<br />
(gdb) clear # removes all breakpoints<br />
<br />
=== Examining ===<br />
<br />
To list source code nearby position or specific places:<br />
(gdb) list<br />
(gdb) list line<br />
(gdb) list function<br />
(gdb) list file:line<br />
(gdb) list file:function<br />
(gdb) list *address<br />
<br />
To list execution backtrace (or <code>bt</code> for short):<br />
(gdb) backtrace<br />
<br />
To change frame to operate on:<br />
(gdb) frame frame-number<br />
<br />
To change thread to operate on:<br />
(gdb) thread thread-number<br />
<br />
To print some value or expression:<br />
(gdb) print $register<br />
(gdb) print variable<br />
(gdb) print *address<br />
(gdb) print *(int *)address<br />
(gdb) print *(char **)address<br />
(gdb) print myfunc(p1, p2) # will actually execute it and return result!<br />
(gdb) print *a = 123 # will actually change *a value and return 123!<br />
(gdb) print file::variable<br />
(gdb) print function::variable<br />
<br />
To disassembly:<br />
(gdb) disassembly<br />
(gdb) disassembly file:line<br />
<br />
Print function arguments:<br />
(gdb) info args<br />
<br />
Print locals:<br />
(gdb) info locals<br />
<br />
Print breakpoints:<br />
(gdb) info breakpoints<br />
<br />
Print threads:<br />
(gdb) info threads<br />
<br />
=== Stepping ===<br />
<br />
To go to next instruction, possible entering a function (or <code>s</code> for short):<br />
(gdb) step<br />
<br />
To go to next instruction, but avoid entering new functions (or <code>n</code> for short):<br />
(gdb) next<br />
<br />
To continue until the function returns:<br />
(gdb) finish<br />
<br />
To continue execution (or <code>c</code> for short):<br />
(gdb) continue<br />
<br />
=== Manipulating Program ===<br />
<br />
To set variable to some value:<br />
(gdb) set var name=value<br />
<br />
To force function to return:<br />
(gdb) return value<br />
(gdb) return expression<br />
<br />
=== Changing Signal Handlers ===<br />
<br />
(gdb) handle signal action<br />
<br />
debugging applications with old libC, those pre-nptl, can be really annoying due SIG32 and SIG33, one can ignore those with:<br />
(gdb) handle SIG32 nostop<br />
(gdb) handle SIG32 noprint<br />
(gdb) handle SIG33 nostop<br />
(gdb) handle SIG33 noprint<br />
<br />
=== Shared Object Paths ===<br />
<br />
Often your cross compile root is not <code>/</code>, so you might have to add new paths to the search list.<br />
<br />
Unset absolute prefix:<br />
(gdb) set solib-absolute-prefix null<br />
<br />
Add paths to search paths:<br />
(gdb) set solib-search-path /path1:/path2<br />
<br />
Alternatively you can choose to set the prefix to the root of your target file system. Specially if you are doing<br />
embedded development and already exporting your root file system from you host machine to your target machine it can <br />
be very rewarding so simply use that as root:<br />
(gdb) set solib-absolute-prefix /rootfs<br />
<br />
[[Category:Tools]]</div>Keesjhttps://elinux.org/index.php?title=GDB&diff=9043GDB2009-01-14T13:51:57Z<p>Keesj: /* Shared Object Paths */</p>
<hr />
<div>The GNU Debugger GDB is the most common debug tool for Linux. It features most used features one can think of, including server-client debug architecture (so you run the heavy debug part on your host/pc machine), but lack some bits as checkpoint-restart during execution.<br />
<br />
== Documentation ==<br />
<br />
GDB ships with extensive documentation at http://www.gnu.org/software/gdb/documentation/, but there are some good [http://refcards.com/docs/peschr/gdb/gdb-refcard-a4.pdf quick reference cards] as well.<br />
<br />
== Basic Usage ==<br />
<br />
Documentation is so large that sometimes its hard to get started, so most simple tasks can be done with the following commands, but please read GDB docs as soon as possible!<br />
<br />
=== Startup ===<br />
<br />
To start a new application for debug, use:<br />
<br />
$ gdb ./binary<br />
$ gdb ./binary core.dump<br />
$ gdb --args ./binary arg1 arg2<br />
$ gdb --command=my-gdb-commands.txt --args ./binary arg1 arg2<br />
<br />
and then run it with (args just required if no --args were used):<br />
<br />
(gdb) run arg1 arg2<br />
<br />
if you need to execute a series of commands every time, consider writing them on a file and use <code>--command=file</code> (or <code>-x file</code>).<br />
<br />
It's usually a pain to run the full gdb on your device, so use gdbserver on the target and gdb on host:<br />
<br />
target/device$ gdbserver 0.0.0.0:2345 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 ./binary arg1 arg2<br />
target/device$ gdbserver /dev/ttyS1 --attach PID<br />
<br />
host/pc$ gdb<br />
(gdb) target remote /dev/ttyS1<br />
(gdb) target remote 192.168.0.123:2345<br />
<br />
If application is already running, find out its pid (ps, top, pidof, ...) and:<br />
<br />
$ gdb --pid $PID<br />
<br />
<br />
=== Breakpoints ===<br />
<br />
If you control-C (^C), it will break at that point, but you can also schedule a breakpoint with:<br />
<br />
(gdb) break function<br />
(gdb) break line<br />
(gdb) break file:function<br />
(gdb) break file:line<br />
<br />
conditional breaks are in the form:<br />
<br />
(gdb) break where if condition<br />
<br />
where <code>condition</code> is some C expression that evaluates to 1 or 0, like <code>*ptr == NULL</code><br />
<br />
One can disable or remove breakpoints with:<br />
(gdb) enable breakpoint-number<br />
(gdb) disable breakpoint-number<br />
(gdb) delete breakpoint-number<br />
(gdb) clear # removes all breakpoints<br />
<br />
=== Examining ===<br />
<br />
To list source code nearby position or specific places:<br />
(gdb) list<br />
(gdb) list line<br />
(gdb) list function<br />
(gdb) list file:line<br />
(gdb) list file:function<br />
(gdb) list *address<br />
<br />
To list execution backtrace (or <code>bt</code> for short):<br />
(gdb) backtrace<br />
<br />
To change frame to operate on:<br />
(gdb) frame frame-number<br />
<br />
To change thread to operate on:<br />
(gdb) thread thread-number<br />
<br />
To print some value or expression:<br />
(gdb) print $register<br />
(gdb) print variable<br />
(gdb) print *address<br />
(gdb) print *(int *)address<br />
(gdb) print *(char **)address<br />
(gdb) print myfunc(p1, p2) # will actually execute it and return result!<br />
(gdb) print *a = 123 # will actually change *a value and return 123!<br />
(gdb) print file::variable<br />
(gdb) print function::variable<br />
<br />
To disassembly:<br />
(gdb) disassembly<br />
(gdb) disassembly file:line<br />
<br />
Print function arguments:<br />
(gdb) info args<br />
<br />
Print locals:<br />
(gdb) info locals<br />
<br />
Print breakpoints:<br />
(gdb) info breakpoints<br />
<br />
Print threads:<br />
(gdb) info threads<br />
<br />
=== Stepping ===<br />
<br />
To go to next instruction, possible entering a function (or <code>s</code> for short):<br />
(gdb) step<br />
<br />
To go to next instruction, but avoid entering new functions (or <code>n</code> for short):<br />
(gdb) next<br />
<br />
To continue until the function returns:<br />
(gdb) finish<br />
<br />
To continue execution (or <code>c</code> for short):<br />
(gdb) continue<br />
<br />
=== Manipulating Program ===<br />
<br />
To set variable to some value:<br />
(gdb) set var name=value<br />
<br />
To force function to return:<br />
(gdb) return value<br />
(gdb) return expression<br />
<br />
=== Changing Signal Handlers ===<br />
<br />
(gdb) handle signal action<br />
<br />
debugging applications with old libC, those pre-nptl, can be really annoying due SIG32 and SIG33, one can ignore those with:<br />
(gdb) handle SIG32 nostop<br />
(gdb) handle SIG32 noprint<br />
(gdb) handle SIG33 nostop<br />
(gdb) handle SIG33 noprint<br />
<br />
=== Shared Object Paths ===<br />
<br />
Often your cross compile root is not <code>/</code>, so you might have to add new paths to the search list.<br />
<br />
Unset absolute prefix:<br />
(gdb) set solib-absolute-prefix null<br />
<br />
Add paths to search paths:<br />
(gdb) set solib-search-path /path1:/path2<br />
<br />
Alternatively you can choose to set the prefix to the root of your target file system. Specially if you are doing<br />
embedded development and already exporting your root file system from you host machine to your target machine it can <br />
be very rewarding so simply use that as root:<br />
(gdb) set solib-absolute-prefix /rootfs<br />
<br />
[[Category:Tools]]</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardOpenOCD&diff=8957BeagleBoardOpenOCD2009-01-09T20:41:47Z<p>Keesj: /* Build OpenOCD */</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This page is about how to use open source [http://openocd.berlios.de/web/ OpenOCD] [http://en.wikipedia.org/wiki/JTAG JTAG] software with [[BeagleBoard|BeagleBoard]]. With this, it will be possible to have OMAP3 JTAG debug using cheap [[BeagleBoardJTAG|JTAG hardware]], e.g. [[BeagleBoardJTAG#TinCanTools_Flyswatter|Flyswatter]].<br />
<br />
'''As of December 2008, OpenOCD doesn't work with Beagle Board (ARM Cortex A8, OMAP3). OpenOCD support is work in progress'''. This section tries to cover the recent status to<br />
<br />
* give everybody the steps to recent status in case they want to help<br />
* be ready if support is ready <br />
<br />
<br />
=OpenOCD JTAG bring up=<br />
<br />
On [http://www.beagleboard.org/irclogs/index.php?date=2008-04-25#T15:43:07 IRC] it was discussed what will be Add Cortex-A8 CPU ID. Currently only Cortex-M3 is supported. Take this as example. Once you connect to target you should get error message ''expect cpuid of xxxxxx but got yyyyyy'' which should contain Cortex-A8 CPU ID.<br />
* Take CPU scan lengths from OMAP3530 CCS config.<br />
* Regarding EMU0/EMU1 pins on BeagleBoard, pulling both pins down does currently not make Cortex-A8 CPU accessible. Only one TAP is visible (ICEPick). Therefore OpenOCD will not be able to validate the scan chain. The documentation for the control of EMU0/EMU1 is very misleading:<br />
<br />
0 0 ICEPick + default TAP(s)<br />
0 1 ICEPick Reserved<br />
1 0 ICEPick Wait-in-reset<br />
1 1 ICEPick Default condition<br />
NOTES: ICEPick is always in the scan chain<br />
''Default TAPs are the ARM and the ETB''<br />
<br />
This table is identical to the [http://wiki.davincidsp.com/index.php?title=Debugging_on_DaVinci_using_Olimex_dongle Davinci] documentation, with one ''BIG'' difference:<br />
* The OMAP3xx has ''NO'' default TAP (ARM or ETB taps) which means that the configuration of EMU0-L/EMU1-L doesn't add ARM to scan chain (above table is wrong, though).<br />
The OMAP3xx uses a TAP router, it needs to be [[OMAP3530_ICEPICK|programmed with the information about available TAPS]] first, before ARM is accessible. Once the DAP has been added to the TAP router, via a programming sequence, the ARM core can be accessed.<br />
<br />
TI has a [http://focus.ti.com/lit/ml/sprp603/sprp603.pdf good presentation] describing the functionality of the ICEPick TAP Router (or generically refered to as JTAG Route Controller or JRC). The ICEPick jtag device ID is 0x0b73b02f (Manufacturer: 0x017, Part: 0xb73b, Version: 0x0) and is the same as the Davinci series.<br />
<br />
It may still be possible to use the EMU0-L/EMU1-L configuration, but with consideration that the TAP router will already configured for with the arm core interface. Yet to be tested.<br />
<br />
If above basics work, additionally MMU, cache support and some include files for A8 might be added to OpenOCD.<br />
<br />
Note: If you made some progress regarding BeagleBoard OpenOCD support, please send a short note to [http://groups.google.com/group/beagleboard BeagleBoard ML] and [https://lists.berlios.de/mailman/listinfo/openocd-development OpenOCD ML].<br />
<br />
'''Status December 2008''':<br />
<br />
* [https://lists.berlios.de/pipermail/openocd-development/2008-December/004160.html Status mail] at OpenOCD mailing list.<br />
* There is some [https://lists.berlios.de/pipermail/openocd-development/2008-October/thread.html discussion] how to extend OpenOCD to support JRC configuration (see thread ''JTAG emulator with openocd for beagleboard'').<br />
<br />
=Build OpenOCD=<br />
<br />
[http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD OpenOCD build instructions] describe how to build [http://openocd.berlios.de/web/ OpenOCD]. For questions you can use [https://lists.berlios.de/mailman/listinfo/openocd-development OpenOCD Mailing list].<br />
<br />
Get OpenOCD code via [http://subversion.tigris.org/ svn]:<br />
<br />
> svn checkout svn://svn.berlios.de/openocd/trunk openocd<br />
<br />
For Flyswatter you additionally need [http://www.ftdichip.com/Drivers/D2XX.htm libftd2xx] or [http://www.intra2net.com/de/produkte/opensource/ftdi/ libFTDI]. While libFTDI is available in source, libftd2xx is supposed to be 50% [http://www.beagleboard.org/irclogs/index.php?date=2008-10-16#T16:06:22 faster] than libFTDI. The libtfd2xx binaries are available booth as shared library or linkable archive.<br />
<br />
If you downloaded OpenOCD svn and have libftd2xx or libFTDI, build OpenOCD (assuming you extracted/built FTDI library already):<br />
<br />
> cd openocd<br />
> ./bootstrap<br />
> ./configure --enable-ft2232_ftd2xx --with-ftd2xx-linux-tardir=<path_to>/libftd2xx0.4.16 --prefix=/home/user/bin/openOCD<br />
''or'' (depending which FTDI library you use, see above)<br />
> ./configure --enable-ft2232_libftdi --prefix=/home/user/bin/openOCD<br />
> make<br />
> make install<br />
<br />
'''Note''': By default (make & make install) only .info documentation is installed. You can get PDF or HTML documentation by<br />
<br />
make pdf<br />
<br />
or<br />
<br />
make html<br />
<br />
Resulting documentation can be found in openocd/doc, then.<br />
<br />
'''Note''': If you like to save some disk space and don't plan to debug OpenOCD binary itself, you can strip this (remove unneeded debug symbols):<br />
<br />
> cd <openocd_install_dir>/bin<br />
> strip openocd<br />
<br />
(e.g. with OpenOCD 1.0 this reduced binary size from ~3MB to ~700kB)<br />
<br />
'''Note''': If you don't have libftdi in standard path, you might like to extend library search path:<br />
<br />
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<path_to>/lib<br />
<br />
if you e.g. get<br />
<br />
> ./openocd<br />
./openocd: error while loading shared libraries: libftdi.so.1: cannot open shared object file: No such file or directory<br />
<br />
=Beagle configuration file=<br />
<br />
OpenOCD runtime is controlled by several [http://openocd.berlios.de/doc/Simple-Configuration-Files.html#Simple-Configuration-Files configuration files]. I.e. main configuration file (openocd.cfg) calling ("source") various sub configurations. For Beagle, in directory where you start ''openocd'' create a file '''openocd.cfg''' (assuming you use Flyswatter):<br />
<br />
#File openocd.cfg<br />
#Basic configuration<br />
telnet_port 4444<br />
gdb_port 3333<br />
<br />
#Interface<br />
source [find interface/flyswatter.cfg]<br />
<br />
#jtag scan chain<br />
source [find target/omap3530.cfg]<br />
<br />
and a file '''omap3530.cfg''':<br />
<br />
#File omap3530.cfg<br />
#TI OMAP3530 processor - http://www.ti.com <br />
<br />
if { [info exists CHIPNAME] } { <br />
set _CHIPNAME $CHIPNAME <br />
} else { <br />
set _CHIPNAME omap3530<br />
}<br />
<br />
if { [info exists ENDIAN] } { <br />
set _ENDIAN $ENDIAN <br />
} else { <br />
# this defaults to a little endianness<br />
set _ENDIAN little<br />
}<br />
<br />
if { [info exists CPUTAPID ] } {<br />
set _CPUTAPID $CPUTAPID<br />
} else {<br />
# force an error till we get a good number<br />
set _CPUTAPID 0xffffffff<br />
}<br />
<br />
#jtag scan chain<br />
jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0xf -expected-id 0x0b7ae02f<br />
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0x0 -expected-id $_CPUTAPID -disable<br />
<br />
jtag configure $_CHIPNAME.cpu -event tap-enable {<br />
puts "Enabling Cortex-A8 @ OMAP3"<br />
irscan omap3530.jrc 7<br />
drscan omap3530.jrc 8 0x89<br />
irscan omap3530.jrc 2<br />
drscan omap3530.jrc 32 0x81000080<br />
drscan omap3530.jrc 32 0xa3002048<br />
drscan omap3530.jrc 32 0x81002148<br />
drscan omap3530.jrc 32 0xa3002148<br />
runtest 10<br />
puts "Cortex-A8 @ OMAP3 enabled"<br />
}<br />
<br />
Interface configuration file ''flyswatter.cfg'' is part of OpenOCD source.<br />
<br />
Assuming you<br />
* have a omap3530.cfg in target directory<br />
* have Flyswatter switched on (attached to USB)<br />
* have openocd.cfg in the directory you start openocd from<br />
you can now start openocd with<br />
<br />
openocd -s <path_to_config_files> // e.g. <patch_of_openocd_install_dir>/lib/openocd<br />
<br />
This should result in<br />
<br />
> openocd -s lib/openocd/<br />
<br />
Open On-Chip Debugger 1.0 (2008-12-19-17:38) svn:1261<br />
<br />
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS<br />
<br />
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $<br />
jtag_speed: 1<br />
Info: JTAG tap: omap3530.jrc tap/device found: 0x0b7ae02f (Manufacturer: 0x017, Part: 0xb7ae, Version: 0x0)<br />
Info: JTAG Tap/device matched<br />
Warning:no gdb ports allocated as no target has been specified<br />
Warning:no tcl port specified, using default port 6666<br />
<br />
This shows that your (Flyswatter) JTAG dongle basically works and that you are able to see OMAP3 JRC. OpenOCD now runs as deamon.<br />
<br />
=Controlling OpenOCD=<br />
<br />
Once OpenOCD runs as [http://openocd.berlios.de/doc/Running.html#Running daemon] like above, you can connect using ''telnet'' or ''GDB''<br />
<br />
==telnet==<br />
<br />
Connect to OpenOCD daemon. Assuming you do it on your local machine, open a second terminal window and do (assuming port 4444 as configured in above openocd.cfg):<br />
<br />
> '''telnet localhost 4444'''<br />
Trying 127.0.0.1...<br />
Connected to localhost.<br />
Escape character is '^]'.<br />
Open On-Chip Debugger<br />
> <br />
<br />
This should give you<br />
<br />
Info: accepting 'telnet' connection from 0<br />
<br />
in window where OpenOCD daemon is started.<br />
<br />
At OpenOCDs telnet prompt you can now issue OpenOCD commands. E.g. ''help'' should result in<br />
<br />
> '''help'''<br />
cpu <name> - prints out target options and a comment<br />
on CPU which matches name<br />
debug_level adjust debug level <0-3><br />
drscan execute DR scan <device> <num_bits> <value><br />
<num_bits1> <value2> ...<br />
endstate finish JTAG operations in <tap_state><br />
exit exit telnet session<br />
fast fast <enable/disable> - place at beginning of<br />
config files. Sets defaults to fast and dangerous.<br />
fast_load loads active fast load image to current target -<br />
mainly for profiling purposes<br />
fast_load_image same args as load_image, image stored in memory -<br />
mainly for profiling purposes<br />
find <file> - print full path to file according to<br />
OpenOCD search rules<br />
ft2232_device_desc the USB device description of the FTDI FT2232<br />
device<br />
ft2232_latency set the FT2232 latency timer to a new value<br />
ft2232_layout the layout of the FT2232 GPIO signals used to<br />
control output-enables and reset signals<br />
ft2232_serial the serial number of the FTDI FT2232 device<br />
ft2232_vid_pid the vendor ID and product ID of the FTDI FT2232<br />
device<br />
gdb_breakpoint_override hard/soft/disabled - force breakpoint type for gdb<br />
'break' commands.The raison d'etre for this option<br />
is to support GDB GUI's without a hard/soft<br />
breakpoint concept where the default OpenOCD<br />
behaviour is not sufficient<br />
gdb_detach<br />
gdb_flash_program enable or disable flash program<br />
gdb_memory_map enable or disable memory map<br />
gdb_port daemon configuration command gdb_port<br />
gdb_report_data_abort enable or disable report data<br />
help Tcl implementation of help command<br />
init initializes target and servers - nop on subsequent<br />
invocations<br />
interface try to configure interface<br />
irscan execute IR scan <device> <instr> [dev2] [instr2]<br />
...<br />
jtag perform jtag tap actions<br />
jtag_device jtag_device <ir_length> <ir_expected> <ir_mask><br />
jtag_khz same as jtag_speed, except it takes maximum khz as<br />
arguments. 0 KHz = RTCK.<br />
jtag_nsrst_delay jtag_nsrst_delay <ms> - delay after deasserting<br />
srst in ms<br />
jtag_ntrst_delay jtag_ntrst_delay <ms> - delay after deasserting<br />
trst in ms<br />
jtag_rclk fallback_speed_khz - set JTAG speed to RCLK or use<br />
fallback speed<br />
jtag_reset toggle reset lines <trst> <srst><br />
jtag_speed set jtag speed (if supported)<br />
log_output redirect logging to <file> (default: stderr)<br />
ocd_array2mem convert a TCL array to memory locations and write<br />
the values<br />
ocd_flash_banks return information about the flash banks<br />
ocd_mem2array read memory and return as a TCL array for script<br />
processing<br />
power_restore Overridable procedure run when power restore is<br />
detected. Runs 'reset init' by default.<br />
production <serialnumber> - Runs production procedure. Throws<br />
exception if procedure failed. Prints progress<br />
messages. Implement this procedure in the target<br />
script.<br />
production Runs test procedure. Throws exception if procedure<br />
failed. Prints progress messages. Implement in<br />
target script.<br />
production_info Displays information on production procedure for<br />
target script. Implement this procedure in target<br />
script.<br />
profile profiling samples the CPU PC<br />
reset_config<br />
runtest move to Run-Test/Idle, and execute <num_cycles><br />
scan_chain print current scan chain configuration<br />
script <filename> - filename of OpenOCD script (tcl) to<br />
run<br />
shutdown shut the server down<br />
sleep <n> [busy] - sleep for n milliseconds. "busy"<br />
means busy wait<br />
srst_deasserted Overridable procedure run when srst deassert is<br />
detected. Runs 'reset init' by default.<br />
target configure target<br />
targets change the current command line target (one<br />
parameter) or lists targets (with no parameter)<br />
tcl_port port on which to listen for incoming TCL syntax<br />
telnet_port port on which to listen for incoming telnet<br />
connections<br />
verify_ircapture verify value captured during Capture-IR<br />
<enable|disable><br />
version show OpenOCD version<br />
virt2phys translate a virtual address into a physical<br />
address<br />
xsvf run xsvf <file><br />
flash bank flash bank <driver> <base> <size> <chip_width><br />
<bus_width> <target> [driver_options ...]<br />
mflash bank mflash bank <soc> <base> <chip_width> <bus_width> <br />
<RST pin> <WP pin> <DPD pin> <target #><br />
nand device<br />
pld device<br />
<br />
Now, we can try to print recent OMAP3 scan chain configuration and enable Cortex-A8 manually (by configuring JRC):<br />
<br />
> '''scan_chain'''<br />
TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr<br />
---|--------------------|---------|------------|------------|------|------|------|---------<br />
0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x01 | 0x0f | 0x3f<br />
1 | omap3530.cpu | n | 0x00000000 | 0xffffffff | 0x04 | 0x01 | 0x00 | 0x0f<br />
<br />
> '''jtag tapenable omap3530.cpu'''<br />
Enabling Cortex-A8 @ OMAP3<br />
Cortex-A8 @ OMAP3 enabled<br />
1<br />
> '''scan_chain'''<br />
TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr<br />
---|--------------------|---------|------------|------------|------|------|------|---------<br />
0 | omap3530.jrc | Y | 0x0b7ae02f | 0x0b7ae02f | 0x06 | 0x01 | 0x0f | 0x3f<br />
1 | omap3530.cpu | Y | 0x00000000 | 0xffffffff | 0x04 | 0x01 | 0x00 | 0x0f<br />
<br />
==GDB==<br />
<br />
tbd.<br />
<br />
=GDB ARM=<br />
<br />
To [[DebuggingTheLinuxKernelUsingGdb|debug]] an ARM target with GNU debugger ([[GDB|GDB]]), you need a GDB understanding ARM processor. If your ARM cross compilation tool chain doesn't include a GDB, you can easily build it your self.<br />
<br />
* Download latest [http://www.gnu.org/software/gdb/download/ GDB sources]. [http://openocd.berlios.de/doc/GDB-and-OpenOCD.html#GDB-and-OpenOCD OpenOCD docu] recommends to use GDB 6.7 or newer. Here, we use GDB 6.8 which is the recent version while writing this.<br />
<br />
* Extract, configure and build GDB for ARM. Afterwards remove temporary stuff. Options are:<br />
** <path_where_ARM_gdb_shall_be_installed_to> : Directory where you want to install the resulting tool to. E.g. /home/user/arm-gdb/<br />
** <ARM_toolchain_prefix> : The prefix of your ARM GCC toolchain, e.g. ''arm-linux'' or ''arm-none-linux-gnueabi'' ([[BeagleBoard#Cortex_A8_ARM|CodeSourcery tool chain]]).<br />
<br />
> tar xfj gdb-6.8.tar.bz2<br />
> mkdir build-gdb<br />
> cd build-gdb/<br />
build-gdb > ../gdb-6.8/configure --prefix=<path_where_ARM_gdb_shall_be_installed_to> --target=<ARM_toolchain_prefix> i686-pc-linux-gnu<br />
build-gdb > make -j4<br />
build-gdb > make install<br />
build-gdb > cd ..<br />
> rm -rf gdb-6.8 build-gdb<br />
> export PATH=$PATH:<path_where_ARM_gdb_shall_be_installed_to>/bin<br />
<br />
Test:<br />
<br />
bin> ./arm-none-linux-gnueabi-gdb<br />
GNU gdb 6.8<br />
Copyright (C) 2008 Free Software Foundation, Inc.<br />
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html><br />
This is free software: you are free to change and redistribute it.<br />
There is NO WARRANTY, to the extent permitted by law. Type "show copying"<br />
and "show warranty" for details.<br />
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".<br />
(gdb)</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8875Debugging The Linux Kernel Using Gdb2009-01-05T13:22:24Z<p>Keesj: /* Loading Symbols of a loaded module */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]]. Using printk is a relatively simple, effective and cheap way to find problems. There are many other Linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the GNU debugger (GDB) to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. When using [[JTAG|JTAG]] and when using [[Qemu|QEMU]] system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source JTAG debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. [http://openocd.berlios.de/web/ OpenOCD] is pretty usable on the targets we tested ARM11 and ARM9.<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target (read armv6). with that you might also want to have the gdbserver that can serve as stub for you user land debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO...<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger. Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed. Most important is the difference between your vmlinux and the zImage. What you need to understand at this point is that the zImage is a container. This container gets loaded by a boot loader and that execution is handed over to the zImage. This zImage unpacks the kernel to the same memory location and starts executing the kernel. (explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the Linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't need to modify the kernel in any way. This is because we operate on the hardware, CPU core level. Overall this means that you can follow your normal development method. You can let your bootstrap and boot loader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be as simple as loading the vmlinuz and connecting to the remote target:<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel and reset your board using the JTAG reset signal. Your boot loader will initialize your board and the execution will stop at the start of the kernel. After that you can load a kernel into memory and run it.<br />
<br />
Execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via JTAG.<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. In such situations is it '''very''' handy to be able to dump the kernel log buffer. This can be done by looking at the content of the __log_buf in the kernel. In gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. Currently we use this routine that copied from wchar.gdb until something "normal" came out. We defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging a kernel module. We will need to help gdb a little. One problem with modules is that it is not possible to determine where in the memory a module will be loaded before it is actually loaded so only once it is loaded we need to determine the address in memory it is loaded and tell gdb about it. There are many ways of determining this information. Here are 3 ways:<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==Loading Symbols of a loaded module ==<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
<br />
Note that we use the .o file and not the .ko one. The address at the end is the address where the kernel decided to load<br />
the module<br />
<br />
== Pointers ==<br />
<br />
In the Linux Documentation directory under the kdump you will find file called gdbmacros.txt and it looks very promising as among other things it contains the a dmesg implementation<br />
<br />
head linux-2.6.22.1/Documentation/kdump/gdbmacros.txt<br />
#<br />
# This file contains a few gdb macros (user defined commands) to extract<br />
# useful information from kernel crashdump (kdump) like stack traces of<br />
# all the processes or a particular process and trapinfo.<br />
#<br />
<br />
<br />
A "find . -name "*gdb*" in the linux kernel directory also shows up a few interesting .gdbinit files that apparently can perform low level initialization.</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8563Debugging The Linux Kernel Using Gdb2008-12-15T21:11:25Z<p>Keesj: Added links/pointers to in kernel documentation</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==Loading Symbols of a loaded module ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
<br />
<br />
== Pointers ==<br />
<br />
In the Linux Documentation directory under the kdump you will find file called gdbmacros.txt and it looks very promising as among other things it contains the a dmesg implementation<br />
<br />
head linux-2.6.22.1/Documentation/kdump/gdbmacros.txt<br />
#<br />
# This file contains a few gdb macros (user defined commands) to extract<br />
# useful information from kernel crashdump (kdump) like stack traces of<br />
# all the processes or a particular process and trapinfo.<br />
#<br />
<br />
<br />
A "find . -name "*gdb*" in the linux kernel directory also shows up a few interesting dotgdbinit files<br />
that apparently can perform low level initialization.</div>Keesjhttps://elinux.org/index.php?title=Hammer_How_to_build_Kernel&diff=8538Hammer How to build Kernel2008-12-14T08:32:41Z<p>Keesj: </p>
<hr />
<div>Here is how to build a custom kernel:<br />
<br />
NOTE: If you are installing a custom rootfs, you may have to increase the size of the space in flash to hold the new rootfs image. You do this by editing the '''linux-<version>/arch/arm/mach-s3c2410/mach-tct_hammer.c''' file. Find the '''.size''' string and change the value to be a little larger than your rootfs image is. The image size is in hex, so you will have to do a conversion to get the right value.<br />
<br />
Some common values for '''.size''' are:<br />
<br />
2 MB = 0x340000<br />
3 MB = <br />
4 MB = <br />
5 MB = <br />
6 MB = <br />
8 MB = <br />
<br />
You may have to increase the size of your '''initramfs/initrd''' to accomodate your ramdisk image if the '''uncompressed''' size is larger than about 12 MB. There will be both compressed and uncompressed rootfs images in the buildroot/binaries/<project> directory. To do this, you have to set the size of the '''initramfs/initrd''' in the kernel. Find Block Devices in the kernel configuration and set the size to be just a little larger than your '''uncompressed''' initramfs/initrd. Only add a multiple of 1024 bytes.<br />
<br />
Do:<br />
<br />
tar xzf linux-2.6.22.tar.gz<br />
cd linux-2.6.22<br />
zcat ../Hammer-linux-2.6.22-09122007.diff.gz | patch -p1<br />
Edit linux-<version>/arch/arm/mach-s3c2410/mach-tct_hammer.c to change '''.size''' if needed.<br />
cp hammer-config .config<br />
make oldconfig<br />
make zImage<br />
make modules<br />
<br />
The kernel can be found in arch/arm/boot/zImage<br />
<br />
[[Category:TCT-Hammer]]<br />
[[Category:TinCanTools]]</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8456Debugging The Linux Kernel Using Gdb2008-12-09T20:22:08Z<p>Keesj: /* Loading the files */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==Loading Symbols of a loaded module ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8451Debugging The Linux Kernel Using Gdb2008-12-09T11:17:49Z<p>Keesj: /* loading the files */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==Loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=BeagleBoardAndOpenEmbeddedGit&diff=8450BeagleBoardAndOpenEmbeddedGit2008-12-09T11:07:28Z<p>Keesj: /* OpenEmbedded and Bitbake install */ Added http svn link for people behind a firewall</p>
<hr />
<div>[[Category: Linux]]<br />
[[Category: OMAP]]<br />
This guide briefly describes the steps that need to be taken in order to create an [http://www.openembedded.org/ OpenEmbedded] (OE) based image for the [[BeagleBoard]].<br />
It was created while performing an install on ubuntu804jeos (a minimal console only vmware appliance). This guide differs in that the official GettingStarted uses monotone while we will be using git. The second difference is that this guide only focuses on running on Ubuntu and developing for beagle.<br />
<br />
The first step is to get a working Open Embedded installation. This can seam a daunting task at first but the rewards are great so here we go. This guide tries to be self containing. We therefore will not push you to use Google or read the other manuals.<br />
<br />
=== Prerequisites ===<br />
OE tries to be as self supporting as possible. OE will both compile the cross compiler and the tools needed to compile a whole system. Still some dependencies are to be met using the "host" system. During the install we will be able to run almost all the commands as normal user but right now we will install the basic set of packages that are required to make OE to be happy.<br />
<br />
Host tools to install:<br />
sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev <br />
sudo apt-get install docbook-utils gawk help2man diffstat gtk-doc-tools file g++<br />
<br />
Nice to have optional tools to install:<br />
sudo apt-get install python-psyco minicom<br />
<br />
OE and many tools and scripts that are used contain bashisms. We therefore want to change the default "/bin/sh" to point to bash.<br />
sudo dpkg-reconfigure dash<br />
#and select no<br />
<br />
<br />
An other change need need to perform as root is to change some default settings of the kernel.<br />
sudo vi /etc/sysctl.conf<br />
vm.vdso_enabled = 0<br />
vm.mmap_min_addr = 0<br />
<br />
Run<br />
sudo sysctl -p<br />
<br />
== The effective install ==<br />
We are going install the OpenEmbedded system under the user's home directory in a directory called "oe". We will need about 10 gig of free disk space. Under that we will be putting the different components of the OE system. Those components are [http://bitbake.berlios.de/manual/ Bitbake], the OpenEmbedded meta-data and the beagle configuration. The Bitbake task executor will be put under "opt". The OpenEmbedded meta-data ( Bitbake recipes ), classes ( Bitbake extentions) and configuration (machine and arch setup) will be located under the "org.openembedded.dev" directory. The BeagleBoard configuration will be placed under "org.beagleboard.dev" directory.<br />
<br />
=== OpenEmbedded and Bitbake install ===<br />
This part really is not that difficult after all.<br />
<br />
Set the dir where everything will be done<br />
export OE_HOME=$HOME/oe<br />
<br />
Install Bitbake<br />
<br />
mkdir -p $OE_HOME/opt<br />
cd $OE_HOME/opt<br />
svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake<br />
#or if your are behind a firewall<br />
svn co <nowiki>http://svn.berlios.de/svnroot/repos/bitbake/branches/bitbake-1.8</nowiki> bitbake<br />
<br />
<br />
<br />
Install the OpenEmbedded meta-data using git<br />
cd $OE_HOME<br />
git clone git://git.openembedded.net/openembedded<br />
<br />
=== Creating the BeagleBoard configuration and profile ===<br />
We now need to tweak OpenEmbedded to fit our Beagle needs. We create a profile script that we can run whenever we feel like playing with beagle. This script will perform a few tasks. It will add bitbake to our PATH so we can run the bitbake command from anywhere. It will then export the BBPATH and BBFILES. This tells bitbake where to find it's meta-data. BBPATH will booth point to our own org.beagleboard.dev files and org.openembedded.dev.<br />
<br />
But first we create a local.conf containing the most important choices we need to make. Change at least the MACHINE to beagleboard. Comment the BBFILES variable as we will defines then in our profile script do select angstrom-2008.1 as distro. Remove the last line after that<br />
<br />
mkdir -p $OE_HOME/beagleboard/beagleboard/conf<br />
cat > $OE_HOME/beagleboard/beagleboard/conf/local.conf <<_EOF<br />
DISTRO = "angstrom-2008.1"<br />
BBFILES = "$OE_HOME/openembedded/packages/*/*.bb"<br />
TMPDIR = "$OE_HOME/tmp"<br />
MACHINE = "beagleboard"<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
_EOF<br />
<br />
Now we create our profile. There are TWO CHOICES here. <br />
<br />
CHOICE 1) If you are going to operate directly connected to the internet (i.e. NO Proxy Firewall), then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
CHOICE 2) If you will be operating from behind a Proxy Firewall, then do:<br />
<br />
cd $OE_HOME<br />
cat > $OE_HOME/beagleboard/beagleboard/profile.sh <<_EOF<br />
export OE_HOME=\$HOME/oe<br />
export MY_OE_CONF="beagleboard"<br />
export BBPATH=\$OE_HOME/beagleboard/:\$OE_HOME/beagleboard/\$MY_OE_CONF:\$OE_HOME/openembedded<br />
export BBFILES="\$OE_HOME/openembedded/packages/*/*.bb"<br />
export PATH=\$OE_HOME/opt/bitbake/bin:\$PATH<br />
export CVS_TARBALL_STASH="http://oesources.org/sources/current/"<br />
if [ "\$PS1" ]; then<br />
if [ "\$BASH" ]; then<br />
export PS1="\[\033[01;32m\]OE:\$MY_OE_CONF\[\033[00m\] \${PS1}"<br />
fi<br />
fi<br />
_EOF<br />
<br />
Now make the profile executable:<br />
<br />
chmod +x beagleboard/beagleboard/profile.sh<br />
<br />
== Running ==<br />
We now have finished the installation. If everything goes well we can now create images for the BeagleBoard<br />
<br />
source beagleboard/beagleboard/profile.sh<br />
<br />
Pull down any changes in the git tree.<br />
<br />
cd $OE_HOME/openembedded<br />
git pull<br />
git checkout<br />
<br />
Now build the console image.<br />
<br />
cd $OE_HOME<br />
bitbake console-image<br />
<br />
If this goes well your computer will be compiling for a long time. A long time can be several hours.<br />
<br />
If you receive an error of the form "ERROR: Unable to open conf/bitbake.conf" check that your profile.sh created earlier has the correct BBPATH setting (copy/pasting from this page may cause a line-break between the export command and the BBPATH var).<br />
<br />
== Preparing the system for booting ==<br />
The output of the bitbake command will ultimately be found under the $OE_HOME/tmp/deploy/glibc/images/beagleboard. In there you can find at least 3 interesting files:<br />
* console-image-beagleboard.tar<br />
* console-image-beagleboard.jffs2 and <br />
* uImage-beagleboard.bin<br />
<br />
The console images are representations of a full and self containing file system *including* a kernel. The uImage is a linux kernel image that is suitable to be loaded by the U-boot bootloader. The difference between the tar file and the jffs2 image is that the later is better suited to directly put on a raw partition. <br />
<br />
We are going to use the U-boot that is already provided in the NAND flash of the beagleboard as that one already support the MMC can load kernel images from a fat file system.<br />
What we will do is to format a SD-card to hold both a fat and an ext2 file system. We will put the kernel in the fat file system as U-boot failed to load the image from a ext2 file system. We will unpack the console-image under the ext2 file system.<br />
<br />
===Create partitions and format the SD-card ===<br />
We usually create two partitions, the first one has a FAT partition type and the second one a Linux file system type . We then format them and put content on them.<br />
We are not going the describe the formating other then briefly because it just if to easy to format the wrong partition. There are a few reasons for having a first partition as FAT but his is not the scope of this document ( Think of U-boot, windows , mass-storage ). Instruction for formatting the SD-card correctly can be found at: [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Boot Disk Format]<br />
<br />
Here is the output of the fdisk -l command after creating the new partitions.<br />
Disk /dev/mmcblk0: 2032 MB, 2032664576 bytes<br />
1 heads, 16 sectors/track, 248128 cylinders<br />
Units = cylinders of 16 * 512 = 8192 bytes<br />
Disk identifier: 0x2f3dffc4<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/mmcblk0p1 2 12209 97664 b W95 FAT32<br />
/dev/mmcblk0p2 12210 248128 1887352 83 Linux<br />
<br />
We now format the file systems ext2 file system under /mnt. Some system will perform a automount of the newly created file system. Try to disable this automount feature if possible (it is not easy) or use gparted <br />
mkfs.vfat /dev/mmcblk0p1<br />
mkfs.ext2 /dev/mmcblk0p2<br />
<br />
Mount the ext2 file system and unpack the archive. Do not forget the -C option.<br />
mount /dev/mmcblk0p2 /mnt<br />
tar xvf system/angstrom/deploy/glibc/images/beagleboard/console-image-beagleboard.tar -C /mnt<br />
umount /mnt<br />
<br />
Mount the fat file system and copy the kernel image to there.<br />
mount /dev/mmcblk0p1 /mnt<br />
cp system/angstrom/deploy/glibc/images/beagleboard/uImage-beagleboard.bin /mnt/uImage<br />
umount /mnt<br />
<br />
== Booting ==<br />
We can put the SD-card in the beagleboard and wait for the U-boot prompt. The kernel we compiled only gave serial output if we first ran the coninfo command we therefore type coninfo and ask U-Boot to initialise<br />
the mmc stack. After that we set the kernel command line telling what the console is and where our root file system is located. We then load the image from the fat file system into memory and boot the kernel<br />
<br />
coninfo<br />
mmcinit<br />
setenv bootargs console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1<br />
fatload mmc 0:1 0x80000000 uImage<br />
bootm<br />
<br />
===One very important note:=== <br />
<br />
It's important to have an X-Loader on your Beagleboard that uses the uBoot on the SD Card that goes with the Angstrom uImage. The B5 Beagleboards do not appear to come with such an X-Loader / U-Boot combination (i.e. the B5 standard uBoot will lead to problems with the sound driver and other things, but will not tell you that it's creating a problem).<br />
<br />
The fix is to load a new X-Loader which will in turn automatically load the uBoot from the SD card, which again in turn will load the uImage properly.<br />
<br />
So you likely will have to upgrade the X-Loader. Here's what to do:<br />
<br />
* Make an SD Card with the [http://www.angstrom-distribution.org/demo/beagleboard Angstrom Demo files]. See the [http://code.google.com/p/beagleboard/wiki/LinuxBootDiskFormat Beagleboard Wiki Page] for more info on making the SD Card.<br />
* Put the SD Card in the Beagle, and boot up to the U-Boot Prompt.<br />
* Do the first six instructions in the [http://code.google.com/p/beagleboard/wiki/BeagleNANDFlashing Flashing Commands with U-Boot] section. <br />
* Reboot the Beagle to see that the new X-Loader is properly loaded.<br />
<br />
This will update the X-Loader to a newer version that will automatically load uBoot from the SD card, and then load uImage from the SD card, rather than always using the uBoot in the Beagleboard NAND.<br />
<br />
<br />
<br />
== Using the OpenEmbedded Environment ==<br />
<br />
If you have not used bitbake / OpenEmbedded before, a helpful example for creating packages that can be installed on a beagle linux install (such as the one created above) can be found at [http://www.gumstix.net/Software/view/Build-system-overview/Hello-world-tutorial/111.html Hello World Tutorial for Gumstix].</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8442Debugging The Linux Kernel Using Gdb2008-12-08T07:18:15Z<p>Keesj: /* Debugging the linux kernel using gdb */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. This technique is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8440Debugging The Linux Kernel Using Gdb2008-12-07T12:43:26Z<p>Keesj: /* Debugging the kernel */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is because we operate on the hardware , cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the vmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8439Debugging The Linux Kernel Using Gdb2008-12-06T10:16:07Z<p>Keesj: /* Debugging the linux kernel using gdb */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== Requirements ==<br />
GDB:<br />
<br />
You need to get yourself a GDB that is capable of understanding you target architecture. Often this come with you cross-compiler but if you have do compile it yourself you need to understand the difference between --target and --host configure options. GDB will be running on host(read x86) and will be able to understand target( read armv6). with that you might also want to have the gdbserver that can serve as stub for you userland debugging.<br />
<br />
OpenOCD:<br />
<br />
TODO..<br />
<br />
A JTAG Dongle:<br />
<br />
TODO...<br />
<br />
<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is becasue as we operate on the hardware cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the zmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8438Debugging The Linux Kernel Using Gdb2008-12-06T09:43:21Z<p>Keesj: /* vmlinuz v.s zImage */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Debugging the kernel ===<br />
<br />
The JTAG based debugging method described here is not intrusive. This means that besides debugging symbols you don't<br />
need to modify the kernel in any way. This is becasue as we operate on the hardware cpu core level. Overall this means that you can follow your normal development method. You can let your bootstrap and bootloader do their work and for example start debugging a running kernel. If your gdb-aware debugger is running it can be a simple as loading the zmlinuz and connecting to the remote target<br />
<br />
load vmlinuz<br />
target remote :3333<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8318Debugging The Linux Kernel Using Gdb2008-11-28T13:15:21Z<p>Keesj: /* Determining the module load address */</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
<br />
set $current = modules.next <br />
<br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
<br />
set $container_offset = ((int)&((struct module *)0).list) <br />
<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8317Debugging The Linux Kernel Using Gdb2008-11-28T13:14:10Z<p>Keesj: added a "gdb" lsmod implementation</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is harder.<br />
<br />
==Determining the module load address ==<br />
gdb itself does not have knowledge about kernel modules and when debugging<br />
a kernel module. We will need to help gdb a little. One problem with modules<br />
is that it is not possible to determine where in the memory a module<br />
will be loaded before is actually is loaded so only once is it loaded we need<br />
to determine the address in memory it is loaded and tell gdb about it.<br />
There are many ways of determining this information. I will list 3 ways<br />
<br />
lsmod<br />
<br />
cat /sys/module/mydriver/sections/.text<br />
<br />
#gdb implementation of the linux lsmod<br />
define lsmod<br />
# The Linux kernel contains a generic double linked list implementation.<br />
# The "modules struct" is such a linked list and it contains information about modules.<br />
set $current = modules.next <br />
#The list implementation is done by adding a list_head struct to a container<br />
#containing the data that is to be "listed". If one know the offset in bytes<br />
#between the start of the struct and the "list_head" a simple formular can <br />
#be defined to determine the "content" of the list item. This value<br />
#is dependent on alignment and storage sized of the data in the struct<br />
#and is determined here for the struct module..<br />
set $container_offset = ((int)&((struct module *)0).list)<br />
#Iterate over the list printing modules information<br />
while($current != modules.prev)<br />
printf "%s 0x%08x\n", \<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->name ,\<br />
((struct module *) (((char*) ($current)) - $container_offset ) )->module_core<br />
set $current = $current.next <br />
end<br />
end<br />
<br />
<br />
==loading the files ==<br />
<br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8294Debugging The Linux Kernel Using Gdb2008-11-26T19:32:52Z<p>Keesj: added ovewview image</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
[[Image:Kernel_gdb_debugging_component_overvierw_small.png]]<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=File:Kernel_gdb_debugging_component_overvierw_small.png&diff=8293File:Kernel gdb debugging component overvierw small.png2008-11-26T19:30:28Z<p>Keesj: </p>
<hr />
<div></div>Keesjhttps://elinux.org/index.php?title=File:Kernel_gdb_debugging_component_overvierw.png&diff=8292File:Kernel gdb debugging component overvierw.png2008-11-26T19:25:00Z<p>Keesj: Overview of the kernel gdb debugging setup</p>
<hr />
<div>Overview of the kernel gdb debugging setup</div>Keesjhttps://elinux.org/index.php?title=File:Kernel_gdb_debugging_component_overvierw.svg&diff=8291File:Kernel gdb debugging component overvierw.svg2008-11-26T19:23:33Z<p>Keesj: </p>
<hr />
<div></div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8289Debugging The Linux Kernel Using Gdb2008-11-26T18:49:59Z<p>Keesj: Added linkx to the Kernel debugging tips and gdb page</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function this is well described in [[Kernel Debugging Tips]] . Using printk is a relatively simple, effective and cheap way to find problems. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. The [[GDB]] page describes some basic gdb command and also gives good links to documentation. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8287Debugging The Linux Kernel Using Gdb2008-11-26T14:12:55Z<p>Keesj: User talk:Keesj moved to DebuggingTheLinuxKernelUsingGdb: Moving the page to a more official place.</p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8286Debugging The Linux Kernel Using Gdb2008-11-26T14:10:27Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernel using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8271Debugging The Linux Kernel Using Gdb2008-11-25T20:18:53Z<p>Keesj: /* The basics */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
<br />
To start debugging are kernel you will need to configure the kernel to have debug symbols. Once this is done<br />
you can do your normal kernel development. When needed you can "hook-up" your debugger<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8270Debugging The Linux Kernel Using Gdb2008-11-25T20:15:07Z<p>Keesj: /* Debugging the linux kernels using gdb */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation. OpenOCD is pretty usable on the targets we tested arm11 and arm9<br />
<br />
== The basics ==<br />
<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8267Debugging The Linux Kernel Using Gdb2008-11-25T19:31:28Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
== The basics ==<br />
<br />
Start debugging a running kernel.<br />
<br />
- start openocd<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8266Debugging The Linux Kernel Using Gdb2008-11-25T19:29:53Z<p>Keesj: /* Debugging a kernel module (.o and .ko ) */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===<br />
Debugging a kernel module is not much harder. <br />
<br />
add-symbol-file drivers/mydrivers/mydriver.o 0xbf098000<br />
note that we use the .o file and not the .ko one. the address at the end is currenly gotten from running<br />
cat /sys/module/mydriver/sections/.text</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8265Debugging The Linux Kernel Using Gdb2008-11-25T19:26:14Z<p>Keesj: /* Getting the kernel log buffer */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
Sometimes the kernel will panic before the serial is up and running. in such situations is it *VERY* handy to be able to dump the kernel log buffer.<br />
this can be done by looking at the content of the __log_buf in the kernel. in gdb this can be done by issuing <br />
<br />
p (char*) &__log_buf[log_start]<br />
<br />
There must be a simple way of printing the memory area between log_start and log_end.<br />
<br />
The problem is that gdb stops after the first line. currently we use this routine that copied from wchar.gdb until something "normal" came out.<br />
we defined dmesg it like this:<br />
<br />
define dmesg<br />
set $__log_buf = $arg0<br />
set $log_start = $arg1<br />
set $log_end = $arg2<br />
set $x = $log_start<br />
echo "<br />
while ($x < $log_end)<br />
set $c = (char)(($__log_buf)[$x++])<br />
printf "%c" , $c<br />
end<br />
echo "\n<br />
end<br />
document dmesg<br />
dmesg __log_buf log_start log_end<br />
Print the content of the kernel message buffer<br />
end<br />
<br />
and call it like this:<br />
dmesg __log_buf log_start log_end<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8264Debugging The Linux Kernel Using Gdb2008-11-25T19:12:36Z<p>Keesj: /* Loading a kernel in memory */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels<br />
onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel<br />
and reset your board using the jtag reset signal. Your bootloader will initialize your board and the execution will stop at the start of the kernel.<br />
after that you can load a kernel into memory and run it.<br />
<br />
execute the following:<br />
<br />
(gdb) file vmlinux<br />
(gdb) target remote :3333<br />
(gdb) break __init_begin<br />
(gdb) cont<br />
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..<br />
Breakpoint 1, 0xc0008000 in stext ()<br />
(gdb) load vmlinux<br />
Loading section .text.head, size 0x240 lma 0xc0008000<br />
Loading section .init, size 0xe4dc0 lma 0xc0008240<br />
Loading section .text, size 0x219558 lma 0xc00ed000<br />
Loading section .text.init, size 0x7c lma 0xc0306558<br />
Loading section __ksymtab, size 0x4138 lma 0xc0307000<br />
Loading section __ksymtab_gpl, size 0x1150 lma 0xc030b138<br />
Loading section __kcrctab, size 0x209c lma 0xc030c288<br />
Loading section __kcrctab_gpl, size 0x8a8 lma 0xc030e324<br />
Loading section __ksymtab_strings, size 0xc040 lma 0xc030ebcc<br />
Loading section __param, size 0x2e4 lma 0xc031ac0c<br />
Loading section .data, size 0x1e76c lma 0xc031c000<br />
Start address 0xc0008000, load size 3345456<br />
Transfer rate: 64 KB/sec, 15632 bytes/write.<br />
(gdb) cont<br />
<br />
This will boot your kernel that was loaded into memory via jtag<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8263Debugging The Linux Kernel Using Gdb2008-11-25T18:50:16Z<p>Keesj: /* vmlinuz zImage and CO */</p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
=== vmlinuz v.s zImage ===<br />
When you want to debug the kernel you need a little understanding of how the kernel is composed.<br />
Most important is the difference between your vmlinux and the zImage. What you need to understand at this point<br />
is that the zImage is a container. This container gets loaded by a bootloader and that execution is handed over to the zImage. <br />
This zImage unpacks the kernel to the same memory location and starts executing the kernel.(explain that vmlinux does not have to be the real kernel as it is possible to debug a "stripped" kernel using a non stripped vmlinux). overall if we look at a compiled kernel we will see that vmlinux is located at the root of the kernel tree whiles the zImage is located under arch/arm/boot<br />
<br />
vmlinux<br />
arch/arm/boot<br />
`-- zImage<br />
<br />
vmlinux is what we will be using during debugging of the linux kernel.<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8262Debugging The Linux Kernel Using Gdb2008-11-25T17:34:39Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using JTAG and when using qemu system emulation. As the second option does not require any hardware you could go on and try it right away!<br />
<br />
The open source jtag debugging world is not that big. One project stands out in terms of debugging capabilities is OpenOCD and this is the tool used in this documentation.<br />
<br />
=== vmlinuz zImage and CO ===<br />
<br />
=== Loading a kernel in memory ===<br />
<br />
=== Getting the kernel log buffer ===<br />
<br />
=== Debugging a kernel module (.o and .ko ) ===</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8260Debugging The Linux Kernel Using Gdb2008-11-25T14:29:14Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux grown techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy.<br />
<br />
Most of the examples here will work in two (open source) situations. when using jtag and when using qemu system emulation.<br />
As the second option does not require any hardware you could go on and try it right away!</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8259Debugging The Linux Kernel Using Gdb2008-11-25T13:51:30Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux based techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging. Overall starting using gdb to do kernel debugging is relatively easy <br />
<br />
<br />
<br />
jtag/qemu<br />
<br />
and work most of the time. One reason for using these ancient techniques this can probably be found in the roots of<br />
the Linux kernel (i386) and the tools available to debug those.On the Embedded side<br />
we are better served with hardware assisted tools to debug software.</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8258Debugging The Linux Kernel Using Gdb2008-11-25T13:16:30Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. Using printk it as it is relatively simple and effective and cheap technique to use. There are many other linux based techniques that take the debugging and profiling approach to a higher level. On this page we will discuss using the gnu debugger to do kernel debugging.<br />
<br />
<br />
<br />
jtag/qemu<br />
<br />
and work most of the time. One reason for using these ancient techniques this can probably be found in the roots of<br />
the Linux kernel (i386) and the tools available to debug those.On the Embedded side<br />
we are better served with hardware assisted tools to debug software.</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8257Debugging The Linux Kernel Using Gdb2008-11-25T10:56:24Z<p>Keesj: </p>
<hr />
<div>= Debugging the linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. People use printk it as it is relatively simple and effective and cheap technique to use.<br />
<br />
jtag/qemu<br />
<br />
and work most of the time. One reason for using these ancient techniques this can probably be found in the roots of<br />
the Linux kernel (i386) and the tools available to debug those.On the Embedded side<br />
we are better served with hardware assisted tools to debug software.</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8256Debugging The Linux Kernel Using Gdb2008-11-25T10:48:45Z<p>Keesj: </p>
<hr />
<div>= Debugging arm linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done by adding print statements to code by using the famous printk function. People use printk it as it is relatively simple and effective technique to use.<br />
<br />
and work most of the time. One reason for using these ancient techniques this can probably be found in the roots of<br />
the Linux kernel (i386) and the tools available to debug those.On the Embedded side<br />
we are better served with hardware assisted tools to debug software.</div>Keesjhttps://elinux.org/index.php?title=Debugging_The_Linux_Kernel_Using_Gdb&diff=8255Debugging The Linux Kernel Using Gdb2008-11-25T10:34:30Z<p>Keesj: </p>
<hr />
<div>= Debugging arm linux kernels using gdb =<br />
<br />
The majority of day to day kernel debugging is done using the famous printk and<br />
other related techniques. One reason for this can probably be found in the roots of<br />
the Linux kernel (i386) and the tools available to debug those. on the Embedded side<br />
we are better served with hardware assisted tools to debug software.</div>Keesj