pixdrift Posted January 26 Share Posted January 26 (edited) 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 Edited January 27 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 26 Share Posted January 26 It would probably be easier to just add the dts and start adjusting the same rather than adding all those vendor patches first. We already know that except audio, dma and iommu everything else is there for H618. Regarding AIC8800 patches, put them in patch/misc directory and add a section for them in lib/functions/compilation/patch/drivers_network.sh 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 27 Author Share Posted January 27 (edited) Sure, I guess that's down to approach. I have ruled out most of the patches, but wanted to determine if anything else had been added from upstream or that differed from what was there for H61x. Interestingly, the CPU Frequency scaling patch from Sipeed (not sure of full origin) includes more scaling steps in the CPU configuration, not sure if there is worth implementing in H61x as it will impact other boards, but it looks like an improvement over what is there. I went looking for the temperate configuration, not sure if it's related but their kernel configuration has +# CONFIG_THERMAL is not set Couldn't find anything specific to temperature/thermal in their patches, not sure how it's implemented, I thought the temperate output would be coming straight off the SoC? in which case, we would expect it to be implemented and working correctly (even without patches applied), is that correct? Not sure how the temp sensing is implemented in hardware. I plan to clean up (and merge together) many of the patches once the board is booting correctly. Edited January 27 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 27 Author Share Posted January 27 (edited) After booting the vendor image LPI3H_20240110_SD.img from their wiki (https://wiki.sipeed.com/hardware/en/longan/h618/lpi3h/1_intro.html) for comparison, I confirmed they appear to have THERMAL off, likely as it's not currently supported (I will ask them). After installing lm-sensors, there were no results and sensors-detect also failed to find anything root@lpi3h-5396:/# uname -a Linux lpi3h-5396 6.7.0-rc3+ #1 SMP PREEMPT Wed Dec 20 10:17:59 UTC 2023 aarch64 GNU/Linux root@lpi3h-5396:/# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. When looking at potentially turning this configuration off in u-boot, I found the kernel config file placed into the FAT partition (for u-boot) suggests Armbian built the configuration with CONFIG_THERMAL=y. # ls -l total 62480 -rwxr-xr-x 1 root root 179 Jan 27 16:46 armbianEnv.txt -rwxr-xr-x 1 root root 1536 Jan 26 20:34 armbian_first_run.txt.template -rwxr-xr-x 1 root root 230454 Jan 26 20:34 boot.bmp -rwxr-xr-x 1 root root 3187 Jan 27 16:31 boot.cmd -rwxr-xr-x 1 root root 3259 Jan 26 20:35 boot.scr -rwxr-xr-x 1 root root 216337 Jan 26 20:33 config-6.7.2-edge-sunxi64 drwxr-xr-x 3 root root 4096 Jan 26 20:34 dtb -rwxr-xr-x 1 root root 23103496 Jan 26 20:33 Image -rwxr-xr-x 1 root root 18400198 Jan 26 20:35 initrd.img-6.7.2-edge-sunxi64 -rwxr-xr-x 1 root root 3594747 Jan 26 20:33 System.map-6.7.2-edge-sunxi64 -rwxr-xr-x 1 root root 18400262 Jan 26 20:36 uInitrd # grep ^CONFIG_THERMAL= config-6.7.2-edge-sunxi64 CONFIG_THERMAL=y Am I right in my thinking that Armbian is using a generic sunxi64 kernel config for the kernel build because the board is in the sunxi64 family? or have I misinterpreted this? This isn't specified in the kernel defconfig I have brought in for the board. I will take a closer look at the build log, just keeping a running log here in case others find the information useful for their own troubleshooting. Edited January 27 by pixdrift 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 27 Share Posted January 27 4 hours ago, pixdrift said: generic sunxi64 kernel config for the u-boot build Sorry, I am not sure what you meant by that. As far as kernel config is concerned, all 32-bit allwinner boards uses config/kernel/linux-sunxi-* and all 64-bit allwinner boards uses config/kernel/linux-sunxi64-*. If required, you can change the kernel config using ./compile.sh BOARD=<board> BRANCH=<branch> kernel-config command. All boards uses their own uboot defconfig files to generate u-boot config. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 27 Author Share Posted January 27 32 minutes ago, Gunjan Gupta said: Sorry, I am not sure what you meant by that. As far as kernel config is concerned, all 32-bit allwinner boards uses config/kernel/linux-sunxi-* and all 64-bit allwinner boards uses config/kernel/linux-sunxi64-*. If required, you can change the kernel config using ./compile.sh BOARD=<board> BRANCH=<branch> kernel-config command. All boards uses their own uboot defconfig files to generate u-boot config. Thanks for your response. As always @Gunjan Gupta you are right, I was meant to say kernel not u-boot. I will rebuild now with thermal off and see how I go. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 27 Author Share Posted January 27 I have it booting and working now by turning off thermal support in kernel (also needed to disable a sun4i multifunction driver that expected the thermal configuration to be there). Board boots, network works.. and doesn't appear to get too hot. I must admit, I am a little surprised because I was under the impression that the thermals for CPU/GPU came directly off the SoC, and as the SoC is the same as the Orange Pi Zero 3 (and other boards if it's common for H616), I was expecting it to work. I will go back to the vendor regarding patching for temperature. In the meantime, what's the best way to have this board specific kernel configuration added to Armbian (ie. the config differs from the base sunxi64 kernel config) until the thermal issue is resolved? Are there any methods for adding it to the board configuration that would be merged if I raised a PR in future for the board? Thanks! 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 27 Share Posted January 27 1 minute ago, pixdrift said: what's the best way to have this board specific kernel configuration added to Armbian One possible option can be to convert the configs that are creating problems to be built as modules and then blacklist the modules using MODULES_BLACKLIST in board config. 1 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 27 Author Share Posted January 27 1 minute ago, Gunjan Gupta said: One possible option can be to convert the configs that are creating problems to be built as modules and then blacklist the modules using MODULES_BLACKLIST in board config. This is a great suggestion, and a very clean way to implement. If switching to module in the sunx64 kernel config, will the other dependent boards will need changes to support loading the module, or it's safe to assume the will load automatically? 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 27 Share Posted January 27 Just now, pixdrift said: If switching to module in the sunx64 kernel config, will the other dependent boards will need changes to support loading the module, or it's safe to assume the will load automatically? Theoretically modules should get loaded automatically based on the compatible string in the dts. But we can always check if that is not the case and add MODULES to board config to force loading them. Another option can also be to add status=disabled for the dts node in LonganPi's dts to disable the dts node belonging to the kernel module to prevent the module from coming into action. 1 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 30 Author Share Posted January 30 I have raised the thermal config issue with the Sipeed developers here: https://github.com/sipeed/LonganPi-3H-SDK/issues/16 Not keen on having to manage this in Armbian, so will wait to see if they come up with a patch to resolve the temperate reporting. I haven't looked at any of the thermal code myself yet. 0 Quote Link to comment Share on other sites More sharing options...
Володимир Дідик Posted February 5 Share Posted February 5 “Golang SHA256 Benchmark CPU Test” https://github.com/foxjony/sha256-benchmark Can you test the speed of this processor with this algorithm? 0 Quote Link to comment Share on other sites More sharing options...
rymut Posted April 2 Share Posted April 2 I got mine Longan Pi 3H two weeks ago, I started tinkering before finding out this post. Source code here: https://github.com/rymut/armbian-build_mangopi-mq-quad_longan-pi-3h/tree/development @pixdrift I don't have any issue with temperature - yes board runs a bit hot 50~55 degrees (with no workload with simple flat metal heat used as a heat sink), but no shutdown so far in 48 hours uptime. I skipped applying 0006-arm64-dts-allwinner-h616-Add-CPU-Operating-Performan.patch and use armbian default cpu opp table for h616. Any way my repository is still work in progress - I definitely need to add overlay containing wifi firmware and not copy it after first boot. 0 Quote Link to comment Share on other sites More sharing options...
lalaki Posted April 12 Share Posted April 12 (edited) I have a h618 board(orangepizero3) with the same problem. Use the following solution, the device tree nodes may be a little different. Edit boot.cmd: nano /boot/boot.cmd Disabling dts nodes with fdt: # After adding to fdt resize …… fdt set "/thermal-zones/gpu-thermal" "status" "disabled" fdt set "/thermal-zones/cpu-thermal" "status" "disabled" fdt set "/thermal-zones/ddr-thermal" "status" "disabled" fdt set "/thermal-zones/ve-thermal" "status" "disabled" Re-generate boot.scr: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Try boot. Edited April 12 by lalaki 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.