AM3352: u-boot -> Kernel data abort

I'm getting a similar thing if I try to TFTP boot as well:

link up on port 0, speed 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.2.4 (40 ms)
Using cpsw device
TFTP from server 192.168.2.1; our IP address is 192.168.2.4
Filename 'zImage'.
Load address: 0x82000000
Loading: #################################################T ################
         #################################################################
         ########################################T #########################
         #################################################################
         ####
         54.7 KiB/s
done
Bytes transferred = 3863040 (3af200 hex)
link up on port 0, speed 1000, full duplex
Using cpsw device
TFTP from server 192.168.2.1; our IP address is 192.168.2.4
Filename 'dtb/am335x-epn11291.dtb'.
Load address: 0x88000000
Loading: ###
         48.8 KiB/s
done
Bytes transferred = 32322 (7e42 hex)
Scanning disks on mmc...
Card did not respond to voltage select!
MMC Device 2 not found
MMC Device 3 not found
Found 1 disks
## Starting EFI application at 82000000 ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
data abort
pc : [<8ff87650>]          lr : [<8ff87685>]
reloc pc : [<80800650>]    lr : [<80800685>]
sp : 8df66604  ip : 0f787000     fp : 00000000
r10: 8ff88000  r9 : 8df66eb8     r8 : 00000000
r7 : 8ff878d0  r6 : 8ff87884     r5 : 000000ad  r4 : 200378d0
r3 : 00000000  r2 : 00000050     r1 : 8ff87880  r0 : abb1aaad
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32
Code: 2010ea83 bdf0d1f5 5b04f856 b2c54068 (5025f854)
UEFI image [0x8cbaf000:0x8cf5ffff] '/dtb\am335x-epn11291.dtb'
Resetting CPU ...

resetting ...

Hey Adam,
From your log files, it seems ok for u-boot loading kernel zImage, and dtb file.
I uploaded in attachment my note on u-boot loading kernel start process for your reference.
If you have JTAG access on your board, can we run a simple test:
- stop @u-boot prompt
- setup two (HW)breakpoints at 0x82000000, 0x80008000
- run "boot" @u-boot prompt
- if 1st bkpt @0x82000000 is hit, => u-boot loading zImage ok. you may check DDR @0x82000000
- if 2nd bkpt @0x80008000 is hit, => kernel compression ok. kernel is ready to run.
Best,
-Hong

u-boot_kernel.docx

minor correction: - if 2nd bkpt @0x80008000 is hit, => kernel DEcompression ok. kernel is ready to run.

Hey Hong, no JTAG on this board unfortunately. Can I privately send you my dts and am335x_xyz.h file, maybe you can see where it's going wrong? I have a feeling it's something silly.

Hey Adam, I'm thinking to run an alternative test given that no JTAT is available on your board.
Stop @u-boot prompt, instead of run normal "boot" cmd, run sub-cmds @u-boot as listed below.

run init_console
run envboot
run bootcmd_mmc0
mmc rescan
run loadimage
run args_mmc
run loadfdt
bootz ${loadaddr} - ${fdtaddr}

These sub-cmds are break-up version of "run bootcmd", these sub-cmds may be a bit different from yours depending on your u-boot build. These can be checked from "printenv" @u-boot prompt.

I'm also attaching a simple patch. After running cmd "bootz ${loadaddr} - ${fdtaddr})",
it prints "Switching to zImage entry = 0x82000000" right before hand-off from u-boot to kernel decompression routine running from 0x82000000.

Starting kernel ...
Switching to zImage entry = 0x82000000
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.94-gbe5389fd85 (sitara@sitara-Latitude-E6410) 

Best,

-Hong

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 9558dbc0c3..2471d5c723 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -11,6 +11,7 @@
  * Copyright (C) 2001  Erik Mouw (J.A.K.Mouw@its.tudelft.nl)
  */
 
+#define DEBUG
 #include <common.h>
 #include <command.h>
 #include <dm.h>
@@ -400,6 +401,7 @@ static void boot_jump_linux(bootm_headers_t *images, int flag)
 							  0, machid, r2);
 		} else
 #endif
+			printf("Switching to zImage entry = 0x%4X\n", (uint)images->ep);
 			kernel_entry(0, machid, r2);
 	}
 #endif

Hong, here's the outputs of doing what you suggest. The only difference is I had to run findfdt before loadfdt. I think the "loadimage" failed.

Press SPACE to abort autoboot in 5 seconds
=> run init_console
=> run envboot
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
=> run bootcmd_mmc0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
=> mmc rescan
=> run loadimage
## Current stack ends at 0x8df67a28 3863040 bytes read in 579 ms (6.4 MiB/s)
=> run args_mmc
=> run loadfdt
loading /undefined ...
=> run findfdt
=> run loadfdt
loading /am335x-epn11291.dtb ...
=> bootz ${loadaddr} - ${fdtaddr}
## Current stack ends at 0x8df67bd0 ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
=>

Do you have a good resource on the kernel boot process you can point me to? I think my issue is in all the include files so I'd like to take a step back and simplify the evm stuff. I just need to:

-find the fdt (findfdt)

-boot from MMC1 (eMMC) if it's available

-boot from MMC0 (SD card) if it's available

-eventually if neither is available I'll have to load the eMMC image from TFTP in chunks

Is it as simple as just changing the CONFIG_BOOTCOMMAND in my defconfig, and creating new functions in my .h to load the kernel instead of using distro_bootcmd?

Adam

Hey Adam,

Thanks for running sub-cmds @u-boot prompt. From your log, the issue seems pointing to your kernel DTB file <am335x-epn11291.dtb>.
"ERROR: Did not find a cmdline Flattened Device Tree" is triggered in boot_get_fdt() function in "common/image-fdt.c" file.
One simple scenario is "fdt_addr@0x88000000 points to a in-valid fdt image header"...
You may want to add "define #DEDUG" into very top of "common/image-fdt.c" file.
I'm attaching the log captured w/ "define #DEDUG" added in "common/image-fdt.c" for your reference.

4280832 bytes read in 282 ms (14.5 MiB/s)
41528 bytes read in 5 ms (7.9 MiB/s)
*  fdt: cmdline image address = 0x88000000
## Checking for 'FDT'/'FDT Image' at 88000000
*  fdt: raw FDT blob
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   of_flat_tree at 0x88000000 size 0x0000a238
## device tree at 88000000 ... 8800a237 (len=53816 [0xD238])
   Loading Device Tree to 8fff2000, end 8ffff237 ... OK

Starting kernel ...

Best,

-Hong

Hey Hong Guan64 Now that I have a good boot happening I'm having an issue with my eth0 interface once the kernel takes over. It works perfectly in u-boot, mdio commands are all good, etc. I just wanted to see if you had any thoughts before making another post... Like everything else it's probably pretty silly.

The errors I get from the kernel log:

[    1.749757] net eth0: initializing cpsw version 1.12 (0)
[    1.757608] net eth0: phy "/ocp/ethernet@4a100000/mdio@4a101000/ethernet-phy@0" not found on slave 0
[    1.773322] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.792520] Waiting up to 110 more seconds for network.

All the other CPSW stuff seems to go ok:

[    1.223421] libphy: Fixed MDIO Bus: probed
[    1.302630] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000
[    1.310367] libphy: 4a101000.mdio: probed
[    1.316095] cpsw 4a100000.ethernet: Detected MACID = f4:e1:1e:a9:af:89
[    1.322992] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4
[    1.329405] cpsw 4a100000.ethernet: ALE Table size 1024
[    1.334795] cpsw 4a100000.ethernet: cpts: overflow check period 500 (jiffies)

I'm thinking it's probably an issue with my fdt. I looked at several other boards with RGMII and don't see what's different. Here's the section(s) out of my dts:

cpsw_default: cpsw_default {
		pinctrl-single,pins = <
			/* Slave 1 */
			AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txen.rgmii1_tctl */
			AM33XX_IOPAD(0x918, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxdv.rgmii1_rctl */
			AM33XX_IOPAD(0x91c, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd3.rgmii1_td3 */
			AM33XX_IOPAD(0x920, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd2.rgmii1_td2 */
			AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd1.rgmii1_td1 */
			AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txd0.rgmii1_td0 */
			AM33XX_IOPAD(0x92c, PIN_OUTPUT_PULLDOWN | MUX_MODE2)	/* mii1_txclk.rgmii1_tclk */
			AM33XX_IOPAD(0x930, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxclk.rgmii1_rclk */
			AM33XX_IOPAD(0x934, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd3.rgmii1_rd3 */
			AM33XX_IOPAD(0x938, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd2.rgmii1_rd2 */
			AM33XX_IOPAD(0x93c, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd1.rgmii1_rd1 */
			AM33XX_IOPAD(0x940, PIN_INPUT_PULLDOWN | MUX_MODE2)	/* mii1_rxd0.rgmii1_rd0 */
		>;
	};

	cpsw_sleep: cpsw_sleep {
		pinctrl-single,pins = <
			/* Slave 1 reset value */
			AM33XX_IOPAD(0x914, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x918, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x91c, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x920, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x924, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x928, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x92c, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x930, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x934, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x938, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x93c, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x940, PIN_INPUT_PULLDOWN | MUX_MODE7)
		>;
	};

	davinci_mdio_default: davinci_mdio_default {
		pinctrl-single,pins = <
			/* MDIO */
			AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)	/* mdio_data.mdio_data */
			AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0)			/* mdio_clk.mdio_clk */
		>;
	};

	davinci_mdio_sleep: davinci_mdio_sleep {
		pinctrl-single,pins = <
			/* MDIO reset value */
			AM33XX_IOPAD(0x948, PIN_INPUT_PULLDOWN | MUX_MODE7)
			AM33XX_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE7)
		>;
	};

&mac {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&cpsw_default>;
	pinctrl-1 = <&cpsw_sleep>;
	slaves = <1>;
	status = "okay";
};

&davinci_mdio {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&davinci_mdio_default>;
	pinctrl-1 = <&davinci_mdio_sleep>;
	status = "okay";

	ethphy0: ethernet-phy@0 {
		compatible = "marvell";
		reg = <0>;
	};
};

&cpsw_emac0 {
	phy-handle = <&ethphy0>;
	phy-mode = "rgmii-id";
};

I also went through the kernel's menuconfig and didn't see anything that jumped out at me, but the issue may also be there. I'm using a Marvell 88E1510 PHY.

Thank you!

Adam

Absolutely.