1. I moved to the new flat

    There are moments in a life when we want to change something. So I changed place of living.

    Moved out of rented flat into my own one. Still Szczecin, still suburbian part of it (I moved by about 1500 meters). Nothing fancy, plain 3 rooms but it is mine (once I pay bank’s part in next few years).

    It needs some changes as I am taller than previous owners. My list of ideas to make gets longer and longer each time I see something interesting in store of someone’s home.

    Server wardrobe

    Previous owners left several built-in wardrobes so I decided to use one for my servers. Moved my NAS, router, HoneyComb and Mustang into top shelf with all required cabling. This way none of them occupy my desk area.

    And why ‘server wardrobe’ name for it? In Polish we use ‘szafa serwerowa’ for ‘server rack’. But ‘szafa’ is also ‘wardrobe’ so that’s why :D

    New desk for my office

    In previous years I used a custom made desk. It was real monster — L-shaped with several shelves under. That allowed me to keep multiple systems running on/under desk (there were times when 16 ports in Ethernet switches were not enough).

    But it was also heavy and hard to manipulate/move. So it went to trash.

    For first days I used some table but it was not the right choice. In meantime I looked at several setups and desks to find which features to look for.

    Finally ended with buying VS series 901 desk. 180x90 cm gave me a lot of space, all cables go though dedicated gap into cable organiser under desk. And there I have Ethernet switch, laptop’s docking station (and it’s power supply), power supply for my monitor, usb hubs and all cables. No more floating cables! And all that for ~100€ for used one.

    Nicely organized desk
    Nicely organized desk

    Still need to buy some office storage unit with some drawers — it would go on left side of desk (where currently bathroom drawers are present). Looking through used office furniture again.

    Hall of fame

    On photo above you may see shelf behind my desk. I plan to organize some kind of ‘Hall of fame’ there for devices which helped with my carieer:

    • Sharp Zaurus SL-5500 (got one recently from Andrea Adami)
    • Atmel AT91SAM9263-EK developer board
    • Applied Micro Mustang

    And few other ones as I need to track where I have them first or where I can get them (anyone has spare ST NDK-15?).


    Due to some weird location of light switches I decided to speedup a bit and move most of home lights to controllable ones. To make things easier I went into system used by one of my friends: Trådfri by Ikea.

    Lights, motion sensor to get some dimmed light during night walk to toilet, remotes etc.


    It is good to have own space for living. I can alter it in any way I want. Without checking will it be useful for short people.

    Written by Marcin Juszkiewicz on
  2. My twenty plus years of IRC

    In 1996 I started studies at Białystok University of Technology. And one of early days I found that corridor with text terminals. Some time later I joined that crowd and started using HP-2623A term with SunOS account.

    And one of first applications crowd shown me was ircII (other were bash, screen, pine and ncftp). So I am IRC user for over 24 years now and this XKCD comics can be about me:

    2078: He announces that he's finally making the jump from screen+irssi to tmux+weechat.
    Team chat


    As wrote above I started with ircII. It was painful to use so quickly some scripts landed — Venom, Lice and some others. Tried Epic, Epic2000 and some other clients to finally end with Irssi. I have never been a fan of GUI based ones.

    There were moments when people used CTCP VERSION to check what clients other users use. In old Amiga days I usually had it set to similar one as AmIRC one but with version bumped above whatever was released. Simple trolling for all those curious people. Nowadays it simply replies with “telnet” and there was a day when I logged to IRC server and exchanged some messages using just telnet :D


    For years I was user of IRCnet. It was popular in Poland so why bother with checking other networks. But as time passed and I became more involved in FOSS projects there was a need to start using Freenode, then OFTC, Mozilla etc.

    Checked how old my accounts are as it nicely show when I started using which network.


    IRCnet was my first IRC network. Stopped using it few years ago as all channels I was on went quiet or migrated elsewhere (mostly Freenode).

    For years I was visible on Amiga channels #amisia, #amigapl where I met several friends and I am in contact with many of them still.


    The journey started on 15th May 2004. This was time when I started playing with OpenEmbedded and knew that this is a project where I will spend some of my free time (it became hobby, then job).

    It was a place where CentOS, Fedora, Linaro, OpenStack and several other projects were present.

    NickServ- Information on Hrw (account hrw):
    NickServ- Registered : Mar 15 10:59:47 2004 (17y 9w 6d ago)
    NickServ- Last addr  : ~hrw@redhat/hrw
    NickServ- vHost      : redhat/hrw
    NickServ- Last seen  : now
    NickServ- Flags      : HideMail
    NickServ- *** End of Info ***


    For me OFTC means Debian. Later also virtualization stuff as QEMU and libvirt folks sit there.

    NickServ- Nickname information for hrw (Marcin Juszkiewicz)
    NickServ- hrw is currently online
    NickServ-   Time registered: Fri 10 Jun 2011 17:43:55 +0000 (9y 11m 10d 14:47:05 ago)
    NickServ- Account last quit: Tue 18 May 2021 09:07:55 +0000 (1d 23:23:05 ago)
    NickServ- Last quit message: Remote host closed the connection
    NickServ-         Last host: 00019652.user.oftc.net
    NickServ-               URL: http://marcin.juszkiewicz.com.pl/
    NickServ-      Cloak string: Not set
    NickServ-          Language: English (0)
    NickServ-           ENFORCE: ON
    NickServ-            SECURE: OFF
    NickServ-           PRIVATE: ON
    NickServ-             CLOAK: ON
    NickServ-          VERIFIED: YES


    And since yesterday I am on Libera as well.

    NickServ- Information on hrw (account hrw):
    NickServ- Registered : May 19 15:26:18 2021 +0000 (17h 32m 35s ago)
    NickServ- Last seen  : now
    NickServ- Flags      : HideMail, Private
    NickServ- *** End of Info ***

    What next?

    I saw and used several instant messaging platforms. All of them were younger than IRC. Many of them are no longer popular, several are no longer existing. IRC survived so I continue to use it.

    Written by Marcin Juszkiewicz on
  3. What ‘a new computer’ is?

    During last months I had several discussions about buying a new computer. Helped few friends with choosing setup etc. And several of them were surprised when I told that I never bought ‘a new computer’.

    8-bit era

    My first computer was Atari 65XE which my parents bought as a new computer. I learnt BASIC, tried few other programming languages (Forth anyone?) and played games. But it was not platform for long use.


    Two years later I earned money collecting berries in Swedish forests and bought my first computer — used Amiga 600. And two weeks later added 425MB hard disk inside. Nice improvement, still same 12” green monitor. More programming, less games. Demoscene watching started.

    Time passed, I sold A600 and bought used Amiga 1200 instead. Same hdd and monitor (also same mouse as I liked old one more). Then some CPU accelerator card, then another, new ATA controller, new hdd, used cd-rom drive and used 14” VGA mono monitor.

    AmigaOS was great operating system but platform was dying, hardware was expensive and slow, no new software.

    Let move to PC

    Year 2000 was moment when I decided to abandon AmigaOS and bought a PC. Which reused hdd, cd-rom and monitor. In some sense it was a new computer but still kept something from previous system. In next years some minor/major upgrades happened.

    In 2006 I switched architecture of my desktop system. From x86 to x86-64. In as cheap as possible way. It was time when embedded Linux was starting to not be “just a hobby”.

    Years passed, processors, mainboards, memory amount, storage, cases, expansion cards, monitors etc. were changing. But still there was no point of ‘ok, let me buy whole new computer’ as most of components were reused.

    Do laptops count?

    There were several laptops in meantime. One of them (Asus UL30A) was even brand new. But, contrary to other users, I use laptops only during travels — at home they usually sit connected to power and sometimes are used as headless build machine (as I tend to use different Linux distribution than my desktop there).


    And none of Arm systems I use count. I bought Sharp Zaurus SL-5500A (no longer own), Nokia N810 tablet and some small board computers like Wandboard (sold), Raspberry/Pi 3 (sold) or RockPro64. Android devices do not count either.


    Who knows, maybe one day I will buy a new computer. Whole one — case, mainboard, processor, memory, storage, graphics. Or something NUC like.

    Just there is nothing interesting so far to make such buy. Or I am not lazy enough to just buy whole workstation instead of building it on my own ;D

    Written by Marcin Juszkiewicz on
  4. Sometimes one tweet is enough

    Two weeks ago I wrote on Twitter:

    Is there some company with spare AArch64 CPU cycles?

    Opendev (project behind OpenStack and some more) would make use of another aarch64 server offer.

    Current one is iirc paid by @Arm, hosted by @equinixmetal and operated by @LinaroOrg.

    Why I did that? Maybe frustration, maybe burnout. Hard to tell. But I did. Without targeting any Arm related company as I did not wanted to force anyone to do anything.


    A few hours later I got an email from Peter Pouliot from Ampere Computing. With information that they provided hardware to Oregon State University Open Source Lab (OSUOSL in short) and that we may get nodes there.

    As I have no idea how exactly Opendev infrastructure works I added Kevin Zhao to the list. He is Linaro employee working on all instances of Linaro Developer Cloud and he maintained all AArch64 resources provided to Opendev.


    Kevin added Opendev infra admins: Clark Boylan and Ian Wienand. Peter added Lance Alberson from OSUOSL. I was just one of addresses in emails looking how things go.

    And it went nice. If was pleasure to read how it goes. Two days, 8 emails, arrangements were made. Then changes to Opendev infrastructure configuration followed and week later ‘linaro-us’ was not the only provider of AArch64 nodes.


    Opendev has two providers of AArch64 nodes now:

    • linaro-us-regionone
    • osuosl-regionone

    First one is paid by Arm Ltd, hosted at Equinix Metal (formerly Packet) and operated by Kevin Zhao from Linaro.

    Second one runs on Ampere provided hardware and is operated by OSUOSL admins.

    check-arm64’ pipeline on Opendev CI gets less clogged. And I hope that more and more projects will use it to test their code not only on x86-64 ;D

    Written by Marcin Juszkiewicz on
  5. Five years @linaro.org

    Five years ago I got an email from Kristine with “Linaro Assignee On-Boarding” title. Those were busy years.


    According to stackalytics I did 1144 reviews so far:

    OpenStack project Reviews
    kolla 641
    kolla-ansible 445
    releases 14
    nova 11
    loci 9
    requirements 7
    devstack 4
    tripleo-ci 3
    pbr 2
    magnum 2

    Those were different ones — from simple fixes to new features. Sometimes it was hard to convince projects that my idea makes sense. There were patches with over 50 revisions. Some needed split to smaller ones, reordering etc.

    And at the end AArch64 is just another architecture in OpenStack family. Linaro Developer Cloud managed to pass official certifications etc.


    Countless projects. From suggesting ‘can you publish aarch64 wheel’ to adding code to make it happen. Or work on getting manylinux2014 working properly.

    Linaro CI

    We have Jenkins setup at Linaro. With several build machines attached to it. And countless amount of jobs running there. I maintain several ones and my job is taking care and adding new ones when needed.


    Due to my work at Linaro Enterprise Group (renamed later at Linaro Datacenter & Cloud Group) I dealt with many AArch64 server systems. From HPe Moonshot to Huawei D06. With Qualcomm Falkor in meantime. Used CentOS 7/8 on them. Debian 9/10/11. Added needed config entries to Debian kernel to get them working out of the box (iirc excluding M400 cartridges no one maintained any more).


    I did “OpenStack on AArch64” talk at three conferences in a row. First Linaro Connect LAS16 (as group talk), then on Pingwinaria in Poland and finally in Kiev, Ukraine. Same slides, translated English -> Polish -> English and updated each time.

    Since then I do not give lectures at conferences any more. Prefer to attend someone’s talks. Or spend time on hallway discussions. Linaro Connect events were good place for them (and hope they will be in future too).

    At the end of each there was listing of every person who worked at Linaro for 5 or 10 years. Due to pandemic I missed that part. But hope for that memorial glass ;D

    Written by Marcin Juszkiewicz on
  6. Let’s play with some new stuff

    Two days ago Arm announced Arm v9 architecture. Finally we can discuss it in open instead saying “I prefer not to talk about this” (because NDA etc.).

    New things

    There are several new things in v9 version. SVE2, Spectre/Meltdown like mitigations, memory tagging, realms… And some of them are present in v8 already (mitigations are v8.5 IIRC).


    But how it goes work in hardware? There was no new cpu core announcements so we need to wait for Arm Neoverse N2 derived designs (as it will be v9).

    As usual mobile phones and tablets will get it first. Then probably Apple will put it into newer Macbooks. Decade later servers and workstations.

    And there are always those machines in labs. Packed with NDAs, access queues etc…

    $ uname -a
    Linux bach 5.11.0-73 #1 SMP Fri Mar 12 11:34:12 UTC 2021 aarch64 GNU/Linux
    $ head -n8 /proc/cpuinfo
    processor       : 0
    BogoMIPS        : 50.00
    Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp rme
                      asimdhp cpuid sb16 fp16 asimdrdm uafp jscvt fcma sb128 lrcpc
                      dcpop sha3 sm3 sm4 asimddp afd sha512 sve asimdfhm dit ilrcpc
                      rng flagm tme ssbs paca pacg sb dcpodp ac97 flagm2 frint mte
                      sve2 bf16 bti
    CPU implementer : 0x4a
    CPU architecture: 9
    CPU variant     : 0x0
    CPU part        : 0xf02
    CPU revision    : 0

    And sorry, no benchmarks allowed on not-mass-market hardware. The good part? It is still AArch64 so no recompilation required. Some software packages gets first set of SVE2 improvements soon.

    That was only a joke

    The truth is that even labs do not have such stuff. While most of features listed in output of /proc/cpuinfo exists in newer Arm v8 cores some of them were added there for fun:

    • afd (April Fools’ Day)
    • sb16 and sb128 (SoundBlaster 16/128)
    • ac97 (yet another sound device)
    • uafp (Use-After-Free Protection)


    I would like to thank a few people.

    Arnd Bergmann pointed out that two fields related to CPU are wrong:

    • implementer should be ASCII code (so I changed from 0xe3 to 0x4a (‘J’ as in Joke))
    • part field is just 12 bits (so changed from 0x1f02 to - 0xf02)

    Mark Brown spotted duplicated ‘rng’ feature. And Ryan Houdek who wrote about ‘tme’ feature.

    Written by Marcin Juszkiewicz on
  7. From a diary of AArch64 porter — manylinux2014

    Python wheels… Everyone loves them, many people curse when they are not available for their setup. I am in both groups every time I have to do something more complex with Python.

    So today I will show how to build Python wheel in quick way.

    What is manylinux?

    Linux world has a lot of distributions. Even more when you add their releases into the mix. And they ship different versions of Python. At same time we have Pypi which works as repository of ready to use Python packages.

    So manylinux idea was created to have minimal requirements for building Python packages. To make sure that you can install it on any distribution.

    So far there were several versions built:

    name base distribution PEP
    manylinux1 CentOS 5 PEP 513
    manylinux2010 CentOS 6 PEP 571
    manylinux2014 CentOS 7 PEP 599
    manylinux_2_24 Debian 9 ‘stretch’ PEP 600

    As you see old releases are used to make sure that resulting binaries work on any newer distribution. manylinux2014 added non-x86 architectures (aarch64, ppc64le, s390x).

    Each image contains several versions of Python binaries ready to use in /opt/python/ directory.

    Manylinux images are distributed as container images on pypa repository on quay.io. Run under Docker, Kubernetes, Podman etc.

    Source code is available in ‘manylinux’ repository on GitHub.

    Let’s use!

    My work requires me to build TensorFlow 1.5.15 version, which depends on NumPy 1.18.* version. None of them are available as wheels for AArch64 architecture.

    So let me run container and install NumPy dependencies:

    $ docker run -it -u root -v $PWD:/tmp/numpy quay.io/pypa/manylinux2014_aarch64
    [root@fa339493a417 /]# cd /tmp/numpy/
    [root@fa339493a417 /tmp/numpy/]# yum install -y blas-devel lapack-devel
    [root@fa339493a417 /tmp/numpy/]# 

    Image has several versions of Python installed and I want to build NumPy 1.18.5 for each of them so my build script is easy:

    for py in /opt/python/cp3[6789]*
        pyver=`basename $py`
        $py/bin/python -mvenv $pyver
        source $pyver/bin/activate
        pip wheel numpy==1.18.5

    Result is simple — I got set of wheel files. One per Python version. But it is not the end of work as NumPy libraries depend on blas/lapack we installed into system.

    add libraries to the wheel

    There is a tool we need to run: “auditwheel”. What it does is inspecting wheel file, all library symbols used, external libraries etc. Then it bundles required libraries into wheel file:

    INFO:auditwheel.main_repair:Repairing numpy-1.18.5-cp39-cp39-linux_aarch64.whl
    INFO:auditwheel.wheeltools:Previous filename tags: linux_aarch64
    INFO:auditwheel.wheeltools:New filename tags: manylinux2014_aarch64
    INFO:auditwheel.wheeltools:Previous WHEEL info tags: cp39-cp39-linux_aarch64
    INFO:auditwheel.wheeltools:New WHEEL info tags: cp39-cp39-manylinux2014_aarch64
    Fixed-up wheel written to /root/wheelhouse/numpy-1.18.5-cp39-cp39-manylinux2014_aarch64.whl

    File size changed from 13 467 772 to 16 806 338 bytes and resulting wheel can be installed on any distribution.

    Let summarise

    Manylinux is great tool to provide Python packages. It is easy to use on developer’s machine or on CI. And makes life of Python users much easier.

    Written by Marcin Juszkiewicz on
  8. U-Boot and generic distro boot

    Small board computers (SBC) usually come with U-Boot as firmware. There could be some more components like Arm Trusted Firmware, OPTEE etc but what user interact with is the U-Boot itself.

    Since 2016 there is the CONFIG_DISTRO_DEFAULTS option in U-Boot configuration. It selects defaults suitable for booting general purpose Linux distributions. Thanks to it board is able to boot most of OS installers out of the box without any user interaction.


    How does it know how to do that? There are several scripts and variables involved. Run “printenv” command in U-Boot shell and there you should see some of them named like “boot_*, bootcmd_* scan_dev_for_*”.

    In my example I would use environment from RockPro64 running U-Boot 2021.01 version.

    I will prettify all scripts for readability. Script contents may be expanded — in such case I will give name as a comment and then it’s content.

    Let’s boot

    First variable used by U-Boot is “bootcmd”. It reads it to know how to boot operating system on the board.

    In out case this variable has “run distro_bootcmd” in it. So what is there on RockPro64 SBC:

    setenv nvme_need_init
    for target in ${boot_targets}
        run bootcmd_${target}

    It says that on-board NVME needs some initialization and then goes through set of scripts using order from “boot_targets” variable. On RockPro64 this variable sets “mmc0 mmc1 nvme0 usb0 pxe dhcp sf0” order which means:

    • eMMC
    • MicroSD
    • NVME
    • USB storage
    • PXE
    • DHCP
    • SPI flash

    Both eMMC and MicroSD look similar: ‘devnum=X; run mmc_boot’ — set MMC number and then try to boot by running ‘mmc_boot’ script:

    if mmc dev ${devnum}; then 
        run scan_dev_for_boot_part; 

    NVME one initialize PCIe subsystem (via “boot_pci_enum”), then scans for NVME devices (via “nvme_init”) and do the similar stuff (here with expanded scripts):

    # boot_pci_enum
    pci enum
    # nvme_init
    if ${nvme_need_init}; then 
        setenv nvme_need_init false;
        nvme scan;
    if nvme dev ${devnum}; then 
        run scan_dev_for_boot_part; 

    USB booting goes with “usb_boot”:

    usb start;
    if usb dev ${devnum}; then 
        run scan_dev_for_boot_part;

    PXE network boot? Initialize USB, scan PCI, get network configuration, do PXE boot:

    # boot_net_usb_start
    usb start
    # boot_pci_enum
    pci enum
    if pxe get; then 
        pxe boot; 

    DHCP method feels like last resort one (do not ask me for meaning of all those variables):

    # boot_net_usb_start
    usb start
    # boot_pci_enum
    pci enum
    if dhcp ${scriptaddr} ${boot_script_dhcp}; then 
        source ${scriptaddr}; 
    setenv efi_fdtfile ${fdtfile}; 
    setenv efi_old_vci ${bootp_vci};
    setenv efi_old_arch ${bootp_arch};
    setenv bootp_vci PXEClient:Arch:00011:UNDI:003000;
    setenv bootp_arch 0xb;
    if dhcp ${kernel_addr_r}; then 
        tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};
        if fdt addr ${fdt_addr_r}; then 
            bootefi ${kernel_addr_r} ${fdt_addr_r}; 
            bootefi ${kernel_addr_r} ${fdtcontroladdr};
    setenv bootp_vci ${efi_old_vci};
    setenv bootp_arch ${efi_old_arch};
    setenv efi_fdtfile;
    setenv efi_old_arch;
    setenv efi_old_vci;

    And last method is SPI flash:

    if sf probe ${busnum}; then
        # run scan_sf_for_scripts; 
        ${devtype} read ${scriptaddr} ${script_offset_f} ${script_size_f}; 
        source ${scriptaddr}; 
        echo SCRIPT FAILED: continuing...

    Search for boot partition

    Note how block devices end with one script: “scan_dev_for_boot_part”. What it does is quite simple:

    part list ${devtype} ${devnum} -bootable devplist; 
    env exists devplist || setenv devplist 1; 
    for distro_bootpart in ${devplist}; do 
        if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then 
            run scan_dev_for_boot; 
    setenv devplist

    We know type and number of boot device from previous step so now we check for bootable partitions. Which means EFI System Partition for GPT disks and partitions marked as bootable in case of MBR. If none are present then first one is assumed to be bootable one.

    Search for distribution boot information

    Once we found boot partitions it is time to search for boot stuff with “scan_dev_for_boot” script:

    echo Scanning ${devtype} ${devnum}:${distro_bootpart}...;
    for prefix in ${boot_prefixes}; do 
        run scan_dev_for_extlinux; 
        run scan_dev_for_scripts; 
    run scan_dev_for_efi;

    Old style OS configuration

    First U-Boot checks for “extlinux/extlinux.conf” file, then go for old style “boot.scr” (in uimg and clear text formats). Both of them are checked in / and /boot/ directories of checked partition (those names are in “boot_prefixes” variable).

    Let us look at it:

    # scan_dev_for_extlinux
    if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf};then 
        echo Found ${prefix}${boot_syslinux_conf}; 
        # run boot_extlinux; 
        sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
        echo SCRIPT FAILED: continuing...; 
    # scan_dev_for_scripts
    for script in ${boot_scripts}; do 
        if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then 
            echo Found U-Boot script ${prefix}${script}; 
            # run boot_a_script; 
            load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; 
            source ${scriptaddr}
            echo SCRIPT FAILED: continuing...; 

    EFI compliant OS

    And finally U-Boot checks for EFI style BootOrder variables and generic OS loader path:

    # scan_dev_for_efi
    setenv efi_fdtfile ${fdtfile};
    for prefix in ${efi_dtb_prefixes}; do
        if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then 
            # run load_efi_dtb; 
            load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
    # run boot_efi_bootmgr;
    if fdt addr ${fdt_addr_r}; then 
        bootefi bootmgr ${fdt_addr_r};
        bootefi bootmgr;
    if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootaa64.efi; then
        echo Found EFI removable media binary efi/boot/bootaa64.efi; 
        # run boot_efi_binary; 
        load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; 
        if fdt addr ${fdt_addr_r}; then 
            bootefi ${kernel_addr_r} ${fdt_addr_r};
            bootefi ${kernel_addr_r} ${fdtcontroladdr};
        echo EFI LOAD FAILED: continuing...;
    setenv efi_fdtfile


    At this moment board should be in either OS or in OS loader (being EFI binary).

    Final words

    All that work on searching for boot media, boot scripts, boot configuration files, OS loaders, EFI BootOrder entries etc is done without any user interaction. Every bootable media is checked and tried.

    If I would add SATA controller support into U-Boot binary then all disks connected to such would also be checked. Without any code/environment changes from my side.

    So if your SBC has some weird setup then consider moving to distro generic one. Boot fresh mainline U-Boot, store copy of your existing environment (“printenv” shows it) and then reset to generic one with “env default -a” command. Probably would need to set MAC adresses for network interfaces.

    Written by Marcin Juszkiewicz on
Page 4 / 105