• Content Count

  • Joined

  • Last visited

About piter75

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. piter75

    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 ;-)
  2. Ok, found the cultprit in the patching of network driver. There is v20.02.7 version available in the download area that fixes it.
  3. piter75

    Orange pi 4

    Nice summary ;-) IMHO all versions tested by you boot in similar time - somewhere around 1:45 you get the prompt. They are all equipped with the patch that sets the CPU clock properly in u-boot - otherwise it would take at least 40-60 secs longer. Most of that time is taken to resize the filesystem on the SD card. In first two you can see that root fs is mounted ~6-7 seconds into the kernel boot. Subsequent boots should be faster but without RTC (I think there is no port for it) it will also take some time to fsck the rootfs because of "superblock write time in the future" check ;-)
  4. 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.
  5. piter75

    Orange pi 4

    Tried the latest buster desktop image from download area and it takes ~90 secs to boot (boot time will be shorter with the next release) but it works on my OrangePi 4B unit: root@orangepi4:~# uname -a Linux orangepi4 5.4.26-rockchip64 #20.02.5 SMP PREEMPT Thu Mar 19 21:39:46 CET 2020 aarch64 GNU/Linux I am more and more inclined to change the default to be 7 and let people lower it at will ;-)
  6. piter75

    Orange pi 4

    Can you provide the serial console output?
  7. piter75

    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:
  8. piter75

    Orange pi 4

    need more details here ! ;-) The image (buster_legacy 20.02.3) boot fine for me. Did you write it to the card that was previously used for Xunlong's BSP? If so you need to wipe the secondary GPT partition that is left over after BSP install. You can find the procedure here. With the existence of GPT Rockchip's loader tries to read trust according to non standard coordinates found in GPT
  9. piter75

    NanoPC T4

    What version of kernel did you upgrade to? To fix it without writing a new image you could probably simply boot with SD, mount eMMC and remove fdtfile entry from mounted "boot/armbianEnv.txt". It is probably pointing to a "rockchip/rk3399-nanopi4-rev00.dtb" file that is not part of modern kernel package anymore
  10. Shouldn't you actually be partitioning a /dev/nvme0n1 device as /dev/nvme0 is simply a controller? https://serverfault.com/questions/892134/why-is-there-both-character-device-and-block-device-for-nvme https://metebalci.com/blog/a-quick-tour-of-nvm-express-nvme/
  11. You can try building images from this branch: https://github.com/armbian/build/tree/orangepi-4-dts-cleanup-part1 or wait for it to be merged into master. Reboot issue is fixed - verified with current and legacy.
  12. 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
  13. 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.
  14. 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 ;-)
  15. @raidboy are you using SPI to boot? Can you provide the failed boot log from serial console?