Ryzer Posted June 19, 2023 Share Posted June 19, 2023 Initially I attempted upgrading the kernel from 6.1.26 to 6.1.33 using the build scripts to generate the newer kernel and headers. After rebooting I found that the system just appeared to hang around starting kernel. I did wait 10 minutes at first, thinking that perhaps their maybe some stuff going on in the background but after that conclude that it had most certainly crashed. The frustrating thing being that I did not appear to get any errors come through the debug port. At this point I assumed that perhaps something may have broke during the upgrade. My second attempt was using a completely fresh compiled image but unfortunately the result was still the same. U-Boot SPL 2022.10-armbian (Jun 15 2023 - 13:35:35 +0000) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2022.10-armbian (Jun 15 2023 - 13:35:35 +0000) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: LinkSprite pcDuino3 DRAM: 1 GiB Core: 52 devices, 23 uclasses, devicetree: separate WDT: Not starting watchdog@1c20c90 MMC: mmc@1c0f000: 0 Loading Environment from FAT... Unable to use mmc 0:1... Unknown monitor Unknown monitor In: serial Out: serial Err: serial Net: eth_designware ethernet@1c50000: Can't get reset: -2 eth0: ethernet@1c50000 230454 bytes read in 12 ms (18.3 MiB/s) Unknown monitor starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 2 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 4121 bytes read in 2 ms (2 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 154 bytes read in 2 ms (75.2 KiB/s) 16660327 bytes read in 690 ms (23 MiB/s) 8480576 bytes read in 355 ms (22.8 MiB/s) Found mainline kernel configuration 42775 bytes read in 9 ms (4.5 MiB/s) 5532 bytes read in 5 ms (1.1 MiB/s) Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x816740 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 16660263 Bytes = 15.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 4901c000, end 49fff727 ... OK Loading Device Tree to 48fa9000, end 4901bfff ... OK DE is present but not probed Starting kernel ... I will gratefully for any possible insight Cheers Ryzer 0 Quote Link to comment Share on other sites More sharing options...
Ryzer Posted July 11, 2023 Author Share Posted July 11, 2023 Image built with 6.1.34 works although encounter the same issues as under 6.1.26. There is a constant system load greater than 2.0 which under the prior 5.15.xx kernel this would normal settle down 5 minutes after boot. From what I could find it looks like one contributor was the r8188eu driver, which is in the staging directory but appears that it has been removed and support incorporated into the rtl8xxxu driver in the very latest kernel release. The second I discovered is the GPADC driver, this has given me grief in the past as I found that trying to use more than one of the 'adc' pins at a time seemed to cause the soc temperature reading to become very erratic. Anyway after finding the post below I found that disabling mode seemed to bring the system load to more reason levels, floating round the 0.20 - 0.30 mark. This seems like a better option rather than disabling the ability to read the CPU temperature outright, even if the output is supposedly based on average of 3 internal readings. Cheers Ryzer 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.