zador.blood.stained

And what about the Do you know if it needs additional software support on top of the base USB-C and whether it should be working already?

Is it? RK3399 .dtsi and the status matrix show a lot of supported HW features. But I didn't pay much attention to Rockchip development, so can you please name some roadblocks for getting at least server images with the mainline stack working? I'm not saying that we should immediately release mainline based images, I just indicated my opinion on next and dev kernel branch mapping.

My 2 cents (thx to FriendlyArm and Igor for the sample) Subjective pros: Lots of fast interfaces (PCIe, USB3 and Type C) with a pretty fast CPU Good software support (for the SoC), both BSP and mainline, we'll have to see if the audio chip and PMIC have good support too Subjective cons / nitpicks: Type C can't be used for powering the board Finding an appropriate connector for the fan may be tricky, though it is understandable given the component density on the PCB Serial console baud rate (1500000) may not work with some USB-UART adapters (applies to all Rockchip SoCs and devices AFAIK), it was a bit disappointing that the default kit does not include a USB-UART adapter M.2 connector has a standoff for only one card form factor, though again it is understandable given the component density on the PCB Details to keep in mind: Some I/O interfaces are 1.8V only according to specifications I'm in favor of having a single kernel source(s) too (default - 4.4 BSP, next - kernel.org mainline, dev - maybe ayufan's mainline?) I think (and hope) that the mainline kernel should be suitable for server and lightweight desktop usage scenarios, and hope that this device along with Odroid N1 and RockPro64 will get upstream DTs soon enough ... without active cooling, which is IMO a not a bad idea for this board, especially if you install a M.2 SSD on it.

How exactly did you copy the SD cards? Raspberry Pi and Raspbian distributions are a very rare instance where it is enough to simply clone the partitions or rsync to a prepared and mounted card, for most other SoCs you need to raw copy the whole card or reinstall the bootloader manually on new cards because it is not stored on a partition, and if you are using a filesystem level copy you have to adjust the UUID in two places.

You didn't add necessary kernel arguments (i.e. root= ), so it's not stuck, it's working exactly as expected

64bit boards usually have an uncompressed kernel (/boot/Image) that should be started with booti instead of bootz

Yes, this is already implemented in the legacy/BSP stack. Since mainline u-boot and kernel were made from scratch rather than by porting the Allwinner code, this functionality and many other things were not added.

It is not powered off completely in this state, it is sitting in a standby mode in the legacy u-boot. Both mainline u-boot and kernel do not support such functionality unless you implement it by yourself.

Prebuilt images provided at armbian.com - no, because they contain non-free elements: firmware in /lib/firmware and non-free (but not essential for system operation) packages such as iozone3. Obviously those parts can be removed from an installed system at any time.

The upper frequency point is limited for a reason

Pessimistic/realistic expectations based on the status or timeline of some other kernel features (i.e. MLC NAND, requests API, sunxi DE2 driver / H3 DVFS and THS, ...) I see things like this and this, and as I understand it, you need to have support for such devices without any userspace hacks (i.e. loading firmware) in order to add it to the kernel. And generic serdev bindings don't support any resets/clocks/regulators.

Serdev is a right approach to handle this, but it may take several years to gain support for all necessary features (clocks, resets, regulators).

If this driver has proper DRM/KMS stack implementation then it should be possible to force modes on the kernel command line, either with drm_kms_helper.edid_firmware= or with video= parameters. https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes

This does not work, rfkill-gpio is not DT aware and it does not support any advanced properties like clocks or resets. This commit is based on an old attempt to push this functionality to rfkill-gpio, but it was rejected.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/leds/common.txt Edit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/devicetree/bindings/leds/leds-gpio.txt (please note that these are GPIO leds, not PWM leds, so you can't fine tune the brightness level).

This is the base address of the RTC controller, it is present in the overall memory map and at the beginning of the RTC controller description.

The datasheet may be incorrect. This output should be disabled by default and writing 1 should enable it. https://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_with_mainline_kernel Also <1 10> is PB10, PA10 would be <0 10>

This enables the "slow clock" (losc) output, though not all BT modules need this clock signal. Reference - Allwinner H5 user manual, section 4.8.3.16 (page 190). Though in a more or less recent kernel this can be enabled with a DT property.

There is no kernel support for these types of BT chips (with reset/enable GPIOs), so these GPIOs are usually handled from userspace before running hciattach, i.e. like here

UART 0 is ttyS0 and it is already defined as a serial console in the DT: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts?h=linux-4.14.y#n60

Yes, when PMIC on an A64 based device shut down after cpufrequtils.service was started - CPU frequency and voltage caused a power spike and undervoltage (i.e. due to microUSB powering) so PMIC protected device from undervoltage by killing the power. Adjust kernel command line in boot.cmd/boot.scr to not include "console=tty1" in the kernel command line.

Desktop notifications + web browser + video/music player for example? And it's not about whether you need those sounds, it's about whether only the needed application will obtain the exclusive audio output (if you don't set up dmix). setting up ALSA dmix as the default output device is easy enough IMO

You can always check this to see what kernel features are available. "NO" in the "CPUFreq" row answers why there is no CPU frequency available and "NO" in the "Thermal" row tells why we won't try to up the frequency from the default 890MHz value.

Tweaking this setting was disabled a week ago, so newer images built from the master branch should work fine out of the box.

The Armbian build script can be run only on x86_64 hardware, it's not possible to run it on armhf/arm64 devices.