JMCC

Members
  • Content count

    272
  • Joined

  • Last visited

About JMCC

  • Rank
    Elite member

Recent Profile Visitors

517 profile views
  1. JMCC

    Librecomputer Renegade RK3328

    Have you figured out if it is something specific for certain hardware configs / board revision numbers? Mine is 1Gb RAM, rev ROC-RK3328-CC-V1.0-A, and I am experiencing the SD card issues that can be observed in the logs posted here. It seems like in this post, @switch confirmed that he was not having SD card issues (he posted a link for "armbianmonitor -u "results, but now he deleted it, probably privacy concerns?). He has a 4Gb board. @Da Xue Would it be useful if we all posted here our board RAM size and revision number, together with a succint statement saying whether we have card problems or not?
  2. JMCC

    Librecomputer Renegade RK3328

    We have other problems too with Ayufan's kernel on Renegade, like the SD card related I experience in my board. Firefly's kernel is basically a Rockchip kernel from February 24 2018 plus about a dozen patches, while our current Ayufan kernel seems to be remotely based on a Rockchip kernel from May 2017, with hundreds of patches on top. I know the SD card problems are not in any Armbian patch (I tried disabling them all), but locating the problem in the Ayufan's history seems extremely difficult. Probably the network speed problem will be difficult too. Just in case, to make sure the problem is not in our Device Tree patches, you may want to try your tests with the Firefly image and the attached DTB. rk3328-roc-cc.dtb
  3. https://docs.armbian.com/Developer-Guide_Build-Preparation/ By using the Armbian build script, you can build a Stretch image for the C1, and also a TB image with custom kernel config. However, the TB kernel is currently not usable from the build script, because of upstream changes that broke the build. Developers are working on it, and eventually they will bring it up again.
  4. Seems like GLES is still working, and it was only the glshim/gl4es wrapper that broke. The laggy experience you are having now is mot probably because it is using MESA software emulation for OpenGL, instead of glshim/gl4es. I suggest that, whatever the method you used to originally install glshim/gl4es (compile? deb packages?), you try to revert it (sudo make uninstall / apt-get purge -packages-), and then reinstall it.
  5. A question about Forum structure: There are those forums labeled as "Tech support", for supported boards, which I understand are only meant for support questions. Then, there is a "Peer to peer support" category, for questions that do not pertain strictly to Armbian tech support. But very often people post other kind of questions, related to supported boards, in the tech support forums, even though they are asking for some kind of help that goes beyond strict tech support and would be better in Peer-to-peer assistance. I see that sometimes Devs get upset about it, and you guys have your point, but it is also true that it is more intuitive to go directly to the forum labeled with your SoC, rather than going to the community forums category below. So we must assume that those things will happen, and it is an understandable mistake. Maybe we can find some way to re-structure the forum somehow in the future to avoid that confusion. But, in the meantime, I suggest that Devs just ignore those questions, and leave them for the community, if they don't feel like answering them. Eventually, some mod may move them to the community subforum, or not. I think that leaving it unreplied is better than the Dev telling the person "you should not ask this question here"; it wears you out to answer that again and again, and you guys have enough worries already, no need to add unpleasant experiences for you in having to make those answers. And also, it can give sometimes an impression of hostility against newcomers.
  6. I haven messed that much with Allwinner H3's mali, but I can tell you that in many other SoC's, there is no (socname)_dri.so because that is a OpenGL library, and Mali GPU's only support OpenGL-ES. Many programs throw that error when trying to look for the lib in an ARM-based board, and that doesn't necessarily mean that anything is badly configured. I'm not sure if there is some wrapper that provides a kind of "bridge" library, like "whatever_dri.so", to replace the lacking library in OpenGL-ES based GPU's. I think it is totally Retropie related . As you said, Everything works well in Armbian, until you run the Retropie install script, which breaks it. So the solution here would be to debug the retropie install script, and see where it breaks the feature you need.
  7. Moved to Peer-to-peer technical support, since Retropie is not part of Armbian. As a suggestion, I think @jernej's OpenElec has a different mali driver, you can try to patch it to Armbian kernel and try how it works. More info here: https://blog.danman.eu/orangepi-installing-openelec-chroot-into-armbian/
  8. JMCC

    Librecomputer Renegade RK3328

    It seems like a normal number to me.
  9. JMCC

    Librecomputer Renegade RK3328

    Here's the situation: I tried using their device tree (which is very similar to the one we were using before I made the last PR), but that makes our kernel unable to initialize SD card, as happened before that last PR I mentioned. So I was assuming that a recent kernel like ours introduced some incompatibility with the old device tree. But, now that you mention, it can also be that they are using some patch we don't have. If I am able to pinpoint that patch, it can be introduced per-board without affecting Rock64, can't it?
  10. JMCC

    Librecomputer Renegade RK3328

    Can you please do somethings that performs intensive SD card I/O, like for example: $ sudo apt install libreoffice And then, post here the output of: $ sudo armbianmonitor -u
  11. JMCC

    Librecomputer Renegade RK3328

    Thanks for the hint. Disabled both zram and ramlog, with no difference. I'm still trying to figure out why I'm the only one experiencing the problem. Could be a defective unit, but then why does it work with Firefly's image?
  12. JMCC

    Librecomputer Renegade RK3328

    Got a brand new Samsung Evo+ 64Gb, and same failure: FS corruption after a few writes. My board only has 1Gb RAM, that is the only difference I can think of with the rest of your boards. So @tkaiser do you think there is any chance that the new ZRAM implementation can be causing this problem? I've seen nothing in the logs that may suggest something like that, but if you can have a look: http://ix.io/1g8E
  13. +1 for moving the discussion to the other forum.
  14. Way to go! And the Ayufan kernel has DT overlays already implemented, so that's another goal that would be fulfilled by making that kernel work with RK3288.