TonyMac32

I didn't get any feedback on you about the HDMI hotplug, however on some favorable testing on a Renegade I've pushed a patch into the build system to set the drive levels on the SD to 8mA, up from 4mA. I don't have a failuyre to boot issue with my SD cards, supply and Rock64, however a sample size of 1 is not representative, and my conclusion was that bumping all rk3328 devices to 8mA was advisable. At @Igor's discretion this can be built for nightly or test.

Yep. I mentioned a while ago that I was amused by the giant one packaged with the NanoPi Neo. At the same time I was using them for dumb music players, so not a lot of heavy lifting so I didn't care.

OK, upon booting mine a specific behavior occurred, it did not output to the display until I unplugged/replugged it.

Hang on, I should be able to give you the device tree momentarily. I was tossing that patch to Igor since he has quick access to the image hosting. I can do 2 versions for testing. What time are you on, I am just going to be getting to "work" in another few hours for this

@Igor if you've the time to humor the topic some more, the patch below is changing the pin drive levels to 8 mA from 4. I'm building a rock64 image now to test, of course I have the old board, I don't know if anything besides the ethernet has changed. I'll see if I can force modes and observe errors. kernel-rockchip64-default.patch

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards. The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor*** A lot of boards from various vendors inevitably have some difficulties with electrical signalling. You see it in delay values, phase correction in software, etc. The general prevailing theory is almost always "get it close and fix it in software". But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way. Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC. This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor. GPIO's on SoC's have, typically, current limiting on each pin or bank of pins. For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings. This includes the SD card bus, clock, output, etc. These current limits are exactly that, limits. If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting. if it needs more, however, it will only get what the drive setting allows. SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them. Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz. Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208). The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions. The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card. I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard. I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance. In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior. This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability. In this circuit the LimiterDiode does exactly that, it limits current. With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable. Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result. The board will crash if it attempts this. Now, you might say, what if the board is extremely well made and the capacitance is lower? Well, it looks like this (assuming 20 pF, which may not really be possible): Still, no hope of operating properly. Dropping to 25 MHz has roughly the same effect. As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA. I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin. Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down. On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA. I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant At 25 MHz, however, 8 mA is far more reasonable: Now to the big reason for 1.8 V signalling: 50 MHz, 1.8V, 40 pF, 8 mA drive. Assumptions: source/sink values both controlled. It's possible this is not the case. If there is no "sink" limit, or if you assume 20 mA sink limit: 3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink: Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V: So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time) Needless to say, a lot more than 4. This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's. 50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves. RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode. Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.

@Igor I'm not convinced 50 MHz SD communications at 3.3V are stable on any rockchip SoC using a 4mA GPIO driver limit. I'll make a separate topic for that discussion, but it might be the problem, I see some rockchip updates to the sdmmc clock sources, it could be a similar story to the Amlogic devices where they were not clocking at the requested speed before due to an error in picking a divider or some such nonsense.

OK, I had been using https://github.com/superna9999/meta-meson/tree/sumo/recipes-kernel/linux for the patches.

Received the little board, realized I don't have an of the tiny bolt needed to hold it down. Anyone know what thread this is? It fits nicely, sits slightly lower than the heat sink of the Duo. [edit] I scrounged screws from an old broken Seagate hard drive, so it's on the board now, but remembered my SSD got put into a PS3, so testing will have to wait a bit. [emoji14]

I missed your question, @Tido, sorry. As far as the test voltage goes, unless you have quite a poor quality supply, it is validated over 50 to 60 hz and often from 100 to 240 volts. There are some efficiency considerations if we were talking about transformers, but otherwise it should be fine.

Rockchip is pretty stable, I played video through chrome for several days without issue. @JMCC scripts may need updated for Bionic or Stretch use.

That RockPro64 heat sink is big enough, is anyone has a cnc and the will, they could remove a millimeter or so from the area around the actual contact patch and give that a try with compound instead of a shim.

well it only works on the Tinker with the RK3288 and the 4.4 kernel (not so smelly as the one tkaiser spoke of, it is full-featured, even if it's aging)

Following @JMCC's media script you can watch video in chromium on Tinker Board, Mali, VPU, etc all works. (Took a minute to get that kernel fixed though thanks to Rockchip)

With the camera connected, what does lsusb say? Is it attaching as a mass storage or as a media transfer device?

Oof, I did not check the heat sink on the T4. I also have some copper shims lying about...

With the fix to 4.14 reboot last night they should be ready. The only thing I can think of is the RPi touchscreen on 4.4 has an upside-down touchscreen response, if the user rotates the desktop in settings it's ok again. Sent from my Pixel using Tapatalk

I've updated the build system, it won't be reflected in downloads until we rebuild images.

I didn't know it wasn't working out of the box, I've fixed the issue in the scripts and aded a udev rule: https://github.com/armbian/build/commit/9b6a1c23a3252719cda76a0e8b20d756004b3b1f That rule keeps you from getting the "USB analog stereo" or whatever sink/source, where pulseaudio probes the device after it's been manually loaded. Thanks for the (inadvertent) heads up, and for the kudos.

OK, the audio confusion that was going on is, I think, resolved. I cleaned up my pa configuration patching and added a udev rule so pulseaudio doesn't enumerate the device twice (which it was doing) udev rule targets the specific VID:PID of the onboard ALC4040 so external USB cards still work (currently listening to a 2007 Creative Labs X-Mod) <-- Card is crappier than I remember. Maybe some caps are bad after 11 years of abuse/neglect, I hear audible noise in my headphones. Build and test if you would, it will be in the next release. [edit] Kernel 4.18 is now bootable, but needs some love before it's ready for use: http://ix.io/1lpi

4.14? As for Rockchip, if any help is given @Myy from Rockchip for VPU, 4.4 will be irrelevant.

This is the method used on RK3288.

The s905x uses a dwc3 controller but runs high-speed out to the world. Ask Amlogic, I have no idea why.

bump, since kernels got another update and 4.14 appears to be the kernel of the week. I can't remember but is this Xenial-specific? Never mind, <ctrl>-f doesn't find things in the teasers, I found it.

I wanted to use mine for occasional transcoding of live tv or videos to smaller devices to save bandwidth (prior to the XU4Q and my involvement here), so it might be liquid cooled. (No, I'm not saying it is a sane solution, however I've found that the XU4's SoC does not respond to most cooling solutions well, and it was fun trying to make a miniature liquid cooling rig. ) It works quite well, but the pump is its own (less annoying) noise source. I need to hook the small radiator fan into the system PWM port so it stays off 99% of the time. And package it. It lives in my basement next to the ethernet switches, so I neglect it. :-/ I have to think the SoC probably needs a board that can dissipate heat away from the bottom of the SoC as well, given how much heat I find on the bottom side under load. @tkaiser, do the HC1 or 2 have a copper plane for this that you know of? (And no, to the general audience, I am not saying anything is poorly made, I'm simply considering that an avenue for improvement if it has not already been taken) It hadn't occurred to me that any of these vendors weren't doing that until I found out that it was a "new feature" on the Pi 3B+ . My XU4 was similar, I was able to get it to 49 with new thermal paste and biasing the pressure between the springs of the fansink (the SoC is nowhere near the center, so the thought that the fansink sits flush is a bit silly). With a thermal epoxy-held copper 15mm water block I get 31 at idle, and it hits 85 within 10 seconds with minerd. I agree with this, and if needed you can use a small (40mm^2) fan which is fractionally as loud as the fansink (which is amazingly loud). A 12V one will run at lower RPM with the 5V input, since that heatsink is large enough, it's just not overly efficient as tkaiser mentioned. Any forced draft will improve it. Interesting tidbit, I can see throttling occurring but I'm still showing cooling state = 0 on armbianmonitor. [edit] that's with kernel 4.9.61. 4.14.66 is not showing that issue.