#linuxcnc-devel Logs

May 31 2020

07:49 AM jepler: Tom_L: thanks! I wouldn't expect the perf to be any different than the last image, the kernel is the same.
08:00 AM jepler: What is exciting about this iteration is that all the debian packages are installed via apt-get, rather than direct download. Which means it's easier (but not trivial, due to the conflicts: raspberrypi-kernel of our kernel package) for someone else to set up a pi without the image.
08:03 AM jepler: (and it's preconfigured to get packages from linuxcnc.org and buildbot)
08:05 AM cerna: Weren't some other pieces of hardware of armhf/aarch64 architecture in buildbot? I distinctly remember photos of Odroids.
08:06 AM jepler: there used to be an odroid (c3) on buildbot but that was years ago.
08:06 AM jepler: I don't think there's been an aarch64 machine on buildbot
08:07 AM jepler: due to the 8gb model pi4 I expect to be looking into at least aarch64 kernel, but probably with raspbian userspace
08:07 AM jepler: which is "demented armhf" as you know
08:17 AM cerna: Well, then I probably confused it with something else. I have been leaning more to the standard Debian or Alpine, so "demented armhf" goes beside me.
08:19 AM jepler: okay.
08:20 AM jepler: Debian's "armhf" architecture indicates a specific ABI. Raspbian designates their architecture "armhf" but it is not the same ABI as Debian
08:21 AM jepler: This is due to the fact that the earliest pi were not "armhf" compatible, but the performance of the compatible debian architecture "armel"
08:22 AM jepler: some pi sold today, notably the pi zero, are still not compatible with the debian abi
08:22 AM jepler: this means basically that you can't support raspberry pi and non-rpi systems with the same binary package
08:27 AM cerna: Hmm, Odroid C3 is A72, which is armv8, so aarch64. Thank you for the explanation. As far as I know, the armel and armhf are similar in instruction set but not similar on the ABI level.
08:29 AM cerna: The question is, I think, if you necessarily need to support all Pis in one package. Cross-building is breeze in post-stretch debian.
08:43 AM jepler: I'm reasonably confident the Odroid C3 had an armhf userspace running on it
08:44 AM jepler: I may have the model wrong. Maybe it was Odroid U2
08:46 AM jepler: wrong over and over again. it was this one https://www.hardkernel.com/shop/odroid-u3/
08:46 AM jepler: Samsung Exynos4412 Prime Cortex-A9 Quad Core 1.7Ghz with 1MB L2 cache
08:48 AM jepler: What workflow do you follow when cross-building an armhf package on amd64 (say)? I have a workflow that uses qemu, but my AMD Ryzen 7 3700X is not faster than my pi4, due to the qemu overhead.
08:50 AM jepler: our ./configure is sure not cross-build friendly, patches welcome.
08:54 AM jepler: > Raspbian builds a single image for all of the Raspberry families, so you will get an armhf 32-bit, hard floating-point system, but built for the ARMv6 ISA (with VFP2), unlike Debian's ARMv7 ISA (with VFP3) port.
09:26 AM cerna: So far (when one doesn't want to use sbuild and friends) I tried the best the Docker + crossbuild-essential-armhf (which will take in the GNU compilers) + multiarch of needed packages + build profiles in debian/control file. However, I don't think it would work generally for LinuxCNC - given the need for old distributions. It works fine in Buster.
09:28 AM jepler: how do build profiles help? is there a pull request, if it's applicable in general?
09:35 AM cerna: Not much, probably. But it has to do with translation of build depends: https://wiki.debian.org/CrossTranslatableBuildDeps#A3._Use_restriction_syntax_with_new_namespace And no, no pull so far.
09:39 AM jepler: that page is dated 2014, did they settle on an approach?
09:41 AM cerna: I have no idea. That's why the build-profiles looked sanest to me.
10:02 AM skunkworks: is there a buster/linuxcnc livecd somewhere? I have not been keeping track of the work
10:05 AM jepler: skunkworks: not that I'm aware of
10:06 AM Tom_L: just the debs from buildbot
10:13 AM jepler: somewhere during the buster cycle I looked and it seemed they had re-done the live+installer image generation entirely, so my work from stretch wouldn't apply. I didn't look again since then.
10:15 AM Tom_L: is there still the issue with the lib for gmoccapy, gscreen?
10:18 AM jepler: unless someone has done something
10:20 AM skunkworks: Thanks
10:20 AM skunkworks: I am fine with stretch..
10:21 AM jepler: The best path for things relying on removed libraries is to rewrite them. The expedient path would be to rebuild stretch-or-older packages on buster and arrange for them to be served from linuxcnc.org.
10:22 AM jepler: the coward's path would be to remove the UIs altogether which don't work on current systems
10:24 AM skunkworks: heh
11:59 AM skunkworks: heh - poor peter.. 5i25_SKUNKWORKS_PWMD.bit
12:13 PM jepler: 5i25_HELP_IM_TRAPPED_IN_A_FIRMWARE_FACTORY.bit
12:15 PM skunkworks: sometimes you need to visualize.. http://electronicsam.com/images/greenmachine/IMG_20200531_120134.jpg
12:16 PM jepler: so far no luck getting booted to the desktop via USB hard drive. After upgrading to the beta firmware and installing some updated raspberrypi-bootloader files on the target it does boot but it seems to be getting disk errors and never reaches the desktop.
12:17 PM jepler: I've used this USB enclosure but not this disk as ~/src on a pi and had no trouble
12:19 PM skunkworks: I only did it once. And that was needing the sd card still.
12:20 PM skunkworks: I know when I did it - I read that only certain usb-ssd converters seemed to work
12:20 PM jepler: [1645021.904665] sd 10:0:0:0: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
12:20 PM jepler: [1645021.904671] sd 10:0:0:0: [sdb] tag#10 CDB: Read(10) 28 00 01 7e 08 80 00 00 80 00
12:20 PM jepler: [1645021.964805] scsi host10: uas_eh_device_reset_handler start
12:20 PM jepler: (but it doesn't recover)
12:28 PM jepler: yes I had set usb storage quirks on the system where I was successfully using it...
12:28 PM jepler: now it boots to desktop, yay.. I ordered another same-brand USB converter, boo
12:28 PM jepler: I'd have jumped brands if I'd remembered this when buying another enclosure
12:30 PM skunkworks: jepler: what changed (that it boots now)
12:31 PM jepler: well now I'm not confident
12:31 PM jepler: I added this to /boot/cmdline.txt: usbstoragequirks=0080:a001:u
12:31 PM skunkworks: wow
12:31 PM jepler: but it's spelled wrong, it's usb-storage.quirks=
12:31 PM jepler: https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt#L5280
12:34 PM jepler: and because of the bootloader fiddling my system now has broken packages. good thing this is a throwaway.