Search the Community

The distributions for this SBC don't boot due to errors to thermal device. I saw some messages in the forum where has be told that disabling thermal check the distribution works. Can you blacklist or disable thermal sensors check?

How to compile DKMS on the board? I am trying this for the past week without success and starting to go crazy... The last kernel which worked is 6.11.2. I tried with zfs-dkms (from apt's repositories and from manually build .deb from zfs git) and with aic8800 drivers. I've tried Bookworm image, tried Noble. Tried -current and -edge kernels. Tried many kernel revisions. Tried to build kernels (image & headers) with compile.sh with docker, without docker. Updated my x86 Debian to Trixie. Compilers are same on the build host and on the board: longanpi-3h# dpkg -l | grep -i gcc ii gcc 4:13.2.0-7ubuntu1 arm64 GNU C compiler ii gcc-13 13.3.0-6ubuntu2~24.04 arm64 GNU C compiler ii gcc-13-aarch64-linux-gnu 13.3.0-6ubuntu2~24.04 arm64 GNU C compiler for the aarch64-linux-gnu architecture ii gcc-13-base:arm64 13.3.0-6ubuntu2~24.04 arm64 GCC, the GNU Compiler Collection (base package) ... root@4585c06e2f54:/armbian# dpkg -l | grep -i gcc ii gcc 4:13.2.0-7ubuntu1 amd64 GNU C compiler ii gcc-13 13.3.0-6ubuntu2~24.04 amd64 GNU C compiler ii gcc-13-aarch64-linux-gnu 13.3.0-6ubuntu2~24.04cross1 amd64 GNU C compiler for the aarch64-linux-gnu architecture ii gcc-13-aarch64-linux-gnu-base:amd64 13.3.0-6ubuntu2~24.04cross1 amd64 GCC, the GNU Compiler Collection (base package) ... Or even better: Is it possible somehow to build those drivers on the host PC? 16x x86 CPUs are much, much faster than 4x A53.

Kernel crash on freshly installed image for LonganPi 3H. Image downloaded from: https://www.armbian.com/longanpi-3h/ Ubuntu 24.04 Noble. Sometimes it will crash few seconds after boot, before logging or doing anything. Didn't install or do anything, just apt-get update and upgrade. logs: https://paste.next.armbian.com/ocofepenup [ 1511.118664] Internal error: Oops: 0000000096000044 [#1] SMP [ 1511.124251] Modules linked in: sunrpc rtl8xxxu mac80211 cfg80211 sunxi_cedrus(C) rfkill libarc4 v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videodev videobuf2_common polyval_ce sun50i_h6_prcm_ppu mc polyval_generic dump_reg cpufreq_dt zram zsmalloc binfmt_misc sch_fq_codel fuse dm_mod realtek sun6i_rtc_ccu dwmac_sun8i mdio_mux [ 1511.155156] CPU: 1 UID: 0 PID: 2658 Comm: sshd Tainted: G WC 6.12.23-current-sunxi64 #1 [ 1511.164459] Tainted: [W]=WARN, [C]=CRAP [ 1511.168292] Hardware name: Sipeed Longan Pi 3H (DT) [ 1511.173166] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1511.180124] pc : enqueue_timer+0x3c/0x150 [ 1511.184141] lr : __mod_timer+0x30c/0x370 [ 1511.188063] sp : ffff800085a13920 [ 1511.191376] x29: ffff800085a13920 x28: 00000000000005a8 x27: 0000000000000000 [ 1511.198514] x26: ffff8000821f6000 x25: 0000000000000001 x24: 0000000100049ec4 [ 1511.205652] x23: 000000000000000c x22: ffff0000ff760000 x21: 0000000100049ecc [ 1511.212789] x20: ffff0000ff760000 x19: 0000000100049ec4 x18: 0000000000000042 [ 1511.219926] x17: 85a0e7cbaf550a08 x16: 01010000d9864102 x15: 1880ada177e5cf73 [ 1511.227064] x14: 54c33ab316000103 x13: 6a5d85a0e7cbaf55 x12: 0a0801010000d986 [ 1511.234201] x11: 41021880ada177e5 x10: cf7354c33ab31600 x9 : ffff800080125244 [ 1511.241341] x8 : ffff800080b33870 x7 : ffff0000ff7600d0 x6 : ffff800082201980 [ 1511.248479] x5 : 000000000000000c x4 : 000000000000000c x3 : 0000000100049ecc [ 1511.255617] x2 : ffff0000ff760070 x1 : 0000000000000000 x0 : ffff0000ff760000 [ 1511.262756] Call trace: [ 1511.265204] enqueue_timer+0x3c/0x150 [ 1511.268868] __mod_timer+0x30c/0x370 [ 1511.272444] mod_timer+0x1c/0x30 [ 1511.275673] sk_reset_timer+0x28/0x98 [ 1511.279339] tcp_schedule_loss_probe.part.0+0x13c/0x270 [ 1511.284567] tcp_write_xmit+0x320/0x1390 [ 1511.288492] __tcp_push_pending_frames+0x44/0x108 [ 1511.293197] tcp_push+0xbc/0x168 [ 1511.296431] tcp_sendmsg_locked+0xa14/0xc38 [ 1511.300616] tcp_sendmsg+0x40/0x70 [ 1511.304021] inet6_sendmsg+0x4c/0x78 [ 1511.307599] __sock_sendmsg+0x64/0xc0 [ 1511.311265] sock_write_iter+0xa8/0x118 [ 1511.315102] vfs_write+0x334/0x3b8 [ 1511.318508] ksys_write+0xf8/0x120 [ 1511.321911] __arm64_sys_write+0x24/0x38 [ 1511.325835] invoke_syscall+0x50/0x120 [ 1511.329590] el0_svc_common.constprop.0+0x48/0xf0 [ 1511.334296] do_el0_svc+0x24/0x38 [ 1511.337615] el0_svc+0x30/0xd0 [ 1511.340675] el0t_64_sync_handler+0x120/0x130 [ 1511.345034] el0t_64_sync+0x190/0x198 [ 1511.348703] Code: a9025bf5 aa0003f6 aa0303f5 f8657841 (f9000261) [ 1511.354794] ---[ end trace 0000000000000000 ]--- [ 1511.359410] note: sshd[2658] exited with irqs disabled [ 1571.130516] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 1571.136471] rcu: 1-...0: (7 GPs behind) idle=ad6c/1/0x4000000000000000 softirq=10876/10876 fqs=6851 [ 1571.145603] rcu: (detected by 2, t=15004 jiffies, g=19153, q=1042 ncpus=4) [ 1571.152564] Sending NMI from CPU 2 to CPUs 1: [ 1581.152989] rcu: rcu_sched kthread starved for 555 jiffies! g19153 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=0 [ 1581.167420] rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior. [ 1581.176371] rcu: RCU grace-period kthread stack dump: [ 1581.181418] task:rcu_sched state:R running task stack:0 pid:17 tgid:17 ppid:2 flags:0x00000008 [ 1581.192290] Call trace: [ 1581.194738] __switch_to+0xe8/0x150 [ 1581.198235] 0x0 [ 1581.200080] rcu: Stack dump where RCU GP kthread last ran: [ 1581.205561] Sending NMI from CPU 2 to CPUs 0:

Hello fellow Sunxi forum members, Some may know me from previous Armbian adventures, primarily Orange Pi Zero 3... but I have jumped brands for a change of scenery (but not SoC). When researching H61X based boards for the Zero 2 and Zero 3 development we were doing in another thread, I found the Sipeed LonganPi 3H, which is a relatively new board that took a while to find. My first impressions are that is really well made, and packs a lot in to the Raspberry Pi Zero style profile (although it also has a daughter board). It was shipped quickly in a nice quality hard plastic storage case and.. best of all.. it has two hardware buttons.. so I can reset! (very useful when you are rebooting endlessly). You can find a review of the board here: https://www.cnx-software.com/2023/12/29/sipeed-longan-pi3h-a-raspberry-pi-zero-sized-board-with-gigabit-ethernet-wifi-6-hdmi-and-usb-ports/ There has been some great development on GitHub here (and the documentation on their site is also good) https://github.com/sipeed/LonganPi-3H-SDK https://wiki.sipeed.com/hardware/en/longan/h618/lpi3h/1_intro.html I basically started this thread as I thought I would look outside of the Orange Pi's I had and see if I could get the SDK build working in the Armbian framework. It should be noted that the SDK builds are standalone and use slightly dated uboot and kernel, but I was keen to at least get the builds working in Armbian so I can start iterating and improving. I want it to be very clearly known that I am just migrating the great work from the above Sipeed GitHub repo (their scripts work really cleanly), and will slowly work through issues that I identify as I go. Currently I have migrated all the patches over (named the same as the original repo) until a clean/bootable build is achieved and then I will look at cleaning up the patch structure (although, in all honesty I prefer the numeric patch ordering to what exists currently in the sunxi patching directories.. but that's another discussion). My preliminary porting work to the Armbian build framework can be found here and is configured to only support edge with a wip board configuration for the Longan Pi 3H. https://github.com/pixdrift/armbian_build/tree/longanpi_3h Status: - The Armbian build completely cleanly for both the uboot (held back) and mainline kernel builds for 6.7.2 kernel. - Of the patches from the SDK repository, roughly 10 don't currently apply (not as bad as it sounds) - I have made some minor updates to two patches, and added comments for all problematic/failing patches - Many of the patches are related to CPU Frequency scaling, and I expect these are failing because CPU frequency patches are already in Armbian (I will confirm in future) - The build currently boots a separate boot partition, and that boot partition is using MBR (not GPT) as I had issues with the boot loader locating the GPT partition (haven't looked closely at this) The good news is.. I have the board booting, with 6.7.2 and I get serial output for the boot. The bad news is, it immediately and abruptly decides that the GPU has hit a temperature threshold and shuts down the device (corrupting the FS in the process). On subsequent reboots, fsck is launched to repair the filesystem and GPU hits temperature threshold. On investigation, I don't believe the GPU is actually hot, it's just the configuration has an issue and it's likely reporting a very high temperature value. I will try and confirm this as it may be a patch not applied correctly for GPU? The following is the log from the serial output First boot: =========== U-Boot SPL 2024.01-rc2-armbian (Jan 24 2024 - 11:15:42 +0000) DRAM: 4096 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0 (debug):armbian NOTICE: BL31: Built : 10:42:19, Jan 24 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a083600, model: LonganPi 3H INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP305 on RSB ERROR: RSB: set run-time address: 0x10003 INFO: Could not init RSB: -65539 INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for erratum 855873 was applied INFO: BL31: cortex_a53: CPU workaround for erratum 1530924 was applied INFO: PSCI: Suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 INFO: Changed devicetree. U-Boot 2024.01-rc2-armbian (Jan 24 2024 - 11:15:42 +0000) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: LonganPi 3H DRAM: 4 GiB Core: 48 devices, 19 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0, mmc@4022000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Net: eth0: ethernet@5020000 Unknown command 'usb' - try 'help' Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 3259 bytes read in 1 ms (3.1 MiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 129 bytes read in 1 ms (126 KiB/s) 30310 bytes read in 5 ms (5.8 MiB/s) Working FDT set to 4fa00000 Failed to load '/dtb/allwinner/overlay/-fixup.scr' 18400262 bytes read in 762 ms (23 MiB/s) 23103496 bytes read in 957 ms (23 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41880000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18400198 Bytes = 17.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 48e73000, end 49fff3c6 ... OK Loading Device Tree to 0000000048e03000, end 0000000048e72fff ... OK Working FDT set to 48e03000 Starting kernel ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. [ 2.498172] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.506572] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.519090] reboot: Power down done. Second boot: ============ Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. [ 2.475525] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down Begin: Will now [ 2.484056] reboot: HARDWARE PROTECTION shutdown (Temperature too high) check root file system ... fsck from util-linux [ 2.495463] reboot: Power down 2.38.1 Next steps: I am currently running on coffee fumes.. but when I my cognition returns, I plan to work through the remaining patches I have flagged as problematic in series.armbian in my branch. Potentially from there I will reach out to the Sipeed developers if I can't find anything obvious that is causing the above temperature issues . If that fails, I will look to hack up the image to disable the thermal protection code that is shutting the board down so I can boot and get more information about this issue (but this obviously risks the board being damaged). Asking for assistance: If you have any idea what might be causing the temp issue (ie. where to look) drop a message. I am sure I will get to it eventually when I have time, but assistance on where to focus my attention (which module/configuration components) would be a great help. That being said, I haven't looked at any of the currently failing patches so may be a quick fix! If you have one of these boards (even if you aren't a developer) please sign up to the Armbian forums and let me know, it's always great to have other people available for testing