Issue TFTP booting from SPL

AdamGerken · October 14, 2020, 5:14pm

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?

RobertCNelson · October 14, 2020, 5:36pm

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…

Regards,

AdamGerken · October 14, 2020, 5:41pm

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

RobertCNelson · October 14, 2020, 5:43pm

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

Regards,

AdamGerken · October 14, 2020, 5:50pm

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?

AdamGerken · October 14, 2020, 6:31pm

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

AdamGerken · October 14, 2020, 7:42pm

Found this topic: https://patchwork.ozlabs.org/project/uboot/patch/20191021232652.132164-4-sjg@chromium.org/

AdamGerken · October 14, 2020, 7:57pm

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.

RobertCNelson · October 14, 2020, 8:23pm

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:

Regards,

AdamGerken · October 15, 2020, 2:55pm

@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.

RobertCNelson · October 15, 2020, 3:08pm

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

Regards,

AdamGerken · October 15, 2020, 3:18pm

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.

AdamGerken · October 16, 2020, 2:40pm

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…

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.

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.

Thanks!

RobertCNelson · October 16, 2020, 2:53pm

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

github.com

u-boot/u-boot/blob/3c99166441bf3ea325af2da83cfe65430b49c066/board/ti/am335x/board.c#L1058-L1086


      
          #if !CONFIG_IS_ENABLED(OF_CONTROL)
          static const struct omap_hsmmc_plat am335x_mmc0_platdata = {
          	.base_addr = (struct hsmmc *)OMAP_HSMMC1_BASE,
          	.cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_4BIT,
          	.cfg.f_min = 400000,
          	.cfg.f_max = 52000000,
          	.cfg.voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195,
          	.cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
          };
          
          U_BOOT_DEVICE(am335x_mmc0) = {
          	.name = "omap_hsmmc",
          	.platdata = &am335x_mmc0_platdata,
          };
          
          static const struct omap_hsmmc_plat am335x_mmc1_platdata = {
          	.base_addr = (struct hsmmc *)OMAP_HSMMC2_BASE,
          	.cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS | MMC_MODE_8BIT,
          	.cfg.f_min = 400000,
          	.cfg.f_max = 52000000,

This file has been truncated. show original

Regards,

AdamGerken · October 16, 2020, 2:58pm

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: https://lists.denx.de/pipermail/u-boot/2013-August/160783.html but that didn’t help.

AdamGerken · October 16, 2020, 3:30pm

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?

RobertCNelson · October 16, 2020, 4:37pm

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

Regards,

AdamGerken · October 16, 2020, 4:39pm

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…

AdamGerken · October 16, 2020, 6:02pm

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

AdamGerken · October 16, 2020, 8:54pm

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