TonyMac32

Sorry for the silence. Starting with the Asus overlay https://github.com/TinkerBoard/debian_kernel/blob/develop/arch/arm/boot/dts/overlays/justboom-dac-overlay.dts The Overrides exploded the patching process 100% of the time, I didn't get that debugged yet. perhaps @martinayotte has something interesting on that. The power supplies I commented out because they're named/structured differently in the 4.14 + kernels and it seems to fallback to a dummy anyway. The interesting issue I haven't quite gotten is why the sound node isn't obeying a "disabled" patch, the normal soundcards are still loading as though nothing has been changed (Yes, I am watching the boot terminal to make sure the overlay applied). I was finishing the launch of a crowdsourcing for a project of mine, and some unexpected family health issues have been in the way, I think there might be a higher intervention against my working. Below is the WIP overlay, no override and I also added a "sound-ext-card { }" section to the device tree to target these hats at. My DAC is a Just Boom DAC Zero, but it should be extremely similar (might be pcm5122 instead of 5121) /dts-v1/; /plugin/; / { compatible = "rockchip,rk3288"; fragment@0 { target-path = "/sound"; __overlay__ { status = "disabled"; }; }; fragment@1 { target = <&i2c1>; __overlay__ { dac: pcm5121@4d { compatible = "ti,pcm5121"; reg = <0x4d>; /* AVDD-supply = <&vcc_io>; DVDD-supply = <&vvcc_io>; CPVDD-supply = <&vcc_io>; */ status = "okay"; }; }; }; fragment@2 { target-path = "/sound-ext-card"; __overlay__ { compatible = "justboom,justboom-dac"; i2s-controller = <&i2s>; status = "okay"; }; }; fragment@3 { target = <&hdmi>; __overlay__ { hdmi-i2s-audio-disable; }; }; };

Good, I can't wait to play with the little thing.

Testpoints everywhere Sent from my Pixel using Tapatalk

You have used an RPi zero before, yes?

https://www.raspberrypi.org/blog/driverless-cars-run-by-raspberry-pi/

Should be easily doable, there's even an example in the TinkerOS kernel.

I agree, which is why this is not under normal development as a topic. There is the reality, however, that people buying RPi-shaped boards want support for RPi peripherals and accessories, so my thought is to discuss ways to support that, while implementing a few on a platform that only has 1 board with gpio anyway (Rockchip). If it must be that I have a fork of the build system and stuff all of this in "user patches" then so be it, but I think we need to come up with a way to handle this per board rather than per family.

I'm not sure what will and won't be a worthy overlay to put directly into Armbian itself with the current script structure, I intend to document the ones I add here, @martinayotte may as well if he's bored. :-P I will be focusing on RPi GPIO compatibles, since those are nice pre-packaged devices in general. I have Tinker, RockPi 4, Le Potato/K2/C2, Tritium H2+/3/5, Rock64, Renegade, and some others. Everything here is a placeholder at the moment. Status Tinker Le Potato Meson64 Renegade Tritium Automation Hat Generic DAC (Pi) MCC 118 DAQ MicroDot PHAT Inky WHAT (e-ink) ENC28J60 for Pi

RK3288 also is stuck at older u-boot, I guess we need to investigate further what changed.

Awesome, let me take a look at that after bit, I've been working 12's at my job due to some craziness, need some sleep. :lol: I also need to learn the fixup scripts with u-boot so we can make these overlays a bit more configurable at boot.

Haha hopefully it is that quick. [emoji38] I unfortunately do not have an eMMC for my K2 to test, but the others here do. Sent from my Pixel using Tapatalk

An RPi is not 1) reliable 2) the most cost-effective 3) worth $35 4) worth any more discussion. The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited. Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official. Sent from my Pixel using Tapatalk

The last 4-5 posts very clearly say "we're close, please wait". Sent from my Pixel using Tapatalk

If you look at the datasheet for the SoC it will be in there, I'm cooking dinner at the moment. :-) Sent from my Pixel using Tapatalk

The eMMC bootloader is always installed a little differently on the eMMC than SD. The output Igor is seeing is the first stage loader in the SoC, it's not finding the bootloader where it wants to see it, it's probably just an offset. Sent from my Pixel using Tapatalk