We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
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.
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?
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
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, 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 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.
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…
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.
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…