| rrq | building "arm" i stoo hard for me .. (whether cross-compiling or on an armhf filesystem) .. the source includes some aarch64-special opcodes where I would need to learn the inner workings too deeply to device armv7 alternatives. | 01:23 |
|---|---|---|
| rrq | I'm now exploring the path of building an arm64 u-boot with legacy kernel loading .. though having random crash issues with gcc 14.2.0 :( | 01:27 |
| gnarface | hmm, i thought that between having the right cross-compilation flags and the right settings in u-boot's menuconfig it should work | 01:30 |
| gnarface | but also, gcc 14 really already? | 01:30 |
| gnarface | i think i last tried this between gcc 7.x something and gcc 9.x something, and i know for sure it didn't work on any version of gcc earlier than that, so maybe it's just a gcc glitch again? cross-builds seem hard... | 01:31 |
| gnarface | what are you setting, specifically, for $ARCH and $CROSS_COMPILE on your make commands? | 01:32 |
| rrq | I'm building on a recent ceres arm64 setup on an amd64, using the "binfmt approach", and thus no ARCH and CROSS_COMPILE arguments | 01:34 |
| gnarface | hmmm | 01:34 |
| gnarface | you might still need to set ARCH | 01:35 |
| gnarface | and also, you will definitely still have had to enable multi-arch inside the chroot (it's a chroot, right?) for arm, (as in arm32) to have all the right stuff | 01:36 |
| rrq | possibly; though "uname -m" says aarch64 so I'd expect that to fool everything | 01:36 |
| gnarface | hmmm | 01:36 |
| rrq | it's a chroot | 01:36 |
| gnarface | i did mine with cross-compiling but for some reason still needed binfmt... | 01:37 |
| gnarface | i might have gotten some steps from conflicting paths there confused, but it still worked, but, also, i was doing a arm64 build | 01:37 |
| gnarface | the thing is, i could have sworn that early on i built arm32 accidentally and didn't figure that out until after first boot, but it's so long ago now i'm not sure... | 01:38 |
| rrq | possibly this problem is because I'm using the "sunxi" branch that has the orangepi_3_lts_defconfig | 01:39 |
| gnarface | ah, maybe | 01:39 |
| gnarface | i just used the regular upstream vanilla u-boot version | 01:39 |
| gnarface | and uh... i forget exactly but something like sun50i_pine64_plus_defconfig? | 01:40 |
| gnarface | and for the OG pinebook i just used pinebook_defconfig (i did this successfully a couple times for different A64 stuff from pine64, but that's the limit of my experience) | 01:40 |
| gnarface | oh... hmm, but those would be in the ./arch/arm64 directory, and there's probably no 32-bit equivalents in the ./arch/arm/ directory... i wonder if that matters | 01:42 |
| gnarface | yea, i used sun50i-a64-pinebook for the OG pinebook and sun50i-a64-pine64-plus for the SoC boards | 01:44 |
| gnarface | this most recent time | 01:44 |
| rrq | I want to build for sun50i-h6-orangepi-3-lts | 01:45 |
| gnarface | so maybe you have to build a 64-bit binary after all and just change menuconfig options to add multiarch support or something | 01:45 |
| gnarface | not sure now | 01:45 |
| rrq | can I tell sun50i-h6-orangepi-3-lts on to make, to focus on that? | 01:46 |
| gnarface | you should be able to | 01:46 |
| gnarface | i seem to have last tested with gcc11 btw fyi, according to my logs | 01:46 |
| gnarface | three steps: 1) make sun50i-h6-orangepi-3-lts 2) make menuconfig 3) make -j4 | 01:47 |
| gnarface | on my cross-build environment i also set ARCH and CROSS_COMPILE of course | 01:47 |
| gnarface | ARCH="arm64" CROSS_COMPILE="aarch64-linux-gnu-" make pinebook_defconfig | 01:47 |
| gnarface | (old notes) | 01:48 |
| gnarface | is it possible you neglected to build the arm trusted firmware and copy the right file from there into the u-boot source tree first? | 01:48 |
| rrq | hmm "make sun50i-h6-orangepi-3-lts" complains about missing targte | 01:48 |
| gnarface | is it possible you neglected to build the arm trusted firmware and copy the right file from there into the u-boot source tree first? | 01:48 |
| gnarface | from my notes, i used $BUILDROOT/build/sun50iw1p1/release/bl31.bin but that's hardware specific | 01:49 |
| rrq | ah.. I did build that on the armhf trial(s) . but now forgot about it for the arm64 trials... thanks | 01:49 |
| * rrq back to trials... | 01:50 | |
| gnarface | you should have to copy some file from there, and it probably also has to be built to the right arch, i assume | 01:50 |
| gnarface | what's the point of what you're trying to do here? you should be able to just boot aarch64 devuan on that hardware and use multi-arch for any 32-bit stuff you need... | 02:11 |
| gnarface | multi-arch works on the pine64 stuff, i assume it should work on those too | 02:11 |
| rrq | yes I have an aarch64 devuan but I want to have it run armhf (aarch32) kernel as well as filesystem | 02:18 |
| rrq | (to be an armhf/armel build host) | 02:19 |
| gnarface | ah, i see | 02:19 |
| rrq | now a I also wonder whether there's an EFI load path with a 64->32 load wrapping | 02:20 |
| rrq | (will explore when my current trial path fails) | 02:36 |
| rrq | .. I changed to use gcc-12 (-t daedalus) and still have the random segfaults; most likely not due to gcc itself, but rather to me running arm64 on amd64 (through binfmt) | 06:40 |
| gnarface | did you maybe accidentally use a amd64 rootfs in the chroot instead of an arm64 one? i did that by accident once and i think the result was lots of segfaults... | 08:49 |
| rrq | no, but it was a ceres; I now will use the arm64 on the pi3 for building my own u-boot; I got it going by reusing the first 4M of the debian image, but I haven't found the source of that u-boot | 10:55 |
| rrq | that u-boot doesn't include bootz and I'm generally unsure about it | 10:56 |
| rrq | that will be a daedalus (debootstrap) | 10:58 |
| rrq | actually the debian image u-boot is within 1M; the 4M includes a blanked out gap of the u-boot's FAT | 11:00 |
| rrq | (I guess) | 11:00 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!