Your SlideShare is downloading. ×
LCE13: LAVA Workshop II - Adding 3rd Party boards to LAVA
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

LCE13: LAVA Workshop II - Adding 3rd Party boards to LAVA

522
views

Published on

Resource: LCE13 …

Resource: LCE13
Name: LAVA Workshop II - Adding 3rd Party boards to LAVA
Date: 11-07-2013
Speaker:
Video: https://www.youtube.com/watch?v=2650zzSApV8

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
522
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Adding a Third party board to LAVA Senthil Kumaran, Tyler Baker & Fu Wei LCE13 - Dublin, July 2013 LAVA Workshop III
  • 2. ● Board Requirements ● Master image creation ● Trapping Console Output Case Studies ● BeagleBone Black ● ARMv6 ● CubieBoard ● Physical and emulated devices Overview
  • 3. Board Requirements
  • 4. ○ Power cycle ○ Storage device support in bootloader and kernel ○ Persistent serial connection during power cycle ○ Ethernet connection to download stuff ○ Bootloader - u-boot or UEFI support Boards with serial and ethernet
  • 5. ○ Power cycle ○ Force bootloader to fastboot externally ○ Images for LAVA - boot.img: kernel + ramdisk, system.img, userdata.img ○ Storage device support in bootloader and kernel ○ Fastboot support in bootloader ○ ADB support in Kernel ○ Serial console support in bootloader and kernel Boards with Fastboot and ADB
  • 6. Master Image
  • 7. ○ rootfs is the root filesystem tree specific to an OS ○ rootfs provided by Linaro could be used to inject your own kernel ○ Linaro ROOTFS ■ NANO ■ DEVELOPER ■ ALIP ■ UBUNTU DESKTOP ROOTFS
  • 8. ○ hwpack is the list of packages that is required for a particular board ○ linaro-hwpack-install from linaro-image-tools ○ linaro-media-create takes the --hwpack switch ○ linaro-hwpack-create from linaro-image-tools ■ linaro-hwpack-create hwpacks/omap3 1 ○ Latest hwpack configuration file format is in YAML HWPACK
  • 9. ○ linaro-media-create is used to create master image ○ rootfs and hwpack are needed to create a master image ○ plan your partition layout in the memory device ○ Example linaro-media-create --rootfs ext3 --mmc /dev/mmcblk0 --dev mx51evk --hwpack hwpack_linaro-imx51_20110407-0_armel_unsupported.tar.gz --binary linaro-natty- nano-tar-20110412-0.tar.gz ○ http://images.validation.linaro.org/ Creating master image
  • 10. Trapping Console Output
  • 11. ○ interrupt_boot_command ■ 'r' ○ interrupt_boot_prompt ■ Hit any key to stop autoboot: ○ bootloader_prompt ■ U-Boot# ○ image_boot_msg ■ Uncompressing Linux... ○ master_str ■ root@master Console Output
  • 12. U-Boot 2013.04-rc1-14237-g90639fe-dirty (Apr 13 2013 - 13:57:11) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: <ethaddr> not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: - interrupt_boot_prompt r - interrupt_boot_command U-Boot# - bootloader_prompt Console Output
  • 13. Uncompressing Linux... done, booting the kernel. - image_boot_msg [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.8.13.0-1-linaro-am335x (buildd@dryad) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #1ubuntu1~ci+130523073008-Ubuntu SMP Thu May 23 09:24:35 UTC 201 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] AM335X ES1.0 (neon ) [ 0.000000] PERCPU: Embedded 8 pages/cpu @c0ae5000 s9408 r8192 d15168 u32768 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [ 0.000000] Kernel command line: console=ttyO0,115200n8 root=LABEL=testrootfs rootwait ro ... Last login: Tue Jun 25 08:19:38 UTC 2013 on tty1 Welcome to Linaro 13.03 (GNU/Linux 3.8.13.0-1-linaro-am335x armv7l) * Documentation: https://wiki.linaro.org/ root@master: - master_str Console Output
  • 14. ● Why is this not a robust string to expect? ○ image_boot_msg ■ Uncompressing Linux... ● What would be a better string? ● Hopefully now you can see why trapping console output is critical to understand when adding third party boards to LAVA. Console Output
  • 15. Add a Board to LAVA BeagleBone Black
  • 16. ○ eMMC + SD card ■ SYSBOOT pins strapped to boot from eMMC first and SD card second. ■ U-Boot present on the eMMC defaulted to using eMMC partitions for booting. ○ Booting to into the Master Image ■ LAVA assumes that when the board is powered on, it requires no intervention to boot master image. ○ No HWPACK existed for the AM335x BeagleBone Black Challenges
  • 17. ○ U-Boot ■ Hijack the bootloader using uEnv.txt ● uEnv.txt will be read from the SD partition ● This is used to setup booting off the SD card instead of eMMC. ● This allowed a clean boot into the Master Image present on the SD card without replacing the original bootloader in the eMMC. ○ Master Image ■ B&B team provided a HWPACK for the AM335x ■ Beaglebone target added to Master Image scripts. BeagleBone Black Solutions
  • 18. Add a Board to LAVA ARMv6
  • 19. ○ ARMv6 is unsupported ○ All packages must be recompiled for ARMv6 support ○ All major distributions support armhf rather than armel ○ ARMv6 is bound to armel which is unsupported ○ Depend on third parties for packages or compile each package for a distribution ○ Raspberry Pi is an example for this Challenges
  • 20. Add a Board to LAVA
  • 21. ○ Luckily, Compare with Beaglebone, we have not the problem to boot the master image ■ Cubie boot from SD card first and NAND second. ■ Boot procedure defaulted to be controlled by uEn v.txt ○ No Standard HWPACK existed for the Allwinner A10 CubieBoard Challenges
  • 22. ○ Master Image ■ lava-create-master make a master image in two steps: ● Preparing vanilla Linaro image ● Converting vanilla image to LAVA master image ■ linux-sunxi.org provided a nonstandard HWPACK and scripts for making a bootable image, so we can make a vanilla image. ■ create a new config file "cubie.conf" ■ using pre-build vanilla image to make a master image by lava-create-master CubieBoard Solutions
  • 23. ○ make a cubie.conf file including the info below: ■ image_boot_msg = Starting kernel ● Cubie kernel has no "Uncompressing Linux" output ■ bootloader_prompt = # ● We also can deploy a CubieBoard 2 (Dual- core A7) into LAVA by the same way. Cubie lava-dispatcher config file
  • 24. General Considerations Physical and Emulated devices
  • 25. ○ Needs a master image ○ Serial connection and network is mandatory ○ Adhere to board requirements as mentioned earlier ○ lp:lava-dispatcher ■ lava_dispatcher/device/master.py ■ lava_dispatcher/device/target.py ■ lava_dispatcher/device/boot_options.py ■ lava_dispatcher/client/targetdevice.py Physical devices
  • 26. ○ Does not need a master image ○ Command to create an emulated device ○ Device configs should be populated properly in lava- dispatcher ○ lp:lava-dispatcher ■ lava_dispatcher/device/target.py ■ lava_dispatcher/device/boot_options.py ■ lava_dispatcher/client/targetdevice.py ■ lava_dispatcher/default-config/lava-dispatcher/device-defaults. conf ■ lava_dispatcher/default-config/lava-dispatcher/device-types Emulated devices
  • 27. Open Discussion