• Content Count

  • Joined

  • Last visited

About Reddwarf

  • Rank
    Elite member

Recent Profile Visitors

542 profile views
  1. Probably the driver for your chip is not implemented in 5.3 yet, remember it is a Release Candidat...
  2. Which Armbian version are you running? If it is one with kernel 5.3-RCx tyr one with kernel 5.2
  3. I assume the WiFi will be supported eventually, but it the GPU supported? And how is the AM3 compared to the AM6 performancewise? Will the remote work with Linux Touch?
  4. Hard to say with only that message. Do you have the correct kernel headers installed? It may be that your kernel does not support that kind of driver, but I'm not that familiar with drivers to say for sure.
  5. Can you post the console output from trying to load the module?
  6. AFAIK these are universal images, just edit uEnv.ini to point to the correct DTB (or extlinux.ini).
  7. And where/how is that option enabled?
  8. @balbes150: Is the source on Github always up-to-date with the latest image you have released? And once downloaded, will the source automagically update itself each time it is compiled?
  9. FYI there is a bug (missing dependency) in Ubunto 19.x Disco with xfce4 which leads to an issue starting programs from the menu. It can be fixed with: sudo apt install libexo-1-0 and things work as expected again
  10. I don't know but you could try to download one of the images for Odroid C2 and see if there is a DTB, then try to use that DTB with Balbes image(s). BTW: Does the C2 have the same cpu type as the Amlogic TV-boxes?
  11. There is a separate build for Odroid C2,
  12. Easy enough if you know where they are found. This should be cleaned out by the build script as a first step. Not good enough. Besides, the "build" directory of /lib/modules/<vesion>/ needed for compiling 3rd party drivers is completely missing from Armbian...
  13. So why nag about dtb's when the problem is with the packages, I don't follow the reasoning.
  14. debs and DTB's are not the same, or what? Emptying the output folders should be done by the script, that's the accepted way of doing things, or there should be a "make clean" option. Now, I'v done a lot more testing and it turns out that if you enable an option with build error, resetting the configuration dos not help, the script will crash on the next build. Even deleting the whole Build-Armbian folder and cloning it fresh does not help. This suggests that there are temp- or working-folders left behind that are not cleared before the next build. So some more work needed on the script(s). Since I have no way of knowing where those resides the only way of resetting I found is to delete the whole virtual machine and create it again. Anyway, the script works for some kernel configurations but some (useful ones) crashes.