Jump to content


  • Posts

  • Joined

  • Last visited

 Content Type 


Member Map




Everything posted by TonyMac32

  1. Right, confusing is, they were correct for quite some time, so my curiosity is: What changed? Perhaps someone updated for one of the newer boards without checking for collateral damage.
  2. 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.
  3. 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
  4. https://github.com/armbian/build/pull/3979
  5. 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.
  6. Hello cyph84, Yes, this was working in the past, I can take a look.
  7. 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.
  8. 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.
  9. 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...
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. I checked bluetooth recently, I'll have to look again.
  15. https://github.com/torvalds/linux/blob/09688c0166e76ce2fb85e86b9d99be8b0084cdf9/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts#L294 all the GPIO on the headers should be there.
  16. Awesome, I didn't notice this before, I have no fewer than 3 I.MX8M boards I'd like to have builds for. I will take a look at this.
  17. The device tree file name and the compatible do not and almost never are the same. This may be a bug in the scripting, but it has nothing to do with an error in the device tree.
  18. The "Invalid" tag is cancer. That needs to be "Off-topic", "Out of scope", "needs clarification" or something else. Honestly we are actively rebranding ourselves as a toxic community at a terrifying rate.
  19. The RAM controller was being starved for voltage. I have recently rectified this problem and moved to the official mainline USB3 driver for this board. The GPU and DMC share the same regulator, so there was conflict. https://github.com/armbian/build/commit/ee610096bc5d252307789c3818aa8b59147bf1d5
  20. I don't have the board either, but here is the detail: The miniDP is usually (exclusively other than this specific board) routed through a TypeC port controller. As a result, the driver relies on an ext-con node and endpoint to assign the display port. A patch was submitted that was a bit of a hack to mainline to create a 'virtual' power delivery controller that was permanently stuck in "type-c miniDP alt mode". This patch did not apply/work for me and the person who was testing it at the time. They should have just stuck with a TypeC with fusb302, it would have been more useful for anyone not wanting to run the display, and it conforms to the state of the Rockchip codebase. As I'm about to dig back into all the other boards that implement the expected configuration I'll see if any progress was made on this front. Without the board it's really hard to debug such an edge case though.
  21. @ning I just caught up with the forums, I've not been on them in a long time. Please keep all political discussion off of these boards. Also, please stick to English for the benefit of the community in general. @axzxc1236 You could use something like this https://www.amazon.com/MakerFocus-Raspberry-Expansion-DockerPi-Compatible/dp/B07VK5L164/ Just double check it has no special connection that only works with the Pi 4. There are a lot of these available from various vendors.
  22. So far my Jetson Nano won't get to desktop using the images on the download site. I have the original one, is this a device tree issue?
  23. I'll have to take a look at it, I also have to implement this on a couple other RK3399 boards so I'll review the T4 first to make sure my example is still working
  • Create New...