Issue TFTP booting from SPL

Hey all (Robert)

I have a board that I’m trying to TFTP the spl and u-boot and have two issues I’ve been trying to work on. I’m using u-boot 2020.10 mainline so not exactly what’s prescribed here but I think it’s pretty similar.

I’m getting spl TFTP’d to the AM3352 no problem, but then it looks like spl can’t get ‘ethaddr’ so when it sends BOOTP requests they don’t go anywhere, and obviously can’t load u-boot.img.

Here’s the boot log:

I guess my question is where should spl be getting env variables from? I tried doing set_env(“ethaddr”, “00:11:22:33:44:55”); in “spl_start_uboot()” but it didn’t change anything.

Second question is when I compile I don’t seem to be getting u-boot.img for some reason. I assume that’s a setting somewhere?

Hi @AdamGerken, very strange, sadly I haven’t tried tftp on mainline in a while, I do know that it works over the usart:

and it did build the u-boot.img…

Normally ethaddr get’s set in u-boot.img:

Loading Environment from FAT... <ethaddr> not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a100000, eth3: usb_ether

Okay, time to fire up a tftp server and test some things…


I just did away with the EEPROM checks all together in my board.c so maybe that’s the issue?

I can serial load u-boot-spl.bin and u-boot.bin with no issues at all. I can then TFTP load the Kernet, etc. I think (hope) my last issue is getting spl to TFTP u-boot

as long as that means it uses the “BeagleBone Black” DDR/Ethernet defaults, it’d expect it to work.


Yes, the DDR init is now just hardcoded to use the right parameters, and that seems to work. There doesn’t appear to be any Ethernet related stuff in the board.c that applies any more.

There is some stuff that’s excluded by “if(board_is_ice2())” as well as the CPSW platdata that is untouched but shouldn’t be included due to #if !CONFIG_IS_ENABLED(OF_CONTROL)

Which leaves the reading of the mac from the efuse which doesn’t run in SPL.

I hardcode the env board_name in board_late_init() maybe that has some knock-on effect?

Ok so I have CONFIG_SPL_ENV_IS_NOWHERE so the env should be in the spl binary. Any idea where this is set?

Found this topic:

Ok, adding # CONFIG_SPL_USE_TINY_PRINTF is not set got rid of the error in spl but I’m still not seeing the BOOTP messages from spl, only the ROM ones.

I’m still not convinced spl has an ethaddr set, which wouldn’t allow it to talk to the server, no? Do you know how spl gets its env variables? Even just a dummy MAC should be fine.

It’ll should have a default MAC from the bootrom… Sorry i haven’t worked enough on this boot method, ravikp7 used the vid/pid for identification:


@RobertCNelson I’m trying to see why ethernet isn’t working in 2020.10 spl. I’m looking through your u-boot source/patch and see that there’s a large section of CPSW code that is #ifndef’d out by CONFIG_DM_ETH however there are no DM configs in the am335x_evm_defconfig, and only GPIO and SERIAL in arch/arm/mach-omap2/am335x/Kconfig so I’m assuming you don’t use DM for the ethernet drivers? Have you ever tried DM? I’m starting to think that even though DM_ETH was required from 2020.07 onwards and appears to have been updated it isn’t actually supported.

DM_ETH is the only option after 2019.04, that’s one reason why we still use that old version for


I understand. Such a pain. It works perfectly in u-boot, just doesn’t work in spl. Someone has been doing a lot of work on the am335x_evm platform in the latest u-boot so hopefully soon TI will be catching up with the times.

Hey @RobertCNelson, Happy Friday. I diverted back to your 2019.04 plus patches and hardcoded the board.c for my board, all is working great now. So I think, for future reference, 2020.10 doesn’t really support DM Ethernet in SPL, even though it appears to. Oh well.

I do have two hopefully quick questions about 2019.04 now…

  1. I always get RTC 32KCLK Source: External. Even though I don’t have an external RTC. I added in CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC in hopes that rtc32k_enable would kick in and enable the internal RTC. I do have an OSC hooked up so it should work, but board_init always reports External.

EDIT: never mind on the RTC. I was writing 1 to bit 3, instead of a 0. Real RTFM moment.

  1. My MMC1 bus, which is an eMMC like the BBB, reports that it’s using a 4-bit bus. Is there anyway to tell it to use 8? I can confirm with 2020.10 and the DM_MMC with dts that the 8-bit mode is working.


Humm, it should be in 8-bit mode based on:


Yeah, that’s what I thought. I still have that in my board.c but:


I tried adding #define CONFIG_HSMMC2_8BIT to board.h per: but that didn’t help.

Thought I had it… CONFIG_OF_CONTROL was set, but un defining that doesn’t help.

I do get: No match for driver 'omap_hsmmc' for both in my boot log but I don’t think that’s the issue, right?

Do you need 8-bit mode in u-boot, as the kernel has it’s own pinmux, thus this would only affect u-boot…


Not really “need” but the board is going to boot from eMMC and u-boot is going to flash the eMMC image from TFTP so a little extra speed would be nice…

Any other clues or places to look? I’ve tried a bunch of stuff now and nothing is helping. Enabling HS400, etc…

@RobertCNelson does the BBB use all 8-bits? I can’t figure out what is different between my build and the am335x_evm build…