| Message ID | 1395869509-14263-2-git-send-email-eric@eukrea.com |
|---|---|
| State | Superseded |
| Delegated to: | Stefano Babic |
| Headers | show |
On Wed, Mar 26, 2014 at 6:31 PM, Eric Bénard <eric@eukrea.com> wrote: > this board is produced by Embest/Element 14 and is based on i.MX6 Dual > The following features are tested : > - UART2 (console) > - eMMC > - uSDCard > - Ethernet > - USB Host (through 2 ports hub) > - HDMI output > - I2C 1/2 > - SPI NOR Flash > > Boot on SPI NOR and through USB loader are tested. > > For more informations on this board : > http://www.embest-tech.com/shop/star/marsboard.html > > As this board shares a lot with RiOTboard, both boards are supported by > the same code base which is renamed embest/mx6boards > > Signed-off-by: Eric Bénard <eric@eukrea.com> I understand both boards share a lot of code but I think the set of ifdef makes harder for people to understand the board code. Personally I prefer v1.
On Wed, Mar 26, 2014 at 11:21 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > I understand both boards share a lot of code but I think the set of > ifdef makes harder for people to understand the board code. Personally > I prefer v1. Me too. I also think the ifdefs may easily cause confusion. For example: if someone sends a patch for Riotboard, he/she may break Marsboard without knowing. Usually the developer has only one board and is not able to test on both boards. Regards, Fabio Estevam
Dear Otavio, In message <CAP9ODKrj9as+R7gb-STCnqpoSGFdKg_diJ=P+Vg6hTOka5dfMw@mail.gmail.com> you wrote: > > I understand both boards share a lot of code but I think the set of > ifdef makes harder for people to understand the board code. Personally > I prefer v1. Duplication of so much code is really bad. It's always been a maintenance nightmare. The new version is much better. [Of course there are also ways to avoid ifdefs, but there are not so many here, and they are actually pretty easy to follow.] Best regards, Wolfgang Denk
Dear Fabio Estevam, In message <CAOMZO5D2N1Zvo5ogEAM1_EwT-0KKamzGvRfPEekh5zymQkLrhw@mail.gmail.com> you wrote: > > Me too. I also think the ifdefs may easily cause confusion. So you suggest we remove all conditional code and use duplication everywhere? You must be joking... > For example: if someone sends a patch for Riotboard, he/she may break > Marsboard without knowing. > > Usually the developer has only one board and is not able to test on both boards. Yes, of course. If someone touches common code he make breake things for boards he did not test. That has always been the case, everywehre. But that has never been a reason to duplicate code, or to accept code duplication. On contrary, we permanently struggle to reduce such duplication. Otherwise we would have to strictly split ARM and PowerPC code, and all other architectures. We would need code copies for each SoC. Actually each board would need his own version of the whole U-Boot code. Sorry, but this is just bizarre... Best regards, Wolfgang Denk
adding my 0.02$ to this discussion... On 26.03.2014 22:31, Eric Bénard wrote: > this board is produced by Embest/Element 14 and is based on i.MX6 Dual > The following features are tested : > - UART2 (console) > - eMMC > - uSDCard > - Ethernet > - USB Host (through 2 ports hub) > - HDMI output > - I2C 1/2 > - SPI NOR Flash > > Boot on SPI NOR and through USB loader are tested. > > For more informations on this board : > http://www.embest-tech.com/shop/star/marsboard.html > > As this board shares a lot with RiOTboard, both boards are supported by > the same code base which is renamed embest/mx6boards > > Signed-off-by: Eric Bénard <eric@eukrea.com> > --- > board/embest/{riotboard => mx6boards}/Makefile | 2 +- > .../riotboard.c => mx6boards/mx6boards.c} | 49 +++++++++++++++++- > boards.cfg | 3 +- > include/configs/{riotboard.h => embestmx6boards.h} | 58 ++++++++++++++++++++++ > 4 files changed, 108 insertions(+), 4 deletions(-) > rename board/embest/{riotboard => mx6boards}/Makefile (87%) > rename board/embest/{riotboard/riotboard.c => mx6boards/mx6boards.c} (91%) > rename include/configs/{riotboard.h => embestmx6boards.h} (84%) > > diff --git a/board/embest/riotboard/Makefile b/board/embest/mx6boards/Makefile > similarity index 87% > rename from board/embest/riotboard/Makefile > rename to board/embest/mx6boards/Makefile > index 5f978c0..467fb50 100644 > --- a/board/embest/riotboard/Makefile > +++ b/board/embest/mx6boards/Makefile > @@ -6,4 +6,4 @@ > # SPDX-License-Identifier: GPL-2.0+ > # > > -obj-y := riotboard.o > +obj-y := mx6boards.o > diff --git a/board/embest/riotboard/riotboard.c b/board/embest/mx6boards/mx6boards.c > similarity index 91% > rename from board/embest/riotboard/riotboard.c > rename to board/embest/mx6boards/mx6boards.c > index 15eaa1e..374c2ec 100644 > --- a/board/embest/riotboard/riotboard.c > +++ b/board/embest/mx6boards/mx6boards.c > @@ -60,6 +60,9 @@ DECLARE_GLOBAL_DATA_PTR; > PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ > PAD_CTL_ODE | PAD_CTL_SRE_FAST) > > +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ > + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) > + > int dram_init(void) > { > gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); > @@ -153,8 +156,10 @@ iomux_v3_cfg_t const usdhc3_pads[] = { > MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), > MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), > MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), > +#ifdef CONFIG_RIOTBOARD > MX6_PAD_SD3_DAT4__GPIO7_IO01 | MUX_PAD_CTRL(NO_PAD_CTRL), /* WP */ > MX6_PAD_SD3_DAT5__GPIO7_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ > +#endif > }; > > iomux_v3_cfg_t const usdhc4_pads[] = { > @@ -187,7 +192,12 @@ int board_mmc_getcd(struct mmc *mmc) > ret = !gpio_get_value(USDHC2_CD_GPIO); > break; > case USDHC3_BASE_ADDR: > +#ifdef CONFIG_RIOTBOARD > ret = !gpio_get_value(USDHC3_CD_GPIO); > +#endif > +#ifdef CONFIG_MARSBOARD > + ret = 1; /* eMMC/uSDHC3 is always present */ > +#endif Yes, I agree. #ifdef's are ugly. But code duplication is also a problem as Wolfgang has mentioned. Isn't there a way to detect the board type at runtime somehow (via CPU type or GPIO input, ...)? And then dynamically configure the board either for "RiOT" or "MarS"? This would make the code a bit more complex of course. But there would be no #ifdef's and no code duplication. And you would only have to maintain one U-Boot binary / version for both boards. So, what do you think? Is this possible? Thanks, Stefan
Hi Stefan, Le Thu, 27 Mar 2014 08:05:10 +0100, Stefan Roese <sr@denx.de> a écrit : > Yes, I agree. #ifdef's are ugly. But code duplication is also a problem > as Wolfgang has mentioned. > > Isn't there a way to detect the board type at runtime somehow (via CPU > type or GPIO input, ...)? And then dynamically configure the board > either for "RiOT" or "MarS"? This would make the code a bit more complex > of course. But there would be no #ifdef's and no code duplication. And > you would only have to maintain one U-Boot binary / version for both boards. > > So, what do you think? Is this possible? > Thanks for the idea, that's possible by detecting i.MX6Solo vs i.MX6Dual. I'll try to implement that. Eric
On Thu, Mar 27, 2014 at 2:36 AM, Wolfgang Denk <wd@denx.de> wrote: > Dear Fabio Estevam, > > In message <CAOMZO5D2N1Zvo5ogEAM1_EwT-0KKamzGvRfPEekh5zymQkLrhw@mail.gmail.com> you wrote: >> >> Me too. I also think the ifdefs may easily cause confusion. > > So you suggest we remove all conditional code and use duplication > everywhere? You must be joking... Not everywhere. We are just talking about board files here, which are coming obsolete these days with device tree... > >> For example: if someone sends a patch for Riotboard, he/she may break >> Marsboard without knowing. >> >> Usually the developer has only one board and is not able to test on both boards. > > Yes, of course. If someone touches common code he make breake things > for boards he did not test. That has always been the case, So in theory yes, we could have a single board file for all the mx6 boards out there and make it full of ifdefs all over it to handle all the hardware variations. Not so good for the users though if they want to make a simple change and then they are forced to read all the schematics of several unrelated boards. > everywehre. But that has never been a reason to duplicate code, > or to accept code duplication. On contrary, we permanently struggle > to reduce such duplication. > > Otherwise we would have to strictly split ARM and PowerPC code, and > all other architectures. We would need code copies for each SoC. > Actually each board would need his own version of the whole U-Boot > code. Sorry, but this is just bizarre... Looks like you are extrapolating too much here. Our discussion is only about board files, not common driver code or architectural code. Regards, Fabio Estevam
Em 27/03/2014 09:44, "Fabio Estevam" <festevam@gmail.com> escreveu: > > On Thu, Mar 27, 2014 at 2:36 AM, Wolfgang Denk <wd@denx.de> wrote: > > Dear Fabio Estevam, > > > > In message < CAOMZO5D2N1Zvo5ogEAM1_EwT-0KKamzGvRfPEekh5zymQkLrhw@mail.gmail.com> you wrote: > >> > >> Me too. I also think the ifdefs may easily cause confusion. > > > > So you suggest we remove all conditional code and use duplication > > everywhere? You must be joking... > > Not everywhere. We are just talking about board files here, which are > coming obsolete these days with device tree... And this does work, as can be seen in Barebox which has it working for quite some time. You can see equivalent patch in http://lists.infradead.org/pipermail/barebox/2014-March/018408.html It seems U-Boot is behind ! Regards,
Hi Fabio, Le Thu, 27 Mar 2014 09:44:02 -0300, Fabio Estevam <festevam@gmail.com> a écrit : > So in theory yes, we could have a single board file for all the mx6 > boards out there and make it full of ifdefs all over it to handle all > the hardware variations. > here we talk of 2 boards from the same manufacturer which are very similar. What Wolfgang asked is very relevant in that case. Eric
Hi Otavio, Le Thu, 27 Mar 2014 09:50:10 -0300, Otavio Salvador <otavio@ossystems.com.br> a écrit : > And this does work, as can be seen in Barebox which has it working for > quite some time. > > You can see equivalent patch in > > http://lists.infradead.org/pipermail/barebox/2014-March/018408.html > > It seems U-Boot is behind ! > I don't know what you are trying to demonstrate here but in the present case, I'll also submit a v2 of these patches on barebox'ML to factorize the code and the device tree. Eric
On Thu, Mar 27, 2014 at 12:59 PM, Eric Bénard <eric@eukrea.com> wrote: > Hi Fabio, > > Le Thu, 27 Mar 2014 09:44:02 -0300, > Fabio Estevam <festevam@gmail.com> a écrit : >> So in theory yes, we could have a single board file for all the mx6 >> boards out there and make it full of ifdefs all over it to handle all >> the hardware variations. >> > here we talk of 2 boards from the same manufacturer which are very > similar. What Wolfgang asked is very relevant in that case. Agreed now. I wasn't aware they were from the same manufacturer. Regards, Fabio Estevam
Dear Fabio Estevam, In message <CAOMZO5BF0e20eRs4keLH+jkGkQuTGn5Eci-W_9qTRnDBCdk9Dw@mail.gmail.com> you wrote: > > So in theory yes, we could have a single board file for all the mx6 > boards out there and make it full of ifdefs all over it to handle all > the hardware variations. Well, actually I do think there is some common code for iMX6 that could / should be factored out. And that does not even need any ifdefs. > > Otherwise we would have to strictly split ARM and PowerPC code, and > > all other architectures. We would need code copies for each SoC. > > Actually each board would need his own version of the whole U-Boot > > code. Sorry, but this is just bizarre... > > Looks like you are extrapolating too much here. Our discussion is only Not more than you, just in the other direction ;-) Best regards, Wolfgang Denk
diff --git a/board/embest/riotboard/Makefile b/board/embest/mx6boards/Makefile similarity index 87% rename from board/embest/riotboard/Makefile rename to board/embest/mx6boards/Makefile index 5f978c0..467fb50 100644 --- a/board/embest/riotboard/Makefile +++ b/board/embest/mx6boards/Makefile @@ -6,4 +6,4 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y := riotboard.o +obj-y := mx6boards.o diff --git a/board/embest/riotboard/riotboard.c b/board/embest/mx6boards/mx6boards.c similarity index 91% rename from board/embest/riotboard/riotboard.c rename to board/embest/mx6boards/mx6boards.c index 15eaa1e..374c2ec 100644 --- a/board/embest/riotboard/riotboard.c +++ b/board/embest/mx6boards/mx6boards.c @@ -60,6 +60,9 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ PAD_CTL_ODE | PAD_CTL_SRE_FAST) +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + int dram_init(void) { gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); @@ -153,8 +156,10 @@ iomux_v3_cfg_t const usdhc3_pads[] = { MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), +#ifdef CONFIG_RIOTBOARD MX6_PAD_SD3_DAT4__GPIO7_IO01 | MUX_PAD_CTRL(NO_PAD_CTRL), /* WP */ MX6_PAD_SD3_DAT5__GPIO7_IO00 | MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ +#endif }; iomux_v3_cfg_t const usdhc4_pads[] = { @@ -187,7 +192,12 @@ int board_mmc_getcd(struct mmc *mmc) ret = !gpio_get_value(USDHC2_CD_GPIO); break; case USDHC3_BASE_ADDR: +#ifdef CONFIG_RIOTBOARD ret = !gpio_get_value(USDHC3_CD_GPIO); +#endif +#ifdef CONFIG_MARSBOARD + ret = 1; /* eMMC/uSDHC3 is always present */ +#endif break; case USDHC4_BASE_ADDR: ret = 1; /* eMMC/uSDHC4 is always present */ @@ -205,9 +215,13 @@ int board_mmc_init(bd_t *bis) /* * According to the board_mmc_init() the following map is done: * (U-boot device node) (Physical Port) + * ** RiOTboard : * mmc0 SDCard slot (bottom) * mmc1 uSDCard slot (top) * mmc2 eMMC + * ** MarSBoard : + * mmc0 uSDCard slot (bottom) + * mmc1 eMMC */ for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) { switch (i) { @@ -224,6 +238,11 @@ int board_mmc_init(bd_t *bis) gpio_direction_input(USDHC3_CD_GPIO); usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK); usdhc_cfg[1].max_bus_width = 4; +#ifdef CONFIG_MARSBOARD + gpio_direction_output(IMX_GPIO_NR(7, 8) , 0); + udelay(250); + gpio_set_value(IMX_GPIO_NR(7, 8), 1); +#endif break; case 2: imx_iomux_v3_setup_multiple_pads( @@ -248,6 +267,20 @@ int board_mmc_init(bd_t *bis) } #endif +#ifdef CONFIG_MXC_SPI +iomux_v3_cfg_t const ecspi1_pads[] = { + MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_EB2__GPIO2_IO30 | MUX_PAD_CTRL(NO_PAD_CTRL), +}; + +static void setup_spi(void) +{ + imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads)); +} +#endif + struct i2c_pads_info i2c_pad_info1 = { .scl = { .i2c_mode = MX6_PAD_CSI0_DAT9__I2C1_SCL | MUX_PAD_CTRL(I2C_PAD_CTRL), @@ -458,21 +491,28 @@ int board_init(void) { /* address of boot parameters */ gd->bd->bi_boot_params = PHYS_SDRAM + 0x100; - /* i2c1 : PMIC, Audio codec */ + /* i2c1 : PMIC, Audio codec on RiOT, Expansion connector on MarS */ setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info1); /* i2c2 : HDMI EDID */ setup_i2c(1, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info2); /* i2c3 : LVDS, Expansion connector */ setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, &i2c_pad_info3); - +#ifdef CONFIG_MXC_SPI + setup_spi(); +#endif return 0; } #ifdef CONFIG_CMD_BMODE static const struct boot_mode board_boot_modes[] = { {"sd2", MAKE_CFGVAL(0x40, 0x28, 0x00, 0x00)}, +#ifdef CONFIG_RIOTBOARD {"sd3", MAKE_CFGVAL(0x40, 0x30, 0x00, 0x00)}, {"emmc", MAKE_CFGVAL(0x40, 0x38, 0x00, 0x00)}, +#endif +#ifdef CONFIG_MARSBOARD + {"emmc", MAKE_CFGVAL(0x40, 0x30, 0x00, 0x00)}, +#endif {NULL, 0}, }; #endif @@ -488,6 +528,11 @@ int board_late_init(void) int checkboard(void) { +#ifdef CONFIG_MARSBOARD + puts("Board: MarSBoard\n"); +#endif +#ifdef CONFIG_RIOTBOARD puts("Board: RIoTboard\n"); +#endif return 0; } diff --git a/boards.cfg b/boards.cfg index a29417c..d211cda 100644 --- a/boards.cfg +++ b/boards.cfg @@ -323,7 +323,8 @@ Active arm armv7 mx6 freescale mx6sabresd Active arm armv7 mx6 freescale mx6sabresd mx6qsabresd mx6sabresd:IMX_CONFIG=board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg,MX6Q Fabio Estevam <fabio.estevam@freescale.com> Active arm armv7 mx6 freescale mx6slevk mx6slevk mx6slevk:IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL Fabio Estevam <fabio.estevam@freescale.com> Active arm armv7 mx6 solidrun hummingboard hummingboard_solo hummingboard:IMX_CONFIG=board/solidrun/hummingboard/solo.cfg,MX6S,DDR_MB=512 Jon Nettleton <jon.nettleton@gmail.com> -Active arm armv7 mx6 embest riotboard riotboard riotboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024 Eric Bénard <eric@eukrea.com> +Active arm armv7 mx6 embest mx6boards riotboard embestmx6boards:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024,RIOTBOARD Eric Bénard <eric@eukrea.com> +Active arm armv7 mx6 embest mx6boards marsboard embestmx6boards:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,MARSBOARD Eric Bénard <eric@eukrea.com> Active arm armv7 omap3 - overo omap3_overo - Steve Sakoman <sakoman@gmail.com> Active arm armv7 omap3 - pandora omap3_pandora - Grazvydas Ignotas <notasas@gmail.com> Active arm armv7 omap3 8dtech eco5pk eco5pk - Raphael Assenat <raph@8d.com> diff --git a/include/configs/riotboard.h b/include/configs/embestmx6boards.h similarity index 84% rename from include/configs/riotboard.h rename to include/configs/embestmx6boards.h index 747ec79..07ea2d2 100644 --- a/include/configs/riotboard.h +++ b/include/configs/embestmx6boards.h @@ -22,10 +22,19 @@ #define CONFIG_MXC_UART_BASE UART2_BASE #define CONFIG_CONSOLE_DEV "ttymxc0" #define CONFIG_MMCROOT "/dev/mmcblk1p2" +#ifdef CONFIG_RIOTBOARD #define CONFIG_DEFAULT_FDT_FILE "imx6s-riotboard.dtb" +#elif defined CONFIG_MARSBOARD +#define CONFIG_DEFAULT_FDT_FILE "imx6q-marsboard.dtb" +#else +#error Please define a board (RIOTBOARD or MARSBOARD) +#endif + #define PHYS_SDRAM_SIZE (1u * 1024 * 1024 * 1024) +#ifdef CONFIG_RIOTBOARD #define CONFIG_SUPPORT_EMMC_BOOT /* eMMC specific */ +#endif #define CONFIG_MX6 @@ -96,6 +105,19 @@ #define CONFIG_PHYLIB #define CONFIG_PHY_ATHEROS +#ifdef CONFIG_MARSBOARD +#define CONFIG_CMD_SF +#ifdef CONFIG_CMD_SF +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_SST +#define CONFIG_MXC_SPI +#define CONFIG_SF_DEFAULT_BUS 0 +#define CONFIG_SF_DEFAULT_CS (0 | (IMX_GPIO_NR(2, 30) << 8)) +#define CONFIG_SF_DEFAULT_SPEED 20000000 +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 +#endif +#endif + /* allow to overwrite serial and ethaddr */ #define CONFIG_ENV_OVERWRITE #define CONFIG_CONS_INDEX 1 @@ -134,6 +156,24 @@ #define EMMC_ENV "" #endif +#ifdef CONFIG_CMD_SF +#define SF_ENV \ + "update_spi_firmware=" \ + "if test ${ip_dyn} = yes; then " \ + "setenv get_cmd dhcp; " \ + "else " \ + "setenv get_cmd tftp; " \ + "fi; " \ + "if ${get_cmd} ${update_spi_firmware_filename}; then " \ + "if sf probe; then " \ + "sf erase 0 0xc0000; " \ + "sf write ${loadaddr} 0x400 ${filesize}; " \ + "fi; " \ + "fi\0" +#else +#define SF_ENV "" +#endif + #define CONFIG_EXTRA_ENV_SETTINGS \ "script=boot.scr\0" \ "image=zImage\0" \ @@ -161,6 +201,7 @@ "fi; " \ "fi\0" \ EMMC_ENV \ + SF_ENV \ "mmcargs=setenv bootargs console=${console},${baudrate} " \ "root=${mmcroot}\0" \ "loadbootscript=" \ @@ -263,10 +304,22 @@ #define CONFIG_ENV_SIZE (8 * 1024) +#ifdef CONFIG_RIOTBOARD #define CONFIG_ENV_IS_IN_MMC +#endif +#ifdef CONFIG_MARSBOARD +#define CONFIG_ENV_IS_IN_SPI_FLASH +#endif #if defined(CONFIG_ENV_IS_IN_MMC) #define CONFIG_ENV_OFFSET (6 * 64 * 1024) +#elif defined(CONFIG_ENV_IS_IN_SPI_FLASH) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_ENV_SECT_SIZE (8 * 1024) +#define CONFIG_ENV_SPI_BUS CONFIG_SF_DEFAULT_BUS +#define CONFIG_ENV_SPI_CS CONFIG_SF_DEFAULT_CS +#define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE +#define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED #endif #define CONFIG_OF_LIBFDT @@ -275,7 +328,12 @@ #define CONFIG_CMD_CACHE #endif +#ifdef CONFIG_RIOTBOARD #define CONFIG_SYS_FSL_USDHC_NUM 3 +#elif defined(CONFIG_MARSBOARD) +#define CONFIG_SYS_FSL_USDHC_NUM 2 +#endif + #if defined(CONFIG_ENV_IS_IN_MMC) #define CONFIG_SYS_MMC_ENV_DEV 2 /* SDHC4 */ #endif
this board is produced by Embest/Element 14 and is based on i.MX6 Dual The following features are tested : - UART2 (console) - eMMC - uSDCard - Ethernet - USB Host (through 2 ports hub) - HDMI output - I2C 1/2 - SPI NOR Flash Boot on SPI NOR and through USB loader are tested. For more informations on this board : http://www.embest-tech.com/shop/star/marsboard.html As this board shares a lot with RiOTboard, both boards are supported by the same code base which is renamed embest/mx6boards Signed-off-by: Eric Bénard <eric@eukrea.com> --- board/embest/{riotboard => mx6boards}/Makefile | 2 +- .../riotboard.c => mx6boards/mx6boards.c} | 49 +++++++++++++++++- boards.cfg | 3 +- include/configs/{riotboard.h => embestmx6boards.h} | 58 ++++++++++++++++++++++ 4 files changed, 108 insertions(+), 4 deletions(-) rename board/embest/{riotboard => mx6boards}/Makefile (87%) rename board/embest/{riotboard/riotboard.c => mx6boards/mx6boards.c} (91%) rename include/configs/{riotboard.h => embestmx6boards.h} (84%)