Help building AROS hosted on Linux ARM: AROS FORUMS

Help building AROS hosted on Linux ARM

Last updated on 4 months ago

FaroxMember

Posted 6 months ago

Hi
I was looking a way to use more my Handheld ARM based called Pyra (Dragonbox Pyra) an ARM (Omap5 cpu with 4GB ram) linux based machine (Debian Buster v10 with kernel 5.6.19 adapted) and have a try to compile the latest Aros sources by Deadwood directly on this device.
Compilation stops after build libpopupmenu.a and trying to build libatomic have this error:

Quote

Configuring build in bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic
configure: WARNING: unrecognized options: --disable-nls, --without-x
checking for --enable-version-specific-runtime-libs... no
checking for --enable-generated-files-in-srcdir... no
checking build system type... arm-unknown-linux-gnu
checking host system type... arm-unknown-aros
checking target system type... arm-unknown-aros
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for arm-aros-strip... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-strip
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for arm-aros-gcc... /media/farox/pyra2/arosbuilds/toolchain-core-armhf/arm-aros-gcc
checking whether the C compiler works... no
configure: error: in /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic': configure: error: C compiler cannot create executables Seeconfig.log' for more details
make[2]: *** [mmakefile:4489: /media/farox/pyra2/arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic/.configured] Error 77
[MMAKE] make --no-print-directory TOP=/media/farox/pyra2/arosbuilds/toolchain-core-armhf-build SRCDIR=/media/farox/pyra2/arosbuilds/AROS CURDIR=tools/crosstools/gnu TARGET=tools-crosstools-gcc-libatomic-configure -s --file=mmakefile tools-crosstools-gcc-libatomic-configure failed: 512
[MMAKE] Error: Error while running make in tools/crosstools/gnu: No such file or directory
make[1]: *** [Makefile:361: linklibs-libatomic] Error 10
make: *** [Makefile:183: crosstools] Error 2

looking at config.log on arosbuilds/toolchain-core-armhf-build/bin/linux-arm/gen/host/tools/crosstools/gnu/gcc/arm-aros/libatomic

i found that arosbuilds/toolchain-core-armhf/arm-aros-ld: cannot find -laeabi
so i do make linklibs-aeabi-arm-quick
and the missing lib was built.

now the next stop is at
fatal error: bits/libc-header-start.h: No such file or directory
and
fatal error: sys/cdefs.h: No such file or directory
in many places so after checking that i have this missing include files i have noted that my include path is a bit different, standard searching path is /usr/arm-linux-gnueabihf but in my system is /usr/include/arm-linux-gnueabihf
so if i add my path to some mmakefiles compilation goes on....but is a better way to add this path to avoid every mmakefiles to be changed?
i fixed with adding
-I/usr/include/arm-linux-gnueabihf
to where is missing on mmakefiles like
USER_INCLUDES := -isystem $(GENINCDIR) -I/usr/include/arm-linux-gnueabihf $(KERNEL_INCLUDES)

P.s. I have changed many mmakefiles and have at least compiled (after many hours) the toolchain doing make every time in arosbuilds/toolchain-core-armhf-build (also have to disable making tests under cplusplus but don't remember the directory ...) but i ask an help to have an automated way to correctly build without modify mmakefiles.

Thanks

Edited by Farox on 30-03-2025 03:45, 6 months ago

deadwoodAROS Dev

Posted 6 months ago

Last time I built armhf target was around 2 years ago. At that point I built is via cross-compilation from linux (ubuntu 22.04) using linux armhf crosscompiler (this can explain the path differences you are experiencing) as well as using AROS gcc cross-compiler in version 6.5.0 (build with option 21) in rebuild.sh). Since then AROS GCC has been updated to 10.5.0 and I don't believe anyone tried to build the armhf target again.

My suggestion would be to downgrade GCC to 6.5.0 (via editing AROS/config/gcc_def file) and try to first build using cross-compilation from x86_64 linux. Once that works, you will have a "template" to compare to native compilation under arm linux.

FaroxMember

Posted 6 months ago

Thanks for your suggestion...but i think the toolchain with GCC 10.5.0 is compilable if i found a way to pass the path of my system to the script that build (option 21 on rebuild).
The other only changes are (but i don't know where to modify...) is to add the build of libaeabi and disable the building of some tests under cplusplus that use exceptions and is not supported under ARM.
I'll try to crosscompile with my Linux amd64 PC.

deadwoodAROS Dev

Posted 6 months ago

For paths look into core-linux-armhf/bin/linux-armhf/gen/config/target.cfg. A number of build-wide variable is set there containing paths to local build system. These variables and the target.cfg file are generated by AROS ./configure script.

1 user reacted to this post

Farox

FaroxMember

Posted 6 months ago

Thanks compilation now go forward...i changed target.cfg under "toolchain-core-armhf-build/bin/linux-arm/gen/config" and do make on "toolchain-core-armhf-build" dir.

Now i need to find where to enable build libaeabi.a so i can build the entire toolchain with option 21 of rebuild.sh

deadwoodAROS Dev

Posted 6 months ago

I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:

#MM- linklibs-armhd : libklibs-aeabi-arm

Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.

1 user reacted to this post

Argo

FaroxMember

Posted 6 months ago

deadwood wrote:

@deadwood - I found something that looks like libeabi in AROS/arm-all/arm-aeabi/mmakefile.src. Try adding a third line there:

#MM- linklibs-armhd : libklibs-aeabi-arm

Though I don't remember needing this library. Possibly the 6.5.0 GCC somehow does this while 10.5.0 is missing this.

I try adding this line (and the variant "linklibs-armhf" instead of hd) but it did not solve the automatic building of the missing lib. I must do "linklibs-aeabi-arm-quick".
Anyway after have build the aeabi lib i succefully built the toolchain (after many hours...).

To test I restarted from selecting option 21 (on rebuild.sh) but after many hours i get the same error of the kernel includes not found...maybe i need to modify the configure script for my case.

With the toolchain built i try to build the core-linux-armhf (DEBUG) (option 22) but after a while it stopped with
"cannot find -laeabi " so i made it built manually...and now i can continue compiling...i'll let you know if all goes ok.

Edited by Farox on 01-04-2025 15:21, 6 months ago

1 user reacted to this post

deadwood

FaroxMember

Posted 6 months ago

@deadwood
I retry building the toolchain but this time i edited the configure script adding my path to the armhf section and it worked, no more need to do any changes on mmakefiles (excluding the tests on cplusplus), only remain to find how to automate the building of libaeabi.
With the toolchain built i also built the core-linux-armhf (DEBUG) (option 22) , but i found that when i run Aros bootstrap (that i found on /boot/linux/AROSBootstrap) i have this error:

./boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa698c000 - 0xb698c000 (268435456 bytes)
boot/linux/Devs/hostlib.resource: Object of the wrong type or architecture

this is the result of "file"
file ./boot/linux/Devs/hostlib.resource
./boot/linux/Devs/hostlib.resource: ELF 32-bit LSB executable, ARM, EABI5 version 1 (AROS Research Operating System), statically linked, not stripped

Edited by Farox on 07-04-2025 14:51, 6 months ago

deadwoodAROS Dev

Posted 6 months ago

Ok, I think what is going on. Check AROS/bootstrap/elfloader.c - the error comes from there. In general AROS binaries on all architectures are not real binaries but relocable objects. This is what this check is checking. However... on ARM there was an effort to change AROS binaries to real ELF executables (and your file command output proves that hostlib.resource is a real ELF executable). Now if we are lucky, all you need to do to change the check to expect ELF executable not ET_REL. If we are not lucky, hosted kernel has not been modified to work with real executables (the effort was prototyped on rPI native port I believe)

1 user reacted to this post

Farox

FaroxMember

Posted 6 months ago

#10

deadwood wrote:

@deadwood - Ok, I think what is going on. Check AROS/bootstrap/elfloader.c - the error comes from there. In general AROS binaries on all architectures are not real binaries but relocable objects. This is what this check is checking. However... on ARM there was an effort to change AROS binaries to real ELF executables (and your file command output proves that hostlib.resource is a real ELF executable). Now if we are lucky, all you need to do to change the check to expect ELF executable not ET_REL. If we are not lucky, hosted kernel has not been modified to work with real executables (the effort was prototyped on rPI native port I believe)

Maybe we are not so lucky this time...but i'm not sure about it.
i changed on elfloader.c the line:
//if (eh->type != ET_REL || eh->machine != AROS_ELF_MACHINE)
if (eh->machine != AROS_ELF_MACHINE)

to bypass the ET_REL check but now i have a segmentation error...

./boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa69fa000 - 0xb69fa000 (268435456 bytes)
Errore di segmentazione

Thanks a lot for your help.

deadwoodAROS Dev

Posted 6 months ago

#11

Well, now the fun part comes in: debugging.

Run AROS through gdb:

$ gdb ./boot/linux/AROSBootstrap

and when it breaks on SIGSEV, do

$ loadbt
$ bt

You should see stack trace of where the crash happened.

Note: if you never did this before, gdb will complain about NOT using .gdbinit file - but this file is necessary for AROS debugging to work. Follow the on-screen gdb instructions to "add" this file to "safe" files and you should be ready to go.

2 users reacted to this post

Argo, Farox

FaroxMember

Posted 6 months ago

#12

OK this is the log from GDB:

Quote

gdb ./boot/linux/AROSBootstrap
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./boot/linux/AROSBootstrap...done.
(gdb) r
Starting program: /media/farox/CDEV/arosbuilds/core-linux-amrhf-d/bin/linux-arm/AROS/boot/linux/AROSBootstrap
[Bootstrap] RAM memory block allocated: 0xa6a2a000 - 0xb6a2a000 (268435456 bytes)

Program received signal SIGSEGV, Segmentation fault.
0x00403364 in relocate (eh=0x417eb0, sh=0x417ee8, shrel_idx=2,
DefSysBase=4285900)
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:352
352 signed long offset = *p;
(gdb) loadbt
Checking frame #0
Undefined set logging command: "enabled on". Try "help set logging".
(gdb) bt
#0 0x00403364 in relocate (eh=0x417eb0, sh=0x417ee8, shrel_idx=2,
DefSysBase=4285900)
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:352
#1 0x00403c10 in LoadKernel (FirstELF=0x418c48, ptr_ro=0xa684a1d6,
ptr_rw=0x41d0b4, tracker_p=0xb6ffa000 "240314A", DefSysBase=4285900,
kick_end=0x0, kernel_entry=0xbefff138,
kernel_debug=0x4165d0 <Debug_KickList>
at /media/farox/CDEV/arosbuilds/AROS/bootstrap/./elfloader.c:575
#2 0x00401968 in bootstrap (argc=1, argv=0xbefff2d4)
at /media/farox/CDEV/arosbuilds/AROS/arch/all-hosted/bootstrap/./bootstrap.c:366
#3 0x00400f48 in main (argc=1, argv=0xbefff2d4)
at /media/farox/CDEV/arosbuilds/AROS/arch/all-hosted/bootstrap/./main.c:9
(gdb)

1 user reacted to this post

Argo

deadwoodAROS Dev

Posted 6 months ago

#13

Ok, I looks like the elf loader in bootstrap code was not changed to handle real executables. If you want to experiment with it, check how mschulz tried to implement full ELF loader in arch/arm-raspi/elf.c (commits from March and April 2019). You might be able to utilize parts of that code. Alternativelly try contacting mschulz on discord - he moved away from AROS but maybe can help with some pointers.

1 user reacted to this post

Farox

FaroxMember

Posted 6 months ago

#14

Thanks a lot for your help...for the moment i want to compile with some of the fix from NinjaCowboy
https://github.com/aros-development-team/AROS/pull/621
that fixed some thinks to run on Raspberry Pi (regarding relocation).
Next i will look at commits from M. Schulz.
Thanks

1 user reacted to this post

Argo

deadwoodAROS Dev

Posted 6 months ago

#15

Oh yes, good catch, I forgot about those changes from NinjaCowboy. Hope it will out. Eventually I'd love to see ELF executables support added to both x86_64 and m68k.

2 users reacted to this post

Argo, Farox

CrumbNewbie

Posted 4 months ago

#16

Any success? I would be more interested in the big endian rpi3 flavour. I've added a pair of options to rebuild-conf and modified slightly configure to add armeb (I'm not sure if this is really required). Removing libatomic seems to help to build the sdk (I don't know if it's a good idea) but building aros big endian fails (also requesting -laeabi although the big endian flavour is supposedly added). I was thinking that perhaps I'm doing It wrong and I should try with arm64-big endian instead of armeb. Perhaps It builds better. Michal had multicore support disabled in his tests iirc. A big endian version could use some kind of hunkreader that loads and executes 68k code on musashi, the emulator should have access to host memory.

I don't know if ARMs can execute big endian code in a little endian linux host, perhaps it could make easier to debug.

23)
TOOLCHAIN_DIR=$(pwd)/toolchain-core-armeb
BUILD_DIR=$(pwd)/toolchain-core-armeb-build
TOOLCHAIN_BUILD=yes
# USER_LDFLAGS= -static
CONFIGURE_TARGET=raspi-armeb
# CONFIGURE_OPTS="--with-cpu=armv7-a --with-fpu=vfpv3-d16"
MAKE_TARGET="-s crosstools"
;;
24)
TOOLCHAIN_DIR=$(pwd)/toolchain-core-armeb
BUILD_DIR=$(pwd)/core-raspi-armeb
CONFIGURE_TARGET=raspi-armeb
CONFIGURE_OPTS="--with-aros-toolchain=yes --enable-debug"
;;

FaroxMember

Posted 4 months ago

#17

Crumb wrote:

@Crumb - Any success? I would be more interested in the big endian rpi3 flavour. I've added a pair of options to rebuild-conf and modified slightly configure to add armeb (I'm not sure if this is really required). Removing libatomic seems to help to build the sdk (I don't know if it's a good idea) but building aros big endian fails (also requesting -laeabi although the big endian flavour is supposedly added). I was thinking that perhaps I'm doing It wrong and I should try with arm64-big endian instead of armeb. Perhaps It builds better. Michal had multicore support disabled in his tests iirc. A big endian version could use some kind of hunkreader that loads and executes 68k code on musashi, the emulator should have access to host memory.

I don't know if ARMs can execute big endian code in a little endian linux host, perhaps it could make easier to debug.

23)
TOOLCHAIN_DIR=$(pwd)/toolchain-core-armeb
BUILD_DIR=$(pwd)/toolchain-core-armeb-build
TOOLCHAIN_BUILD=yes
# USER_LDFLAGS= -static
CONFIGURE_TARGET=raspi-armeb
# CONFIGURE_OPTS="--with-cpu=armv7-a --with-fpu=vfpv3-d16"
MAKE_TARGET="-s crosstools"
;;
24)
TOOLCHAIN_DIR=$(pwd)/toolchain-core-armeb
BUILD_DIR=$(pwd)/core-raspi-armeb
CONFIGURE_TARGET=raspi-armeb
CONFIGURE_OPTS="--with-aros-toolchain=yes --enable-debug"
;;

Sadly no success, i have built toolchain and Aros sources with some of the NinjaCowboy changes but they do act like in my previous post. I'm really not an expert here, also i asked "mschulz" on discord for any help, but he is busy with other works and also, after a long time away from Aros, he said maybe he couldn't offer such a big help.

I don't have an ARM64 machine, so i tryed to build only on a 32bit machine, but is interesting your experiment.

Also i read that ARM cpu's can operate in both endian modes (one at a time selectable only at boot iirc), but don't think is possible (in my humble experience) to run a big endian code hosted in a little endian linux.
Would be interesting to find the last working code from mschulz in 2019 and rebuild this version...but at moment i have other things to port on Aros.

If you try let me know in this thread.

You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.

Moderator: Administrator, Moderators

Users who participated in discussion: deadwood, Farox, Crumb

Search AROSWorld

Help building AROS hosted on Linux ARM