Tag Archives: linux

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.

Obsoleted but mainline

Lot was written about why upstreaming matters. And why it should be done earlier than later too. And I found out that I have perfect example.

Few days ago Linus Walleij contacted me with a question:

Hi Marcin, do you still have the Nomadik NHK8815 board? I’m contemplating fixing it to work some time, but haven’t got hold of one. I think it only needs a device tree actually, so we could hack it up at some conference if you’re at the same some time.

And then I realized that indeed — I still have it somewhere in my basement gathering dust. We quickly agreed on shipping it so Linus will be able to finish work on adding support for already obsolete board in mainline kernel.

For me NHK-15 is a perfect example of device which was supported in wrong way. When I got it 5 years ago it was already several kernel releases behind with kernel (no stable updates even). I managed to get Poky Linux running on it but told clearly that it will gather dust after finishing task because for me board with no upstream support is worthless.

So board spent few weeks on my desk and then went back to the box and on shelf in basement. Then became forgotten. For 5 years. Today I opened box, checked contents, added some filling so it is ready for courier. Then I will forget about it again.

UPDATE: My Sim.One board joined NHK-15 as it is hard to find working device with EP93xx processor in it.

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.

My first day with Fedora

Yesterday I switched my home desktop from Ubuntu 13.10 to Fedora 19 to have work environment ready for my Red Hat tasks.

Installation was easy as Fedora installer does not ask too many questions. But also does not give any software choice so I took KDE one. Made a backup of Ubuntu rootfs and /home partition and 10 minutes later I was running same X11 session but with Fedora logo in a corner.

Installing extra packages is argh… There is yum and basically nothing else. I tried Apper and Yumex — none of them was useful. Apper was unable to remove Konversation and message I got was useless (“some package depend on it” like). Yum did not have any objections. Yumex was even worse as it gave me a list of all packages without any grouping applied. Even “dselect” was better in 1999 when I started with Debian.

So I installed APT. This one works but only kind of… “apt-cache search something” takes eons, installing packages is impossible due to a way how RPM works…

Because RPM allows to have more than 1 version of package installed at same time. WHY? How it is supposed to work at all??? And no, I did not have any filesystem corruptions or something like that…

Anyway those problems can be bypassed or ignored. But then there are other ones. I always thought that Debian legal team has very strict rules about what can go into distribution. Fedora proved that I was wrong. External repositories are a must have here. MP3 or AAC playback? Forget. Probably also video playback etc. Want Google Chrome? Forget. I understand why Adobe Flash is not in repo (but there is one with it as well) but all that? Probably there are more entries here but I did not yet finished installing stuff I use/need.

Will have to add few tweaks here and there (like bumping “nr_uarts” kernel option to have all 7 serial ports) but it works. And I like “journalctl -b” way of checking what was going on since system boot ;D

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.

RedHat and real AArch64 hardware today

In around 3 hours from now Jon Masters from RedHat will have first live multi-node cluster 64-bit ARM silicon demo running Fedora. On real hardware…

It amazing how it went from new architecture announcement though simulators, boostrapping distributions to running those on real hardware. When I was working on AArch64 we were said that it will take one more year before we see devices not emulators or FPGAs (which I heard were slower than simulator).

I hope to work on AArch64 support again — one day in a future.

BTW — there will be no live streaming but Jon wrote that there will be video posted in short time after.