Re: [U-Boot] [PATCH v2 2/2] MarSBoard: add new board
Dear Fabio Estevam, In message you wrote: > > Me too. I also think the ifdefs may easily cause confusion. So you suggest we remove all conditional code and use duplication everywhere? You must be joking... > For example: if someone sends a patch for Riotboard, he/she may break > Marsboard without knowing. > > Usually the developer has only one board and is not able to test on both > boards. Yes, of course. If someone touches common code he make breake things for boards he did not test. That has always been the case, everywehre. But that has never been a reason to duplicate code, or to accept code duplication. On contrary, we permanently struggle to reduce such duplication. Otherwise we would have to strictly split ARM and PowerPC code, and all other architectures. We would need code copies for each SoC. Actually each board would need his own version of the whole U-Boot code. Sorry, but this is just bizarre... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I don't mind criticism. You know me. I've never been one to take offence at criticism. No one could say I'm the sort to take offence at criticism -- Not twice, anyway. Not without blowing bubbles. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] MarSBoard: add new board
Dear Otavio, In message you wrote: > > I understand both boards share a lot of code but I think the set of > ifdef makes harder for people to understand the board code. Personally > I prefer v1. Duplication of so much code is really bad. It's always been a maintenance nightmare. The new version is much better. [Of course there are also ways to avoid ifdefs, but there are not so many here, and they are actually pretty easy to follow.] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] MarSBoard: add new board
On Wed, Mar 26, 2014 at 11:21 PM, Otavio Salvador wrote: > I understand both boards share a lot of code but I think the set of > ifdef makes harder for people to understand the board code. Personally > I prefer v1. Me too. I also think the ifdefs may easily cause confusion. For example: if someone sends a patch for Riotboard, he/she may break Marsboard without knowing. Usually the developer has only one board and is not able to test on both boards. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] MarSBoard: add new board
On Wed, Mar 26, 2014 at 6:31 PM, Eric Bénard wrote: > this board is produced by Embest/Element 14 and is based on i.MX6 Dual > The following features are tested : > - UART2 (console) > - eMMC > - uSDCard > - Ethernet > - USB Host (through 2 ports hub) > - HDMI output > - I2C 1/2 > - SPI NOR Flash > > Boot on SPI NOR and through USB loader are tested. > > For more informations on this board : > http://www.embest-tech.com/shop/star/marsboard.html > > As this board shares a lot with RiOTboard, both boards are supported by > the same code base which is renamed embest/mx6boards > > Signed-off-by: Eric Bénard I understand both boards share a lot of code but I think the set of ifdef makes harder for people to understand the board code. Personally I prefer v1. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Fix e6500 L2 cache stash IDs
The value written to L2CSR1 didn't match the value written to the device tree. Signed-off-by: Scott Wood --- arch/powerpc/cpu/mpc85xx/fdt.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c index 33bc900..31e63f7 100644 --- a/arch/powerpc/cpu/mpc85xx/fdt.c +++ b/arch/powerpc/cpu/mpc85xx/fdt.c @@ -275,12 +275,16 @@ static inline void ft_fixup_l2cache(void *blob) u32 *reg = (u32 *)fdt_getprop(blob, off, "reg", 0); #if defined(CONFIG_SYS_FSL_QORIQ_CHASSIS2) && defined(CONFIG_E6500) /* Only initialize every eighth thread */ - if (reg && !((*reg) % 8)) + if (reg && !((*reg) % 8)) { + fdt_setprop_cell(blob, l2_off, "cache-stash-id", +(*reg / 4) + 32 + 1); + } #else - if (reg) -#endif + if (reg) { fdt_setprop_cell(blob, l2_off, "cache-stash-id", -(*reg * 2) + 32 + 1); +(*reg * 2) + 32 + 1); + } +#endif #endif fdt_setprop(blob, l2_off, "cache-unified", NULL, 0); -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master info ARM/master
Hi Tom, > Stephen Warren (1): > ARM: tegra: make all I2C ports open-drain > > board/nvidia/dalmore/pinmux-config-dalmore.h | 16 > board/nvidia/venice2/pinmux-config-venice2.h | 16 > 2 files changed, 16 insertions(+), 16 deletions(-) Is there something holding you back including my USB changes (v5)? -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master info ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean, and ./MAKEALL -a arm only shows failures that were already present in ARM/master. The following changes since commit ab6423cae0323e8db2c8fdd0a99138d93fde2137: Merge branch 'u-boot/master' into 'u-boot-arm/master' (2014-03-25 10:53:15 +0100) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to 352580870ca64b23a485a6b2ba6febc240b10904: ARM: tegra: make all I2C ports open-drain (2014-03-26 15:20:56 -0700) Stephen Warren (1): ARM: tegra: make all I2C ports open-drain board/nvidia/dalmore/pinmux-config-dalmore.h | 16 board/nvidia/venice2/pinmux-config-venice2.h | 16 2 files changed, 16 insertions(+), 16 deletions(-) Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] RiOTboard: add new board
this board is produced by Embest/Element 14 and is based on i.MX6 Solo The following features are tested : - UART2 (console) - eMMC - SDCard - uSDCard - Ethernet - USB Host (through 4 ports hub) - HDMI output - I2C 1/2/3 Boot on eMMC and through USB loader are tested. For more informations on this board : http://www.riotboard.org/ Signed-off-by: Eric Bénard --- board/embest/riotboard/Makefile| 9 + board/embest/riotboard/riotboard.c | 493 + boards.cfg | 1 + include/configs/riotboard.h| 299 ++ 4 files changed, 802 insertions(+) create mode 100644 board/embest/riotboard/Makefile create mode 100644 board/embest/riotboard/riotboard.c create mode 100644 include/configs/riotboard.h diff --git a/board/embest/riotboard/Makefile b/board/embest/riotboard/Makefile new file mode 100644 index 000..5f978c0 --- /dev/null +++ b/board/embest/riotboard/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := riotboard.o diff --git a/board/embest/riotboard/riotboard.c b/board/embest/riotboard/riotboard.c new file mode 100644 index 000..15eaa1e --- /dev/null +++ b/board/embest/riotboard/riotboard.c @@ -0,0 +1,493 @@ +/* + * Copyright (C) 2014 Eukréa Electromatique + * Author: Eric Bénard + * Fabio Estevam + * Jon Nettleton + * + * based on sabresd.c which is : + * Copyright (C) 2012 Freescale Semiconductor, Inc. + * and on hummingboard.c which is : + * Copyright (C) 2013 SolidRun ltd. + * Copyright (C) 2013 Jon Nettleton . + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \ + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CLK_CTRL (PAD_CTL_SPEED_LOW |\ + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | \ + PAD_CTL_HYS) + +#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_PD (PAD_CTL_PUS_100K_DOWN | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_CLK ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + +#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ + PAD_CTL_ODE | PAD_CTL_SRE_FAST) + +int dram_init(void) +{ + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); + + return 0; +} + +static iomux_v3_cfg_t const uart2_pads[] = { + MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), + MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), +}; + +static void setup_iomux_uart(void) +{ + imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); +} + +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), + /* 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), + /* 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_CTRL), + MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD), + /* AR8035 PHY Reset */ + MX6_PAD_EIM_D31__GPIO3_IO31 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD), + /* AR8035 PHY Interrupt */ + MX6_PAD_ENET_TX_EN__GPIO1_IO28 | MUX_PAD_CTRL(ENET_PAD_CTRL), +}; + +static v
[U-Boot] [PATCH v2 2/2] MarSBoard: add new board
this board is produced by Embest/Element 14 and is based on i.MX6 Dual The following features are tested : - UART2 (console) - eMMC - uSDCard - Ethernet - USB Host (through 2 ports hub) - HDMI output - I2C 1/2 - SPI NOR Flash Boot on SPI NOR and through USB loader are tested. For more informations on this board : http://www.embest-tech.com/shop/star/marsboard.html As this board shares a lot with RiOTboard, both boards are supported by the same code base which is renamed embest/mx6boards Signed-off-by: Eric Bénard --- board/embest/{riotboard => mx6boards}/Makefile | 2 +- .../riotboard.c => mx6boards/mx6boards.c} | 49 +- boards.cfg | 3 +- include/configs/{riotboard.h => embestmx6boards.h} | 58 ++ 4 files changed, 108 insertions(+), 4 deletions(-) rename board/embest/{riotboard => mx6boards}/Makefile (87%) rename board/embest/{riotboard/riotboard.c => mx6boards/mx6boards.c} (91%) rename include/configs/{riotboard.h => embestmx6boards.h} (84%) diff --git a/board/embest/riotboard/Makefile b/board/embest/mx6boards/Makefile similarity index 87% rename from board/embest/riotboard/Makefile rename to board/embest/mx6boards/Makefile index 5f978c0..467fb50 100644 --- a/board/embest/riotboard/Makefile +++ b/board/embest/mx6boards/Makefile @@ -6,4 +6,4 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y := riotboard.o +obj-y := mx6boards.o diff --git a/board/embest/riotboard/riotboard.c b/board/embest/mx6boards/mx6boards.c similarity index 91% rename from board/embest/riotboard/riotboard.c rename to board/embest/mx6boards/mx6boards.c index 15eaa1e..374c2ec 100644 --- a/board/embest/riotboard/riotboard.c +++ b/board/embest/mx6boards/mx6boards.c @@ -60,6 +60,9 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ PAD_CTL_ODE | PAD_CTL_SRE_FAST) +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + int dram_init(void) { gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); @@ -153,8 +156,10 @@ iomux_v3_cfg_t const usdhc3_pads[] = { MX6_PAD_SD3_DAT1__SD3_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), MX6_PAD_SD3_DAT2__SD3_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), MX6_PAD_SD3_DAT3__SD3_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), +#ifdef CONFIG_RIOTBOARD MX6_PAD_SD3_DAT4__GPIO7_IO01| MUX_PAD_CTRL(NO_PAD_CTRL), /* WP */ MX6_PAD_SD3_DAT5__GPIO7_IO00| MUX_PAD_CTRL(NO_PAD_CTRL), /* CD */ +#endif }; iomux_v3_cfg_t const usdhc4_pads[] = { @@ -187,7 +192,12 @@ int board_mmc_getcd(struct mmc *mmc) ret = !gpio_get_value(USDHC2_CD_GPIO); break; case USDHC3_BASE_ADDR: +#ifdef CONFIG_RIOTBOARD ret = !gpio_get_value(USDHC3_CD_GPIO); +#endif +#ifdef CONFIG_MARSBOARD + ret = 1; /* eMMC/uSDHC3 is always present */ +#endif break; case USDHC4_BASE_ADDR: ret = 1; /* eMMC/uSDHC4 is always present */ @@ -205,9 +215,13 @@ int board_mmc_init(bd_t *bis) /* * According to the board_mmc_init() the following map is done: * (U-boot device node)(Physical Port) +* ** RiOTboard : * mmc0SDCard slot (bottom) * mmc1uSDCard slot (top) * mmc2eMMC +* ** MarSBoard : +* mmc0uSDCard slot (bottom) +* mmc1eMMC */ for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) { switch (i) { @@ -224,6 +238,11 @@ int board_mmc_init(bd_t *bis) gpio_direction_input(USDHC3_CD_GPIO); usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK); usdhc_cfg[1].max_bus_width = 4; +#ifdef CONFIG_MARSBOARD + gpio_direction_output(IMX_GPIO_NR(7, 8) , 0); + udelay(250); + gpio_set_value(IMX_GPIO_NR(7, 8), 1); +#endif break; case 2: imx_iomux_v3_setup_multiple_pads( @@ -248,6 +267,20 @@ int board_mmc_init(bd_t *bis) } #endif +#ifdef CONFIG_MXC_SPI +iomux_v3_cfg_t const ecspi1_pads[] = { + MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_EB2__GPIO2_IO30 | MUX_PAD_CTRL(NO_PAD_CTRL), +}; + +static void setup_spi(void) +{ + imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads)); +} +#endif + struct i2c_pads_info i2c_pad_info1 = { .scl = { .i2c_mode = MX6_PAD_CSI0_DAT9__I2C1_SCL | MUX_PAD_CTRL(I2C_PAD_CTRL), @@ -458,21 +491,28 @@ int board_init(void) { /* address of boot parameters
Re: [U-Boot] [PATCH] ARM: tegra: add Jetson TK1 board
On 03/26/2014 02:59 PM, Tom Warren wrote: > I'll fix it on application. Pinmux changes and this patch should be in/tested > late today, and if it looks good to you I'll issue a PR to Albert. Aren't you only sending "ARM: tegra: make all I2C ports open-drain" for 2014.04? I was assuming the other pinmux driver change would all go into the next release, since they were posted well after the merge window. >> -Original Message- >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] >> Sent: Tuesday, March 25, 2014 12:17 PM >> To: Wolfgang Denk; Tom Warren >> Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren >> Subject: Re: [U-Boot] [PATCH] ARM: tegra: add Jetson TK1 board >> >> On 03/25/2014 01:13 PM, Wolfgang Denk wrote: >>> Dear Stephen, >>> >>> In message <1395769173-8143-1-git-send-email- >> swar...@wwwdotorg.org> you wrote: Jetson TK1 is an NVIDIA Tegra124 reference board, which shares much of its design with Venice2. >>> ... +++ b/include/configs/jetson-tk1.h @@ -0,0 +1,79 @@ +/* + * (C) Copyright 2013-2014 + * NVIDIA Corporation + * + * SPDX-License-Identifier: GPL-2.0 >>> >>> Is there any specific reason this is not GPL-2.0+ ? >> >> Oops. I evidently cut/paste from the wrong place. Please consider that to say >> GPL-2.0+. Tom, can you fix this while applying, or do you want a repost (I'd >> probably hold off on a repost until after 2014.04 is out in case there are >> any >> other comments). > -- > nvpublic > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 3/3] T1040QDS/U-QE: Add u-qe support to t1040qds
On 03/21/2014 01:21 AM, Zhao Qiang wrote: > Add u-qe support for t1040qds > > Signed-off-by: Zhao Qiang > --- > Changes for v2: > - modify CONFIG_SYS_QE_FMAN_FW_ADDR to CONFIG_SYS_FMAN_FW_ADDR and > CONFIG_SYS_QE_FW_ADDR > Changes for v3: > - use CONFIG_U_QE instead of CONFIG_PPC_T1040 > Changes for v4: > - ifdef CONFIG_U_QE, include "../../../../drivers/qe/qe.h" > Changes for v5: > - no > Changes for v6: > - rebase > Changes for v7: > - split to two patches, the one to support u-qe and the other is to add > u-qe to t1040qds > > board/freescale/t1040qds/t1040qds.c | 27 +++ > include/configs/T1040QDS.h | 3 +++ > 2 files changed, 30 insertions(+) > > diff --git a/board/freescale/t1040qds/t1040qds.c > b/board/freescale/t1040qds/t1040qds.c > index 3dec447..d50ad42 100644 > --- a/board/freescale/t1040qds/t1040qds.c > +++ b/board/freescale/t1040qds/t1040qds.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include "../common/qixis.h" > #include "t1040qds.h" > @@ -89,6 +90,30 @@ int select_i2c_ch_pca9547(u8 ch) > return 0; > } > > +static void qe_board_setup(void) > +{ > + u8 brdcfg15, brdcfg9; > + > + if (hwconfig("qe") && hwconfig("tdm")) { This is called before environmental variables are relocated to DDR. It will cause a warning. Please use hwconfig_f. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: make all I2C ports open-drain
On 03/21/2014 03:27 PM, Tom Warren wrote: > I've updated u-boot-tegra/next with this patch, rebased it against ARM > master, and pushed it to Denx. All tegra boards build OK. > > Albert - if you want, you can use u-boot-tegra/next to bring in this patch, > or apply it to ARM master yourself, or I can do a formal PR. Let me know. Or > TomR can just apply it to Denx master. I haven't seen any response to this, so I assume simply sending a pull request is the best way forward. > Tom > >> -Original Message- >> From: Stephen Warren [mailto:swar...@wwwdotorg.org] >> Sent: Friday, March 21, 2014 11:31 AM >> To: u-boot@lists.denx.de; Simon Glass; Tom Warren; Stephen Warren >> Cc: Tom Rini >> Subject: Re: [U-Boot] [PATCH] ARM: tegra: make all I2C ports open-drain >> >> On 03/12/2014 01:10 PM, Stephen Warren wrote: >>> From: Stephen Warren >>> >>> I2C protocol requires open-drain IOs. Fix the Dalmore and Venice2 >>> pinmux tables to configure the IOs correctly. Without this, Tegra may >>> actively drive the lines high while an external device is actively >>> driving the lines low, which can only lead to bad things. >> >> Tom (or Tom or Albert), >> >> This one patch should really be applied as a bug-fix for v2014.04. It'd be >> good >> to get it applied soon. >> >> The other large pinmux series I sent can obviously wait until the next >> release. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] spi: davinci: add support for multiple bus and chip select
>-Original Message- >From: Jagan Teki [mailto:jagannadh.t...@gmail.com] >Sent: Sunday, March 23, 2014 7:07 AM >To: Karicheri, Muralidharan >Cc: Rini, Tom; u-boot@lists.denx.de; Chang, Rex >Subject: Re: [U-Boot] [PATCH v3 8/9] spi: davinci: add support for multiple >bus and chip >select > >Hi, > >On Sat, Mar 22, 2014 at 2:21 AM, Murali Karicheri wrote: >> Currently davinci spi driver supports only bus 0 cs 0. >> This patch allows driver to support bus 1 and bus 2 with configurable >> number of chip selects. Also defaults are selected in a way to avoid >> regression on other platforms that uses davinci spi driver and has >> only one spi bus. >> >> Signed-off-by: Rex Chang >> Signed-off-by: Murali Karicheri >> Acked-by: Tom Rini >> --- >> drivers/spi/davinci_spi.c | 60 >++--- >> drivers/spi/davinci_spi.h | 33 + >> 2 files changed, 90 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c >> index e3fb321..b682bc4 100644 >> --- a/drivers/spi/davinci_spi.c >> +++ b/drivers/spi/davinci_spi.c >> @@ -32,7 +32,27 @@ struct spi_slave *spi_setup_slave(unsigned int bus, >> unsigned int >cs, >> if (!ds) >> return NULL; >> >> - ds->regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI_BASE; >> + ds->slave.bus = bus; >> + ds->slave.cs = cs; >> + >> + switch (bus) { >> + case SPI0_BUS: >> + ds->regs = (struct davinci_spi_regs *)SPI0_BASE; >> + break; >> +#ifdef CONFIG_SYS_SPI1 >> + case SPI1_BUS: >> + ds->regs = (struct davinci_spi_regs *)SPI0_BASE; >> + break; >> +#endif >> +#ifdef CONFIG_SYS_SPI2 >> + case SPI2_BUS: >> + ds->regs = (struct davinci_spi_regs *)SPI2_BASE; >> + break; >> +#endif >> + default: /* Invalid bus number */ >> + return NULL; >> + } >> + >> ds->freq = max_hz; >> >> return &ds->slave; >> @@ -59,7 +79,7 @@ int spi_claim_bus(struct spi_slave *slave) >> writel(SPIGCR1_MASTER_MASK | SPIGCR1_CLKMOD_MASK, >> &ds->regs->gcr1); >> >> /* CS, CLK, SIMO and SOMI are functional pins */ >> - writel((SPIPC0_EN0FUN_MASK | SPIPC0_CLKFUN_MASK | >> + writel(((1 << slave->cs) | SPIPC0_CLKFUN_MASK | >> SPIPC0_DOFUN_MASK | SPIPC0_DIFUN_MASK), >> &ds->regs->pc0); >> >> /* setup format */ >> @@ -262,9 +282,43 @@ out: >> return 0; >> } >> >> +#ifdef CONFIG_SYS_SPI1 >> +static int bus1_cs_valid(unsigned int bus, unsigned int cs) { >> + if ((bus == SPI1_BUS) && (cs < SPI1_NUM_CS)) >> + return 1; >> + return 0; >> +} >> +#else >> +static int bus1_cs_valid(unsigned int bus, unsigned int cs) { >> + return 0; >> +} >> +#endif >> + >> +#ifdef CONFIG_SYS_SPI2 >> +static int bus2_cs_valid(unsigned int bus, unsigned int cs) { >> + if ((bus == SPI2_BUS) && (cs < SPI2_NUM_CS)) >> + return 1; >> + return 0; >> +} >> +#else >> +static int bus2_cs_valid(unsigned int bus, unsigned int cs) { >> + return 0; >> +} >> +#endif >> + >> int spi_cs_is_valid(unsigned int bus, unsigned int cs) { >> - return bus == 0 && cs == 0; >> + if ((bus == SPI0_BUS) && (cs < SPI0_NUM_CS)) >> + return 1; >> + else if (bus1_cs_valid(bus, cs)) >> + return 1; >> + else if (bus2_cs_valid(bus, cs)) >> + return 1; >> + return 0; >> } >> >> void spi_cs_activate(struct spi_slave *slave) diff --git >> a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h index >> 33f69b5..d4612d3 100644 >> --- a/drivers/spi/davinci_spi.h >> +++ b/drivers/spi/davinci_spi.h >> @@ -74,6 +74,39 @@ struct davinci_spi_regs { >> /* SPIDEF */ >> #define SPIDEF_CSDEF0_MASK BIT(0) >> >> +#define SPI0_BUS 0 >> +#define SPI0_BASE CONFIG_SYS_SPI_BASE >> +/* >> + * Define default SPI0_NUM_CS as 1 for existing platforms that uses >> +this >> + * driver. Platform can configure number of CS using >> +CONFIG_SYS_SPI0_NUM_CS >> + * if more than one CS is supported and by defining CONFIG_SYS_SPI0. >> + */ >> +#ifndef CONFIG_SYS_SPI0 >> +#define SPI0_NUM_CS1 >> +#else >> +#define SPI0_NUM_CSCONFIG_SYS_SPI0_NUM_CS >> +#endif >> + >> +/* >> + * define CONFIG_SYS_SPI1 when platform has spi-1 device (bus #1) and >> + * CONFIG_SYS_SPI1_NUM_CS defines number of CS on this bus */ #ifdef >> +CONFIG_SYS_SPI1 >> +#define SPI1_BUS 1 >> +#define SPI1_NUM_CSCONFIG_SYS_SPI1_NUM_CS >> +#define SPI1_BASE CONFIG_SYS_SPI1_BASE >> +#endif >> + >> +/* >> + * define CONFIG_SYS_SPI2 when platform has spi-2 device (bus #2) and >> + * CONFIG_SYS_SPI2_NUM_CS defines number of CS on this bus */ #ifdef >> +CONFIG_SYS_SPI2 >> +#define SPI2_BUS 2 >> +#define SPI2_NUM_CSCONFIG_SYS_SPI2_NUM_CS >> +#defi
Re: [U-Boot] [PATCH 2/2] MarSBoard: add new board
Hi Wolfgang, Le Wed, 26 Mar 2014 20:02:57 +0100, Wolfgang Denk a écrit : > In message <1395858363-21054-2-git-send-email-e...@eukrea.com> you wrote: > > > > this board is produced by Embest/Element 14 and is based on i.MX6 Dual > > Comparing this patch agains the earlier one for the RiOTboard, it > turns out that the differences between these two boards are really > minimal. > > Would it not make sense to combine all the common code? Actually I > think you should be able to use all common code with just two > different target names. > that seems possible : the main differences at u-boot level are the eSDHC (3 on the RiOT vs 2 on the MarS) and the SPI flash which is populated in the MarSBoard (and used for boot when the RiOT boots on the eMMC). I'll check how to factorize the code. Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MarSBoard: add new board
Dear Eric, In message <1395858363-21054-2-git-send-email-e...@eukrea.com> you wrote: > > this board is produced by Embest/Element 14 and is based on i.MX6 Dual Comparing this patch agains the earlier one for the RiOTboard, it turns out that the differences between these two boards are really minimal. Would it not make sense to combine all the common code? Actually I think you should be able to use all common code with just two different target names. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To be awake is to be alive.- Henry David Thoreau, in "Walden" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] lib: uuid: add functions to generate UUID version 4
On 03/26/2014 06:00 AM, Przemyslaw Marczak wrote: > On 03/25/2014 08:28 PM, Stephen Warren wrote: >> On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: >>> This patch adds support to generate UUID (Universally Unique Identifier) >>> in version 4 based on RFC4122, which is randomly. >>> >>> Source: https://www.ietf.org/rfc/rfc4122.txt >>> diff --git a/lib/uuid.c b/lib/uuid.c >> >>> /* >>>* UUID - Universally Unique IDentifier - 128 bits unique number. >>>*There are 5 versions and one variant of UUID defined by RFC4122 >>> - *specification. Depends on version uuid number base on a time, >>> - *host name, MAC address or random data. >>> + *specification. Depends on version uuid number base on: >> >> I still have no idea what "Depends on version uuid number base on" means. > > It means that each UUID version "result" depends on different source > data, as listed here... How bout replacing that sentence with: A UUID contains a set of fields. The set varies depending on the version of the UUID, as shown below: >>> + *- time, MAC address(v1), >>> + *- user ID(v2), >>> + *- MD5 of name or URL(v3), >>> + *- random data(v4), >>> + *- SHA-1 of name or URL(v5), >>> + * timestamp - 60-bit: time_low, time_mid, time_hi_and_version >>> + * version - 4 bit (bit 4 through 7 of the time_hi_and_version) >>> + * clock seq - 14 bit: clock_seq_hi_and_reserved, clock_seq_low >>> + * variant: - bit 6 and 7 of clock_seq_hi_and_reserved >>> + * node - 48 bit >>> + * In this version all fields beside 4 bit version are randomly generated. >>> + * source: https://www.ietf.org/rfc/rfc4122.txt >> >> gen_rand_uuid() doesn't actually honor that format; it creates pure >> random data rather than filling in any timestamps, clock sequence >> data, etc. > > Actually, yes but two fields are NOT set randomly, and this is what > comment includes: > "In this version all fields beside 4 bit version are randomly generated." > Moreover the gen_rand_uuid() respects endianess for setting bits, > and this could be checked on linux host by "uuid -d uboot_uuid_string" > in shell. While it's true that some fields are set non-randomly, most aren't; you really can't claim that e.g. placing random data in the timestamp field is a valid timestamp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] lib: uuid: code refactor for proper maintain between uuid bin and string
On 03/26/2014 06:00 AM, Przemyslaw Marczak wrote: > Hello Stephen, > Thanks for review again:) > > On 03/25/2014 08:12 PM, Stephen Warren wrote: >> On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: >>> Changes in lib/uuid.c to: >>> - uuid_str_to_bin() >>> - uuid_bin_to_str() >>> >>> New parameter is added to specify input/output string format in >>> listed functions >>> This change allows easy recognize which UUID type is or should be >>> stored in given >>> string array. Binary data of UUID and GUID is always stored in big >>> endian, only >>> string representations are different as follows. >>> >>> String byte: 0 36 >>> String char: ---- >>> string UUID:be be be be be >>> string GUID:le le le be be >>> >>> This patch also updates functions calls and declarations in a whole >>> code. >>> diff --git a/lib/uuid.c b/lib/uuid.c >> >> >>> +void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, >>> + uuid_str_t str_format) >>> { >>> -static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11, >>> - 12, 13, 14, 15}; >>> +const u8 uuid_char_order[UUID_BIN_LEN] = {0, 1, 2, 3, 4, 5, 6, >>> 7, 8, >>> + 9, 10, 11, 12, 13, 14, 15}; >>> +const u8 guid_char_order[UUID_BIN_LEN] = {3, 2, 1, 0, 5, 4, 7, >>> 6, 8, >>> + 9, 10, 11, 12, 13, 14, 15}; >> >> These are really more binary data order than char order, since each one >> of the bytes pointed at by entries in these arrays ends up being 2 >> characters. s/char/bin/ in the variable names perhaps? > > Yes, you are right. But according to the specification UUID and UUID bin > format are always in big-endian - only bytes in some STRING blocks have > different order. This works in two ways but to be consistent with > specification I called this as "uuid_char_order". And this is directly > used by sprintf: "sprintf(uuid_str, "%02x", uuid_bin[char_order[i]]);". That doesn't make much sense. If I have 2 bytes stored in memory as: 0xaa 0x55 ... and sometimes the string representation of them is aa55 and sometimes 55aa, then *by definition*, that's interpreting the binary data as BE vs LE. The binary data is not always BE. The only exception would be if for bytes in memory 0xaa 0x55 the 16-bit integer/numerical (in-register) value was always 0xaa55 (BE), yet the string representation of that integer was sometimes aa55 and sometimes 55aa. However, that's not how integer->string conversion works. Different string representations of the binary data would only be possible if the binary data isn't an integer but rather a string of bytes, yet endianness has no meaning for data that is natively a string of bytes, only for larger values that have been serialized into a string of bytes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] cmd:gpt: randomly generate each partition uuid if undefined
On 03/26/2014 06:01 AM, Przemyslaw Marczak wrote: > On 03/25/2014 08:51 PM, Stephen Warren wrote: >> On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: >>> Changes: >>> - randomly generate partition uuid if any is undefined and >>> CONFIG_RAND_UUID >>>is defined >>> - print debug info about set/unset/generated uuid >>> - update doc/README.gpt >>> >>> Update existing code to the new library functions. >>> diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c >>> -if ((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}')) { >>> -s = strdup(str); >>> -if (s == NULL) >>> -return -1; >>> -memset(s + strlen(s) - 1, '\0', 1); >>> -memmove(s, s + 2, strlen(s) - 1); >>> +if (!((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}'))) >>> +return -1; >> >> Since you're inverting that test, you need to change && to || too. >> > No, because the invertion refers to the result of "if" - not one of > conditions. > !(cond1 && cond2) is the same as: > (!cond1 || !cond2) > so this change is ok. Ah yes, right. >>> diff --git a/doc/README.gpt b/doc/README.gpt >>> index 5c133f3..51515c8 100644 >>> --- a/doc/README.gpt >>> +++ b/doc/README.gpt >>> @@ -101,7 +101,7 @@ Offset SizeDescription >>> 40 8 B First usable LBA for partitions (primary partition >>> table last >>> LBA + 1) >>> 48 8 B Last usable LBA (secondary partition table first >>> LBA - 1) >>> -56 16 BDisk GUID (also referred as UUID on UNIXes) >>> +56 16 BDisk GUID (also referred as UUID on UNIXes) in big >>> endian >> >> According to your earlier comment, GUIDs have a mix of LE and BE fields, >> so I would simply drop this change and the similar change below. Let >> wikipedia or the comment you added near to top of lib/uuid.c specify the >> details. >> > Actually I think that this is an important info here. The information > about endianness is also placed in few places in lib/uuid.c Why isn't the endianness of all the fields in this structure defined in this comment then? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] RiOTboard: add new board
this board is produced by Embest/Element 14 and is based on i.MX6 Solo The following features are tested : - UART2 (console) - eMMC - SDCard - uSDCard - Ethernet - USB Host (through 4 ports hub) - HDMI output - I2C 1/2/3 Boot on eMMC and through USB loader are tested. For more informations on this board : http://www.riotboard.org/ Signed-off-by: Eric Bénard --- board/embest/riotboard/Makefile| 9 + board/embest/riotboard/riotboard.c | 493 + boards.cfg | 1 + include/configs/riotboard.h| 299 ++ 4 files changed, 802 insertions(+) create mode 100644 board/embest/riotboard/Makefile create mode 100644 board/embest/riotboard/riotboard.c create mode 100644 include/configs/riotboard.h diff --git a/board/embest/riotboard/Makefile b/board/embest/riotboard/Makefile new file mode 100644 index 000..5f978c0 --- /dev/null +++ b/board/embest/riotboard/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := riotboard.o diff --git a/board/embest/riotboard/riotboard.c b/board/embest/riotboard/riotboard.c new file mode 100644 index 000..15eaa1e --- /dev/null +++ b/board/embest/riotboard/riotboard.c @@ -0,0 +1,493 @@ +/* + * Copyright (C) 2014 Eukréa Electromatique + * Author: Eric Bénard + * Fabio Estevam + * Jon Nettleton + * + * based on sabresd.c which is : + * Copyright (C) 2012 Freescale Semiconductor, Inc. + * and on hummingboard.c which is : + * Copyright (C) 2013 SolidRun ltd. + * Copyright (C) 2013 Jon Nettleton . + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \ + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CLK_CTRL (PAD_CTL_SPEED_LOW |\ + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | \ + PAD_CTL_HYS) + +#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_PD (PAD_CTL_PUS_100K_DOWN | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_CLK ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + +#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ + PAD_CTL_ODE | PAD_CTL_SRE_FAST) + +int dram_init(void) +{ + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); + + return 0; +} + +static iomux_v3_cfg_t const uart2_pads[] = { + MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), + MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), +}; + +static void setup_iomux_uart(void) +{ + imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); +} + +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), + /* 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), + /* 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_CTRL), + MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD), + /* AR8035 PHY Reset */ + MX6_PAD_EIM_D31__GPIO3_IO31 | MUX_PAD_CTRL(ENET_PAD_CTRL_PD), + /* AR8035 PHY Interrupt */ + MX6_PAD_ENET_TX_EN__GPIO1_IO28 | MUX_PAD_CTRL(ENET_PAD_CTRL), +}; + +static v
[U-Boot] [PATCH 2/2] MarSBoard: add new board
this board is produced by Embest/Element 14 and is based on i.MX6 Dual The following features are tested : - UART2 (console) - eMMC - uSDCard - Ethernet - USB Host (through 2 ports hub) - HDMI output - I2C 1/2 - SPI NOR Flash Boot on SPI NOR and through USB loader are tested. For more informations on this board : http://www.embest-tech.com/shop/star/marsboard.html Signed-off-by: Eric Bénard --- board/embest/marsboard/Makefile| 9 + board/embest/marsboard/marsboard.c | 489 + boards.cfg | 1 + include/configs/marsboard.h| 304 +++ 4 files changed, 803 insertions(+) create mode 100644 board/embest/marsboard/Makefile create mode 100644 board/embest/marsboard/marsboard.c create mode 100644 include/configs/marsboard.h diff --git a/board/embest/marsboard/Makefile b/board/embest/marsboard/Makefile new file mode 100644 index 000..e87cc87 --- /dev/null +++ b/board/embest/marsboard/Makefile @@ -0,0 +1,9 @@ +# +# Copyright (C) 2007, Guennadi Liakhovetski +# +# (C) Copyright 2011 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := marsboard.o diff --git a/board/embest/marsboard/marsboard.c b/board/embest/marsboard/marsboard.c new file mode 100644 index 000..3735462 --- /dev/null +++ b/board/embest/marsboard/marsboard.c @@ -0,0 +1,489 @@ +/* + * Copyright (C) 2014 Eukréa Electromatique + * Author: Eric Bénard + * Fabio Estevam + * Jon Nettleton + * + * based on sabresd.c which is : + * Copyright (C) 2012 Freescale Semiconductor, Inc. + * and on hummingboard.c which is : + * Copyright (C) 2013 SolidRun ltd. + * Copyright (C) 2013 Jon Nettleton . + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +DECLARE_GLOBAL_DATA_PTR; + +#define UART_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \ + PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \ + PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +#define USDHC_PAD_CLK_CTRL (PAD_CTL_SPEED_LOW |\ + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | \ + PAD_CTL_HYS) + +#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_PD (PAD_CTL_PUS_100K_DOWN | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS) + +#define ENET_PAD_CTRL_CLK ((PAD_CTL_PUS_100K_UP & ~PAD_CTL_PKE) | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + +#define I2C_PAD_CTRL (PAD_CTL_PUS_100K_UP | \ + PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ + PAD_CTL_ODE | PAD_CTL_SRE_FAST) + +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + +int dram_init(void) +{ + gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE); + + return 0; +} + +static iomux_v3_cfg_t const uart2_pads[] = { + MX6_PAD_EIM_D26__UART2_TX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), + MX6_PAD_EIM_D27__UART2_RX_DATA | MUX_PAD_CTRL(UART_PAD_CTRL), +}; + +static void setup_iomux_uart(void) +{ + imx_iomux_v3_setup_multiple_pads(uart2_pads, ARRAY_SIZE(uart2_pads)); +} + +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), + /* 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), + /* 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_CTRL), + MX6_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL_PD), + /* AR8035 PHY Reset */ + MX6_PAD_EIM_D31__GPIO3_IO31 | MUX_P
Re: [U-Boot] [PATCH v4 4/6] new commands: uuid and guid - generate random unique identifier
On 03/26/2014 06:01 AM, Przemyslaw Marczak wrote: > Hello Stephen, > > On 03/25/2014 08:37 PM, Stephen Warren wrote: >> On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: >>> Those commands basis on implementation of random UUID generator >>> version 4 >>> which is described in RFC4122. The same algorithm is used for generation >>> both ids but string representation is different as below. >>> diff --git a/include/common.h b/include/common.h >> >>> #if defined(CONFIG_RANDOM_MACADDR) || \ >>> defined(CONFIG_BOOTP_RANDOM_DELAY) || \ >>> defined(CONFIG_CMD_LINK_LOCAL) || \ >>> -defined(CONFIG_RANDOM_UUID) >>> +defined(CONFIG_RANDOM_UUID) || \ >>> +defined(CONFIG_CMD_UUID) >> >> Why not require that if you want to use CONFIG_CMD_UUID, you must define >> CONFIG_RANDOM_UUID too? You can even make that automatic in >> include/config_fallbacks.h which already does similar things: >> >> #if defined(CONFIG_CMD_FAT) && !defined(CONFIG_FS_FAT) >> #define CONFIG_FS_FAT >> #endif >> >> That way, you won't need to touch lib/Makefile in this patch either, or >> modify the ifdef that wraps gen_rand_uuid(). >> > > I change this part of code in one of my other patch set which can be > found here: http://patchwork.ozlabs.org/patch/332499/ > After apply those changes then I add some automation here. OK. It seems better to get the code right when first introduced, but as long as it gets simplified, I guess that's fine. >>> diff --git a/lib/uuid.c b/lib/uuid.c ... >>> +#ifdef CONFIG_CMD_UUID >>> +int do_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) ... >> This duplicates some code; the call to gen_rand_uuid(). I think it would >> be better as: >> >> if (argc < 2) >> return CMD_RET_USAGE; ... > Yes, this is better, but the first condition should be as: > if ((argc != 1) || (argc != 2)) s/||/&&/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] exynos5: Enable tps65090 on smdk5250
From: Aaron Durbin The TPS65090 pmic chip can be on exynos5250 boards. Therefore, select the appropriate config option for TPS65090 devices. This commit should really use exynos5-dt.c, when it is available. Signed-off-by: Simon Glass Reviewed-by: Simon Glass --- include/configs/exynos5-dt.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h index 414db42..fbf09f5 100644 --- a/include/configs/exynos5-dt.h +++ b/include/configs/exynos5-dt.h @@ -259,6 +259,7 @@ /* PMIC */ #define CONFIG_POWER #define CONFIG_POWER_I2C +#define CONFIG_POWER_TPS65090 /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
From: Aaron Durbin The current pmic i2c code assumes the current i2c bus is the same as the pmic device's bus. There is nothing ensuring that to be true. Therefore, select the proper bus before performing a transaction. Signed-off-by: Aaron Durbin Signed-off-by: Simon Glass Reviewed-by: Simon Glass --- drivers/power/power_i2c.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c index ac76870..594cd11 100644 --- a/drivers/power/power_i2c.c +++ b/drivers/power/power_i2c.c @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val) if (check_reg(p, reg)) return -1; + I2C_SET_BUS(p->bus); + switch (pmic_i2c_tx_num) { case 3: if (p->sensor_byte_order == PMIC_SENSOR_BYTE_ORDER_BIG) { @@ -66,6 +68,8 @@ int pmic_reg_read(struct pmic *p, u32 reg, u32 *val) if (check_reg(p, reg)) return -1; + I2C_SET_BUS(p->bus); + if (i2c_read(pmic_i2c_addr, reg, 1, buf, pmic_i2c_tx_num)) return -1; -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] initcall: Improve debugging support
Add the ability to display the code offset of an initcall even after it is relocated. This makes it much easier to relate initcalls back to the U-Boot System.map file. Signed-off-by: Simon Glass --- include/initcall.h | 2 +- lib/initcall.c | 17 - 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/include/initcall.h b/include/initcall.h index 2378077..65f67dc 100644 --- a/include/initcall.h +++ b/include/initcall.h @@ -6,4 +6,4 @@ typedef int (*init_fnc_t)(void); -int initcall_run_list(init_fnc_t init_sequence[]); +int initcall_run_list(const init_fnc_t init_sequence[]); diff --git a/lib/initcall.c b/lib/initcall.c index fa76dd7..7597bad 100644 --- a/lib/initcall.c +++ b/lib/initcall.c @@ -7,15 +7,22 @@ #include #include -int initcall_run_list(init_fnc_t init_sequence[]) +DECLARE_GLOBAL_DATA_PTR; + +int initcall_run_list(const init_fnc_t init_sequence[]) { - init_fnc_t *init_fnc_ptr; + const init_fnc_t *init_fnc_ptr; for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) { - debug("initcall: %p\n", *init_fnc_ptr); + unsigned long reloc_ofs = 0; + + if (gd->flags & GD_FLG_RELOC) + reloc_ofs = gd->reloc_off; + debug("initcall: %p\n", (char *)*init_fnc_ptr - reloc_ofs); if ((*init_fnc_ptr)()) { - debug("initcall sequence %p failed at call %p\n", - init_sequence, *init_fnc_ptr); + printf("initcall sequence %p failed at call %p\n", + init_sequence, + (char *)*init_fnc_ptr - reloc_ofs); return -1; } } -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
From: Tom Wai-Hong Tam This adds driver support for the TPS65090 PMU. Support includes hooking into the pmic infrastructure so that the pmic commands can be used on the console. The TPS65090 supports the following functionality: - fet enable/disable/querying - getting and setting of charge state Even though it is connected to the pmic infrastructure it does not hook into the pmic charging charging infrastructure. Signed-off-by: Tom Wai-Hong Tam Signed-off-by: Simon Glass Signed-off-by: Hatim Ali Signed-off-by: Katie Roberts-Hoffman Signed-off-by: Rong Chang Signed-off-by: Sean Paul Signed-off-by: Vincent Palatin Signed-off-by: Aaron Durbin --- doc/device-tree-bindings/power/tps65090.txt | 21 ++ drivers/power/pmic/Makefile | 1 + drivers/power/pmic/pmic_tps65090.c | 296 include/fdtdec.h| 1 + include/power/tps65090_pmic.h | 83 lib/fdtdec.c| 1 + 6 files changed, 403 insertions(+) create mode 100644 doc/device-tree-bindings/power/tps65090.txt create mode 100644 drivers/power/pmic/pmic_tps65090.c create mode 100644 include/power/tps65090_pmic.h diff --git a/doc/device-tree-bindings/power/tps65090.txt b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644 index 000..6a8a884 --- /dev/null +++ b/doc/device-tree-bindings/power/tps65090.txt @@ -0,0 +1,21 @@ +TPSchrome binding += + +The device tree node which describes the operation of the Texas Instrument +TPS65090 power regulator chip is as follows: + +Required properties : +- compatible : "ti,tps65090" +- reg : slave address on the i2c bus + +The tps65090 node should appear as a subnode of the i2c bus that connects it. + +Example +=== + + i2c@12ca { + power-regulator@48 { + compatible = "ti,tps65090" + reg = <0x48>; + }; + }; diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile index 0b45ffa..7ed55e6 100644 --- a/drivers/power/pmic/Makefile +++ b/drivers/power/pmic/Makefile @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o diff --git a/drivers/power/pmic/pmic_tps65090.c b/drivers/power/pmic/pmic_tps65090.c new file mode 100644 index 000..ef9f911 --- /dev/null +++ b/drivers/power/pmic/pmic_tps65090.c @@ -0,0 +1,296 @@ +/* + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved. + * Use of this source code is governed by a BSD-style license that can be + * found in the LICENSE file. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License ("GPL") version 2 as published by the Free + * Software Foundation. + */ + +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define TPS65090_NAME "TPS65090_PMIC" + +/* TPS65090 register addresses */ +enum { + REG_CG_CTRL0 = 4, + REG_CG_STATUS1 = 0xa, + REG_FET1_CTRL = 0x0f, + REG_FET2_CTRL, + REG_FET3_CTRL, + REG_FET4_CTRL, + REG_FET5_CTRL, + REG_FET6_CTRL, + REG_FET7_CTRL, + TPS65090_NUM_REGS, +}; + +enum { + CG_CTRL0_ENC_MASK = 0x01, + + MAX_FET_NUM = 7, + MAX_CTRL_READ_TRIES = 5, + + /* TPS65090 FET_CTRL register values */ + FET_CTRL_TOFET = 1 << 7, /* Timeout, startup, overload */ + FET_CTRL_PGFET = 1 << 4, /* Power good for FET status */ + FET_CTRL_WAIT = 3 << 2, /* Overcurrent timeout max */ + FET_CTRL_ADENFET= 1 << 1, /* Enable output auto discharge */ + FET_CTRL_ENFET = 1 << 0, /* Enable FET */ +}; + +/** + * Checks for a valid FET number + * + * @param fet_id FET number to check + * @return 0 if ok, -1 if FET value is out of range + */ +static int tps65090_check_fet(unsigned int fet_id) +{ + if (fet_id == 0 || fet_id > MAX_FET_NUM) { + debug("parameter fet_id is out of range, %u not in 1 ~ %u\n", + fet_id, MAX_FET_NUM); + return -1; + } + + return 0; +} + +/** + * Set the power state for a FET + * + * @param pmic pmic structure for the tps65090 + * @param fet_id Fet number to set (1..MAX_FET_NUM) + * @param set 1 to power on FET, 0 to power off + * @return FET_ERR_COMMS if we got a comms error, FET_ERR_NOT_READY if the + * FET failed to change state. If all is ok, returns 0. + */ +static int tps65090_fet_set(struct pmic *pmic, int fet_id, int set) +{ + int retry; + u32 reg, value; + + value = FET_CTRL_ADENFET | FET_CT
[U-Boot] [PATCH 06/10] exynos: Enable PSHOLD in SPL
There is quite a tight deadline in enabling PSHOLD, less than a second. In some cases (e.g. with USB download), U-Boot takes longer than that to load, so the board powers off before U-Boot starts. Add a call in SPL to enable PSHOLD. Signed-off-by: Simon Glass --- arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv7/exynos/lowlevel_init.c b/arch/arm/cpu/armv7/exynos/lowlevel_init.c index 11fe5b8..48b5511 100644 --- a/arch/arm/cpu/armv7/exynos/lowlevel_init.c +++ b/arch/arm/cpu/armv7/exynos/lowlevel_init.c @@ -48,6 +48,8 @@ int do_lowlevel_init(void) arch_cpu_init(); + set_ps_hold_ctrl(); + reset_status = get_reset_status(); switch (reset_status) { -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] exynos: Enable the LCD backlight for snow
The backlight uses FETs on the TPS65090. Enable this so that the display is visible. Signed-off-by: Simon Glass --- board/samsung/smdk5250/exynos5-dt.c | 90 + 1 file changed, 90 insertions(+) diff --git a/board/samsung/smdk5250/exynos5-dt.c b/board/samsung/smdk5250/exynos5-dt.c index c83b034..a0ae641 100644 --- a/board/samsung/smdk5250/exynos5-dt.c +++ b/board/samsung/smdk5250/exynos5-dt.c @@ -20,6 +20,7 @@ #include #include #include +#include #include DECLARE_GLOBAL_DATA_PTR; @@ -60,6 +61,52 @@ int checkboard(void) #endif #ifdef CONFIG_LCD +static int board_dp_bridge_setup(void) +{ + struct exynos5_gpio_part1 *gpio1 = + (struct exynos5_gpio_part1 *)samsung_get_base_gpio_part1(); + const int MAX_TRIES = 10; + int num_tries; + + debug("%s\n", __func__); + + /* Setup the GPIOs */ + + /* PD is ACTIVE_LOW, and initially de-asserted */ + s5p_gpio_set_pull(&gpio1->y2, 5, GPIO_PULL_NONE); + s5p_gpio_direction_output(&gpio1->y2, 5, 1); + + /* Reset is ACTIVE_LOW */ + s5p_gpio_set_pull(&gpio1->x1, 5, GPIO_PULL_NONE); + s5p_gpio_direction_output(&gpio1->x1, 5, 0); + + udelay(10); + s5p_gpio_set_value(&gpio1->x1, 5, 1); + + s5p_gpio_direction_input(&gpio1->x0, 7); + + /* +* We need to wait for 90ms after bringing up the bridge since there +* is a phantom "high" on the HPD chip during its bootup. The phantom +* high comes within 7ms of de-asserting PD and persists for at least +* 15ms. The real high comes roughly 50ms after PD is de-asserted. The +* phantom high makes it hard for us to know when the NXP chip is up. +*/ + mdelay(90); + + for (num_tries = 0; num_tries < MAX_TRIES; num_tries++) { + /* Check HPD. If it's high, we're all good. */ + if (s5p_gpio_get_value(&gpio1->x0, 7)) + return 0; + + debug("%s: eDP bridge failed to come up; try %d of %d\n", + __func__, num_tries, MAX_TRIES); + } + + /* Immediately go into bridge reset if the hp line is not high */ + return -ENODEV; +} + void exynos_cfg_lcd_gpio(void) { struct exynos5_gpio_part1 *gpio1 = @@ -81,4 +128,47 @@ void exynos_set_dp_phy(unsigned int onoff) { set_dp_phy_ctrl(onoff); } + +void exynos_backlight_on(unsigned int onoff) +{ + debug("%s(%u)\n", __func__, onoff); + + if (onoff) { +#ifdef CONFIG_POWER_TPS65090 + struct exynos5_gpio_part1 *gpio1 = + (struct exynos5_gpio_part1 *) + samsung_get_base_gpio_part1(); + int ret; + + ret = tps65090_fet_enable(1); /* Enable FET1, backlight */ + if (ret) + return; + + /* T5 in the LCD timing spec (defined as > 10ms) */ + mdelay(10); + + /* board_dp_backlight_pwm */ + s5p_gpio_direction_output(&gpio1->b2, 0, 1); + + /* T6 in the LCD timing spec (defined as > 10ms) */ + mdelay(10); + + /* board_dp_backlight_en */ + s5p_gpio_direction_output(&gpio1->x3, 0, 1); +#endif + } +} + +void exynos_lcd_power_on(void) +{ + debug("%s\n", __func__); + +#ifdef CONFIG_POWER_TPS65090 + /* board_dp_lcd_vdd */ + tps65090_fet_enable(6); /* Enable FET6, lcd panel */ +#endif + + board_dp_bridge_setup(); +} + #endif -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] exynos5: support tps65090 pmic
From: Aaron Durbin The TSP65090 is a PMIC on some exynos5 boards. The init function is called for the TPS65090 pmic. If that device is not a part of the device tree (returns -ENODEV) then continue. Otherwise return a failure. Signed-off-by: Aaron Durbin Signed-off-by: Simon Glass Reviewed-by: Simon Glass --- board/samsung/common/board.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c index 3866495..654bdb6 100644 --- a/board/samsung/common/board.c +++ b/board/samsung/common/board.c @@ -23,6 +23,7 @@ #include #include #include +#include DECLARE_GLOBAL_DATA_PTR; @@ -261,6 +262,12 @@ int power_init_board(void) ret = max77686_init(); #endif + /* The TPS65090 may not be in the device tree. If so, it is not +* an error. */ + ret = tps65090_init(); + if (ret == 0 || ret == -ENODEV) + return 0; + return ret; } #endif -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] power: Rename CONFIG_PMIC_... to CONFIG_POWER_...
Commit be3b51aa did this mostly, but several have been added since. Do the job again. Signed-off-by: Simon Glass --- drivers/power/power_fsl.c | 6 +++--- include/configs/arndale.h | 4 ++-- include/configs/exynos5250-dt.h | 2 +- include/configs/mx25pdk.h | 2 +- include/configs/mx35pdk.h | 2 +- include/configs/mx53evk.h | 2 +- include/configs/mx53loco.h| 2 +- include/configs/woodburn_common.h | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/power/power_fsl.c b/drivers/power/power_fsl.c index ac0b541..a64161b 100644 --- a/drivers/power/power_fsl.c +++ b/drivers/power/power_fsl.c @@ -11,9 +11,9 @@ #include #include -#if defined(CONFIG_PMIC_FSL_MC13892) +#if defined(CONFIG_POWER_FSL_MC13892) #define FSL_PMIC_I2C_LENGTH3 -#elif defined(CONFIG_PMIC_FSL_MC34704) +#elif defined(CONFIG_POWER_FSL_MC34704) #define FSL_PMIC_I2C_LENGTH1 #endif @@ -51,7 +51,7 @@ int pmic_init(unsigned char bus) p->hw.i2c.addr = CONFIG_SYS_FSL_PMIC_I2C_ADDR; p->hw.i2c.tx_num = FSL_PMIC_I2C_LENGTH; #else -#error "You must select CONFIG_POWER_SPI or CONFIG_PMIC_I2C" +#error "You must select CONFIG_POWER_SPI or CONFIG_POWER_I2C" #endif return 0; diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 515facf..30ecd45 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -224,8 +224,8 @@ /* PMIC */ #define CONFIG_PMIC -#define CONFIG_PMIC_I2C -#define CONFIG_PMIC_MAX77686 +#define CONFIG_POWER_I2C +#define CONFIG_POWER_MAX77686 #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-arndale diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index b7ff472..9d1d56a 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -45,7 +45,7 @@ #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK /* PMIC */ -#define CONFIG_PMIC_MAX77686 +#define CONFIG_POWER_MAX77686 /* Sound */ #define CONFIG_CMD_SOUND diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h index af6aafa..571d45a 100644 --- a/include/configs/mx25pdk.h +++ b/include/configs/mx25pdk.h @@ -106,7 +106,7 @@ #define CONFIG_POWER #define CONFIG_POWER_I2C #define CONFIG_POWER_FSL -#define CONFIG_PMIC_FSL_MC34704 +#define CONFIG_POWER_FSL_MC34704 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x54 #define CONFIG_DOS_PARTITION diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h index 0a46f4c..ab48144 100644 --- a/include/configs/mx35pdk.h +++ b/include/configs/mx35pdk.h @@ -52,7 +52,7 @@ #define CONFIG_POWER #define CONFIG_POWER_I2C #define CONFIG_POWER_FSL -#define CONFIG_PMIC_FSL_MC13892 +#define CONFIG_POWER_FSL_MC13892 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x08 #define CONFIG_RTC_MC13XXX diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h index 3f0d80a..042cdd0 100644 --- a/include/configs/mx53evk.h +++ b/include/configs/mx53evk.h @@ -45,7 +45,7 @@ #define CONFIG_POWER_I2C #define CONFIG_POWER_FSL #define CONFIG_SYS_FSL_PMIC_I2C_ADDR8 -#define CONFIG_PMIC_FSL_MC13892 +#define CONFIG_POWER_FSL_MC13892 #define CONFIG_RTC_MC13XXX /* MMC Configs */ diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index 1415584..365d072 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -80,7 +80,7 @@ #define CONFIG_POWER_I2C #define CONFIG_DIALOG_POWER #define CONFIG_POWER_FSL -#define CONFIG_PMIC_FSL_MC13892 +#define CONFIG_POWER_FSL_MC13892 #define CONFIG_SYS_DIALOG_PMIC_I2C_ADDR0x48 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8 diff --git a/include/configs/woodburn_common.h b/include/configs/woodburn_common.h index 695bc23..259205e 100644 --- a/include/configs/woodburn_common.h +++ b/include/configs/woodburn_common.h @@ -55,7 +55,7 @@ #define CONFIG_POWER #define CONFIG_POWER_I2C #define CONFIG_POWER_FSL -#define CONFIG_PMIC_FSL_MC13892 +#define CONFIG_POWER_FSL_MC13892 #define CONFIG_SYS_FSL_PMIC_I2C_ADDR 0x8 #define CONFIG_RTC_MC13XXX -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] exynos: dts: Enable LCD for snow
Enable LCD for snow. This is a 1366 x 768 panel. Signed-off-by: Simon Glass --- arch/arm/dts/exynos5250-snow.dts | 44 1 file changed, 44 insertions(+) diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts index 42a687b..725a1bf 100644 --- a/arch/arm/dts/exynos5250-snow.dts +++ b/arch/arm/dts/exynos5250-snow.dts @@ -192,4 +192,48 @@ /* UP LEFT*/ 0x070b0067 0x070c0069>; }; + + fimd@1440 { + samsung,vl-freq = <60>; + samsung,vl-col = <1366>; + samsung,vl-row = <768>; + samsung,vl-width = <1366>; + samsung,vl-height = <768>; + + samsung,vl-clkp; + samsung,vl-dp; + samsung,vl-hsp; + samsung,vl-vsp; + + samsung,vl-bpix = <4>; + + samsung,vl-hspw = <32>; + samsung,vl-hbpd = <80>; + samsung,vl-hfpd = <48>; + samsung,vl-vspw = <5>; + samsung,vl-vbpd = <14>; + samsung,vl-vfpd = <3>; + samsung,vl-cmd-allow-len = <0xf>; + + samsung,winid = <0>; + samsung,interface-mode = <1>; + samsung,dp-enabled = <1>; + samsung,dual-lcd-enabled = <0>; + }; + + dp@145b { + samsung,lt-status = <0>; + + samsung,master-mode = <0>; + samsung,bist-mode = <0>; + samsung,bist-pattern = <0>; + samsung,h-sync-polarity = <0>; + samsung,v-sync-polarity = <0>; + samsung,interlaced = <0>; + samsung,color-space = <0>; + samsung,dynamic-range = <0>; + samsung,ycbcr-coeff = <0>; + samsung,color-depth = <1>; + }; + }; -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] exynos: dts: Disable cros_ec interrupts due to broken GPIOs
At present the GPIO numbering patch has not been applied, so exynos GPIO numbering is inconsistent (there are large gaps). Disable interrupts to avoid a crash on boot. Signed-off-by: Simon Glass --- arch/arm/dts/exynos5250-snow.dts | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts index 9b48a0c..42a687b 100644 --- a/arch/arm/dts/exynos5250-snow.dts +++ b/arch/arm/dts/exynos5250-snow.dts @@ -44,7 +44,11 @@ reg = <0x1e>; compatible = "google,cros-ec"; i2c-max-frequency = <10>; - ec-interrupt = <&gpio 782 1>; + /* +* GPIO numbering is broken on exynos at present +* +* ec-interrupt = <&gpio 782 1>; +*/ }; power-regulator@48 { @@ -60,7 +64,11 @@ reg = <0>; compatible = "google,cros-ec"; spi-max-frequency = <500>; - ec-interrupt = <&gpio 782 1>; + /* +* GPIO numbering is broken on exynos at present +* +* ec-interrupt = <&gpio 782 1>; +*/ optimise-flash-write; status = "disabled"; }; -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/10] Enable LCD display on snow
This series adds a driver for TPS65090 and plumbs it in to get the LCD working correctly on snow. The display driver is already present, but needs information about the display to be provided in the device tree. The backlight also needs to be enabled - it is controlled by a FET on the TPS65090. Note that the TPS65090 is controlled by the device tree so will only be present if the board's device tree file specifies it. At present this is only the case for snow, but other exynos5 boards will use it (e.g. pit). Note: the TPS65090 driver was sent to the list around the middle of last year but was never applied. Aaron Durbin (3): exynos5: Enable tps65090 on smdk5250 power: Explicitly select pmic device's bus exynos5: support tps65090 pmic Simon Glass (6): power: Rename CONFIG_PMIC_... to CONFIG_POWER_... exynos: Enable PSHOLD in SPL exynos: dts: Disable cros_ec interrupts due to broken GPIOs exynos: dts: Enable LCD for snow exynos: Enable the LCD backlight for snow initcall: Improve debugging support Tom Wai-Hong Tam (1): power: Add support for TPS65090 PMU chip. arch/arm/cpu/armv7/exynos/lowlevel_init.c | 2 + arch/arm/dts/exynos5250-snow.dts| 56 +- board/samsung/common/board.c| 7 + board/samsung/smdk5250/exynos5-dt.c | 90 + doc/device-tree-bindings/power/tps65090.txt | 21 ++ drivers/power/pmic/Makefile | 1 + drivers/power/pmic/pmic_tps65090.c | 296 drivers/power/power_fsl.c | 6 +- drivers/power/power_i2c.c | 4 + include/configs/arndale.h | 4 +- include/configs/exynos5-dt.h| 1 + include/configs/exynos5250-dt.h | 2 +- include/configs/mx25pdk.h | 2 +- include/configs/mx35pdk.h | 2 +- include/configs/mx53evk.h | 2 +- include/configs/mx53loco.h | 2 +- include/configs/woodburn_common.h | 2 +- include/fdtdec.h| 1 + include/initcall.h | 2 +- include/power/tps65090_pmic.h | 83 lib/fdtdec.c| 1 + lib/initcall.c | 17 +- 22 files changed, 585 insertions(+), 19 deletions(-) create mode 100644 doc/device-tree-bindings/power/tps65090.txt create mode 100644 drivers/power/pmic/pmic_tps65090.c create mode 100644 include/power/tps65090_pmic.h -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Load kernel from JFFS2 / Bad Data CRC
Ok, I've found my error I don't used FTP in binary mode when I download file in filesystem. Sorry, for the disruption. Sophie -- View this message in context: http://u-boot.10912.n7.nabble.com/Load-kernel-from-JFFS2-Bad-Data-CRC-tp176605p176610.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/phy: Fix PHY id for VSC8514
In the current Datasheet for VSC8514 there is a mistake, saying that the PHY id is 0x70570. The real value in the identifier registers is 0x70670. Linux PHY driver uses 0x70670 also. Signed-off-by: Codrin Ciubotariu Cc: York Sun --- drivers/net/phy/vitesse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index c555979..3a55d27 100644 --- a/drivers/net/phy/vitesse.c +++ b/drivers/net/phy/vitesse.c @@ -296,7 +296,7 @@ static struct phy_driver VSC8574_driver = { static struct phy_driver VSC8514_driver = { .name = "Vitesse VSC8514", - .uid = 0x70570, + .uid = 0x70670, .mask = 0x0, .features = PHY_GBIT_FEATURES, .config = &vsc8514_config, -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/cpu/mpc85xx: Add MAC address for layer 2 switch
T1040RDB and T1040QDS boards have an integrated l2 switch. The switch needs a MAC address for Layer 2 protocols (MSTP, LLDP, LACP, etc). Setting a MAC address on l2switchaddr will add a MAC in device-tree, under node l2switch. Signed-off-by: Codrin Ciubotariu Cc: York Sun --- arch/powerpc/cpu/mpc85xx/fdt.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c index 33bc900..7866545 100644 --- a/arch/powerpc/cpu/mpc85xx/fdt.c +++ b/arch/powerpc/cpu/mpc85xx/fdt.c @@ -582,6 +582,28 @@ static void fdt_fixup_usb(void *fdt) #define fdt_fixup_usb(x) #endif +#if defined(CONFIG_T1040RDB) || defined(CONFIG_T1040QDS) +static void fdt_fixup_l2_switch(void *blob) +{ + uchar l2swaddr[6]; + int node; + + node = fdt_node_offset_by_compatible(blob, -1, "vitesse-9953"); + if (node == -FDT_ERR_NOTFOUND) + /* no l2switch node has been found */ + return; + + if (!eth_getenv_enetaddr("l2switchaddr", l2swaddr)) { + printf("Warning: MAC address for l2switch not found\n"); + memset(l2swaddr, 0, sizeof(l2swaddr)); + } + fdt_setprop(blob, node, "local-mac-address", l2swaddr, + sizeof(l2swaddr)); +} +#else +#define fdt_fixup_l2_switch(x) +#endif + void ft_cpu_setup(void *blob, bd_t *bd) { int off; @@ -719,6 +741,8 @@ void ft_cpu_setup(void *blob, bd_t *bd) "clock-frequency", gd->bus_clk/2, 1); fdt_fixup_usb(blob); + + fdt_fixup_l2_switch(blob); } /* -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Load kernel from JFFS2 / Bad Data CRC
More information : when I compare the file download in ram with fsload and nand read I have a word of difference ... If someone have an idea ... thanks sophie fsload 100 uImage ### JFFS2 loading 'uImage' to 0x100 ### JFFS2 load complete: 3287019 bytes loaded to 0x100 One9x> nand read 200 $nandbootaddr $nandimgsize NAND read: device 0 offset 0x1010, size 0x40 4194304 bytes read: OK One9x> cmp 100 200 $nandimgsize word at 0x01013a48 (0x490daeaf) != word at 0x02013a48 (0x490d00ae) Total of 20114 word(s) were the same One9x> fsload c0 rootfs ### JFFS2 loading 'rootfs' to 0xc0 ### JFFS2 load complete: 24973697 bytes loaded to 0xc0 One9x> nand read 200 $nandramfsaddr $nandramfssize NAND read: device 0 offset 0x1050, size 0x180 25165824 bytes read: OK One9x> cmp c0 200 nandramfssize Total of 0 word(s) were the same One9x> cmp c0 200 $nandramfssize word at 0x00c0fcd0 (0xfdf0ddf) != word at 0x0200fcd0 (0xfdf0d00) Total of 16180 word(s) were the same One9x> fsload c0 dtb ### JFFS2 loading 'dtb' to 0xc0 ### JFFS2 load complete: 14843 bytes loaded to 0xc0 One9x> nand read 200 $nandfdtaddr $nandfdtsize NAND read: device 0 offset 0x11d0, size 0x10 1048576 bytes read: OK One9x> cmp c0 200 $nandfdtsize word at 0x00c01580 (0x2ab73) != word at 0x02001580 (0x2ab) Total of 1376 word(s) were the same -- View this message in context: http://u-boot.10912.n7.nabble.com/Load-kernel-from-JFFS2-Bad-Data-CRC-tp176605p176607.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
Dear Ian Campbell, In message <1395826756.22808.13.ca...@kazak.uk.xensource.com> you wrote: > > > Please add a comment to explain that. > > Unless you object I think I'll do as Marek suggested name the function > sunxi_name_to_gpio and make the #define to that, it seems more > consistent that way. That's better, indeed. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In any group of employed individuals the only naturally early riser is _always_ the office manager, who will _always_ leave reproachful little notes ... on the desks of their subordinates. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Load kernel from JFFS2 / Bad Data CRC
hello, I try to load from JFFS2 filesystem , the kernel,rootfs and DTB. and I have bad data CRC error on my file. Have you any idea of the reason ? I try to copy several kernel image in the filesystem i've got the same error, also with rootfs. I've no problem with "raw" file and using nand read in other MTD with the same kernel,rootfs, dtb. Sophie environnement : - u-boot 2013 from SDK freescale 1.4 - linux 3.8.13 from SDK freescale 1.4 - custom board based on P2020 STEP 1 - In Linux mount JFFS2 file system and copy kernel, rootfs and DTB. STEP 2 - In U-boot fsload 100 uImage ### JFFS2 loading 'uImage' to 0x100 ### JFFS2 load complete: 3287019 bytes loaded to 0x100 One9x> iminfo 100 ## Checking Image at 0100 ... Legacy image found Image Name: Linux-3.8.13-rt9-00053-g939d8fd- Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:3286999 Bytes = 3.1 MiB Load Address: Entry Point: Verifying Checksum ...Bad Data CRC One9x> Bad Data CRC configuration: I've define : #define CONFIG_CMD_JFFS2 #define CONFIG_JFFS2_NAND #define CONFIG_JFFS2_CMDLINE baudrate=9600 bootargs=root=/dev/ram rw ip=P2020_One9x:eth0:off console=ttyS0,9600 ramdisk_size=70 cache-sram-size=0x1 bootcmd=setenv bootargs root=/dev/ram rw ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate ramdisk_size=70 cache-sram-size=0x1;nand read 100 $nandbootaddr $nandimgsize;nand read 200 $nandramfsaddr $nandramfssize;nand read c0 $nandfdtaddr $nandfdtsize;bootm 100 200 c0 bootdelay=10 bootfile=uImage consoledev=ttyS0 eth1addr=00:11:22:33:44:55 ethact=eTSEC3 ethaddr=00:11:22:33:44:55 ethprime=eTSEC3 fdtaddr=0xc0 fdtfile=p2020one91.dtb fdtsize=10 filesize=3227eb hostname=P2020_One9x ipaddr=192.168.1.10 loadaddr=100 loads_echo=1 mtddevname=NAND_FILE_SYSTEM mtddevnum=1 mtdids=nand0=flash mtdparts=mtdparts=flash:1M(uboot),256M(NAND_FILE_SYSTEM),-(User_Data) nandbootaddr=1010 nandfdtaddr=11d0 nandfdtsize=10 nandimgsize=40 nandramfsaddr=1050 nandramfssize=180 netdev=eth0 nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr partition=nand0,1 ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs; tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr readJFFS2=fsload 100 kernel rootpath=/opt/nfsroot serverip=192.168.1.1 uboot=u-boot.bin updatenand= tftpboot $loadaddr uImage;nand erase $nandbootaddr $nandimgsize;nand write $loadaddr $nandbootaddr $nandimgsize;tftpboot 100 rootfs;nand erase $nandramfsaddr $nandramfssize;nand write $loadaddr $nandramfsaddr $nandramfssize;tftpboot $loadaddr $fdtfile;nand erase $nandfdtaddr $nandfdtsize;nand write $loadaddr $nandfdtaddr $nandfdtsize; Environment size: 2004/131068 bytes ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_ARMV7_NONSEC on altera soc (alignment issues ?)
Hi I am currently trying to configure either Altera Soc and Xilinx Zynq to boot Linux in nonsecure-mode. This mail focusses on the Altera SOC. As soon as the u-boot switched to normal mode it seems there is a problem with code alignment handling? At least it seems the code which is running beforehand stops working in normal mode and stops in either data_abort or prefetch handler. It stopps working when it hits the call to stdio_devices[file]->puts(s); in console_puts (console.c:255). print *stdio_devices[file] $2 = {flags = 16978471, ext = 16978464, name = "$\022\003\001\202\022\003\001\360\031\003\001\020\060\220", , start = 0xe92d4070, stop = 0xe2806010, putc = 0xe1530006, puts = 0xe1a04000, tstc = 0xe1a05001, getc = 0xe5810024, priv = 0x1a07, list = { next = 0xe5831004, prev = 0xe5813000}} As there are unaligned addresses (putc?) in these function calls i have the impression that this is not working in normal mode but in secure mode. Unfortunatly i was not able to get the mainline u-boot to boot on the altera soc so i patched the altera release: git://git.rocketboards.org/u-boot-socfpga.git with the 1740999a39ea4217bf926002d10869c0d925a5dc aka socfpga_v2013.01.01-rel branch. As the altera u-boot release socfpga_v2013.01.01-rel is to old to have the CONFIG_ARMV7_NONSEC patches i cherry-picked the following patches: d4296887544ddf95808bfb62f312008f519efb7bextend non-secure switch to also go into HYP mode ba6a1698116da272f14c53a3ae41467cb7fc4372add SMP support for non-secure switch bb975455650b1f36681de31a93ffe54952ed3a6btrigger non-secure state switch during bootm execution 1ef923851ab8ffcc4265fd991815b88d9c1f12d7add C function to switch to non-secure state 16212b594f385bd594d5d316bf11b13c1186e3d7add assembly routine to switch to non-secure state 45b940d6f9a9d4989452ea67480e299bfa51ee19add secure monitor handler to switch to non-secure state d75ba503a972df09784f1a332ba356ef8b42a0a6ARM: prepare armv7.h to be included from assembly source I also applied the attached hacked together patches to get the system running and fix up the stack pointer in normal mode as it pointed to 0. Best regards Tim>From ada1a10d612d8f123ff63b17a7b4e5d586a9a43a Mon Sep 17 00:00:00 2001 From: Tim Sander Date: Mon, 24 Mar 2014 15:12:47 +0100 Subject: [PATCH 1/3] CONFIG_ARMV7_NONSEC compile fixes --- arch/arm/cpu/u-boot.lds |1 + board/altera/socfpga/socfpga_common.c | 16 include/configs/socfpga_cyclone5.h|4 3 files changed, 21 insertions(+) diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index e6b202b..1ea1ac2 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -88,6 +88,7 @@ SECTIONS __bss_end__ = .; } + .rel.plt : { *(.rel.plt) } /DISCARD/ : { *(.dynstr*) } /DISCARD/ : { *(.dynamic*) } /DISCARD/ : { *(.plt*) } diff --git a/board/altera/socfpga/socfpga_common.c b/board/altera/socfpga/socfpga_common.c index 5e459bb..8f6d215 100644 --- a/board/altera/socfpga/socfpga_common.c +++ b/board/altera/socfpga/socfpga_common.c @@ -81,4 +81,20 @@ int designware_board_phy_init(struct eth_device *dev, int phy_addr, } return 0; } + +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT) +/* Setting the address at which secondary cores start from. + * Versatile Express uses one address for all cores, so ignore corenr + */ +void smp_set_core_boot_addr(unsigned long addr, int corenr) +{ +/* The SYSFLAGS register on VExpress needs to be cleared first + * by writing to the next address, since any writes to the address + * at offset 0 will only be ORed in + */ +writel(~0, CONFIG_SYSFLAGS_ADDR + 4); +writel(addr, CONFIG_SYSFLAGS_ADDR); +} +#endif + #endif diff --git a/include/configs/socfpga_cyclone5.h b/include/configs/socfpga_cyclone5.h index 106c52c..a2b8b3b 100644 --- a/include/configs/socfpga_cyclone5.h +++ b/include/configs/socfpga_cyclone5.h @@ -35,4 +35,8 @@ #define CONFIG_EPHY_PHY_ADDR CONFIG_EPHY1_PHY_ADDR #define CONFIG_PHY_INTERFACE_MODE SOCFPGA_PHYSEL_ENUM_RGMII +#define CONFIG_ARMV7_NONSEC +#define CONFIG_SYSFLAGS_ADDR0x1c010030 +#define CONFIG_SMP_PEN_ADDR CONFIG_SYSFLAGS_ADDR + #endif /* __CONFIG_H */ -- 1.7.9.5 >From 7ead8c23659ad64dfdf54994f0e1c9f6e376b6aa Mon Sep 17 00:00:00 2001 From: Tim Sander Date: Wed, 26 Mar 2014 13:37:17 +0100 Subject: [PATCH 2/3] restore stack pointer in normal mode, remove prints in u-boot final stage, add GIC_BASE_ADDRESS --- arch/arm/cpu/armv7/nonsec_virt.S |5 + arch/arm/cpu/armv7/virt-v7.c | 18 +++--- arch/arm/include/asm/armv7.h |7 --- arch/arm/lib/bootm.c |2 +- common/bootstage.c |3 +++ include/configs/socfpga_common.h |2 ++ include/configs/socfpga_cyclone5.h |1 + 7 files changed, 31 insertions(+), 7 deletions(-) diff --git a/arch/arm/cpu/armv7/nonsec_vi
[U-Boot] Serial init
I am trying to do console init before dram init so that I can give inputs from serial port and then initialize dram and bring up uboot. But there seems to be some linnking problem. I used serial_init and checked the makefiles. They seem to be fine. But still when I call serial_init before dram init, I get undefined reference to serial_init error. Please help ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 rom API
Hi, I see in u-boot sources that the L2 cache is enabled and invalidated on OMAP3 using secure monitor calls. Where can I find the documentation for these calls? I see that the corresponding information is available for instance for DM8148 in its TRM, but not in OMAP3530 TRM. I am interested in the call to set the L2 cache auxiliary control register, if it exists. Thanks in advance. Regards. -- Gilles. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/t4240: updated RCW and PBI for rev2.0
From: Shaohui Xie Also, remove workaround of rev1.0. Signed-off-by: Shaohui Xie --- board/freescale/t4qds/t4_pbi.cfg | 14 -- board/freescale/t4qds/t4_rcw.cfg | 6 +++--- 2 files changed, 3 insertions(+), 17 deletions(-) diff --git a/board/freescale/t4qds/t4_pbi.cfg b/board/freescale/t4qds/t4_pbi.cfg index c598fb5..6126266 100644 --- a/board/freescale/t4qds/t4_pbi.cfg +++ b/board/freescale/t4qds/t4_pbi.cfg @@ -13,20 +13,6 @@ 09000d00 09000d04 fff8 09000d08 8112 -#workaround for IFC bus speed -091241c0 f03f3f3f -091241c4 ff003f3f -09124010 0101 -09124130 000c -#workaround for SERDES A-006031 -090ea000 064740e6 -090ea020 064740e6 -090eb000 064740e6 -090eb020 064740e6 -090ec000 064740e6 -090ec020 064740e6 -090ed000 064740e6 -090ed020 064740e6 #Configure alternate space 0910 0914 ff00 diff --git a/board/freescale/t4qds/t4_rcw.cfg b/board/freescale/t4qds/t4_rcw.cfg index 74df01a..076fbc9 100644 --- a/board/freescale/t4qds/t4_rcw.cfg +++ b/board/freescale/t4qds/t4_rcw.cfg @@ -1,7 +1,7 @@ #PBL preamble and RCW header aa55aa55 010e0100 #serdes protocol 1_28_6_12 -120c0019 0c101915 -04383063 30548c00 6c02 1d00 +16070019 18101916 +04383060 30548c00 6c02 f500 eeee 000307fc - 0020 + 0028 -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] trats/trats2: enable CONFIG_RANDOM_UUID
Hello Stephen, On 03/25/2014 08:51 PM, Stephen Warren wrote: On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: Signed-off-by: Przemyslaw Marczak Patch description? Why are these function useful on these platforms? For completeness (I have no real ack power of Samsung platforms), Acked-by: Stephen Warren Ok, I add some more description. And thank you for review. Regards -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/6] lib: uuid: add functions to generate UUID version 4
Hello Stephen, On 03/25/2014 08:28 PM, Stephen Warren wrote: On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: This patch adds support to generate UUID (Universally Unique Identifier) in version 4 based on RFC4122, which is randomly. Source: https://www.ietf.org/rfc/rfc4122.txt Some nits in the comments below, but otherwise: Acked-by: Stephen Warren diff --git a/include/uuid.h b/include/uuid.h +/* This is structure is in big-endian */ +struct uuid { Not any more; with the introduction of enum uuid_str_t, some of the fields could be either LE or BE. I would say "See the comment near the top of lib/uuid.c for details of the endianness of fields in this struct". No, those fields are always in big-endian. So no matter what is architecture endianess - this data should be stored as big endian. Only string representation has different character order for GUID. diff --git a/lib/uuid.c b/lib/uuid.c /* * UUID - Universally Unique IDentifier - 128 bits unique number. *There are 5 versions and one variant of UUID defined by RFC4122 - *specification. Depends on version uuid number base on a time, - *host name, MAC address or random data. + *specification. Depends on version uuid number base on: I still have no idea what "Depends on version uuid number base on" means. It means that each UUID version "result" depends on different source data, as listed here... + *- time, MAC address(v1), + *- user ID(v2), + *- MD5 of name or URL(v3), + *- random data(v4), + *- SHA-1 of name or URL(v5), + * + * This library implements UUID v4. I think that should say "gen_rand_uuid()" not "This library", since the source of the data in the UUID fields only matters when creating the UUID, not when performing str<->bin conversion. Yes, right notice. + * + * Layout of UUID Version 4: I should remove "Version 4" in the comment subject, because layout refers to all uuid versions. + * timestamp - 60-bit: time_low, time_mid, time_hi_and_version + * version - 4 bit (bit 4 through 7 of the time_hi_and_version) + * clock seq - 14 bit: clock_seq_hi_and_reserved, clock_seq_low + * variant: - bit 6 and 7 of clock_seq_hi_and_reserved + * node - 48 bit + * In this version all fields beside 4 bit version are randomly generated. + * source: https://www.ietf.org/rfc/rfc4122.txt gen_rand_uuid() doesn't actually honor that format; it creates pure random data rather than filling in any timestamps, clock sequence data, etc. Actually, yes but two fields are NOT set randomly, and this is what comment includes: "In this version all fields beside 4 bit version are randomly generated." Moreover the gen_rand_uuid() respects endianess for setting bits, and this could be checked on linux host by "uuid -d uboot_uuid_string" in shell. Thanks -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/6] cmd:gpt: randomly generate each partition uuid if undefined
Hello Stephen, On 03/25/2014 08:51 PM, Stephen Warren wrote: On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: Changes: - randomly generate partition uuid if any is undefined and CONFIG_RAND_UUID is defined - print debug info about set/unset/generated uuid - update doc/README.gpt Update existing code to the new library functions. The changelog should be below the --- line, and a patch description should exist. This is the patch description:) and there is also change log below "---", but okay I can make some edits. Assuming the comments below are fixed, Acked-by: Stephen Warren diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c -static char extract_env(const char *str, char **env) +static int extract_env(const char *str, char **env) { + int ret = -1; char *e, *s; - +#ifdef CONFIG_RANDOM_UUID + char uuid_str[UUID_STR_LEN + 1]; +#endif if (!str || strlen(str) < 4) The blank line needs to be after the #endif not before the #ifdef, so the variable declarations are separate from the code. Ok. return -1; - if ((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}')) { - s = strdup(str); - if (s == NULL) - return -1; - memset(s + strlen(s) - 1, '\0', 1); - memmove(s, s + 2, strlen(s) - 1); + if (!((strncmp(str, "${", 2) == 0) && (str[strlen(str) - 1] == '}'))) + return -1; Since you're inverting that test, you need to change && to || too. No, because the invertion refers to the result of "if" - not one of conditions. !(cond1 && cond2) is the same as: (!cond1 || !cond2) so this change is ok. diff --git a/doc/README.gpt b/doc/README.gpt index 5c133f3..51515c8 100644 --- a/doc/README.gpt +++ b/doc/README.gpt @@ -101,7 +101,7 @@ Offset SizeDescription 40 8 B First usable LBA for partitions (primary partition table last LBA + 1) 48 8 B Last usable LBA (secondary partition table first LBA - 1) -56 16 BDisk GUID (also referred as UUID on UNIXes) +56 16 BDisk GUID (also referred as UUID on UNIXes) in big endian According to your earlier comment, GUIDs have a mix of LE and BE fields, so I would simply drop this change and the similar change below. Let wikipedia or the comment you added near to top of lib/uuid.c specify the details. Actually I think that this is an important info here. The information about endianness is also placed in few places in lib/uuid.c @@ -160,6 +160,9 @@ To restore GUID partition table one needs to: Fields 'name', 'size' and 'uuid' are mandatory for every partition. The field 'start' is optional. + option: CONFIG_RANDOM_UUID + If any partition "uuid" no exists then it is randomly generated. s/"uuid"/UUID/ Ok. Thanks -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/6] new commands: uuid and guid - generate random unique identifier
Hello Stephen, On 03/25/2014 08:37 PM, Stephen Warren wrote: On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: Those commands basis on implementation of random UUID generator version 4 which is described in RFC4122. The same algorithm is used for generation both ids but string representation is different as below. char: 0914 19 24 36 ---- UUID: be be be be be GUID: le le le be be Commands usage: - uuid - guid Square brackets are usually used to indicate optional parameters: - uuid [] - guid [] Ok, I change this. diff --git a/include/common.h b/include/common.h #if defined(CONFIG_RANDOM_MACADDR) || \ defined(CONFIG_BOOTP_RANDOM_DELAY) || \ defined(CONFIG_CMD_LINK_LOCAL) || \ - defined(CONFIG_RANDOM_UUID) + defined(CONFIG_RANDOM_UUID) || \ + defined(CONFIG_CMD_UUID) Why not require that if you want to use CONFIG_CMD_UUID, you must define CONFIG_RANDOM_UUID too? You can even make that automatic in include/config_fallbacks.h which already does similar things: #if defined(CONFIG_CMD_FAT) && !defined(CONFIG_FS_FAT) #define CONFIG_FS_FAT #endif That way, you won't need to touch lib/Makefile in this patch either, or modify the ifdef that wraps gen_rand_uuid(). I change this part of code in one of my other patch set which can be found here: http://patchwork.ozlabs.org/patch/332499/ After apply those changes then I add some automation here. diff --git a/lib/uuid.c b/lib/uuid.c +#ifdef CONFIG_CMD_UUID +int do_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) +{ + char uuid[UUID_STR_LEN + 1]; + uuid_str_t str_format; + + if (!strcmp(argv[0], "uuid")) + str_format = UUID_STR_FORMAT_STD; + else + str_format = UUID_STR_FORMAT_GUID; + + if (argc == 1) { + gen_rand_uuid_str(uuid, str_format); + printf("%s\n", uuid); + } else if (argc == 2) { + gen_rand_uuid_str(uuid, str_format); + setenv(argv[1], uuid); + } else { + return CMD_RET_USAGE; + } This duplicates some code; the call to gen_rand_uuid(). I think it would be better as: if (argc < 2) return CMD_RET_USAGE; gen_rand_uuid_str(uuid, str_format); if (argc == 1) printf("%s\n", uuid); else setenv(argv[1], uuid); Yes, this is better, but the first condition should be as: if ((argc != 1) || (argc != 2)) +U_BOOT_CMD(uuid, CONFIG_SYS_MAXARGS, 1, do_uuid, + "UUID - generate Universally Unique Identifier version 4", Would it be batter to say "a random ..." rather than "... version 4"? I'm not sure if the details of the version matter so long as its a valid UUID, and certainly the fact the generated UUID is random is likely more interesting. + "\n" "[]\n" Ok, I also apply those two commands above. Thanks -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x: i2c: bus 2 issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/26/2014 07:10 AM, Ilya Ledvich wrote: > Hello, Recently I've found a problem with I2C bus 2 on AM335X based > devices. Executing the command "i2c dev 2" in the u-boot CLI causes > CPU reset. The issue is found on v2013.10, v2014.01 and > v2014.04-rc1 and appears on BeagleBone and CM-T335 devices. Please > see the log taken from BeagleBone: The clocks aren't being enabled for i2c2 and at least on beaglebone/etc neither is the pinmux, just i2c0/i2c1. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTMsFrAAoJENk4IS6UOR1WNXsP/Rz9tLZbw91SBfSVWrf6Fjvk hQf5OS6zYPAbPXO9L81ZeARXPsNmsC5tn7UANrr+AFwTw+7nUKjALNu5bygE4JRy QxSn8JHaMounLgXy1Gp5VLQYY0dqqq6C8EuLCWbYsg8l0fIdciJae4br8+pHYcnh /4wLigMuP4hbihLw7Zx3BYofgzlM/KNqF/Csrqy/UXPn9vKVzyimZRAOdSeLrEkP rEO1In5s1hu6QkGepIb1pwIOdDYYZKJnAhhHFPZdb8U/sYFr5znEV6KtFQk3MrKy QpUC4H0mdl1u87C+z071OX63Ubiclve455CGA94JtFoBAMLJIXGrY7mgu9o+Invz a4lrfbrLeduhPtTpMO3ht0k833as/ok7jSgdz4xtzI8r5SoJOb9cO3Oj/gtFhbwu 29DWSGCfQWjWNspMncTbH9bcb/aXOjbRPbyYiv5af5hY0qIexi2Zn1cnPvsst+qh SCZda5DSRbc9sGLl/xVhWoWfe6eFFUZbDD40RQk9LI6oQdYWeJp/MdCVhg8ukQwo lJgUIyadbGG/HQ6hcZtapErhXRpBSB1nvc4t4UDihMFBbMZe5Q1O75mF0xbKe2xi aH/rnrYomSBmnChm+3DVatheSLill06x01gExGfqySQHhm+ASBKltVmR3pjpLf9/ seu0MaggJ+KimuhOLSYL =1b6v -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/6] lib: uuid: code refactor for proper maintain between uuid bin and string
Hello Stephen, Thanks for review again:) On 03/25/2014 08:12 PM, Stephen Warren wrote: On 03/19/2014 11:58 AM, Przemyslaw Marczak wrote: Changes in lib/uuid.c to: - uuid_str_to_bin() - uuid_bin_to_str() New parameter is added to specify input/output string format in listed functions This change allows easy recognize which UUID type is or should be stored in given string array. Binary data of UUID and GUID is always stored in big endian, only string representations are different as follows. String byte: 0 36 String char: ---- string UUID:be be be be be string GUID:le le le be be This patch also updates functions calls and declarations in a whole code. Ah, this patch pretty much solves all the comments I had on patch 1/6, so feel free to ignore those. Just a couple minor points below, but otherwise, patches 1 and 2, Acked-by: Stephen Warren Ok, thank you. diff --git a/include/uuid.h b/include/uuid.h +typedef enum { + UUID_STR_FORMAT_STD, + UUID_STR_FORMAT_GUID +} uuid_str_t; I would rename "STD" to "UUID"; after all, someone wanting to use GUIDs might think /that/ is the standard format:-) But this is a bit bike-sheddy/nit-picky, so if you don't want to I won't object. Actually I think that UUID_STR_FORMAT_UUID gives no information that this the main format of UUID, so I prefer to leave STD. diff --git a/lib/uuid.c b/lib/uuid.c +void uuid_bin_to_str(unsigned char *uuid_bin, char *uuid_str, +uuid_str_t str_format) { - static const u8 le[16] = {3, 2, 1, 0, 5, 4, 7, 6, 8, 9, 10, 11, - 12, 13, 14, 15}; + const u8 uuid_char_order[UUID_BIN_LEN] = {0, 1, 2, 3, 4, 5, 6, 7, 8, + 9, 10, 11, 12, 13, 14, 15}; + const u8 guid_char_order[UUID_BIN_LEN] = {3, 2, 1, 0, 5, 4, 7, 6, 8, + 9, 10, 11, 12, 13, 14, 15}; These are really more binary data order than char order, since each one of the bytes pointed at by entries in these arrays ends up being 2 characters. s/char/bin/ in the variable names perhaps? Yes, you are right. But according to the specification UUID and UUID bin format are always in big-endian - only bytes in some STRING blocks have different order. This works in two ways but to be consistent with specification I called this as "uuid_char_order". And this is directly used by sprintf: "sprintf(uuid_str, "%02x", uuid_bin[char_order[i]]);". + const u8 *char_order; int i; + /* +* UUID and GUID bin data - always in big endian: +* 4B-2B-2B-2B-6B +* be be be be be Strings don't really have an endianness, since they're already byte data. Rather than endianness, you really mean "normal numerical digit ordering". This comment also applies to the description of UUID string formats in patch 1/6. Right but the comment above says about "bin" data (16B len). Thanks -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] am335x: i2c: bus 2 issue
Hello, Recently I've found a problem with I2C bus 2 on AM335X based devices. Executing the command "i2c dev 2" in the u-boot CLI causes CPU reset. The issue is found on v2013.10, v2014.01 and v2014.04-rc1 and appears on BeagleBone and CM-T335 devices. Please see the log taken from BeagleBone: U-Boot SPL 2014.01 (Mar 26 2014 - 10:13:48) No AC power, disabling frequency switch reading args spl: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.01 (Mar 26 2014 - 10:13:48) I2C: ready DRAM: 256 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment Net:not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt ** Unable to read file uEnv.txt ** ** File not found /boot/zImage ** Card did not respond to voltage select! mmc1(part 0) is current device Card did not respond to voltage select! Booting from nand ... no devices available no devices available Bad Linux ARM zImage magic! U-Boot# U-Boot# i2c dev 0 Setting bus to 0 U-Boot# i2c dev 1 Setting bus to 1 U-Boot# i2c dev 2 Setting bus to 2 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [<8f769b58>] lr : [<8f769b34>] sp : 8f62ddb0 ip : 00b41640 fp : r10: 0003 r9 : 8f62df28 r8 : 0036 r7 : 0001 r6 : 000186a0 r5 : 4819c000 r4 : 8f7a35f4 r3 : r2 : 004b r1 : 00030d40 r0 : 003c Flags: Nzcv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... Best regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
On Wednesday, March 26, 2014 at 10:39:16 AM, Ian Campbell wrote: > On Wed, 2014-03-26 at 10:03 +0100, Wolfgang Denk wrote: > > Dear Ian Campbell, > > > > In message <1395822781.29683.12.ca...@dagon.hellion.org.uk> you wrote: > > > On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > > > > +int sunxi_gpio_set_cfgpin(u32 pin, u32 val); > > > > > +int sunxi_gpio_get_cfgpin(u32 pin); > > > > > +int sunxi_gpio_set_drv(u32 pin, u32 val); > > > > > +int sunxi_gpio_set_pull(u32 pin, u32 val); > > > > > +int name_to_gpio(const char *name); > > > > > +#define name_to_gpio name_to_gpio > > > > > > > > What is this ugly define doing here ? > > > > > > common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or > > > not) a default fallback implementation. I think this is a reasonably > > > (but not very) common idiom for such cases where the non-default > > > variant is not best expressed as a macro. > > > > Please add a comment to explain that. > > Unless you object I think I'll do as Marek suggested name the function > sunxi_name_to_gpio and make the #define to that, it seems more > consistent that way. I'd suggest you fix cmd_gpio.c while at it too ;-) 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 2/9] sunxi: initial sun7i pinmux and gpio support
On Wed, 2014-03-26 at 10:03 +0100, Wolfgang Denk wrote: > Dear Ian Campbell, > > In message <1395822781.29683.12.ca...@dagon.hellion.org.uk> you wrote: > > On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > > > > > +int sunxi_gpio_set_cfgpin(u32 pin, u32 val); > > > > +int sunxi_gpio_get_cfgpin(u32 pin); > > > > +int sunxi_gpio_set_drv(u32 pin, u32 val); > > > > +int sunxi_gpio_set_pull(u32 pin, u32 val); > > > > +int name_to_gpio(const char *name); > > > > +#define name_to_gpio name_to_gpio > > > > > > What is this ugly define doing here ? > > > > common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or > > not) a default fallback implementation. I think this is a reasonably > > (but not very) common idiom for such cases where the non-default variant > > is not best expressed as a macro. > > Please add a comment to explain that. Unless you object I think I'll do as Marek suggested name the function sunxi_name_to_gpio and make the #define to that, it seems more consistent that way. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] raw data
Can the command be used to load raw data from a partition (GPT) in SATA SSD? Can you show example using the command? Thanks. On Mon, Mar 24, 2014 at 9:09 AM, wrote: > Hi, > >Is there a command to read raw data from a disk partition to memory? > Nand / mmc command is ok. > > > Best wishes, > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] unsigned long long in ARMv8
Hi, experts: in 32bit ARM SOC platform: u-boot use "unsigned long long" as a uint64 data type. So, if with 74bit ARM SOC: Long type : means a 64bit data type. So how to map "unsigned long long " to a "long" data type if compiling a 64bit u-boot? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
Dear Ian Campbell, In message <1395822781.29683.12.ca...@dagon.hellion.org.uk> you wrote: > On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > > > +int sunxi_gpio_set_cfgpin(u32 pin, u32 val); > > > +int sunxi_gpio_get_cfgpin(u32 pin); > > > +int sunxi_gpio_set_drv(u32 pin, u32 val); > > > +int sunxi_gpio_set_pull(u32 pin, u32 val); > > > +int name_to_gpio(const char *name); > > > +#define name_to_gpio name_to_gpio > > > > What is this ugly define doing here ? > > common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or > not) a default fallback implementation. I think this is a reasonably > (but not very) common idiom for such cases where the non-default variant > is not best expressed as a macro. Please add a comment to explain that. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de EMACS belongs in : Editor too big! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
Dear Ian, [Cc: list truncated / changed] In message <1395822638.29683.9.ca...@dagon.hellion.org.uk> you wrote: > > I looked at this transform in a few different contexts and one concern I > had was that readl and writel have barriers in them (after the read and > before the write respectively) while clrsetbits and friends do not. I They are supposed to. They map to the out_##type() / in_##type() standard I/O accessors which are supposed to be suitable to access device registers. I can see that the ARM implementation maps this to __raw_write##type() / __raw_read##type() and then to __arch_put##type() / __arch_get##type() which indeed do not include MBs. > But I think I am probably being overly cautious here and the obvious > transformation can be made. Anyone got any thoughts? I'm not an expert for ARM, but this indeed looks suspiscious - thanks for reporting this. It is conspicuous that Linux does not use out_##type() / in_##type() for ARM, and instead uses iowrite##type() / ioread##type() - which do include MBs. Albert - what do you think? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober! - Terry Pratchett, _Men at Arms_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
On Wednesday, March 26, 2014 at 09:33:01 AM, Ian Campbell wrote: > On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > > +int sunxi_gpio_set_cfgpin(u32 pin, u32 val); > > > +int sunxi_gpio_get_cfgpin(u32 pin); > > > +int sunxi_gpio_set_drv(u32 pin, u32 val); > > > +int sunxi_gpio_set_pull(u32 pin, u32 val); > > > +int name_to_gpio(const char *name); > > > +#define name_to_gpio name_to_gpio > > > > What is this ugly define doing here ? > > common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or > not) a default fallback implementation. I think this is a reasonably > (but not very) common idiom for such cases where the non-default variant > is not best expressed as a macro. This should be fixed, the name_to_gpio() there should be replaced by a __weak function. (patch is welcome) Nonetheless, in your case, please don't do #define FOO FOO, but choose some sensible name for the function. 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 2/9] sunxi: initial sun7i pinmux and gpio support
On Wednesday, March 26, 2014 at 09:30:38 AM, Ian Campbell wrote: > On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > > + cfg = readl(&pio->cfg[0] + index); > > > + cfg &= ~(0xf << offset); > > > + cfg |= val << offset; > > > + > > > + writel(cfg, &pio->cfg[0] + index); > > > > clrsetbits_le32() here. > > I looked at this transform in a few different contexts and one concern I > had was that readl and writel have barriers in them (after the read and > before the write respectively) while clrsetbits and friends do not. I > don't think this will matter for the read/modify/write bit twiddling > itself (since there are register dependencies) but I was slightly > concerned that the barriers were hiding the lack of explicit barriers > which would be required between the various reads/writes. > > But I think I am probably being overly cautious here and the obvious > transformation can be made. Anyone got any thoughts? +CC Tom, Albert . 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 2/9] sunxi: initial sun7i pinmux and gpio support
On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > +int sunxi_gpio_set_cfgpin(u32 pin, u32 val); > > +int sunxi_gpio_get_cfgpin(u32 pin); > > +int sunxi_gpio_set_drv(u32 pin, u32 val); > > +int sunxi_gpio_set_pull(u32 pin, u32 val); > > +int name_to_gpio(const char *name); > > +#define name_to_gpio name_to_gpio > > What is this ugly define doing here ? common/cmd_gpio.c uses the #ifndef name_to_gpio pattern to provide (or not) a default fallback implementation. I think this is a reasonably (but not very) common idiom for such cases where the non-default variant is not best expressed as a macro. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/9] sunxi: initial sun7i pinmux and gpio support
On Mon, 2014-03-24 at 21:54 +0100, Marek Vasut wrote: > > + cfg = readl(&pio->cfg[0] + index); > > + cfg &= ~(0xf << offset); > > + cfg |= val << offset; > > + > > + writel(cfg, &pio->cfg[0] + index); > > clrsetbits_le32() here. I looked at this transform in a few different contexts and one concern I had was that readl and writel have barriers in them (after the read and before the write respectively) while clrsetbits and friends do not. I don't think this will matter for the read/modify/write bit twiddling itself (since there are register dependencies) but I was slightly concerned that the barriers were hiding the lack of explicit barriers which would be required between the various reads/writes. But I think I am probably being overly cautious here and the obvious transformation can be made. Anyone got any thoughts? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.
On Mon, 2014-03-24 at 21:52 +0100, Marek Vasut wrote: > On Friday, March 21, 2014 at 10:54:18 PM, Ian Campbell wrote: > > This has been stripped back for mainlining and supports only sun7i. These > > changes are not useful by themselves but are split out to make the patch > > sizes more manageable. > > [...] Thanks for all your feedback here and on the other patches, I'll sort it all out. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/9] sunxi: initial sun7i clocks and timer support.
On Mon, 2014-03-24 at 23:42 +0100, Olliver Schinagl wrote: [...] > I've got a local cleanup patch set where I fixed this already to > clrsetbits_le32 >[...] > Same here, got that in my local tree too Could you post what you've got please? > >> +#ifdef CONFIG_SPL_BUILD > >> +#define PLL1_CFG(N, K, M, P) (1 << 31 | 0 << 30 | 8 << 26 | 0 << 25 | > > \ > >> + 16 << 20 | (P) << 16 | 2 << 13 | (N) << 8 | \ > >> + (K) << 4 | 0 << 3 | 0 << 2 | (M) << 0) > > Here is well. > dito :) > > > >> +#define RDIV(a, b)((a + (b) - 1) / (b)) > > This is some kind of DIV_ROUND_UP() from include/common.h ? > > > > [...] > That one i didn't have; > > Ian, I guess you can verify that generic macro works for here? Yeah, I'll look into that and all the other feedback from Marek. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v3] mpc85xx/t104x: Add deep sleep framework support
From: Tang Yuantian When T104x soc wakes up from deep sleep, control is passed to the primary core that starts executing uboot. After re-initialized some IP blocks, like DDRC, kernel will take responsibility to continue to restore environment it leaves before. Signed-off-by: Tang Yuantian --- v3: - fix out-of-tree compile warning v2: - added explaination for CONFIG_DEEP_SLEEP - fixed some issues README | 4 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c| 7 arch/powerpc/cpu/mpc85xx/fdt.c | 22 arch/powerpc/cpu/mpc85xx/liodn.c | 27 ++ arch/powerpc/cpu/mpc85xx/start.S | 9 + arch/powerpc/include/asm/global_data.h | 2 ++ arch/powerpc/lib/board.c | 66 +++--- drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 42 +++--- include/fdt_support.h | 4 +++ include/fsl_ddr_sdram.h| 4 +++ 10 files changed, 171 insertions(+), 16 deletions(-) diff --git a/README b/README index 216f0c7..25ffb90 100644 --- a/README +++ b/README @@ -427,6 +427,10 @@ The following options need to be configured: In this mode, a single differential clock is used to supply clocks to the sysclock, ddrclock and usbclock. + CONFIG_DEEP_SLEEP + Inidcates this SoC supports deep sleep feature. If deep sleep is + supported, core will start to execute uboot when wakes up. + - Generic CPU options: CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 81aeadd..1be29f8 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -279,6 +279,7 @@ void cpu_init_f (void) #ifdef CONFIG_MPC8548 ccsr_local_ecm_t *ecm = (void *)(CONFIG_SYS_MPC85xx_ECM_ADDR); uint svr = get_svr(); + gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET); /* * CPU2 errata workaround: A core hang possible while executing @@ -330,6 +331,12 @@ void cpu_init_f (void) in_be32(&gur->dcsrcr); #endif +#ifdef CONFIG_DEEP_SLEEP + /* disable the console if boot from deep sleep */ + if (in_be32(&gur->scrtsr[0]) & (1 << 3)) + gd->flags |= GD_FLG_SILENT | + GD_FLG_DEEP_SLEEP | GD_FLG_DISABLE_CONSOLE; +#endif } /* Implement a dummy function for those platforms w/o SERDES */ diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c index 33bc900..9351f63 100644 --- a/arch/powerpc/cpu/mpc85xx/fdt.c +++ b/arch/powerpc/cpu/mpc85xx/fdt.c @@ -35,6 +35,9 @@ void ft_fixup_cpu(void *blob, u64 memory_limit) u32 bootpg = determine_mp_bootpg(NULL); u32 id = get_my_id(); const char *enable_method; +#ifdef CONFIG_DEEP_SLEEP + ulong len; +#endif off = fdt_node_offset_by_prop_value(blob, -1, "device_type", "cpu", 4); while (off != -FDT_ERR_NOTFOUND) { @@ -108,6 +111,25 @@ void ft_fixup_cpu(void *blob, u64 memory_limit) printf("Failed to reserve memory for spin table: %s\n", fdt_strerror(off)); } + +#ifdef CONFIG_DEEP_SLEEP + /* +* reserve the memory space for deep sleep. +* This space will be re-used next time when boot from deep sleep. +* The space includes bd_t, gd_t, stack and uboot image. +* Reserve 1K for stack. +*/ + len = sizeof(bd_t) + sizeof(gd_t) + (1 << 10); + /* round up to 4K */ + len = (len + (4096 - 1)) & ~(4096 - 1); + + off = fdt_add_mem_rsv(blob, gd->relocaddr - len, + len + ((ulong)&__bss_end - gd->relocaddr)); + if (off < 0) + printf("Failed to reserve memory for deep sleep: %s\n", + fdt_strerror(off)); + +#endif } #endif diff --git a/arch/powerpc/cpu/mpc85xx/liodn.c b/arch/powerpc/cpu/mpc85xx/liodn.c index 19e130e..a166765 100644 --- a/arch/powerpc/cpu/mpc85xx/liodn.c +++ b/arch/powerpc/cpu/mpc85xx/liodn.c @@ -14,6 +14,8 @@ #include #include +DECLARE_GLOBAL_DATA_PTR; + int get_dpaa_liodn(enum fsl_dpaa_dev dpaa_dev, u32 *liodns, int liodn_offset) { liodns[0] = liodn_bases[dpaa_dev].id[0] + liodn_offset; @@ -164,6 +166,8 @@ static void setup_rman_liodn_base(struct liodn_id_table *tbl, int size) void set_liodns(void) { + bool is_deepsleep = false; + /* setup general liodn offsets */ set_liodn(liodn_tbl, liodn_tbl_sz); @@ -179,16 +183,25 @@ void set_liodns(void) } /* setup FMAN block(s) liodn bases & offsets if we have one */ +#ifdef CONFIG_DEEP_SLEEP + if (gd->flags & GD_FLG_DEEP_SLEEP) + is_deepsleep = true; +#endif + #ifdef CONFIG_SYS_DPAA_FMAN - set_liodn(fman1_liodn_tbl, fman1_liodn_tbl_sz); - setup_fman_li
[U-Boot] [PATCH 1/2 v2] mpc85xx: Add support for the supplement configuration unit register
From: Tang Yuantian The supplement configuration unit (SCFG) provides chip-specific configuration and status registers for the device. It is the chip defined module for extending the device configuration unit (DCFG) module. It provides a set of CCSR registers in addition to those available in the device configuration unit. The base address for this unit is 0x0F_C000. Signed-off-by: Tang Yuantian --- v2: - fix checkpatch warning arch/powerpc/include/asm/immap_85xx.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/powerpc/include/asm/immap_85xx.h b/arch/powerpc/include/asm/immap_85xx.h index 4b6f9d0..0f0f3d4 100644 --- a/arch/powerpc/include/asm/immap_85xx.h +++ b/arch/powerpc/include/asm/immap_85xx.h @@ -3151,4 +3151,26 @@ struct dcsr_dcfg_regs { #defineDCSR_DCFG_ECC_DISABLE_USB2 0x4000 u8 res_524[0x1000 - 0x524]; /* 0x524 - 0x1000 */ }; + +#define CONFIG_SYS_MPC85xx_SCFG \ + (CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_SCFG_OFFSET) +#define CONFIG_SYS_MPC85xx_SCFG_OFFSET 0xfc000 +/* The supplement configuration unit register */ +struct ccsr_scfg { + u32 dpslpcr;/* 0x000 Deep Sleep Control register */ + u32 usb1dpslpcsr;/* 0x004 USB1 Deep Sleep Control Status register */ + u32 usb2dpslpcsr;/* 0x008 USB2 Deep Sleep Control Status register */ + u32 fmclkdpslpcr;/* 0x00c FM Clock Deep Sleep Control register */ + u32 res1[4]; + u32 esgmiiselcr;/* 0x020 Ethernet Switch SGMII Select Control reg */ + u32 res2; + u32 pixclkcr; /* 0x028 Pixel Clock Control register */ + u32 res3[245]; + u32 qeioclkcr; /* 0x400 QUICC Engine IO Clock Control register */ + u32 emiiocr;/* 0x404 EMI MDIO Control Register */ + u32 sdhciovselcr;/* 0x408 SDHC IO VSEL Control register */ + u32 qmifrstcr; /* 0x40c QMAN Interface Reset Control register */ + u32 res4[60]; + u32 sparecr[8]; /* 0x500 Spare Control register(0-7) */ +}; #endif /*__IMMAP_85xx__*/ -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 6/6] arm: faraday: add virtual machine support
2014-03-26 14:52 GMT+08:00 Wolfgang Denk : > Dear Kuo-Jung Su, > > In message <1395813799-3672-7-git-send-email-dant...@gmail.com> you wrote: >> From: Kuo-Jung Su >> >> Faraday Virtual Machine (FVM) is a QEMU based emulator >> which is designed for early stage software development >> (i.e., IPL, SPL development). > ... >> +ulong clk_get_rate(const char *id) >> +{ >> + ulong ret = 0; >> + >> + if (!strcmp(id, "AHB")) >> + ret = clk_get_rate_ahb(); >> + else if (!strcmp(id, "APB")) >> + ret = clk_get_rate_apb(); >> + else if (!strcmp(id, "CPU")) >> + ret = clk_get_rate_cpu(); >> + else if (!strcmp(id, "I2C")) >> + ret = clk_get_rate_apb(); >> + else if (!strcmp(id, "SSP")) >> + ret = clk_get_rate_apb(); >> + else if (!strcmp(id, "SPI")) >> + ret = clk_get_rate_ahb(); >> + else if (!strcmp(id, "MMC") || !strcmp(id, "SDC")) >> + ret = clk_get_rate_ahb(); >> + >> + return ret; >> +} > > I have seen basically identical code in [PATCH v11 4/6] arm: faraday: > add A369 evaluation board; please move this (and other common code) > into a common location so we have only one implementation of common > code. > Got it, thanks -- Best wishes, Kuo-Jung Su ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v11 1/6] arm: add Faraday ARMv5TE cores support
2014-03-26 14:47 GMT+08:00 Wolfgang Denk : > Dear Kuo-Jung Su, > > In message <1395813799-3672-2-git-send-email-dant...@gmail.com> you wrote: >> From: Kuo-Jung Su >> >> Here is the list of verified cores: >> >> 1. FA606TE (ARMv5TE, no mmu) >> 2. FA626TE (ARMv5TE) > ... >> diff --git a/include/configs/faraday-common.h >> b/include/configs/faraday-common.h >> new file mode 100644 >> index 000..546c0a9 >> --- /dev/null >> +++ b/include/configs/faraday-common.h > ... >> +#ifndef CONFIG_ETHADDR >> +#define CONFIG_ETHADDR 00:41:71:00:00:50 >> +#endif >> + >> +#ifndef CONFIG_IPADDR >> +#define CONFIG_IPADDR 10.0.0.192 >> +#endif >> + >> +#ifndef CONFIG_NETMASK >> +#define CONFIG_NETMASK 255.255.255.0 >> +#endif >> + >> +#ifndef CONFIG_SERVERIP >> +#define CONFIG_SERVERIP 10.0.0.128 >> +#endif > > We do not allow such static network configuration. Especially > assigning the same MAC address to all devices is deadly. Also, > the address is not an officially assigned nor a local one. > Please remove all this code. > Got it, thanks >> +# endif >> +# ifndef CONFIG_G_DNL_VENDOR_NUM >> +# define CONFIG_G_DNL_VENDOR_NUM0x1d50 /* OpenMoko */ >> +# endif > > This looks wrong to me? > >> +# ifndef CONFIG_G_DNL_PRODUCT_NUM >> +# define CONFIG_G_DNL_PRODUCT_NUM 0x5119 >> +# endif > > Is this a valid ID? > By stealing the OpenMoko's vendor id & product id, I could directly use the OpenMoko dfu-util without any modifications. And unfortunately we don't have a registered OUI for Faraday Technology, so I'll remove this ID in the next release. >> +/* Console I/O Buffer Size */ >> +#define CONFIG_SYS_CBSIZE 256 >> + >> +/* Max number of command args */ >> +#define CONFIG_SYS_MAXARGS 32 > > You use a large number of args with a tiny console buffer? This looks > suspicious. Please check. > Got it, thanks >> +#define CONFIG_CMD_AUTOSCRIPT /* support autoscript */ > > This has been removed years ago. Please use CONFIG_CMD_SOURCE > instead. > Got it, thanks -- Best wishes, Kuo-Jung Su ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] beagle-bone fdt booting problem
Hi, I'm playing with fdt booting on beaglebone board. I'm using latest u-boot git HEAD (2c072c958bb544c72f0e848375803dbd6971f022) + I've added to am335x_evm confing : #ifndef CONFIG_SPL_BUILD #define CONFIG_OF_CONTROL #define CONFIG_OF_SEPARATE #endif I took beaglebone devicetree from kernel. Then I took patch [1] to build image from u-boot and my compiled DT blob. Booting this image always fails with: No valid FDT found - please append one to U-Boot binary, use u-boot-dtb.bin or define CONFIG_OF_EMBED. For sandbox, use -d ** CONFIG_OF_CONTROL defined but no FDT - please see doc/README.fdt-control I poke around this and find out that when CONFIG_OF_SEPARATE is used then fdt_blob is set to address of .__end pointer. When evaluate image with hexdump it seems that fdt blob (in my particular case and configuration) is shifted by 312 bytes from .__end. When I point gd->fdt_blob (hack in code) to that address it boots fine. Any ideas what I'm doing wrong (I must do something wrong as it seems nobody complains :)). [1] - http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commit;h=d4ab2022cdfe098e93819c58188ad36174160872 BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot