Archive

This week I’m proudly participating at the Ubuntu Developer Summit to help planning and defining what will the Quantal Quetzal (12.10) release be in the next following months.

As usual I’m wearing not only the Linaro hat, but also my Ubuntu and Canonical ones, interested and participating actively at most topics that are related with ARM in general.

And what can I say after the first 3 days at UDS-Q? Well, busy as never before and with great opportunities to help getting Ubuntu to rock even more at ARM, with current devices/platforms and with the exciting new ones that will be coming in the next few months.

Great start as usual by Mark, showing the great opportunities for both Canonical and Ubuntu, describing the new target and use cases, and also showing how important Cloud is now for Ubuntu. After that we had, finally, the announcement of a real hardware availability from Calxeda, proving that ARM server are indeed real! (which is a quite important accomplishment)

This was the first time that all the schedule displays available at UDS were all covered by the ARM boards provided by Linaro. This time we got Pandaboard, Origen and also Snowball constantly showing the schedule through all the day. Low power and powerful devices all around :-)

Discussion to cover all the possible embedded related use cases for Ubuntu, and trying to understand the real requirements for a minimum filesystem (rootfs) for those devices. While we didn’t decide to generate the smallest-still-apt/dpkg-compatible rootfs for our users (as ubuntu-core is already covering most of the cases), we’ll provide enough tools and documentation on how to easily generate them. At Linaro side the Ubuntu Nano image should probably reflect such suggestions.

Here the focus was basically to review and understand if we would really continue providing pre-installed based images instead of just supporting live based ones. Having the images provided only at the SD cards are very useful to make the bootstrap and install quite easy, but it hurts badly the performance. As we’re now getting ARM boards that are very powerful in many ways, the I/O bound shouldn’t limit what the users would be able to get from them. The decision for Quantal is to drop support for the pre-installed images, and provide live based ones at the SD cards (think like the live-sd image as we have with CD on other archs), where the user would install Ubuntu the same way as done with x86, and using USB/Sata based devices as rootfs by default.

The focus of this session was basically to better understand what might be the missing pieces for a proper OpenStack support at ARM. Quite a few open questions still, but the missing pkgs enablement, LXC testing and support and KVM for a few platforms will help making sure the support is at least correctly in place. After initial support, continuous test and validation should happen to make sure the ARM platforms keeps well supported over the time (which will be better stressed and tested once MAAS/Juju is also supported properly at ARM).

Clearly the most important session of the day for ARM. Great discussion on how to prepare and start the ARMv8 port at Ubuntu and Debian, by starting with cross-build support with multiarch and later support with Fast Models and Qemu. A lot is still to be covered once ARM is able to publish the ARMv8 support for Toolchain and Kernel, and session will be reviewed again at Linaro Connect at the end of this month.

Usual review of the patches the Ubuntu Kernel team is maintaining at the Ubuntu Kernel tree. At Linaro this is important as we also enable the Ubuntu specific patch-set at the packages provided by the LEB, for proper kernel and user-space support. Luckily this time it seems the delta is really minimum, which should probably also start to be part of Linux Linaro in the following month.

Usual discussion about trying to avoid replicated work that is strictly related with each ARM board we support at both Ubuntu and Linaro. Decision is to finally sync with the latest flash-kernel available at Debian and try to get the common project/package with the hardware specific bits in place, so it can be used by linaro-image-tools, flash-kernel and debian-cd.

Session to review and plan what are the next steps for the MAAS project, which is also missing proper ARM support for now. Great discussions on understanding all the requirements, as they will not necessarily match entirely with the usual ARM devices we have at the moment. Here the goal for ARM is to continue improving the PXE support at U-Boot (even with UEFI chainload later), and understanding what might be missing to also have IPMI support (even if not entirely provided by the hardware).

Great session covering what might be the improvements and development on the graphics side for next release. Goal is to use a system compositor that would be started right at the beginning at the boot, which will then be controlled and used properly once lightdm is up (with X11). This will improve a lot the user experience on normal x86 based desktops, and luckily on ARM we’re also in a quite nice situation with the work done by Linaro helping getting the proper DRM/KMS support for the boards we support, so I hope ARM will be in a great shape here :-)

At this session we could cover what seems to be the most recurrent and problematically thing at supporting ARM servers, which is the lack of a single and supported boot method and boot loader. UEFI should be able to help on this front soon, but until then the focus will be to keep checking and making sure the current PXE implementation at u-boot works as expected (chainloading UEFI on u-boot is also another possibility Linaro is investigating). There is also the request for IPMI support, which is still unclear in general how it’ll be done generically speaking.

As Ubuntu is also moving to the direction of continuous validating and testing all important components available, there’s the need for a proper validation of the bootloader, and the effect at the user experience while booting the system. For ARM it’s also a special case, as U-Boot is still the main bootloader used across the boards. Test case descriptions in place, and discussion will probably continue at Linaro Connect as this is also an area where we also want to help validating/testing.

Here the Ubuntu Server Team presented how they are benchmarking and checking performance at the server level at x86, and covering what might still be needed to run and validate the ARM boards the same way. For ARM the plan is to run the same test cases on the available scenarios, and also try to get Linaro involved by making sure this is also part of the continuous validation and testing done with LAVA. Another important topic that will probably be extended at Linaro Connect is finding a way to get the power consumption data when running the test cases/benchmarks, so it can be further optimised later on.

Last session of the day, trying to find the missing gaps to finally get the OpenGL ES2.0 support merged at the Compiz and Unity upstream branches used by the entire Ubuntu desktop (across all archs). Following work and actions will basically be to fix the remaining and important plugins after merging the changes, and also getting a few test cases to properly validate the support at Ubuntu. Once all done, it should be merged ASAP.

These are just a few topics which I was able to participate. There are a lot of more exciting work coming on, which can all be found at http://summit.ubuntu.com/uds-q/. Remember that you’re still able to participate in a few of them tomorrow and friday, as remote access is provided for all the sessions we have.

I’m sure a lot of more exciting stuff will be discussed for ARM support until the end of this week, and at Linaro Connect, at the end of the month, we’ll be able to review and get our hands dirty as well :-)

For those following the development of the next Ubuntu release (12.04 – Precise Pangolin), you all know that we’re quite close to the release date already, and to make sure Precise rocks since day 0, we all need to work hard to get most of the bugs sorted out during the next few weeks.

At Linaro, the Linaro Developer Platform team will be organizing an ARM porting Jam this Friday, with the goal of getting all developers interested in fixing and working on bugs and portability issues related with the Ubuntu ARM port (mostly issues with ARMHF at the moment).

The idea of having the Porting Jam at Friday is to have it as a joint effort with Ubuntu’s Fix Friday and Ubuntu Global Jam, so expect quite a few other developers helping improving Ubuntu as well!

Remember that for ARM this release will be a quite huge milestone, as it’ll be the first LTS release supporting ARM, besides delivering support for ARM servers and ARMHF as default, so let’s make sure it rocks!

As at Linaro we usually work with many PPAs over the releases, there was a need to generate a proper changelog for a PPA, in a way we could know what packages got changed before doing the release.

At first I thought I could just parse the repository metadata (as a PPA is nothing more than a debian repository), but then I realized I could just use the awesome (yes, *awesome*) launchpadlib, if it had a way to get the data I needed.

So I called the launchpadlib master I know (Ursinha), and in 15 minutes we saw that we could use it to parse the “.changes” file, and from there get the data I needed. As Launchpad stores the PPA packages publishing history, it’s quite easy to get all the changes over period of time.

A few minutes later (after also noticing that there’s a python-debian module to parse the changes file), I created the first version of the generate-ppa-changelog.py script, that does exactly what I needed, and with just a few python lines :-)

optional arguments:
-h, –help show this help message and exit
-d YYYYMMDD, –date YYYYMMDD
start date to probe for changes
-s SERIES, –series SERIES
ubuntu series to look for changes (default: natty)
-t TEAM, –team TEAM launchpad team that owns the PPA
-p PPA, –ppa PPA ppa name to probe the changelog (default: first PPA)
–version show program’s version number and exit

If no argument is given, it will probe all the changes for the default series.

It’s been a while since I don’t post anything, and the main reason is that I just got a new job and I’ve being pretty busy with it :-)

After working at INdT for more than 2 years, I decided that it was time to move on, get back to Campinas, get closer with friends and family and start looking for a new job.

I had a quite good time at Recife, working with Mamona, Maemo and MeeGo, mostly helping bring up different ARM platforms to be used by the Institute in many different projects. The work was nice, but Recife can be hard to get through over the time. I’ll for sure miss the nice work place we’ve built, and the nice people I worked with.

About the new job, I’m quite happy to announce that I’m now working as a Software Engineer at Canonical. My main objective now is to help bringing Ubuntu into different ARM platforms, like beagleboard and the new pandaboard.

Canonical is awesome, and the people from the Ubuntu Platform Team is even greater. Had the opportunity to meet most of the people at the last Ubuntu Platform Sprint that was held at Prague, and it was awesome to see so many skilled and fun guys working together to improve Ubuntu.

That’s it, now it’s time to get back to work because we have a huge pile of cool and fun things to work on :-) If you’re interested in understading, helping and participating on what we’re currently doing, get at #ubuntu-arm, freenode, and ping me (rsalveti)!

Now, about the things that interest me the most, the current status in Linux in general:

Kernel:
The kernel we’ve been working on is a vendor’s based one, using 2.6.29 as base. With this kernel we have many features implemented, like blitter support, framebuffer, hdmi output and many more.

At upstream side, the code is just starting to be merged, and you can see already some basic commits going on linux-2.6, like commits 1, 2, 3, 4 and 5. STE seems to be doing a great job on getting the changes upstream, since it’s the only feasible way to make it supported in mid, long term in linux. So expect more changes at 2.6.34 and 2.6.35.

U-Boot:
Similar with the kernel, we’re also using a custom vendor’s version. They’re just starting to make the support upstream, and you can find the patch series here.

Once we get the basic U-Boot and Linux support upstream, we can start working directly with mainline, fixing and improving it when needed.

Connectors - HDMI, uSD, Headset and micro USB.

Our work:
Since we got the board we’ve been playing on supporting many different Linux platforms, and optimizing the basic Linux OS core to be commonly used by different distros.

We started with Maemo 5, as a proof of concept, and we got it up and running with a very good performance and hopefully soon we’ll be able to share more details.

OE Angstrom/Mamona is very easy to support, since we just need to create the machine configuration and use the same compilers already used by other ARMv7 architectures.

Personally I started testing Ubuntu Lucid release, and just got the very basic support, with a custom and simple image. Ubuntu is now a very good option since it’s targeting ARMv7 platforms, with compiler optimizations and Thumb2 support. NEON support is not included by default, but you can support it by compiling specific components by hand. For more information please check at ubuntu wikipage.

Meego also boots and runs fine at this platform, but since it’s just a basic OS ATM (armv5 only), doesn’t have anything interesting to play with.

Besides platform support, we’ve been working on creating the hardware accelerated X server video driver, to use EXA, DRI2 and Xvideo with overlay. Once we get it all running we can easily use it in any Linux distro we want, and X we’ll be accelerated by default.

Connectors - RJ45, Uart and MIPI34, for debug.

Now the important question, where’s the code?
STE still didn’t deliver the main software in public, so we can’t just release the Kernel, U-Boot and other development that requires support from these software components. But this is changing, and I believe that very soon we’ll be able to get most of the things in public, so others can download and test if needed.

In the next posts I’ll be showing more about the status of these distros on this hardware, also showing the performance and demonstrating it.

After some people’s requests, it’s nice to hear that the BOSSA committee decided to extend the call for presentation to January 17, 2010.

This is the first year that the conference is doing a call for presentation, so if you are working with free and open source technologies related to mobile embedded platforms, please submit an abstract of your presentation at http://www.bossaconference.indt.org/.

The conference will be held in Manaus, Amazonas – Brazil, a different city from the other years. As always, it’ll be an awesome conference, having lots of interesting talks and people, and also the opportunity to hack and discuss new ideas :-)

If you have something with Qt, WebKit, Android, OpenEmbedded, Linux Kernel, Maemo, etc, please, go there and try it out, I guarantee that if accepted, you won’t regret!

So, as I told at the previous post, I went to FISL 10 last week, also with the opportunity to give a presentation about OpenEmbedded and Mamona.

The conference was quite good this year, not because the level of the technical presentations, but because a lot of important people from many communities went there also. The talks after the presentations, and also at the bar, were the most productive part of the event :-)

My presentation was actually quite cool, with many people interested in OpenEmbedded and also how to hack those Nokia Tablet Devices.

For those who can read portuguese, follow this link to get the presentation.