Twenty five years of Linux

As I came back from PTO I had to dig into work mails. One of threads was about 25 years of Linux and there was a question “which was your first kernel” and I thought that it may be not an easy question to answer.

For me first was 2.0.2[6-8] (do not remember) on some Uni server where I got my first Linux account (normally used SunOS and text terminal). I remember that there was simple root exploit we used.

Then 2.0.36 on my Amiga 1200 (Debian ‘slink’) was first I run on my hardware.

2.2.10 was first I used for longer as it was Debian ‘potato’ m68k one.

2.3.47 was first I cross compiled (on i686/linux for m68k/linux). And it worked!

2.4.0-test5 was first I built for my x86 desktop once I moved from Amiga/AmigaOS to PC/Debian. I had Duron/600 desktop and old 386 desktop both running same version. Duron got newer ones later, 386 stayed with this one for about year when I returned it.

When I bougth Sharp Zaurus SL-5500 PDA 2.4.18-rmk7-pxa3-embeddix was running on it. So this is my first Linux version on mobile device. Next jump was 2.6.11 on Zaurus c760 as first 2.6 one on mobile.

During OpenZaurus maintaince I started upstreaming kernel patches. 2.6.17 was first with my patches in.

When I had that strange ProGear webpad I wrote backlight for it (based on someone’s code) and 2.6.21 was first with my driver in (and I removed it in 3.7).

Waiting for 96 boards with MIPS or Arduino?

Linaro Connect in progress. Bubblegum 96 announced and present at 96boards website. But I am waiting for MIPS version…

Why MIPS? Looking how earlier Consumer Edition 96 boards devices got released it looks to me that compliance to specification is optional. And as there is no information that cpu has to be ARM (“Design is SoC independent (targets 32 or 64 bit SoCs)”) so let make MIPS one.

I thought about Atmega first but kernel support shall be provided and video output. On the other side — both (Linux kernel on AVR and video output) were already done in past on that platform so maybe it could be done.

You can run any random kernel release, have own set of ugly patches for bootloader. And you will get “96 boards officially certified” stamp on it.

In my opinion 96boards project should enforce “your SoC should have at least minimal support in linux-next kernel tree” rule before even looking at products. Actions Semi maybe is good in producing chips but looks like they have no idea how to take care of software.

Fedora 23 and unsupported ARM/AArch64 devices

Week ago Fedora 23 got released. Also for ARM and AArch64 architectures. But it does not mean that it supports all possible hardware.


There is the installation guide which lists two supported hardware platforms (besides QEMU):

  • Applied Micro Mustang
  • AMD Seattle

And then we got email from Clive Messer with question why we do not support 96Boards, ie. HiKey and Dragonboard as they are cheap and available.

I am not surprised with such question. It would be great to have support for both boards but their current state makes it quite hard. There is no support for them in mainline kernel, Dragonboard needs some firmware files which license forbids packaging it (note bolded part):

Distribution of the Redistributable Binary Code is subject to the following restrictions: (i) Redistributable Binary Code may only be distributed in binary format and may not be distributed in source code format: (ii) Redistributable Binary Code may not be distributed on a stand alone basis but may be redistributed in conjunction with and as a part of a software application created by you; (iii) the Redistributable Binary Code may only operate in conjunction with platforms incorporating Qualcomm Technologies, Inc. chipsets; (iv) redistribution of the Redistributable Binary Code must include the .txt file setting forth the terms and condition of this Agreement; (v) you may not use Qualcomm Technologies’ or its affiliates or subsidiaries name, logo or trademarks; and (vi) copyright, trademark, patent and any other notices that appear on the Materials may not be removed or obscured.

So even if we get mainline kernel working on it some things will not work without non-free files.

Then we have bootloaders. Hikey can be flashed with UEFI but (according to bootloader install documentation) you need to keep partitions in some magic way. Where is “there has to be one ef00 type partition formatted with FAT” as it is with other UEFI powered machines? Dragonboard 410c uses fastboot ;(


On ARM side there is common question about “most readily available and used board, with the most units sold and the biggest community” one. I think that developers from that community do not want their board supported in main distributions like Debian or Fedora.

Heresy? Do not think so. What needs to get board supported was told many times. Mainline kernel support, firmware blobs with redistribution license, drivers for graphics and sane bootloader (UEFI, U-Boot, maybe some other too).


So if you want to have your board supported then spend some time on mainlining your changes/drivers. And then come to us.

USB on Mustang

When I got APM Mustang at home I knew that one day I will use it to test desktop environments. Lack of graphics and USB kept me away from it. And I am closer now…

Yesterday Mark Langsdorf wrote two patches which allow to use USB3 ports from Mustang’s backplate. I applied first version of them, altered DeviceTree blob a bit and after reboot I got that:

16:36 hrw@pinkiepie-rawhide:~$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 1234:2088 Brain Actuated Technologies 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

All with slightly modified 3.18-rc2 kernel from Fedora rawhide.

Now need to sort out graphics… But first need to buy yet another card…

USB Sucks Badly?

I bought new hub to use on my desk: 7 port USB 3.0 one with switchable ports. Connected to USB 3.0 port and problems started…

Base of my desktop is P67X-UD3-B3 mainboard from Gigabyte which I have chosen due to amount of USB ports on back (alternative was one of Z68 based mainboard which would give me HDMI/VGA/DVI ports for integrated graphics). But now it looks like it was not good choice.

I have those devices connected:

  • Microsoft Optical Mouse with Tilt Wheel
  • Microsoft Natural Ergonomic Keyboard 4000
  • Future Technology Devices International, Ltd FT232 USB-Serial
  • Logitech Webcam Pro 9000
  • NEC HighSpeed Hub integrated in my second monitor
  • Genesys Logic based 7-port USB 3.0 hub on my desk
  • Samsung ML-2160 Laser printer

But when I plug any of those USB 1.1 devices all I have is “Not enough bandwidth for new device state.” message from kernel. Faster devices are fine so I can connect pen drives, hard drives, phones or tablets. But forget about USB-Serial dongles or Yubikeys or BlueTooth…

Why’s that? Take a look at “lsusb -t” output:

/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 7, If 0, Class=Hub, Driver=hub/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
    |__ Port 1: Dev 28, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 29, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 3: Dev 62, If 0, Class=Mass Storage, Driver=usb-storage, 480M
    |__ Port 2: Dev 54, If 0, Class=Printer, Driver=usblp, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 3: Dev 10, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 2: Dev 11, If 0, Class=Video, Driver=uvcvideo, 480M
            |__ Port 2: Dev 11, If 1, Class=Video, Driver=uvcvideo, 480M
            |__ Port 2: Dev 11, If 2, Class=Audio, Driver=snd-usb-audio, 480M
            |__ Port 2: Dev 11, If 3, Class=Audio, Driver=snd-usb-audio, 480M
            |__ Port 3: Dev 12, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
        |__ Port 5: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 5: Dev 5, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 6: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M

How many EHCI buses do you see? You may say two (as there are two ehci-pci entries) or you may say four (as there are four 480M buses). I would say that “not enough” is best answer.

I played with cables to move devices from 2nd bus to 1st one, moved printer from 3rd bus to 5th (which is two USB 3.0 connectors on top of computer’s case) and still not enough bandwidth for Yubikey or other USB 1.1 device. Note that all devices plugged into on-desk USB 3.0 hub lands on 3rd (1.1/2.0) or 4th (3.0) bus.

During next few days I will plug extra USB 2.0 controller to check will it improve situation after keyboard, mouse, monitor, webcam, ftdi move there.

UPDATE: turns out that USB 3.0 hub does not fully conform to specification. In the end I have added USB 2.0 hub (connected to 2.0 port) just for my USB 1.1 devices.

New boot setup of my Chromebook

After several recompilations I finally got what I wanted on my Chromebook. Clean and easy way of booting own kernel.

Now situation is clean and easy:

  • power on Chromebook
  • ChromeOS U-Boot from SPI flash starts
  • white screen of warning appears
  • Ctrl-d to skip it
  • U-Boot starts from mmcblk0p1
  • U-Boot reads boot.txt from mmcblk0p2 (ext2 /boot/ partition)
  • U-Boot reads uImage kernel and exynos5250-snow.dtb file from mmcblk0p2
  • Kernel boots directly to Fedora F19 stored on mmcblk0p3

This way I can quickly test mainline kernels (but this may require U-Boot change for simplefb support), manipulate 3.[48]-chromeos ones etc.

Next step would be replace bootloader stored in SPI flash but this voids warranty so let it wait a bit.

Booted mainline kernel on Chromebook

Olof Johannson wrote on Google+ how to get mainline kernel booting on Samsung ARM Chromebook. As mine returned from repair with new speakers and bottom cover I decided to take a look.

With chainloaded U-Boot and just standard “exynos_defconfig” build of 3.11-rc2 I got my machine booting to Ubuntu right away:

00:06 hrw@krolik:~$ cat /proc/device-tree/model ;echo
Google Snow
00:06 hrw@krolik:~$ uname -snrp
Linux krolik 3.11.0-rc2 armv7l

There are some things missing (audio, usb 3.0, backlight and more) but even with what is available we can boot and use Chromebook with mainline kernel instead of ChromeOS one.

I will revert to 3.4-chromeos for now and try 3.8-chromeos one but that’s because I use Chromebook as developer machine for some builds where storage speed matters.

Linux 3.9 and Chromebook support

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.

How to fry speakers in your Chromebook

Lot of people asked me how I managed to fry left speaker in my Chromebook. There are also few which said that it is Ubuntu fault.

So today I used recovery to wipe out my installation of Ubuntu from device and decided to check under Chromium OS. And yes, I got nice smell of burnt plastic etc coming from left speaker area.

Why? Because it is kernel bug. Not Ubuntu, ALSA or user. Ok, it is a bit of user’s fault cause you should not have to play with ALSA mixer. But you can — all binaries are part of Chromium OS stable.

So let me give you needed steps:

  1. Boot Samsung Chromebook (ARM one) to Chromium OS
  2. Login or use guest session
  3. Run terminal (Ctrl+Alt+t)
  4. Run “alsamixer -c0”
  5. Set “Lineout” to highest value
  6. Unmute everything what starts with “Left” or “Right” (depends which speaker you do not like)
  7. Touch speakers (but better not for long)
  8. Hold “Power” button to shut down before it will burn though your desk.

In normal situation I would assume that sound driver will take care of combinations which may break your hardware. But looks like Chromebook developers did had such idea.

Is this howto useful? I think it is. Cause if you have device broken in some way and you want to get it replaced you can just run it and hope for replacement instead of repair.

And when next time someone will write me “go and fix ubuntu rather than putting blame on samsung. Its Ubuntu which is the cause” like I got in recent comment I will just ban such person from commenting.

Yes, I am using Midnight Commander

Today Alan Pope was surprised that I am using Midnight Commander. It was not the first time when I saw such reaction.

Why am I using mc? It is “simple” tool, works fine and I know it. Some of its features are useless today (like /#sh: way of handling copying over ssh which got replaced by sshfs) but if it works why I should abandon it? I can use it remotely (try it with Nautilus/Dolphin/Thunar), on every type of terminal (but was incredibly hardcore on HP2623A one).

But thing which I love it in is “patchfs”. It allows to handle diffs like archives but with read/write operations. I can remove not wanted parts from patch without going into editor. When I was dealing with crazy/huge patches I was able to clean them in few minutes