Dropped AAAA record from DNS

I host my blog on small machine somewhere in OVH. As part of package I got IPv6 address for it. Five minutes ago I decided to no longer use it.

My home Internet provider (UPC) does not offer IPv6 addresses so testing is my blog (or other pages/services I host) reachable via IPv6 was always problematic. Ok, I have sixxs.net tunnel setup on one of routers at home but it is not fun when your browser (and other tools) decide to use IPv6 instead of IPv4 and slow down from 250/20 Mbps to tunnel speed.

So when today I got information that something is not reachable via IPv6 I decided to just drop use of it on server. Will fix configs but do not want to get information that something else break on the other day.

Red Hat Enterprise Linux Server for ARM 7.2 Development Preview released!

When I started working for Red Hat I got a list of packages in RHEL 7.0 which did not built for AArch64. Some time later I worked on merging those fixes in Fedora and upstream. Red Hat Enterprise Linux 7.0 got released. Then 7.1 followed. Then CentOS developers added AArch64 target based on work we did in RHEL.

Yesterday Red Hat Enterprise Linux 7.2 got released. What makes this version special is one paragraph:

Red Hat is also making available Red Hat Enterprise Linux Server for ARM 7.2 Development Preview, which was first made available to partners and their customers in June 2015. This Development Preview enables new partner hardware and additional features for the ARM architecture.

Which means AArch64 port. Working out of box on SBSA/SBBR compliant hardware.

Unbricking APM Mustang

Firmware update usually ends well. Previous (1.15.19) firmware failed to boot on some of Mustangs at Red Hat but worked fine on one under my desk. Yesterday I got 1.15.22 plus slimpro update and managed to get machine into non-bootable state (firmware works fine on other machines).

So how to get APM Mustang back into working state?

  • Get a SD card and connect it to an PC Linux machine with reader support.
  • Download Mustang software from MyAPM (1.5.19 was latest available there).
  • Unpack “mustang_sq_1.15.19.tar.xz” and then “mustang_binaries_1.15.19.tar.xz” tarballs.
  • Write the boot loader firmware to the SD card: “dd if=tianocore_media.img of=/dev/SDCARD“.
  • Take FAT formatted USB drive and put there some files from “mustang_binaries_1.15.19.tar.xz” archive (all into root directory):
    • potenza/apm_upgrade_tianocore.cmd
    • potenza/tianocore_media.img
    • potenza/UpgradeFirmware.efi
  • Power off your Mustang
  • Configure the Mustang to boot from SD card via these jumpers change:
    • Find HDR9 (close to HDR8, which is next to PCIe port)
    • Locate pin 11-12 and 17-18.
    • Connect 11-12 and 17-18 with jumpers
  • Insert SD card to Mustang SD port
  • Connect serial cable to Mustang and your PC.
  • Run minicom/picocom/screen/other-preferred-serial-terminal and connect to Mustang serial port
  • Power up Mustang and you should boot with SD UEFI firmware:
X-Gene Mustang Board
Boot firmware (version 1.1.0 built at 12:25:21 on Jun 22 2015)
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3020002 I0
PROGRESS CODE: V3020003 I0
PROGRESS CODE: V3021001 I0
TianoCore 1.1.0 UEFI 2.4.0 Jun 22 2015 12:24:25
CPU: APM ARM 64-bit Potenza Rev A3 1400MHz PCP 1400MHz
     32 KB ICACHE, 32 KB DCACHE
     SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
Board: X-Gene Mustang Board
The default boot selection will start in   2 second 
  • Press any key to get into UEFI menu.
  • Select “Shell” option and you will be greeted with a list of recognized block devices and filesystems. Check which is USB (“FS6” in my case).
Shell> fs6:
FS6:\> ls  
Directory of: FS6:\
08/04/2015  00:28              39,328  UpgradeFirmware.efi
08/27/2015  19:20                  56  apm_upgrade_tianocore.cmd
08/27/2015  19:20           2,098,176  tianocore_media.img
  • Flash firmware using “UpgradeFirmware.efi apm_upgrade_tianocore.cmd” command.
  • Power off
  • Change jumpers back to normal (11-12 and 17-18 to be open).
  • Eject SD card from Mustang
  • Power on

And your Mustang should be working again. You can also try to write other versions of firmware of course or grab files from internal hdd.

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.

AArch64

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 ;(

ARM

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).

Summary

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