Canonical Voices

Posts tagged with 'arm'

Marcin Juszkiewicz

When I bought Samsung ARM Chromebook few months ago I had no idea about UCM profiles and burnt speakers (left is dead, right is resting)…

This was good lesson. I learnt more about how UseCase Manager works, took profiles from ChromeOS and added them into Ubuntu so other users will be a bit more safe (due to lack of testers it took months to merge it into “precise” and “quantal” releases).

During last months I had discussions with some Debian, Ubuntu, Fedora developers about how to solve such problems and how to keep UCM profiles shared between distributions.

In meantime Liam Girdwood pointed me to (not used) UCM git tree at ALSA Project server. So finally I spent some time and sent Ubuntu ones for merging.

I also got newer profiles for OMAP4 devices and some updates for Chromebook ones.

The idea is to collect UCM profiles, keep them in one place and share in each distribution packages. So if your hardware has profiles created then join us to make users life easier.


All rights reserved © Marcin Juszkiewicz
Call for ALSA UCM profiles was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Linus Torvalds released Linux 3.9 and many websites published summaries what’s new in it. One of common entries is support for ChromeOS laptops. But what that means for Samsung ARM Chromebook users?

Let’s start with Kernel Newbies summary which lists 5 commits:

None of them are for ARM Chromebook. But that does not mean that nothing was done for it. Touchpad driver was merged, many Exynos platform changes were made but yeah — still lot to do.

But that’s a curse of ARM platforms…

UPDATE: Arnd Bermann wrote a comment on my Google+ post that Olof Johansson has “linux-next” bootable on ARM Chromebook. YAY!

UPDATE: I got ChromeOS 3.8 kernel running on my Chromebook. Needs some testing and then will land in “saucy” as default one probably.


All rights reserved © Marcin Juszkiewicz
Linux 3.9 and Chromebook support was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

As guys from/around Texas Instruments promised there is new Beaglebone Black on a market. Faster, cheaper, with video output and other extras. For me it looks like Raspberry/Pi killer done right.

What is on board?

There is a lot of goods:

  • 1GHz TI AM355x cpu with ARM Cortex-A8 core supporting ARMv7-a instruction set
  • PowerVR GPU with OpenGL ES support (closed source driver)
  • HDMI output (with audio)
  • 512MB ram
  • 2GB eMMC
  • 92 expansion pins
  • USB Host
  • USB device
  • Ethernet
  • microSD slot
  • user controlled LEDs
  • serial port header

And it still supports (most of) expansion boards from the original Beaglebone which can add extra functionality so possibilities are uncountable. All that for only 45$.

But why it is better?

  1. ARMv7-a cpu core. It means that you can run any Linux distribution on it. Think Ubuntu/armhf, Debian/armhf, Fedora/armhf. No need to reinvent a wheel (aka armhfv6 done for Raspbian distribution).

  2. No dependencies on closed source components. You can boot board and use it with what ever you want and still have control on all sources used. Sure, there are some binary blobs for OpenGL ES but if you do not need this then you are fine. Try to boot R/Pi without binary blobs…

  3. Texas Instruments level of support. Sure, we heard that they abandoned mobile market but Sitara line of processors is still in development, there are new CPUs and they provide documentation and source code for product. Also amount of work done in mainline kernel is not something to be ignored.

  4. Expansion headers. Compare 26 pins of R/Pi with 92 of Beaglebone… Then add capes to this.

So which one to choose?

Beaglebone Black of course ;D

As people on IRC told there are other cheap devices made in China with faster cpus and more memory. But for me Beaglebone is not ‘yet another ARM computer’ but rather ‘yet another microcontroller on ultra steroids’ and this is where the true power of this board resides.


All rights reserved © Marcin Juszkiewicz
Death to Raspberry/Pi — Beaglebone Black is on a market was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

I think that most asked question about Chromebook in last months was about hardware acceleration. So let’s write something about it.

OpenGL ES

There is a driver for OpenGL ES for Samsung Exynos5 Dual cpu present in Chromebook. But there are two versions of it: Week35 and Week45. Both require different kernel versions.

Ubuntu 13.04 has 3.4.0-5 kernel package which was built from R23 kernel branch. Week35 OpenGL ES driver works with it and you have to grab it from ChromeOS (but maybe it got updated there already).

I still have to find time and get R25 (or R26 or R27) kernel working so we could upgrade to Week45 driver. This one is available in ChromeOS as well (beta or dev).

Where are my packages?

There were packages which provided OpenGL ES driver binaries (week45). I removed them due to license issues as it looks like Samsung bought Mali T604 license from ARM Ltd. and got it working with Exynos5 Dual. Then they sub licensed it to Google for use with ChromeOS.

So Samsung does not distribute the driver — Google does. And even when they give tarball with files there is no license in it — just standard “Google Terms of Service” note.

No redistribution license == no packages. Sure, someone can make “chromebook-opengles-driver-installer” like package which would grab binaries from ChromeOS (I did such for week35) or will fetch them from network. Feel free to do it — you can use my chromebook-mali-driver repository as a base. Once you will get it working I can put it into Samsung Chromebook PPA.

Multimedia decoding

Other thing is hardware accelerated multimedia decoding (maybe also encoding). Under ChromeOS it was done with OpenMAX stuff. Google even had some binaries available but they crashed badly under Ubuntu.

How situation looks today? No idea as I did not had time for Chromebook stuff in last months.


All rights reserved © Marcin Juszkiewicz
Hardware acceleration on Chromebook was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

This year I spent Easter in other way than in past years. Instead of staying with the family I went for demoscene party — Revision 2013 in Saarbrücken.

Please note (RSS readers mostly) that this post will contain many YouTube videos embedded. Please go to my blog to have them properly displayed (I use WordPress + Jetpack plugin to embed them).

Friday

Took us 12 hours to get there (mostly due to waiting on TXL and FRA airports) but we managed to be at party place around 19:00 on Friday. Registered, met friends and went to Kirchberg Hotel to drop bags.

Hotel has two stars but was perfectly fine for such trip as our. Clean bed, good breakfast, quiet place (except church bells at 10:00 on Sunday). All just ~2km from E-Werk where Revision took place.

Back to party, more people to meet, discuss a bit with guys from ARM Ltd about Samsung Chromebook, Cortex-A15, Mali etc. One guy joined with his Chromebook and recognized me when I asked “may I fry your speakers?” :D

Timetable listed one interesting thing: “Curio’s 2012 Essentials” which was ~1 hour long set of PC demos from previous year. It was nice as I was totally out of PC scene so was able to check how it looks.

Taxi to hotel was just 6€ ;D

Saturday

Attended “How to start writing compilers without a Ph.D” seminar as it sounded interesting to me. And it was ;) Video below:

Also had discussion with ARM guys about presenting not only technical demos (like Unreal Engine one) but also to show some demoscene productions. Soon “Beginnings” by Elude started on one of Nexus 10 tablets and was working nice. But coder who wrote it was not so happy about that when we discussed that later… I think that it would be a good thing for ARM Mali team to get some good demoscene groups to write demos for Android platform to amaze people with nice looking productions. ARM even had seminar for OpenGLES 3.0 API:

But Saturday was also full of competitions. Tracked music, oldskool music (read: 8-bit mostly), photo, animation/video, game, ascii/ansi, Amiga intros, PC 4K intros, Oldskool demos (8-bit, Atari STE, Amiga 500)…

There were many entries in compos where productions from long time no see groups/people were presented. For example in oldskool demo we got “RINK A DINK REDUX” from Lemon which was astonishing:

There were also demos for Amstrad CPC, MSX1, ZX Spectrum, Commodore 64 and other platforms. Oldskool music compo had even NES entry ;)

But it was also visible that demoscene is not full of amateurs like it was years ago. Some of videos in animation/video compo had professional level. “Lübeck 24x7x365″ took 50 days of recording but was really nice:

There was a concert in the evening… Ear plugs were not strong enough for me so I spent most of time outside talking with people. Next time need to take some better hearing protectors…

Sunday

As Saturday ended really late for us and competitions were planned for 13:00 we decided to not rush and stay in bed longer :) But at around 10:00 bells in local church started their music compo so we were not able to sleep anymore.

We got music, graphics, wild and of course PC 64K intro, web browser demo/intro, Amiga demo and PC demo competitions that day.

Graphics one was won by “Double Trouble by the Royal Forces” made by forcer & prince. Huge amount of details which was not so visible on big screen as it was on a tunnel’s wall where it was hanging as few square meters photo copy.

Wild compo… Man, that was something great. From productions made for Arduino (with some shields) though ARM Cortex-M3 one to interesting hack by Dexter/Abyss which shown one view on monochrome TV and second on oscilloscope while both were connected to Composite video signal only… See it for yourself (or grab separate entries from scene.org FTP server):

Then DJ set by h0ffman (skipped by me) and clue of party — Amiga and PC demos/intros. Different quality but most of them was really good — both from technical or design view (but not always from both at same time).

But as I am not a coder I looked mostly at design and audio/video part. All those names like ‘ray matching’ etc meant nothing to me so when someone tried to explain why demo which I did not like was so great I just told similar thing ;D

Monday

Wake up, breakfast, pack, pay, go to party place. We did not manage to get there before voting ended so not voted for PC demo compo entries. Greeted those who was still present, discussed a bit and then return trip… This time just ~9 hours but next time (if there will be such) we plan to go there by car. Less time needed.

Random stuff

I liked how party was organized — it was my first such event abroad and many people told me that Revision is the last demoscene party in old style. I really liked it. Saw many different platforms like MSX1, MSX2, C= VIC20, Amstrad CPC or Videoton…

Due to Easter time shops where closed on Sunday/Monday but it was not a problem for me as there was free coffee/tea, beer/water/orange juice was available to buy at low price (2.5€ for 0.5l beer) and there was hot food served all time (like 10:00 – midnight) also not so expensive.

Weather could be better as it was cold but at least there was no snow (which we still have here).

It was also nice to see Kiero at work as he was finishing “Machinist” Amiga demo on his x86-64 laptop with WinUAE running fullscreen. I was surprised that ASUS UL30A is capable to run it fast enough.

Amount of discussions with people is probably uncountable. Chromebook, ARM, Android, Amiga, scene were just subset of topics…

Will I go there next year? Will see…


All rights reserved © Marcin Juszkiewicz
Revision 2013 was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Second day in a row I managed to get 8 hours of sleep like I was not able at Linaro Connect Asia 2013. There was no time for sleeping as so many things had happened.

This time I decided to go to Hong Kong on Friday to have whole Sunday for shopping or sight seeing etc. Also to make things different I went though Helsinki (was Istanbul in 2012). It was interesting experience to hear English language with Finnish accent. There were moments when during in-flight announcements I was not able to recognize when they ended Finnish part and started English one ;D

HEL was cold but only outside so once I got to terminal it was fine. Rushed though, passed biometric passport gate and got a seat with electricity to charge my Chromebook and phone. Flight was “fine” as usual but as it was during night I tried to catch some sleep.

Finnair’s crew had some problems getting in-flight entertainment system working so we could watch how Linux booted on those NSC Geode GX2 based devices. Due to copyright note in bootloader (redboot) I assumed that it is not older than 9 years. Very slow boot anyway with lot of text printed. They should show some splash + potential progress bar instead. But finally it started working. Provided in-ear headphones are much better than ones on Lufthansa flights.

Landed, got prepaid sim from “3″ network, met Andrea Gallo and we went to hotel. I had plans to go to the city center but was too tired for it. I also lacked HKD due to other layout of keypad in ATM :D

ATM keypad in Hong Kong

On Sunday we grouped and went to Shim Shui Po to do some electronics related shopping. Prices in Hong Kong are similar/worse than in Europe so I bought only few things which I had problems finding in low price at home: mini-ITX case (16€), Nexus 4 back cover (6.5€), case for Samsung Chromebook (7.5€) and some cables. There are still no USB 3.0 cables in wide selection ;( I also bought crappy dual sim phone for 10€ as I needed one to get my Polish sim on network.

I also did some shopping on Tuesday — this time on Ladies’ Market. It is one long street with lot of sellers with clothes, wallets, toys, phone covers, headphones and other gift like things of unknown quality. I left there all money I had but got gifts for everyone I wanted. Haggling there is a must as 40% of starting price is easy to get. And you do not even need to tell anything to get price lowered…

We also went to Shenzen, China for one afternoon but that’s story for separate post.

But I went there for connecting with people. And to discuss/present our work done in last cycle and to be done in next ones.

Each day started with keynote (Friday one had Linaro awards). And we got speakers from outside of Linaro:

  • Jon Corbet (LWN)
  • Lars Kurth (Citrix)
  • Jason Taylor (Facebook)
  • Greg Kroah-Hartman

Each talk was interesting. Jon shown Linaro developers that Big.Little switcher should be taken for community review earlier, Lars presented Xen on ARM (v7, v8), Jason told about how Facebook handles servers and where is a space for ARM ones. Greg’s talk was best — he told why he does not want our code, what kind of mistakes people do in sent patches and gave us story how one code submission can break whole set of devices due to lack of testing. I wonder how Linaro Kernel WG will handle Greg’s new requirement of having all Linaro patches signed by senior kernel developer.

This was also first conference where I was fully ARMed. I left my x86 laptop at home and took Samsung Chromebook instead. Ubuntu runs fine on it, speed is comparable but size (13.3″ contra 11.6″) and weight differ. This also gave me few more occasions to talk with other developers.

I spoke with Citrix guys about Chromebook kernel changes and their Xen backport will probably be merged into “linux-chromebook 3.4″ package. Also had some discussions with ARM Mali developers which resulted in removal of OpenGLES packages from Chromebook support PPA due to licence issues (I do not have redistribution permission).

We also had meeting about hacking Samsung Chromebook where ChromeOS, Debian, Linaro, OpenSUSE, Ubuntu developers had discussion about what we can expect, where we are, how to get some things fixed etc. After that Nicolas ‘Charbax’ Charbonnier from armdevices.net shot video about it:

Direct link to video

I remember that Charbax tried to make interview with me at one of earlier Linaro Connects but I always rejected that idea. This time he went for help… And I could not refuse to Zack Pfeffer :) How it went? You tell me:

Direct link to video

Hong Kong was great. Weather was perfect with +25°C, sun and no rain. Someone told me March is the last moment for being there :)

At a beach near hotel in Hong Kong

But then I had to leave. Problem with return flights is that they usually are around midnight. Add lack of sleep during previous nights and result is not nice mix. So we spent some time in airport lounge to charge batteries (our and devices) and then squeezed in economy class for 11 hours. Took a nap, watched movie in English with Finnish subtitles (learnt new word even) and read “Amiga, the future was here” book.

Imagine weather change when we landed in Helsinki… -13°C and snow. As I left my spring jacket in checked-in baggage (but I had sweater) those few minutes from airport -> bus -> plane were cold ones. Similar few hours later in Berlin. But I had some time for shopping. Skipped salmiakki cause it is hard to know which ones will be hardcore just enough but got some other things.

Helsinki with snow

Szczecin was nice on Saturday. Cold, but spring was visible. Winter came during night:

Szczecin next day

Next Linaro Connect will be in Dublin, Ireland. See you there!


All rights reserved © Marcin Juszkiewicz
Linaro Connect Asia 2013 was fun was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Today I got email that ‘xf86-video-armsoc’ landed in Ubuntu 13.04 ‘raring’. I also sent ‘linux-chromebook’ into archive.

Next step would be ‘vboot-utils’ which are now in NEW queue in Debian. Once it lands I will sync it into Ubuntu so we can sign kernels. What else needs to go into archive? Maybe OpenGLES driver. I have 0.45 packaged but need to fix showing the license.

What with support of older Ubuntu releases? I do not care about them and have a feeling that those who run them on their Chromebooks does not care as well (no one checked UCM profiles which were for verification).

So if you want to have good working Ubuntu on your Samsung ARM Chromebook then update to 13.04 or take care of backporting updates or ‘talk to the hand’.


All rights reserved © Marcin Juszkiewicz
Chromebook support lands in 13.04 was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

This year no one blocked me from going to FOSDEM ;D

What are plans? There will be some AArch64 related talks which I want to attend:

  • Bootstrapping Fedora for AArch64
  • Bootstrapping Debian/Ubuntu for AArch64
  • Porting software for AArch64
  • Porting OpenJDK for AArch64
  • What the hell is AArch64

Few ARM ones:

  • Freedreno update
  • Open ARM GPU drivers
  • ARM status in Linux kernel

Few for entertainment:

  • Buildroot contra Debian
  • Baserock introduction
  • Eudev

Some for curiosity:

  • HipHop
  • Why there is no such thing as FOSS phone?

Original titles may differ. There are over 450 events during FOSDEM, several keynotes etc. There will be also few thousand people so I would rather not find a time to attend even half of sessions listed above… But for me this is how this conference work :D

Normally I do not take hardware with my (other than phone). This time I packed two boards, two tablets and hope to get rid of most of them ;)


All rights reserved © Marcin Juszkiewicz
Going for FOSDEM was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Some time passed since last Chromebook post so I want to give small update on Ubuntu status.

Dylan Reid from Chromium team fixed ALSA driver so frying speakers is now past. This change will go into next stable Chromium update probably. I got it merged into Ubuntu kernel and released as “3.4.0-4″ version in PPA.

In meantime Vladimir Smirnov took a look at “release-R25″ branch of kernel and got it booted. He shared configuration so I went with it, synced with Ubuntu one and got it running on my Chromebook. So expect new kernel release after FOSDEM.

There are Mali OpenGLES drivers available for download. I was unable to use them with R23 kernel (current Ubuntu one) but they do work with R25 branch so another thing to take care. This time I have to make new packaging as I need to add click thought license support. After that we can drop Chromium OS from our devices ;)

VBoot utilities are also in PPA. So signing of kernels and manipulating partition tables do not need files from Chromium anymore.

But there is one thing. Or rather lack of it… I do not have time to check do my packages work under older versions of Ubuntu (12.04, 12.10). Due to that I will not release any new updates for them — will support only ‘raring’ (13.04). Everything will be available in PPA so anyone can test.


All rights reserved © Marcin Juszkiewicz
Chromebook update was originally posted on Marcin Juszkiewicz website

Read more
Prakash

Samsung announced an 8 core! yes an 8 core ARM processor which may power the Samsung Galaxy S4

Rather than a single eight-core chip, it has two quad-cores inside – one being a quad-core ARM Cortex A15 and the other a quad-core Cortex A7. The Cortex A15 deals with the tough stuff but passes off the easy tasks to the Cortex A7, or they can both be fired up to really show off. This means it’s strong enough to provide all the power you may need, while at the same time being smart enough to conserve energy when it can. If you’re wondering just how much difference the Exynos 5 Octa and other big.LITTLE chips will make when used in a device, ARM’s CEO Warren East said he expects “twice the performance and half the power consumption” compared to today’s best offerings.

Read More.

Read more
Prakash

While ARM is gaining a lot of momentum, the challenge with ARM until now was that every architecture is very different from different vendors and requires a separate kernel and entire OS stack.

With Linux Kernel 3.7, this has changed for the better.

ARM’s problem was that, unlike the x86 architecture, where one Linux kernel could run on almost any PC or server, almost every ARM system required its own customized Linux kernel. Now with 3.7, ARM architectures can use one single vanilla Linux kernel while keeping their special device sauce in device trees.

The end result is that ARM developers will be able to boot and run Linux on their devices and then worry about getting all the extras to work. This will save them, and the Linux kernel developers, a great deal of time and trouble.

Just as good for those ARM architects and programmers who are working on high-end, 64-bit ARM systems, Linux now supports 64-bit ARM processors. 64-bit ARM CPUs won’t ship until in commercial quantities until 2013. When they do arrive though programmers eager to try 64-bit ARM processors on servers will have Linux ready for them.

Read More.

Read more
pitti

I just released Apport 2.7.

The main new feature is supporting foreign architectures in apport-retrace. If apport-retrace works in sandbox mode and works on a crash that was not produced on the same architecture as apport-retrace is running on, it will now build a sandbox for the report’s architecture and invoke gdb with the necessary magic options to produce a proper stack trace (and the other gdb information).
Right now this works for i386, x86_64, and ARMv7, but if someone is interested in making this work for other architectures, please ping me.

This is rolled out to the Launchpad retracers, see for example Bug #1088428. So from now on you can report your armhf crashes to Launchpad and they ought to be processed. Note that I did a mass-cleanup of old armhf crash bugs this morning, as the existing ones were way too old to be retraced.

For those who are running their own retracers for their project: You need to add an armhf specific apt sources list your per-release configuration directory, e. g. Ubuntu 12.04/armhf/sources.list as armhf is on ports.ubuntu.com instead of archive.ubuntu.com. Also, you need to add an armhf crash database to your crashdb.conf and add a cron job for the new architecture. You can see how all this looks like in the configuration files for the Launchpad retracers.

The other improvement concerns package hooks. So far, when a package hook crashed the exception was only printed to stderr, where most people would never see them when using the GTK or KDE frontend. With 2.7 these exceptions are also added to the report itself (HookError_filename), so that they appear in the bug reports.

The release also fixes a couple of bugs, see the release notes for details.

Read more
Marcin Juszkiewicz

Lot of services followed article on EETimes where it was announced that Samsung will present 8-core ARM cpu. What was skipped on some of them is that this is big.LITTLE design so it is made as 4xCortex-A7 + 4xCortex-A15 setup.

Good to know that there will be silicon from other vendors than ARM Ltd. Current development platform is Versatile Express TC2 (Test Chip 2) which shows that amount of A7 cores does not have to match A15 ones (it has 3xA7 + 2xA15).

But amount of cores is one thing. People usually complain about battery life and guess that such setup will suck power like crazy… when it is especially designed to save power.

Take a look at current “war” at mobile market. 2 years ago single core 1GHz Cortex-A8 cpu wit 512MB ram was high end. Then we got dual core cpu (usually Cortex-A9 based like Exynos4, OMAP4, Tegra2) and 512-1024MB of memory. Battery usually had similar capacity and lived similar time. During 2012 we saw move to quad core processors in mobile devices (Exynos4412, Tegra3) with 1-2GB ram. Space for battery was same or smaller. Next year will bring Cortex-A15 cpu (Exynos5, OMAP5, Tegra4) but this eats power…

So phones will probably get big.LITTLE processors to give users with lot of cpu power when needed and battery life otherwise. Cortex-A5/8/9/15 will not disappear from market — will land in normal and cheap devices.

I have dual core Cortex-A15 netbook now (Chromebook) and it works fast. Who knows, maybe in 2014 I will be able to replace it with something powered by 4xA7 + 4xA15 processor (unless ARMv8 will land at same time). And there is a work on getting ALL of cores running at same time…


All rights reserved © Marcin Juszkiewicz
Samsung will have big.LITTLE. So what? was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

As you know I am responsible for building cross compilers for Ubuntu. They targeted “armel” and “armhf”. But this will change.

During last few weeks I was slowly updating cross compiler source packages for ‘raring’ (current Ubuntu development version). Most of time was taken by conferences so it had to wait until previous week when I got first two parts (binutils/cross and arm{el,hf,64}-cross-toolchain-base) working. I found some issues in binutils, eglibc, linux, gcc-4.7 but make workarounds for them — will report bugs and work on fixes of course.

But situation is not nice. Armel was dropped from ‘raring’ which made building a bit harder (had to find a way to get “linux-libc-dev” package from “linux-source-3.7.0″). But I am more and more convinced that I should just drop “armel” cross compiler. It will make my life easier but of course patches are welcome.

Multilib support will get dropped as well. “armhf” cross compiler will not build for “armel” cause there will be no eglibc packages.

But there will be a bonus — I work also on “arm64″ cross compiler.


All rights reserved © Marcin Juszkiewicz
Ubuntu cross compilers situation for 13.04 ‘raring’ was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Some days ago I got Chromebook and have to say that device is amazing. Light, small and fast enough for conference laptop. During Linaro Connect I did some hacking on it with help from Olof Johansson and Andrew Wafaa (he brought Chromebook for me from Cambridge). I also used script from Jay Lee to get all information required to resize STATE partition and fit Ubuntu on internal storage.

Now I am running Ubuntu ‘raring’ on my Chromebook with XFCE as a desktop — all running from internal storage (16GB eMMC from SanDisk). So far I did not remove original Chromium from device as I keep it as a reference system to be able to compare what I got with how it works with system from Google.

So what works? Most of things — suspend/resume, wifi, bluetooth, sound, touchpad, usb ports, sd storage, camera. But why they should not work when I am using same kernel binary as Chromium OS does ;) So far did not yet came to rebuilding kernel — there were more important things to do first.

During Wednesday hacking evening I updated xf86-video-armsoc driver to X11 ABI 13 used by packages in ‘raring’ so I got 2D accelerated environment. Tried to find all sources required to build xf86-input-cmt driver but then got hint from Olof that “evdev” driver is enough — all it needs is small snippet of X11 configuration. And yes — it works but is not precise. Andrew told that he will try to build “cmt” driver for OpenSUSE so we will know how better it is.

What next? I have to create package for “cgpt” (GPT manipulation tool with support for Chromium OS extensions), tools and keys needed to sign kernel and kernel itself. Then some work would be needed for OpenGLES stuff but this can wait. I plan to upload everything needed into Debian and then request syncs to Ubuntu. From yesterday’s discussions I know which mailing lists I should go.

But I do not plan to cover everything. There will be no installation support from me. Users have to do it on their own cause there are several ways of getting other operating systems on Chromebook:

  • boot from SD card
  • boot from USB storage
  • resizing STATE partition to put system on internal eMMC (I did that)
  • removing Chromium OS completely to get more space for own system

Then there are also systems when user has developer firmware installed (that’s different that developer mode) or even setup where normal U-Boot is used as bootloader.


All rights reserved © Marcin Juszkiewicz
Used Chromebook for few days was originally posted on Marcin Juszkiewicz website

Read more

The Ubuntu Developer Summit was held in Copenhagen last week, to discuss plans for the next six-month cycle of Ubuntu. This was the most productive UDS that I've been to — maybe it was the shorter four-day schedule, or the overlap with Linaro Connect, but it sure felt like a whirlwind of activity.

I thought I'd share some details about some of the sessions that cover areas I'm working on at the moment. In no particular order:

Improving cross-compilation

Blueprint: foundations-r-improve-cross-compilation

This plan is a part of a mutli-cycle effort to improve cross-compilation support in Ubuntu. Progress is generally going well — the consensus from the session was that the components are fairly close to complete, but we still need some work to pull those parts together into something usable.

So, this cycle we'll be working on getting that done. While we have a few bugfixes and infrastructure updates to do, one significant part of this cycle’s work will be to document the “best-practices” for cross builds in Ubuntu, on wiki.ubuntu.com. This process will be heavily based on existing pages on the Linaro wiki. Because most of the support for cross-building is already done, the actual process for cross-building should be fairly straightforward, but needs to be defined somewhere.

I'll post an update when we have a working draft on the Ubuntu wiki, stay tuned for details.

Rapid archive bringup for new hardware

Blueprint: foundations-r-rapid-archive-bringup

I'd really like for there to be a way to get an Ubuntu archive built “from scratch”, to enable custom toolchain/libc/other system components to be built and tested. This is typically useful when bringing up new hardware, or testing rebuilds with new compiler settings. Because we may be dealing with new hardware, doing this bootstrap through cross-compilation is something we'd like too.

Eventually, it would be great to have something as straightforward as the OpenEmbedded or OpenWRT build process to construct a repository with a core set of Ubuntu packages (say, minbase), for previously-unsupported hardware.

The archive bootstrap process isn't done often, and can require a large amount of manual intervention. At present, there's only a couple of folks who know how to get it working. The plan here is to document the bootstrap process in this cycle, so that others can replicate the process, and possibly improve the bits that are a little too janky for general consumption.

ARM64 / ARMv8 / aarch64 support

Blueprint: foundations-r-aarch64

This session is an update for progress on the support for ARMv8 processors in Ubuntu. While no general-purpose hardware exists at the moment, we want to have all the pieces ready for when we start seeing initial implementations. Because we don't have hardware yet, this work has to be done in a cross-build environment; another reason to keep on with the foundations-r-improve-cross-compilation plan!

So far, toolchain progress is going well, with initial cross toolchains available for quantal.

Although kernel support isn’t urgent at the moment, we’ll be building an initial kernel-headers package for aarch64. There's also a plan to get a page listing the aarch64-cross build status of core packages, so we'll know what is blocked for 64-bit ARM enablement.

We’ve also got a bunch of workitems for volunteers to fix cross-build issues as they arise. If you're interested, add a workitem in the blueprint, and keep an eye on it for updates.

Secure boot support in Ubuntu

Blueprint: foundations-r-secure-boot

This session covered progress of secure boot support as at the 12.10 Quantal Quetzal release, items that are planned for 13.04, and backports for 12.04.2.

As for 12.10, we’ve got the significant components of secure boot support into the release — the signed boot chain. The one part that hasn't hit 12.10 yet is the certificate management & update infrastructure, but that is planned to reach 12.10 by way of a not-too-distant-future update.

The foundations team also mentioned that they were starting the 12.04.2 backport right after UDS, which will bring secure boot support to our current “Long Term Support” (LTS) release. Since the LTS release is often preferred Ubuntu preinstall situations, this may be used as a base for hardware enablement on secure boot machines. Combined with the certificate management tools (described at sbkeysync & maintaining uefi key databases), and the requirement for “custom mode” in general-purpose hardware, this will allow for user-defined trust configuration in an LTS release.

As for 13.04, we're planning to update the shim package to a more recent version, which will have Matthew Garrett's work on the Machine Owner Key plan from SuSE.

We're also planning to figure out support for signed kernel modules, for users who wish to verify all kernel-level code. Of course, this will mean some changes to things like DKMS, which run custom module builds outside of the normal Ubuntu packages.

Netboot with secure boot is still in progress, and will require some fixes to GRUB2.

And finally, the sbsigntools codebase could do with some new testcases, particularly for the PE/COFF parsing code. If you're interested in contributing, please contact me at jeremy.kerr@canonical.com.

Read more

Cross-compile-o-naut wookey has recently posted a set of Debian & Ubuntu packages for an aarch64 (ie, 64-bit ARMv8) cross compiler:

The repositories here contain sources and binaries for the arm64 bootstrap in Debian (unstable) and Ubuntu (quantal). There are both toolchain and tools packages for amd64 build machines and arm64 binaries built with them. And corresponding sources.

For the lazy:

[jk@pecola ~]$ wget -O - http://people.debian.org/~wookey/bootstrap/bootstrap-archive.key |
    sudo apt-key add -
[jk@pecola ~]$ sudo apt-add-repository 'deb http://people.debian.org/~wookey/bootstrap/ubunturepo/ quantal-bootstrap main universe'
[jk@pecola ~]$ sudo apt-get update
[jk@pecola ~]$ sudo apt-get install --install-recommends gcc-4.7-aarch64-linux-gnu

... which gives you a cross compiler for aarch64:

[jk@pecola ~]$ cat helloworld.c 
#include <stdio.h>
int main(void) { printf("hello world\n"); return 0; }
[jk@pecola ~]$ aarch64-linux-gnu-gcc-4.7 -Wall -O2 -o helloworld helloworld.c
[jk@pecola ~]$ aarch64-linux-gnu-objdump -f helloworld 
helloworld:     file format elf64-littleaarch64
architecture: aarch64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000400450

Read more
Marcin Juszkiewicz

Sometimes it is good to take a look at IRC channel in the evening. There will be new chromebook from Samsung. Someone may say “So what? It’s just yet another chromebook not worth looking at.” but I will disagree.

What is special in this device? Specification of course ;) Exynos5 Dual (5250) which has 2 Cortex-A15 cores, 2GB of memory, 16GB of eMMC (a bit small but 64GB sd cards exist) and all that in 11.6″ netbook case. There is no ARM device on a market which could be compared and run open source operating system.

I hope to get one soon — online stores will sell it on Monday. From what I know there will be a way to run other operating system than ChromeOS — I will switch to Ubuntu or Debian on first day probably.

And finally will replace Efika MX Smartbook.


All rights reserved © Marcin Juszkiewicz
New thing to buy: Samsung Chromebook was originally posted on Marcin Juszkiewicz website

Read more
Marcin Juszkiewicz

Over year ago I wrote post in which I complained about cheap developer boards but concentrated on ones supported by Linaro. This time I want to write about boards which I did not even had occasion to play with.

Most popular one was Rasperry/Pi. But as I already wrote why I’m tired of it I prefer to not discuss it too much. In short: old cpu core (ARM11), not enough memory (256MB), requires closed binaries even to boot (the GPU binary also contains the first stage bootloader).

Then we have a lot of boards based on AllWinner A10/A13 cpus. Single core Cortex-A8, no Linux kernel support in mainline. Fun is that there is Serial ATA controller in SoC but most of the boards does not offer that so users have to use SD or USB storage which is slower. Example devices: Hackberry, Cubieboard, Mele A1000.

Fun stuff starts to appear from Freescale area. i.MX6 cpu has potential and many options available. There are Wandboard, Sabrelite with second one providing interesting addons like mini PCI-Express slot (with PCIe signals) or small board with buttons (Android oriented).

Quad A9 boards are also available with Samsung s3c4412 cpu — like ODroid-X which I described when it was released. But no Serial-ATA in this processor.

So which one to choose? All depends what you want to do with it. Few days ago on debian-arm mailing list someone asked “Workstation based on ARM motherboard, good idea ?” which got me to conclusion that it possible to setup low specification desktop today with ARM cpu.

I wonder how much would I have to pay for mini-ITX compatible board (can be smaller but has to be mountable to normal PC case) with 2-4GB of memory (SO-DIMM preferred) with quad core cpu and Serial ATA. So I could connect usb mouse/keyboard, monitor though HDMI, speakers with 3.5mm jack, Ethernet (1GbE preferred) and boot Debian/Ubuntu straight from SATA hard drive or ssd. 2D/3D acceleration working and recent (max 2 versions old) Linux kernel working with not insane amount of patches. But such day probably will not happen.

UPDATE: Looks like VIA had such idea with their APC board. Neo-ITX format but components few years old ;(


All rights reserved © Marcin Juszkiewicz
Let’s take a look at ARM boards again was originally posted on Marcin Juszkiewicz website

Read more

Most of the components of the 64-bit ARM toolchain have been released, so I've put together some details on building a cross compiler for aarch64. At present, this is only binutils & compiler (ie, no libc), so is probably not useful for applications. However, I have a 64-bit ARM kernel building without any trouble.

Update: looking for an easy way to install a cross-compiler on Ubuntu or debian? Check out aarch64 cross compiler packages for Ubuntu & Debian.

pre-built toolchain

If you're simply looking to download a cross compiler, here's one I've built earlier: aarch64-cross.tar.gz (.tar.gz, 85MB). It's built for an x86_64 build machine, using Ubuntu 12.04 LTS, but should work with other distributions too.

The toolchain is configured for paths in /opt/cross/. To install it, do a:

[jk@pecola ~]$ sudo mkdir /opt/cross
[jk@pecola ~]$ sudo chown $USER /opt/cross
[jk@pecola ~]$ tar -C /opt/cross/ -xf aarch64-x86_64-cross.tar.gz

If you'd like to build your own, here's how:

initial setup

We're going to be building in ~/build/aarch64-toolchain/, and installing into /opt/cross/aarch64/. If you'd prefer to use other paths, simply change these in the commands below.

[jk@pecola ~]$ mkdir -p ~/build/arm64-toolchain/
[jk@pecola ~]$ cd ~/build/arm64-toolchain/
[jk@pecola ~]$ prefix=/opt/cross/aarch64/

We'll also need a few packages for the build:

[jk@pecola ~]$ sudo apt-get install bison flex libmpfr-dev libmpc-dev texinfo

binutils

I have a git repository with a recent version of ARM's aarch64 support, plus a few minor updates at git://kernel.ubuntu.com/jk/arm64/binutils.git (or browse the gitweb view). To build:

Update: arm64 support has been merged into upstream binutils, so you can now use the official git repository. The commit 02b16151 builds successfully for me.

[jk@pecola arm64-toolchain]$ git clone git://gcc.gnu.org/git/binutils.git
[jk@pecola arm64-toolchain]$ cd binutils
[jk@pecola binutils]$ ./configure --prefix=$prefix --target=aarch64-none-linux
[jk@pecola binutils]$ make
[jk@pecola binutils]$ make install
[jk@pecola binutils]$ cd ..

kernel headers

Next up, the kernel headers. I'm using Catalin Marinas' kernel tree on kernel.org here. We don't need to do a full build (we don't have a compiler yet..), just the headers_install target.

[jk@pecola arm64-toolchain]$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
[jk@pecola arm64-toolchain]$ cd linux-aarch64
[jk@pecola linux-aarch64]$ git reset --hard b6fe1645
[jk@pecola linux-aarch64]$ make ARCH=arm64 INSTALL_HDR_PATH=$prefix headers_install
[jk@pecola linux-aarch64]$ cd ..

gcc

And now we should have things ready for the compiler build. I have a git tree up at git://kernel.ubuntu.com/jk/arm64/gcc.git (gitweb), but this is just the aarch64 branch of upstream gcc.

[jk@pecola arm64-toolchain]$ git clone git://kernel.ubuntu.com/jk/arm64/gcc.git
[jk@pecola arm64-toolchain]$ cd gcc/aarch64-branch/
[jk@pecola aarch64-branch]$ git reset --hard d6a1e14b
[jk@pecola aarch64-branch]$ ./configure --prefix=$prefix \
    --target=aarch64-none-linux --enable-languages=c \
    --disable-threads --disable-shared --disable-libmudflap \
    --disable-libssp --disable-libgomp --disable-libquadmath
[jk@pecola aarch64-branch]$ make
[jk@pecola aarch64-branch]$ make install
[jk@pecola aarch64-branch]$ cd ../..

That's it! You should have a working compiler for arm64 kernels in /opt/cross/aarch64.

Read more