TonyMac32

Those "things" are insane. Is the shipping system run by some kind of mafia? Surely the EU can handle simple shipping more effectively than that?

Mine booted quickly and easily with the Firefly image, I need to try to make an Armbian image for it at this point. The case/heat sink are also very nice

@Tido I've cycled the micro-USB on my tinkerboard hundreds (if not over a thousand) times, the resistance has increased, making it more susceptible to power issues, but nothing has broken. Same for my "S". In a static situation where the user is going to set it up and leave it with a switch (official Tinker supply, loverpi supply, etc), I don't think this is a real concern. For a hardware tinkerer, yes.

@chwe I think I have clearly outlined the issues with the Tinker, although, magically it seems, the PMIC seems to make all the difference, voltage drops don't wipe out the SD/SoC, worst case seems to be USB peripherals disappearing.

Well, the USB hub isn't the end of the world, since it isn't the center of the system's modern connectivity like a Pi. I'd take one if I could get it.

Mine wouldn't reliably make it through a movie... :'( I had to put my media center back to my Pi 2. That was before some of the "magic" secret VC4 blob updates that limited clock speed, and did who knows what else... So maybe it works as stable as my Pi 2 now.

Fair, however the Tinker S is $85, and you don't have to buy RAM and an SSD for it like the already $130 NUC (OK, a case). I haven't tried the media script on my RK3328 boards yet, but they are slower than the RK3288 or RK3399 by a wide margin in desktop use. Perhaps https://www.amazon.com/Z83-W-Fanless-PC-x5-Z8350-Support/dp/B07FXL6NLM No idea how well linux supports those little thingies, I know it can boot, but peripherals, well...

I just set one up last night, no issues. You need to do it on a clean install I think for best results. Sent from my Pixel using Tapatalk

Don't forget the Tinker Board, RK3288 with 4.4 kernel supports full hardware video decoding, Mali Midgard, etc. 2GB RAM and available eMMC. I set one up as a desktop for a usability test, there are no noticeable performance issues in desktop use, and the kernel support is mature, whereas rk3399 is still WIP.

This is then a peer-to-peer topic, not a board support question. I've moved it over and merged in your other post. Things to look for: Make sure the drive mounts at boot, make sure the samba user has access to the drive, and then set up the share permissions properly. I have done this using Google as my guide several times (I don't do it enough to memorize the steps)

For the tinkerboard, if you have a case that can accommodate it, it is good to either power it with 5.25 volts (and 3 amps) or through the gpio header with 5.1 V of clean power. As JMCC said, all minus the BPi are good choices. I use an XU4 for my media server on SD, I've never had any issues with SD corruption (anecdotal I know, but I had far more trouble with Pi's, enough to start trying to port a HAT library to literally any other platform rather than just use the Pi I have on my desk)

You didn't answer my question. I also see this is a double post with one that was already moved to peer to peer.

Is there a problem with the board recognizing the drive, or is the issue in setting up the network share?

The function might be able to be hooked into the makedeb part of the kernel build script, I haven't spent more than 2-3 minutes considering the option, mostly brainstorming, since this won't be the last such piece of code.

@Tommy21 perhaps a snippet of the errors? :-)

It might also be worth looking into simply scripting the cloning and compiling of such out of tree code as part of the board configs, the amount of work to graft this stuff in can be time consuming. On another note, did you get the firmwares into the package system?

It's not taking the config you're feeding it, if it's doing what it did to me when I tried it. I know it's not in his 'need to do' list, but perhaps @Neil Armstrong can shed some light? I've stuffed Midgard drivers into the kernel for in-tree compilation without much difficulty, but these sources are messing with me. I also don't claim to be a wizard or a professional.

http://linux-meson.com/doku.php DVFS should be available, look for dmesg errors concerning that.

I'm going to hazard a guess that https://forum.armbian.com/forum/34-hardware-hacks/ Might have the information you're looking for, there are 3 different "general-purpose" gpio libraries there, if the rock64 isn't in any of them, the documentation is relatively clear on how to add them.

OK, I had a situation change, and a client for the device even if I can't use it here, so I now have one of these DAQ's. I woke up a Pi2 from a probably 7 month hibernation, and am looking at how it works. The trick now is to eradicate all the broadcom-based stuff and move the code over to a different GPIO framework.

Don't forget Rock64 Rev 3. I'll take one of those and an Pine H64 B, please.

I don't see why it *couldn't* if all the pieces are in place. The question is whether or not the driver stack and applications have all been set up properly for that, which isn't as easy as a standard device with proper support. This is where Rockchip's uniqueness is unhelpful.

You've reminded me to double-check the ram configuration on Renegade and Potato, they may be slow.

I think the challenge was to boot it on your own board. :-P Sent from my Pixel using Tapatalk

I went 2-layer, of course they both have surface mounts on both sides, so it might be hot air reflow time. Sent from my Pixel using Tapatalk