| View previous topic :: View next topic |
| Author |
Message |
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
 Posted: Fri Feb 10, 2017 2:59 am Post subject: Crossbuild of runit-2.1.1-r1 fails for aarch64. |
 |
|
Hello,
I've been following https://wiki.gentoo.org/index.php?title=Raspberry_Pi_3_64_bit_Install. Pretty much everything built except runit-2.1.1-r1 and some things which depend on it. Notably both portage and GCC are built if the issue needs to be worked around.
Searching returns very few results unfortunately.
EDIT: There are a number of packages with dotfiles in their work directories. I have used FEATURES="keepwork". They seemed to appear when not using it as well. Is the package successfully installed already? Something tells me it isn't, or it wouldn't be scheduled for emerge.
| Code: | >>> It appears that 'runit-2.1.1-r1' is already setup; skipping.
>>> Remove '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/.setuped' to force setup.
>>> WORKDIR is up-to-date, keeping...
>>> It appears that 'runit-2.1.1-r1' is already prepared; skipping.
>>> Remove '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/.prepared' to force prepare.
>>> It appears that 'runit-2.1.1-r1' is already configured; skipping.
>>> Remove '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/.configured' to force configuration.
>>> Compiling source in /usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/work/admin/runit-2.1.1/src ...
make -j8 -l8
./chkshsgr || ( cat warn-shsgr; exit 1 )
/bin/sh: ./chkshsgr: cannot execute binary file: Exec format error
Oops. Your getgroups() returned 0, and setgroups() failed; this means
that I can't reliably do my shsgr test. Please either ``make'' as root
or ``make'' while you're in one or more supplementary groups.
Makefile:237: recipe for target 'hasshsgr.h' failed
make: *** [hasshsgr.h] Error 1
emake failed
* ERROR: sys-process/runit-2.1.1-r1::gentoo failed (compile phase):
* emake failed
*
* Call stack:
* ebuild.sh, line 115: Called src_compile
* environment, line 2240: Called default
* phase-functions.sh, line 805: Called default_src_compile
* phase-functions.sh, line 842: Called __eapi2_src_compile
* phase-helpers.sh, line 785: Called die
* The specific snippet of code:
* emake || die "emake failed"
*
* If you need support, post the output of `emerge --info '=sys-process/runit-2.1.1-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-process/runit-2.1.1-r1::gentoo'`.
* The complete build log is located at '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/temp/build.log'.
* The ebuild environment file is located at '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/temp/environment'.
* Working directory: '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/work/admin/runit-2.1.1/src'
* S: '/usr/aarch64-unknown-linux-gnu/tmp/portage/sys-process/runit-2.1.1-r1/work/admin/runit-2.1.1/src' |
|
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Fri Feb 10, 2017 2:35 pm Post subject: |
|
|
R0b0t1,
This is one of those cases where chkshsgr is built for arm64 then run on the build host, which gets you the Exec format error.
That's game over. The build system is probably not tested for cross compiling.
If you want to make the build system skip the test that fails, make a file
/usr/aarch64-unknown-linux-gnu/etc/portage/patches/sys-process/runit/runit.patch
containing
| Code: | --- /Makefile 2017-02-10 13:57:15.977028281 +0000
+++ /Makefile 2017-02-10 13:54:25.519316696 +0000
@@ -234,7 +234,7 @@
hasshsgr.h: chkshsgr choose compile hasshsgr.h1 hasshsgr.h2 load \
tryshsgr.c warn-shsgr
+# ./chkshsgr || ( cat warn-shsgr; exit 1 )
- ./chkshsgr || ( cat warn-shsgr; exit 1 )
./choose clr tryshsgr hasshsgr.h1 hasshsgr.h2 > hasshsgr.h
haswaitp.h: choose compile haswaitp.h1 haswaitp.h2 load trywaitp.c |
That comments out the test that fails and the package builds.
There is another wrinkle. For EAPI 6 ebuilds, patches found in /etc/portage/patches/<catagory>/<package>/<name>-<version>.patch are applied by portage.
For EAPI < 6 you need to edit the ebuild to call epatch_user.
In this case we find that
| Code: | # grep EAPI /usr/portage/sys-process/runit/*
grep: /usr/portage/sys-process/runit/files: Is a directory
/usr/portage/sys-process/runit/runit-2.1.1-r1.ebuild:EAPI="3"
/usr/portage/sys-process/runit/runit-2.1.2-r1.ebuild:EAPI=6
/usr/portage/sys-process/runit/runit-2.1.2.ebuild:EAPI=5 |
and | Code: | # grep arm64 /usr/portage/sys-process/runit/*
grep: /usr/portage/sys-process/runit/files: Is a directory
/usr/portage/sys-process/runit/runit-2.1.1-r1.ebuild:KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86"
/usr/portage/sys-process/runit/runit-2.1.2-r1.ebuild:KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"
/usr/portage/sys-process/runit/runit-2.1.2.ebuild:KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"
|
It follows that if you use the ~arm64 version of runit, the patch will be applied by portage. If you want the arm64 version, you need to make yourself an overlay and edit the ebuild.
I've only done build testing. It may not work.
--- edit ---
I'm not sure that epatch_user goes back as far as EAPI 3, so it gets harder to have portage apply the patch.
It can sill be done though.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Fri Feb 10, 2017 5:39 pm Post subject: |
|
|
| NeddySeagoon wrote: |
It follows that if you use the ~arm64 version of runit, the patch will be applied by portage. If you want the arm64 version, you need to make yourself an overlay and edit the ebuild.
I've only done build testing. It may not work.
--- edit ---
I'm not sure that epatch_user goes back as far as EAPI 3, so it gets harder to have portage apply the patch.
It can sill be done though. |
Thanks, the patch works. I have no problem running ~arm64 however I was experiencing issues cross compiling GCC 5.4. I may ask for help with that later depending on if this root works.
If you don't mind, how did you get your raspberry pi 3's root? Are you and Sakaki building off of the gentoo-hosted unsigned stage3, or working from the raspberry pi foundation's release image? Is it possible to get, at least, a minimal set of packages on the crossroot so that fixups for packages like runit (if there are any more) can be run natively? That is what I was aiming for.
My plan is to copy the cross-compiled kernel over to /boot on an SD card, and then untar /usr/aarch64-unknown-linux-gnu on the root partition of the SD card. That should theoretically be all I need to do, right? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Fri Feb 10, 2017 8:37 pm Post subject: |
|
|
R0b0t1,
I cross compiled everything needed to boot. That's not an entire stage3. Perl and a few other things were missing.
I was not aware of the Gentoo arm64 stage3 and the Raspberry Pi Foundation do not openly support a 64 bit install.
They don't hinder the community working on arm64 for the Pi though.
My arm64 root started out with me banging two stones together :)
Its documented in this topic Raspberry Pi 3 - 64 Bit Operation and the wiki page that I have already linked.
There are a lot of references to the Raspberry Pi forums.
There is a script in that forums thread that cross compiles gcc. gcc C is not enough.
You must have C++ too as gcc is now written in C++.
You don't need u-boot any more as that thread describes. The Raspberry Pi bootcode.bin is now 64 bit friendly.
It knows three default kernel names
kernel.img fer the Pi 1
kernel7.image for the Pi 2
kernel8.img for the Pi 3 in 64 bit mode.
Neither do you need a serial console. When I started, that's all the I/O there was. USB was soon added, then Ethernet, which needs USB.
If you use kernel8.img as your kernel name, bootcode.bin sets the Pi into 64 bit mode. If you use another kernel name, you need to set 64 bit mode in config.txt.
Since cross compiling enough to boot and be useful was difficult. I tried the building boot and test with an empty root filesystem.
The kernel messages and panic when root failed to mount was a very welcome sight.
In the end, I had to set CXX in my cross make.conf so build systems could find the cross C++ compiler.
Here's my cross make.conf
That CXX is a nasty hack. Its version dependent and it points to the wrong version now. I'm on gcc-6.3.0
The bare minimum you need in the root filesystem is
| Code: | $ lddtree /bin/bash
/bin/bash (interpreter => /lib64/ld-linux-x86-64.so.2)
libreadline.so.7 => /lib64/libreadline.so.7
libncurses.so.6 => /lib64/libncurses.so.6
libdl.so.2 => /lib64/libdl.so.2
libc.so.6 => /lib64/libc.so.6 |
Thats a dynamically linked bash and all its dependencies.
That will let you boot with init=/bin/bash. I ran that on an amd64 box. The interpreter name will be incorrect.
All you will have is bash but its still a good test case.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Tue Feb 14, 2017 1:15 am Post subject: |
|
|
EDIT 2: I get a more reasonable message about being unable to find a /, as you described. However it seems to fail before attempting to launch the init binary or script and it should be able to find a f2fs filesystem. There is still one logo at the top. SMP should be enabled by default, but I'm going to ignore it for now.
EDIT: I referred to the newer wiki article and copied out arch/arm64/boot/Image as kernel8.img. When booting there is only a single logo at the top (single core). After boot I receive a stream of errors without much content saying "mmc0." I suppose I will try to set up config.txt. In the meantime, any information welcome.
Thanks for the information. With any luck I will get it booting soon.
| NeddySeagoon wrote: | R0b0t1,
I cross compiled everything needed to boot. That's not an entire stage3. Perl and a few other things were missing.
I was not aware of the Gentoo arm64 stage3 and the Raspberry Pi Foundation do not openly support a 64 bit install.
They don't hinder the community working on arm64 for the Pi though.
My arm64 root started out with me banging two stones together 
Its documented in this topic Raspberry Pi 3 - 64 Bit Operation and the wiki page that I have already linked.
There are a lot of references to the Raspberry Pi forums.
There is a script in that forums thread that cross compiles gcc. gcc C is not enough.
You must have C++ too as gcc is now written in C++.
You don't need u-boot any more as that thread describes. The Raspberry Pi bootcode.bin is now 64 bit friendly.
It knows three default kernel names
kernel.img fer the Pi 1
kernel7.image for the Pi 2
kernel8.img for the Pi 3 in 64 bit mode.
Neither do you need a serial console. When I started, that's all the I/O there was. USB was soon added, then Ethernet, which needs USB.
If you use kernel8.img as your kernel name, bootcode.bin sets the Pi into 64 bit mode. If you use another kernel name, you need to set 64 bit mode in config.txt.
Since cross compiling enough to boot and be useful was difficult. I tried the building boot and test with an empty root filesystem.
The kernel messages and panic when root failed to mount was a very welcome sight.
|
It's refreshing to hear I won't need to set some of that up. I had hoped to boot another ARM board of mine headlessly but had enough problems with it I eventually needed to set serial handling up. Thankfully the Raspberry Pi is better supported.
Unfortunately, having built a kernel from the 4.10.y (?) branch cloned from the foundation's website I can't get my board to boot using it. It halts at the rainbow screen. The kernel I moved to /boot was the vmlinux located in the top level of the kernel source - having inspected the filetype of the provided kernels, I attempted to make the zImage, but was informed that a rule to make it didn't exist. What type of kernel did you end up using?
EDIT: Bash will autocomplete a make target of bzImage but there is no rule for it.
I was also informed that my version of ld did not support --fix-cortex-a53-843419. I am using GCC 4. Should I upgrade to ~amd64 to build the cross chain, or does it not matter?
| NeddySeagoon wrote: |
In the end, I had to set CXX in my cross make.conf so build systems could find the cross C++ compiler.
Here's my cross make.conf
That CXX is a nasty hack. Its version dependent and it points to the wrong version now. I'm on gcc-6.3.0
The bare minimum you need in the root filesystem is
| Code: | $ lddtree /bin/bash
/bin/bash (interpreter => /lib64/ld-linux-x86-64.so.2)
libreadline.so.7 => /lib64/libreadline.so.7
libncurses.so.6 => /lib64/libncurses.so.6
libdl.so.2 => /lib64/libdl.so.2
libc.so.6 => /lib64/libc.so.6 |
Thats a dynamically linked bash and all its dependencies.
That will let you boot with init=/bin/bash. I ran that on an amd64 box. The interpreter name will be incorrect.
All you will have is bash but its still a good test case. |
Great, a bit more minimal than I had envisioned but I suppose it's worth trying. I will need to pull the part out of genkernel that copies dependencies listed by ldd again. Well... once I build a kernel, that is. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Tue Feb 14, 2017 11:47 am Post subject: |
|
|
R0b0t1,
| Quote: | | Unfortunately, having built a kernel from the 4.10.y (?) branch cloned from the foundation's website I can't get my board to boot using it. It halts at the rainbow screen. |
Check the partition type on partition1 on the microSD card. The Pi does. It sticks at the rainbow if its not FAT32. FAT16 may work too.
| Code: | Device Boot Start End Sectors Size Id Type
/dev/sdk1 * 2048 264191 262144 128M b W95 FAT32
/dev/sdk2 264192 4458495 4194304 2G 82 Linux swap / Solaris
/dev/sdk3 4458496 15523839 11065344 5.3G 83 Linux |
| Quote: | | EDIT: Bash will autocomplete a make target of bzImage but there is no rule for it. |
Run make and use Image file in arch/arm64/boot Its about 12M and not compressed.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Thu Feb 16, 2017 1:47 am Post subject: |
|
|
Thanks,
I have something which boots now. The partitions are:
- /dev/sda1, /dev/mmcblk0p1 - FAT32.
- /dev/sda2, /dev/mmcblk0p2 - ext4 (was f2fs).
- /dev/sda3, /dev/mmcblk0p3 - swap.
Unfortunately after boot I receive a series of messages, repeating forever:
It is hard to discern what comes before those messages.
When the root partition was f2fs and I set rootfstype to f2fs, it would fail to find the f2fs filesystem. When removing the rootfstype flag it apparently was able to mount the filesystem properly and I received the same output. Moving to ext4 hasn't solved the issue though now rootfstype as ext4 is accepted. Any suggestions? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Thu Feb 16, 2017 10:10 am Post subject: |
|
|
R0b0t1,
Do you have a selection of microSD cards to test?
I used 8G an 32G HC-I cards all Sandisk and a couple of different 64G XC-I cards.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Thu Feb 16, 2017 5:40 pm Post subject: |
|
|
| NeddySeagoon wrote: | R0b0t1,
Do you have a selection of microSD cards to test?
I used 8G an 32G HC-I cards all Sandisk and a couple of different 64G XC-I cards. |
I do have a 32GB Samsung EVO card which works properly that I was booting the ARM32 stage3 off of. The card which fails is a 128GB Samsung PRO+. If you think this makes a difference I will obtain a smaller card and try tonight (or install the kernel alongside the 32 bit OS, but I'd prefer to keep that installation intact). I'm able to access the full contents of the card via a USB to SDHC converter as well as boot Sakaki's Gentoo image off of that card.
If I remember correctly the SDHC card slot on the board is connected to a built in memory controller which may have address limitations, but it doesn't seem like it is an issue.
EDIT: Taking Sakaki's image and swapping its kernel for mine causes the RPi3 to hang on the rainbow screen. What? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Thu Feb 16, 2017 9:14 pm Post subject: |
|
|
R0b0t1,
Are you switching the Pi to 64 bit mode or naming your kernel kernel8.img?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Thu Feb 16, 2017 10:15 pm Post subject: |
|
|
| NeddySeagoon wrote: | R0b0t1,
Are you switching the Pi to 64 bit mode or naming your kernel kernel8.img? |
Yes. It's named kernel8.img. Here is what I was about to post to Sakaki's thread, but figured would be best placed here to avoid cluttering it:
There is something missing from the instructions given. I had the idea of recompiling my kernel and placing it in Sakaki's image. With the provided config.txt it fails to boot. When that is renamed or deleted my kernel will boot to Sakaki's userland. If I create my own /boot from the freshly cloned repository at https://github.com/raspberrypi/firmware I receive the mmc0 line and what looks to be some low-level hardware error messages and there is only one core active.
To reiterate, that same kernel booted when placed in Sakaki's boot with all four cores active to a desktop. Unfortunately the mouse (or input in general) didn't work. If it's true his kernel is simply configured with "make bcmrpi3_defconfig" and the change to the frequency governor I am terribly confused by both results I encountered.
What might be missing from my /boot or / that would lead to the repetitive errors and only one core being enabled? Based on the lack of SMP I take it must be very early in the boot process.
EDIT: I saved Sakaki's /boot from the last time I had imaged one of my SD cards. The difference is within /boot and thankfully doesn't involve modules on /. I'm going to see if I can find any differences. Booting without a valid / gives me a kernel stack trace involving fork, which I suspect means it tried to execute the init script. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54588
Location: 56N 3W
|
| Posted: Thu Feb 16, 2017 10:35 pm Post subject: |
|
|
R0b0t1,
https://github.com/raspberrypi/firmware provides a 32 bit dtb file. The contents of this are quite different from the 64 bit one you get from building your own kernel.
You must use your 64 bit one for correct 64 bit operation.
In the guide you rename the original 32 bit one.
Look in raspberrypi_sources/arch/arm64/boot/dts/broadcom/bcm2710-rpi-3-b.dts. All it is is | Code: | #define RPI364
#include "../../../../arm/boot/dts/bcm2710-rpi-3-b.dts"
|
Just a define and an include pointing to the 32 bit bcm2710-rpi-3-b.dts, which is full of conditionals controlled by RPI364.
Its a bit of a hack and upstream do it properly by having a different dts file name.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
R0b0t1
Apprentice
Joined: 05 Jun 2008
Posts: 264
|
| Posted: Fri Feb 17, 2017 2:19 am Post subject: |
|
|
NeddySeagoon,
Thanks, some combination of carelessness and switching screens every couple of minutes must have let me let myself miss that. It's mostly booting now. In retrospect the behavior makes a lot of sense knowing now that I forgot to provide the device tree file.
Currently the issue I'm experiencing is that boot hangs after enumerating the attached devices and initializing the random number generator. Unless anyone has more specific suggestions I'm going to be playing with config.txt to see if video configuration is hanging the boot (granted I don't see how it would be) or something similar.
EDIT: Adding a cmdline.txt and config.txt per this guide has given me no success. Enabling the video core causes boot to hang on the rainbow screen, and I must leave hdmi_drive unset as my monitor does not support audio and refuses to decode a signal with audio embedded in it.
But, having checked, I am proud to report that / is now detected. My next plan of action is to see if init runs and does nothing or if I need to install an init system. Having done (most of) this process for an ODROID-XU I don't remember needing to install an init system as @system should have it, and it should therefor be in the .tar.xz I made of /usr/aarch64-unknown-linux-gnu.
EDIT 2: It seems since originally mentioning the lack of a signed DIGESTS for the experimental stage3 for arm64 one has been provided (or I missed seeing it the first time...?). Having put that on / the system boots successfully! I am also able to use the video core, or, at least, enable it in config.txt after copying the modules over.
I am still annoyed that I apparently missed something. Can anyone give me pointers on where to look?
EDIT 3: Having just configured the 64bit system on the SD card, I realized OpenRC may in fact have been left out. The arm64 version had blockers and I had removed the global ~arm64 keyword. Switching the package to the unstable version seems like it may have fixed it. I will back up the changes I made a check again later tonight. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
