• Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

delius's Achievements

  1. Hi, Armbian gurus, The dump is now uploaded to And also, I found something unusual in sun50i-h6-pine-h64-model-b.dts: hdmi-sound { compatible = "simple-audio-card"; simple-audio-card,format = "i2s"; simple-audio-card,name = "sun50i-h6-hdmi"; simple-audio-card,mclk-fs = <0x80>; simple-audio-card,frame-inversion; status = "disabled"; phandle = <0x53>; simple-audio-card,codec { sound-dai = <0x08>; }; simple-audio-card,cpu { sound-dai = <0x09>; dai-tdm-slot-num = <0x02>; dai-tdm-slot-width = <0x20>; }; }; Although I am not familiar with dts, I changed the status = "disabled" to "okay" to compile dtb again to replace the one in /boot/dtb/allwinner/ ... But unfortunately, it didn't work neither. Do you have any more idea?
  2. 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.
  3. Oh yeah, What a miss, my apology. Here is the link to the dump of #armbianmonitor -u armbianmonitor dump on PineH64 with latest current Armbian desktop Thank you.
  4. Hi, Armbian gurus. I tried latest Armbian image for PineH64-b. (Armbian_20.11_Pineh64-b_focal_current_5.8.16_desktop) And I surprisingly found there is no audio device when I looked around.( by #aplay -l ) Is this expected for now? My older 5.6 kernel has HDMI device at least. I tried search audio problem around but had no discover so far. Please allow me to confirm with you. I'm looking for a good 5.8 multimedia-capable kernel to merge with my gentoo rootfs. Thank you.
  5. 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 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 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
  6. 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.
  7. 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.
  8. 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/ Fire up 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.
  9. 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.
  10. 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?
  11. 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.
  12. 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.
  13. 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.
  14. 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/ to make KERNEL_SOURCE = my previous repo; KERNELBRACH = master. To make it fetchable during bilding. 3. Modify lib/ skip aufs patch. 4. Modify lib/ skip advanced_patch in compile_kernel() After all these hassle, I can use 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.
  15. 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.