* Thierry Moreau (thierry.moreau@connotech.com) wrote:
Hi,
Hello Thierry,
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.
There are ports overlays for opt and xorg collections ready for arm64. I've tested them on the pine64 and all is working right with fbdev. I was able to run Mali on the cubieboard but I didn't mess with 64b stuff. Arm64 arch was tested the first time in CRUX-ARM 64b 3.3 and it will be officially supported on the next release (3.4) which we are working on currently. The base is ready from the toolchain to the ports overlays as you can see repositories and branches in the development section.
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".
This is a shared problem on embedded devices. I started connecting an external harddrive to make builds and finished using a nfs share over a NAS.
Firefox build quits with a cc1-process-being-killed message, with meager troubleshooting application. Filed a bug report on Mozilla, did not attract attention.
That's not a bug, it's an error about not enoght memory to build right. You need a big swap file (not sure if 8GB are enoght, mine is 16GB) to build these packages (firefox, chromium, QT,...) I've tested firefox on the pine64 and it's working right too
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?
Make a big swap file and firefox will build without problems, It'll take much time, probably around 30h without CPU throtling due to temperature problems. Good heatsink and fan help on big builds.
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?
I don't like to play with packages because you need all linked ones. This is hard to manage and not the aim of a source based distro.
Regards,
- Thierry _______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu https://crux-arm.nu/mailman/listinfo/crux-arm
Regards, --- Victor Martinez Learning bit by bit | http://vjml.es