adhoc | Tenkawa: why is there currently an issue ? | 02:32 |
---|---|---|
adhoc | morning all | 02:32 |
tuxd3v | good morning adhoc | 02:33 |
Tenkawa | adhoc: it's not currently working | 02:36 |
adhoc | ok | 02:36 |
Tenkawa | arm64 to armel crosscompiple has to be done kinda creatively in the kernel install stages | 02:37 |
Tenkawa | I've aleady tested it successfully in debian | 02:37 |
Tenkawa | working on getting it clean in devuan | 02:37 |
Tenkawa | s/crosscompiple/crosscompile/ | 02:38 |
tuxd3v | Tenkawa, I still do amd64 crosscompile to armel | 02:40 |
Tenkawa | x86 works fine... this is arm64 to armel | 02:41 |
Tenkawa | which is for the automated builds | 02:41 |
tuxd3v | I believe a different crosscompiler needs to exist | 02:42 |
Tenkawa | it is.. llvm | 02:42 |
tuxd3v | ho, you are using llvm :) | 02:42 |
Tenkawa | tuxd3v: this is what I did most of my career | 02:43 |
Tenkawa | wish we had these tools back when I was still working | 02:44 |
tuxd3v | probably you will need to compile llv for that, you is there any crosscompilers already availlable? | 02:45 |
tuxd3v | llvm* | 02:45 |
Tenkawa | tuxd3v: nope.. everything we need is already there | 02:45 |
tuxd3v | ho, nice :) | 02:46 |
tuxd3v | I am still using gcc | 02:46 |
Tenkawa | like I said... I've already got debian fixed... I'm about 3/4 done with devuan | 02:46 |
Tenkawa | devuan's had links in /etc/alternatives that were causing a problem | 02:47 |
tuxd3v | I never compiled with llvm a kernel | 02:48 |
tuxd3v | but I know its possible now | 02:48 |
Tenkawa | the arm64 build machine creates a custom armel chroot and builds the entire image inside it with the builder | 02:48 |
tuxd3v | nice | 02:49 |
Tenkawa | not "quite" as fast as native arm64 but still faster than x86 | 02:49 |
Tenkawa | going to run more tests over the next couple of days before I give it the complete "go" | 02:50 |
tuxd3v | :) | 02:50 |
Tenkawa | have 2 rpi4's standing by to install and test it on | 02:50 |
Tenkawa | and a bunch of zeros | 02:51 |
Tenkawa | to run it on | 02:51 |
Tenkawa | (i'm building it on an odroid right now) | 02:51 |
tuxd3v | I don't have any zero | 02:52 |
Tenkawa | so I need to move it to a rpi4 to make it rpi to rpi | 02:52 |
Tenkawa | well this is an zero build | 02:52 |
Tenkawa | armel | 02:52 |
Tenkawa | (or modified armhf) | 02:53 |
Tenkawa | foundation modifies armhf code to make it run | 02:53 |
Tenkawa | right now I'm only testing beowulf | 02:54 |
tuxd3v | yeah, the userspace is armel on debian, the rpi foundation has everything I believe compiled with support for floating point .. | 02:54 |
Tenkawa | yeah.. in theory I can make it armhf although I will have to modify the make I think to do that | 02:55 |
Tenkawa | I believe when I ran ps it was running a softfp build | 02:55 |
Tenkawa | but for proof of concept test thats fine | 02:55 |
tuxd3v | it will be a lot of trouble, as you needed to recompile the entire userspace with floating foint support, too much work | 02:56 |
Tenkawa | no.. it is pulling the same devuan userland | 02:57 |
Tenkawa | the kernel is the only thing that needs to be redone | 02:57 |
tuxd3v | I compile the kernel and its armhf | 02:57 |
tuxd3v | its the only thing | 02:57 |
tuxd3v | kernel, headers, and libc-dev | 02:57 |
Tenkawa | yes ... armel defaults are not armhf.. thats why I may need to force the change for the kernel | 02:58 |
tuxd3v | the rest, I get from the repos :) | 02:58 |
Tenkawa | not hard to do.. just have to add a flag to the build scrippt | 02:58 |
Tenkawa | I think I can actually do it in the kernel config itself | 02:59 |
tuxd3v | at least with gcc, if you have a version that suports hfloat, I believe it already compiles as hfloat | 03:00 |
tuxd3v | its in that way, in the kernel sources | 03:01 |
Tenkawa | gcc gets called from clang... llvm wraps the necessary things needed though to handle the multiple architectural difficulties | 03:02 |
Tenkawa | it makes things "much" less complicated | 03:02 |
Tenkawa | it is a bit slower at compile time though | 03:03 |
tuxd3v | I still need to check were can I change that, but its probably in the defconfig file | 03:05 |
tuxd3v | CONFIG_VFP=y | 03:05 |
Tenkawa | tuxd3v: you around? | 18:30 |
tuxd3v | Tenkawa, yes I am :) | 18:31 |
Tenkawa | we almost have it and it is going to be even easier to run pi zero builds on arm64 | 18:31 |
Tenkawa | just builder changes.. thats it | 18:32 |
Tenkawa | just got finished testing the image part.. need to test runtime part | 18:32 |
Tenkawa | won't need the chroot setup or any of the extra setup | 18:33 |
Tenkawa | I just needed to debug why it was forcibly calling the wrong architecture | 18:34 |
tuxd3v | nice | 18:34 |
Tenkawa | once we found out why we figured out where to add the fix | 18:34 |
Tenkawa | already built an image both with gcc and with clang | 18:35 |
Tenkawa | haven't tested either yet but they wouldn't even build before | 18:35 |
tuxd3v | that is an improvment | 18:35 |
Tenkawa | indeed | 18:35 |
tuxd3v | how are you compiling the kernel? | 18:36 |
tuxd3v | I use a script, for that | 18:36 |
Tenkawa | everything is through the builder | 18:36 |
c0rnelius | adam_free2air: I believe this is fixed now - https://github.com/pyavitz/rpi-img-builder/issues/29 | 18:39 |
c0rnelius | Although I haven't made the changes to the debian branches | 18:39 |
tuxd3v | Tenkawa, yes but to build the deb packages I use 'scripts/package/mkdebian' | 18:57 |
tuxd3v | it determines if the package is armhf or armel, based on the content of 'include/config/auto.conf' | 18:57 |
tuxd3v | he searches for 'CONFIG_VFP=y' in 'auto.conf' | 18:59 |
tuxd3v | based on that he build armhf or armel :) | 18:59 |
c0rnelius | The problem we were having was cross compiling v7 and v6 kernel on a v8 host. | 19:03 |
c0rnelius | Although they would install fine on a running machine, the kernels would fail during the header clean up and recompile cycle inside the builder. | 19:04 |
c0rnelius | It would appear just forcing a ARCH=arm into the process corrects the issue. | 19:04 |
c0rnelius | So basically one would no longer need to use x86-64 for cross comps. Could just build everything from a ARM64 host. | 19:06 |
tuxd3v | that is nice | 19:07 |
tuxd3v | but you don't need proper compilers on arm64 for that? | 19:08 |
c0rnelius | Arm64 provides cross compilers | 19:08 |
c0rnelius | armhf on the other hand does not. | 19:08 |
c0rnelius | At least last time I checked? But who would bother crossing anything on armhf anyway. | 19:09 |
tuxd3v | so you can compile in arm64 for armel or armhf? | 19:09 |
c0rnelius | yeap | 19:09 |
c0rnelius | just did so. | 19:09 |
tuxd3v | nice | 19:09 |
c0rnelius | I'm building for armhf right now to make sure its clean. But armv6 for sure works 100% | 19:09 |
c0rnelius | So I'm going to assume this is gonna be fine. | 19:10 |
tuxd3v | :) | 19:10 |
c0rnelius | I'm building a rtl8812au wifi module right now on a pizero that was compiled on a arm64 box. | 19:12 |
c0rnelius | So far, no errors. | 19:12 |
c0rnelius | To bad it takes forever with one core. | 19:12 |
tuxd3v | yeah those cores are a lot slower :) | 19:15 |
c0rnelius | success | 19:16 |
c0rnelius | LD [M] /home/patrick/rtl8812au/88XXau.o | 19:16 |
c0rnelius | MODPOST /home/patrick/rtl8812au/Module.symvers | 19:16 |
c0rnelius | CC [M] /home/patrick/rtl8812au/88XXau.mod.o | 19:17 |
c0rnelius | LD [M] /home/patrick/rtl8812au/88XXau.ko | 19:17 |
c0rnelius | make[1]: Leaving directory '/usr/src/linux-headers-5.10.52' | 19:17 |
tuxd3v | nice! | 19:17 |
tuxd3v | c0rnelius, do you have also the kernel source packages built on the pizero | 22:54 |
tuxd3v | or you just the default tar.gz format of the souces from mainline? | 22:55 |
tuxd3v | I mean to compile your kernel module :) | 22:56 |
c0rnelius | I don't run debpkg to also build then source deb, nor for the pi kernels do I use mainline unless I have a specific reason to do so. I pull foundation sources. | 23:25 |
c0rnelius | aria2c https://github.com/raspberrypi/linux/archive/refs/heads/rpi-5.10.y.tar.gz | 23:26 |
c0rnelius | Change the 5.x.y to pull the source. Thats what the builder does. | 23:27 |
c0rnelius | then/the* | 23:27 |
c0rnelius | The only SoC that Raspberry Pi has that I allow in the builders to pull from mainline is bcm2711. | 23:29 |
c0rnelius | The rest seem like a pointless venture. Unless ur goal is to have a have ass kernel running on the board. | 23:30 |
c0rnelius | have a half* | 23:31 |
c0rnelius | can't type, sorry. | 23:31 |
Tenkawa | what did I miss> | 23:39 |
Tenkawa | er ? | 23:39 |
Tenkawa | (was updating patches) | 23:39 |
c0rnelius | probably nothing | 23:39 |
Tenkawa | I looked up more info on the arm float details... raspbian is the only distro out there compiling armhf with hard float currently | 23:41 |
Tenkawa | (at least well known) | 23:42 |
c0rnelius | They are the only one as far a I know | 23:42 |
c0rnelius | it was made specific, which is why when the pi4 came out they changed the name of the distro. the people behind it don't support arm64 and the name changed happened when the foundation decided to move on. | 23:43 |
Tenkawa | the compiler uses extensions that arent avail in all other compilers | 23:45 |
c0rnelius | I'm pretty sure the people behind Raspbian aren't really on the payroll of the Foundation so it became a problem. | 23:45 |
Tenkawa | on top of arm1176 | 23:45 |
c0rnelius | If it was easy the Ubuntu boys would support it. :) | 23:45 |
Tenkawa | clang can't use them | 23:46 |
Tenkawa | I tried earlier | 23:46 |
c0rnelius | Yeah Raspbian is a frankien build of sorts | 23:46 |
Tenkawa | it doesn't support the cpu mode | 23:47 |
c0rnelius | It worked in the foundations favor because the userland is still shit. | 23:47 |
Tenkawa | you get this: | 23:47 |
Tenkawa | clang: error: the clang compiler does not support '-mcpu= "arm1176jzf-s' | 23:47 |
Tenkawa | gcc does with the right rebuilding | 23:48 |
Tenkawa | thats why raspbian can work | 23:48 |
Tenkawa | I'm sure clang "could"... | 23:48 |
c0rnelius | This is why Peter is asking to much. | 23:49 |
Tenkawa | but it would have to be made to | 23:49 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!