1. Why my device is not supported by distributions

    During weekend I was in Puck, Poland at small conference called “Zimowisko linuksowe” (Linux winter camp) where I had a talk called “Dlaczego moje urządzenie nie jest obsługiwane przez dystrybucje” (Why my device is not supported by distributions).

    In talk I presented how distributions (Debian, Fedora) handle ARM devices (one kernel for all, one image for all) and why it does not fit Raspberry/Pi or Chromebook. Also mentioned Roseapple/Pi as an example of how not to make support for device.

    There were questions about suggested boards (most of people knew Raspberry/Pi and one or two other by name) and ARM powered laptops other than Chromebooks.

    And then we went to celebrate birthdays of few friends who had them on same day.

    You can download presentation in Polish or English (translation was requested by few folks from IRC after I annouced that there will be such talk).

    Written by Marcin Juszkiewicz on
  2. 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.

    Written by Marcin Juszkiewicz on
  3. Cello: new AArch64 enterprise board from 96boards project

    Few hours ago, somewhere in some hotel in Bangkok Linaro Connect has started. So during morning coffee I watched keynote and noticed that Jon Masters presented RHELSA 7.2 out of the box experience on Huskyboard. And then brand new board from 96boards project was announced: Cello.

    Lot of people was expecting that this Linaro Connect will bring Huskyboard alive so people will finally have an option for some cheap board for all their AArch64 needs. Instead Cello was presented:

    Cello
    Cello

    Compared to Husky (below) there are some hardware differences to notice but it is normal as 96borads enterprise specification only tells where to put ports.

    Husky
    Husky

    I suppose that both boards were designed by different companies. Maybe it was a request from Linaro to ODM vendors to design and mass produce 96boards enterprise board and Husky was prototyped first but Cello won. Or maybe we will see Husky in distribution as well. Good part is: you can preorder Cello and get it delivered in Q2/2016.

    Have to admit that I hoped for some industry standard board (96boards Enterprise specification mentions microATX) instead of this weird 96boards-only format which I ranted about already. Anyway 299 USD for quad-core Cortex-A57 with SATA, UEFI, ACPI, PCIe (and maybe few more four letter acronyms) does not sound bad but good luck with finding case for it ;(

    Written by Marcin Juszkiewicz on
  4. From the diary of AArch64 porter — system calls

    When userspace want to talk to kernel it can use system calls. Applications usually do it via wrappers in libc to not have to deal with different numbers on different architectures.

    There are over four hundred system calls in Linux kernel. Many of them have “legacy” status and as such are not available on many new architectures. Riku Voipio from Linaro has nice slides about it.

    So to make things easier for developers I worked on creating a table showing all system calls and their number/status on different architectures. But this table was generated partially by hand…

    I changed code to keep a list of all syscalls in place, wrote generator of C code and added makefile on top. And then pushed it into a new git repo called syscalls-table. Code is MIT licensed.

    Please go, check the code, run it on any architecture and send me pull requests. The only requirements for generating list of architecture specific syscalls list are bash and C compiler. Table generation requires Python but does not have to be run on target platform.

    Written by Marcin Juszkiewicz on
  5. Raspberry/Pi 3? Meh

    I was mostly offline during last three days. You know — meeting long-time-no-see friends, walking tens of kilometres in other city looking at cellphone screen (aka playing Ingress) etc.

    But even then it was hard to not notice that Raspberry Foundation announced new version of their product called Raspberry/Pi 3 — many friends asked me what do I think about it, is it worth buying now, will Fedora run on it etc.

    So let make it short. No, it will not run Fedora 24 because there is no support for this device (I would not call it developer board as it would be insult to all developer boards) in mainline kernel, it still boots in insane way, has new binary blob without permissions to distribute etc… And since R/Pi 2 got released year ago there was no community effort to get this board supported and we have better things to do.

    Is it worth buying? If all you want to do is connect few sensors to GPIO/I²C/SPI pins then maybe as it is cheap, but I would go for Beaglebone to get wide distribution support. If you want to make a desktop then forget it (1GB of memory). If you want to make anything related to storage/networking forget it too (storage on USB shared with all other USB devices as there is only one USB host port).

    For years Raspberry Foundation did not learn that price is not the only thing which makes product worth using. BCM2835 was terrible but usable. BCM2836 got newer cpu core but rest stayed so resulting device was far behind properly made developer boards. BCM2837 should not happen.

    Written by Marcin Juszkiewicz on
  6. I may go back to Linaro

    Few days ago my manager asked me if I would like to go back to Linaro. This time not as ‘Linaro-but-Canonical engineer’ but as ‘Red Hat assigned engineer’. That made me thinking…

    Those three years at Linaro were good time. Learnt a lot about cross toolchains, got possibility to work on bootstrapping AArch64 support in OpenEmbedded, Debian/Ubuntu and then Fedora/RHEL. Met many skilled people from around the world, travelled into places which I would probably not visit on my own.

    Going back sounds good. From my discussions with few people from Linaro there is more and more AArch64 related work there (and I have some hardware at home) so my rusty arm32 skills can rust in peace. Have to take a closer look at what exactly is on a plate there to take and find some place.

    So if you work for Linaro and will be at FOSDEM (or devconf.cz) then I would love to talk.

    Written by Marcin Juszkiewicz on
  7. Running 32-bit ARM virtual machine on AArch64 hardware

    It was a matter of days and finally all pieces are done. Running 32-bit ARM virtual machines on 64-bit AArch64 hardware is possible and quite easy.

    Requirements

    • AArch64 hardware (I used APM Mustang as usual)
    • ARM rootfs (fetched Fedora 22 image with “virt-builder” tool)
    • ARM kernel and initramfs (I used Fedora 24 one)
    • Virt Manager (can be done from shell too)

    Configuration

    Start “virt-manager” and add new machine:

    Add new machine
    Add new machine

    Select rootfs, kernel, initramfs (dtb will be provided internally by qemu) and tell kernel where rootfs is:

    Storage/boot options
    Storage/boot options

    Then set amount of memory and cores. I did 10GB of RAM and 8 cores. Save machine.

    Let’s run

    Open created machine and press Play button. It should boot:

    Booted system
    Booted system

    I upgraded F22 to F24 to have latest development system.

    Is it fast?

    If I would just boot and write about it then there will be questions about performance. I did build of gcc 5.3.1-3 using mock (standard Fedora way). On arm32 Fedora builder it took 19 hours, on AArch64 builder 4.5h only. On my machine AArch64 build took 9.5 hour and in this vm it took 12.5h (slow hdd used). So builder with memory and some fast storage will boost arm32 builds a lot.

    Numbers from “openssl speed” shows performance similar to host cpu:

    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    md2               1787.41k     3677.19k     5039.02k     5555.88k     5728.94k
    mdc2                 0.00         0.00         0.00         0.00         0.00
    md4              24846.05k    81594.07k   226791.59k   418185.22k   554344.45k
    md5              18881.79k    60907.46k   163927.55k   281694.58k   357168.47k
    hmac(md5)        21345.25k    69033.83k   177675.52k   291996.33k   357250.39k
    sha1             20776.17k    65099.46k   167091.03k   275240.62k   338582.71k
    rmd160           15867.02k    42659.95k    88652.54k   123879.77k   140571.99k
    rc4             167878.11k   186243.61k   191468.46k   192576.51k   193112.75k
    des cbc          35418.48k    37327.19k    37803.69k    37954.56k    37991.77k
    des ede3         13415.40k    13605.87k    13641.90k    13654.36k    13628.76k
    idea cbc         36377.06k    38284.93k    38665.05k    38864.71k    39032.15k
    seed cbc         42533.48k    43863.15k    44276.22k    44376.75k    44397.91k
    rc2 cbc          29523.86k    30563.20k    30763.09k    30940.50k    30857.44k
    rc5-32/12 cbc        0.00         0.00         0.00         0.00         0.00
    blowfish cbc     60512.96k    66274.07k    67889.66k    68273.15k    68302.17k
    cast cbc         56795.77k    61845.42k    63236.86k    63251.11k    63445.82k
    aes-128 cbc      61479.48k    65319.32k    67327.49k    67773.78k    66590.04k
    aes-192 cbc      53337.95k    55916.74k    56583.34k    56957.61k    57024.51k
    aes-256 cbc      46888.06k    48538.97k    49300.82k    49725.44k    50402.65k
    camellia-128 cbc    59413.00k    62610.45k    63400.53k    63593.13k    63660.03k
    camellia-192 cbc    47212.40k    49549.89k    50590.21k    50843.99k    50012.16k
    camellia-256 cbc    47581.19k    49388.89k    50519.13k    49991.68k    50978.82k
    sha256           27232.09k    64660.84k   119572.57k   151862.27k   164874.92k
    sha512            9376.71k    37571.93k    54401.88k    74966.36k    84322.99k
    whirlpool         3358.92k     6907.67k    11214.42k    13301.08k    14065.66k
    aes-128 ige      60127.48k    65397.14k    67277.65k    67428.35k    67584.00k
    aes-192 ige      52340.73k    56249.81k    57313.54k    57559.38k    57191.08k
    aes-256 ige      46090.63k    48848.96k    49684.82k    49861.32k    49892.01k
    ghash           150893.11k   171448.55k   177457.92k   179003.39k   179595.95k
                      sign    verify    sign/s verify/s
    rsa  512 bits 0.000322s 0.000026s   3101.3  39214.9
    rsa 1024 bits 0.001446s 0.000073s    691.7  13714.6
    rsa 2048 bits 0.008511s 0.000251s    117.5   3987.5
    rsa 4096 bits 0.058092s 0.000945s     17.2   1058.4
                      sign    verify    sign/s verify/s
    dsa  512 bits 0.000272s 0.000297s   3680.6   3363.6
    dsa 1024 bits 0.000739s 0.000897s   1353.1   1115.2
    dsa 2048 bits 0.002762s 0.002903s    362.1    344.5
                                  sign    verify    sign/s verify/s
     256 bit ecdsa (nistp256)   0.0005s   0.0019s   1977.8    538.3
     384 bit ecdsa (nistp384)   0.0015s   0.0057s    663.0    174.6
     521 bit ecdsa (nistp521)   0.0035s   0.0136s    286.8     73.4
                                  op      op/s
     256 bit ecdh (nistp256)   0.0016s    616.0
     384 bit ecdh (nistp384)   0.0049s    204.8
     521 bit ecdh (nistp521)   0.0115s     87.2
    
    Written by Marcin Juszkiewicz on
  8. FOSDEM and Devconf.cz trip

    As two years and year ago I plan to make conference combo: FOSDEM in Brussels and then Devconf.cz in Brno. Weekend after weekend. But this time I want to make it different.

    First I thought that will skip devconf.cz one. But this is quite important Fedora conference so checked how to make it cheaper that in previous years. And found out few deals and setup a trip which should be interesting.

    From home to SXF and then with Ryanair to Brussels. Visit friends, meet friends, make some beers, attend talks, discuss with strange and familiar people — like each time during FOSDEM.

    Then fly to Bratislava, Slovakia (Ryanair from CRL) and stay there for few days. Visit some places, do some Ingress missions, buy fridge magnet — typical tourist stuff.

    From there take a train to Brno. Stay at some cheap ho(s)tel, attend devconf.cz conference, do some beers, meet friends etc. Like on normal conference.

    And from there go back home by train. With one hour break at Berlin Hbf station.

    Have to fill a form to arrange PTO for Bratislava and buy some tickets. Hope that it will be fun trip.

    Written by Marcin Juszkiewicz on
Page 21 / 106