TonyMac32

I got off track on this, now trying to get Uboot to compile, I'm missing an expected toolchain it would seem.

The FAQ is totally incorrect, it is actually true 4K. Their initial release used a "fake" 4k where it was up-scaled, why, honestly I don't know. Now, the Legacy kernel works with 4k on my Samsung, however I am aware that some Acer products are... different. I believe I saw a patch related to this, I can take a look. The Next and Dev kernels do not yet have 4k support, I haven't rounded up everything needed, and the DRM system has gone through some changes since 4.4, so it's not a drop it in and go situation. their 4k video player is the QT based one found in the rockchip repo. @chwe I understand, I was actually outdoors repairing some masonry, I had to rebuild/replace some sections of a 70 year old wall. Beautiful weather for it, and a good excuse to work with my hands.

I had to zoom in until I got to the mobile device format to log in.

http://www.vishay.com/docs/83725/4n25.pdf This series is the "garden variety", basically made by everyone. Pay attention to speeds, if you're doing high-speed communications stuff these will have a detrimental effect. Ideal diode circuits are something you can do yourself, or buy prepackaged: http://www.linear.com/product/LTC4358 They aren't the cheapest, but can keep everything happy (say you power your Tinker from the GPIO then plug in the OTG connector. The two supplies can "fight" if they aren't at the same level.)

For industrial purposes I would recommend opto-isolating quite literally everything, and having the opto-isolators in DIP sockets for easy replacement in case of fire. For power, "Ideal Diode" circuits using a FET are useful as well to prevent back-feeding. This is a general rule of thumb for me at work, it also allows level shifting without much difficulty. I have an application where I need to switch from 9 to 24 volts as part of a communication protocol to a special sensor, and the opto-isolators made it a breeze.

It should be in your 4.12

Strange, I've got a solid 3.3 on that pin. Is there anything else plugged in, and can you check the voltage on any of the other GPIO pins? They all feed from VCC33IO. [edit] Checked 4.12 and 4.13 kernels, 3.3 Volts on both.

Now that is interesting. Let me take a look. which physical pin in particular? The 3.3 volt supply? I'm getting 3.3 on all pins...

Well, this "driver" was written like quite a lot of ASUS's Tinker OS code, full of "magic numbers" and hackish shortcuts. For instance, using the numeric value "8500" instead of having an enumerated "register" and setting the proper bits. "8500" tells the atmega micro on the display control board to power up the device)

Dev images need to be built, and are as unstable as we get. Currently 4.13 doesn't have any features (board-wise) not present in 4.12

The ASUS driver and the RPi driver, despite "doing the same thing", do it quite differently. I'm going to try this in the 4.4 first to reduce the amount of extra work and possible incompatibilities.

Patched in the driver, however the function of_get_drm_display_mode() has an added parameter (u32 *bus_flags), keeping it from building (could be more, this is just the first one). <---resolved It's device tree parameter related, has pixel clock and DE polarity information, according to the source file. Had to add an I2C "tinker_mcu" driver and the panel driver. So far, I'm getting a collection of errors and a mess on the screen, but it is commanding the backlight on and off, so that's something. Tracking down what I2C command failed, I think it's probably the mode set command before sending data.

Initial test resulted in an "oops": I'll start digging around. The "ASUS" screen appears to be functionally identical to the RPI one, using the TC358762XBG display bridge. I will say up front, powering the screen via the Tinker Board or the Tinker Board via the screen will be nothing but trouble, it would be best to feed both independently. Looking through, there were some DRM commits related to display on the Tinkerboard Kernel. I'll see what if they can move to the mainline. If not, this will probably have to become a discussion about adding support to the legacy kernel.

@Myy in case it's any help, kernel 4.13 with the vcodec driver included with your adjustments. [ 6.974433] rk-vcodec ff9a0000.vpu-service: probe device [ 6.974449] rk-vcodec ff9a0000.vpu-service: vpu mmu dec eeaa4810 [ 6.974694] rk-vcodec ff9a0000.vpu-service: allocator is drm [ 6.974753] rk-vcodec ff9a0000.vpu-service: checking hw id 4831 [ 6.991040] rk-vcodec ff9a0000.vpu-service: init success [ 6.996089] rk-vcodec ff9c0000.hevc-service: probe device [ 6.996110] rk-vcodec ff9c0000.hevc-service: vpu mmu dec eeaa5010 [ 6.996387] rk-vcodec ff9c0000.hevc-service: allocator is drm [ 6.996438] rk-vcodec ff9c0000.hevc-service: checking hw id 6867 [ 7.085518] rk-vcodec ff9c0000.hevc-service: init success

I'm "re-injecting" the @Myy - modified driver into the dev tree so it builds without extra steps, I'll patch/update kernel configs/etc shortly. My test build shows it loaded successfully, ideally that means it's ready for gstreamer/etc. I believe the ASUS folks are using a gstreamer plugin on Chromium, might be a good place to start. If there's a more proper way to do this tell me, I don't know all the features of the build scripts as yet.

Awesome. I'll patch this into the Dev image for anyone here that wants to experiment with the user space parts.

Right, I was just making sure everyone was on the same page, especially since the 4.11 kernel is eol and the hardware support on Tinker was less than complete. (Partially the kernel's fault, partially the speed I've been able to roll out changes) I also need to take a look and make sure I didn't have https://github.com/rockchip-linux/kernel/issues/15 Going on, I never specifically looked at it, it could be the issue. Checking tonight.

@chwe remember how I said I was gifted a screen for experimentation? ;-). Besides, it's not such a hard thing.

https://dl.armbian.com/tinkerboard/nightly The latest nightly is 4.12

Update May-21-2018: script may have negative impact on HDMI audio, needs further investigation. Patches pushed to enable I2S HDMI device, but audio does not come out. Update Feb-20-2018: script update committed for out of the box audio support (both outputs and inputs) for ASUS Tinker Board. Available sinks: BT-VOIP SPDIF Headset (the jack) Available sources: BT-VOIP Headset-input (the jack) Tinkerboard sound is possible with Armbian, however I have not worked to get it set up "out of the box" because of a major bug in the sound itself, namely that it outputs pure high pitched garbage from certain applications and certain source materials. I don't want anyone going deaf/destroying equipment, and I don't want to get backed into a corner on something I don't immediately know how to fix. That said, I'm hoping @Kwiboo or @Da Alchemist or the like may have an idea of what's going on here, it's one of the more annoying issues holding this back from being a daily driver. It's important to note I experienced the same sort of insanity using a simple I2S DAC with the Tinker Board. If some PA settings can take care of it that's great, if it's a clock issue on the Tinker I'm not sure where to go from there. I will be doing some testing on the new kernel 4.13, as there have been some clock reassignments/adjustments that, while seemingly unrelated, may be. Also, has anyone found a specific driver for the Realtek chip, or is it still just "generic USB Audio?"

If you could take a peek at the ASUS GPIO library and/or the pulseaudio settings, I'm going to start working on the DSI/CSI support, I have been gifted with the promise of a display to test with. The Sound shouldn't be too bad *except* for the garbage sound it sometimes spits out. This is part of the reason I haven't pushed to figure out what I need to change in the build script to make the right device default, I don't want the avalanche of "oh shit you blew out my eardrums!" that will result unless we fix whatever is causing that garbage output. If you decide to attack something, I'll make a specific topic for it that I can maintain the OP on. At least it's not a VW-powered Porsche...

I will see if I can recreate it, have you tried with the legacy kernel? There is also a nightly 4.12.3.

I'd been running a virtual box VM on Windows 10, Ubuntu Xenial as the guest OS to run the Armbian build scripts. Compilation was fast (it's the most powerful machine to my name), but writing to SD cards, etc was never very good, more or less everything that wasn't compiling kind of sucked, not to mention only being able to dedicate so much HDD to it, and multiple various vendor Linux source trees and such starts to get big fast. I have a laptop I bought to give me some mobility (who wants to live in their basement?), It would be self-contained, so it would have desktop environment and be performing compilation, running Xenial.

Well, it's gotten to the point where I'm dedicating a PC to this, using the VM is only so useful. Any recommendations on tools (Git gui's, specific code editors, etc?) A lot of this stuff I already have ideas/"go-to"s, but I'd like some new ideas/recommendations. And I think it would help out others to know.

I don't have any hardware for the DSI interface, I'm assuming that's how the display is attached? There will be some necessary device tree adjustment for it, but without the hardware I can't do any testing.