README.hardware: update installation instructions for beagleboard

o Add C4 specific instructions
o Replace poky with core
o Correct a kernel version typo
o Clarify some language to avoid confusion encountered during testing

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Zhao Yi <yi.zhao@windriver.com>
Cc: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Jeff Osier-mixon <jeffrey.osier-mixon@intel.com>
Cc: Koen Kooi <koen@dominion.thruhere.net>

README.hardware

@@ -1,429 +1,66 @@
-                     Poky Hardware Reference Guide
-                     =============================
+                          Poky Hardware README
+                          ====================
 
 This file gives details about using Poky with different hardware reference
-boards and consumer devices. A full list of target machines can be found by 
-looking in the meta/conf/machine/ directory. If in doubt about using Poky with 
-your hardware, consult the documentation for your board/device. To discuss 
-support for further hardware reference boards/devices please contact OpenedHand.
+boards and consumer devices. A full list of target machines can be found by
+looking in the meta/conf/machine/ directory. If in doubt about using Poky with
+your hardware, consult the documentation for your board/device.
 
-QEMU Emulation Images (qemuarm and qemux86)
-===========================================
+Support for additional devices is normally added by creating BSP layers - for
+more information please see the Yocto Board Support Package (BSP) Developer's
+Guide - documentation source is in documentation/bspguide or download the PDF
+from:
+
+   http://yoctoproject.org/community/documentation
+
+Support for machines other than QEMU may be moved out to separate BSP layers in
+future versions.
+
+
+QEMU Emulation Targets
+======================
 
 To simplify development Poky supports building images to work with the QEMU
-emulator in system emulation mode. Two architectures are currently supported,
-ARM (via qemuarm) and x86 (via qemux86). Use of the QEMU images is covered
-in the Poky Handbook.
+emulator in system emulation mode. Several architectures are currently
+supported:
+
+  * ARM (qemuarm)
+  * x86 (qemux86)
+  * x86-64 (qemux86-64)
+  * PowerPC (qemuppc)
+  * MIPS (qemumips)
+
+Use of the QEMU images is covered in the Poky Reference Manual. The Poky
+MACHINE setting corresponding to the target is given in brackets.
+
 
 Hardware Reference Boards
 =========================
 
-The following boards are supported by Poky:
+The following boards are supported by Poky's core layer:
 
-  * Compulab CM-X270 (cm-x270)
-  * Compulab EM-X270 (em-x270)
-  * FreeScale iMX31ADS (mx31ads)
-  * Marvell PXA3xx Zylonite (zylonite)
-  * Logic iMX31 Lite Kit (mx31litekit)
-  * Phytec phyCORE-iMX31 (mx31phy)
   * Texas Instruments Beagleboard (beagleboard)
+  * Freescale MPC8315E-RDB (mpc8315e-rdb)
+  * Ubiquiti Networks RouterStation Pro (routerstationpro)
 
-For more information see board's section below. The Poky MACHINE setting
+For more information see the board's section below. The Poky MACHINE setting
 corresponding to the board is given in brackets.
 
+
 Consumer Devices
 ================
 
-The following consumer devices are supported by Poky:
+The following consumer devices are supported by Poky's core layer:
 
-  * FIC Neo1973 GTA01 smartphone (fic-gta01)
-  * HTC Universal (htcuniversal)
-  * Nokia 770/N800/N810 Internet Tablets (nokia770 and nokia800)
-  * Sharp Zaurus SL-C7x0 series (c7x0)
-  * Sharp Zaurus SL-C1000 (akita)
-  * Sharp Zaurus SL-C3x00 series (spitz)
+  * Intel Atom based PCs and devices (atom-pc)
 
-For more information see board's section below. The Poky MACHINE setting
-corresponding to the board is given in brackets.
+For more information see the device's section below. The Poky MACHINE setting
+corresponding to the device is given in brackets.
 
 
-                          Hardware Reference Boards
-                          =========================
 
-Compulab CM-X270 (cm-x270)
-==========================
-
-The bootloader on this board doesn't support writing jffs2 images directly to 
-NAND and normally uses a proprietary kernel flash driver. To allow the use of
-jffs2 images, a two stage updating procedure is needed. Firstly, an initramfs
-is booted which contains mtd utilities and this is then used to write the main
-filesystem. 
-
-It is assumed the board is connected to a network where a TFTP server is 
-available and that a serial terminal is available to communicate with the 
-bootloader (38400, 8N1). If a DHCP server is available the device will use it
-to obtain an IP address. If not, run:
-
-  ARMmon > setip dhcp off
-  ARMmon > setip ip 192.168.1.203
-  ARMmon > setip mask 255.255.255.0
-
-To reflash the kernel:
-
-  ARMmon > download kernel tftp zimage 192.168.1.202
-  ARMmon > flash kernel
-
-where zimage is the name of the kernel on the TFTP server and its IP address is 
-192.168.1.202. The names of the files must be all lowercase.
-
-To reflash the initrd/initramfs:
-
-  ARMmon > download ramdisk tftp diskimage 192.168.1.202
-  ARMmon > flash ramdisk
-
-where diskimage is the name of the initramfs image (a cpio.gz file).
-
-To boot the initramfs:
-
-  ARMmon > ramdisk on
-  ARMmon > bootos "console=ttyS0,38400 rdinit=/sbin/init"
-
-To reflash the main image login to the system as user "root", then run:
-
-  # ifconfig eth0 192.168.1.203
-  # tftp -g -r mainimage 192.168.1.202
-  # flash_eraseall /dev/mtd1
-  # nandwrite /dev/mtd1 mainimage
-
-which configures the network interface with the IP address 192.168.1.203,
-downloads the "mainimage" file from the TFTP server at 192.168.1.202, erases
-the flash and then writes the new image to the flash.
-
-The main image can then be booted with:
-
-  ARMmon > bootos "console=ttyS0,38400 root=/dev/mtdblock1 rootfstype=jffs2"
-
-Note that the initramfs image is built by poky in a slightly different mode to
-normal since it uses uclibc. To generate this use a command like:
-
-IMAGE_FSTYPES=cpio.gz MACHINE=cm-x270 POKYLIBC=uclibc bitbake poky-image-minimal-mtdutils
-
-
-Compulab EM-X270 (em-x270)
-==========================
-
-Fetch the "Linux - kernel and run-time image (Angstrom)" ZIP file from the
-Compulab website. Inside the images directory of this ZIP file is another ZIP
-file called 'LiveDisk.zip'. Extract this over a cleanly formatted vfat USB flash
-drive. Replace the 'em_x270.img' file with the 'updater-em-x270.ext2' file.
-
-Insert this USB disk into the supplied adapter and connect this to the
-board. Whilst holding down the the suspend button press the reset button. The
-board will now boot off the USB key and into a version of Angstrom. On the
-desktop is an icon labelled "Updater". Run this program to launch the updater
-that will flash the Poky kernel and rootfs to the board.
-
-
-FreeScale iMX31ADS (mx31ads)
-===========================
-
-The correct serial port is the top-most female connector to the right of the
-ethernet socket.
-
-For uploading data to RedBoot we are going to use tftp. In this example we
-assume that the tftpserver is on 192.168.9.1 and the board is on192.168.9.2. 
-
-To set the IP address, run:
-
-  ip_address -l 192.168.9.2/24 -h 192.168.9.1
-
-To download a kernel called "zimage" from the TFTP server, run:
-
-  load -r -b 0x100000 zimage
-
-To write the kernel to flash run:
-
-  fis create kernel
-
-To download a rootfs jffs2 image "rootfs" from the TFTP server, run:
-
-  load -r -b 0x100000 rootfs
-
-To write the root filesystem  to flash run:
-
-  fis create root
-
-To load and boot a kernel and rootfs from flash:
-
-  fis load kernel
-  exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rootfstype=jffs2 init=linuxrc ip=none"
-
-To load and boot a kernel from a TFTP server with the rootfs over NFS:
-
-  load -r -b 0x100000 zimage
-  exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=192.168.9.1:/mnt/nfsmx31 rw ip=192.168.9.2::192.168.9.1:255.255.255.0"
-
-The instructions above are for using the (default) NOR flash on the board,
-there is also 128M of NAND flash. It is possible to install Poky to the NAND 
-flash which gives more space for the rootfs and instructions for using this are
-given below. To switch to the NAND flash:
-
-  factive NAND
-
-This will then restart RedBoot using the NAND rather than the NOR. If you
-have not used the NAND before then it is unlikely that there will be a
-partition table yet. You can get the list of partitions with 'fis list'.
-
-If this shows no partitions then you can create them with:
-
-  fis init
-
-The output of 'fis list' should now show:
-
-Name              FLASH addr  Mem addr    Length      Entry point
-RedBoot           0xE0000000  0xE0000000  0x00040000  0x00000000
-FIS directory     0xE7FF4000  0xE7FF4000  0x00003000  0x00000000
-RedBoot config    0xE7FF7000  0xE7FF7000  0x00001000  0x00000000
-
-Partitions for the kernel and rootfs need to be created:
-
-fis create -l 0x1A0000 -e 0x00100000 kernel
-fis create -l 0x5000000 -e 0x00100000 root
-
-You may now use the instructions above for flashing. However it is important
-to note that the erase block size for the NAND is different to the NOR so the
-JFFS erase size will need to be changed to 0x4000. Stardard images are built
-for NOR and you will need to build custom images for NAND.
-
-You will also need to update the kernel command line to use the correct root
-filesystem. This should be '/dev/mtdblock7' if you adhere to the partitioning
-scheme shown above. If this fails then you can doublecheck against the output
-from the kernel when it evaluates the available mtd partitions.
-
-
-Marvell PXA3xx Zylonite (zylonite)
-==================================
-
-These instructions assume the Zylonite is connected to a machine running a TFTP 
-server at address 192.168.123.5 and that a serial link (38400 8N1) is available 
-to access the blob bootloader. The kernel is on the TFTP server as 
-"zylonite-kernel" and the root filesystem jffs2 file is "zylonite-rootfs" and 
-the images are to be saved in NAND flash.
-
-The following commands setup blob:
-
-  blob> setip client 192.168.123.4
-  blob> setip server 192.168.123.5
-
-To flash the kernel:
-
-  blob> tftp zylonite-kernel
-  blob> nandwrite -j 0x80800000 0x60000 0x200000
-
-To flash the rootfs:
-
-  blob> tftp zylonite-rootfs
-  blob> nanderase -j 0x260000 0x5000000
-  blob> nandwrite -j 0x80800000 0x260000 <length>
-
-(where <length> is the rootfs size which will be printed by the tftp step)
-
-To boot the board:
-
-  blob> nkernel
-  blob> boot
-
-
-Logic iMX31 Lite Kit (mx31litekit)
-===============================
-
-The easiest method to boot this board is to take an MMC/SD card and format 
-the first partition as ext2, then extract the poky image onto this as root. 
-Assuming the board is network connected, a TFTP server is available at 
-192.168.1.33 and a serial terminal is available (115200 8N1), the following 
-commands will boot a kernel called "mx31kern" from the TFTP server:
-
-  losh> ifconfig sm0 192.168.1.203 255.255.255.0 192.168.1.33
-  losh> load raw 0x80100000 0x200000 /tftp/192.168.1.33:mx31kern
-  losh> exec 0x80100000 - 
-
-
-Phytec phyCORE-iMX31 (mx31phy)
-==============================
-
-Support for this board is currently being developed. Experimental jffs2 
-images and a suitable kernel are available and are known to work with the
-board.
-
-
-                             Consumer Devices
-                             ================
-
-FIC Neo1973 GTA01 smartphone (fic-gta01)
-========================================
-
-To install Poky on a GTA01 smartphone you will need "dfu-util" tool
-which you can build with "bitbake dfu-util-native" command.
-
-Flashing requires these steps:
-
-  1. Power down the device.
-  2. Connect the device to the host machine via USB.
-  3. Hold AUX key and press Power key. There should be a bootmenu
-     on screen.
-  4. Run "dfu-util -l" to check if the phone is visible on the USB bus. 
-     The output should look like this:
-
-     dfu-util - (C) 2007 by OpenMoko Inc.
-     This program is Free Software and has ABSOLUTELY NO WARRANTY
-
-     Found Runtime: [0x1457:0x5119] devnum=19, cfg=0, intf=2, alt=0, name="USB Device Firmware Upgrade"
-
-  5. Flash the kernel with "dfu-util -a kernel -D uImage-2.6.21.6-moko11-r2-fic-gta01.bin"
-  6. Flash rootfs with "dfu-util -a rootfs -D <image>", where <image> is the
-     jffs2 image file to use as the root filesystem 
-     (e.g. ./tmp/deploy/images/poky-image-sato-fic-gta01.jffs2) 
-
-
-HTC Universal (htcuniversal)
-============================
-
-Note: HTC Universal support is highly experimental.
-
-On the HTC Universal, entirely replacing the Windows installation is not 
-supported, instead Poky is booted from an MMC/SD card from Windows. Once Poky
-has booted, Windows is no longer in memory or active but when power is removed,
-the user will be returned to windows and will need to return to Linux from 
-there.
-
-Once an MMC/SD card is available it is suggested its split into two partitions,
-one for a program called HaRET which lets you boot Linux from within Windows
-and the second for the rootfs. The HaRET partition should be the first partition
-on the card and be vfat formatted. It doesn't need to be large, just enough for
-HaRET and a kernel (say 5MB max). The rootfs should be ext2 and is usually the 
-second partition. The first partition should be vfat so Windows recognises it 
-as if it doesn't, it has been known to reformat cards.
-
-On the first partition you need three files:
-
-  * a HaRET binary (version 0.5.1 works well and a working version 
-    should be part of the last Poky release)
-  * a kernel renamed to "zImage"
-  * a default.txt which contains:
-
-set kernel "zImage"
-set mtype "855"
-set cmdline "root=/dev/mmcblk0p2 rw console=ttyS0,115200n8 console=tty0 rootdelay=5 fbcon=rotate:1"
-boot2
-
-On the second parition the root file system is extracted as root. A different
-partition layout or other kernel options can be changed in the default.txt file.
-
-When inserted into the device, Windows should see the card and let you browse
-its contents using File Explorer. Running the HaRET binary will present a dialog
-box (maybe after messages warning about running unsigned binaries) where you 
-select OK and you should then see Poky boot. Kernel messages can be seen by 
-adding psplash=false to the kernel commandline.
-
-
-Nokia 770/N800/N810 Internet Tablets (nokia770 and nokia800)
-============================================================
-
-Note: Nokia tablet support is highly experimental.
-
-The Nokia internet tablet devices are OMAP based tablet formfactor devices 
-with large screens (800x480), wifi and touchscreen.
-
-To flash images to these devices you need the "flasher" utility which can be 
-downloaded from the http://tablets-dev.nokia.com/d3.php?f=flasher-3.0. This 
-utility needs to be run as root and the usb filesystem needs to be mounted 
-although most distributions will have done this for you. Once you have this 
-follow these steps:
-
-  1. Power down the device.
-  2. Connect the device to the host machine via USB 
-     (connecting power to the device doesn't hurt either).
-  3. Run "flasher -i"
-  4. Power on the device.
-  5. The program should give an indication it's found 
-     a tablet device. If not, recheck the cables, make sure you're 
-     root and usbfs/usbdevfs is mounted.
-  6. Run "flasher -r <image> -k <kernel> -f", where <image> is the
-     jffs2 image file to use as the root filesystem 
-     (e.g. ./tmp/deploy/images/poky-image-sato-nokia800.jffs2) 
-     and <kernel> is the kernel to use 
-     (e.g. ./tmp/deploy/images/zImage-nokia800.bin).
-  7. Run "flasher -R" to reboot the device.
-  8. The device should boot into Poky.
-
-The nokia800 images and kernel will run on both the N800 and N810.
-
-
-Sharp Zaurus SL-C7x0 series (c7x0)
-==================================
-
-The Sharp Zaurus c7x0 series (SL-C700, SL-C750, SL-C760, SL-C860, SL-7500)
-are PXA25x based handheld PDAs with VGA screens. To install Poky images on
-these devices follow these steps:
-
-  1. Obtain an SD/MMC or CF card with a vfat or ext2 filesystem.
-  2. Copy a jffs2 image file (e.g. poky-image-sato-c7x0.jffs2) onto the
-     card as "initrd.bin":
-
-     $ cp ./tmp/deploy/images/poky-image-sato-c7x0.jffs2 /path/to/my-cf-card/initrd.bin
-
-  3. Copy an Linux kernel file (zImage-c7x0.bin) onto the card as 
-     "zImage.bin":
-
-     $ cp ./tmp/deploy/images/zImage-c7x0.bin /path/to/my-cf-card/zImage.bin
-
-  4. Copy an updater script (updater.sh.c7x0) onto the card
-     as "updater.sh":
-
-     $ cp ./tmp/deploy/images/updater.sh.c7x0 /path/to/my-cf-card/updater.sh
-
-  5. Power down the Zaurus.
-  6. Hold "OK" key and power on the device. An update menu should appear 
-     (in Japanese).
-  7. Choose "Update" (item 4).
-  8. The next screen will ask for the source, choose the appropriate 
-     card (CF or SD).
-  9. Make sure AC power is connected.
-  10. The next screen asks for confirmation, choose "Yes" (the left button).
-  11. The update process will start, flash the files on the card onto 
-      the device and the device will then reboot into Poky.
-
-
-Sharp Zaurus SL-C1000 (akita)
-=============================
-
-The Sharp Zaurus SL-C1000 is a PXA270 based device otherwise similar to the 
-c7x0. To install Poky images on this device follow the instructions for 
-the c7x0 but replace "c7x0" with "akita" where appropriate.
-
-
-Sharp Zaurus SL-C3x00 series (spitz)
-====================================
-
-The Sharp Zaurus SL-C3x00 devices are PXA270 based devices similar
-to akita but with an internal microdrive. The installation procedure 
-assumes a standard microdrive based device where the root (first) 
-partition has been enlarged to fit the image (at least 100MB, 
-400MB for the SDK).
-
-The procedure is the same as for the c7x0 and akita models with the 
-following differences:
-
- 1. Instead of a jffs2 image you need to copy a compressed tarball of the 
-    root fileystem (e.g. poky-image-sato-spitz.tar.gz) onto the
-    card as "hdimage1.tgz":
-
-    $ cp ./tmp/deploy/images/poky-image-sato-spitz.tar.gz /path/to/my-cf-card/hdimage1.tgz
-
- 2. You additionally need to copy a special tar utility  (gnu-tar) onto 
-    the card as "gnu-tar":
-
-    $ cp ./tmp/deploy/images/gnu-tar /path/to/my-cf-card/gnu-tar
+                      Specific Hardware Documentation
+                      ===============================
 
 
 Intel Atom based PCs and devices (atom-pc)
@@ -512,15 +149,26 @@ The Beagleboard is an ARM Cortex-A8 development board with USB, DVI-D, S-Video,
 faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
 the NAND flash. The beagleboard MACHINE is tested on the following platforms:
 
-  o Beagleboard xM
+  o Beagleboard C4
+  o Beagleboard xM Rev A
 
-TODO: need someone with a Beagleboard C4 to verify these instructions.
+The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
+these instructions assume you have erased the NAND on the C4 so its boot
+behavior matches that of the xM. To do this, issue the following commands from
+the u-boot prompt (note that the unlock may be unecessary depending on the
+version of u-boot installed on your board and only one of the erase commands
+will succeed):
 
-Due to the lack of NAND on the xM, the install and boot process varies a bit
-between boards.  The C4 can run the x-loader and u-boot binaries from NAND or
-the SD, while the xM can only run them from the SD. The following instructions
-apply to both the C4 and the xM, but the C4 can skip step 2 (as noted below),
-and may require modification of the NAND environment.
+    # nand unlock
+    # nand erase
+    # nand erase.chip
+
+To further tailor these instructions for your board, please refer to the
+documentation at http://www.beagleboard.org.
+
+From a Linux system with access to the image files perform the following steps
+as root, replacing mmcblk0* with the SD card device on your machine (such as sdc
+if used via a usb card reader):
 
   1. Partition and format an SD card:
      # fdisk -lu /dev/mmcblk0
@@ -536,14 +184,14 @@ and may require modification of the NAND environment.
      # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
      # mke2fs -j -L "root" /dev/mmcblk0p2
 
-   The following assumes the SD card partition 1 and 2 are mounted at
-   /media/boot and /media/root respectively. The files referenced here
-   are made available after the build in build/tmp/deploy/images.
+  The following assumes the SD card partition 1 and 2 are mounted at
+  /media/boot and /media/root respectively. Removing the card and reinserting
+  it will do just that on most modern Linux desktop environments.
+  
+  The files referenced below are made available after the build in
+  build/tmp/deploy/images.
 
   2. Install the boot loaders
-     This step can be omitted for the C4 as it can have the x-loader and
-     u-boot installed in NAND.
-
      # cp MLO-beagleboard /media/boot/MLO
      # cp u-boot-beagleboard.bin /media/boot/u-boot.bin
 
@@ -568,15 +216,213 @@ and may require modification of the NAND environment.
      boot
      EOF
      ) > serial-boot.cmd
-     # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Poky Minimal" -d ./serial-boot.cmd ./boot.scr
+     # mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Core Minimal" -d ./serial-boot.cmd ./boot.scr
      # cp boot.scr /media/boot
 
-   6. Unmount the SD partitions and boot the Beagleboard
+   6. Unmount the SD partitions, insert the SD card into the Beagleboard, and
+      boot the Beagleboard
 
 Note: As of the 2.6.37 linux-yocto kernel recipe, the Beagleboard uses the
       OMAP_SERIAL device (ttyO2). If you are using an older kernel, such as the
-      2.6.35 linux-yocto-stable, be sure replace ttyO2 with ttyS2 above. You
+      2.6.34 linux-yocto-stable, be sure to replace ttyO2 with ttyS2 above. You
       should also override the machine SERIAL_CONSOLE in your local.conf in
       order to setup the getty on the serial line:
 
       SERIAL_CONSOLE_beagleboard = "115200 ttyS2"
+
+
+Freescale MPC8315E-RDB (mpc8315e-rdb)
+=====================================
+
+The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and
+software development of network attached storage (NAS) and digital media server
+applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which
+includes a built-in security accelerator.
+
+Setup instructions
+------------------
+
+You will need the following:
+* nfs root setup on your workstation
+* tftp server installed on your workstation
+
+Load the kernel and boot it as follows:
+
+ 1. Get the kernel (uImage.mpc8315erdb) and dtb (mpc8315erdb.dtb) files from
+    the Poky build tmp/deploy directory, and make them available on your tftp
+    server.
+
+ 2. Set up the environment in U-Boot:
+
+ =>setenv ipaddr <board ip>
+ =>setenv serverip <tftp server ip>
+ =>setenv bootargs root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:255.255.255.0:mpc8315e:eth0:off console=ttyS0,115200
+
+ 3. Download kernel and dtb to boot kernel.
+
+ =>tftp 800000 uImage.mpc8315erdb
+ =>tftp 780000 mpc8315erdb.dtb
+ =>bootm 800000 - 780000
+
+
+Ubiquiti Networks RouterStation Pro (routerstationpro)
+======================================================
+
+The RouterStation Pro is an Atheros AR7161 MIPS-based board. Geared towards
+networking applications, it has all of the usual features as well as three
+type IIIA mini-PCI slots and an on-board 3-port 10/100/1000 Ethernet switch,
+in addition to the 10/100/1000 Ethernet WAN port which supports
+Power-over-Ethernet.
+
+Setup instructions
+------------------
+
+You will need the following:
+* A serial cable - female to female (or female to male + gender changer)
+  NOTE: cable must be straight through, *not* a null modem cable.
+* USB flash drive or hard disk that is able to be powered from the
+  board's USB port.
+* tftp server installed on your workstation
+
+NOTE: in the following instructions it is assumed that /dev/sdb corresponds
+to the USB disk when it is plugged into your workstation. If this is not the
+case in your setup then please be careful to substitute the correct device
+name in all commands where appropriate.
+
+--- Preparation ---
+
+1) Build an image (e.g. poky-image-minimal) using "routerstationpro" as the
+MACHINE
+
+2) Partition the USB drive so that primary partition 1 is type Linux (83).
+Minimum size depends on your root image size - poky-image-minimal probably
+only needs 8-16MB, other images will need more.
+
+  # fdisk /dev/sdb
+  Command (m for help): p
+
+  Disk /dev/sdb: 4011 MB, 4011491328 bytes
+  124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors
+  Units = sectors of 1 * 512 = 512 bytes
+  Sector size (logical/physical): 512 bytes / 512 bytes
+  I/O size (minimum/optimal): 512 bytes / 512 bytes
+  Disk identifier: 0x0009e87d
+
+     Device Boot      Start         End      Blocks   Id  System
+  /dev/sdb1              62     1952751      976345   83  Linux
+
+3) Format partition 1 on the USB as ext3
+
+  # mke2fs -j /dev/sdb1
+
+4) Mount partition 1 and then extract the contents of
+tmp/deploy/images/poky-image-XXXX.tar.bz2 into it (preserving permissions).
+
+  # mount /dev/sdb1 /media/sdb1
+  # cd /media/sdb1
+  # tar -xvjpf tmp/deploy/images/poky-image-XXXX.tar.bz2
+
+5) Unmount the USB drive and then plug it into the board's USB port
+
+6) Connect the board's serial port to your workstation and then start up
+your favourite serial terminal so that you will be able to interact with
+the serial console. If you don't have a favourite, picocom is suggested:
+
+  $ picocom /dev/ttyUSB0 -b 115200
+
+7) Connect the network into eth0 (the one that is NOT the 3 port switch). If
+you are using power-over-ethernet then the board will power up at this point.
+
+8) Start up the board, watch the serial console. Hit Ctrl+C to abort the
+autostart if the board is configured that way (it is by default). The
+bootloader's fconfig command can be used to disable autostart and configure
+the IP settings if you need to change them (default IP is 192.168.1.20).
+
+9) Make the kernel (tmp/deploy/images/vmlinux-routerstationpro.bin) available
+on the tftp server.
+
+10) If you are going to write the kernel to flash (optional - see "Booting a
+kernel directly" below for the alternative), remove the current kernel and
+rootfs flash partitions. You can list the partitions using the following
+bootloader command:
+
+  RedBoot> fis list
+
+You can delete the existing kernel and rootfs with these commands:
+
+  RedBoot> fis delete kernel
+  RedBoot> fis delete rootfs
+
+--- Booting a kernel directly ---
+
+1) Load the kernel using the following bootloader command:
+
+  RedBoot> load -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin
+
+You should see a message on it being successfully loaded.
+
+2) Execute the kernel:
+
+  RedBoot> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO"
+
+Note that specifying the command line with -c is important as linux-yocto does
+not provide a default command line.
+
+--- Writing a kernel to flash ---
+
+1) Go to your tftp server and gzip the kernel you want in flash. It should
+halve the size.
+
+2) Load the kernel using the following bootloader command:
+
+  RedBoot> load -r -b 0x80600000 -m tftp -h <ip of tftp server> vmlinux-routerstationpro.bin.gz
+
+This should output something similar to the following:
+
+  Raw file loaded 0x80600000-0x8087c537, assumed entry at 0x80600000
+
+Calculate the length by subtracting the first number from the second number
+and then rounding the result up to the nearest 0x1000.
+
+3) Using the length calculated above, create a flash partition for the kernel:
+
+  RedBoot> fis create -b 0x80600000 -l 0x240000 kernel
+
+(change 0x240000 to your rounded length -- change "kernel" to whatever
+you want to name your kernel)
+
+--- Booting a kernel from flash ---
+
+To boot the flashed kernel perform the following steps.
+
+1) At the bootloader prompt, load the kernel:
+
+  RedBoot> fis load -d -e kernel
+
+(Change the name "kernel" above if you chose something different earlier)
+
+(-e means 'elf', -d 'decompress')
+
+2) Execute the kernel using the exec command as above.
+
+--- Automating the boot process ---
+
+After writing the kernel to flash and testing the load and exec commands
+manually, you can automate the boot process with a boot script.
+
+1) RedBoot> fconfig
+   (Answer the questions not specified here as they pertain to your environment)
+2) Run script at boot: true
+  Boot script: 
+  .. fis load -d -e kernel
+  .. exec
+  Enter script, terminate with empty line
+  >> fis load -d -e kernel
+  >> exec -c "console=ttyS0,115200 root=/dev/sda1 rw rootdelay=2 board=UBNT-RSPRO"
+  >> 
+3) Answer the remaining questions and write the changes to flash:
+  Update RedBoot non-volatile configuration - continue (y/n)? y
+  ... Erase from 0xbfff0000-0xc0000000: .
+  ... Program from 0x87ff0000-0x88000000 at 0xbfff0000: .
+4) Power cycle the board.
+

bitbake/bin/bitbake-layers

@@ -1,4 +1,10 @@
-#!/usr/bin/env python2.6
+#!/usr/bin/env python
+
+# This script has subcommands which operate against your bitbake layers, either
+# displaying useful information, or acting against them.
+# Currently, it only provides a show_appends command, which shows you what
+# bbappends are in effect, and warns you if you have appends which are not being
+# utilized.
 
 import cmd
 import logging
@@ -13,6 +19,7 @@ import bb.cache
 import bb.cooker
 import bb.providers
 from bb.cooker import state
+from bb.server import none
 
 
 logger = logging.getLogger('BitBake')
@@ -38,14 +45,11 @@ class Commands(cmd.Cmd):
         self.returncode = 0
         self.config = Config(parse_only=True)
         self.cooker = bb.cooker.BBCooker(self.config,
-                                         self.register_idle_function)
+                                         bb.server.none)
         self.config_data = self.cooker.configuration.data
         bb.providers.logger.setLevel(logging.ERROR)
         self.prepare_cooker()
 
-    def register_idle_function(self, function, data):
-        pass
-
     def prepare_cooker(self):
         sys.stderr.write("Parsing recipes..")
         logger.setLevel(logging.ERROR)

bitbake/bin/bitdoc

@@ -497,7 +497,7 @@ def main():
         doc.insert_doc_item(doc_ins)
 
     # let us create the HTML now
-    bb.mkdirhier(output_dir)
+    bb.utils.mkdirhier(output_dir)
     os.chdir(output_dir)
 
     # Let us create the sites now. We do it in the following order

bitbake/doc/manual/Makefile

@@ -45,7 +45,7 @@ endif
 	$(call command,xsltproc --stringparam base.dir $@/ $(if $(htmlcssfile),--stringparam html.stylesheet $(htmlcssfile)) $(htmlxsl) $(manual),XSLTPROC $@ $(manual))
 
 $(xmltotypes): $(manual)
-	$(call command,xmlto --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))
+	$(call command,xmlto --with-dblatex --extensions -o $(topdir)/$@ $@ $(manual),XMLTO $@ $(manual))
 
 clean:
 	rm -rf $(cleanfiles)

bitbake/doc/manual/usermanual.xml

@@ -97,7 +97,7 @@ share common metadata between many packages.</para></listitem>
                 <title>Setting a default value (??=)</title>
                 <para><screen><varname>A</varname> ??= "somevalue"</screen></para>
                 <para><screen><varname>A</varname> ??= "someothervalue"</screen></para>
-                <para>If <varname>A</varname> is set before the above, it will retain that value.  If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>.  This is a lazy version of ??=, in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used.</para>
+                <para>If <varname>A</varname> is set before the above, it will retain that value.  If <varname>A</varname> is unset prior to the above, <varname>A</varname> will be set to <literal>someothervalue</literal>.  This is a lazy version of ?=, in that the assignment does not occur until the end of the parsing process, so that the last, rather than the first, ??= assignment to a given variable will be used.</para>
             </section>
             <section>
                 <title>Immediate variable expansion (:=)</title>

bitbake/lib/bb/build.py

@@ -221,7 +221,8 @@ def exec_func_shell(function, d, runfile, cwd=None):
         if logger.isEnabledFor(logging.DEBUG):
             script.write("set -x\n")
         data.emit_func(function, script, d)
-
+        if cwd:
+            script.write("cd %s\n" % cwd)
         script.write("%s\n" % function)
         os.fchmod(script.fileno(), 0775)
 
@@ -238,8 +239,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
         logfile = sys.stdout
 
     try:
-        bb.process.run(cmd, env=env, cwd=cwd, shell=False, stdin=NULL,
-                       log=logfile)
+        bb.process.run(cmd, env=env, shell=False, stdin=NULL, log=logfile)
     except bb.process.CmdError:
         logfn = d.getVar('BB_LOGFILE', True)
         raise FuncFailed(function, logfn)

bitbake/lib/bb/cache.py

@@ -43,7 +43,7 @@ except ImportError:
     logger.info("Importing cPickle failed. "
                 "Falling back to a very slow implementation.")
 
-__cache_version__ = "137"
+__cache_version__ = "138"
 
 recipe_fields = (
     'pn',
@@ -78,6 +78,8 @@ recipe_fields = (
     'summary',
     'license',
     'section',
+    'fakerootenv',
+    'fakerootdirs'
 )
 
 
@@ -172,6 +174,8 @@ class RecipeInfo(namedtuple('RecipeInfo', recipe_fields)):
             summary          = cls.getvar('SUMMARY', metadata),
             license          = cls.getvar('LICENSE', metadata),
             section          = cls.getvar('SECTION', metadata),
+            fakerootenv      = cls.getvar('FAKEROOTENV', metadata),
+            fakerootdirs     = cls.getvar('FAKEROOTDIRS', metadata),
         )
 
 
@@ -584,6 +588,8 @@ class CacheData(object):
         self.summary = {}
         self.license = {}
         self.section = {}
+        self.fakerootenv = {}
+        self.fakerootdirs = {}
 
         # Indirect Cache variables (set elsewhere)
         self.ignored_dependencies = []
@@ -647,3 +653,5 @@ class CacheData(object):
         self.summary[fn] = info.summary
         self.license[fn] = info.license
         self.section[fn] = info.section
+        self.fakerootenv[fn] = info.fakerootenv
+        self.fakerootdirs[fn] = info.fakerootdirs

bitbake/lib/bb/cooker.py

@@ -253,7 +253,9 @@ class BBCooker:
         localdata = data.createCopy(self.configuration.data)
         bb.data.update_data(localdata)
         bb.data.expandKeys(localdata)
-        taskdata = bb.taskdata.TaskData(self.configuration.abort)
+        # We set abort to False here to prevent unbuildable targets raising
+        # an exception when we're just generating data
+        taskdata = bb.taskdata.TaskData(False)
 
         runlist = []
         for k in pkgs_to_build:

bitbake/lib/bb/fetch/bzr.py

@@ -94,7 +94,7 @@ class Bzr(Fetch):
             bb.utils.remove(os.path.join(ud.pkgdir, os.path.basename(ud.pkgdir)), True)
             bzrcmd = self._buildbzrcommand(ud, d, "fetch")
             logger.debug(1, "BZR Checkout %s", loc)
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", bzrcmd)
             runfetchcmd(bzrcmd, d)

bitbake/lib/bb/fetch/cvs.py

@@ -137,7 +137,7 @@ class Cvs(Fetch):
         else:
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(pkgdir)
+            bb.utils.mkdirhier(pkgdir)
             os.chdir(pkgdir)
             logger.debug(1, "Running %s", cvscmd)
             myret = os.system(cvscmd)

bitbake/lib/bb/fetch/git.py

@@ -131,7 +131,7 @@ class Git(Fetch):
 
         # If the checkout doesn't exist and the mirror tarball does, extract it
         if not os.path.exists(ud.clonedir) and os.path.exists(repofile):
-            bb.mkdirhier(ud.clonedir)
+            bb.utils.mkdirhier(ud.clonedir)
             os.chdir(ud.clonedir)
             runfetchcmd("tar -xzf %s" % (repofile), d)
 
@@ -188,7 +188,7 @@ class Git(Fetch):
             os.chdir(coprefix)
             runfetchcmd("%s checkout -q -f %s%s" % (ud.basecmd, ud.tag, readpathspec), d)
         else:
-            bb.mkdirhier(codir)
+            bb.utils.mkdirhier(codir)
             os.chdir(ud.clonedir)
             runfetchcmd("%s read-tree %s%s" % (ud.basecmd, ud.tag, readpathspec), d)
             runfetchcmd("%s checkout-index -q -f --prefix=%s -a" % (ud.basecmd, coprefix), d)

bitbake/lib/bb/fetch/hg.py

@@ -131,7 +131,7 @@ class Hg(Fetch):
             fetchcmd = self._buildhgcommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", fetchcmd)
             runfetchcmd(fetchcmd, d)

bitbake/lib/bb/fetch/osc.py

@@ -98,7 +98,7 @@ class Osc(Fetch):
             oscfetchcmd = self._buildosccommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", oscfetchcmd)
             runfetchcmd(oscfetchcmd, d)

bitbake/lib/bb/fetch/perforce.py

@@ -154,7 +154,7 @@ class Perforce(Fetch):
 
         # create temp directory
         logger.debug(2, "Fetch: creating temporary directory")
-        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oep4.XXXXXX', localdata), localdata)
         tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, 1) or "false")
         tmpfile = tmppipe.readline().strip()

bitbake/lib/bb/fetch/repo.py

@@ -71,7 +71,7 @@ class Repo(Fetch):
         else:
             username = ""
 
-        bb.mkdirhier(os.path.join(codir, "repo"))
+        bb.utils.mkdirhier(os.path.join(codir, "repo"))
         os.chdir(os.path.join(codir, "repo"))
         if not os.path.exists(os.path.join(codir, "repo", ".repo")):
             runfetchcmd("repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d)

bitbake/lib/bb/fetch/svk.py

@@ -71,7 +71,7 @@ class Svk(Fetch):
         localdata = data.createCopy(d)
         data.update_data(localdata)
         logger.debug(2, "Fetch: creating temporary directory")
-        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oesvk.XXXXXX', localdata), localdata)
         tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, 1) or "false")
         tmpfile = tmppipe.readline().strip()

bitbake/lib/bb/fetch/svn.py

@@ -146,7 +146,7 @@ class Svn(Fetch):
             svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", svnfetchcmd)
             runfetchcmd(svnfetchcmd, d)

bitbake/lib/bb/fetch2/__init__.py

@@ -525,6 +525,7 @@ class FetchData(object):
         self.localpath = None
         self.lockfile = None
         self.mirrortarball = None
+        self.basename = None
         (self.type, self.host, self.path, self.user, self.pswd, self.parm) = decodeurl(data.expand(url, d))
         self.date = self.getSRCDate(d)
         self.url = url
@@ -554,15 +555,6 @@ class FetchData(object):
         if not self.method:
             raise NoMethodError(url)
 
-        if self.method.supports_srcrev():
-            self.revisions = {}
-            for name in self.names:
-                self.revisions[name] = srcrev_internal_helper(self, d, name)
-
-            # add compatibility code for non name specified case
-            if len(self.names) == 1:
-                self.revision = self.revisions[self.names[0]]
-
         if hasattr(self.method, "urldata_init"):
             self.method.urldata_init(self, d)
 
@@ -573,11 +565,19 @@ class FetchData(object):
         elif self.localfile:
             self.localpath = self.method.localpath(self.url, self, d)
 
-        if self.localfile and self.localpath:
-            # Note: These files should always be in DL_DIR whereas localpath may not be.
-            basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath), d)
-            self.donestamp = basepath + '.done'
-            self.lockfile = basepath + '.lock'
+        # Note: These files should always be in DL_DIR whereas localpath may not be.
+        basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename), d)
+        self.donestamp = basepath + '.done'
+        self.lockfile = basepath + '.lock'
+
+    def setup_revisons(self, d):
+        self.revisions = {}
+        for name in self.names:
+            self.revisions[name] = srcrev_internal_helper(self, d, name)
+
+        # add compatibility code for non name specified case
+        if len(self.names) == 1:
+            self.revision = self.revisions[self.names[0]]
 
     def setup_localpath(self, d):
         if not self.localpath:
@@ -731,7 +731,7 @@ class FetchMethod(object):
                        destdir = urldata.path.rsplit("/", 1)[0]
                     else:
                        destdir = "."
-                    bb.mkdirhier("%s/%s" % (rootdir, destdir))
+                    bb.utils.mkdirhier("%s/%s" % (rootdir, destdir))
                     cmd = 'cp %s %s/%s/' % (file, rootdir, destdir)
 
         if not cmd:
@@ -742,7 +742,7 @@ class FetchMethod(object):
         os.chdir(rootdir)
         if 'subdir' in urldata.parm:
             newdir = ("%s/%s" % (rootdir, urldata.parm.get('subdir')))
-            bb.mkdirhier(newdir)
+            bb.utils.mkdirhier(newdir)
             os.chdir(newdir)
 
         cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', data, True), cmd)
@@ -913,9 +913,6 @@ class Fetch(object):
             m = ud.method
             localpath = ""
 
-            if not ud.localfile:
-                continue
-
             lf = bb.utils.lockfile(ud.lockfile)
 
             try:
@@ -951,7 +948,7 @@ class Fetch(object):
                         mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
                         localpath = try_mirrors (self.d, ud, mirrors)
 
-                if not localpath or not os.path.exists(localpath):
+                if not localpath or ((not os.path.exists(localpath)) and localpath.find("*") == -1):
                     raise FetchError("Unable to fetch URL %s from any source." % u, u)
 
                 if os.path.exists(ud.donestamp):

bitbake/lib/bb/fetch2/bzr.py

@@ -45,6 +45,8 @@ class Bzr(FetchMethod):
         relpath = self._strip_leading_slashes(ud.path)
         ud.pkgdir = os.path.join(data.expand('${BZRDIR}', d), ud.host, relpath)
 
+        ud.setup_revisons(d)
+
         if not ud.revision:
             ud.revision = self.latest_revision(ud.url, ud, d)
 
@@ -93,7 +95,7 @@ class Bzr(FetchMethod):
             bzrcmd = self._buildbzrcommand(ud, d, "fetch")
             bb.fetch2.check_network_access(d, bzrcmd, ud.url)
             logger.debug(1, "BZR Checkout %s", loc)
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", bzrcmd)
             runfetchcmd(bzrcmd, d)

bitbake/lib/bb/fetch2/cvs.py

@@ -139,7 +139,7 @@ class Cvs(FetchMethod):
         else:
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(pkgdir)
+            bb.utils.mkdirhier(pkgdir)
             os.chdir(pkgdir)
             logger.debug(1, "Running %s", cvscmd)
             bb.fetch2.check_network_access(d, cvscmd, ud.url)

bitbake/lib/bb/fetch2/git.py

@@ -72,15 +72,18 @@ class Git(FetchMethod):
 
         ud.basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
 
-        for name in ud.names:
-            # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
-            if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
-                ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
-
         ud.write_tarballs = (data.getVar("BB_GENERATE_MIRROR_TARBALLS", d, True) or "0") != "0"
 
         ud.localfile = ud.clonedir
 
+        ud.setup_revisons(d)
+
+        for name in ud.names:
+            # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
+            if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
+                ud.branches[name] = ud.revisions[name]
+                ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
+
     def localpath(self, url, ud, d):
         return ud.clonedir
 
@@ -116,7 +119,7 @@ class Git(FetchMethod):
 
         # If the checkout doesn't exist and the mirror tarball does, extract it
         if not os.path.exists(ud.clonedir) and os.path.exists(ud.fullmirror):
-            bb.mkdirhier(ud.clonedir)
+            bb.utils.mkdirhier(ud.clonedir)
             os.chdir(ud.clonedir)
             runfetchcmd("tar -xzf %s" % (ud.fullmirror), d)
 

bitbake/lib/bb/fetch2/hg.py

@@ -57,6 +57,8 @@ class Hg(FetchMethod):
         ud.pkgdir = os.path.join(data.expand('${HGDIR}', d), ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
+        ud.setup_revisons(d)
+
         if 'rev' in ud.parm:
             ud.revision = ud.parm['rev']
         elif not ud.revision:
@@ -131,7 +133,7 @@ class Hg(FetchMethod):
             fetchcmd = self._buildhgcommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", fetchcmd)
             bb.fetch2.check_network_access(d, fetchcmd, ud.url)

bitbake/lib/bb/fetch2/local.py

@@ -40,6 +40,7 @@ class Local(FetchMethod):
 
     def urldata_init(self, ud, d):
         # We don't set localfile as for this fetcher the file is already local!
+        ud.basename = os.path.basename(ud.url.split("://")[1].split(";")[0])
         return
 
     def localpath(self, url, urldata, d):
@@ -49,6 +50,9 @@ class Local(FetchMethod):
         path = url.split("://")[1]
         path = path.split(";")[0]
         newpath = path
+        dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
+        if os.path.exists(dldirfile):
+            return dldirfile
         if path[0] != "/":
             filespath = data.getVar('FILESPATH', d, True)
             if filespath:
@@ -57,8 +61,17 @@ class Local(FetchMethod):
                 filesdir = data.getVar('FILESDIR', d, True)
                 if filesdir:
                     newpath = os.path.join(filesdir, path)
+        if not os.path.exists(newpath) and path.find("*") == -1:
+            return dldirfile
         return newpath
 
+    def need_update(self, url, ud, d):
+        if url.find("*") != -1:
+            return False
+        if os.path.exists(ud.localpath):
+            return False
+        return True
+
     def download(self, url, urldata, d):
         """Fetch urls (no-op for Local method)"""
         # no need to fetch local files, we'll deal with them in place.

bitbake/lib/bb/fetch2/osc.py

@@ -96,7 +96,7 @@ class Osc(FetchMethod):
             oscfetchcmd = self._buildosccommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", oscfetchcmd)
             bb.fetch2.check_network_access(d, oscfetchcmd, ud.url)

bitbake/lib/bb/fetch2/perforce.py

@@ -152,7 +152,7 @@ class Perforce(FetchMethod):
 
         # create temp directory
         logger.debug(2, "Fetch: creating temporary directory")
-        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oep4.XXXXXX', localdata), localdata)
         tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
         tmpfile = tmppipe.readline().strip()

bitbake/lib/bb/fetch2/repo.py

@@ -69,7 +69,7 @@ class Repo(FetchMethod):
         else:
             username = ""
 
-        bb.mkdirhier(os.path.join(codir, "repo"))
+        bb.utils.mkdirhier(os.path.join(codir, "repo"))
         os.chdir(os.path.join(codir, "repo"))
         if not os.path.exists(os.path.join(codir, "repo", ".repo")):
             bb.fetch2.check_network_access(d, "repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)

bitbake/lib/bb/fetch2/svk.py

@@ -75,7 +75,7 @@ class Svk(FetchMethod):
         localdata = data.createCopy(d)
         data.update_data(localdata)
         logger.debug(2, "Fetch: creating temporary directory")
-        bb.mkdirhier(data.expand('${WORKDIR}', localdata))
+        bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oesvk.XXXXXX', localdata), localdata)
         tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
         tmpfile = tmppipe.readline().strip()

bitbake/lib/bb/fetch2/svn.py

@@ -56,6 +56,8 @@ class Svn(FetchMethod):
         ud.pkgdir = os.path.join(data.expand('${SVNDIR}', d), ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
+        ud.setup_revisons(d)
+
         if 'rev' in ud.parm:
             ud.revision = ud.parm['rev']
 
@@ -122,7 +124,7 @@ class Svn(FetchMethod):
             svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
             logger.info("Fetch " + loc)
             # check out sources there
-            bb.mkdirhier(ud.pkgdir)
+            bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", svnfetchcmd)
             bb.fetch2.check_network_access(d, svnfetchcmd, ud.url)

bitbake/lib/bb/runqueue.py

@@ -204,9 +204,9 @@ class RunQueueData:
             ret.extend([nam])
         return ret
 
-    def get_user_idstring(self, task):
+    def get_user_idstring(self, task, task_name_suffix = ""):
         fn = self.taskData.fn_index[self.runq_fnid[task]]
-        taskname = self.runq_task[task]
+        taskname = self.runq_task[task] + task_name_suffix
         return "%s, %s" % (fn, taskname)
 
     def get_task_id(self, fnid, taskname):
@@ -1060,27 +1060,23 @@ class RunQueueExecute:
         return
 
     def fork_off_task(self, fn, task, taskname, quieterrors=False):
-        the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)
 
-        env = bb.data.export_vars(the_data)
-        env = bb.data.export_envvars(env, the_data)
+        envbackup = os.environ.copy()
+        env = {}
 
         taskdep = self.rqdata.dataCache.task_deps[fn]
         if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
-            envvars = the_data.getVar("FAKEROOTENV", True).split()
+            envvars = (self.rqdata.dataCache.fakerootenv[fn] or "").split()
             for var in envvars:
                 comps = var.split("=")
                 env[comps[0]] = comps[1]
-            fakedirs = (the_data.getVar("FAKEROOTDIRS", True) or "").split()
+
+            fakedirs = (self.rqdata.dataCache.fakerootdirs[fn] or "").split()
             for p in fakedirs:
                 bb.mkdirhier(p)
             logger.debug(2, "Running %s:%s under fakeroot, state dir is %s" % (fn, taskname, fakedirs))
-
-        envbackup = os.environ.copy()
-        for e in envbackup:
-            os.unsetenv(e)
-        for e in env:
-            os.putenv(e, env[e])
+            for e in env:
+                os.putenv(e, env[e])
 
         sys.stdout.flush()
         sys.stderr.flush()
@@ -1111,6 +1107,20 @@ class RunQueueExecute:
             # No stdin
             newsi = os.open(os.devnull, os.O_RDWR)
             os.dup2(newsi, sys.stdin.fileno())
+
+
+            the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)
+
+            env2 = bb.data.export_vars(the_data)
+            env2 = bb.data.export_envvars(env2, the_data)
+
+            for e in os.environ:
+                os.unsetenv(e)
+            for e in env2:
+                os.putenv(e, env2[e])
+            for e in env:
+                os.putenv(e, env[e])
+
             if quieterrors:
                 the_data.setVarFlag(taskname, "quieterrors", "1")
 
@@ -1137,7 +1147,8 @@ class RunQueueExecute:
         for e in env:
             os.unsetenv(e)
         for e in envbackup:
-            os.putenv(e, envbackup[e])
+            if e in env:
+                os.putenv(e, envbackup[e])
 
         return pid, pipein, pipeout
 
@@ -1177,6 +1188,25 @@ class RunQueueExecuteTasks(RunQueueExecute):
                     self.rq.scenequeue_covered.add(task)
                     found = True
 
+        # Detect when the real task needs to be run anyway by looking to see
+        # if any of its dependencies within the same package are scheduled
+        # to be run.
+        covered_remove = set()
+        for task in self.rq.scenequeue_covered:
+            task_fnid = self.rqdata.runq_fnid[task]
+            for dep in self.rqdata.runq_depends[task]:
+                if self.rqdata.runq_fnid[dep] == task_fnid:
+                    if dep not in self.rq.scenequeue_covered:
+                        covered_remove.add(task)
+                        break
+
+        for task in covered_remove:
+            fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
+            taskname = self.rqdata.runq_task[task] + '_setscene'
+            bb.build.del_stamp(taskname, self.rqdata.dataCache, fn)
+            logger.debug(1, 'Not skipping task %s because it will have to be run anyway', task)
+            self.rq.scenequeue_covered.remove(task)
+
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
         for task in self.rq.scenequeue_covered:
@@ -1483,7 +1513,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
     def task_fail(self, task, result):
         self.stats.taskFailed()
         index = self.rqdata.runq_setscene[task]
-        bb.event.fire(runQueueTaskFailed(task, self.stats, result, self), self.cfgData)
+        bb.event.fire(sceneQueueTaskFailed(index, self.stats, result, self), self.cfgData)
         self.scenequeue_notcovered.add(task)
         self.scenequeue_updatecounters(task)
 
@@ -1616,6 +1646,14 @@ class runQueueTaskFailed(runQueueEvent):
         runQueueEvent.__init__(self, task, stats, rq)
         self.exitcode = exitcode
 
+class sceneQueueTaskFailed(runQueueTaskFailed):
+    """
+    Event notifing a setscene task failed
+    """
+    def __init__(self, task, stats, exitcode, rq):
+        runQueueTaskFailed.__init__(self, task, stats, exitcode, rq)
+        self.taskstring = rq.rqdata.get_user_idstring(task, "_setscene")
+
 class runQueueTaskCompleted(runQueueEvent):
     """
     Event notifing a task completed

bitbake/lib/bb/server/xmlrpc.py

@@ -52,6 +52,8 @@ if sys.hexversion < 0x020600F0:
 # implementations from Python 2.6.6's xmlrpclib.
 #
 # Upstream Python bug is #8194 (http://bugs.python.org/issue8194)
+# This bug is relevant for Python 2.7.0 and 2.7.1 but was fixed for
+# Python > 2.7.2
 ##
 
 class BBTransport(xmlrpclib.Transport):
@@ -107,6 +109,18 @@ class BBTransport(xmlrpclib.Transport):
 
         return u.close()
 
+def _create_server(host, port):
+    # Python 2.7.0 and 2.7.1 have a buggy Transport implementation
+    # For those versions of Python, and only those versions, use our
+    # own copy/paste BBTransport class.
+    if (2, 7, 0) <= sys.version_info < (2, 7, 2):
+        t = BBTransport()
+        s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
+    else:
+        s = xmlrpclib.Server("http://%s:%d/" % (host, port), allow_none=True)
+
+    return s
+
 class BitBakeServerCommands():
     def __init__(self, server, cooker):
         self.cooker = cooker
@@ -116,8 +130,8 @@ class BitBakeServerCommands():
         """
         Register a remote UI Event Handler
         """
-        t = BBTransport()
-        s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
+        s = _create_server(host, port)
+
         return bb.event.register_UIHhandler(s)
 
     def unregisterEventHandler(self, handlerNum):
@@ -240,8 +254,7 @@ class BitbakeUILauch():
 
 class BitBakeServerConnection():
     def __init__(self, serverinfo):
-        t = BBTransport()
-        self.connection = xmlrpclib.Server("http://%s:%s" % (serverinfo.host, serverinfo.port), transport=t, allow_none=True)
+        self.connection = _create_server(serverinfo.host, serverinfo.port)
         self.events = uievent.BBUIEventQueue(self.connection)
         for event in bb.event.ui_queue:
             self.events.queue_event(event)

bitbake/lib/bb/ui/goggle.py

@@ -105,6 +105,8 @@ def main (server, eventHandler):
         # ignore interrupted io
         if ioerror.args[0] == 4:
             pass
+    except KeyboardInterrupt:
+        pass
     finally:
         server.runCommand(["stateStop"])
 

bitbake/lib/bb/ui/hob.py

@@ -420,7 +420,7 @@ class MainWindow (gtk.Window):
         label.show()
         response = dialog.run()
         dialog.destroy()
-        if not response == gtk.RESPONSE_YES:
+        if response == gtk.RESPONSE_YES:
             self.handler.cancel_build()
         return
 

bitbake/lib/bb/utils.py

@@ -407,13 +407,12 @@ def lockfile(name, shared=False):
     Use the file fn as a lock file, return when the lock has been acquired.
     Returns a variable to pass to unlockfile().
     """
-    path = os.path.dirname(name)
-    if not os.path.isdir(path):
-        logger.error("Lockfile destination directory '%s' does not exist", path)
-        sys.exit(1)
+    dirname = os.path.dirname(name)
+    mkdirhier(dirname)
 
-    if not os.access(path, os.W_OK):
-        logger.error("Error, lockfile path is not writable!: %s" % path)
+    if not os.access(dirname, os.W_OK):
+        logger.error("Unable to acquire lock '%s', directory is not writable",
+                     name)
         sys.exit(1)
 
     op = fcntl.LOCK_EX
@@ -449,7 +448,7 @@ def unlockfile(lf):
     Unlock a file locked using lockfile()
     """
     try:
-        # If we had a shared lock, we need to promote to exclusive before 
+        # If we had a shared lock, we need to promote to exclusive before
         # removing the lockfile. Attempt this, ignore failures.
         fcntl.flock(lf.fileno(), fcntl.LOCK_EX|fcntl.LOCK_NB)
         os.unlink(lf.name)

documentation/adt-manual/Makefile

@@ -0,0 +1,42 @@
+XSLTOPTS = --stringparam html.stylesheet style.css \
+           --stringparam  chapter.autolabel 1 \
+           --stringparam  appendix.autolabel A \
+           --stringparam  section.autolabel 1 \
+           --stringparam  section.label.includes.component.label 1 \
+         --xinclude
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
+XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
+
+all: html pdf tarball
+
+pdf:
+	../tools/poky-docbook-to-pdf adt-manual.xml ../template
+
+##
+# These URI should be rewritten by your distribution's xml catalog to
+# match your localy installed XSL stylesheets.
+
+html:
+#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html 
+
+#	xsltproc $(XSLTOPTS) -o adt-manual.html $(XSL_XHTML_URI) adt-manual.xml
+	xsltproc $(XSLTOPTS) -o adt-manual.html adt-manual-customization.xsl adt-manual.xml
+
+tarball: html
+	tar -cvzf adt-manual.tgz adt-manual.html adt-manual.pdf style.css figures/adt-title.png figures/yocto-project-transp.png
+
+validate:
+	xmllint --postvalid --xinclude --noout adt-manual.xml
+
+OUTPUTS = adt-manual.tgz adt-manual.html adt-manual.pdf
+SOURCES = *.png *.xml *.css
+
+publish:
+	scp -r $(OUTPUTS) $(SOURCES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-doc/adt-manual
+
+clean:
+	rm -f $(OUTPUTS)

documentation/adt-manual/adt-command.xml

@@ -0,0 +1,66 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<chapter id='using-the-command-line'>
+<title>Using the Command Line</title>
+    <para>
+        Recall that earlier we talked about how to use an existing toolchain 
+        tarball that had been installed into <filename>/opt/poky</filename>, 
+        which is outside of the Poky build environment 
+        (see <xref linkend='using-an-existing-toolchain-tarball'>
+        “Using an Existing Toolchain Tarball”)</xref>.  
+        And, that sourcing your architecture-specific environment setup script 
+        initializes a suitable development environment.  
+        This setup occurs by adding the compiler, QEMU scripts, QEMU binary, 
+        a special version of <filename>pkgconfig</filename> and other useful 
+        utilities to the <filename>PATH</filename> variable.
+        Variables to assist pkgconfig and autotools are also defined so that, 
+        for example, <filename>configure.sh</filename> can find pre-generated 
+        test results for tests that need target hardware on which to run.  
+        These conditions allow you to easily use the toolchain outside of the 
+        Poky build environment on both autotools-based projects and 
+        makefile-based projects.
+    </para>
+
+<section id='autotools-based-projects'>
+<title>Autotools-Based Projects</title>
+    <para>
+        For an autotools-based project you can use the cross-toolchain by just 
+        passing the appropriate host option to <filename>configure.sh</filename>.
+        The host option you use is derived from the name of the environment setup 
+        script in <filename>/opt/poky</filename> resulting from unpacking the 
+        cross-toolchain tarball.
+        For example, the host option for an ARM-based target that uses the GNU EABI 
+        is <filename>armv5te-poky-linux-gnueabi</filename>.
+        Note that the name of the script is 
+        <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
+        Thus, the following command works:
+        <literallayout class='monospaced'>
+     $ configure &dash;&dash;host-armv5te-poky-linux-gnueabi &dash;&dash;with-libtool-sysroot=&lt;sysroot-dir&gt;
+        </literallayout>
+    </para>
+    <para>
+        This single command updates your project and rebuilds it using the appropriate 
+        cross-toolchain tools.
+    </para>
+</section>
+
+<section id='makefile-based-projects'>
+<title>Makefile-Based Projects</title>
+    <para>
+        For a makefile-based project you use the cross-toolchain by making sure 
+        the tools are used.  
+        You can do this as follows:
+        <literallayout class='monospaced'>
+     CC=arm-poky-linux-gnueabi-gcc
+     LD=arm-poky-linux-gnueabi-ld
+     CFLAGS=”${CFLAGS} &dash;&dash;sysroot=&lt;sysroot-dir&gt;”
+     CXXFLAGS=”${CXXFLAGS} &dash;&dash;sysroot=&lt;sysroot-dir&gt;”
+        </literallayout>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/adt-manual/adt-eclipse.xml

@@ -0,0 +1,435 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<chapter id='adt-eclipse'>
+<title>Working Within Eclipse</title>
+    <para>
+        The Eclipse IDE is a popular development environment and it fully supports 
+        development using Yocto Project.  
+        When you install and configure the Eclipse Yocto Project Plug-in into 
+        the Eclipse IDE you maximize your Yocto Project design experience.  
+        Installing and configuring the Plug-in results in an environment that 
+        has extensions specifically designed to let you more easily develop software.  
+        These extensions allow for cross-compilation and deployment and execution of 
+        your output into a QEMU emulation session.  
+        You can also perform cross-debugging and profiling.  
+        The environment also has a suite of tools that allows you to perform 
+        remote profiling, tracing, collection of power data, collection of 
+        latency data, and collection of performance data.
+    </para>
+    <para>
+        This section describes how to install and configure the Eclipse IDE 
+        Yocto Plug-in and how to use it to develop your Yocto Project.
+    </para>
+
+<section id='setting-up-the-eclipse-ide'>
+    <title>Setting Up the Eclipse IDE</title>
+    <para>
+        To develop within the Eclipse IDE you need to do the following:
+        <orderedlist>
+            <listitem><para>Be sure the optimal version of Eclipse IDE 
+            is installed.</para></listitem>
+            <listitem><para>Install required Eclipse plug-ins prior to installing 
+            the Eclipse Yocto Plug-in.</para></listitem>
+            <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
+        </orderedlist>
+    </para>
+
+    <section id='installing-eclipse-ide'>
+    <title>Installing Eclipse IDE</title>
+        <para>
+            It is recommended that you have the Helios 3.6.1 version of the 
+            Eclipse IDE installed on your development system.  
+            If you don’t have this version you can find it at 
+            <ulink url='http://www.eclipse.org/downloads'></ulink>.  
+            From that site, choose the Eclipse Classic version.  
+            This version contains the Eclipse Platform, the Java Development 
+            Tools (JDT), and the Plug-in Development Environment.
+        </para>
+        <para>
+            Once you have downloaded the tarball, extract it into a clean 
+            directory and complete the installation.
+        </para>
+        <para>
+            One issue exists that you need to be aware of regarding the Java 
+            Virtual machine’s garbage collection (GC) process.  
+            The GC process does not clean up the permanent generation 
+            space (PermGen).  
+            This space stores meta-data descriptions of classes.  
+            The default value is set too small and it could trigger an 
+            out-of-memory error such as the following:
+            <literallayout class='monospaced'>
+     Java.lang.OutOfMemoryError: PermGen space
+            </literallayout>
+        </para>
+        <para>
+            This error causes the application to hang.
+        </para>
+        <para>
+            To fix this issue you can use the &dash;&dash;vmargs option when you start 
+            Eclipse to increase the size of the permanent generation space:
+            <literallayout class='monospaced'>
+     eclipse &dash;&dash;vmargs &dash;&dash;XX:PermSize=256M
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='installing-required-plug-ins-and-the-eclipse-yocto-plug-in'>
+    <title>Installing Required Plug-ins and the Eclipse Yocto Plug-in</title>
+        <para>
+            Before installing the Yocto Plug-in you need to be sure that the 
+            CDT 7.0, RSE 3.2, and Autotools plug-ins are all installed in the 
+            following order.  
+            After installing these three plug-ins, you can install the 
+            Eclipse Yocto Plug-in.  
+            Use the following URLs for the plug-ins:
+            <orderedlist>
+                <listitem><para><emphasis>CDT 7.0</emphasis> – 
+                <ulink url='http://download.eclipse.org/tools/cdt/releases/helios/'></ulink>:  
+                For CDT main features select the checkbox so you get all items.  
+                For CDT optional features expand the selections and check 
+                “C/C++ Remote Launch”.</para></listitem>
+                <listitem><para><emphasis>RSE 3.2</emphasis> – 
+                <ulink url='http://download.eclipse.org/tm/updates/3.2'></ulink>:  
+                Check the box next to “TM and RSE Main Features” so you select all 
+                those items.  
+                Note that all items in the main features depend on 3.2.1 version.  
+                Expand the items under “TM and RSE Uncategorized 3.2.1” and 
+                select the following:  “Remote System Explorer End-User Runtime”, 
+                “Remote System Explorer Extended SDK”, “Remote System Explorer User Actions”, 
+                “RSE Core”, “RSE Terminals UI”, and “Target Management Terminal”.</para></listitem>
+                <listitem><para><emphasis>Autotools</emphasis> – 
+                <ulink url='http://download.eclipse.org/technology/linuxtools/update/'></ulink>:
+                Expand the items under “Linux Tools” and select “Autotools support for 
+                CDT (Incubation)”.</para></listitem>
+                <listitem><para><emphasis>Yocto Plug-in</emphasis> – 
+                <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/1.0'></ulink>:
+                Check the box next to “Development tools &amp; SDKs for Yocto Linux” 
+                to select all the items.</para></listitem>
+            </orderedlist>
+        </para>
+        <para>
+            Follow these general steps to install a plug-in:
+            <orderedlist>
+                <listitem><para>From within the Eclipse IDE select the 
+                “Install New Software” item from the “Help” menu.</para></listitem>
+                <listitem><para>Click “Add…” in the “Work with:” area.</para></listitem>
+                <listitem><para>Enter the URL for the repository and leave the “Name” 
+                field blank.</para></listitem>
+                <listitem><para>Check the boxes next to the software you need to 
+                install and then complete the installation.  
+                For information on the specific software packages you need to include, 
+                see the previous list.</para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='configuring-the-plug-in'>
+    <title>Configuring the Plug-in</title>
+        <para>
+            Configuring the Eclipse Yocto Plug-in involves choosing the Cross 
+            Compiler Options, selecting the Target Architecture, and choosing 
+            the Target Options.  
+            These settings are the default settings for all projects.  
+            You do have opportunities to change them later if you choose to when 
+            you configure the project.  
+            See “Configuring the Cross Toolchain” section later in the manual.
+        </para>
+        <para>
+            To start, you need to do the following from within the Eclipse IDE:
+            <itemizedlist>
+                <listitem><para>Choose Windows -&gt; Preferences to display 
+                the Preferences Dialog</para></listitem>
+                <listitem><para>Click “Yocto SDK”</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='configuring-the-cross-compiler-options'>
+        <title>Configuring the Cross-Compiler Options</title>
+            <para>
+                Choose between ‘SDK Root Mode’ and ‘Poky Tree Mode’ for Cross 
+                Compiler Options.
+                <itemizedlist>
+                    <listitem><para><emphasis>SDK Root Mode</emphasis> – Select this mode 
+                    when you are not concerned with building an image or you do not have 
+                    a Poky build tree on your system.  
+                    For example, suppose you are an application developer and do not 
+                    need to build an image.  
+                    You just want to use an architecture-specific toolchain on an 
+                    existing kernel and root filesystem.  
+                    When you use SDK Root Mode you are using the toolchain installed 
+                    in the <filename>/opt/poky</filename> directory.</para></listitem>
+                    <listitem><para><emphasis>Poky Tree Mode</emphasis> – Select this mode 
+                    if you are concerned with building images for hardware or your 
+                    development environment already has a build tree.  
+                    In this case you likely already have a Poky build tree installed on 
+                    your system or you (or someone else) will be building one.
+                    When you use the Poky Tree Mode you are using the toolchain bundled 
+                    inside the Poky build tree.  
+                    If you use this mode you must also supply the Poky Root Location 
+                    in the Preferences Dialog.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='configuring-the-sysroot'>
+        <title>Configuring the Sysroot</title>
+            <para>
+                Specify the sysroot, which is used by both the QEMU user-space 
+                NFS boot process and by the cross-toolchain regardless of the 
+                mode you select (SDK Root Mode or Poky Tree Mode).  
+                For example, sysroot is the location to which you extract the 
+                downloaded image’s root filesystem to through the ADT Installer.
+            </para>
+        </section>
+
+        <section id='selecting-the-target-architecture'>
+        <title>Selecting the Target Architecture</title>
+            <para>
+                Use the pull-down Target Architecture menu and select the 
+                target architecture.
+            </para>
+            <para>
+                The Target Architecture is the type of hardware you are 
+                going to use or emulate.  
+                This pull-down menu should have the supported architectures.  
+                If the architecture you need is not listed in the menu then you 
+                will need to re-visit 
+                <xref linkend='adt-prepare'>
+                “Preparing to Use the Application Development Toolkit (ADT)”</xref> 
+                section  earlier in this document.
+            </para>
+        </section>
+
+        <section id='choosing-the-target-options'>
+        <title>Choosing the Target Options</title>
+            <para>
+                You can choose to emulate hardware using the QEMU emulator, or you 
+                can choose to use actual hardware.
+                <itemizedlist>
+                    <listitem><para><emphasis>External HW</emphasis> – Select this option 
+                    if you will be using actual hardware.</para></listitem>
+                    <listitem><para><emphasis>QEMU</emphasis> – Select this option if 
+                    you will be using the QEMU emulator.  
+                    If you are using the emulator you also need to locate the Kernel 
+                    and you can specify custom options.</para>
+                    <para>In Poky Tree Mode the kernel you built will be located in the 
+                    Poky Build tree in <filename>tmp/deploy/images</filename> directory.   
+                    In SDK Root Mode the pre-built kernel you downloaded is located 
+                    in the directory you specified when you downloaded the image.</para>
+                    <para>Most custom options are for advanced QEMU users to further 
+                    customize their QEMU instance.  
+                    These options are specified between paired angled brackets.  
+                    Some options must be specified outside the brackets.
+                    In particular, the options <filename>serial</filename>, 
+                    <filename>nographic</filename>, and <filename>kvm</filename> must all 
+                    be outside the brackets.  
+                    Use the <filename>man qemu</filename> command to get help on all the options
+                    and their use.  
+                    The following is an example:
+                        <literallayout class='monospaced'>
+    serial ‘&lt;-m 256 -full-screen&gt;’
+                        </literallayout>
+                    </para>
+                    <para>
+                    Regardless of the mode, Sysroot is already defined in the “Sysroot” 
+                    field.</para></listitem>
+                </itemizedlist>
+            </para>
+            <para>
+                Click the “OK” button to save your plug-in configurations.
+            </para>
+        </section>
+    </section>
+</section>
+
+<section id='creating-the-project'>
+<title>Creating the Project</title>
+    <para>
+        You can create two types of projects:  Autotools-based, or Makefile-based.  
+        This section describes how to create autotools-based projects from within 
+        the Eclipse IDE.  
+        For information on creating projects in a terminal window see 
+        <xref linkend='using-the-command-line'> “Using the Command Line”</xref> 
+        section.
+    </para>
+    <para>
+        To create a project based on a Yocto template and then display the source code, 
+        follow these steps:
+        <orderedlist>
+            <listitem><para>Select File -> New -> Project.</para></listitem>
+            <listitem><para>Double click “CC++”.</para></listitem>
+            <listitem><para>Double click “C Project” to create the project.</para></listitem>
+            <listitem><para>Double click “Yocto SDK Project”.</para></listitem>
+            <listitem><para>Select “Hello World ANSI C Autotools Project”.  
+            This is an Autotools-based project based on a Yocto Project template.</para></listitem>
+            <listitem><para>Put a name in the “Project name:” field.</para></listitem>
+            <listitem><para>Click “Next”.</para></listitem>
+            <listitem><para>Add information in the “Author” field.</para></listitem>
+            <listitem><para>Use “GNU General Public License v2.0” for the License.</para></listitem>
+            <listitem><para>Click “Finish”.</para></listitem>
+            <listitem><para>Answer ‘Yes” to the open perspective prompt.</para></listitem>
+            <listitem><para>In the Project Explorer expand your project.</para></listitem>
+            <listitem><para>Expand ‘src’.</para></listitem>
+            <listitem><para>Double click on your source file and the code appears 
+            in the window.  
+            This is the template.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='configuring-the-cross-toolchains'>
+<title>Configuring the Cross-Toolchains</title>
+    <para>
+        The previous section, <xref linkend='configuring-the-cross-compiler-options'>
+        “Configuring the Cross-Compiler Options”</xref>, set up the default project 
+        configurations.  
+        You can change these settings for a given project by following these steps:
+        <orderedlist>
+            <listitem><para>Select Project -> Invoke Yocto Tools -> Reconfigure Yocto.  
+            This brings up the project Yocto Settings Dialog.  
+            Settings are inherited from the default project configuration.  
+            The information in this dialogue is identical to that chosen earlier 
+            for the Cross Compiler Option (SDK Root Mode or Poky Tree Mode), 
+            the Target Architecture, and the Target Options.  
+            The settings are inherited from the Yocto Plug-in configuration performed 
+            after installing the plug-in.</para></listitem>
+            <listitem><para>Select Project -> Reconfigure Project.  
+            This runs the <filename>autogen.sh</filename> in the workspace for your project.  
+            The script runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
+            <filename>autoconf</filename>, <filename>autoheader</filename>, 
+            <filename>automake &dash;&dash;a</filename>, and 
+            <filename>./configure</filename>.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='building-the-project'>
+<title>Building the Project</title>
+    <para>
+        To build the project, select Project -&gt; Build Project.  
+        You should see the console updated and you can note the cross-compiler you are using.
+    </para>
+</section>
+
+<section id='starting-qemu-in-user-space-nfs-mode'>
+<title>Starting QEMU in User Space NFS Mode</title>
+    <para>
+        To start the QEMU emulator from within Eclipse, follow these steps:
+        <orderedlist>
+            <listitem><para>Select Run -> External Tools -> External Tools Configurations...
+            This selection brings up the External Tools Configurations Dialogue.</para></listitem>
+            <listitem><para>Go to the left navigation area and expand ‘Program’.  
+            You should find the image listed.  
+            For example, qemu-x86_64-poky-linux.</para></listitem>
+            <listitem><para>Click on the image.  
+            This brings up a new environment in the main area of the External 
+            Tools Configurations Dialogue.  
+            The Main tab is selected.</para></listitem>
+            <listitem><para>Click “Run” next.  
+            This brings up a shell window.</para></listitem>
+            <listitem><para>Enter your host root password in the shell window at the prompt.  
+            This sets up a Tap 0 connection needed for running in user-space NFS mode.</para></listitem>
+            <listitem><para>Wait for QEMU to launch.</para></listitem>
+            <listitem><para>Once QEMU launches you need to determine the IP Address 
+            for the user-space NFS.  
+            You can do that by going to a terminal in the QEMU and entering the 
+            <filename>ipconfig</filename> command.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='deploying-and-debugging-the-application'>
+<title>Deploying and Debugging the Application</title>
+    <para>
+        Once QEMU is running you can deploy your application and use the emulator 
+        to perform debugging.  
+        Follow these steps to deploy the application.
+        <orderedlist>
+            <listitem><para>Select Run -> Debug Configurations...</para></listitem>
+            <listitem><para>In the left area expand “C/C++Remote Application”.</para></listitem>
+            <listitem><para>Locate your project and select it to bring up a new 
+            tabbed view in the Debug Configurations dialogue.</para></listitem>
+            <listitem><para>Enter the absolute path into which you want to deploy 
+            the application.  
+            Use the Remote Absolute File Path for C/C++Application:.  
+            For example, enter <filename>/usr/bin/&lt;programname&gt;</filename>.</para></listitem>
+            <listitem><para>Click on the Debugger tab to see the cross-tool debugger 
+            you are using.</para></listitem>
+            <listitem><para>Create a new connection to the QEMU instance 
+            by clicking on “new”.</para></listitem>
+            <listitem><para>Select “TCF, which means Target Communication Framework.</para></listitem>
+            <listitem><para>Click “Next”.</para></listitem>
+            <listitem><para>Clear out the “host name” field and enter the IP Address 
+            determined earlier.</para></listitem>
+            <listitem><para>Click Finish to close the new connections dialogue.</para></listitem>
+            <listitem><para>Use the drop-down menu now in the “Connection” field and pick 
+            the IP Address you entered.</para></listitem>
+            <listitem><para>Click “Debug” to bring up a login screen and login.</para></listitem>
+            <listitem><para>Accept the debug perspective.</para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
+<section id='running-user-space-tools'>
+<title>Running User-Space Tools</title>
+    <para>
+        As mentioned earlier in the manual several tools exist that enhance 
+        your development experience.  
+        These tools are aids in developing and debugging applications and images.  
+        You can run these user-space tools from within the Yocto Eclipse 
+        Plug-in through the Window -> YoctoTools menu.
+    </para>
+    <para>
+        Once you pick a tool you need to configure it for the remote target. 
+        Every tool needs to have the connection configured. 
+        You must select an existing TCF-based RSE connection to the remote target. 
+        If one does not exist, click "New" to create one.
+    </para>
+    <para>
+        Here are some specifics about the remote tools:
+        <itemizedlist>
+            <listitem><para><emphasis>OProfile:</emphasis>  Selecting this tool causes 
+            the oprofile-server on the remote target to launch on the local host machine.  
+            The oprofile-viewer must be installed on the local host machine and the 
+            oprofile-server must be installed on the remote target, respectively, in order 
+            to use.  
+            You can locate both the viewer and server from 
+            <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>.  
+            You need to compile and install the oprofile-viewer from the source code 
+            on your local host machine.  
+            The oprofile-server is installed by default in the image.</para></listitem>
+            <listitem><para><emphasis>Lttng-ust:</emphasis>  Selecting this tool runs 
+            "usttrace" on the remote target, transfers the output data back to the 
+            local host machine and uses "lttv-gui" to graphically display the output.  
+            The "lttv-gui" must be installed on the local host machine to use this tool.  
+            For information on how to use "lttng" to trace an application, see 
+            <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para>
+            <para>For "Application" you must supply the absolute path name of the 
+            application to be traced by user mode lttng.  
+            For example, typing <filename>/path/to/foo</filename> triggers 
+            <filename>usttrace /path/to/foo</filename> on the remote target to trace the 
+            program <filename>/path/to/foo</filename>.</para>
+            <para>"Argument" is passed to <filename>usttrace</filename>
+            running on the remote target.</para></listitem>
+            <listitem><para><emphasis>PowerTOP:</emphasis>  Selecting this tool runs 
+            "PowerTOP" on the remote target machine and displays the results in a 
+            new view called "powertop".</para>
+            <para>"Time to gather data(sec):" is the time passed in seconds before data 
+            is gathered from the remote target for analysis.</para>
+            <para>"show pids in wakeups list:" corresponds to the -p argument 
+            passed to "powertop".</para></listitem>
+            <listitem><para><emphasis>LatencyTOP and Perf:</emphasis>  "LatencyTOP" 
+            identifies system latency, while "perf" monitors the system's 
+            performance counter registers. 
+            Selecting either of these tools causes an RSE terminal view to appear 
+            from which you can run the tools. 
+            Both tools refresh the entire screen to display results while they run.</para></listitem>
+        </itemizedlist>
+    </para>
+</section> 
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/adt-manual/adt-intro.xml

@@ -0,0 +1,117 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<chapter id='adt-intro'>
+
+<title>Application Development Toolkit (ADT) User's Guide</title>
+
+<para>
+    Welcome to the Application Development Toolkit User’s Guide.  This manual provides 
+    information that lets you get going with the ADT to develop projects using the Yocto 
+    Project.
+</para>
+
+<section id='book-intro'>
+    <title>Introducing the Application Development Toolkit (ADT)</title>
+    <para>
+        Fundamentally, the ADT consists of an architecture-specific cross-toolchain and 
+        a matching sysroot that are both built by the Poky build system.  
+        The toolchain and sysroot are based on a metadata configuration and extensions, 
+        which allows you to cross develop for the target on the host machine.
+    </para>
+    <para>
+        Additionally, to provide an effective development platform, the Yocto Project 
+        makes available and suggests other tools as part of the ADT.  
+        These other tools include the Eclipse IDE Yocto Plug-in, an emulator (QEMU), 
+        and various user-space tools that greatly enhance your development experience.
+    </para>
+    <para>
+        The resulting combination of the architecture-specific cross-toolchain and sysroot 
+        along with these additional tools yields a custom-built, cross-development platform 
+        for a user-targeted product.
+    </para>
+    
+    <section id='the-cross-toolchain'>
+        <title>The Cross-Toolchain</title>
+        <para>
+            The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger 
+            that are all generated through a Poky build that is based on your metadata 
+            configuration or extension for your targeted device.  
+            The cross-toolchain works with a matching target sysroot.
+        </para>
+    </section>
+
+    <section id='sysroot'>
+        <title>Sysroot</title>
+        <para>
+            The matching target sysroot contains needed headers and libraries for generating 
+            binaries that run on the target architecture.  
+            The sysroot is based on the target root filesystem image that is built by 
+            Poky and uses the same metadata configuration used to build the cross-toolchain.
+        </para>
+    </section>
+
+    <section id='the-qemu-emulator'>
+        <title>The QEMU Emulator</title>
+        <para>
+            The QEMU emulator allows you to simulate your hardware while running your 
+            application or image.  
+            QEMU is installed several ways:  as part of the Poky tree, ADT installation 
+            through a toolchain tarball, or through the ADT Installer.
+        </para>
+    </section>
+
+    <section id='user-space-tools'>
+        <title>User-Space Tools</title>
+        <para>
+            User-space tools are included as part of the distribution.  
+            You will find these tools helpful during development.  
+            The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust.  
+            These tools are common development tools for the Linux platform.
+        <itemizedlist>
+            <listitem><para><emphasis>LatencyTOP</emphasis> – LatencyTOP focuses on latency 
+                that causes skips in audio,
+                stutters in your desktop experience, or situations that overload your server 
+                even when you have plenty of CPU power left.  
+                You can find out more about LatencyTOP at 
+                <ulink url='http://www.latencytop.org/'></ulink>.
+            </para></listitem>
+            <listitem><para><emphasis>PowerTOP</emphasis> – Helps you determine what   
+                software is using the most power.  
+                You can find out more about PowerTOP at 
+                <ulink url='http://www.linuxpowertop.org/'></ulink>.
+            </para></listitem>
+            <listitem><para><emphasis>OProfile</emphasis> – A system-wide profiler for Linux 
+                systems that is capable 
+                of profiling all running code at low overhead.  
+                You can find out more about OProfile at 
+                <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
+            </para></listitem>
+            <listitem><para><emphasis>Perf</emphasis> – Performance counters for Linux used 
+                to keep track of certain 
+                types of hardware and software events.  
+                For more information on these types of counters see 
+                <ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click 
+                on “Perf tools.”
+            </para></listitem>
+            <listitem><para><emphasis>SystemTap</emphasis> – A free software infrastructure 
+                that simplifies 
+                information gathering about a running Linux system.  
+                This information helps you diagnose performance or functional problems.  
+                SystemTap is not available as a user-space tool through the Yocto Eclipse IDE Plug-in.  
+                See <ulink url='http://sourceware.org/systemtap'></ulink> for more information 
+                on SystemTap.
+            </para></listitem>
+            <listitem><para><emphasis>Lttng-ust</emphasis> – A User-space Tracer designed to 
+                provide detailed information on user-space activity.  
+                See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.
+            </para></listitem>
+        </itemizedlist>
+        </para>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/adt-manual/adt-manual-customization.xsl

@@ -0,0 +1,8 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+  
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+
+<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
+
+</xsl:stylesheet>

documentation/adt-manual/adt-manual.xml

@@ -0,0 +1,70 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<book id='adt-manual' lang='en' 
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/adt-title.png' 
+                    format='SVG' 
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>    
+        </mediaobject>
+
+        <title></title> 
+
+        <authorgroup>
+            <author>
+                <firstname>Jessica</firstname> <surname>Zhang</surname>
+                <affiliation>
+                    <orgname>Intel Corporation</orgname>
+                </affiliation>
+                <email>jessica.zhang@intel.com</email>
+            </author>
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+      <year>2010-2011</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under 
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="adt-intro.xml"/>
+
+    <xi:include href="adt-prepare.xml"/>
+
+    <xi:include href="adt-package.xml"/>
+
+    <xi:include href="adt-eclipse.xml"/>
+
+    <xi:include href="adt-command.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!-- 
+vim: expandtab tw=80 ts=4 
+-->

documentation/adt-manual/adt-package.xml

@@ -0,0 +1,82 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<chapter id='adt-package'>
+<title>Optionally Customizing the Development Packages Installation</title>
+    <para>
+        Because the Yocto Project is suited for embedded Linux development it is 
+        likely that you will need to customize your development packages installation.  
+        For example, if you are developing a minimal image then you might not need 
+        certain packages (e.g. graphics support packages).  
+        Thus, you would like to be able to remove those packages from your sysroot.
+    </para>
+
+<section id='package-management-systems'>
+    <title>Package Management Systems</title>
+    <para>
+        The Yocto Project supports the generation of root filesystem files using 
+        three different Package Management Systems (PMS):
+    <itemizedlist>
+        <listitem><para><emphasis>OPKG</emphasis> – A less well known PMS whose use 
+            originated in the OpenEmbedded and OpenWrt embedded Linux projects.  
+            This PMS works with files packaged in an <filename>.ipk</filename> format.
+            See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more 
+            information about OPKG.</para></listitem>
+        <listitem><para><emphasis>RPM</emphasis> – A more widely known PMS intended for GNU/Linux 
+            distributions.  
+            This PMS works with files packaged in an <filename>.rms</filename> format.
+            The Yocto Project currently installs through this PMS by default.  
+            See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
+            for more information about RPM.</para></listitem>
+        <listitem><para><emphasis>Debian</emphasis> – The PMS for Debian-based systems 
+            is built on many PMS tools.  
+            The lower-level PMS tool dpkg forms the base of the Debian PMS.  
+            For information on dpkg see 
+            <ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem>
+    </itemizedlist>
+    </para>
+</section>
+
+<section id='configuring-the-pms'>
+    <title>Configuring the PMS</title>
+    <para>
+        Whichever PMS you are using you need to be sure that the 
+        <filename>PACKAGE_CLASSES</filename> variable in the <filename>conf/local.conf</filename>
+        file is set to reflect that system.  
+        The first value you choose for the variable specifies the package file format for the root
+        filesystem.
+        Additional values specify additional formats for convenience or testing.  
+        See the configuration file for details.
+    </para>
+    <para>
+        As an example, consider a scenario where you are using OPKG and you want to add 
+        the libglade package to sysroot.
+    </para>
+    <para>
+        First, you should generate the ipk file for the libglade package and add it 
+        into a working opkg repository.  
+        Use these commands:
+        <literallayout class='monospaced'>
+     $ bitbake libglade
+     $ bitbake package-index
+        </literallayout>
+    </para>
+    <para>
+        Next, source the environment setup script.  
+        Follow that by setting up the installation destination to point to your 
+        sysroot as <filename>&lt;sysroot dir&gt;</filename>.  
+        Finally, have an opkg configuration file <filename>&lt;conf file&gt;</filename>
+        that corresponds to the opkg repository you have just created. 
+        The following command forms should now work:
+        <literallayout class='monospaced'>
+     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; update
+     $ opkg-cl –f &lt;conf file&gt;> -o &lt;sysroot dir&gt; --force-overwrite install libglade
+     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; --force-overwrite install libglade-dbg
+     $ opkg-cl –f &lt;conf file&gt; -o &lt;sysroot dir&gt; --force-overwrite install libglade-dev
+        </literallayout>
+    </para>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/adt-manual/adt-prepare.xml

@@ -0,0 +1,244 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<chapter id='adt-prepare'>
+
+<title>Preparing to Use the Application Development Toolkit (ADT)</title>
+
+<para>
+    In order to use the ADT it must be installed, the environment setup script must be 
+    sourced, and the kernel and filesystem image specific to the target architecture must exist.  
+    This section describes how to install the ADT, set up the environment, and provides 
+    some reference information on kernels and filesystem images.
+</para>
+
+<section id='installing-the-adt'>
+    <title>Installing the ADT</title>
+    <para>
+        You can install the ADT three ways.  
+        However, we recommend configuring and running the ADT Installer script.  
+        Running this script automates much of the process for you.  
+        For example, the script allows you to install the QEMU emulator and 
+        user-space NFS, define which root filesystem profiles to download, 
+        and allows you to define the target sysroot location.
+    </para>
+    <note>
+        If you need to generate the ADT tarball you can do so using the following command:
+        <literallayout class='monospaced'>
+     $ bitbake adt-installer
+        </literallayout>
+        This command generates the file <filename>adt-installer.tar.bz2</filename>
+        in the <filename>../build/tmp/deploy/sdk</filename> directory.
+    </note>
+
+    <section id='configuring-and-running-the-adt-installer'>
+        <title>Configuring and Running the ADT Installer</title>
+        <para>
+            The ADT Installer is contained in a tarball that can be built using 
+            <filename>bitbake adt-installer</filename>. 
+            Yocto Project has a pre-built ADT Installer tarball that you can download 
+            from <filename>tmp/deploy/sdk</filename> located in the build directory.
+        </para>
+
+        <note>
+            You can install and run the ADT Installer tarball in any directory you want.
+        </note>
+
+        <para>
+            Before running the ADT Installer you need to configure it by editing 
+            the <filename>adt-installer.conf</filename> file, which is located in the 
+            directory where the ADT Installer tarball was installed.  
+            Your configurations determine which kernel and filesystem image are downloaded.  
+            The following list describes the variables you can define for the ADT Installer.  
+            For configuration values and restrictions see the comments in  
+            the <filename>adt-installer.conf</filename> file:
+
+            <itemizedlist>
+                <listitem><para><filename>YOCTOADT_IPKG_REPO</filename> – This area 
+                includes the IPKG-based packages and the root filesystem upon which 
+                the installation is based.  
+                If you want to set up your own IPKG repository pointed to by 
+                <filename>YOCTOADT_IPKG_REPO</filename>, you need to be sure that the 
+                directory structure follows the same layout as the reference directory 
+                set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>.  
+                Also, your repository needs to be accessible through HTTP.
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT-TARGETS</filename> – The machine 
+                target architectures for which you want to set up cross-development 
+                environments.
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT_QEMU</filename> – Indicates whether 
+                or not to install the emulator QEMU.
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT_NFS_UTIL</filename> – Indicates whether 
+                or not to install user-mode NFS.  
+                If you plan to use the Yocto Eclipse IDE plug-in against QEMU, 
+                you should install NFS.
+                    <note>
+                    To boot QEMU images using our userspace NFS server, you need 
+                    to be running portmap or rpcbind. 
+                    If you are running rpcbind, you will also need to add the -i 
+                    option when rpcbind starts up. 
+                    Please make sure you understand the security implications of doing this. 
+                    Your firewall settings may also have to be modified to allow 
+                    NFS booting to work.
+                    </note>
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename> - The root 
+                filesystem images you want to download.
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_&lt;arch&gt;</filename> - The 
+                root filesystem used to extract and create the target sysroot.
+                </para></listitem>
+                <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> - The 
+                location of the target sysroot that will be set up on the development machine.
+                </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            After you have configured the <filename>adt-installer.conf</filename> file, 
+            run the installer using the following command:
+            <literallayout class='monospaced'>
+     $ adt_installer
+            </literallayout>
+        </para>
+
+        <para>
+            Once the installer begins to run you are asked whether you want to run in 
+            interactive or silent mode.  
+            If you want to closely monitor the installation then choose “I” for interactive 
+            mode rather than “S” for silent mode.  
+            Follow the prompts from the script to complete the installation.
+        </para>
+
+        <para>
+            Once the installation completes, the cross-toolchain is installed in 
+            <filename>/opt/poky/$SDKVERSION</filename>.
+        </para>
+
+        <para>
+            Before using the ADT you need to run the environment setup script for 
+            your target architecture also located in <filename>/opt/poky/$SDKVERSION</filename>.
+            See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref> 
+            section for information.
+        </para>
+    </section>
+
+    <section id='using-an-existing-toolchain-tarball'>
+        <title>Using an Existing Toolchain Tarball</title>
+        <para>
+            If you do not want to use the ADT Installer you can install the toolchain 
+            and the sysroot by hand.  
+            Follow these steps:
+            <orderedlist>
+                <listitem><para>Locate and download the architecture-specific toolchain 
+                tarball from <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0'></ulink>.
+                Look in the ‘toolchain’ folder and then open up the folder that matches your 
+                host development system (i.e. 'i686' for 32-bit machines or 'x86_64' 
+                for 64-bit machines).  
+                Then, select the toolchain tarball whose name includes the appropriate 
+                target architecture.
+                <note>
+                    If you need to build the toolchain tarball use the 
+                    <filename>bitbake meta-toolchain</filename> command after you have 
+                    sourced the poky-build-init script.  
+                    The tarball will be located in the build directory at 
+                    <filename>tmp/deploy/sdk</filename> after the build.
+                </note>
+                </para></listitem>
+                <listitem><para>Make sure you are in the root directory and then expand 
+                the tarball.  
+                The tarball expands into the <filename>/opt/poky/$SDKVERSION</filename> directory.
+                </para></listitem>
+                <listitem><para>Set up the environment by sourcing the environment set up 
+                script.  
+                See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref>
+                for information.
+                </para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+
+    <section id='using-the-toolchain-from-within-the-build-tree'>
+        <title>Using the Toolchain from Within the Build Tree</title>
+        <para>
+            A final way of accessing the toolchain is from the build tree.  
+            The build tree can be set up to contain the architecture-specific cross toolchain.  
+            To populate the build tree with the toolchain you need to run the following command:
+            <literallayout class='monospaced'>  
+     $ bitbake meta-ide-support
+            </literallayout>
+        </para>
+ 
+        <para>
+            Before running the command you need to be sure that the 
+            <filename>conf/local.conf</filename> file in the build directory has 
+            the desired architecture specified for the <filename>MACHINE</filename> 
+            variable.
+            See the <filename>local.conf</filename> file for a list of values you 
+            can supply for this variable.  
+            You can populate the build tree with the cross-toolchains for more 
+            than a single architecture.  
+            You just need to edit the <filename>local.conf</filename> file and re-run 
+            the BitBake command.
+        </para>
+
+        <para>
+            Once the build tree has the toolchain you need to source the environment 
+            setup script so that you can run the cross-tools without having to locate them.  
+            See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref>
+            for information.
+        </para>
+    </section>
+</section>
+
+<section id='setting-up-the-environment'>
+    <title>Setting Up the Environment</title>
+    <para>
+        Before you can use the cross-toolchain you need to set up the environment by 
+        sourcing the environment setup script.  
+        If you used adt_installer or used an existing ADT tarball to install the ADT,
+        then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename>
+        directory.  
+        If you are using the ADT from a Poky build tree, then look in the build 
+        directory in <filename>tmp</filename> for the setup script.
+    </para>
+
+    <para> 
+        Be sure to run the environment setup script that matches the architecture for 
+        which you are developing.  
+        Environment setup scripts begin with the string “environment-setup” and include as 
+        part of their name the architecture.  
+        For example, the environment setup script for a 64-bit IA-based architecture would 
+        be the following: 
+        <literallayout class='monospaced'>
+     /opt/poky/environment-setup-x86_64-poky-linux
+        </literallayout>
+    </para>
+</section>
+
+<section id='kernels-and-filesystem-images'>
+    <title>Kernels and Filesystem Images</title>
+    <para>
+        You will need to have a kernel and filesystem image to boot using your 
+        hardware or the QEMU emulator.  
+        That means you either have to build them or know where to get them.  
+        You can find lots of details on how to get or build images and kernels for your 
+        architecture in the "Yocto Project Quick Start" found at 
+        <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'></ulink>.
+        <note> 
+            Yocto Project provides basic kernels and filesystem images for several 
+            architectures (x86, x86-64, mips, powerpc, and arm) that can be used 
+            unaltered in the QEMU emulator.  
+            These kernels and filesystem images reside in the Yocto Project release 
+            area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0/'></ulink>
+            and are ideal for experimentation within Yocto Project.
+        </note>
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/adt-manual/style.css

@@ -0,0 +1,968 @@
+/* 
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+   
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+	  Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+ 
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+.reviewer {
+  color: red;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 80%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/adt-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+  
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+} 
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption, 
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;  
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+  
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #aaa;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #aaa;
+}
+
+
+.warning {
+  background-color: #fea;
+}
+
+.caution {
+  background-color: #fea;
+}
+
+.tip {
+  background-color: #eff;
+}
+
+.note {
+  background-color: #dfc;
+}
+
+.glossary dl dt, 
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title, 
+div.colophon .title, 
+div.chapter .titlepage .title,
+div.article .titlepage .title 
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-image: url("figures/yocto-project-bw.png");
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #666666;
+   color: #fff;   
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #fff;   
+}
+
+.tip a,
+.note a {
+   color: #fff;   
+   text-decoration: underline;
+}

documentation/bsp-guide/Makefile

@@ -20,7 +20,7 @@ html:
 	xsltproc $(XSLTOPTS) -o bsp-guide.html bsp-guide-customization.xsl bsp-guide.xml
 
 tarball: html
-	tar -cvzf bsp-guide.tgz style.css bsp-guide.html figures/bsp-title.png
+	tar -cvzf bsp-guide.tgz style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png
 
 validate:
 	xmllint --postvalid --xinclude --noout bsp-guide.xml
@@ -29,7 +29,7 @@ OUTPUTS = bsp-guide.pdf bsp-guide.html
 SOURCES = *.png *.xml *.css *.svg
 
 publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
+	scp -r $(OUTPUTS) $(SOURCES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-doc/bsp-guide
 
 clean:
 	rm -f $(OUTPUTS)

documentation/bsp-guide/bsp-guide.xml

@@ -23,7 +23,7 @@
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
-                <email>richard@linux.intel.com</email>
+                <email>richard.purdie@linuxfoundation.org</email>
             </author>
         </authorgroup>
 
@@ -31,7 +31,13 @@
             <revision>
                 <revnumber>0.9</revnumber>
                 <date>27 October 2010</date>
-                <revremark>Beta Draft</revremark>
+                <revremark>This manual revision is the initial manual and corresponds to the 
+                    Yocto Project 0.9 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/bsp-guide/bsp.xml

@@ -83,7 +83,7 @@ meta-<bsp_name>/conf/layer.conf
 meta-<bsp_name>/conf/machine/*.conf
 meta-<bsp_name>/recipes-bsp/*
 meta-<bsp_name>/recipes-graphics/*            
-meta-<bsp_name>/recipes-kernel/linux/linux-yocto-stable.bbappend
+meta-<bsp_name>/recipes-kernel/linux/linux-yocto_git.bbappend
                 </programlisting>
             </para>
 
@@ -107,7 +107,7 @@ meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_prepr
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch
 meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb
-meta-crownbay/recipes-kernel/linux/linux-wrs_git.bbappend
+meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
                 </programlisting>
             </para>
 
@@ -160,7 +160,7 @@ meta-&lt;bsp_name&gt;/binary/&lt;bootable_images&gt;
             </programlisting>
 
             <para>
-                This optional area contains useful pre-built kernels and userspace filesystem 
+                This optional area contains useful pre-built kernels and user-space filesystem 
                 images appropriate to the target system.
                 This directory contains the Application Development Toolkit (ADT) and minimal
                 live images when the BSP is has been "tar-balled" and placed on the Yocto Project website. 
@@ -315,7 +315,7 @@ meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb
             <section id='bsp-filelayout-kernel'>
             <title>Linux Kernel Configuration</title>
             <programlisting>
-meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto-stable.bbappend
+meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto_git.bbappend
             </programlisting>
 
             <para>
@@ -330,27 +330,27 @@ meta-&lt;bsp_name&gt;/recipes-kernel/linux/linux-yocto-stable.bbappend
                 directory.
             </para>
             <para>
-                Suppose you use a BSP that uses the <filename>linux-yocto-stable_git.bb</filename> kernel, 
+                Suppose you use a BSP that uses the <filename>linux-yocto_git.bb</filename> kernel, 
                 which is the preferred kernel to use for developing a new BSP using the Yocto Project.
                 In other words, you have selected the kernel in your 
                 <filename>&lt;bsp_name&gt;.conf</filename> file by adding the following statement:
                 <programlisting>
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
                 </programlisting>
-                You would use the <filename>linux-yocto-stable_git.bbappend</filename> file to append 
+                You would use the <filename>linux-yocto_git.bbappend</filename> file to append 
                 specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
             </para>
             <para>
                 Now take a look at the existing "crownbay" BSP.
                 The append file used is:
                 <programlisting>
-meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
+meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend
                 </programlisting>
                 The file contains the following:
                 <programlisting>
 FILESEXTRAPATHS := "${THISDIR}/${PN}"
 COMPATIBLE_MACHINE_crownbay = "crownbay"
-KMACHINE_crownbay = "crownbay"
+KMACHINE_crownbay = "yocto/standard/crownbay"
                 </programlisting>
                 This append file adds "crownbay" as a compatible machine,
                 and additionally sets a Yocto Kernel-specific variable that identifies the name of the 
@@ -371,7 +371,7 @@ KMACHINE_crownbay = "crownbay"
                 For example, suppose you had a set of configuration options in a file called 
                 <filename>defconfig</filename>.  
                 If you put that file inside a directory named 
-                <filename class='directory'>/linux-yocto-stable</filename> and then added 
+                <filename class='directory'>/linux-yocto</filename> and then added 
                 a SRC_URI statement such as the following to the append file, those configuration
                 options will be picked up and applied when the kernel is built.
                 <programlisting>
@@ -391,13 +391,14 @@ SRC_URI += "file://defconfig \
                 </programlisting>
             </para>
             <para>
-                The FILESEXTRAPATHS variable is boilerplated here in order to make it easy to do that.
+                The FILESEXTRAPATHS variable is in boilerplate form here in order to make it easy 
+                to do that.
                 It basically allows those configuration files to be found by the build process.
             </para>
             <note><para>
                 Other methods exist to accomplish grouping and defining configuration options.
                 For example, you could directly add configuration options to the Yocto kernel 
-                <filename class='directory'>wrs_meta</filename> branch for your BSP.
+                <filename class='directory'>meta</filename> branch for your BSP.
                 The configuration options will likely end up in that location anyway if the BSP gets 
                 added to the Yocto Project. 
                 For information on how to add these configurations directly, see the 
@@ -407,7 +408,7 @@ SRC_URI += "file://defconfig \
             </para>
             <para>
                 In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified 
-                configuration options to the <filename class='directory'>wrs_meta</filename> branch.
+                configuration options to the <filename class='directory'>meta</filename> branch.
                 Not only is it easier for BSP developers to not have to worry about putting those 
                 configurations in the branch, but having the maintainers do it allows them to apply 
                 'global' knowledge about the kinds of common configuration options multiple BSPs in 
@@ -533,19 +534,22 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
             </para>
 
             <para>
-	      For cases where you can substitute something and still maintain functionality, the Poky website will make
-	      available a 'de-featured' BSP completely free of the encumbered IP.
-              In that case you can use the substitution directly and without any further licensing requirements.  
-              If present, this fully 'de-featured' BSP will be named meta-&lt;bsp_name&gt; (i.e. the
-	      normal default naming convention).  
-              If available, this is the simplest the most preferred option.
+	      For cases where you can substitute something and still maintain functionality, 
+              the Yocto Project website at 
+              <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink> 
+              will make available a 'de-featured' BSP completely free of the encumbered IP.
+              In that case you can use the substitution directly and without any further licensing
+              requirements.  
+              If present, this fully 'de-featured' BSP will be named appropriately different 
+              than the normal encumbered BSP.
+              If available, this substitution is the simplest and most preferred option.
               This, of course, assumes the resulting functionality meets requirements.
             </para>
 
             <para>
-	      If however, a non-encumbered version is unavailable or the 'free' version would provide unsuitable
-	      functionality or quality, an encumbered version can be used.  
-              Encumbered versions of a BSP are given names of the form meta-&lt;bsp_name&gt;-nonfree.
+	      If however, a non-encumbered version is unavailable or the 'free' version 
+              would provide unsuitable functionality or quality, you can use 
+              an encumbered version.  
             </para>
 
             <para>  
@@ -559,14 +563,23 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
 
 		<para>
 		  Get a license key (or keys) for the encumbered BSP by visiting 
+                  a website and providing the name of the BSP and your email address
+                  through a web form.
+                </para>
+ 
+<!--
                   <ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
 		  and give the name of the BSP and your e-mail address in the web form.
 		</para>
 
+                COMMENT:  This link is not implemented at this point.  
+
 		<programlisting>
 		  [screenshot of dialog box]
 		</programlisting>
 
+-->
+
 		<para>
 		  After agreeing to any applicable license terms, the
 		  BSP key(s) will be immediately sent to the address
@@ -609,7 +622,8 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
 		  encumbered BSP.  
                   These prompts usually take the form of instructions
 		  needed to manually fetch the encumbered package(s)
-		  and md5 sums into the required directory (e.g. the poky/build/downloads)
+		  and md5 sums into the required directory 
+                  (e.g. the <filename>poky/build/downloads</filename>).
                   Once the manual package fetch has been
 		  completed, restart the build to continue where
 		  it left off.
@@ -619,25 +633,21 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
               </listitem>
               <listitem>
 		<para>
-		  Get a full-featured BSP recipe rather than a key, by
-		  visiting
-		  <ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
-		  Accepting the license agreement(s) presented will
-		  subsequently allow you to download a tarball
-		  containing a full-featured BSP that is legally cleared for
-		  your use by the just-given license agreement(s).
-		  This method will also allow the encumbered image to
-		  be built with no change at all to the normal build
-		  process.
-		</para>
+		  Get a full-featured BSP recipe rather than a key.
+                  You can do this by visiting the applicable BSP download page from the Yocto 
+                  Project website at
+                  <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink>.
+		  BSP tarballs that have proprietary information can be downloaded after agreeing 
+                  to licensing requirements as part of the download process. 
+                  Obtaining the code this way allows you to build an encumbered image with 
+                  no changes at all as compared to the normal build. 
+                </para>
               </listitem>
 	    </orderedlist>
 	    <para>
 	      Note that the third method is also the only option available
-	      when downloading pre-compiled images generated from
-	      non-free BSPs.  
-              Those images are likewise available at
-	      <ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
+	      when downloading pre-compiled images generated from non-free BSPs.  
+              Those images are likewise available at from the Yocto Project website.
             </para> 
         </section>
 

documentation/bsp-guide/style.css

@@ -50,9 +50,13 @@ body {
   color: #333;
 }
 
+.reviewer {
+  color: red;
+}
+
 h1,h2,h3,h4,h5,h6,h7 {
   font-family: Arial, Sans;
-  color:#999999;
+  color: #00557D;
   clear: both;
 }
 
@@ -76,7 +80,7 @@ h2 {
   margin: 2em 0em 0.66em 0em;
   padding: 0.5em 0em 0em 0em;
   font-size: 1.5em;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h3.subtitle {
@@ -90,28 +94,28 @@ h3 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 140%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h4 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 120%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h5 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 110.000%;
-  border-bottom: 1px solid black;
+  font-size: 110%;
+  font-weight: bold;
 }
 
 h6 {
   margin: 1em 0em 0em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 80%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 .authorgroup {
@@ -124,7 +128,7 @@ h6 {
   padding-right: 50px;
   margin-left: 0px;
   text-align: right;
-  width: 700px;
+  width: 740px;
 }
 
 h3.author {
@@ -132,6 +136,7 @@ h3.author {
   padding: 0em 0em 0em 0em;
   font-weight: normal;
   font-size: 100%;
+  color: #333;
   clear: both;
 }
 
@@ -154,6 +159,7 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
   padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
 }
 
 .toc p,
@@ -930,7 +936,7 @@ table {
 
 .tip,
 .note {
-   background: #91ae35;
+   background: #666666;
    color: #fff;   
    padding: 20px;
    margin: 20px;

documentation/kernel-manual/Makefile

@@ -27,7 +27,7 @@ html:
 	xsltproc $(XSLTOPTS) -o kernel-manual.html yocto-project-kernel-manual-customization.xsl kernel-manual.xml
 
 tarball: html
-	tar -cvzf kernel-manual.tgz kernel-manual.html style.css figures/kernel-title.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png
+	tar -cvzf kernel-manual.tgz kernel-manual.html kernel-manual.pdf style.css figures/kernel-title.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png
 
 validate:
 	xmllint --postvalid --xinclude --noout kernel-manual.xml
@@ -36,7 +36,7 @@ OUTPUTS = kernel-manual.tgz kernel-manual.html kernel-manual.pdf
 SOURCES = *.png *.xml *.css
 
 publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
+	scp -r $(OUTPUTS) $(SOURCES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-doc/kernel-manual
 
 clean:
 	rm -f $(OUTPUTS)

documentation/kernel-manual/kernel-how-to.xml

@@ -425,18 +425,18 @@ repository.
 
                 <literallayout class='monospaced'>
      # full description of the changes
-     &gt; git whatchanged &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
-        &gt; eg: git whatchanged standard..common_pc-standard
+     &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+        &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
 
      # summary of the changes
-     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
+     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
 
      # source code changes (one combined diff)
-     &gt; git diff &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
-     &gt; git show &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
+     &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+     &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
 
      # dump individual patches per commit
-     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;bsp&gt;-&lt;kernel type&gt;
+     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
 
      # determine the change history of a particular file
      &gt; git whatchanged &lt;path to file&gt;
@@ -467,15 +467,15 @@ repository.
      # determine which branches contain a feature
      &gt; git branch --contains &lt;tag&gt;
 
-     # show the changes in a kernel type - (0.9 examples)
-     &gt; git whatchanged wrs_base..&lt;kernel type&gt;
-        &gt; eg: git whatchanged wrs_base..standard
+     # show the changes in a kernel type
+     &gt; git whatchanged yocto/base..&lt;kernel type&gt;
+        &gt; eg: git whatchanged yocto/base..yocto/standard/base
                 </literallayout>
 
                 <para>
                     You can use many other comparisons to isolate BSP changes.
                     For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or
-                    you can compare agains subsystems (e.g. git whatchanged mm).
+                    you can compare against subsystems (e.g. git whatchanged mm).
                 </para>
             </section>
         </section>
@@ -600,7 +600,7 @@ repository.
                 <para>
                     Distributed development with git is possible when you use a universally 
                     agreed-upon unique commit identifier (set by the creator of the commit) that maps to a
-                    specific changeset with a specific parent.  
+                    specific change set with a specific parent.  
                     This identifier is created for you when
                     you create a commit, and is re-created when you amend, alter or re-apply
                     a commit.  
@@ -733,10 +733,10 @@ repository.
 
                     <para>
                         For example, the following command pushes the changes from your local branch
-                        <filename>common_pc-standard</filename> to the remote branch with the same name 
-                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.27</filename>.
+                        <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name 
+                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>.
                     <literallayout class='monospaced'>
-     &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard
+     &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base
                     </literallayout>
                     </para>
 
@@ -866,9 +866,9 @@ repository.
 
                 <para>
                     The following commands illustrate some of the steps you could use to
-                    import the common_pc-standard kernel into a secondary SCM:
+                    import the yocto/standard/common-pc/base kernel into a secondary SCM:
                 <literallayout class='monospaced'>
-     &gt; git checkout common_pc-standard
+     &gt; git checkout yocto/standard/common-pc/base
      &gt; cd .. ; echo linux/.git &gt; .cvsignore
      &gt; cvs import -m "initial import" linux MY_COMPANY start
                 </literallayout>
@@ -881,8 +881,8 @@ repository.
                 <para>
                     The following commands illustrate how you can condense and merge two BSPs into a second SCM:
                 <literallayout class='monospaced'>
-     &gt; git checkout common_pc-standard
-     &gt; git merge common_pc_64-standard
+     &gt; git checkout yocto/standard/common-pc/base
+     &gt; git merge yocto/standard/common-pc-64/base
      # resolve any conflicts and commit them
      &gt; cd .. ; echo linux/.git &gt; .cvsignore
      &gt; cvs import -m "initial import" linux MY_COMPANY start
@@ -1006,9 +1006,12 @@ That's it. Configure and build.
             <title>Creating a BSP Based on an Existing Similar BSP</title>
 
             <para>
-                This section provides an example for creating a BSP that is based on an existing, and hopefully, 
-                similar one.  
-                Follow these steps and keep in mind your particular situation and differences:
+                This section provides an example for creating a BSP
+                that is based on an existing, and hopefully, similar
+                one.  It assumes you will be using a local kernel
+                repository and will be pointing the kernel recipe at
+                that.  Follow these steps and keep in mind your
+                particular situation and differences:
 
             <orderedlist>
                 <listitem><para>
@@ -1016,16 +1019,14 @@ That's it. Configure and build.
                 </para>
                 
                 <para>
-                    You can start with something in <filename>meta/conf/machine</filename>.  
-                    Or, <filename>meta-emenlow/conf/machine</filename> has an example in its own layer.
+                    You can start with something in <filename>meta/conf/machine</filename> - <filename>
+                    meta/conf/machine/atom-pc.conf</filename> for example.  Or, you can start with a machine 
+                    configuration from any of the BSP layers in the meta-intel repository at 
+                    <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as 
+                    <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>.
                 </para>
                 
                 <para>
-                    The most up-to-date machines that are probably most similar to yours and that you might want 
-                    to look at are <filename>meta/conf/machine/atom-pc.conf</filename> and 
-                    <filename>meta-emenlow/conf/machine/emenlow.conf</filename>.  
-                    Both of these files were either just added or upgraded to use the Yocto Project kernel 
-                    at <ulink url='http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/'></ulink>.
                     The main difference between the two is that "emenlow" is in its own layer.
                     It is in its own layer because it needs extra machine-specific packages such as its 
                     own video driver and other supporting packages.  
@@ -1049,19 +1050,21 @@ That's it. Configure and build.
                 <para>
                     As an example consider this:
                     <itemizedlist>
-                        <listitem><para>Copy meta-emenlow</para></listitem>
+                        <listitem><para>Copy meta-emenlow to meta-mymachine</para></listitem>
                         <listitem><para>Fix or remove anything you do not need.  
                         For this example the only thing left was the kernel directory with a 
-                        <filename>linux-yocto-stable_git.bbappend</filename> file 
-                        (linux-yocto-stable is the kernel listed in 
-                        <filename>meta-crownbay/conf/machine/crownbay.conf</filename></para></listitem>.
+                        <filename>linux-yocto_git.bbappend</filename>
+                        file
+                        and <filename>meta-mymachine/conf/machine/mymachine.conf</filename>
+                        (linux-yocto is the kernel listed in
+                        <filename>meta-emenlow/conf/machine/emenlow.conf</filename>)</para></listitem>.
                         <listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename> 
-                        so the new layer can be found by Bitbake.</para></listitem>
+                        so the new layer can be found by BitBake.</para></listitem>
                     </itemizedlist>
                 </para></listitem>
                 
                 <listitem><para>
-                    Get an image with a working kernel built.
+                    Create a machine branch for your machine.
                 </para>
 
                 <para>
@@ -1070,58 +1073,52 @@ That's it. Configure and build.
                     To create this branch first create a bare clone of the Yocto Project git repository.
                     Next, create a local clone of that:
                     <literallayout class='monospaced'>
-     $ git clone --bare git://git.pokylinux.org/linux-2.6-windriver.git
-     linux-2.6-windriver.git
-     $ git clone linux-2.6-windriver.git linux-2.6-windriver
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-2.6.37.git
+     linux-yocto-2.6.37.git
+     $ git clone linux-yocto-2.6.37.git linux-yocto-2.6.37
                     </literallayout>
                 </para>
                 
                 <para>
                     Now create a branch in the local clone and push it to the bare clone:
                     <literallayout class='monospaced'>
-     $ git checkout -b crownbay-standard origin/standard 
-     $ git push origin crownbay-standard:crownbay-standard
+     $ git checkout -b yocto/standard/mymachine origin/yocto/standard/base
+     $ git push origin yocto/standard/mymachine:yocto/standard/mymachine
                     </literallayout>
-                </para>
-               
-                <para>
-                    At this point, your git tree should compile.
                 </para></listitem>
-                
+               
                 <listitem><para>
-                    In a layer, create a <filename>linux-yocto-stable_git.bbappend</filename> 
+                    In a layer, create a <filename>linux-yocto_git.bbappend</filename> 
                     file with the following:
                 </para>       
                 
                 <para>
                     <literallayout class='monospaced'>
-     COMPATIBLE_MACHINE = ${MACHINE}
+     FILESEXTRAPATHS := "${THISDIR}/${PN}"
+     COMPATIBLE_MACHINE_mymachine = "mymachine"
 
      # It is often nice to have a local clone of the kernel repository, to
      # allow patches to be staged, branches created, and so forth.  Modify
      # KSRC to point to your local clone as appropriate.
 
-     # KSRC ?= /path/to/your/bare/clone/yocto-kernel
+     KSRC ?= /path/to/your/bare/clone/for/example/linux-yocto-2.6.37.git
 
-     # KMACHINE is the branch to be built, or alternateively 
+     # KMACHINE is the branch to be built, or alternatively 
      # KBRANCH can be directly set.
+     # KBRANCH is set to KMACHINE in the main linux-yocto_git.bb
+     # KBRANCH ?= "${LINUX_KERNEL_TYPE}/${KMACHINE}"
 
-     # KBRANCH ?= "${KMACHINE}-${LINUX_KERNEL_TYPE}"
+     KMACHINE_mymachine  = "yocto/standard/mymachine"
 
-     # SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+     SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
                     </literallayout>
                 </para>
 
-                <para>
-                    In the previous sample file you need to update and remove the comment from 
-                    the KSRC assignment and also remove the comment from the SRC_URI line.
-                </para>
-                
                 <para>
                     After doing that, select the machine in <filename>build/conf/local.conf</filename>:
                     <literallayout class='monospaced'>
       #
-      MACHINE ?= "crownbay"
+      MACHINE ?= "mymachine"
       #
                     </literallayout>
                 </para>
@@ -1131,6 +1128,10 @@ That's it. Configure and build.
                     <literallayout class='monospaced'>
      $ bitbake poky-image-sato-live
                     </literallayout>
+                </para></listitem>
+
+                <listitem><para>
+                    Modify the kernel configuration for your machine.
                 </para>
                 
                 <para>
@@ -1149,17 +1150,22 @@ That's it. Configure and build.
                     And, another <filename>.cfg</filename> file would contain:
                     <literallayout class='monospaced'>
      CONFIG_LOG_BUF_SHIFT=18
+                    </literallayout>
 
-     http://git.pokylinux.org/cgit/cgit.cgi/linux-2.6-windriver/
+                <para>
+                    These config fragments could then be picked up and
+                    applied to the kernel .config by appending them to the kernel SRC_URI:
+                </para>
 
-     SRC_URI_append_crownbay = " file://some.cfg \
+                    <literallayout class='monospaced'>
+     SRC_URI_append_mymachine = " file://some.cfg \
                                   file://other.cfg \
                                "
                     </literallayout>
                 </para>
                 
                 <para>
-                    You could also add these directly to the git repository <filename>wrs_meta</filename>
+                    You could also add these directly to the git repository <filename>meta</filename>
                     branch as well.
                     However, the former method is a simple starting point.
                 </para></listitem>
@@ -1173,7 +1179,7 @@ That's it. Configure and build.
                 <para>
                     Practically speaking, to generate the patches, you'd go to the source in the build tree:
                     <literallayout class='monospaced'>
-     build/tmp/work/crownbay-poky-linux/linux-yocto-2.6.34+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
+     build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
 0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux
                     </literallayout>
                 </para>
@@ -1182,7 +1188,7 @@ That's it. Configure and build.
                     Then, modify the code there, using quilt to save the changes, and recompile until 
                     it works:
                     <literallayout class='monospaced'>
-     $ bitbake -c compile -f linux-yocto-stable
+     $ bitbake -c compile -f linux-yocto
                     </literallayout>
                 </para></listitem>
                 
@@ -1191,7 +1197,7 @@ That's it. Configure and build.
                     SRC_URI location.
                     The patch is applied the next time you do a clean build.
                     Of course, since you have a branch for the BSP in git, it would be better to put it there instead.
-                    For example, in this case, commit the patch to the "crownbay-standard" branch, and during the 
+                    For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the 
                     next build it is applied from there.
                 </para></listitem>
             </orderedlist>

documentation/kernel-manual/kernel-manual.xml

@@ -31,7 +31,13 @@
             <revision>
                 <revnumber>0.9</revnumber>
                 <date>24 November 2010</date>
-                <revremark>Beta Draft</revremark>
+                <revremark>This revision is the initial document draft and corresponds with 
+                    the Yocto Project 0.9 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/kernel-manual/style.css

@@ -56,7 +56,7 @@ body {
 
 h1,h2,h3,h4,h5,h6,h7 {
   font-family: Arial, Sans;
-  color:#999999;
+  color: #00557D;
   clear: both;
 }
 
@@ -79,9 +79,8 @@ h2.subtitle {
 h2 {
   margin: 2em 0em 0.66em 0em;
   padding: 0.5em 0em 0em 0em;
-  font-size: 2em;
+  font-size: 1.5em;
   font-weight: bold;
-  color: black;
 }
 
 h3.subtitle {
@@ -94,29 +93,29 @@ h3.subtitle {
 h3 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 150%;
+  font-size: 140%;
   font-weight: bold;
-  color: black;
-  border-bottom: 2px solid black;
 }
 
 h4 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 130%;
-  border-bottom: 1px solid black;
+  font-size: 120%;
+  font-weight: bold;
 }
 
 h5 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 120%;
+  font-size: 110%;
+  font-weight: bold;
 }
 
 h6 {
   margin: 1em 0em 0em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 100%;
+  font-size: 80%;
+  font-weight: bold;
 }
 
 .authorgroup {
@@ -124,12 +123,12 @@ h6 {
   background-repeat: no-repeat;
   padding-top: 256px;
   background-image: url("figures/kernel-title.png");
-  background-position: top;
+  background-position: left top;
   margin-top: -256px;
   padding-right: 50px;
-  margin-left: 50px;
+  margin-left: 0px;
   text-align: right;
-  width: 700px;
+  width: 740px;
 }
 
 h3.author {
@@ -137,6 +136,7 @@ h3.author {
   padding: 0em 0em 0em 0em;
   font-weight: normal;
   font-size: 100%;
+  color: #333;
   clear: both;
 }
 
@@ -159,6 +159,7 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
   padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
 }
 
 .toc p,
@@ -246,7 +247,6 @@ div.legalnotice p.legalnotice-title {
 p {
   line-height: 1.5em;
   margin-top: 0em;
-  color: black; font-size: 100%;
   
 }
 
@@ -946,7 +946,7 @@ table {
 
 .tip,
 .note {
-   background: #91ae35;
+   background: #666666;
    color: #fff;   
    padding: 20px;
    margin: 20px;

documentation/kernel-manual/yocto-project-kernel-manual-customization.xsl

@@ -3,6 +3,6 @@
   
   <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
 
-  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
+<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
 
 </xsl:stylesheet>

documentation/poky-ref-manual/Makefile

@@ -30,7 +30,7 @@ OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf
 SOURCES = *.png *.xml *.css *.svg
 
 publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
+	scp -r $(OUTPUTS) $(SOURCES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-doc/poky-ref-manual
 
 clean:
 	rm -f $(OUTPUTS)

documentation/poky-ref-manual/development.xml

@@ -12,7 +12,7 @@
     </para>
 
         <section id="platdev-appdev-external-sdk">
-        <title>External Development Using the Poky SDK</title>
+        <title>External Development Using the Application Development Toolkit (ADT)</title>
         <para>
             The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and 
             libraries suitable for application development outside of Poky. 
@@ -45,17 +45,41 @@
         </section>
 
         <section id="using-the-eclipse-and-anjuta-plug-ins">
-        <title>Using the Eclipse and Anjuta Plug-ins</title>
+        <title>Using the Eclipse Plug-in</title>
         <para>
-            Yocto Project supports both Anjuta and Eclipse IDE plug-ins to make developing software
-            easier for the application developer. The plug-ins provide capability
-            extensions to the graphical IDE allowing for cross compilation, 
-            deployment and execution of the output in a QEMU emulation session. 
-            Support of these plug-ins also allows for cross debugging and
-            profiling.  Additionally, the Eclipse plug-in provides a suite of tools 
+            The current release of the Yocto Project supports the Eclipse IDE plug-in
+            to make developing software easier for the application developer. 
+            The plug-in provides capability extensions to the graphical IDE to allow
+            for cross compilation, deployment and execution of the output in a QEMU 
+            emulation session. 
+            Support of the Eclipse plug-in also allows for cross debugging and
+            profiling.  
+            Additionally, the Eclipse plug-in provides a suite of tools 
             that allows the developer to perform remote profiling, tracing, collection of 
             power data, collection of latency data and collection of performance data.
         </para>
+        <note>
+            The current release of the Yocto Project no longer supports the Anjuta plug-in.
+            However, the Poky Anjuta Plug-in is available to download directly from the Poky 
+            Git repository located through the web interface at
+            <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
+            The community is free to continue supporting it beyond the Yocto Project 0.9
+            Release.            
+        </note>
+        <para>
+            To use the Eclipse plug-in you need the Eclipse Framework (Helios 3.6.1) along 
+            with other plug-ins installed into the Eclipse IDE.
+            Once you have your environment setup you need to configure the Eclipse plug-in.
+            For information on how to install and configure the Eclipse plug-in, see the
+            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'>
+            "Working Within Eclipse"</ulink> chapter in the 
+            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
+            "Application Development Toolkit (ADT) User's Guide."</ulink>
+         </para>
+
+
+
+<!--
 
             <section id="the-eclipse-plug-in">
             <title>The Eclipse Plug-in</title>
@@ -67,12 +91,13 @@
                 <literallayout class='monospaced'>
      Help -> Install New Software
                 </literallayout>
-                Specify the target URL as <ulink url='http://www.yoctoproject.org/downloads/eclipse-plug-in/'></ulink>.
+                Specify the target URL as 
+                <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>.
             </para>
             <para>
                 If you want to download the source code for the plug-in you can find it in the Poky 
                 git repository, which has a web interface, and is located at
-                <ulink url="http://git.pokylinux.org/cgit.cgi/eclipse-poky"></ulink>.
+                <ulink url="http://git.yoctoproject.org"></ulink> under IDE Plugins.
             </para>
   
                 <section id="installing-and-setting-up-the-eclipse-ide">
@@ -301,15 +326,14 @@
                 Plug-in are all required. 
                 The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand 
                 labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or 
-                directly from the Poky Git repository located at 
-                <ulink url="git://git.pokylinux.org/anjuta-poky"></ulink>.
-                You can also access a web interface to the repository at
-                <ulink url="http://git.pokylinux.org/?p=anjuta-poky.git;a=summary"></ulink>.
+                directly from the Poky Git repository located at git://git.yoctoproject.org/anjuta-poky.
+                You can access the source code from a web interface to the repository at
+                <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
              </para>
              <para>
                 See the README file contained in the project for more information on 
                 Anjuta dependencies and building the plug-in. 
-                If you want to disable remote gdb debugging, pass the "--disable-gdb-integration" switch when 
+                If you want to disable remote gdb debugging, pass the "&dash;&dash;disable-gdb-integration" switch when 
                 you configure the plug-in.
             </para>
                 <section id="setting-up-the-anjuta-plugin">
@@ -416,6 +440,10 @@
                 </para>
                 </section>
             </section>
+
+
+-->
+
         </section>
 
         <section id="platdev-appdev-qemu">
@@ -691,7 +719,7 @@
                 </literallayout>
                 Once the binary is built you can find it here: 
                 <programlisting>
-tmp/sysroots/&lt;host-arch&lt;/usr/bin/&lt;target-abi&gt;-gdb 
+tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb 
                 </programlisting>
             </para>
 
@@ -909,8 +937,8 @@ $ opreport -cl
 
         <para>
             A graphical user interface for OProfile is also available. 
-            You can download and build it from svn at
-            <ulink url="http://svn.o-hand.com/repos/oprofileui/trunk/"></ulink>. 
+            You can download and build it from the Yocto Project at
+            <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. 
             If the "tools-profile" image feature is selected, all necessary binaries
             are installed onto the target device for OProfileUI interaction.
         </para>
@@ -926,7 +954,7 @@ $ opreport -cl
             </caption>
          </mediaobject>
          </screenshot>
--->
+
         <para>
             In order to convert the data in the sample format from the target
             to the host you need the <filename>opimport</filename> program. 
@@ -935,13 +963,12 @@ $ opreport -cl
             <ulink url='http://debian.o-hand.com/'>OpenedHand repository</ulink>.
             We recommend using OProfile 0.9.3 or greater. 
         </para>
+-->
         <para>
             Even though Poky usually includes all needed patches on the target device, you 
             might find you need other OProfile patches for recent OProfileUI features.
-            If so, see the <ulink url='http://svn.o-hand.com/repos/oprofileui/trunk/README'>
+            If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'>
             OProfileUI README</ulink> for the most recent information.
-            You can also see <ulink url="http://labs.o-hand.com/oprofileui">OProfileUI website
-            </ulink> for general information on the OProfileUI project. 
         </para>
 
         <section id="platdev-oprofile-oprofileui-online">
@@ -1038,7 +1065,7 @@ $ opreport -cl
                 a "vmlinux" file that matches the running kernel is available. 
                 In Poky, that file is usually located in 
                 <filename>/boot/vmlinux-KERNELVERSION</filename>, where KERNEL-version is the 
-                version of the kernel (e.g. 2.6.23). 
+                version of the kernel. 
                 Poky generates separate vmlinux packages for each kernel
                 it builds so it should be a question of just making sure a matching package is 
                 installed - for example: <filename>opkg install kernel-vmlinux</filename>. 

documentation/poky-ref-manual/extendpoky.xml

@@ -46,7 +46,7 @@
                 "do_install" tasks.
                 The <glossterm><link linkend='var-S'>S</link></glossterm> variable defines the 
                 directory containing the source code, which is set to <glossterm><link linkend='var-WORKDIR'>
-                WORKDIR</link></glossterm> in this case - the directory Bitbake uses for the build.
+                WORKDIR</link></glossterm> in this case - the directory BitBake uses for the build.
             </para>
             <programlisting>
 DESCRIPTION = "Simple helloworld application"
@@ -68,7 +68,7 @@ do_install() {
 }
             </programlisting>
             <para>
-                By default, the "helloworld", "helloworld-dbg" and "hellworld-dev"
+                By default, the "helloworld", "helloworld-dbg" and "helloworld-dev"
                 packages are built. 
                 For information on how to customize the packaging process, see
                 <link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link>.
@@ -81,7 +81,7 @@ do_install() {
                 Applications that use autotools such as <filename>autoconf</filename> and 
                 <filename>automake</filename> require a recipe that has a source archive listed in 
                 <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> and 
-                <filename>also inherits autotools</filename>, which instructs Bitbake to use the
+                also inherits autotools, which instructs BitBake to use the
                 <filename>autotools.bbclass</filename> file, which contains the definitions of all the steps
                 needed to build an autotooled application.
                 The result of the build is automatically packaged. 
@@ -114,13 +114,13 @@ inherit autotools gettext
             <para>
                 Applications that use GNU <filename>make</filename> also require a recipe that has
                 the source archive listed in <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. 
-                You do not need to add a <function>do_compile</function> step since by default Bitbake 
+                You do not need to add a "do_compile" step since by default BitBake 
                 starts the <filename>make</filename> command to compile the application. 
                 If you need additional <filename>make</filename> options you should store them in the 
                 <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable.
-                Bitbake passes these options into the <filename>make</filename> GNU invocation. 
+                BitBake passes these options into the <filename>make</filename> GNU invocation. 
                 Note that a "do_install" task is still required.
-                Otherwise Bitbake runs an empty "do_install" task by default. 
+                Otherwise BitBake runs an empty "do_install" task by default. 
             </para>
             <para>
                 Some applications might require extra parameters to be passed to the compiler.
@@ -209,8 +209,8 @@ FILES_sxpm = "${bindir}/sxpm"
             <title>Post Install Scripts</title>
 
             <para>
-                To add a post-installation script to a package, add a <function>pkg_postinst_PACKAGENAME()
-                </function> function to the <filename>.bb</filename> file and use 
+                To add a post-installation script to a package, add a <filename>pkg_postinst_PACKAGENAME()
+                </filename> function to the <filename>.bb</filename> file and use 
                 <filename>PACKAGENAME</filename> as the name of the package you want to attach to the 
                 <filename>postinst</filename> script.
                 Normally <glossterm><link linkend='var-PN'>PN</link></glossterm> can be used, which 
@@ -298,8 +298,8 @@ IMAGE_INSTALL += "strace"
             <para>
                 For complex custom images, the best approach is to create a custom task package
                 that is used to build the image or images. 
-                A good example of a tasks package is <filename>meta/recipes-sato/tasks/task-poky.bb
-                </filename>. 
+                A good example of a tasks package is 
+                <filename>meta/recipes-sato/tasks/task-poky.bb</filename>. 
                 The <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> 
                 variable lists the task packages to build along with the complementary
                 -dbg and -dev packages. 
@@ -364,6 +364,16 @@ RRECOMMENDS_task-custom-tools = "\
                 Users can add extra features by extending the class or creating a custom class for use 
                 with specialized image <filename>.bb</filename> files.
             </para>
+            <para>
+                Poky ships with two SSH servers you can use in your images: Dropbear and OpenSSH. 
+                Dropbear is a minimal SSH server appropriate for resource-constrained environments,
+                while OpenSSH is a well-known standard SSH server implementation.
+                By default, poky-image-sato is configured to use Dropbear.
+                The poky-image-basic and poky-image-lsb images both include OpenSSH.
+                To change these defaults, edit the <filename>IMAGE_FEATURES</filename> variable
+                so that it sets the image you are working with to include ssh-server-dropbear 
+                or ssh-server-openssh.
+            </para>
         </section>
 
         <section id='usingpoky-extend-customimage-localconf'>
@@ -484,7 +494,7 @@ COMPATIBLE_MACHINE = '(qemux86|qemumips)'
             <title>Adding a Formfactor Configuration File</title>
             <para>
                 A formfactor configuration file provides information about the 
-                target hardware on which Poky is running, and information that Poky cannot 
+                target hardware on which Poky is running and information that Poky cannot 
                 obtain from other sources such as the kernel.  
                 Some examples of information contained in a formfactor configuration file include 
                 framebuffer orientation, whether or not the system has a keyboard, 
@@ -495,10 +505,10 @@ COMPATIBLE_MACHINE = '(qemux86|qemumips)'
                 Reasonable defaults are used in most cases, but if customization is 
                 necessary you need to create a <filename>machconfig</filename> file 
                 under <filename>meta/packages/formfactor/files/MACHINENAME/</filename>,
-                where <literal>MACHINENAME</literal> is the name for which this information
+                where <filename>MACHINENAME</filename> is the name for which this information
                 applies. 
                 For information about the settings available and the defaults, see 
-                <filename>meta/packages/formfactor/files/config</filename>. 
+                <filename>meta/recipes-bsp/formfactor/files/config</filename>. 
                 Following is an example for qemuarm:
             </para>
             <programlisting>
@@ -519,7 +529,7 @@ DISPLAY_SUBPIXEL_ORDER=vrgb
     <section id="usingpoky-changes">
         <title>Making and Maintaining Changes</title>
         <para>
-            Because Poky offers extreme configurability and flexibility, we recognize that people will want 
+            Because Poky is extremely configurable and flexible, we recognize that people will want 
             to extend, configure or optimize Poky for their specific uses.
             To best keep pace with future Poky changes we recommend you make controlled changes to Poky.
         </para>
@@ -531,12 +541,12 @@ DISPLAY_SUBPIXEL_ORDER=vrgb
         </para>
 
         <section id="usingpoky-changes-layers">
-          <title>Bitbake Layers</title>
+          <title>BitBake Layers</title>
           <para>
                 Often, people want to extend Poky either by adding packages
                 or by overriding files contained within Poky to add their own
                 functionality. 
-                Bitbake has a powerful mechanism called
+                BitBake has a powerful mechanism called
                 "layers", which provides a way to handle this extension in a fully
                 supported and non-invasive fashion.
            </para>
@@ -565,7 +575,7 @@ BBLAYERS = " \
            </para>
 
           <para>
-               Bitbake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
+               BitBake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
                and adds the recipes, classes and configuration contained within the layer to Poky.
                To create your own layer, independent of the main Poky repository,
                simply create a directory with a <filename>conf/layer.conf</filename> file and
@@ -603,14 +613,14 @@ BBFILE_PRIORITY_emenlow = "6"
                 Note the use of the <glossterm><link linkend='var-LAYERDIR'>LAYERDIR</link></glossterm> 
                 variable with the immediate expansion operator.
                 The LAYERDIR variable expands to the directory of the current layer and
-                requires the immediate expansion operator so that Bitbake does not wait to expand the variable 
+                requires the immediate expansion operator so that BitBake does not wait to expand the variable 
                 when it's parsing a different directory.
             </para>
             <para>
-                Bitbake can locate where other bbclass and configuration files are applied through 
+                BitBake can locate where other bbclass and configuration files are applied through 
                 the <glossterm><link linkend='var-BBPATH'>BBPATH</link></glossterm>
                 environment variable. 
-                For these cases, Bitbake uses the first file with the matching name found in BBPATH.
+                For these cases, BitBake uses the first file with the matching name found in BBPATH.
                 This is similar to the way the PATH variable is used for binaries. 
                 We recommend, therefore, that you use unique bbclass and configuration file names in your
                 custom layer.
@@ -664,7 +674,7 @@ BBFILE_PRIORITY_emenlow = "6"
     variables allowing moves to be made towards generating checksums and allowing
     use of the dependency information in other parts of bitbake.
     
-    Signed-off-by: Richard Purdie rpurdie@linux.intel.com
+    Signed-off-by: Richard Purdie richard.purdie@linuxfoundation.org
             </literallayout>
 
             <para>
@@ -704,7 +714,7 @@ BBFILE_PRIORITY_emenlow = "6"
                 Usually, version increases occur only to packages.
                 However, if for some reason PV changes but does not increase, you can increase the 
                 <glossterm><link linkend='var-PE'>PE</link></glossterm> variable (Package Epoch).
-                The PE variable defaults to '0'.
+                The PE variable defaults to "0".
             </para>
             <para>
                 Version numbering strives to follow the 
@@ -737,7 +747,7 @@ BBFILE_PRIORITY_emenlow = "6"
             <para>
                 The core component of any development effort with Poky is often an 
                 automated build testing framework and an image generation process. 
-                You can use these core components to check that the metadata is buildable, 
+                You can use these core components to check that the metadata can be built, 
                 highlight when commits break the build, and provide up-to-date images that 
                 allow people to test the end result and use it as a base platform for further 
                 development. 
@@ -813,7 +823,8 @@ BBFILE_PRIORITY_emenlow = "6"
             For a standard recipe not related to 
             <glossterm><link linkend='var-MACHINE'>MACHINE</link></glossterm> the location is
             <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
-            For target device-dependent packages you should use the MACHINE variable instead of 
+            For target device-dependent packages you should use the <filename>MACHINE</filename>
+            variable instead of 
             <glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></glossterm> 
             in the directory name.
         </para>
@@ -854,19 +865,19 @@ BBFILE_PRIORITY_emenlow = "6"
                 into the new patch file:
 
                 <literallayout class='monospaced'>
-quilt new NAME-OF-PATCH.patch
+     quilt new NAME-OF-PATCH.patch
                 </literallayout>
 
                 After notifying quilt, add all modified files into that patch:
                 <literallayout class='monospaced'>
-quilt add file1 file2 file3
+     quilt add file1 file2 file3
                 </literallayout>
 
                 You can now start editing. 
                 Once you are done editing, you need to use quilt to generate the final patch that 
                 will contain all your modifications.
                 <literallayout class='monospaced'>
-quilt refresh
+     quilt refresh
                 </literallayout>
 
                 You can find the resulting patch file in the
@@ -959,7 +970,7 @@ LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
                 This practice allow you to just track the "COPYING" file as long as it is kept up to date. 
             </para>
             <tip>
-                If you specify an empty or invalid "md5" parameter, Bitbake returns an md5 mis-match 
+                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
                 error and displays the correct "md5" parameter value during the build. The correct parameter
                 is also captured in the build log. 
             </tip>

documentation/poky-ref-manual/faq.xml

@@ -108,7 +108,7 @@
                 </listitem>
                 <listitem>
                     <para>
-                    Send us bitbake recipes if you have them (see the Poky handbook to find out how to create recipes)
+                    Send us BitBake recipes if you have them (see the Poky handbook to find out how to create recipes)
                     </para>
                 </listitem>
             </itemizedlist>
@@ -148,7 +148,7 @@
         </question>
         <answer>
             <para>
-                To add a package you need to create a bitbake recipe - see the Poky handbook to find out how to create a recipe.
+                To add a package you need to create a BitBake recipe - see the Poky handbook to find out how to create a recipe.
             </para>
         </answer>
     </qandaentry>
@@ -248,7 +248,8 @@
     <qandaentry>
         <question>
             <para>
-                I see lots of 404 responses for files on http://pokylinux.org/sources/*. Is something wrong?
+                I see lots of 404 responses for files on 
+                http://autobuilder.yoctoproject.org/sources/*. Is something wrong?
             </para>
         </question>
         <answer>
@@ -331,22 +332,186 @@
         </question>
         <answer>
             <para>
-                If the same build is failing in totally different and random ways the most likely explaination is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is senstive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues.
+                If the same build is failing in totally different and random ways the most likely explanation is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is sensitive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues.
             </para>
         </answer>
     </qandaentry>
     <qandaentry>
         <question>
             <para>
-                What do we need to ship for licence complience?
+                What do we need to ship for license compliance?
             </para>
         </question>
         <answer>
             <para>
-                This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL complience there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built.
+                This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL compliance there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built.
             </para>
         </answer>
     </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I disable the cursor on my touchscreen device?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You need to create a form factor file as described in 
+                <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
+                and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one.
+                <literallayout class='monospaced'>
+     HAVE_TOUCHSCREEN=1
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I make sure connected network interfaces are brought up by default?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The default interfaces file provided by the netbase recipe does not 
+                automatically bring up network interfaces. 
+                Therefore you will need to add a BSP-specific netbase that includes an interfaces 
+                file.
+                See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
+                for information on creating these types of miscellaneous recipe files.
+            </para>
+            <para>
+                For example, add the following files to your layer:
+                <literallayout class='monospaced'>
+     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
+     meta-MACHINE/recipes-bsp/netbase/netbase_4.44.bbappend
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I create images with more free space?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Images are created to be 1.2 times the size of the populated root filesystem. 
+                To modify this ratio so that there is more free space available you need to 
+                set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>.  
+                For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets 
+                the image size ratio to one and a half times the size of the populated 
+                root filesystem.
+                <literallayout class='monospaced'>
+     IMAGE_OVERHEAD_FACTOR = "1.5"
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How does Poky obtain source code and will it work behind my firewall or proxy server?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The way Poky obtains source code is highly configurable.
+                You can setup Poky to get source code in most environmnents if 
+                HTTP transport is available.
+            </para>
+            <para>
+                When Poky searches for source code it first tries the local download directory.
+                If that location fails, Poky tries PREMIRRORS, the upstream source, 
+                and then MIRRORS in that order.
+            </para>
+            <para>
+                By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources, 
+                upstreams for normal tarballs and then falls back to a number of other mirrors 
+                including the Yocto Project source mirror if those fail.
+            </para>
+            <para>
+                As an example, you could add a specific server for Poky to attempt before any
+                others by adding something like the following to the <filename>local.conf</filename>
+                configuration file:
+                <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
+     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
+     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
+                </literallayout>
+            </para>
+            <para>
+                These changes cause Poky to intercept GIT, FTP, HTTP, and HTTPS
+                requests and direct them to the <filename>http://</filename> sources mirror.
+                You can use <filename>file://</filename> urls to point to local directories 
+                or network shares as well.
+            </para>
+            <para>
+                Aside from the previous technique, these options also exist:
+                <literallayout class='monospaced'>
+     BB_NO_NETWORK = "1"
+                </literallayout>
+             </para>
+             <para>
+                 This statement tells BitBake to throw an error instead of trying to access the 
+                 Internet.
+                 This technique is useful if you want to ensure code builds only from local sources.
+             </para>
+             <para>
+                 Here is another technique:
+                 <literallayout class='monospaced'>
+     BB_FETCH_PREMIRRORONLY = "1"
+                 </literallayout>
+             </para>
+             <para>
+                 This statement limits Poky to pulling source from the PREMIRRORS only.
+                 Again, this technique is useful for reproducing builds.
+             </para>
+             <para>
+                 Here is another technique:
+                 <literallayout class='monospaced'>
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+                 </literallayout>
+             </para>
+             <para>
+                 This statement tells Poky to generate mirror tarballs.
+                 This technique is useful if you want to create a mirror server.
+                 If not, however, the technique can simply waste time during the build.
+             </para>
+             <para>
+                 Finally, consider an example where you are behind an HTTP-only firewall.
+                 You could make the following changes to the <filename>local.conf</filename>
+                 configuration file as long as the premirror server is up to date:
+                 <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
+     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
+     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
+     BB_FETCH_PREMIRRORONLY = "1" 
+                 </literallayout>
+             </para>
+             <para>
+                 These changes would cause Poky to successfully fetch source over HTTP and 
+                 any network accesses to anything other than the premirror would fail.
+             </para>
+             <para>
+                 Poky also honors the standard environment variables 
+                 <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
+                 <filename>https_proxy</filename>, and <filename>all_proxy</filename>
+                 to redirect requests through proxy servers.
+             </para>
+        </answer>
+    </qandaentry>
+
+
+
 </qandaset>
 </appendix>
 <!-- 

documentation/poky-ref-manual/introduction.xml

@@ -8,8 +8,8 @@
     <title>Welcome to Poky!</title>
 
     <para>
-        Poky is the build tool in Yocto Project.
-        Yocto Project uses Poky to build images (kernel, system, and application software) for 
+        Poky is the build tool in the Yocto Project.
+        The Yocto Project uses Poky to build images (kernel, system, and application software) for 
         targeted hardware.
     </para>
 
@@ -69,7 +69,7 @@
 
     <para>
         Poky has a growing open source community and is also backed up by commercial organizations 
-        including <ulink url="http://www.intel.com/">Intel Corporation</ulink>.
+        including Intel&reg; Corporation.
     </para>
 </section>
 
@@ -78,7 +78,8 @@
     <para>
         The sections in this reference manual describe different aspects of Poky. 
         The <link linkend='usingpoky'>'Using Poky'</link> section provides an overview of the components 
-        that make up Poky followed by information about using Poky and debugging images created in Yocto Project. 
+        that make up Poky followed by information about using Poky and debugging images created in 
+        the Yocto Project. 
         The <link linkend='extendpoky'>'Extending Poky'</link> and 
         <link linkend='bsp'>'Board Support Packages'</link> sections provide information 
         about how to extend and customize Poky along with advice on how to manage these changes. 
@@ -90,7 +91,7 @@
     </para>
 
     <para>
-        This manual applies to Poky Release 4.0 (laverne).
+        This manual applies to Poky Release 5.0 (Bernard).
     </para>
 </section>
 
@@ -118,7 +119,7 @@
         <title>Releases</title>
 
         <para>Periodically, we make releases of Poky available
-            at <ulink url='http://pokylinux.org/releases/'/>.
+            at <ulink url='http://yoctoproject.org/downloads/poky/'/>.
             These releases are more stable and more rigorously tested than the nightly development images.
         </para>
     </section>
@@ -129,7 +130,7 @@
         <para>
             We make nightly builds of Poky for testing purposes and to make the
             latest developments available. The output from these builds is available
-            at <ulink url='http://autobuilder.pokylinux.org/'/>.
+            at <ulink url='http://autobuilder.yoctoproject.org/'/>.
             The numbers used in the builds increase for each subsequent build and can be used to 
             reference a specific build.
         </para>
@@ -152,8 +153,8 @@
 
         <para>
             Poky is available from our git repository located at
-            git://git.pokylinux.org/poky.git; a web interface to the repository
-            can be accessed at <ulink url='http://git.pokylinux.org/'/>.
+            git://git.yoctoproject.org/poky.git; a web interface to the repository
+            can be accessed at <ulink url='http://git.yoctoproject.org/'/>.
         </para>
 
         <para>

documentation/poky-ref-manual/poky-ref-manual.xml

@@ -47,6 +47,11 @@
                 <date>24 November 2010</date>
                 <revremark>Poky Master Documentation</revremark>
             </revision>
+            <revision>
+                <revnumber>5.0+git</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/poky-ref-manual/ref-bitbake.xml

@@ -33,16 +33,16 @@
 
         <para>
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
-            Poky keeps this file in <filename class="directory">meta/conf/</filename>.
-            BitBake finds it by examining the <varname>BBPATH</varname> environment 
-            variable and looking for the <filename class="directory">meta/conf/</filename> 
+            Poky keeps this file in <filename>meta/conf/</filename>.
+            BitBake finds it by examining the <filename>BBPATH</filename> environment 
+            variable and looking for the <filename>meta/conf/</filename> 
             directory.
         </para>
 
         <para>
             In Poky, <filename>bitbake.conf</filename> lists other configuration 
-            files to include from a <filename class="directory">conf/</filename> 
-            directory below the directories listed in <varname>BBPATH</varname>. 
+            files to include from a <filename>conf/</filename> 
+            directory below the directories listed in <filename>BBPATH</filename>. 
             In general the most important configuration file from a user's perspective 
             is <filename>local.conf</filename>, which contains a user's customized 
             settings for Poky. 
@@ -54,11 +54,11 @@
             The DISTRO and MACHINE environment variables are both usually set in 
             the <filename>local.conf</filename> file. 
             Valid distribution 
-            configuration files are available in the <filename class="directory">
+            configuration files are available in the <filename>
             meta/conf/distro/</filename> directory and valid machine configuration 
-            files in the <filename class="directory">meta/conf/machine/</filename> 
+            files in the <filename>meta/conf/machine/</filename> 
             directory. 
-            Within the <filename class="directory">meta/conf/machine/include/</filename> 
+            Within the <filename>meta/conf/machine/include/</filename> 
             directory are various <filename>tune-*.inc</filename> configuration files that provide common 
             "tuning" settings specific to and shared between particular architectures and machines.
         </para>
@@ -70,7 +70,7 @@
             <glossterm><link linkend='var-INHERIT'>INHERIT</link></glossterm>
             variable are also inculded. 
             Class files are searched for in a classes subdirectory 
-            under the paths in <varname>BBPATH</varname> in the same way as
+            under the paths in <filename>BBPATH</filename> in the same way as
             configuration files.
         </para>
 
@@ -79,31 +79,29 @@
             variable <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm> 
             is set, usually in
             <filename>local.conf</filename>, and defines the list of places to search for 
-            <filename class="extension">.bb</filename> files. 
-            By default, the BBFILES variable specifies the <filename class="directory">meta/packages/
-            </filename> directory within Poky, but other directories such as
-            <filename class="directory">meta-extras/</filename> can be included 
-            too. 
+            <filename>.bb</filename> files. 
+            By default, the BBFILES variable specifies the <filename>meta/recipes-*/
+            </filename> directory within Poky. 
             Adding extra content to BBFILES is best achieved through the use of BitBake
             <link linkend='usingpoky-changes-layers'>"layers"</link>.
         </para>
 
         <para>
-            BitBake parses each <filename class="extension">.bb</filename> file in BBFILES and 
+            BitBake parses each <filename>.bb</filename> file in BBFILES and 
             stores the values of various variables.  
-            In summary, for each <filename class="extension">.bb</filename> 
+            In summary, for each <filename>.bb</filename> 
             file the configuration plus the base class of variables are set, followed 
-            by the data in the <filename class="extension">.bb</filename> file 
+            by the data in the <filename>.bb</filename> file 
             itself, followed by any inherit commands that
-            <filename class="extension">.bb</filename> file might contain.
+            <filename>.bb</filename> file might contain.
         </para>
 
         <para>
-            Because parsing <filename class="extension">.bb</filename> files is a time 
+            Because parsing <filename>.bb</filename> files is a time 
             consuming process, a cache is kept to speed up subsequent parsing. 
-            This cache is invalid if the timestamp of the <filename class="extension">.bb</filename> 
+            This cache is invalid if the timestamp of the <filename>.bb</filename> 
             file itself changes, or if the timestamps of any of the include, 
-            configuration or class files the <filename class="extension">.bb</filename>
+            configuration or class files the <filename>.bb</filename>
             file depends on changes.
         </para>
     </section>
@@ -112,7 +110,7 @@
         <title>Preferences and Providers</title>
 
         <para>
-            Once all the <filename class="extension">.bb</filename> files have been 
+            Once all the <filename>.bb</filename> files have been 
             parsed, BitBake starts to build the target (poky-image-sato in the previous section's 
             example) and looks for providers of that target.
             Once a provider is selected, BitBake resolves all the dependencies for  
@@ -125,7 +123,7 @@
 
         <para>
             Sometimes a target might have multiple providers.
-            An common example is "virtual/kernel", which is provided by each kernel package. 
+            A common example is "virtual/kernel", which is provided by each kernel package. 
             Each machine often elects the best kernel provider by using a line similar to the 
             following in the machine configuration file:
         </para>
@@ -195,18 +193,18 @@ PREFERRED_PROVIDER_virtual/kernel = "linux-rp"
             The build now starts with BitBake forking off threads up to the limit set in the 
             <glossterm><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm> variable.
             BitBake continues to fork threads as long as there are tasks ready to run,
-            those taksks have all their dependencies met, and the thread threshold has not been 
+            those tasks have all their dependencies met, and the thread threshold has not been 
             exceeded.
         </para>
 
         <para>
             As each task completes, a timestamp is written to the directory specified by the 
             <glossterm><link linkend='var-STAMPS'>STAMPS</link></glossterm> variable (usually 
-            <filename class="directory">build/tmp/stamps/*/</filename>). 
+            <filename>build/tmp/stamps/*/</filename>). 
             On subsequent runs, BitBake looks at the STAMPS directory and does not rerun 
             tasks that are already completed unless a timestamp is found to be invalid. 
             Currently, invalid timestamps are only considered on a per 
-            <filename class="extension">.bb</filename> file basis.
+            <filename>.bb</filename> file basis.
             So, for example, if the configure stamp has a timestamp greater than the 
             compile timestamp for a given target then the compile task would rerun.
             Running the compile task again, however, has no effect on other providers 

documentation/poky-ref-manual/ref-classes.xml

@@ -6,16 +6,16 @@
 
 <para>
     Class files are used to abstract common functionality and share it amongst multiple 
-    <filename class="extension">.bb</filename> files. Any metadata usually found in a 
-    <filename class="extension">.bb</filename> file can also be placed in a class 
+    <filename>.bb</filename> files. Any metadata usually found in a 
+    <filename>.bb</filename> file can also be placed in a class 
     file. Class files are identified by the extension 
-    <filename class="extension">.bbclass</filename> and are usually placed 
-    in a <filename class="directory">classes/</filename> directory beneath the 
-    <filename class="directory">meta*/</filename> directory or the directory pointed
-    by BUILDDIR (e.g. <filename class="directory">build/</filename>)in the same way as
-    <filename class="extension">.conf</filename> files in the <filename 
+    <filename>.bbclass</filename> and are usually placed 
+    in a <filename>classes/</filename> directory beneath the 
+    <filename>meta*/</filename> directory or the directory pointed
+    by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
+    <filename>.conf</filename> files in the <filename 
     class="directory">conf</filename> directory. Class files are searched for 
-    in BBPATH in the same was as <filename class="extension">.conf</filename> files too.
+    in BBPATH in the same was as <filename>.conf</filename> files too.
 </para>
 
 <para>
@@ -28,14 +28,14 @@
     <title>The base class - <filename>base.bbclass</filename></title>
 
     <para>
-        The base class is special in that every <filename class="extension">.bb</filename> 
+        The base class is special in that every <filename>.bb</filename> 
         file inherits it automatically. It contains definitions of standard basic 
         tasks such as fetching, unpacking, configuring (empty by default), compiling 
         (runs any Makefile present), installing (empty by default) and packaging 
         (empty by default). These are often overridden or extended by other classes 
         such as <filename>autotools.bbclass</filename> or 
         <filename>package.bbclass</filename>. The class also contains some commonly
-        used functions such as <function>oe_runmake</function>.
+        used functions such as <filename>oe_runmake</filename>.
     </para>
 </section>
 
@@ -43,13 +43,13 @@
     <title>Autotooled Packages - <filename>autotools.bbclass</filename></title>
 
     <para>
-        Autotools (autoconf, automake, libtool) brings standardisation and this
-        class aims to define a set of tasks (configure, compile etc.) that will
-        work for all autotooled packages.  It should usually be enough to define
-        a few standard variables as documented in the <link
-        linkend='usingpoky-extend-addpkg-autotools'>simple autotools
-        example</link> section and then simply "inherit autotools". This class
-        can also work with software that emulates autotools.
+        Autotools (autoconf, automake, libtool) bring standardization. 
+        This class defines a set of tasks (configure, compile etc.) that 
+        work for all autotooled packages.  
+        It should usually be enough to define a few standard variables as documented in the 
+        <link linkend='usingpoky-extend-addpkg-autotools'>simple autotools
+        example</link> section and then simply "inherit autotools". 
+        This class can also work with software that emulates autotools.
     </para>
 
     <para>
@@ -60,26 +60,29 @@
     <itemizedlist>
       <listitem>
         <para>
-            'do_configure' regenerates the configure script (using autoreconf) and
-            then launches it with a standard set of arguments used during
-            cross-compilation. Additional parameters can be passed to 
-            <command>configure</command> through the <glossterm><link 
-            linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable.
+            <filename>do_configure</filename> &dash; regenerates the configure script (using autoreconf) 
+            and then launches it with a standard set of arguments used during
+            cross-compilation. 
+            You can pass additional parameters to 
+            <filename>configure</filename> through the 
+            <glossterm><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable.
         </para>
       </listitem>
       <listitem>
         <para>
-            'do_compile' runs <command>make</command> with arguments specifying 
-            the compiler and linker. Additional arguments can be passed through 
+            <filename>do_compile</filename> &dash; runs <filename>make</filename> with 
+            arguments that specify the compiler and linker. 
+            You can pass additional arguments through 
             the <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
             </glossterm> variable.
         </para>
       </listitem>
       <listitem>
         <para>
-            'do_install' runs <command>make install</command> passing a DESTDIR 
-            option taking its value from the standard <glossterm><link
-            linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable.
+            <filename>do_install</filename> &dash; runs <filename>make install</filename> 
+            and passes a <filename>DESTDIR</filename> 
+            option, which takes its value from the standard 
+            <glossterm><link linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable.
         </para>
       </listitem>
     </itemizedlist>
@@ -91,54 +94,31 @@
 
     <para>
         Several programs can fulfill the same or similar function and
-        they can be installed with the same name. For example the <command>ar</command> 
+        be installed with the same name. 
+        For example, the <filename>ar</filename> 
         command is available from the "busybox", "binutils" and "elfutils" packages. 
-        This class handles the renaming of the binaries so multiple packages 
-        can be installed which would otherwise conflict and yet the 
-        <command>ar</command> command still works regardless of which are installed
-        or subsequently removed. It renames the conflicting binary in each package 
+        The <filename>update-alternatives.bbclass</filename> class handles renaming the 
+        binaries so that multiple packages can be installed without conflicts. 
+        The <filename>ar</filename> command still works regardless of which packages are installed
+        or subsequently removed. 
+        The class renames the conflicting binary in each package 
         and symlinks the highest priority binary during installation or removal 
         of packages.
-
+    </para>
+    <para>
         Four variables control this class:
     </para>
-
-
-    <variablelist>
-    <varlistentry>
-    <term>ALTERNATIVE_NAME</term>
-    <listitem>
-       <para>
-            Name of binary which will be replaced (<command>ar</command> in this example)
-       </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_LINK</term>
-    <listitem>
-        <para>
-            Path to resulting binary ("/bin/ar" in this example)
-        </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_PATH</term>
-    <listitem>
-        <para>
-            Path to real binary ("/usr/bin/ar.binutils" in this example)
-        </para>
-    </listitem>
-    </varlistentry>
-    <varlistentry>
-    <term>ALTERNATIVE_PRIORITY</term>
-    <listitem>
-        <para>
-            Priority of binary, the version with the most features should have the highest priority
-        </para>
-    </listitem>
-    </varlistentry>
-    </variablelist>
-
+    <itemizedlist>
+        <listitem><para><filename>ALTERNATIVE_NAME</filename> &dash; The name of the 
+        binary that is replaced (<filename>ar</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_LINK</filename> &dash; The path to 
+        the resulting binary (<filename>/bin/ar</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_PATH</filename> &dash; The path to the 
+        real binary (<filename>/usr/bin/ar.binutils</filename> in this example).</para></listitem>
+        <listitem><para><filename>ALTERNATIVE_PRIORITY</filename> &dash; The priority of 
+        the binary. 
+        The version with the most features should have the highest priority.</para></listitem>
+    </itemizedlist>
     <para>
 	Currently, only one binary per package is supported.
     </para>
@@ -172,7 +152,7 @@
     <para>
         During staging Bitbake installs such scripts into the <filename 
         class="directory">sysroots/</filename> directory. It also changes all
-        paths to point into the <filename class="directory">sysroots/</filename>
+        paths to point into the <filename>sysroots/</filename>
         directory so all builds which use the script will use the correct 
         directories for the cross compiling layout.
     </para>
@@ -215,7 +195,7 @@
     </para>
 
     <para>
-        Result of their work are <filename class="directory">tmp/deploy/source/</filename> 
+        Result of their work are <filename>tmp/deploy/source/</filename> 
         subdirs with sources sorted by <glossterm><link linkend='var-LICENSE'>LICENSE</link>
         </glossterm> field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each
         license dir.
@@ -319,7 +299,7 @@
     </para>
     <para>
         This means that each kernel module built is packaged separately and inter-module dependencies are
-        created by parsing the <command>modinfo</command> output. If all modules are
+        created by parsing the <filename>modinfo</filename> output. If all modules are
         required then installing the "kernel-modules" package will install all
         packages with modules and various other kernel packages such as "kernel-vmlinux".
     </para>
@@ -403,7 +383,7 @@
 
     <para>
         Only the most useful/important classes are covered here but there are 
-        others, see the <filename class="directory">meta/classes</filename> directory for the rest. 
+        others, see the <filename>meta/classes</filename> directory for the rest. 
     </para>
 </section>
 

documentation/poky-ref-manual/ref-images.xml

@@ -5,62 +5,83 @@
     <title>Reference: Images</title>
 
     <para>
-        Poky has several standard images covering most people's standard needs. A full 
-        list of image targets can be found by looking in the directories 
-        <filename class="directory">  meta/recipes-core/images/</filename>, 
-        <filename class="directory">  meta/recipes-extended/images/</filename>, 
-        <filename class="directory">  meta/recipes-sato/images/</filename> and 
-        <filename class="directory">  meta/recipes-tbd/meta/</filename>. The standard 
-        images are listed below along with details of what they contain:
+        Poky has several standard images covering most people's standard needs. 
+        Use the following command to list the supported images:
+        <literallayout class='monospaced'>
+     $ ls meta*/recipes*/images/*.bb
+        </literallayout>
+        Images are listed below along with details of what they contain:
     </para>
 
+    <note>
+        Building an image without GNU Public License Version 3 (GPLv3) components is 
+        only supported for minimal and base images.
+        Furthermore, if you are going to build an image using non-GPLv3 components,
+        you must make the following changes in the <filename>local.conf</filename> file
+        before using the BitBake command to build the minimal or base image:
+        <literallayout class='monospaced'>
+     1. Comment out the IMAGE_EXTRA_FEATURES line
+     2. Set INCOMPATIBLE_LICENSE = "GPLv3"
+        </literallayout>
+    </note>
+
     <itemizedlist>
             <listitem>
                 <para>
-                    <emphasis>poky-image-minimal</emphasis> - A small image, just enough 
-                    to allow a device to boot
+                    <emphasis>poky-image-minimal</emphasis> - A small image just capable 
+                    of allowing a device to boot.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>poky-image-base</emphasis> - console only image with full
-                    support of target device hardware
+                    <emphasis>poky-image-base</emphasis> - A console-only image that fully 
+                    supports the target device hardware. 
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>poky-image-core</emphasis> - X11 image with simple apps like
-                    terminal, editor and file manager
+                    <emphasis>poky-image-core</emphasis> - An X11 image with simple 
+                    applications such as terminal, editor, and file manager.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>poky-image-sato</emphasis> - X11 image with Sato theme and
-                    Pimlico applications. Also contains terminal, editor and file manager.
+                    <emphasis>poky-image-sato</emphasis> - An X11 image with Sato theme and
+                    Pimlico applications. 
+                    The image also contains terminal, editor, and file manager.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>poky-image-sdk</emphasis> - X11 image like poky-image-sato but
-                    also include native toolchain and libraries needed to build applications 
-                    on the device itself. Also includes testing and profiling tools and debug
-                    symbols.
+                    <emphasis>poky-image-sato-dev</emphasis> - An X11 image similar to 
+                    poky-image-sato but
+                    also includes a native toolchain and libraries needed to build applications 
+                    on the device itself. The image also includes testing and profiling tools 
+                    as well as debug symbols.  This image was formerly poky-image-sdk.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>meta-toolchain</emphasis> - This generates a tarball containing
-                    a standalone toolchain which can be used externally to Poky. It is self
-                    contained and unpacks to the <filename class="directory">/opt/poky</filename>
-                    directory. It also contains a copy of QEMU and the scripts necessary to run 
+                    <emphasis>poky-image-lsb</emphasis> - An image suitable for implementations 
+                    that conform to Linux Standard Base (LSB).
+                </para>
+            </listitem>
+            <listitem>
+                <para>
+                    <emphasis>meta-toolchain</emphasis> - This image generates a tarball 
+                    that contains a stand-alone toolchain that can be used externally to Poky. 
+                    The tarball is self-contained and unpacks to the 
+                    <filename class="directory">/opt/poky</filename> directory. 
+                    The tarball also contains a copy of QEMU and the scripts necessary to run 
                     poky QEMU images.
                 </para>
             </listitem>
             <listitem>
                 <para>
-                    <emphasis>meta-toolchain-sdk</emphasis> - This includes everything in 
+                    <emphasis>meta-toolchain-sdk</emphasis> - This image includes everything in 
                     meta-toolchain but also includes development headers and libraries
-                    forming a complete standalone SDK. See the <link linkend='platdev-appdev-external-sdk'> 
+                    to form a complete standalone SDK. 
+                    See the <link linkend='platdev-appdev-external-sdk'> 
                     External Development Using the Poky SDK</link> section for more information.
                 </para>
             </listitem>

documentation/poky-ref-manual/ref-structure.xml

@@ -32,9 +32,8 @@
         </para>
 
         <para>
-            For more information on BitBake, see the BitBake project site at 
-            <ulink url="http://bitbake.berlios.de/"/> 
-            and the BitBake on-line manual at <ulink url="http://bitbake.berlios.de/manual/"/>.
+            For more information on BitBake, see the BitBake on-line manual at 
+            <ulink url="http://bitbake.berlios.de/manual/"/>.
         </para>
     </section>
 
@@ -62,7 +61,7 @@
         </para>
     </section>
 
-    <section id='structure-core-meta-extras'>
+<!--    <section id='structure-core-meta-extras'>
         <title><filename class="directory">meta-extras/</filename></title>
 
         <para>
@@ -71,8 +70,25 @@
             This metadata is disabled by default and is not supported as part of Poky.
         </para>
     </section>
+-->
 
-    <section id='structure-core-meta-***'>
+    <section id='structure-core-meta-demoapps'>
+        <title><filename class="directory">meta-demoapps/</filename></title>
+
+        <para>
+            This directory contains recipes for applications and demos that are not core.
+        </para>
+    </section>
+
+    <section id='structure-core-meta-rt'>
+        <title><filename class="directory">meta-rt/</filename></title>
+
+        <para>
+            This directory contains recipes for RealTime.
+        </para>
+    </section>
+
+<!--    <section id='structure-core-meta-***'>
         <title><filename class="directory">meta-***/</filename></title>
 
         <para>
@@ -80,6 +96,7 @@
             The layers are enabled by adding them to the <filename>conf/bblayers.conf</filename> file.
         </para>
     </section>
+-->
 
     <section id='structure-core-scripts'>
         <title><filename class="directory">scripts/</filename></title>
@@ -92,7 +109,7 @@
         </para>
     </section>
 
-    <section id='structure-core-sources'>
+<!--    <section id='structure-core-sources'>
         <title><filename class="directory">sources/</filename></title>
 
         <para>
@@ -124,6 +141,7 @@
             <filename class="extension">.md5</filename> file as well.
         </para>
     </section>
+-->
 
     <section id='handbook'>
         <title><filename class="directory">documentation</filename></title>
@@ -160,11 +178,28 @@
             like Poky to generate the build output.
         </para>
     </section>
+
+    <section id='structure-basic-top-level'>
+        <title><filename>LICENSE, README, and README.hardware</filename></title>
+
+        <para>
+            These files are standard top-level files. 
+        </para>
+    </section>
 </section>
 
 <section id='structure-build'>
     <title>The Build Directory - <filename class="directory">build/</filename></title>
 
+    <section id='structure-build-pseudodone'>
+        <title><filename>build/pseudodone</filename></title>
+
+        <para>
+            This tag file indicates that the intitial pseudo binar was created. 
+            The first time BitBake is invoked this file is built. 
+        </para>
+    </section>
+
     <section id='structure-build-conf-local.conf'>
         <title><filename>build/conf/local.conf</filename></title>
 
@@ -198,6 +233,36 @@
         </para>
     </section>
 
+    <section id='structure-build-conf-sanity_info'>
+        <title><filename>build/conf/sanity_info</filename></title>
+
+        <para>
+            This file is created during the build to indicate the state of the sanity checks.
+        </para>
+    </section>
+
+    <section id='structure-build-downloads'>
+        <title><filename>build/downloads/</filename></title>
+
+        <para>
+            This directory is used for the upstream source tarballs.
+            The directory can be reused by multiple builds or moved to another location. 
+            You can control the location of this directory through the
+            <glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-sstate-cache'>
+        <title><filename>build/sstate-cache/</filename></title>
+
+        <para>
+            This directory is used for the shared state cache.
+            The directory can be reused by multiple builds or moved to another location. 
+            You can control the location of this directory through the
+            <glossterm><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></glossterm> variable.
+        </para>
+    </section>
+
     <section id='structure-build-tmp'>
         <title><filename class="directory">build/tmp/</filename></title>
 
@@ -211,6 +276,14 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-buildstats'>
+        <title><filename class="directory">build/tmp/buildstats/</filename></title>
+
+        <para>
+            This directory stores the build statistics.
+        </para>
+    </section>
+
     <section id='structure-build-tmp-cache'>
         <title><filename class="directory">build/tmp/cache/</filename></title>
 
@@ -231,7 +304,7 @@
         <title><filename class="directory">build/tmp/deploy/deb/</filename></title>
 
         <para>
-            This directory receives any .deb packages produced by Poky.
+            This directory receives any <filename>.deb</filename> packages produced by Poky.
             The packages are sorted into feeds for different architecture types.
         </para>
     </section>
@@ -240,7 +313,7 @@
         <title><filename class="directory">build/tmp/deploy/rpm/</filename></title>
 
         <para>
-            This directory receives any .rpm packages produced by Poky.  
+            This directory receives any <filename>.rpm</filename> packages produced by Poky.  
             The packages re sorted into feeds for different architecture types.
         </para>
     </section>
@@ -257,7 +330,7 @@
     <section id='structure-build-tmp-deploy-ipk'>
         <title><filename class="directory">build/tmp/deploy/ipk/</filename></title>
 
-        <para>This directory receives .ipk packages produced by Poky.</para>
+        <para>This directory receives <filename>.ipk</filename> packages produced by Poky.</para>
     </section>
 
     <section id='structure-build-tmp-sysroots'>
@@ -513,6 +586,15 @@
         </para>
     </section>
 
+    <section id='structure-meta-recipes-support'>
+        <title><filename class="directory">meta/recipes-support/</filename></title>
+
+        <para>
+            This directory contains recipes that used by other recipes, but that are not directly 
+            included in images (i.e. depenendies of other recipes).
+        </para>
+    </section>
+
     <section id='structure-meta-site'>
         <title><filename class="directory">meta/site/</filename></title>
 
@@ -523,6 +605,14 @@
             passed to "autoconf" for the various architectures. 
         </para>
     </section>
+
+    <section id='structure-meta-recipes-txt'>
+        <title><filename class="directory">meta/recipes.txt/</filename></title>
+
+        <para>
+            This file is a description of the contents of <filename>recipes-*</filename>.
+        </para>
+    </section>
 </section>
 
 </appendix>

documentation/poky-ref-manual/ref-variables.xml

@@ -766,6 +766,12 @@ recipes-graphics/xorg-font/fiont-alias_1.0.2.bb:PR - "$(INC_PR).0"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
+            <glossdef>
+                <para>Directory for the shared state.</para>
+            </glossdef>
+
+        </glossentry>
         <glossentry id='var-SHELLCMDS'><glossterm>SHELLCMDS</glossterm>
             <glossdef>
                 <para>

documentation/poky-ref-manual/resources.xml

@@ -18,8 +18,8 @@
     <title>Bugtracker</title>
 
     <para>
-        Problems with Poky should be reported in the 
-        <ulink url='http://bugzilla.pokylinux.org/'>bug tracker</ulink>.
+        Problems with Poky should be reported using the Bugzilla application at 
+        <ulink url='http://bugzilla.yoctoproject.org/'></ulink>.
     </para>
 </section>
 
@@ -75,7 +75,8 @@
             for Yocto Project.
         </para></listitem>
         <listitem><para>
-            <ulink url='http://pokylinux.org'>The Poky website</ulink> 
+            <ulink url='http://pokylinux.org'>The Poky website</ulink> - The home site
+            for Poky Linux.
         </para></listitem>
         <listitem><para>
             <ulink url='http://www.openedhand.com/'>OpenedHand</ulink> - The
@@ -96,8 +97,8 @@
             - The tool used to process Poky metadata.
         </para></listitem>
         <listitem><para>
-            <ulink url='http://bitbake.berlios.de/manual/'>Bitbake User
-                Manual</ulink>
+            <ulink url='http://bitbake.berlios.de/manual/'>BitBake User
+                Manual</ulink> - A comprehensive guide to the BitBake tool.
         </para></listitem>
         <listitem><para>
             <ulink url='http://pimlico-project.org/'>Pimlico</ulink> - A
@@ -148,7 +149,7 @@
 </programlisting>
 
     <para>
-        A Poky contributions tree (poky-contrib, git://git.pokylinux.org/poky-contrib.git)
+        A Poky contributions tree (poky-contrib, git://git.yoctoproject.org/poky-contrib.git)
         exists for people to stage contributions in, for regular contributors.
         If people desire such access, please ask on the mailing list. Usually
         access will be given to anyone with a proven track record of good patches.

documentation/poky-ref-manual/style.css

@@ -50,9 +50,13 @@ body {
   color: #333;
 }
 
+.reviewer {
+  color: red;
+}
+
 h1,h2,h3,h4,h5,h6,h7 {
   font-family: Arial, Sans;
-  color:#999999;
+  color: #00557D;
   clear: both;
 }
 
@@ -76,7 +80,7 @@ h2 {
   margin: 2em 0em 0.66em 0em;
   padding: 0.5em 0em 0em 0em;
   font-size: 1.5em;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h3.subtitle {
@@ -90,28 +94,28 @@ h3 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 140%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h4 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 120%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h5 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 110.000%;
-  border-bottom: 1px solid black;
+  font-size: 110%;
+  font-weight: bold;
 }
 
 h6 {
   margin: 1em 0em 0em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 80%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 .authorgroup {
@@ -132,6 +136,7 @@ h3.author {
   padding: 0em 0em 0em 0em;
   font-weight: normal;
   font-size: 100%;
+  color: #333;
   clear: both;
 }
 
@@ -154,6 +159,7 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
   padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
 }
 
 .toc p,
@@ -930,7 +936,7 @@ table {
 
 .tip,
 .note {
-   background: #91ae35;
+   background: #666666;
    color: #fff;   
    padding: 20px;
    margin: 20px;

documentation/poky-ref-manual/usingpoky.xml

@@ -5,7 +5,7 @@
 
     <para>
         This section gives an overview of the components that make up Poky 
-        following by information about running poky builds and dealing with any
+        followed by information about running poky builds and dealing with any
         problems that may arise.
     </para>
 
@@ -13,13 +13,13 @@
     <title>Poky Overview</title>
 
     <para>
-        The bitbake task executor together with various types of configuration files form the core of Poky.
-        This section overviews the bitbake task executor and the
+        The BitBake task executor together with various types of configuration files form the core of Poky.
+        This section overviews the BitBake task executor and the
         configuration files by describing what they are used for and they they interact.
     </para>
     
     <para>  
-        Bitbake handles the parsing and execution of the data files. 
+        BitBake handles the parsing and execution of the data files. 
         The data itself is of various types:
     <itemizedlist>
         <listitem><para>Recipes:  Provides details about particular pieces of software</para></listitem>
@@ -31,7 +31,7 @@
     </para>
 
     <para> 
-        Bitbake knows how to combine multiple data sources together and refers to each data source
+        BitBake knows how to combine multiple data sources together and refers to each data source
         as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
     </para>
 
@@ -43,17 +43,17 @@
     </para>
 
     <section id='usingpoky-components-bitbake'>
-        <title>Bitbake</title>
+        <title>BitBake</title>
 
         <para>
-            Bitbake is the tool at the heart of Poky and is responsible
+            BitBake is the tool at the heart of Poky and is responsible
             for parsing the metadata, generating a list of tasks from it
-            and then executing them. To see a list of the options bitbake
+            and then executing them. To see a list of the options BitBake
             supports look at 'bitbake --help'.
         </para>
 
         <para>
-            The most common usage for bitbake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
             packagename is the name of the package you want to build (referred to as the 'target'
             in this manual). 
             The target often equates to the first part of a <filename>.bb</filename> filename.
@@ -63,14 +63,14 @@
      $ bitbake matchbox-desktop
             </literallayout>
             Several different versions of <filename>matchbox-desktop</filename> might exist.
-            Bitbake chooses the one selected by the distribution configuration.
-            You can get more details about how bitbake chooses between different versions
+            BitBake chooses the one selected by the distribution configuration.
+            You can get more details about how BitBake chooses between different versions
             and providers in the <link linkend='ref-bitbake-providers'>
             'Preferences and Providers'</link> section.
         </para>
         <para>
-            Bitbake also tries to execute any dependent tasks first.
-            So for example, before building <filename>matchbox-desktop</filename> bitbake
+            BitBake also tries to execute any dependent tasks first.
+            So for example, before building <filename>matchbox-desktop</filename> BitBake
             would build a cross compiler and glibc if they had not already been built.
         </para>
 
@@ -151,13 +151,24 @@
     </para>
     <para>
         The target is the name of the recipe you want to build. 
-        Common targets are the images in <filename>meta/recipes-core/images</filename>),
+        Common targets are the images in <filename>meta/recipes-core/images</filename>,
         <filename>/meta/recipes-sato/images</filename>, etc.
         Or, the target can be the name of a recipe for a specific piece of software such as 
         <application>busybox</application>. 
         For more details about the standard images available, see the 
         <link linkend="ref-images">'Reference: Images'</link> appendix.
     </para>
+    <note>
+        Building an image without GNU Public License Version 3 (GPLv3) components is 
+        only supported for minimal and base images.
+        See <link linkend='ref-images'>'Reference: Images'</link> for more information.
+    </note>
+    <note>
+        When building an image using GPL components you need to maintain your original 
+        settings and not switch back and forth applying different versions of the GNU
+        Public License.  If you rebuild using different versions of GPL you can get 
+        dependency errors due to some components not being rebuilt.
+    </note>
 </section>
 
 <section id='usingpoky-install'>
@@ -183,12 +194,12 @@
     <para>
         The exact method for debugging Poky depends on the nature of the 
         problem and on the system's area from which the bug originates. 
-        Standard debugging practises such as comparison against the last 
-        known working version with examination of the changes and the reapplication of steps 
+        Standard debugging practices such as comparison against the last 
+        known working version with examination of the changes and the re-application of steps 
         to identify the one causing the problem are
         valid for Poky just as they are for any other system. 
-        It's impossible to detail every possible potential failure but here are some general
-        tips to aid in debugging:
+        Even though it is impossible to detail every possible potential failure, 
+        here are some general tips to aid in debugging:
     </para>
 
     <section id='usingpoky-debugging-taskfailures'>
@@ -197,7 +208,7 @@
         <para>The log file for shell tasks is available in <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. 
             For example, the "compile" task of busybox 1.01 on the ARM spitz machine might be 
             <filename>tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234</filename>.
-            To see what bitbake runs to generate that log, look at the corresponding 
+            To see what BitBake runs to generate that log, look at the corresponding 
             <filename>run.do_taskname.pid </filename> file located in the same directory.
         </para>
 
@@ -214,10 +225,10 @@
             In most cases the series is: fetch, unpack, patch, configure,
             compile, install, package, package_write and build. 
             The default task is "build" and any tasks on which it depends build first - hence, 
-            the standard bitbake behaviour. 
+            the standard BitBake behaviour. 
             Some tasks exist, such as devshell, that are not part of the default build chain.  
             If you wish to run a task that is not part of the default build chain you can use the 
-            "-c" option in bitbake as follows:
+            "-c" option in BitBake as follows:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
             </literallayout>
@@ -241,7 +252,7 @@
         <para>
             This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it.
             The last command reruns all tasks, basically the packaging tasks, after the compile.
-            Bitbake recognizes that the "compile" task was rerun and therefore understands that the other
+            BitBake recognizes that the "compile" task was rerun and therefore understands that the other
             tasks also need to be run again.
         </para>
 
@@ -259,7 +270,7 @@
         <title>Dependency Graphs</title>
 
         <para>
-            Sometimes it can be hard to see why bitbake wants to build some other packages before a given 
+            Sometimes it can be hard to see why BitBake wants to build some other packages before a given 
             package you've specified.
             The <filename>bitbake -g targetname</filename> command creates the <filename>depends.dot</filename> and
             <filename>task-depends.dot</filename> files in the current directory. 
@@ -270,11 +281,11 @@
     </section>
 
     <section id='usingpoky-debugging-bitbake'>
-        <title>General Bitbake Problems</title>
+        <title>General BitBake Problems</title>
 
         <para>
-            You can see debug output from bitbake by using the "-D" option.
-            The debug output gives more information about what bitbake
+            You can see debug output from BitBake by using the "-D" option.
+            The debug output gives more information about what BitBake
             is doing and the reason behind it. 
             Each "-D" option you use increases the logging level.
             The most common usage is <filename>-DDD</filename>.
@@ -282,9 +293,9 @@
 
         <para>
             The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
-            bitbake chose a certain version of a package or why bitbake
+            BitBake chose a certain version of a package or why BitBake
             picked a certain provider.
-            This command could also help you in a situation where you think bitbake did something 
+            This command could also help you in a situation where you think BitBake did something 
             unexpected.
         </para>
     </section>
@@ -296,7 +307,7 @@
             the command form <filename>bitbake -b somepath/somefile.bb</filename>. 
             This command form does not check for dependencies so you should use it
             only when you know its dependencies already exist. 
-            You can also specify fragments of the filename and bitbake checks for a unique match.
+            You can also specify fragments of the filename and BitBake checks for a unique match.
         </para>
     </section>
 

documentation/yocto-project-qs/Makefile

@@ -17,16 +17,16 @@ html:
 	xsltproc $(XSLTOPTS) -o yocto-project-qs.html yocto-project-qs-customization.xsl yocto-project-qs.xml
 
 tarball: html
-	tar -cvzf yocto-project-qs.tgz yocto-project-qs.html style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png
+	tar -cvzf yocto-project-qs.tgz yocto-project-qs.html ypqs.pdf style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png
 
 validate:
 	xmllint --postvalid --xinclude --noout yocto-project-qs.xml
 
-OUTPUTS = yocto-project-qs.tgz yocto-project-qs.html
+OUTPUTS = yocto-project-qs.tgz yocto-project-qs.html ypqs.pdf
 SOURCES = *.png *.xml *.css
 
 publish:
-	scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
+	scp -r $(OUTPUTS) $(SOURCES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-doc/yocto-quick-start
 
 clean:
 	rm -f $(OUTPUTS)

documentation/yocto-project-qs/style.css

@@ -50,9 +50,13 @@ body {
   color: #333;
 }
 
+.reviewer {
+  color: red;
+}
+
 h1,h2,h3,h4,h5,h6,h7 {
   font-family: Arial, Sans;
-  color:#999999;
+  color: #00557D;
   clear: both;
 }
 
@@ -76,7 +80,7 @@ h2 {
   margin: 2em 0em 0.66em 0em;
   padding: 0.5em 0em 0em 0em;
   font-size: 1.5em;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h3.subtitle {
@@ -90,28 +94,28 @@ h3 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 140%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h4 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 120%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 h5 {
   margin: 1em 0em 0.5em 0em;
   padding: 1em 0em 0em 0em;
-  font-size: 110.000%;
-  border-bottom: 1px solid black;
+  font-size: 110%;
+  font-weight: bold;
 }
 
 h6 {
   margin: 1em 0em 0em 0em;
   padding: 1em 0em 0em 0em;
   font-size: 80%;
-  font-weight: normal;
+  font-weight: bold;
 }
 
 .authorgroup {
@@ -132,6 +136,7 @@ h3.author {
   padding: 0em 0em 0em 0em;
   font-weight: normal;
   font-size: 100%;
+  color: #333;
   clear: both;
 }
 
@@ -154,6 +159,7 @@ h3.author {
 .list-of-examples,
 .list-of-figures {
   padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
 }
 
 .toc p,
@@ -241,7 +247,6 @@ div.legalnotice p.legalnotice-title {
 p {
   line-height: 1.5em;
   margin-top: 0em;
-  color: black; font-size: 100%;
   
 }
 
@@ -941,7 +946,7 @@ table {
 
 .tip,
 .note {
-   background: #91ae35;
+   background: #666666;
    color: #fff;   
    padding: 20px;
    margin: 20px;

documentation/yocto-project-qs/yocto-project-qs.xml

@@ -13,9 +13,10 @@
     <title>Welcome!</title>
     <para>
         Welcome to the Yocto Project!  
-        The Yocto Project (YP) is an open-source collaboration project focused on embedded Linux
+        The Yocto Project is an open-source collaboration project focused on embedded Linux
         developers.
-        Amongst other things, YP uses the Poky build tool to construct complete Linux images.
+        Amongst other things, the Yocto Project uses the Poky build tool to 
+        construct complete Linux images.
     </para>
     <para>
         This short document will give you some basic information about the environment as well 
@@ -26,11 +27,18 @@
         and run it using the QEMU emulator.
     </para>
     <para>
-        For complete information on the Yocto Project you should check out the 
+        For complete information on the Yocto Project, you should check out the 
         <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
         You can find the latest builds, breaking news, full development documentation, and a 
         rich Yocto Project Development Community into which you can tap.
     </para>
+    <para>
+        Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
+        at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and 
+        the FAQ appendix located in the 
+        <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
+        Poky Reference Manual</ulink> helpful.
+    </para>
 </section>
 
 <section id='yp-intro'>
@@ -83,11 +91,11 @@
     </itemizedlist>
 
     <para>
-        Yocto Project can generate images for many kinds of devices.  
+        The Yocto Project can generate images for many kinds of devices.  
         However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS,
-        and PPC based architectures as well as specific hardware such as the Intel Desktop Board
+        and PPC-based architectures as well as specific hardware such as the Intel Desktop Board
         DH55TC.  
-        Because an image developed with Yocto Project can boot inside a QEMU emulator, the 
+        Because an image developed with the Yocto Project can boot inside a QEMU emulator, the 
         development environment works nicely as a test platform for developing embedded software.
     </para>
 
@@ -95,7 +103,7 @@
         Another important Yocto Project feature is the Sato reference User Interface. 
         This optional GNOME mobile-based UI, which is intended for devices with
         resolution but restricted size screens, sits neatly on top of a device using the 
-        GNOME Mobile Stack providing a well defined user experience. 
+        GNOME Mobile Stack providing a well-defined user experience. 
         Implemented in its own layer, it makes it clear to developers how they can implement 
         their own UIs on top of Yocto Linux.
     </para>
@@ -111,7 +119,12 @@
     <itemizedlist>
         <listitem>
             <para>A host system running a supported Linux distribution (i.e. recent releases of
-                Fedora, OpenSUSE, Debian, and Ubuntu).</para>
+                Fedora, OpenSUSE, Debian, and Ubuntu).
+            <note>
+                For notes about using the Yocto Project on development systems that use 
+                older Linux distributions see 
+                <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink>
+            </note></para>
         </listitem>
         <listitem>
             <para>The right packages.</para>
@@ -142,7 +155,7 @@
      unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
      python-pysqlite2 diffstat help2man make gcc build-essential \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     mercurial autoconf automake
+     mercurial autoconf automake groff
             </literallayout>
 
         <para>
@@ -176,7 +189,7 @@
             
         <para>
             The latest release images for the Yocto Project are kept at 
-            <ulink url="http://yoctoproject.org/downloads/yocto-0.9/"></ulink>.
+            <ulink url="http://yoctoproject.org/downloads/yocto-1.0/"></ulink>.
             Nightly and developmental builds are also maintained.  However, for this 
             document a released version of Yocto Project is used.
         </para>
@@ -228,11 +241,21 @@
              recommend having at least 100GB of free disk space.
          </para></note>
 
+         <note><para>
+             By default, Poky searches for source code using a pre-determined order
+             through a set of locations.
+             If you encounter problems with Poky finding and downloading source code, see
+             the FAQ entry "How does Poky obtain source code and will it work behind my
+             firewall or proxy server?" in the 
+             <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
+             Poky Reference Manual</ulink>.
+         </para></note>
+
          <para>
              <literallayout class='monospaced'>
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-laverne-4.0.tar.bz2
-     $ tar xjf poky-laverne-4.0.tar.bz2
-     $ source poky-laverne-4.0/poky-init-build-env poky-4.0-build
+     $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2
+     $ tar xjf poky-bernard-5.0.tar.bz2
+     $ source poky-bernard-5.0/poky-init-build-env poky-5.0-build
              </literallayout>
          </para>
 
@@ -242,7 +265,7 @@
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
-     INHERIT += "rm_work"
+     INHERIT += rm_work
              </literallayout>
          </para></tip>
 
@@ -250,8 +273,8 @@
              <listitem><para>The first two commands extract the Yocto Project files from the 
              release tarball and place them into a subdirectory of your current directory.</para></listitem>
              <listitem><para>The <command>source</command> command creates the 
-             <filename>poky-4.0-build</filename> directory and executes the <command>cd</command>
-             command to make <filename>poky-4.0-build</filename> the working directory.
+             <filename>poky-5.0-build</filename> directory and executes the <command>cd</command>
+             command to make <filename>poky-5.0-build</filename> the working directory.
              The resulting build directory contains all the files created during the build.   
              By default the target architecture is qemux86.
              To change this default, edit the value of the MACHINE variable in the 
@@ -270,15 +293,6 @@
              <literallayout class='monospaced'>
      $ bitbake poky-image-sato
              </literallayout>
-             <note><para>
-                 If you are running Fedora 14 or another distribution 
-                 that ships with GNU make v3.82 you need to run the following two 
-                 <command>bitbake</command> commands instead:
-                 <literallayout class='monospaced'>
-     $ bitbake make-native
-     $ bitbake poky-image-sato
-                 </literallayout>
-             </para></note>
              <note><para>
                  BitBake requires Python 2.6.  For more information on this requirement, 
                  see the FAQ appendix in the 
@@ -353,9 +367,10 @@
         <title>Installing the Toolchain</title>
          <para>
              You can download the pre-built toolchain, which includes the poky-qemu script and 
-             support files, from <ulink url='http://yoctoproject.org/downloads/yocto-0.9/toolchain/'></ulink>.  
+             support files, from 
+             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>.  
              Toolchains are available for 32-bit and 64-bit development systems from the 
-             <filename>i586</filename> and <filename>x86_64</filename> folders, respectively. 
+             <filename>i686</filename> and <filename>x86_64</filename> folders, respectively. 
              Each type of development system supports five target architectures.
              The tarball files are named such that a string representing the host system appears 
              first in the filename and then is immediately followed by a string representing
@@ -367,10 +382,10 @@
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
-                i586 or x86_64.
+                i686 or x86_64.
        
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
-                i585, x86_64, powerpc, mips, or arm.
+                i686, x86_64, powerpc, mips, or arm.
        
          &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
          </literallayout>
@@ -381,7 +396,7 @@
          </para>
 
          <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-i586-toolchain-sdk-0.9.tar.bz2
+     yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
          </literallayout>
 
          <para>
@@ -393,7 +408,7 @@
          <para>
              <literallayout class='monospaced'>
      $ cd /
-     $ sudo tar -xvjf yocto-eglibc-x86_64-i586-toolchain-sdk-0.9.tar.bz2
+     $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2
              </literallayout>
          </para>
          </section>
@@ -403,7 +418,7 @@
          <para>
              You can download the pre-built Linux kernel and the filesystem image suitable for 
              running in the emulator QEMU from 
-             <ulink url='http://yoctoproject.org/downloads/yocto-0.9/qemu'></ulink>.
+             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>.
              Be sure to use the kernel and filesystem image that matches the architecture you want 
              to simulate.
          </para>
@@ -455,10 +470,10 @@
 
      Where:
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
-                i586, x86_64, ppc603e, mips, or armv5te.
+                i686, x86_64, ppc603e, mips, or armv5te.
 
          &lt;<emphasis>if</emphasis>&gt; is a string representing an embedded application binary interface.
-                Not all setup scripts include this string.
+              Not all setup scripts include this string.
          </literallayout>
 
          <para>
@@ -466,17 +481,16 @@
          </para>
 
          <literallayout class='monospaced'>
-     $ poky-qemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel</emphasis>&gt; &lt;<emphasis>image</emphasis>&gt; &lt;<emphasis>fstype</emphasis>&gt;
+     $ poky-qemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel</emphasis>&gt; &lt;<emphasis>filesystem_image</emphasis>&gt;
 
      Where:
          &lt;<emphasis>qemuarch</emphasis>&gt; is a string representing the target architecture: qemux86, qemux86-64, 
                     qemuppc, qemumips, or qemuarm.
 
-         &lt;<emphasis>kernel</emphasis>&gt;    is the architecture-specific kernel.
+         &lt;<emphasis>kernel</emphasis>&gt; is the architecture-specific kernel.
 
-         &lt;<emphasis>image</emphasis>&gt;     is the .ext3 filesystem image.
+         &lt;<emphasis>filesystem_image</emphasis>&gt; is the .ext3 filesystem image.
 
-         &lt;<emphasis>fstype</emphasis>&gt;    is the filesystem type.
          </literallayout>
 
          <para>
@@ -486,8 +500,8 @@
          </para>
 
          <literallayout class='monospaced'>
-     $ source /opt/poky/environment-setup-i586-poky-linux 
-     $ poky-qemu qemui586 zImage-2.6.34-qemux86-0.9 yocto-image-sdk-qemux86-0.9.rootfs.ext3 ext3
+     $ source /opt/poky/environment-setup-i686-poky-linux 
+     $ poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin yocto-image-sdk-qemux86-1.0.rootfs.ext3
          </literallayout>
 
          <para>

meta-rt/recipes-kernel/linux-yocto-rt_stablegit.bb

@@ -8,7 +8,10 @@ LINUX_VERSION ?= "2.6.34"
 LINUX_KERNEL_TYPE = "preempt_rt"
 LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE_EXTENSION}"
 
-PR = "r0"
+KMETA = wrs_meta
+KBRANCH = ${KMACHINE}-${LINUX_KERNEL_TYPE}
+
+PR = "r1"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 SRCREV_FORMAT = "meta_machine"
 
@@ -18,16 +21,11 @@ COMPATIBLE_MACHINE = "(qemux86-64|atom-pc)"
 python __anonymous () {
     import bb, re, string
 
-    rev = bb.data.getVar("SRCREV_machine", d, 1)
-    if rev == "standard":
-        bb.data.setVar("SRCREV_machine", "${SRCREV_meta}", d)
-
     kerntype = string.replace(bb.data.expand("${LINUX_KERNEL_TYPE}", d), "_", "-")
     bb.data.setVar("LINUX_KERNEL_TYPE_EXTENSION", kerntype, d)
 }
 
-SRC_URI = "git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;fullclone=1;branch=${KBRANCH};name=machine \
-           git://git.pokylinux.org/linux-2.6-windriver.git;protocol=git;noclone=1;branch=wrs_meta;name=meta"
+SRC_URI = "git://git.yoctoproject.org/linux-2.6-windriver.git;protocol=git;nocheckout=1;branch=${KBRANCH},wrs_meta;name=machine,meta"
 
 # Functionality flags
 KERNEL_REVISION_CHECKING ?= "t"

meta-yocto/recipes-core/netbase/netbase-4.45/beagleboard/interfaces

@@ -0,0 +1,27 @@
+# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
+ 
+# The loopback interface
+auto lo
+iface lo inet loopback
+
+# Wireless interfaces
+iface wlan0 inet dhcp
+	wireless_mode managed
+	wireless_essid any
+	wpa-driver wext
+	wpa-conf /etc/wpa_supplicant.conf
+
+iface atml0 inet dhcp
+
+# Wired or wireless interfaces
+auto eth0
+iface eth0 inet dhcp
+iface eth1 inet dhcp
+
+# Ethernet/RNDIS gadget (g_ether) or LAN9514 on BeagleBoard xM
+auto usb0
+iface usb0 inet dhcp
+
+# Bluetooth networking
+iface bnep0 inet dhcp
+

meta-yocto/recipes-core/netbase/netbase_4.45.bbappend

@@ -0,0 +1,3 @@
+THISDIR := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
+FILESPATH =. "${@base_set_filespath(["${THISDIR}/${PN}"], d)}:"
+

meta/classes/autotools.bbclass

@@ -109,8 +109,8 @@ autotools_do_configure() {
 			AUTOV=`automake --version |head -n 1 |sed "s/.* //;s/\.[0-9]\+$//"`
 			automake --version
 			echo "AUTOV is $AUTOV"
-			if [ -d ${STAGING_DATADIR}/aclocal-$AUTOV ]; then
-				acpaths="$acpaths -I${STAGING_DATADIR}/aclocal-$AUTOV"
+			if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
+				acpaths="$acpaths -I${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV"
 			fi
 			if [ -d ${STAGING_DATADIR}/aclocal ]; then
 				acpaths="$acpaths -I ${STAGING_DATADIR}/aclocal"

meta/classes/boot-directdisk.bbclass

@@ -49,7 +49,7 @@ build_boot_dd() {
 	IMAGE=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect
 
 	install -d ${HDDDIR}
-	install -m 0644 ${STAGING_DIR}/${MACHINE}${HOST_VENDOR}-${HOST_OS}/kernel/bzImage ${HDDDIR}/vmlinuz
+	install -m 0644 ${STAGING_DIR_HOST}/kernel/bzImage ${HDDDIR}/vmlinuz
 	install -m 444 ${STAGING_LIBDIR}/syslinux/ldlinux.sys ${HDDDIR}/ldlinux.sys
 
 	BLOCKS=`du -bks ${HDDDIR} | cut -f 1`

meta/classes/crosssdk.bbclass

@@ -9,6 +9,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_FPU = ""
 
 target_libdir = "${SDKPATHNATIVE}${libdir_nativesdk}"
 target_includedir = "${SDKPATHNATIVE}${includedir_nativesdk}"

meta/classes/debian.bbclass

@@ -107,7 +107,13 @@ python debian_package_name_hook () {
 					if newpkg != pkg:
 						bb.data.setVar('PKG_' + pkg, newpkg, d)
 
-	for pkg in (bb.data.getVar('AUTO_LIBNAME_PKGS', d, 1) or "").split():
+	# reversed sort is needed when some package is substring of another
+	# ie in ncurses we get without reverse sort: 
+	# DEBUG: LIBNAMES: pkgname libtic5 devname libtic pkg ncurses-libtic orig_pkg ncurses-libtic debian_pn None newpkg libtic5
+	# and later
+	# DEBUG: LIBNAMES: pkgname libtic5 devname libtic pkg ncurses-libticw orig_pkg ncurses-libtic debian_pn None newpkg libticw
+	# so we need to handle ncurses-libticw->libticw5 before ncurses-libtic->libtic5
+	for pkg in sorted((bb.data.getVar('AUTO_LIBNAME_PKGS', d, 1) or "").split(), reverse=True):
 		auto_libname(packages, pkg)
 }
 

meta/classes/distrodata.bbclass

@@ -347,7 +347,6 @@ python do_checkpkg() {
 		f = tempfile.NamedTemporaryFile(delete=False, prefix="%s-1-" % pn)
 		status = internal_fetch_wget(url, d, f)
 		fhtml = f.read()
-
 		if status == "SUCC" and len(fhtml):
 			newver = parse_inter(curver)
 
@@ -436,6 +435,10 @@ python do_checkpkg() {
 			else:
 				"""newver still contains a full package name string"""
 				status = re.search("(\d+[\.\-_])*(\d+[0-9a-zA-Z]*)", newver[1]).group()
+				if "_" in status:
+					status = re.sub("_",".",status)
+				elif "-" in status:
+					status = re.sub("-",".",status)
 		elif not len(fhtml):
 			status = "ErrHostNoDir"
 
@@ -531,6 +534,12 @@ python do_checkpkg() {
 	
 			alturi = bb.encodeurl([type, host, altpath, user, pswd, {}])
 			newver = check_new_version(alturi, curname, d)
+			while(newver == "ErrHostNoDir"):
+				if alturi == "/download":
+					break
+				else:
+					alturi = "/".join(alturi.split("/")[0:-2]) + "/download"
+					newver = check_new_version(alturi, curname, d)
 			if not re.match("Err", newver):
 				pupver = newver
 				if pupver != pcurver:
@@ -550,13 +559,38 @@ python do_checkpkg() {
 			gitproto = parm['protocol']
 		else:
 			gitproto = "rsync"
-
-		gitcmd = "git ls-remote %s://%s%s%s HEAD 2>&1" % (gitproto, gituser, host, path)
-		print gitcmd
-		ver = os.popen(gitcmd).read()
-		if ver and re.search("HEAD", ver):
-			pupver = ver.split("\t")[0]
-			if pcurver == pupver:
+		gitcmd = "git ls-remote %s://%s%s%s *tag* 2>&1" % (gitproto, gituser, host, path)
+		gitcmd2 = "git ls-remote %s://%s%s%s HEAD 2>&1" % (gitproto, gituser, host, path)
+		tmp = os.popen(gitcmd).read()
+		tmp2 = os.popen(gitcmd2).read()
+		#This is for those repo have tag like: refs/tags/1.2.2
+		if tmp:
+			tmpline = tmp.split("\n")
+			verflag = 0
+			for line in tmpline:
+				if len(line)==0:
+					break;
+				puptag = line.split("/")[-1]
+				puptag = re.search("[0-9][0-9|\.|_]+[0-9]", puptag)
+				if puptag == None:
+					continue;
+				puptag = puptag.group()
+				puptag = re.sub("_",".",puptag)
+				plocaltag = pversion.split("+")[0]
+				if "git" in plocaltag:
+					plocaltag = plocaltag.split("-")[0]
+				result = bb.utils.vercmp(("0", puptag, ""), ("0", plocaltag, ""))
+				if result > 0:
+					verflag = 1
+					pstatus = "UPADTE"
+					pupver = puptag
+				elif verflag == 0 :
+					pupver = plocaltag
+					pstatus = "MATCH"
+		#This is for those no tag repo
+		elif tmp2:
+			pupver = tmp2.split("\t")[0]
+			if pupver in pversion:
 				pstatus = "MATCH"
 			else:
 				pstatus = "UPDATE"
@@ -580,7 +614,7 @@ python do_checkpkg() {
 		for line in svninfo.split("\n"):
 			if re.search("^Last Changed Rev:", line):
 				pupver = line.split(" ")[-1]
-				if pcurver == pupver:
+				if pupver in pversion:
 					pstatus = "MATCH"
 				else:
 					pstatus = "UPDATE"

meta/classes/distutils-base.bbclass

@@ -1,5 +1,5 @@
 DEPENDS  += "${@["python-native python", ""][(bb.data.getVar('PACKAGES', d, 1) == '')]}"
-RDEPENDS += "python-core"
+RDEPENDS_${PN} += "${@['', 'python-core']['${PN}' == '${BPN}']}"
 
 inherit distutils-common-base
 

meta/classes/image.bbclass

@@ -113,7 +113,8 @@ fakeroot do_rootfs () {
 
 	# Run ldconfig on the image to create a valid cache 
 	# (new format for cross arch compatibility)
-	ldconfig -r ${IMAGE_ROOTFS} -c new
+	echo executing: ldconfig -r ${IMAGE_ROOTFS} -c new -v
+	ldconfig -r ${IMAGE_ROOTFS} -c new -v
 
 	# (re)create kernel modules dependencies
 	# This part is done by kernel-module-* postinstall scripts but if image do

meta/classes/insane.bbclass

@@ -32,58 +32,58 @@ PACKAGEFUNCS += " do_package_qa "
 def package_qa_get_machine_dict():
     return {
             "darwin9" : { 
-                        "arm" :       (40,     0,    0,          True,          True),
+                        "arm" :       (40,     0,    0,          True,          32),
                       },
             "linux" : { 
-                        "arm" :       (40,    97,    0,          True,          True),
-                        "armeb":      (40,    97,    0,          False,         True),
-                        "powerpc":    (20,     0,    0,          False,         True),
-                        "i386":       ( 3,     0,    0,          True,          True),
-                        "i486":       ( 3,     0,    0,          True,          True),
-                        "i586":       ( 3,     0,    0,          True,          True),
-                        "i686":       ( 3,     0,    0,          True,          True),
-                        "x86_64":     (62,     0,    0,          True,          False),
-                        "ia64":       (50,     0,    0,          True,          False),
-                        "alpha":      (36902,  0,    0,          True,          False),
-                        "hppa":       (15,     3,    0,          False,         True),
-                        "m68k":       ( 4,     0,    0,          False,         True),
-                        "mips":       ( 8,     0,    0,          False,         True),
-                        "mipsel":     ( 8,     0,    0,          True,          True),
-                        "s390":       (22,     0,    0,          False,         True),
-                        "sh4":        (42,     0,    0,          True,          True),
-                        "sparc":      ( 2,     0,    0,          False,         True),
+                        "arm" :       (40,    97,    0,          True,          32),
+                        "armeb":      (40,    97,    0,          False,         32),
+                        "powerpc":    (20,     0,    0,          False,         32),
+                        "i386":       ( 3,     0,    0,          True,          32),
+                        "i486":       ( 3,     0,    0,          True,          32),
+                        "i586":       ( 3,     0,    0,          True,          32),
+                        "i686":       ( 3,     0,    0,          True,          32),
+                        "x86_64":     (62,     0,    0,          True,          64),
+                        "ia64":       (50,     0,    0,          True,          64),
+                        "alpha":      (36902,  0,    0,          True,          64),
+                        "hppa":       (15,     3,    0,          False,         32),
+                        "m68k":       ( 4,     0,    0,          False,         32),
+                        "mips":       ( 8,     0,    0,          False,         32),
+                        "mipsel":     ( 8,     0,    0,          True,          32),
+                        "s390":       (22,     0,    0,          False,         32),
+                        "sh4":        (42,     0,    0,          True,          32),
+                        "sparc":      ( 2,     0,    0,          False,         32),
                       },
             "linux-uclibc" : { 
-                        "arm" :       (  40,    97,    0,          True,          True),
-                        "armeb":      (  40,    97,    0,          False,         True),
-                        "powerpc":    (  20,     0,    0,          False,         True),
-                        "i386":       (   3,     0,    0,          True,          True),
-                        "i486":       (   3,     0,    0,          True,          True),
-                        "i586":       (   3,     0,    0,          True,          True),
-                        "i686":       (   3,     0,    0,          True,          True),
-                        "x86_64":     (  62,     0,    0,          True,          False),
-                        "mips":       (   8,     0,    0,          False,         True),
-                        "mipsel":     (   8,     0,    0,          True,          True),
-                        "avr32":      (6317,     0,    0,          False,         True),
-			"sh4":        (42,	 0,    0,          True,          True),
+                        "arm" :       (  40,    97,    0,          True,          32),
+                        "armeb":      (  40,    97,    0,          False,         32),
+                        "powerpc":    (  20,     0,    0,          False,         32),
+                        "i386":       (   3,     0,    0,          True,          32),
+                        "i486":       (   3,     0,    0,          True,          32),
+                        "i586":       (   3,     0,    0,          True,          32),
+                        "i686":       (   3,     0,    0,          True,          32),
+                        "x86_64":     (  62,     0,    0,          True,          64),
+                        "mips":       (   8,     0,    0,          False,         32),
+                        "mipsel":     (   8,     0,    0,          True,          32),
+                        "avr32":      (6317,     0,    0,          False,         32),
+			"sh4":        (42,	 0,    0,          True,          32),
 
                       },
             "uclinux-uclibc" : {
-                        "bfin":       ( 106,     0,    0,          True,         True),
+                        "bfin":       ( 106,     0,    0,          True,         32),
                       }, 
             "linux-gnueabi" : {
-                        "arm" :       (40,     0,    0,          True,          True),
-                        "armeb" :     (40,     0,    0,          False,         True),
+                        "arm" :       (40,     0,    0,          True,          32),
+                        "armeb" :     (40,     0,    0,          False,         32),
                       },
             "linux-uclibcgnueabi" : {
-                        "arm" :       (40,     0,    0,          True,          True),
-                        "armeb" :     (40,     0,    0,          False,         True),
+                        "arm" :       (40,     0,    0,          True,          32),
+                        "armeb" :     (40,     0,    0,          False,         32),
                       },
             "linux-gnuspe" : {
-                        "powerpc":    (20,     0,    0,          False,         True),
+                        "powerpc":    (20,     0,    0,          False,         32),
                       },
             "linux-uclibcspe" : {
-                        "powerpc":    (20,     0,    0,          False,         True),
+                        "powerpc":    (20,     0,    0,          False,         32),
                       },
 
        }
@@ -243,7 +243,7 @@ def package_qa_check_arch(path,name,d, elf):
         return True
 
     #if this will throw an exception, then fix the dict above
-    (machine, osabi, abiversion, littleendian, bits32) \
+    (machine, osabi, abiversion, littleendian, bits) \
         = package_qa_get_machine_dict()[target_os][target_arch]
 
     # Check the architecture and endiannes of the binary
@@ -251,6 +251,10 @@ def package_qa_check_arch(path,name,d, elf):
         error_msg = "Architecture did not match (%d to %d) on %s" % \
                  (machine, elf.machine(), package_qa_clean_path(path,d))
         sane = package_qa_handle_error(4, error_msg, name, path, d)
+    elif not bits == elf.abiSize():
+        error_msg = "Bit size did not match (%d to %d) on %s" % \
+                 (bits, elf.abiSize(), package_qa_clean_path(path,d))
+        sane = package_qa_handle_error(4, error_msg, name, path, d)
     elif not littleendian == elf.isLittleEndian():
         error_msg = "Endiannes did not match (%d to %d) on %s" % \
                  (littleendian, elf.isLittleEndian(), package_qa_clean_path(path,d))
@@ -342,8 +346,12 @@ def package_qa_check_license(workdir, d):
     sane = True
 
     lic_files = bb.data.getVar('LIC_FILES_CHKSUM', d, True)
+    lic = bb.data.getVar('LICENSE', d, True)
     pn = bb.data.getVar('PN', d, True)
 
+    if lic == "CLOSED":
+        return True
+
     if not lic_files:
         # just throw a warning now. Once licensing data in entered for enough of the recipes,
         # this will be converted into error and False will be returned.
@@ -445,14 +453,12 @@ def package_qa_walk(path, funcs, package,d):
     #if this will throw an exception, then fix the dict above
     target_os   = bb.data.getVar('TARGET_OS',   d, True)
     target_arch = bb.data.getVar('TARGET_ARCH', d, True)
-    (machine, osabi, abiversion, littleendian, bits32) \
-        = package_qa_get_machine_dict()[target_os][target_arch]
 
     sane = True
     for root, dirs, files in os.walk(path):
         for file in files:
             path = os.path.join(root,file)
-            elf = oe.qa.ELFFile(path, bits32)
+            elf = oe.qa.ELFFile(path)
             try:
                 elf.open()
             except:

meta/classes/kernel.bbclass

@@ -202,7 +202,7 @@ do_menuconfig() {
         export DBUS_SESSION_BUS_ADDRESS='${DBUS_SESSION_BUS_ADDRESS}'
         export XAUTHORITY='${XAUTHORITY}'
 	export TERMWINDOWTITLE="${PN} Kernel Configuration"
-	export SHELLCMDS="bash make menuconfig"
+	export SHELLCMDS="make menuconfig"
 	${TERMCMDRUN}
 	if [ $? -ne 0 ]; then
 		echo "Fatal: '${TERMCMD}' not found. Check TERMCMD variable."

meta/classes/module.bbclass

@@ -3,6 +3,13 @@ DEPENDS += "virtual/kernel"
 
 inherit module-base
 
+# Ensure the hostprogs are available for module compilation
+module_do_compile_prepend() {
+	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
+	oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+	           -C ${STAGING_KERNEL_DIR} scripts
+}
+
 module_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
@@ -15,7 +22,10 @@ module_do_compile() {
 
 module_do_install() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
-	oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" CC="${KERNEL_CC}" LD="${KERNEL_LD}" modules_install
+	oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" \
+	           KERNEL_SRC=${STAGING_KERNEL_DIR} \
+	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
+	           modules_install
 }
 
 pkg_postinst_append () {

meta/classes/native.bbclass

@@ -22,6 +22,7 @@ TARGET_OS = "${BUILD_OS}"
 TARGET_VENDOR = "${BUILD_VENDOR}"
 TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
+TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"
 HOST_OS = "${BUILD_OS}"

meta/classes/nativesdk.bbclass

@@ -34,6 +34,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_FPU = ""
 
 CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
 CFLAGS = "${BUILDSDK_CFLAGS}"

meta/classes/package.bbclass

@@ -180,6 +180,7 @@ def splitfile(file, debugfile, debugsrcdir, d):
     objcopy = bb.data.getVar("OBJCOPY", d, True)
     debugedit = bb.data.expand("${STAGING_LIBDIR_NATIVE}/rpm/bin/debugedit", d)
     workdir = bb.data.expand("${WORKDIR}", d)
+    workparentdir = os.path.dirname(workdir)
     sourcefile = bb.data.expand("${WORKDIR}/debugsources.list", d)
 
     # We ignore kernel modules, we don't generate debug info files.
@@ -194,7 +195,7 @@ def splitfile(file, debugfile, debugsrcdir, d):
 
     # We need to extract the debug src information here...
     if debugsrcdir:
-	os.system("%s'%s' -b '%s' -d '%s' -i -l '%s' '%s'" % (pathprefix, debugedit, workdir, debugsrcdir, sourcefile, file))
+	os.system("%s'%s' -b '%s' -d '%s' -i -l '%s' '%s'" % (pathprefix, debugedit, workparentdir, debugsrcdir, sourcefile, file))
 
     bb.mkdirhier(os.path.dirname(debugfile))
 
@@ -222,15 +223,20 @@ def splitfile2(debugsrcdir, d):
     objcopy = bb.data.getVar("OBJCOPY", d, True)
     debugedit = bb.data.expand("${STAGING_LIBDIR_NATIVE}/rpm/bin/debugedit", d)
     workdir = bb.data.expand("${WORKDIR}", d)
+    workparentdir = os.path.dirname(workdir)
+    workbasedir = os.path.basename(workdir)
     sourcefile = bb.data.expand("${WORKDIR}/debugsources.list", d)
 
     if debugsrcdir:
        bb.mkdirhier("%s%s" % (dvar, debugsrcdir))
 
        processdebugsrc =  "LC_ALL=C ; sort -z -u '%s' | egrep -v -z '(<internal>|<built-in>)$' | "
+       # We need to ignore files that are not actually ours
+       # we do this by only paying attention to items from this package
+       processdebugsrc += "fgrep -z '%s' | "
        processdebugsrc += "(cd '%s' ; cpio -pd0mL '%s%s' 2>/dev/null)"
 
-       os.system(processdebugsrc % (sourcefile, workdir, dvar, debugsrcdir))
+       os.system(processdebugsrc % (sourcefile, workbasedir, workparentdir, dvar, debugsrcdir))
 
        # The copy by cpio may have resulted in some empty directories!  Remove these
        for root, dirs, files in os.walk("%s%s" % (dvar, debugsrcdir)):

meta/classes/package_rpm.bbclass

@@ -777,7 +777,7 @@ python do_package_rpm () {
 	cmd = cmd + " --define 'debug_package %{nil}'"
 	cmd = cmd + " -bb " + outspecfile
 
-	# Build the spec file!
+	# Build the rpm package!
 	bb.data.setVar('BUILDSPEC', cmd + "\n", d)
 	bb.data.setVarFlag('BUILDSPEC', 'func', '1', d)
 	bb.build.exec_func('BUILDSPEC', d)
@@ -797,6 +797,9 @@ SSTATETASKS += "do_package_write_rpm"
 do_package_write_rpm[sstate-name] = "deploy-rpm"
 do_package_write_rpm[sstate-inputdirs] = "${PKGWRITEDIRRPM}"
 do_package_write_rpm[sstate-outputdirs] = "${DEPLOY_DIR_RPM}"
+# Take a shared lock, we can write multiple packages at the same time...
+# but we need to stop the rootfs/solver from running while we do...
+do_package_write_rpm[sstate-lockfile-shared] += "${DEPLOY_DIR_RPM}/rpm.lock"
 
 python do_package_write_rpm_setscene () {
 	sstate_setscene(d)

meta/classes/populate_sdk_rpm.bbclass

@@ -5,6 +5,7 @@ rpmlibdir = "/var/lib/rpm"
 RPMOPTS="--dbpath ${rpmlibdir} --define='_openall_before_chroot 1'"
 RPM="rpm ${RPMOPTS}"
 
+do_populate_sdk[lockfiles] += "${DEPLOY_DIR_RPM}/rpm.lock"
 
 populate_sdk_post_rpm () {
 

meta/classes/rootfs_rpm.bbclass

@@ -46,6 +46,32 @@ fakeroot rootfs_rpm_do_rootfs () {
 	# Setup base system configuration
 	mkdir -p ${IMAGE_ROOTFS}/etc/rpm/
 
+	mkdir -p ${IMAGE_ROOTFS}${rpmlibdir}
+	mkdir -p ${IMAGE_ROOTFS}${rpmlibdir}/log
+	cat > ${IMAGE_ROOTFS}${rpmlibdir}/DB_CONFIG << EOF
+# ================ Environment
+set_data_dir            .
+set_create_dir          .
+set_lg_dir              ./log
+set_tmp_dir             ./tmp
+
+# -- thread_count must be >= 8
+set_thread_count        64
+
+# ================ Logging
+
+# ================ Memory Pool
+set_mp_mmapsize         268435456
+
+# ================ Locking
+set_lk_max_locks        16384
+set_lk_max_lockers      16384
+set_lk_max_objects      16384
+mutex_set_max           163840
+
+# ================ Replication
+EOF
+
 	#install pacakges
 	export INSTALL_ROOTFS_RPM="${IMAGE_ROOTFS}"
 	export INSTALL_PLATFORM_RPM="${TARGET_ARCH}"

meta/classes/sanity.bbclass

@@ -40,7 +40,26 @@ def check_sanity_tmpdir_change(tmpdir):
 def check_sanity_version_change():
     # Sanity checks to be done when SANITY_VERSION changes
     return ""
-    
+
+def check_pseudo_wrapper():
+    import subprocess as sub
+    # Check if bitbake wrapper is being used
+    pseudo_build = os.environ.get( 'PSEUDO_BUILD' )
+    if not pseudo_build:
+        bb.warn("Bitbake has not been run using the bitbake wrapper (scripts/bitbake); this is likely because your PATH has been altered from that normally set up by the poky-init-build-env script. Not using the wrapper may result in failures during package installation, so it is highly recommended that you set your PATH back so that the wrapper script is being executed.")
+
+    if (not pseudo_build) or pseudo_build == '2':
+        # pseudo ought to be working, let's see if it is...
+        p = sub.Popen(['sh', '-c', 'PSEUDO_DISABLED=0 id -u'],stdout=sub.PIPE,stderr=sub.PIPE)
+        out, err = p.communicate()
+        if out.rstrip() != '0':
+            msg = "Pseudo is not functioning correctly, which will cause failures during package installation. Please check your configuration."
+            if pseudo_build == '2':
+                return msg
+            else:
+                bb.warn(msg)
+    return ""
+
 def check_create_long_filename(filepath, pathname):
     testfile = os.path.join(filepath, ''.join([`num`[-1] for num in xrange(1,200)]))
     try:
@@ -149,7 +168,7 @@ def check_sanity(e):
     if not check_app_exists('${BUILD_PREFIX}g++', e.data):
         missing = missing + "C++ Compiler (%sg++)," % data.getVar("BUILD_PREFIX", e.data, True)
 
-    required_utilities = "patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg chrpath wget"
+    required_utilities = "patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg chrpath wget cpio"
 
     # qemu-native needs gcc 3.x
     if "qemu-native" not in assume_provided and "gcc3-native" in assume_provided:
@@ -170,10 +189,12 @@ def check_sanity(e):
         # This path is no longer user-readable in modern (very recent) Linux
         try:
             if os.path.exists("/proc/sys/vm/mmap_min_addr"):
-                f = file("/proc/sys/vm/mmap_min_addr", "r")
-                if (f.read().strip() != "0"):
-                        messages = messages + "/proc/sys/vm/mmap_min_addr is not 0. This will cause problems with qemu so please fix the value (as root).\n\nTo fix this in later reboots, set vm.mmap_min_addr = 0 in /etc/sysctl.conf.\n"
-                f.close()
+                f = open("/proc/sys/vm/mmap_min_addr", "r")
+                try:
+                    if (int(f.read().strip()) > 65536):
+                        messages = messages + "/proc/sys/vm/mmap_min_addr is not <= 65536. This will cause problems with qemu so please fix the value (as root).\n\nTo fix this in later reboots, set vm.mmap_min_addr = 65536 in /etc/sysctl.conf.\n"
+                finally:
+                    f.close()
         except:
             pass
 
@@ -185,6 +206,10 @@ def check_sanity(e):
         missing = missing.rstrip(',')
         messages = messages + "Please install following missing utilities: %s\n" % missing
 
+    pseudo_msg = check_pseudo_wrapper()
+    if pseudo_msg != "":
+        messages = messages + pseudo_msg + '\n'
+
     # Check if DISPLAY is set if IMAGETEST is set
     if not data.getVar( 'DISPLAY', e.data, True ) and data.getVar( 'IMAGETEST', e.data, True ) == 'qemu':
         messages = messages + 'qemuimagetest needs a X desktop to start qemu, please set DISPLAY correctly (e.g. DISPLAY=:1.0)\n'
@@ -211,7 +236,7 @@ def check_sanity(e):
     nolibs = data.getVar('NO32LIBS', e.data, True)
     if not nolibs:
         lib32path = '/lib'
-        if os.path.exists('/lib64') and os.path.islink('/lib64'):
+        if os.path.exists('/lib64') and ( os.path.islink('/lib64') or os.path.islink('/lib') ):
            lib32path = '/lib32'
 
         if os.path.exists('%s/libc.so.6' % lib32path) and not os.path.exists('/usr/include/gnu/stubs-32.h'):

meta/classes/sstate.bbclass

@@ -39,8 +39,10 @@ python () {
         scan_cmd = "grep -Irl ${STAGING_DIR} ${SSTATE_BUILDDIR}"
         bb.data.setVar('SSTATE_SCAN_CMD', scan_cmd, d)
 
+    unique_tasks = set((bb.data.getVar('SSTATETASKS', d, True) or "").split())
+    d.setVar('SSTATETASKS', " ".join(unique_tasks))
     namemap = []
-    for task in (bb.data.getVar('SSTATETASKS', d, True) or "").split():
+    for task in unique_tasks:
         namemap.append(bb.data.getVarFlag(task, 'sstate-name', d))
         funcs = bb.data.getVarFlag(task, 'prefuncs', d) or ""
         funcs = "sstate_task_prefunc " + funcs
@@ -58,6 +60,7 @@ def sstate_init(name, task, d):
     ss['dirs'] = []
     ss['plaindirs'] = []
     ss['lockfiles'] = []
+    ss['lockfiles-shared'] = []
     return ss
 
 def sstate_state_fromvars(d, task = None):
@@ -72,6 +75,7 @@ def sstate_state_fromvars(d, task = None):
     outputs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-outputdirs', d) or "", d)).split()
     plaindirs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-plaindirs', d) or "", d)).split()
     lockfiles = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-lockfile', d) or "", d)).split()
+    lockfilesshared = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-lockfile-shared', d) or "", d)).split()
     interceptfuncs = (bb.data.expand(bb.data.getVarFlag("do_" + task, 'sstate-interceptfuncs', d) or "", d)).split()
     if not name or len(inputs) != len(outputs):
         bb.fatal("sstate variables not setup correctly?!")
@@ -80,6 +84,7 @@ def sstate_state_fromvars(d, task = None):
     for i in range(len(inputs)):
         sstate_add(ss, inputs[i], outputs[i], d)
     ss['lockfiles'] = lockfiles
+    ss['lockfiles-shared'] = lockfilesshared
     ss['plaindirs'] = plaindirs
     ss['interceptfuncs'] = interceptfuncs
     return ss
@@ -101,6 +106,8 @@ def sstate_install(ss, d):
         bb.fatal("Package already staged (%s)?!" % manifest)
 
     locks = []
+    for lock in ss['lockfiles-shared']:
+        locks.append(bb.utils.lockfile(lock, True))
     for lock in ss['lockfiles']:
         locks.append(bb.utils.lockfile(lock))
 
@@ -229,19 +236,23 @@ def sstate_clean(ss, d):
 
     manifest = bb.data.expand("${SSTATE_MANFILEPREFIX}.%s" % ss['name'], d)
 
-    if not os.path.exists(manifest):
-       return
+    if os.path.exists(manifest):
+        locks = []
+        for lock in ss['lockfiles-shared']:
+            locks.append(bb.utils.lockfile(lock, True))
+        for lock in ss['lockfiles']:
+            locks.append(bb.utils.lockfile(lock))
 
-    locks = []
-    for lock in ss['lockfiles']:
-        locks.append(bb.utils.lockfile(lock))
+        sstate_clean_manifest(manifest, d)
 
-    sstate_clean_manifest(manifest, d)
+        for lock in locks:
+            bb.utils.unlockfile(lock)
 
-    for lock in locks:
-        bb.utils.unlockfile(lock)
-
-    oe.path.remove(d.getVar("STAMP", True) + ".do_" + ss['task'] + "*")
+    stfile = d.getVar("STAMP", True) + ".do_" + ss['task']
+    oe.path.remove(stfile)
+    oe.path.remove(stfile + "_setscene")
+    oe.path.remove(stfile + ".*")
+    oe.path.remove(stfile + "_setscene" + ".*")
 
 CLEANFUNCS += "sstate_cleanall"
 
@@ -301,18 +312,45 @@ def sstate_hardcode_path(d):
 def sstate_package(ss, d):
     import oe.path
 
+    def make_relative_symlink(path, outputpath, d):
+        # Replace out absolute TMPDIR paths in symlinks with relative ones
+        if not os.path.islink(path):
+            return
+        link = os.readlink(path)
+        if not os.path.isabs(link):
+            return
+        if not link.startswith(tmpdir):
+            return
+
+        depth = link.rpartition(tmpdir)[2].count('/')
+        base = link.partition(tmpdir)[2].strip()
+        while depth > 1:
+            base = "../" + base
+            depth -= 1
+
+        bb.debug(2, "Replacing absolute path %s with relative path %s" % (link, base))
+        os.remove(path)
+        os.symlink(base, path)
+
+    tmpdir = bb.data.getVar('TMPDIR', d, True)
+
     sstatebuild = bb.data.expand("${WORKDIR}/sstate-build-%s/" % ss['name'], d)
     sstatepkg = bb.data.getVar('SSTATE_PKG', d, True) + '_'+ ss['name'] + ".tgz"
     bb.mkdirhier(sstatebuild)
     bb.mkdirhier(os.path.dirname(sstatepkg))
     for state in ss['dirs']:
         srcbase = state[0].rstrip("/").rsplit('/', 1)[0]
-        oe.path.copytree(state[1], sstatebuild + state[0])
         for walkroot, dirs, files in os.walk(state[1]):
             for file in files:
                 srcpath = os.path.join(walkroot, file)
                 dstpath = srcpath.replace(state[1], sstatebuild + state[0])
                 bb.debug(2, "Preparing %s for packaging at %s" % (srcpath, dstpath))
+                make_relative_symlink(srcpath, dstpath, d)
+            for dir in dirs:
+                srcpath = os.path.join(walkroot, dir)
+                dstpath = srcpath.replace(state[1], sstatebuild + state[0])
+                make_relative_symlink(srcpath, dstpath, d)
+        oe.path.copytree(state[1], sstatebuild + state[0])
 
     workdir = bb.data.getVar('WORKDIR', d, True)
     for plain in ss['plaindirs']:
@@ -354,7 +392,7 @@ def pstaging_fetch(sstatepkg, d):
     # Try a fetch from the sstate mirror, if it fails just return and
     # we will build the package
     try:
-        fetcher = bb.fetch2.Fetch([srcuri], localdata)
+        fetcher = bb.fetch2.Fetch([srcuri], localdata, cache=False)
         fetcher.download()        
 
         # Need to optimise this, if using file:// urls, the fetcher just changes the local path

meta/classes/toolchain-scripts.bbclass

@@ -24,6 +24,8 @@ toolchain_create_sdk_env_script () {
 	fi
 	echo 'export CFLAGS="${TARGET_CC_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
 	echo 'export CXXFLAGS="${TARGET_CC_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
+	echo 'export LDFLAGS="--sysroot=${SDKTARGETSYSROOT}"' >> $script
+	echo 'export CPPFLAGS="--sysroot=${SDKTARGETSYSROOT}"' >> $script
 	echo 'export POKY_NATIVE_SYSROOT="${SDKPATHNATIVE}"' >> $script
 	echo 'export POKY_TARGET_SYSROOT="${SDKTARGETSYSROOT}"' >> $script
 	echo 'export POKY_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script
@@ -83,6 +85,8 @@ toolchain_create_sdk_env_script_for_installer () {
 	fi
 	echo 'export CFLAGS="${TARGET_CC_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
 	echo 'export CXXFLAGS="${TARGET_CC_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
+	echo 'export LDFLAGS="--sysroot=##SDKTARGETSYSROOT##"' >> $script
+	echo 'export CPPFLAGS="--sysroot=##SDKTARGETSYSROOT##"' >> $script
 	echo 'export POKY_NATIVE_SYSROOT="${SDKPATHNATIVE}"' >> $script
 	echo 'export POKY_TARGET_SYSROOT="##SDKTARGETSYSROOT##"' >> $script
 	echo 'export POKY_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script

meta/conf/bitbake.conf

@@ -92,8 +92,9 @@ SDK_CC_ARCH = "${BUILD_CC_ARCH}"
 
 BASE_PACKAGE_ARCH = "${HOST_ARCH}"
 PACKAGE_ARCH = "${BASE_PACKAGE_ARCH}"
-MACHINE_ARCH = "${@[bb.data.getVar('BASE_PACKAGE_ARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))]}"
-PACKAGE_ARCHS = "all any noarch ${TARGET_ARCH} ${PACKAGE_EXTRA_ARCHS} ${MACHINE}"
+MACHINE_ARCH = "${@[bb.data.getVar('BASE_PACKAGE_ARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-', '_')}"
+PACKAGE_EXTRA_ARCHS ??= "${TARGET_ARCH}"
+PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}"
 # MACHINE shouldn't be included here as a variable dependency since machine specific 
 # packages are handled using multimachine
 PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
@@ -348,7 +349,7 @@ IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
 
 # This option allows for a precentage overage of the actaul image size rather than a
 # fixed extra space
-IMAGE_OVERHEAD_FACTOR ?= 1.2
+IMAGE_OVERHEAD_FACTOR ?= 1.3
 
 # Comment this option if you want default genext2fs behavior (i.e. create minimal inode number)
 IMAGE_EXTRA_OPTION ?= "-i 8192"
@@ -759,5 +760,5 @@ TRANSLATED_TARGET_ARCH ??= ${TARGET_ARCH}
 # Setup our default hash policy
 BB_SIGNATURE_HANDLER ?= "basic"
 BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
-BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
+BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM USER FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET POKYBASE"
 

meta/conf/distro/include/distro_tracking_fields.inc

@@ -2590,11 +2590,11 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-libmusicbrainz="2 years"
 RECIPE_LAST_UPDATE_pn-libmusicbrainz = "Nov 16, 2010"
 RECIPE_MAINTAINER_pn-libmusicbrainz = "Dongxiao Xu <dongxiao.xu@intel.com>"
 
-RECIPE_STATUS_pn-clutter-gst-1.0 = "red"
-DISTRO_PN_ALIAS_pn-clutter-gst-1.0 = "OpenSuSE=clutter-gst Debian=clutter-gst"
-RECIPE_LATEST_VERSION_pn-clutter-gst-1.0 = "0.11.0+git0+d48c6fc67b48304f90e51b520631c1ecc10410af"
-RECIPE_LAST_UPDATE_pn-clutter-gst = "Feb 4, 2010"
-RECIPE_MAINTAINER_pn-clutter-gst-1.0 = "Dongxiao Xu <dongxiao.xu@intel.com>"
+RECIPE_STATUS_pn-clutter-gst-1.4 = "red"
+DISTRO_PN_ALIAS_pn-clutter-gst-1.4 = "OpenSuSE=clutter-gst Debian=clutter-gst"
+RECIPE_LATEST_VERSION_pn-clutter-gst-1.4 = "0.11.0+git0+d48c6fc67b48304f90e51b520631c1ecc10410af"
+RECIPE_LAST_UPDATE_pn-clutter-gst-1.4 = "Feb 4, 2010"
+RECIPE_MAINTAINER_pn-clutter-gst-1.4 = "Dongxiao Xu <dongxiao.xu@intel.com>"
 
 RECIPE_STATUS_pn-farsight2 = "red"
 RECIPE_LATEST_VERSION_pn-farsight2 = "0.0.20"
@@ -2681,13 +2681,14 @@ RECIPE_MAINTAINER_pn-libsamplerate0 = "Dongxiao Xu <dongxiao.xu@intel.com>"
 RECIPE_STATUS_pn-oprofileui = "green"
 DISTRO_PN_ALIAS_pn-oprofileui = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 RECIPE_DEPENDENCY_CHECK_pn-oprofileui = "not done"
-RECIPE_LATEST_VERSION_pn-oprofileui = "0.0+svnr197"
-RECIPE_NO_OF_PATCHES_pn-oprofileui = "0"
+RECIPE_LATEST_VERSION_pn-oprofileui = "0.0+git0+e2d998d8a55dc1e49d1588841f83eff8e6809753"
+RECIPE_NO_OF_PATCHES_pn-oprofileui = "1"
+RECIPE_PATCH_pn-oprofileui+dso_linking_change_build_fix = "fix the build by explicitely passing -lm to linker"
 RECIPE_INTEL_SECTION_pn-oprofileui = "sdk-tools"
-RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-oprofileui = "13 days"
-RECIPE_LATEST_RELEASE_DATE_pn-oprofileui = "07/2008"
+RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-oprofileui = "5 months"
+RECIPE_LATEST_RELEASE_DATE_pn-oprofileui = "Dec 10, 2010"
 RECIPE_COMMENTS_pn-oprofileui = ""
-RECIPE_LAST_UPDATE_pn-oprofileui = "Jul 20, 2010"
+RECIPE_LAST_UPDATE_pn-oprofileui = "Mar 9, 2011"
 RECIPE_MAINTAINER_pn-oprofileui = "Dexuan Cui <dexuan.cui@intel.com>"
 
 RECIPE_STATUS_pn-oprofile = "green"
@@ -5216,10 +5217,10 @@ RECIPE_STATUS_pn-clutter-box2d = "red"
 RECIPE_LATEST_VERSION_pn-clutter-box2d = "0.10.0"
 RECIPE_MAINTAINER_pn-clutter-box2d = "Edwin Zhai <edwin.zhai@intel.com>"
 
-RECIPE_STATUS_pn-clutter-gtk-1.0 = "red"
-DISTRO_PN_ALIAS_pn-clutter-gtk-1.0 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
-RECIPE_LATEST_VERSION_pn-clutter-gtk-1.0 = "0.90.0+git0+e8d828ba1d87937baa571e68fdff22f3e2d79ca8"
-RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Edwin Zhai <edwin.zhai@intel.com>"
+RECIPE_STATUS_pn-clutter-gtk-1.4 = "red"
+DISTRO_PN_ALIAS_pn-clutter-gtk-1.4 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
+RECIPE_LATEST_VERSION_pn-clutter-gtk-1.4 = "0.90.0+git0+e8d828ba1d87937baa571e68fdff22f3e2d79ca8"
+RECIPE_MAINTAINER_pn-clutter-gtk-1.4 = "Edwin Zhai <edwin.zhai@intel.com>"
 
 RECIPE_STATUS_pn-tidy = "red"
 RECIPE_LATEST_VERSION_pn-tidy = "0.1.0+git0+e25416e1293e1074bfa6727c80527dcff5b1f3cb"
@@ -5236,14 +5237,14 @@ RECIPE_LATEST_VERSION_pn-libgalago = "0.5.2"
 RECIPE_LAST_UPDATE_pn-libgalago = "Apr 11, 2007"
 RECIPE_MAINTAINER_pn-libgalago = "Edwin Zhai <edwin.zhai@intel.com>"
 
-RECIPE_STATUS_pn-clutter-1.0 = "red"
-DISTRO_PN_ALIAS_pn-clutter-1.0 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
-RECIPE_LATEST_VERSION_pn-clutter-1.0 = "1.0+git0+ce5025d0a2b701541ca9343686f9dac858905da4"
-RECIPE_LAST_UPDATE_pn-clutter-1.0 = "Jan 29, 2010"
-RECIPE_MAINTAINER_pn-clutter-1.0 = "Edwin Zhai <edwin.zhai@intel.com>"
+RECIPE_STATUS_pn-clutter-1.4 = "red"
+DISTRO_PN_ALIAS_pn-clutter-1.4 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+RECIPE_LATEST_VERSION_pn-clutter-1.4 = "1.0+git0+ce5025d0a2b701541ca9343686f9dac858905da4"
+RECIPE_LAST_UPDATE_pn-clutter-1.4 = "Jan 29, 2010"
+RECIPE_MAINTAINER_pn-clutter-1.4 = "Edwin Zhai <edwin.zhai@intel.com>"
 
 RECIPE_STATUS_pn-clutter = "red"
-DISTRO_PN_ALIAS_pn-clutter-gtk-1.0 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
+DISTRO_PN_ALIAS_pn-clutter = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
 RECIPE_LATEST_VERSION_pn-clutter = "1.2.8"
 RECIPE_MAINTAINER_pn-clutter = "Edwin Zhai <edwin.zhai@intel.com>"
 
@@ -5468,12 +5469,11 @@ RECIPE_STATUS_pn-swabber = "red"
 RECIPE_STATUS_pn-mc = "red"
 RECIPE_STATUS_pn-man = "red"
 RECIPE_STATUS_pn-man-pages = "red"
-RECIPE_STATUS_pn-gthumb = "red"
 RECIPE_STATUS_pn-guilt-native = "red"
 RECIPE_STATUS_pn-icon-naming-utils = "red"
 RECIPE_STATUS_pn-groff = "red"
 RECIPE_LATEST_VERSION_pn-groff = "1.21"
-RECIPE_NO_UPDATE_REASON_pn-texinfo = "1.18.1.4 is latest GPLv2 Version no 1.21"
+RECIPE_NO_UPDATE_REASON_pn-groff = "1.18.1.4 is latest GPLv2 Version no 1.21"
 
 RECIPE_STATUS_pn-eglibc = "red"
 
@@ -5489,8 +5489,10 @@ RECIPE_LATEST_RELEASE_DATE_pn-lighttpd = "08/2010"
 RECIPE_COMMENTS_pn-lighttpd = ""
 
 RECIPE_LATEST_VERSION_pn-adt-installer = "1.0"
-RECIPE_MANUAL_CHECK_DATE_adt-installer-mpeg2dec = "Jan 17, 2011"
+RECIPE_MANUAL_CHECK_DATE_adt-installer = "Jan 17, 2011"
+DISTRO_PN_ALIAS_pn-adt-installer = "Intel"
 RECIPE_LATEST_VERSION_pn-glew = "1.5.7"
+RECIPE_MANUAL_CHECK_DATE_pn-glew = "Feb 28, 2011"
 RECIPE_LATEST_VERSION_pn-mpeg2dec = "0.4.1"
 RECIPE_MANUAL_CHECK_DATE_pn-mpeg2dec = "Jan 17, 2011"
 RECIPE_LATEST_VERSION_pn-lame = "3.98.4"
@@ -5505,7 +5507,9 @@ RECIPE_LATEST_VERSION_pn-libxml-simple-perl = "2.18"
 RECIPE_LATEST_VERSION_pn-talloc = "2.0.5"
 RECIPE_LATEST_VERSION_pn-mesa-demos = "8.0.1"
 RECIPE_LATEST_VERSION_pn-libtool-cross = "2.4"
+RECIPE_STATUS_pn-gthumb = "red"
 RECIPE_LATEST_VERSION_pn-gthumb = "2.12.2"
+
 RECIPE_LATEST_VERSION_pn-libtheora = "1.2.0"
 RECIPE_NO_UPDATE_REASON_pn-libtheora = "1.1.1 is latest stable release not 1.2.0alpha1"
 
@@ -5520,6 +5524,8 @@ RECIPE_LATEST_VERSION_pn-sysprof = "6b5b8432711ef5c747f8375073cd9af88922d3c6"
 RECIPE_LATEST_VERSION_pn-table = "d42a44938699ee30a998fc42bc149aebf69389db"
 RECIPE_LATEST_VERSION_pn-texinfo = "4.13a"
 RECIPE_NO_UPDATE_REASON_pn-texinfo = "Checking script parse directory wrong"
+RECIPE_MANUAL_CHECK_DATE_pn-texinfo = "Feb 28, 2011"
+
 RECIPE_LATEST_VERSION_pn-yaffs2-utils = "HEAD"
 RECIPE_LATEST_VERSION_pn-blktrace = "a788dfde86dfaff8f1c277a233f92c1822e06b76"
 RECIPE_LATEST_VERSION_pn-dtc = "37c0b6a0916c31a5eae0a9ddfcc5d0b8fb4569c6"
@@ -5598,3 +5604,31 @@ RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-docbook-utils = "1 month"
 RECIPE_COMMENTS_pn-docbook-utils = ""
 RECIPE_LAST_UPDATE_pn-docbook-utils = "Jan 26, 2011"
 RECIPE_MAINTAINER_pn-docbook-utils = "Scott Garman <scott.a.garman@intel.com>"
+
+RECIPE_LATEST_VERSION_pn-task-qte-toolchain-target = "1.0"
+RECIPE_MANUAL_CHECK_DATE_pn-task-qte-toolchain-target = "Feb 28, 2011"
+DISTRO_PN_ALIAS_pn-task-qte-toolchain-target = "Intel"
+RECIPE_LATEST_VERSION_pn-mailx = "12.4"
+RECIPE_MANUAL_CHECK_DATE_pn-mailx = "Feb 28, 2011"
+RECIPE_LATEST_VERSION_pn-libgcc = "4.5.1"
+RECIPE_MANUAL_CHECK_DATE_pn-libgcc = "Feb 28, 2011"
+
+RECIPE_STATUS_pn-transfig = "green"
+RECIPE_DEPENDENCY_CHECK_pn-transfig = "not done"
+RECIPE_LATEST_VERSION_pn-transfig = "3.2.5d"
+RECIPE_NO_OF_PATCHES_pn-transfig = "0"
+RECIPE_LATEST_RELEASE_DATE_pn-transfig = "2010/07/23"
+RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-transfig = "1 year"
+RECIPE_COMMENTS_pn-transfig = ""
+RECIPE_LAST_UPDATE_pn-transfig = "Feb 9, 2011"
+RECIPE_MAINTAINER_pn-transfig = "Scott Garman <scott.a.garman@intel.com>"
+
+RECIPE_STATUS_pn-linuxdoc-tools = "green"
+RECIPE_DEPENDENCY_CHECK_pn-linuxdoc-tools = "not done"
+RECIPE_LATEST_VERSION_pn-linuxdoc-tools = "0.9.66"
+RECIPE_NO_OF_PATCHES_pn-linuxdoc-tools = "3"
+RECIPE_LATEST_RELEASE_DATE_pn-linuxdoc-tools = "unknown"
+RECIPE_TIME_BETWEEN_LAST_TWO_RELEASES_pn-linuxdoc-tools = "unknown"
+RECIPE_COMMENTS_pn-linuxdoc-tools = ""
+RECIPE_LAST_UPDATE_pn-linuxdoc-tools = "Feb 25, 2011"
+RECIPE_MAINTAINER_pn-linuxdoc-tools = "Scott Garman <scott.a.garman@intel.com>"

meta/conf/distro/include/poky-default-revisions.inc

@@ -98,19 +98,19 @@ SRCREV_machine_pn-linux-yocto-stable_beagleboard ?= "ef7f944e773950d4016b7643f9e
 SRCREV_machine_pn-linux-yocto-stable ?= "72ca49ab08b8eb475cec82a10049503602325791"
 SRCREV_meta_pn-linux-yocto-stable ?= "e1f85a470934a0cf6abde5d95533e74501822c6b"
 # development SRCREVs
-SRCREV_machine_pn-linux-yocto_qemuarm ?= "dd15f43fe3d4820ce112501c1a790c9bc12cfd0b"
-SRCREV_machine_pn-linux-yocto_qemumips ?= "76f30ca447fd0f06e76d0cb4935b016a1440e23e"
-SRCREV_machine_pn-linux-yocto_qemuppc ?= "b318cc6df4a439dc2b547f8eb841ff1ede69419b"
-SRCREV_machine_pn-linux-yocto_qemux86 ?= "37e8651b5df243aca2388867212c06338159df4e"
-SRCREV_machine_pn-linux-yocto_qemux86-64 ?= "2b412826bbeb4a16abe2ea74f2456ab880c6e3c1"
-SRCREV_machine_pn-linux-yocto_emenlow ?= "db6fc8c0d3d7f3e474e6c6b95138123911311942"
-SRCREV_machine_pn-linux-yocto_atom-pc ?= "2b412826bbeb4a16abe2ea74f2456ab880c6e3c1"
-SRCREV_machine_pn-linux-yocto_routerstationpro ?= "17dedeb17887eb398743b04615302b61bd95ffdd"
-SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= "6117f19403ccd5c288ce553def432925296a28b7"
-SRCREV_machine_pn-linux-yocto_beagleboard ?= "2b412826bbeb4a16abe2ea74f2456ab880c6e3c1"
-SRCREV_machine_pn-linux-yocto ?= "2b412826bbeb4a16abe2ea74f2456ab880c6e3c1"
-SRCREV_meta_pn-linux-yocto ?= "e2737075b79e4fc682e41051cf1c0bc47a47d502"
-SRCREV_pn-linux-libc-headers-yocto ??= "2b412826bbeb4a16abe2ea74f2456ab880c6e3c1"
+SRCREV_machine_pn-linux-yocto_qemuarm ?= "233213a1e09eae3de7047ff406b156608788ec17"
+SRCREV_machine_pn-linux-yocto_qemumips ?= "54bb956f70349923af29f28a4f9471f5658e1787"
+SRCREV_machine_pn-linux-yocto_qemuppc ?= "6f21e2e83dc93e108183256f3efebb63a6a11b6d"
+SRCREV_machine_pn-linux-yocto_qemux86 ?= "c75cbd202d8abb0b5f316f934f5d33c17ff6d3c3"
+SRCREV_machine_pn-linux-yocto_qemux86-64 ?= "2b2ef940457f0bb40e0fb76937c921c2962364ca"
+SRCREV_machine_pn-linux-yocto_emenlow ?= "f296e59556bdd738eaea8e34606f068dddb8610f"
+SRCREV_machine_pn-linux-yocto_atom-pc ?= "2b2ef940457f0bb40e0fb76937c921c2962364ca"
+SRCREV_machine_pn-linux-yocto_routerstationpro ?= "530ca3030e15a5d829e804a58e4e449db82f9b4a"
+SRCREV_machine_pn-linux-yocto_mpc8315e-rdb ?= "e14870b99caa29b6e9d98a3e7d5337b0c63cc264"
+SRCREV_machine_pn-linux-yocto_beagleboard ?= "2b2ef940457f0bb40e0fb76937c921c2962364ca"
+SRCREV_machine_pn-linux-yocto ?= "2b2ef940457f0bb40e0fb76937c921c2962364ca"
+SRCREV_meta_pn-linux-yocto ?= "212cae404e57ff9dc58c808035770d51325c3512"
+SRCREV_pn-linux-libc-headers-yocto ??= "2b2ef940457f0bb40e0fb76937c921c2962364ca"
 SRCREV_pn-matchbox-config-gtk ??= "3ed74dfb7c57be088a5ab36e446c0ccde9fa1028"
 SRCREV_pn-matchbox-desktop-sato ??= "76"
 SRCREV_pn-matchbox-desktop ??= "af7ed6775487380be73160aa0298bf6019765fad"
@@ -140,12 +140,13 @@ OPKGSRCREV = "596"
 SRCREV_pn-opkg ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-native ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-nativesdk ??= "${OPKGSRCREV}"
+SRCREV_pn-adt-installer ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-nogpg ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-nogpg-native ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-nogpg-nativesdk ??= "${OPKGSRCREV}"
 SRCREV_pn-opkg-utils-native ??= "4747"
 SRCREV_pn-opkg-utils ??= "4747"
-SRCREV_pn-oprofileui ??= "197"
+SRCREV_pn-oprofileui ??= "e2d998d8a55dc1e49d1588841f83eff8e6809753"
 SRCREV_pn-tcf-agent ??= "1078"
 SRCREV_pn-osc-native ??= "9096"
 SRCREV_pn-owl-video ??= "394"
@@ -164,7 +165,7 @@ SRCREV_pn-qemu-nativesdk ??= "${QEMUSRCREV}"
 SRCREV_pn-qemu ??= "${QEMUSRCREV}"
 SRCREV_pn-qemugl ??= "d888bbc723c00d197d34a39b5b7448660ec1b1c0"
 SRCREV_pn-qemugl-nativesdk ??= "d888bbc723c00d197d34a39b5b7448660ec1b1c0"
-SRCREV_pn-sat-solver = "9e1f2a097965debebc69cebf8ed73c6ff31a5220"
+SRCREV_pn-sat-solver = "0a7378d5f482f477a01cf1690d76871ab8bdcc32"
 SRCREV_pn-screenshot ??= "292"
 SRCREV_pn-settings-daemon ??= "0f174f463dfed500b65533e249cd22942e439c77"
 SRCREV_pn-swabber-native ??= "a0792390c5d6d5a5bade7ab155c80eef3f30fa52"
@@ -176,12 +177,10 @@ TRACECMDREV ?= "6c696cec3f264a9399241b6e648f58bc97117d49"
 SRCREV_pn-trace-cmd ??= ${TRACECMDREV}
 SRCREV_pn-kernelshark ??= ${TRACECMDREV}
 SRCREV_pn-tidy ??= "e25416e1293e1074bfa6727c80527dcff5b1f3cb"
-SRCREV_pn-u-boot-omap3 ??= "f40f6db278f602b55820693634a7256b0b4e4b80"
-SRCREV_pn-u-boot ??= "v2010.12"
 SRCREV_pn-ubootchart ??= "10"
 SRCREV_pn-webkit-gtk ??= "72836"
 SRCREV_pn-web-webkit ??= "130"
-SRCREV_pn-web ??= "129"
+SRCREV_pn-web ??= "131"
 SRCREV_pn-xcb-proto ??= "d81ca233e98be8fa59e8c90d262c0516944c5a66"
 SRCREV_pn-xcb-proto-native ??= "d81ca233e98be8fa59e8c90d262c0516944c5a66"
 SRCREV_pn-xf86-video-intel ??= "87ea531c5dc5b39809395b277c330854aaaaf019"

meta/conf/distro/include/poky-default.inc

@@ -19,7 +19,7 @@ GCCVERSION ?= "4.5.1"
 SDKGCCVERSION ?= "4.5.1"
 BINUVERSION ?= "2.21"
 GLIBCVERSION ?= "2.10.1"
-LINUXLIBCVERSION ?= "2.6.36"
+LINUXLIBCVERSION ?= "2.6.37.2"
 
 # Temporary preferred version overrides for PPC
 PREFERRED_VERSION_u-boot-mkimage-native_powerpc ?= "2009.08"

meta/conf/distro/poky.conf

@@ -2,8 +2,8 @@
 #@DESCRIPTION: Distribution configuration for the Yocto Project build by Poky
 
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 4.0)"
-DISTRO_VERSION = "0.9+snapshot-${DATE}"
+DISTRO_NAME = "Yocto (Built by Poky 5.0.1)"
+DISTRO_VERSION = "1.0.1"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
@@ -117,6 +117,8 @@ POKY_EXTRA_RDEPENDS = "task-poky-boot"
 POKY_EXTRA_RDEPENDS_qemuarm = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemuarmv6 = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemuarmv7 = "qemu-config"
+POKY_EXTRA_RDEPENDS_qemumips = "qemu-config"
+POKY_EXTRA_RDEPENDS_qemuppc = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemux86 = "qemu-config"
 POKY_EXTRA_RDEPENDS_qemux86-64 = "qemu-config"
 
@@ -130,8 +132,8 @@ EXTRAOPKGCONFIG = "poky-feed-config-opkg"
 # This is a list of packages that are used by poky to build the distribution, they are not
 # directly part of the distribution. 
 HOSTTOOLS_WHITELIST_GPLv3 ?= ""
-WHITELIST_GPLv3 ?= "less gnome-common"
-LGPLv2_WHITELIST_GPLv3 ?= "libassuan gnutls libtasn1 libidn" 
+WHITELIST_GPLv3 ?= "less"
+LGPLv2_WHITELIST_GPLv3 ?= "libassuan gnutls libtasn1 libidn libgcc gcc-runtime" 
 
 # This is a list of packages that require a commercial license to ship
 # product. If shipped as part of an image these packages may have 

meta/conf/machine/include/tune-atom.inc

@@ -2,4 +2,8 @@ BASE_PACKAGE_ARCH = "core2"
 TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse"
 #MOBLIN_CFLAGS = "-Os -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables"
 
-PACKAGE_EXTRA_ARCHS += "x86 i386 i486 i586 core2"
+PACKAGE_EXTRA_ARCHS += "x86 i386 i486 core2"
+
+# Work around a gcc bug for core2 which caused matchbox-panel to segfault
+# and possibly others.
+FULL_OPTIMIZATION_pn-gtk+ = "-fexpensive-optimizations -frename-registers -O2 -ggdb -feliminate-unused-debug-types"