TonyMac32

If anyone picked up the UGOOS box: http://freaktab.com/forum/tv-player-support/ugoos-aa/530975-official-ugoos-firmwares-for-devices-based-on-rk3288 Quite a bit of info on how to flash it/etc. I picked one up because, why not...

Tinker OS has 1.8 GHz opp point in it's dts, I'll update that. (Also, the Miqi patches already applied to 4.11 give it 1.8 GHz) The reboot hack/fix on 4.4 does not work on 4.11. There appears to be an mmc soft-reset property in 4.12, but I haven't tracked down all the parts. Final question: does anyone else lose HDMI after an extended inactive period? I won't discount it being my monitor, but show of hands? Lastly, I picked up https://www.amazon.com/gp/product/B01HSBM5JM/ to replace the 20x20mm tinker board default. I did not use the included thermal pad, I used a thin 20x20 one I had lying around. I had to cut a 2x2 fin chunk off to go around the inductor next to the Realtek audio chip. Now, in my noisy environment I'm not too worried about it, and I was trying to compile some things, so I stuck a little 25x25 mm fan on it directly over the processor. I was idling around 42 C, now I'm at 32. Yes, it's a noisy little bugger, but not overly so. (next to my gaming/dev pc it's silent) I have not gotten a real chance to try out running the board from the GPIO +5 and Gnd, however after the system shuts down those pins remain energized, so that's a good sign.

I am going to attempt to put the reboot patch in there tonight and get some more dts work done, I'm afraid none of the rockchip wifi system interface is built into the 4.11 kernel. I'll take a look at 4.12 to see how much work I want to put into it, and of course look at some other rockchip-oriented kernels to see if they have it implemented or not. Remember we don't have working BT in the 4.4 either. And then there's the sound issue, which should just be an ALSA configuration and maybe a PA fix, if someone else wanted to start looking into that. ;-)

I saw those, was tempted to grab another unit since the server/experimental one isn't really good for anything package wise with my "modifications" (it lives in my basement and was attached to a USB 3.0 RAID 5 before I upgraded my main machine and moved the old one to that tasking (Plex Server, 4 tuner TVHeadend tuner, general purpose file server, etc) What improvements could be made to that heatsink design? Curiosity on my part, I have very little experience with heatsinks but am looking to improve the situation on my Tinker Board (I've put bigger heatsinks on low-power voltage regulators...)

I went too far and stuck a copper GPU RAM liquid block on it...

The XU4 is down to $65 these days (that's assuming you add the ~$6 power supply. If you already have one it's $59

regulator.13 is vdd10_lcd, you want regulator.4, vdd_arm

It's my opinion the heat sink provided with the tinker board is incredibly inadequate. I'm not happy with the temperature it operates and will be looking at the maximum dimensions I can reasonably use for a passive heatsink. Of course, I also have a ~28mm (salvaged from a machine, never measured it) north bridge heat sink on my NanoPi NEO... Would this be best accomplished with dt overlays or something else?

The op points are in the device tree, it only has op points to 1.608 GHz. I have seen 1.8 working, I didn't add it to the tree because I was not certain they all had the -C like mine and didn't want to cause a major issue. So far I've seen them all be -C's however, anyone want to chime in if they do not?

I'm using some cables I spec'd online, I can' tremember the exact source, however their voltage drop is minimal and so far they've worked well. That said I'd prefer a better solution, if someone were to take care to use adequate protection, it looks like putting 5V on the GPIO (pins 2-3) will supply VCC_SYS, which is what the RK808 uses to get all the system voltages. You'd only be missing the surge suppressor, current limiter, and usb charge detector. (that one might be a sticking point, I think it might signal power OK)

I have seen a lot of temperature variation from image to image (not Armbian, I'm talking from ASUS's images, Rockchip-linux build, etc). CPU op points and temperature trip points are moving around a lot, I haven't been taxing mine all that hard, mostly doing quick "did my patch work" checks. I checked my router, the last 3 bytes of my MAC address are still seemingly random, it should be stable between builds/images, correct? As far as powering the tinker board goes, I see no way to bypass the microUSB yet, I need to try to probe "USBIN_VBUS_80" on the board itself, otherwise any solution will be extremely hack. If lucky there is a tespoint somewhere that can be used.

Uploading patch to fix reboot on Tinker board 4.4 kernel. The miqi must not use vmmc or vqmmc supplies, or else it would also be affected. The shutdown sequence turns the SD card off completely before reboot, and fails to reset to 3.3 volts from 1.8 (for high-speed cards)

@Tido Yeah, that's @Myy. I also see it's pointing at beta.armbian.com. @Igor I was going to ask about Miqi rebooting tonight, it slipped my mind, thank you.

I'm afraid not, I played with it briefly but couldn't get any meaningful information on where it was getting hung up from logs. It looks like it makes it to shutdown just fine, but hangs on the actual restart as if it's not pointing at the right location on soft reset. [Edit] With some research into the ASUS kernel, determined cause to be power being disabled to the SD card, a somewhat hack-ish workaround is in place, patch merged.

Built, no longer getting the "error, address not set" on the ethernet at boot. Getting late, can't dig in much further but I'd guess it's a success.

Well, I can try to build using it as the base and applying the updated patches, or just look at their commits and move them over to the Miqi kernel assuming no conflicts. If I had a Miqi I'd be a little less nervous about that part... @gkkpch The mac address fix is great, I was looking at the Tinker Board Kernel, they appear to have done it there instead of U-boot, https://github.com/TinkerBoard/debian_kernel/commit/2d84377b2c0541d9491ab33f936832634f5db123 Grabbing it in U-boot I like, instead of messing with the normal kernel drivers to add the function.

Thank you for that, I'll take a look later, I had a similar experience through I2S much earlier on, so that might be the ticket. gkkpch, good find on the kernel, something else to look at later.

...so. I decided to give it another try in a bit more structured way, mpv will play MP3's like nobody's business with asound.conf set up to make card o device 2 default. Volume is very loud very fast, but a start. Firefox, on the other hand, spits out static and tries to make my ears bleed. I'll do some digging, at least I know pulseaudio is (sort of) paying attention. I'm guessing my woes come down to sample rates and channels. This does sound pretty good through my ATH-M50x headphones, unlike a Pi... As this is a USB device, I can say I'm not getting a jittery mess, I do seem to be running out of buffer to my home media server, but again, not the sound card. I'm going to start from a fresh image and try to do it properly and get the kinks ironed out. Not having any form of datasheet on this codec is a pain... Anyone from ASUS reading this, take note and provide. ;-) Same goes for the rest of the board. [edit] Ran through 16 and 24 bit lossy compression files, and 16/44.1 and 24/96 FLAC, no playback issues. So sample rate isn't it.

Thank you @Myy, I'll take a look. @gkkpch, I'll take a look, I was actually playing with I2S devices originally, I did plug in some USB headphones I have and didn't get any output, however I can't blame that on Armbian as whatever chipset the Klipsch headsets use is pretty finicky and was targetted at consoles. I'll try it again with a creative labs "XMod" I have lying around, it worked with linux 10 years ago, it should still... There was that comment by @tkaiser concerning an amazing number of IRQ's being generated by the OTG controller. I haven't looked at that either since it hasn't caused any issues for what I'm doing at present, however I wonder if that could be causing Isochronous transfers to go haywire... If I'm not mistaken the Tinker board does not actually expose the OTG controller, probably just as well to shut it off (of course the official data also says it can't display a 4k desktop... sooooo...) Thoughts?

Yep, pulse audio implodes anytime I touch anything, anyone with enough mojo and a tinkerboard want to try this out? HW:0,2 is the one that works on Tinker OS, none of the others do.

Thanks Chris, There is a discrete codec on the board, that's the "ALC4040" chip, which, if using Realtek's website as reference, does not exist. . The system reports it as a USB audio device, so I would guess it can do 24/192 digitally, not via onboard DAC (I think the Raspberry Pi is 10 bit? Ugh.) So I did some comparing of the Tinker OS 1.4 kernel to the Armbian one source-wise, there is no difference, in fact spending a bit more time to carefully look, I just need to get pulseaudio to use Card 0 device 2 (Has the user friendly name of "Headset-output" on Tinker OS). I've always simply used ALSA, so the pulseaudio part is less than amused with my tinkering. (Pun not initially intended but wholly owned.) **** List of PLAYBACK Hardware Devices **** card 0: Audio [USB Audio], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Audio [USB Audio], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: Audio [USB Audio], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0

Other news, getting wireless into mainline is going to be a pain, there is a rockchip-specific system interface file that references all sorts of goodness that they seem to have added to the kernel. Running through the spaghetti.

I would guess. The info I've found for both drivers was that they were I2C only, so I'm poking through the Tinker OS 1.4 kernel for some insight, if any is to be had.

Thank you Myy. I pulled up the /usr/share/alsa directory and got this off of the Tinker OS image that's not part of Armbian: CARDINFO{driver}=="rockchip_rt5616", INCLUDE="rt5616", GOTO="init_end" CARDINFO{driver}=="rockchip_rt5640", INCLUDE="rt5640", GOTO="init_end"

Trying to figure out the audio thing, I can't find a single reference to the ALC4040 anywhere, that's the USB codec used on the Tinkerboard. Tinker OS dmesg: [ 2.917147] usb 3-1: Product: USB Audio [ 3.149587] input: Generic USB Audio as /devices/platform/ff500000.usb/usb3/3-1/3-1:1.255/0003:0BDA:481A.0004/input/input3 [ 3.210790] hid-generic 0003:0BDA:481A.0004: input,hiddev0,hidraw3: USB HID v1.11 Device [Generic USB Audio] on usb-ff500000.usb-1/input255 [ 7.225474] #0: Generic USB Audio at usb-ff500000.usb-1, high speed Armbian kernel 4.11: [ 1.867749] usb 3-1: new high-speed USB device number 2 using ehci-platform [ 2.255639] usb 3-1: config 1 has an invalid interface number: 255 but max is 6 [ 2.255651] usb 3-1: config 1 has no interface number 6 [ 2.256990] usb 3-1: New USB device found, idVendor=0bda, idProduct=481a [ 2.257002] usb 3-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 2.257012] usb 3-1: Product: USB Audio [ 2.257021] usb 3-1: Manufacturer: Generic [ 2.257030] usb 3-1: SerialNumber: 201405280001 [ 4.376017] input: Generic USB Audio as /devices/platform/ff500000.usb/usb3/3-1/3-1:1.255/0003:0BDA:481A.0004/input/input4 [ 4.428391] hid-generic 0003:0BDA:481A.0004: input,hiddev0,hidraw3: USB HID v1.11 Device [Generic USB Audio] on usb-ff500000.usb-1/input255 It looks like the results are the same, but I can't for the life of me get sound out of the jack on Armbian. Has anyone else had luck? Going for a lobotomy on Tinker OS, it has a USB-audio device endoint like Armbian does, but it is also showing a "headset-output", which is the one that works. [edit] forgot to check if the realtek "HDA-intel" module is in Armbian.