initramfs Run /init

  • Hi,I used a different version of the kernel, but it got stuck when it finally started init, which is the init program for initramfs, and the console just said it couldn't operate.

    log:

    [ 1.973467] Freeing unused kernel memory: 3648K

    [ 1.985519] Run /init as init process

    ---------------------------------------------------------------------

    I added some printing information at the beginning of the init program of initramfs, the kernel did not print, so I think the kernel did not run to init, but the kernel did not report an error, I don't know where the problem is! Can you give me some hints?

  • Hardware? .. what LE image? .. what exactly did you change, and why are you building different versions of the kernel. Our crystal ball is not working this week. Add details please.

    Hi,I want to port TV to a new chip platform, which is not fully supported by the Linux mainline kernel, so I use the kernel provided by the chip manufacturer.

    log:

  • The <incomplete> log shows the SoC vendor is Rockchip so I moved the thread, but SoC model is <unknown> and kernel version is <unkown> which means our ability to guess the <unknown> problem is <unknown>. The lack of technical info from you is rather annoying but also rather irrelevant, because your <unknown> hardware probably needs a Rockchip Linux 4.4 vendor kernel? and our codebase is not compatible with Rockchip vendor kernels. It was in the past, but our display and video pipeline is now dependent on modern (upstream/mainline) Linux kernel APIs that legacy kernels do not support. You might be able to frankenstein an LE image to boot and even start Kodi, but there will be no video decoding in hardware which is essential for playback on an ARM SoC device. To get a more useful answer you will need to provide more useful info.

  • The <incomplete> log shows the SoC vendor is Rockchip so I moved the thread, but SoC model is <unknown> and kernel version is <unkown> which means our ability to guess the <unknown> problem is <unknown>. The lack of technical info from you is rather annoying but also rather irrelevant, because your <unknown> hardware probably needs a Rockchip Linux 4.4 vendor kernel? and our codebase is not compatible with Rockchip vendor kernels. It was in the past, but our display and video pipeline is now dependent on modern (upstream/mainline) Linux kernel APIs that legacy kernels do not support. You might be able to frankenstein an LE image to boot and even start Kodi, but there will be no video decoding in hardware which is essential for playback on an ARM SoC device. To get a more useful answer you will need to provide more useful info.

    Sorry, the chip is rk3568 and the kernel version is 4.19. If the problem is caused by the low kernel version, I have to wait for Rockchip to add the mainline kernel. I used kernel 5.10 to boot the tv system in rk3568. Although the system can be used, npu and hdmi cannot be used, so I changed the kernel.

  • Linux 4.19 is less-worse than 4.4 but the underlying issue is the same; userspace apps like Kodi and FFMpeg (and g-streamer, not that LE uses it) are evolved around V4L2 kernel APIs and code that simply does not support the vendor kernels. The good thing is - Rockchip has numerous corporate backers funding upstreaming development for chipsets like RK3568 so support is being actively worked on and is starting to land in mailing lists .. and as long as that work follows standards (which it is/does/will-continue-to-do) creating an LE image in the future should be fairly simple.

  • Linux 4.19 is less-worse than 4.4 but the underlying issue is the same; userspace apps like Kodi and FFMpeg (and g-streamer, not that LE uses it) are evolved around V4L2 kernel APIs and code that simply does not support the vendor kernels. The good thing is - Rockchip has numerous corporate backers funding upstreaming development for chipsets like RK3568 so support is being actively worked on and is starting to land in mailing lists .. and as long as that work follows standards (which it is/does/will-continue-to-do) creating an LE image in the future should be fairly simple.

    Yes, if the mainline kernel fully supports rk3568, then creating LE image is easy. Before I added rk3568 to the 5.10 kernel, and using the LE image created by it, I found a problem with the npu driver and drm, and everything else was fine. Maybe I should wait for rockchip, although the speed is a bit slow.

  • kongxin You will want to use kernel head and uboot head for the 3568 - there is development being done but on the “edge” - lkml and denx mailing lists have regular patches.

    I don’t quite understand what you mean. I don’t see what I want on the kernel patch list, such as npu, vop driver, etc. I have run TV system on rk3568 as early as two months ago, but npu and vop driver There is a problem, which prevents me from using hdmi and npu. So I replaced it with a 4.19 kernel with full support for rk3568. As you can see, the kernel freezes when the init program of the initramfs is booted. For this reason, I have used the initramfs of other chips, replaced the interpreted scripts, and compiled busybox statically. The problem remains. I have to change the kernel back and continue to wait for Rockchip to support rk3568.

  • You can set boot debug and alter init to review what is failing. E.g. https://github.com/heitbaum/Libre…1235eb9963fe106 but as chewitt points out unless the kernel you use has support for V4L2 Kodi may display, but any video decode won’t succeed. I have a number of similar issues as you are describing with some SoCs - rk3399pro, h616, rk3568, d1 (even Intel TGL) - all falling into the category of either too new or not yet fully mainlined - but I continue to test and upstream support for these.

  • You can set boot debug and alter init to review what is failing. E.g. https://github.com/heitbaum/Libre…1235eb9963fe106 but as chewitt points out unless the kernel you use has support for V4L2 Kodi may display, but any video decode won’t succeed. I have a number of similar issues as you are describing with some SoCs - rk3399pro, h616, rk3568, d1 (even Intel TGL) - all falling into the category of either too new or not yet fully mainlined - but I continue to test and upstream support for these.

    Thank you, your patch is very useful.

  • I don;t know what IP is used for NPU in RK chips but in general NPU drivers are often a challenge to upstream due to NDAs and restrictions on the SDKs from the IP owners.

  • As fyi the Radxa n10c rk3399pro has the npu connected via USB3 and the interface to the npu is https://github.com/rockchip-linux/rknn-toolkit the NPU is actually a discreet A35 cpu rk1808 https://wiki.radxa.com/RockpiN10/dev/NPU-booting - https://www.cnx-software.com/2018/09/24/roc…ils-rk1808-npu/ and there are a bunch of hacks in place to startup the npu using sysfs which don’t convert well into mainline. If you connect to the rk1808 uart on the n10c board, you can actually see the (blob npu kernel boot on the rk1808) I haven’t spent much time on the n10c or my P2 in recent times.