• Content Count

  • Joined

  • Last visited


About TonyMac32

  • Rank
    Embedded member

Profile Information

  • Gender
  • Location

Contact Methods

  • Website URL

Recent Profile Visitors

12497 profile views
  1. 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.
  2. 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.
  3. Are the kernel config differences unable to be added to our current ones? Same with the wifi, is there some kind of incompatibility?
  4. I did this differently, I simply used zfs-dkms and then set up my pool. no containers or anything needed.
  5. 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
  6. 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?
  7. 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
  8. 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)
  9. 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.
  10. 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 )
  11. 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:
  12. 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:
  13. 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.