piter75

  • Content Count

    267
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 got a reaction from Piscenois in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    With Armbian v20.11 one can write mainline u-boot image to board's SPI and enjoy booting nvme drives without any mmc devices.
    Prerequisities: ROCK Pi 4(A/B/C) v1.4 or 1.3 with SPI soldered in (v1.3 comes without SPI flash from the factory).
     
    If you already have Radxa's u-boot written to SPI you need to short pins 23 and 25 for Armbian to boot Boot fresh image of Armbian v20.11.x for ROCK Pi 4(A/B/C) Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's  enable spi-nor by executing (as root):
    echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running
    ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run nand-sata-install choose option: "Boot from SPI - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit Reboot Enjoy Armbian booting with SPI / NVMe  
    Why bother with mainline u-boot?
    It is known to boot some NVMe drives that legacy u-boot from Radxa has issues with, eg. SAMSUNG 970 EVO Plus and SAMSUNG PM981.
    This does not mean that all NVMe drives are supported, YMMV.
     
    Which NVMe drives are known to be working?
    Corsair MP510 240GB/480GB
    Gigabyte SSD M.2 2280 PCIe x2 Model:GP-GSM2NE8128GNTD
    HP SSD EX900 M.2 NVMe 120GB. Model: 2YY42AA#ABB
    Intel SSD 660p Model:SSDPEKNW512GB
    Kingston A1000 SSD 240GB (PHISON PS5008-E8-10)
    Kingston A2000 M.2 2280 PCIe NVMe
    PNY 250GB XLR8 CS3030 M.2 NVMe SSD PCIe Gen3 x4
    Sabrent Rocket 256GB NVMe PCIe M.2 2280
    Samsung 970 EVO Plus SSD 250GB M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s
    Samsung SM981 256GB
     
    Why not using Radxa's u-boot SPI image?
    Ambian's u-boot configuration is incompatible with Radxa's SPI image
     
    Why Armbian is using u-boot that is incompatible with Radxa's?
    It uses mainline u-boot with Open Source TPL/SPL/proper and BL31 from Rockchip packaged into u-boot and we may switch to using open source ATF instead of the BL31 in the future.
     
    Can I boot Radxa's images with Armbian's u-boot written to SPI?
    Yes. Armbian's SPI u-boot is compatible with Radxa's images available here: https://github.com/radxa/rock-pi-images-released/releases
    It may not be compatible with some older images (released before July 2020) because of the device tree filename change.
  2. Like
    piter75 got a reaction from denni_isl in HDMI is broken on RK3399-based boards for high resolution display since Armbian 20.08   
    The tag was always there but at a different configuration level so no need to change it manually ;-)
     
    Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
    Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
    It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
    This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.
  3. Like
    piter75 got a reaction from Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    IIRC I already agreed to changing the patch naming scheme for rockchip64 legacy kernels in the github discussion few weeks ago.
    I would interpret the lack of response from others as indifference ;p
    ... or are we talking about other missing response?
     
    BTW. I also received my mezzanine board which I reordered from AliExpress seller after previous order being cancelled resulted in a refund.
    The order went smooth this time. 
  4. Like
    piter75 got a reaction from Werner in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    With Armbian v20.11 one can write mainline u-boot image to board's SPI and enjoy booting nvme drives without any mmc devices.
    Prerequisities: ROCK Pi 4(A/B/C) v1.4 or 1.3 with SPI soldered in (v1.3 comes without SPI flash from the factory).
     
    If you already have Radxa's u-boot written to SPI you need to short pins 23 and 25 for Armbian to boot Boot fresh image of Armbian v20.11.x for ROCK Pi 4(A/B/C) Add the following lines to /boot/armbianEnv.txt overlays=spi-jedec-nor param_spinor_spi_bus=1 Reboot If you shorted 23-25 pins in 1.) then: disconnect them after the ROCK Pi 4 fully boot's  enable spi-nor by executing (as root):
    echo spi1.0 > /sys/bus/spi/drivers/spi-nor/bind verify that the SPI mtd interface is enabled by running
    ls /dev/mtdblock0 if the last command does not list any file then something went wrong between 3.) and 5.) Run nand-sata-install choose option: "Boot from SPI - system on SATA, USB or NVMe" choose NVMe partition, eg. /dev/nvme0n1p1 accept erasing of the choosen partition with "Yes" choose fs type (tested with ext4) wait a few minutes for rootfs transfer to chosen partition choose writing SPI bootloader with "Yes" confirm that you want to flash it with "Yes" wait ~60 seconds for writing choose Exit Reboot Enjoy Armbian booting with SPI / NVMe  
    Why bother with mainline u-boot?
    It is known to boot some NVMe drives that legacy u-boot from Radxa has issues with, eg. SAMSUNG 970 EVO Plus and SAMSUNG PM981.
    This does not mean that all NVMe drives are supported, YMMV.
     
    Which NVMe drives are known to be working?
    Corsair MP510 240GB/480GB
    Gigabyte SSD M.2 2280 PCIe x2 Model:GP-GSM2NE8128GNTD
    HP SSD EX900 M.2 NVMe 120GB. Model: 2YY42AA#ABB
    Intel SSD 660p Model:SSDPEKNW512GB
    Kingston A1000 SSD 240GB (PHISON PS5008-E8-10)
    Kingston A2000 M.2 2280 PCIe NVMe
    PNY 250GB XLR8 CS3030 M.2 NVMe SSD PCIe Gen3 x4
    Sabrent Rocket 256GB NVMe PCIe M.2 2280
    Samsung 970 EVO Plus SSD 250GB M.2 2280, PCIe 3.0 x4, NVMe, 3500/2300 MB/s
    Samsung SM981 256GB
     
    Why not using Radxa's u-boot SPI image?
    Ambian's u-boot configuration is incompatible with Radxa's SPI image
     
    Why Armbian is using u-boot that is incompatible with Radxa's?
    It uses mainline u-boot with Open Source TPL/SPL/proper and BL31 from Rockchip packaged into u-boot and we may switch to using open source ATF instead of the BL31 in the future.
     
    Can I boot Radxa's images with Armbian's u-boot written to SPI?
    Yes. Armbian's SPI u-boot is compatible with Radxa's images available here: https://github.com/radxa/rock-pi-images-released/releases
    It may not be compatible with some older images (released before July 2020) because of the device tree filename change.
  5. Like
    piter75 reacted to jsorocil in SPI flash boot doesn't work   
    Finally found the problem - HW "issue". My SPI flash is not soldered (no place on motherboard) - it is connected with wires which are (presumably) too long. Workaround is to reduce SPI speed in u-boot and Linux.
     
    U-boot:

    diff --git a/arch/arm/dts/rk3399-rockpro64.dtsi b/arch/arm/dts/rk3399-rockpro64.dtsi index 9bca258012..797dd80d38 100644 --- a/arch/arm/dts/rk3399-rockpro64.dtsi +++ b/arch/arm/dts/rk3399-rockpro64.dtsi @@ -677,7 +677,7 @@         flash@0 {                 compatible = "jedec,spi-nor";                 reg = <0>; -               spi-max-frequency = <10000000>; +               spi-max-frequency = <1000000>;         };  };
     
    Linux:
    Recompile your device tree with reduced SPI speed:

            flash@0 {                 compatible = "jedec,spi-nor";                 reg = <0>; -               spi-max-frequency = <10000000>; +               spi-max-frequency = <1000000>;         };
  6. Like
    piter75 reacted to gounthar in Station P1 - unboxing   
    Mine is 000048.
  7. Like
    piter75 got a reaction from Baptiste in Rockpro64 PCIe NVME boot not working Armbian 20.11.3 Focal with Linux 5.9.14-rockchip64   
    Thanks for testing!
     
    The boot hanging issue has a workaround now in the rockchip64-u-boot-v2020.10 branch indeed and the board boots consistently for me again.
    I don't know if it also fixed those "Timeout poll on interrupt endpoint" errors - I did not observe them with v2020.10.
     
    This is also fixed in the branch with the patch from Sigmaris.
     
    I will also definitely add some polish to the nand-sata-install writing process.
  8. Like
    piter75 got a reaction from NicoD in Board Bring Up Station P1 rk3399, M1 rk3328   
    I had the same.
    They explained after a few days that it had some outgoing customs issues and asked me to place the order again.
    Yesterday I opened a dispute which was resolved by Aliexpress within an hour in my favour and today I got the money back.
    Seeing how well it went with the dispute I ordered it again - it was 0.25EUR more expensive now. Let's see how it fares this time ;-)
  9. Like
    piter75 got a reaction from RussianNeuroMancer in HDMI is broken on RK3399-based boards for high resolution display since Armbian 20.08   
    The tag was always there but at a different configuration level so no need to change it manually ;-)
     
    Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
    Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
    It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
    This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.
  10. Like
    piter75 got a reaction from Werner in NanoPi R4S   
    You can use "dwc3-0-host" overlay in /boot/armbianEnv.txt to enable it now - it switches to port from otg to host mode.
     
    overlays=dwc3-0-host  
    I will prepare some corrections to the device tree soon and will enable the host by default to make it consistent with vendor's configuration.
  11. Like
    piter75 got a reaction from JMCC in Armbian v21.02   
    @JMCC This should do the trick to fix it for boards in rk3399 family:
    https://github.com/armbian/config/pull/134/files
  12. Like
    piter75 got a reaction from gounthar in Board Bring Up Station P1 rk3399, M1 rk3328   
    Ultimately we should have a single kernel source for all rockchip64 devices ;p
    At this point neither rockchip64 nor rk3399 is really fit for that. They do not support rk3308 as a simple example. It should probably be some more or less stable cut from Rockchip's master.
    Until recently I was actually more inclined to move devices from rockchip64 to rk3399 and make it a base for switching to Rockchip's master whether it would be 4.4 or 4.19 (FriendlyElec is already using 4.19 for R4S).
     
    On the other hand boards are now divided ~50/50 between those kernels so we can move Station P1 to rockchip64 if it fits there better.
    We will worry about switching to some form of Rockchip's master later - most probably not earlier than with first rk3568 boards...
     
    As stated above I see no harm in that.
  13. Like
    piter75 got a reaction from Larry Matter in Unable to boot Buster Legacy on NanoPi M4V2   
    Glad to hear that
     
    The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
    After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.
  14. Like
    piter75 got a reaction from Larry Matter in Unable to boot Buster Legacy on NanoPi M4V2   
    Ok, it needs one more change to fix the boot issue (besides working bluetooth).
    Right now the service type is set to forking but the brcm_patchram_plus_rk3399 binary is not forking so systemd treats it as not successfully activated / activating.
     
    Change Type to exec and it should be properly treated by systemd.
    I adjusted it in the PR too: https://github.com/armbian/build/pull/2480/commits/92729573cea1aa786432e1dce42d641019e8bcd4
  15. Like
    piter75 got a reaction from JMCC in Unable to boot Buster Legacy on NanoPi M4V2   
    Glad to hear that
     
    The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
    After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.
  16. Like
    piter75 got a reaction from NicoD in Board Bring Up Station P1 rk3399, M1 rk3328   
    Almost all shipments from Aliexpress come to me through Liege and get here usually within 3-4 weeks - it should be sooner for you 
    One additional factor though is Christmas time...
     
    BTW, I have ordered one too.
  17. Like
    piter75 got a reaction from NicoD in Board Bring Up Station P1 rk3399, M1 rk3328   
    In case neither of you wins this time ...
    https://www.aliexpress.com/item/20000004598102.html delivery to my country is free
  18. Like
    piter75 got a reaction from Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    In case neither of you wins this time ...
    https://www.aliexpress.com/item/20000004598102.html delivery to my country is free
  19. Like
    piter75 reacted to NicoD in Improving thermals on your SBC   
    Hi all.
    I've just finished a new video where I polish the heatsink of my Rock Pi X with sandpaper. This because there's a rather thick powdercoating on the heatsink in the spot where it makes contact with the SoC.
    This caused a lot of thermal resistance. The SoC would get hot and overheat, while the heatsink didn't warm up. And the top of the board was the hottest spot.
    Here my video.

    On the NanoPi M4 and M4V2 there was a thermal pad included. This also was pretty bad.
    I raplaced those with a copper shim and some thermal paste and improved the thermals by about 10C.

    If you like to use your board passively cooled it can be important to look for the details to improve things. This method might also be possible on the Rock Pi 4. I don't have it anymore to test.
    Greetings.
  20. Like
    piter75 got a reaction from NicoD in Unable to boot Buster Legacy on NanoPi M4V2   
    Glad to hear that
     
    The funny thing is that the kernel switching never worked for rk3399 family as it is a bit of a frankenstein...
    After https://github.com/armbian/config/pull/127 is merged and published it should work as expected.
  21. Like
    piter75 got a reaction from Arvo in Unable to boot Buster Legacy on NanoPi M4V2   
    Ok, it needs one more change to fix the boot issue (besides working bluetooth).
    Right now the service type is set to forking but the brcm_patchram_plus_rk3399 binary is not forking so systemd treats it as not successfully activated / activating.
     
    Change Type to exec and it should be properly treated by systemd.
    I adjusted it in the PR too: https://github.com/armbian/build/pull/2480/commits/92729573cea1aa786432e1dce42d641019e8bcd4
  22. Like
    piter75 got a reaction from TRS-80 in Free and Libre Open Source SBC List Thread   
    I might have been a little bit too braggy (and tired)  last night.
    SPI boot for ROCK Pi 4 still uses a single blob file
     
    The other part of the message is correct however - it takes a simple change to the configuration file to enable both blobless boot for both SD/eMMC and SPI and I run my ROCK Pi 4B this way.
     
  23. Like
    piter75 got a reaction from NicoD in Board Bring Up Station P1 rk3399, M1 rk3328   
    It needs some more love than simply using roc-rk3399-pc as base device tree ;-)
    I will try to tweak a bit here and there in the coming days.
  24. Like
    piter75 got a reaction from Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    It needs some more love than simply using roc-rk3399-pc as base device tree ;-)
    I will try to tweak a bit here and there in the coming days.
  25. Like
    piter75 got a reaction from Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    I fixed booting: https://github.com/armbian/build/commit/cd886792c0e4cb9761eddb6e9dca355892663769
    I also switched blue led to heartbeat trigger for a clear indication that the board booted.
     
    It boots but is rather not in the best shape - shutdown takes ages and it probably does not shutdown fully.
    It was most probably my first boot with legacy using roc-rk3399-pc ;-)
    I used roc-rk3399-pc to try it as Station P1 uses non standard headers for serial debig - probably 2.0mm pitch instead of 2.54mm. I need to get those.