>From: Igor Grinberg [mailto:grinb...@compulab.co.il]
>Hi Pekon,
>
>On 07/04/14 22:05, Pekon Gupta wrote:
>> This patch series adds support for parallel NAND devices support connected
>> via
>> GPMC chip-select on various boards belonging to AM33xx and OMAPx platforms.
>> This series also moves so
Hi everyone,
when it comes to optimizing the boot sequence there are several documents with
a lot of hints. One of them is to skip the check sum calculation of the image
in U-Boot (set verify n) - some of them say "you don't need to verify every
time you boot, since it is always the same image
when I use yaffs2 with inband-tags, the file always miss some part which
filled with 0s.
It prints 'yaffs: Chunk -1 not found zero instead' when ytrace is 0x800.
I found out mtd_block_markbad & mtd_block_isbad parameter is wrong.
In file fs\yaffs2\yaffs_guts.c, line 4658 to 4664?
/
This adds CONFIG_TLB_SIZE for individual board, whose TLB size maybe
larger than PGTABLE_SIZE.
Signed-off-by: Xiubo Li
---
arch/arm/lib/board.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index dc34190..b7327ce 100644
--- a/arch/arm/lib/boa
Add support for 3rd and 4th I2C.
Signed-off-by: Shengzhou Liu
---
drivers/i2c/fsl_i2c.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index aa159f8..811033b 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/driver
- Fix base address of I2C2 as 0x118100 instead of 0x119000.
- Add definitions for I2C3 & I2C4.
Signed-off-by: Shengzhou Liu
---
include/configs/T1040QDS.h | 10 --
include/configs/T104xRDB.h | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/include/configs/
Dear Ian Campbell,
In message <1404682080.11284.33.ca...@dagon.hellion.org.uk> you wrote:
>
> Oh, I didn't mean to suggest skipping all that good stuff, just that the
> patch is already in a local branch ready to go when it is acked so I
> don't need to fetch it from patchwork.
It is a very good
> >>> [U-Boot,v4,03/10] ARM: non-sec: reset CNTVOFF to zero
> >>>
> >>> Before switching to non-secure, make sure that CNTVOFF is set
> >>> to zero on all CPUs. Otherwise, kernel running in non-secure
> >>> without HYP enabled (hence using virtual timers) may observe
> >> But we have HYP enabled. I
> >>> +#define CONFIG_ARMV7_NONSEC
> >>> +#define CONFIG_ARMV7_VIRT
> >>> +#define CONFIG_SOC_BIG_ENDIAN
> >>> +#define CONFIG_DCFG_CCSR_SCRATCHRW1 0x01ee0200
> >>> +#define CONFIG_DCFG_CCSR_BRR 0x01ee00e4
> >> Why are you hardcoding the register addresses in this file? I saw that
Fixes a bug when objcopy doesn't put .dtb.init.rodata section to resulting
u-boot.bin, so u-boot was unable to find embedded DTB.
---
arch/arm/config.mk | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 66ecc2e..5fa1825 100644
--- a/arch/arm/conf
Four I2C controllers' offset are:
#define CONFIG_SYS_FSL_I2C_OFFSET 0x118000
#define CONFIG_SYS_FSL_I2C2_OFFSET 0x118100
#define CONFIG_SYS_FSL_I2C3_OFFSET 0x119000
#define CONFIG_SYS_FSL_I2C4_OFFSET 0x119100
I will add I2C3 and I2C4.
Thanks,
Shengzhou
> -Original Message-
> From: Sun
'-elf' appears twice in the toolchain priority_list.
The second one is rudundant.
Signed-off-by: Masahiro Yamada
Cc: Simon Glass
---
tools/buildman/toolchain.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index e3
Toolchains.__init__ is expected to display a warning message
when the [toolchain] section is missing from ~/.buildman file.
But it never works.
In that case, instead, buildmain fails with an error message
which is difficult to understand:
Traceback (most recent call last):
File "tools/buildm
On Sun, 2014-07-06 at 22:54 +0200, Albert ARIBAUD wrote:
> Hi Ian,
>
> On Sun, 06 Jul 2014 20:22:31 +0100, Ian Campbell
> wrote:
>
> > On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> > > Hi Ian,
> > >
> > > Slightly off-topic, but... When you provide some code excerpt, you
> > > shou
Hi Ian,
On Sun, 06 Jul 2014 20:22:31 +0100, Ian Campbell
wrote:
> On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> > Hi Ian,
> >
> > Slightly off-topic, but... When you provide some code excerpt, you
> > should make sure it doesn't look like a git patch, because if it does,
> > then o
On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
> adds sun4i and sun5i support
Does this series omit FEL mode support or did you just not include it
for the new boards?
I think in general we want a _FEL variant for every board except the
minority which don't have an OTG port etc.
Ian.
_
On Sun, 2014-07-06 at 21:18 +0200, Albert ARIBAUD wrote:
> Hi Ian,
>
> Slightly off-topic, but... When you provide some code excerpt, you
> should make sure it doesn't look like a git patch, because if it does,
> then our Patchwork, which reads the list, will think it is actually a
> patch submiss
Hi Ian,
Slightly off-topic, but... When you provide some code excerpt, you
should make sure it doesn't look like a git patch, because if it does,
then our Patchwork, which reads the list, will think it is actually a
patch submission:
http://patchwork.ozlabs.org/patch/367391/
Amicalement,
Albert
On Mon, 2014-06-09 at 11:36 +0200, Hans de Goede wrote:
> Here is v2 of my patch series to be applied on top of Ian's recently merged
> basic sun7i support.
For the A13-OLinuXinoM and r7-tv-dongle with this series I'm seeing:
arch/arm/cpu/armv7/sunxi/board.c: In function ‘cpu_eth_init’:
arch/arm/
Hello Scott,
In message <20140701104510.83c0d383...@gemini.denx.de> I wrote:
...
> > When the code is synced, the corresponding Linux SHA1 or tag should be
> > placed in the commit message. This is the case for the NAND code.
> > Unfortunately it has never been true of the mtd/ubi code, but this
Hi Heiko,
On Fri, 2014-06-13 at 22:55 +0200, Hans de Goede wrote:
> 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
OK, my best thanks for your great answer.
--
View this message in context:
http://u-boot.10912.n7.nabble.com/Giving-control-to-standalone-app-tp183635p183639.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot
Hi mazen.e,
On Sun, 6 Jul 2014 06:00:03 -0700 (PDT), "mazen.e"
wrote:
> Dear
>
> Many thanks for your reply.
>
> But what if mistakenly or accidentally the standalone application write to
> the memory where u-boot resides, would that cause the standalone application
> to crash? Otherwise (in
Dear
Many thanks for your reply.
But what if mistakenly or accidentally the standalone application write to
the memory where u-boot resides, would that cause the standalone application
to crash? Otherwise (in case the standalone application has written to
u-boot memory without crash ) what happ
On 06-07-14 13:10, mazen.e wrote:
Dear all,
At the moment U-Boot branches to the OS entry point, U-Boot is dead and no
longer exists, does this property hold also when u-boot loads a standalone
application.
In fact, I want to 'give control' to a standalone application, what does
exactly the
Dear all,
At the moment U-Boot branches to the OS entry point, U-Boot is dead and no
longer exists, does this property hold also when u-boot loads a standalone
application.
In fact, I want to 'give control' to a standalone application, what does
exactly the word 'give control' mean? e.g. 'givi
Hi Pekon,
On 07/04/14 22:05, Pekon Gupta wrote:
> This patch series adds support for parallel NAND devices support connected via
> GPMC chip-select on various boards belonging to AM33xx and OMAPx platforms.
> This series also moves some board specific CONFIG_NAND_xx from generic files
> to individ
27 matches
Mail list logo
