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

ARM Samsung Chromebook
by Wawrzek Niewodniczanski 18 Aug '19

18 Aug '19

Hi, I had an old, but (when I last check it) still working Samsung Chromebook with ARM chip inside (I think it's that one: https://www.chromium.org/a/chromium.org/dev/chromium-os/developer-informati…, don't have time to check, but Model is XE303C12). I'm happy to give it away for free, for someone ready to do something meaningful with it. Maybe it'll help someone in this group? Wawrzek -- Dr Wawrzyniec Niewodniczański or Wawrzek for short PhD in Quantum Chemistry & MSc in Molecular Engineering WWW: http://wawrzek.name E-MAIL: jobs(a)wawrzek.name Linux User #177124

2 1

CRUX-ARM 3.5 RC1 ready
by Victor Martinez 24 Jul '19

24 Jul '19

Hello all, last week we built first CRUX-ARM 3.5 RC1 images for 32b/64b. http://resources.crux-arm.nu/files/devel-test/3.5/ They are ready to be tested. Feel free to try them and comment. Problems and suggestions are welcome. Regards, --- CRUX-ARM System Team | http://crux-arm.nu

1 0

Aarch64 testing ports.
by Milan Buška 04 Jun '19

04 Jun '19

Greetings to all crux-arm users. I have built ports for aarch64. If anyone has any interest, visit https://github.com/sajcho. I welcome the critical response. With respect Milan -- Remember, no question is too stupid and no problem too small -- We've all been beginners

1 0

Thoughts on Kernel Compiling for ARM
by Robin Krens 19 May '19

19 May '19

Dear CRUX-arm users, developers, Over the last couple months, I have been playing around with CRUX-arm. One of things I noticed is the lack of a handbook or general approach for CRUX-arm. I'm aware of the difference with x86 and that there is no one size fits all solution. It could be the lack of documentation, but I think as of now, CRUX-arm goes against the main CRUX philosophy. The KISS principle, handbook and simple package management are, I think, the strong points of CRUX. For most supported boards, however, it seems it is impossible to redo/retrace the steps, compile a bootloader/kernel and have a basic working system. With "basic working system" here I mean something that boots and has basic funtionality (i.e. networking and usb storage). Referring to the x86 handbook (installation section) it just mentions how to enable some basic options（CONFIG_SATA_AHCI=y， CONFIG_BLK_DEV_SD=y，CONFIG_EXT4_FS=y）to bring up your root filesystem. Maybe your graphics cards or webcam doesn't work. Doesn't matter. CRUX is targeted for the experienced user. They will figure it out. Comparing this to the ARM branch of CRUX, most supported boards just provide a bootloader and kernel image. But I have no idea what these kernels are about. Are these basic configurations? Or are these copies from armbian just to work out of the box? Again, this could be a lack of documentation and misunderstanding on my side. But I would like to see a clearer approach. Maybe some devices on your board don't work, doesn't matter, at least it is more elegant. Again, I think CRUX is for the experienced user. Users that want a fullblown and fast working system, will swander off to armbian anyway. I would like to hear other people's opinions about the above mentioned points. Besides that, I willing to work on a general handbook for ARM. Sincerely, Robin Krens

3 4

[ANN] CRUX-ARM 3.4 Released
by CRUX-ARM System Team 24 Jul '18

24 Jul '18

Hello there, we are pleased to announce CRUX-ARM 3.4 release. Now officially supported 32b and 64b devices: Release notes: http://crux-arm.nu/Documentation/ReleaseNotes3-4 Changelog: http://crux-arm.nu/Documentation/Changelog#3-4 Download: http://crux-arm.nu/Main/Download Best regards, -- CRUX-ARM System Team | http://crux-arm.nu

1 0

I'm basically done with Crux ARM64b on OdroidC2
by Thierry Moreau 05 Jun '18

05 Jun '18

Hi Victor, I'm basically done with Crux Arm64b on Odroid C2. Overall, the Odroid C2 builds packages at circa 2.75 faster than reported times for other arm native builds (I'm not a fan of benchmarks, so not a firm statement against a specific alternative). For opt/xpdf, I changed a dependency from qt4 to qt5, the former being a bit outdated. The build opt/qt5 required a change from -reduce-relocations to -no-reduce-relocations. The build opt/ghostscript required a setting -DPNG_ARM_NEON_OPT=0 in CPPFLAGS because the arm neon optimisation source code requires an assembler source file that is not compliant to arm64 (the error message was less instructional than my root cause explanation). (I wrongly reported that ghostscript has been build.) I forgot to send you my odroidc2-arm64 port collection, which is an adaptation of pine64-arm port collection. Since my project goals are more towards removing packages, protocol support, and other software functions that are not necessary for some specific security-intensive applications, I am not inclined to keep up to date with package revisions. This is the meaning of "I'm basically done." Still, I might make a revision to my document for a section on building Crux packages, but it's not too high on my list of priorities. I wish to thank you and the Crux Arm team for this marvelous Linux distribution preparation methodology. Regards, - Thierry

1 0

build chromium crux-arm
by Milan Buška 05 Jun '18

05 Jun '18

Hello, I have just finished compiling the port of chromium successfully. Pleasant is that there is no need to make any modifications to Pkgfile. As you can see, the crux 3.4/opt/chromium port is fully compatible with crux-arm64 Regards -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 1

Fwd: Definition of release in Pkgfile
by Milan Buška 03 Jun '18

03 Jun '18

---------- Forwarded message ---------- From: Milan Buška <milan.buska(a)gmail.com> Date: 2018-06-02 16:46 GMT+02:00 Subject: Re: [crux-arm] Definition of release in Pkgfile To: Fredrik Rinnestam <fredrik(a)rinnestam.se> Hello. 2018-06-02 15:03 GMT+02:00 Fredrik Rinnestam <fredrik(a)rinnestam.se>: > On Sat, Jun 02, 2018 at 01:14:18PM +0200, Milan Buška wrote: >> Hello. >> >> How do I define the release value in Pkgfile. >> >> Example: >> I have the port xyz - release=1 >> I use four patches in the xyz port - release=4 >> >> I understand it correctly. >> >> Regards >> >> Milan > > $release is just the version of the Pkgfile itself. If you change the > port in some way like changing build-options or adding patches without > the $version chaning - then you should increment the $release. This is > to differentiate the port. > > > -- > > Fredrik Rinnestam > _______________________________________________ > crux-arm mailing list > crux-arm(a)crux-arm.nu > https://crux-arm.nu/mailman/listinfo/crux-arm crux firefox port => version=60.0.1 release=1 crux-arm64 firefox port - I have to use four patches for build crux-arm64 firefox port => version=60.0.1 release=4 Thank you for the lesson -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 2

Definition of release in Pkgfile
by Milan Buška 02 Jun '18

02 Jun '18

Hello. How do I define the release value in Pkgfile. Example: I have the port xyz - release=1 I use four patches in the xyz port - release=4 I understand it correctly. Regards Milan -- ---------------------------------------------------------------------------- Remember, no question is too stupid and no problem too small--We've all been beginners

2 1

xorg packages in Crux Arm64: great successes until attempting to build a web browser
by Thierry Moreau 02 Jun '18

02 Jun '18

Hi, as you may have noticed I installed Crux Arm 64 bits on the Odroid C2 hardware. Since I reported on the milestone of GUI-less installation, I had the pleasure to realize that the default "fbdev" X11 driver allows xorg applications built almost trivially. I build openbox, xterm, gvim, geeqie, ghostscript. Then I made a minimal xorg.conf file, and those applications worked nicey as soon as I soft-linked ~/.xinitrc to /usr/bin/openbox. "Almost trivially" must be understood in the context of the Crux philosophy and the fact that the target architecture is not officially supported by the Crux Arm volunteer efforts. I did not need to troubleshoot any source code, just some minor build process details, for the above X11 packages. The fbdev X11 driver does not provide the GUI acceleration from the ARM Mali GPU present on this Amlogic SOC target. Not a design goal for me. Thus, I am quite well served by the Crux Arm offerings. Thanks. The heavyweight X11 application is the web browser (any of them is a monster). This is problematic in this native build environment with 2GB CPU memory and a slow (and potentially unreliable?) MicroSD "mass storage". Firefox build quits with a cc1-process-being-killed message, with meager troubleshooting application. Filed a bug report on Mozilla, did not attract attention. I am frightened by the 400MB tarball size for Chromium (and I would like to avoid Chromium as it would not fit some project policies). Opera port (from contrib) does not download automatically, so building for ARM64 might be challenging. The other two candidates are midori and surf (both from contrib) and are looking less monstruous. Surf is based on webkitgtk (from opt) and a few ports from contrib which were built almost trivially. The web browser complexity seems mostly within the webkitgtk package, but fortunately the webkit package (and its gtk variant) is backed by an active open source community (there is a section on building for ARM devices on the basic instruction pages for package build). My current difficulty is with webkitgtk port build, using cmake with which I am not familiar. Some DerivedSources seem to be missing (ending as an #include file not found) but I noticed (more fundamentally) that a MacroAssembler<target>.h was selected for X86 while the ARM64 version is present (while ARM64 switches/defines do appear somewhere in a cmake cache file). I leave midori aside for now. Any comment, any suggestion? Since the X11 installation went well for smaller size applications, I guess the overall approach is okay and the steep learning curve for building a web browser in a foreign architecture is unavoidable. If we step back a moment, is there any way to procure an X.11 web browser -- even one with 5 to 10 years lag in functionality -- in binary form or otherwise as a first proof-of-concept milestone? Regards, - Thierry

4 7