davidrusling

Giving up is not an option.   I finally found a console armfh image, installed it and got wifi to work with a WPA password protected network.   Then I set about getting to a graphical login.  Guess what?   Installing the XFCE desktop does not cause X to be installed, oh no, that would be way too easy.   After a lot of trial and error (xorg-x11-drv-modesetting is not a good idea on the chromebook, by the way) I got xfce working.   Now trying to get some Gnome variant (mate or cinnamon) working.   This has taken way too long and has meant no development work, only stress and bother.

I've been trying to sort out my build environment; I've been using a USB disk (as in spinning), mounting it by hand as the home directory of a separate development account.  Wouldn't it be better, I thought, to mount the disk when it's there and ignore it otherwise.  Guess what?   You can, /etc/fstab now looks like:

UUID=a7ad21a6-6458-4d33-bc80-c87e189ca798 /home/david ext4 nofail,auto,errors=remount-ro 0 1

Note: you could use the disk name, but using the UID is more portable. 

You can find the packages here - http://mirrors.fedoraproject.org/publiclist/Fedora/18/armhfp/

How to upgrade from F17 to F18 (courtesy of Jon Masters):

1. Install the rpm by downloading both of the noarch packages there.
2. Install them with rpm, or with "yum install fedora-release*.rpm"
3. Then do a "yum install rpm yum" to upgrade those bits.
4. You will see some failures during that process due to the linker path changing and the upgrade not working (we don't really do upgrades per-se on ARM devices at the moment).
5. Shutdown the system with a halt/poweroff/or powerbutton press/hold.
6. Take out the SD Card. Insert into another system and make a symlink from /lib/ld-linux.so.3->/lib/ld-2.16.so (which should happen during a glibc upgrade but actually isn't being created properly right now).
7. Re-insert into system and boot it up.
8. Do a "yum upgrade --skip-broken"

I fixed a couple of other problems with webrtc and it now builds.   Tom invited me to post patches to him so that these fixes can get into the main release.   I look forward to doing that, it's been a while since I donated patches anywhere.  Unfortunately, my 8Gb SD card has filled up and, despite deleting various things, I need to create another one.   Luckily Jon Masters has posted a clean 'how to' install Fedora (complete with lurid warnings) @ https://fedoraproject.org/wiki/Architectures/ARM/Samsung_Chromebook_2012.   

I've been doing a little bit of playing trying to get the Chrome web browser built on F17.   The x86 source rpms can be found at http://fedoraproject.org/wiki/Chromium.   The list of packages is:

chromium-21.0.1180.89-1.fc17.src.rpm          

chromium-ffmpegsumo-21.0.1180.81-1.fc17.src.rpm

jsoncpp-0.6.0-0.1.20120626svn249.fc17.src.rpm  

nacl-binutils-2.20.1-4.gitf412ed5.fc17.src.rpm 

nacl-gcc-4.4.3-5.git3937565.fc17.src.rpm 

nacl-newlib-1.20.0-2.git67e3510.fc17.src.rpm  

v8-3.11.10.20-1.fc17.src.rpm     

webrtc-0.1-0.6.20120613svn2401.fc17.src.rpm 

I downloaded these and started to try and build them.  

• jsoncpp builds as is.
• v8 is missing a load of devel RPMs, and built after they were added.    
• Webrtc caused all sorts of problems, all associated with the use of SSE2.  I exchanged some email with Tom Callaway and his proposal was to fix the problems in the source RPMs rather than try to substitute them.   

Webrtc is causing all sorts of problems, mostly around the use of SSE2.   I tracked down something called webrtc-audio-processing (see http://freedesktop.org/software/pulseaudio/webrtc-audio-processing/) and this builds just fine on ARM.  Investigating, it uses WEBRTC_USE_SSE2, defined in typedefs.h, to use / comment out the SSE2 code on non-X86 platforms.   Looking at the webrtc source RPM, it used a similar define (WEBRTC_ARCH_X86_FAMILY) to do the same thing.    modules/audio-processing/aec was breaking, I fixed this in aec_core.c, aec_core_sse2.c and aec_rdft_sse2.c.

 
Here's the reason why, I now have a decent ARM based system on which to play.  I've installed Fedora and I'm playing. 

http://www.linaro.org/linaro-blog/2012/12/03/how-linaros-technical-steering-committee-works/

http://www.linaro.org/linaro-blog/2012/11/08/why-openness-is-not-optional/

 
I've been through Narita airport several times but, sadly, never stayed in Japan so this trip was a real treat and I thoroughly enjoyed Yokohama and this event.   The web site for this event can be seen here - http://events.linuxfoundation.org/events/linuxcon-japan.   All of the talks were videod and will be on line at some point.   It is the third of these events and drew a good technical crowd, but perhaps that was due more to having Linus Torvalds there than me.   It was also good to be able to offer some support, however small, to Japan following the terrible events of March 11th.

Linus surprised the world by announcing v3.0 and he explained this during his Q&A session as being the right time, it being 20 years of Linux and 2.6 having been around a very long time, essentially since they moved to an always stable development flow.    He also said some kind words about the ARM Linux community and welcomed the group maintained ARM subarchitecture maintainance tree in kernel.org that we are setting up.  The picture above is the first that we've had together since the Digital Alpha days about 19 years ago.   For various reasons, this was after drinking some good Japanese whisky.

One of the ongoing discussions was about how we could support the more traditional embedded Linux world with long term supported kernel versions.    The idea is that we would pick one a year and back port useful bug fixes etc into it.    The situation at the moment appears to be that each company is already doing this, so maybe doing it together would reduce the burden and create a better result.    The tricky bit would be to get the users of such a tree to agree on the version, in particular the distributions.    I think that this is where standards organisations, such as Genivi would fit.    An interesting idea though and one that I will raise in Linaro.

There was also a good technical talk from Ted T'so talking about performance of EXT4 on SMP systems.   Basically, too many locks does not help performance, but it also really shows that in order to understand and tune such systems, you really need instrumentation and good benchmarks.

I’ve just got back from a busy week at the Linaro Developer Summit in Budapest. At the last LDS we decided that we wanted to integrate the activities of the TSC (Technical Steering Committee) into the developer summit, rather than have a parallel event. We were successful, but boy was I busy.

On the technical side, I concentrated on the memory management and kernel upstreaming sessions. Both were about the wider ARM Linux community coming together to solve problems. Memory management is a problem that will take a while to solve, but I think that we have a good direction and, as importantly, a bunch of engineering that we can get going on now. Kernel upstreaming is as much about how we accelerate the rate of ARM kernel consolidation as how the ARM Linux maintainers organise themselves and interact with the rest of the Linux community.

In the run up to LDS, the TSC had been working hard to evolve Linaro’s high level requirements, so at LDS we chose to take a step back and look at how we manage those requirements more efficiently. The problem here is that Linaro has grown very rapidly in this last short year. The first time we were at UDS (and Linaro wasn’t quite born), there were around 50 of us, at the first LDS there were around 100 and this time I believe that there were 200 of us. In other words, we’ve doubled our presence every 6 months. In a similar way, the complexity of the requirements we’re dealing with and the problems that we’re trying to solve is doubling too, so we need to do things differently.

Of course, it wasn’t all work. The evenings were spent socializing with friends old and new and seeing some of Budapest, a lovely old city.

Dave