Marcin Juszkiewicz - fedorahttps://marcin.juszkiewicz.com.pl/2023-04-17T12:36:00+02:00“Ten” years at Linaro2023-04-17T12:36:00+02:002023-04-17T12:36:00+02:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2023-04-17:/2023/04/17/ten-years-at-linaro/Three + seven = ten. Right?<p>Some time ago was a day when I reached “ten” years at Linaro. Why “”? Because it
was 3 + 7 rather than 10 years straight. First three years as Canonical
contractor now seven years at Red Hat employee assigned as Member Engineer.</p>
<h3>My first three years at Linaro</h3>
<h4>NewCo or NewCore? Or Ubuntu on <span class="caps">ARM</span>?</h4>
<p>In 2010 I signed contract with Canonical as “Foundation <span class="caps">OS</span> Engineer”. Once there
I signed another paper which moved me to NewCo project (also called NewCore but
NewCo name is on paper I signed).</p>
<p>On 30th April 2010 I got “Welcome to Linaro” e-mail.</p>
<!--MORE-->
<p>Then <a href="/2010/05/14/uds-continues/"><span class="caps">UDS</span>-M happened</a> where we were hiding under
“Ubuntu on Arm” name (despite the fact that Ubuntu had such team).</p>
<h4>Ah, it is Linaro now :D</h4>
<p>On 3rd June 2010 <a href="https://www.linaro.org/news/arm-freescale-ibm-samsung-st-ericsson-and-texas-instruments-form-new-company-to-speed-the-rollout-of-linux-based-devices/">Linaro was officially announced</a>.
No more hiding, we went public with name.</p>
<h4>My team</h4>
<p>I became a part of Developer Platform team and worked mostly on toolchain
packages for Ubuntu and later Debian. There were funny moments at
sprints/summits/connects when I joked that I have two managers to listen to (one
from Toolchain Working Group and one from Developer Platform).</p>
<p>There were Debian/Ubuntu developers there and people from other environments.</p>
<p>At some moment it was renamed to “Base and Baselines”. Or “Bed and Breakfast” as
most of time “<span class="caps">BB</span>” was used instead of full name.</p>
<h4>AArch64 bring up</h4>
<p>In 2012 I dusted off my OpenEmbedded knowledge and started working on getting
AArch64 architecture bring up. Lot of not-yet-public patches was in use. The fun
of seeing “Hello world!” message in emulator printed by <span class="caps">OS</span> image I built from
scratch was something I hope to never forget.</p>
<p>Each time I am choosing mug for my coffee I see Pac-Man one I bought during
Linaro/Arm AArch64 sprint we had in October 2012.</p>
<figure id="__yafg-figure-1">
<img alt="My AArch64 mug" loading="lazy" src="/files/2023/04/IMG_20230417_140623-700x.jpg" title="My AArch64 mug">
<figcaption>My AArch64 mug</figcaption>
</figure>
<h4>The End</h4>
<p>There was lot of noise in 2011 about deal between Canonical and Linaro. Several
engineers at Linaro were from Canonical and there was some messy situation
related with money.</p>
<p>It ended with retiring of people every quarter. Some moved back to Canonical,
some changed job and got hired directly by Linaro. There were also people who
moved to Linaro member companies and stayed with their Linaro position. Some
people left both companies and went to other jobs.</p>
<p>I was supposed to <a href="/2012/10/26/so-long-and-thanks-for-all-the-fish/">leave Linaro in 2012</a>
but it was postponed by half a year. So <a href="/2013/05/31/my-time-at-linaro-is-over/">I left</a> after about 37 months.</p>
<h3>Second round</h3>
<p>Time passed, I was working at Red Hat on getting AArch64 first class citizen in
<span class="caps">RHEL</span> and Fedora Linux distributions. And one day my manager asked <a href="/2016/01/25/i-may-go-back-to-linaro/">do I want to
work at Linaro again</a>.</p>
<p>I did some research, discussed with friends at Linaro and on <a href="/2016/04/08/back-linaro-org/">8th April 2016 I
was back</a>.</p>
<h4>My team <span class="caps">II</span></h4>
<p>This time I became part of <span class="caps">LEG</span>: Linaro Enterprise Group. Servers, data centres
etc. There were several teams to choose and I ended in <span class="caps">SDI</span> (Software Defined
Infrastructure) one. We were behind <span class="caps">LDC</span> (Linaro Developer Cloud) project.</p>
<p>At some moment <span class="caps">LEG</span> became <span class="caps">LDCG</span> (Linaro Datacenter and Cloud Group). Some years
later <span class="caps">LDCG</span> lost “and Cloud” part as <span class="caps">AWS</span> and other cloud providers started
offering AArch64 systems so we did not had to deal with it any more.</p>
<h4>OpenStack all over</h4>
<p>First version of <span class="caps">LDC</span> was Debian based with OpenStack ‘liberty’. Then were weird
months when we had to reinvent deployment several times. It was mess most of time.</p>
<p>So we abandoned own solutions and went with OpenStack Kolla. I quickly became
one of core developers there. <span class="caps">LDC</span> moved to be container based.</p>
<p>In 2022 we ended working on OpenStack. <span class="caps">LDC</span> is now used only for internal projects.</p>
<h4>Building stuff</h4>
<p>With my “give me software and I will build it” mantra I ended also as kind of <span class="caps">CI</span>
jobs developer for <span class="caps">LEG</span> teams. Apache Bigtop, Apache Arrow, TensorFlow, <span class="caps">EDK2</span> and
several other projects. Some used containers, some were running shell scripts,
some Ansible.</p>
<h4><span class="caps">SBSA</span> Reference Platform</h4>
<p>I was involved in some work around getting <span class="caps">QEMU</span> to emulate <span class="caps">SBSA</span> Reference
Platform (“sbsa-ref” machine). Created some <span class="caps">CI</span> jobs to run test suites, build
firmware images etc. After running test suites I created a bunch of issues in
Jira so we can track how things go.</p>
<p>During recent months I became more involved. I am testing patches, running them
through both <span class="caps">SBSA</span> and <span class="caps">BSA</span> Arm Compliance Suites and reporting results.</p>
<p>I have own <a href="https://github.com/hrw/sbsa-ref-status">set of scripts</a> to handle
logs to make it easier to track how things are now.</p>
<h4>Summary</h4>
<p>At last Linaro Connect events there was always a moment when they announced
people who worked at Linaro for 5 (or later) 10 years. I have to admit — I felt
envy several times.</p>
<p>And when I was 5 years straight at Linaro we had <span class="caps">COVID</span>-19 pandemic so there was
no event.</p>Is Wayland really a future of desktop?2022-09-19T13:35:00+02:002022-09-19T13:35:00+02:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2022-09-19:/2022/09/19/is-wayland-really-a-future-of-desktop/For me it has a long way still ;(<p>Each time I update my Fedora desktop to new release (usually around Beta) I
give a try to Wayland. Which shows that I still use X11.</p>
<h3>My setup</h3>
<p>My desktop has Ryzen cpu and NVidia <span class="caps">GTX</span> 1050 Ti graphics card. Only one monitor
(34” 3440x1440). I use binary blobs as this generation of <span class="caps">GPU</span> chipset is not
really usable with <span class="caps">FOSS</span> driver (nouveau).</p>
<p>For desktop environment I use <span class="caps">KDE</span>. Which means Plasma desktop/panel, Konsole and
few <span class="caps">KDE</span> apps. Firefox and Chrome as web browsers, Thunderbird for mail, Steam
for gaming and Zoom (or Google Meet) for most of video calls.</p>
<!--MORE-->
<h3>Issues this time</h3>
<p>So what went wrong? Several things:</p>
<ul>
<li><span class="caps">KDE</span> decided that KEY_4 is the same as KEY_KP4. Too bad that I have separate
actions on them. Already <a href="https://bugs.kde.org/show_bug.cgi?id=453423">reported by someone
else</a>.</li>
<li>Zoom does not even want to cooperate — opens window for a moment and quits.
There is <a href="https://community.zoom.com/t5/Meetings/Linux-Regarding-Nvidia-Xwayland-Wayland/m-p/72922">a discussion in Zoom forum</a> for this.</li>
<li>Google Meet in Chrome listed only 3 windows when I tried to share a window and
there was no way to share whole screen (got black screen instead). XWayland related?</li>
<li><span class="caps">MPV</span> movie player refused to use any hardware accelerated output.</li>
<li>Factorio game at first worked in 60 fps. But then I loaded bigger base and it
went down to 1.3 fps (while it is around 60 fps under X11).</li>
</ul>
<p>Did not tested other games — have far too much time spent in Factorio and
plan to finally do last achievement there.</p>
<p>Would love to be able to get rid of video meetings but they are part of remote
work. Having to switch whole desktop session just to addend a meeting feels weird.</p>
<h3>Things which went fine</h3>
<p>I would like to list several things which went fine compared to my previous
attempts. The only one visible one was that font sizes are finally more
consistent with X11 session. They are not the same size in pixels but year ago
they were much bigger under Wayland.</p>
<h3>Maybe next time</h3>
<p>I will give another try in 6 months — after upgrade to Fedora 38 Beta.</p>U-Boot and generic distro boot2021-03-14T10:14:00+01:002021-03-14T10:14:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2021-03-14:/2021/03/14/u-boot-and-generic-distro-boot/U-Boot can boot distro installer out of box<p>Small board computers (<span class="caps">SBC</span>) usually come with U-Boot as firmware. There could be
some more components like Arm Trusted Firmware, <span class="caps">OPTEE</span> etc but what user interact
with is the U-Boot itself.</p>
<p>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 <span class="caps">OS</span> installers out of the box without
any user interaction.</p>
<h3>How?</h3>
<p>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_*”.</p>
<p>In my example I would use environment from RockPro64 running U-Boot 2021.01 version.</p>
<p>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.</p>
<h3>Let’s boot</h3>
<p>First variable used by U-Boot is “bootcmd”. It reads it to know how to boot
operating system on the board.</p>
<p>In out case this variable has “run distro_bootcmd” in it. So what is there on
RockPro64 <span class="caps">SBC</span>:</p>
<pre><code>setenv nvme_need_init
for target in ${boot_targets}
do
run bootcmd_${target}
done
</code></pre>
<p>It says that on-board <span class="caps">NVME</span> 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:</p>
<ul>
<li>eMMC</li>
<li>MicroSD</li>
<li><span class="caps">NVME</span></li>
<li><span class="caps">USB</span> storage</li>
<li><span class="caps">PXE</span></li>
<li><span class="caps">DHCP</span></li>
<li><span class="caps">SPI</span> flash</li>
</ul>
<p>Both eMMC and MicroSD look similar: ‘devnum=X; run mmc_boot’ — set <span class="caps">MMC</span> number
and then try to boot by running ‘mmc_boot’ script:</p>
<pre><code>if mmc dev ${devnum}; then
devtype=mmc;
run scan_dev_for_boot_part;
fi
</code></pre>
<p><span class="caps">NVME</span> one initialize PCIe subsystem (via “boot_pci_enum”), then scans for <span class="caps">NVME</span>
devices (via “nvme_init”) and do the similar stuff (here with expanded scripts):</p>
<pre><code># boot_pci_enum
pci enum
# nvme_init
if ${nvme_need_init}; then
setenv nvme_need_init false;
nvme scan;
fi
if nvme dev ${devnum}; then
devtype=nvme;
run scan_dev_for_boot_part;
fi
</code></pre>
<p><span class="caps">USB</span> booting goes with “usb_boot”:</p>
<pre><code>usb start;
if usb dev ${devnum}; then
devtype=usb;
run scan_dev_for_boot_part;
fi
</code></pre>
<p><span class="caps">PXE</span> network boot? Initialize <span class="caps">USB</span>, scan <span class="caps">PCI</span>, get network configuration, do <span class="caps">PXE</span> boot:</p>
<pre><code># boot_net_usb_start
usb start
# boot_pci_enum
pci enum
dhcp;
if pxe get; then
pxe boot;
fi
</code></pre>
<p><span class="caps">DHCP</span> method feels like last resort one (do not ask me for meaning of all those variables):</p>
<pre><code># boot_net_usb_start
usb start
# boot_pci_enum
pci enum
if dhcp ${scriptaddr} ${boot_script_dhcp}; then
source ${scriptaddr};
fi;
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};
else
bootefi ${kernel_addr_r} ${fdtcontroladdr};
fi;
fi;
setenv bootp_vci ${efi_old_vci};
setenv bootp_arch ${efi_old_arch};
setenv efi_fdtfile;
setenv efi_old_arch;
setenv efi_old_vci;
</code></pre>
<p>And last method is <span class="caps">SPI</span> flash:</p>
<pre><code>busnum=0
if sf probe ${busnum}; then
devtype=sf;
# run scan_sf_for_scripts;
${devtype} read ${scriptaddr} ${script_offset_f} ${script_size_f};
source ${scriptaddr};
echo SCRIPT FAILED: continuing...
fi
</code></pre>
<h3>Search for boot partition</h3>
<p>Note how block devices end with one script: “scan_dev_for_boot_part”. What it
does is quite simple:</p>
<pre><code>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;
fi;
done;
setenv devplist
</code></pre>
<p>We know type and number of boot device from previous step so now we check for
bootable partitions. Which means <span class="caps">EFI</span> System Partition for <span class="caps">GPT</span> disks and
partitions marked as bootable in case of <span class="caps">MBR</span>. If none are present then first one
is assumed to be bootable one.</p>
<h3>Search for distribution boot information</h3>
<p>Once we found boot partitions it is time to search for boot stuff with
“scan_dev_for_boot” script:</p>
<pre><code>echo Scanning ${devtype} ${devnum}:${distro_bootpart}...;
for prefix in ${boot_prefixes}; do
run scan_dev_for_extlinux;
run scan_dev_for_scripts;
done;
run scan_dev_for_efi;
</code></pre>
<h4>Old style <span class="caps">OS</span> configuration</h4>
<p>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).</p>
<p>Let us look at it:</p>
<pre><code># 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...;
fi
# 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...;
fi;
done
</code></pre>
<h4><span class="caps">EFI</span> compliant <span class="caps">OS</span></h4>
<p>And finally U-Boot checks for <span class="caps">EFI</span> style BootOrder variables and generic <span class="caps">OS</span> loader path:</p>
<pre><code># 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}
fi;
done;
# run boot_efi_bootmgr;
if fdt addr ${fdt_addr_r}; then
bootefi bootmgr ${fdt_addr_r};
else
bootefi bootmgr;
fi
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};
else
bootefi ${kernel_addr_r} ${fdtcontroladdr};
fi
echo EFI LOAD FAILED: continuing...;
fi;
setenv efi_fdtfile
</code></pre>
<h3>Booted</h3>
<p>At this moment board should be in either <span class="caps">OS</span> or in <span class="caps">OS</span> loader (being <span class="caps">EFI</span> binary).</p>
<h3>Final words</h3>
<p>All that work on searching for boot media, boot scripts, boot configuration
files, <span class="caps">OS</span> loaders, <span class="caps">EFI</span> BootOrder entries etc is done without any user
interaction. Every bootable media is checked and tried.</p>
<p>If I would add <span class="caps">SATA</span> controller support into U-Boot binary then all disks
connected to such would also be checked. Without any code/environment changes
from my side.</p>
<p>So if your <span class="caps">SBC</span> 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 <span class="caps">MAC</span> adresses for network interfaces.</p>I got HoneyComb2021-02-18T19:09:00+01:002021-02-18T19:09:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2021-02-18:/2021/02/18/i-got-honeycomb/Finally some hardware with (almost) <span class="caps">SBSA</span>/<span class="caps">SBBR</span> compliance!<p>Few years ago SolidRun released <a href="https://shop.solid-run.com/product/SRM8040S00D04GE008D00CH/">MACCHIATObin</a> board. Nice fast cpu, <span class="caps">PCI</span> Express
slot, several network ports. I did not buy it because it supported only 16 <span class="caps">GB</span>
of memory and I wanted to be able to run OpenStack.</p>
<p>Time has passed, <a href="https://shop.solid-run.com/product/SRLX216S00D00GE064H08CH/">HoneyComb <span class="caps">LX2</span>
system</a> appeared on
AArch64 market. More cores, more memory. Again I haven’t bought it — my Ryzen
5 upgrade costed less than HoneyComb price is.</p>
<p>And when someone asked me for some serious AArch64 system to buy I was
suggesting HoneyComb.</p>
<h3>Let us look at hardware</h3>
<p>So what do we have here?</p>
<ul>
<li>16 Cortex-A72 cores</li>
<li>2 <span class="caps">SO</span>-<span class="caps">DIMM</span> slots (up to <span class="caps">64GB</span> ram in total)</li>
<li><span class="caps">USB</span> 2.0 and 3.0 ports (as ports and/or headers)</li>
<li>standard <span class="caps">ATX</span> power socket (no 12V <span class="caps">AUX</span> needed)</li>
<li>3 fan connectors (one with <span class="caps">PWM</span>, two with 12V)</li>
<li>front panel connectors like on x86-64 motherboards</li>
<li>M.2 slot for <span class="caps">NVME</span> (pcie x4)</li>
<li><span class="caps">PCI</span> Express slot (open x8 one so x16 card fits)</li>
<li>MicroSD slot (for firmware)</li>
<li>4 <span class="caps">SFP</span>+ ports for 10GbE networking</li>
<li>1 GbE port</li>
<li>4 <span class="caps">SATA</span> ports</li>
<li>serial console via microUSB port</li>
<li>power/reset buttons</li>
</ul>
<figure id="__yafg-figure-1">
<img alt="HoneyComb board layout" loading="lazy" src="/files/2021/02/honeycomb-layout.webp" title="HoneyComb board layout">
<figcaption>HoneyComb board layout</figcaption>
</figure>
<p>Lot of networking and there is even version with 100GbE port added: <a href="https://shop.solid-run.com/product/SRLX216S00D00GE064C08CH/">ClearFog
<span class="caps">CX</span> <span class="caps">LX2</span></a>.</p>
<h3>So how I got it?</h3>
<p>I wrote that I did not bought it, right? Jon Nettleton (from SolidRun) contacted
me recently and asked:</p>
<blockquote>
<p>Morning. do you have any interest in a HoneyComb? I have some old stock
boards available to the community. I figured it may help you out with your
<span class="caps">UEFI</span> Qemu work.</p>
</blockquote>
<p>We discussed about <span class="caps">SBSA</span>/<span class="caps">SBBR</span> stuff and I sent him an email with address
information and shipping notes.</p>
<p>Some days passed and board arrived. I added spare <span class="caps">NVME</span> and two sticks of Kingston
HyperX 2933 <span class="caps">CL17</span> memory and it was ready to go (microsd card keeps firmware):</p>
<figure id="__yafg-figure-2">
<img alt="HoneyComb board ready to go" loading="lazy" src="/files/2021/02/honeycomb-ram-nvme.webp" title="HoneyComb board ready to go">
<figcaption>HoneyComb board ready to go</figcaption>
</figure>
<h3>Let’s run something</h3>
<p>Debian ‘bullseye’ booted right away. Again I used pendrive from my <span class="caps">EBBR</span>
compliant RockPro64. Started without problems.</p>
<h4>Network ports issue</h4>
<p>Ok, there was one problem — on-board ethernet ports do not work yet with
mainline nor distribution kernels so I had to dig out my old <span class="caps">USB</span> based network card.</p>
<p>There are patches for Linux kernel to get all ports running. May get merged into
5.13 kernel if things go nicely.</p>
<h3>Plans?</h3>
<p>I plan few things for HoneyComb:</p>
<ul>
<li>check several distributions how they handle AArch64 systems</li>
<li>improve <span class="caps">SBSA</span> <span class="caps">ACS</span> code as HoneyComb is almost <span class="caps">SBSA</span> level 3 compliant (there are
some places where error/warning messages break output)</li>
<li>build, deploy and test OpenStack</li>
<li>test software</li>
<li>check how it works as AArch64 desktop (like I did with <span class="caps">APM</span> Mustang 6 years ago)</li>
</ul>EBBR on EspressoBin2021-02-15T21:53:00+01:002021-02-15T21:53:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2021-02-15:/2021/02/15/ebbr-on-espressobin/Takes some time but EspressoBin can be <span class="caps">EBBR</span> too.<blockquote>
<p><span class="caps">SBBR</span> or <span class="caps">GTFO</span></p>
<p>Me.</p>
</blockquote>
<p>Yeah, right. But world is not so nice and there are many cheap <span class="caps">SBC</span> on market
which are not <span class="caps">SBBR</span> compliant and probably never will. And with small amount of
work they can do <span class="caps">EBBR</span> (<a href="https://github.com/ARM-software/ebbr/">Embedded Base Boot Requirements</a>).</p>
<p><span class="caps">NOTE</span>: I have similar post about <a href="/2020/06/17/ebbr-on-rockpro64/"><span class="caps">EBBR</span> on RockPro64 board</a>.</p>
<h3><span class="caps">WTH</span> is <span class="caps">EBBR</span>?</h3>
<p>It is specification for devices which are not servers and do not pretend to be
such. U-Boot is all they have and with properly configured one they have some
subset of <span class="caps">EFI</span> Boot/Runtime Services to load distribution bootloader (grub-efi
usually) like it is done on servers.</p>
<p><span class="caps">ACPI</span> is not required but may be present. DeviceTree is perfectly fine. You may
provide both or one of them.</p>
<p>Firmware can be stored wherever you wish. Even <span class="caps">MBR</span> partitioning is available if
really needed.</p>
<h3>Few words about board itself</h3>
<p>EspressoBin has <span class="caps">4MB</span> of <span class="caps">SPI</span> flash on board. Less than on RockPro64 but still
enough for storing firmware (U-Boot takes less than <span class="caps">1MB</span>).</p>
<p>This <span class="caps">SBC</span> is nothing new — first version was released in 2016. There were
several revisions with different memory type, amount of ram chips, type of them
(ddr3 or ddr4), <span class="caps">CPU</span> speed and some more changes.</p>
<p>I got EspressoBin revision 5 with <span class="caps">1GB</span> ram of ddr3 in 2 chips. And 1GHz processor.</p>
<p>It may sound silly that I repeat that information but it matters when you start
building firmware for that board.</p>
<h3>So let us build fresh firmware</h3>
<p>This is Marvell so abandon all hope for sanity.</p>
<p>Thanks to Arm Trusted Firmware authors there is <a href="https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html">good documentation on how to
build firmware for EspressoBin</a>
which guides step by step and explains all arguments you need. For me it was
several <code>git clone</code> calls and then two <code>make</code> calls:</p>
<pre><code>make -C u-boot CROSS_COMPILE=aarch64-linux-gnu- \
mvebu_espressobin-88f3720_defconfig u-boot.bin -j12
make -C trusted-firmware-a CROSS_COMPILE=aarch64-linux-gnu- \
CROSS_CM3=arm-none-linux-gnueabihf- PLAT=a3700 \
CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 \
MV_DDR_PATH=$PWD/marvell/mv-ddr-marvell/ \
WTP=$PWD/marvell/A3700-utils-marvell/ \
CRYPTOPP_PATH=$PWD/marvell/cryptopp/ \
BL33=$PWD/u-boot/u-boot.bin \
mrvl_flash -j12
</code></pre>
<p>And I had to install cross toolchain for 32-bit arm because the one I had was
for building kernels/bootloaders only.</p>
<h3>Is your U-Boot friendly or not?</h3>
<p>First you need to check which version of U-Boot and hardware you have. Then
check does it recognize <span class="caps">SPI</span> flash or not:</p>
<pre><code>Marvell>> sf probe
SF: unrecognized JEDEC id bytes: 9d, 70, 16
Failed to initialize SPI flash at 0:0 (error -2)
</code></pre>
<p>I had bad luck as my board used <span class="caps">SPI</span> chip not recognized by any official U-Boot build…</p>
<h3>Armbian to the rescue</h3>
<p>I asked in few places did anyone had some experiences with this board. One of
them was #debian-arm <span class="caps">IRC</span> channel where I got hint from Xogium that Armbian may
have U-Boot builds.</p>
<p>And they have <a href="https://www.armbian.com/espressobin/">whole page about EspressoBin</a>.
With information how to choose firmware files etc.</p>
<p>So I downloaded archive with proper files for <a href="http://wiki.espressobin.net/tiki-index.php?page=Bootloader+recovery+via+UART"><span class="caps">UART</span> recovery</a>.
The important thing to remember is that once you move jumpers and load all
firmware files over serial they are not written in <span class="caps">SPI</span> flash so reset of board
means you start over.</p>
<p>Quick check is <span class="caps">SPI</span> flash detected:</p>
<pre><code>Marvell>> sf probe
SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
</code></pre>
<p>Yeah! Now can start <span class="caps">USB</span> and flash own firmware build:</p>
<pre><code>Marvell>> bubt flash-image.bin spi usb
Burning U-Boot image "flash-image.bin" from "usb" to "spi"
Bus usb@58000: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@5e000: USB EHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb@5e000 for devices... 2 USB Device(s) found
Image checksum...OK!
SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
Erasing 991232 bytes (242 blocks) at offset 0 ...Done!
Writing 990944 bytes from 0x6000000 to offset 0 ...Done!
</code></pre>
<p>Quick reset and board boots to fresh, mainline U-Boot:</p>
<pre><code>TIM-1.0
WTMI-devel-18.12.1-1a13f2f
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.108V
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL1: Built : 17:11:19, Feb 15 2021
NOTICE: BL1: Booting BL2
NOTICE: BL2: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL2: Built : 17:11:20, Feb 15 2021
NOTICE: BL1: Booting BL31
NOTICE: BL31: v2.4(release):v2.4-345-g04c122310 (Marvell-devel-18.12.2)
NOTICE: BL31: Built : 18:07:02, Feb 15 2021
U-Boot 2021.01 (Feb 15 2021 - 19:25:41 +0100)
DRAM: 1 GiB
Comphy-0: USB3_HOST0 5 Gbps
Comphy-1: PEX0 2.5 Gbps
Comphy-2: SATA0 5 Gbps
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC: sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected is25wp032 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Card did not respond to voltage select! : -110
Net: eth0: neta@30000
Hit any key to stop autoboot: 0
</code></pre>
<h3>Final steps</h3>
<p><span class="caps">OK</span>, so <span class="caps">SBC</span> has fresh, mainline firmware. Nice. But still some stuff needs to be done.</p>
<p>First note <span class="caps">MAC</span> addresses of Ethernet ports. Use <code>printenv</code> command to check
stored environment and note few variables:</p>
<pre><code>eth1addr=f0:ad:4b:aa:97:01
eth2addr=f0:ad:4b:aa:97:02
eth3addr=f0:ad:4b:aa:97:03
ethaddr=f0:ad:4e:72:10:ef
</code></pre>
<p>Of course you may also skip that step and rely on random ones or choose own ones
(I had router with C0:<span class="caps">FF</span>:<span class="caps">EE</span>:C0:<span class="caps">FF</span>:<span class="caps">EE</span> in past).</p>
<p>Then reset environment to default values stored in U-Boot binary and set those
<span class="caps">MAC</span> addresses by hand:</p>
<pre><code>=> env default -a -f
=> setenv eth1addr f0:ad:4b:aa:97:01
=> setenv eth2addr f0:ad:4b:aa:97:02
=> setenv eth3addr f0:ad:4b:aa:97:03
=> setenv ethaddr f0:ad:4e:72:10:ef
=> saveenv
Saving Environment to SPIFlash... Erasing SPI flash...Writing to SPI flash...done
OK
=>
</code></pre>
<h3>What <span class="caps">EBBR</span> brings?</h3>
<p>Now your board is ready to boot Debian, Fedora and several other distribution
install media with two commands:</p>
<pre><code>=> set boot_targets usb0
=> boot
</code></pre>
<p>It will find <span class="caps">EFI</span> bootloader and start it. Just like on any other boring
<span class="caps">SBBR</span>/<span class="caps">EBBR</span> system.</p>
<p>Distributions with old style ‘boot.scr’ script (like OpenWRT for example) will
also work so no functionality loss.</p>FOSDEM 2021 was the best online event ever2021-02-08T10:53:00+01:002021-02-08T10:53:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2021-02-08:/2021/02/08/fosdem-2021-was-the-best-online-event-ever/33 thousands of attendees on online conference. Only <span class="caps">FOSDEM</span> makes it possible.<p>My family got used to the fact that I am not available at beginning of February.
Because of my <span class="caps">FOSDEM</span> trip. This year was not both not so different and different
at same time.</p>
<p>Due to <span class="caps">COVID</span>-19 pandemic <span class="caps">FOSDEM</span> 2021 was online. So there was no reason for any
trip other than to local shops to buy some Belgian beers. And I was not
available to anyone during weekend.</p>
<h3>Online? It will be terrible!</h3>
<p>During 2020 I attended several online events. For some of them I prefer to not
remember that I did it. Terrible recordings of talk, some had bandwidth issues.
On some organizers did not managed to get presenters agree on online presence so
some meetings had to be dropped when they were supposed to start.</p>
<h3>Matrix to the rescue</h3>
<p><span class="caps">FOSDEM</span> team decided to organize some way for attendees to chat with each other.
Matrix was setup on chat.fosdem.org with some rooms for basic <span class="caps">FOSDEM</span> stuff, room
for each devroom, rooms for continuing discussion after talk… There was also
“Virtual Janson Bar” one for food/drink discussions (renamed to “Virtual
Delirium” for after conference hours).</p>
<p>Cloakroom had own channel, food trucks had another one. People were sending
photos of their food/waffles/beer/etc.</p>
<blockquote>
<p><a href="https://twitter.com/fosdem/status/1358441632027312129"><span class="caps">FOSDEM</span> @fosdem tweeted</a>:</p>
<p>Oh and before you leave don’t forget to pickup your luggage and coat at the
cloackroom https://chat.fosdem.org/#/room/#cloakroom:fosdem.org 🙃</p>
</blockquote>
<p>Nearly every room had widget with Jitsi for video chat. It was used mostly
for Q&A sessions and after talk discussions.</p>
<p>And it worked good. There were hot discussions with questions asked during talk
and then replied during Q&A session. Links to many projects and interesting
additional pages were posted that way.</p>
<h3>Streaming all the way</h3>
<p>One of things <span class="caps">FOSDEM</span> is famous for is networking at event. And live streaming of
all rooms. This year was no different. My monitor’s screen was split to two
Firefox windows: left side kept discussions on Matrix server, right side had
live streaming schedule and video of currently attended talk. At same time my
phone has “<span class="caps">FOSDEM</span> Companion” app started with bookmarks opened to make it easy
to check which talks I wanted to see.</p>
<p>At some moments I had two videos started — one waited for start of presentation
and second with some other talk running. Once new one started I closed watched
one. Simple method of watching part of talk to see is it interesting or not.</p>
<p>There were some talks where I dropped during first few minutes and moved to
other one. Something quite hard to do when you are in a middle of a room at
normal <span class="caps">FOSDEM</span>.</p>
<p>Videos of talks will be available during next few days. I have a page with
<a href="/fosdem/2021.html"><span class="caps">FOSDEM</span> talks with slides/video links</a> which will get updates
during next days.</p>
<h3>At same time at <span class="caps">ULB</span>…</h3>
<p>Normally <span class="caps">FOSDEM</span> takes place in Brussels at <span class="caps">ULB</span>. There were some attendees there
so we had messages like that on Matrix:</p>
<blockquote>
<p>I went to tram and is was nearly empty. Did I messed timezones or what?</p>
</blockquote>
<p>I got permission from Luilegeant to post some pictures from <span class="caps">ULB</span> so you may see
what we missed this year:</p>
<figure id="__yafg-figure-1">
<img alt="FOSDEM 2021" loading="lazy" src="/files/2021/02/IMG_4378-700x.jpg" title="FOSDEM 2021">
<figcaption><span class="caps">FOSDEM</span> 2021</figcaption>
</figure>
<figure id="__yafg-figure-2">
<img alt="Entry to J building" loading="lazy" src="/files/2021/02/IMG_4375-700x.jpg" title="Entry to J building">
<figcaption>Entry to J building</figcaption>
</figure>
<figure id="__yafg-figure-3">
<img alt="Janson bar was closed" loading="lazy" src="/files/2021/02/IMG_4377-700x.jpg" title="Janson bar was closed">
<figcaption>Janson bar was closed</figcaption>
</figure>
<figure id="__yafg-figure-4">
<img alt="crane instead of food trucks" loading="lazy" src="/files/2021/02/IMG_4379-700x.jpg" title="crane instead of food trucks">
<figcaption>crane instead of food trucks</figcaption>
</figure>
<p>Looks like typical <span class="caps">FOSDEM</span> weather ;D</p>
<h3>Some final words</h3>
<p>I enjoyed <span class="caps">FOSDEM</span> 2021. It was different that usual ones but adding Matrix for
chat allowed to get that feeling of being with other attendees. I hope that
online events in 2021 will copy it.</p>
<blockquote>
<p><a href="https://twitter.com/_ShinIce/status/1358461185537044488">Shin Ice @_ShinIce tweeted</a></p>
<p>#<span class="caps">FOSDEM21</span> is coming to an end and it was awesome as always 🤘 </p>
<p>we have an estimation of ~33.6k attendees for the conference and ~20k
attendees for today…impressive…and now take this numbers and try to fill
the <span class="caps">ULB</span> 😱</p>
</blockquote>
<p>Compare that with usual 8-9 thousands in previous years.</p>
<p>There were many people from other continents taking part in conference just
because being online allowed them. For several of them it was night time all the time.</p>
<p>See you at <span class="caps">ULB</span> in 2022!</p>Standards are boring2021-01-20T17:33:00+01:002021-01-20T17:33:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2021-01-20:/2021/01/20/standards-are-boring/Your Arm board can be compliant too.<blockquote>
<p>We have made Arm servers boring.</p>
<p>Jon Masters</p>
</blockquote>
<p>Standards are boring. Satisfied users may not want to migrate to other boards
the market tries to sell them.</p>
<p>So Arm market is flooded with piles of small board computers (<span class="caps">SBC</span>). Often they
are compliant to standards only when it comes to connectors.</p>
<h3>But our hardware is not standard</h3>
<p>It is not a matter of ‘let produce <span class="caps">UEFI</span> ready hardware’ but rather ‘let write
<span class="caps">EDK2</span> firmware for boards we already have’.</p>
<p>Look at Raspberry/Pi then. It is shitty hardware but got popular. And group of
people wrote <span class="caps">UEFI</span> firmware for it. Probably without vendor support even.</p>
<h3>Start with <span class="caps">EBBR</span></h3>
<p>Each new board should be <span class="caps">EBBR</span> compliant at start. Which is easy — do ‘whatever
hardware’ and put properly configured U-Boot on it. Upstreaming support for your
small device should not be hard as you often base on some already existing hardware.</p>
<p>Add <span class="caps">16MB</span> of <span class="caps">SPI</span> flash to store firmware. Your users will be able to boot <span class="caps">ISO</span>
without wondering where on boot media they need to write bootloaders.</p>
<p>Then work on <span class="caps">EDK2</span> for board. Do <span class="caps">SMBIOS</span> (easy) and keep your existing Device
Tree. You are still <span class="caps">EBBR</span>. Remember about upstreaming your work — some people
will complain, some will improve your code.</p>
<h3>Add <span class="caps">ACPI</span>, go <span class="caps">SBBR</span></h3>
<p>Next step is moving from Device Tree to <span class="caps">ACPI</span>. May take some time to understand
why there are so many tables and what <span class="caps">ASL</span> is. But as several other systems show
it can be done.</p>
<p>And this brings you to <span class="caps">SBBR</span> compliance. Or SystemReady <span class="caps">ES</span> if you like marketing.</p>
<h3><span class="caps">SBSA</span> for future design</h3>
<p>Doing new SoC tends to be “let us take previous one and improve a bit”. So this
time change it a bit and make your next SoC compliant with <span class="caps">SBSA</span> level 3. All
needed components are probably already included in your Arm license.</p>
<p>Grab <span class="caps">EDK2</span> support you did for previous board. Look at <span class="caps">QEMU</span> <span class="caps">SBSA</span> Reference
Platform support, look at other <span class="caps">SBSA</span> compliant hardware. Copy, reuse their
drivers, their code.</p>
<h3>Was it worth?</h3>
<p>At the end you will have <span class="caps">SBSA</span> compliant hardware running <span class="caps">SBBR</span> compliant firmware. </p>
<p>Congratulations, your board is SystemReady <span class="caps">SR</span> compliant. Your marketing team may
write that you are on same list as Ampere with their Altra server.</p>
<p>Users buy your hardware and can install whatever <span class="caps">BSD</span>, Linux distribution they
want. Some will experiment with Microsoft Windows. Others may work on porting
Haiku or other exotic operating system. </p>
<p>But none of them will have to think “how to get this shit running”. And they
will tell friends that your device is as boring as it should be when it comes to
running <span class="caps">OS</span> on it == more sales.</p>So long, and thanks for all the fun2020-12-10T12:33:00+01:002020-12-10T12:33:00+01:00Marcin Juszkiewicztag:marcin.juszkiewicz.com.pl,2020-12-10:/2020/12/10/so-long-and-thanks-for-all-the-fun/My Mustang is no more.<p>During last days I tried to get my Applied Micro Mustang running again. And it
looks like it is no more. Like that Norwegian Blue parrot.</p>
<h3>Tried some things</h3>
<p>By default Mustang outputs information on serial console. It does not here.
Checked serial cables, serial to usb dongles. Nothing.</p>
<p>Tried to <a href="/2015/11/18/unbricking-apm-mustang/">load firmware from <span class="caps">SD</span> card</a>
instead of on-board flash. Nope.</p>
<p>Time to put it to rest.</p>
<h3>How it looked</h3>
<p>When <a href="/2014/06/10/aarch64-is-in-the-house/">I got it in June 2014</a> it came in 1U
server case. With several loud fans. Including one on cpu radiator. So I took
the board out and put into <span class="caps">PC</span> Tower case. Also replaced 50mm processor fan with
80mm one:</p>
<figure id="__yafg-figure-1">
<img alt="Top view of Mustang" loading="lazy" src="/files/2020/12/IMG_20201210_220604-700x.jpg" title="Top view of Mustang">
<figcaption>Top view of Mustang</figcaption>
</figure>
<figure id="__yafg-figure-2">
<img alt="Side view" loading="lazy" src="/files/2020/12/IMG_20201210_220612-700x.jpg" title="Side view">
<figcaption>Side view</figcaption>
</figure>
<h3>All that development…</h3>
<p>I did several things on it:</p>
<ul>
<li><a href="/2014/10/30/usb-on-mustang/">tested <span class="caps">USB</span> support</a></li>
<li>tested <span class="caps">PCI</span> Express support</li>
<li><a href="/2015/01/14/started-x11-on-aarch64-hardware-this-time/">run X11 on hardware</a></li>
<li><a href="/2015/09/11/how-to-get-xserver-running-out-of-box-on-aarch64/">debugged why X11 does not start out of the box</a></li>
<li><a href="/2015/11/18/unbricking-apm-mustang/">wrote new instruction how to unbrick it</a></li>
<li>run 64 and 32-bit virtual machines</li>
<li>used it as a desktop (<a href="/2015/09/21/aarch64-desktop-day-one/">day 1</a>, <a href="/2015/09/22/aarch64-desktop-day-two/">day 2</a>, <a href="/2015/09/25/aarch64-desktop-last-day/">last day</a>)</li>
<li>tested OpenStack</li>
</ul>
<p>Some of them were done for first time on AArch64.</p>
<p>Board gave me lot of fun. I built countless software packages on it. For CentOS,
Debian, Fedora, <span class="caps">RHEL</span>. Tested installers of each of them.</p>
<p>Was running OpenStack on it since ‘liberty’ (especially after moving from <span class="caps">16GB</span>
to <span class="caps">32GB</span> ram).</p>
<h3>What next?</h3>
<p>I am going to frame it. With few other devices which helped me during
<a href="/2020/02/11/my-whole-career-is-built-on-foss/">my career</a>.</p>
<h3>Replacement?</h3>
<p>It would be nice to replace Mustang with some newer AArch64 hardware. From what
is available on mass market SolidRun HoneyComb looks closest. But I will wait
for something with Armv8.4 cores to be able to play with nested virtualization.</p>
<p><strong><span class="caps">UPDATE</span>:</strong> I got it working again.</p>