Jump to content

piter75

Members
  • Posts

    306
  • Joined

  • Last visited

Reputation Activity

  1. Like
    piter75 got a reaction from molodye in M.2 NVMe SSDs for NanoPC-T4   
    I believe "apt install linux-dtb-legacy-rk3399 linux-image-legacy-rk3399" is what you really wanted to do ;-)
  2. Like
    piter75 reacted to rpardini in rock-5b with vendor u-boot & vendor kernel; PR and test images   
    Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
     
    XFCE desktop with "browsers" app group
    - https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz
     
    CLI
    - https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz
     
    PR: https://github.com/armbian/build/pull/3984 (against master)
    All work by @amazingfate I just gathered stuff and built images.
    Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
     
     
  3. Like
    piter75 got a reaction from Excalibur in Booting ROCK Pi 4(A/B/C) with mainline u-boot in SPI, NVMe and Armbian v20.11.x   
    The truth is I did not test the SPI booting lately. Will give it a shot as soon as I find some spare time.
     
    It's not merged into master yet: https://github.com/armbian/build/pull/3489
  4. Like
    piter75 reacted to catalinii in Do you like to see your favorite board supported?   
    Radxa rock-3a github.com/catalinii
  5. 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'.
     
  6. Like
    piter75 got a reaction from Willy Moto 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 hartraft 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 got a reaction from ebin-dev 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.
     
  9. Like
    piter75 got a reaction from aprayoga 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.
     
  10. 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.
     
  11. 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.
     
  12. 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
  13. 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
     
     
  14. 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:
     
  15. Like
    piter75 got a reaction from Thireus in NanoPi R4S   
    It will be fixed with https://github.com/armbian/build/pull/2877
  16. 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
  17. 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.
     
  18. 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.
     
  19. 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.
     
  20. 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
  21. 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.
  22. 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 ;-)
  23. 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
  24. 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
  25. 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  
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines