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

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

Result

In the end I concentrated again to msm8994:

Model checking the BPF verifier by shunghsiyu

Project Description

BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

Goal for this Hackweek

Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

Resources

Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
- Has a section specifically on model checking
Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
[PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier

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.

FizzBuzz OS by mssola

Project Description

FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

This project is free software and you can find it here.

Goal for this Hackweek

Better understand the RISC-V SBI interface.
Better understand RISC-V in privileged mode.
Have fun.

Resources

Results

The project was a resounding success Lots of learning, and the initial target was met.

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

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

Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

Description

"LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

Goals

Goals of this project:

Modify the RSpec tests and run them against a real LDAP server
Replace the net-ldap rubygem with the ruby-ldap rubygem

Achieving the above mentioned goals will:

Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
Make a step towards officially supporting LDAP in OBS.

Resources

Replace ruby-ldap rubygem with net-ldap

Implement a full OBS api client in Rust by nbelouin

Description

I recently started to work on tooling for OBS using rust, to do so I started a Rust create to interact with OBS API, I only implemented a few routes/resources for what I needed. What about making it a full fledged OBS client library.

Goals

Implement more routes/resources
Implement a test suite against the actual OBS implementation
Bonus: Create an osc like cli in Rust using the library

Resources

https://github.com/suse-edge/obs-tools/tree/main/obs-client
https://api.opensuse.org/apidocs/

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

Automation of ABI compatibility checks by ateixeira

Description

ABI compatibility checks could be further automated by using the OBS API to download built RPMs and using existing tools to analyze ABI compatibility between the libraries contained in those packages. This project aims to explore these possibilities and figure out a way to make ABI checks as painless and fast as possible for package maintainers.

Resources

https://github.com/openSUSE/abi-compliance-checker

https://github.com/lvc/abi-compliance-checker

https://sourceware.org/libabigail/

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.