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.
Hey everyone, I’m having an issue where I have a custom AM3352 board that’s pretty simple: debug UART, UART for BLE HCI, eMMC, and RGMII PHY. No I2C, no GPIOs needed… super simple. I’m trying to get everything booted, using the BeagleBone/AM335X_EVM as bases and I’m having a bit of trouble. I thought since I based this off Robert’s directions on Linux on ARM I’d ask here… the TI forum hasn’t been much help.
What I’m trying to do here is UART boot the u-boot-spl.bin and u-boot.img which is working, but for some reason when I get into the u-boot prompt I can seem to get any ethernet traffic going. I’m trying to get a TFTP boot going from there to load the kernel, dtb, and filesystem.
I’ve enabled the correct PHY driver in menuconfig, and I can see that the PHY is connected and talking via MDIO commands in u-boot, and I can see the link speed via “mii info” but there just doesn’t seem to be traffic. I think I’ve gotten down the path that I need to be using the driver method for setting up Ethernet? I get some errors when I try to compile u-boot with CONFIG_DM_ETH though:
drivers/built-in.o: In function `device_is_compatible':
/home/adam/u-boot/drivers/core/device.c:815: undefined reference to `ofnode_device_is_compatible'
drivers/gpio/built-in.o: In function `gpio_request_tail':
/home/adam/u-boot/drivers/gpio/gpio-uclass.c:665: undefined reference to `ofnode_get_name'
drivers/gpio/built-in.o: In function `_gpio_request_by_name_nodev':
/home/adam/u-boot/drivers/gpio/gpio-uclass.c:692: undefined reference to ofnode_parse_phandle_with_args'
adding #include <dm/ofnode.h> didn’t change it, even thought that’s where these functions are defined…
Similarly if I try CONFIG_DM_MMC I get an error:
drivers/built-in.o: In function `omap_hsmmc_execute_tuning':
/home/adam/u-boot/drivers/mmc/omap_hsmmc.c:645: undefined reference to `thermal_get_temp'
Hi @AdamGerken, how are you defining your board in u-boot? Thru the old board file, or thru a device tree model? CONFIG_DM_ETH points toward device-tree model…
U-Boot v2019.04 sorta supports both, for BeagleBoard.org we still use the old board file method. (I really need to start looking at switching us to use’s U-Boot newer device-tree model…)
But aside, that’s one reason why we are “stuck” on v2019.04, the non DM_ETH code got ripped out shortly after:
Which means after v2019.04, you need to use the device-tree model to get Ethernet working in u-boot.
Basically, if you need CONFIG_DM_ETH, you should really just ignore my patch-set and use mainline v2020.04 (which was just released 2 days ago…) and see if it works better.
Hey Robert, thanks for the reply, and all the work you’ve put into this, your stuff is way easier to understand, for me at least, than any of the other guides.
I originally used your patches on 2019.04 and did the board file method… I had no idea u-boot had even start implementing device tree stuff. I’m not much of a linux guy, mostly just hardware and some microcontroller code here and there, this is my first real dive into this stuff. Anyway, I ran into my issues with ethernet once u-boot is up and running and an Engineer on the TI forum led me down the path of not using the driver model being the issue, because that’s what they support.
I’m honestly not at all sure what’s right and wrong… they want me to use the SDK exclusively and I’m not too keen on that for some reason, my board doesn’t have an EEPROM so it’s a pain to untangle the SDK to work.
I think I would rather do what you suggest and move my u-boot forward in the mainline and adopt the device tree method vs backwards if the driver model really is what I need to solve my issue. If all goes well, this product will morph into several others for my customer.
I have some upper level questions though. Do I even need to make board files, mux, etc? Is CONFIG_DM the only thing I need to set to tell u-boot to use the driver model… other than making the dts and adding to the Makefile, obviously. How does u-boot know which dtb to use? Do you know of a good walk through of porting a board using the driver model?
Hi @AdamGerken, so for a BeagleBone Black Clone board, take a look here:
am335x_evm_defconfig: default device tree, is defined by CONFIG_DEFAULT_DEVICE_TREE, the CONFIG_OF_LIST can be cut down…
Part of the board file is still used, you can force a specific device tree thru:
Device tree’s can be found here (basic green for example)
PS, non-eeprom, is tricky, but you can hack into “./board/ti/common/board_detect.c” and just create a fake eeprom in memory, that way you can set ep->name/ep->version and get thru most of the board detection’s reads… (u-boot only reads the eeprom once, then uses the cached values…)
I’ve done that here, for “blank” eeprom’s, and create a fake A335BLNK + EMMC device, so a very basic kernel dtb (am335x-bonegreen.dtb) will be loaded…
Alright, I’ve been fighting this for a couple more days now. I’ve moved to mainline u-boot v2020.04 to use the driver model as in the SDK. I have to be close now and I just a have a couple questions that will hopefully keep me moving in the right direction:
I get in my u-boot boot log: “Net: error: phy_id read failed”
I think this may have something to do with the phy not working well. I’ve verified that my MDIO interface is working… once booted I can talk to the PHY. I also verified it’s loading the correct Marvell drivers. I just can’t figure out where that error message is coming from. any clues?
Another oddity is that if I don’t do the pinmux in the board file the ethernet doesn’t work at all, even though it’s defined in my dts file as well. What’s up with that? Do I really need both? Is something wrong with the setup of the dts? The dts definitely seems to be working, I can make changes and see the results when compiled and booted.
Lastly, and this isn’t really an issue, but an annoyance, is there any way to get rid of the I2C lines? I don’t have I2C, I have it disabled in the configs, etc. but the “Error, wrong i2c adapter 0 max 0 possible” error keeps showing up.
OK, got the phy_id error sorted. It was in CPSW.c if it failed to find phy-handle it would look for phy-id then fail that if it found neither, and since phy-id is no more, I was looking in the wrong spot. Apparently I was missing “slaves = <1>” in my dt. All good now. Ethernet still doesn’t seem to work though.
I have to see if I can figure out loopback on the PHY or something, at this point everything looks like it should be working but just… isn’t.
Hey Robert, I tracked my previous issue down to a hardware issue in the RGMII lines, I have corrected boards in now and everything appears to be working, I have the TFTP server working well and can load the spl. In my images from mainline loading the spl via tftp just kills the whole thing, so I moved back to my images based on your steps and I get “SPL: Unsupported Boot Device!” when trying to boot u-boot from tftp.
