Neil Williams: Validating ARMMP device tree blobs
I ve done various bits with ARMMP and LAVA on this blog already, usually waiting until I ve got all the issues ironed out before writing it up. However, this time I m just going to do a dump of where it s at, how it works and what can be done.
I m aware that LAVA can seem mysterious at first, the package description has improved enormously recently, thanks to exposure in Debian: LAVA is a continuous integration system for deploying operating systems onto physical and virtual hardware for running tests. Tests can be simple boot testing, bootloader testing and system level testing, although extra hardware may be required for some system tests. Results are tracked over time and data can be exported for further analysis.
The LAVA documentation has a glossary of terms like result bundle and all the documentation is also available in the lava-server-doc package.
The goal is to validate the dtbs built for the Debian ARMMP kernel. One of the most accessible ways to get the ARMMP kernel onto a board for testing is tftp using the Debian daily DI builds. Actually using the DI initrd can come later, once I ve got a complete preseed config so that the entire install can be automated. (There are some things to sort out in LAVA too before a full install can be deployed and booted but those are at an early stage.) It s enough at first to download the vmlinuz which is common to all ARMMP deployments, supply the relevant dtb, partner those with a minimal initrd and see if the board boots.
The first change comes when this process is compared to how boards are commonly tested in LAVA with a zImage or uImage and all/most of the modules already built in. Packaged kernels won t necessarily raise a network interface or see the filesystem without modules, so the first step is to extend a minimal initramfs to include the armmp modules.
apt install pax u-boot-toolsThe minimal initramfs I selected is one often used within LAVA:
wget http://images.armcloud.us/lava/common/linaro-image-minimal-initramfs-genericarmv7a.cpio.gz.u-bootIt has a u-boot header added, as most devices using this would be using u-boot and this makes it easier to debug boot failures as the initramfs doesn t need to have the header added, it can simply be downloaded to a local directory and passed to the board as a tftp location. To modify it, the u-boot header needs to be removed. Rather than assuming the size, the u-boot tools can (indirectly) show the size:
$ ls -l linaro-image-minimal-initramfs-genericarmv7a.cpio.gz.u-boot -rw-r--r-- 1 neil neil 5179571 Nov 26 2013 linaro-image-minimal-initramfs-genericarmv7a.cpio.gz.u-boot $ mkimage -l linaro-image-minimal-initramfs-genericarmv7a.cpio.gz.u-boot Image Name: linaro-image-minimal-initramfs-g Created: Tue Nov 26 22:30:49 2013 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5179507 Bytes = 5058.11 kB = 4.94 MB Load Address: 00000000 Entry Point: 00000000Referencing http://www.omappedia.com/wiki/Development_With_Ubuntu, the header size is the file size minus the data size listed by mkimage.
5179571 - 5179507 == 64So, create a second file without the header:
dd if=linaro-image-minimal-initramfs-genericarmv7a.cpio.gz.u-boot of=linaro-image-minimal-initramfs-genericarmv7a.cpio.gz skip=64 bs=1decompress it
gunzip linaro-image-minimal-initramfs-genericarmv7a.cpio.gzNow for the additions
dget http://ftp.uk.debian.org/debian/pool/main/l/linux/linux-image-3.14-1-armmp_3.14.12-1_armhf.deb(Yes, this process will need to be repeated when this package is rebuilt, so I ll want to script this at some point.)
dpkg -x linux-image-3.14-1-armmp_3.14.12-1_armhf.deb kernel-dir cd kernel-dirPulling in the modules we need for most needs, comes thanks to a script written by the Xen folks. The set is basically disk, net, filesystems and LVM.
find lib -type d -o -type f -name modules.\* -o -type f -name \*.ko \( -path \*/kernel/lib/\* -o -path \*/kernel/crypto/\* -o -path \*/kernel/fs/mbcache.ko -o -path \*/kernel/fs/ext\* -o -path \*/kernel/fs/jbd\* -o -path \*/kernel/drivers/net/\* -o -path \*/kernel/drivers/ata/\* -o -path \*/kernel/drivers/scsi/\* -o -path \*/kernel/drivers/md/\* \) pax -x sv4cpio -s '%lib%/lib%' -d -w >../cpio gzip -9f cpiooriginal Xen script (GPL-3+) I found it a bit confusing that
i is used for extract by cpio, but that s how it is. Extract the minimal initramfs to a new directory:
sudo cpio -id < ../linaro-image-minimal-initramfs-genericarmv7a.cpioExtract the new cpio into the same location. (Yes, I could do this the other way around and pipe the output of find into the already extracted location but that's for when I get a script to do this):
sudo cpio --no-absolute-filenames -id < ../ramfs/cpioCPIO Manual Use newc format, the new (SVR4) portable format, which supports file systems having more than 65536 i-nodes. (4294967295 bytes)
(41M)
find . cpio -H newc -o > ../armmp-image.cpio... and add the u-boot header back:
mkimage -A arm -T ramdisk -C none -d armmp-image.cpio.gz debian-armmp-initrd.cpio.gz.u-bootNow what? Now send the combination to LAVA and test it. Results bundle for a local LAVA test job using this technique. (18k) submission JSON - uses
file:// references, so would need modification before being submitted to LAVA elsewhere.
complete log of the test job (72k)
Those familiar with LAVA will spot that I haven't optimised this job, it boots the ARMMP kernel into a minimal initramfs and then expects to find apt and other tools. Actual tests providing useful results would use available tools, add more tools or specify a richer rootfs.
The tests themselves are very quick (the job described above took 3 minutes to run) and don't need to be run particularly often, just once per board type per upload of the ARMMP kernel. LAVA can easily run those jobs in parallel and submission can be automated using authentication tokens and the lava-tool CLI. lava-tool can be installed without lava-server, so can be used in hooks for automated submissions.
Extensions
That's just one DTB and one board. I have a range of boards available locally:
* iMX6Q Wandboard (used for this test)* iMX.53 Quick Start Board (needs updated u-boot)
* Beaglebone Black
* Cubie2
* CubieTruck
* arndale (no dtb?)
* pandaboard Other devices available could involve ARMv7 devices hosted at www.armv7.com and validation.linaro.org - as part of a thank you to the Debian community for providing the OS which is (now) running all of the LAVA infrastructure. That doesn't cover all of the current DTBs (and includes many devices which have no DTBs) so there is plenty of scope for others to get involved. Hopefully, the above will help get people started with a suitable kernel+dtb+initrd and I'd encourage anyone interested to install
lava-server and have a go at running test jobs based on those so that we start to build data about as many of the variants as possible.
(If anyone in DI fancies producing a suitable initrd with modules alongside the DI initrd for armhf builds, or if anyone comes up with a patch for DI to do that, it would help enormously.)
This will at least help Debian answer the question of what the Debian ARMMP package can actually support.
For help on LAVA, do read through the documentation and then come to us at #linaro-lava or the linaro-validation mailing list or file bugs in Debian: reportbug lava-server.
, so you can ask me.
I'm giving one talk on the LAVA software and there will be a BoF on validation and CI in Debian.
I picked up Zoe from Sarah this morning and dropped her at Kindergarten.
Traffic seemed particularly bad this morning, or I'm just out of practice.
I spent the day powering through the last two parts of the registration block
of my real estate licence training. I've got one more piece of assessment to
do, and then it should be done. The rest is all dead-tree written stuff that I
have to mail off to get marked.
Zoe's doing tennis this term as her extra-curricular activity, and it's on a
Tuesday afternoon after Kindergarten at the tennis court next door.
I'm not sure what proportion of the class is continuing on from previous terms,
and so how far behind the eight ball Zoe will be, but she seemed to do okay
today, and she seemed to enjoy it. Megan's in the class too, and that didn't
seem to result in too much cross-distraction.
After that, we came home and just pottered around for a bit and then Zoe
watched some TV until Sarah came to pick her up.


At this moment, some 153 Tamil refugees, fleeing the same type of instability that brought a horrible death to the passengers of MH17,
Recently I was updating
Modern desktop environments like
Reworking Intel Glamor
The original Intel driver Glamor support was based on the notion that
it would be better to have the Intel driver capture any fall backs and
try to make them faster than Glamor could do internally. Now that
Glamor has reasonably complete acceleration, and its fall backs aren t
terrible, this isn t as useful as it once was, and because this uses
Glamor in a weird way, we re making the Glamor code harder to maintain.
Fixing the Intel driver to not use Glamor in this way took a bit of
effort; the UXA support is all tied into the overall operation of the
driver.
Separating out UXA functions
The first task was to just identify which functions were UXA-specific
by adding _uxa to their names. A couple dozen sed runs and now a
bunch of the driver is looking better.
Next, a pile of UXA-specific functions were actually inside the
non-UXA parts of the code. Those got moved out, and a new
intel_uxa.h file was created to hold all of the definitions.
Finally, a few non UXA-specific functions were actually in the uxa
files; those got moved over to the generic code.
Removing the Glamor paths in UXA
Each one of the UXA functions had a little piece of code at the top
like:
because a few
parameters that depend on the GTT size were not initialized until
after that frame buffer was allocated. I haven t analyzed what effect
this has on performance.
Page Flipping and Resize
Page flipping (or just flipping) means switching the entire display
from one frame buffer to another. It s generally the fastest way of
updating the screen as you don t have to copy any bits.
The trick with flipping is that a client hands you a random
pixmap and you need to stuff that into the KMS API. With UXA, that s
pretty easy as all pixmaps are managed through the UXA API which knows
which underlying kernel BO is tied with each pixmap. Using Glamor,
only the underlying GL driver knows the mapping. Fortunately (?), we
have the EGL Image extension, which lets us take a random GL texture
and turn it into a file descriptor for a DMA-BUF kernel object. So, we
have this cute little dance:







I use a laptop with Atheros wifi card with ath9k driver. I use
hostapd to convert my laptop wifi into AP (Access point) so I can
share network with my Nexus 7 and Kindle. This has been working
fine for quite some time till my recent update.
After recent system update (I use Debian Sid), I couldn't for some
reason convert my wifi into AP so my device can connect. I can't find
anything in log nor in hostapd debug messages which is useful to
trouble shoot the issue. Every time I start the laptop my wifi card
will be blocked by RF-KILL and I have manually unblock (both hard and
soft). The script which I use to convert my Wifi into AP is below
Something straight out from the real world: Menu cards in restaurants are
not nice to deal with if you are blind. It is an old problem we grow used
to ignoring over time, but still something that can be quite nagging.
There are a lot of psychological issues involved in this one.
Of course, you can ask for the menu to be read out to you by the staff.
While they usually do their best, you end up missing out on
some things most of the time.
First of all, depending on the current workload in the restaurant,
the staff will usually try to cut some time and not read everything to you.
What they usually do is to try to understand what type of meal you are
interested in, and just read the choices from that category to you.
While this can be considered a service in some situations (human preprocessing),
there are situations were you will definitely miss a highlight on the menu that
you would have liked to choose if you knew that it was there.
And even if the staff decides to read the complete menu to you (which is rare),
you are confronted with the 7-things-in-my-head-at-once problem.
It is usually rather hard to decide amongst a list of more then 7 items,
because our short-term memory is sort of limited. What the sighted
restaurant goers do, is to skip back and forth between the available options,
until they hit a decisive moment. True, that can take a while,
but it is definitely a lot easier if you can perform "random access reads" to
the list of choices yourself. However, if someone presents a substantial number
of choices to you in a row, as sequential speech, you loose the random
access ability. You either remember every choice from the beginning and do your
choosing mentaully (if you do have extraordinary mental abilities), or you end
up asking the staff to read previous items aloud again. This can work, but
usually it doesn't. At some point, you do not want to bother the staff anymore,
and you even start to feel stupid for asking again and again, while this is
something totally normal to every sighted person, just that
"they" do their "random access browsing" on their own, so "they"
have no need to feel bad about how long it takes them to decide, minus the typical
social pressure that arises after a a certain time for everyone, at least
if you are dining in a group.
In very rare cases, you happen to meet staff that is truly "awake", doing
their best to not let you feel that they might be pressed on time, and
really taking as much time as necessary to help you make the perfect decision.
This is rare, but if it happens, it is almost a magical moment.
One of these moments, where there are no "artificial" barriers between
humans doing communcation. Anyway, I am drifting away.
The perfect solution to this problem is to provide random access browsing
of a restaurant menu with the help of digital devices. Trying to make
braille menus available in all restaurants is a goal which is not realistically
reachable. Menus go out of date, and need changing. And getting a physical
braille copy updated and reprinted is considerably more involved as with digital media.
Restaurant owners will also likely not see the benefit to rpvide a braille
card for a very small circle of customers. With a digital online menu,
that is a completely different story.
These days, almost every blind person in at least my social circles
owns an iOS (or similar) device. These devices have speech synthesis and web
browsers.
Of course, some restaurants especially in urban areas do already
have a menu online. I have found them manually with google and
friends sometimes in the past, which has already given me the
ability to actually sit back, and really comfortably choose
amongst the available offerings myself, without having to bother
a human, and without having to feel bad about (ab)using their time.
However, the case where a restaurant really has their menu online is rather rare
still in the area where I am. And, it can be tedious to google
for a restaurant website. Sometimes, the website itself is just
marginally accessible, which makes it even more frustrating to
get a relaxed dinner-experience.
I have discovered a location-based solution for the restaurant-menu problem recently.
Foursquare offers the ability to provide a direct link to the menu in
a restaurant-entry. I figured, since all you need to do is
write a single webpage where the (common) menu items are listed per restaurant,
that I could begin to create restaurant menus for my favourite locations,
on my own. Well, not quite, but almost. I will sometimes need
help from others to get the menu digitized, but that's just a one-time
piece of work I hopefully can outsource :-). Once the actual content
is in my INBUX, I create a nice HTML page listing the menu in a rather
speech-based browser friendly way.
I have begun to do this today, with the menu of a restaurant just about
500 meters away from my apartment.
Every now and then I decide I'll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn't think I was aiming that high. I thought I'd start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the "I have my laptop and I want to remain connected" case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.
Let's start with getting a SIP server up and running. I went with 
A common theme over the last few decades was that we could afford to simply
sit back and let computer (hardware) engineers take care of increases in
computing speed thanks to