Issue TFTP booting from SPL

Embedded Linux Discussions
21

In Linux, it does, but with our factory default eMMC, you won’t really see an improvement between 4-bit and 8-bit. There are really cheap microSD’s on the 4-bit interface that are faster then the factory default eMMC at 8-bit…

Factory BBB eMMC in 4-bit:

=> version
U-Boot 2019.04-00002-gc9b3922522 (Aug 24 2020 - 16:42:18 -0500), Build: jenkins-github_Bootloader-Builder-144

arm-linux-gnueabihf-gcc (Linaro GCC 6.5-2018.12) 6.5.0
GNU ld (Linaro_Binutils-2018.12) 2.27.0.20161229
=> mmc dev 1
switch to partitions #0, OK
mmc1(part 0) is current device
=> mmc info
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC02 
Bus Speed: 48000000
Mode : MMC High Speed (52MHz)
Rd Block Len: 512
MMC version 4.4.1
High Capacity: No
Capacity: 1.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 KiB
HC WP Group Size: 0 Bytes
User Capacity: 1.8 GiB
Boot Capacity: 1 MiB ENH
RPMB Capacity: 128 KiB ENH

Regards,

22

Ok, kind of irritating that this one thing isn’t quite perfect but oh well.

Thanks for the help.

EDIT: interesting thing to note, I commented out all the platdata stuff at the bottom of the board.c file and the “No match for driver ‘omap_hsmmc’” messages went away, but both MMC interfaces work exactly the same as before.

23

Just to update the public record, switching to DM_MMC in 2019.04 worked perfectly, and the eMMC now reports 8-bit.

image

Just needed to add to my defconfig:
CONFIG_OF_CONTROL=y
CONFIG_SUPPORT_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE=“your-board”
CONFIG_DM_MMC=y

Device Tree entry:

	emmc_pins: pinmux_emmc_pins {
		pinctrl-single,pins = <
			0x080 (PIN_INPUT | MUX_MODE2)		//eMMC_CLK
			0x084 (PIN_INPUT_PULLUP | MUX_MODE2)	//eMMC_CMD
			0x000 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D0
			0x004 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D1
			0x008 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D2
			0x00c (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D3
			0x010 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D4
			0x014 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D5
			0x018 (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D6
			0x01c (PIN_INPUT_PULLUP | MUX_MODE1)	//eMMC_D7
		>;
	};

&mmc2 {
	pinctrl-names = "default";
	pinctrl-0 = <&emmc_pins>;
	bus-width = <8>;
	ti,non-removable;
	max-frequency = <96000000>;
	status = "okay";
};
1 Like
24

Awesome @AdamGerken

25

Ok, blast from the past. I have a new revision of this board and I was hoping to get it up and going with mainline u-boot and I’m so close I can taste it. I’m having the exact same issue again though, no BOOTP messages from SPL. I tried DM with SPL but that appears to still not work so I tried updating the board.c to match the EVM board.c with regards to the networking stuff with no luck.

The new stuff that looks like it handles networking in SPL:

/* CPSW plat */
#if !CONFIG_IS_ENABLED(OF_CONTROL)
struct cpsw_slave_data slave_data[] = {
	{
		.slave_reg_ofs  = CPSW_SLAVE0_OFFSET,
		.sliver_reg_ofs = CPSW_SLIVER0_OFFSET,
		.phy_addr       = 0,
	},
	{
		.slave_reg_ofs  = CPSW_SLAVE1_OFFSET,
		.sliver_reg_ofs = CPSW_SLIVER1_OFFSET,
		.phy_addr       = 1,
	},
};

struct cpsw_platform_data am335_eth_data = {
	.cpsw_base		= CPSW_BASE,
	.version		= CPSW_CTRL_VERSION_2,
	.bd_ram_ofs		= CPSW_BD_OFFSET,
	.ale_reg_ofs		= CPSW_ALE_OFFSET,
	.cpdma_reg_ofs		= CPSW_CPDMA_OFFSET,
	.mdio_div		= CPSW_MDIO_DIV,
	.host_port_reg_ofs	= CPSW_HOST_PORT_OFFSET,
	.channels		= 8,
	.slaves			= 2,
	.slave_data		= slave_data,
	.ale_entries		= 1024,
	.mac_control		= 0x20,
	.active_slave		= 0,
	.mdio_base		= 0x4a101000,
	.gmii_sel		= 0x44e10650,
	.phy_sel_compat		= "ti,am3352-cpsw-phy-sel",
	.syscon_addr		= 0x44e10630,
	.macid_sel_compat	= "cpsw,am33xx",
};

struct eth_pdata cpsw_pdata = {
	.iobase = 0x4a100000,
	.phy_interface = 0,
	.priv_pdata = &am335_eth_data,
};

U_BOOT_DRVINFO(am335x_eth) = {
	.name = "eth_cpsw",
	.plat = &cpsw_pdata,
};
#endif

I added .phy_if = PHY_INTERFACE_MODE_RGMII, to the salve_data struct, still with no luck.

The old code that worked back in the day has a function, board_eth_init() which is what I suspect the issue is… after 2019.04 they removed non DM networking so I assume they removed the call to this function.

Any new ideas? @RobertCNelson’s u-boot is now up to 2020.10 or something so if the EVM network boots I’m sure this has been addressed at some point in time?

Thanks!

26

Hi @AdamGerken i recently tested v2022.04 for beagleboard.org… Networking is back, dhcp commands and pxe boot seem to be operating… So now that the old Ethernet stack has been removed, and the new DM stuff has taken over, 2022.04 might be worth you to retest…

Regards,

27

Robert, as always that you for the quick reply.

2022.04 is what I pulled and am trying to use. My issue is the SPL networking… it doesn’t seem to send the bootp request to TFTP load the u-boot.img. It says it has a link up at 1000mbps so I assume the MDIO portion is working. Haven’t gotten u-boot loaded enough to confirm that but it compiles happily with DM networking, RGMII options, etc so I hope that’ll work.

Should DM work for SPL? If I turn on DM for SPL I don’t seem to get any networking or serial so I assumed the DM stuff still wasn’t implemented for SPL, with it off I at least get some networking and serial.

28

@RobertCNelson I’m not sure what I’m doing wrong here. Do you know if there are any other settings I need to change in the U_BOOT_DRVINFO set up to switch to RGMII in SPL other than phy.if? I’m thinking I’m somehow not setting this up correctly.

SPL_DM doesn’t seem to work at all still unfortunately.

The hardware works find with the old 2019.04 stuff I have for the previous revision of this board.

/* CPSW plat */
#if !CONFIG_IS_ENABLED(OF_CONTROL)
struct cpsw_slave_data slave_data[] = {
	{
		.slave_reg_ofs  = CPSW_SLAVE0_OFFSET,
		.sliver_reg_ofs = CPSW_SLIVER0_OFFSET,
		.phy_addr       = 0,
		.phy_if = PHY_INTERFACE_MODE_RGMII
	},
	{
		.slave_reg_ofs  = CPSW_SLAVE1_OFFSET,
		.sliver_reg_ofs = CPSW_SLIVER1_OFFSET,
		.phy_addr       = 1,
		.phy_if = PHY_INTERFACE_MODE_RGMII
	},
};

struct cpsw_platform_data am335_eth_data = {
	.cpsw_base		= CPSW_BASE,
	.version		= CPSW_CTRL_VERSION_2,
	.bd_ram_ofs		= CPSW_BD_OFFSET,
	.ale_reg_ofs		= CPSW_ALE_OFFSET,
	.cpdma_reg_ofs		= CPSW_CPDMA_OFFSET,
	.mdio_div		= CPSW_MDIO_DIV,
	.host_port_reg_ofs	= CPSW_HOST_PORT_OFFSET,
	.channels		= 8,
	.slaves			= 1,
	.slave_data		= slave_data,
	.ale_entries		= 1024,
	.mac_control		= 0x20,
	.active_slave		= 0,
	.mdio_base		= 0x4a101000,
	.gmii_sel		= 0x44e10650,
	.phy_sel_compat		= "ti,am3352-cpsw-phy-sel",
	.syscon_addr		= 0x44e10630,
	.macid_sel_compat	= "cpsw,am33xx",
};

struct eth_pdata cpsw_pdata = {
	.iobase = 0x4a100000,
	.phy_interface = 0,
	.priv_pdata = &am335_eth_data,
};

U_BOOT_DRVINFO(am335x_eth) = {
	.name = "eth_cpsw",
	.plat = &cpsw_pdata,
};
#endif
29

Some more info I found today right before quitting time, of course:

For some reason cpsw_gmii_sel_am3352() in cpsw.c is not getting the correct data from the structs above. If I hard code it to be RGMII it does work.

static void cpsw_gmii_sel_am3352(struct cpsw_priv *priv,
				 phy_interface_t phy_mode)
{
	u32 reg;
	u32 mask;
	u32 mode = 0;
	bool rgmii_id = false;
	int slave = priv->data->active_slave;

	reg = readl(priv->data->gmii_sel);

	switch (phy_mode) {
	case PHY_INTERFACE_MODE_RMII:
		mode = AM33XX_GMII_SEL_MODE_RMII;
		break;

	case PHY_INTERFACE_MODE_RGMII:
	case PHY_INTERFACE_MODE_RGMII_RXID:
		mode = AM33XX_GMII_SEL_MODE_RGMII;
		break;
	case PHY_INTERFACE_MODE_RGMII_ID:
	case PHY_INTERFACE_MODE_RGMII_TXID:
		mode = AM33XX_GMII_SEL_MODE_RGMII;
		rgmii_id = true;
		break;

	case PHY_INTERFACE_MODE_MII:
	default:
		mode = AM33XX_GMII_SEL_MODE_MII;
		break;
	};

	mode = AM33XX_GMII_SEL_MODE_RGMII;  //HARD CODE THESE
	rgmii_id = true;					//HARD CODE

	mask = GMII_SEL_MODE_MASK << (slave * 2) | BIT(slave + 6);
	mode <<= slave * 2;

	if (priv->data->rmii_clock_external) {
		if (slave == 0)
			mode |= AM33XX_GMII_SEL_RMII1_IO_CLK_EN;
		else
			mode |= AM33XX_GMII_SEL_RMII2_IO_CLK_EN;
	}

	if (rgmii_id) {
		if (slave == 0)
			mode |= AM33XX_GMII_SEL_RGMII1_IDMODE;
		else
			mode |= AM33XX_GMII_SEL_RGMII2_IDMODE;
	}

	reg &= ~mask;
	reg |= mode;

	printf("In cpsw_gmii_sel_am3352, mode:%d, id: %d", mode, rgmii_id);

	writel(reg, priv->data->gmii_sel);
}

Tomorrow’s task is find out why.

Also, now that I can move on to TFTP loading the u-boot.img I’m getting: TFTP error: trying to overwrite reserved memory... If anyone knows anything about that. I tried # CONFIG_LMB is not set in my defconfig bu that didn’t seem to help.

30

Alright there’s definitely some break-down of info in cpsw.c causing the plat data from board.c not to make it to cpsw_gmii_sel_am3352() but I can’t figure it out. I’m just going to leave it hard coded for now. It’s also definitely LMB causing my issue in tftp.c, commenting out all the #ifdef CONFIG_LMB sections makes the tftp work as expected.

Now, I don’t get any serial in u-boot. I think it’s still running but has no output… Ugh.

31

Alright throwing in the towel, back to 2019.04 I go. Not sure how any of these newer ones TFTP boot from SPL.

32

Hey Everyone! Two years later still running into the same issues, and it is driving me mad! Did anyone have any solution for this with u-boot 202x.xx?

Our custom board support is done, BOOTP messages appear on the serial, but no bootp packets at my server’s wireshark.