piter75

Hmm... is it only mine unit that works well with legacy kernel image and latest u-boot? If you want you can try latest `current` image with 5.4.0 kernel: https://drive.google.com/open?id=1R26QdAaoNJDDmvNvKNUZWT53OZsJnVkj xz -dcv Armbian_19.11.3_Nanopim4v2_buster_current_5.4.0_minimal.img.xz | sudo dd bs=1M of=/dev/sdb You can use above command line to skip explicit decompression step. EDIT: Ok. I just saw your latest message.

What we have right now is, probably, exactly what you wanted to achieve: Option 2 for building Option 3 for packaging This boils down to having all bootloader components built from source code as opposed to having to load binary blob from vendor in the process. I am not an expert on ATF but I understand it as a firmware running in a secure zone of the processor with a set of interfaces (eg. PSCI for power control) that let it interact with the rest of the software. Not using ATF would mean that one had to code those interfaces themselves.

The kudos belong to Levin Du of T-Firefly team who did the heavy lifting. I merely paved the path with my u-boot PR and helped make the reboot work in mainline ATF for rk3399. Oh and BTW... this is the first rk3399 board in Armbian which boots with full and fresh OSS combo: mainline u-boot's TPL/SPL + mainline ATF.

Doesn't. You probably had a display connected? I will test that scenario. This seems more like an electrical problem but as you said before... it works well in "dev". I am puzzled

That's odd. Especially that the same dongle works for you in dev kernel. If only I could replicate the issue with my CP2104. I will try to use one of the other dongles I have and see. Out of curiosity.. What dongle is that? Do you use TX,RX and GND wires? I guess that it was working well for you with NanoPi M4 default image patched by you with RockPi 4's u-boot? Not that it will change anything for your issue but I will rebase my branch onto master now before further experiments. It would be great if anyone else beside us would try to make a default's branch build from this branch (nanopi-m4v2-u-boot-v2019.10-ddr-miniloader) or dared to use the binary image here: https://drive.google.com/open?id=1xAh4i7cw9KgVo4ZGWm5F58nMXfIB5li4

Here is the one I compiled few minutes ago. https://drive.google.com/open?id=1xAh4i7cw9KgVo4ZGWm5F58nMXfIB5li4 For this build I removed my custom config from "userpatches/config-default.conf" and copied there one from the "config/templates/config-example.conf" directory so it is pristine. Here are its contents: Can you post contents of yours "userpatches/config-default.conf" file too? The differences of loaded file sizes are strange indeed: 142 vs. 244 - that's "/boot/armbianEnv.txt" - we should have exactly the same file here out of the box but maybe you were referring to a build before my latest changes with extra logging 6514583 vs. 7556947 - that's "uInitrd-4.4.192-rk3399" - 1M difference in init ram disk - this I cannot explain, yet Can you share the "/boot/initrd.img-4.4.192-rk3399" file from your install?

There is one thing that comes to my mind... I have some features disabled in my config-minimal.conf. I have AUFS disabled for sure, which is irrelevant. Will let you know about the rest later. Dev kernel should have a sound card working by now 😉

@pask I have just booted default images (using SD), both minimal: http://ix.io/22yt and desktop: http://ix.io/22zD. I have enabled verbose boot logging in the branch so maybe we can see where it hangs for you.

I briefly tested it in one of the iterations and I remember it working but I could definitely break it on the way. I will check it out and sound card as well. That's what came to my mind too and I was going to explore that too. Thanks for feedback. Great to hear that it worked What $BRANCH did you use - dev / default? Was it desktop, default or minimal build? Oh.. and what boot medium did you use SD/eMMC?

Sorry @pask That's what happens when a prototype leaves factory without proper testing ;p It is fixed now in the branch so please pull. As a side note I followed your comment about possibility of SD controller problems and I find it possible. Until yesterday I was always testing with SD for the convenience and simplicity of it but yesterday I burned eMMC finally and I must admit that I had no errors in mainline on bootup in that setup. Default/legacy build was stable even with the SD card for me. This needs further testing of course...

@pask, @NicoD, @pkfox, @TCB13 Would you find some time for building and running the Armbian image from my branch: https://github.com/armbian/build/tree/nanopi-m4v2-u-boot-v2019.10-ddr-miniloader The build: is based on latest: u-boot and ddr/miniloader/bl31 from Rockchip (could not get mine to run reliably with u-boot's TPL/SPL combo) has lowered min frequency to 408MHz contains wi-fi firmware provided by @martinayotte in this thread For my tests I mainly build minimal `dev` target: ./compile.sh minimal BOARD=nanopim4v2 BRANCH=dev RELEASE=buster It would be grate if you could find some time to test it

Well, I remember sometimes seeing strange errors related to u-boot script loading in the logs when you were testing my `blind` builds. For which I thank you again @pask I continue to run stable with the combination of latest ddr/miniloader/bl31 combo from Rockchip and min frequency lowered to 408MHz but I use only console so our crashes may not be related. For building u-boot I mostly exploit Armbian build system running in Vagrant. After this PR: https://github.com/armbian/build/pull/1616 which I merged into my branch it became really easy to tinker with u-boot, build u-boot alone and dd the bootloader parts to SD. When it comes to docs I think these places come to my mind as a starter: http://opensource.rock-chips.com/wiki_Boot_option#U-Boot https://github.com/u-boot/u-boot/blob/master/doc/README.rockchip https://github.com/armbian/build/blob/d184b0393038be2bf29d78fd9cf469e7a26b5f0c/config/sources/families/rk3399.conf#L23 https://github.com/armbian/build/blob/master/config/sources/families/include/rockchip64_common.inc#L63

Ok, the causes of the crashes could be different for us as I use it solely in the terminal Anyway, I did something which I cannot imagine could help but... it seems that it helped. I remember reading somewhere lately about instability of PX30 at 408MHz that was avoided by changing min frequency to 600MHz. Our images for RK3399 have default min of 600MHz so I did the opposite and changed the min to 408MHz. I will definitely observe it for a longer time but last 40-50 reboots were clean of errors while before it happened every 3-5 reboot.

I don't want to make another thread about M4V2 images, at least yet, so I will squeeze in here ;-) @pask, @NicoD, @pkfox all of you are using NanoPi M4 image patched with Rock Pi 4 u-boot that @pask prepared. Is it stable for you? On my M4V2, both retrofitted M4 image and my own builds specifically for M4V2, I observe Kernel errors from time to time - especially during boot-up. I started wondering whether my device may be faulty...

I started working on the build config for M4V2 but it will certainly not happen before the PR, that @Igor referred to, is merged into master. I have a device finally so I should soon have a branch that I would like M4V2 owners to build locally and test.

IMHO It could never work with mainline kernel. At first it was named "RockPi-4B" in Armbian's custom device tree and then it was renamed to "Radxa ROCK Pi 4" following Rock Pi 4's device tree upstreaming somewhere around July. At this point you could: use "default" image which should work fine with "libmraa" make yourself and overlay with a model change to survive kernel updates try adjusting "libmraa" to make it work with mainline kernel (and upstreaming the change) - probably by the means of verifying that "compatible" contains "radxa,rockpi4" 3rd option would be best in the long run IMO.

You were probably building rockpi-4b target then as rockpi-4a could never work until moments ago ;-) rockpi-4a is also not part of automatic build process now/yet and is no different than -4b anyway. Pull latest master and it should build without issues for both Rock Pi 4 targets: [ o.k. ] Writing U-boot bootloader [ /dev/loop0 ] [ .... ] Fingerprinting [ o.k. ] Done building [ /home/vagrant/armbian/output/images/Armbian_5.99_Rockpi-4a_Debian_buster_dev_5.3.0-rc4_minimal.img ] [ o.k. ] Runtime [ 10 min ] [ o.k. ] Repeat Build Options [ ./compile.sh BOARD=rockpi-4a BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ]

I have checked the latest default buster images (desktop and no desktop - 20191009) and both of them boot fine: ____ _ ____ _ _ _ ____ | _ \ ___ ___| | _| _ \(_) | || | | __ ) | |_) / _ \ / __| |/ / |_) | |_____| || |_| _ \ | _ < (_) | (__| <| __/| |_____|__ _| |_) | |_| \_\___/ \___|_|\_\_| |_| |_| |____/ Welcome to Debian Buster with Armbian Linux 4.4.192-rockchip64 System load: 0.61 0.29 0.11 Up time: 1 min Memory usage: 2 % of 3876MB IP: CPU temp: 28°C Usage of /: 3% of 58G root@rockpi:~# uname -a Linux rockpi 4.4.192-rockchip64 #1 SMP Tue Oct 8 18:39:24 CEST 2019 aarch64 GNU/Linux

I have been happily booting Rock Pi 4B v1.4 since August with both eMMC and SD. As others already pointed it would be good if you had some console logs. At this point I am running custom Armbian build based on latest u-boot and open source ATF but will burn SD with latest "official" image, check if it boots and will get back with the results.

Setting the "performance index / capacity" in device tree is IMO a good thing per se - it instructs the kernel's scheduler which cores are more performant and which could / should process more tasks. The issue here is that on boot big cores' clock is not initialised properly, they perform actually much worse than LiTTLE cores and kernel is scheduling more tasks to them as it expects them to be faster. Before 5.2 the cpus were treated as equal so although not as short as 4.4 the boot times were not annoying. The change just emphasised the issue IMHO. Manjaro's patch reverted the performance segregation of the cores to bring back pre 5.2 behaviour. Ezequiel's patch OTOH tries to initialise cpufreq driver as soon as possible during the boot to make the cores' performance closer to the kernel's assumption of it - at least that's how I understand it.

IMHO, as @drice suggested it has to do with the big CPUs starting at low frequency: cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 408000 KHz It was emphasised by this commit: https://github.com/torvalds/linux/commit/97df3aa76b4a384e29668f374a8b1034a31aa215 which makes a preference to use to use big cores instead of LiTTLE ones. There are some patches to make it work better: https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-aarch64-rc/commit/129dd4053ddca867b0255bd7e4cff109b66bf61a https://gitlab.collabora.com/rockpi/linux/commit/e55cd521ed67943cc3edcd8b78884ad53741da8c I have used the latter in my local build on Rock Pi 4 and it works well - boot times in 5.3-rc4 are reduced. I did not make a PR for it as it is a hack really but I sure can to make the booting experience smoother. This should be fixed in 5.2 and reapplied for 5.3-rc4 with the following patch: https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-dev/RK808-use-syscore-for-poweroff.patch It works on Rock Pi 4 and in principle should on all other RK3399 / RK808 based boards, including NanoPC T4.

One more question. What revision are your boards?

@gufmar do you possibly also have an eMMC module? If so did you have luck using it reliably with model A? As strange as it may sound eMMC in model B is working reliably but in A it is only detected once in N boots with 5.2 kernel. On the other hand with kernel 4.4 it is initialised correctly all of the times also in model A.