Signed-off-by: Poonam Aggrwal
Signed-off-by: Shaveta Leekha
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index ecde00b..7970684 100644
--- a/arch/power
CPC1 is not being enabled by default as powerpc is supposed to
use only CPC2.
Signed-off-by: Shaveta Leekha
Signed-off-by: Sandeep Singh
---
include/configs/B4860QDS.h |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/configs/B4860QDS.h b/include/configs/B4
If hwconfig does not contains "en_cpc" then by default all cpcs are enabled
If this config is defined then only those individual cpcs which are defined
in the subargument of "en_cpc" will be enabled e.g en_cpc:cpc1,cpc2; (this
will enable cpc1 and cpc2) or en_cpc:cpc2; (this enables just cpc2)
Sig
Tom, is this patch ok for you? If yes, do you plan to merge it?
On Sat, Jun 28, 2014 at 1:21 AM, Thierry Reding
wrote:
> On Tue, Jun 24, 2014 at 11:45:29AM +0900, Alexandre Courbot wrote:
>> From: Bryan Wu
>>
>> On Tegra114 and Tegra124 platforms, certain display-related registers cannot
>> be a
Hi Stephen Warren,
On 07/02/2014 06:59 AM, Stephen Warren wrote:
From: Stephen Warren
A UDC's alloc_request method should zero out the newly allocated request.
Ensure the Atmel driver does so. This issue was found by code inspection,
following the investigation of an intermittent issue with ci
Signed-off-by: Luka Perkov
CC: Prafulla Wadaskar
CC: Stefan Roese
---
include/configs/ib62x0.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/ib62x0.h b/include/configs/ib62x0.h
index 186fd35..cd38577 100644
--- a/include/configs/ib62x0.h
+++ b/include/configs/ib62x0.h
@@
Each board with defines it's own set of values. If we do not define
CONFIG_MVGBE_PORTS we will hit following error:
mvgbe.c: In function 'mvgbe_initialize':
mvgbe.c:700:34: error: 'CONFIG_MVGBE_PORTS' undeclared (first use in this
function)
u8 used_ports[MAX_MVGBE_DEVS] = CONFIG_MVGBE_PORTS;
T
Signed-off-by: Luka Perkov
CC: Prafulla Wadaskar
CC: Stefan Roese
---
arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
index da80240..312d2b2 10064
When diffing through the various kwbimage.cfg files only show
relevant changes.
Signed-off-by: Luka Perkov
CC: Prafulla Wadaskar
CC: Stefan Roese
---
board/iomega/iconnect/kwbimage.cfg | 4 ++--
board/raidsonic/ib62x0/kwbimage.cfg | 22 +++---
2 files changed, 13 insertions(+
Shengzhou,
If u-boot uses 2nd I2C controller, it is good to have some comments. Please
complete with four I2C controllers' offset.
York
On 07/01/2014 12:37 AM, Jain Priyanka-B32167 wrote:
> Hello Shengzhou,
>
> T1040 has two dual I2C controller.
> First Dual I2C Controller : 0x118 (first i
On Fri, Jun 27, 2014 at 11:55:06AM +0200, Stefan Roese wrote:
> All those functions removed with this patch are not accessed at all. So lets
> remove them.
>
> Signed-off-by: Stefan Roese
> ---
>
> arch/arm/cpu/arm926ejs/kirkwood/cpu.c | 55
> ---
> 1 file chang
On 07/01/2014 04:57 PM, Jörg Krause wrote:
>
> On 07/02/2014 12:51 AM, Stephen Warren wrote:
>> [...]
>>> Loading: ##
>>> 4.3 MiB/s
>>> done
>>> Bytes transferred = 18003 (4653 hex)
>>> CACHE: Misaligned operation at range [40008000, 4000c653]
>> OK, that particular e
From: Stephen Warren
A UDC's alloc_request method should zero out the newly allocated request.
Ensure the Atmel driver does so. This issue was found by code inspection,
following the investigation of an intermittent issue with ci_udc, which
was tracked down to failing to zero out allocated reques
On 07/02/2014 12:51 AM, Stephen Warren wrote:
[...]
Loading: ##
4.3 MiB/s
done
Bytes transferred = 18003 (4653 hex)
CACHE: Misaligned operation at range [40008000, 4000c653]
OK, that particular error happens well after the network transfer phase
of the tftp comman
On 07/01/2014 04:42 PM, Jörg Krause wrote:
>
> On 07/01/2014 11:36 PM, Stephen Warren wrote:
>> [snip]
>> Can you please try one more thing:
>>
>> Go back to u-boot-usb/master plus just your board support patches. Apply
>> the following and test that:
>>
>>> diff --git a/drivers/usb/gadget/ci_udc.
On Wednesday, July 02, 2014 at 12:42:40 AM, Jörg Krause wrote:
> On 07/01/2014 11:36 PM, Stephen Warren wrote:
> > [snip]
> > Can you please try one more thing:
> >
> > Go back to u-boot-usb/master plus just your board support patches. Apply
> >
> > the following and test that:
> >> diff --git a/
On 07/01/2014 04:47 PM, Jörg Krause wrote:
>
> On 07/02/2014 12:36 AM, Stephen Warren wrote:
>> On 07/01/2014 04:34 PM, Jörg Krause wrote:
>>> On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
> [snip]
>>> Can you edit arch/arm/cpu/arm926ejs/cache.c
On 07/02/2014 12:36 AM, Stephen Warren wrote:
On 07/01/2014 04:34 PM, Jörg Krause wrote:
On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspe
On 07/01/2014 11:36 PM, Stephen Warren wrote:
[snip]
Can you please try one more thing:
Go back to u-boot-usb/master plus just your board support patches. Apply
the following and test that:
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index a6433e8d2d8d..13be1b73d3d1
On 07/01/2014 04:34 PM, Jörg Krause wrote:
>
> On 07/01/2014 01:22 PM, Jörg Krause wrote:
>>
>> On 07/01/2014 01:19 PM, Marek Vasut wrote:
>>> [snip]
> Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
> printf() , then re-test please ? I suspect this might trap somethi
On 07/01/2014 01:22 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this pat
On 07/01/2014 11:31 PM, Stephen Warren wrote:
On 07/01/2014 03:25 PM, Jörg Krause wrote:
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either
On 07/01/2014 03:31 PM, Stephen Warren wrote:
> On 07/01/2014 03:25 PM, Jörg Krause wrote:
>>
>> On 07/01/2014 07:41 PM, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> This is a series of small fixes and cleanups either required by those
>>> fixes, or enabled now that the fixes are made.
>
On 07/01/2014 03:25 PM, Jörg Krause wrote:
>
> On 07/01/2014 07:41 PM, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> This is a series of small fixes and cleanups either required by those
>> fixes, or enabled now that the fixes are made.
>>
>> I hope that either patch 1 or 4 might fix the is
On 07/01/2014 07:41 PM, Stephen Warren wrote:
From: Stephen Warren
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The o
From: Stephen Warren
Almost all of ci_udc.c uses variable name "ep" for a struct usb_ep and
"ci_ep" for a struct ci_ep. This is nice and consistent, and helps people
know what type a variable is without searching for the declaration.
handle_ep_complete() doesn't do this, so fix it to be consisten
Le 1 juil. 2014 22:03, "Albert ARIBAUD" a écrit
:
>
> Hi Bastien,
>
> On Sun, 8 Jun 2014 18:30:25 +0200, Bastien ROUCARIÈS
> wrote:
>
> > From: Jamie Lentin
> >
> > So we can re-use DNS-325 configuration for the DNS-320 without things
getting
> > confusing, rename all common parts from dns325 t
Hi Bastien,
On Sun, 8 Jun 2014 18:30:25 +0200, Bastien ROUCARIÈS
wrote:
> From: Jamie Lentin
>
> So we can re-use DNS-325 configuration for the DNS-320 without things getting
> confusing, rename all common parts from dns325 to dnskw, and use a config
> option to configure DNS-325 specifics.
>
Hi Fabio,
On Tue, 1 Jul 2014 10:53:57 -0300, Fabio Estevam
wrote:
> Hi Helmut,
>
> On Tue, Jul 1, 2014 at 10:33 AM, Helmut Raiger wrote:
> > Hi,
> >
> > the commit 41623c91 breaks the SPL on i.mx31 platforms.
> > The original startup code (start.S) was position independent to
> > allow rel
Hi Minkyu,
On Mon, 30 Jun 2014 17:42:38 +0900, Minkyu Kang
wrote:
> Dear Albert,
>
> 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
From: Stephen Warren
Call cleanup() before running tests too. If a previous test was CTRL-C'd
some stale files may have been left around. dfu-util refuses to receive
a file to a filename that already exists, which results in false test
failures if the files aren't cleaned up first.
Signed-off-by
From: Stephen Warren
On Tegra, the DFU buffer size is 1M. Consequently, the 8M test always
fails. Add tests for the 1M size, and one byte less as a corner case,
so that some large tests are executed and expected to pass.
Signed-off-by: Stephen Warren
---
test/dfu/dfu_gadget_test_init.sh | 2 +-
From: Stephen Warren
The buffer is too small if it's < size to read, not if it's <= the size.
This fixes the 1MB test case on Tegra, which has a 1MB buffer.
Signed-off-by: Stephen Warren
---
drivers/dfu/dfu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dfu/dfu.c
On Mon, Jun 30, 2014 at 02:32:20PM -0700, Stephen Warren wrote:
> On 06/30/2014 02:53 PM, Allen Martin wrote:
> > Norrin (PM370) is a Tegra124 clamshell board that is very similar to
> > venice2, but it has a different panel, the sdcard cd sense is flipped,
> > and it has a different revision of th
On Fri, Jun 27, 2014 at 4:37 AM, Pantelis Antoniou <
pantelis.anton...@gmail.com> wrote:
> Hi Eli,
>
> On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote:
>
> > The current wait loop just reads the status 1 times, which makes the
> > actual timeout period platform-dependent. The udelay() call wi
From: Stephen Warren
ci_udc_probe() initializes a pair of QHs and QTDs for each EP. After
each pair has been initialized, the pair is cache-flushed. The
conversion from QH/QTD index [0..2*NUM_END_POINTS) to EP index
[0..NUM_ENDPOINTS] is incorrect; it simply subtracts 1 (which yields
the QH/QTD i
From: Stephen Warren
This will allow functions other than ci_udc_probe() to make use of the
constants in a future change.
This in turn requires converting the const int variables to #defines,
since the initialization of one global const int can't depend on the
value of another const int; the com
From: Stephen Warren
2 QTDs are allocated for each EP. The current allocation scheme aligns
the first QTD in each pair, but simply adds the struct size to calculate
the second QTD's address. This will result in a non-cache-aligned
addresss IF the system's ARCH_DMA_MINALIGN is not 32 bytes (i.e. t
From: Stephen Warren
Fix ci_ep_submit_next_request()'s ZLP transmission code to explicitly
call ci_get_qtd() to find the address of the other QTD to use. This
will allow us to correctly align each QTD individually in the future,
which may involve leaving a gap between the QTDs.
Signed-off-by: St
From: Stephen Warren
This is a series of small fixes and cleanups either required by those
fixes, or enabled now that the fixes are made.
I hope that either patch 1 or 4 might fix the issues Jörg is seeing, but
I'm not sure that will happen. The other patches shouldn't change any
behaviour.
Ste
From: Stephen Warren
There's no need to store an array of QTD pointers in the controller.
Since the calculation is so simple, just have ci_get_qtd() perform it
at run-time, rather than pre-calculating everything.
Signed-off-by: Stephen Warren
---
drivers/usb/gadget/ci_udc.c | 8 +++-
drive
From: Stephen Warren
struct ci_req is a purely software structure, and needs no specific
memory alignment. Hence, allocate it with calloc() rather than
memalign(). The use of memalign() was left-over from when struct ci_req
was going to hold the aligned bounce buffer, but this is now dynamically
Hi Tom,
On Thu, 19 Jun 2014 10:53:11 -0700, Tom Warren
wrote:
> Albert,
>
> Please pull u-boot-tegra/master into ARM/master. Thanks!
>
> ./MAKEALL -s tegra AOK, checkpatch.pl is OK, and ./MAKEALL -a arm only
> shows failures that were already present in ARM/master.
>
> The following changes s
On Tuesday, July 01, 2014 at 05:16:26 PM, Stephen Warren wrote:
> On 07/01/2014 09:13 AM, Marek Vasut wrote:
> > On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote:
> >> On 06/30/2014 06:04 PM, Marek Vasut wrote:
> >>> Instead of weird allocation of ci_drv->items_mem and then even weird
On 07/01/2014 09:13 AM, Marek Vasut wrote:
> On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote:
>> On 06/30/2014 06:04 PM, Marek Vasut wrote:
>>> Instead of weird allocation of ci_drv->items_mem and then even weirder
>>> distribution of offsets in this memory area into ci_drv->items ar
On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote:
> On 06/30/2014 06:04 PM, Marek Vasut wrote:
> > Instead of weird allocation of ci_drv->items_mem and then even weirder
> > distribution of offsets in this memory area into ci_drv->items array,
> > just allocate ci_drv->items as a big
On 06/30/2014 06:04 PM, Marek Vasut wrote:
> Instead of weird allocation of ci_drv->items_mem and then even weirder
> distribution of offsets in this memory area into ci_drv->items array,
> just allocate ci_drv->items as a big slab of aligned memory (replaces
> ci_drv->items_mem) and let ci_get_qtd
Hello Minkyu,
On 06/27/2014 01:34 PM, Przemyslaw Marczak wrote:
On 06/27/2014 11:40 AM, Minkyu Kang wrote:
Dear Przemyslaw Marczak,
On 26/06/14 23:15, Przemyslaw Marczak wrote:
On an Odroid U3 board, the SOC is unable to reset the eMMC card
in the DWMMC mode by the cpu software reset. Manual
Hello Jeroen,
On 06/30/2014 08:30 PM, Jeroen Hofstee wrote:
Hello Przemyslaw.
[...]
#include
+void __reset_misc(void) {}
+
+void reset_misc(void)
+__attribute((weak, alias("__reset_misc")));
+
can you please use __weak here and provide a prototype, wherever it
ends up in the end. It
Hi Helmut,
On Tue, Jul 1, 2014 at 10:33 AM, Helmut Raiger wrote:
> Hi,
>
> the commit 41623c91 breaks the SPL on i.mx31 platforms.
> The original startup code (start.S) was position independent to
> allow relocation in board_init_f. This is necessary as the internal
> RAM used by the IPL to l
Hi Tom,
On Thu, 19 Jun 2014 18:03:25 -0400, Tom Rini wrote:
> Hey,
>
> 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:/
Hi,
the commit 41623c91 breaks the SPL on i.mx31 platforms.
The original startup code (start.S) was position independent to
allow relocation in board_init_f. This is necessary as the internal
RAM used by the IPL to load the first 2kB from NAND is also
used by the NAND controller to buffer pag
On 07/01/2014 01:35 PM, Marek Vasut wrote:
On Tuesday, July 01, 2014 at 01:22:41 PM, Jörg Krause wrote:
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
The option can be used to save the environment in spi flash.
Implementation code is already exist in command/env_sf.c. But
the documentation is missing.
This patch add the details for this option to the README file.
Signed-off-by: Josh Wu
---
README | 37 +
On Tuesday, July 01, 2014 at 01:22:41 PM, Jörg Krause wrote:
> On 07/01/2014 01:19 PM, Marek Vasut wrote:
> > [snip]
> >
> >>> Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
> >>> printf() , then re-test please ? I suspect this might trap something
> >>> still. Ah, and pleas
On 07/01/2014 01:19 PM, Marek Vasut wrote:
[snip]
Can you edit arch/arm/cpu/arm926ejs/cache.c and change the debug() to
printf() , then re-test please ? I suspect this might trap something
still. Ah, and please test on u-boot-usb/master with this patch.
No additional output on the console.
Wh
On Tuesday, July 01, 2014 at 01:03:25 PM, Jörg Krause wrote:
> On 07/01/2014 12:17 PM, Marek Vasut wrote:
> > On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
> >> On 07/01/2014 02:04 AM, Marek Vasut wrote:
> >>> Instead of weird allocation of ci_drv->items_mem and then even weirder
> >
On 07/01/2014 12:17 PM, Marek Vasut wrote:
On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
On 07/01/2014 02:04 AM, Marek Vasut wrote:
Instead of weird allocation of ci_drv->items_mem and then even weirder
distribution of offsets in this memory area into ci_drv->items array,
just a
Dear Scott,
In message <1404169793.2435.204.ca...@snotra.buserror.net> you wrote:
>
> > (git) diff needs a reference to diff against. Maybe I missed some
> > earlier comments about that, but how exactly should this be done
> > here?
>
> When the code is synced, the corresponding Linux SHA1 or tag
On Tuesday, July 01, 2014 at 08:51:45 AM, Jörg Krause wrote:
> On 07/01/2014 02:04 AM, Marek Vasut wrote:
> > Instead of weird allocation of ci_drv->items_mem and then even weirder
> > distribution of offsets in this memory area into ci_drv->items array,
> > just allocate ci_drv->items as a big sla
From: Chao Fu
Add DSPI and QSPI bus definition in SOC level.
Sf probe command parameter bus will decide which module will work.
Add register base definition.
Signed-off-by: Chao Fu
---
arch/arm/include/asm/arch-vf610/imx-regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/in
From: Chao Fu
Add spi device info for vf610-twr board.
Enable fsl-spi-interface for compatibility of fsl-dspi and fsl-qspi.
Signed-off-by: Chao Fu
---
board/freescale/vf610twr/vf610twr.c | 24
include/configs/vf610twr.h | 2 ++
2 files changed, 26 insertions(
From: Chao Fu
Freescale has some series of chips(e.g. vf610) contain two kinds of
SPI modules, DSPI and QSPI. U-boot spi current code can't compile and
enable the two modules at same time. So add fsl-spi-interface make two
spi driver code work together.
Usage:(e.g.)
SPI bus defination ca
Hello Shengzhou,
T1040 has two dual I2C controller.
First Dual I2C Controller : 0x118 (first i2c bus), 0x1181000(second I2C bus)
Second Dual I2C Controller : 0x119 (third i2c bus), 0x1191000(fourth I2C
bus)
My understanding is CONFIG_SYS_FSL_I2C_OFFSET is offset for first I2C
controlle
The base address of I2C2 is 0x118100 instead of 0x119000.
Signed-off-by: Shengzhou Liu
---
include/configs/T1040QDS.h | 2 +-
include/configs/T104xRDB.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h
index 2215ac8..5
65 matches
Mail list logo