TonyMac32

Ah, found an "unexpanded" one https://www.aliexpress.com/item/NEW-Zero-1-2GHz-Cortex-A7-512Mbit-DDR-Core-Board-Development-Board-Module-Mini-PC/32945243814.html

I hadn't even looked at it that closely...I have some V3s's lying around, at that price I can actually build my own board...

Didn't know this thing was ever going to see the light of day: https://www.aliexpress.com/item/Lichee-Pi-Zero-1GHz-Cortex-A7-512Mbit-DDR-Development-Board-Module-Mini-PC/32931418720.html I see the original board outline is still there, but it grew a bit of a waistline A valid question is why, and I'm not sure, nor will I buy it, just thought it interesting that it popped up. With complete kernel support for VDEC/VENC/ camera this is actually somewhat interesting, so maybe some people would like to play with it. I'm sure @Icenowy knows more than is humanly possible about the capabilities and whether it's worth talking about.

I forgot this came up in this topic, I have modified the rk3328.dtsi to use 8mA drive strength on all rk3328 boards, that will fix the issues for most users as far as the electrical interface is concerned (it is default 4 mA). 12 mA is available, if someone spends enough time rigorously testing to determine it's needed (probably edge cases with crappier than normal cards or poorly routed designs with too much capacitance) Rock64 was having the same complaints. https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519 For S905X, I'm afraid I haven't found a way to change the output drive level.

@rino Thanks for the test! Could you test changing resolutions? Sent from my Pixel using Tapatalk

The script is for the tinker board, I referenced it as an example, the gpio's have to be adjusted for the Pine. (I don't have one or I'd just do it) Sent from my Pixel using Tapatalk

It's in our build system, I'll post links after bit, I simplified somewhat. You'll need to find your gpio's that correspond to the ones used on tinker https://github.com/armbian/build/blob/master/packages/bsp/rockchip/start_bt.sh https://github.com/armbian/build/blob/master/packages/bsp/rockchip/tinker-bluetooth.service PineA64 has those GPIO's here:

For the Tinker Board myself, @Myy, and someone else on GitHub (bad memory) worked out a user-space solution to toggle the reset line on the module. This is the issue you are experiencing, if I had to guess, that the Bluetooth is not reset on boot.

The build system pulls the sources for the board/kernel you select, you have to add a couple switches or modify the config file to enable making patches, see docs.armbian.com

There is?

Right, I found that during my lunch break while talking back and forth on here, that's the only missing piece I know of (It didn't cross my mind, I'd aborted a build and the resulting restart didn't clean the source directory wiping out my patch, so I was redoing some stuff and forgot to look at u-boot before I needed to stop and sleep.)

All of them unfortunately. They (almost*) all work on boot now after the last few patches you recommended)posted, but switching resolution is a problem on all, and hot plugging can result in only part of the screen showing output. Switch from higher to lower res results in a garbled display. * The 4k display boots in 1080p with a strange interlacing pattern making only some of the desktop accessible. A plug cycle and it is fine, as long as the whole screen displays the desktop (black bar at the bottom possible seemingly at random). [Edit] I will dump xrandr data from a different board arch (or maybe just older kernel) for these, the resolutions/frequencies look different than I'm used to seeing with the current Meson64. Sent from my Pixel using Tapatalk

Exactly, but for now I am learning to walk. ;-) Sent from my Pixel using Tapatalk

"kaputt". [emoji38] This is something said only in some places here, and only because the settlements in my region were primarily German long ago and the people did not move around much in the low mountains. I am working on overlays now, I have good examples from@Martinayotte to work from, I have one last u-boot adjustment to make and I think it is at least ready for testing. I will add it to the 4.19 kernel first since that is dev and is building nightlies. Sent from my Pixel using Tapatalk

:-) that's why I am giving it a go, seeing your examples it didn't look awful, and I've wanted to get it worked out for some time. Sent from my Pixel using Tapatalk

I am talking about Rockchip for Tinker board, not rockchip64. Unless it was changed, it should be simple mainline. Sent from my Pixel using Tapatalk

Well, when the boot script says to apply it, u-boot spits out the "help text" for the command, reverts to original DTS, and boots without the adjustment. I haven't played with any parameters requiring the fix-up script yet... I will do some more tonight before accepting defeat. ;-) Ah, also, we only use mainline u-boot. [Edit] I need to check libfdt and and fdt_overlay, given the issue I would guess they aren't enabled right now.

Topic to discuss RK3288 overlays, primarily concerning ASUS Tinker Board, the MiQi is technically EOL and has very little GPIO anyway, and TV boxes are more or less sealed. Kernel 4.19 will be the pilot for this, the discussion now that it seems to be working thanks to @martinayotte and @zador.blood.stained's feedback and examples is what to overlay. For testing/debugging I started with some ASUS overlays for RTC and 1wire. Easy ones: spidev out of the default tree but as default overlays. instead of making 1 overlay and messing with parameters, just make 2 overlays DAC's: I don't have a lot of hardware to play with, but @gkkpch has contributed to the existing ASUS overlays, if we ask super nicely maybe we'll get some help. I2S on mainline is a question Harder ones: RPI display: I almost got this working on Mainline, I need to return to it, make it work, and make it an overlay. Cameras: I honestly don't know if this is actually possible, I need to look at the drivers a bit more closely. Original Content from Split:

Do you know if this includes mainline? I'm going to be completely honest with you, if it weren't for vdec I'd throw away the 4.4 kernel immediately.

Yes, we use the boot script for that purpose, the Asus code is written without worrying too much about other hardware or general extensibility. My thought would be to work this out in mainline, and not fool with Rockchips increasingly crusty kernel. Unless you think you need video decoding acceleration, everything else works.

We support both u-boot overlay and runtime. U-boot uses the text file like you're thinking. Interestingly the only board I use for Volumio at the moment is my Pi2, some years ago I bought the hifiberry dac+ pro and the nice little case. I also have some "how cheap can you get" nanopi Neo's as remote speakers, they're fun because they're tiny.

I can think of many objective definitions that could be used, but people who like to sell especially expensive things maintain their claims that a perfectly measured reproduction of frequency, phase, and amplitude can't be trusted... All while the critics are not understanding what "output impedance" is.

To be honest it's because I never learned how to do device tree overlays. Now that I'm seeing what must be done for mainline thanks to @martinayotte awesomely doing Meson64 and some rockchip64, I can take a stab at Tinker.

Do tell, others might be interested. And perhaps adjust the title to reflect the actual issue/fix? Thanks!

Good to know, the HX1230 is only $0.13 more it looks like.