Skip to contentSkip to conversation

add initial support for bluegiga apx4devkit

PATCH New Veli-Pekka Peltola 3 participants 6 messages Dec 13, 2011 – Dec 14, 2011

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

Add initial support for Bluegiga APX4 CoM and development kit.

---
 board/bluegiga/apx4devkit/Makefile     |   45 +++++++
 board/bluegiga/apx4devkit/apx4devkit.c |  204 ++++++++++++++++++++++++++++++++
 boards.cfg                             |    1 +
 include/configs/apx4devkit.h           |  176 +++++++++++++++++++++++++++
 4 files changed, 426 insertions(+), 0 deletions(-)
 create mode 100644 board/bluegiga/apx4devkit/Makefile
 create mode 100644 board/bluegiga/apx4devkit/apx4devkit.c
 create mode 100644 include/configs/apx4devkit.h
board/bluegiga/apx4devkit/Makefile new file +45 -0
new file mode 100644
index 0000000..4fec2f0
@@ -0,0 +1,45 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).o
+
+COBJS	:= apx4devkit.o
+
+SRCS	:= $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(call cmd_link_o_target, $(OBJS))
+
+all:	$(ALL)
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
board/bluegiga/apx4devkit/apx4devkit.c new file +204 -0

204 lines not on this page · raw message

boards.cfg +1 -0
index 1e5b3e0..214e22f 100644
@@ -159,6 +159,7 @@ tx25                         arm         arm926ejs   tx25                karo
 zmx25                        arm         arm926ejs   zmx25               syteco         mx25
 imx27lite                    arm         arm926ejs   imx27lite           logicpd        mx27
 magnesium                    arm         arm926ejs   imx27lite           logicpd        mx27
+apx4devkit                   arm         arm926ejs   -                   bluegiga       mx28
 m28evk                       arm         arm926ejs   -                   denx           mx28
 nhk8815                      arm         arm926ejs   nhk8815             st             nomadik
 nhk8815_onenand              arm         arm926ejs   nhk8815             st             nomadik       nhk8815:BOOT_ONENAND
include/configs/apx4devkit.h new file +176 -0

176 lines not on this page · raw message

Signature · 1 line
1.7.5.4
#1 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

Quoted 4 lines · Veli-Pekka Peltola

Add initial support for Bluegiga APX4 CoM and development kit.

I applied this patch on top of head U-boot and got build errors when building "make u-boot.sb".

Can you please try it and let me know if you are able to boot it?

I am rebasing my mx28evk on top of the latest U-boot and I am facing some issues.

Would be interested to know if your mx28 board can boot with the latest origin/master.

Thanks,

Fabio Estevam

#2 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

In reply to Veli-Pekka Peltola
Quoted 5 lines · Veli-Pekka Peltola

Add initial support for Bluegiga APX4 CoM and development kit.

---

Hi Veli-Pekka,

Quoted 4 lines
 board/bluegiga/apx4devkit/Makefile     |   45 +++++++
 board/bluegiga/apx4devkit/apx4devkit.c |  204 ++++++++++++++++++++++++++++++++
 boards.cfg                             |    1 +
 include/configs/apx4devkit.h           |  176 +++++++++++++++++++++++++++

You should also update the MAINTAINERS file, adding your name as board maintainer.

Quoted 5 lines
 4 files changed, 426 insertions(+), 0 deletions(-)
 create mode 100644 board/bluegiga/apx4devkit/Makefile
 create mode 100644 board/bluegiga/apx4devkit/apx4devkit.c
 create mode 100644 include/configs/apx4devkit.h

your board configuration file does not set any SPL constant. I cannot understand how it works. Only u-boot.bin can be built, and this is only a part of the system. What about the first boot loader (SPL) ?

Please add also in the commit message which components (Ethernet, MMC, I2C, SPI,...) you support with your patch.

Quoted 48 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +48 -0
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MUX_CONFIG_GENERIC	(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#define MUX_CONFIG_GPMI	(MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
+#define MUX_CONFIG_GPMI_12MA	(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+
+const iomux_cfg_t iomux_setup[] = {
+	/* GPMI NAND */
+	MX28_PAD_GPMI_D00__GPMI_D0 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D01__GPMI_D1 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D02__GPMI_D2 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D03__GPMI_D3 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D04__GPMI_D4 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D05__GPMI_D5 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D06__GPMI_D6 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D07__GPMI_D7 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_ALE__GPMI_ALE | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_CLE__GPMI_CLE | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_CE0N__GPMI_CE0N | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_RDY0__GPMI_READY0 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_RDN__GPMI_RDN | MUX_CONFIG_GPMI_12MA,
+	MX28_PAD_GPMI_WRN__GPMI_WRN | MUX_CONFIG_GPMI_12MA,
+	MX28_PAD_GPMI_RESETN__GPMI_RESETN | MUX_CONFIG_GPMI_12MA,
+
+	/* MMC0 */
+	MX28_PAD_SSP0_DATA0__SSP0_D0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA1__SSP0_D1 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA2__SSP0_D2 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA3__SSP0_D3 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA4__SSP0_D4 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA5__SSP0_D5 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA6__SSP0_D6 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA7__SSP0_D7 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_CMD__SSP0_CMD | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT |
+		(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_NOPULL),
+	MX28_PAD_SSP0_SCK__SSP0_SCK |
+		(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),
+
+	/* FEC Ethernet */
+	MX28_PAD_ENET0_MDC__ENET0_MDC | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_MDIO__ENET0_MDIO | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RX_EN__ENET0_RX_EN | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TX_EN__ENET0_TX_EN | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RXD0__ENET0_RXD0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RXD1__ENET0_RXD1 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_GENERIC,

board/bluegiga/apx4devkit/apx4devkit.c line 97

Quoted 10 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +10 -0
+	MX28_PAD_ENET_CLK__CLKCTRL_ENET | MUX_CONFIG_GENERIC,
+};
+
+/*
+ * Functions
+ */
+int board_early_init_f(void)
+{
+	/* Setup only pads needed by U-Boot that are not initialized before */
+	mxs_iomux_setup_multiple_pads(iomux_setup, ARRAY_SIZE(iomux_setup));

Mmmhh..die Pins are setup in the SPL code, checks in arch/arm/cpu/arm926ejs/mx28/spl_boot.c.

You are adding a lot of pins that are maybe duplicated, are'nt they ?

board/bluegiga/apx4devkit/apx4devkit.c line 139

Quoted 9 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +9 -0
+#ifdef CONFIG_CMD_NET
+
+#define MII_PHY_CTRL2	0x1f
+
+int fecmxc_mii_postcall(int phy)
+{
+	miiphy_write("FEC", 0, MII_PHY_CTRL2, 0x8180);
+	return 0;
+}

So you have only one ethernet interface - add also this info in your commit message.

board/bluegiga/apx4devkit/apx4devkit.c line 172

Quoted 4 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +4 -0
+void imx_get_mac_from_fuse(char *mac)
+{
+	memset(mac, 0, 6);
+}

This is wrong, and surely you do not get the address from fuses.

Quoted 7 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +7 -0
+#ifdef CONFIG_SERIAL_TAG
+#define MXS_OCOTP_MAX_TIMEOUT	1000000
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+	struct mx28_ocotp_regs *ocotp_regs =
+		(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+

board/bluegiga/apx4devkit/apx4devkit.c line 191

Quoted 10 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +10 -0
+	serialnr->high = 0;
+	serialnr->low = 0;
+
+	writel(OCOTP_CTRL_RD_BANK_OPEN, &ocotp_regs->hw_ocotp_ctrl_set);
+
+	if (mx28_wait_mask_clr(&ocotp_regs->hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+				MXS_OCOTP_MAX_TIMEOUT)) {
+		printf("MXS: Can't get serial number from OCOTP\n");
+		return;
+	}

I think we can factorize some code with m28evk, and putting code to access OCOTP in a common directory, such as arch/arm/cpu/arm926ejs/mx28.

board/bluegiga/apx4devkit/apx4devkit.c line 203

Quoted 7 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +7 -0
+#ifdef CONFIG_REVISION_TAG
+u32 get_board_rev(void)
+{
+	if (getenv("revision#") != NULL)
+		return simple_strtoul(getenv("revision#"), NULL, 10);
+	return 0;
+}

Do you get the revision from an environment and not from hardware ? There is a big chance to have the wrong revision number...

include/configs/apx4devkit.h line 115

Quoted 8 lines
include/configs/apx4devkit.h new file +8 -0
+/* Environment is in NAND */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_SECT_SIZE		(128 * 1024)
+#define CONFIG_ENV_SIZE		(128 * 1024)
+#define CONFIG_ENV_SIZE_REDUND		CONFIG_ENV_SIZE
+#define CONFIG_ENV_OFFSET		0x120000
+#define CONFIG_ENV_OFFSET_REDUND	\
+		(CONFIG_ENV_OFFSET + CONFIG_ENV_SECT_SIZE)

You set the environment in NAND, but you reserve only one sector for each of the two copies. If the single sector becomes bad, you lose the redundancy. Should you not have more as one sector for the environment ?

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#3 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

Hi Stefano,

Thanks for your review. Please see my comments below.

Quoted 9 lines · Stefano Babic
Quoted 5 lines · Veli-Pekka Peltola

Add initial support for Bluegiga APX4 CoM and development kit.

---

Hi Veli-Pekka,

Quoted 7 lines
Quoted 4 lines
  board/bluegiga/apx4devkit/Makefile     |   45 +++++++
  board/bluegiga/apx4devkit/apx4devkit.c |  204 ++++++++++++++++++++++++++++++++
  boards.cfg                             |    1 +
  include/configs/apx4devkit.h           |  176 +++++++++++++++++++++++++++

You should also update the MAINTAINERS file, adding your name as board maintainer.

Will be added to v2.

Quoted 9 lines
Quoted 5 lines
  4 files changed, 426 insertions(+), 0 deletions(-)

create mode 100644 board/bluegiga/apx4devkit/Makefile create mode 100644 board/bluegiga/apx4devkit/apx4devkit.c create mode 100644 include/configs/apx4devkit.h

your board configuration file does not set any SPL constant. I cannot understand how it works. Only u-boot.bin can be built, and this is only a part of the system. What about the first boot loader (SPL) ?

Currently we are using a different strategy to load U-Boot from NAND than M28EVK for example. We have very small U-Boot placed to first sector in NAND to load this bigger version of U-Boot.

But now I understand that our way is far away from optimal so this will be reworked in v2.

Quoted 2 lines

Please add also in the commit message which components (Ethernet, MMC, I2C, SPI,...) you support with your patch.

Will be added to v2 commit message.

Quoted 62 lines
Quoted 48 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +48 -0
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MUX_CONFIG_GENERIC	(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#define MUX_CONFIG_GPMI	(MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
+#define MUX_CONFIG_GPMI_12MA	(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+
+const iomux_cfg_t iomux_setup[] = {
+	/* GPMI NAND */
+	MX28_PAD_GPMI_D00__GPMI_D0 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D01__GPMI_D1 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D02__GPMI_D2 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D03__GPMI_D3 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D04__GPMI_D4 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D05__GPMI_D5 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D06__GPMI_D6 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_D07__GPMI_D7 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_ALE__GPMI_ALE | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_CLE__GPMI_CLE | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_CE0N__GPMI_CE0N | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_RDY0__GPMI_READY0 | MUX_CONFIG_GPMI,
+	MX28_PAD_GPMI_RDN__GPMI_RDN | MUX_CONFIG_GPMI_12MA,
+	MX28_PAD_GPMI_WRN__GPMI_WRN | MUX_CONFIG_GPMI_12MA,
+	MX28_PAD_GPMI_RESETN__GPMI_RESETN | MUX_CONFIG_GPMI_12MA,
+
+	/* MMC0 */
+	MX28_PAD_SSP0_DATA0__SSP0_D0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA1__SSP0_D1 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA2__SSP0_D2 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA3__SSP0_D3 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA4__SSP0_D4 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA5__SSP0_D5 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA6__SSP0_D6 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DATA7__SSP0_D7 | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_CMD__SSP0_CMD | MUX_CONFIG_GENERIC,
+	MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT |
+		(MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_NOPULL),
+	MX28_PAD_SSP0_SCK__SSP0_SCK |
+		(MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL),
+
+	/* FEC Ethernet */
+	MX28_PAD_ENET0_MDC__ENET0_MDC | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_MDIO__ENET0_MDIO | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RX_EN__ENET0_RX_EN | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TX_EN__ENET0_TX_EN | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RXD0__ENET0_RXD0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_RXD1__ENET0_RXD1 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_GENERIC,
+	MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_GENERIC,

board/bluegiga/apx4devkit/apx4devkit.c line 97

Quoted 10 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +10 -0
+	MX28_PAD_ENET_CLK__CLKCTRL_ENET | MUX_CONFIG_GENERIC,
+};
+
+/*
+ * Functions
+ */
+int board_early_init_f(void)
+{
+	/* Setup only pads needed by U-Boot that are not initialized before */
+	mxs_iomux_setup_multiple_pads(iomux_setup, ARRAY_SIZE(iomux_setup));

Mmmhh..die Pins are setup in the SPL code, checks in arch/arm/cpu/arm926ejs/mx28/spl_boot.c.

Quoted 1 line

You are adding a lot of pins that are maybe duplicated, are'nt they ?

After we switch to SPL, these will be moved/removed.

Quoted 4 lines
Quoted 4 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +4 -0
+#ifdef CONFIG_CMD_NET
+
+#define MII_PHY_CTRL2	0x1f
+
Quoted 8 lines

board/bluegiga/apx4devkit/apx4devkit.c line 139

Quoted 5 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +5 -0
+int fecmxc_mii_postcall(int phy)
+{
+	miiphy_write("FEC", 0, MII_PHY_CTRL2, 0x8180);
+	return 0;
+}

So you have only one ethernet interface - add also this info in your commit message.

Ok. I will also add a comment here why this is needed.

Quoted 6 lines

board/bluegiga/apx4devkit/apx4devkit.c line 172

Quoted 4 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +4 -0
+void imx_get_mac_from_fuse(char *mac)
+{
+	memset(mac, 0, 6);
+}

This is wrong, and surely you do not get the address from fuses.

What is correct way to get ethernet mac from environment instead of fuses? FEC driver seems to call imx_get_mac_from_fuse always. Should it be changed to use a new configuration option? Or should we try to read mac from fuses which are zeros and then fall back to environment?

Quoted 12 lines
Quoted 12 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +12 -0
+#ifdef CONFIG_SERIAL_TAG
+#define MXS_OCOTP_MAX_TIMEOUT	1000000
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+	struct mx28_ocotp_regs *ocotp_regs =
+		(struct mx28_ocotp_regs *)MXS_OCOTP_BASE;
+
+	serialnr->high = 0;
+	serialnr->low = 0;
+
+	writel(OCOTP_CTRL_RD_BANK_OPEN,&ocotp_regs->hw_ocotp_ctrl_set);
+
Quoted 8 lines

board/bluegiga/apx4devkit/apx4devkit.c line 191

Quoted 5 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +5 -0
+	if (mx28_wait_mask_clr(&ocotp_regs->hw_ocotp_ctrl_reg, OCOTP_CTRL_BUSY,
+				MXS_OCOTP_MAX_TIMEOUT)) {
+		printf("MXS: Can't get serial number from OCOTP\n");
+		return;
+	}

I think we can factorize some code with m28evk, and putting code to access OCOTP in a common directory, such as arch/arm/cpu/arm926ejs/mx28.

Sounds like a good idea. I will do that.

Quoted 9 lines

board/bluegiga/apx4devkit/apx4devkit.c line 203

Quoted 7 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +7 -0
+#ifdef CONFIG_REVISION_TAG
+u32 get_board_rev(void)
+{
+	if (getenv("revision#") != NULL)
+		return simple_strtoul(getenv("revision#"), NULL, 10);
+	return 0;
+}

Do you get the revision from an environment and not from hardware ?

Yes, that's the plan. In the history we have used revision number to include information about integrated modem, wifi and so on.

Quoted 1 line

There is a big chance to have the wrong revision number...

Yes but even with empty environment the board will still boot up.

Quoted 4 lines
Quoted 4 lines
include/configs/apx4devkit.h new file +4 -0
+/* Environment is in NAND */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_SECT_SIZE		(128 * 1024)
+#define CONFIG_ENV_SIZE		(128 * 1024)
Quoted 8 lines

include/configs/apx4devkit.h line 115

Quoted 4 lines
include/configs/apx4devkit.h new file +4 -0
+#define CONFIG_ENV_SIZE_REDUND		CONFIG_ENV_SIZE
+#define CONFIG_ENV_OFFSET		0x120000
+#define CONFIG_ENV_OFFSET_REDUND	\
+		(CONFIG_ENV_OFFSET + CONFIG_ENV_SECT_SIZE)

You set the environment in NAND, but you reserve only one sector for each of the two copies. If the single sector becomes bad, you lose the redundancy. Should you not have more as one sector for the environment ?

Statistically this has not been a problem so far. But I see the risk and I will increase environment size a little bit.

Quoted 2 lines

Best regards,
Stefano Babic

--
Veli-Pekka Peltola

#4 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

Quoted 4 lines · Veli-Pekka Peltola

But now I understand that our way is far away from optimal so this will be reworked in v2.

In this way you can also profit of the work already done in the SPL code.

Quoted 11 lines
Quoted 6 lines

board/bluegiga/apx4devkit/apx4devkit.c line 172

Quoted 4 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +4 -0
+void imx_get_mac_from_fuse(char *mac)
+{
+    memset(mac, 0, 6);
+}

This is wrong, and surely you do not get the address from fuses.

What is correct way to get ethernet mac from environment instead of fuses? FEC driver seems to call imx_get_mac_from_fuse always. Should it be changed to use a new configuration option? Or should we try to read mac from fuses which are zeros and then fall back to environment?

I have supposed that new Freescale's SOCs are always delivered with a valid MAC address in the fuses. Some IMX SOCs have no fuse at all, and the MAC address is only taken from the environment, such as the MX35.

I see here a couple of points. First at all, imx_get_mac_from_fuse should be factorized between your board and m28evk. Maybe we need some CONFIG_ to add the vendor part, but reading from fuse itself can be shared code. and if the values read are all zeroes, we have the fallback to the environment ethaddr variable.

Quoted 9 lines
Quoted 2 lines

Do you get the revision from an environment and not from hardware ?

Yes, that's the plan. In the history we have used revision number to include information about integrated modem, wifi and so on.

Quoted 1 line

There is a big chance to have the wrong revision number...

Yes but even with empty environment the board will still boot up.

Of course, until you do not do something different in code based on the revision number, such as setting the MUX differently or putting the gpio in a different mode...if you only print the revision number, there is no issue.

Quoted 5 lines
Quoted 3 lines

You set the environment in NAND, but you reserve only one sector for each of the two copies. If the single sector becomes bad, you lose the redundancy. Should you not have more as one sector for the environment ?

Statistically this has not been a problem so far.

There is no rule - nothing happens until the sector becomes bad. Then the redundancy feature is not available anymore. It depends on you to check the risk and decide to increase the size or not.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#5 lore raw

PATCH 1/1 add initial support for bluegiga apx4devkit

Quoted 7 lines · Stefano Babic
Quoted 7 lines
Quoted 6 lines

board/bluegiga/apx4devkit/apx4devkit.c line 172

Quoted 4 lines
board/bluegiga/apx4devkit/apx4devkit.c new file +4 -0
+void imx_get_mac_from_fuse(char *mac)
+{
+    memset(mac, 0, 6);
+}

This is wrong, and surely you do not get the address from fuses.

Quoted 8 lines
Quoted 4 lines

What is correct way to get ethernet mac from environment instead of fuses? FEC driver seems to call imx_get_mac_from_fuse always. Should it be changed to use a new configuration option? Or should we try to read mac from fuses which are zeros and then fall back to environment?

I have supposed that new Freescale's SOCs are always delivered with a valid MAC address in the fuses. Some IMX SOCs have no fuse at all, and the MAC address is only taken from the environment, such as the MX35.

At least our i.MX28 SoCs doesn't have any fuses preprogrammed. MX28EVK seems to have CUST0 and CUST1 preprogrammed.

Quoted 5 lines

I see here a couple of points. First at all, imx_get_mac_from_fuse should be factorized between your board and m28evk. Maybe we need some CONFIG_ to add the vendor part, but reading from fuse itself can be shared code. and if the values read are all zeroes, we have the fallback to the environment ethaddr variable.

I will try to do some factorization.

Our product is more like an OEM thing so we try to avoid programming any fuses as our customers might want to do that with their own mac address.

--
Veli-Pekka Peltola