piter75

  • Content Count

    287
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 got a reaction from Matthias in NanoPi M4 V2 - M4 Image not working   
    This is good but let's see if it keeps being stable.
    I still think that we are covering up for some other issue with this cpu frequency governor behaviour change 
  2. Like
    piter75 reacted to Matthias in NanoPi M4 V2 - M4 Image not working   
    I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
    But of course, that's not a prove against crashes...
  3. Like
    piter75 got a reaction from Matthias in NanoPi M4 V2 - M4 Image not working   
    @Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
    The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.
  4. Like
    piter75 got a reaction from TCB13 in NanoPi M4 V2 - M4 Image not working   
    @Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
    The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.
  5. Like
    piter75 got a reaction from TCB13 in NanoPi M4 V2 - M4 Image not working   
    Could you possibly test it with 4.x on M4v2?
  6. Like
    piter75 got a reaction from NicoD in NanoPi M4 V2 - M4 Image not working   
    Did you build the kernel yourself?
    I have committed a fix (https://github.com/armbian/build/commit/8c93385a84e2c8847ad5cf03684bee9c58596bf7) to the build system a few days ago. It should fix issues with the most common MTU of 1500.
    It will be build into some future kernel / image build.
  7. Like
    piter75 got a reaction from aaditya in Solved: Downloading files from Samba shares on NanoPi M4V2 stalls   
    I have taken another route with this PR.
    I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
    With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
    Higher MTUs would require further shortening of the PBL.
     
    I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
    The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.
  8. Like
    piter75 got a reaction from aaditya in Armbian Buster current (with Linux 5.4.y) on the Rock Pi 4   
    Network issues are solved upstream.
    eMMC tweak for your board is not in the build system yet. I will prepare it soon and give you a shout.
  9. Like
    piter75 got a reaction from Matthias in Solved: Downloading files from Samba shares on NanoPi M4V2 stalls   
    I have taken another route with this PR.
    I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue.
    With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled.
    Higher MTUs would require further shortening of the PBL.
     
    I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit.
    The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.
  10. Like
    piter75 got a reaction from Igor in why armbian images aren't booting on rock pi 4b?   
    The issue is fixed in v5.4.11 - I removed the patch from the build system for future builds.
  11. Like
    piter75 got a reaction from aaditya in Rock Pi S, RK3308 CPU, is it supported by anything?   
    See my post regarding Armbian for Rock Pi S on Radxa's forum.
     
    Since then:
    kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested.
    I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks.
     
    Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6.
    I will probably prepare a "dev" kernel with one of 5.5 RCs soon.
  12. Like
    piter75 got a reaction from Nagy István in Rock Pi S, RK3308 CPU, is it supported by anything?   
    See my post regarding Armbian for Rock Pi S on Radxa's forum.
     
    Since then:
    kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested.
    I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks.
     
    Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6.
    I will probably prepare a "dev" kernel with one of 5.5 RCs soon.
  13. Like
    piter75 got a reaction from TonyMac32 in Rock PI 4 A not starting   
    Totally agree. This is the only way to get help in this case.
     
    This crossed my mind before and I think it is a good idea.
    We already have it in place for Rock Pi 4b (it was implemented before we had Rock Pi 4a as a separate board) and it works well when used with the same u-boot version on eMMC and SD.
     
    @raidboy you can try to use Rock Pi 4b image which has priority set to SD and see if it works better in this scenario. Nothing is guaranteed as you are mixing stages of u-boots compiled with different configurations and even different code bases so... YMMV.
  14. Like
    piter75 got a reaction from aaditya in Armbian Buster current (with Linux 5.4.y) on the Rock Pi 4   
    So it seems to be the same issue I had.
    I will add the patch to the build as it does not seem to harm the eMMC modules that boot also without it.
     
    The problem is definitely with 5.4.7+.
    Others also started noticing and patching for it: https://gist.github.com/jakogut/bc21de0535b640f2374c1d07a710e8ab
    I did not notice it as currently I am mostly spending time with NanoPi M4V2 which have mdio and phy nodes already setup in device tree.
    Will dig a bit more into that issue.
  15. Like
    piter75 reacted to Panzerknacker in ROC-RK3399-PC (Renegade Elite)   
    Edit: hack deleted. Link to working patches added.
     
    Patches to enable 12V from MPS MP8859 regulator.
    https://github.com/Reichl/linux-next-roc-pc/commit/54ecff244bee053de72230f0b989b4a480d06ec2
    and it's parents.
  16. Like
    piter75 got a reaction from aaditya in Armbian Buster current (with Linux 5.4.y) on the Rock Pi 4   
    My Rock Pi 4B boots fine from eMMC in hs400es mode with 5.4.x but... I remember having similar issues to yours on one of Rock Pi 4A I had.
    I found the difference between 5.x and 4.4 in regards to hs400es initialisation that made it work but finally returned the unit and did not pursue it any further.
     
    Can you try building yourself an image with below patch applied or use the precompiled image I shared and see if it boots fine using eMMC?
    fix-hs400es-init-on-some-boards.patch
  17. Like
    piter75 reacted to chwe in NanoPI 4MV2   
    there's a tool to test this:
     
    https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test
     
    @tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind
    https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3
    https://github.com/armbian/build/issues/546
     
     
  18. Like
    piter75 got a reaction from mad in NanoPi M4 V2 - M4 Image not working   
    Well... exactly. It also freezes some more packages.
     
    I am not much of a "UI" guy ;-)
  19. Like
    piter75 got a reaction from TonyMac32 in ROC-RK3399-PC (Renegade Elite)   
    Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:
    lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.
    This should workaround power issues when powering from usb-c with pd compliant power units.
  20. Like
    piter75 got a reaction from gounthar in ROC-RK3399-PC (Renegade Elite)   
    Well... the troubles are not with the power units per se but with the combination of issues in mainline kernel for this board:
    lack of support for MP8859 buck-boost converter which means it always provides 5V instead of switching to 12V possible misconfiguration of FUSB302B PD chip driver used in roc-rk3399-pc If I understand the patch correctly, Markus made some modifications to the power curve of fusb302 PD chip to switch usb-c voltage to 15V when more power is needed.
    This should workaround power issues when powering from usb-c with pd compliant power units.
  21. Like
    piter75 got a reaction from Hugh Cole-Baker in ROC-RK3399-PC (Renegade Elite)   
    Sure, I was thinking about it.
    Feeling motivated by your message  I will do that tonight
  22. Like
    piter75 got a reaction from NicoD in NanoPi M4 V2 - M4 Image not working   
    A lot of credit goes also to you
    Once again thanks for testing the images since the beginning.
     
    As for the slow boot it plaques now all rk3399 boards.
    I am tempted to bring the following hack to Armbian: https://gitlab.collabora.com/rockpi/linux/commit/ea2fb5589b4cd92728a6139ee5043945d3e10173
    I am using it for weeks now in my builds and don't regret it ;-)
  23. Like
    piter75 got a reaction from NicoD in NanoPi M4 V2 - M4 Image not working   
    I rebased my branch onto latest master changes.
    Took me some time to make the sound working in kernel 5.4.
     
    Branch is now named nanopi-m4v2-bring-up and supports "legacy", "current" and "dev" targets.
    Did not test "legacy" much yet but "current" 5.4 works quite well.
    In dev wi-fi is broken, but anyway "current" is much more compelling as it is 5.4 vs. 5.4-rc1 in dev.
     
    Command line for "current":
    ./compile.sh BOARD=nanopim4v2 BRANCH=current RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no  
  24. Like
    piter75 got a reaction from Fred St-Pierre in ROC-RK3399-PC (Renegade Elite)   
    The kudos belong to Levin Du of T-Firefly team who did the heavy lifting.
    I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399.
     
    Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.
  25. Like
    piter75 got a reaction from Fred St-Pierre in ROC-RK3399-PC (Renegade Elite)   
    What we have right now is, probably, exactly what you wanted to achieve:
    Option 2 for building Option 3 for packaging This boils down to having all bootloader components built from source code as opposed to having to load binary blob from vendor in the process.
     
    I am not an expert on ATF but I understand it as a firmware running in a secure zone of the processor with a set of interfaces (eg. PSCI for power control) that let it interact with the rest of the software.
    Not using ATF would mean that one had to code those interfaces themselves.