• Posts

  • Joined

  • Last visited

Everything posted by TonyMac32

  1. 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.
  2. @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 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.
  3. 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?
  4. 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
  5. I have a Tinkerboard 2, the only thing causing any issue is the use of a variant of the standard buck converters to power the big cores and the GPU. I have not gotten this converter to operate properly using the (really ugly and hackish) mainline Linux driver. Since the existing Mainline Linux driver is pretty much crap, it makes it very difficult to add the variant. @JMCC a differentiating factor for the Tinker 2 includes it's power input/management, which is extremely robust (it can power all USB ports per specification, unlike any other SBC I am aware of save the Tinker Edge R) and its use of the newer revision RK3399 which supports 2.0 GHz with no overclock and uses less power overall. The nanoPC T4 would be my only recommendation for an alternate that is currently supported due to its feature set and design. Ah, it also has a socket for standard PCIe wifi modules, which makes it possible to upgrade. I will be revisiting the driver code to figure out why I haven't been able to make it happy, the variant is not incredibly different from the normal device.
  6. This is true. However, I see little value in another kernel for any single board. The Station boards do not warrant that much special attention, let them exist without wifi until support can be properly managed by the vendor if they want Armbian. The world is overflowing with RK3328 and RK3399 boards. 🤷🏼‍♂️
  7. Right, an overlay was added for the 2 GHz OPP, it is not stable on all boards, there are a lot of rk3399's out there.
  8. I need to check the legacy kernel and see if it has the DRAM issues mainline had, that might account for all of these issues. [edit] I've verified the DRAM timings on legacy do not mach those I pulled from the vendor kernel and applied to mainline. I'll take a look.
  9. I just ran into this as well, if you download the server image you can install the desktop through armbian-config. I just did it on Tinkerboard about 20 minutes ago, watching "The Italian Job" on Kodi right now.
  10. Are the kernel config differences unable to be added to our current ones? Same with the wifi, is there some kind of incompatibility?
  11. I did this differently, I simply used zfs-dkms and then set up my pool. no containers or anything needed.
  12. Hello @joey99, This is a bit of a complicated question, I'll give it my best shot. The Raspberry Pi GPIO's are tied to the Broadcom SoC and as such are named accordingly. This will not be the numbering found on any other board with an open market SoC. So the numbers will never line up on anything else, since no one is allowed to buy the processors used by the RPi foundation. To the GPIO on the RK3328 (The SoC found in the Rock64), Rockchip arranges it's GPIO thusly: Bank ---> Group ---> Pin The RK3328 has GPIO0,1,2,3 Each has a theoretical 32 pins, grouped A0-7, B0-7, C0-7, and D0-7 Linux will assign these a scalar value, IO 0- whatever the top number is. That's where my knowledge ends. In short, your hat should work, assuming you have the drivers for it and can extract the proper pin numbers out of the documentation. [Edit] and on second look ,that display is HDMI, but I assume you were thinking of SPI LCD's. A GPIO TFT LCD will not be compatible as the Rockchip pins for parallel LCD are not sent to the same places.
  13. I just received my Helios64, I immediately checked it for the Magjack center point to ground concern, and mine tests that it is connected. Is there a revision number on the board which can be used to identify the clean point between the pre and post fix boards?
  14. power delivery through USB-C. Oh and mode switching. So if it set to the mode you want by default it should be ok, but the better question is why was it eating clock cycles
  15. burning an image for test [Edit] H3 boots fine H2+ as well As an aside, is it an H5 board? that will require a different image than the H3 (The Tritium came in H2+, H3 and H5 variants)
  16. I just did a quick test on Le Potato, increasing CMA to 512 MB was very easy following the above instructions with the /boot/dtb/amlogic/meson-gxl-s905x-libretech-cc.dtb device tree. The property yo uwant to change is right at the top of the file as a handle under "reserved-memory" Any value that is 0x400000 aligned should be valid, so you can experiment.
  17. Thankfully the kernel does not need recompiled for this, only the device tree. See the post below, I b elieve this is still accurate as far as device tree decompile/recompile method, can be done on the device (use the correct device tree for your board )
  18. Hello uniformBuffer, The CMA memory is set by a device tree entry, so that would be the only way to change it to my knowledge. The drivers are extremely unoptimized presently for the vdec/venc, and the recommended setting is over 800 MB. This is an obvious problem for a general-purpose distribution, it renders the La Frite 512 MB boards unbootable, and leaves no real room for any working tasks on the 1 GB ones. It may be possible to implement this as an overlay, but in the meantime modifying the device tree is the only route: This patch gives you the handle and value to get the required 896 MB CMA pool.
  19. Remember the bcm2835 is the RPi SoC, you'll find no drivers for that mess in an Armbian distro for another SoC. You need to see if I2C is enabled via overlay for your board, and if you have an overlay for the specific RTC, in this case looking at your documentation rtc-ds1307. If you don't want the kernel to be using it, you should be able to probe for it on I2C0 and use some reference materials on the web to operate it:
  20. Hi sulfuroid, I would look at a USB keyboard, unless you want to start writing device drivers. There are some projects out there for hooking the buttons to a micro and reporting as an HID that might make it easier. I have never tried it though.
  21. For some info: The boot process explained: Sent from my Pixel using Tapatalk
  22. Which image are you using? Sent from my Pixel using Tapatalk
  23. Good luck with the deployment! Sent from my Pixel using Tapatalk