- CRUX-ARM - lists.crux-arm.nu

Crux-arm 64 bits nearly done for Odroid C2
by Thierry Moreau 03 May '18

03 May '18

Dear happy few Crux fans, As hinted in a previous post, I installed the generic Crux ARM 64 bits root fs image (RC2) on a MicroSD partition having booted the ArchLinux O/S image (as a shortcut for u-boot installation). It is now working except for a strange behavior for the agetty (or any other process) output to /dev/tty1 USUALLY does not show up on the hdmi display, but SOMETIMES works fine. It worked on two occasions, but I am unable to identify a causal pattern (at first a cable handling sequence seemed at stake). I have ssh access to the system for troubleshooting. The HDMI connection is working coherently in the following sense: the EDID information is indeed reflected in /sys/devices/virtual/amhdmitx/amhdmitx0/edid and when I change the HDMI parameters, the display (a 7 in. camera monitor sold in the professional video market) indeed reports the change in a temporary pop-up tile (in the otherwise blank screen). I.e. the HDMI parameter change is effected by echo -n 480i60hz >/sys/devices/virtual/amhdmitx/amhdmitx0/disp_mode and then echo -n 480p60hz >/sys/devices/virtual/amhdmitx/amhdmitx0/disp_mode (change from 480i to 480p). I will refer to the Hardkernel/Odroid community forum for help and I will keep the Crux arm list informed. Regards, - Thierry Moreau

2 2

Some interest in Crux-arm64
by Thierry Moreau 20 Apr '18

20 Apr '18

Hi! The Odroid C2 Arm64 SBC is getting some attention these days. Its video capability seems to be a driver for some decent shelf life at our local distributors. If one whishes integrated WIFI plus SATA in the Arm64 world, ASUS has the Tinker Board S, see https://www.asus.com/us/supportonly/Tinker%20Board%20S/HelpDesk_Download/ I am working towards Crux-arm64 on the OdroidC2, having a cross-compiled Linux kernel (3.16) booting either Ubuntu or ArchLinux. Crux is the only distribution I self-support for X86 devices. I "git cloned" much of crux-arm.nu/gitweb. I have a previous experience of re-packaging Crux X86-64 (basically to make a "features-lean" system such that security-wise, the attack surface is reduced). In this new Arm64 project, I might be able to contribute back to the crux-arm.nu contents. Any useful tip, suggestion, or comment? Regards, - Thierry Moreau

3 8

ldconfig fires unknown machine 40
by Michael Etscheid 17 Apr '18

17 Apr '18

Sorry for sending first e-mail html formated... Hello, I started translating the packages from the crux-arm project. 1st ToolchainSetup was OK 2nd PkgutilsCross was OK 3. buildingPackages returns the error messages "/sbin/ldconfig: /lib/libm.so.6 is for unknown machine 40." after compiling glibc. Once the /etc/ld.so.conf file exists in the toolchain directory, pkgadd calls ldconfig, which fails. I found hints on the Internet that from version 2.16 ldconfig no longer accepts the libraries of type EM_ARM if it was compiled for X86 and ejects the error messages from above. What is the recommended procedure? Do I need a compile environment with glibc < 2.16 or is there an adaptation for glibc 2.23/2.24, so that ldconfig also supports libraries of type ARM. Thanks Helmut

2 1

*****SPAM***** ldconfig fires unknown machine 40
by Michael Etscheid 30 Mar '18

30 Mar '18

1 0

[patch] glibc: updated to 2.24-10
by Fredrik Rinnestam 29 Jan '18

29 Jan '18

patch attached -- Fredrik Rinnestam

2 1

Re: [crux-arm] setup chromium - [1:1:0100/000000.534166:ERROR:broker_posix.cc(41)] Invalid node channel message
by Victor Martinez 05 Sep '17

05 Sep '17

* Milan Bu??ka (milan.buska(a)gmail.com) wrote: > Hi Victor > > 2017-06-28 10:46 GMT+02:00 Victor Martinez <pitillo(a)crux-arm.nu>: > > * Milan Bu??ka (milan.buska(a)gmail.com) wrote: > >> 2017-06-26 16:16 GMT+02:00 Milan Bu??ka <milan.buska(a)gmail.com>: > >> > Hello everyone > >> > > > Hey Milan, > > > >> > After 10 hours of compiling Chromium 59.0.3071.109, I get a message > >> > after running: > >> > > >> > [1: 1: 0100 / 000000.534166: ERROR: broker_posix.cc (41)] Invalid node > >> > channel message > >> > > >> > Does anyone know if it is going to fix it or it is for a new recompilation. > >> > > >> > Note: > >> > The compilation was done for the "ARM" architecture, so I apologize in > >> > advance for sending > >> > this message to the mailing list (lists.crux.nu). > >> > Maybe this is not an architecture-specific error. > >> > >> Repair > >> > >> > I attach a link to broker_posix.cc > >> > https://chromium.googlesource.com/chromium/src/+blame/refs/heads/master/moj… > >> > >> https://chromium.googlesource.com/chromium/src/+blame/59.0.3071.109/mojo/ed… > >> > >> > Line 41 error > >> > Line 43 "Invalid node channel message" > >> > >> Line 41 "Invalid node channel message" > >> > >> > > >> > Finally - I do not speak the English language so this message has been created > >> > via a google translator - please do not stone me for it > >> > > >> > > >> > > >> > Best regards > >> > > > Here I've built it on the cubieboard2 without problems but I've found at run time some of them. > > > > When I start chromium I can see this error and currently I'm trying to get some time to deep into it: > > > > [13761:13795:0625/150130.122737:ERROR:browser_gpu_channel_host_factory.cc(103)] Failed to launch GPU process. > > Received signal 4 <unknown> 0000b373284a > > > > Not many time recently to figure out what's happening, but I'll try to update this thread if I find something interesting. > > > >> > Milan Buska > >> > > Regards, > > > > Thank you for answer. > > I used CFLAGS when compiling > - CFLAGS="-O2 -pipe -march=armv7ve -mtune=cortex-a15 -mfpu=neon > -mfloat-abi=hard -mabi=aapcs-linux -marm -mtls-dialect=gnu" > CXXFLAGS="${CFLAGS}" > > I try to change > - CFLAGS="-O2 -pipe -march=armv7ve -mtune=cortex-a15 -mfpu=vfpv4 > -mfloat-abi=hard -mabi=aapcs-linux -marm -mtls-dialect=gnu" > CXXFLAGS="${CFLAGS}" > > $ cat /proc/cpuinfo > processor : 0 > model name : ARMv7 Processor rev 3 (v7l) > BogoMIPS : 80.01 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls > vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x3 > CPU part : 0xc0f > CPU revision : 3 > > processor : 1 > model name : ARMv7 Processor rev 3 (v7l) > BogoMIPS : 80.01 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls > vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x3 > CPU part : 0xc0f > CPU revision : 3 > > processor : 2 > model name : ARMv7 Processor rev 3 (v7l) > BogoMIPS : 80.01 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls > vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x3 > CPU part : 0xc0f > CPU revision : 3 > > processor : 3 > model name : ARMv7 Processor rev 3 (v7l) > BogoMIPS : 80.01 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls > vfpv4 idiva idivt vfpd32 lpae evtstrm > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x3 > CPU part : 0xc0f > CPU revision : 3 > > Hardware : NVIDIA Tegra SoC (Flattened Device Tree) > Revision : 0000 > Serial : 0000000000000000 > > > Another alternative > > Select a version that does not depend on the nodejs > > I will report with what results. > > Regards > > Milan > > -- Hey Milan, I've made some tests on the last veesion: https://crux-arm.nu/gitweb?p=ports/opt-arm.git;a=commitdiff;h=c4acdcba5460e… and it's working fine now on the cubieboard2. Could you verify in your device and report problems please? Regards, --- Victor Martinez Learning bit by bit | http://vjml.es

2 2

setup chromium - [1:1:0100/000000.534166:ERROR:broker_posix.cc(41)] Invalid node channel message
by Milan Buška 28 Jun '17

28 Jun '17

Hello everyone After 10 hours of compiling Chromium 59.0.3071.109, I get a message after running: [1: 1: 0100 / 000000.534166: ERROR: broker_posix.cc (41)] Invalid node channel message Does anyone know if it is going to fix it or it is for a new recompilation. Note: The compilation was done for the "ARM" architecture, so I apologize in advance for sending this message to the mailing list (lists.crux.nu). Maybe this is not an architecture-specific error. I attach a link to broker_posix.cc https://chromium.googlesource.com/chromium/src/+blame/refs/heads/master/moj… Line 41 error Line 43 "Invalid node channel message" Finally - I do not speak the English language so this message has been created via a google translator - please do not stone me for it Best regards Milan Buska

2 3

Compilation firefox-53.0.2 ends with an error
by Milan Buska 31 May '17

31 May '17

Hi. Compile firefox-53.0.2. /devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/_virtualenv/bin/python /devel/firefox/work/src/firefox-53.0.2/config/expandlibs_gen.py -o libipc_glue.a.desc BackgroundChildImpl.o BackgroundParentImpl.o FileDescriptorSetChild.o FileDescriptorSetParent.o GeckoChildProcessHost.o URIUtils.o Unified_cpp_ipc_glue0.o Unified_cpp_ipc_glue1.o make[5]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/ipc/glue' libdocshell_base.a.desc rm -f libdocshell_base.a /devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/_virtualenv/bin/python /devel/firefox/work/src/firefox-53.0.2/config/expandlibs_gen.py -o libdocshell_base.a.desc Unified_cpp_docshell_base0.o make[5]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf/docshell/base' make[4]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[3]: *** [/devel/firefox/work/src/firefox-53.0.2/config/recurse.mk:33: compile] Error 2 make[3]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[2]: *** [/devel/firefox/work/src/firefox-53.0.2/config/rules.mk:522: default] Error 2 make[2]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2/obj-armv7l-unknown-linux-gnueabihf' make[1]: *** [/devel/firefox/work/src/firefox-53.0.2/client.mk:419: realbuild] Error 2 make[1]: Leaving directory '/devel/firefox/work/src/firefox-53.0.2' make: *** [client.mk:170: build] Error 2 Where can be a mistake ? Regards -- --------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

3 11

Re: [crux-arm] crux 3.3 on aarch64
by Victor Martinez 23 May '17

23 May '17

* Peter Johansson (rossolis8240(a)telia.com) wrote: > Hello Victor! > Hey Peter, > > > > > How did you do that? From cross compilation or deploying the generic aarch63 image? > > It was not so hard, from zero it did take me about 10days (never done any ports before) > I used pi64, a very naked 64bit rootsystem that are based on debian aarch64. > > 1. Booted it on a external usb-disk. (that need separate 5v power) Also added a fan to cool the cpu. > 2. Downloaded build-sysroot and gcc tools from linaro > 3. Compiled gcc 6.3.0 on pc to be used on the target system and with some essential files like "init". > 4. Removed the debian based /etc + debian files and placed crux 3.3 version there instead. > 5. With the compiler in place the "real" work began, to build everything from zero. > Step by step new programs were built, for example linux-utils,pkg-utils > We work in a different way. We start from scratch at cross compiling level. We genererate a crossrootfs and then we deploy it to the powerfull machine where we rebuild core ports collection natively with generic CFLAGS in two stages (two passes). After this, we have a rootfs to deploy to any compat device and let users optimize their devices or run a generic build. All these steps are a bit explained here [1] and [2]. > > > Got X11 to work yesterday with fbturbo. > > > Been very stable all the time. > A note, crux 3.3 default xorg-libpixman are buggy on aarch64, X11 did freeze are a short while. > The latest pixman (35.1 git) will solve that. > I should make some tests and provide an overlay for aarch64 then. Thank you for the info. > Now everything work just fine. > > > > Added this to the Pkgfile to be able to make some packages (aarch64 unknown) > > > > > > sed 's/abacus)/aarch64)/g' -i config.sub > > > sed 's/abacus-unknown/aarch64-linux/g' -i config.sub > > > > > > ./configure --prefix=/usr --build=aarch64-linux-gnu > > > > > Thank you very much for the information provided. I've faced the build arch problem and > > some specific ports related to aarch64 too. > > I did discover there is need of a third line to (some x11 packages need it) > Add sed 's/a29k/aarch64/g' > > With them I successfully built the whole system. > > Made a small patch-skript "aap" (cat /root/aa-mod.txt >> Pkfile; mcedit Pkgfile) > Moved the lines in place with mcedit > All done in seconds :) > Taking note to read about the a29k detail. > > We have ready a generic release for aarch64 [1] and another optimized one for the pine64 [2]. > > In both cases we try to keep near CRUX and specally with everything related to the toolchain. > > Currently we provide gcc 6.3.0 and binutils 2.27 (as CRUX and CRUX-ARM 32b). > > > We don't plan to move far from CRUX in any port version, only for exceptions when we need > > to create a port overlay for specific device needs. > Good idea. Me myself used 7.1.0 because it has (i think) best aarch64 (hard to find)support. > It can be overlayed too, but this will put us far from CRUX and this isn't the idea. May be keep the same version and look for patches or just wait. CRUX-ARM aarch64 is still under development because these reasons (not only toolchain components aren't ready yet for aarch64, there are lot of software, like you told about X11 stuf, not ready/pulished yet). > > Actually we don't have an rpi3 to provide an optimized release nor test the generic one > > on it. Good to know that someone else got CRUX-ARM working on this amazing device. > It is a amazing small board, it perform very well and very cheap to. > > > The xorg fbturbo driver should work just fine, but without providing acceleration. I think, > > at least, it could be great to make a port for /opt/VC and firmware (I had something done > > for the raspberrypi 1 for video playing if I remember right). > > In my system I built mesa3D v17 and libdrm freedreno, however the freedreno failed to start. > It seem like the 3D performance are quite good to, did see on the internet some got quite demanding > 3D games to run, how good I dont know, it will be interesting to find out. > That sounds promising really (currently I'm using the pine64 as a headless server, but I plan to deploy X11 and make some test with the TV soon if I find some spare time). > Working now on getting mplayer to work, it compiles(with some help) but like with many of the other programs, aarch64 not yet > fully supported. In mplayer the float/dsp hardware are not used right. > Too much work ahead for aarch64 architecture... but time to time, there are lot of people working in this "new" architecture. Soon we'll start seeing software ready to be built cleanly on these devices. > Regards > Peter > Regards, [1] https://crux-arm.nu/Documentation/HowDoWeWork [2] https://crux-arm.nu/Documentation/HowToContribute --- Victor Martinez Learning bit by bit | http://vjml.es

1 0

crux 3.3 on aarch64
by Peter Johansson 22 May '17

22 May '17

Hello! In the last few days I have completed a crux-3.3 port on aarch64 (Raspberry Pi 3) Built all packages on it, core, xorg, gcc-7.1.0, binutils-2.28 Got X11 to work yesterday with fbturbo. Been very stable all the time. Added this to the Pkgfile to be able to make some packages (aarch64 unknown) sed 's/abacus)/aarch64)/g' -i config.sub sed 's/abacus-unknown/aarch64-linux/g' -i config.sub ./configure --prefix=/usr --build=aarch64-linux-gnu Regards Peter Johansson

2 1