Forums › Reference, Evaluation, and Development Boards › OSD32MP1-RED › Ethernet troubles in U-Boot
Hello.
I’ve been having issues getting ethernet access up and running in U-Boot with the v1.2 rev of the RED. When I interrupt boot at the U-Boot stage and use the dhcp command, I get this response:
1 2 3 4 5 | invalid MAC address in OTP 00:00:00:00:00:00 Net: stm32mp1_clk_get_parent: no parents defined for clk id 123 Error: ethernet@5800a000 address not set. No ethernet found. |
I’m using Buildroot. I took the existing device tree files in the source tree for the RED and replaced them with the v1.2 versions at OSD32MP1-RED-Device-tree.
That fixed the issue of ethernet not working in Linux, but I’m still having issues in U-Boot. My goal is to be able to get a DHCP lease in U-Boot and then bring a Linux image over the network, so ethernet working in U-Boot is key to that goal.
The error occurs even with the reference v1.2 images provided by Octavo (both the OpenSTLinux and Debian images), so it isn’t an issue specific to my Buildroot configuration.
Any help is appreciated. Thank you.
Austin,
I have found several issues with the ST implementation of the DWC QOS drivers (dwc_eth_qos.c). I have not confirmed but it appears that the MAC clocks are stopped and the “mdio” and “mii” commands will get stuck and you will see a cryptic “not idle at entry” error. I found that the substitute is to run “ethtool eth0” in Linux instead and not use U-Boot’s equivalent.
However, you can get dhcp to work. First, confirm your MAC address:
> env print ethaddr
If you don’t have one, make one up for now:
> env set ethaddr 11:22:33:44:55:66
The run:
> dhcp
You should get an IP address. Then “ping” your gateway and it should respond.
Carlos
Thank you, Carlos! I was distracted by the message about the clock and didn’t notice the one about the invalid MAC address.
I set a random MAC and DHCP worked as expected. Thanks again. I’ll keep an eye out for the “not idle at entry” errors also.
By the way, for anyone who finds this in the future and wonders why certain random MAC addresses they try result in “invalid address”: the least-significant bit of the first byte of the address must not be a 1.
For example: E9:D3:F5:DD:F5:19 is invalid because the first byte is 11101001, so the LSB is a 1. But E8:D3:F5:DD:F5:19 is valid because the first byte is 11101000, so the LSB is a 0.
Useful to know.
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields