piter75

  • Content Count

    287
  • Joined

  • Last visited

Reputation Activity

  1. 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
  2. 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
  3. 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.
  4. 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.
  5. 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
  6. 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.
     
  7. 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.
  8. 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.
  9. 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.
  10. Like
    piter75 got a reaction from Werner in Board Bring Up Station P1 rk3399, M1 rk3328   
    Oops... It seems that I have broken it even before it was introduced  - after one of the mainline updates to roc-rk3399-pc.
     
    It needs different device tree than mainline. Linking it to a proper filename should be enough.
     
    I will post a quick fix tonight.
  11. Like
    piter75 got a reaction from BiNiCKNiCH in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    No problem 
    Care to share what drive do you boot with SPI?
     
    Thanks for sharing the drive info 
    I will add it to a known working list.
  12. 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.
  13. Like
    piter75 got a reaction from TRS-80 in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    That's the cultprit - u-boot does not recognise your SPI flash chip.
    I only enabled XTX flash chips for ROCK Pi 4 as those come preinstalled but I should enable some more of them especially for owners of v1.3 that did the soldering themselves.
    I will try to squeeze it into v20.11.2
  14. Like
    piter75 reacted to Igor in Armbian v20.11.y Bugfix release(s)   
    Bugfix v1 was already pushed out:
     
    [AR-551] - Update fan configuration, enable network LED and enable UPS timer Updated Helios64, Rockpi 4* images and rockchip64 kernels  
    Bugfix v2
     
    Let's try to patch other critical things before Christmas. I already addressed ZFS problem on Focal by adding most recent DKMS package, but to solve it also for Buster it requires all kernel recompilation - in case you want to push some late changes, now it's the time. The Beast can handle that in no time  We hopefully fixed Odroid HC4 (don't have HW to test), added KVIM2, DVFS on mvebu will be disabled from now on to secure stability (moving to 5.9.y ?) ... What will fail if we update Allwinner to 5.9.y? Mvebu? Rockchip.hf is ready. 
     
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000@ebin-dev @Heisath@chwe@ning@lanefu@gprovost@aprayoga@5kft @JMCC@karabek@Igor@martinayotte@tkaiser@selfbg@Siraj@jock@going 
     
    What else can be squeezed into this mini quick release? Smaller, almost done, things only.
     
    I would also like to point out that we are progressing nicely with:

    - updated Desktop variant (sits in our main build repository under the branch "desktop"), where also some other general things has been changed. Merge into master is estimated 2/2021, early adopters are welcome. There are other changes, not just desktop.
    - native ARM building. Need more testing, but basics are working.
     
    Today +7 days?
  15. Like
    piter75 got a reaction from TRS-80 in NanoPi R4S   
    At this point roc-rk3399-pc is the only one with blob-less boot sequence by default but it's certainly possible with some others too 
    https://github.com/armbian/build/blob/master/config/sources/families/rk3399.conf#L19
    And it's LPDDR4 too...
  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 JMCC in AMD Threadripper 3990X Armbian Build Server Review   
    Okay, another use case. This one will bring some surprises.
     
    Let us imagine we want to compile natively armhf/arm64 binaries. Like, for example, making the new Armbian multimedia packages that we will announce very soon
     
    In this case, the Threadripper will be in clear disadvantage, since it needs to virtualize the ARM CPU through Qemu. But, will it be able to make up with core count and sheer processing power? Here are the numbers. We will compare the Threadripper with the Ampere ARM server, and with my highly optimized Odroid XU4 (good cooling and slight overclock).
     
    First, a single thread 7-zip bench (Decompressing MIPS, higher is better):
    $ 7z b -mmt1 Threadripper (native amd64): 4793 Threadripper (emulating armhf): 1529 Ampere ARM server (native armhf): 2889 Odroid XU4 (native armhf): 2160 As you can see, the single-core performance of the Threadripper is reduced to 1/3 of its natiive performance when emulating through Qemu, leaving it well below the Odroid XU4 and the Ampere.
     
    Now, a real-world use case: let us compile our customized version of Kodi for armhf (compilation time, lower is better):
    $ time cmake --build . -- -j$(nproc --all) Threadripper (emulating armhf): 18m9.696s Ampere (native armhf): 5m50.033s Odroid XU4 (native armhf): 45m50.711s The 32-core ARM server beats here the 64C/128T AMD server for more than three times shorter compile time. And Odroid XU4 gets just slightly above double the compile time of the AMD. If we factor in power consumption, it becomes very clear that compiling in an emulated environment is very suboptimal.
     
    Now, we must remember that for building Armbian images we don't emulate, but instead cross-compile. In that case, the AMD is working natively, and that is another story. In that case, the AMD has absolutely no match with the ARM server, or anything else I ever tested. We will probably post numbers about this in some other opportunity.
  18. Like
    piter75 got a reaction from TRS-80 in Rock Pi S won't boot with custom builds   
    I remember building the ROCK Pi S image a few day ago and it was working fine. I will build again to verify it.
     
    Refer to the output/debug/install.log to see if there are any errors during initramfs build.
  19. Like
    piter75 got a reaction from JMCC in Armbian v20.11 (Tamandua) Planning Thread   
    I took a shortcut and enabled SPI by default for ROCK Pi 4.
    I verified it with SPI CLK shorted on v1.4 but obviously it was not enough
    The fix is in master.
  20. Like
    piter75 reacted to Igor in Armbian Donations   
    Assembled - first boot of Ubuntu 20.04 looks very very nice  But it was tense ... "what if it will not work?"
     
    Also NVME and SATA DOMs are recognized but 10Gb NIC. Which probably need more recent kernel ... and water cooling doesn't fit into the case. Currently mounted outside, which might even not be that bad.
     

  21. Like
    piter75 reacted to Werner in Forum adjustments   
    To strengthen the symbiosis between Kobol and Armbian a new dedicated club has been created for Kobol products with Armbian support. It will be maintained directly by Kobol associates @gprovost and @aprayoga.
    Check it out:
     
  22. Like
    piter75 reacted to Igor in Armbian Donations   
    2 x NVME arrived, memory tomorrow, CPU, cooling and 2x DOM ETA next week.


  23. Like
    piter75 reacted to NicoD in 32-core 3.3Ghz ARM Server Review   
    Today I had the pleasure of benchmarking an ARM64 server.
    This server has been made available for Armbian to test native ARM64 image building.
    I knew nothing about the server. Nobody told me any details.
    So everything was an adventure for me to find out. I got SSH access, so my research began.

    A lscpu informed me it had 32-cores all clocked at 3.3Ghz. 
     
    cat /proc/cpuinfo confirmed these 32-cores
     
    Checking on what kernel we're on. Ubuntu Focal 5.4.0-52-generic. 
    And how much memory. 128GB RAM.

    So first thing I wanted to know, how does one core perform with 7-zip benchmark?
    The record I had seen until now was from the A73 cores from the Odroid N2+ clocked at 2.4Ghz. 2504MIPS decompression.
    So :
    taskset -c 31 7z b
     
    This beats the Odroid N2+ its A73 cores clocked at 2.4Ghz. 2763 vs 2504MIPS decompression. 
    This also tells me these cores do not perform as good per clock as a high performance core. 
    While doing the single core benchmark I checked the sensors to know the wattage and temperature.
     
    CPU power is about 20W for a single core tasks. 
    Without a load the CPU consumes between 10W-15W. So in total it consumes a bit more than 20W in idle.
    Temperature never went under 49C even after +5 minutes in idle. 
     
    Of course, the next thing to do is an all-core 7zip benchmark. 
    This gives an amazing result. Way higher than anything I had ever seen on ARM.
     
    85975MIPS decompression. This is amazing.
    Best I had seen was 11000MIPS of the Odroid N2+. So this server does 8 x better than the N2+. 
    Tho, I must say. 7zip does bad with unequal clusers. The N2+ has a great difference in cluster frequencies. So it performs worse then expected here. 

    The wattage went a lot higher, up to 110W. And the temperature rose quickly up to 75C in seconds.
     
    To test the internet connection I downloaded an Armbian image multiple times. Sometimes it was as low as 3MB/s. 
    Highest average speed I've seen was 12.5MB/s
     
    Next test. BMW Blender render benchmark. 
    Here the fastest I had ever seen was by the Khadas VIM3. That did it in 42m51s.
    I haven't done this yet with the N2+ in Armbian. In Odroid's Ubuntu it was a little slower. I expect it to be a little faster than the VIM3 in Armbian Bionic. 
    This is a tile based test. So every core gets its own task, until all tiles are done. 

    Well, this ARM64 server did this in 8m27s. 
    5 x faster compared to the Khadas VIM3. 

    For this the wattage didn't go over 85W. But the temperature did rise to 83C. So it started to throttle. 

    @lanefu already had done SBC-Bench on it when it was free. So this I didn't have to do myself.
    http://ix.io/2Dcc
    Here we see a lot. For example the CPUMiner did : 81.0kH/s 
    The Odroid N2+                                                         : 14 kH/s         5.7 x less 
    RK3399 does a maximum of                                     : 10.23kH/s     8 x less
    Odroid C2 clocked at 1.75Ghz                                   : 4.65kH/s       17 x less

    So this server clearly can move a lot of bits around. 
    Now, what is this server? Ask google if nobody else tells me. "32 core ARM server 3.3Ghz"
    First answer : https://www.theregister.com/2018/09/18/ampere_shipping/
    That looks like it is this CPU. But still I can't find the exact name. 
    2nd answer : https://www.servethehome.com/ampere-32-core-64-bit-arm-chip-x-gene-3-ip/
    So this is the Ampere 32-core 64-bit from X-Gene 3 IP.

    Here the wikichip : https://en.wikichip.org/wiki/apm/x-gene/apm883832-x3?fbclid=IwAR0ljCQ61DY8Zwh_VyZd0fQH43dmPUTJA-CGLiQKYqU2fWwszFm1CPjH6Zo

    This supports up to 1TB RAM. 8 channels @ 2666Mhz. With a maximum memory bandwidth of 158.95 GiB/s.
    42 lanes of PCIe Gen 3, with 8 controllers
    – x16 or two x8/x4
    – x16 or two x8/x4
    – x8 or two x4
    – Two x1

    4 x SATA Gen 3 ports, 2 x USB2. And a TDP of 125W TDP.

    For me this is just an awesome thing to behold. I use ARM for almost everything.
    The NanoPi M4V2 is my main desktop computer.
    It isn't as powerful as my PC, but does the task for 10 x less power consumption, while being completely silent.

    But when I need a big CPU, it isn't enough.
    Even the more powerful Odroid N2+ isn't powerful enough to render long, +20minutes 1440p video's for example for my Youtube channel.
    So then i need to use my x86/amd64 PC. 

    Today I have seen and tasted the future. 
    While this doesn't use the most modern Cortex/clusters. And it is only 16nm.
    So there is still a lot of room for improvements in performance and lower power consumption. 

    ARM for desktop is possible, and ARM servers for big datacenters is possible(AWS). I have seen the future, I loved every second of it. 

    Here benchmarks compared to my SBCs

     

    Greetings, NicoD
  24. Like
    piter75 got a reaction from Pedro Lamas in NanoPi M4V2 randomly crashes   
    @aprayoga Fingers crossed!
    I remember playing with "regulator-ramp-delay" with M4V2 before (after noticing slow big cpu cluster transitions) but I probably did not got that high and definitely did not see that post you mentioned (and was not successful).
    I started some tests with 40000 right now.
     
    @Pedro Lamas if you want to also try testing it...
    Save below overlay into a file in your M4V2 (let's name it rump-delay-test.dts), run "sudo armbian-add-overlay rump-delay-test.dts" and reboot your M4V2.
    /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; fragment@0 { target = <&vdd_cpu_b>; __overlay__ { regulator-ramp-delay = <40000>; }; }; };  
  25. Like
    piter75 got a reaction from Pedro Lamas in NanoPi M4V2 randomly crashes   
    Yes. They are treated as separate groups/clusters when it comes to scaling and they also have separate regulators assigned to them.
     
    cpufrequtils however cannot configure their limits separately - the same limits are applied to both clusters