Re: [U-Boot] [PATCH 21/21] sunxi: emac: Remove non device-model code
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > All sunxi boards now use the device-model, so remove the non device-model > code. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/21] sunxi: Move all boards to the device-model
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig > index 3831d3b..3997637 100644 > --- a/board/sunxi/Kconfig > +++ b/board/sunxi/Kconfig > @@ -529,4 +529,16 @@ config GMAC_TX_DELAY > ---help--- > Set the GMAC Transmit Clock Delay Chain value. > > +config NET > + default y > + > +config NETDEVICES > + default y > + > +config DM_ETH > + default y > + > +config DM_SERIAL > + default y None of these have a more appropriate home than sunxi/Kconfig? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/21] sunxi: dts: Add a CONFIG_DEFAULT_DEVICE_TREE setting to all sunxi boards
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > This is a preparation patch for switching all sunxi boards over to using > the device model. > > Note that rather then defining both CONFIG_DEFAULT_DEVICE_TREE (for u-boot) > and CONFIG_FDTFILE (for the kernel), this commit simply replaces all > CONFIG_FDTFILE defconfig settings with CONFIG_DEFAULT_DEVICE_TREE and > uses CONFIG_DEFAULT_DEVICE_TREE for setting the default fdtfile env value > in sunxi-common.h . > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/21] sunxi: dts: Add minimal dts files for board which lack a dts sofar
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > u-boot has support for a number of boards for which a dts file still needs > to be written, add minimal dts files for these boards so that we can switch > them over to device-model / fdt. Can these minimal things not be submitted to mainline regardless? I mean they are factually accurate descriptions of the h/w so far as they go, so why not? > + * [...] for u-boot only These aren't really "for u-boot only", they are still generic facts about the board, just perhaps a bit incomplete. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/21] sunxi: dts: Add dts files which have been submitted but not yet merged upstream
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > We need dts files for all boards we support, so bring in a few unmerged ones, > these will be replaced with the upstream merged versions the next time we > sync dts files. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/21] sunxi: dts: Sync all dts files with upstream kernel
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > Bring all the sunxi dts files (and update existing ones) from > mripard/sunxi/dt-for-4.1 A specific SHA1 might be a useful reference for whomever does the next update and/or the specific runes used to update (cp sun*.dts ... ?) > (which will be merged into upstream master any > day now). This is necessary so that we can move all sunxi boards over to > the device model. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/21] sunxi: emac: port to phylib
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > This is a preparation-patch for adding device-model support to the emac > driver. > > Signed-off-by: Hans de Goede Think I saw this and the following few patches in a separate v2, so I've ignored them here. Let me know if I got things the wrong way around. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/21] sunxi: gmac: Move sunxi_gmac_initialize proto out of netdev.h
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > netdev.h should not be included in device-model enabled builds (doing so > causes compiler warnings about struct eth_device not being declared), but > we do use sunxi_gmac_initialize in the device-model case, so move it out of > netdev.h . Worth keeping the emac one alongside? Regardless: > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/21] sunxi: gpio: Build sunxi_name_to_gpio_bank for device-model code too
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > When doing a device-model enabled build we still need sunxi_name_to_gpio_bank > (for now) for the mmc pinmux code in board/sunxi/board.c, so build it for > device-model enabled builds too. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/21] sunxi: gpio: Add compatible strings for all supported SoCs
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > We want to use device-model/fdt with other model SoCs too, so add > compatible strings for the other SoCs to the dm sunxi gpio code. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/21] sunxi: soft-i2c: Fix gpio handling to work with the device-model
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > i2c_init_board() gets called before the device-model (gpio) code is > initialized, so move the setup of the soft-i2c pins out of i2c_init_board() > and into board_init(), at which time the device-model setup has been done. > > Also add proper error checking and properly request the gpios as that is > mandatory with the device-model. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/21] sunxi: display: Fix gpio handling to work with the device-model
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > The device-model gpio functions may return another value then -1 as error, > make the sunxi display code properly handle this. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/21] sunxi: usbc: Fix vbus gpio handling to work with the device-model
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > The device-model gpio functions may return another value then -1 as error, > make the sunxi usbc properly handle this. > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/21] sunxi: mmc: Fix card-detect gpio handling to work with the device-model
On Fri, 2015-04-24 at 17:23 -0600, Simon Glass wrote: > HI Hans, > > On 24 April 2015 at 07:48, Hans de Goede wrote: > > The device-model gpio functions may return another value then -1 as error, > > make the sunxi mmc code properly handle this. > > FYI I tend to call it 'drive model' rather than 'device model'. It ^r? > might be good to change your commit messages it to avoid confusion. > > Reviewed-by: Simon Glass Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/21] sunxi: Do not build i2c support when we've no i2c controllers
On Fri, 2015-04-24 at 15:48 +0200, Hans de Goede wrote: > This fixes the following errors being printed during boot: > > Error, wrong i2c adapter 0 max 0 possible > Error, wrong i2c adapter 0 max 0 possible > > Signed-off-by: Hans de Goede Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] sunxi: emac: Add driver model support
On Sat, 2015-04-25 at 13:51 +0200, Hans de Goede wrote: > Hi All, > > Here is v2 of my patch series to add driver model support to the sunxi > emac driver. > > Changes since v1: > -Add a patch to rename DMA_CPU_TRRESHOLD to EMAC_RX_BUFSIZE. > > Please review. All LGTM: Acked-by: Ian Campbell ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dm: i2c-gpio: Remove redundant dm_gpio_set_value() call
dm_gpio_set_dir_flags() will also set gpio output value when switching to
gpio output. So it's not necessary to call dm_gpio_set_value() after
dm_gpio_set_dir_flags() call.
Signed-off-by: Axel Lin
---
drivers/i2c/i2c-gpio.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index ed899d4..a8b83c5 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -41,18 +41,19 @@ static int i2c_gpio_sda_get(struct gpio_desc *sda)
static void i2c_gpio_sda_set(struct gpio_desc *sda, int bit)
{
- if (bit) {
+ if (bit)
dm_gpio_set_dir_flags(sda, GPIOD_IS_IN);
- } else {
+ else
dm_gpio_set_dir_flags(sda, GPIOD_IS_OUT);
- dm_gpio_set_value(sda, 0);
- }
}
static void i2c_gpio_scl_set(struct gpio_desc *scl, int bit)
{
- dm_gpio_set_dir_flags(scl, GPIOD_IS_OUT);
- dm_gpio_set_value(scl, bit);
+ ulong flags = GPIOD_IS_OUT;
+
+ if (bit)
+ flags |= GPIOD_IS_OUT_ACTIVE;
+ dm_gpio_set_dir_flags(scl, flags);
}
static void i2c_gpio_write_bit(struct gpio_desc *scl, struct gpio_desc *sda,
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] gpio: stm32_gpio: Use clrsetbits_le32() at appropriate places
Use clrsetbits_le32() to replace clrbits_le32() + setbits_le32(). Signed-off-by: Axel Lin --- v2: Conver one more place (updating &gpio_regs->afr[dsc->pin >> 3] register) to use clrsetbits_le32(). drivers/gpio/stm32_gpio.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c index d3497e9..6d6fdb0 100644 --- a/drivers/gpio/stm32_gpio.c +++ b/drivers/gpio/stm32_gpio.c @@ -69,22 +69,14 @@ int stm32_gpio_config(const struct stm32_gpio_dsc *dsc, setbits_le32(&STM32_RCC->ahb1enr, 1 << dsc->port); i = (dsc->pin & 0x07) * 4; - clrbits_le32(&gpio_regs->afr[dsc->pin >> 3], (0xF << i)); - setbits_le32(&gpio_regs->afr[dsc->pin >> 3], ctl->af << i); + clrsetbits_le32(&gpio_regs->afr[dsc->pin >> 3], 0xF << i, ctl->af << i); i = dsc->pin * 2; - clrbits_le32(&gpio_regs->moder, (0x3 << i)); - setbits_le32(&gpio_regs->moder, ctl->mode << i); - - clrbits_le32(&gpio_regs->otyper, (0x3 << i)); - setbits_le32(&gpio_regs->otyper, ctl->otype << i); - - clrbits_le32(&gpio_regs->ospeedr, (0x3 << i)); - setbits_le32(&gpio_regs->ospeedr, ctl->speed << i); - - clrbits_le32(&gpio_regs->pupdr, (0x3 << i)); - setbits_le32(&gpio_regs->pupdr, ctl->pupd << i); + clrsetbits_le32(&gpio_regs->moder, 0x3 << i, ctl->mode << i); + clrsetbits_le32(&gpio_regs->otyper, 0x3 << i, ctl->otype << i); + clrsetbits_le32(&gpio_regs->ospeedr, 0x3 << i, ctl->speed << i); + clrsetbits_le32(&gpio_regs->pupdr, 0x3 << i, ctl->pupd << i); rv = 0; out: -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] README: fix typo in 'currently'
On Sat, Apr 25, 2015 at 06:53:10PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/6] mx6cuboxi: Introduce multi-SoC support
On Sat, Apr 25, 2015 at 06:47:18PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite, > mx6dual and mx6quad. Add support for the different SoC/memory sizes > combinations. > > DDR initialization values were extracted from Solid-run internal U-boot. > > Tested on a CuBox-i4Pro, HummingBoard-i2eX and HummingBoard-i1. > > Signed-off-by: Rabeeh Khoury > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/6] mx6cuboxi: Differentiate Cubox-i and Hummingboard
On Sat, Apr 25, 2015 at 06:47:19PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Introduce is_hummingboard() function that reads GPIOs that can distinguish > between Cubox-i and Hummingboard. > > Print the board name accordingly. > > Based on a patch from Rabeeh Khoury. > > Signed-off-by: Rabeeh Khoury > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/6] mx6cuboxi: Prepare for multi SoC support
On Sat, Apr 25, 2015 at 06:47:17PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite, > mx6dual and mx6quad. > > Use IOMUX_PADS() macro in order to prepare for the multi-SoC support. > Also pass 'MX6QDL' in the defconfig to indicate it. > > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/6] mx6cuboxi: Fix the defconfig name
On Sat, Apr 25, 2015 at 06:47:16PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > The correct name of the defconfig file is 'mx6cuboxi_defconfig'. > > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 5/6] mx6cuboxi: Use more standard namings for fdt variables
On Sat, Apr 25, 2015 at 06:47:20PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > README file suggests to use 'fdtfile' for the dtb file name and > 'fdt_addr_r' for the dtb address in RAM, so do as suggested. > > Signed-off-by: Fabio Estevam Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/6] mx6cuboxi: Load the correct 'fdtfile' variable
On Sat, Apr 25, 2015 at 06:47:21PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Instead of hardcoding the 'fdtfile' variable, let's detect the SoC and > board variant on the fly and change the dtb name. > > Based on the scheme done on am335x board. > > Signed-off-by: Fabio Estevam Thanks for reworking this! Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/6] mx6cuboxi: Load the correct 'fdtfile' variable
On 2015-04-25, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Instead of hardcoding the 'fdtfile' variable, let's detect the SoC and
> board variant on the fly and change the dtb name.
>
> Based on the scheme done on am335x board.
>
> Signed-off-by: Fabio Estevam
Tested-By: Vagrant Cascadian
> ---
> Changes since v4:
> - None
>
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 25 +
> include/configs/mx6cuboxi.h | 19 ---
> 2 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 83410b2..e06186e 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -212,6 +212,31 @@ int checkboard(void)
> return 0;
> }
>
> +static bool is_mx6q(void)
> +{
> + if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
> + return true;
> + else
> + return false;
> +}
> +
> +int board_late_init(void)
> +{
> +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> + if (is_hummingboard())
> + setenv("board_name", "HUMMINGBOARD");
> + else
> + setenv("board_name", "CUBOXI");
> +
> + if (is_mx6q)
> + setenv("board_rev", "MX6Q");
> + else
> + setenv("board_rev", "MX6DL");
> +#endif
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_SPL_BUILD
> #include
> static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
> diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
> index 98b48d5..b569f34 100644
> --- a/include/configs/mx6cuboxi.h
> +++ b/include/configs/mx6cuboxi.h
> @@ -29,6 +29,7 @@
>
> #define CONFIG_SYS_MALLOC_LEN(2 * SZ_1M)
> #define CONFIG_BOARD_EARLY_INIT_F
> +#define CONFIG_BOARD_LATE_INIT
> #define CONFIG_MXC_GPIO
> #define CONFIG_MXC_UART
> #define CONFIG_CMD_FUSE
> @@ -81,14 +82,14 @@
> #define CONFIG_MXC_UART_BASE UART1_BASE
> #define CONFIG_CONSOLE_DEV "ttymxc0"
> #define CONFIG_MMCROOT "/dev/mmcblk0p2"
> -#define CONFIG_DEFAULT_FDT_FILE "imx6q-hummingboard.dtb"
> #define CONFIG_SYS_FSL_USDHC_NUM 1
> #define CONFIG_SYS_MMC_ENV_DEV 0 /* SDHC2 */
>
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "script=boot.scr\0" \
> "image=zImage\0" \
> - "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> + "fdtfile=undefined\0" \
> "fdt_addr_r=0x1800\0" \
> "boot_fdt=try\0" \
> "ip_dyn=yes\0" \
> @@ -156,9 +157,21 @@
> "fi; " \
> "else " \
> "bootz; " \
> - "fi;\0"
> + "fi;\0" \
> + "findfdt="\
> + "if test $board_name = HUMMINGBOARD && test $board_rev = MX6Q ;
> then " \
> + "setenv fdtfile imx6q-hummingboard.dtb; fi; " \
> + "if test $board_name = HUMMINGBOARD && test $board_rev = MX6DL
> ; then " \
> + "setenv fdtfile imx6dl-hummingboard.dtb; fi; " \
> + "if test $board_name = CUBOXI && test $board_rev = MX6Q ; then
> " \
> + "setenv fdtfile imx6q-cubox-i.dtb; fi; " \
> + "if test $board_name = CUBOXI && test $board_rev = MX6DL ; then
> " \
> + "setenv fdtfile imx6dl-cubox-i.dtb; fi; " \
> + "if test $fdtfile = undefined; then " \
> + "echo WARNING: Could not determine dtb to use; fi; \0" \
>
> #define CONFIG_BOOTCOMMAND \
> + "run findfdt; " \
> "mmc dev ${mmcdev};" \
> "if mmc rescan; then " \
> "if run loadbootscript; then " \
> --
> 1.9.1
live well,
vagrant
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: fix typo in 'currently'
From: Fabio Estevam Signed-off-by: Fabio Estevam --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index 9b748cc..8e6b053 100644 --- a/README +++ b/README @@ -5506,7 +5506,7 @@ loaded to, and "Flash Location" gives the image's address in NOR flash or offset in NAND flash. *Note* - these variables don't have to be defined for all boards, some -boards currenlty use other variables for these purposes, and some +boards currently use other variables for these purposes, and some boards use these variables for other purposes. Image File NameRAM Address Flash Location -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 4/6] mx6cuboxi: Differentiate Cubox-i and Hummingboard
From: Fabio Estevam
Introduce is_hummingboard() function that reads GPIOs that can distinguish
between Cubox-i and Hummingboard.
Print the board name accordingly.
Based on a patch from Rabeeh Khoury.
Signed-off-by: Rabeeh Khoury
Signed-off-by: Fabio Estevam
---
Changes since v4:
- None
board/solidrun/mx6cuboxi/mx6cuboxi.c | 41 +++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 1f240ae..83410b2 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -71,6 +71,12 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
};
+static iomux_v3_cfg_t const hb_cbi_sense[] = {
+ /* These pins are for sensing if it is a CuBox-i or a HummingBoard */
+ IOMUX_PADS(PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX_PADS(PAD_EIM_DA4__GPIO3_IO04 | MUX_PAD_CTRL(UART_PAD_CTRL)),
+};
+
static void setup_iomux_uart(void)
{
SETUP_IOMUX_PADS(uart1_pads);
@@ -167,9 +173,42 @@ int board_init(void)
return 0;
}
+static bool is_hummingboard(void)
+{
+ int val1, val2;
+
+ SETUP_IOMUX_PADS(hb_cbi_sense);
+
+ gpio_direction_input(IMX_GPIO_NR(4, 9));
+ gpio_direction_input(IMX_GPIO_NR(3, 4));
+
+ val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
+ val2 = gpio_get_value(IMX_GPIO_NR(3, 4));
+
+ /*
+* Machine selection -
+* Machineval1, val2
+* -
+* HB rev 3.x x 0
+* CBi0 1
+* HB 1 1
+*/
+
+ if (val2 == 0)
+ return true;
+ else if (val1 == 0)
+ return false;
+ else
+ return true;
+}
+
int checkboard(void)
{
- puts("Board: MX6 Hummingboard\n");
+ if (is_hummingboard())
+ puts("Board: MX6 Hummingboard\n");
+ else
+ puts("Board: MX6 Cubox-i\n");
+
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/6] mx6cuboxi: Introduce multi-SoC support
From: Fabio Estevam
Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite,
mx6dual and mx6quad. Add support for the different SoC/memory sizes
combinations.
DDR initialization values were extracted from Solid-run internal U-boot.
Tested on a CuBox-i4Pro, HummingBoard-i2eX and HummingBoard-i1.
Signed-off-by: Rabeeh Khoury
Signed-off-by: Fabio Estevam
---
Changes since v4:
- Add Rabeeh's SOB
board/solidrun/mx6cuboxi/mx6cuboxi.c | 134 ---
1 file changed, 125 insertions(+), 9 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 0377dc4..1f240ae 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -175,7 +175,7 @@ int checkboard(void)
#ifdef CONFIG_SPL_BUILD
#include
-static const struct mx6dq_iomux_ddr_regs mx6_ddr_ioregs = {
+static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
.dram_sdclk_0 = 0x00020030,
.dram_sdclk_1 = 0x00020030,
.dram_cas = 0x00020030,
@@ -204,7 +204,36 @@ static const struct mx6dq_iomux_ddr_regs mx6_ddr_ioregs = {
.dram_dqm7 = 0x00020030,
};
-static const struct mx6dq_iomux_grp_regs mx6_grp_ioregs = {
+static const struct mx6sdl_iomux_ddr_regs mx6dl_ddr_ioregs = {
+ .dram_sdclk_0 = 0x0028,
+ .dram_sdclk_1 = 0x0028,
+ .dram_cas = 0x0028,
+ .dram_ras = 0x0028,
+ .dram_reset = 0x000c0028,
+ .dram_sdcke0 = 0x3000,
+ .dram_sdcke1 = 0x3000,
+ .dram_sdba2 = 0x,
+ .dram_sdodt0 = 0x3030,
+ .dram_sdodt1 = 0x3030,
+ .dram_sdqs0 = 0x0028,
+ .dram_sdqs1 = 0x0028,
+ .dram_sdqs2 = 0x0028,
+ .dram_sdqs3 = 0x0028,
+ .dram_sdqs4 = 0x0028,
+ .dram_sdqs5 = 0x0028,
+ .dram_sdqs6 = 0x0028,
+ .dram_sdqs7 = 0x0028,
+ .dram_dqm0 =0x0028,
+ .dram_dqm1 =0x0028,
+ .dram_dqm2 =0x0028,
+ .dram_dqm3 =0x0028,
+ .dram_dqm4 =0x0028,
+ .dram_dqm5 =0x0028,
+ .dram_dqm6 =0x0028,
+ .dram_dqm7 =0x0028,
+};
+
+static const struct mx6dq_iomux_grp_regs mx6q_grp_ioregs = {
.grp_ddr_type = 0x000C,
.grp_ddrmode_ctl = 0x0002,
.grp_ddrpke = 0x,
@@ -221,7 +250,25 @@ static const struct mx6dq_iomux_grp_regs mx6_grp_ioregs = {
.grp_b7ds = 0x0030,
};
-static const struct mx6_mmdc_calibration mx6_mmcd_calib = {
+static const struct mx6sdl_iomux_grp_regs mx6sdl_grp_ioregs = {
+ .grp_ddr_type = 0x000c,
+ .grp_ddrmode_ctl = 0x0002,
+ .grp_ddrpke = 0x,
+ .grp_addds = 0x0028,
+ .grp_ctlds = 0x0028,
+ .grp_ddrmode = 0x0002,
+ .grp_b0ds = 0x0028,
+ .grp_b1ds = 0x0028,
+ .grp_b2ds = 0x0028,
+ .grp_b3ds = 0x0028,
+ .grp_b4ds = 0x0028,
+ .grp_b5ds = 0x0028,
+ .grp_b6ds = 0x0028,
+ .grp_b7ds = 0x0028,
+};
+
+/* microSOM with Dual processor and 1GB memory */
+static const struct mx6_mmdc_calibration mx6q_1g_mmcd_calib = {
.p0_mpwldectrl0 = 0x,
.p0_mpwldectrl1 = 0x,
.p1_mpwldectrl0 = 0x,
@@ -236,7 +283,49 @@ static const struct mx6_mmdc_calibration mx6_mmcd_calib = {
.p1_mpwrdlctl =0x422a423c,
};
-static struct mx6_ddr3_cfg mem_ddr = {
+/* microSOM with Quad processor and 2GB memory */
+static const struct mx6_mmdc_calibration mx6q_2g_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x,
+ .p0_mpwldectrl1 = 0x,
+ .p1_mpwldectrl0 = 0x,
+ .p1_mpwldectrl1 = 0x,
+ .p0_mpdgctrl0 =0x0314031c,
+ .p0_mpdgctrl1 =0x023e0304,
+ .p1_mpdgctrl0 =0x03240330,
+ .p1_mpdgctrl1 =0x03180260,
+ .p0_mprddlctl =0x3630323c,
+ .p1_mprddlctl =0x3436283a,
+ .p0_mpwrdlctl =0x36344038,
+ .p1_mpwrdlctl =0x422a423c,
+};
+
+/* microSOM with Solo processor and 512MB memory */
+static const struct mx6_mmdc_calibration mx6dl_512m_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x0045004D,
+ .p0_mpwldectrl1 = 0x003A0047,
+ .p0_mpdgctrl0 = 0x023C0224,
+ .p0_mpdgctrl1 = 0x02000220,
+ .p0_mprddlctl = 0x4846,
+ .p0_mpwrdlctl = 0x32343032,
+};
+
+/* microSOM with Dual lite processor and 1GB memory */
+static const struct mx6_mmdc_calibration mx6dl_1g_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x0045004D,
+ .p0_mpwldectrl1 = 0x003A0047,
+ .p1_mpwldectrl0 = 0x001F001F,
+ .p1_mpwldectrl1 = 0x00210035,
+ .p0_mpdgctrl0 =0x023C0224,
+ .p0_mpdgctrl1 =0x02000220,
+ .p1_mpdgctrl0 =0x02200220,
+ .p1_mpdgctrl1 =0x02000220,
+ .p0_mprddlctl =0x4846,
+ .p1_mprddlctl =0x40424
[U-Boot] [PATCH v5 6/6] mx6cuboxi: Load the correct 'fdtfile' variable
From: Fabio Estevam
Instead of hardcoding the 'fdtfile' variable, let's detect the SoC and
board variant on the fly and change the dtb name.
Based on the scheme done on am335x board.
Signed-off-by: Fabio Estevam
---
Changes since v4:
- None
board/solidrun/mx6cuboxi/mx6cuboxi.c | 25 +
include/configs/mx6cuboxi.h | 19 ---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 83410b2..e06186e 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -212,6 +212,31 @@ int checkboard(void)
return 0;
}
+static bool is_mx6q(void)
+{
+ if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+ return true;
+ else
+ return false;
+}
+
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ if (is_hummingboard())
+ setenv("board_name", "HUMMINGBOARD");
+ else
+ setenv("board_name", "CUBOXI");
+
+ if (is_mx6q)
+ setenv("board_rev", "MX6Q");
+ else
+ setenv("board_rev", "MX6DL");
+#endif
+
+ return 0;
+}
+
#ifdef CONFIG_SPL_BUILD
#include
static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 98b48d5..b569f34 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -29,6 +29,7 @@
#define CONFIG_SYS_MALLOC_LEN (2 * SZ_1M)
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
#define CONFIG_MXC_GPIO
#define CONFIG_MXC_UART
#define CONFIG_CMD_FUSE
@@ -81,14 +82,14 @@
#define CONFIG_MXC_UART_BASE UART1_BASE
#define CONFIG_CONSOLE_DEV "ttymxc0"
#define CONFIG_MMCROOT "/dev/mmcblk0p2"
-#define CONFIG_DEFAULT_FDT_FILE"imx6q-hummingboard.dtb"
#define CONFIG_SYS_FSL_USDHC_NUM 1
#define CONFIG_SYS_MMC_ENV_DEV 0 /* SDHC2 */
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "fdtfile=undefined\0" \
"fdt_addr_r=0x1800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
@@ -156,9 +157,21 @@
"fi; " \
"else " \
"bootz; " \
- "fi;\0"
+ "fi;\0" \
+ "findfdt="\
+ "if test $board_name = HUMMINGBOARD && test $board_rev = MX6Q ;
then " \
+ "setenv fdtfile imx6q-hummingboard.dtb; fi; " \
+ "if test $board_name = HUMMINGBOARD && test $board_rev = MX6DL
; then " \
+ "setenv fdtfile imx6dl-hummingboard.dtb; fi; " \
+ "if test $board_name = CUBOXI && test $board_rev = MX6Q ; then
" \
+ "setenv fdtfile imx6q-cubox-i.dtb; fi; " \
+ "if test $board_name = CUBOXI && test $board_rev = MX6DL ; then
" \
+ "setenv fdtfile imx6dl-cubox-i.dtb; fi; " \
+ "if test $fdtfile = undefined; then " \
+ "echo WARNING: Could not determine dtb to use; fi; \0" \
#define CONFIG_BOOTCOMMAND \
+ "run findfdt; " \
"mmc dev ${mmcdev};" \
"if mmc rescan; then " \
"if run loadbootscript; then " \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 5/6] mx6cuboxi: Use more standard namings for fdt variables
From: Fabio Estevam
README file suggests to use 'fdtfile' for the dtb file name and
'fdt_addr_r' for the dtb address in RAM, so do as suggested.
Signed-off-by: Fabio Estevam
---
Changes since v5:
- Use fdt_addr_r as per README (suggested by Vagrant)
include/configs/mx6cuboxi.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 5d58b16..98b48d5 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -88,8 +88,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
- "fdt_addr=0x1800\0" \
+ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "fdt_addr_r=0x1800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"console=" CONFIG_CONSOLE_DEV "\0" \
@@ -117,12 +117,12 @@
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
- "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+ "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
- "bootz ${loadaddr} - ${fdt_addr}; " \
+ "bootz ${loadaddr} - ${fdt_addr_r}; " \
"else " \
"if test ${boot_fdt} = try; then " \
"bootz; " \
@@ -145,8 +145,8 @@
"fi; " \
"${get_cmd} ${image}; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- "bootz ${loadaddr} - ${fdt_addr}; " \
+ "if ${get_cmd} ${fdt_addr_r} ${fdtfile}; then " \
+ "bootz ${loadaddr} - ${fdt_addr_r}; " \
"else " \
"if test ${boot_fdt} = try; then " \
"bootz; " \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/6] mx6cuboxi: Fix the defconfig name
From: Fabio Estevam The correct name of the defconfig file is 'mx6cuboxi_defconfig'. Signed-off-by: Fabio Estevam --- Changes since v4: - None board/solidrun/mx6cuboxi/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/solidrun/mx6cuboxi/MAINTAINERS b/board/solidrun/mx6cuboxi/MAINTAINERS index 3d468ed..a3506c2 100644 --- a/board/solidrun/mx6cuboxi/MAINTAINERS +++ b/board/solidrun/mx6cuboxi/MAINTAINERS @@ -3,4 +3,4 @@ M: Fabio Estevam S: Maintained F: board/solidrun/mx6cuboxi/ F: include/configs/mx6cuboxi.h -F: configs/mx6cuboxi_spl_defconfig +F: configs/mx6cuboxi_defconfig -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/6] mx6cuboxi: Prepare for multi SoC support
From: Fabio Estevam
Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite,
mx6dual and mx6quad.
Use IOMUX_PADS() macro in order to prepare for the multi-SoC support.
Also pass 'MX6QDL' in the defconfig to indicate it.
Signed-off-by: Fabio Estevam
---
Changes since v4:
- None
board/solidrun/mx6cuboxi/mx6cuboxi.c | 60 ++--
configs/mx6cuboxi_defconfig | 2 +-
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index b696dcb..0377dc4 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -59,22 +58,22 @@ int dram_init(void)
}
static iomux_v3_cfg_t const uart1_pads[] = {
- MX6_PAD_CSI0_DAT10__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ IOMUX_PADS(PAD_CSI0_DAT10__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX_PADS(PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
};
static iomux_v3_cfg_t const usdhc2_pads[] = {
- MX6_PAD_SD2_CLK__SD2_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_CMD__SD2_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ IOMUX_PADS(PAD_SD2_CLK__SD2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_CMD__SD2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
};
static void setup_iomux_uart(void)
{
- imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+ SETUP_IOMUX_PADS(uart1_pads);
}
static struct fsl_esdhc_cfg usdhc_cfg[1] = {
@@ -88,7 +87,7 @@ int board_mmc_getcd(struct mmc *mmc)
int board_mmc_init(bd_t *bis)
{
- imx_iomux_v3_setup_multiple_pads(usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ SETUP_IOMUX_PADS(usdhc2_pads);
usdhc_cfg[0].esdhc_base = USDHC2_BASE_ADDR;
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
gd->arch.sdhc_clk = usdhc_cfg[0].sdhc_clk;
@@ -97,33 +96,33 @@ int board_mmc_init(bd_t *bis)
}
static iomux_v3_cfg_t const enet_pads[] = {
- MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ IOMUX_PADS(PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL)),
/* AR8035 reset */
- MX6_PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
+ IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
/* AR8035 interrupt */
- MX6_PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ IOMUX_PADS(PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL)),
/* GPIO16 -> AR8035 25MHz */
- MX6_PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ IOMUX_PADS(PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(NO_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TX_CTL__RGMII_TX_CTL |
MUX_PAD_CTRL(ENET_PAD_CTRL)),
/* AR8035 CLK_25M --> ENET_REF_CLK (V22) */
- MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL_CLK),
- MX6_PAD_RGMII_RXC__RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD0__RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
- MX6_PAD_RGMII_RD1__RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
- MX6_PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_C
[U-Boot] [PATCH 4/4 v2] x86: minnowmax: initialize the pin-muxing from device tree
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Fix ordering of include header
board/intel/minnowmax/minnowmax.c | 9 +
include/configs/minnowmax.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/board/intel/minnowmax/minnowmax.c
b/board/intel/minnowmax/minnowmax.c
index 6e82b16..0244d35 100644
--- a/board/intel/minnowmax/minnowmax.c
+++ b/board/intel/minnowmax/minnowmax.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,6 +15,14 @@
DECLARE_GLOBAL_DATA_PTR;
+int arch_early_init_r(void)
+{
+ /* do the pin-muxing */
+ gpio_ich6_pinctrl_init();
+
+ return 0;
+}
+
int board_early_init_f(void)
{
lpc47m_enable_serial(SERIAL_DEV, UART0_BASE);
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 823e051..3c7b266 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -15,6 +15,7 @@
#define CONFIG_SYS_MONITOR_LEN (1 << 20)
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_ARCH_EARLY_INIT_R
#define CONFIG_NR_DRAM_BANKS 1
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4 v2] x86: gpio: add pinctrl support from the device tree
Every pin can be configured now from the device tree. A dt-bindings
has been added to describe the different property available.
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Clean commit message
- Rename compatible string 'ich6' to 'x86'
- Fix coding style
- Create a dt-bindinds documentation
- Move x86-gpio defines to a specific header
- Reorder the functions to avoid the need for forward declarations
- Rename double underscore functions to only one
- Create a specific function to configure one pin
- Use a define to prevent build/support issues with other x86 CPU that
doesn't have a IOBASE.
arch/x86/dts/minnowmax.dts | 21 ++
arch/x86/include/asm/arch-baytrail/gpio.h | 1 +
arch/x86/include/asm/gpio.h| 1 +
.../gpio/intel,x86-pinctrl.txt | 31 +++
drivers/gpio/intel_ich6_gpio.c | 234 ++---
include/dt-bindings/gpio/x86-gpio.h| 36
6 files changed, 295 insertions(+), 29 deletions(-)
create mode 100644 doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
create mode 100644 include/dt-bindings/gpio/x86-gpio.h
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index c73e421..ea10963 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include
+
/include/ "skeleton.dtsi"
/include/ "serial.dtsi"
@@ -21,6 +23,25 @@
silent_console = <0>;
};
+ pch_pinctrl {
+ compatible = "intel,x86-pinctrl";
+ pin_usb_host_en0@0 {
+ gpio-offset = <0x80 8>;
+ pad-offset = <0x260>;
+ mode-gpio;
+ output-value = <1>;
+ direction = ;
+ };
+
+ pin_usb_host_en1@0 {
+ gpio-offset = <0x80 9>;
+ pad-offset = <0x258>;
+ mode-gpio;
+ output-value = <1>;
+ direction = ;
+ };
+ };
+
gpioa {
compatible = "intel,ich6-gpio";
u-boot,dm-pre-reloc;
diff --git a/arch/x86/include/asm/arch-baytrail/gpio.h
b/arch/x86/include/asm/arch-baytrail/gpio.h
index 4e8987c..85a65a8 100644
--- a/arch/x86/include/asm/arch-baytrail/gpio.h
+++ b/arch/x86/include/asm/arch-baytrail/gpio.h
@@ -9,5 +9,6 @@
/* Where in config space is the register that points to the GPIO registers? */
#define PCI_CFG_GPIOBASE 0x48
+#define PCI_CFG_IOBASE 0x4c
#endif /* _X86_ARCH_GPIO_H_ */
diff --git a/arch/x86/include/asm/gpio.h b/arch/x86/include/asm/gpio.h
index 1099427..ed85b08 100644
--- a/arch/x86/include/asm/gpio.h
+++ b/arch/x86/include/asm/gpio.h
@@ -147,6 +147,7 @@ struct pch_gpio_map {
} set3;
};
+int gpio_ich6_pinctrl_init(void);
void setup_pch_gpios(u16 gpiobase, const struct pch_gpio_map *gpio);
void ich_gpio_set_gpio_map(const struct pch_gpio_map *map);
diff --git a/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
b/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
new file mode 100644
index 000..45ab1af
--- /dev/null
+++ b/doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
@@ -0,0 +1,31 @@
+Intel x86 PINCTRL/GPIO controller
+
+Pin-muxing on x86 can be described with a node for the PINCTRL master
+node and a set of child nodes for each pin on the SoC.
+
+The PINCTRL master node requires the following properties:
+- compatible : "intel,x86-pinctrl"
+
+Pin nodes must be children of the pinctrl master node and can
+contain the following properties:
+- pad-offset- (required) offset in the IOBASE for the pin to
configured.
+- gpio-offset - (required) offset in the GPIOBASE for the pin to
configured and
+ also the bit shift in this register.
+- mode-gpio- (optional) standalone property to force the
pin into GPIO mode.
+- mode-func- (optional) function number to assign to the
pin. if 'mode-gpio'
+ is set, this property will be ignored.
+in case of 'mode-gpio' property set:
+- output-value - (optional) this set the default output value of the
GPIO.
+- direction - (optional) this set the direction of the gpio.
+- pull-str - (optional) this set the pull strength of the pin.
+- pull-assign - (optional) this set the pull assignement (up/down) of
the pin.
+
+Example:
+
+pin_usb_host_en0@0 {
+gpio-offset = <0x80 8>;
+pad-offset = <0x260>;
+mode-gpio;
+output-value = <1>;
+direction = ;
+};
diff --git a/drivers/gpio/intel_ich6_gpio.c b/drivers/gpio/intel_ich6_gpio.c
index 7e679a0..c18c60f 100644
--- a/drivers/gpio/intel_ich6_gpio.c
+++ b/drivers/gpio/intel_ich6_gpio.c
@@ -44,21 +44,28 @@ struct ich6_bank_p
[U-Boot] [PATCH 2/4 v2] x86: minnowmax: add GPIO banks in the device tree
There are 6 banks:
4 banks for CORE: available in S0 mode
2 banks for SUS (Suspend): available in S0-S5 mode
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Fix typo in the commit message
arch/x86/dts/minnowmax.dts | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 8f34369..c73e421 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -21,6 +21,48 @@
silent_console = <0>;
};
+ gpioa {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0 0x20>;
+ bank-name = "A";
+ };
+
+ gpiob {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x20 0x20>;
+ bank-name = "B";
+ };
+
+ gpioc {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x40 0x20>;
+ bank-name = "C";
+ };
+
+ gpiod {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x60 0x20>;
+ bank-name = "D";
+ };
+
+ gpioe {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x80 0x20>;
+ bank-name = "E";
+ };
+
+ gpiof {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0xA0 0x20>;
+ bank-name = "F";
+ };
+
chosen {
stdout-path = "/serial";
};
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4 v3] x86: baytrail: fix the GPIOBASE address
The correct GPIOBASE address on the baytrail is 0x48 Signed-off-by: Gabriel Huau --- Changes for v2: - Add a commit message Changes for v3: - Fix patch number arch/x86/include/asm/arch-baytrail/gpio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/arch-baytrail/gpio.h b/arch/x86/include/asm/arch-baytrail/gpio.h index ab4e059..4e8987c 100644 --- a/arch/x86/include/asm/arch-baytrail/gpio.h +++ b/arch/x86/include/asm/arch-baytrail/gpio.h @@ -8,6 +8,6 @@ #define _X86_ARCH_GPIO_H_ /* Where in config space is the register that points to the GPIO registers? */ -#define PCI_CFG_GPIOBASE 0x44 +#define PCI_CFG_GPIOBASE 0x48 #endif /* _X86_ARCH_GPIO_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] mx6cuboxi: Use more standard namings for fdt variables
On 2015-04-25, Fabio Estevam wrote: > From: Fabio Estevam > > Use the more standard fdtfile and fdtaddr variable names. I think you want to change fdtaddr to fdt_addr_r, as it's the location in ram, as opposed to the location on the flash media (which would use fdt_addr), according to README. But definitely leave fdtfile as fdtfile. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v2] x86: baytrail: fix the GPIOBASE address
The correct GPIOBASE address on the baytrail is 0x48 Signed-off-by: Gabriel Huau --- Changes for v2: - Add a commit message arch/x86/include/asm/arch-baytrail/gpio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/arch-baytrail/gpio.h b/arch/x86/include/asm/arch-baytrail/gpio.h index ab4e059..4e8987c 100644 --- a/arch/x86/include/asm/arch-baytrail/gpio.h +++ b/arch/x86/include/asm/arch-baytrail/gpio.h @@ -8,6 +8,6 @@ #define _X86_ARCH_GPIO_H_ /* Where in config space is the register that points to the GPIO registers? */ -#define PCI_CFG_GPIOBASE 0x44 +#define PCI_CFG_GPIOBASE 0x48 #endif /* _X86_ARCH_GPIO_H_ */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset
On Thu 2014-10-02 00:34:48, Jagan Teki wrote: > On 2 October 2014 00:27, Stefan Roese wrote: > > On 01.10.2014 20:25, Marek Vasut wrote: > >> > >> On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > >>> > >>> This is needed for the SoCFPGA booting from SPI NOR flash > >>> e.g. (N25Q256A). With these changes, the SoCrates can boot and > >>> re-boot (reset) from SPI NOR flash without any problems. > >> > >> > >> Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to > >> your > >> board please? > >> > >> [1] http://www.rocketboards.org/foswiki/Documentation/SocBoardQspiBoot > > > > > > Yes. This seems to be that case. But I can't change it right now. So this > > "solution" with the soft-reset is better than nothing. > > If this is some think that must require, any possibility to this > resetting prior to u-boot? > like preloader or in first stage boot loader or something. u-boot-spl 2013.01/altera set it up like this for us; and mainline u-boot-spl does not work on socfpga... that's why we need to do it here, and that's why you don't see it on your board. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/4 v3] mtd: sf: Add CONFIG_SPI_N25Q256A_RESET for software-reset
On Wed 2014-10-01 20:25:55, Marek Vasut wrote: > On Wednesday, October 01, 2014 at 05:13:11 PM, Stefan Roese wrote: > > This is needed for the SoCFPGA booting from SPI NOR flash > > e.g. (N25Q256A). With these changes, the SoCrates can boot and > > re-boot (reset) from SPI NOR flash without any problems. > > Seems like your SPI NOR reset logic is buggy. Does any of [1] apply to your > board please? Actually, this has nothing to do with SPI NOR reset logic. Yes, we need to reset NOR flash during u-boot startup, because hardware was already initialized to 4-byte addressing by u-boot-spl. No matter what reset logic does, if it passes u-boot-spl (and SPI NOR is actually used), it will be in 4-byte mode. And no, mainline u-boot-spl is not usable on socfpga, and probably will not be usable for a whill, so u-boot-spl from altera is only option here. So.. what to do? Do you want this patch? Do you want patch that know how to switch back to 3-byte addressing on this particular flash? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] socfpga: implement arria V socdk SPI flash config in dts
Arria V SocDK has same QSPI and SPI flash configuration as Socrates. Add
support for it.
Signed-off-by: Pavel Machek
diff --git a/arch/arm/dts/socfpga_arria5_socdk.dts
b/arch/arm/dts/socfpga_arria5_socdk.dts
index 4e529a1..1b86897 100644
--- a/arch/arm/dts/socfpga_arria5_socdk.dts
+++ b/arch/arm/dts/socfpga_arria5_socdk.dts
@@ -25,6 +25,10 @@
* to be added to the gmac1 device tree blob.
*/
ethernet0 = &gmac1;
+
+ spi0 = "/spi@ff705000"; /* QSPI */
+ spi1 = "/spi@fff0";
+ spi2 = "/spi@fff01000";
};
regulator_3_3v: 3-3-v-regulator {
@@ -72,3 +76,23 @@
&usb1 {
status = "okay";
};
+
+&qspi {
+ status = "okay";
+
+ flash0: n25q00@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q00";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+ page-size = <256>;
+ block-size = <16>; /* 2^16, 64KB */
+ read-delay = <4>; /* delay value in read data capture register
*/
+ tshsl-ns = <50>;
+ tsd2d-ns = <50>;
+ tchsh-ns = <4>;
+ tslch-ns = <4>;
+ };
+};
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/6] mx6cuboxi: Prepare for multi SoC support
From: Fabio Estevam
Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite,
mx6dual and mx6quad.
Use IOMUX_PADS() macro in order to prepare for the multi-SoC support.
Also pass 'MX6QDL' in the defconfig to indicate it.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- None
board/solidrun/mx6cuboxi/mx6cuboxi.c | 60 ++--
configs/mx6cuboxi_defconfig | 2 +-
2 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index b696dcb..0377dc4 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -59,22 +58,22 @@ int dram_init(void)
}
static iomux_v3_cfg_t const uart1_pads[] = {
- MX6_PAD_CSI0_DAT10__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX6_PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL),
+ IOMUX_PADS(PAD_CSI0_DAT10__UART1_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX_PADS(PAD_CSI0_DAT11__UART1_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL)),
};
static iomux_v3_cfg_t const usdhc2_pads[] = {
- MX6_PAD_SD2_CLK__SD2_CLK| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_CMD__SD2_CMD| MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
- MX6_PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ IOMUX_PADS(PAD_SD2_CLK__SD2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_CMD__SD2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT0__SD2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT1__SD2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT2__SD2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
+ IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
};
static void setup_iomux_uart(void)
{
- imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+ SETUP_IOMUX_PADS(uart1_pads);
}
static struct fsl_esdhc_cfg usdhc_cfg[1] = {
@@ -88,7 +87,7 @@ int board_mmc_getcd(struct mmc *mmc)
int board_mmc_init(bd_t *bis)
{
- imx_iomux_v3_setup_multiple_pads(usdhc2_pads, ARRAY_SIZE(usdhc2_pads));
+ SETUP_IOMUX_PADS(usdhc2_pads);
usdhc_cfg[0].esdhc_base = USDHC2_BASE_ADDR;
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
gd->arch.sdhc_clk = usdhc_cfg[0].sdhc_clk;
@@ -97,33 +96,33 @@ int board_mmc_init(bd_t *bis)
}
static iomux_v3_cfg_t const enet_pads[] = {
- MX6_PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ IOMUX_PADS(PAD_ENET_MDIO__ENET_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL)),
/* AR8035 reset */
- MX6_PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
+ IOMUX_PADS(PAD_KEY_ROW4__GPIO4_IO15 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD)),
/* AR8035 interrupt */
- MX6_PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+ IOMUX_PADS(PAD_DI0_PIN2__GPIO4_IO18 | MUX_PAD_CTRL(NO_PAD_CTRL)),
/* GPIO16 -> AR8035 25MHz */
- MX6_PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(NO_PAD_CTRL),
- MX6_PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ IOMUX_PADS(PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(NO_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TXC__RGMII_TXC | MUX_PAD_CTRL(NO_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD0__RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD1__RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD2__RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TD3__RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL)),
+ IOMUX_PADS(PAD_RGMII_TX_CTL__RGMII_TX_CTL |
MUX_PAD_CTRL(ENET_PAD_CTRL)),
/* AR8035 CLK_25M --> ENET_REF_CLK (V22) */
- MX6_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL_CLK),
- MX6_PAD_RGMII_RXC__RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD0__RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
- MX6_PAD_RGMII_RD1__RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD),
- MX6_PAD_RGMII_RD2__RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_RGMII_RD3__RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_C
[U-Boot] [PATCH v4 6/6] mx6cuboxi: Load the correct 'fdtfile' variable
From: Fabio Estevam
Instead of hardcoding the 'fdtfile' variable, let's detect the SoC and
board variant on the fly and change the dtb name.
Based on the scheme done on am335x board.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Based on the scheme done on am335x board as per Tom Rini's suggestion
board/solidrun/mx6cuboxi/mx6cuboxi.c | 25 +
include/configs/mx6cuboxi.h | 19 ---
2 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 83410b2..e06186e 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -212,6 +212,31 @@ int checkboard(void)
return 0;
}
+static bool is_mx6q(void)
+{
+ if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
+ return true;
+ else
+ return false;
+}
+
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ if (is_hummingboard())
+ setenv("board_name", "HUMMINGBOARD");
+ else
+ setenv("board_name", "CUBOXI");
+
+ if (is_mx6q)
+ setenv("board_rev", "MX6Q");
+ else
+ setenv("board_rev", "MX6DL");
+#endif
+
+ return 0;
+}
+
#ifdef CONFIG_SPL_BUILD
#include
static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index bc7c577..32e0e5e 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -29,6 +29,7 @@
#define CONFIG_SYS_MALLOC_LEN (2 * SZ_1M)
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
#define CONFIG_MXC_GPIO
#define CONFIG_MXC_UART
#define CONFIG_CMD_FUSE
@@ -81,14 +82,14 @@
#define CONFIG_MXC_UART_BASE UART1_BASE
#define CONFIG_CONSOLE_DEV "ttymxc0"
#define CONFIG_MMCROOT "/dev/mmcblk0p2"
-#define CONFIG_DEFAULT_FDT_FILE"imx6q-hummingboard.dtb"
#define CONFIG_SYS_FSL_USDHC_NUM 1
#define CONFIG_SYS_MMC_ENV_DEV 0 /* SDHC2 */
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "fdtfile=undefined\0" \
"fdtaddr=0x1800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
@@ -156,9 +157,21 @@
"fi; " \
"else " \
"bootz; " \
- "fi;\0"
+ "fi;\0" \
+ "findfdt="\
+ "if test $board_name = HUMMINGBOARD && test $board_rev = MX6Q ;
then " \
+ "setenv fdtfile imx6q-hummingboard.dtb; fi; " \
+ "if test $board_name = HUMMINGBOARD && test $board_rev = MX6DL
; then " \
+ "setenv fdtfile imx6dl-hummingboard.dtb; fi; " \
+ "if test $board_name = CUBOXI && test $board_rev = MX6Q ; then
" \
+ "setenv fdtfile imx6q-cubox-i.dtb; fi; " \
+ "if test $board_name = CUBOXI && test $board_rev = MX6DL ; then
" \
+ "setenv fdtfile imx6dl-cubox-i.dtb; fi; " \
+ "if test $fdtfile = undefined; then " \
+ "echo WARNING: Could not determine dtb to use; fi; \0" \
#define CONFIG_BOOTCOMMAND \
+ "run findfdt; " \
"mmc dev ${mmcdev};" \
"if mmc rescan; then " \
"if run loadbootscript; then " \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/6] mx6cuboxi: Differentiate Cubox-i and Hummingboard
From: Fabio Estevam
Introduce is_hummingboard() function that reads GPIOs that can distinguish
between Cubox-i and Hummingboard.
Print the board name accordingly.
Based on a patch from Rabeeh Khoury.
Signed-off-by: Rabeeh Khoury
Signed-off-by: Fabio Estevam
---
Changes since v3:
- None
board/solidrun/mx6cuboxi/mx6cuboxi.c | 41 +++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 1f240ae..83410b2 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -71,6 +71,12 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
IOMUX_PADS(PAD_SD2_DAT3__SD2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL)),
};
+static iomux_v3_cfg_t const hb_cbi_sense[] = {
+ /* These pins are for sensing if it is a CuBox-i or a HummingBoard */
+ IOMUX_PADS(PAD_KEY_ROW1__GPIO4_IO09 | MUX_PAD_CTRL(UART_PAD_CTRL)),
+ IOMUX_PADS(PAD_EIM_DA4__GPIO3_IO04 | MUX_PAD_CTRL(UART_PAD_CTRL)),
+};
+
static void setup_iomux_uart(void)
{
SETUP_IOMUX_PADS(uart1_pads);
@@ -167,9 +173,42 @@ int board_init(void)
return 0;
}
+static bool is_hummingboard(void)
+{
+ int val1, val2;
+
+ SETUP_IOMUX_PADS(hb_cbi_sense);
+
+ gpio_direction_input(IMX_GPIO_NR(4, 9));
+ gpio_direction_input(IMX_GPIO_NR(3, 4));
+
+ val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
+ val2 = gpio_get_value(IMX_GPIO_NR(3, 4));
+
+ /*
+* Machine selection -
+* Machineval1, val2
+* -
+* HB rev 3.x x 0
+* CBi0 1
+* HB 1 1
+*/
+
+ if (val2 == 0)
+ return true;
+ else if (val1 == 0)
+ return false;
+ else
+ return true;
+}
+
int checkboard(void)
{
- puts("Board: MX6 Hummingboard\n");
+ if (is_hummingboard())
+ puts("Board: MX6 Hummingboard\n");
+ else
+ puts("Board: MX6 Cubox-i\n");
+
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/6] mx6cuboxi: Introduce multi-SoC support
From: Fabio Estevam
Cubox-i and Hummingboard support several MX6 SoCs: mx6solo, mx6dual-lite,
mx6dual and mx6quad. Add support for the different SoC/memory sizes
combinations.
DDR initialization values were extracted from Solid-run internal U-boot.
Tested on a CuBox-i4Pro, HummingBoard-i2eX and HummingBoard-i1.
Signed-off-by: Rabeeh Khoury
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Add Rabeeh's SOB
board/solidrun/mx6cuboxi/mx6cuboxi.c | 134 ---
1 file changed, 125 insertions(+), 9 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 0377dc4..1f240ae 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -175,7 +175,7 @@ int checkboard(void)
#ifdef CONFIG_SPL_BUILD
#include
-static const struct mx6dq_iomux_ddr_regs mx6_ddr_ioregs = {
+static const struct mx6dq_iomux_ddr_regs mx6q_ddr_ioregs = {
.dram_sdclk_0 = 0x00020030,
.dram_sdclk_1 = 0x00020030,
.dram_cas = 0x00020030,
@@ -204,7 +204,36 @@ static const struct mx6dq_iomux_ddr_regs mx6_ddr_ioregs = {
.dram_dqm7 = 0x00020030,
};
-static const struct mx6dq_iomux_grp_regs mx6_grp_ioregs = {
+static const struct mx6sdl_iomux_ddr_regs mx6dl_ddr_ioregs = {
+ .dram_sdclk_0 = 0x0028,
+ .dram_sdclk_1 = 0x0028,
+ .dram_cas = 0x0028,
+ .dram_ras = 0x0028,
+ .dram_reset = 0x000c0028,
+ .dram_sdcke0 = 0x3000,
+ .dram_sdcke1 = 0x3000,
+ .dram_sdba2 = 0x,
+ .dram_sdodt0 = 0x3030,
+ .dram_sdodt1 = 0x3030,
+ .dram_sdqs0 = 0x0028,
+ .dram_sdqs1 = 0x0028,
+ .dram_sdqs2 = 0x0028,
+ .dram_sdqs3 = 0x0028,
+ .dram_sdqs4 = 0x0028,
+ .dram_sdqs5 = 0x0028,
+ .dram_sdqs6 = 0x0028,
+ .dram_sdqs7 = 0x0028,
+ .dram_dqm0 =0x0028,
+ .dram_dqm1 =0x0028,
+ .dram_dqm2 =0x0028,
+ .dram_dqm3 =0x0028,
+ .dram_dqm4 =0x0028,
+ .dram_dqm5 =0x0028,
+ .dram_dqm6 =0x0028,
+ .dram_dqm7 =0x0028,
+};
+
+static const struct mx6dq_iomux_grp_regs mx6q_grp_ioregs = {
.grp_ddr_type = 0x000C,
.grp_ddrmode_ctl = 0x0002,
.grp_ddrpke = 0x,
@@ -221,7 +250,25 @@ static const struct mx6dq_iomux_grp_regs mx6_grp_ioregs = {
.grp_b7ds = 0x0030,
};
-static const struct mx6_mmdc_calibration mx6_mmcd_calib = {
+static const struct mx6sdl_iomux_grp_regs mx6sdl_grp_ioregs = {
+ .grp_ddr_type = 0x000c,
+ .grp_ddrmode_ctl = 0x0002,
+ .grp_ddrpke = 0x,
+ .grp_addds = 0x0028,
+ .grp_ctlds = 0x0028,
+ .grp_ddrmode = 0x0002,
+ .grp_b0ds = 0x0028,
+ .grp_b1ds = 0x0028,
+ .grp_b2ds = 0x0028,
+ .grp_b3ds = 0x0028,
+ .grp_b4ds = 0x0028,
+ .grp_b5ds = 0x0028,
+ .grp_b6ds = 0x0028,
+ .grp_b7ds = 0x0028,
+};
+
+/* microSOM with Dual processor and 1GB memory */
+static const struct mx6_mmdc_calibration mx6q_1g_mmcd_calib = {
.p0_mpwldectrl0 = 0x,
.p0_mpwldectrl1 = 0x,
.p1_mpwldectrl0 = 0x,
@@ -236,7 +283,49 @@ static const struct mx6_mmdc_calibration mx6_mmcd_calib = {
.p1_mpwrdlctl =0x422a423c,
};
-static struct mx6_ddr3_cfg mem_ddr = {
+/* microSOM with Quad processor and 2GB memory */
+static const struct mx6_mmdc_calibration mx6q_2g_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x,
+ .p0_mpwldectrl1 = 0x,
+ .p1_mpwldectrl0 = 0x,
+ .p1_mpwldectrl1 = 0x,
+ .p0_mpdgctrl0 =0x0314031c,
+ .p0_mpdgctrl1 =0x023e0304,
+ .p1_mpdgctrl0 =0x03240330,
+ .p1_mpdgctrl1 =0x03180260,
+ .p0_mprddlctl =0x3630323c,
+ .p1_mprddlctl =0x3436283a,
+ .p0_mpwrdlctl =0x36344038,
+ .p1_mpwrdlctl =0x422a423c,
+};
+
+/* microSOM with Solo processor and 512MB memory */
+static const struct mx6_mmdc_calibration mx6dl_512m_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x0045004D,
+ .p0_mpwldectrl1 = 0x003A0047,
+ .p0_mpdgctrl0 = 0x023C0224,
+ .p0_mpdgctrl1 = 0x02000220,
+ .p0_mprddlctl = 0x4846,
+ .p0_mpwrdlctl = 0x32343032,
+};
+
+/* microSOM with Dual lite processor and 1GB memory */
+static const struct mx6_mmdc_calibration mx6dl_1g_mmcd_calib = {
+ .p0_mpwldectrl0 = 0x0045004D,
+ .p0_mpwldectrl1 = 0x003A0047,
+ .p1_mpwldectrl0 = 0x001F001F,
+ .p1_mpwldectrl1 = 0x00210035,
+ .p0_mpdgctrl0 =0x023C0224,
+ .p0_mpdgctrl1 =0x02000220,
+ .p1_mpdgctrl0 =0x02200220,
+ .p1_mpdgctrl1 =0x02000220,
+ .p0_mprddlctl =0x4846,
+ .p1_mprddlctl =0x40424
[U-Boot] [PATCH v4 5/6] mx6cuboxi: Use more standard namings for fdt variables
From: Fabio Estevam
Use the more standard fdtfile and fdtaddr variable names.
Signed-off-by: Fabio Estevam
---
Changes since v3:
- Newly introduced in this series as per Vagrant Cascadian's suggestion
include/configs/mx6cuboxi.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
index 5d58b16..bc7c577 100644
--- a/include/configs/mx6cuboxi.h
+++ b/include/configs/mx6cuboxi.h
@@ -88,8 +88,8 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
- "fdt_addr=0x1800\0" \
+ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "fdtaddr=0x1800\0" \
"boot_fdt=try\0" \
"ip_dyn=yes\0" \
"console=" CONFIG_CONSOLE_DEV "\0" \
@@ -117,12 +117,12 @@
"bootscript=echo Running bootscript from mmc ...; " \
"source\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
- "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+ "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdtaddr} ${fdtfile}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run mmcargs; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
"if run loadfdt; then " \
- "bootz ${loadaddr} - ${fdt_addr}; " \
+ "bootz ${loadaddr} - ${fdtaddr}; " \
"else " \
"if test ${boot_fdt} = try; then " \
"bootz; " \
@@ -145,8 +145,8 @@
"fi; " \
"${get_cmd} ${image}; " \
"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
- "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- "bootz ${loadaddr} - ${fdt_addr}; " \
+ "if ${get_cmd} ${fdtaddr} ${fdtfile}; then " \
+ "bootz ${loadaddr} - ${fdtaddr}; " \
"else " \
"if test ${boot_fdt} = try; then " \
"bootz; " \
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/6] mx6cuboxi: Fix the defconfig name
From: Fabio Estevam The correct name of the defconfig file is 'mx6cuboxi_defconfig'. Signed-off-by: Fabio Estevam --- Changes since v3: - None board/solidrun/mx6cuboxi/MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/solidrun/mx6cuboxi/MAINTAINERS b/board/solidrun/mx6cuboxi/MAINTAINERS index 3d468ed..a3506c2 100644 --- a/board/solidrun/mx6cuboxi/MAINTAINERS +++ b/board/solidrun/mx6cuboxi/MAINTAINERS @@ -3,4 +3,4 @@ M: Fabio Estevam S: Maintained F: board/solidrun/mx6cuboxi/ F: include/configs/mx6cuboxi.h -F: configs/mx6cuboxi_spl_defconfig +F: configs/mx6cuboxi_defconfig -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Correct Minnowboard instructions to use the right descriptor
On Sat, Apr 25, 2015 at 11:46:43AM -0600, Simon Glass wrote: > The descriptor provided with the FSP does not seem to work. Update the > instructions to use the descriptor from the original Intel firmware. > > Signed-off-by: Simon Glass > --- > > doc/README.x86 | 23 --- > 1 file changed, 20 insertions(+), 3 deletions(-) > > diff --git a/doc/README.x86 b/doc/README.x86 > index 0355d1c..fe31f3d 100644 > --- a/doc/README.x86 > +++ b/doc/README.x86 > @@ -127,15 +127,32 @@ board/intel/minnowmax/fsp.bin > Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same > directory: board/intel/minnowmax/vga.bin > > -You still need two more binary blobs. These come from the sample SPI image > -provided in the FSP (SPI.bin at the time of writing). > +You still need two more binary blobs. The first comes from the original > +firmware image available from: > + > +http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip > + > +Unzip it: > + > + $ unzip 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip > > Use ifdtool in the U-Boot tools directory to extract the images from that > file, for example: > > + $ ./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin > + > +This will provide the descriptor file - copy this into the correct place: > + > + $ cp flashregion_0_flashdescriptor.bin > board/intel/minnowmax/descriptor.bin > + > +Then do the same with the sample SPI image provided in the FSP (SPI.bin at > +the time of writing) to obtain the last image. Note that this will also > +produce a flash descriptor file, but it does not seem to work, probably > +because it is not designed for the Minnowmax. That is why you need to get > +the flash descriptor from the original firmware as above. > + > $ ./tools/ifdtool -x BayleyBay/SPI.bin > $ cp flashregion_2_intel_me.bin board/intel/minnowmax/me.bin > - $ cp flashregion_0_flashdescriptor.bin > board/intel/minnowmax/descriptor.bin > > Now you can build U-Boot and obtain u-boot.rom + Then you ... to flash u-boot.rom ? :) Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Correct Minnowboard instructions to use the right descriptor
The descriptor provided with the FSP does not seem to work. Update the instructions to use the descriptor from the original Intel firmware. Signed-off-by: Simon Glass --- doc/README.x86 | 23 --- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/doc/README.x86 b/doc/README.x86 index 0355d1c..fe31f3d 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -127,15 +127,32 @@ board/intel/minnowmax/fsp.bin Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same directory: board/intel/minnowmax/vga.bin -You still need two more binary blobs. These come from the sample SPI image -provided in the FSP (SPI.bin at the time of writing). +You still need two more binary blobs. The first comes from the original +firmware image available from: + +http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip + +Unzip it: + + $ unzip 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip Use ifdtool in the U-Boot tools directory to extract the images from that file, for example: + $ ./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin + +This will provide the descriptor file - copy this into the correct place: + + $ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin + +Then do the same with the sample SPI image provided in the FSP (SPI.bin at +the time of writing) to obtain the last image. Note that this will also +produce a flash descriptor file, but it does not seem to work, probably +because it is not designed for the Minnowmax. That is why you need to get +the flash descriptor from the original firmware as above. + $ ./tools/ifdtool -x BayleyBay/SPI.bin $ cp flashregion_2_intel_me.bin board/intel/minnowmax/me.bin - $ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin Now you can build U-Boot and obtain u-boot.rom -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 2/3] driver/ddr/altera/: Add the sdram calibration portion
Hi!
> +++ b/drivers/ddr/altera/Makefile
> @@ -0,0 +1,12 @@
> +#
> +# (C) Copyright 2000-2003
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
Umm. Looks like nothing of Wolfgang's original code is remaining at this point,
you can delete this.
> +/**
> +
> **
> + ** NOTE: Special Rules for Globale Variables
> **
> + **
> **
They are global, not globale.
> + ** All global variables that are explicitly initialized (including
> **
> + ** explicitly initialized to zero), are only initialized once, during
> **
> + ** configuration time, and not again on reset. This means that they
> **
> + ** preserve their current contents across resets, which is needed for some
> **
> + ** special cases involving communication with external modules. In
> **
> + ** addition, this avoids paying the price to have the memory initialized,
> **
> + ** even for zeroed data, provided it is explicitly set to zero in the code,
> **
> + ** and doesn't rely on implicit initialization.
> **
Is this true for variables in this .c file, or for all of them?
> +/*
> + * Temporary workaround to place the initial stack pointer at a safe
> + * offset from end
> + */
> +asm(".global __alt_stack_pointer");
> +asm("__alt_stack_pointer = " __stringify(STACK_POINTER));
How is this different from normal variable?
> +/* For HPS running on actual hardware */
> +
> +#define DLEVEL 0
DEBUG_LEVEL?
> +/*
> + * space around comma is required for varargs macro to remove comma if args
> + * is empty
> + */
> +#define BFM_GBL_SET(field, value)
> +#define BFM_GBL_GET(field) ((long unsigned int)0)
> +#define BFM_STAGE(stage)
> +#define BFM_INC_VFIFO
> +#define COV(label)
I don't get the comment, or the macros. Can you just remove them?
Thanks,
Pavel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/5] mx6cuboxi: Load the correct 'fdt_file' variable
On 2015-04-25, Fabio Estevam wrote:
> On Sat, Apr 25, 2015 at 3:05 AM, Stefano Babic wrote:
>
>> Are you sure ? I think Fabio's intention is to have setenv fdt_file as
>> part of check_suffix, and it is not if you add a trailing \0
>
> That's correct.
Yes, I understood that intention, but there's no \0 in check_suffix now,
which means that whatever comes after the check_suffix code will be
appended to check_suffix. The check_suffix code needs a \0 to define
where it ends and the next line begins...
>>> and maybe should
>>> be indented to line up with the if statement:
>>>
>>> + "setenv fdt_file ${dts_prefix}${dts_suffix}\0" \
>>
>> If checkpatch does not complain...
>
> checkpatch did not complain, but for better readability I could do as
> Vagrant suggested and write it like:
>
> #define CONFIG_EXTRA_ENV_SETTINGS \
>"script=boot.scr\0" \
>"image=zImage\0" \
> - "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
> + "check_suffix=" \
> + "if is_hummingboard; then " \
> + "setenv dts_suffix -hummingboard.dtb;" \
> + "else " \
> + "setenv dts_suffix -cubox-i.dtb;" \
> + "fi; "\
> + "setenv fdt_file ${dts_prefix}${dts_suffix};" \
Just to be clearer about my earlier point, I think you really want the
\0 at the end of check_suffix:
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "check_suffix=" \
+ "if is_hummingboard; then " \
+ "setenv dts_suffix -hummingboard.dtb;" \
+ "else " \
+ "setenv dts_suffix -cubox-i.dtb;" \
+ "fi; "\
+ "setenv fdt_file ${dts_prefix}${dts_suffix}\0" \
I'm also wondering if "check_suffix" is a good description for the code;
It's actually setting the dts_suffix and fdt_file variables. Some of the
ti boards call their corresponding code "findfdt" which seems more
accurate, although something like "set_fdt_vars" might even more
appropriate.
Another minor point: the variables are actually working with dtb files,
not dts files. I think the dts_prefix/dts_suffix should probably be
named dtb_prefix/dtb_suffix or fdt_prefix/fdt_suffix.
And while I'm at it, Dare I make the case again for fdtfile
vs. fdt_file?
Thanks for working on getting hummingboard/cubox-i support into mainline
u-boot!
live well,
vagrant
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] mx6cuboxi: Load the correct 'fdt_file' variable
On Fri, Apr 24, 2015 at 08:46:55AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Instead of hardcoding the 'fdt_file' variable, let's detect the SoC and > board variant on the fly and change the dtb name. > > Based on a patch from Rabeeh Khoury. > > Signed-off-by: Rabeeh Khoury > Signed-off-by: Fabio Estevam I'm biased but I'd really like to see something like board/ti/am335x/board.c::board_late_init() where we use CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG and set board_name / board_rev and let the shell handle whatever else may come. This will make handling any future revs / board types easier and be more flexible. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/5] mx6cuboxi: Load the correct 'fdt_file' variable
On 2015-04-24, Stefano Babic wrote:
> On 25/04/2015 01:47, Vagrant Cascadian wrote:
>> On 2015-04-24, Fabio Estevam wrote:
>>> Instead of hardcoding the 'fdt_file' variable, let's detect the SoC and
>>> board variant on the fly and change the dtb name.
>> ...
>>> diff --git a/include/configs/mx6cuboxi.h b/include/configs/mx6cuboxi.h
>>> index 5d58b16..c3cf633 100644
>>> --- a/include/configs/mx6cuboxi.h
>>> +++ b/include/configs/mx6cuboxi.h
>> ...
>>> #define CONFIG_EXTRA_ENV_SETTINGS \
>>> "script=boot.scr\0" \
>>> "image=zImage\0" \
>>> - "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
>>> + "check_suffix=" \
>>> + "if is_hummingboard; then " \
>>> + "setenv dts_suffix -hummingboard.dtb;" \
>>> + "else " \
>>> + "setenv dts_suffix -cubox-i.dtb;" \
>>> + "fi; "\
>>> + "setenv fdt_file ${dts_prefix}${dts_suffix};" \
>>> "fdt_addr=0x1800\0" \
>>
>> The setenv fdt_file line needs to terminate with "\0",
>
> Are you sure ? I think Fabio's intention is to have setenv fdt_file as
> part of check_suffix, and it is not if you add a trailing \0
Well, if you don't append the \0, then fdt_addr=0x1800 is appended
to check_suffix, and fdt_addr is left unset... At least, that's what a
booted system showed.
live well,
vagrant
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fastboot boot base address behaviour
On Saturday, April 25, 2015 at 08:22:26 AM, Maxime Ripard wrote: > On Thu, Apr 23, 2015 at 02:00:01PM +0200, Marek Vasut wrote: > > On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote: > > > On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote: > > > > > I've been trying to use fastboot (and especially the boot command) > > > > > on sunxi recently, and got it to work pretty fine (apart from > > > > > PSCI, but that's another story). > > > > > > > > > > The only thing that worries me a bit is that by default, both the > > > > > fastboot tool and mkbootimg will generate an image with the kernel > > > > > address set to 0x10008000. > > > > > > > > Looks like MX6 DRAM base address, so this should definitelly not be > > > > fixed to this address here. The +0x8000 offset is the kernel load > > > > offset. > > > > > > > > > While it might work on some targets, it obviously doesn't on the > > > > > Allwinner SoCs that most of the time have the RAM mapped to > > > > > 0x400, which result in the kernel being relocated to some > > > > > address that is not in RAM, failing badly. > > > > > > > > Yep. > > > > > > > > > I would expect U-Boot to relocate the kernel to some reasonable > > > > > address, and not try to do something dumb by actually trusting > > > > > completely the boot image. > > > > > > > > I'd expect the image to be correct in the first place though ;-) > > > > > > > > > I guess one way to solve this would be to really treat 0x10008000 > > > > > as the default, and relocate the kernel to whatever value make > > > > > sense on the current platform (even though that needs to be > > > > > defined). > > > > > > > > > > That way, "fastboot boot zImage" would actually work out of the > > > > > box, without requiring to set the optional "-b" option to set the > > > > > kernel base address to some decent value. > > > > > > > > Then I'd say such "default" address should be something like > > > > 0x . > > > > > > I'd probably agree if we were on a perfect world :) > > > > > > But the fact is that the tools that are creating these boot.img in > > > Android all have this default, and *will* fill the kernel address > > > header to this value. > > > > > > https://android.googlesource.com/platform/system/core/+/master/fastboot > > > /fas tboot.cpp, line 72 > > > https://android.googlesource.com/platform/system/core/+/master/mkbootim > > > g/m kbootimg.c, line 112 > > > > > > So even if we send a patch to Android itself, that won't fix the tools > > > that are already in the source code of published Android versions, or > > > the packages bundled in the distribution. > > > > > > So I think that instead of blindly trusting these tools, U-Boot should > > > handle that address has the de facto default, even if it doesn't make > > > any sense :) > > > > OK, now I agree. Maybe we should fix both -- the tools and U-Boot. > > I'll try to cook up a patch, send it to AOSP and see how it goes. Ok, thank you! 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 3/4] sunxi: emac: Rename DMA_CPU_TRRESHOLD to EMAC_RX_BUFSIZE
On 25 April 2015 at 05:51, Hans de Goede wrote:
> Besides being spelled wron, the DMA_CPU_TRRESHOLD define actually has
:-)
> nothing to do with DMA as we only use mmio fifo access. Rename it to
> EMAC_RX_BUFSIZE to properly reflect what it does.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/net/sunxi_emac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass
>
> diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
> index 038f474..e43b1e7 100644
> --- a/drivers/net/sunxi_emac.c
> +++ b/drivers/net/sunxi_emac.c
> @@ -153,7 +153,7 @@ struct sunxi_sramc_regs {
> #define EMAC_CRCERR(0x1 << 4)
> #define EMAC_LENERR(0x3 << 5)
>
> -#define DMA_CPU_TRRESHOLD 2000
> +#define EMAC_RX_BUFSIZE2000
>
> struct emac_eth_dev {
> struct emac_regs *regs;
> @@ -455,7 +455,7 @@ static int _sunxi_emac_eth_recv(struct emac_eth_dev
> *priv, void *packet)
>
> /* Move data from EMAC */
> if (good_packet) {
> - if (rx_len > DMA_CPU_TRRESHOLD) {
> + if (rx_len > EMAC_RX_BUFSIZE) {
> printf("Received packet is too big (len=%d)\n",
> rx_len);
> return -EMSGSIZE;
> }
> --
> 2.3.5
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/5] mx6cuboxi: Load the correct 'fdt_file' variable
Hi Stefano and Vagrant,
On Sat, Apr 25, 2015 at 3:05 AM, Stefano Babic wrote:
> Are you sure ? I think Fabio's intention is to have setenv fdt_file as
> part of check_suffix, and it is not if you add a trailing \0
That's correct.
>
>> and maybe should
>> be indented to line up with the if statement:
>>
>> + "setenv fdt_file ${dts_prefix}${dts_suffix}\0" \
>
> If checkpatch does not complain...
checkpatch did not complain, but for better readability I could do as
Vagrant suggested and write it like:
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
- "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "check_suffix=" \
+ "if is_hummingboard; then " \
+ "setenv dts_suffix -hummingboard.dtb;" \
+ "else " \
+ "setenv dts_suffix -cubox-i.dtb;" \
+ "fi; "\
+ "setenv fdt_file ${dts_prefix}${dts_suffix};" \
I can send a v4 with such format.
Thanks,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] x86: minnowmax: use the correct NOR in the configuration
Hi,
Wrong command ... I sent a duplicate patch v2, you can ignore this one,
sorry.
Regards,
Gabriel
On 04/25/2015 08:19 AM, Gabriel Huau wrote:
The SPI NOR on the minnowboard max is a MICRON N25Q064A
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Update the dts to put the correct flash name
arch/x86/dts/minnowmax.dts | 2 +-
include/configs/minnowmax.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 3936e21..dd20b2c 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -94,7 +94,7 @@
compatible = "intel,ich";
spi-flash@0 {
reg = <0>;
- compatible = "sst,25vf016b", "spi-flash";
+ compatible = "stmicro,n25q064a", "spi-flash";
memory-map = <0xff80 0x0080>;
};
};
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 3c7b266..72393fa 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -43,7 +43,7 @@
#define CONFIG_SCSI_DEV_LIST\
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_VALLEYVIEW_SATA}
-#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SPI_FLASH_STMICRO
#define CONFIG_MMC
#define CONFIG_SDHCI
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] x86: minnowmax: use the correct NOR in the configuration
The SPI NOR on the minnowboard max is a MICRON N25Q064A
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Update the dts to put the correct flash name
arch/x86/dts/minnowmax.dts | 2 +-
include/configs/minnowmax.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 3936e21..dd20b2c 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -94,7 +94,7 @@
compatible = "intel,ich";
spi-flash@0 {
reg = <0>;
- compatible = "sst,25vf016b", "spi-flash";
+ compatible = "stmicro,n25q064a", "spi-flash";
memory-map = <0xff80 0x0080>;
};
};
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 3c7b266..72393fa 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -43,7 +43,7 @@
#define CONFIG_SCSI_DEV_LIST\
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_VALLEYVIEW_SATA}
-#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SPI_FLASH_STMICRO
#define CONFIG_MMC
#define CONFIG_SDHCI
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] x86: minnowmax: use the correct NOR in the configuration
The SPI NOR on the minnowboard max is a MICRON N25Q064A
Signed-off-by: Gabriel Huau
---
Changes for v2:
- Update the dts to put the correct flash name
arch/x86/dts/minnowmax.dts | 2 +-
include/configs/minnowmax.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 3936e21..dd20b2c 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -94,7 +94,7 @@
compatible = "intel,ich";
spi-flash@0 {
reg = <0>;
- compatible = "sst,25vf016b", "spi-flash";
+ compatible = "stmicro,n25q064a", "spi-flash";
memory-map = <0xff80 0x0080>;
};
};
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 3c7b266..72393fa 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -43,7 +43,7 @@
#define CONFIG_SCSI_DEV_LIST\
{PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_VALLEYVIEW_SATA}
-#define CONFIG_SPI_FLASH_SST
+#define CONFIG_SPI_FLASH_STMICRO
#define CONFIG_MMC
#define CONFIG_SDHCI
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] x86: ivybridge: Use reset_cpu()
Now that reset_cpu() functions correctly, use it instead of directly
accessing the port.
Signed-off-by: Simon Glass
---
arch/x86/cpu/ivybridge/cpu.c | 5 ++---
arch/x86/cpu/ivybridge/early_me.c | 7 +++
arch/x86/cpu/ivybridge/sdram.c| 3 +--
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
index 37f3731..a62b30e 100644
--- a/arch/x86/cpu/ivybridge/cpu.c
+++ b/arch/x86/cpu/ivybridge/cpu.c
@@ -92,7 +92,7 @@ static int set_flex_ratio_to_tdp_nominal(void)
/* Issue warm reset, will be "CPU only" due to soft reset data */
outb(0x0, PORT_RESET);
- outb(0x6, PORT_RESET);
+ outb(SYS_RST | RST_CPU, PORT_RESET);
cpu_hlt();
/* Not reached */
@@ -286,8 +286,7 @@ int print_cpuinfo(void)
/* System is not happy after keyboard reset... */
debug("Issuing CF9 warm reset\n");
- outb(0x6, 0xcf9);
- cpu_hlt();
+ reset_cpu();
}
/* Early chipset init required before RAM init can work */
diff --git a/arch/x86/cpu/ivybridge/early_me.c
b/arch/x86/cpu/ivybridge/early_me.c
index 356bbb4..0347197 100644
--- a/arch/x86/cpu/ivybridge/early_me.c
+++ b/arch/x86/cpu/ivybridge/early_me.c
@@ -183,9 +183,8 @@ int intel_early_me_init_done(u8 status)
}
/* Perform the requested reset */
- if (reset) {
- outb(reset, 0xcf9);
- cpu_hlt();
- }
+ if (reset)
+ reset_cpu();
+
return -1;
}
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index 9a6da37..42e1e60 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -393,8 +393,7 @@ int sdram_initialise(struct pei_data *pei_data)
/* If MRC data is not found we cannot continue S3 resume. */
if (pei_data->boot_mode == PEI_BOOT_RESUME && !pei_data->mrc_input) {
debug("Giving up in sdram_initialize: No MRC data\n");
- outb(0x6, PORT_RESET);
- cpu_hlt();
+ reset_cpu();
}
/* Pass console handler in pei_data */
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] x86: quark: Use reset_cpu()
Now that reset_cpu() functions correctly, use it instead of directly
accessing the port.
Signed-off-by: Simon Glass
---
arch/x86/cpu/quark/quark.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index e4b19c2..a5aa014 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -110,7 +110,7 @@ int print_cpuinfo(void)
void reset_cpu(ulong addr)
{
/* cold reset */
- outb(0x08, PORT_RESET);
+ x86_full_reset();
}
int cpu_mmc_init(bd_t *bis)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] x86: fsp: Use reset_cpu()
Now that reset_cpu() functions correctly, use it instead of directly
accessing the port on boards that use a Firmware Support Package (FSP).
Signed-off-by: Simon Glass
---
arch/x86/lib/fsp/fsp_common.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index f668259..001494d 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -17,13 +17,6 @@ int print_cpuinfo(void)
return default_print_cpuinfo();
}
-void reset_cpu(ulong addr)
-{
- /* cold reset */
- outb(0x06, PORT_RESET);
-}
-
-
int board_pci_post_scan(struct pci_controller *hose)
{
u32 status;
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] x86: Implement reset_cpu() correctly for modern CPUs
The existing code is pretty ancient and is unreliable on modern hardware.
Generally it will hang.
We can use port 0xcf9 to initiate reset on more modern hardware (say in the
last 10 years). Update the reset_cpu() function to do this, and add a new
'full reset' function to perform a full power cycle.
Signed-off-by: Simon Glass
---
arch/x86/cpu/cpu.c | 22 +-
arch/x86/include/asm/processor.h | 11 +++
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index c9614f1..13b3baa 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -380,21 +380,17 @@ void flush_cache(unsigned long dummy1, unsigned long
dummy2)
asm("wbinvd\n");
}
-void __attribute__ ((regparm(0))) generate_gpf(void);
-
-/* segment 0x70 is an arbitrary segment which does not exist */
-asm(".globl generate_gpf\n"
- ".hidden generate_gpf\n"
- ".type generate_gpf, @function\n"
- "generate_gpf:\n"
- "ljmp $0x70, $0x47114711\n");
-
__weak void reset_cpu(ulong addr)
{
- printf("Resetting using x86 Triple Fault\n");
- set_vector(13, generate_gpf); /* general protection fault handler */
- set_vector(8, generate_gpf);/* double fault handler */
- generate_gpf(); /* start the show */
+ /* Do a hard reset through the chipset's reset control register */
+ outb(SYS_RST | RST_CPU, PORT_RESET);
+ for (;;)
+ cpu_hlt();
+}
+
+void x86_full_reset(void)
+{
+ outb(FULL_RST, PORT_RESET);
}
int dcache_status(void)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 3e26202..a24028d 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -27,6 +27,17 @@
#define PORT_RESET 0xcf9
+enum {
+ SYS_RST = 1 << 1, /* clear for soft reset, set for hard */
+ RST_CPU = 1 << 2, /* initiate reset */
+ FULL_RST= 1 << 3, /* full power cycle */
+};
+
+/**
+ * x86_full_reset() - reset everything: perform a full power cycle
+ */
+void x86_full_reset(void);
+
static inline __attribute__((always_inline)) void cpu_hlt(void)
{
asm("hlt");
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Testing u-boot-dm/next
Hi Stephen, On 24 April 2015 at 22:46, Stephen Warren wrote: > On 04/08/2015 09:11 PM, Simon Glass wrote: >> (Correcting address for Masahiro, sorry) >> >> On 8 April 2015 at 21:07, Simon Glass wrote: >> >>> Hi, >>> >>> I have quite a few patches queued up in the next branch of u-boot-dm, >>> ready for when the merge window options. >>> >>> If anyone has time and can give it a spin on their board, it would be much >>> appreciated! > > I assume this has been merged into u-boot/master now. FWIW, commit > d8c1d5d5fb6e "Merge branch 'buildman' of git://git.denx.de/u-boot-x86" > from there seems to work fine on the RPi. Thanks for the follow-up, good to hear. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: core: drop device removal error path correctly
On 24 April 2015 at 07:04, Simon Glass wrote: > On 24 April 2015 at 02:28, Masahiro Yamada > wrote: >> Trivial bug fix for commit 5a87c4174d18 (dm: core: Drop device >> removal error path when not supported). >> >> Signed-off-by: Masahiro Yamada >> --- >> >> drivers/core/device.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > Thanks Masahiro. Not enough test coverage around unbinding devices! > > Acked-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] serial: ns16550: Remove hard-coded baud_divisor setting
On 24 April 2015 at 21:05, Simon Glass wrote: > > On Apr 24, 2015 8:53 PM, "Axel Lin" wrote: >> >> This was accidentally added by commit dd0b0122bacc >> "serial: ns16550: Add an option to specify the debug UART register shift". >> Remove it. >> >> Signed-off-by: Axel Lin >> --- >> drivers/serial/ns16550.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c >> index fd110b3..3d376d7 100644 >> --- a/drivers/serial/ns16550.c >> +++ b/drivers/serial/ns16550.c >> @@ -255,7 +255,6 @@ void debug_uart_init(void) >> */ >> baud_divisor = calc_divisor(com_port, CONFIG_DEBUG_UART_CLOCK, >> CONFIG_BAUDRATE); >> - baud_divisor = 13; >> serial_out_shift(&com_port->ier, CONFIG_DEBUG_UART_SHIFT, >> CONFIG_SYS_NS16550_IER); >> serial_out_shift(&com_port->mcr, CONFIG_DEBUG_UART_SHIFT, >> UART_MCRVAL); >> -- >> 2.1.0 >> >> >> > > Acked-by: Simon Glass Applied to u-boot-dm, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] biosemu: Do not free vga_info->BIOSImage when it is 0xc0000
On 24 April 2015 at 21:54, Simon Glass wrote: > On 24 April 2015 at 06:40, Simon Glass wrote: >> On 24 April 2015 at 01:48, Bin Meng wrote: >>> For x86, vga_info->BIOSImage points to 0xc which cannot be freed. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> drivers/bios_emulator/atibios.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> Acked-by: Simon Glass > > Acked-by: Simon Glass Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] x86: Write configuration tables in last_stage_init()
On 24 April 2015 at 04:10, Bin Meng wrote: > We can write the configuration table in last_stage_init() for all x86 > boards, but not with coreboot since coreboot already has them. > > Signed-off-by: Bin Meng > Acked-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/cpu/cpu.c| 10 + > arch/x86/include/asm/tables.h | 49 > +++ > arch/x86/lib/Makefile | 1 + > arch/x86/lib/tables.c | 30 ++ > include/configs/x86-common.h | 1 + > 5 files changed, 91 insertions(+) > create mode 100644 arch/x86/include/asm/tables.h > create mode 100644 arch/x86/lib/tables.c Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] x86: Support platform PIRQ routing
On 24 April 2015 at 04:10, Bin Meng wrote: > On x86 boards, platform chipset receives up to four different > interrupt signals from PCI devices (INTA/B/C/D), which in turn > will be routed to chipset internal PIRQ lines then routed to > 8259 PIC finally if configuring the whole system to work under > the so-called PIC mode (in contrast to symmetric IO mode which > uses IOAPIC). > > We add two major APIs to aid this, one for routing PIRQ and the > other one for generating a PIRQ routing table. > > Signed-off-by: Bin Meng > Acked-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/Kconfig| 31 > arch/x86/include/asm/pirq_routing.h | 139 > > arch/x86/lib/Makefile | 1 + > arch/x86/lib/pirq_routing.c | 129 + > 4 files changed, 300 insertions(+) > create mode 100644 arch/x86/include/asm/pirq_routing.h > create mode 100644 arch/x86/lib/pirq_routing.c Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] pci: Remove parameter 'class' of pci_rom_load()
On 24 April 2015 at 06:40, Simon Glass wrote: > On 24 April 2015 at 01:48, Bin Meng wrote: >> pci_rom_load() does not use its parameter 'class', so remove it. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci_rom.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > Acked-by: Simon Glass Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] pci: Option rom class is a 24-bit number
On 24 April 2015 at 21:54, Simon Glass wrote: > On 24 April 2015 at 01:48, Bin Meng wrote: >> We should pass a u32 class number to pci_rom_probe() instead of a u16. >> >> Signed-off-by: Bin Meng >> --- >> >> drivers/pci/pci_rom.c | 20 +++- >> 1 file changed, 11 insertions(+), 9 deletions(-) > > Acked-by: Simon Glass Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] x86: queensbay: Implement PIRQ routing
On 24 April 2015 at 06:40, Simon Glass wrote: > On 24 April 2015 at 04:10, Bin Meng wrote: >> Implement Intel Queensbay platform-specific PIRQ routing support. >> The chipset PIRQ routing setup is called in the arch_misc_init(). >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - Correct a typo in the commit message >> - Use a local variable in fill_irq_info() >> - Print a debug message if creating pirq table fails >> - Use a C structure for RCBA register access >> >> arch/x86/cpu/queensbay/Makefile | 2 +- >> arch/x86/cpu/queensbay/irq.c | 242 >> +++ >> arch/x86/cpu/queensbay/tnc.c | 10 +- >> arch/x86/include/asm/arch-queensbay/device.h | 94 +++ >> arch/x86/include/asm/arch-queensbay/irq.h| 55 ++ >> arch/x86/include/asm/arch-queensbay/tnc.h| 39 - >> arch/x86/include/asm/u-boot-x86.h| 2 + >> configs/crownbay_defconfig | 1 + >> include/configs/crownbay.h | 1 + >> 9 files changed, 442 insertions(+), 4 deletions(-) >> create mode 100644 arch/x86/cpu/queensbay/irq.c >> create mode 100644 arch/x86/include/asm/arch-queensbay/device.h >> create mode 100644 arch/x86/include/asm/arch-queensbay/irq.h > > Acked-by: Simon Glass Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] x86: Install a default e820 table in the __weak install_e820_map()
On 23 April 2015 at 20:41, Simon Glass wrote:
> Hi Bin,
>
> On 21 April 2015 at 19:01, Bin Meng wrote:
>> Hi Simon,
>>
>> On Tue, Apr 21, 2015 at 9:52 PM, Simon Glass wrote:
>>> Hi Bin,
>>>
>>> On 20 April 2015 at 22:21, Bin Meng wrote:
Create a default e820 table with 3 entries which is enough to boot
a Linux kernel.
Signed-off-by: Bin Meng
---
arch/x86/lib/zimage.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 566b048..c3f8a73 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -25,6 +25,8 @@
#endif
#include
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* Memory lay-out:
*
@@ -40,16 +42,29 @@
#define COMMAND_LINE_SIZE 2048
-unsigned generic_install_e820_map(unsigned max_entries,
- struct e820entry *entries)
+/*
+ * Install a default e820 table with 3 entries as follows:
+ *
+ * 0x00-0x0a Useable RAM
+ * 0x0a-0x10 Reserved for ISA
+ * 0x10-gd->ram_size Useable RAM
+ */
+__weak unsigned install_e820_map(unsigned max_entries,
+struct e820entry *entries)
{
- return 0;
+ entries[0].addr = 0;
+ entries[0].size = ISA_START_ADDRESS;
+ entries[0].type = E820_RAM;
+ entries[1].addr = ISA_START_ADDRESS;
+ entries[1].size = ISA_END_ADDRESS - ISA_START_ADDRESS;
+ entries[1].type = E820_RESERVED;
+ entries[2].addr = ISA_END_ADDRESS;
+ entries[2].size = gd->ram_size - ISA_END_ADDRESS;
+ entries[2].type = E820_RAM;
+
+ return 3;
}
-unsigned install_e820_map(unsigned max_entries,
- struct e820entry *entries)
- __attribute__((weak, alias("generic_install_e820_map")));
-
static void build_command_line(char *command_line, int auto_boot)
{
char *env_command_line;
--
1.8.2.1
>>>
>>> Why is this code sitting in zimage.c? Should it be used with bootm also?
>>
>> Sorry I am not sure I understand your point. setup_zimage() is called
>> by boot_prep_linux() in bootm.c.
>
> I mean that install_e820_map() seems to be unrelated to zimage, and is
> perhaps better kept in a more generic place, perhaps
> arch/x86/lib/bootm.c or even arch/x86/lib/e820. Anyway let's apply
> this and we can figure that out later.
>
> Acked-by: Simon Glass
>
> Regards,
> Simon
Applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] x86: Clean up arch/x86/include/asm/e820.h
On 21 April 2015 at 07:55, Simon Glass wrote: > On 20 April 2015 at 22:21, Bin Meng wrote: >> There are lots of unused codes defined in e820.h, clean it up. >> >> Signed-off-by: Bin Meng >> --- >> >> arch/x86/include/asm/e820.h | 133 >> +--- >> 1 file changed, 2 insertions(+), 131 deletions(-) > > Acked-by: Simon Glass Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] x86: Add a function to assign IRQ numbers to PCI device
On 24 April 2015 at 04:10, Bin Meng wrote: > Add a function to assign an IRQ number to PCI device's interrupt > line register in its configuration space, so that the PCI device > can have its interrupt working under PIC mode after OS boots up. > > Signed-off-by: Bin Meng > Acked-by: Simon Glass > --- > > Changes in v2: None > > arch/x86/cpu/pci.c | 21 + > arch/x86/include/asm/pci.h | 14 ++ > 2 files changed, 35 insertions(+) Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] i2c: mxc: refactor i2c driver and support dm
1. Introduce a new structure `struct mxc_i2c_bus`, this structure will
used for non-DM and DM.
1. Remove `struct mxc_i2c_regs` structure, but use register offset to access
registers based on `base` entry of `struct mxc_i2c_bus`.
2. Remove most `#ifdef I2C_QUIRK_REG`. Using driver_data to contain platform
flags. A new flag is introduced, I2C_QUIRK_FLAG.
3. Most functions use `struct mxc_i2c_bus` as one of the parameters.
4. Support DM
5. Make most functions common to DM and non-DM, try to avoid duplicated code.
6. struct i2c_parms and struct sram_data are removed, since we move to use
struct mxc_i2c_regs.
7. Remove bus_i2c_read bus_i2c_write prototype in header file
8. The frist paramter of bus_i2c_init is modified to i2c index, since
bus_i2c_init is a must now, so it is also implemented for DM part.
Signed-off-by: Peng Fan
---
Changes v2:
This patch is a big change from v1 patch.
1. Refactor driver, remove register access based on structure, but use
'base + offset'
2. Introduce mxc_i2c_bus structure
3. Introduce I2C_QUIRK_FLAG and remove most I2C_QUIRK_REG and use
driver_data to contain the flags for different platforms
4. Avoid duplicated code between DM and non-DM part
5. The function name i2c_init_transfer is not changed.
6. Remove bus_i2c_read/write prototype from header file
7. change bus_i2c_init's first parameter to i2c index
8. Rename patch name, since refactor non-DM part.
arch/arm/imx-common/i2c-mxv7.c| 3 +-
arch/arm/include/asm/imx-common/mxc_i2c.h | 6 +-
drivers/i2c/mxc_i2c.c | 585 --
3 files changed, 402 insertions(+), 192 deletions(-)
diff --git a/arch/arm/imx-common/i2c-mxv7.c b/arch/arm/imx-common/i2c-mxv7.c
index 1a632e7..3c793ef 100644
--- a/arch/arm/imx-common/i2c-mxv7.c
+++ b/arch/arm/imx-common/i2c-mxv7.c
@@ -99,8 +99,7 @@ int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
if (ret)
goto err_idle;
- bus_i2c_init(i2c_bases[i2c_index], speed, slave_addr,
- force_idle_bus, p);
+ bus_i2c_init(i2c_index, speed, slave_addr, force_idle_bus, p);
return 0;
diff --git a/arch/arm/include/asm/imx-common/mxc_i2c.h
b/arch/arm/include/asm/imx-common/mxc_i2c.h
index af86163..94b085f 100644
--- a/arch/arm/include/asm/imx-common/mxc_i2c.h
+++ b/arch/arm/include/asm/imx-common/mxc_i2c.h
@@ -54,10 +54,6 @@ struct i2c_pads_info {
int setup_i2c(unsigned i2c_index, int speed, int slave_addr,
struct i2c_pads_info *p);
-void bus_i2c_init(void *base, int speed, int slave_addr,
+void bus_i2c_init(int index, int speed, int slave_addr,
int (*idle_bus_fn)(void *p), void *p);
-int bus_i2c_read(void *base, uchar chip, uint addr, int alen, uchar *buf,
- int len);
-int bus_i2c_write(void *base, uchar chip, uint addr, int alen,
- const uchar *buf, int len);
#endif
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index fc5ee35..9894f3e 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -21,26 +21,21 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
-#ifdef I2C_QUIRK_REG
-struct mxc_i2c_regs {
- uint8_t iadr;
- uint8_t ifdr;
- uint8_t i2cr;
- uint8_t i2sr;
- uint8_t i2dr;
-};
-#else
-struct mxc_i2c_regs {
- uint32_tiadr;
- uint32_tifdr;
- uint32_ti2cr;
- uint32_ti2sr;
- uint32_ti2dr;
-};
-#endif
+#define I2C_QUIRK_FLAG (1 << 0)
+
+#define IMX_I2C_REGSHIFT 2
+#define VF610_I2C_REGSHIFT 0
+/* Register index */
+#define IADR 0
+#define IFDR 1
+#define I2CR 2
+#define I2SR 3
+#define I2DR 4
#define I2CR_IIEN (1 << 6)
#define I2CR_MSTA (1 << 5)
@@ -68,6 +63,23 @@ struct mxc_i2c_regs {
#error "define CONFIG_SYS_I2C_BASE to use the mxc_i2c driver"
#endif
+/*
+ * Information about i2c controller
+ * struct mxc_i2c_bus - information about the i2c[x] bus
+ * @base: Address of I2C bus controller
+ * @speed: Speed of I2C bus
+ * @driver_data: Flags for different platforms, such as I2C_QUIRK_FLAG.
+ * @idle_bus_fn: function to force bus idle
+ * @idle_bus_data: parameter for idle_bus_fun
+ */
+struct mxc_i2c_bus {
+ ulong base;
+ ulong driver_data;
+ int speed;
+ int (*idle_bus_fn)(void *p);
+ void *idle_bus_data;
+};
+
#ifdef I2C_QUIRK_REG
static u16 i2c_clk_div[60][2] = {
{ 20, 0x00 }, { 22, 0x01 }, { 24, 0x02 }, { 26, 0x03 },
@@ -104,7 +116,6 @@ static u16 i2c_clk_div[50][2] = {
};
#endif
-
#ifndef CONFIG_SYS_MXC_I2C1_SPEED
#define CONFIG_SYS_MXC_I2C1_SPEED 10
#endif
@@ -125,11 +136,10 @@ static u16 i2c_clk_div[50][2] = {
#define CONFIG_SYS_MXC_I2C3_SLAVE 0
#endif
-
/*
* Calculate and set proper clock divider
*/
-static uint8_t i2c_imx_get_clk(unsigned int rate)
+static uint8_
[U-Boot] [PATCH v2 2/4] sunxi: emac: Prepare for driver-model support
Split all the core functionality out into functions taking a
struct emac_eth_dev *priv argument as preparation for adding driver-model
support.
Signed-off-by: Hans de Goede
---
drivers/net/sunxi_emac.c | 115 +--
1 file changed, 71 insertions(+), 44 deletions(-)
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index b9fd1b8..038f474 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -309,9 +309,9 @@ static void emac_setup(struct emac_eth_dev *priv)
writel(EMAC_MAC_MFL, ®s->mac_maxf);
}
-static void emac_reset(struct eth_device *dev)
+static void emac_reset(struct emac_eth_dev *priv)
{
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ struct emac_regs *regs = priv->regs;
debug("resetting device\n");
@@ -323,10 +323,9 @@ static void emac_reset(struct eth_device *dev)
udelay(200);
}
-static int sunxi_emac_eth_init(struct eth_device *dev, bd_t *bd)
+static int _sunxi_emac_eth_init(struct emac_eth_dev *priv, u8 *enetaddr)
{
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
- struct emac_eth_dev *priv = dev->priv;
+ struct emac_regs *regs = priv->regs;
int ret;
/* Init EMAC */
@@ -347,14 +346,14 @@ static int sunxi_emac_eth_init(struct eth_device *dev,
bd_t *bd)
/* Set up EMAC */
emac_setup(priv);
- writel(dev->enetaddr[0] << 16 | dev->enetaddr[1] << 8 |
- dev->enetaddr[2], ®s->mac_a1);
- writel(dev->enetaddr[3] << 16 | dev->enetaddr[4] << 8 |
- dev->enetaddr[5], ®s->mac_a0);
+ writel(enetaddr[0] << 16 | enetaddr[1] << 8 | enetaddr[2],
+ ®s->mac_a1);
+ writel(enetaddr[3] << 16 | enetaddr[4] << 8 | enetaddr[5],
+ ®s->mac_a0);
mdelay(1);
- emac_reset(dev);
+ emac_reset(priv);
/* PHY POWER UP */
ret = phy_startup(priv->phydev);
@@ -390,14 +389,9 @@ static int sunxi_emac_eth_init(struct eth_device *dev,
bd_t *bd)
return 0;
}
-static void sunxi_emac_eth_halt(struct eth_device *dev)
+static int _sunxi_emac_eth_recv(struct emac_eth_dev *priv, void *packet)
{
- /* Nothing to do here */
-}
-
-static int sunxi_emac_eth_recv(struct eth_device *dev)
-{
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ struct emac_regs *regs = priv->regs;
struct emac_rxhdr rxhdr;
u32 rxcount;
u32 reg_val;
@@ -415,7 +409,7 @@ static int sunxi_emac_eth_recv(struct eth_device *dev)
/* Had one stuck? */
rxcount = readl(®s->rx_fbc);
if (!rxcount)
- return 0;
+ return -EAGAIN;
}
reg_val = readl(®s->rx_io_data);
@@ -431,7 +425,7 @@ static int sunxi_emac_eth_recv(struct eth_device *dev)
/* Enable RX */
setbits_le32(®s->ctl, 0x1 << 2);
- return 0;
+ return -EAGAIN;
}
/* A packet ready now
@@ -463,22 +457,19 @@ static int sunxi_emac_eth_recv(struct eth_device *dev)
if (good_packet) {
if (rx_len > DMA_CPU_TRRESHOLD) {
printf("Received packet is too big (len=%d)\n", rx_len);
- } else {
- emac_inblk_32bit((void *)®s->rx_io_data,
-net_rx_packets[0], rx_len);
-
- /* Pass to upper layer */
- net_process_received_packet(net_rx_packets[0], rx_len);
- return rx_len;
+ return -EMSGSIZE;
}
+ emac_inblk_32bit((void *)®s->rx_io_data, packet, rx_len);
+ return rx_len;
}
- return 0;
+ return -EIO; /* Bad packet */
}
-static int sunxi_emac_eth_send(struct eth_device *dev, void *packet, int len)
+static int _sunxi_emac_eth_send(struct emac_eth_dev *priv, void *packet,
+ int len)
{
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ struct emac_regs *regs = priv->regs;
/* Select channel 0 */
writel(0, ®s->tx_ins);
@@ -495,17 +486,64 @@ static int sunxi_emac_eth_send(struct eth_device *dev,
void *packet, int len)
return 0;
}
-int sunxi_emac_initialize(void)
+static void sunxi_emac_board_setup(struct emac_eth_dev *priv)
{
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
struct sunxi_sramc_regs *sram =
(struct sunxi_sramc_regs *)SUNXI_SRAMC_BASE;
+ struct emac_regs *regs = priv->regs;
+ int pin;
+
+ /* Map SRAM to EMAC */
+ setbits_le32(&sram->ctrl1, 0x5 << 2);
+
+ /* Configure pin mux settings for MII Ethernet */
+ for (pin = SUNXI_GPA(0); pin <= SUNXI_GPA(17); pin++)
+ sunxi_gpio_set_cfgpin(pin, SUNXI_GPA_EMAC);
+
+
[U-Boot] [PATCH v2 1/4] sunxi: emac: port to phylib
This is a preparation-patch for adding device-model support to the emac
driver.
Signed-off-by: Hans de Goede
---
drivers/net/sunxi_emac.c | 111 +
include/configs/sunxi-common.h | 2 +
2 files changed, 71 insertions(+), 42 deletions(-)
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index 7b31f8c..b9fd1b8 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -156,9 +156,9 @@ struct sunxi_sramc_regs {
#define DMA_CPU_TRRESHOLD 2000
struct emac_eth_dev {
- u32 speed;
- u32 duplex;
- u32 phy_configured;
+ struct emac_regs *regs;
+ struct mii_dev *bus;
+ struct phy_device *phydev;
int link_printed;
};
@@ -195,11 +195,10 @@ static void emac_outblk_32bit(void *reg, void *data, int
count)
}
/* Read a word from phyxcer */
-static int emac_phy_read(const char *devname, unsigned char addr,
- unsigned char reg, unsigned short *value)
+static int emac_mdio_read(struct mii_dev *bus, int addr, int devad, int reg)
{
- struct eth_device *dev = eth_get_dev_by_name(devname);
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ struct emac_eth_dev *priv = bus->priv;
+ struct emac_regs *regs = priv->regs;
/* issue the phy address and reg */
writel(addr << 8 | reg, ®s->mac_madr);
@@ -213,18 +212,16 @@ static int emac_phy_read(const char *devname, unsigned
char addr,
/* push down the phy io line */
writel(0x0, ®s->mac_mcmd);
- /* and write data */
- *value = readl(®s->mac_mrdd);
-
- return 0;
+ /* And read data */
+ return readl(®s->mac_mrdd);
}
/* Write a word to phyxcer */
-static int emac_phy_write(const char *devname, unsigned char addr,
- unsigned char reg, unsigned short value)
+static int emac_mdio_write(struct mii_dev *bus, int addr, int devad, int reg,
+ u16 value)
{
- struct eth_device *dev = eth_get_dev_by_name(devname);
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ struct emac_eth_dev *priv = bus->priv;
+ struct emac_regs *regs = priv->regs;
/* issue the phy address and reg */
writel(addr << 8 | reg, ®s->mac_madr);
@@ -244,12 +241,44 @@ static int emac_phy_write(const char *devname, unsigned
char addr,
return 0;
}
-static void emac_setup(struct eth_device *dev)
+static int sunxi_emac_init_phy(struct emac_eth_dev *priv, void *dev)
{
- struct emac_regs *regs = (struct emac_regs *)dev->iobase;
+ int ret, mask = 0x;
+
+#ifdef CONFIG_PHY_ADDR
+ mask = 1 << CONFIG_PHY_ADDR;
+#endif
+
+ priv->bus = mdio_alloc();
+ if (!priv->bus) {
+ printf("Failed to allocate MDIO bus\n");
+ return -ENOMEM;
+ }
+
+ priv->bus->read = emac_mdio_read;
+ priv->bus->write = emac_mdio_write;
+ priv->bus->priv = priv;
+ strcpy(priv->bus->name, "emac");
+
+ ret = mdio_register(priv->bus);
+ if (ret)
+ return ret;
+
+ priv->phydev = phy_find_by_mask(priv->bus, mask,
+ PHY_INTERFACE_MODE_MII);
+ if (!priv->phydev)
+ return -ENODEV;
+
+ phy_connect_dev(priv->phydev, dev);
+ phy_config(priv->phydev);
+
+ return 0;
+}
+
+static void emac_setup(struct emac_eth_dev *priv)
+{
+ struct emac_regs *regs = priv->regs;
u32 reg_val;
- u16 phy_val;
- u32 duplex_flag;
/* Set up TX */
writel(EMAC_TX_SETUP, ®s->tx_mode);
@@ -262,12 +291,8 @@ static void emac_setup(struct eth_device *dev)
writel(EMAC_MAC_CTL0_SETUP, ®s->mac_ctl0);
/* Set MAC CTL1 */
- emac_phy_read(dev->name, 1, 0, &phy_val);
- debug("PHY SETUP, reg 0 value: %x\n", phy_val);
- duplex_flag = !!(phy_val & (1 << 8));
-
reg_val = 0;
- if (duplex_flag)
+ if (priv->phydev->duplex == DUPLEX_FULL)
reg_val = (0x1 << 0);
writel(EMAC_MAC_CTL1_SETUP | reg_val, ®s->mac_ctl1);
@@ -302,7 +327,7 @@ static int sunxi_emac_eth_init(struct eth_device *dev, bd_t
*bd)
{
struct emac_regs *regs = (struct emac_regs *)dev->iobase;
struct emac_eth_dev *priv = dev->priv;
- u16 phy_reg;
+ int ret;
/* Init EMAC */
@@ -320,7 +345,7 @@ static int sunxi_emac_eth_init(struct eth_device *dev, bd_t
*bd)
udelay(1);
/* Set up EMAC */
- emac_setup(dev);
+ emac_setup(priv);
writel(dev->enetaddr[0] << 16 | dev->enetaddr[1] << 8 |
dev->enetaddr[2], ®s->mac_a1);
@@ -332,29 +357,32 @@ static int sunxi_emac_eth_init(struct eth_device *dev,
bd_t *bd)
emac_reset(dev);
/* PHY POWER UP */
- emac_phy_read(dev->name, 1, 0, &phy_reg);
- emac_phy_write(dev->name, 1, 0, phy_reg & (~(0x1 << 11)));
- mdelay
[U-Boot] [PATCH v2 0/4] sunxi: emac: Add driver model support
Hi All, Here is v2 of my patch series to add driver model support to the sunxi emac driver. Changes since v1: -Add a patch to rename DMA_CPU_TRRESHOLD to EMAC_RX_BUFSIZE. Please review. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] sunxi: emac: Rename DMA_CPU_TRRESHOLD to EMAC_RX_BUFSIZE
Besides being spelled wron, the DMA_CPU_TRRESHOLD define actually has
nothing to do with DMA as we only use mmio fifo access. Rename it to
EMAC_RX_BUFSIZE to properly reflect what it does.
Signed-off-by: Hans de Goede
---
drivers/net/sunxi_emac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index 038f474..e43b1e7 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -153,7 +153,7 @@ struct sunxi_sramc_regs {
#define EMAC_CRCERR(0x1 << 4)
#define EMAC_LENERR(0x3 << 5)
-#define DMA_CPU_TRRESHOLD 2000
+#define EMAC_RX_BUFSIZE2000
struct emac_eth_dev {
struct emac_regs *regs;
@@ -455,7 +455,7 @@ static int _sunxi_emac_eth_recv(struct emac_eth_dev *priv,
void *packet)
/* Move data from EMAC */
if (good_packet) {
- if (rx_len > DMA_CPU_TRRESHOLD) {
+ if (rx_len > EMAC_RX_BUFSIZE) {
printf("Received packet is too big (len=%d)\n", rx_len);
return -EMSGSIZE;
}
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] sunxi: emac: Add driver model support
Modify the sunxi-emac eth driver to support driver model.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/board.c | 4 +-
drivers/net/sunxi_emac.c | 81
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 7e9cf11..cde13ef 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -12,7 +12,9 @@
#include
#include
+#ifndef CONFIG_DM_ETH
#include
+#endif
#include
#include
#ifdef CONFIG_SPL_BUILD
@@ -224,7 +226,7 @@ int cpu_eth_init(bd_t *bis)
mdelay(200);
#endif
-#ifdef CONFIG_SUNXI_EMAC
+#if defined CONFIG_SUNXI_EMAC && !defined CONFIG_DM_ETH
rc = sunxi_emac_initialize(bis);
if (rc < 0) {
printf("sunxi: failed to initialize emac\n");
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index e43b1e7..306a022 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -160,6 +161,9 @@ struct emac_eth_dev {
struct mii_dev *bus;
struct phy_device *phydev;
int link_printed;
+#ifdef CONFIG_DM_ETH
+ uchar rx_buf[EMAC_RX_BUFSIZE];
+#endif
};
struct emac_rxhdr {
@@ -509,6 +513,7 @@ static void sunxi_emac_board_setup(struct emac_eth_dev
*priv)
clrsetbits_le32(®s->mac_mcfg, 0xf << 2, 0xd << 2);
}
+#ifndef CONFIG_DM_ETH
static int sunxi_emac_eth_init(struct eth_device *dev, bd_t *bis)
{
return _sunxi_emac_eth_init(dev->priv, dev->enetaddr);
@@ -573,3 +578,79 @@ int sunxi_emac_initialize(void)
return sunxi_emac_init_phy(priv, dev);
}
+#endif
+
+#ifdef CONFIG_DM_ETH
+static int sunxi_emac_eth_start(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ return _sunxi_emac_eth_init(dev->priv, pdata->enetaddr);
+}
+
+static int sunxi_emac_eth_send(struct udevice *dev, void *packet, int length)
+{
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+
+ return _sunxi_emac_eth_send(priv, packet, length);
+}
+
+static int sunxi_emac_eth_recv(struct udevice *dev, uchar **packetp)
+{
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+ int rx_len;
+
+ rx_len = _sunxi_emac_eth_recv(priv, priv->rx_buf);
+ *packetp = priv->rx_buf;
+
+ return rx_len;
+}
+
+static void sunxi_emac_eth_stop(struct udevice *dev)
+{
+ /* Nothing to do here */
+}
+
+static int sunxi_emac_eth_probe(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+
+ priv->regs = (struct emac_regs *)pdata->iobase;
+ sunxi_emac_board_setup(priv);
+
+ return sunxi_emac_init_phy(priv, dev);
+}
+
+static const struct eth_ops sunxi_emac_eth_ops = {
+ .start = sunxi_emac_eth_start,
+ .send = sunxi_emac_eth_send,
+ .recv = sunxi_emac_eth_recv,
+ .stop = sunxi_emac_eth_stop,
+};
+
+static int sunxi_emac_eth_ofdata_to_platdata(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ pdata->iobase = dev_get_addr(dev);
+
+ return 0;
+}
+
+static const struct udevice_id sunxi_emac_eth_ids[] = {
+ { .compatible = "allwinner,sun4i-a10-emac" },
+ { }
+};
+
+U_BOOT_DRIVER(eth_sunxi_emac) = {
+ .name = "eth_sunxi_emac",
+ .id = UCLASS_ETH,
+ .of_match = sunxi_emac_eth_ids,
+ .ofdata_to_platdata = sunxi_emac_eth_ofdata_to_platdata,
+ .probe = sunxi_emac_eth_probe,
+ .ops= &sunxi_emac_eth_ops,
+ .priv_auto_alloc_size = sizeof(struct emac_eth_dev),
+ .platdata_auto_alloc_size = sizeof(struct eth_pdata),
+};
+#endif
--
2.3.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fastboot boot base address behaviour
On Thu, Apr 23, 2015 at 02:00:01PM +0200, Marek Vasut wrote: > On Thursday, April 23, 2015 at 09:41:04 AM, Maxime Ripard wrote: > > On Wed, Apr 22, 2015 at 05:56:23PM +0200, Marek Vasut wrote: > > > > I've been trying to use fastboot (and especially the boot command) on > > > > sunxi recently, and got it to work pretty fine (apart from PSCI, but > > > > that's another story). > > > > > > > > The only thing that worries me a bit is that by default, both the > > > > fastboot tool and mkbootimg will generate an image with the kernel > > > > address set to 0x10008000. > > > > > > Looks like MX6 DRAM base address, so this should definitelly not be > > > fixed to this address here. The +0x8000 offset is the kernel load > > > offset. > > > > > > > While it might work on some targets, it obviously doesn't on the > > > > Allwinner SoCs that most of the time have the RAM mapped to 0x400, > > > > which result in the kernel being relocated to some address that is not > > > > in RAM, failing badly. > > > > > > Yep. > > > > > > > I would expect U-Boot to relocate the kernel to some reasonable > > > > address, and not try to do something dumb by actually trusting > > > > completely the boot image. > > > > > > I'd expect the image to be correct in the first place though ;-) > > > > > > > I guess one way to solve this would be to really treat 0x10008000 as > > > > the default, and relocate the kernel to whatever value make sense on > > > > the current platform (even though that needs to be defined). > > > > > > > > That way, "fastboot boot zImage" would actually work out of the box, > > > > without requiring to set the optional "-b" option to set the kernel > > > > base address to some decent value. > > > > > > Then I'd say such "default" address should be something like 0x . > > > > I'd probably agree if we were on a perfect world :) > > > > But the fact is that the tools that are creating these boot.img in > > Android all have this default, and *will* fill the kernel address > > header to this value. > > > > https://android.googlesource.com/platform/system/core/+/master/fastboot/fas > > tboot.cpp, line 72 > > https://android.googlesource.com/platform/system/core/+/master/mkbootimg/m > > kbootimg.c, line 112 > > > > So even if we send a patch to Android itself, that won't fix the tools > > that are already in the source code of published Android versions, or > > the packages bundled in the distribution. > > > > So I think that instead of blindly trusting these tools, U-Boot should > > handle that address has the de facto default, even if it doesn't make > > any sense :) > > OK, now I agree. Maybe we should fix both -- the tools and U-Boot. I'll try to cook up a patch, send it to AOSP and see how it goes. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Test
Hi! I don't see any problems with the U-Boot mailing list - I receive more and more letters, timestamp of the latest one is "Sat, 25 Apr 2015 08:39:55 UTC". Did you check the amount of available space or spam folder? Your mail provider may be overwhelmed by the stream of this huge mailing list. Cheers, Nable. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/21] sunxi: emac: Add device model support
Hi,
On 25-04-15 01:24, Simon Glass wrote:
Hi Hans,
On 24 April 2015 at 07:48, Hans de Goede wrote:
Modify the sunxi-emac eth driver to support device model.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/board.c | 4 +-
drivers/net/sunxi_emac.c | 81
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 7e9cf11..cde13ef 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -12,7 +12,9 @@
#include
#include
+#ifndef CONFIG_DM_ETH
#include
+#endif
#include
#include
#ifdef CONFIG_SPL_BUILD
@@ -224,7 +226,7 @@ int cpu_eth_init(bd_t *bis)
mdelay(200);
#endif
-#ifdef CONFIG_SUNXI_EMAC
+#if defined CONFIG_SUNXI_EMAC && !defined CONFIG_DM_ETH
rc = sunxi_emac_initialize(bis);
if (rc < 0) {
printf("sunxi: failed to initialize emac\n");
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index 038f474..a9efe11 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -160,6 +161,9 @@ struct emac_eth_dev {
struct mii_dev *bus;
struct phy_device *phydev;
int link_printed;
+#ifdef CONFIG_DM_ETH
+ uchar rx_buf[DMA_CPU_TRRESHOLD];
THRESHOLD
This define already exists and actually has the typo in it, I can
do another preparation patch fixing this I guess.
Also does this need to be DMA-aligned? - e.g. DM_FLAG_ALLOC_PRIV_DMA
Nope, this driver only uses mmio, not dma, the name of the
variable not only has a typo it is also misleading. Guess I
better do a preparation patch to slot in before this one
to fixup the define's name.
Regards,
Hans
+#endif
};
struct emac_rxhdr {
@@ -509,6 +513,7 @@ static void sunxi_emac_board_setup(struct emac_eth_dev
*priv)
clrsetbits_le32(®s->mac_mcfg, 0xf << 2, 0xd << 2);
}
+#ifndef CONFIG_DM_ETH
static int sunxi_emac_eth_init(struct eth_device *dev, bd_t *bis)
{
return _sunxi_emac_eth_init(dev->priv, dev->enetaddr);
@@ -573,3 +578,79 @@ int sunxi_emac_initialize(void)
return sunxi_emac_init_phy(priv, dev);
}
+#endif
+
+#ifdef CONFIG_DM_ETH
+static int sunxi_emac_eth_start(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ return _sunxi_emac_eth_init(dev->priv, pdata->enetaddr);
+}
+
+static int sunxi_emac_eth_send(struct udevice *dev, void *packet, int length)
+{
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+
+ return _sunxi_emac_eth_send(priv, packet, length);
+}
+
+static int sunxi_emac_eth_recv(struct udevice *dev, uchar **packetp)
+{
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+ int rx_len;
+
+ rx_len = _sunxi_emac_eth_recv(priv, priv->rx_buf);
+ *packetp = priv->rx_buf;
+
+ return rx_len;
+}
+
+static void sunxi_emac_eth_stop(struct udevice *dev)
+{
+ /* Nothing to do here */
+}
+
+static int sunxi_emac_eth_probe(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+
+ priv->regs = (struct emac_regs *)pdata->iobase;
+ sunxi_emac_board_setup(priv);
+
+ return sunxi_emac_init_phy(priv, dev);
+}
+
+static const struct eth_ops sunxi_emac_eth_ops = {
+ .start = sunxi_emac_eth_start,
+ .send = sunxi_emac_eth_send,
+ .recv = sunxi_emac_eth_recv,
+ .stop = sunxi_emac_eth_stop,
+};
+
+static int sunxi_emac_eth_ofdata_to_platdata(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ pdata->iobase = dev_get_addr(dev);
+
+ return 0;
+}
+
+static const struct udevice_id sunxi_emac_eth_ids[] = {
+ { .compatible = "allwinner,sun4i-a10-emac" },
+ { }
+};
+
+U_BOOT_DRIVER(eth_sunxi_emac) = {
+ .name = "eth_sunxi_emac",
+ .id = UCLASS_ETH,
+ .of_match = sunxi_emac_eth_ids,
+ .ofdata_to_platdata = sunxi_emac_eth_ofdata_to_platdata,
+ .probe = sunxi_emac_eth_probe,
+ .ops= &sunxi_emac_eth_ops,
+ .priv_auto_alloc_size = sizeof(struct emac_eth_dev),
+ .platdata_auto_alloc_size = sizeof(struct eth_pdata),
+};
+#endif
--
2.3.5
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/21] sunxi: Do not build i2c support when we've no i2c controllers
Hi, On 25-04-15 01:22, Simon Glass wrote: Hi Hans, On 24 April 2015 at 07:48, Hans de Goede wrote: This fixes the following errors being printed during boot: Error, wrong i2c adapter 0 max 0 possible Error, wrong i2c adapter 0 max 0 possible Signed-off-by: Hans de Goede Where does the error come from? Somewhere in the i2c code I presume, I did not investigate, I started by trying to simply disable building the i2c stuff as it makes no sense to have i2c support build-in when there are no controllers, and that indeed fixed things. Regards, Hans Reviewed-by: Simon Glass --- include/configs/sunxi-common.h | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 3e49aba..f97e626 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -261,14 +261,15 @@ #define CONFIG_SPL_I2C_SUPPORT #endif -#define CONFIG_SYS_I2C #if defined CONFIG_I2C0_ENABLE || defined CONFIG_I2C1_ENABLE || \ defined CONFIG_I2C2_ENABLE || defined CONFIG_I2C3_ENABLE || \ defined CONFIG_I2C4_ENABLE +#define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI -#endif #define CONFIG_SYS_I2C_SPEED 40 #define CONFIG_SYS_I2C_SLAVE 0x7f +#define CONFIG_CMD_I2C +#endif #if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD) #define CONFIG_SYS_I2C_SOFT @@ -288,8 +289,6 @@ extern int soft_i2c_gpio_scl; #define CONFIG_VIDEO_LCD_I2C_BUS -1 /* NA, but necessary to compile */ #endif -#define CONFIG_CMD_I2C - /* PMU */ #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || defined CONFIG_AXP221_POWER #define CONFIG_SPL_POWER_SUPPORT -- 2.3.5 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/21] sunxi: Move ALL boards to the device-model
Hi Simon, Thanks for the quick review. On 25-04-15 01:23, Simon Glass wrote: Hi Hans, On 24 April 2015 at 07:48, Hans de Goede wrote: Hi Simon, Ian, As promised here is my patch-set to move all sunxi boards to the device-model, it was slightly more work then I expected, and as such the patch-set is also somewhat larger then expected, but it is done :) Please review, since this all only touches sunxi specific files the intention is to merge this through the sunxi tree as soon as all the patches are acked. General comments: Can you add to this cover letter *what* you are moving the driver model. I think it is GPIOs and Ethernet, is that right? Right, this moves the bits which have been converted to the driver-model over to the driver model for all boards. Currently that is only gpio and ethernet AFAIK, and only for u-boot proper, not for the SPL. - s/device model/driver model/ (or driver-model which is often more correct) Ah, oops, will fix in all the patches. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
