yes, i realize not too many people care about MPC8260 but it's one of my target systems, and this might apply to MPC83xx as well, i'll check shortly.
was just perusing our current setup for U-Boot on an MPC8260 board (which works), we have this fairly innocuous board setup routine which looks a lot like *other* peoples' innocuous board setup routines:
#if defined(CONFIG_OF_BOARD_SETUP) int ft_board_setup(void *blob, bd_t *bd) { ft_cpu_setup(blob, bd); #ifdef CONFIG_PCI ft_pci_setup(blob, bd); #endif return 0; }
but i noticed just yesterday that, in arch/powerpc/cpu/mpc8260/cpu.c one reads:
#if defined(CONFIG_OF_LIBFDT) && defined (CONFIG_OF_BOARD_SETUP) void ft_cpu_setup (void *blob, bd_t *bd) { #if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) ||\ defined(CONFIG_HAS_ETH2) || defined(CONFIG_HAS_ETH3) fdt_fixup_ethernet(blob); <---- UH OH #endif
... snip ...
this threw me a bit since i remembered this from common/image-fdt.c:
int image_setup_libfdt(bootm_headers_t *images, void *blob, int of_size, struct lmb *lmb) { ulong *initrd_start = &images->initrd_start; ulong *initrd_end = &images->initrd_end; int ret = -EPERM; int fdt_ret;
... snip ...
fdt_fixup_ethernet(blob); <--- called there as well
so assuming that image_setup_libfdt() is being called in this situation (i'm assuming it is, unless there's some weird configuration that skips over it), then fdt_fixup_ethernet() seems to be called twice. AFAICT, that won't cause a problem, it just seems silly.
now, from what i can read, that common FDT handling code in common/image-fdt.c was added back in May of 2013:
$ git show 13d06981a9829c9edcfd6f9f582d216fbaed95e5 Author: Simon Glass sjg@chromium.org Date: Wed May 8 08:06:01 2013 +0000
image: Add device tree setup to image library
This seems to be a common function for several architectures, so create a common function rather than duplicating the code in each arch. ... snip ...
at which time i *assume* board maintainers could then remove some duplicate calls from their own code (such as calls to fdt_fixup_ethernet), knowing it would be called automatically. so does it make sense that the call to that routine still exists in MCP8260 cpu.c? was this just a (perfectly understandable) case of people not really caring about MPC8260 anymore?
actually, if i do a search under arch/:
$ grep -r fdt_fixup_ethernet arch arch/powerpc/cpu/mpc8260/cpu.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/mpc83xx/fdt.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/mpc86xx/fdt.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/mpc85xx/fdt.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/ppc4xx/fdt.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/mpc8xx/fdt.c: fdt_fixup_ethernet(blob); arch/powerpc/cpu/mpc512x/cpu.c: fdt_fixup_ethernet(blob); arch/nios2/cpu/fdt.c: fdt_fixup_ethernet(blob); arch/arm/cpu/armv7/ls102xa/fdt.c: fdt_fixup_ethernet(blob); $
there are still a few calls. are those calls still supposed to be there given that fdt_fixup_ethernet() seems guaranteed(?) to be called now based on simon's common FDT handling routine? or am i misreading something?
rday