Jump to content


  • Posts

  • Joined

  • Last visited

Other groups


Profile Information

  • Gender
  • Location

Contact Methods

  • Website URL

Recent Profile Visitors

18344 profile views
  1. Are you trying to power the board via the GPIO? I don't think there is a GPIO to shut off the 5V pins from within the board itself.
  2. https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc#L20 This is the default for Meson64. No one added the actual top speeds for the Vims apparently https://github.com/armbian/build/blob/master/config/sources/families/meson-g12a.conf#L5 is the override for the Meson G12A. G12B needs something similar in here: https://github.com/armbian/build/blob/master/config/sources/families/meson-g12b.conf
  3. https://github.com/armbian/build/pull/3979
  4. I have never used Amlogic's nasty vendor code. Ah. I've never tried it on that kernel, given we won't ever support it. I'll be reviewing 5.19. That said, the driver is mainlined, there shouldn't be any work on our side. In the past I was patching in Jerome's series for GX and GXL to get the audio out.
  5. Hello cyph84, Yes, this was working in the past, I can take a look.
  6. I've pushed the fix to the build system, this new forum organization stuck my answer at the very top so it was removed from the discussion flow.
  7. So far no luck. We do have a redundant patch adding the nodes, but that isn't the culprit. The driver complains it doesn't have the host-drv pin defined, but it's shared with the USB2 (same situation between Renegade and Rock64) EDIT: A PHY driver was added back in the dark days before USB3 support by the kernel. It is only used by the Rock64 and Renegade, (and apparently also the RK3328 Station M-whatever). I've removed the entries and USB3 is working again now that mainline supports it without said special case driver. I will open a PR tonight with the fixes.
  8. I'll take a look momentarily, the same patch enabled the usb3 for both the Rock64 and the Renegade, and it looks like mainline has that enabled by default but the patch still exists. May or may not be a cause, I would hope redundant entries simply got ignored...
  9. I'm not sure the purpose of this, to be honest. All of U-boot on eMMC vs only the SPL does not seem to make any functional difference to me.
  10. I have this hat and a couple potato's, if you can provide the scripts I could take a look. I am just getting my lab/office set back up, so it might take a bit longer to review than hoped for.
  11. Please provide logs/dmesg/ armbianmonitor -u output so we can have some idea of what if anything is going on in the kernel. If it's U-boot related and you have a serial UART for debug, that would also be helpful information.
  12. Right. The C2 doesn't put as much effort into the Pi header compatibility as a lot of other boards. I haven't used one for GPIO partly for that reason. I need to add some of my other boards to this but: https://docs.google.com/spreadsheets/d/1dJq7MM1_zA5HtXywDMZ9HMKyPaNgGmkxnuz3wYuk4s8/edit?usp=sharing
  13. I checked bluetooth recently, I'll have to look again.
  • Create New...