TonyMac32

Members
  • Content count

    312
  • Joined

  • Last visited

About TonyMac32

  • Rank
    Embedded member

Contact Methods

  • Website URL
    http://www.electricgraveyard.com

Profile Information

  • Gender
    Male
  • Location
    Michigan

Recent Profile Visitors

823 profile views
  1. rockchip hardware crypto on Tinker Board?

    I've added XZ for squashfs to dev and enabled crypto, I confirm it's loading and new ciphers reflected in /proc/crypto. I'm not sure what would be causing issue, trying to get some more background on it.
  2. Trying to boot NanoPi-K2

    @zador.blood.stained hit it on the head, there is no u-boot in balbes images. If you still get the loop with a custom image, the u-boot blob isn't being written to the correct position on the card, so the first stage bootloader isn't seeing it. Now I don't know why you might be able to get to a u-boot prompt "after a while". That doesn't sound healthy. I have the u-boot source from the June Amlogic sources, what board is the K2 most like, maybe I can build a blob for you that will work.
  3. Rock64 Mini NAS and media center, works?

    Client side of course transcoding is irrelevant to the Rock64, but server side it is not. I was able to call up videos while in central Mexico from my server in Michigan thanks to transcoding, firstly I have a 5Mbps uplink and secondly the distance and network quality were less than ideal, I certainly wouldn't call it a dead duck.
  4. Kernel -rcX : Last version issues

    Why can't things just work??? Thanks for the heads up @Myy
  5. rockchip hardware crypto on Tinker Board?

    Welcome to the forum! Not on my part, do you have the logged errors you were speaking of? I was unaware of that entire system, looks interesting enough. Is there a specific benefit over normal package management, ease of publication/etc? Also, how on earth do you snap boot files and kernels? Ok, off-topic... Perhaps simply pull request with changes and explanation. @Igor, any harm? Or maybe a feature we'd want?
  6. UAS + mainline kernel + coherent-pool memory size

    Is there an indication that SZ_1M is enough? Synolgoy: https://forum.synology.com/enu/viewtopic.php?t=109025 It looks like 1024k was too small for DVB transport in their case, I find this of interest as I can see an OMV setup with TV tuner being a popular use case (personally biased). I can patch it, although determining if it worked is another matter. I can not, for what it's worth, come up with any downside to increasing it, unless of course it cuts too much into available RAM.
  7. Rock64 Mini NAS and media center, works?

    That's exactly what I did... I maintained some servers for fraternities when I was in college, I learned a few relevant tidbits. The RAID box I have has eSATA as well as USB 3 and presents itself as a single drive rather than as a port replicator. But yes, I'm sure that's not the best USB 3 to SATA bridge in there, it's on its fifth year, any trouble and I may simply go to a pair of mirrored redundant disks without all the overhead. My current setup is designed around the idea of highly disposable clients with permissions, so centralized staorage was key. However, it is, to the fully functional clients, as you suppose: they have full copies to reduce traffic on the network itself, synchronized for changes. For the Rock64 I've seen their little hat with the fast ethernet and sound, I'd be more interested in a fast Ethernet to cover an HDHomerun in a dedicated fashion. For Plex, and I can say this as I run it, I hate their transcoding scheme. I think they should have that portion of their work wholly documented so interested parties can improve hardware support. As it stands the Plex transcoder is 100% software on all platforms but select PC's (which need this advantage the least) This is important for the next point: The XU4 is capable of transcoding in software, at least with my really stupid cooling system (what throttling?), I am not sure the Rock64 will have that ability. If the transcoder were truly open for development, it would be possible to have transcoders for these lightweight ARM devices. This is, of course, unimportant if all of your devices support direct streaming of everything you want to watch, or you're not going to stream outside the home. I've been watching Emby develop, I may need to try it out if I can get ffmpeg working properly on Rock64 and Tinker Board, having a more or less shared vcodec system. (Tinker is more primitive). When I say "I" it's actually more likely @Myy, who is working to get it working on mainline while I cheer enthusiastically. This board has a barrel jack, so that's a positive. It is tiny though, so I can't be certain it has a very high current rating, often the miniature ones top out at 1 to 1.5 amps. I have not done my normal power testing on the Rock64, but I doubt it will disappoint. Type C will not be a solution for a few years yet, because of the saturation of microUSB and the availability of $1 for three adapters to USB Type C. Sadly the reality will be properly designed boards being powered via a meter long AWG 24 cable at 5.0 Volts through a microUSB to Type C adapter. I have a wired home network, not for speed but rather for reliability, I have many neighbors, all with wireless, and several who think that Channels 2, 7, etc are valid for use.
  8. UAS + mainline kernel + coherent-pool memory size

    I'll let that other Dev with a Tinker Board take care of it.
  9. Rock64 Mini NAS and media center, works?

    As far as the RAID5 on USB 3, I have to say I do agree with @tkaiser , even if I do run that exact setup. An example: my RAID box now has a chassis supply in it and some wire hackery after the garbage factory supply failed and would have left me data-less. USB3 connectors are crap, I've had to reset that several times over the years due to it just magically ceasing to work. (It's a full-size A to B), those extra conductors in the top half are the culprit). I bought a second drive to mirror the array as a doomsday backup, and the only utterly irreplaceable data (photos) I have incremental backup running to a cloud drive. I have an XU4 serving that purpose for now.
  10. The VPU driver

    Hmm, it may be about power consumption as well, if the driver doesn't bring it up (like a headless application) you might save some mW. As it stands I'm going to patch to enable them all in the board DTS's. I'll take a look at that bluetooth driver tonight as well. If it could do PlanetSide 2 I'd be happy. Of course that game makes my i7-6800k cry, and it's a 4-year old game...
  11. The VPU driver

    Right, the patch is changing that to "disabled" for mainline, unless a new revision comes out. You don't think you need a 16 GB RAM rk3288 board?
  12. TonyMac32

  13. Debian Stretch Porting and Optimizations

    For curiosity I built Stretch for the Tinker Board a week or so ago, it worked then. Let me try it again and see/share the results.
  14. The VPU driver

    I started adding some current Rockchip patches to the 4.13 dtsi for rk3288, there are a couple iommu entries added that are related to the vcodec. I haven't pushed them yet because either adding them in "disabled" state or the 64-bit register values in these entries shut down my HDMI output, I had to status ok them in the dts for the board and fix the 64-bit entries. For the curious, Rockchip is pushing to use 64-bit values to support lpae: https://patchwork.kernel.org/patch/9878101/ They are making other patches assuming this one will go through, although it hasn't been accepted yet. https://patchwork.kernel.org/patch/9878013/ https://patchwork.kernel.org/patch/9907831/
  15. Banana Pi R2

    Yeah, I kind of signed off when a FriendlyARM document got put up as BPi's, and contradicted the post it was in. Not to mention this happened minutes after I said we should be open and honest if we want this thing to work out. I'm very disappointed. Now, since I don't know the structure of BPi's company, it is possible Lion just copied that from their blog, where the same falsification existed, without realizing. That's why I didn't jump up and down and rant about it. As you can see I've done my best to continue a civil conversation. Perhaps others would care to endeavor to likewise treat us with improved control of their tongues. Or fingers, as it were.