Librem 5: u-boot-librem5 depends on newlib-arm-none-eabi from Alpine testing

changed milestone to %[device] Librem 5 support

added help wanted + 1 deleted label

mentioned in commit dbd46702

By Oliver Smith on 2020-05-24T01:36:19

I'll have to try it, I don't know. IIRC I was just looking for anything at the time that could cross compile ATF for booting the device.

By clayton craft on 2020-05-24T01:45:59

Related to this, do you know when the Librem 5 will be able to use upstream u-boot rather than a Purism fork @craftyguy?

By Bart Ribbers on 2020-05-25T08:39:46

I don't know, I've asked on the purism librem5 matrix channel.

The librem5 package in pmos would not be able to use the u-boot from Alpine as-is. This package does more than just build u-boot, it puts u-boot + other things u-boot requires into an image file that can be flashed to the device. When the librem5 can use upstream u-boot, that functionality will either need to continue on in some similar package to this one, or get merge into the librem5 device package in aports.

By clayton craft on 2020-05-25T08:46:42

Can't we simply use gcc-armv7 from postmarketOS together with the pmb:cross-native APKBUILD option to build u-boot-librem5 and avoid the dependency altogether?

FYI I had a lot of problem getting this all to work in a single package initially, there are two binaries produced by this package, one needs to be aarch64 and the other needs to be armhf. They are meant to run on different cores/cpus on the device (aarch64 for main cpu, armhf for the m4 cortex cpu). Does the 'pmb:cross-native' thing support this use case?

By clayton craft on 2020-05-25T08:49:16

I would split this package into 2 packages, 1 for building the m4 firmware (called m4-librem5, and must be armhf), and 1 (called u-boot-librem5) for building uboot/ATF and creating the final image that includes uboot/ATF/m4 firmwares.

It would allow me to use gcc-armv7 for the 1st package m4-librem5, and gcc-aarch64 (whatever it's called) for the 2nd u-boot-librem5 package.

Thoughts?

By clayton craft on 2020-06-27T08:09:01

Sounds good!

By Oliver Smith on 2020-06-27T08:09:01

I can't get this to build..

gcc -Os -fomit-frame-pointer -g -o m4_ocram.elf m4_start.o m4_main.o iomux-v3.o ddr_loader.o gpio.o timer.o uart.o usdhc.o spi.o -Wl,--gc-sections -T ldscript -nostartfiles -Wl,-Map,m4.map,--cref,-n -Wl,-Ttext,0x00900000
/usr/lib/gcc/armv6-alpine-linux-musleabihf/9.3.0/../../../../armv6-alpine-linux-musleabihf/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/armv6-alpine-linux-musleabihf/9.3.0/../../../../armv6-alpine-linux-musleabihf/bin/ld: cannot find -lgcc_s

That seems like something fundamental to linking is missing or misconfigured, since libgcc (which provides libgcc_s.so.1) is installed.

Full build output is attached.fail_armhf.out

here's the APKBUILD I'm using:

# Maintainer:  Clayton Craft <clayton@craftyguy.net>
pkgname=m4-librem5
pkgver=0.1
pkgrel=0
_m4version="a017421c340a69f2392086da93841244f78a03c5"
pkgdesc="Cortex M4 firmware for the Purism Librem5 phone"
url="http://www.denx.de/wiki/U-Boot/"
arch="armhf"
license="GPL-2.0-or-later"
makedepends="$depends_dev musl-dev binutils"
options="!check !tracedeps"
source="
        m4-${_m4version}.tar.gz::https://source.puri.sm/Librem5/Cortex_M4/-/archive/${_m4version}/Cortex_M4-${_m4version}.tar.gz
        "

builddir="$srcdir"/Cortex_M4-${_m4version}

build() {
        make CC=gcc OBJCOPY=objcopy
}

package() {
        install -D -m644 "$builddir"/m4.bin \
                "$pkgdir/usr/share/firmware/librem5/m4.bin"
}
sha512sums="035a4358ddf586c829da7fa2fb0d9d1df913c0c454f2d0e57ff0c6794552e49950fb6373f9aaf72e0e4c78ab411496aabbc60bf66cd76e35053f7a2d77911735  m4-a017421c340a69f2392086da93841244f78a03c5.tar.gz"

I'm overriding CC and OBJCOPY on the commandline because in the Makefile they are set to some cross compiler. building this with pmb:cross-native doesn't help, it still fails for the same reason.

@ollieparanoid I'm also confused/unsure about what 'arch' this APKBUILD should specify. This is a package that needs to build an armhf binary, but it needs to be installed on an aarch64 system. So maybe 'arch=aarch64' in the APKBUILD and use cross compilers, but that's exactly what I had before.

The other option is accept that the librem5 "won't work" on Alpine 3.12 since there's no compiler available to build the m4 firmware. It looks like 'edge' has the cross compiler now so 3.13 should be fine, right?

By clayton craft on 2020-06-29T11:20:54

I've looked into this for a good two hours now and can't get it to build either - with the same cannot find -lgcc_s error :\

This is how the APKBUILD should look like, notably:

arch="aarch64"
makedepends="gcc-armv7 binutils-armv7 musl-dev-armv7"
options="pmb:cross-native"
make CC=armv7-alpine-linux-musleabihf-gcc OBJCOPY=armv7-alpine-linux-musleabihf-objcopy

(Caveat: it's possible to override CFLAGS, but not LDFLAGS with the Makefile, as the LDFLAGS specified in the Makefile will override whatever is set as environment var.)

I've tried all kinds of combinations of setting -L, --sysroot, LIBRARY_PATH to get gcc to find /usr/armv7-alpine-linux-musleabihf/lib/libgcc_s.so, but without success. With strace I'm seeing, that gcc considers /usr/armv7-alpine-linux-musleabihf/lib/ - but I don't get why it does not find libgcc_so.so in there.

Does anybody have an idea or wants to take a shot at it?

# Maintainer:  Clayton Craft <clayton@craftyguy.net>
pkgname=m4-librem5
pkgver=0_git20190116
pkgrel=0
_commit="a017421c340a69f2392086da93841244f78a03c5"
pkgdesc="Cortex M4 firmware for the Purism Librem5 phone"
url="https://source.puri.sm/Librem5/Cortex_M4"
arch="aarch64"
license="GPL-2.0-or-later"
makedepends="gcc-armv7 binutils-armv7 musl-dev-armv7"
options="!check !tracedeps pmb:cross-native"
source="
        m4-${_commit}.tar.gz::https://source.puri.sm/Librem5/Cortex_M4/-/archive/${_commit}/Cortex_M4-${_commit}.tar.gz
        "

builddir="$srcdir/Cortex_M4-$_commit"

build() {
        make \
		CC=armv7-alpine-linux-musleabihf-gcc \
		OBJCOPY=armv7-alpine-linux-musleabihf-objcopy
}

package() {
        install -D -m644 "$builddir"/m4.bin \
                "$pkgdir/usr/share/firmware/librem5/m4.bin"
}
sha512sums="035a4358ddf586c829da7fa2fb0d9d1df913c0c454f2d0e57ff0c6794552e49950fb6373f9aaf72e0e4c78ab411496aabbc60bf66cd76e35053f7a2d77911735  m4-a017421c340a69f2392086da93841244f78a03c5.tar.gz"

(Possibly related: #233)

By Oliver Smith on 2020-06-29T11:23:46

I discovered that this builds if I remove -n from the LDFLAGS, but I'm not sure if if the resulting binary is usable, or if this is even desired. The manpage for ld says:

-n
    Turn off page alignment of sections, and disable linking against shared libraries.  If the output format supports Unix style magic numbers, mark the output as "NMAGIC".

So that's probably not a useful discovery..

By clayton craft on 2020-06-30T07:43:00

I guess we could test it, without having any damage (since it's just written to the SD card, if it does not work, just flash it again with the working one, right?).

It's weird that this firmware thing requires linking against shared libraries in the first place.

By Oliver Smith on 2020-06-30T07:46:33

Yeah I can test it pretty easily.

It's weird that this firmware thing requires linking against shared libraries in the first place.

I agree. But I'm not going to pretend I know much about how this works, especially if it's linked against a shared library that probably won't be available at runtime since the binary, and only the binary, is embedded in the image. I'll ask the Purism folks too, maybe they have some ideas.

By clayton craft on 2020-06-30T07:49:44

The other option is accept that the librem5 "won't work" on Alpine 3.12 since there's no compiler available to build the m4 firmware. It looks like 'edge' has the cross compiler now so 3.13 should be fine, right?

gcc-arm-none-eabi is in Alpine testing currently. If you can convince the maintainer to move it to community before 3.13 is released, then it will be available in 3.13, otherwise not.

By Oliver Smith on 2020-06-29T11:23:02

mentioned in issue pmbootstrap#1937 (closed)

By Oliver Smith on 2020-06-30T09:11:19

mentioned in issue #724 (closed)

By clayton craft on 2020-08-26T19:50:25

It's also not trivial to fork newlib-arm-none-eabi, as this in turn depends on gcc-arm-none-eabi from Alpine testing, which is part of gcc-cross-embedded and depends on gcc-arm-none-eabi itself.

crust needed gcc-or1k-elf and binutils-or1k-elf, so the following packages were already added to v20.05:

gcc-cross-embedded
gcc-cross-embedded-stage1
binutils-cross-embedded
newlib-stage1

Maybe it's now feasible to package the armhf cross compiling related bits too.

By Oliver Smith on 2020-08-26T20:26:32

mentioned in merge request !1611 (closed)

By Oliver Smith on 2020-10-01T09:34:31

assigned to @ollieparanoid

By Oliver Smith on 2021-01-17T14:33:51

changed milestone to %v21.03 Release (Beta 2)

The super lazy method would be repackaging the apks from edge (like we do for cross/musl-*). But we can probably do it more elegantly.

To move this forward, one could look into getting it building on v20.05 again (in a testing branch, without pushing the packages to v20.05 branch); we would then need to fork the same packages to v21.03. As mentioned above, several packages were forked for crust already, it should be doable.

By Oliver Smith on 2021-02-03T08:55:45

I started a WIP branch on v20.05, but compiling gcc fails when configuring libgcc with this super generic task, which leads me to believe the compiler didn't actually build or something?

Branch is here: https://gitlab.postmarketos.org/postmarketos/pmaports/-/commits/v20.05_l5_uboot_arm

configure:3745: checking for suffix of object files
configure:3767: /home/pmos/build/src/build-arm-none-eabi/./gcc/xgcc -B/home/pmos/build/src/build-arm-none-eabi/./gcc/ -B/usr/arm-none-eabi/bin/ -B/usr/arm-none-eabi/lib/ -isyste
m /usr/arm-none-eabi/include -isystem /usr/arm-none-eabi/sys-include    -c -pipe -Os -ffunction-sections -fdata-sections  conftest.c >&5
/home/pmos/build/src/build-arm-none-eabi/./gcc/as: exec: line 106: illegal option -m
configure:3771: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3785: error: in `/home/pmos/build/src/build-arm-none-eabi/arm-none-eabi/libgcc':
configure:3787: error: cannot compute suffix of object files: cannot compile

By clayton craft on 2021-02-03T08:55:44

I didn't split the u-boot and m4 packages in that branch yet.. just in case you're curious why the m4 package earlier in this issue isn't there.

By clayton craft on 2021-02-03T09:06:03

@craftyguy, you were on the right track. But more packages needed to be adjusted.

https://gitlab.com/ollieparanoid/pmaports/-/commits/v20.05_l5_uboot_arm

With this branch, I got it to build

Notes:

(pushed to ollieparanoid, not the pmOS namespace)
I've unrolled several loops that would fill subpackages and makedepends, so pmbootstrap can parse it
Using pmb:cross-native, so u-boot actually gets built in the x86_64 chroot

Can you test if this u-boot version works? You could either test it now if you find the time. Or we do it on the v21.03 branch, as soon as it is ready there. I'll try to branch it today, or if that does not work out, early next week.

(To make it easier to maintain this in the future, we could put the gcc-cross-embedded related packages into a subdirectory.)

By Oliver Smith on 2021-02-22T20:31:47

@ollieparanoid thanks for getting it to this point! Yeah I can test it out soon, it might be a day or so before I get to it through, so if you need to branch before then we could add the L5 in the first service pack for the new stable branch.

By clayton craft on 2021-02-22T20:31:47

added device-purism-librem5 label

mentioned in merge request !1988 (closed)

By Oliver Smith on 2021-02-25T10:18:22

all patches from the branch adjusted and pushed to v21.03, except for the pmb:cross-native patch. this one should go through master, hence: !1988 (closed)

By Oliver Smith on 2021-02-25T10:19:25

mentioned in issue #992 (closed)

By Oliver Smith on 2021-02-25T10:25:05

closed

Librem 5: u-boot-librem5 depends on newlib-arm-none-eabi from Alpine testing

Child items 0

Activity