Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Marek Vasut]

On Sunday, January 03, 2016 at 03:56:01 PM, Stefano Babic wrote:
> Hi Michael,
> 
> some aditional comments before you will send V3:

[...]

> > diff --git a/board/i2se/duckbill/Makefile b/board/i2se/duckbill/Makefile
> > new file mode 100644
> > index 000..b5577e3
> > --- /dev/null
> > +++ b/board/i2se/duckbill/Makefile
> > @@ -0,0 +1,12 @@
> > +#
> > +# (C) Copyright 2014-2015
> > +# Michael Heimpold, m...@heimpold.de.
> > +#
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +
> > +ifndef CONFIG_SPL_BUILD
> > +obj-y  := duckbill.o
> > +else
> > +obj-y  := iomux.o
> > +endif

All the MXS boards should use spl.o , since it's not only iomux in there.

> Well, it is okay if you want to maintain the name, but iomux is one of
> the most used name for files. What about duckbill-iomux ?
> 
[...]

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Stefano Babic]

Hi Michael,

some aditional comments before you will send V3:

On 13/12/2015 12:09, Michael Heimpold wrote:
> Signed-off-by: Michael Heimpold 

This is the patch introducing a new board. It is not bad if you add some
info in the commit message, for example which peripherals are already
supported and so on. See other commit messages from other boards.

> ---
> 
> Please note, that this board setup files need the function
> mxs_power_switch_dcdc_clocksource() as introduced in my patch
> "ARM: mxs: allow boards to select DC-DC switching clock source"
> 
> Changes in v2:
>   - added autoboot stuff
>   - reworked tftp update workflow
>   - added dc-dc clock source configuration
> 
> Changes in v1:
>   - initial public submission
> 
>  arch/arm/Kconfig  |   8 ++
>  arch/arm/include/asm/mach-types.h |  13 +++
>  board/i2se/duckbill/Kconfig   |  15 +++
>  board/i2se/duckbill/MAINTAINERS   |   6 ++
>  board/i2se/duckbill/Makefile  |  12 +++
>  board/i2se/duckbill/duckbill.c| 180 +++
>  board/i2se/duckbill/iomux.c   | 162 
>  configs/duckbill_defconfig|   8 ++
>  include/configs/duckbill.h| 216 
> ++
>  9 files changed, 620 insertions(+)
>  create mode 100644 board/i2se/duckbill/Kconfig
>  create mode 100644 board/i2se/duckbill/MAINTAINERS
>  create mode 100644 board/i2se/duckbill/Makefile
>  create mode 100644 board/i2se/duckbill/duckbill.c
>  create mode 100644 board/i2se/duckbill/iomux.c
>  create mode 100644 configs/duckbill_defconfig
>  create mode 100644 include/configs/duckbill.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fb9176b..e612194 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -167,6 +167,13 @@ config TARGET_MX28EVK
>   select CPU_ARM926EJS
>   select SUPPORT_SPL
>  
> +config TARGET_DUCKBILL
> + bool "Support duckbill"
> + select CPU_ARM926EJS
> + select SUPPORT_SPL
> + help
> +   Support for I2SE's Duckbill series.
> +

This is a complete separate issue - it could be fixed later. I noted
that the number of MX23/MX28 boards (mxs) is becoming quite large, and
each time arch/arm/Kconfig must be fixed. What about to add a
arch/arm/cpu/arm926ejs/mxs/Kconfig, in the same way we did for MX6 ?

>  config TARGET_MX23_OLINUXINO
>   bool "Support mx23_olinuxino"
>   select CPU_ARM926EJS
> @@ -803,6 +810,7 @@ source "board/freescale/vf610twr/Kconfig"
>  source "board/gumstix/pepper/Kconfig"
>  source "board/h2200/Kconfig"
>  source "board/hisilicon/hikey/Kconfig"
> +source "board/i2se/duckbill/Kconfig"
>  source "board/imx31_phycore/Kconfig"
>  source "board/isee/igep0033/Kconfig"
>  source "board/maxbcm/Kconfig"
> diff --git a/arch/arm/include/asm/mach-types.h 
> b/arch/arm/include/asm/mach-types.h
> index d51be0b..1f0ffaa 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
>  #define MACH_TYPE_COLIBRI_T30  4493
>  #define MACH_TYPE_APALIS_T30   4513
>  #define MACH_TYPE_OMAPL138_LCDK2495
> +#define MACH_TYPE_DUCKBILL 4754

The file was still updated last year, but we preferred to set the
MACH_TYPE directly into the board configuration file, as this value is
used only once and only for legacy boards. Please set

#define CONFIG_MACH_TYPE4754

in include/configs/duckbill.h

> +
>  /*
>   * These have not yet been registered
>   */
> diff --git a/board/i2se/duckbill/Kconfig b/board/i2se/duckbill/Kconfig
> new file mode 100644
> index 000..98c1e46
> --- /dev/null
> +++ b/board/i2se/duckbill/Kconfig
> @@ -0,0 +1,15 @@
> +if TARGET_DUCKBILL
> +
> +config SYS_BOARD
> + default "duckbill"
> +
> +config SYS_VENDOR
> + default "i2se"
> +
> +config SYS_SOC
> + default "mxs"
> +
> +config SYS_CONFIG_NAME
> + default "duckbill"
> +
> +endif
> diff --git a/board/i2se/duckbill/MAINTAINERS b/board/i2se/duckbill/MAINTAINERS
> new file mode 100644
> index 000..5496baa
> --- /dev/null
> +++ b/board/i2se/duckbill/MAINTAINERS
> @@ -0,0 +1,6 @@
> +I2SE DUCKBILL BOARD
> +M:   Michael Heimpold 
> +S:   Maintained
> +F:   board/i2se/duckbill/
> +F:   include/configs/duckbill.h
> +F:   configs/duckbill_defconfig

Some files are missing, I presume.

> diff --git a/board/i2se/duckbill/Makefile b/board/i2se/duckbill/Makefile
> new file mode 100644
> index 000..b5577e3
> --- /dev/null
> +++ b/board/i2se/duckbill/Makefile
> @@ -0,0 +1,12 @@
> +#
> +# (C) Copyright 2014-2015
> +# Michael Heimpold, m...@heimpold.de.
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +ifndef   CONFIG_SPL_BUILD
> +obj-y:= duckbill.o
> +else
> +obj-y:= iomux.o
> +endif

Well, it is okay if you want to maintain the name, but iomux is one of
the most used name for files. What about duckbill-iomux ?

> diff --git 

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Marek Vasut]

On Sunday, December 13, 2015 at 12:09:58 PM, Michael Heimpold wrote:

Commit message describing the board would be real nice.

> Signed-off-by: Michael Heimpold 
> ---
> 
> Please note, that this board setup files need the function
> mxs_power_switch_dcdc_clocksource() as introduced in my patch
> "ARM: mxs: allow boards to select DC-DC switching clock source"

[...]

> diff --git a/arch/arm/include/asm/mach-types.h
> b/arch/arm/include/asm/mach-types.h index d51be0b..1f0ffaa 100644
> --- a/arch/arm/include/asm/mach-types.h
> +++ b/arch/arm/include/asm/mach-types.h
> @@ -1107,6 +1107,7 @@ extern unsigned int __machine_arch_type;
>  #define MACH_TYPE_COLIBRI_T30  4493
>  #define MACH_TYPE_APALIS_T30   4513
>  #define MACH_TYPE_OMAPL138_LCDK2495
> +#define MACH_TYPE_DUCKBILL 4754

This board is still using mach id to boot kernel ? Wow ...

>  #ifdef CONFIG_ARCH_EBSA110
>  # ifdef machine_arch_type
> @@ -14188,6 +14189,18 @@ extern unsigned int __machine_arch_type;
>  # define machine_is_apalis_t30() (0)
>  #endif

[...]

> +int board_init(void)
> +{
> + /* Adress of boot parameters */
> + gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
> +
> + return 0;
> +}
> +
> +#ifdef   CONFIG_CMD_MMC

#ifdef[SPACE] please, not [TAB]

> +int board_mmc_init(bd_t *bis)
> +{
> + return mxsmmc_initialize(bis, 0, NULL, NULL);
> +}
> +#endif
> +
> +#ifdef   CONFIG_CMD_NET

DTTO

[...]

> +void mx28_adjust_mac(int dev_id, unsigned char *mac)
> +{
> + mac[0] = 0x00;
> + mac[1] = 0x01;
> + mac[2] = 0x87;
> +}
> +#endif
> +
> +#ifdef CONFIG_OF_BOARD_SETUP
> +int ft_board_setup(void *blob, bd_t *bd)
> +{
> + uint8_t enetaddr[6];
> + u32 mac = 0;
> +
> + enetaddr[0] = 0x00;
> + enetaddr[1] = 0x01;
> + enetaddr[2] = 0x87;

Looks like there are two copies of the same OUI ?

> +#ifdef CONFIG_MXS_OCOTP
> + /* only Duckbill SPI has a MAC for the QCA7k */
> + fuse_read(0, 1, );
> +#endif
> +
> + if (mac != 0) {
> + enetaddr[3] = (mac >> 16) & 0xff;
> + enetaddr[4] = (mac >>  8) & 0xff;
> + enetaddr[5] =  mac& 0xff;
> +
> + fdt_find_and_setprop(blob,
> + 
> "/apb@8000/apbh@8000/ssp@80014000/ethernet@0", +  
> 
> "local-mac-address", enetaddr, 6, 1);

You can use aliases {} to locate the ethernet node here.

> + }
> +
> + return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_REVISION_TAG
> +u32 get_board_rev(void)
> +{
> + return system_rev;
> +}
> +#endif
> +
> +#ifdef CONFIG_SERIAL_TAG
> +void get_board_serial(struct tag_serialnr *serialnr)
> +{
> + serialnr->low = serialno;
> + serialnr->high = 0;
> +}
> +#endif
> +
> +int misc_init_r(void)
> +{
> + unsigned int led_red_gpio;
> + char *s;
> +
> + /* Board revision detection */
> + gpio_direction_input(MX28_PAD_LCD_D17__GPIO_1_17);
> +
> + /* MX28_PAD_LCD_D17__GPIO_1_17: v1 = pull-down, v2 = pull-up */
> + system_rev =
> + gpio_get_value(MX28_PAD_LCD_D17__GPIO_1_17);

Does gpio_get_value() always return 0/1 value ? I don't think so.

> + system_rev += 1;
> +
> + /* enable red LED to indicate a running bootloader */
> + if (system_rev == 1)
> + led_red_gpio = MX28_PAD_AUART1_RX__GPIO_3_4;
> + else
> + led_red_gpio = MX28_PAD_SAIF0_LRCLK__GPIO_3_21;
> + gpio_direction_output(led_red_gpio, 1);
> +
> + if (system_rev == 1)
> + puts("Board: I2SE Duckbill\n");
> + else
> + puts("Board: I2SE Duckbill 2\n");
> +
> + serialno = getenv_ulong("serial#", 10, 0);
> + s = getenv("serial#");
> + if (s && s[0]) {
> + puts("Serial: ");
> + puts(s);
> + putc('\n');
> + }
> +
> + return 0;
> +}

[...]

> diff --git a/include/configs/duckbill.h b/include/configs/duckbill.h
> new file mode 100644
> index 000..fa70f29
> --- /dev/null
> +++ b/include/configs/duckbill.h
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2014-2015 Michael Heimpold 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +#ifndef __CONFIGS_DUCKBILL_H__
> +#define __CONFIGS_DUCKBILL_H__
> +
> +/* System configurations */
> +#define CONFIG_MX28  /* i.MX28 SoC */
> +#define CONFIG_MACH_TYPE MACH_TYPE_DUCKBILL
> +
> +#define CONFIG_MISC_INIT_R
> +
> +#define CONFIG_SYS_MXS_VDD5V_ONLY
> +
> +/* U-Boot Commands */
> +#define CONFIG_SYS_NO_FLASH
> +#define CONFIG_DISPLAY_CPUINFO
> +#define CONFIG_DOS_PARTITION
> +
> +#define CONFIG_CMD_BOOTZ
> +#define CONFIG_CMD_CACHE
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_EXT4
> +#define CONFIG_CMD_EXT4_WRITE
> +#define CONFIG_CMD_FAT
> +#define CONFIG_CMD_FUSE
> +#define CONFIG_CMD_GPIO
> +#define CONFIG_CMD_I2C
> +#define CONFIG_CMD_MII
> +#define CONFIG_CMD_MMC
> +#define CONFIG_CMD_SPI
> +#define CONFIG_CMD_UNZIP
> +
> 

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Michael Heimpold]

Hi Marek,

thanks for your review. My comments inline below.

Am Sunday 13 December 2015, 16:40:14 schrieb Marek Vasut:
> On Sunday, December 13, 2015 at 12:09:58 PM, Michael Heimpold wrote:
> 
> Commit message describing the board would be real nice.
> 

Ok, I'll add it in v3.

[...]
> > 
> >  #define MACH_TYPE_COLIBRI_T30  4493
> >  #define MACH_TYPE_APALIS_T30   4513
> >  #define MACH_TYPE_OMAPL138_LCDK2495
> > 
> > +#define MACH_TYPE_DUCKBILL 4754
> 
> This board is still using mach id to boot kernel ? Wow ...

Not really. But I looked at other iMX28 boards and all still define such
a MACH_TYPE. For historic reasons, only? However, I think it does not hurt,
so some customers who think they still need to go with old Freescale kernel
could use this...

[...]

> > +
> > +#ifdef CONFIG_CMD_MMC
> 
> #ifdef[SPACE] please, not [TAB]
> 

I heavily used m28evk and mx28evk as reference, so I thought
that tab is the preferred style, but I can change, have no strong opinion
on this...

> [...]
> 
> > +void mx28_adjust_mac(int dev_id, unsigned char *mac)
> > +{
> > +   mac[0] = 0x00;
> > +   mac[1] = 0x01;
> > +   mac[2] = 0x87;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, bd_t *bd)
> > +{
> > +   uint8_t enetaddr[6];
> > +   u32 mac = 0;
> > +
> > +   enetaddr[0] = 0x00;
> > +   enetaddr[1] = 0x01;
> > +   enetaddr[2] = 0x87;
> 
> Looks like there are two copies of the same OUI ?

I'm not sure, whether I understand the question correctly?
All Duckbill devices only have one Ethernet interface. For this
interface the MAC is programmed into the first OTP fuse register
as this seems to be best practise on this platform. Since this register
is only 24 bit, the first two byte must be adjusted by board code.
The "Duckbill SPI" is an evaluation platform for QCA7000 powerline
chip. On this devices, the second OTP register is programmed with
a second MAC adress, but this address must be passed via DT to kernel.
Both addresses usually have the same OUI, thats correct.

> 
> > +#ifdef CONFIG_MXS_OCOTP
> > +   /* only Duckbill SPI has a MAC for the QCA7k */
> > +   fuse_read(0, 1, );
> > +#endif
> > +
> > +   if (mac != 0) {
> > +   enetaddr[3] = (mac >> 16) & 0xff;
> > +   enetaddr[4] = (mac >>  8) & 0xff;
> > +   enetaddr[5] =  mac& 0xff;
> > +
> > +   fdt_find_and_setprop(blob,
> > +
> > "/apb@8000/apbh@8000/ssp@80014000/ethernet@0", +
> > 
> > "local-mac-address", enetaddr, 6, 1);
> 
> You can use aliases {} to locate the ethernet node here.

"can" == "should" ? :-)
I'll have a look, but AFAIR in linux' imx28.dtsi, ethernet1 alias is
already used for mac1. I'm not sure, if I can redefine it in board DT
to point to SPI node...

[...]
> > +
> > +   /* MX28_PAD_LCD_D17__GPIO_1_17: v1 = pull-down, v2 = pull-up */
> > +   system_rev =
> > +   gpio_get_value(MX28_PAD_LCD_D17__GPIO_1_17);
> 
> Does gpio_get_value() always return 0/1 value ? I don't think so.
> 

Hm, on mxs this seems to be the case, and include/asm-generic/gpio.h
tells this, too - but also tells, that this interface described there is
deprecated? It seems that I do not see the forest for the trees looking
for the API docu... Anyway, I would simply add !! to do the trick...

[...]

> > +/* FEC Ethernet on SoC */
> > +#ifdef CONFIG_CMD_NET
> > +#define CONFIG_FEC_MXC
> > +#define CONFIG_NET_MULTI
> > +#define CONFIG_MX28_FEC_MAC_IN_OCOTP
> > +#define CONFIG_FEC_MXC_PHYADDR 1
> > +#define IMX_FEC_BASE   MXS_ENET0_BASE
> 
> This IMX_FEC_BASE is definitelly unused on MXS.
> 
I use fecmxc_initialize in the board setup, not fecmxc_initialize_multi,
and thus this define is required. However, I could switch to
fecmxc_initialize_multi and the I could drop CONFIG_FEC_MXC_PHYADDR
and IMX_FEC_BASE...

> > +#endif
> > +
> > +#define CONFIG_IPADDR  192.168.1.10
> > +#define CONFIG_SERVERIP192.168.1.1
> > +#define CONFIG_NETMASK 255.255.255.0
> > +#define CONFIG_GATEWAYIP   192.168.1.254
> 
> Definitelly remove these, you should never ever hard-code these settings
> into U-Boot.

I don't understand. This are only default settings in case, U-Boot starts with
an empty environment. Other boards do the same, so what's wrong here?
> 
> > +/* BOOTP options */
> > +#define CONFIG_BOOTP_SUBNETMASK
> > +#define CONFIG_BOOTP_GATEWAY
> > +#define CONFIG_BOOTP_HOSTNAME
> 
> DTTO

These defines affect what is requested in the DHCP/BOOTP packet. I do not
think, it can drop it.

> 
> > +/* SPI */
> > +#ifdef CONFIG_CMD_SPI
> > +#define CONFIG_DEFAULT_SPI_BUS 2
> 
> Add default CS please

I think I'll prefer to drop the SPI block completely, no real usage.

> 
> > +#define CONFIG_DEFAULT_SPI_MODESPI_MODE_0
> > +#endif
> > +
> > +/* Boot Linux */
> > +#define CONFIG_BOOTDELAY   1
> > +#define CONFIG_BOOTFILE"zImage"
> 
> Why don't you switch to fitImage ?
> 

Re: [U-Boot] [PATCH v2] arm: mxs: add support for I2SE's Duckbill boards

[Marek Vasut]

On Sunday, December 13, 2015 at 10:53:30 PM, Michael Heimpold wrote:
> Hi Marek,

Hi!

> thanks for your review. My comments inline below.

np :)

> Am Sunday 13 December 2015, 16:40:14 schrieb Marek Vasut:
> > On Sunday, December 13, 2015 at 12:09:58 PM, Michael Heimpold wrote:
> > 
> > Commit message describing the board would be real nice.
> 
> Ok, I'll add it in v3.
> 
> [...]
> 
> > >  #define MACH_TYPE_COLIBRI_T30  4493
> > >  #define MACH_TYPE_APALIS_T30   4513
> > >  #define MACH_TYPE_OMAPL138_LCDK2495
> > > 
> > > +#define MACH_TYPE_DUCKBILL 4754
> > 
> > This board is still using mach id to boot kernel ? Wow ...
> 
> Not really. But I looked at other iMX28 boards and all still define such
> a MACH_TYPE. For historic reasons, only?

Yes, they are (probably) capable of booting some obscure pre-DT kernel versions.

> However, I think it does not hurt,
> so some customers who think they still need to go with old Freescale kernel
> could use this...

OK

> [...]
> 
> > > +
> > > +#ifdef   CONFIG_CMD_MMC
> > 
> > #ifdef[SPACE] please, not [TAB]
> 
> I heavily used m28evk and mx28evk as reference, so I thought
> that tab is the preferred style, but I can change, have no strong opinion
> on this...

Space please ;-)

> > [...]
> > 
> > > +void mx28_adjust_mac(int dev_id, unsigned char *mac)
> > > +{
> > > + mac[0] = 0x00;
> > > + mac[1] = 0x01;
> > > + mac[2] = 0x87;

HERE

> > > +}
> > > +#endif
> > > +
> > > +#ifdef CONFIG_OF_BOARD_SETUP
> > > +int ft_board_setup(void *blob, bd_t *bd)
> > > +{
> > > + uint8_t enetaddr[6];
> > > + u32 mac = 0;
> > > +
> > > + enetaddr[0] = 0x00;
> > > + enetaddr[1] = 0x01;
> > > + enetaddr[2] = 0x87;

HERE

> > Looks like there are two copies of the same OUI ?
> 
> I'm not sure, whether I understand the question correctly?

See the "HERE" markers above, you have two copies of the same thing in
the code for whatever reason.

> All Duckbill devices only have one Ethernet interface. For this
> interface the MAC is programmed into the first OTP fuse register
> as this seems to be best practise on this platform. Since this register
> is only 24 bit, the first two byte must be adjusted by board code.
> The "Duckbill SPI" is an evaluation platform for QCA7000 powerline
> chip. On this devices, the second OTP register is programmed with
> a second MAC adress, but this address must be passed via DT to kernel.
> Both addresses usually have the same OUI, thats correct.

See above, it's just a nitpick.

> > > +#ifdef CONFIG_MXS_OCOTP
> > > + /* only Duckbill SPI has a MAC for the QCA7k */
> > > + fuse_read(0, 1, );
> > > +#endif
> > > +
> > > + if (mac != 0) {
> > > + enetaddr[3] = (mac >> 16) & 0xff;
> > > + enetaddr[4] = (mac >>  8) & 0xff;
> > > + enetaddr[5] =  mac& 0xff;
> > > +
> > > + fdt_find_and_setprop(blob,
> > > +
> > > "/apb@8000/apbh@8000/ssp@80014000/ethernet@0", +
> > > 
> > > "local-mac-address", enetaddr, 6, 1);
> > 
> > You can use aliases {} to locate the ethernet node here.
> 
> "can" == "should" ? :-)

Yes, it's a good idea. It's also how U-Boot patches $ethaddr into the
DT, it uses the aliases to do that.

> I'll have a look, but AFAIR in linux' imx28.dtsi, ethernet1 alias is
> already used for mac1. I'm not sure, if I can redefine it in board DT
> to point to SPI node...

You can always define ethernet2 .

> [...]
> 
> > > +
> > > + /* MX28_PAD_LCD_D17__GPIO_1_17: v1 = pull-down, v2 = pull-up */
> > > + system_rev =
> > > + gpio_get_value(MX28_PAD_LCD_D17__GPIO_1_17);
> > 
> > Does gpio_get_value() always return 0/1 value ? I don't think so.
> 
> Hm, on mxs this seems to be the case, and include/asm-generic/gpio.h
> tells this, too - but also tells, that this interface described there is
> deprecated? It seems that I do not see the forest for the trees looking
> for the API docu... Anyway, I would simply add !! to do the trick...

I think that's a good idea, I wouldn't depend on it returning 0/1 .

> [...]
> 
> > > +/* FEC Ethernet on SoC */
> > > +#ifdef   CONFIG_CMD_NET
> > > +#define CONFIG_FEC_MXC
> > > +#define CONFIG_NET_MULTI
> > > +#define CONFIG_MX28_FEC_MAC_IN_OCOTP
> > > +#define CONFIG_FEC_MXC_PHYADDR   1
> > > +#define IMX_FEC_BASE MXS_ENET0_BASE
> > 
> > This IMX_FEC_BASE is definitelly unused on MXS.
> 
> I use fecmxc_initialize in the board setup, not fecmxc_initialize_multi,
> and thus this define is required. However, I could switch to
> fecmxc_initialize_multi and the I could drop CONFIG_FEC_MXC_PHYADDR
> and IMX_FEC_BASE...

Oh I see. Whichever you prefer then.

> > > +#endif
> > > +
> > > +#define CONFIG_IPADDR192.168.1.10
> > > +#define CONFIG_SERVERIP  192.168.1.1
> > > +#define CONFIG_NETMASK   255.255.255.0
> > > +#define CONFIG_GATEWAYIP 192.168.1.254
> > 
> > Definitelly remove these, you should never ever hard-code these settings
> > into U-Boot.
> 
> I don't understand. This are only default