The imaging process for pandas works as follows, briefly: - panda boots from uboot partition - uboot configuration tries to PXE boot - if successful, it boots into a linux live image, where some shell scripts write {boot,system,userdata}.img into the appropriate partitions, but not overwriting the uboot partition, and reboot - board boots into whatever image was put on it So, initial deployments of sdcards need to include a small image that only contains a partition table and the uboot partition - no android, no b2g, nothing else. Then we can reimage the remainder using the process above. In bug 800048, I set up the DHCP configuration for PXE booting based on a panda that included a vendor-class string in its DHCP requests: Vendor-Class Option 60, length 24: "U-boot.armv7.omap4_panda" However, on trying to test this with the pandas in chassis 3 (for bug 807341, as imaged in bug 797629), no DHCP options are forthcoming: 11:20:30.515355 0e:60:d5:15:4e:01 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 296: vlan 48, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 278) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 0e:60:d5:15:4e:01 (oui Unknown), length 250, xid 0xd7420000, Flags [Broadcast] Client-Ethernet-Address 0e:60:d5:15:4e:01 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 4: Subnet-Mask, Default-Gateway, Domain-Name-Server, BR I'm not sure what's different between the images on those two pandas. So: We need what IMHO we should call a "uboot image", as described above. And it should resemble that on panda-0021, and not that on panda-0034. Ideally it's well-understood and the steps to build it are in a shell script in hg somewhere, but if it comes to dd'ing it off panda-0021 and calling it good, I guess that's OK. I'm remote and fairly clueless about actually handling mobile hardware (I don't know what adb is, for example), so I'm not the person to do this. Who is?

I installed a pre-built image from Linaro as described in [1]. Simply wipe the unnecessary files afterwards. [1] http://releases.linaro.org/12.05/android/leb-panda/

Where did you install it?

Is there any particular reason for even using the sdcard for anything other than uboot? Why not just NFS boot the pandaboard and have boot, system, and userdata all come from an NFS server?

I strongly suspect that would adversely affect build times, if it's even possible. NFS mounts are filesystem mounts, not partitions. Perhaps you're thinking of iSCSI? Pandas with iSCSI, yikes :) Anyway, let's not scope-creep this bug. We're on a very tight deadline to get these implemented, so I want to stick with the design we've already planned on.

(In reply to Dustin J. Mitchell [:dustin] from comment #2) > Where did you install it? Not sure what you mean. Onto the sdcard as described in the document. When you put the sd into the pandaboard afterwards, it should boot the linaro image.

Oh, so you're speaking generally, rather than to either of the images I'm asking about. Do you know if the resulting image acts like panda-0034 or panda-0021? You should be able to tell by tcpdumping (with -v) on the same network while it boots. If its DHCP requests include a Vendor-Class, it's good (like panda-0021). Otherwise, it's bad (like panda-0034).

From talking to a few other folks, it looks like the official technique for generating this image is https://wiki.mozilla.org/Auto-tools/Projects/Pandaboard_Setup (the "WHAT WE ARE USING" version) It's not clear to me whether that generates an image with a DHCP that includes the Vendor-Class, though. It also generates a much larger image than what we need (since it includes an Android image, and even does a bunch of futzing in that image). Perhaps we should add another sub-section there with everything up to but not including "Put SD card in pandaboard and boot it", and with instructions to dd if=/dev/zero all partitions other than the boot partition. I'm not sure if zeroing the partitions will make the imaging process any faster, but at least it removes ambiguity (an unused Android image that we might later be tempted to ineffectually "update") and will make the images gzip up nicely. This would become a u-boot image that is versioned independently of the Fennec-testing Android images, and that gets revised much less frequently.

That sounds fairly straightforward. As to whether that image will do DHCP correctly or not: I have no idea. I don't know what those particular pandaboards are imaged with.

From some random tcpdumping of pan-032 while joel was working on it, *another* vendor class: 12:30:45.704379 0e:60:ad:5d:4e:01 > Broadcast, ethertype 802.1Q (0x8100), length 384: vlan 48, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 18170, offset 0, flags [none], proto UDP (17), length 366) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 0e:60:ad:5d:4e:01, length 338, xid 0x649e8e3e, secs 10, Flags [none] (0x0000) Client-Ethernet-Address 0e:60:ad:5d:4e:01 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1488 Vendor-Class Option 60, length 51: "dhcpcd-5.2.10:Linux-3.2.0+:armv7l:OMAP4 Panda board" Hostname Option 12, length 24: "android-12f121a010df3518" Parameter-Request Option 55, length 9: Subnet-Mask, Static-Route, Default-Gateway, Domain-Name-Server Domain-Name, BR, Lease-Time, RN RB that hostname option might be useful, though. At any rate, the uboot image will be the first of several DHCP transactions that occur throughout the boot process, and it's the only one for which the vendor-class (or other attributes of the request) is important.

Brian said yesterday he could work on this. If not, Jake can take it on Monday.

In order to make a "pre-seed" sdcard image, we need to agree on a common partition table layout that will work with both android and B2G. Right now the current Android image only uses 2gb of a 16gb sdcard. While this was intentional to reduce the time it took to dd an image, I'm not sure if this is enough space for the current (and future) b2g build artifacts. Plus, when bmm is in place the time to re-image will not be directly proportional to the partition sizes since we won't be doing block to block copying via dd. This is the current android partition table layout: Model: SD SU16G (sd/mmc) Disk /dev/mmcblk0: 15.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos VOLNAME Number Start End Size Type File system Flags BOOT 1 32.3kB 138MB 138MB primary fat16 boot, lba SYSTEM 2 138MB 675MB 537MB primary ext4 CACHE 3 675MB 944MB 268MB primary ext4 4 944MB 2147MB 1204MB extended USERDATA 5 944MB 1481MB 537MB logical ext4 MEDIA 6 1481MB 2147MB 667MB logical ext4 Open questions: 1) Should we expand SYSTEM and USERDATA partitions to account for future b2g build growth? If so, how much do we anticipate? 2) Should we expand MEDIA to the edge or near edge of the sdcard end limit? Is MEDIA going to be used for anything in production? If we do expand the partitions to use all 16gb of the sdcard, I would suggest we keep a 400Mb buffer of free space to account for the inconsistency we have seen in actually state sdcard size. I would also like to take this opportunity to update the Linaro Uboot binaries to the latest tip since there have been patches for improved pxe boot handling. Of course this will need to be tested before deploying so we can revert if need be.

This sounds like a lot of work. I know when we scoped out the work for Android and panda boards for this quarter it did not involve spending an extra week or two redoing the file system and base OS image for Android testing. If this is ateam related work, we need to drop some of our other goals or push this out a quarter. As I am not up to speed on all the BMM stuff, maybe this is taken care of by others.

We need to build the u-boot image one way or another, for reasons described in comment 0. So this isn't "re-doing". It's "doing" (and a bit late already). I suspect that the answers to Jake's questions aren't going to affect the performance of the pandas -- they're mostly future-proofing. So, given a lack of other opinions on the topic, IMHO Jake should just make a moderate expansion of each partition (say, to a total of 8g), leaving some space for future futzing (maybe we'll invent a need for a fourth partition, or want to cache Android images on the card, or .. who knows). As for who does this (hi Gary!), my understanding is that Jake will build this image and do preliminary testing (does it booth the live image, can it do an Android install and a B2G install, etc.)

I suspect the shuffling of partitions would not affect how the current Android builds work. To answer a question from earlier, I don't see a need for the Android OS to use the MEDIA partition. Maybe it does some stuff there by default, but we don't use that.

:jmaher, I am doing the work here and just as Dustin said, we need this one way or another since this is allows BMM will be able to functionally re-purpose pandas between android and b2g. This should have no effect on the current android setup except for now allowing BMM to handle re-imaging. I just need some input on the questions before I continue with build this pre-seed u-boot image.

As directed, I've moved ahead and created a pre-seed u-boot image with the latest linaro u-boot bin and boot.scr. The partition table follows the same layout as what is posted in comment 11 but partition 6 is extended to 8Gb. Directions for burning to sdcard are here: https://mana.mozilla.org/wiki/display/IT/Manual+Panda+SD+Card+Imaging Download the image here: people.mozilla.com/~jwatkins/uboot-preseed.img.bz2

Nice. I'll put this image in the Pandas tomorrow. Van

Awesome! Let's get that image in the puppetagain data as a permanent home. It should probably also have a version number in the filename, and some documentation pointing to it.

I should be able to get Jake's new image into all the Pandas in r201-1 today. I've sent Amy the csv containing the MAC addresses. Will try to get r201-2 and r202-3 inventoried and imaged by Friday EOD.

This image is created, right? Any other work to do here? If it's just dcops stuff, let's make a dcops bug?

This image has been created and documented. dcops have been actively putting this image in the new chassis in order to scrape the mac addresses for inventory.