Couple of false starts - I took the script about cross-compiling and forgot to change the TARGET_ARCH from arm6 to aarch64. It probably successfully built the arm6 32-bit architecture, but that wasn't what I needed, so I started over with the cross-compile. That SEEMS to have worked. I copied the "date" program over from the amd64 cross-development to the Raspberry, and it runs. I haven't crossed the bridge of creating the bootable image yet, but it seems like I may be on the right track for the cross-development. On the native side, definitely not as successful. It was exciting to see it max out all four CPU threads with "-j4" on the buildworld, but it kept failing at crazy spots with "sh" errors
Code:
Apr 23 14:42:41 tobias kernel: pid 41294 (sh), uid 1002: exited on signal 11 (core dumped)
Apr 23 15:16:33 tobias Àáÿÿÿÿ: stack overflow detected; terminated
Apr 23 15:16:48 tobias kernel: pid 49694 (sh), uid 1002: exited on signal 6 (core dumped)
Apr 23 20:44:40 tobias sh: stack overflow detected; terminated
Apr 23 20:45:06 tobias kernel: pid 64540 (sh), uid 1002: exited on signal 6 (core dumped)
./lib/libc/tests/stdlib/sh.core
./sbin/restore/sh.core
(note that while it failed on different files in the stdlib directory, it failed there twice, so that's why there is only two core files)
I was not too surprised that the native build did not work since I think this is uncharted territory, but I was VERY surprised to find segmentation faults and stack overflows from sh! That doesn't really make sense to me. I'm rerunning the native build without the "-j4" and I swear, it is going going less than 1/4th as fast. I really thought that each of the CPU threads on the arm was about 1/2 the speed of each of the cores on the AMD64, but that does not seem to be the case. The buildworld on the amd64 took three hours flat, and the buildworld on the arm is entering the 18th hour and still going. I am very concerned about what is going on on the arm. The one stack overflow message shows a corrupted program name. The fact that sh is getting memory faults on anything is scary. I'm running the native one again just to see if it will eventually successfully complete. I'll be very intrigued if it actually succeeds in building the things it failed at when it was running fully parallel. In that case, I'm going to wonder if my little raspberry is overheating, or if this is some strange artifact of running out of memory, or what. It claims to have ~150MB active and ~300MB free right now. I stopped mysql server and apache just to free up as many resources as possible. It doesn't seem to have recompiled the programs/files it was working on when it failed - but I don't understand the buildworld all that well yet, so this could be a lack of understanding on my part. I'm just getting back into this after decades of absence. It may even be that it is reporting the wrong program - this is a Tier 2 environment, so the territory is somewhat uncharted. I'm thrilled as much works as does, really.
The script which did the apparently successful buildworld and buildkernel cross-build was:
Code:
#!/bin/sh
export BASEDIR=$PWD
export MAKEOBJDIRPREFIX=$BASEDIR/obj
cd $BASEDIR/src
make -j3 buildworld TARGET_ARCH=aarch64 UBLDR_LOADADDR=0x00200000 && \
make -j3 buildkernel TARGET_ARCH=aarch64 KERNCONF=GENERIC
I am not going to claim that this is "perfect". My "obj" tree has a crazy number of levels to it which doesn't seem optimal, but maybe there's a good reason for it I haven't figured out yet. Basically, it is
$BASEDIR/obj/arm64.aarch64/$BASEDIR/src and I have no idea while
$BASEDIR is represented twice in that path. I don't know that that is the expansion that created it - I'm just using that construct to represent the parts of the path that are duplicated, which by no small coincidence, is the BASEDIR. I don't see a reason for it, but as I said, I'm still learning.
If anyone else is going on this journey with me, or if there's a better forum for me to make these posts, just let me know. Anyway, we'll see what happens with the native build.
