On Thu, Apr 10, 2014 at 7:41 AM, Nikita Kiryanov wrote:
> On 04/09/2014 06:40 PM, Tim Harvey wrote:
>>
>> On Wed, Apr 9, 2014 at 7:56 AM, Nikita Kiryanov
>> wrote:
>>>
>>> Hi Tim,
>>>
>>>
>>> On 04/03/2014 09:01 AM, Tim Harvey wrote:
Add new function that can take an array of iomux
The LTC3676 PMIC includes four DC/DC converters, and three 300mA
LDO Regulators (two Adjustable). The DC/DC converters are adjustable based
on a resistor devider (board-specific).
This adds support for the LTC3676 by creating a namespace unique init function
that uses the PMIC API to allocate a pm
Signed-off-by: Tim Harvey
---
board/gateworks/gw_ventana/gw_ventana.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/gateworks/gw_ventana/gw_ventana.c
b/board/gateworks/gw_ventana/gw_ventana.c
index c130e2c..48e90e0 100644
--- a/board/gateworks/gw_ventana/gw_venta
Avoid uding pmic_init() as this forces the model of only allowing a
single PMIC driver to be built at a time.
Signed-off-by: Tim Harvey
---
drivers/power/pmic/pmic_pfuze100.c | 2 +-
include/power/pfuze100_pmic.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/p
The Gateworks Ventana boards share much in common, but there are two differing
PMIC's used on them. This patch series adds a new PMIC driver for the LTC3676
and supports them both within the common board support file.
Signed-off-By: Tim Harvey
Tim Harvey (4):
power: make pfuze100 be able to co
The LTC3676 PMIC is used instead of the PFUZE100 PMIC on the
GW51xx/GW52xx/GW53xx Ventana baseboards. In order to support the IMX6Q SoC
at 1GHz on those baseboards, we need to adjust the voltage scaling for the SW1
and SW3 DC/DC converters on the LTC3676 for 1225mV. Note that the scalar
values for
On 4/23/2014 1:01 AM, Scott Wood wrote:
On Mon, 2014-04-21 at 10:46 +0530, Prabhakar Kushwaha wrote:
qe_init() does not use data copied from NAND. Thise code is not tested or
complied causing compilation error during NAND boot
So, remove QE firmware copy from NAND to ddr.
Signed-off-by: Prabh
From: Stephen Warren
This re-imports the entire Venice2 pinmux data from the board's master
spreadsheet, and makes use of the new IO clamping GPIO initialization
table features. This makes the board port fully compliant with the
required HW-defined pinmux initialization sequence.
Signed-off-by:
From: Stephen Warren
Define enum PMUX_FUNC_DEFAULT, which indicates that a table entry passed
to pinmux_config_pingrp()/pinmux_config_pingrp_table() shouldn't change
the mux option in HW.
For pins that will be used as GPIOs, the mux option is irrelevant, so we
simply don't want to define any mux
From: Stephen Warren
The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Modify the Jetson TK1 board to do this.
Signed-off-by: Stephen Warren
---
board/nvidia/jetson-tk1/jetson-tk1.c | 2 ++
1 file changed, 2 insertion
From: Stephen Warren
The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. Add a feature to the GPIO driver
which executes a GPIO configuration table. Board files will use
From: Stephen Warren
The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. This patch implements this
procedure for Jetson TK1. For pins which are to be used as GPIOs, the
From: Stephen Warren
The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Add a function to the pinmux driver to allow boards to do this.
Signed-off-by: Stephen Warren
---
arch/arm/cpu/tegra-common/pinmux-common.c | 16 +
On Mon, 2014-04-21 at 10:46 +0530, Prabhakar Kushwaha wrote:
> qe_init() does not use data copied from NAND. Thise code is not tested or
> complied causing compilation error during NAND boot
>
> So, remove QE firmware copy from NAND to ddr.
>
> Signed-off-by: Prabhakar Kushwaha
Where does the Q
On Tue, 2014-04-22 at 10:04 +0900, Masahiro Yamada wrote:
> Hi Scott,
>
>
> > > It is really really painful to wait more than 10 seconds just for bad
> > > block
> > > scanning to boot Linux.
> >
> > Making bad block scans faster is a good thing, but why do you need to
> > scan them just to boo
On 22 April 2014 12:45, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
> ---
> doc/README.generic-board | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/README.generic-board b/doc/README.generic-board
> index 50d3a26..17da0b9 100644
> --- a/doc/README.generic-boa
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Enable CONFIG_SYS_GENERIC_BOARD, so that we get rid of the following warning on
boot:
"Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be remove
Signed-off-by: Fabio Estevam
---
doc/README.generic-board | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/README.generic-board b/doc/README.generic-board
index 50d3a26..17da0b9 100644
--- a/doc/README.generic-board
+++ b/doc/README.generic-board
@@ -17,7 +17,7 @@ architect
Dear Pierre Aubert,
In message <1398182087-14913-4-git-send-email-p.aub...@staubli.com> you wrote:
> This sub-command adds support for the RPMB partition of an eMMC:
> * mmc rpmb key
> Programs the authentication key in the eMMC This key can not
> be overwritten.
> * mmc rpmb read <#count>
Dear Pierre,
In message <5350c8bc.9000...@staubli.com> you wrote:
>
> > I think that now, with more subcommands being added, we should
> > convert the mmc code to proper subcommand handling. [It might even
> > make sense to do so for "mmc rpmb", too.]
> Do you think about the use of the macro U_B
On 04/21/2014 05:31 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 18 April 2014 11:15, Stephen Warren wrote:
>>
>> From: Stephen Warren
>>
>> When both CONFIG_API and CONFIG_LCD are enabled, the API code calls
>> lcd_display_bitmap(). That isn't compiled unless either CONFIG_CMD_BMP
>> or CONFIG_S
User's confirmation is asked in different commands. This commit adds a
function for such confirmation.
Signed-off-by: Pierre Aubert
---
common/cmd_fuse.c | 11 ++-
common/cmd_nand.c | 16 +---
common/cmd_otp.c | 18 +++---
common/console.c | 28 +
This patch adds functions for read, write and authentication
key programming for the Replay Protected Memory Block partition
in the eMMC.
Signed-off-by: Pierre Aubert
CC: Pantelis Antoniou
---
drivers/mmc/Makefile |1 +
drivers/mmc/rpmb.c | 323 +++
This sub-command adds support for the RPMB partition of an eMMC:
* mmc rpmb key
Programs the authentication key in the eMMC This key can not
be overwritten.
* mmc rpmb read <#count> [address of key]
Reads <#count> blocks of 256 bytes in the RPMB partition
beginning at block number . If t
This serie of patches adds some functions and a sub-command of 'mmc' for
programming the authentication key and for reading and writing the RPMB
partition of an eMMC according to the JEDEC standard No. 64-A441
The sub-command rpmb is enabled by the flag CONFIG_SUPPORT_EMMC_RPMB defined
in the b
On 04/22/2014 03:43 AM, Masahiro Yamada wrote:
> This commit modifies mkconfig not to define CONFIG_SYS_ARCH,
> CONFIG_SYS_CPU, CONFIG_SYS_SOC, CONFIG_SYS_VENDOR, CONFIG_SYS_BOARD.
>
> They are still used in some board files.
> Tegra family, OMAP-Panda board, some Samsung boards.
>
> Add CONFIG_S
On Fri, Apr 18, 2014 at 11:25:23AM +0200, Michael Trimarchi wrote:
> Hi Tom
>
> On Thu, Jan 30, 2014 at 10:31 PM, Tom Rini wrote:
> > Add a bootbus sub-command to the mmc command to allow for setting
> > the boot_bus_width, reset_boot_bus_width and boot_mode fields of
> > BOOT_BUS_WIDTH (EXT_CSD
On 04/22/2014 03:43 AM, Masahiro Yamada wrote:
> Drop CONFIG_SYS_ARCH and CONFIG_SYS_SOC from the code.
This seems like something that will be annoying to people who rely on
this behaviour; the patch removes functionality for no purpose.
___
U-Boot maili
On Fri, Apr 18, 2014 at 12:26:21AM +0530, RAGHAVENDRA GANIGA wrote:
> I am writing the support for rtc ds1347
>
> my driver file resides in drivers/rtc/ds1347.c
>
> who is the custodian for the rtc subsystem of uboot
> or just i have to mail patch to u-boot@lists.denx.de
I haven't picked it up
On Thu, Apr 17, 2014 at 09:44:06PM +0200, Daniel Schwierzeck wrote:
> Hi Tom,
>
> 2014-04-07 17:41 GMT+02:00 Paul Burton :
> > This series fixes issues with the pcnet driver & its memory accesses.
> >
> > Previously the network interface on the MIPS Malta board was unreliable
> > & would often tim
Hi Andy,
On 14.04.2014 13:32, Andy Pont wrote:
I am looking at porting U-Boot to a board that is being designed with a
Micron PC28D00AP30 NOR flash device and can't work out whether this is
something that is already supported by U-Boot or whether it is work that I
will need to undertake.
I have
On Tue, Apr 22, 2014 at 4:43 AM, Masahiro Yamada
wrote:
> Drop CONFIG_SYS_ARCH and CONFIG_SYS_SOC from the code.
That is clear from the diff, but you are not stating why you need this change.
Rob
>
> Signed-off-by: Masahiro Yamada
> Cc: Rob Herring
> Cc: Stephen Warren
> ---
>
> common/cmd_
Dear Masahiro,
In message <1398159826-29398-2-git-send-email-yamad...@jp.panasonic.com> you
wrote:
> CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment
> variables, "arch", "cpu", "board", etc. depending on
> CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively.
>
> We are dis
Dear Albert,
In message you wrote:
>
> Also, I don't think we need a *centralized* source of information.
> I think we need a source of information which requires minimal effort
> when adding or removing a board (or SoC, or...). Therefore, I'm fine
> with a board-specific file (defconfig or othe
Dear Masahiro,
In message <20140422163032.3ae3.aa925...@jp.panasonic.com> you wrote:
>
> I did this (CONFIG_BOARD_MAINTAINER) in my RFC
> http://patchwork.ozlabs.org/patch/330915/
> (but user-editable)
>
> I think everyone was opposed to my idea
> and we chose to add MAINTAINERS file.
Well, spe
From: Shaohui Xie
Current driver uses a Maximum value for MDIO_HOLD when doing 10G MDIO
access, this is due to an errata A-006260 on T4 rev1.0 which is fixed
on rev2.0, so remove the maximum value to use the default value for rev2.0.
Signed-off-by: Shaohui Xie
---
drivers/net/fm/memac_phy.c |
Secure Boot Target is added for T2080RDB
Changes:
For Secure boot, CPC is configured as SRAM and used as house
keeping area which needs to be disabled.
So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T2080RDB.
Signed-off-by: Aneesh Bansal
---
arch/powerpc/include/asm/fsl_secure_boot.h | 1 +
b
T1040RDB.h file is removed and a unified file T104xRDB.h is created.
Hence macro CONFIG_T1040 is renamed to CONFIG_T104x.
Signed-off-by: Gaurav Kumar Rana
Signed-off-by: Aneesh Bansal
---
arch/powerpc/include/asm/fsl_secure_boot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Drop CONFIG_SYS_ARCH and CONFIG_SYS_SOC from the code.
Signed-off-by: Masahiro Yamada
Cc: Rob Herring
Cc: Stephen Warren
---
common/cmd_pxe.c | 4
1 file changed, 4 deletions(-)
diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 3483328..4b4a954 100644
--- a/common/cmd_pxe.c
+++ b/c
This commit modifies mkconfig not to define CONFIG_SYS_ARCH,
CONFIG_SYS_CPU, CONFIG_SYS_SOC, CONFIG_SYS_VENDOR, CONFIG_SYS_BOARD.
They are still used in some board files.
Tegra family, OMAP-Panda board, some Samsung boards.
Add CONFIG_SYS_SOC, CONFIG_SYS_BOARD definition to their header files
to
CONFIG_ENV_VARS_UBOOT_CONFIG, if defined, sets environment
variables, "arch", "cpu", "board", etc. depending on
CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_BOARD, respectively.
We are discussing the introduction of Kconfig.
In our discussion, we found boolean CONFIG macros are more useful
in Kconf
When I posted the RFC version of Kconfig series,
I defined
CONFIG_SYS_ARCH, CONFIG_SYS_CPU, CONFIG_SYS_SOC, CONFIG_SYS_VENDOR,
CONFIG_SYS_BOARD in Kconfig.
For example,
configs/harmony_defconfig was like this:
CONFIG_SPL=y
CONFIG_ARM=y
CONFIG_SYS_CPU="armv7"
CONFIG_SOC_DIR=y
CONFIG_SYS_S
On 04/16/2014 08:44 AM, Masahiro Yamada wrote:
> arch/arm/include/asm/spl.h requires all SoCs to have
> arch/arm/include/asm/arch-*/spl.h.
>
> But many of them just define BOOT_DEVICE_* macros.
>
> Those macros are used in the "switch (boot_device) { ... }"
> statement in common/spl/spl.c.
>
> S
The T4080 SoC is a low-power version of the T4240/T4160.
T4080 combines 4 dual-threaded Power Architecture e6500
cores with single cluster and two memory complexes.
Signed-off-by: Shengzhou Liu
---
based on 'next' branch of u-boot-mpc85xx.
arch/powerpc/cpu/mpc85xx/Makefile | 2 ++
arch
Hi Masahiro,
On Tue, 22 Apr 2014 16:30:32 +0900, Masahiro Yamada
wrote:
> Hi Albert,
>
> > Can'we have the maintainer(s) be part of the board config file
> > from the start, like a required (but possible non-editable)
> > configuration item, something like "CONFIG_MAINTAINER_EMAIL"?
> >
> > Th
From: Shaohui Xie
Add support of 2 stage NAND/SD boot loader using SPL framework.
PBL initialise the internal SRAM and copy SPL, this further
initialise DDR using SPD and environment and copy u-boot from
NAND/SD to DDR, finally SPL transfer control to u-boot.
NOR uses CS1 instead of CS2 when NAND
Hi Tim,
On 04/21/14 21:28, Tim Harvey wrote:
> On Sun, Apr 20, 2014 at 12:52 AM, Igor Grinberg
> wrote:
>> On 04/18/14 09:35, Tim Harvey wrote:
>>> On Thu, Apr 17, 2014 at 4:44 AM, Stefano Babic wrote:
Hi Igor, hi Tim
On 17/04/2014 13:22, Igor Grinberg wrote:
>
> get
Hi Albert,
> Can'we have the maintainer(s) be part of the board config file
> from the start, like a required (but possible non-editable)
> configuration item, something like "CONFIG_MAINTAINER_EMAIL"?
>
> This would, at least, keep all information for a single board
> in a single place.
I did t
55 matches
Mail list logo
