piter75

Members
  • Content Count

    127
  • Joined

  • Last visited


Reputation Activity

  1. Like
    piter75 got a reaction from JrRockeTer in Nanopi-M4V2 won't booting from eMMC and does not see eMMC: SOLVED eMMC plugs in opposite way than original M4   
    You are right, eMMC modules are compatible with both M4 and M4V2.
    Do you install eMMC modules the right way? eMMC in M4V2 needs to be rotated 180º vs. the way it was installed in your M4.
  2. Like
    piter75 got a reaction from Dyfcom in Nanopi M4v2 - crash/freeze   
    There are some older threads where people noticed it too, myself included 
     
    Would you like to participate in testing of a possible cure workaround for those issues?
    Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
    If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
     
    I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.
  3. Like
    piter75 got a reaction from aaditya in rk3399 vs rockchip64 family   
    You probably meant RockPro64 which is indeed a SBC name that is now part of rockchip64 family.
     
    Well... IMHO the name is fitting well.
     
    The idea of rockchip64 family is to consolidate one day all (rockchip 64) bit boards if possible - that means all based on 64 bit SoCs, eg. rk3328, rk3399 and rk3308.
    The rockchip64 family is nothing new - it already exists and contains rk3328 and rk3399 boards.
  4. Like
    piter75 got a reaction from aaditya in Nanopi M4v2 - crash/freeze   
    There are some older threads where people noticed it too, myself included 
     
    Would you like to participate in testing of a possible cure workaround for those issues?
    Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 
    If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix
     
    I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful.
  5. Like
    piter75 got a reaction from aaditya in Kernel 5.x.x and rk3399   
    I wonder what was actually changed to fix this.
    Nonetheless we will keep our changes in u-boot for the "current" target which is v5.4.x
  6. Like
    piter75 got a reaction from Werner in Nanopi M4v2 - crash/freeze   
    Mainline kernel is known to be unstable for this board
    Legacy is the way to go for now if you want it stable.
  7. Like
    piter75 reacted to gounthar in Orange pi 4   
    I had a lot of stability issues with the original Orange Pi image, and it's running like a charm with Armbian.
    Thanks, folks!
  8. Like
    piter75 reacted to Igor in THE testing thread   
    FYI. I am talking with Olimex to produce this board in a quantity of around 20 pcs.
  9. Like
    piter75 got a reaction from Jack953 in Orange pi 4   
    Well done!
     
    I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)
  10. Like
    piter75 got a reaction from iamdrq in Orange pi 4   
    Well done!
     
    I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)
  11. Like
    piter75 got a reaction from VyacheslavS in Orange pi 4   
    Well done!
     
    I have added your patches with minor tweaks to the Armbian build system - it will be available in the images from the download area... at some point ;-)
  12. Like
    piter75 reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
     
    Thank you all for attending the meeting!
  13. Like
    piter75 reacted to magixx256 in Orange pi 4   
    So initially I had some trouble booting the Armbian images even the one I built locally.
    I'm certain this was because I had not properly wiped the MicroSD card after trying out the images from Orange Pi (I ended up using gparted to create an new msdos partition table) .
    Anyway I got around to testing some of the images and though I'd post the state of those as well:
     
    1. Armbian_19.11.9_Orangepi4_buster_current_5.4.16_minimal.img
    This was the image found here on Page 3 posted by @piter75
    It seemed to boot fine. eth0 and WLAN exist but I did not get connectivity (this was an issue with my router)
    https://asciinema.org/a/313413
    2. Armbian_20.02.6_Orangepi4_bionic_current_5.4.27_minimal.img
    Downloaded from https://www.armbian.com/orange-pi-4/#kernels-archive-all
    Some issues seen during booting, but eventually it boots.
    eth0 and WLAN exist but I did not get connectivity due to my router
    https://asciinema.org/a/313424
    3. Armbian_20.05.0-trunk_Orangepi4_bionic_current_5.4.27_minimal.img
    Image built locally using the docker guide.
    Kernel seems to take a bit longer to boot and there is no output from it as before.
    eth0 and WLAN exist, after messing with router eth0 works as expected.
    https://asciinema.org/a/313427
    Image available at https://mega.nz/#!jgZmzAzb!yp-g2viNrXAjO-rpM_25meDVBNSxOo2I8gOqD6t-p7g
    4. Armbian_20.05.0-trunk_Orangepi4_bionic_dev_5.5.13_minimal.img
    Image built locally using the docker guide.
    Kernel seems to take a bit longer to boot and there is no output from it as before.
    eth0 and WLAN exist, after messing with router eth0 works as expected.
    https://asciinema.org/a/313445
    Image available at https://mega.nz/#!LpIinS5I!MzscJ_tS5S4_5pcxpz5CZXKUeFxf3LdeE8IBIfORl-A

    All images flashed with Etcher
    MicroSD was Samsung Evo Select 64GB
    Board was OrangePi 4 4GB v1.3 without eMMC (cheapest config for this RAM)
    PSU was the USB barrel connector to a known good phone charger.
     
    I also tried out the mPCIe adapter with a mPCIe SATA card (ASM1061). The speeds were disappointing at max 210mb/s considering the card can definitely do 350mb/s+ in my laptop.
    I had hoped the newest os/kernel version would solve this, but it does not appear to do so. Maybe my testing methodology is wrong but I am doubting this after trying 2 different cards and multiple OSs.
    Another thing to note is that this board runs hot at ~75*C even with a small heatsink (no fan was used) and little going on.
     
    If anyone has something they'd like me to try then please ask.
  14. Like
    piter75 got a reaction from manuti in Rock Pi S, RK3308 CPU, is it supported by anything?   
    Unfortunately... yes. I did not test the upgrade path with latest changes
     
    At this point, if you can discard your install, you can download latest image (v20.02.06 / v4.4.217).
    If you want to recover your install you need to mount the SD in some other PC or SBC and modify "boot/armbianEnv.txt" as follows:
    add line overlays=uart0 change overlay_prefix line to overlay_prefix=rk3308 I will be more careful next time...
     
    As for the Radxa repos I don't use them.
  15. Like
    piter75 reacted to Igor in Added Nanopi R2S   
    + updates to: rockpis, rockchip64 and odroidxu4 legacy kernel
  16. Like
    piter75 got a reaction from gounthar in Orange pi 4   
    Do you happen to be using the same SD card that you used previously for Xunlong's BSP?
    If so this is a known issue: 
     
  17. Like
    piter75 got a reaction from aaditya in Potential OPP issue with NanoPi M4V2   
    We could do that but I am pretty sure, although of course may be wrong ;p, that it's not a CPU frequency issue.
     
    What I observed so far is that most of the time when I cold boot the board I see following lines at the end of DDR training in Rockchip's binary:
    change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 0, cs 1, advanced training done channel 1, cs 0, advanced training done channel 1, cs 1, advanced training done channel 1, cs 0, dq 31 RISK!!! TdiVW_total violate spec channel 1, cs 1, dq 31 RISK!!! TdiVW_total violate spec ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 Those "dq 31 RISK!!! TdiVW_total violate spec" lines do not look promising.
    OTOH most of the times when I reboot the board after some time I do not see those lines which may mean that memory chips used in M4V2 require a bit different params.
    As a piece of additional info, I also tried to use u-boot's TPL to train LPDDR4 in v2020.01 and although it works well for RockPi 4, RockPro64 and ROC-RK3399-PC it ends up with a kernel crash on 100% of boots with M4V2
  18. Like
    piter75 got a reaction from aaditya in Potential OPP issue with NanoPi M4V2   
    I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
     
    I did not have any issues with it on my boards so I did not pursue to change it but...
    When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
    https://github.com/armbian/build/compare/rk3399-disable-overclocking
     
    It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.
  19. Like
    piter75 got a reaction from aaditya in Armbian images do not boot on RockPi4a (with workaround)   
    The reason for this patch to exist is that it is difficult to remove / insert the eMMC module of RockPi 4 while installed with large heatsink and in general I think that SD should take precedence over eMMC in our tinkerers' world ;-)
    Nonetheless I think your use case is valid and it would be great to have a solution that switches to SD only if it is actually bootable. It would then satisfy both cases.
  20. Like
    piter75 got a reaction from aaditya in Armbian images do not boot on RockPi4a (with workaround)   
    Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
     
    Now it looks more clear and a bit unfortunate... ;-)
    U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
    g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
    in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
    I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
    Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
     
    Now the positive stuff...
    @raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
    To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
    Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)
  21. Like
    piter75 got a reaction from TRS-80 in Armbian images do not boot on RockPi4a (with workaround)   
    Wanted to be sure of that. It was not that long ago that we were chasing issues with OrangePi 4 not booting from Armbian with SD that had Xunlong's BSP image on that card before (because of secondary GPT) ;-)
     
    Now it looks more clear and a bit unfortunate... ;-)
    U-Boot 2017.09-02676-g4490220395 (Jul 01 2019 - 07:49:56 +0000) The u-boot image is pretty ancient:
    g4490220395 => https://github.com/radxa/u-boot/commit/44902203959cef9d92dff2f36896c7ec27fb3d88
    in next commit Radxa added DOS partition support to it => https://github.com/radxa/u-boot/commit/59412e4610af669538a057995ed2d418703723a2
    I have a later g674eaa57f0 in SPI and it boots Armbian fine  => https://github.com/radxa/u-boot/commit/674eaa57f03d48aa1803650a901f0244563eea60
    Full history here: https://github.com/radxa/u-boot/commits/rk3399-pie-gms-express-baseline
     
    Now the positive stuff...
    @raidboy to boot Armbian images without creating GPT on them you can simply connect pin 23 with 25 (or any other GND/black) pin on GPIO header. This disables onboard SPI.
    To erase the SPI you could use this guide: https://wiki.radxa.com/Rockpi4/dev/spi-install#Erase_images_on_SPI_device.
    Writing zeroes with dd to /dev/mtdblock0 while being booted with Radxa's image should also do the trick ;-)
  22. Like
    piter75 got a reaction from Neko May in Potential OPP issue with NanoPi M4V2   
    I don't know the reason for the decision to do it, as it predates the beginning of my usage of Armbian, but I tend to agree that we should play safe by default.
     
    I did not have any issues with it on my boards so I did not pursue to change it but...
    When I was suspecting CPU issues with M4V2 I created the changes to disable the overclocking but also to make it easy to overclock with the overlay if one wanted to experiment:
    https://github.com/armbian/build/compare/rk3399-disable-overclocking
     
    It did not fix the M4V2 mainline issues but I think we can reconsider the default behaviour anyway.
  23. Like
    piter75 got a reaction from aaditya in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    I would add the mentioned options to kernel config, built the kernel, copied resulting ".config" file over "linux-rockchip64-current.config" and then commit it.
    It would be great to do the same with "dev" kernel (which is now 5.5.y in Armbian's master) in the same PR for feature parity  
  24. Like
    piter75 reacted to chwe in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    IMO the easiest way is ./compile.sh KERNEL_CONFIGURE=yes make your changes when menuconfig pops up and you get your new config in output/config after compilation. It's even named the way it should be..
  25. Like
    piter75 got a reaction from aaditya in rk3399-bluetooth.service is still present in "systemctl list-jobs"   
    I didn't have time and enough interest in Bluetooth to pursue a solution but one thing I have noticed with 5.x kernels on all rk3399 boards I own is that Bluetooth's firmware is correctly patched after cold boot / power on but not after a reboot.