SUSE Hack Week: [ARM] Bootstrap ILP32 on AArch64

Some customers are still stuck in a world of 32bit. On ARM64, we have two options for those poor folks:

1) Run applications in the legacy ARMv7 instruction set 2) Compile applications with 32bit, but for the new AArch64 instruction set. This is called ILP32.

The main reason option 1 is a bad idea is that some hardware is already dropping ARMv7 instruction set support. And there will be more to come.

So if we ever want to enable people to run code that is not 64bit safe on AArch64 platforms, we need to provide them with a way out. Hence we should bootstrap at least the bare minimum to enable them to compile their own (broken) code.

Beware that all of this is in a big flux. The interfaces (ABI, syscalls) are not yet set in stone.

Join this project Leave this project

Looking for hackers with the skills:

arm ilp32 binutils kernel aarch64 obs openbuildservice

This project is part of:

Hack Week 12

Activity

almost 10 years ago: a_faerber left this project.

almost 10 years ago: a_faerber added keyword "obs" to this project.

almost 10 years ago: a_faerber added keyword "openbuildservice" to this project.

almost 10 years ago: a_faerber liked this project.

almost 10 years ago: a_faerber joined this project.

almost 10 years ago: algraf added keyword "arm" to this project.

almost 10 years ago: algraf added keyword "ilp32" to this project.

almost 10 years ago: algraf added keyword "binutils" to this project.

almost 10 years ago: algraf added keyword "kernel" to this project.

almost 10 years ago: algraf added keyword "aarch64" to this project.

almost 10 years ago: algraf started this project.

almost 10 years ago: algraf originated this project.

Comments

Be the first to comment!

Similar Projects

kernel

Modularization and Modernization of cifs.ko for Enhanced SMB Protocol Support by hcarvalho

Creator:
Enzo Matsumiya ematsumiya@suse.de @ SUSE Samba team
Members:
Henrique Carvalho henrique.carvalho@suse.com @ SUSE Samba team

Description

Split cifs.ko in 2 separate modules; one for SMB 1.0 and 2.0.x, and another for SMB 2.1, 3.0, and 3.1.1.

Goals

Primary

Start phasing out/deprecation of older SMB versions

Secondary

Clean up of the code (with focus on the newer versions)
Update cifs-utils
Update documentation
Improve backport workflow (see below)

Technical details

Ideas for the implementation.

fs/smb/client/{old,new}.c to generate the respective modules
- Maybe don't create separate folders? (re-evaluate as things progresses!)
Remove server->{ops,vals} if possible
Clean up fs_context.* -- merge duplicate options into one, handle them in userspace utils
Reduce code in smb2pdu.c -- tons of functions with very similar init/setup -> send/recv -> handle/free flow
Restructure multichannel
- Treat initial connection as "channel 0" regardless of multichannel enabled/negotiated status, proceed with extra channels accordingly
- Extra channel just point to "channel 0" as the primary server, no need to allocate an extra TCPServerInfo for each one
Authentication mechanisms
- Modernize algorithms (references: himmelblau, IAKERB/Local KDC, SCRAM, oauth2 (Azure), etc.

Linux on Cavium CN23XX cards by tsbogend

Before Cavium switched to ARM64 CPUs they developed quite powerful MIPS based SOCs. The current upstream Linux kernel already supports some Octeon SOCs, but not the latest versions. Goal of this Hack Week project is to use the latest Cavium SDK to update the Linux kernel code to let it running on CN23XX network cards.

Hacking on sched_ext by flonnegren

Description

Sched_ext upstream has some interesting issues open for grabs:

Goals

Send patches to sched_ext upstream

Also set up perfetto to trace some of the example schedulers.

Resources

https://github.com/sched-ext/scx

Create a DRM driver for VGA video cards by tdz

Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.

VGA has a number of limitations, which make this project interesting.

There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.

The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.

Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA

Kill DMA and DMA32 memory zones by ptesarik

Description

Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.

Goals

Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).

Resources

LPC2024 talk:
video:

aarch64

Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel

Result

In the end I concentrated again to msm8994:

Investigate non-booting Forlinx OKMX8MX-C board (aarch64) by a_faerber

Description

In the context of a SUSE customer inquiry last year, a Forlinx OKMX8MX-C arm64 board had been relayed to me from China that a customer was not successful booting SUSE Linux Micro on. Typically this happens when the vendor's bootloader (e.g., U-Boot) is not configured properly (e.g., U-Boot's distro boot) to be compliant with Arm SystemReady Devicetree (formerly IR) band. Unfortunately I could not immediately get it to emit any output, to even diagnose why it wasn't working. There was no public documentation on the vendor's website to even confirm I was checking the right UARTs.

Earlier this year (2024) I happened to meet the ODM/OEM, Forlinx, at Embedded World 2024 in Nuremberg and again the Monday before Hackweek 24 at Electronica 2024 in Munich. The big puzzle was that the PCB print "OKMX8MX-C" does not match any current Forlinx product, there being OKMX8MM-C and OKMX8MP-C products with the Mini and Plus variants of NXP i.MX 8M family instead. One suggestion from Forlinx staff was to double-check the DIP switches on the board for boot mode selection.

Goals

Double-check the board name and investigate further what may be wrong with this board.

Resources

none

Progress

The board name is indeed as spelled above, not matching any product on forlinx.net.
The DIP switches were set to boot from microSD.
Changing the DIP switches to eMMC boot did result in UART1 RS-232 output! (although at times garbled with the cable supplied and USB adapter used)
As feared, it did not automatically load our GRUB from USB.
Booting our GRUB manually from USB (via eMMC U-Boot commands fatload+bootefi) was unsuccessful, with partially Chinese error messages.
This confirmed the initial suspicion, already shared with Forlinx at Embedded World 2024, that the Forlinx System-on-Module's boot firmware was not Arm SystemReady Devicetree compliant and that a firmware update would be necessary to remedy that.
The microSD card turned out not to contain a bootable image but to only include Chinese-language board documentation (dated 20220507) and BSP files. They used a diverging name of OKMX8MQ-C.

obs

Learn about OSB and contribute to `kustomize` and `k9s` packages to add ARM arch by dpock

Description

There are already k9s and kustomize packages that exist for openSUSE today. These could be used as the source for these binaries in our rancher projects. By using them we would benefit from CVE fixes included in our distribution of the packages not in cluded upstream. However they are not providing arm package builds which are required.

Goals

[ ] Update the kustomize package in OBS to use the newest version and send change request

Resources

k9s: https://build.opensuse.org/package/show/openSUSE:Factory/k9s
kustomize: https://build.opensuse.org/package/show/openSUSE:Factory/kustomize
Learning Docs: https://confluence.suse.com/display/packaging/Training%2C+Talks+and+Videos

New features in openqa-trigger-from-obs for openQA by jlausuch

Description

Implement new features in openqa-trigger-from-obs to make xml more flexible.

Goals

One of the features to be implemented: - Possibility to define "VERSION" and "ARCH" variables per flavor instead of global.

Resources

https://github.com/os-autoinst/openqa-trigger-from-obs

Bootstrap openSUSE on LoongArch by glaubitz

Description

LoongArch is a new architecture from China which has its roots in the MIPS architecture. It has been created by Loongson and is already supported by Debian Ports, Gentoo and Loongnix.

Upstream support for LoongArch is already quite complete which includes LLVM, Rust, Golang, GRUB, QEMU, LibreOffice and many more. In Debian Ports, where the port is called "loong64", more than 95% of the whole Debian archive have been successfully built for LoongArch.

QEMU support is rather complete and stable such that packages can be built in emulated environments. Hardware can also be requested by Loongson on request for free. Access to real hardware is also provided through the GCC Compile Farm.

Goals

The initial goal should be to add LoongArch to OBS and build a minimal set of packages.

Resources

Introduction to LoongArch: https://docs.kernel.org/arch/loongarch/introduction.html
LoongArch community on Github: https://github.com/loongarchlinux
Debian Ports repository for loong64: http://ftp.ports.debian.org/debian-ports/pool-loong64/main/
Gentoo stage3 for loong: https://www.gentoo.org/downloads/#loong

Results

Acknowledgements

Thanks to Adrian Schröter and Rüdiger Oertl for the help with setting up the FTP space and OBS project
Thanks to Dirk Müller for the input on how to get started with a new port
Thanks to Richard Biener for quickly accepting my submit requests to add loongarch64 support to the toolchain

Explore the integration between OBS and GitHub by pdostal

Project Description

The goals:

1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.

Goal for this Hackweek

Do as much as possible, blog about it and maybe use it another existing project.

Resources

Git CI to automate the creation of product definition by gyribeiro

Description

Automate the creation of product definition

Goals

Create a Git CI that will:

automatically be triggered once a change (commit) in package list is done.
run tool responsible to update product definition based on the changes in package list
test the updated product definition in OBS
submit a pull request updating the product definition in the repository

NOTE: this Git CI may also be triggered manually

Resources

https://docs.gitlab.com/ee/ci/
https://openbuildservice.org/2021/05/31/scm-integration/
https://github.com/openSUSE/openSUSE-release-tools