Hi Otavio,
On 03/09/2016 22:27, Otavio Salvador wrote:
> On Sat, Sep 3, 2016 at 6:40 AM, Stefano Babic wrote:
>> On 03/09/2016 01:15, Petr Kulhavy wrote:
>>> You are saying that in order to cover my use case(s) I need two
>>> defconfigs. Well, ok...
>>> But how do I integrate this into Buildroot?
Hi Jagan,
On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki wrote:
>
> diff --git a/board/freescale/mx6ul/Kconfig b/board/freescale/mx6ul/Kconfig
> index f97b905..d902cd0 100644
> --- a/board/freescale/mx6ul/Kconfig
> +++ b/board/freescale/mx6ul/Kconfig
At least for i.MX we follow the convention:
board
Hi Fabio
On Sun, Sep 4, 2016 at 3:08 PM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki wrote:
>>
>> diff --git a/board/freescale/mx6ul/Kconfig b/board/freescale/mx6ul/Kconfig
>> index f97b905..d902cd0 100644
>> --- a/board/freescale/mx6ul/Kconfig
>> +++ b/board/
Hi Fabio,
+ Tom (looking for any suggestions for not maintaining separate board
files if the board code is sharing different boards with same SOC)
On Sun, Sep 4, 2016 at 6:38 PM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki wrote:
>>
>> diff --git a/board/free
On Thu, Sep 1, 2016 at 7:38 PM, Michal Simek wrote:
> Current code generates warning when it is compiled for arm64:
> Warnings:
> In file included from drivers/spi/zynq_spi.c:14:0:
> drivers/spi/zynq_spi.c: In function ‘zynq_spi_init_hw’:
> drivers/spi/zynq_spi.c:95:9: warning: large integer impli
On Fri, Sep 2, 2016 at 8:24 PM, Tom Rini wrote:
> On Thu, Sep 01, 2016 at 01:24:40PM +0530, Vignesh R wrote:
>
>> This udelay() was added as an HACK and is no longer required. All
>> read/write/erase operations work fine even without this delay. Hence,
>> remove the udelay() call.
>>
>> Tested rea
On Thu, Sep 1, 2016 at 1:24 PM, Vignesh R wrote:
> TI QSPI has four 32 bit data registers which can be used to transfer 16
> bytes of data at once. The register group QSPI_SPI_DATA_REG_3,
> QSPI_SPI_DATA_REG_2, QSPI_SPI_DATA_REG_1 and QSPI_SPI_DATA_REG is
> treated as a single 128-bit word for shi
On Sun, Sep 4, 2016 at 6:56 AM, Fabio Estevam wrote:
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki wrote:
>> i.MX6UL GEA M6UL modules are system on module solutions manufactured
>> by Engicam with following characteristics:
>> Processor NXP i.MX 6UltraLite MCIMX6G2, 528 MHz
>> RAM
On 09/04/2016 01:38 AM, Masahiro Yamada wrote:
> 2016-09-02 23:12 GMT+09:00 Marek Vasut :
>> On 09/02/2016 03:09 PM, Masahiro Yamada wrote:
>>> 2016-09-02 20:58 GMT+09:00 Marek Vasut :
On 09/02/2016 12:36 PM, Masahiro Yamada wrote:
> -ret = expression;
> -if (ret)
> -
Hi Fabio,
On Sun, Sep 4, 2016 at 7:57 AM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 5:22 AM, Jagan Teki wrote:
>> Since most of the board along with the config code used for
>> mx6ul boards are common and for improving code reusability
>> refactor or group code as mx6ul notatio
Hi Fabio,
On Sun, Sep 4, 2016 at 7:53 AM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Sat, Sep 3, 2016 at 10:26 PM, Fabio Estevam wrote:
>
>>> configs/mx6ul_geam_kit_defconfig | 11 +++
>>> include/configs/mx6ul.h | 1 +
>>
>> This file does not exist.
>
> Ok, I see you introduce
On Sun, Sep 4, 2016 at 10:32 AM, Jagan Teki wrote:
> Please do read the thread fully before commenting, I've mentioned the
> state of hardware when I relied to Peng. And also this is an RFC patch
> I'm looking for comments on function like changes whether the flow of
> adding code to existing sof
On 09/03/2016 12:53 AM, Simon Glass wrote:
> Hi,
>
> On 1 September 2016 at 03:49, wrote:
>> On 16-08-23 15:17:12, Marek Vasut wrote:
>>> On 08/09/2016 08:14 PM, Sanchayan Maity wrote:
Hello,
This is the second version of the patchset for migrating Vybrid
USB driver to driver
Some patches to fix the Pine64 support:
The first two patches revert two patches that actually broke booting
Pine64 via the boot0 blob, already in 2016.07.
This has been discussed on IRC before, the commit messages contain
some details on the reasons for the revert. As the intent of those
original
Now that we don't use SRAM C for the SPL stack anymore, there is no
need to clock down AHB1 to 100 MHz.
Keeping it at the recommended 200 MHz allows faster peripherals.
This reverts commit 5bc88cc2be3a962005b6e5768e06ca8f6ffcb88d.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunx
There is no "CONFIG_MACH_SUN50I_A64" in upstream U-Boot, so fix
the name to prevent the option to be enabled.
Signed-off-by: Andre Przywara
---
board/sunxi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 1b30669..3ec011a
Casting "int"s to pointers is only valid for 32-bit systems.
Add the appropriate pointer type cast to avoid a compiler warning
when compiling for AArch64.
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/board.c
This commit moved the SPL stack into SRAM C, which worked when the SPL
set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
from the CPU.
However booting with boot0 (and thus not using SPL at all) we still run
with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
Since t
The all current Rockchip SoCs supporting 4GB of ram have problems
accessing the memory region 0xfe00~0xff00. Actually, some IP
controller can't address to, so let's limit the available range.
This patch fixes a bug which found in miniarm-rk3288-4GB board. The
U-Boot was relocated to 0xfef7
2016-09-02 23:35 GMT+09:00 Tom Rini :
>> >> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>> >> index c25fcf3..d4a5bc9 100644
>> >> --- a/arch/arm/mach-exynos/Kconfig
>> >> +++ b/arch/arm/mach-exynos/Kconfig
>> >> @@ -61,6 +61,9 @@ endif
>> >>
>> >> if ARCH_EXYNOS5
>> >
2016-08-30 9:21 GMT+09:00 Simon Glass :
> Update the defconfig files to match their canonical form, as produced by
> 'make safedefconfig'.
>
> This is the result of running 'tools/moveconfig.py -s' on the tree.
>
> Signed-off-by: Simon Glass
>
> diff --git a/configs/10m50_defconfig b/configs/10m5
T series boards use unified RCW for sd, api and nand boot.
Now split txxx_rcw.cfg to txxx_sd_rcw.cfg, txxx_spi_rcw.cfg
and txxx_nand_rcw.cfg for SPI/NAND/SD boot.
Signed-off-by: Zhao Qiang
---
.../t102xqds/{t1024_rcw.cfg => t1024_nand_rcw.cfg} | 0
.../t102xqds/{t1024_rcw.cfg => t1024_sd_rcw.cf
FLUSH command is restricted to CCSR space. So use WAIT
command in case of non-CCSR board.
Signed-off-by: Zhao Qiang
---
board/freescale/t208xqds/t208x_pbi.cfg | 3 +--
board/freescale/t208xrdb/t2080_pbi.cfg | 3 +--
board/freescale/t4qds/t4_pbi.cfg | 3 +--
board/freescale/t4rdb/t4_pbi.cfg
The SPL and U-Boot proper may use different initial stack
locations, which are configured via CONFIG_SPL_STACK and
CONFIG_SYS_INIT_SP_ADDR defines. The lowlevel_init.S
code needs to handle this in the same way as crt0.S
Without this fix, setting the U-Boot stack location to some
place, which is no
On Mon, 5 Sep 2016 01:32:38 +0100
Andre Przywara wrote:
> This commit moved the SPL stack into SRAM C, which worked when the SPL
> set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
> from the CPU.
> However booting with boot0 (and thus not using SPL at all) we still run
> w
On Mon, 5 Sep 2016 01:32:39 +0100
Andre Przywara wrote:
> Now that we don't use SRAM C for the SPL stack anymore, there is no
> need to clock down AHB1 to 100 MHz.
It's just another way to say it, but we are not clocking the AHB1
down, but rather keeping it at a failsafe default. If I understan
On Mon, 5 Sep 2016 01:32:41 +0100
Andre Przywara wrote:
> Casting "int"s to pointers is only valid for 32-bit systems.
> Add the appropriate pointer type cast to avoid a compiler warning
> when compiling for AArch64.
>
> Signed-off-by: Andre Przywara
> ---
> board/sunxi/board.c | 2 +-
> 1 fi
27 matches
Mail list logo
