Jump to content

TonyMac32

Moderators
  • Posts

    2400
  • Joined

  • Last visited

Posts posted by TonyMac32

  1. 14 hours ago, ebin-dev said:

    You should be very careful with Armbian updates until Armbian on Helios64 is maintained by someone.

    image.png.3ad1520738edc5c453dceeee293433c6.png

     

    Fully Agree.  I might have a replacement for the Helios64 on the way, if/when it arrives I'll be able to do some tests on the Helios64 as it won't be my active machine, but as you see above I haven't updated in a *long* time.

  2. 10 hours ago, desperex said:

    Did anyone try to port collabora's patch for rock5b? 

     

    Not so far, I stuck the tree for this board in mainline and it will be available with 6.6.  I haven't messed with the USB3 yet, the collabora kernel is my secondary interest for this board, and, since I don't really get anything out of it, the board isn't my first priority either outside of personal interest. 

     

    I'll look at lowering the eMMC frequency, but some actual testing for errors will be needed to make sure 150 MHz is truly "good" and not just "tolerably bad" for the driver  :D

  3. On 8/16/2023 at 6:47 PM, Patrick Pesch said:

    param_spidev_spi_bus=0
    param_spidev_spi_cs=0
    param_spidev_max_freq=1000000

     

    is entirely dependant on the device tree overlays handling fixups, or is that RPi style syntax? 

     

    In any case I already found an issue with the overlays for this family (spi-spidev overlay as written is in fact only applicable to rk3399 https://github.com/armbian/build/issues/5778) , I'll add one for rk3328 spidev, it will not work the way you have above though since fixups are super hacky.

  4. Raspbian has it's own things going on, and is using the Libre Computer kernel, tuned for their boards.  I will need to take a look and see what has disturbed the Le Potato image in our distro, it's not immediately obvious but these boards share kernels with a lot of devices and sometimes we step on each others toes.

  5. Hello switch,

     

       While the RK3328 does have the hardware, the crypto patches have not made it into the mainline kernel yet:  https://patchwork.kernel.org/project/linux-rockchip/list/?series=680902

     

    As a result the hardware crypto won't be available.  That patchset infers it is identical to the crypto module in the RK3288, so as long as the RK3399 parts of that deries don't tie it up, it should be applied soon.

  6. I've had trouble supporting this board, a lot of "s" variant boards in particular do not like to boot using mainline ATF. The only reason there are mainline images is because I created a device tree/got a supply driver/etc.  The DP over type C should work provided the device tree is updated, you can find examples on several other RK3399 boards we support.

  7. 40 minutes ago, NicoD said:

    First off, the VIM3 has all its cores clocked to 1.5Ghz by default.

     

    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

  8. 1 hour ago, cyph84 said:

    when you say it was working, do you remember if its mainline's implementation or Amlogic's BSP code?

     

    I have never used Amlogic's nasty vendor code.

     

    1 hour ago, cyph84 said:

    On Armbian's 5.17.5-meson64 kernel:

     

    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.

     

  9. 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.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines