Jump to content

Custom built image doesn't start

kriptonus

By kriptonus
in Allwinner sunxi

 Share

Recommended Posts

kriptonus

kriptonus

Posted
Posted

Hi there!

 

I've just compiled from armbian buil tools a new image for Orange Pi 3 LTS. Then flash it on sdcard, anything was well, but armbian doesn't start at all. Nothing on the HDMI, nothing on the debug serial. Also LED doesn't light. I've tried two images: ubuntu jammy with GNOME and next case XFCE. Both cases didn't work. I've downloaded prebuilt image from armbian.org and it starts well. In my opinion, some problem with custom images in u-boot. but I don't know how to give a diagnosis.

0
Link to comment
Share on other sites
going

going

Posted
Posted
30.07.2023 в 20:37, kriptonus сказал:

I've just compiled from armbian buil tools a new image for Orange Pi 3 LTS. Then flash it on sdcard, anything was well, but armbian doesn't start at all. Nothing on the HDMI, nothing on the debug serial. Also LED doesn't light. I've tried two images: ubuntu jammy with GNOME and next case XFCE. Both cases didn't work. I've downloaded prebuilt image from armbian.org and it starts well. In my opinion, some problem with custom images in u-boot. but I don't know how to give a diagnosis.

In order for a doctor to make a diagnosis, he needs a patient.
Tell us the build parameters. To narrow down the search, you need to know at least the version of the kernel that will be built.

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
5 hours ago, kriptonus said:

Hi! I've tried built image from your's source, but it didn't work also. Nothing on the debug serial. Board isn't starting.

Thanks for testing it out. That rules out that the problem is caused by crust. 

 

Could you please check building against this commit https://github.com/armbian/build/tree/748eba003136a0681a72cab403171cf8e565c529. See if board boots with uboot version 2023.07-rc4? We have bumped you boot quite a lot for allwinner in last few weeks and somewhere between those bumps the booting stopped working.

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted

@goingIgor also noticed that his orange pi 3 stopped booting sometime about a month ago after I bumped u-boot and kernel couple of time. As there is no output on serial, the culprit is most likely u-boot and not kernel. We decided that we will test first by removing crust, that was the change in my branch, and then rolling back u-boot versions.

0
Link to comment
Share on other sites
going

going

Posted
Posted
3 часа назад, Gunjan Gupta сказал:

and then rolling back u-boot versions.

No. On the contrary, we'll just fix the build process.
I have found what needs to be done.

 

@Gunjan Gupta

I did not find in the build system the correct export of parameters when building with SCP:

export SCP=/src/crust/build/scp/scp.bin

and without using it.

If SCP is not used, pass the parameter to ignore.

export SCP=/dev/null

It is necessary to add somewhere in this place or I do not know

lib/functions/compilation/uboot.sh#L151

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
3 hours ago, going said:

I did not find in the build system the correct export of parameters when building with SCP:

export SCP=/src/crust/build/scp/scp.bin

and without using it.

SCP parameter is not supplied because scp.bin is copied to the location expected by uboot by default. Hence there is no need to set SCP variable. Its similar to how we copy atf and never set destination flag for the same.

 

3 hours ago, going said:

If SCP is not used, pass the parameter to ignore.

export SCP=/dev/null

It is necessary to add somewhere in this place or I do not know

lib/functions/compilation/uboot.sh#L151

Instead of that, we are using BINMAN_ALLOW_MISSING=1 when crust is not enabled for a board. This results in u-boot generating a dummy scp.bin file itself containing nothing but noop operation. Boards do boot with the autogenerated scp file. I had tested both scenario in details on nanopiduo2 (sun8i H3) board when I added crust support. And later when I got orange pi prime (sun50i H5) I have tested both scenario on that board as well.There is no fault of build system here. And as per Igor, Board was working until 2023.07-rc4 and broke afterwards. We just never got to testing whether the board boots if we rollback u-boot because of Igor's vacations

0
Link to comment
Share on other sites
going

going

Posted
Posted
1 час назад, Gunjan Gupta сказал:

There is no fault of build system here. And as per Igor, Board was working until 2023.07-rc4 and broke afterwards.

I just put together an image with this new u-boot: linux-u-boot-bananapim64-edge (2023.07.02)
 

The device is loading.

Скрытый текст 
U-Boot SPL 2023.07.02-armbian (Aug 13 2023 - 16:11:31 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.9(debug):0cf5f08-dirty
NOTICE:  BL31: Built : 16:11:26, Aug 13 2023
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x20a9298, model: BananaPi-M64
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
INFO:    PMIC: Probing AXP803 on RSB
INFO:    PMIC: aldo1 voltage: 2.800V
INFO:    PMIC: dcdc1 voltage: 3.300V
INFO:    PMIC: dcdc5 voltage: 1.500V
INFO:    PMIC: dcdc6 voltage: 1.100V
INFO:    PMIC: dldo1 voltage: 3.300V
INFO:    PMIC: dldo2 voltage: 3.300V
INFO:    PMIC: fldo1 voltage: 1.200V
INFO:    PMIC: Enabling DC SW
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: cortex_a53: CPU workaround for 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


U-Boot 2023.07.02-armbian (Aug 13 2023 - 16:11:31 +0000) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: BananaPi-M64
DRAM:  2 GiB
Core:  73 devices, 19 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20ca0
MMC:   mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial@1c28000
Out:   serial@1c28000
Err:   serial@1c28000
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@1c30000, eth1: usb_ether
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 2 USB Device(s) found
scanning bus usb@1c1b400 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
3259 bytes read in 2 ms (1.6 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
155 bytes read in 2 ms (75.2 KiB/s)
41928 bytes read in 5 ms (8 MiB/s)
Working FDT set to 4fa00000
3821 bytes read in 3 ms (1.2 MiB/s)
Applying kernel provided DT fixup script (sun50i-a64-fixup.scr)
## Executing script at 45000000
18501157 bytes read in 948 ms (18.6 MiB/s)
22392840 bytes read in 1146 ms (18.6 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=417d0000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    18501093 Bytes = 17.6 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 48e5b000, end 49fffde5 ... OK
   Loading Device Tree to 0000000048de8000, end 0000000048e5afff ... OK
Working FDT set to 48de8000

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.4.9-9 (root@vm-jammy) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3
[    0.000000] Machine model: BananaPi-M64
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] NUMA: NODE_DATA [mem 0xbfbc1040-0xbfbc2fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] cma: Reserved 128 MiB at 0x00000000b5a00000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.4
[    0.000000] percpu: Embedded 20 pages/cpu s42088 r8192 d31640 u81920
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 843419
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] alternatives: applying boot alternatives
[    0.000000] Kernel command line: root=UUID=29353d34-288d-4d1f-9cb0-727866714fe5 rootwait rootfstype=ext4 splash=verbose console=ttyS0,115200 console=1
[    0.000000] The swapaccount= commandline option is deprecated. Please report your usecase to linux-mm@kvack.org if you depend on this functionality.
[    0.000000] Unknown kernel command line parameters "splash=verbose ubootpart=690b1d77-01 cgroup_enable=memory", will be passed to user space.
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 12288 bytes
[    0.000000] printk: log_buf_len min size: 16384 bytes
[    0.000000] printk: log_buf_len: 32768 bytes
[    0.000000] printk: early log buf free: 14024(85%)
  ......

 

The difference:
1) the build was done in my branch. My branch is in an unbalanced state, but it allows me to build almost any package. The assembly of images is unstable.
2) ATF : ATFBRANCH='commit:0cf5f08a205e4877c9daef5d90e1086643590226' - This v2.9.0 + 440 commits

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
4 minutes ago, going said:

I just put together an image with this new u-boot: linux-u-boot-bananapim64-edge (2023.07.02)
 

The device is loading.

Sorry not sure what your point is. If its that new u-boot works, I already know that is true for most of the devices. Orange pi 3 being not one of them for some reason

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
7 minutes ago, going said:

he first thing that came to mind was the DTB for this device. On the u-boot and kernel side.

Hard to tell from the information I have, which is it broke after jumping to v2023.07-rc6 from v2023.07-rc4. If you check the diff, only dts changed belong to imx family. I don't have the board. Only thing I can do is ask users to roll back to specific commits and let me know if it starts working for them

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
On 8/17/2023 at 12:11 AM, kriptonus said:

What do I need to do to change version in build script?

The version of softwares needed for booting like bootloader, kernel, etc that are used during the build are defined in config/sources/families/include/sunxi64_common.inc file. When we upgrade these things, we sometimes also have to modify the patches that we apply on top of the upstream software. Due to that reason, simply changing the version in the above file will not work and most probably can cause failures during build process.

 

Following are the commits where I updated either U-boot or ATF

Quote

edc0a5bdfc57485a5eeaf89e54ea6be86881aada

4752a90850cc892ae1391da2db63c152ed4d5f74

748eba003136a0681a72cab403171cf8e565c529

5715b12d2fc2b46f9e0d39f9f61187ee4eb8f597

e4f9f637a6280e0a60c88fac148c6bfa8ccb67b1

9525b2d16c0aa0ec5cf446322e58a0dabb26c857

bc46fd509a50db4bcef014d79569b68287ecc19b

For each of the above commits, starting from the top of the above list, you can try the following

  1. Inside the directory where you cloned the armbian/build repository, checkout the code that was there before the software was updated using the following command 
    git checkout <commit_id>~1

    Replace <commit_id> with the hexadecimal value. For example, in order to check if the board booted before the change done in edc0a5bdfc57485a5eeaf89e54ea6be86881aada, run the following command to get the code back to the state it was before that commit 

    git checkout edc0a5bdfc57485a5eeaf89e54ea6be86881aada~1
  2. Then create the build using ./compile.sh, flash it on the sdcard and see if it boots
  3. If the build boots, you don't need to go further down the list. Just share the output of the following command with me 
    git rev-parse HEAD

Using that output I will check what change caused the board to stop booting and will fix the booting issue.

0
Link to comment
Share on other sites
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hello @Gunjan Gupta thanks for being explicit to OP, I would have been far to terse with minimal instructions.

 

Anyways, as this seems to stuck for user's here what found.

  

alistair@h616-hdmi:~/build$ git status
HEAD detached at f2257004a
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	ptmain.sh

nothing added to commit but untracked files present (use "git add" to track)
alistair@h616-hdmi:~/build$ git branch
* (HEAD detached at f2257004a)
  AGM1968/build
  cpu-frequency-scaling
  h616-DE
  main
  sunxi
alistair@h616-hdmi:~/build$ git rev-parse HEAD
f2257004a8fe147cd40dc03384435553ca890bf2
alistair@h616-hdmi:~/build$

  


U-Boot SPL 2022.07-armbian (Nov 30 2022 - 10:44:41 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(debug):a04808c1-dirty
NOTICE:  BL31: Built : 10:44:34, Nov 30 2022
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc086990, model: OrangePi 3 LTS
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
NOTICE:  PMIC: AXP805 detected
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2022.07-armbian (Nov 30 2022 - 10:44:41 +0000) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: OrangePi 3 LTS
DRAM:  2 GiB
Core:  50 devices, 14 uclasses, devicetree: separate
WDT:   Not starting watchdog@7020400
MMC:   mmc@4020000: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet 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
3259 bytes read in 2 ms (1.6 MiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
203 bytes read in 2 ms (98.6 KiB/s)
37640 bytes read in 6 ms (6 MiB/s)
3844 bytes read in 5 ms (750 KiB/s)
Applying kernel provided DT fixup script (sun50i-h6-fixup.scr)
## Executing script at 45000000
17114322 bytes read in 3058 ms (5.3 MiB/s)
 ** fs_devread read error - block
Failed to mount ext2 filesystem...
Can't set block device
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
No EFI system partition
BootOrder not defined
EFI boot manager: Cannot load any image
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1
switch to partitions #0, OK
mmc1(part 0) is current device
No ethernet found.
missing environment variable: pxeuuid
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
Retrieving file: pxelinux.cfg/000000
No ethernet found.
Retrieving file: pxelinux.cfg/00000
No ethernet found.
Retrieving file: pxelinux.cfg/0000
No ethernet found.
Retrieving file: pxelinux.cfg/000
No ethernet found.
Retrieving file: pxelinux.cfg/00
No ethernet found.
Retrieving file: pxelinux.cfg/0
No ethernet found.
Retrieving file: pxelinux.cfg/default-arm-sunxi-sunxi
No ethernet found.
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.
=>

 

 

0
Link to comment
Share on other sites
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hello @Gunjan Gupta .... as discussed emmc got in the way of initial boot above hence serial output.

 

The following boots:  

bc46fd509a50db4bcef014d79569b68287ecc19b

 

Output as follows: 

alistair@h616-hdmi:~/build$ git rev-parse HEAD
6dd7067c79bb04aa2b17eddcfc3730639c070267

 

Will have a look around, when a moment.

0
Link to comment
Share on other sites
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Correct, I suspect its something to do with crust implementation.

 

Edit: 2023.01 9525b2d16c0aa0ec5cf446322e58a0dabb26c857  not booting (for clarity)

          2022.10 bc46fd509a50db4bcef014d79569b68287ecc19b boots

 

  

config/boards/orangepi3-lts.csc

	@@ -7,6 +7,7 @@ KERNEL_TARGET="current,edge"
	MODULES="sprdbt_tty sprdwl_ng"
	MODULES_BLACKLIST_LEGACY="bcmdhd"
	ATFBRANCH="tag:v2.2"
+	CRUSTCONFIG="h6_defconfig"

	function post_family_tweaks_bsp__orangepi3-lts_BSP() {
		display_alert "Installing BSP firmware and fixups"
	@@ -20,4 +21,4 @@ function post_family_tweaks_bsp__orangepi3-lts_BSP() {
		fi

		return 0
-	}
+	}

 

Let me know what else you may need from me and will gladly assist

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted

We already tried disabling crust and user confirmed that board doesn't boot after disabling crust as well. So I don't think its crust.

 

Could you please try placing the attached patch in patch/u-boot/u-boot-sunxi/board_orangepi3-lts and build with latest armbian build code. Lets see if this boots.

0002-update-defconfig.patch

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
37 minutes ago, ALIGMSTEN said:

Edit: 2023.01 9525b2d16c0aa0ec5cf446322e58a0dabb26c857  not booting (for clarity)

          2022.10 bc46fd509a50db4bcef014d79569b68287ecc19b boots

 

Does bc46fd509a50db4bcef014d79569b68287ecc19b boots or bc46fd509a50db4bcef014d79569b68287ecc19b~1 boots? Notice ~1 at the end of commit id, which means we are checking out the commit before the specified commit id which is exactly 6dd7067c79bb04aa2b17eddcfc3730639c070267 as you reported in an earlier comment as the output of git rev-parse HEAD

0
Link to comment
Share on other sites
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Hello @Gunjan Gupta .... thanks for your efforts - you have success!

 

The board boots with your patch changes.

 

https://paste.next.armbian.com/samaqedifo

  

alistair@h616-hdmi:~/build$ git status
On branch sunxi
Your branch is up to date with 'origin/sunxi'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	patch/u-boot/u-boot-sunxi/board_orangepi3-lts/0002-update-defconfig.patch
	ptmain.sh

nothing added to commit but untracked files present (use "git add" to track)
alistair@h616-hdmi:~/build$ git rev-parse HEAD
af42e9d3ec25a89977d04f9d8bd8baa21803316e
alistair@h616-hdmi:~/build$

 

1
Link to comment
Share on other sites
ALIGMSTEN

ALIGMSTEN

Posted
Posted

Some further notes:

 

6dd7067c79bb04aa2b17eddcfc3730639c070267          - dmesg errors below have be effectively dealt with (no longer present)

  

[    1.549095] scpi_protocol scpi: incorrect or no SCP firmware found
[    1.549112] scpi_protocol: probe of scpi failed with error -62

[    2.550711] mdio_bus stmmac-0: MDIO device at address 1 is missing.

[   12.718701] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.719299] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[   12.883571] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.884145] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[   12.917916] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.918560] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[   12.959813] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.960377] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[   12.986871] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[   12.987477] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[   16.093764] platform sound_ac200: deferred probe pending
[  313.115888] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[  313.117333] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[  313.158438] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[  313.159807] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[  313.200901] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[  313.202341] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)
[  313.243587] dwmac-sun8i 5020000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[  313.244947] dwmac-sun8i 5020000.ethernet end0: __stmmac_open: Cannot attach to PHY (error: -19)

 

af42e9d3ec25a89977d04f9d8bd8baa21803316e         - dmesg errors present

  

[    1.454432] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pb not found, using dummy regulator
[    1.456700] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
[    1.457200] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
[    1.457218] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
[    1.457229] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
[    1.457241] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back
[    1.457429] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    1.457444] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    1.457485] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79
[    1.457498] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517
[    1.460996] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79
[    1.461021] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517
[    1.461051] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    1.461063] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    1.461101] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
[    1.461114] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
[    1.461126] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
[    1.461137] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back
[    1.461978] sunxi-mmc 4021000.mmc: allocated mmc-pwrseq
[    1.462425] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
[    1.463737] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79
[    1.463751] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517
[    1.464428] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    1.464441] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    1.464964] of_cfs_init
[    1.464963] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
[    1.464973] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
[    1.464985] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
[    1.464996] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back

 

0
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept