delius

Hi, Armbian gurus. I have make a new kernel and related modules for my pineh64 and want to test it. Thus they are not from dpkg. To test this kernel and modules. I have few questions: 1. About the symbolic links in /boot, are they all mandatory? What if I don't have an initramfs? 2. The Image linked file, is it have to be limited to certain compressed format to work properly? 3. Is there a recommended work flow to test a external kernel? Or I can just test by replacing Image, dtb, and the modules? Thank you.

Hi, NicoD I actually enjoy your video @ youtube a lot. Thank you first. According my current 5.6 kernel: Yes, the GPU clockrate is required to imposed. Or it will get really unstable if you enable panfrost. If you have a newer kernel, you might try it without setting clockrate first. If thing went bad for you, just remember to try this. I use the kernel ripped from libreELEC at https://gitlab.com/FuyuriSeiji/linux-5.6-le I made changes into build system config to use this kernel For the root, I use Gentoo's and emerge mesa with VIDEO_CARDS="panfrost." And the patched of ffmpeg at https://gitlab.com/FuyuriSeiji/ffmpeg These enable my setup to have hardware decoding with DRMPRIME kodi. If you have ever bumped any problem, you might consider what I list here as alternative approach. Good luck

Hi, Armbian gurus. I just try the latest kernel & modules(including /boot, /lib/modules/5.8.7-sunxi64 ) ripped out and put into my working panfrost(mostly)/DRM-Plane ready image. Anything graphical including X window and Kodi become unbearably slow somehow. I'm reading over the kernel configuration, but allow me to ask this at the same time: Besides the kernel and module configuration, is there other factor might cause this? Should I use the earlier DTB/DTS from my previous working version? Any chance to conflict with 5.8 kernel or other side effect? Thank you.

Hi, Sorry that being kind of late for this party. I need to make a Pine H64 ready to X window. I try to read over this thread carefully, but it's a bit too diversive. I met very same problem as NicoD in the thread start. Here are few questions. I wish someone who has clearer idea wouldn't mind lending me a hand. 1. Is current 5.6 kernel ready now? Or it take more patches? 2. Or are there DTS/DTB specially needed not merged required? 3. Which branch of armbian is recommended now? dev or current? Thank you.

Hi, Armbian gurus, I'm replying to end multiple weeks of how did I manage to successfully replace default armbian kernel with LibreELEC one. Upload patched kernel tree to an git repo. Modify armbian build system config to redirect KERNELSOURCE to your repo. For example: I modified config/sources/families/include/sunxi64_common.inc Fire up compile.sh as usual, but selecting "Show a kernel configuration menu before compilation." When kernel menuconfig show up, load your modified kernel config Now you might need optionally disable some patches if the building went wrong. Check your build/userpatches/kernel/<family>/ After these, I can produce Armbian image with patched LibreELEC kernel. I hope it might help someone and also close this this discussion. Thank you.

Hi,JMCC, That's amazingly fast reply. But there is kernel panic or something and kernel dump here on my rock64. (ROCK64_V2.0) Can anyone reproduce this? I'm afraid that I have a faulty device. Thank you, anyway.

Hey, Does anyone try this recently? On Armbian 20.02? It will make system crash during boot after the script is complete. No matter it's Arm SOC or Glamour selected. And I have hard time collecting useful log. Any idea?

Hi, Armbian gurus, I discover that the boot.cmd contains many statements about this FDT, including "fdt addr ${fdt_addr_r}" and "fdt resize 65536." May I ask about what is the proper size for these value? How to calculate these value? With DTB/DTS replacement happened along the replaced kernel tree, could that trigger this problem? I have to confess that I have very limited knowledge about u-boot, please drop me some tip or recommended reading if you think it's going to help, while I'm doing my own reading document from u-boot at the same time. Thank you.

Hi, Armbian gurus, These are the 2 copies of log I captured by USB-TTL. Armbian + LibreELEC 5.5.6 kernel Normal Bootable Armbian The most critical difference I guess is this: ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 116 bytes read in 2 ms (56.6 KiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! 9791617 bytes read in 983 ms (9.5 MiB/s) 15812616 bytes read in 1585 ms (9.5 MiB/s) May someone share more insight about what could be wrong with this header checking stuff? For example: which part of building might trigger this misbehavior? Thank you.

Hi, Werner Thank you for the tip. You are certainly appreciated. I will try to find whatever went wrong. If anyone discover something wrong with those steps, please do not hesitate to share here. Thank you.

Hi, Armbian gurus, I'm trying to make the build system to build image with LibreELEC kernel tree for PineH64 I heard the kernel is patched for being better at hardware decoding Here are what I have done in order: 1. Retrieve patched kernel tree from LibreELEC build system. Upload the patched kernel tree to my gitlab account. 2. Modify config/sources/families/include/sunxi64_common.inc to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding. 3. Modify lib/compilation-prepare.sh: skip aufs patch. 4. Modify lib/compilation.sh: skip advanced_patch in compile_kernel() After all these hassle, I can use compile.sh to build an Armbian 64 bit image with the 5.5.6 patched. BUT unfortunately, I flash the image and found it cannot boot properly. So here are my question: 1. How do you typically debug boot problem for PineH64. 2. Do you think anything could go wrong in those procedure? 3. Do I need to upgrade u-boot as well? It's using v2019.10 as far as I can tell. Thank you.

Hi, Werner Thank you for replying first. But I'm afraid that your suggestion won't work for me. Because I didn't use the kernel built in Armbian build system. Or may you tell me how to make Armbian build the alternative patched kernel tree for me? I look into configs/ and found the content like 'KERNEL_TARGET="current,dev"' May I modify it like pointing a alternative directory instead? Thank you.

Hello, Armbian devs, I have customized a kernel for an existing Armbian system. I wish I can replace the kernel on the system directly without going throught Armbian build system. According to what Martinayotte told me, there are 3 symbolic link to kernel image, dtbs, and uInitrd actually to boot. While I have done first 2, and I know that I have to do "mkimage" to generate a u-boot compatible uinitrd for sure. But... How can I produce the original initramfs, first? I trace the log of Armbian build system and found out it's generated by update-iniramfs command. But the environment is wiped out after it's done. I'm not sure how to reproduce the initramfs for my customized kernel. May anyone tell me what is the proper way to generate initrdfs for a customized kernel for PineH64-b board? Thank you. (edit: specify model)

Hi, Martinayotte, Thank you for helping me clear things out. I will see what I can do with this kernel. Consider this topic closed.

Sir, I appreciate your reply. Does that deb file include a proper boot configuration to boot the kernel within? And what if I built a kernel individually out of Armbian building environment, how can I make it work with existing Armbian system? Thank you.