piter75

  • Content Count

    287
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 got a reaction from Chalix in How to make a SD card bootable with U-Boot   
    @Chalix You have done quite a research already
    Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
     
    U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
    You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
     
    The recipe to write the images to device (more or less) is to be found here.
     
  2. Like
    piter75 got a reaction from hartraft in How to make a SD card bootable with U-Boot   
    @Chalix You have done quite a research already
    Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
     
    U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
    You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
     
    The recipe to write the images to device (more or less) is to be found here.
     
  3. Like
    piter75 got a reaction from gprovost in How to make a SD card bootable with U-Boot   
    @Chalix You have done quite a research already
    Helios64 is Rockchip RK3399 based so you are better off with the theory found here http://opensource.rock-chips.com/wiki_Boot_option as a starter.
     
    U-boot and vendor blob binaries are found in "/usr/lib/linux-u-boot-$BRANCH-helios64_$RELEASE_arm64" folder on your system.
    You are probably using "current" $BRANCH and the latest $RELEASE is 21.02.3.
     
    The recipe to write the images to device (more or less) is to be found here.
     
  4. Like
    piter75 got a reaction from NicoD in Nanopi M4 V2 power issue   
    Something similar to this hat most probably ;-)
    https://www.aliexpress.com/item/33029451117.html
  5. Like
    piter75 got a reaction from Pedro Lamas in Randoms reboot NanoPi M4V2   
    With that setting you are actually disabling the DVFS after the short period of time during boot - before cpufrequtils kicks in.
    My experience is that you could also set it to min/max 2GHz and it would be just as good.
     
    Yes, this mod/tweak/hack ;-) fixes the behaviour of my boards with ondemand governor.
     
    It seems that the instability of little core's voltage during the voltage change was the issue.
    Rockchip has already limited max change per single step for this regulator to 100mV (because of "overshooting") and I did limit it further to 50mV (75mV was still unstable).
    It takes a bit longer to switch between frequencies now (at least 456uS vs at least 196uS for full swing between 408MHz and 1512MHz) but it is stable.
  6. Like
    piter75 got a reaction from lanefu in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    I am not sure of that.
     
    My understanding is that we are still building release images from master branch and the removal of this line from targets.conf:
    -rockpi-4b legacy focal cli stable yes means that focal legacy image for rockpi-4b will not be built.
    Lack of focal legacy image among 20.02.3 release images (built after the referred commit was merged) seems to corroborate that theory ;-)
  7. Like
    piter75 got a reaction from Lennyz1988 in Randoms reboot NanoPi M4V2   
    Glad to hear that.
     
    BTW The fix is now included in Armbian v21.02.3 images
  8. Like
    piter75 got a reaction from i5Js in Randoms reboot NanoPi M4V2   
    Glad to hear that.
     
    BTW The fix is now included in Armbian v21.02.3 images
  9. Like
    piter75 reacted to Igor in Armbian v21.02   
    So far its planned to rebuild them all. Building one or all its pretty much the same trouble  
  10. Like
    piter75 reacted to Heisath in Armbian v21.05 (Jerboa) Release Thread   
    Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
    (let me know if this is a bad date, because it is around easter holiday in Germany for example)
     
    Code Freeze: 2021-04-19 (Monday April 19th)
    Release Date: 2021-05-09 (Sunday May 9th)
    Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
    Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
    Coordinator: @Heisath
     
    The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
     
    Open topics:
    - complete desktop branch merge into master (this seems generally done, but might need fine tuning)
    - enable 3D support (also done? Bugfixing)
    - discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
    - check if remaining boards can / have been updated to LK5.10 (some were left out last release)
    - check possible u-boot updates
    - complete remaining Jira issues
    - cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
    - late topics: 
    - business meeting schedule
    - kernel config changes on arm64
     
    Release Planning Meeting Agenda:
     
    Please add developers and more topics below, I will then also add them here.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali
  11. Like
    piter75 got a reaction from Werner in Randoms reboot NanoPi M4V2   
    @i5Js you can download these packages and install them with apt/dpkg: https://users.armbian.com/piter75/nanopim4v2-stability-fix/
    You need both of them for the fix.
     
    When they are correctly installed and the board is rebooted you should see this message in your dmesg:
    piter@nanopim4v2-4:~$ dmesg | grep rk808-regulator.*buck [ 2.840331] rk808-regulator rk808-regulator: max buck steps per change: 4 The last "4" means you have the fix. No message or "8" means you don't have a fix.
  12. Like
    piter75 got a reaction from frod0r in NanopiM4V2 (Rockchip RK3399) RAID with mdadm appears to write wrong/ corrupt data   
    Could you test this image with your procedure?
    It should fix the issues with voltage scaling on little cores cluster that made my units unstable and fail in the first loop of "memtester 3280M".
    With the fix it run 150 loops without failures.
     
     
  13. 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/960GB
    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 PM981 256GB
    XPG SX6000 Lite 128GB (ASX6000LNP-128GT-C)
     
    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.
  14. 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.
  15. 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. 
  16. 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/960GB
    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 PM981 256GB
    XPG SX6000 Lite 128GB (ASX6000LNP-128GT-C)
     
    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.
  17. 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>;         };
  18. Like
    piter75 reacted to gounthar in Station P1 - unboxing   
    Mine is 000048.
  19. 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.
  20. 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 ;-)
  21. 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.
  22. 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.
  23. 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
  24. 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.
  25. 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.