TonyMac32

Of course, as soon as it isn't crazy WIP. :-) Sent from my Pixel using Tapatalk

The HDMI should be committed, I didn't fix a couple things I noticed on pcie and the audio codec yet. ;-). The Wlan may also be better, the Radxa device tree sets the io to 20 mA across the board on it, committed with hdmi. @Martinayotte, if you would verify it works, I didn't try to bring it up yet. Sent from my Pixel using Tapatalk

Well, mine will talk to various devices over USB3, so I can't reproduce the issue I'm afraid.

I'll take a look, my Rock64 is unfortunately a Rev 1, so there are some differences, but I don't think any are in the USB pathway. On my Renegade (similar) I seem to be having trouble with one of the USB 2.0 ports, still debugging.

Hola tauroblau, If possible please use English on the forums, it is quite helpful to everyone, since all told there are probably over 10 (low estimate) languages spoken by the various members. For the Pi there is no plan on supporting that family of boards. They embody many of the things we point to as fundamental problems with basic board design (micro USB power, horrible I/O bandwidth, propagandist marketing, just plain wrong benchmarking, I could go on. The 300 Mbps on the RPi will be significantly affected (negatively) by any other USB peripheral, like a storage drive. I would recommend researching other boards and finding one with GbE for your needs, the RK3328 boards, RK3288 boards, etc. They are pricier, but if you need the performance, you will have it.

Last note on eMMC https://github.com/ayufan-rock64/linux-mainline-kernel/commit/686e1f1aa461afd4100a18f0374a59e86b23069b

Ok, the UHS and GRF-GPIO patches are both superseded and present upstream. only note from patches: To use this feature, the following options are required in kernel config: - CONFIG_GPIO_SYSCON=y - CONFIG_POWER_AVS=y - CONFIG_ROCKCHIP_IODOMAIN=y

The grf patch should be part of the 4.20, so that's ok, UHS should likewise be unneeded, but I'll check it Sent from my Pixel using Tapatalk

I might add that almost half the balls on the package go to ground on the "G", a shame it wasn't available in a friendlier package than a BGA, although sitting quietly for a moment, one begins to realize that the V3s has 64 MB for a single 32-bit core to use, while the RK3308G is splitting in between 4 64-bit cores. If I were to use it I'd probably power down all but 2 of the cores if possible. I wonder if XIP is an option? It appears QSPI is a possible medium.

Aha! I only turned up the V1.1 datasheet that does not specify the "G" variant.

I was unaware of RAM packaged on board that SoC, do you have a datasheet? Yes, Armbian could run on it if you tailored a command line image to fit, same as for the Allwinner V3s. obviously you'd have to look long and hard at the use case and the tools you want to use in that limited memory space.

I'm afraid not. A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves. A lot of people feel this way, but it would require an agreement on a standard. SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc) And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives". That said, there is a versatility of application to SBC's that does not exist with PC. Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port. So I think there will always be room. An FPGA that runs a RISC-V powerful enough for linux isn't in my budget just yet, but it does look interesting.

No, that's alright, I have a nightly running as well. I've just used Audacity with 3 different headsets on D1, all function properly. In Audacity I simply had it set to all defaults, PA set to default source of "Headset-input" 4.19.12, Debian Stretch

Rockchip/Ayufan 4.4 will be the most advanced in terms of support. 4.19 will be the next most advanced. Anything else will be nearly unusable. After the incredibly smooth sailing with the RK3288 in mainline, the RK3328 is *very* disappointing.

Mainline has been a bit of a problem for Rockchip and the RK3328, however let me review the dev images/builds as well, and likewise, can you get the UART debug output / armbianmonitor -u output before and (if possible) after upgrade? I increased the drive level used to interface to the SD on the 4.4 kernel, but I don't think I did on the mainline, there could be some corruption happening due to malformed bits getting to the SD card. If the DTS changed to include higher speed modes, it would kill it for sure not to use 8 mA instead of 4. https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519

That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters). In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.

The gpio is claimed by the "hog", so is not able to be used by users. This issue (non-powered hub) went away with 4.19, we're only dealing with HDMI issues so far there.

The tinker sound codec is on its own USB root hub, no other devices share it. To expand, in case there is some confusion:. The tinkerboard has 3 USB master ports, one is for the 4x ports on the side, one is for the audio codec, and one is an OTG that I haven't gotten working (minimal effort) on the micro USB. They are independent controllers within the SoC, this is not an RPi situation where the SoC has only 1 USB interface. Sent from my Pixel using Tapatalk

Tinkerboard has high quality USB attached codec with input and output.

If the devices aren't plugged in on boot with 4.17+ the hub will go into a suspend state that can't be woken. I've patched this in the 4.19 dev images by copying the solution for Rockchip (same IP block). One of the upstream contributors submitted a nearly identical patch within a day of mine, so it will be fixed in the future.

350 had plenty of problems, it's biggest strength was how cheap it was. The Mopar 318/340/360 was/is a far better engine series. @Tido@chwe next time say $6. :-P The thing I see with the V3s is the fact that it appears to be in the same price arena as the H3, and without full vdec/venc/camera support it doesn't have a single benefit over the H3 or a decent micro (esp32, etc) Sent from my Pixel using Tapatalk

@picosoft please don't double post if possible. That said, please see the response to your other post.

If you know how to make overlays, you can give nightly dev images a try, I haven't made PWM overlays yet though.

Moved to hardware hacks due to being about libraries.

For the car, use quality line and connectors, and double down on the Teflon tape, paying attention to wrap in the direction of the thread. Another option is to use a GM LS series V8 with a turbo. (Heresy, I know, but sadly no one has done better so far, in terms of efficiency, package size, power, and simplicity, and cost). For inlines I agree wholeheartedly that Japanese motors reign supreme, but for V's, the best engines globally are the LS, the Chrysler Hemi, the Ford Modular, then the Japanese engines, with everyone else either being so exotic, expensive, or pathetic to not matter. Or if you want to spend all of your money, take a second mortgage on your home, sell your children on the black market, and still get beaten, you could use a German engine. [emoji38] Sent from my Pixel using Tapatalk