
On Fri, Sep 13, 2019 at 04:34:45PM +0200, Ondřej Jirman wrote:
On Fri, Sep 13, 2019 at 08:25:09AM -0600, Simon Glass wrote:
Hi Ondřej,
On Thu, 12 Sep 2019 at 17:39, Ondřej Jirman megous@megous.com wrote:
On Thu, Sep 12, 2019 at 01:28:10PM -0600, Simon Glass wrote:
Hi,
On Thu, 12 Sep 2019 at 12:28, Ondřej Jirman megous@megous.com wrote:
Hi,
On Thu, Sep 12, 2019 at 12:22:15PM -0600, Simon Glass wrote:
Hi,
On Thu, 12 Sep 2019 at 10:59, Ondřej Jirman megous@megous.com wrote: > > Hello, > > On Thu, Aug 01, 2019 at 09:46:54AM -0600, Simon Glass wrote: > > This function fits better with the network subsystem, so move it. > > Unfortunately, this breaks builds without CONFIG_NET. Reverting it > fixes the issue. > > LD u-boot > cmd/built-in.o: In function `eth_env_get_enetaddr': > u-boot-v2019.10/cmd/nvedit.c:363: undefined reference to `eth_parse_enetaddr' > make[1]: *** [u-boot-v2019.10/Makefile:1594: u-boot] Error 1 > make[1]: Leaving directory 'builds/.tmp/u-pc-5.4' > make: *** [Makefile:148: sub-make] Error 2 >
Which board is this please?
It's orangepi_pc_defconfig with some menuconfig changes to disable CONFIG_NET.
The issue is that by moving eth_parse_enetaddr to net/ if net is disabled, this function will not be available to nvedit.c.
The board doesn't really matter.
The offending call is in setup_environment() in board/sunxi/board.c so I think the board does matter. There might be something else I am missing but I cannot see it at present.
Would you like to send a patch?
I'd like to send a patch to revert this change and move eth_parse_enetaddr back.
The call eth_env_set_enetaddr() is correct and should succeed even if net is disabled in u-boot. It determines the stable MAC address to use for ethernet interfaces described in DT for Linux to use.
See fdt_fixup_ethernet() that does that.
That feature is independent of the whole network stack and network drivers in u-boot.
So you are saying that you should be able to read the MAC address, etc. with CONFIG_NET disabled?
MAC address is not read from network device, it's generated from serial ID of the SoC and then patched into DTB for later use by Linux.
The process doesn't involve anything related to the net subsystem of u-boot.
Agreed, it sounds like this is more of a generic use function than a network function as there's a lot of platforms where the MAC is generated in a similar fashion.