piter75

  • Posts

    294
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 reacted to catalinii in Do you like to see your favorite board supported?   
    Radxa rock-3a github.com/catalinii
  2. Like
    piter75 reacted to ebin-dev in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    @piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').
     
    It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.
     
    You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.
     
  3. Like
    piter75 got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  4. Like
    piter75 got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  5. Like
    piter75 got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  6. Like
    piter75 got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  7. Like
    piter75 got a reaction from lanefu in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Armbian "current" (5.10.y) compiles without issues.
    I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
    I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
     
    However I did find that with the unit I have the issue happens only in hs400{,es} modes.
    With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
     
    If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
    Upgrade the kernel to 5.10.60, but don't reboot yet.
    Run:
    curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
    If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
    There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
    Below you can find the comparison between hs400 and hs200 modes using iozone.
     
  8. Like
    piter75 reacted to NicoD in Videos : What it takes to maintain Armbian   
    Hi all.
    I've done a collaboration with @Igor, the creator of Armbian.
    He shows and talks about the hardware that is used to maintain the project. Servers, boards, other electronics, ...
    Enjoy!

    More videos to come.
     
  9. Like
    piter75 got a reaction from FossCoder in Rock64 - same mac on two boards   
    This is actually good news that they are present and are different
    Do you see the production week markings on top of the package? What is it? - both of mine are 1810.
     
    I must admit that this scenario crossed my mind when I read that you have two boards. The explanation is a bit long but pretty simple...
     
    Many boards that Armbian support does not have a stable MAC address and have it randomly generated on each startup.
    On the first run Armbian checks the current MAC and creates the NM connection configuration with this random MAC as cloned address.
    Thanks to this the next time you boot the board it uses this MAC instead of another generated one achieving some degree of stability - until next reimage.
     
    With Rockchip (rk3328 and rk3399 at least) it is a bit different as the MACs for first two ethernet interfaces are generated based on CPUID stored in CPU's NVRAM.
    Armbian does not recognise it (not all versions of u-boot can do this generation) and also saves this MAC as a cloned MAC in NM connection settings.
     
    When you switched the SD card between boards you started assigning a stable MAC address from the first board to the second one (as a cloned MAC) and the first one was still using the same stable MAC that's assigned to it ;-)
    The best you could do IMHO in this situation would be to simply delete the cloned-mac-address stance from connection files on both of your boards and enjoy two stable and different MACs for your boards
  10. Like
    piter75 got a reaction from FossCoder in Rock64 - same mac on two boards   
    Is the result of the following command anything different than mine?
    root@rock64:~# xxd /sys/bus/nvmem/devices/rockchip-efuse0/nvmem 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ Both of my rock64 CPUs have their efuse empty and thus both also have the same mac address which is generated by u-boot and based on CPUID. CPUID should be present in bytes 0x07 - 0x16.
    I always wondered if it is a common issue...
    I also have ROCK Pi E and NanoPi R2S - both based on RK3328 - but they have their efuses set.
     
    Did you deactivate and activate the connection after editing cloned mac address?
     
    My "/etc/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection" looks like this and it overrides the default mac address
     
     
  11. Like
    piter75 reacted to NicoD in Review of the PineBook Pro with Armbian   
    Hi al.
    I've finished my review of the PineBook Pro. I just love this thing. Runs great with Armbian.
    Here my video.
    Here all my gathered information:
     
  12. Like
    piter75 got a reaction from Thireus in NanoPi R4S   
    It will be fixed with https://github.com/armbian/build/pull/2877
  13. Like
    piter75 got a reaction from TCB13 in [Invalid] - NanoPi M4V2: SPI Not Working   
    @TCB13 I am a bit late to the party but I figured it may still be needed ;-)
     
    spi-spidev is a special / dynamic overlay. Besides enabling it you need to also configure it and armbian-config cannot currently do that.
     
    For configuration options have a look here:
    https://github.com/armbian/build/blob/master/patch/kernel/archive/rockchip64-5.10/general-rockchip-overlays.patch#L98-L126
    You can also consult the local README file located in: /boot/dtb/rockchip/overlay/README.rockchip-overlays
  14. 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.
     
  15. 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.
     
  16. 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.
     
  17. 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
  18. 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.
  19. 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 ;-)
  20. 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
  21. 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
  22. 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  
  23. 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
  24. 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.
  25. 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.