piter75

Members
  • Content Count

    34
  • Joined

  • Last visited

About piter75

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. That's true but you can also run the following commands. This will "upgrade" to the latest "current" kernel from Armbian release 19.11.3, which is 5.3.11. That's why I said you can downgrade via upgrading... ;-) sudo apt dist-upgrade sudo reboot
  2. The headers package is not bundled in Armbian image and when you install it you are actually installing the last "stable" version of them in "current" target - which right now is 5.3.11 NanoPi M4V2 image was never built with 5.3.11 kernel and that's why the installed header do not match the kernel. One thing you could try as a "creative workaround" would be to upgrade kernel which will actually downgrade it to 5.3.11 and then the kernel and headers packages should match. I just did it on a freshly downloaded image for NanoPi M4V2 with kernel 5.4.2 from Armbian downloads and it worked fine, however YMMV ;-) You better test it first on a spare SD card if you already did a lot of tuning to the current install. EDIT: I assumed you downloaded my image linked a few posts back. If you did build your own image you can transfer a headers package from "output/debs" folder to you machine and install it there without the need for downgrading kernel.
  3. Nice to see we are on the same page here 😉. My plan was to move out all rk3399 to their own family and then trying to merge back.
  4. Rock Pi 4 works well with u-boot v2019.10 even with mainline ATF I fixed the nand-sata-install issue in master. There are still a few things I have to learn about Armbian ;-) OTOH this bug should not affect Rock Pi 4, unless you moved it to rk3399 family while testing.
  5. @martinayotte nand-sata-install bug may be actually my fault introduced during u-boot migration. I will look into that. That is what I want to pursue next - starting with Rock Pi 4 first.
  6. @Hover did you change the sound-dai to point to i2s0 in the following line? https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch#L22 T4's codec is connected to a different i2s bus than M4* You will have to enable i2s0 similar to what I did for i2s1 here: https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch#L64 I think you could probably replace i2s1 -> i2s0 in this node.
  7. Sure, I was thinking about it. Feeling motivated by your message I will do that tonight
  8. @Hover I did not test bluetooth much as I find it non essential for the first rollout ;-) As for the sound you can test this patch: https://github.com/armbian/build/blob/80b757ac27f58085f8c36302a4cd45ab3caa7ae4/patch/kernel/rockchip64-current/board-nanopi-m4v2-dts-add-sound-card.patch accompanied by: CONFIG_SND_SOC_ROCKCHIP_RT5651=y CONFIG_SND_SOC_RT5651=y in the kernel config file.
  9. A lot of credit goes also to you Once again thanks for testing the images since the beginning. As for the slow boot it plaques now all rk3399 boards. I am tempted to bring the following hack to Armbian: https://gitlab.collabora.com/rockpi/linux/commit/ea2fb5589b4cd92728a6139ee5043945d3e10173 I am using it for weeks now in my builds and don't regret it ;-)
  10. I rebased my branch onto latest master changes. Took me some time to make the sound working in kernel 5.4. Branch is now named nanopi-m4v2-bring-up and supports "legacy", "current" and "dev" targets. Did not test "legacy" much yet but "current" 5.4 works quite well. In dev wi-fi is broken, but anyway "current" is much more compelling as it is 5.4 vs. 5.4-rc1 in dev. Command line for "current": ./compile.sh BOARD=nanopim4v2 BRANCH=current RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no
  11. 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.
  12. 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.
  13. 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.
  14. 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