TonyMac32

Why not?

In my case, "Clean up your bench, you slob" - Magic Smoke

I've designed some 315 MHz stuff, and honestly know I can't do higher frequency RF design well enough to show anyone. One of My Tinker S's sacrificed themselves during testing, I had the poor thing perched over some random crap, too much of which was conductive. On the bright side, the converter can tolerate short circuits quite well. The Tinker S, not so much.

Not a bad idea, interestingly the KiCad template doesn't have that done, I'd kind of ignored it while trying to get the grounding of that buck converter sorted. It's a bigger footprint than I wanted, but that's because those cute little Chinese boards you get don't follow any of the guidelines on the L and C values, or how the grounding should work... I noticed my libraries are broken on my GitHub repo for this, giving anyone cloning it a ton of "?"'s, I'll have to mess with it to either move all the symbols I need into the repo itself, or whatever. #1 gripe about KiCad is library management. I'm working on an ESP32 board for my day job, I went ahead and got the wroom32 module (or something like that. I'm not feeling my best today and am not going hunting for them. ) Was thinking about one for fun on my own time, but that stuff really gets as much OSS/OSH attention as I think anything can stand.

Well, Oshpark turned around my order in 5 days, so I was able to build one today: So far no problems, 5.16 V open circuit voltage, nominal design intent was 5.20, so within tolerance.

If you can't do it via mode setting with the appropriate values for the timings, I don't think so, this would be a display driver issue or some complication with the specific monitors handling of that resolution.

http://www.fdk.com/whatsnew-e/release20181217-e.html Ridiculously low energy, but interesting

the vender kernel is the only one with hardware decoding of video, "default" in our system

There was a change of default to mimick the vendor behavior, that was later partially reverted, I think this is part of that situation. I'll poke at it and provide a separate thread to discuss it and a solution. @Martinayotte the vendor went from one uart to another between releases, most likely due to blocking a HAT's compatibility. Sent from my Pixel using Tapatalk

@Igor just verified. Flashed 4.14 from our download archive, then did an apt update/upgrade. Bricked eMMC. So then: Plugged Tinker into USB port on Linux Machine, it booted in UMS. As root on Linux machine, copied rk3288-miniarm.dtb from link above into /boot/dtb folder sync'd umounted/etc. Booted tinker with proper supply, booted normally. I do notice the linux boot messages aren't showing up, it just says the starting kernel line and then after a bit shows the login prompt. I can check that out, probably bootargs. We can push the updated dtb package, which will include the miniarm dtb.

Ah, well, the screw isn't hitting anything, everything is clear and no dangers of any interference. The point is, there is only a set of slots on the HDMI side of the case that hinge together, and that single thumb screw actually holding it together. There's no risk of it coming apart, but more or less it means the case can rattle around a bit, and the SoC to thermal block is dependent on that being tight/stable. having 2 screws instead of one would reduce the rattling and avoid disturbing the contact between the SoC and the aluminum block. As for the heat, I will address that in my follow-up: Yes, it eventually does get to the point of throttling, but if you're going with fanless it's assumed you're not 100% all day long

@Jmcc I briefly tried it, didn't get anywhere. That would be ideal of course, have it as a patch. Sent from my Pixel using Tapatalk

Your classic Tinkers were running "default" vendor kernel, your S's were running "Next". Next was updated to 4.19, default was not. @igor I will try to repeat the fix tonight, I'm still thinking you did something differently than myself or the OP. The device tree for Tinker in 4.19 is set up for overlays and has a lot of things disabled, including the debug UART (maybe was bad idea, but it is enabled in the images by default via overlay). To fix old installs, I reintroduced the 4.14 device tree as "miniarm", which those installs were looking for anyway. That's what worked for me and the OP. It's not beautiful, but neither is u-boot in general. [emoji846] Sent from my Pixel using Tapatalk

the new one has 2, and a big inductor that looks like a small office building. Yes, all of my components sit on the "top", other than the header to connect to the other board. I've taken to using a hot plate with thick steel "heat diffuser" to keep the surface consistent, I don't get any charring that way, the only tricky part is removing boards to cool them acceptably, but I've more or less worked that out, and the hot plate was $25. I will admit SMT is new for me (I hand soldered the boards in this thread, for instance), but so far I'm having decent success.

Yes, Oshpark. I've not been pleased with the circuit itself, it's a bit more sensitive than I like with the FET's and reliance on passives. I have a new one out at fab now using a buck converter, will allow up to 24 V in and output up to 3 amps. I'll be setting it loose in the wild via GitHub and an openhardware.io project in hopes people want to buy me a beer. ;-) that platform uses pcbway and seeed, so you wind up with 10 bare PCB's, unless you provide an adequate BOM for them to build kits. All are good options quality wise, oshpark is a bit spendy if you are doing iterations, but it's also not in China so for me it saves any customs delays (waited on some pcbway boards for 4 weeks after the proposed delivery date one time) Sent from my Pixel using Tapatalk

@wtarreau right, I haven't tried to go past "stock" 1.5 GHz since I haven't really had reason, however on my little bit of testing comparing to some data I think you had, I was able to verify the C2 was the only Amlogic board I have running at the clock speed it was reporting.

@Neil Armstrong It works from what I can tell, also realized I was using the wrong input on my 4K monitor, switched and was able to verify 4k 60 Hz. Awesome! Side note, I saw the patchset land on the mailinglist, will that work on all dw-hdmi 2.0 controllers? [edit] @JMCC this was a fresh build, so your bugfix is verified on my side to work with the 2GB board as well.

Thanks to ASUS, I got my hands on one of these after seeing what appeared to be a giant heat sink fin integrated into the top of the case. This case may be of interest to non-Tinker owners as well, it is not designed like the equivalent Pi cases with a fixed aluminum stud touching the SoC. Instead it has a small aluminum block that has an adhesive side, and a thermal pad side, and is clamped down onto the processor by putting the two halves together. This allows some freedom on the location of the SoC relative to the lid. First off, same nice packaging the Tinker owners are familiar with: The case itself is quite heavy, and a nice color/texture, although the finish is most likely not 100% on this one, as it's pre-production The reason for the weight becomes immediately obvious when pulling the two halves apart: All I can say about this is, if the thermal pad/adhesive aluminum block fit properly, there is a lot of thermal mass here, and I'm perfectly alright with ASUS calling this fanless. The extrusion is very thick, over 8mm in places. Now for the bottom, a comparatively much thinner stamped part, the embossing does it's work to strengthen the base adequately. Something important to notice in this picture: The Tinker sits on aluminum studs, and does not bolt down. The heat sink block holds it in place. I have been told that the two additional holes you see here to the left side of the base are for a VESA mount adapter: https://www.asus.com/Destkop-Accessories/VivoPC_VESA_Mounting_Kit/ I can't verify (no hardware), but the holes are 85mm apart and threaded. Board fits nicely: Now, putting it together only involves 1 thumb screw once you've gotten the aluminum block bit sorted out (a little bit of a balancing act, but not really a problem. This would be my only feedback where I think a different option would have been better: The thumbscrew is located at a position so as to be on center with the SoC. This makes sure the whole stack is making contact, but it also creates a pivot point which rattles when you move the case around. Not a problem for 90% of people, to be honest. In my humble opinion, 2 thumb screws, one to each side, making it a bit more rigid once assembled. Oh, I also pulled out some rubber feet and put them on it, none were provided in the box, and I like the grippy feet. My unofficial testing shows the case very easily outperforming the tiny heat sink thermally, so in that respect it wins. Aesthetically it is a very nice looking product, of course I'd say that should be expected. I'll follow with something a bit more empirical later on.

That I'm not sure of, and I'm also uncertain they were ever "real". I'd have to scour around in here and find what @wtarreau has to say on the matter, since Amlogic processors are under the command of the mighty M4 micro of doom with super-secret firmware. We have the same secret sauce blobs as the legacy u-boot, so it should be there.

The Odroid blob is used for the C2, so it should be able to run up to it's maximum (15xx MHz)

They closed the original and have not resubmitted anything since Sent from my Pixel using Tapatalk

Ok. I'm just relating what I saw last night, changes that failed: -editing armbianEnv locked up after a few seconds at loading kernel. -symlink failed same as above -I forgot to pull the "boot from SD" jumper and it was booting ok after massive errors because of overlays and pulling the SD script after the eMMC one failed. Sent from my Pixel using Tapatalk

@igor the solution that worked on mine was simply dropping the miniarm DTB into the directory and rebooting with the jumper off and the SD out. It sounds like that worked for the OP as well, I think it's safe to push the update. Sent from my Pixel using Tapatalk

If you don't pull the SD card it will fall back to SD, reload the boot script from there, and boot. Probably how the issue escaped in the first place. Sent from my Pixel using Tapatalk

I had to do it as root, then I sync'd and ejected