Re: [U-Boot] [PATCH] socfpga: Relocate arch common functions away from board
Hi Chin,
On Tue, 10 Jun 2014 01:41:06 -0500, Chin Liang See
wrote:
> To move the arch common function away from board folder to
> arch/arm/cpu/armv7/socfpga folder.
>
> Signed-off-by: Chin Liang See
> Cc: Wolfgang Denk
> Cc: Detlev Zundel
> Cc: Pavel Machek
> Cc: Dinh Nguyen
> ---
> arch/arm/cpu/armv7/socfpga/misc.c | 24
> board/altera/socfpga/socfpga_cyclone5.c | 23 ---
> 2 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/socfpga/misc.c
> b/arch/arm/cpu/armv7/socfpga/misc.c
> index 2f1c716..5268f2c 100644
> --- a/arch/arm/cpu/armv7/socfpga/misc.c
> +++ b/arch/arm/cpu/armv7/socfpga/misc.c
> @@ -14,3 +14,27 @@ int dram_init(void)
> gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
> return 0;
> }
> +
> +#if defined(CONFIG_DISPLAY_CPUINFO)
> +/*
> + * Print CPU information
> + */
> +int print_cpuinfo(void)
> +{
> + puts("CPU : Altera SOCFPGA Platform\n");
> + return 0;
> +}
> +#endif
> +
> +#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) && \
> +defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
> +int overwrite_console(void)
> +{
> + return 0;
> +}
> +#endif
> +
> +int misc_init_r(void)
> +{
> + return 0;
> +}
> diff --git a/board/altera/socfpga/socfpga_cyclone5.c
> b/board/altera/socfpga/socfpga_cyclone5.c
> index a960eb6..f366565 100644
> --- a/board/altera/socfpga/socfpga_cyclone5.c
> +++ b/board/altera/socfpga/socfpga_cyclone5.c
> @@ -12,17 +12,6 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -#if defined(CONFIG_DISPLAY_CPUINFO)
> -/*
> - * Print CPU information
> - */
> -int print_cpuinfo(void)
> -{
> - puts("CPU : Altera SOCFPGA Platform\n");
> - return 0;
> -}
> -#endif
> -
> /*
> * Print Board information
> */
> @@ -49,18 +38,6 @@ int board_init(void)
> return 0;
> }
>
> -int misc_init_r(void)
> -{
> - return 0;
> -}
> -
> -#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) &&
> defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
> -int overwrite_console(void)
> -{
> - return 0;
> -}
> -#endif
> -
> /*
> * DesignWare Ethernet initialization
> */
Can you clarify in the commit message why this change is needed or
useful?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] socfpga: Relocate arch common functions away from board
Hi Albert,
On Tue, 2014-06-10 at 09:07 +0200, ZY - albert.u.boot wrote:
> Hi Chin,
>
> On Tue, 10 Jun 2014 01:41:06 -0500, Chin Liang See
> wrote:
>
> > To move the arch common function away from board folder to
> > arch/arm/cpu/armv7/socfpga folder.
> >
> > Signed-off-by: Chin Liang See
> > Cc: Wolfgang Denk
> > Cc: Detlev Zundel
> > Cc: Pavel Machek
> > Cc: Dinh Nguyen
> > ---
> > arch/arm/cpu/armv7/socfpga/misc.c | 24
> > board/altera/socfpga/socfpga_cyclone5.c | 23 ---
> > 2 files changed, 24 insertions(+), 23 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/socfpga/misc.c
> > b/arch/arm/cpu/armv7/socfpga/misc.c
> > index 2f1c716..5268f2c 100644
> > --- a/arch/arm/cpu/armv7/socfpga/misc.c
> > +++ b/arch/arm/cpu/armv7/socfpga/misc.c
> > @@ -14,3 +14,27 @@ int dram_init(void)
> > gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
> > return 0;
> > }
> > +
> > +#if defined(CONFIG_DISPLAY_CPUINFO)
> > +/*
> > + * Print CPU information
> > + */
> > +int print_cpuinfo(void)
> > +{
> > + puts("CPU : Altera SOCFPGA Platform\n");
> > + return 0;
> > +}
> > +#endif
> > +
> > +#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) && \
> > +defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
> > +int overwrite_console(void)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > +int misc_init_r(void)
> > +{
> > + return 0;
> > +}
> > diff --git a/board/altera/socfpga/socfpga_cyclone5.c
> > b/board/altera/socfpga/socfpga_cyclone5.c
> > index a960eb6..f366565 100644
> > --- a/board/altera/socfpga/socfpga_cyclone5.c
> > +++ b/board/altera/socfpga/socfpga_cyclone5.c
> > @@ -12,17 +12,6 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > -#if defined(CONFIG_DISPLAY_CPUINFO)
> > -/*
> > - * Print CPU information
> > - */
> > -int print_cpuinfo(void)
> > -{
> > - puts("CPU : Altera SOCFPGA Platform\n");
> > - return 0;
> > -}
> > -#endif
> > -
> > /*
> > * Print Board information
> > */
> > @@ -49,18 +38,6 @@ int board_init(void)
> > return 0;
> > }
> >
> > -int misc_init_r(void)
> > -{
> > - return 0;
> > -}
> > -
> > -#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) &&
> > defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
> > -int overwrite_console(void)
> > -{
> > - return 0;
> > -}
> > -#endif
> > -
> > /*
> > * DesignWare Ethernet initialization
> > */
>
> Can you clarify in the commit message why this change is needed or
> useful?
>
Sure, let me send out the v2.
Its to avoid code duplication for other non Altera board which use
socfpga.
Thanks
Chin Liang
> Amicalement,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] socfpga: Relocate arch common functions away from board
To move the arch common function away from board folder to
arch/arm/cpu/armv7/socfpga folder. Its to avoid code duplication
for other non Altera dev kit which is using socfpga device.
Signed-off-by: Chin Liang See
Cc: Wolfgang Denk
Cc: Detlev Zundel
Cc: Pavel Machek
Cc: Dinh Nguyen
---
Changes for v2
- Added the purpose of the patch to commit message
---
arch/arm/cpu/armv7/socfpga/misc.c | 24
board/altera/socfpga/socfpga_cyclone5.c | 23 ---
2 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/arch/arm/cpu/armv7/socfpga/misc.c
b/arch/arm/cpu/armv7/socfpga/misc.c
index 2f1c716..5268f2c 100644
--- a/arch/arm/cpu/armv7/socfpga/misc.c
+++ b/arch/arm/cpu/armv7/socfpga/misc.c
@@ -14,3 +14,27 @@ int dram_init(void)
gd->ram_size = get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
return 0;
}
+
+#if defined(CONFIG_DISPLAY_CPUINFO)
+/*
+ * Print CPU information
+ */
+int print_cpuinfo(void)
+{
+ puts("CPU : Altera SOCFPGA Platform\n");
+ return 0;
+}
+#endif
+
+#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) && \
+defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
+int overwrite_console(void)
+{
+ return 0;
+}
+#endif
+
+int misc_init_r(void)
+{
+ return 0;
+}
diff --git a/board/altera/socfpga/socfpga_cyclone5.c
b/board/altera/socfpga/socfpga_cyclone5.c
index a960eb6..f366565 100644
--- a/board/altera/socfpga/socfpga_cyclone5.c
+++ b/board/altera/socfpga/socfpga_cyclone5.c
@@ -12,17 +12,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#if defined(CONFIG_DISPLAY_CPUINFO)
-/*
- * Print CPU information
- */
-int print_cpuinfo(void)
-{
- puts("CPU : Altera SOCFPGA Platform\n");
- return 0;
-}
-#endif
-
/*
* Print Board information
*/
@@ -49,18 +38,6 @@ int board_init(void)
return 0;
}
-int misc_init_r(void)
-{
- return 0;
-}
-
-#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) &&
defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
-int overwrite_console(void)
-{
- return 0;
-}
-#endif
-
/*
* DesignWare Ethernet initialization
*/
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sun5i: Add A13-OLinuXinoM support
Hi Hans, On Mon, 09 Jun 2014 09:56:01 +0200, Hans de Goede wrote: > Hi, > > On 06/09/2014 08:50 AM, Albert ARIBAUD wrote: > > Hi Tom, > > > > On Thu, 20 Mar 2014 08:49:37 -0400, Tom Rini wrote: > > > >> Tested-by: Matt Porter > >> Signed-off-by: Tom Rini > >> --- > > > > Where does this patch come from? The source tree it applies to is not > > that of mainline U-Boot. If this is actually an RFC that I should look > > into, (as the PW state says), then which repository does it apply to? > > This was posted by Tom as an add on patch to my: > "[PATCH u-boot sunxi 00/12] sun4i (v2) + sun5i + pmic + emac support" > > Series, which was a series on top of one of Ian's sun7i support > series: > > http://lists.denx.de/pipermail/u-boot/2014-March/175656.html > > In the mean time (as you know) Ians' series has gone upstream and > I've continued working on the series in question, with Ian > reviewing it. Actually I've just send you a pull-req with the > bits of this series which are ready to go upstream. Which includes > support for the A13-OLinuXinoM as part of the > "sunxi: Add sun5i support" patch. Thanks. Unfortunately, I had lost track of the dependencies -- which is a live example of why patches with dependencies should mention them explicitly after their commit message (not in it, though, as once applied, the dependency info is not relevant any more), so that folks like me can reconstruct the information. :) I'll process you patch series -- not "pull request", as I only pull from other (ARM-related only) U-Boot repos :) -- in a few days, then I'll handle Tom's patch. > Regards, > > Hans Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] omap3: overo: Select fdtfile for expansion board
Am 09.06.2014 22:47, schrieb Ash Charles:
The u-boot Overo board actually supports both Overo (OMAP35xx)
and Overo Storm (AM/DM37xx) COMs with a range of different expansion
boards. This provides a mechanism to select the an appropriate device
tree file based on the processor version and, if available, the
expansion board ID written on the expansion board EEPROM. To match the
3.15+ kernels, fdtfile names have this format:
"omap3-overo[-storm]-.dtb"
By default, we use "omap3-overo-storm-tobi.dtb".
Signed-off-by: Ash Charles
Conflicts:
include/configs/omap3_overo.h
---
board/overo/overo.c | 12
include/configs/omap3_overo.h | 10 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/board/overo/overo.c b/board/overo/overo.c
index 62b50a8..02b606c 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -267,12 +267,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "summit");
break;
case GUMSTIX_TOBI:
printf("Recognized Tobi expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "tobi");
break;
case GUMSTIX_TOBI_DUO:
printf("Recognized Tobi Duo expansion board (rev %d %s)\n",
@@ -293,12 +295,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "palo43");
break;
case GUMSTIX_CHESTNUT43:
printf("Recognized Chestnut43 expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "chestnut43");
break;
case GUMSTIX_PINTO:
printf("Recognized Pinto expansion board (rev %d %s)\n",
@@ -310,6 +314,7 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "gallop43");
break;
case GUMSTIX_ALTO35:
printf("Recognized Alto35 expansion board (rev %d %s)\n",
@@ -317,6 +322,7 @@ int misc_init_r(void)
expansion_config.fab_revision);
MUX_ALTO35();
setenv("defaultdisplay", "lcd35");
+ setenv("expansionname", "alto35");
break;
case GUMSTIX_STAGECOACH:
printf("Recognized Stagecoach expansion board (rev %d %s)\n",
@@ -352,6 +358,7 @@ int misc_init_r(void)
break;
default:
printf("Unrecognized expansion board 0x%08x\n", expansion_id);
+ setenv("expansionname", "tobi");
Why you set the 'expansionname' to 'tobi' for unknown (maybe foreign)
expansion boards?
break;
}
What happens if the eeprom is empty, no eeprom is available or the ETTUS
expansion board is present? In this case the expansionname is empty.
@@ -360,6 +367,11 @@ int misc_init_r(void)
dieid_num_r();
+if (get_cpu_family() == CPU_OMAP34XX)
+ setenv(boardname, "overo")
+else:
+ setenv(boardname, "overo-storm")
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 1a13633..f7483a0 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -83,7 +83,6 @@
/* Environment information */
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
- "fdtfile=overo.dtb\0" \
"bootdir=/boot\0" \
"bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
@@ -152,10 +151,11 @@
"run mmcboot;" \
"fi;" \
"if run loadzimage; then " \
- "if test -n $fdtfile; then " \
- "if run loadfdt; then " \
- "run mmcbootfdt;" \
- "fi;" \
+ "if test $fdtfile; then " \
+ "setenv fdtfile
omap3-${boardname}-${expansionname}.dtb;" \
+ "fi;" \
+ "if run loadfdt; then " \
+ "run mmcbootfdt;" \
"fi;" \
"fi;" \
"fi;" \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://l
Re: [U-Boot] [U-Boot, v5, 3/4] lib, fdt: move fdtdec_get_int() out of lib/fdtdec.c
Hello Tom, Am 05.06.2014 21:15, schrieb Tom Rini: On Wed, May 28, 2014 at 11:33:35AM +0200, Heiko Schocher wrote: move fdtdec_get_int() out of lib/fdtdec.c into lib/fdtdec_common.c as this function is also used, if CONFIG_OF_CONTROL is not used. Poped up on the ids8313 board using signed FIT images, and activating CONFIG_SYS_GENERIC_BOARD. Without this patch it shows on boot: 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 With this patch, it boots again with CONFIG_SYS_GENERIC_BOARD enabled. Signed-off-by: Heiko Schocher Acked-by: Simon Glass Cc: Tom Rini The problem is that on architectures with old compilers (sparc, blackfin, nds32) this doesn't get discarded due to not being used but instead causes link errors. Can you figure out which option (CONFIG_FIT_SIGNATURE I suspect) drives this need and make sure we include fdtdec_common.o then? Thanks! I look into it ... but I think it is not only one config option, as this code is not FIT specific and used also for code which uses DT ... (maybe CONFIG_OF_CONTROL or CONFIG_FIT_SIGNATURE). bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] sunxi: Add i2c support
Hi,
On 06/10/2014 08:33 AM, Heiko Schocher wrote:
> Hello Hans,
>
> Am 09.06.2014 17:15, schrieb Hans de Goede:
>> Add support for the i2c controller found on all Allwinner sunxi SoCs,
>> this is the same controller as found on the Marvell orion5x and kirkwood
>> SoC families, with a slightly different register layout, so this patch uses
>> the existing mvtwsi code.
>>
>> Signed-off-by: Hans de Goede
>> Acked-by: Ian Campbell
>> ---
>
> as this is a newer version, your commit subject should contain a "v2",
> and please add here a short info, what has changed ... look here for
> an explanation how this should look like:
> http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
Ok, will do.
>
>> arch/arm/cpu/armv7/sunxi/board.c| 6 ++
>> arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 5 +
>> arch/arm/include/asm/arch-sunxi/i2c.h | 15 +++
>> board/sunxi/board.c | 7 +++
>> drivers/i2c/mvtwsi.c| 18 ++
>> include/configs/sunxi-common.h | 8
>> 6 files changed, 59 insertions(+)
>> create mode 100644 arch/arm/include/asm/arch-sunxi/i2c.h
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
>> b/arch/arm/cpu/armv7/sunxi/board.c
>> index 1e506b5..024c8c1 100644
>> --- a/arch/arm/cpu/armv7/sunxi/board.c
>> +++ b/arch/arm/cpu/armv7/sunxi/board.c
>> @@ -11,6 +11,7 @@
>>*/
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -91,11 +92,16 @@ void s_init(void)
>> clock_init();
>> timer_init();
>> gpio_init();
>> +i2c_init_board();
>>
>> #ifdef CONFIG_SPL_BUILD
>> gd =&gdata;
>> preloader_console_init();
>>
>> +#ifdef CONFIG_SPL_I2C_SUPPORT
>> +/* Needed early by sunxi_board_init if PMU is enabled */
>> +i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
>> +#endif
>> sunxi_board_init();
>> #endif
>> }
>> diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
>> b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
>> index c1ae227..53f0cbd 100644
>> --- a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
>> +++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
>> @@ -39,6 +39,11 @@ SECTIONS
>> .data : { *(SORT_BY_ALIGNMENT(.data*)) }>.sram
>>
>> . = ALIGN(4);
>> +.u_boot_list : {
>> +KEEP(*(SORT(.u_boot_list*)));
>> +}> .sram
>> +
>> +. = ALIGN(4);
>> __image_copy_end = .;
>> _end = .;
>>
>
> Do you really need this change?
Yes, the sunxi spl uses the i2c bus to program the pmic
voltages before enabling dram.
>
> [...]
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index b05d0b9..543b809 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -106,6 +106,13 @@ int board_mmc_init(bd_t *bis)
>> }
>> #endif
>>
>> +void i2c_init_board(void)
>> +{
>> +sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUNXI_GPB0_TWI0);
>> +sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUNXI_GPB0_TWI0);
>> +clock_twi_onoff(0, 1);
>> +}
>> +
>> #ifdef CONFIG_SPL_BUILD
>> void sunxi_board_init(void)
>> {
>
> I accept this here, but i2c_init_board() hysterically intention was
> to deblock the bus ... I think we need here another approach ...
> board specific initialization should be called from i2c_driver->init() when
> the bus is really used ... (and if not used longer a i2c_driver->deinit()
> should be called, so for example the pins could be used as gpio ... but
> this is a step, I would introduce, if all i2c drivers use the new
> framework ... or we have switched complete to the DM approach)
>
>> diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
>> index d3457b9..ad1ce8f 100644
>> --- a/drivers/i2c/mvtwsi.c
>> +++ b/drivers/i2c/mvtwsi.c
>> @@ -22,6 +22,8 @@
>> #include
>> #elif defined(CONFIG_KIRKWOOD)
>> #include
>> +#elif defined(CONFIG_SUNXI)
>> +#include
>> #else
>> #error Driver mvtwsi not supported by SoC or board
>> #endif
>> @@ -30,6 +32,20 @@
>>* TWSI register structure
>>*/
>>
>> +#ifdef CONFIG_SUNXI
>> +
>> +struct mvtwsi_registers {
>> +u32 slave_address;
>> +u32 xtnd_slave_addr;
>> +u32 data;
>> +u32 control;
>> +u32 status;
>> +u32 baudrate;
>> +u32 soft_reset;
>> +};
>> +
>> +#else
>> +
>> struct mvtwsi_registers {
>> u32 slave_address;
>> u32 data;
>> @@ -43,6 +59,8 @@ struct mvtwsi_registers {
>> u32 soft_reset;
>> };
>>
>> +#endif
>> +
>> /*
>>* Control register fields
>>*/
>
> ? Thats all? I thought you convert this driver to the new i2c framework?
I did a separate patch for that:
"[PATCH 1/5] mvtwsi: convert to CONFIG_SYS_I2C framework"
http://lists.denx.de/pipermail/u-boot/2014-June/181352.html
Which was also send directly to you.
> At least, there should be a change from the i2c_xx() functions to static
> and a prefix add to them ... and a "U_BOOT_I2C_ADAP_COMPLETE" at the end ...
Yes this is all done in the "[PATCH 1/5] mvtwsi: convert to CONFIG_SYS_I2C
Re: [U-Boot] [PATCH] sun5i: Add A13-OLinuXinoM support
Hi, On 06/10/2014 09:25 AM, Albert ARIBAUD wrote: > Hi Hans, > > On Mon, 09 Jun 2014 09:56:01 +0200, Hans de Goede > wrote: > >> Hi, >> >> On 06/09/2014 08:50 AM, Albert ARIBAUD wrote: >>> Hi Tom, >>> >>> On Thu, 20 Mar 2014 08:49:37 -0400, Tom Rini wrote: >>> Tested-by: Matt Porter Signed-off-by: Tom Rini --- >>> >>> Where does this patch come from? The source tree it applies to is not >>> that of mainline U-Boot. If this is actually an RFC that I should look >>> into, (as the PW state says), then which repository does it apply to? >> >> This was posted by Tom as an add on patch to my: >> "[PATCH u-boot sunxi 00/12] sun4i (v2) + sun5i + pmic + emac support" >> >> Series, which was a series on top of one of Ian's sun7i support >> series: >> >> http://lists.denx.de/pipermail/u-boot/2014-March/175656.html >> >> In the mean time (as you know) Ians' series has gone upstream and >> I've continued working on the series in question, with Ian >> reviewing it. Actually I've just send you a pull-req with the >> bits of this series which are ready to go upstream. Which includes >> support for the A13-OLinuXinoM as part of the >> "sunxi: Add sun5i support" patch. > > Thanks. Unfortunately, I had lost track of the dependencies -- which is > a live example of why patches with dependencies should mention them > explicitly after their commit message (not in it, though, as once > applied, the dependency info is not relevant any more), so that folks > like me can reconstruct the information. :) > > I'll process you patch series -- not "pull request", as I only pull > from other (ARM-related only) U-Boot repos :) -- in a few days, then > I'll handle Tom's patch. Adding support for the A13-OLinuXinoM has been integrated into my series, so you can drop Tom's patch. Note I've a lot more allwinner boards (all olimex variants, various mele devices, various mk802 and mk805 variants), which I plan to add support for (these are already support in the u-boot-sunxi git repository), but I'm trying to upstream things in small batches. Let me know if you want me to speed things up and queue up more patches. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] sunxi: Add i2c support
Hello Hans,
Am 10.06.2014 09:44, schrieb Hans de Goede:
Hi,
On 06/10/2014 08:33 AM, Heiko Schocher wrote:
Hello Hans,
Am 09.06.2014 17:15, schrieb Hans de Goede:
Add support for the i2c controller found on all Allwinner sunxi SoCs,
this is the same controller as found on the Marvell orion5x and kirkwood
SoC families, with a slightly different register layout, so this patch uses
the existing mvtwsi code.
Signed-off-by: Hans de Goede
Acked-by: Ian Campbell
---
as this is a newer version, your commit subject should contain a "v2",
and please add here a short info, what has changed ... look here for
an explanation how this should look like:
http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions
Ok, will do.
arch/arm/cpu/armv7/sunxi/board.c| 6 ++
arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 5 +
arch/arm/include/asm/arch-sunxi/i2c.h | 15 +++
board/sunxi/board.c | 7 +++
drivers/i2c/mvtwsi.c| 18 ++
include/configs/sunxi-common.h | 8
6 files changed, 59 insertions(+)
create mode 100644 arch/arm/include/asm/arch-sunxi/i2c.h
[...]
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index d3457b9..ad1ce8f 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -22,6 +22,8 @@
#include
#elif defined(CONFIG_KIRKWOOD)
#include
+#elif defined(CONFIG_SUNXI)
+#include
#else
#error Driver mvtwsi not supported by SoC or board
#endif
@@ -30,6 +32,20 @@
* TWSI register structure
*/
+#ifdef CONFIG_SUNXI
+
+struct mvtwsi_registers {
+u32 slave_address;
+u32 xtnd_slave_addr;
+u32 data;
+u32 control;
+u32 status;
+u32 baudrate;
+u32 soft_reset;
+};
+
+#else
+
struct mvtwsi_registers {
u32 slave_address;
u32 data;
@@ -43,6 +59,8 @@ struct mvtwsi_registers {
u32 soft_reset;
};
+#endif
+
/*
* Control register fields
*/
? Thats all? I thought you convert this driver to the new i2c framework?
I did a separate patch for that:
"[PATCH 1/5] mvtwsi: convert to CONFIG_SYS_I2C framework"
http://lists.denx.de/pipermail/u-boot/2014-June/181352.html
Which was also send directly to you.
At least, there should be a change from the i2c_xx() functions to static
and a prefix add to them ... and a "U_BOOT_I2C_ADAP_COMPLETE" at the end ...
Yes this is all done in the "[PATCH 1/5] mvtwsi: convert to CONFIG_SYS_I2C
framework"
patch.
Hups... Sorry ... I didn;t find it in my inbox ... so, this patch
seems fine to me:
Acked-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Dear Albert Aribaud,
Please pull u-boot-sh/rmobile into u-boot-arm/master.
The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f:
arm: fix a double-definition error of _start symbol (2014-06-09
10:36:40 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-sh.git rmobile
for you to fetch changes up to a59cdc44a9df0887fbb0d7dd5e6229ac0018785b:
arm: rmobile: lager: Remove NOR-Flash support from boards.cfg
(2014-06-10 16:49:31 +0900)
Nobuhiro Iwamatsu (2):
arm: rmobile: koelsch: Remove NOR-Flash support from boards.cfg
arm: rmobile: lager: Remove NOR-Flash support from boards.cfg
boards.cfg | 2 --
1 file changed, 2 deletions(-)
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/5] mvtwsi: convert to CONFIG_SYS_I2C framework
Hello Hans,
Am 09.06.2014 17:15, schrieb Hans de Goede:
Note this has only been tested on Allwinner sunxi devices (support for which
gets introduced by a later patch).
The kirkwood changes have been compile tested using the wireless_space board
config, the orion5x changes have been compile tested using the edminiv2 board
config.
Signed-off-by: Hans de Goede
---
arch/arm/include/asm/arch-kirkwood/config.h | 3 +-
drivers/i2c/Makefile| 2 +-
drivers/i2c/mvtwsi.c| 69 +
include/configs/edminiv2.h | 3 +-
4 files changed, 36 insertions(+), 41 deletions(-)
just a nitpick ...
[...]
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 5ba0e03..d3457b9 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -220,11 +220,10 @@ static int twsi_stop(int status)
/*
* Reset controller.
- * Called at end of i2c_init unsuccessful i2c transactions.
* Controller reset also resets the baud rate and slave address, so
- * re-establish them.
+ * they must be re-established afterwards.
*/
-static void twsi_reset(u8 baud_rate, u8 slave_address)
+static void twsi_reset(struct i2c_adapter *adap)
{
/* ensure controller will be enabled by any twsi*() function */
twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
@@ -232,23 +231,17 @@ static void twsi_reset(u8 baud_rate, u8 slave_address)
writel(0,&twsi->soft_reset);
/* wait 2 ms -- this is what the Marvell LSP does */
udelay(2);
- /* set baud rate */
- writel(baud_rate,&twsi->baudrate);
- /* set slave address even though we don't use it */
- writel(slave_address,&twsi->slave_address);
- writel(0,&twsi->xtnd_slave_addr);
- /* assert STOP but don't care for the result */
- (void) twsi_stop(0);
}
/*
* I2C init called by cmd_i2c when doing 'i2c reset'.
* Sets baud to the highest possible value not exceeding requested one.
*/
-void i2c_init(int requested_speed, int slaveadd)
+static unsigned int twsi_i2c_set_bus_speed(struct i2c_adapter *adap,
+ unsigned int requested_speed)
{
- int tmp_speed, highest_speed, n, m;
- int baud = 0x44; /* baudrate at controller reset */
+ unsigned int tmp_speed, highest_speed, n, m;
+ unsigned int baud = 0x44; /* baudrate at controller reset */
/* use actual speed to collect progressively higher values */
highest_speed = 0;
@@ -263,8 +256,21 @@ void i2c_init(int requested_speed, int slaveadd)
}
}
}
+ writel(baud,&twsi->baudrate);
+ return 0;
+}
+
+static void twsi_i2c_init(struct i2c_adapter *adap, int speed, int slaveadd)
+{
/* reset controller */
- twsi_reset(baud, slaveadd);
+ twsi_reset(adap);
+ /* set speed */
+ twsi_i2c_set_bus_speed(adap, speed);
+ /* set slave address even though we don't use it */
+ writel(slaveadd,&twsi->slave_address);
+ writel(0,&twsi->xtnd_slave_addr);
+ /* assert STOP but don't care for the result */
+ (void) twsi_stop(0);
}
/*
@@ -294,7 +300,7 @@ static int i2c_begin(int expected_start_status, u8 addr)
* I2C probe called by cmd_i2c when doing 'i2c probe'.
* Begin read, nak data byte, end.
*/
-int i2c_probe(uchar chip)
+static int twsi_i2c_probe(struct i2c_adapter *adap, uchar chip)
{
u8 dummy_byte;
int status;
@@ -320,12 +326,13 @@ int i2c_probe(uchar chip)
* cmd_eeprom, so we have to choose here, and for the moment that'll be
* a repeated start without a preceding stop.
*/
-int i2c_read(u8 dev, uint addr, int alen, u8 *data, int length)
+static int twsi_i2c_read(struct i2c_adapter *adap, uchar chip, uint addr,
+ int alen, uchar *data, int length)
{
int status;
/* begin i2c write to send the address bytes */
- status = i2c_begin(MVTWSI_STATUS_START, (dev<< 1));
+ status = i2c_begin(MVTWSI_STATUS_START, (chip<< 1));
/* send addr bytes */
while ((status == 0)&& alen--)
status = twsi_send(addr>> (8*alen),
@@ -333,7 +340,7 @@ int i2c_read(u8 dev, uint addr, int alen, u8 *data, int
length)
/* begin i2c read to receive eeprom data bytes */
if (status == 0)
status = i2c_begin(
- MVTWSI_STATUS_REPEATED_START, (dev<< 1) | 1);
+ MVTWSI_STATUS_REPEATED_START, (chip<< 1) | 1);
/* prepare ACK if at least one byte must be received */
if (length> 0)
twsi_control_flags |= MVTWSI_CONTROL_ACK;
@@ -355,12 +362,13 @@ int i2c_read(u8 dev, uint addr, int alen, u8 *data, int
length)
* I2C write called by cmd_i2c when doing 'i2c write' and by cmd_eeprom.c
* Begin write, send address byte(s), send data bytes, end.
*/
-int i2c_write(u8 dev, uint addr, int alen, u8
[U-Boot] Pull request: u-boot-sh/master
Dear Tom Rini.
Please pull u-boot-sh master branch.
This PR is included part of net stuff.
The following changes since commit 55e8250bd3cfd996d1caa04f520160a89ec04754:
Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-06-08
07:58:41 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-sh.git master
for you to fetch changes up to 1dbd7280dc73dd4a6b38f3d17426393951d7d53e:
net: sh-eth: Fix typo from rESR_RTLF to EESR_RTLF (2014-06-10 17:05:03 +0900)
Nobuhiro Iwamatsu (3):
net: sh-eth: Add support R7S72100 of rmobile
net: sh-eth: Fix coding style
net: sh-eth: Fix typo from rESR_RTLF to EESR_RTLF
drivers/net/sh_eth.c | 45 -
drivers/net/sh_eth.h | 92
2 files changed, 100 insertions(+), 37 deletions(-)
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/3] mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected
Hi Fabio, On 10/06/2014 05:03, Fabio Estevam wrote: > From: Fabio Estevam > > When building a target with CONFIG_ENV_IS_IN_SPI_FLASH the following > warning is seen: > > include/configs/mx28evk.h:73:0: warning: "CONFIG_ENV_SIZE" redefined [enabled > by default] > > Protect the definition of CONFIG_ENV_SIZE to avoid the warning. > > Signed-off-by: Fabio Estevam > --- Put in my queue to be merged. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: correct HAB status for new chip TO
According to:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/log/?h=imx_v2009.08_3.0.35_4.1.0
ENGR00287268 mx6: fix the secure boot issue on the new tapout chip
commit 424cb1a79e9f5ae4ede9350dfb5e10dc9680e90b
newer i.MX6 silicon revisions have an updated ROM and HAB API table.
Please see also:
i.MX Applications Processors Documentation
Engineering Bulletins
EB803, i.MX 6Dual/6Quad Applications Processor Silicon Revsion 1.2 to 1.3
Comparison
With this change the secure boot status is correctly displayed
Signed-off-by: Stefano Babic
---
arch/arm/cpu/armv7/mx6/hab.c | 73 ---
arch/arm/include/asm/arch-mx6/hab.h | 17 ---
arch/arm/include/asm/arch-mx6/imx-regs.h | 2 +
arch/arm/include/asm/arch-mx6/sys_proto.h | 4 +-
4 files changed, 82 insertions(+), 14 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/hab.c b/arch/arm/cpu/armv7/mx6/hab.c
index 5187775..f6810a6 100644
--- a/arch/arm/cpu/armv7/mx6/hab.c
+++ b/arch/arm/cpu/armv7/mx6/hab.c
@@ -7,15 +7,69 @@
#include
#include
#include
+#include
/* start of HAB API updates */
-#define hab_rvt_report_event ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT)
-#define hab_rvt_report_status ((hab_rvt_report_status_t
*)HAB_RVT_REPORT_STATUS)
-#define hab_rvt_authenticate_image \
- ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE)
-#define hab_rvt_entry ((hab_rvt_entry_t *)HAB_RVT_ENTRY)
-#define hab_rvt_exit ((hab_rvt_exit_t *)HAB_RVT_EXIT)
-#define hab_rvt_clock_init HAB_RVT_CLOCK_INIT
+
+#define hab_rvt_report_event_p \
+( \
+ ((is_cpu_type(MXC_CPU_MX6Q) || \
+ is_cpu_type(MXC_CPU_MX6D)) && \
+ (soc_rev() >= CHIP_REV_1_5)) ?\
+ ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) : \
+ (is_cpu_type(MXC_CPU_MX6DL) && \
+(soc_rev() >= CHIP_REV_1_2)) ? \
+ ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT_NEW) : \
+ ((hab_rvt_report_event_t *)HAB_RVT_REPORT_EVENT)\
+)
+
+#define hab_rvt_report_status_p\
+( \
+ ((is_cpu_type(MXC_CPU_MX6Q) || \
+ is_cpu_type(MXC_CPU_MX6D)) && \
+ (soc_rev() >= CHIP_REV_1_5)) ?\
+ ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS_NEW) :\
+ (is_cpu_type(MXC_CPU_MX6DL) && \
+(soc_rev() >= CHIP_REV_1_2)) ? \
+ ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS_NEW) :\
+ ((hab_rvt_report_status_t *)HAB_RVT_REPORT_STATUS) \
+)
+
+#define hab_rvt_authenticate_image_p \
+( \
+ ((is_cpu_type(MXC_CPU_MX6Q) || \
+ is_cpu_type(MXC_CPU_MX6D)) && \
+ (soc_rev() >= CHIP_REV_1_5)) ?\
+ ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE_NEW) : \
+ (is_cpu_type(MXC_CPU_MX6DL) && \
+(soc_rev() >= CHIP_REV_1_2)) ? \
+ ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE_NEW) : \
+ ((hab_rvt_authenticate_image_t *)HAB_RVT_AUTHENTICATE_IMAGE)\
+)
+
+#define hab_rvt_entry_p\
+( \
+ ((is_cpu_type(MXC_CPU_MX6Q) || \
+ is_cpu_type(MXC_CPU_MX6D)) && \
+ (soc_rev() >= CHIP_REV_1_5)) ?\
+ ((hab_rvt_entry_t *)HAB_RVT_ENTRY_NEW) :\
+ (is_cpu_type(MXC_CPU_MX6DL) && \
+(soc_rev() >= CHIP_REV_1_2)) ? \
+ ((hab_rvt_entry_t *)HAB_RVT_ENTRY_NEW) :\
+ ((hab_rvt_entry_t *)HAB_RVT_ENTRY) \
+)
+
+#define hab_rvt_exit_p \
+( \
+ ((is_cpu_type(MXC_CPU_MX6Q) || \
+ is_cpu_type(MXC_CPU_MX6D)) && \
+ (soc_rev() >= CHIP_REV_1_5)) ?\
+ ((hab_rvt_exit_t *)HAB_RVT_EXIT_NEW) : \
+ (is_cpu_type(MXC_CPU_MX6DL) && \
+(soc_rev() >= CHIP_REV_1_2)) ? \
+ ((hab_rvt_exit_t *)HAB_RVT_EXIT_NEW) : \
+ ((hab_rvt_exit_t *)HAB_RVT_EXIT)\
+)
bool is_hab_enabled(void)
{
@@ -52,6 +106,11 @@ int get_h
Re: [U-Boot] [PATCH] sun5i: Add A13-OLinuXinoM support
Hi Hans, On Tue, 10 Jun 2014 09:48:48 +0200, Hans de Goede wrote: > Hi, > > On 06/10/2014 09:25 AM, Albert ARIBAUD wrote: > > Hi Hans, > > > > On Mon, 09 Jun 2014 09:56:01 +0200, Hans de Goede > > wrote: > > > >> Hi, > >> > >> On 06/09/2014 08:50 AM, Albert ARIBAUD wrote: > >>> Hi Tom, > >>> > >>> On Thu, 20 Mar 2014 08:49:37 -0400, Tom Rini wrote: > >>> > Tested-by: Matt Porter > Signed-off-by: Tom Rini > --- > >>> > >>> Where does this patch come from? The source tree it applies to is not > >>> that of mainline U-Boot. If this is actually an RFC that I should look > >>> into, (as the PW state says), then which repository does it apply to? > >> > >> This was posted by Tom as an add on patch to my: > >> "[PATCH u-boot sunxi 00/12] sun4i (v2) + sun5i + pmic + emac support" > >> > >> Series, which was a series on top of one of Ian's sun7i support > >> series: > >> > >> http://lists.denx.de/pipermail/u-boot/2014-March/175656.html > >> > >> In the mean time (as you know) Ians' series has gone upstream and > >> I've continued working on the series in question, with Ian > >> reviewing it. Actually I've just send you a pull-req with the > >> bits of this series which are ready to go upstream. Which includes > >> support for the A13-OLinuXinoM as part of the > >> "sunxi: Add sun5i support" patch. > > > > Thanks. Unfortunately, I had lost track of the dependencies -- which is > > a live example of why patches with dependencies should mention them > > explicitly after their commit message (not in it, though, as once > > applied, the dependency info is not relevant any more), so that folks > > like me can reconstruct the information. :) > > > > I'll process you patch series -- not "pull request", as I only pull > > from other (ARM-related only) U-Boot repos :) -- in a few days, then > > I'll handle Tom's patch. > > Adding support for the A13-OLinuXinoM has been integrated into my series, > so you can drop Tom's patch. Ok. > Note I've a lot more allwinner boards (all olimex variants, various > mele devices, various mk802 and mk805 variants), which I plan to add > support for (these are already support in the u-boot-sunxi git repository), > but I'm trying to upstream things in small batches. Let me know if you > want me to speed things up and queue up more patches. No need to speed things up right now as any new patch series posted at this time would only be considered for next merge window. Right now, I'd only take a new patch for 2014.07 if it was a bug fix, or maybe a really trivial *and* really useful addition. > Regards, > > Hans Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot
Hi Marc, On Sat, 26 Apr 2014 13:17:01 +0100, Marc Zyngier wrote: > PSCI is an ARM standard that provides a generic interface that > supervisory software can use to manage power in the following > situations: > - Core idle management > - CPU hotplug > - big.LITTLE migration models > - System shutdown and reset > > It basically allows the kernel to offload these tasks to the firmware, > and rely on common kernel side code that just calls into PSCI. > > More importantly, it gives a way to ensure that CPUs enter the kernel > at the appropriate exception level (ie HYP mode, to allow the use of > the virtualization extensions), even across events like CPUs being > powered off/on or suspended. > > The main idea here is to turn some of the existing U-Boot code into a > separate section that can live in secure RAM (or a reserved page of > memory), containing a secure monitor that will implement the PSCI > operations. This code will still be alive when U-Boot is long gone, > hence the need for a piece of memory that will not be touched by the > OS. > > This patch series contains 3 parts: > - the first four patches are just bug fixes > - the next two refactor the HYP/non-secure code to allow relocation > in secure memory > - the last four contain the generic PSCI code and DT infrastructure > > This implements the original 0.1 spec, as nobody implements the new > 0.2 version so far. I plan to update this support to 0.2 once there is > an official binding available (and support in the kernel). > > Most of the development has been done on an Allwinner A20 SoC, which > is the main user of this code at the moment. I hope new SoCs will be > using this method in the future (my primary goal for this series being > to avoid more stupid SMP code from creeping up in the Linux > kernel). As instructed, I've removed the A20 support code and made it > a separate series, as there is now an effort to mainline this code > (see Ian Campbell patch series). > > With these three series applied, the A20 now boots in HYP mode, Linux > finds the secondary CPU without any SMP code present in the kernel, > and runs KVM out of the box. The Xen/ARM guys managed to do the same > fairly easily, as did at least one XVizor user. > > This code has also been tested on a VExpress TC2, running KVM with all > 5 CPUs, in order to make sure there was no obvious regression. > > The code is also available at: > git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci-v4 > > A fully merged branch with the A20 support is in the wip/psci-v4-a20 > branch of the same repo. > > Cheers, > > M. > > >From v3: > - Return ARM_PSCI_RET_INVAL instead of ARM_PSCI_RET_NI when PSCI is > entered with an invalid function code. > - Fix !NONSEC compilation > - Rebased on top of adcdeac > > >From v2: > - Dropped the secure stack allocation from the generic PSCI code. There > was too little space there for it to be really useful, and the arch code > knows a lot better about its requirements anyway. It is now the > responsibility of the arch code to provide a stack. This allows it to > get rid of the silly game with the thread registers that was confusing > everyone... > - Added provision for FIQ handling in secure mode. Allwinner A20 is > going to require this for CPU_OFF. > - Better integration of the FDT injection code with the rest of the > code, fixing the truncated FDT issue that people have been reporting > (courtesy of Ma Haijun). > - Cleanup of the AW-specific code (stack allocation, timer macro). > - Rebased on mainline U-Boot (on top of 22a240c32c13). > > >From v1: > - Complete rewrite, now directly relocating the secure code withing > U-Boot, instead of having a separate psci blob. > > Ma Haijun (1): > ARM: convert arch_fixup_memory_node to a generic FDT fixup function > > Marc Zyngier (9): > ARM: HYP/non-sec: move switch to non-sec to the last boot phase > ARM: HYP/non-sec: add a barrier after setting SCR.NS==1 > ARM: non-sec: reset CNTVOFF to zero > ARM: add missing HYP mode constant > ARM: HYP/non-sec: add separate section for secure code > ARM: HYP/non-sec: allow relocation to secure RAM > ARM: HYP/non-sec: add generic ARMv7 PSCI code > ARM: HYP/non-sec: add the option for a second-stage monitor > ARM: HYP/non-sec/PSCI: emit DT nodes > > arch/arm/config.mk | 2 +- > arch/arm/cpu/armv7/Makefile | 5 + > arch/arm/cpu/armv7/nonsec_virt.S| 168 > +--- > arch/arm/cpu/armv7/psci.S | 102 +++ > arch/arm/cpu/armv7/virt-dt.c| 100 +++ > arch/arm/cpu/armv7/virt-v7.c| 59 --- > arch/arm/cpu/u-boot.lds | 30 ++ > arch/arm/include/asm/armv7.h| 11 ++- > arch/arm/include/asm/proc-armv/ptrace.h | 2 + > arch/arm/include/asm/psci.h | 35 +++ > arch/arm/include/asm/secure.h | 26 + > arch/arm
Re: [U-Boot] [RFC 06/10] cc-option: make it work with clang
Hi Jeroen, On Sat, 31 May 2014 22:32:20 +0200 Jeroen Hofstee wrote: > By default clang will return echo a warning if an option is unknown. > Therefore turn warnings into errors when polling for options. As far as I tested with clang 3.5 on Ubuntu 14.04, it looks different. $ clang -fno-delete-null-pointer-checks helloworld.c clang: error: unknown argument: '-fno-delete-null-pointer-checks' $ echo $? 1 Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/rmobile into u-boot-arm/master
Hi Nobuhiro, On Tue, 10 Jun 2014 16:58:39 +0900, Nobuhiro Iwamatsu wrote: > Dear Albert Aribaud, > > Please pull u-boot-sh/rmobile into u-boot-arm/master. > > The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f: > > arm: fix a double-definition error of _start symbol (2014-06-09 > 10:36:40 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh.git rmobile > > for you to fetch changes up to a59cdc44a9df0887fbb0d7dd5e6229ac0018785b: > > arm: rmobile: lager: Remove NOR-Flash support from boards.cfg > (2014-06-10 16:49:31 +0900) > > > Nobuhiro Iwamatsu (2): > arm: rmobile: koelsch: Remove NOR-Flash support from boards.cfg > arm: rmobile: lager: Remove NOR-Flash support from boards.cfg > > boards.cfg | 2 -- > 1 file changed, 2 deletions(-) Isn't the lager commit message slightly wrong, mentioning koelsch instead of lager at one point? Not that it matters much since we are finishing removing support here. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 06/10] cc-option: make it work with clang
Hi Masahiro, On Tue, 10 Jun 2014 17:39:03 +0900, Masahiro Yamada wrote: > Hi Jeroen, > > > On Sat, 31 May 2014 22:32:20 +0200 > Jeroen Hofstee wrote: > > > By default clang will return echo a warning if an option is unknown. > > Therefore turn warnings into errors when polling for options. > > As far as I tested with clang 3.5 on Ubuntu 14.04, > it looks different. > > $ clang -fno-delete-null-pointer-checks helloworld.c > clang: error: unknown argument: '-fno-delete-null-pointer-checks' > $ echo $? > 1 Possibly it depends on how the clang/LLVM toolchain in use has been built and configured. In any case, explicitly turning warnings into errors fixes those toolchains which only emit warnings for unknown options, and it won't harm those such as the one above which already do "the right thing". > Best Regards > Masahiro Yamada Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot - *not* applied
On Tue, 10 Jun 2014 10:36:49 +0200, Albert ARIBAUD wrote: > Hi Marc, > > Applied to u-boot-arm/master, thanks! Apologies -- *not* applied until 08/10 warning is fixed. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/10] ARMv7: add PSCI support to U-Boot - *not* applied
On Tue, 10 Jun 2014 11:06:38 +0200, Albert ARIBAUD wrote: > On Tue, 10 Jun 2014 10:36:49 +0200, Albert ARIBAUD > wrote: > > > Hi Marc, > > > > Applied to u-boot-arm/master, thanks! > > Apologies -- *not* applied until 08/10 warning is fixed. I meant 06/10, not 08/10. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup
Hi, Apologies for the delay in replying. On Fri, Jun 06, 2014 at 11:14:23PM +0100, York Sun wrote: > On 06/06/2014 01:17 PM, York Sun wrote: > > On 06/06/2014 10:32 AM, Mark Rutland wrote: > How is TCR_EL2.SH0 (or TCR_EL1.SH*) configured? > > You'll only need to flush the cache if they're configured non shareable. > >>> > >>> It is configured as non shareable. > >> > >> Is there any reason not to configure them as inner shareable? That way > >> the MMU will look in the D-cache, and you won't have to spend time > >> flushing them. > >> > > > > Mark, > > > > I appreciate the reminder. I tried on our emulator. With inner share set > > for TCR > > SH0 bits, u-boot works with the flushing, but doesn't work without > > flushing. It > > went to exception. > > > > Can you share more information about the inner share? I need to follow up > > with > > our designer to confirm. > > > > A second thought, do I need to set the first MMU table so DDR is inner > shareable? I assume you mean configuring MAIR_ELx such that the mapping covering DDR is cacheable for the inner shareable domain? If so, yes. Cheers, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pick up the maintainership on orphan boards
On 29 May 2014 12:06, Tushar Behera wrote: > On 29 May 2014 11:30, Minkyu Kang wrote: >> Dear Tushar Behera, >> >> On 29/05/14 12:43, Masahiro Yamada wrote: >>> Minkyu, >>> Inderpal Singh is invalid. >>> Could you assign another enginner resposible for "arndale" board? >>> >> >> It seems to Inderpal Singh is no longer with Linaro. >> Could you please assign some people to maintain "arndale" board? >> Henceforth, Chander would be the maintainer for Arndale board. Chander Kashyap Do you want me to send a patch regarding this? >> Thanks, >> Minkyu Kang. > > Dear Minkyu, > > I will update you about the new engineer after I discuss about this > internally. > > Regards, > -- > Tushar Behera -- Tushar Behera ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Arndale: Enable preboot support
We need to run 'usb start' as preboot command so that ethernet comes up during u-boot prompt. Signed-off-by: Tushar Behera --- include/configs/arndale.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 30ecd45..370db82 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -229,6 +229,8 @@ #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-arndale +#define CONFIG_PREBOOT + /* Ethernet Controllor Driver */ #ifdef CONFIG_CMD_NET #define CONFIG_SMC911X -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu: Disable default calculation of CRC32
Patch (SHA1: bd694244db7bc969954)
dfu: Introduction of the "dfu_hash_algo" env variable for checksum method
setting
already introduced more generic handling of the crc32 calculation.
Up till now the CRC32 of received data was calculated unconditionally.
This patch changes this and from now - by default the crc32 is NOT
calculated anymore.
Signed-off-by: Lukasz Majewski
Cc: Marek Vasut
---
drivers/dfu/dfu.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 5878f99..dc09ff6 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -106,21 +106,15 @@ static char *dfu_get_hash_algo(void)
char *s;
s = getenv("dfu_hash_algo");
- /*
-* By default the legacy behaviour to calculate the crc32 hash
-* value is preserved.
-*
-* To disable calculation of the hash algorithm for received data
-* specify the "dfu_hash_algo = disabled" at your board envs.
-*/
- debug("%s: DFU hash method: %s\n", __func__, s ? s : "not specified");
-
- if (!s || !strcmp(s, "crc32"))
- return "crc32";
-
- if (!strcmp(s, "disabled"))
+ if (!s)
return NULL;
+ if (!strcmp(s, "crc32")) {
+ debug("%s: DFU hash method: %s\n", __func__, s);
+ return s;
+ }
+
+ error("DFU hash method: %s not supported!\n", s);
return NULL;
}
--
2.0.0.rc2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] sandbox test script question
Hi, Simon: Is there any doc described how to use 'sb load host / sb ls host' etc cmds? I tried to run: sb info it displayed: 0 Not bound to a backing file .. Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: bcm281xx: Add CONFIG_SYS_GENERIC_BOARD
Hi Steve, On Wed, 14 May 2014 14:18:09 -0700, Steve Rae wrote: > convert to generic board > > Signed-off-by: Steve Rae > --- > > include/configs/bcm28155_ap.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/bcm28155_ap.h b/include/configs/bcm28155_ap.h > index e93b855..bf09939 100644 > --- a/include/configs/bcm28155_ap.h > +++ b/include/configs/bcm28155_ap.h > @@ -14,6 +14,7 @@ > #define CONFIG_ARMV7 > #define CONFIG_KONA > #define CONFIG_SKIP_LOWLEVEL_INIT > +#define CONFIG_SYS_GENERIC_BOARD > > /* > * Memory configuration Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] exynos: pinmux: fix the gpio names for exynos4x12 mmc
This change fixes the bad gpio configuration for the exynos dwmmc. Signed-off-by: Przemyslaw Marczak Cc: Beomho Seo Cc: Minkyu Kang Cc: Jaehoon Chung --- arch/arm/cpu/armv7/exynos/pinmux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c b/arch/arm/cpu/armv7/exynos/pinmux.c index 86a0c75..b929486 100644 --- a/arch/arm/cpu/armv7/exynos/pinmux.c +++ b/arch/arm/cpu/armv7/exynos/pinmux.c @@ -704,8 +704,8 @@ static int exynos4x12_mmc_config(int peripheral, int flags) ext_func = S5P_GPIO_FUNC(0x3); break; case PERIPH_ID_SDMMC4: - start = EXYNOS4_GPIO_K00; - start_ext = EXYNOS4_GPIO_K13; + start = EXYNOS4X12_GPIO_K00; + start_ext = EXYNOS4X12_GPIO_K13; func = S5P_GPIO_FUNC(0x3); ext_func = S5P_GPIO_FUNC(0x4); break; -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] samsung: misc: fix soc revision setting in the set_board_info()
The byte order of soc revision was inverted, now it is fixed.
Signed-off-by: Przemyslaw Marczak
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/common/misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 03106fd..a453a82 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -26,8 +26,8 @@ void set_board_info(void)
{
char info[64];
- snprintf(info, ARRAY_SIZE(info), "%d.%d", s5p_cpu_rev & 0x0f,
-(s5p_cpu_rev & 0xf0) >> 0x04);
+ snprintf(info, ARRAY_SIZE(info), "%u.%u", (s5p_cpu_rev & 0xf0) >> 4,
+s5p_cpu_rev & 0xf);
setenv("soc_rev", info);
snprintf(info, ARRAY_SIZE(info), "%x", s5p_cpu_id);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] samsung: board: checkboard: call get_board_type() for CONFIG_BOARD_TYPES
For support of multiple board types in a one config - it is welcome
to display the current board model. This is what get_board_type()
should return.
Signed-off-by: Przemyslaw Marczak
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/common/board.c | 5 -
include/samsung/misc.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9a745d9..c1f3742 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -283,7 +283,10 @@ int checkboard(void)
board_name = fdt_getprop(gd->fdt_blob, 0, "model", NULL);
printf("Board: %s\n", board_name ? board_name : "unknown");
-
+#ifdef CONFIG_BOARD_TYPES
+ const char *board_type = get_board_type();
+ printf("Model: %s\n", board_type ? board_type : "unknown");
+#endif
return 0;
}
#endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index bad591f..cbd5456 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -37,6 +37,7 @@ void draw_logo(void);
void set_dfu_boot_alt(int bootmode);
#endif
#ifdef CONFIG_BOARD_TYPES
+const char *get_board_type(void);
const char *get_board_type_fdt(void);
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] odroid: add board file for Odroid X2/U3 based on Samsung Exynos4412
This board file supports standard features of Odroid X2 and U3 boards:
- Exynos4412 core clock set to 1000MHz and MPLL peripherial clock set to 800MHz,
- MAX77686 power regulator,
- USB PHY,
- enable XCL205 - power for board peripherials
- check board type: U3 or X2.
Signed-off-by: Przemyslaw Marczak
Cc: Minkyu Kang
Cc: Tom Rini
---
board/samsung/odroid/Makefile | 8 +
board/samsung/odroid/odroid.c | 432 ++
board/samsung/odroid/setup.h | 227 ++
3 files changed, 667 insertions(+)
create mode 100644 board/samsung/odroid/Makefile
create mode 100644 board/samsung/odroid/odroid.c
create mode 100644 board/samsung/odroid/setup.h
diff --git a/board/samsung/odroid/Makefile b/board/samsung/odroid/Makefile
new file mode 100644
index 000..b98aaeb
--- /dev/null
+++ b/board/samsung/odroid/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (c) 2014 Samsung Electronics Co., Ltd. All rights reserved.
+# Przemyslaw Marczak
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y := odroid.o
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
new file mode 100644
index 000..20a41b2
--- /dev/null
+++ b/board/samsung/odroid/odroid.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ * Przemyslaw Marczak
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "setup.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Odroid board types */
+enum {
+ ODROID_TYPE_U3,
+ ODROID_TYPE_X2,
+};
+
+static void set_board_type(void)
+{
+ int val;
+
+ /* Check GPC1 pin 2 */
+ gpio_set_pull(EXYNOS4X12_GPIO_C12, S5P_GPIO_PULL_NONE);
+ gpio_set_drv(EXYNOS4X12_GPIO_C12, S5P_GPIO_DRV_4X);
+ gpio_direction_input(EXYNOS4X12_GPIO_C12);
+
+ /* XCL205 - needs some latch time */
+ mdelay(10);
+
+ /* Check GPC1 pin2 - LED supplied by XCL205 - X2 only */
+ val = gpio_get_value(EXYNOS4X12_GPIO_C12);
+ if (val)
+ gd->board_type = ODROID_TYPE_X2;
+ else
+ gd->board_type = ODROID_TYPE_U3;
+}
+
+const char *get_board_type(void)
+{
+ const char *board_type_str[] = {"U3", "X2"};
+
+ set_board_type();
+
+ return board_type_str[gd->board_type];
+}
+
+const char *get_board_type_fdt(void)
+{
+ const char *board_type_fdt[] = {"u3", "x2"};
+
+ return board_type_fdt[gd->board_type];
+}
+
+static void board_clock_init(void)
+{
+ unsigned int set, clr, clr_src_cpu, clr_pll_con0, clr_src_dmc;
+ struct exynos4x12_clock *clk = (struct exynos4x12_clock *)
+ samsung_get_base_clock();
+
+ /*
+* CMU_CPU clocks src to MPLL
+* Bit values: 0 ; 1
+* MUX_APLL_SEL:FIN_PLL ; FOUT_APLL
+* MUX_CORE_SEL:MOUT_APLL ; SCLK_MPLL
+* MUX_HPM_SEL: MOUT_APLL ; SCLK_MPLL_USER_C
+* MUX_MPLL_USER_SEL_C: FIN_PLL ; SCLK_MPLL
+ */
+ clr_src_cpu = MUX_APLL_SEL(0x1) | MUX_CORE_SEL(0x1) |
+ MUX_HPM_SEL(0x1) | MUX_MPLL_USER_SEL_C(0x1);
+ set = MUX_APLL_SEL(0) | MUX_CORE_SEL(1) | MUX_HPM_SEL(1) |
+ MUX_MPLL_USER_SEL_C(1);
+
+ clrsetbits_le32(&clk->src_cpu, clr_src_cpu, set);
+
+ /* Wait for mux change */
+ while (readl(&clk->mux_stat_cpu) & MUX_STAT_CPU_CHANGING)
+ continue;
+
+ /* Set APLL to 1000MHz */
+ clr_pll_con0 = SDIV(0x7) | PDIV(0x3f) | MDIV(0x3ff) | FSEL(0x1);
+ set = SDIV(0) | PDIV(3) | MDIV(125) | FSEL(1);
+
+ clrsetbits_le32(&clk->apll_con0, clr_pll_con0, set);
+
+ /* Wait for PLL to be locked */
+ while (!(readl(&clk->apll_con0) & PLL_LOCKED_BIT))
+ continue;
+
+ /* Set CMU_CPU clocks src to APLL */
+ set = MUX_APLL_SEL(1) | MUX_CORE_SEL(0) | MUX_HPM_SEL(0) |
+ MUX_MPLL_USER_SEL_C(1);
+ clrsetbits_le32(&clk->src_cpu, clr_src_cpu, set);
+
+ /* Wait for mux change */
+ while (readl(&clk->mux_stat_cpu) & MUX_STAT_CPU_CHANGING)
+ continue;
+
+ set = CORE_RATIO(0) | COREM0_RATIO(2) | COREM1_RATIO(5) |
+ PERIPH_RATIO(0) | ATB_RATIO(4) | PCLK_DBG_RATIO(1) |
+ APLL_RATIO(0) | CORE2_RATIO(0);
+ /*
+* Set dividers for MOUTcore = 1000 MHz
+* coreout = MOUT / (ratio + 1) = 1000 MHz (0)
+* corem0 = armclk / (ratio + 1) = 333 MHz (2)
+* corem1 = armclk / (ratio + 1) = 166 MHz (5)
+* periph = armclk / (ratio + 1) = 1000 MHz (0)
+* atbout = MOUT / (ratio + 1) = 200 MHz (4)
+* pclkdbgout = atbout / (ratio + 1) = 100 MHz (1)
+* sclkapll = MOUTapll / (ratio + 1) = 1000 MHz (0)
+* core2out = core_out / (ratio + 1) = 1000 MHz (0) (armclk)
+ */
+ clr = CORE_RATIO(0x7)
[U-Boot] [PATCH 06/10] samsung: misc: set_board_info: check the board type to set fdt file name
This change adds a call to the get_board_type_fdt() function before setting
the "fdtfile" environment variable.
For CONFIG_BOARD_TYPES below function is called:
- const char *get_board_type_fdt(void) - should return a pointer
to the board type string.
This is useful in case of run many boards with just one config.
Signed-off-by: Przemyslaw Marczak
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/common/misc.c | 8 ++--
include/samsung/misc.h | 3 +++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index d31583b..ace92f8 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -48,6 +48,7 @@ void set_dfu_boot_alt(int bootmode)
void set_board_info(void)
{
char info[64];
+ const char *bdtype = "";
snprintf(info, ARRAY_SIZE(info), "%u.%u", (s5p_cpu_rev & 0xf0) >> 4,
s5p_cpu_rev & 0xf);
@@ -61,8 +62,11 @@ void set_board_info(void)
setenv("board_rev", info);
#endif
#ifdef CONFIG_OF_LIBFDT
- snprintf(info, ARRAY_SIZE(info), "%s%x-%s.dtb",
-CONFIG_SYS_SOC, s5p_cpu_id, CONFIG_SYS_BOARD);
+#ifdef CONFIG_BOARD_TYPES
+ bdtype = get_board_type_fdt();
+#endif
+ snprintf(info, ARRAY_SIZE(info), "%s%x-%s%s.dtb",
+CONFIG_SYS_SOC, s5p_cpu_id, CONFIG_SYS_BOARD, bdtype);
setenv("fdtfile", info);
#endif
}
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index dfc0946..bad591f 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -36,5 +36,8 @@ void draw_logo(void);
#ifdef CONFIG_SET_DFU_BOOT_ALT
void set_dfu_boot_alt(int bootmode);
#endif
+#ifdef CONFIG_BOARD_TYPES
+const char *get_board_type_fdt(void);
+#endif
#endif /* __SAMSUNG_MISC_COMMON_H__ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] arm:reset: call the reset_misc() before the cpu reset
On an Odroid U3 board, the SOC is unable to reset an eMMC card
in the DWMMC mode by the cpu software reset. Manual reset of the card
by switching proper gpio pin - fixes this issue.
Such solution needs to add a call to pre reset function.
This is done by the reset_misc() function, which is called before reset_cpu().
The function reset_misc() is a weak function.
Signed-off-by: Przemyslaw Marczak
Cc: Minkyu Kang
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Albert ARIBAUD
Cc: Tom Rini
---
arch/arm/lib/reset.c | 7 +++
include/common.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 7a03580..3b39466 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -23,6 +23,11 @@
#include
+void __reset_misc(void) {}
+
+void reset_misc(void)
+ __attribute((weak, alias("__reset_misc")));
+
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
puts ("resetting ...\n");
@@ -30,6 +35,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
udelay (5); /* wait 50 ms */
disable_interrupts();
+
+ reset_misc();
reset_cpu(0);
/*NOTREACHED*/
diff --git a/include/common.h b/include/common.h
index 232136c..04bab78 100644
--- a/include/common.h
+++ b/include/common.h
@@ -629,6 +629,7 @@ int checkicache (void);
intcheckdcache (void);
void upmconfig (unsigned int, unsigned int *, unsigned int);
ulong get_tbclk (void);
+void reset_misc(void);
void reset_cpu (ulong addr);
#if defined (CONFIG_OF_LIBFDT) && defined (CONFIG_OF_BOARD_SETUP)
void ft_cpu_setup(void *blob, bd_t *bd);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] odroid: add odroid U3/X2 device tree description
This is a standard description for Odroid boards.
Signed-off-by: Przemyslaw Marczak
Cc: Minkyu Kang
Cc: Tom Rini
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos4412-odroid.dts | 70 ++
2 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/exynos4412-odroid.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5554615..32cb6f5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1,7 +1,8 @@
dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \
exynos4210-universal_c210.dtb \
exynos4210-trats.dtb \
- exynos4412-trats2.dtb
+ exynos4412-trats2.dtb \
+ exynos4412-odroid.dtb
dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
new file mode 100644
index 000..24d0bf1
--- /dev/null
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -0,0 +1,70 @@
+/*
+ * Odroid-U3/X2 board device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ "exynos4.dtsi"
+
+/ {
+ model = "Odroid based on Exynos4412";
+ compatible = "samsung,odroid", "samsung,exynos4412";
+
+ aliases {
+ i2c0 = "/i2c@1386";
+ serial0 = "/serial@1380";
+ console = "/serial@1381";
+ mmc2 = "sdhci@1253";
+ mmc4 = "dwmmc@1255";
+ };
+
+ i2c@1386 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-slave-addr = <0x10>;
+ samsung,i2c-max-bus-freq = <10>;
+ status = "okay";
+
+ max77686_pmic@09 {
+ compatible = "maxim,max77686_pmic";
+ interrupts = <7 0>;
+ reg = <0x09 0 0>;
+ #clock-cells = <1>;
+ };
+ };
+
+ serial@1381 {
+ status = "okay";
+ };
+
+ sdhci@1251 {
+ status = "disabled";
+ };
+
+ sdhci@1252 {
+ status = "disabled";
+ };
+
+ sdhci@1253 {
+ samsung,bus-width = <4>;
+ samsung,timing = <1 2 3>;
+ cd-gpios = <&gpio 0xC2 0>;
+ };
+
+ sdhci@1254 {
+ status = "disabled";
+ };
+
+ dwmmc@1255 {
+ samsung,bus-width = <8>;
+ samsung,timing = <2 1 0>;
+ samsung,removable = <0>;
+ fifoth_val = <0x203f0040>;
+ bus_hz = <4>;
+ div = <0x3>;
+ index = <4>;
+ };
+};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] samsung: misc: set the dfu bootloader setting at boot time.
This change adds new function:
- set_dfu_boot_alt(bootmode) - where bootmode is the value of Exynos ompin[5:1]
masked with BOOT_MODE(x) macro.
This change is useful for devices with more than one boot device,
e.g. with a separated SD and eMMC slots. Different dfu entities are
required for SD and eMMC cards. The board config should define:
- CONFIG_MISC_COMMON
- CONFIG_SET_DFU_BOOT_ALT
and at least one of below alt setting:
- CONFIG_DFU_BOOT_ALT_SD, e.g: "u-boot raw 1 2048"
- CONFIG_DFU_BOOT_ALT_eMMC, e.g: "u-boot raw 0 2048 mmcpart 1"
Signed-off-by: Przemyslaw Marczak
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/common/board.c | 3 +++
board/samsung/common/misc.c | 23 +++
include/samsung/misc.h | 4
3 files changed, 30 insertions(+)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 2970340..9a745d9 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -323,6 +323,9 @@ int arch_early_init_r(void)
#ifdef CONFIG_MISC_INIT_R
int misc_init_r(void)
{
+#ifdef CONFIG_SET_DFU_BOOT_ALT
+ set_dfu_boot_alt(bootmode);
+#endif
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
#endif
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index a453a82..d31583b 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -21,6 +21,29 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_SET_DFU_BOOT_ALT
+void set_dfu_boot_alt(int bootmode)
+{
+ char *alt_bootloader = NULL;
+
+ switch (bootmode) {
+ case BOOT_SDMMC:
+#ifdef CONFIG_DFU_BOOT_ALT_SD
+ alt_bootloader = CONFIG_DFU_BOOT_ALT_SD;
+#endif
+ break;
+ default:
+#ifdef CONFIG_DFU_BOOT_ALT_EMMC
+ alt_bootloader = CONFIG_DFU_BOOT_ALT_EMMC;
+#endif
+ break;
+ }
+
+ if (alt_bootloader)
+ setenv("dfu_alt_bootloader", alt_bootloader);
+}
+#endif
+
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
void set_board_info(void)
{
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 87b53ec..dfc0946 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -33,4 +33,8 @@ void draw_logo(void);
#define BOOT_MODE_SHIFT(0x1)
#define BOOT_MODE(x) ((x >> BOOT_MODE_SHIFT) & BOOT_MODE_MASK)
+#ifdef CONFIG_SET_DFU_BOOT_ALT
+void set_dfu_boot_alt(int bootmode);
+#endif
+
#endif /* __SAMSUNG_MISC_COMMON_H__ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] board:samsung: check the mmc boot device and init the right mmc driver.
It is possible to boot from a few media devices, especially using a micro
SD or eMMC slots. In this situation, boot device should be registered
as block device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
is usually set to "0" in the most config cases.
Signed-off-by: Przemyslaw Marczak
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/common/board.c | 32
include/samsung/misc.h | 5 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..2970340 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -25,6 +25,8 @@
#include
#include
+static int bootmode;
+
DECLARE_GLOBAL_DATA_PTR;
int __exynos_early_init_f(void)
@@ -243,19 +245,33 @@ int board_eth_init(bd_t *bis)
int board_mmc_init(bd_t *bis)
{
int ret;
+ struct exynos4_power *pwr = (struct exynos4_power *)
+ samsung_get_base_power();
+
+ bootmode = BOOT_MODE(readl(&pwr->om_stat));
+ if (bootmode == BOOT_SDMMC) {
+#ifdef CONFIG_SDHCI
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd->fdt_blob);
+#endif
#ifdef CONFIG_DWMMC
- /* dwmmc initializattion for available channels */
- ret = exynos_dwmmc_init(gd->fdt_blob);
- if (ret)
- debug("dwmmc init failed\n");
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd->fdt_blob);
+#endif
+ } else {
+#ifdef CONFIG_DWMMC
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd->fdt_blob);
#endif
-
#ifdef CONFIG_SDHCI
- /* mmc initializattion for available channels */
- ret = exynos_mmc_init(gd->fdt_blob);
+ /* mmc initializattion for available channels */
+ ret = exynos_mmc_init(gd->fdt_blob);
+#endif
+ }
+
if (ret)
debug("mmc init failed\n");
-#endif
+
return ret;
}
#endif
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 10653a1..87b53ec 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -28,4 +28,9 @@ void check_boot_mode(void);
void draw_logo(void);
#endif
+#define BOOT_SDMMC 0x2
+#define BOOT_MODE_MASK (0x1f)
+#define BOOT_MODE_SHIFT(0x1)
+#define BOOT_MODE(x) ((x >> BOOT_MODE_SHIFT) & BOOT_MODE_MASK)
+
#endif /* __SAMSUNG_MISC_COMMON_H__ */
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] odroid: add odroid_config
This config is valid for two devices: - Odroid X2, - Odroid U3. Signed-off-by: Przemyslaw Marczak Cc: Minkyu Kang Cc: Tom Rini --- boards.cfg | 1 + doc/README.odroid| 122 +++ include/configs/odroid.h | 208 +++ 3 files changed, 331 insertions(+) create mode 100644 doc/README.odroid create mode 100644 include/configs/odroid.h diff --git a/boards.cfg b/boards.cfg index 5a85fad..f086998 100644 --- a/boards.cfg +++ b/boards.cfg @@ -296,6 +296,7 @@ Active arm armv7 exynos samsung smdk5420 Active arm armv7 exynos samsung smdkv310 smdkv310 - Chander Kashyap Active arm armv7 exynos samsung trats trats - Lukasz Majewski Active arm armv7 exynos samsung trats2 trats2- Piotr Wilczek +Active arm armv7 exynos samsung odroid odroid- Przemyslaw Marczak Active arm armv7 exynos samsung universal_c210 s5pc210_universal - Przemyslaw Marczak Active arm armv7 highbank- highbank highbank - Rob Herring Active arm armv7 keystoneti k2hk_evm k2hk_evm - Vitaly Andrianov diff --git a/doc/README.odroid b/doc/README.odroid new file mode 100644 index 000..2d74524 --- /dev/null +++ b/doc/README.odroid @@ -0,0 +1,122 @@ + U-boot for Odroid X2/U3 + + +1. Summary +== +This is a quick instruction for setup Odroid boards based on Exynos4412. +Board config: odroid_config + +2. Supported devices + +This U-BOOT config can be used on two boards: +- Odroid U3 +- Odroid X2 +with CPU Exynos 4412 rev 2.0 and 2GB of RAM + +3. Boot sequence + +iROM->BL1->(BL2 + TrustZone)->U-BOOT + +This version of U-BOOT doesn't implement SPL but it is required(BL2) +and can be found in "boot.tar.gz" from here: +http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz + +4. Boot media layout + +The table below shows SD/eMMC cards layout for U-boot. +The block offset is starting from 0 and the block size is 512B. + - +| Binary | Block offset| part type | +| name| SD | eMMC |(eMMC only)| + - +| Bl1 | 1| 0| 1 (boot) | +| Bl2 | 31 | 30 | 1 (boot) | +| U-boot| 63 | 62 | 1 (boot) | +| Tzsw | 2111 | 2110 | 1 (boot) | +| Uboot Env | 2500 | 2500 | 0 (user) | + - + +5. Prepare the SD boot card - with SD card reader += +To prepare bootable media you need boot binaries provided by hardkernel. +File "boot.tar.gz" (link in point 3.) contains: +- E4412_S.bl1.HardKernel.bin +- E4412_S.tzsw.signed.bin +- bl2.signed.bin +- sd_fusing.sh +- u-boot.bin + +This is all you need to boot this board. But if you want to use your custom +u-boot then you need to change u-boot.bin with your own u-boot binary* +and run the script "sd_fusing.sh" - this script is valid only for SD card. + +*note: +The proper binary file of current U-boot is u-boot-dtb.bin. + +quick steps for Linux: +- extract boot.tar.gz +- put any SD card into the SD reader +- check the device with "dmesg" +- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition) +Check if Hardkernel U-boot is booting, and next do the same with your U-boot. + +6. Prepare the eMMC boot card + with a eMMC card reader (boot from eMMC card slot) += +To boot the device from the eMMC slot you should use a special
Re: [U-Boot] U-Boot support for ODROID Board
Hello Hannes, On 06/09/2014 05:11 PM, Przemyslaw Marczak wrote: Hi, On 06/09/2014 05:00 PM, Hannes Petermaier wrote: Hi Przemyslaw, sounds good. Do you have also experience running a current version of Linux Kernel on this board ? best regards, Hannes On 2014-06-09 16:29, Przemyslaw Marczak wrote: Hello Hannes, On 06/09/2014 02:39 PM, Hannes Petermaier wrote: Hello, does anybody know if there is support for the ODROID Board (http://hardkernel.com/main/products/prdt_info.php?g_code=G138745696275&tab_idx=2) with the Samsung exynos 4412 processor ? best regards, hannes I am working on it and I hope to send proper patch set tomorrow, so please follow the list. Supported devices are: Odroid U3/X2 based on Exynos4412 Rev 2.0 / 2GB of DRAM. And maybe in the future Odroid X based on Exynos4412 Rev 1.0 / 1GB of DRAM. Thank you, I have tested it with some internal version of kernel 3.10, but probably it will be available soon at kernel lists. But Hardkernel image should working fine. Thanks you, Please look at my patch set starting from this commit: http://patchwork.ozlabs.org/patch/357879/ It's recommended to apply this patch set at all - to have Odroid U3/X2 working. 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 1/2] Makefile: fix clang warnings due to clang support
Hi Jeroen, On Fri, 30 May 2014 15:45:27 +0200 Jeroen Hofstee wrote: > Building u-boot tools with clang as a host compiler e.g. on > FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` > leads to many warnings [1] for every compiler invocation since > commit 598e2d33. Part of mentioned commit imports linux patches: > > - kbuild: LLVMLinux: Adapt warnings for compilation with clang > - kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang > > No version of clang supports the gcc fno-delete-null-pointer-checks > though, but it is only passed to clang. Gcc does not have the clang > specific Qunused-arguments for the target. Furthermore several > warnings are disabled which aren't encountered in u-boot. Since such > a build has worked for quite some time and works after removing these > changes, just remove the clang specific handling to restore normal > building with clang as hostcc. I have to admit I just copied these line from Kernel without testing it, just for syncing with Kernel makefiles. As far as I tested, Clang did not recognize -fno-delete-null-pointer-checks. It is OK with me if you rip Clang stuff off the top Makefile. Sorry, honestly I am not familiar enough with Clang to make deeper review. This might be useful information for you. some discussion why Linux folks added those lines: https://patchwork.kernel.org/patch/3719881/ Do you also need this to use Clang? https://patchwork.kernel.org/patch/3720041/ Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pick up the maintainership on orphan boards
Hi Tushar, On Tue, 10 Jun 2014 14:54:20 +0530 Tushar Behera wrote: > On 29 May 2014 12:06, Tushar Behera wrote: > > On 29 May 2014 11:30, Minkyu Kang wrote: > >> Dear Tushar Behera, > >> > >> On 29/05/14 12:43, Masahiro Yamada wrote: > >>> Minkyu, > >>> Inderpal Singh is invalid. > >>> Could you assign another enginner resposible for "arndale" board? > >>> > >> > >> It seems to Inderpal Singh is no longer with Linaro. > >> Could you please assign some people to maintain "arndale" board? > >> > > Henceforth, Chander would be the maintainer for Arndale board. > > Chander Kashyap > > Do you want me to send a patch regarding this? Yes. Please do so. Thanks! Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] nand/denali: Adding Denali NAND driver support
Hi Chin, On Tue, 10 Jun 2014 00:42:19 -0500 Chin Liang See wrote: > To add the Denali NAND driver support into U-Boot. It required > information such as register base address from configuration > header file within include/configs folder. > > Signed-off-by: Chin Liang See > Cc: Artem Bityutskiy > Cc: David Woodhouse > Cc: Brian Norris > Cc: Scott Wood > Cc: Masahiro Yamada Thanks for posting v8 when you are busy! Signed-off-by: Masahiro Yamada Reviewed-by: Masahiro Yamada Tested-by: Masahiro Yamada Scott, Could you apply this patch please? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] x86: Enable 32-bit build using x86_64 multilib toolchain
Until now building the x86 arch boards required 32-bit toolchain. As many x86_64 toolchains come with 32-bit support (multilib) that's a good idea to enable build with such toolchains. The change required was to specify the usage of 32-bit explicitly to the compiler and the linker (-m32 and -m elf_i386 flags) and locate the right libgcc path. Signed-off-by: Vasili Galka --- For example on x86_64 Ubuntu "sudo apt-get install gcc-multilib" is enough and no need to install additional 32-bit toolchain. arch/x86/config.mk |5 +++-- arch/x86/cpu/config.mk |2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 38cb7c9..3106079 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -16,17 +16,18 @@ PF_CPPFLAGS_X86 := $(call cc-option, -fno-toplevel-reorder, \ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_X86) PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm PLATFORM_CPPFLAGS += -DREALMODE_BASE=0x7c0 +PLATFORM_CPPFLAGS += -march=i386 -m32 # Support generic board on x86 __HAVE_ARCH_GENERIC_BOARD := y PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden -PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions +PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions -m elf_i386 LDFLAGS_FINAL += --gc-sections -pie LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3 -export NORMAL_LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) +export NORMAL_LIBGCC = $(shell $(CC) $(PLATFORM_CPPFLAGS) -print-libgcc-file-name) CONFIG_USE_PRIVATE_LIBGCC := arch/x86/lib diff --git a/arch/x86/cpu/config.mk b/arch/x86/cpu/config.mk index c1568cac..4b2c873 100644 --- a/arch/x86/cpu/config.mk +++ b/arch/x86/cpu/config.mk @@ -7,7 +7,7 @@ CROSS_COMPILE ?= i386-linux- -PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror +PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -Werror # DO NOT MODIFY THE FOLLOWING UNLESS YOU REALLY KNOW WHAT YOU ARE DOING! LDPPFLAGS += -DRESET_SEG_START=0x -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove ${objtree}/include/asm/proc/ link
mkconfig links ${objtree}/include/asm/proc/ to
${srctree}/arch/${arch}/include/asm/proc-armv/. This seems to be a
remnant from the past. Ever since its introduction in 2003 it is used
only in ARM build and always links to same place, so let's simplify
the code, remove it and reference directly where needed.
Successful MAKEALL for ARM and PowerPC verified on Linux.
Signed-off-by: Vasili Galka
---
arch/arm/include/asm/atomic.h |2 +-
arch/arm/include/asm/bitops.h |2 +-
arch/arm/include/asm/proc-armv/processor.h |2 +-
arch/arm/include/asm/processor.h |2 +-
arch/arm/include/asm/ptrace.h |2 +-
mkconfig |5 -
6 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 1b22eeb..34c07fe 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -25,7 +25,7 @@ typedef struct { volatile int counter; } atomic_t;
#define ATOMIC_INIT(i) { (i) }
#ifdef __KERNEL__
-#include
+#include
#define atomic_read(v) ((v)->counter)
#define atomic_set(v,i)(((v)->counter) = (i))
diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
index 879e20e..597dafb 100644
--- a/arch/arm/include/asm/bitops.h
+++ b/arch/arm/include/asm/bitops.h
@@ -17,7 +17,7 @@
#ifdef __KERNEL__
-#include
+#include
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
diff --git a/arch/arm/include/asm/proc-armv/processor.h
b/arch/arm/include/asm/proc-armv/processor.h
index 5bfab7f..532f207 100644
--- a/arch/arm/include/asm/proc-armv/processor.h
+++ b/arch/arm/include/asm/proc-armv/processor.h
@@ -18,7 +18,7 @@
#ifndef __ASM_PROC_PROCESSOR_H
#define __ASM_PROC_PROCESSOR_H
-#include
+#include
#define KERNEL_STACK_SIZE PAGE_SIZE
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 445d449..83481c6 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -45,7 +45,7 @@ typedef unsigned long mm_segment_t; /* domain
register */
#if 0 /* XXX###XXX */
#include
#endif /* XXX###XXX */
-#include
+#include
#include
union debug_insn {
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 73c9087..a836f6c 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -11,7 +11,7 @@
/* options set using PTRACE_SETOPTIONS */
#define PTRACE_O_TRACESYSGOOD 0x0001
-#include
+#include
#ifndef __ASSEMBLY__
#define pc_pointer(v) \
diff --git a/mkconfig b/mkconfig
index cd911a9..2bf5897 100755
--- a/mkconfig
+++ b/mkconfig
@@ -120,11 +120,6 @@ else
ln -s ${LNPREFIX}arch-${soc} asm/arch
fi
-if [ "${arch}" = "arm" ] ; then
- rm -f asm/proc
- ln -s ${LNPREFIX}proc-armv asm/proc
-fi
-
if [ -z "$KBUILD_SRC" ] ; then
cd ${srctree}/include
fi
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/master
On Tue, Jun 10, 2014 at 05:10:02PM +0900, Nobuhiro Iwamatsu wrote: > Dear Tom Rini. > > Please pull u-boot-sh master branch. > This PR is included part of net stuff. > > The following changes since commit 55e8250bd3cfd996d1caa04f520160a89ec04754: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-06-08 > 07:58:41 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 1dbd7280dc73dd4a6b38f3d17426393951d7d53e: > > net: sh-eth: Fix typo from rESR_RTLF to EESR_RTLF (2014-06-10 17:05:03 > +0900) > > > Nobuhiro Iwamatsu (3): > net: sh-eth: Add support R7S72100 of rmobile > net: sh-eth: Fix coding style > net: sh-eth: Fix typo from rESR_RTLF to EESR_RTLF > > drivers/net/sh_eth.c | 45 - > drivers/net/sh_eth.h | 92 > > 2 files changed, 100 insertions(+), 37 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: Whitespace fix
Signed-off-by: Vasili Galka --- arch/arm/cpu/armv7/exynos/spl_boot.c |4 ++-- board/Marvell/include/pci.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c b/arch/arm/cpu/armv7/exynos/spl_boot.c index ade45fd..7916630 100644 --- a/arch/arm/cpu/armv7/exynos/spl_boot.c +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c @@ -4,8 +4,8 @@ * SPDX-License-Identifier:GPL-2.0+ */ -#include -#include +#include +#include #include #include diff --git a/board/Marvell/include/pci.h b/board/Marvell/include/pci.h index 167248d..572e0d3 100644 --- a/board/Marvell/include/pci.h +++ b/board/Marvell/include/pci.h @@ -7,8 +7,8 @@ /* includes */ -#include"core.h" -#include"memory.h" +#include "core.h" +#include "memory.h" /* According to PCI REV 2.1 MAX agents allowed on the bus are -21- */ #define PCI_MAX_DEVICES 22 -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-dfu
On Tuesday, June 10, 2014 at 08:10:01 AM, Lukasz Majewski wrote: > Hi Marek, > > > On Monday, June 09, 2014 at 12:51:43 PM, Lukasz Majewski wrote: > > > Hi Marek, > > > > > > > Hi Marek, > > > > > > > > > On Monday, May 26, 2014 at 07:46:27 AM, Lukasz Majewski wrote: > > > > > > Hi Marek > > > > > > > > > > > > The following changes since commit > > > > > > > > > > > > fc25fa27e5f439705e9ca42182014e2d75d9f0ae: > > > > > > dfu, nand: add medium specific polltimeout function > > > > > > > > > > > > (2014-05-08 10:38:30 +0200) > > > > > > > > > > > > are available in the git repository at: > > > > > > ssh://gu-...@git.denx.de/u-boot-dfu master > > > > > > > > > > > > for you to fetch changes up to > > > > > > > > > > > > 03bc75c206e25e8aeb8070b86424f7860453: > > > > > > dfu: Introduction of the "dfu_hash_algo" env variable for > > > > > > > > > > > > checksum method setting (2014-05-26 07:31:54 +0200) > > > > > > > > > > > > > > > > > > > > > > > > Lukasz Majewski (1): > > > > > > dfu: Introduction of the "dfu_hash_algo" env variable > > > > > > > > > > > > for > > > > > > > > > > > > checksum method setting > > > > > > > > > > I had merge conflict here, so I picked the one patch by hand. > > > > > > I've made a little mistake. The v4 was merged indeed, however on the > > > list we have agreed to merge v3. Rest of the mail is correct :-). > > > > > > Sorry for confusion. > > > > Please send me an incremental patch. I don't want to rewrite history, > > so I will apply it on top of the current stuff. > > Ok. Great :=) Thanks! 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 2/5] sunxi: Add i2c support
> -Original Message-
> From: Hans de Goede [mailto:hdego...@redhat.com]
> Sent: 09 June 2014 22:44
> To: Albert ARIBAUD
> Cc: Heiko Schocher; Henrik Nordström; Ian Campbell; u-
> b...@lists.denx.de; Prafulla Wadaskar
> Subject: Re: [PATCH 2/5] sunxi: Add i2c support
>
> Hi,
>
> On 06/09/2014 06:09 PM, Albert ARIBAUD wrote:
> > Hi Hans,
> >
> > On Mon, 9 Jun 2014 17:15:27 +0200, Hans de Goede
>
> > wrote:
> >
> >> Add support for the i2c controller found on all
> Allwinner sunxi SoCs,
> >> this is the same controller as found on the Marvell
> orion5x and kirkwood
> >> SoC families, with a slightly different register
> layout, so this patch uses
> >> the existing mvtwsi code.
> >
> > Should not affect orion or kirkwood, since you're
> just adding a
> > variant to the "include switch case" where it was
> intended; but just in
> > case, I'm Cc:ing Prafulla here.
>
> Ah, good idea, thanks. Prafulla, this patch indeed does
> not affect
> orion or kirkwood, but the previous patch in the series
> does, if you
> could review and/or test it that would be great. And
> sorry for not
> CC-ing you on that patch from the get go.
That's okay Hans
>
> Regards,
>
> Hans
>
> >
> >> Signed-off-by: Hans de Goede
> >> Acked-by: Ian Campbell
> >> ---
> >> arch/arm/cpu/armv7/sunxi/board.c| 6
> ++
> >> arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 5 +
> >> arch/arm/include/asm/arch-sunxi/i2c.h | 15
> +++
> >> board/sunxi/board.c | 7
> +++
> >> drivers/i2c/mvtwsi.c| 18
> ++
> >> include/configs/sunxi-common.h | 8
>
> >> 6 files changed, 59 insertions(+)
> >> create mode 100644 arch/arm/include/asm/arch-
> sunxi/i2c.h
> >>
> >> diff --git a/arch/arm/cpu/armv7/sunxi/board.c
> b/arch/arm/cpu/armv7/sunxi/board.c
> >> index 1e506b5..024c8c1 100644
> >> --- a/arch/arm/cpu/armv7/sunxi/board.c
> >> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> >> @@ -11,6 +11,7 @@
> >>*/
> >>
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -91,11 +92,16 @@ void s_init(void)
> >>clock_init();
> >>timer_init();
> >>gpio_init();
> >> + i2c_init_board();
> >>
> >> #ifdef CONFIG_SPL_BUILD
> >>gd = &gdata;
> >>preloader_console_init();
> >>
> >> +#ifdef CONFIG_SPL_I2C_SUPPORT
> >> + /* Needed early by sunxi_board_init if PMU is
> enabled */
> >> + i2c_init(CONFIG_SYS_I2C_SPEED,
> CONFIG_SYS_I2C_SLAVE);
> >> +#endif
> >>sunxi_board_init();
> >> #endif
> >> }
> >> diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> >> index c1ae227..53f0cbd 100644
> >> --- a/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> >> +++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl.lds
> >> @@ -39,6 +39,11 @@ SECTIONS
> >>.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
> >>
> >>. = ALIGN(4);
> >> + .u_boot_list : {
> >> + KEEP(*(SORT(.u_boot_list*)));
> >> + } > .sram
> >> +
> >> + . = ALIGN(4);
> >
> > This adds the U-Boot commands section to an SPL
> linker script, which
> > seems to imply it was not there before. Are you
> actually adding command
> > line to the SPL of this board family?
> >
> >>__image_copy_end = .;
> >>_end = .;
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
> b/arch/arm/include/asm/arch-sunxi/i2c.h
> >> new file mode 100644
> >> index 000..dc5406b
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-sunxi/i2c.h
> >> @@ -0,0 +1,15 @@
> >> +/*
> >> + * Copyright 2014 - Hans de Goede
>
> >> + *
> >> + * SPDX-License-Identifier: GPL-2.0+
> >> + */
> >> +#ifndef _SUNXI_I2C_H_
> >> +#define _SUNXI_I2C_H_
> >> +
> >> +#include
> >> +
> >> +#define CONFIG_I2C_MVTWSI_BASESUNXI_TWI0_BASE
> >> +/* This is abp0-clk on sun4i/5i/7i / abp1-clk on
> sun6i/sun8i which is 24MHz */
> >> +#define CONFIG_SYS_TCLK 2400
> >> +
> >> +#endif
> >> diff --git a/board/sunxi/board.c
> b/board/sunxi/board.c
> >> index b05d0b9..543b809 100644
> >> --- a/board/sunxi/board.c
> >> +++ b/board/sunxi/board.c
> >> @@ -106,6 +106,13 @@ int board_mmc_init(bd_t *bis)
> >> }
> >> #endif
> >>
> >> +void i2c_init_board(void)
> >> +{
> >> + sunxi_gpio_set_cfgpin(SUNXI_GPB(0),
> SUNXI_GPB0_TWI0);
> >> + sunxi_gpio_set_cfgpin(SUNXI_GPB(1),
> SUNXI_GPB0_TWI0);
> >> + clock_twi_onoff(0, 1);
> >> +}
> >> +
> >> #ifdef CONFIG_SPL_BUILD
> >> void sunxi_board_init(void)
> >> {
> >> diff --git a/drivers/i2c/mvtwsi.c
> b/drivers/i2c/mvtwsi.c
> >> index d3457b9..ad1ce8f 100644
> >> --- a/drivers/i2c/mvtwsi.c
> >> +++ b/drivers/i2c/mvtwsi.c
> >> @@ -22,6 +22,8 @@
> >> #include
> >> #elif defined(CONFIG_KIRKWOOD)
> >> #include
> >> +#elif defined(CONFIG_SUNXI)
> >> +#include
> >> #else
> >> #error Driver mvtwsi not supported by SoC or board
> >> #endif
> >> @@ -30,6 +32,20 @@
> >>* TWSI register structure
> >>*/
> >>
> >> +#ifdef CONFIG_SUNXI
> >> +
> >> +struct
Re: [U-Boot] Please pick up the maintainership on orphan boards
On Tue, Jun 10, 2014 at 02:54:20PM +0530, Tushar Behera wrote: > On 29 May 2014 12:06, Tushar Behera wrote: > > On 29 May 2014 11:30, Minkyu Kang wrote: > >> Dear Tushar Behera, > >> > >> On 29/05/14 12:43, Masahiro Yamada wrote: > >>> Minkyu, > >>> Inderpal Singh is invalid. > >>> Could you assign another enginner resposible for "arndale" board? > >>> > >> > >> It seems to Inderpal Singh is no longer with Linaro. > >> Could you please assign some people to maintain "arndale" board? > >> > > Henceforth, Chander would be the maintainer for Arndale board. > > Chander Kashyap > > Do you want me to send a patch regarding this? Well, it would be best for them to send the patch :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] trats/trats2: exynos_power_init: return 0 if no battery detected.
Generic board support is now enabled for Exynos 4, and if any
init function returns an error then the init process is stopped.
This makes a boot issue on the Trats and Trats2 devices. If the device
is supplied by USB cable or an external power supply then it can't boot
because function exynos_power_init returns an error. Now this function
returns 0 if battery is not connected.
Signed-off-by: Przemyslaw Marczak
Cc: Lukasz Majewski
Cc: Piotr Wilczek
Cc: Minkyu Kang
---
board/samsung/trats/trats.c | 2 +-
board/samsung/trats2/trats2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index fec72d4..3dd340b 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -332,7 +332,7 @@ int exynos_power_init(void)
if (!p_chrg->chrg->chrg_bat_present(p_chrg)) {
puts("No battery detected\n");
- return -1;
+ return 0;
}
p_fg->fg->fg_battery_check(p_fg, p_bat);
diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
index e4987ce..fa26e61 100644
--- a/board/samsung/trats2/trats2.c
+++ b/board/samsung/trats2/trats2.c
@@ -214,7 +214,7 @@ int exynos_power_init(void)
if (!p_chrg->chrg->chrg_bat_present(p_chrg)) {
puts("No battery detected\n");
- return -1;
+ return 0;
}
p_fg->fg->fg_battery_check(p_fg, p_bat);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mvtwsi: convert to CONFIG_SYS_I2C framework
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Hans de Goede
> Sent: 09 June 2014 20:45
> To: Albert ARIBAUD; Heiko Schocher
> Cc: u-boot@lists.denx.de; Ian Campbell
> Subject: [U-Boot] [PATCH 1/5] mvtwsi: convert to
> CONFIG_SYS_I2C framework
>
> Note this has only been tested on Allwinner sunxi
> devices (support for which
> gets introduced by a later patch).
>
> The kirkwood changes have been compile tested using the
> wireless_space board
> config, the orion5x changes have been compile tested
> using the edminiv2 board
> config.
>
> Signed-off-by: Hans de Goede
> ---
> arch/arm/include/asm/arch-kirkwood/config.h | 3 +-
> drivers/i2c/Makefile| 2 +-
> drivers/i2c/mvtwsi.c| 69
> +
> include/configs/edminiv2.h | 3 +-
> 4 files changed, 36 insertions(+), 41 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-
> kirkwood/config.h b/arch/arm/include/asm/arch-
> kirkwood/config.h
> index 7a688e4..f7bfa0e 100644
> --- a/arch/arm/include/asm/arch-kirkwood/config.h
> +++ b/arch/arm/include/asm/arch-kirkwood/config.h
> @@ -129,7 +129,8 @@
> */
> #ifdef CONFIG_CMD_I2C
> #ifndef CONFIG_SYS_I2C_SOFT
> -#define CONFIG_I2C_MVTWSI
> +#define CONFIG_SYS_I2C
> +#define CONFIG_SYS_I2C_MVTWSI
These are bit risky changes, I hope it do not break the compatibility with
other boards like guruplug, openrd and so on...
Unfortunately I do not have boards to validate..
So please kindly make sure you test them well.
Regards...
Prafulla . . .
> #endif
> #define CONFIG_SYS_I2C_SLAVE 0x0
> #define CONFIG_SYS_I2C_SPEED 10
> diff --git a/drivers/i2c/Makefile
> b/drivers/i2c/Makefile
> index e33586d..61e9f3c 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -7,7 +7,6 @@
>
> obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
> obj-$(CONFIG_DW_I2C) += designware_i2c.o
> -obj-$(CONFIG_I2C_MVTWSI) += mvtwsi.o
> obj-$(CONFIG_I2C_MV) += mv_i2c.o
> obj-$(CONFIG_I2C_MXS) += mxs_i2c.o
> obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
> @@ -19,6 +18,7 @@ obj-$(CONFIG_SYS_I2C_DAVINCI) +=
> davinci_i2c.o
> obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
> obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
> obj-$(CONFIG_SYS_I2C_KONA) += kona_i2c.o
> +obj-$(CONFIG_SYS_I2C_MVTWSI) += mvtwsi.o
> obj-$(CONFIG_SYS_I2C_MXC) += mxc_i2c.o
> obj-$(CONFIG_SYS_I2C_OMAP24XX) += omap24xx_i2c.o
> obj-$(CONFIG_SYS_I2C_OMAP34XX) += omap24xx_i2c.o
> diff --git a/drivers/i2c/mvtwsi.c
> b/drivers/i2c/mvtwsi.c
> index 5ba0e03..d3457b9 100644
> --- a/drivers/i2c/mvtwsi.c
> +++ b/drivers/i2c/mvtwsi.c
> @@ -220,11 +220,10 @@ static int twsi_stop(int status)
>
> /*
> * Reset controller.
> - * Called at end of i2c_init unsuccessful i2c
> transactions.
> * Controller reset also resets the baud rate and
> slave address, so
> - * re-establish them.
> + * they must be re-established afterwards.
> */
> -static void twsi_reset(u8 baud_rate, u8 slave_address)
> +static void twsi_reset(struct i2c_adapter *adap)
> {
> /* ensure controller will be enabled by any twsi*()
> function */
> twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
> @@ -232,23 +231,17 @@ static void twsi_reset(u8
> baud_rate, u8 slave_address)
> writel(0, &twsi->soft_reset);
> /* wait 2 ms -- this is what the Marvell LSP does
> */
> udelay(2);
> - /* set baud rate */
> - writel(baud_rate, &twsi->baudrate);
> - /* set slave address even though we don't use it */
> - writel(slave_address, &twsi->slave_address);
> - writel(0, &twsi->xtnd_slave_addr);
> - /* assert STOP but don't care for the result */
> - (void) twsi_stop(0);
> }
>
> /*
> * I2C init called by cmd_i2c when doing 'i2c reset'.
> * Sets baud to the highest possible value not
> exceeding requested one.
> */
> -void i2c_init(int requested_speed, int slaveadd)
> +static unsigned int twsi_i2c_set_bus_speed(struct
> i2c_adapter *adap,
> +unsigned int requested_speed)
> {
> - int tmp_speed, highest_speed, n, m;
> - int baud = 0x44; /* baudrate at controller reset */
> + unsigned int tmp_speed, highest_speed, n, m;
> + unsigned int baud = 0x44; /* baudrate at controller
> reset */
>
> /* use actual speed to collect progressively higher
> values */
> highest_speed = 0;
> @@ -263,8 +256,21 @@ void i2c_init(int requested_speed,
> int slaveadd)
> }
> }
> }
> + writel(baud, &twsi->baudrate);
> + return 0;
> +}
> +
> +static void twsi_i2c_init(struct i2c_adapter *adap,
> int speed, int slaveadd)
> +{
> /* reset controller */
> - twsi_reset(baud, slaveadd);
> + twsi_reset(adap);
> + /* set speed */
> + twsi_i2c_set_bus_speed(adap, speed);
> + /* set slave address even though we don't use it */
> + writel(slaveadd, &twsi-
[U-Boot] [RFC] Proposal to change include search model
Hi,
Currently U-Boot has a long list of include search paths. This makes
it hard to understand the location of each header. Moreover, it opens
an easy opportunity for breaking build by including the wrong header.
This is especially easy when compiling the tools directory. I found
numerous commits dealing with such problems over the years.
What I propose is changing the way of how #include directives are
written. For example instead of:
#include /* From toolchain */
#include /* include/api_public.h */
#include /* include/linux/mii.h */
#include /* Auto-generated somewhere */
#include/* Auto-generated somewhere */
#include /* arch/arc/include/asm/arcregs.h */
#include /* arch/arm/include/asm/
arch-davinci/emac_defs.h */
#include "../../../../../drivers/net/davinci_emac.h"
and let the developer guess the locations... I propose writing:
#include /* <> means from toolchain */
#include "inc/api_public.h" /* From u-boot/include/ dir */
#include "inc/linux/mii.h"
#include "config/config.h" /* From dedicated config dir */
#include "generated/bmp_logo.h"
#include "arch/asm/arcregs.h" /* From configured architecture */
#include "soc/emac_defs.h" /* From configured SoC */
#include "u-boot/drivers/net/davinci_emac.h"
This way the developer will instantly know the exact header locations.
Moreover, the chance for ambiguities is very small which makes build
breakages less likely.
The proposal may seem strange to you at first, as most of you are
probably used to a different approach. But please consider its
advantages. I've been working on projects that used similar scheme
and it significantly simplifies the developer life.
The above can be implemented by creating
inc/ arch/ soc/ u-boot/
filesystem links in ${objtree}/include. Then, the only compiler flag
required will be "-iquote ${objtree}/include". No ugly -idirafter flags,
no long search list. Keep it simple.
I'll be glad for your opinions!
P.S. I've already mentioned this proposal when discussing Cygwin/FreeBSD
build breakages. But it deserves a separate thread.
Best,
Vasili
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] usb: ci_udc: complete ep0 direction handling
On 06/01/2014 11:22 AM, Marek Vasut wrote: > On Thursday, May 29, 2014 at 10:53:03 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> handle_setup() currently assumes that the response to a Setup transaction >> will be an OUT transaction, and any subsequent packet (if any) will be an >> IN transaction. This appears to be valid in many cases; both USB ... > Applied all, thanks. Thanks. Are these headed for v2014.07? I don't see these in the main U-Boot repo yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: return meaningful error codes from mmc_select_hwpart
On 06/02/2014 12:18 AM, Pantelis Antoniou wrote: > On May 23, 2014, at 9:47 PM, Stephen Warren wrote: >> Rather than just returning -1 everywhere, try to return something >> meaningful from mmc_select_hwpart(). Note that most other MMC functions >> don't do this, including functions called from mmc_select_hwpart(), so >> I'm not sure how effective this will be. Still, it's one less place with >> hard-coded -1. ... > This does indeed look good. ... > Acked-by: Pantelis Antoniou Are you intending to apply this patch, or were you expecting someone else to? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] cmd_mmc: default to HW partition 0 if not specified
On 05/30/2014 03:11 PM, Stephen Warren wrote: > On 05/23/2014 12:48 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> Currently, "mmc dev 0" does not change the selected HW partition. I >> think it makes more sense if "mmc dev 0" is an alias for "mmc dev 0 0", >> i.e. that HW partition 0 (main data area) is always selected by default >> if the user didn't request a specific partition. Otherwise, the following >> happens, which feels wrong: >> >> Select HW partition 1 (boot0): >> mmc dev 0 1 >> >> Doesn't change the HW partition, so it's still 1 (boot0): >> mmc dev 0 >> >> With this patch, the second command above re-selects the main data area. >> >> Note that some MMC devices (i.e. SD cards) don't support HW partitions. >> However, this patch still works, since mmc_start_init() sets the current >> partition number to 0, and mmc_select_hwpart() succeeds if the requested >> partition is already selected. > > Pantelis, does this series look good? Any comment on this series? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] cmd_mmc: add force_init parameter to init_mmc_device()
On 05/30/2014 03:12 PM, Stephen Warren wrote: > On 05/23/2014 01:24 PM, Stephen Warren wrote: >> From: Stephen Warren >> >> This allows callers to inject mmc->has_init = 0 between finding the >> MMC device, and calling mmc_init(), which forces mmc_init() to rescan >> the HW. Future changes will use this feature. > > Pantelis, does this series look good? Any comments? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: return meaningful error codes from mmc_select_hwpart
On Jun 10, 2014, at 7:00 PM, Stephen Warren wrote: > On 06/02/2014 12:18 AM, Pantelis Antoniou wrote: >> On May 23, 2014, at 9:47 PM, Stephen Warren wrote: >>> Rather than just returning -1 everywhere, try to return something >>> meaningful from mmc_select_hwpart(). Note that most other MMC functions >>> don't do this, including functions called from mmc_select_hwpart(), so >>> I'm not sure how effective this will be. Still, it's one less place with >>> hard-coded -1. > ... >> This does indeed look good. > ... >> Acked-by: Pantelis Antoniou > > Are you intending to apply this patch, or were you expecting someone > else to? I will apply the patch, but it will go out with the rest on the next mmc pull request this week. Regards -- Pantelis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup
On 06/10/2014 02:15 AM, Mark Rutland wrote: > Hi, > > Apologies for the delay in replying. > > On Fri, Jun 06, 2014 at 11:14:23PM +0100, York Sun wrote: >> On 06/06/2014 01:17 PM, York Sun wrote: >>> On 06/06/2014 10:32 AM, Mark Rutland wrote: >> How is TCR_EL2.SH0 (or TCR_EL1.SH*) configured? >> >> You'll only need to flush the cache if they're configured non shareable. > > It is configured as non shareable. Is there any reason not to configure them as inner shareable? That way the MMU will look in the D-cache, and you won't have to spend time flushing them. >>> >>> Mark, >>> >>> I appreciate the reminder. I tried on our emulator. With inner share set >>> for TCR >>> SH0 bits, u-boot works with the flushing, but doesn't work without >>> flushing. It >>> went to exception. >>> >>> Can you share more information about the inner share? I need to follow up >>> with >>> our designer to confirm. >>> >> >> A second thought, do I need to set the first MMU table so DDR is inner >> shareable? > > I assume you mean configuring MAIR_ELx such that the mapping covering > DDR is cacheable for the inner shareable domain? If so, yes. > Mark, I will continue to experiment this idea. In the meantime, please comment on my v6 patch set. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] dfu: free entities when parsing fails
From: Stephen Warren
When dfu_init_env_entities() fails part-way through, some entities may
have been added to dfu_list. These are only removed by dfu_free_entities().
If that function isn't called, those stale entities will still exist the
next time dfu_init_env_entities() is called, leading to confusion. Fix
do_dfu() to ensure that dfu_free_entities() is always called, to avoid
this confusion.
Signed-off-by: Stephen Warren
---
common/cmd_dfu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
index a03538dabb37..433bddd5d2bd 100644
--- a/common/cmd_dfu.c
+++ b/common/cmd_dfu.c
@@ -27,8 +27,9 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
ret = dfu_init_env_entities(interface, simple_strtoul(devstring,
NULL, 10));
if (ret)
- return ret;
+ goto done;
+ ret = CMD_RET_SUCCESS;
if (argc > 4 && strcmp(argv[4], "list") == 0) {
dfu_show_entities();
goto done;
@@ -61,7 +62,7 @@ done:
if (dfu_reset())
run_command("reset", 0);
- return CMD_RET_SUCCESS;
+ return ret;
}
U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot: vexpressca9x4: hang(?) with qemu
09.06.2014 21:52, Matwey V. Kornilov пишет: > > It actually jumps to 0x6001 where the middle of > get_device_and_partition located. > I've found that it works with qemu 1.7 but I have to provide u-boot in ELF format, bare-metal u-boot.bin don't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2014.07-rc3 released
Hey all, I've pushed v2014.07-rc3 out to the repository and tarballs should exist soon. We're getting better on the syncing up of things out of patchwork and I know there's still a few items to go (and some bigger ideas I need to come back to commenting on). As always, if anything is broken please speak up. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.07-rc3 released
Hi Tom! On 10.06.2014 18:14, Tom Rini wrote: I've pushed v2014.07-rc3 out to the repository and tarballs should exist soon. We're getting better on the syncing up of things out of patchwork and I know there's still a few items to go (and some bigger ideas I need to come back to commenting on). As always, if anything is broken please speak up. What comes to my mind is the run_command() return code patch series from Thomas Betker: http://patchwork.ozlabs.org/patch/356568/ http://patchwork.ozlabs.org/patch/356569/ http://patchwork.ozlabs.org/patch/356570/ This series fixes a regression. So its definitely a candidate for this upcoming release (perhaps already on your to-do list). Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] usb: ci_udc: call udc_disconnect() from ci_pullup()
From: Stephen Warren
ci_pullup()'s !is_on path contains a cut/paste copy of udc_disconnect().
Remove the duplication by simply calling udc_disconnect() instead.
Signed-off-by: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 6dc20c6c954c..5f308563e246 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -697,6 +697,17 @@ int usb_gadget_handle_interrupts(void)
return value;
}
+void udc_disconnect(void)
+{
+ struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
+ /* disable pullup */
+ stop_activity();
+ writel(USBCMD_FS2, &udc->usbcmd);
+ udelay(800);
+ if (controller.driver)
+ controller.driver->disconnect(&controller.gadget);
+}
+
static int ci_pullup(struct usb_gadget *gadget, int is_on)
{
struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
@@ -715,27 +726,12 @@ static int ci_pullup(struct usb_gadget *gadget, int is_on)
/* Turn on the USB connection by enabling the pullup resistor */
writel(USBCMD_ITC(MICRO_8FRAME) | USBCMD_RUN, &udc->usbcmd);
} else {
- stop_activity();
- writel(USBCMD_FS2, &udc->usbcmd);
- udelay(800);
- if (controller.driver)
- controller.driver->disconnect(gadget);
+ udc_disconnect();
}
return 0;
}
-void udc_disconnect(void)
-{
- struct ci_udc *udc = (struct ci_udc *)controller.ctrl->hcor;
- /* disable pullup */
- stop_activity();
- writel(USBCMD_FS2, &udc->usbcmd);
- udelay(800);
- if (controller.driver)
- controller.driver->disconnect(&controller.gadget);
-}
-
static int ci_udc_probe(void)
{
struct ept_queue_head *head;
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] usb: ci_udc: clean up all allocations in unregister
From: Stephen Warren
usb_gadget_unregister_driver() is called to tear down the USB device mode
stack. Fix the driver to stop the USB HW (which causes any attached host
to notice the disappearance of the device), and free all allocations
(which obviously prevents memory leaks).
Signed-off-by: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 1428af85cffd..435a2720e96f 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -875,5 +875,11 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
{
+ udc_disconnect();
+
+ ci_ep_free_request(&controller.ep[0].ep, &controller.ep0_req->req);
+ free(controller.items_mem);
+ free(controller.epts);
+
return 0;
}
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] usb: ci_udc: fix probe error cleanup
From: Stephen Warren
If allocation of the ep0 req fails, clean up all the allocations that
were made in ci_udc_probe().
Signed-off-by: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 7a6563f83fd1..1428af85cffd 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -826,6 +826,7 @@ static int ci_udc_probe(void)
ci_ep_alloc_request(&controller.ep[0].ep, 0);
if (!controller.ep0_req) {
+ free(controller.items_mem);
free(controller.epts);
return -ENOMEM;
}
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] usb: ci_udc: fix freeing of ep0 req
From: Stephen Warren
ci_ep_alloc_request() avoids allocating multiple request objects for ep0
by keeping a record of the first req allocated for ep0, and always
returning that instead of allocating a new req. However, if this req is
ever freed, the record of the previous allocation is not cleared, so
ci_ep_alloc_request() will keep returning this stale pointer. Fix
ci_ep_free_request() to clear the record of the previous allocation.
Signed-off-by: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index 5f308563e246..7a6563f83fd1 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -221,9 +221,14 @@ ci_ep_alloc_request(struct usb_ep *ep, unsigned int
gfp_flags)
static void ci_ep_free_request(struct usb_ep *ep, struct usb_request *req)
{
- struct ci_req *ci_req;
+ struct ci_ep *ci_ep = container_of(ep, struct ci_ep, ep);
+ struct ci_req *ci_req = container_of(req, struct ci_req, req);
+ int num;
+
+ num = ci_ep->desc->bEndpointAddress & USB_ENDPOINT_NUMBER_MASK;
+ if (num == 0)
+ controller.ep0_req = 0;
- ci_req = container_of(req, struct ci_req, req);
if (ci_req->b_buf)
free(ci_req->b_buf);
free(ci_req);
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.07-rc3 released
Dear Tom, In message <20140610161453.GB7841@bill-the-cat> you wrote: > > I've pushed v2014.07-rc3 out to the repository and tarballs should exist > soon. The tarball is available on the FTP server. 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 Successful and fortunate crime is called virtue. - Seneca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.07-rc3 released
On Tue, Jun 10, 2014 at 07:01:51PM +0200, Stefan Roese wrote: > Hi Tom! > > On 10.06.2014 18:14, Tom Rini wrote: > >I've pushed v2014.07-rc3 out to the repository and tarballs should exist > >soon. > > > >We're getting better on the syncing up of things out of patchwork and I > >know there's still a few items to go (and some bigger ideas I need to > >come back to commenting on). > > > >As always, if anything is broken please speak up. > > What comes to my mind is the run_command() return code patch series > from Thomas Betker: > > http://patchwork.ozlabs.org/patch/356568/ > http://patchwork.ozlabs.org/patch/356569/ > http://patchwork.ozlabs.org/patch/356570/ > > This series fixes a regression. So its definitely a candidate for > this upcoming release (perhaps already on your to-do list). Yes, I almost grabbed this last week but it had just been posted the day before or so. I shall pick it up, thanks for the reminder. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] omap3: overo: Select fdtfile for expansion board
On Tue, Jun 10, 2014 at 12:30 AM, Stefan Herbrechtsmeier wrote: > Why you set the 'expansionname' to 'tobi' for unknown (maybe foreign) > expansion boards? 1. We need some sort of default otherwise people's boards that either don't have an eeprom or don't have board data set in the eeprom will stop booting. Some Overo COMs don't have NAND therefore there is not a good mechansim for saving the environment. 2. Tobi has been the default for ages and it is reasonable generic choice. It is also the most common expansion board for Overo COMs out there. > >> break; >> } > > What happens if the eeprom is empty, no eeprom is available or the ETTUS > expansion board is present? In this case the expansionname is empty. I think 'expansionname' is set to 'tobi' in the default case of the switch statement. --Ash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dfu: fix some issues with reads/uploads
On 05/30/2014 02:28 AM, Lukasz Majewski wrote: > Stephen Warren wrote: ... >> Wouldn't it be better to have the following separate >> "backends" to DFU: >> >> * MMC (raw IO only) >> * NAND (raw IO only) >> * RAM (raw IO only) >> * Filesystem (anything that fs/fat/ext* load/write can support) >> >> That way, DFU could be applied to e.g. USB mass storage, IDE, >> SATA, ... devices too. > > I think that separating the IO even from dfu_mmc.c code would be a good > way to go. > > Could you however, present how would you like to fit it to the current > design? Here's how I'd love to see the dfu command work. It would take a bit of refactoring of the code, and a change to the format of the dfu_alt_info variable and "dfu" command parameters. Perhaps we could have an option to the "dfu" command saying which cmdline style the user is using? dfu_alt_info = setting [; setting]* setting = mmc_format | nand_format | ram_format | fs_format mmc_format = "mmc" device_id hwpart_num start_sector sector_count nand_format = "nand" device_id start_sector sector_count ram_format = "ram" start_address byte_count fs_format = "fs" fs_device_type fs_device_id filename All fs access would be through the generic filesystem API in fs/fs.c rather than by using run_command(). The "fs_device_type", "fs_device_id", and "filename" parameters in "fs_format" above would simply be passed directly to the fs.c APIs without any interpretation by the DFU code. This would allow automatic support of any memory device type that "load", "ls", ... support. The code also wouldn't have to construct command-lines and then re-parse them; calling functions directly is a lot simpler. The "dfu" command wouldn't take any device type/ID parameters. Instead, all device IDs would be part of the dfu_alt_info variable. This would allow e.g. eMMC partitions and SPI flash devices to be exposed at the same time, rather than having to somehow co-ordinate executing one dfu command in U-Boot to update the SPI flash, then quitting that, then starting a different dfu command in U-Boot to update some data on eMMC. It's harder to automate that vs. just starting dfu once, then running a single script on the host which writes a bunch of dfu settings in sequence without the need for co-ordination. I'm not sure how much time I have to actually work on converting the code to work that way though. Since we already have a working non-DFU flashing solution using U-Boot[1], my management sees any work on DFU as a bit redundant. Still, it would be nice to use standard protocols for this... [1] https://github.com/NVIDIA/tegra-uboot-flasher-scripts ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
On 14-06-09 10:16 PM, Albert ARIBAUD wrote: Hi Steve, (sorry for the duplicate) On Mon, 9 Jun 2014 13:45:50 -0700, Steve Rae wrote: On 14-06-09 03:23 AM, Albert ARIBAUD wrote: Hi Darwin, On Mon, 2 Jun 2014 17:37:25 -0700, Darwin Rambo wrote: On 14-06-02 12:26 AM, Albert ARIBAUD wrote: Hi Darwin, On Mon, 26 May 2014 09:11:35 -0700, Darwin Rambo wrote: Hi Albert, The previous stage bootloader (which I had no control over) wanted it's header to be aligned to a 512 byte MMC block boundary, presumably since this allowed DMA operations without copy/shifting. At the same time, I didn't want to hack a header into start.S because I didn't want to carry another downstream patch. So I investigated if I could shift u-boot's base address as a feature that would allow an aligned header to be used without the start.S patch. I know that a custom header patch to start.S would work, and that a header plus padding will also work. But I found out that you can align the base on certain smaller offsets if you keep the relocation offset at nice boundaries like 0x1000 and if the relocation offset is a multiple of the maximum alignment requirements of the image. The original patch I submitted didn't handle an end condition properly, was ARM64-specific (wasn't tested on other architectures), and because the patch was NAK'd, I didn't bother to submit a v2 patch and consider the idea to be dead. I'm happy to abandon the patch. I hope this helps. Thanks. If I understand correctly, your target has a requirement for storing the image on a 512-byte boundary. But how does this affect the loading of the image into RAM, where the requirement is only that the vectors table be 32-bytes aligned? I mean, if you store the image in MMC at offset 0x200 (thus satisfying the 512-byte boundary requirement) and load it to, say, offset 0x10020 in RAM, how is it a problem for your target? If my example above inadequately represents the issue, then can you please provide a similar but adequate example, a failure case scenario, so that I can hve a correct understanding of the problem? Hi Albert, The constraints I have that I can't change, are that - the 32 byte header is postprocessed and prepended to the image after the build is complete - the header is at a 512 byte alignment in MMC - the header and image are copied to SDRAM to an alignment like 0x8800. Thus the u-boot image is linked at and starts at 0x8820. - the vectors need to be 0x800 aligned for armv8 (.align 11 directive) So far, so good -- I understand that the link-time location of the vectors table is incorrect. So the failure case is that when the relocation happens, it relocates to a 0x1000 alignment, say something like 0xa000. The relocation offset is not a multiple of 0x1000 (0xa000 - 0x8820) and the relocation fails. What does "relocation fails" mean exactly, i.e., where and how exactly does the relocation code behave differently from expected? I'm asking because I don't understand why the relocation offset should be a multiple of 0x1000. Adjusting the relocation offset to a multiple of 0x1000 (by making the relocation address end in 0xN020) fixes the issues and allows u-boot to relocate and run from this address without failing. I hope this helps explain it a bit better. I do understand, however, that if the relocation offset must indeed be a multiple of 0x1000, then obviously the vectors table will end up as misaligned as it was before relocation. Also, personally I would like it if the vectors table was always aligned as it should, and there are at least three other boards which require a prefix/header before their vectors table, as Masahiro (cc:) indicated recently, so that makes the problem a generic one: how to properly integrate a header in-image (as opposed to an out-of-image one, which is just a matter of doing a 'cat', so to speak. Therefore I'd like a generic solution to this, where the header is prepended *and* aligned properly without breaking the start symbol alignment constraints. This /might/ be possible by cleverly adding a '.header' or '.signature' section to the linker script, possibly doing a two-stage link; but this should not require the source code to contain ad hoc relocation tricks. Let me tinker with it in the next few days; I'll try and come up with a clean and generic solution to this "in-code header" question. Thanks again for your explanation! Best regards, Darwin Amicalement, Perhaps an oversimplified example of the current code would help to explain this better: scenario #1: CONFIG_SYS_TEXT_BASE0x8800 vectors:.align 11 /* exception vectors need to be on a 0x800 byte boundary */ compile/linker produces (before relocation): _start symbol is at0x8800 vectors symbol is at0x88000800 the relocation offset is: 0x77f9b000 therefore, after relocation: _start symbol is at0xfff9b000 (0x8800+0xfff9b000) vectors
Re: [U-Boot] [Patch v2] omap3: overo: Select fdtfile for expansion board
Am 10.06.2014 19:17, schrieb Ash Charles: On Tue, Jun 10, 2014 at 12:30 AM, Stefan Herbrechtsmeier wrote: Why you set the 'expansionname' to 'tobi' for unknown (maybe foreign) expansion boards? 1. We need some sort of default otherwise people's boards that either don't have an eeprom or don't have board data set in the eeprom will stop booting. But this cases are handled by GUMSTIX_NO_EEPROM. The default is used for a programmed eeprom with an unknown vendor and device id. Some Overo COMs don't have NAND therefore there is not a good mechansim for saving the environment. You could use an environment file next to the u-boot image. 2. Tobi has been the default for ages and it is reasonable generic choice. It is also the most common expansion board for Overo COMs out there. Ok, but please use the GUMSTIX_NO_EEPROM case and leave the default empty or at least check the vendor id. This allows foreign vendors to use the upstream u-boot if they have an eeprom on there expansion board. break; } What happens if the eeprom is empty, no eeprom is available or the ETTUS expansion board is present? In this case the expansionname is empty. I think 'expansionname' is set to 'tobi' in the default case of the switch statement. I think you mixed the GUMSTIX_NO_EEPROM and default case. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Dear Steve, In message <539746c4.9040...@broadcom.com> you wrote: > > There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not > aligned on a 0x1000 byte boundary (Darwin has attempted to document his > particular use-case...) We should be more precise here and ask for any _good_ reasons. I can think of many good reasons to keep the text base aligned. As for the reasons to use an unaligned address that were brought up here, I still think that it would have been better to use an aligned taxe base and do the rest with a customized linker script. > But we think that the solution to support this is relatively > straightforward: > (1) after determining the "relocation address" (which will be on a > 0x1000 byte boundary), > (2) add "CONFIG_SYS_TEXT_BASE % 4096" to that "relocation address" > (which effectively makes the "relocation offset" a multiple of 0x1000 > too...) > So, in the scenario #1, (CONFIG_SYS_TEXT_BASE % 4096) = 0, so this > algorithm changes nothing. > And in scenario #2, (CONFIG_SYS_TEXT_BASE % 4096) = 0x20, therefore, we > would now get the following: > the relocation offset is: 0x77f9b000 > therefore, after relocation: > _startsymbol is at0xfff9b020 (0x8820+0x77f9b000) > vectors symbol is at0xfff9b800 (0x88000800+0x77f9b000) I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would have to be the same. There is no such requirement. What exactly prevents you from assigning _start a location at offset 0x20 to the start of the text segment, i. e. CONFIG_SYS_TEXT_BASE ? Then everything should be still the same for you, and no voodoo coding would be needed. > (3) HOWEVER, shifting the address UP may cause the end of the relocated > code to run past the end of the available memory... So we could: This problem is void if you just use a poperly aligned text base in combination with a prope start.S resp. linker script to make sure _start is where you want it. > I trust that everyone will find this explanation acceptable... No, I do not see a good reason to add such code. 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 Let the programmers be many and the managers few -- then all will be productive. -- Geoffrey James, "The Tao of Programming" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Makefile: fix clang warnings due to clang support
Hello Masahiro, On di, 2014-06-10 at 21:20 +0900, Masahiro Yamada wrote: > Hi Jeroen, > > > On Fri, 30 May 2014 15:45:27 +0200 > Jeroen Hofstee wrote: > > > Building u-boot tools with clang as a host compiler e.g. on > > FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` > > leads to many warnings [1] for every compiler invocation since > > commit 598e2d33. Part of mentioned commit imports linux patches: > > > > - kbuild: LLVMLinux: Adapt warnings for compilation with clang > > - kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang > > > > No version of clang supports the gcc fno-delete-null-pointer-checks > > though, but it is only passed to clang. Gcc does not have the clang > > specific Qunused-arguments for the target. Furthermore several > > warnings are disabled which aren't encountered in u-boot. Since such > > a build has worked for quite some time and works after removing these > > changes, just remove the clang specific handling to restore normal > > building with clang as hostcc. > > > > I have to admit I just copied these line from Kernel > without testing it, just for syncing with Kernel makefiles. > > > As far as I tested, Clang did not recognize > -fno-delete-null-pointer-checks. > > It is OK with me if you rip Clang stuff off the top Makefile. > > Sorry, honestly I am not familiar enough with Clang > to make deeper review. yup, it should be removed.. since with clang 3.5 trunk it actually errors. You should be able to verify it without cross target support with: `make CC="clang -no-integrated-as" HOSTCC="clang -no-integrated-as" HOST_TOOLS_ALL=y sandbox_config tools` and you get (with clang 3.5) "clang: error: unknown argument: '-fno-delete-null-pointer-checks'" (and yes the commit mentions warns, which more then likely is the case for clang 3.3 / 3.4). Undoing the Linux clang additions (as this patch does) makes the build work again. Since there is no target clang support in U-boot at the moment the target warnings suppression can be removed as well, since it is just dead code at the moment and I would like to see how far we can get with actually fixing warnings, not blindly silencing them... Regards, Jeroen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] clang sandbox warning
Hello Simon,
While trying to find a u-boot make command which likely works with a
pre-build clang linux package I got the following warnings:
`make CC="clang -no-integrated-as" HOSTCC="clang -no-integrated-as"
HOST_TOOLS_ALL=y sandbox_config tools`
/home/jeroen/software/u-boot/arch/sandbox/include/asm/bitops.h:59:17:
warning: variable 'flags' is uninitialized when used here
[-Wuninitialized]
local_irq_save(flags);
^
/home/jeroen/software/u-boot/arch/sandbox/include/asm/bitops.h:56:21:
note: initialize the variable 'flags' to silence this warning
unsigned long flags;
^
= 0
/home/jeroen/software/u-boot/arch/sandbox/include/asm/bitops.h:81:17:
warning: variable 'flags' is uninitialized when used here
[-Wuninitialized]
local_irq_save(flags);
^
/home/jeroen/software/u-boot/arch/sandbox/include/asm/bitops.h:78:21:
note: initialize the variable 'flags' to silence this warning
unsigned long flags;
^
= 0
I guess gcc accepts this since flags is not actually used. Anyway merely
mentioned for completeness. You might be interested in:
/home/jeroen/software/u-boot/tools/../lib/rsa/rsa-sign.c:77:6: warning:
variable 'ret' is used uninitialized whenever 'if' condition is true
[-Wsometimes-uninitialized]
if (!rsa) {
^~~~
/home/jeroen/software/u-boot/tools/../lib/rsa/rsa-sign.c:94:9: note:
uninitialized use occurs here
return ret;
^~~
/home/jeroen/software/u-boot/tools/../lib/rsa/rsa-sign.c:77:2: note:
remove the 'if' if its condition is always false
if (!rsa) {
^~~
/home/jeroen/software/u-boot/tools/../lib/rsa/rsa-sign.c:48:9: note:
initialize the variable 'ret' to silence this warning
int ret;
^
= 0
which actually looks like a bug. And:
/home/jeroen/software/u-boot/tools/../lib/rsa/rsa-verify.c:59:27:
warning: comparison of unsigned expression >= 0 is always true
[-Wtautological-compare]
for (i = key->len - 1; i >= 0; i--) {
~ ^ ~
which looks a bit odd, especially since there is no way to break out of
the loop and reach the final return statement, which has a comment to
that it might be useful (equal).
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Add support for AM43xx Starter Kit
Hi, patches were tested on AM43xx SK on top of v2014.07-rc3. Felipe Balbi (5): board: ti: am43xx: print unsupported board name cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register board: ti: am43xx: add support for AM43xx Starter Kit board: ti: am43xx: add AM437x SK PHY Address board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK arch/arm/cpu/armv7/am33xx/ddr.c | 1 + board/ti/am43xx/board.c | 79 +++-- board/ti/am43xx/board.h | 5 +++ board/ti/am43xx/mux.c | 3 ++ include/configs/am43xx_evm.h| 2 ++ 5 files changed, 88 insertions(+), 2 deletions(-) -- 2.0.0.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register
Signed-off-by: Felipe Balbi --- arch/arm/cpu/armv7/am33xx/ddr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c index 9a625c4..bbe9d1a 100644 --- a/arch/arm/cpu/armv7/am33xx/ddr.c +++ b/arch/arm/cpu/armv7/am33xx/ddr.c @@ -95,6 +95,7 @@ void config_sdram_emif4d5(const struct emif_regs *regs, int nr) &emif_reg[nr]->emif_rd_wr_exec_thresh); writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl); + writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl_shdw); writel(regs->sdram_config, &emif_reg[nr]->emif_sdram_config); writel(regs->sdram_config, &cstat->secure_emif_sdram_config); -- 2.0.0.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] board: ti: am43xx: print unsupported board name
when porting u-boot to a new am43xx board, it
helps to know the name of the current unsupported
board so we don't have to hunt for design documents
to figure out what's written in the EEPROM.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 71af1ae..6197076 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -260,7 +260,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
else if (board_is_gpevm())
return &gp_evm_dpll_ddr;
- puts(" Board not supported\n");
+ printf(" Board '%s' not supported\n", am43xx_board_name);
return NULL;
}
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] board: ti: am43xx: add support for AM43xx Starter Kit
AM43xx Starter Kit is a new board based on
AM437x line of SoCs. Being a low-cost EVM and
small size EVM are intended to provide an entry
level development platform on a full fledged
Hardware System.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 72 +++-
board/ti/am43xx/board.h | 5 +++
include/configs/am43xx_evm.h | 2 ++
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 6197076..b184c20 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -217,6 +217,28 @@ const struct emif_regs ddr3_emif_regs_400Mhz = {
.emif_rd_wr_exec_thresh = 0x0405
};
+static const struct emif_regs ddr3_sk_emif_regs_400Mhz = {
+ .sdram_config = 0x638413b2,
+ .sdram_config2 = 0x,
+ .ref_ctrl = 0x0c30,
+ .sdram_tim1 = 0xeaaad4db,
+ .sdram_tim2 = 0x266b7fda,
+ .sdram_tim3 = 0x107f8678,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x50074be4,
+ .temp_alert_config = 0x0,
+ .emif_ddr_phy_ctlr_1= 0x0e084007,
+ .emif_ddr_ext_phy_ctrl_1= 0x08020080,
+ .emif_ddr_ext_phy_ctrl_2= 0x00700070,
+ .emif_ddr_ext_phy_ctrl_3= 0x00700070,
+ .emif_ddr_ext_phy_ctrl_4= 0x00700070,
+ .emif_ddr_ext_phy_ctrl_5= 0x00700070,
+ .emif_rd_wr_lvl_rmp_win = 0x0,
+ .emif_rd_wr_lvl_rmp_ctl = 0x0,
+ .emif_rd_wr_lvl_ctl = 0x0,
+ .emif_rd_wr_exec_thresh = 0x0405
+};
+
const u32 ext_phy_ctrl_const_base_ddr3[] = {
0x00400040,
0x00350035,
@@ -240,6 +262,48 @@ const u32 ext_phy_ctrl_const_base_ddr3[] = {
0x08102040
};
+static const u32 ext_phy_ctrl_const_base_ddr3_sk[] = {
+ /* first 5 are taken care by emif_regs */
+ 0x00700070,
+
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+
+ 0x00800080,
+ 0x00800080,
+
+ 0x4000,
+
+ 0x08102040,
+
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+};
+
void emif_get_ext_phy_ctrl_const_regs(const u32 **regs, u32 *size)
{
if (board_is_eposevm()) {
@@ -248,6 +312,9 @@ void emif_get_ext_phy_ctrl_const_regs(const u32 **regs, u32
*size)
} else if (board_is_gpevm()) {
*regs = ext_phy_ctrl_const_base_ddr3;
*size = ARRAY_SIZE(ext_phy_ctrl_const_base_ddr3);
+ } else if (board_is_sk()) {
+ *regs = ext_phy_ctrl_const_base_ddr3_sk;
+ *size = ARRAY_SIZE(ext_phy_ctrl_const_base_ddr3_sk);
}
return;
@@ -257,7 +324,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
{
if (board_is_eposevm())
return &epos_evm_dpll_ddr;
- else if (board_is_gpevm())
+ else if (board_is_gpevm() || board_is_sk())
return &gp_evm_dpll_ddr;
printf(" Board '%s' not supported\n", am43xx_board_name);
@@ -410,6 +477,9 @@ void sdram_init(void)
enable_vtt_regulator();
config_ddr(0, &ioregs_ddr3, NULL, NULL,
&ddr3_emif_regs_400Mhz, 0);
+ } else if (board_is_sk()) {
+ config_ddr(400, &ioregs_ddr3, NULL, NULL,
+ &ddr3_sk_emif_regs_400Mhz, 0);
}
}
#endif
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
index 091162e..017047d 100644
--- a/board/ti/am43xx/board.h
+++ b/board/ti/am43xx/board.h
@@ -47,6 +47,11 @@ static inline int board_is_gpevm(void)
return !strncmp(am43xx_board_name, "AM43__GP", HDR_NAME_LEN);
}
+static inline int board_is_sk(void)
+{
+ return !strncmp(am43xx_board_name, "AM43__SK", HDR_NAME_LEN);
+}
+
void enable_uart0_pin_mux(void);
void enable_board_pin_mux(void);
void enable_i2c0_pin_mux(void);
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 823cba6..974ce98 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -226,6 +226,8 @@
"setenv fdtfile am43x-epos-evm.dtb; fi; " \
"if test $board_name = AM43__GP; then " \
"setenv fdtfile am437x-gp-evm.dtb; fi; " \
+ "if test $board_name = AM43__SK; then " \
+ "setenv fdtfile am437x-sk-evm.dtb; fi; " \
"if tes
[U-Boot] [PATCH 5/5] board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK
AM437x Starter Kit has a qspi flash and gbit ethernet
support. By muxing those signals, we can use those
interfaces from u-boot.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/mux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 77c53d2..50967e1 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -97,6 +97,9 @@ void enable_board_pin_mux(void)
if (board_is_gpevm()) {
configure_module_pin_mux(gpio5_7_pin_mux);
configure_module_pin_mux(rgmii1_pin_mux);
+ } else if (board_is_sk()) {
+ configure_module_pin_mux(rgmii1_pin_mux);
+ configure_module_pin_mux(qspi_pin_mux);
} else if (board_is_eposevm()) {
configure_module_pin_mux(rmii1_pin_mux);
configure_module_pin_mux(qspi_pin_mux);
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] board: ti: am43xx: add AM437x SK PHY Address
pass correct PHY Address when running on SK
so that we have working ethernet with this board
too.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index b184c20..054a452 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -227,16 +227,16 @@ static const struct emif_regs ddr3_sk_emif_regs_400Mhz = {
.read_idle_ctrl = 0x0005,
.zq_config = 0x50074be4,
.temp_alert_config = 0x0,
- .emif_ddr_phy_ctlr_1= 0x0e084007,
+ .emif_ddr_phy_ctlr_1= 0x0e084008,
.emif_ddr_ext_phy_ctrl_1= 0x08020080,
- .emif_ddr_ext_phy_ctrl_2= 0x00700070,
- .emif_ddr_ext_phy_ctrl_3= 0x00700070,
- .emif_ddr_ext_phy_ctrl_4= 0x00700070,
- .emif_ddr_ext_phy_ctrl_5= 0x00700070,
+ .emif_ddr_ext_phy_ctrl_2= 0x89,
+ .emif_ddr_ext_phy_ctrl_3= 0x90,
+ .emif_ddr_ext_phy_ctrl_4= 0x8e,
+ .emif_ddr_ext_phy_ctrl_5= 0x8d,
.emif_rd_wr_lvl_rmp_win = 0x0,
- .emif_rd_wr_lvl_rmp_ctl = 0x0,
- .emif_rd_wr_lvl_ctl = 0x0,
- .emif_rd_wr_exec_thresh = 0x0405
+ .emif_rd_wr_lvl_rmp_ctl = 0x,
+ .emif_rd_wr_lvl_ctl = 0x,
+ .emif_rd_wr_exec_thresh = 0x,
};
const u32 ext_phy_ctrl_const_base_ddr3[] = {
@@ -594,6 +594,11 @@ int board_eth_init(bd_t *bis)
writel(RMII_MODE_ENABLE | RMII_CHIPCKL_ENABLE, &cdev->miisel);
cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RMII;
cpsw_slaves[0].phy_addr = 16;
+ } else if (board_is_sk()) {
+ writel(RGMII_MODE_ENABLE, &cdev->miisel);
+ cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
+ cpsw_slaves[0].phy_addr = 4;
+ cpsw_slaves[1].phy_addr = 5;
} else {
writel(RGMII_MODE_ENABLE, &cdev->miisel);
cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] bcm2835_sdhci: Add SDHCI_QUIRK_NO_HISPD_BIT flag
Seems like the controller doesn't support the flag. None of the hi-speed cards I've tried could be read, while they successfully worked with the quirk enabled. Signed-off-by: Lubomir Rintel --- Changes to v2: - I've sent the first version with extra and irrelevant hunk. Sorry. drivers/mmc/bcm2835_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c index 54cfabf..82079d6 100644 --- a/drivers/mmc/bcm2835_sdhci.c +++ b/drivers/mmc/bcm2835_sdhci.c @@ -179,7 +179,7 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq) host->name = "bcm2835_sdhci"; host->ioaddr = (void *)regbase; host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B | - SDHCI_QUIRK_WAIT_SEND_CMD; + SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_NO_HISPD_BIT; host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195; host->ops = &bcm2835_ops; -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bcm2835_sdhci: Add SDHCI_QUIRK_NO_HISPD_BIT flag
Seems like the controller doesn't support the flag. None of the hi-speed cards I've tried could be read, while they successfully worked with the quirk enabled. Signed-off-by: Lubomir Rintel --- drivers/mmc/bcm2835_sdhci.c | 2 +- include/configs/rpi_b.h | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c index 54cfabf..82079d6 100644 --- a/drivers/mmc/bcm2835_sdhci.c +++ b/drivers/mmc/bcm2835_sdhci.c @@ -179,7 +179,7 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq) host->name = "bcm2835_sdhci"; host->ioaddr = (void *)regbase; host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B | - SDHCI_QUIRK_WAIT_SEND_CMD; + SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_NO_HISPD_BIT; host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195; host->ops = &bcm2835_ops; diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h index ed8b4df..1bcb798 100644 --- a/include/configs/rpi_b.h +++ b/include/configs/rpi_b.h @@ -225,6 +225,8 @@ #define CONFIG_CMDLINE_TAG #define CONFIG_INITRD_TAG +#define CONFIG_SYS_GENERIC_BOARD + #include /* Some things don't make sense on this HW or yet */ -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] usb: ci_udc: complete ep0 direction handling
On Tuesday, June 10, 2014 at 05:58:25 PM, Stephen Warren wrote: > On 06/01/2014 11:22 AM, Marek Vasut wrote: > > On Thursday, May 29, 2014 at 10:53:03 PM, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> handle_setup() currently assumes that the response to a Setup > >> transaction will be an OUT transaction, and any subsequent packet (if > >> any) will be an IN transaction. This appears to be valid in many cases; > >> both USB > > ... > > > Applied all, thanks. > > Thanks. Are these headed for v2014.07? I don't see these in the main > U-Boot repo yet. Most likely, I am waiting for Tom to pick my PR up. 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] omap3: overo: Select fdtfile for expansion board
On Tue, Jun 10, 2014 at 11:06 AM, Stefan Herbrechtsmeier wrote: > You could use an environment file next to the u-boot image. Good point. ... > Ok, but please use the GUMSTIX_NO_EEPROM case and leave the default empty or > at least check the vendor id. This allows foreign vendors to use the > upstream u-boot if they have an eeprom on there expansion board. Okay---this makes sense. I'm resending with 'tobi' in the GUMSTIX_NO_EEPROM case instead. I've added a test on vendor id in the default case to likewise use tobi in the case where the eeprom is responsive but un-programmed. ... > I think you mixed the GUMSTIX_NO_EEPROM and default case. Yes---you're totally correct---thanks for catching this. --Ash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v3] omap3: overo: Select fdtfile for expansion board
The u-boot Overo board actually supports both Overo (OMAP35xx)
and Overo Storm (AM/DM37xx) COMs with a range of different expansion
boards. This provides a mechanism to select the an appropriate device
tree file based on the processor version and, if available, the
expansion board ID written on the expansion board EEPROM. To match the
3.15+ kernels, fdtfile names have this format:
"omap3-overo[-storm]-.dtb"
By default, we use "omap3-overo-storm-tobi.dtb".
Signed-off-by: Ash Charles
Conflicts:
include/configs/omap3_overo.h
---
board/overo/overo.c | 14 ++
include/configs/omap3_overo.h | 10 +-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/board/overo/overo.c b/board/overo/overo.c
index 62b50a8..13220c5 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -267,12 +267,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "summit");
break;
case GUMSTIX_TOBI:
printf("Recognized Tobi expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "tobi");
break;
case GUMSTIX_TOBI_DUO:
printf("Recognized Tobi Duo expansion board (rev %d %s)\n",
@@ -293,12 +295,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "palo43");
break;
case GUMSTIX_CHESTNUT43:
printf("Recognized Chestnut43 expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "chestnut43");
break;
case GUMSTIX_PINTO:
printf("Recognized Pinto expansion board (rev %d %s)\n",
@@ -310,6 +314,7 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "gallop43");
break;
case GUMSTIX_ALTO35:
printf("Recognized Alto35 expansion board (rev %d %s)\n",
@@ -317,6 +322,7 @@ int misc_init_r(void)
expansion_config.fab_revision);
MUX_ALTO35();
setenv("defaultdisplay", "lcd35");
+ setenv("expansionname", "alto35");
break;
case GUMSTIX_STAGECOACH:
printf("Recognized Stagecoach expansion board (rev %d %s)\n",
@@ -349,8 +355,11 @@ int misc_init_r(void)
break;
case GUMSTIX_NO_EEPROM:
puts("No EEPROM on expansion board\n");
+ setenv("expansionname", "tobi");
break;
default:
+ if (expansion_id == 0x0)
+ setenv("expansionname", "tobi");
printf("Unrecognized expansion board 0x%08x\n", expansion_id);
break;
}
@@ -360,6 +369,11 @@ int misc_init_r(void)
dieid_num_r();
+ if (get_cpu_family() == CPU_OMAP34XX)
+ setenv("boardname", "overo");
+ else
+ setenv("boardname", "overo-storm");
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 1a13633..f7483a0 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -83,7 +83,6 @@
/* Environment information */
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
- "fdtfile=overo.dtb\0" \
"bootdir=/boot\0" \
"bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
@@ -152,10 +151,11 @@
"run mmcboot;" \
"fi;" \
"if run loadzimage; then " \
- "if test -n $fdtfile; then " \
- "if run loadfdt; then " \
- "run mmcbootfdt;" \
- "fi;" \
+ "if test $fdtfile; then " \
+ "setenv fdtfile
omap3-${boardname}-${expansionname}.dtb;" \
+ "fi;" \
+ "if run loadfdt; then " \
+ "run mmcbootfdt;" \
"fi;" \
"fi;" \
"fi;" \
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] omap3: overo: Select fdtfile for expansion board
Am 10.06.2014 21:02, schrieb Ash Charles:
The u-boot Overo board actually supports both Overo (OMAP35xx)
and Overo Storm (AM/DM37xx) COMs with a range of different expansion
boards. This provides a mechanism to select the an appropriate device
tree file based on the processor version and, if available, the
expansion board ID written on the expansion board EEPROM. To match the
3.15+ kernels, fdtfile names have this format:
"omap3-overo[-storm]-.dtb"
By default, we use "omap3-overo-storm-tobi.dtb".
Signed-off-by: Ash Charles
Conflicts:
include/configs/omap3_overo.h
---
board/overo/overo.c | 14 ++
include/configs/omap3_overo.h | 10 +-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/board/overo/overo.c b/board/overo/overo.c
index 62b50a8..13220c5 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -267,12 +267,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "summit");
break;
case GUMSTIX_TOBI:
printf("Recognized Tobi expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "dvi");
+ setenv("expansionname", "tobi");
break;
case GUMSTIX_TOBI_DUO:
printf("Recognized Tobi Duo expansion board (rev %d %s)\n",
@@ -293,12 +295,14 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "palo43");
break;
case GUMSTIX_CHESTNUT43:
printf("Recognized Chestnut43 expansion board (rev %d %s)\n",
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "chestnut43");
break;
case GUMSTIX_PINTO:
printf("Recognized Pinto expansion board (rev %d %s)\n",
@@ -310,6 +314,7 @@ int misc_init_r(void)
expansion_config.revision,
expansion_config.fab_revision);
setenv("defaultdisplay", "lcd43");
+ setenv("expansionname", "gallop43");
break;
case GUMSTIX_ALTO35:
printf("Recognized Alto35 expansion board (rev %d %s)\n",
@@ -317,6 +322,7 @@ int misc_init_r(void)
expansion_config.fab_revision);
MUX_ALTO35();
setenv("defaultdisplay", "lcd35");
+ setenv("expansionname", "alto35");
break;
case GUMSTIX_STAGECOACH:
printf("Recognized Stagecoach expansion board (rev %d %s)\n",
@@ -349,8 +355,11 @@ int misc_init_r(void)
break;
case GUMSTIX_NO_EEPROM:
puts("No EEPROM on expansion board\n");
+ setenv("expansionname", "tobi");
break;
default:
+ if (expansion_id == 0x0)
+ setenv("expansionname", "tobi");
You should add an additional case (0x0) above GUMSTIX_NO_EEPROM but an
un-programmed eeprom returns GUMSTIX_NO_EEPROM (0x).
printf("Unrecognized expansion board 0x%08x\n", expansion_id);
break;
}
@@ -360,6 +369,11 @@ int misc_init_r(void)
dieid_num_r();
+ if (get_cpu_family() == CPU_OMAP34XX)
+ setenv("boardname", "overo");
+ else
+ setenv("boardname", "overo-storm");
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 1a13633..f7483a0 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -83,7 +83,6 @@
/* Environment information */
#define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
- "fdtfile=overo.dtb\0" \
"bootdir=/boot\0" \
"bootfile=zImage\0" \
"usbtty=cdc_acm\0" \
@@ -152,10 +151,11 @@
"run mmcboot;" \
"fi;" \
"if run loadzimage; then " \
- "if test -n $fdtfile; then " \
- "if run loadfdt; then " \
- "run mmcbootfdt;" \
- "fi;" \
+ "if test $fdtfile; then " \
+ "setenv fdtfile
omap3-${boardname}-${expansionname}.dtb;" \
+ "fi;" \
+ "if run loadfdt; then " \
+ "run mmcbootfdt;" \
"fi;" \
"fi;" \
"f
Re: [U-Boot] [PATCH 1/2] usb: ci_udc: allow multiple buffer allocs per ep
On 06/02/2014 05:02 PM, Jörg Krause wrote: > Sorry, my previous post was not shown correctly. The raw text was missing. I > removed the annotation. > > Since this commit my Ethernet Gadget on a custom Freescale i.MX28 board is > broken. Using tftp to download files I get in almost all cases a timeout: Sorry for the slow response; for some reason I didn't get a copy of the message so I didn't notice it. Could you tell me which include/config/xxx.h file you're using? I guess if it's a custom board, perhaps that file isn't upstream. If so, I'm particularly interested in whether you have CONFIG_USB_GADGET or CONFIG_USB_ETHER enabled. I wonder if applying the following series rather than reverting this commits solves the issue? [U-Boot,1/4] usb: ci_udc: detect queued requests on ep0 http://patchwork.ozlabs.org/patch/353926/ [U-Boot,2/4] usb: ci_udc: use a single descriptor for ep0 http://patchwork.ozlabs.org/patch/353932/ [U-Boot,3/4] usb: ci_udc: pre-allocate ep0 req http://patchwork.ozlabs.org/patch/353931/ [U-Boot,4/4] usb: ci_udc: complete ep0 direction handling http://patchwork.ozlabs.org/patch/353941/ The only other thing I can think of is that there's some issue with the bounce buffer alignment or size being wrong somehow. Perhaps try increasing those? Or, perhaps req->actual ends up being wrong, so ci_debounce() isn't cache-invalidating or copying enough data? Perhaps try rounding up req->len instead of req->actual when performing the cache invalidate? > This is one case: > > Updating rootfs ... > using ci_udc, OUT ep- IN ep- STATUS ep- > MAC 00:19:b8:00:00:02 > HOST MAC 00:19:b8:00:00:01 > high speed config #1: 2 mA, Ethernet Gadget, using CDC Ethernet > USB network up! > Using usb_ether device > TFTP from server 10.0.0.1; our IP address is 10.0.0.2 > Filename 'rootfs.ubifs'. > Load address: 0x40008000 > Loading: ###timeout sending packets to usb ethernet I'm slightly confused by this log. Do you have 2 boards running U-Boot, one running the USB controller in device mode, and this is the log from some other board that's talking to that first board? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
On 14-06-10 11:13 AM, Wolfgang Denk wrote: Dear Steve, In message <539746c4.9040...@broadcom.com> you wrote: There could be "many" reasons why the CONFIG_SYS_TEXT_BASE is not aligned on a 0x1000 byte boundary (Darwin has attempted to document his particular use-case...) We should be more precise here and ask for any _good_ reasons. I can think of many good reasons to keep the text base aligned. As for the reasons to use an unaligned address that were brought up here, I still think that it would have been better to use an aligned taxe base and do the rest with a customized linker script. But we think that the solution to support this is relatively straightforward: (1) after determining the "relocation address" (which will be on a 0x1000 byte boundary), (2) add "CONFIG_SYS_TEXT_BASE % 4096" to that "relocation address" (which effectively makes the "relocation offset" a multiple of 0x1000 too...) So, in the scenario #1, (CONFIG_SYS_TEXT_BASE % 4096) = 0, so this algorithm changes nothing. And in scenario #2, (CONFIG_SYS_TEXT_BASE % 4096) = 0x20, therefore, we would now get the following: the relocation offset is: 0x77f9b000 therefore, after relocation: _start symbol is at0xfff9b020 (0x8820+0x77f9b000) vectors symbol is at0xfff9b800 (0x88000800+0x77f9b000) I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would have to be the same. There is no such requirement. What exactly prevents you from assigning _start a location at offset 0x20 to the start of the text segment, i. e. CONFIG_SYS_TEXT_BASE ? Wolfgang et al. I agree that they do not need to be the same... So our issue is that basically "for every ARMv7 board in the company", we are currently maintaining our own modified/customized version of "arch/arm/cpu/armv7/start.S" in order to add the appropriate 32 byte header... And we could choose to do it using other methods, but they all require us to maintain a customized version of linker scripts, or some other code, or The request here is that with the addition of some relatively straightforward (upstreamed) code, then this can be handled automatically by a post-processing step and we would be able to use a pristine version of the upstreamed code... Our desire is to get this into the beginnings of the "ARMv8" boards, so that we can avoid the maintenance issues we have with the current ARMv7 boards. We appreciate your consideration of this request. Thanks, Steve Then everything should be still the same for you, and no voodoo coding would be needed. (3) HOWEVER, shifting the address UP may cause the end of the relocated code to run past the end of the available memory... So we could: This problem is void if you just use a poperly aligned text base in combination with a prope start.S resp. linker script to make sure _start is where you want it. I trust that everyone will find this explanation acceptable... No, I do not see a good reason to add such code. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] board: ti: am43xx: add AM437x SK PHY Address
Hi Felipe,
On Jun 10, 2014 11:45 AM, "Felipe Balbi" wrote:
>
> pass correct PHY Address when running on SK
> so that we have working ethernet with this board
> too.
>
> Signed-off-by: Felipe Balbi
> ---
> board/ti/am43xx/board.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index b184c20..054a452 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -227,16 +227,16 @@ static const struct emif_regs
ddr3_sk_emif_regs_400Mhz = {
> .read_idle_ctrl = 0x0005,
> .zq_config = 0x50074be4,
> .temp_alert_config = 0x0,
> - .emif_ddr_phy_ctlr_1= 0x0e084007,
> + .emif_ddr_phy_ctlr_1= 0x0e084008,
> .emif_ddr_ext_phy_ctrl_1= 0x08020080,
> - .emif_ddr_ext_phy_ctrl_2= 0x00700070,
> - .emif_ddr_ext_phy_ctrl_3= 0x00700070,
> - .emif_ddr_ext_phy_ctrl_4= 0x00700070,
> - .emif_ddr_ext_phy_ctrl_5= 0x00700070,
> + .emif_ddr_ext_phy_ctrl_2= 0x89,
> + .emif_ddr_ext_phy_ctrl_3= 0x90,
> + .emif_ddr_ext_phy_ctrl_4= 0x8e,
> + .emif_ddr_ext_phy_ctrl_5= 0x8d,
> .emif_rd_wr_lvl_rmp_win = 0x0,
> - .emif_rd_wr_lvl_rmp_ctl = 0x0,
> - .emif_rd_wr_lvl_ctl = 0x0,
> - .emif_rd_wr_exec_thresh = 0x0405
> + .emif_rd_wr_lvl_rmp_ctl = 0x,
> + .emif_rd_wr_lvl_ctl = 0x,
> + .emif_rd_wr_exec_thresh = 0x,
> };
Merge this hunk with the previous patch in the series?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] board: ti: am43xx: add AM437x SK PHY Address
Hi,
On Tue, Jun 10, 2014 at 12:39:08PM -0700, Vaibhav Bedia wrote:
> Hi Felipe,
>
> On Jun 10, 2014 11:45 AM, "Felipe Balbi" wrote:
> >
> > pass correct PHY Address when running on SK
> > so that we have working ethernet with this board
> > too.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > board/ti/am43xx/board.c | 21 +
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> > index b184c20..054a452 100644
> > --- a/board/ti/am43xx/board.c
> > +++ b/board/ti/am43xx/board.c
> > @@ -227,16 +227,16 @@ static const struct emif_regs
> ddr3_sk_emif_regs_400Mhz = {
> > .read_idle_ctrl = 0x0005,
> > .zq_config = 0x50074be4,
> > .temp_alert_config = 0x0,
> > - .emif_ddr_phy_ctlr_1= 0x0e084007,
> > + .emif_ddr_phy_ctlr_1= 0x0e084008,
> > .emif_ddr_ext_phy_ctrl_1= 0x08020080,
> > - .emif_ddr_ext_phy_ctrl_2= 0x00700070,
> > - .emif_ddr_ext_phy_ctrl_3= 0x00700070,
> > - .emif_ddr_ext_phy_ctrl_4= 0x00700070,
> > - .emif_ddr_ext_phy_ctrl_5= 0x00700070,
> > + .emif_ddr_ext_phy_ctrl_2= 0x89,
> > + .emif_ddr_ext_phy_ctrl_3= 0x90,
> > + .emif_ddr_ext_phy_ctrl_4= 0x8e,
> > + .emif_ddr_ext_phy_ctrl_5= 0x8d,
> > .emif_rd_wr_lvl_rmp_win = 0x0,
> > - .emif_rd_wr_lvl_rmp_ctl = 0x0,
> > - .emif_rd_wr_lvl_ctl = 0x0,
> > - .emif_rd_wr_exec_thresh = 0x0405
> > + .emif_rd_wr_lvl_rmp_ctl = 0x,
> > + .emif_rd_wr_lvl_ctl = 0x,
> > + .emif_rd_wr_exec_thresh = 0x,
> > };
>
> Merge this hunk with the previous patch in the series?
oops :-) bad rebase, I guess.
--
balbi
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] Add support for AM43xx Starter Kit
Hi, patches were tested on AM43xx SK on top of v2014.07-rc3 Changes since v1: - fix a bad rebase pointed to by Vaibhav. Felipe Balbi (5): board: ti: am43xx: print unsupported board name cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register board: ti: am43xx: add support for AM43xx Starter Kit board: ti: am43xx: add AM437x SK PHY Address board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK arch/arm/cpu/armv7/am33xx/ddr.c | 1 + board/ti/am43xx/board.c | 79 +++-- board/ti/am43xx/board.h | 5 +++ board/ti/am43xx/mux.c | 3 ++ include/configs/am43xx_evm.h| 2 ++ 5 files changed, 88 insertions(+), 2 deletions(-) -- 2.0.0.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] board: ti: am43xx: print unsupported board name
when porting u-boot to a new am43xx board, it
helps to know the name of the current unsupported
board so we don't have to hunt for design documents
to figure out what's written in the EEPROM.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 71af1ae..6197076 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -260,7 +260,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
else if (board_is_gpevm())
return &gp_evm_dpll_ddr;
- puts(" Board not supported\n");
+ printf(" Board '%s' not supported\n", am43xx_board_name);
return NULL;
}
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] cpu: armv7: am33x: ddr: write emif ref_ctrl_shadow register
Signed-off-by: Felipe Balbi --- arch/arm/cpu/armv7/am33xx/ddr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c index 9a625c4..bbe9d1a 100644 --- a/arch/arm/cpu/armv7/am33xx/ddr.c +++ b/arch/arm/cpu/armv7/am33xx/ddr.c @@ -95,6 +95,7 @@ void config_sdram_emif4d5(const struct emif_regs *regs, int nr) &emif_reg[nr]->emif_rd_wr_exec_thresh); writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl); + writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl_shdw); writel(regs->sdram_config, &emif_reg[nr]->emif_sdram_config); writel(regs->sdram_config, &cstat->secure_emif_sdram_config); -- 2.0.0.rc1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] board: ti: am43xx: add AM437x SK PHY Address
pass correct PHY Address when running on SK
so that we have working ethernet with this board
too.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 6379cef..054a452 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -594,6 +594,11 @@ int board_eth_init(bd_t *bis)
writel(RMII_MODE_ENABLE | RMII_CHIPCKL_ENABLE, &cdev->miisel);
cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RMII;
cpsw_slaves[0].phy_addr = 16;
+ } else if (board_is_sk()) {
+ writel(RGMII_MODE_ENABLE, &cdev->miisel);
+ cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
+ cpsw_slaves[0].phy_addr = 4;
+ cpsw_slaves[1].phy_addr = 5;
} else {
writel(RGMII_MODE_ENABLE, &cdev->miisel);
cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RGMII;
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] board: ti: am43xx: add support for AM43xx Starter Kit
AM43xx Starter Kit is a new board based on
AM437x line of SoCs. Being a low-cost EVM and
small size EVM are intended to provide an entry
level development platform on a full fledged
Hardware System.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/board.c | 72 +++-
board/ti/am43xx/board.h | 5 +++
include/configs/am43xx_evm.h | 2 ++
3 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 6197076..6379cef 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -217,6 +217,28 @@ const struct emif_regs ddr3_emif_regs_400Mhz = {
.emif_rd_wr_exec_thresh = 0x0405
};
+static const struct emif_regs ddr3_sk_emif_regs_400Mhz = {
+ .sdram_config = 0x638413b2,
+ .sdram_config2 = 0x,
+ .ref_ctrl = 0x0c30,
+ .sdram_tim1 = 0xeaaad4db,
+ .sdram_tim2 = 0x266b7fda,
+ .sdram_tim3 = 0x107f8678,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x50074be4,
+ .temp_alert_config = 0x0,
+ .emif_ddr_phy_ctlr_1= 0x0e084008,
+ .emif_ddr_ext_phy_ctrl_1= 0x08020080,
+ .emif_ddr_ext_phy_ctrl_2= 0x89,
+ .emif_ddr_ext_phy_ctrl_3= 0x90,
+ .emif_ddr_ext_phy_ctrl_4= 0x8e,
+ .emif_ddr_ext_phy_ctrl_5= 0x8d,
+ .emif_rd_wr_lvl_rmp_win = 0x0,
+ .emif_rd_wr_lvl_rmp_ctl = 0x,
+ .emif_rd_wr_lvl_ctl = 0x,
+ .emif_rd_wr_exec_thresh = 0x,
+};
+
const u32 ext_phy_ctrl_const_base_ddr3[] = {
0x00400040,
0x00350035,
@@ -240,6 +262,48 @@ const u32 ext_phy_ctrl_const_base_ddr3[] = {
0x08102040
};
+static const u32 ext_phy_ctrl_const_base_ddr3_sk[] = {
+ /* first 5 are taken care by emif_regs */
+ 0x00700070,
+
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+ 0x00350035,
+
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+ 0x00150015,
+
+ 0x00800080,
+ 0x00800080,
+
+ 0x4000,
+
+ 0x08102040,
+
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+ 0x,
+};
+
void emif_get_ext_phy_ctrl_const_regs(const u32 **regs, u32 *size)
{
if (board_is_eposevm()) {
@@ -248,6 +312,9 @@ void emif_get_ext_phy_ctrl_const_regs(const u32 **regs, u32
*size)
} else if (board_is_gpevm()) {
*regs = ext_phy_ctrl_const_base_ddr3;
*size = ARRAY_SIZE(ext_phy_ctrl_const_base_ddr3);
+ } else if (board_is_sk()) {
+ *regs = ext_phy_ctrl_const_base_ddr3_sk;
+ *size = ARRAY_SIZE(ext_phy_ctrl_const_base_ddr3_sk);
}
return;
@@ -257,7 +324,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
{
if (board_is_eposevm())
return &epos_evm_dpll_ddr;
- else if (board_is_gpevm())
+ else if (board_is_gpevm() || board_is_sk())
return &gp_evm_dpll_ddr;
printf(" Board '%s' not supported\n", am43xx_board_name);
@@ -410,6 +477,9 @@ void sdram_init(void)
enable_vtt_regulator();
config_ddr(0, &ioregs_ddr3, NULL, NULL,
&ddr3_emif_regs_400Mhz, 0);
+ } else if (board_is_sk()) {
+ config_ddr(400, &ioregs_ddr3, NULL, NULL,
+ &ddr3_sk_emif_regs_400Mhz, 0);
}
}
#endif
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
index 091162e..017047d 100644
--- a/board/ti/am43xx/board.h
+++ b/board/ti/am43xx/board.h
@@ -47,6 +47,11 @@ static inline int board_is_gpevm(void)
return !strncmp(am43xx_board_name, "AM43__GP", HDR_NAME_LEN);
}
+static inline int board_is_sk(void)
+{
+ return !strncmp(am43xx_board_name, "AM43__SK", HDR_NAME_LEN);
+}
+
void enable_uart0_pin_mux(void);
void enable_board_pin_mux(void);
void enable_i2c0_pin_mux(void);
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 823cba6..974ce98 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -226,6 +226,8 @@
"setenv fdtfile am43x-epos-evm.dtb; fi; " \
"if test $board_name = AM43__GP; then " \
"setenv fdtfile am437x-gp-evm.dtb; fi; " \
+ "if test $board_name = AM43__SK; then " \
+ "setenv fdtfile am437x-sk-evm.dtb; fi; " \
"if test $fdtfil
[U-Boot] [PATCH v2 5/5] board: ti: am43xx: enable QSPI and Gbit Ethernet on AM437x SK
AM437x Starter Kit has a qspi flash and gbit ethernet
support. By muxing those signals, we can use those
interfaces from u-boot.
Signed-off-by: Felipe Balbi
---
board/ti/am43xx/mux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 77c53d2..50967e1 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -97,6 +97,9 @@ void enable_board_pin_mux(void)
if (board_is_gpevm()) {
configure_module_pin_mux(gpio5_7_pin_mux);
configure_module_pin_mux(rgmii1_pin_mux);
+ } else if (board_is_sk()) {
+ configure_module_pin_mux(rgmii1_pin_mux);
+ configure_module_pin_mux(qspi_pin_mux);
} else if (board_is_eposevm()) {
configure_module_pin_mux(rmii1_pin_mux);
configure_module_pin_mux(qspi_pin_mux);
--
2.0.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v3] omap3: overo: Select fdtfile for expansion board
On Tue, Jun 10, 2014 at 12:29 PM, Stefan Herbrechtsmeier wrote: > You should add an additional case (0x0) above GUMSTIX_NO_EEPROM but an > un-programmed eeprom returns GUMSTIX_NO_EEPROM (0x). Forgive my stupidity---I don't follow. Either, 1. No eeprom is probed or expansion_id is 0x (blank)--->this gets caught by the GUMSTIX_NO_EEPROM case, or 2. An eeprom written with all zeros is read--->this gets caught by the if statement nested in the default case. Thanks for your patience in trying to find a change that works generally. --Ash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
Dear Steve, In message <53975ec2.1080...@broadcom.com> you wrote: > > > I still cannot understand why _start and CONFIG_SYS_TEXT_BASE would > > have to be the same. There is no such requirement. What exactly > > prevents you from assigning _start a location at offset 0x20 to the > > start of the text segment, i. e. CONFIG_SYS_TEXT_BASE ? > > Wolfgang et al. > > I agree that they do not need to be the same... > So our issue is that basically "for every ARMv7 board in the company", > we are currently maintaining our own modified/customized version of > "arch/arm/cpu/armv7/start.S" in order to add the appropriate 32 byte > header... There should be more clever ways to implement this. If nothing else comes to mind, an #ifdef in "arch/arm/cpu/armv7/start.S" should be sufficient to condistionally insert / adjust any offset that might be needed for a specific board. > And we could choose to do it using other methods, but they all require > us to maintain a customized version of linker scripts, or some other > code, or ... or a CONFIG setting in your board config file resp. your board's defconfig. > The request here is that with the addition of some relatively > straightforward (upstreamed) code, then this can be handled > automatically by a post-processing step and we would be able to use a > pristine version of the upstreamed code... I'm sorry, but I disagree especially on the "straightforward" part. Also, I see no reason to make the existing code unnecessarily complex, and add more disadvantages (like increased meory footprint etc.) when the same purpose can be implemented without adding any special code at all. > Our desire is to get this into the beginnings of the "ARMv8" boards, so > that we can avoid the maintenance issues we have with the current ARMv7 > boards. > > We appreciate your consideration of this request. These are two different things: implementing a clean and easy way to support a necessary feature is one thing; to do it in the suggested way by adding code where none is needed is another thing. I'm all for adding support for any features that are useful, even if only for a single user, as long as they don't hurt other users. All I'm asking is to chose another way to implement this feature. So far, I did not see any arguments that my alternative proposals would cause any problems to you? 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 It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Proposal to change include search model
On di, 2014-06-10 at 18:53 +0300, Vasili Galka wrote:
> Hi,
>
> Currently U-Boot has a long list of include search paths. This makes
> it hard to understand the location of each header. Moreover, it opens
> an easy opportunity for breaking build by including the wrong header.
> This is especially easy when compiling the tools directory. I found
> numerous commits dealing with such problems over the years.
>
> What I propose is changing the way of how #include directives are
> written. For example instead of:
>
> #include /* From toolchain */
> #include /* include/api_public.h */
> #include /* include/linux/mii.h */
> #include /* Auto-generated somewhere */
> #include/* Auto-generated somewhere */
> #include /* arch/arc/include/asm/arcregs.h */
> #include /* arch/arm/include/asm/
> arch-davinci/emac_defs.h */
> #include "../../../../../drivers/net/davinci_emac.h"
>
> and let the developer guess the locations... I propose writing:
>
> #include /* <> means from toolchain */
> #include "inc/api_public.h" /* From u-boot/include/ dir */
> #include "inc/linux/mii.h"
> #include "config/config.h" /* From dedicated config dir */
> #include "generated/bmp_logo.h"
> #include "arch/asm/arcregs.h" /* From configured architecture */
> #include "soc/emac_defs.h" /* From configured SoC */
> #include "u-boot/drivers/net/davinci_emac.h"
>
> This way the developer will instantly know the exact header locations.
> Moreover, the chance for ambiguities is very small which makes build
> breakages less likely.
>
> The proposal may seem strange to you at first, as most of you are
> probably used to a different approach. But please consider its
> advantages. I've been working on projects that used similar scheme
> and it significantly simplifies the developer life.
>
> The above can be implemented by creating
> inc/ arch/ soc/ u-boot/
> filesystem links in ${objtree}/include. Then, the only compiler flag
> required will be "-iquote ${objtree}/include". No ugly -idirafter flags,
> no long search list. Keep it simple.
>
> I'll be glad for your opinions!
>
This sounds way too complex if you ask me for what your are trying to
fix. For one thing #include<> versus include "" is compiler specific and
not defined in general. If I find some time I will see if I can find
another solution for it. But you're warned heads up that it might
include one additional -I for standard c libraries for the target (which
is only errno.h at the moment, afaik) ;)
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tps6586x.h: fix inclusion guard
cc: Simon Glass
Signed-off-by: Jeroen Hofstee
---
include/tps6586x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/tps6586x.h b/include/tps6586x.h
index 10ca103..78ce428 100644
--- a/include/tps6586x.h
+++ b/include/tps6586x.h
@@ -5,7 +5,7 @@
* SPDX-License-Identifier:GPL-2.0+
*/
-#ifndef __H_
+#ifndef _TPS6586X_H_
#define _TPS6586X_H_
enum {
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
