Some interest in Crux-arm64
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
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
Hi!
Hey Thierry,
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.
Pretty nice toy too, but we haven't one of them, so we can't support it officially.
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/
There are other interesting development boards which supports ARM64 and has integrated SATA (Firefly based on the RK3399). I belive it hasn't wifi but can be added an expaion card to give more outputs and supports wifi/BT.
I am working towards Crux-arm64 on the OdroidC2, having a cross-compiled Linux kernel (3.16) booting either Ubuntu or ArchLinux.
Probably there is no need to start from scratch... We have a generic ARM64 release ready to deploy to a device (if not supported currently by us) and rebuild the entire core collection ports with your specific/custom CFLAGS. Take a look to the 3.3 Release notes, the last point: https://crux-arm.nu/Documentation/ReleaseNotes3-3 You'll find there the generic release and two optimizations, for the pine64 and the raspberrypi 3. If none of this last ones fit your need for the Odroid C2, you can deploy the generic release and rebuild with your custom CFLAGS :)
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?
I hope you can find interesting info in this reply and avoid some time cross compiling.
Regards,
Regards,
- Thierry Moreau _______________________________________________ crux-arm mailing list crux-arm@crux-arm.nu https://crux-arm.nu/mailman/listinfo/crux-arm
Victor Martinez Learning bit by bit | http://vjml.es
Hi Victor! Thanks for this feedback. On 17/04/18 05:34 PM, Victor Martinez wrote:
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
Hi!
Hey Thierry, [...]
I am working towards Crux-arm64 on the OdroidC2, having a cross-compiled Linux kernel (3.16) booting either Ubuntu or ArchLinux.
Probably there is no need to start from scratch... We have a generic ARM64 release ready to deploy to a device (if not supported currently by us) and rebuild the entire core collection ports with your specific/custom CFLAGS.
Take a look to the 3.3 Release notes, the last point: https://crux-arm.nu/Documentation/ReleaseNotes3-3
You'll find there the generic release and two optimizations, for the pine64 and the raspberrypi 3.
If none of this last ones fit your need for the Odroid C2, you can deploy the generic release and rebuild with your custom CFLAGS :)
Thanks for pointing me to Crux Arm64 development releases. Here is what I have achieved with a quick trial with the Odroid C2: I started with a MicroSD memory having Archlinux already installed: A single ext4 partition, u-boot from Archlinux binary distribution, having replaced the kernel by kernel 3.14.55 with patches distributed by Hardkernel (and cross-compiled by me with gcc 7.3). From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device. The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
[...]
Any useful tip, suggestion, or comment?
I hope you can find interesting info in this reply and avoid some time cross compiling.
My interest in cross-compiling from Crux sources with the Arm64 devices as a target comes from a security-paranoia-induced motivation for having every piece of running software being auditable, in addition having no adversary tools in the target system (even no shell in the case of an "open source HSM that performs a cryptographic computation and nothing else). A third motivation is that the next target device (having followed this path for X86_64 targets) might be some architecture not envisioned at all for Crux. My eventual contributions to Crux Arm64 are a by-product of my efforts, not an aim in itself. Regards, - Thierry
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too /f
* Fredrik Rinnestam (fredrik@rinnestam.se) wrote:
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too
Good catch Fredrik! Hope it helps Thierry. --- Victor Martinez Learning bit by bit | http://vjml.es
On 19/04/18 04:22 PM, Victor Martinez wrote:
* Fredrik Rinnestam (fredrik@rinnestam.se) wrote:
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too
Good catch Fredrik! Hope it helps Thierry.
Yes, good advice. My kernel installation notes indeed referred to /lib/{modules,firmware}. It did not change the blank display (blank screen hdmi output signal, not "no hdmi signal"). - Thierry
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
On 19/04/18 04:22 PM, Victor Martinez wrote:
* Fredrik Rinnestam (fredrik@rinnestam.se) wrote:
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too
Good catch Fredrik! Hope it helps Thierry.
Yes, good advice. My kernel installation notes indeed referred to /lib/{modules,firmware}.
I understand the the version inside those directories should be right.
It did not change the blank display (blank screen hdmi output signal, not "no hdmi signal").
Is there any specific option for the bootloader?
- Thierry
Regards, --- Victor Martinez Learning bit by bit | http://vjml.es
On 19/04/18 06:54 PM, Victor Martinez wrote:
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
On 19/04/18 04:22 PM, Victor Martinez wrote:
* Fredrik Rinnestam (fredrik@rinnestam.se) wrote:
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too
Good catch Fredrik! Hope it helps Thierry.
Yes, good advice. My kernel installation notes indeed referred to /lib/{modules,firmware}.
I understand the the version inside those directories should be right.
It did not change the blank display (blank screen hdmi output signal, not "no hdmi signal").
Is there any specific option for the bootloader?
I am quite ignorant on this part (u-boot customization for hardware and kernel image). My guess is that the u-boot is able to achieve its purpose since a bash interpreter (could it be a busybox shell?) is able to obey a "shutdown -h now" command. My further guess is that some configuration is missing in the startup steps from /sbin/init. If this was on the top of my priority, I would investigate these startup steps in the ArchLinux root filesystem (look at Odroid C2 in https://archlinuxarm.org/about/downloads ) to find something specific to the hdmi output configuration (fbdev? dvi?). From such hints, an equivalent configuration of some Crux startup file(s) should fix the issue. - Thierry
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
On 19/04/18 06:54 PM, Victor Martinez wrote:
* Thierry Moreau (thierry.moreau@connotech.com) wrote:
On 19/04/18 04:22 PM, Victor Martinez wrote:
* Fredrik Rinnestam (fredrik@rinnestam.se) wrote:
On 2018-04-19 13:59, Thierry Moreau wrote:
From the Archlinux partition I removed every /<dir> except /boot. Then untarred the generic 64b release -- thanks -- to this device.
The Odroid C2 boots with this. I was able to log root/root, and then shutdown -h now. But there is no display (I did observe success by the keyboard capslock LED going live, and then dead). Lack of display shouldn't be too difficult to troubleshoot.
You should have left /lib/modules in place too
Good catch Fredrik! Hope it helps Thierry.
Yes, good advice. My kernel installation notes indeed referred to /lib/{modules,firmware}.
I understand the the version inside those directories should be right.
It did not change the blank display (blank screen hdmi output signal, not "no hdmi signal").
Is there any specific option for the bootloader?
Hey Thierry, I waa reviewing the second mail and you are login in with archlinux credentials (root/root) because in CRUX-ARM the first time you login to the system with root account it ask to set a password. I don't understand this very well.
I am quite ignorant on this part (u-boot customization for hardware and kernel image).
Have you taken a look to boot.ini options? May be you have there video resolution options to fit your needs.
My guess is that the u-boot is able to achieve its purpose since a bash interpreter (could it be a busybox shell?) is able to obey a "shutdown -h now" command.
We've find this behaviour on a old device (wm8505) with a prebuilt kernel. We needed to overlay the rc script and adapt to its needs, but any other device is working as expected.
My further guess is that some configuration is missing in the startup steps from /sbin/init. If this was on the top of my priority, I would investigate these startup steps in the ArchLinux root filesystem (look at Odroid C2 in https://archlinuxarm.org/about/downloads ) to find something specific to the hdmi output configuration (fbdev? dvi?). From such hints, an equivalent configuration of some Crux startup file(s) should fix the issue.
I'll try to take a look this afternoon, but I have other feonts between hands (iptables, llvm, cland and chromium... and the new 3.4 devwlopment) and without a device for testing it's hard to help.
- Thierry
Regards, --- Victor Martinez Learning bit by bit | http://vjml.es
participants (3)
-
Fredrik Rinnestam
-
Thierry Moreau
-
Victor Martinez