Some boards e.g. keymile arm boards have CONFIG_CMD_I2C switched on
but they use soft i2c on kirkwood. So don't switch CONFIG_I2C_MVTWSI
on in this case.
Signed-off-by: Holger Brunck
cc: Valentin Longchamp
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
arch/arm/include/asm/arch-kirkwood/config.
commit 010a958b
(arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h)
breaks building keymile arm targets, when u-boot.kwb tries to
generate the binary with mkimage. A simple make or MAKEALL
succeeded because it don't try to build the kirwood binary at the end.
Due this commit we use the C
Dear Rob Herring,
On 13 June 2011 21:45, Rob Herring wrote:
> On 06/13/2011 01:59 AM, Minkyu Kang wrote:
>>
>> Dear Rob Herring,
>>
>> On 12 June 2011 06:46, Rob Herring wrote:
>>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>>> index 280738f..c82bde0 100644
>>> --- a/drivers/mmc/sdhc
On 06/12/2011 03:16 AM, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
> ---
> Build tested only. Don't have access to this hardware.
>
> board/imx31_phycore/config.mk |1 -
> board/imx31_phycore/imx31_phycore.c | 22 ++
> include/configs/imx31_phycore.h
On 06/12/2011 03:16 AM, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam
> ---
> Build tested only. Don't have access to this hardware.
>
> board/mx1ads/config.mk | 25 -
> board/mx1ads/mx1ads.c| 27 +++
> include/configs/mx1ads.h |
On 06/12/2011 05:41 AM, Fabio Estevam wrote:
> commit 0015de1a (MX5: Make the weim structure complete) fixed the name for
> the WEIM registers in order to match with the MX51/MX53 manuals.
>
> Fix the WEIM register for vision2 board so that it can build again.
>
> Signed-off-by: Fabio Estevam
A
Hi List,
as some may know I'am working on an SPL for the devkit8000.
Now I have a problem with the UART init where I hope someone on the
list can help.
My problem is in drivers/serial/serial.c with the function
calc_divisor. With my defines this function is essentially just this:
return (CONFIG_S
Dear Wolfgang,
On Thursday 09 June 2011 03:11 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4def62a6.7060...@ti.com> you wrote:
>>
>> I still don't think this is the 'right' solution for my problem. I don't
>> like the fact that clrsetbits_le32() introduces a lot of un-necessary
>> 'vo
Dear Mark Jackson,
Am 13.06.2011 15:28, schrieb Andreas Bießmann:
> Dear Mark Jackson,
>
> Am 13.06.2011 um 14:26 schrieb Mark Jackson:
>> Can anyone help ?
>
> My last try with avr32 boards was around 2011.03 release ... will have a look
> for it tomorrow.
ATSTK1002 and our (not mainline) bo
Hi Prafulla,
Please, consider pulling this patch.
Regards,
Simon
On Sat, Jun 11, 2011 at 03:16:07PM +0200, Simon Guinot wrote:
> This patch add support for the Network Space v2 board and parents, based
> on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
> and Internet Space
Dear Aneesh V,
In message <4df71fbf.6030...@ti.com> you wrote:
>
> As I start re-working on my patches I realize that there is no
> alternative to get_bit_field(). clrsetbits_le32() works as an
> alternative for set_bit_field() but I couldn't find anything in io.h
> that could replace get_bit_fie
Dear Wolfgang,
On Tuesday 14 June 2011 04:21 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4df71fbf.6030...@ti.com> you wrote:
>>
>> As I start re-working on my patches I realize that there is no
>> alternative to get_bit_field(). clrsetbits_le32() works as an
>> alternative for set_bi
Hi, Reinhard!
On Thu, Jun 09, 2011 at 11:45:31AM -0400, Sergey Lapin wrote:
> Make AFEB9260 build again.
> Based on fix for AT91SAM9260EK.
>
> Signed-off-by: Sergey Lapin
> ---
> Fixed unneeded 1s in defines in board configuration
> Removed most undefs in board configuration
> Setting SoC name i
This is a Delivery Status Notification (DSN).
I was unable to deliver your message to
use...@sancharnet.in.
I said
RCPT TO:
And they gave me the error;
550 Recipient Suspended
Reporting-MTA: dns; etexusa.com
Final-Recipient: RFC822; userid@sancharnet.in
Action: failed
Status: 5.0.0
Rece
Hi Simon,
On 14/06/11 18:52, Simon Schwarz wrote:
> Hi List,
>
> as some may know I'am working on an SPL for the devkit8000.
> Now I have a problem with the UART init where I hope someone on the
> list can help.
Are you working with a latest version of U-Boot? Do you have additional
modification
Dear Hong Xu,
> Rework for AT91SAM9263 SoC, makes it build again.
> Based on the work for AT91SAM9260-EK.
>
> Signed-off-by: Hong Xu
> ---
> arch/arm/cpu/arm926ejs/at91/lowlevel_init.S|2 +-
> arch/arm/cpu/arm926ejs/at91/timer.c| 13 ++
> arch/arm/include/asm/arch-a
Dear Hong Xu,
> Rework for AT91SAM9261(9G10) SoC, makes it build again.
> Based on the work for AT91SAM9260-EK.
>
> Signed-off-by: Hong Xu
> ---
> arch/arm/cpu/arm926ejs/at91/at91sam9261_devices.c | 45 +---
> arch/arm/include/asm/arch-at91/at91_spi.h |2 +-
> arch/arm/in
Dear Hong Xu,
> Rework for AT91SAM9RL SoC, makes it build again.
> Based on the work for AT91SAM9260-EK.
>
>
> Signed-off-by: Hong Xu
> ---
> arch/arm/cpu/arm926ejs/at91/at91sam9rl_devices.c | 26 ++--
> arch/arm/include/asm/arch-at91/at91_spi.h |2 +-
> arch/arm/include/asm/ar
Dear Aneesh V,
In message <4df7488a.6000...@ti.com> you wrote:
>
> Yes. I have seen those macros. But more often than not the bit field is
> more than 1 bit wide and the value to be set is not necessarily all 0's
> or all 1's. That's why I have to use clrsetbits_*()
I see. In such a case (and on
Signed-off-by: Fabio Estevam
---
include/configs/mx31pdk.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index ba1e187..77e93ab 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -118,6 +118
(Sorry forgot the ML on CC - resend)
Hi Graeme,
2011/6/14 Graeme Russ :
> Hi Simon,
>
> On 14/06/11 18:52, Simon Schwarz wrote:
>> Hi List,
>>
>> as some may know I'am working on an SPL for the devkit8000.
>> Now I have a problem with the UART init where I hope someone on the
>> list can help.
>
>
Hi again,
seems that there is a problem with gd - at least your test breaks...
I added unsigned long temp at the end of gd.
And added
unsigned long a=0;
a=gd->temp;
gd->temp = 4;
to calc_divisor
Here is a part of the debugging session:
Breakpoint 1, calc_divisor (port=) at serial.c:171
171
Hello Eric,
we have both, a beagle xM-B and a beagle xM-C. The following works on
both boards and is different from your patch. It is not possible to
differentiate between Rev xM-A and xM-B. Anyway, the only difference is
in the processors silicon revision (ES 1.0 to ES 1.1).
regards,
chris.
From: Rob Herring
Create a common header sdhci.h and move register defintions there. Set the
base address from the board init code.
The Samsung SDHCI controller has extra registers. Make them conditional
on CONFIG_MMC_S5P.
Signed-off-by: Rob Herring
---
Minkyu Kang,
Please take a look at the
Ok. It seems I (or more precise a college) have a possible solution.
>From the assembly one can see that r8 is used with a total ridiculus
value - and on ARM r8 is used to point to gd - tada.
I will test that and report back.
Regards
Simon
2011/6/14 Simon Schwarz :
> Hi again,
>
> seems that th
Hi there
We know how busy you are, so just a quick note, if we may, to let you know
about China Daily European Edition, advertising in which is now available for
the first time ever!
From China Daily, now 30 years old, as you might see it's a brand new and
exciting opportunity, especially if y
Hi Christian,
On 14/06/2011 16:27, Christian Spielberger wrote:
> we have both, a beagle xM-B and a beagle xM-C. The following works on
> both boards and is different from your patch. It is not possible to
> differentiate between Rev xM-A and xM-B. Anyway, the only difference is
> in the processor
On Tue, Jun 14, 2011 at 6:53 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message <4df7488a.6000...@ti.com> you wrote:
>>
>> Yes. I have seen those macros. But more often than not the bit field is
>> more than 1 bit wide and the value to be set is not necessarily all 0's
>> or all 1's. That's
Dear Hong Xu,
> Rework for AT91SAM9261(9G10)-EK, makes it build again.
> Based on the work for AT91SAM9260-EK.
>
>
> Signed-off-by: Hong Xu
> ---
> Makefile | 23 -
> board/atmel/at91sam9261ek/at91sam9261ek.c | 136
> +++--
> boar
From: Jason Cooper
This fixes 'EHCI timed out on TD...' on the dreamplug board.
Signed-off-by: Jason Cooper
---
include/usb.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/usb.h b/include/usb.h
index 53603a5..168e2b2 100644
--- a/include/usb.h
+++ b/include/
Dear Reinhard Meyer,
Am 12.06.2011 um 13:25 schrieb Andreas Bießmann:
> This patch sets the ATMEL_PMX_AA_TXD2 to the correct value.
>
> Signed-off-by: Andreas Bießmann
> CC: Jens Scharsig
> CC: e...@eukrea.com
this is a fix and should go into 2011.06. Jens, Eric ... any objections?
regards
MX31 Reference Manual states the following possible values for the silicon
revision:
.srev = 0x00,
.srev = 0x10,
.srev = 0x11,
.srev = 0x12,
.srev = 0x13,
.srev = 0x14,
.srev = 0x15,
.srev = 0x28,
.srev = 0x29,
However it is possible to find some pre-production silicon on some old
hardware, suc
Dear Sergey Lapin,
> Make AFEB9260 build again.
> Based on fix for AT91SAM9260EK.
>
> Signed-off-by: Sergey Lapin
> ---
> Fixed unneeded 1s in defines in board configuration
> Removed most undefs in board configuration
> Setting SoC name in board configuration
>
> board/afeb9260/afeb9260.c |
Dear Friends,
I have received several different patches reworking
"at91sam*_devices.c"
and
"at91sam9*.h".
Lokking at them, none of them is completely done the way the files for
at91sam9260 are done.
Examples:
9260, 9263: ATMEL_ID_USART0
9261: ATMEL_ID_US0
9260 uses the CONFIG_AT91_GPIO_PULL
On 12/06/2011 13:25, Andreas Bießmann wrote:
> This patch sets the ATMEL_PMX_AA_TXD2 to the correct value.
>
> Signed-off-by: Andreas Bießmann
> CC: Jens Scharsig
> CC: e...@eukrea.com
Acked-by: Eric Bénard
Thanks !
> ---
> changes since v1:
> - fix typo in commit message
>
> arch/arm/include
Dear Simon Glass,
In message you wrote:
>
> > Looking closer, the "FIELD_VAL" macro alone will probably not suffice,
> > as you need both shift directions, like that:
> >
> >#define FIELD_SHIFT 16
> >#define FIELD_MASK 0xF
> >
> >
> >#define FIELD_BITS(x) (x << 16
When specified in the flags argument of nand_write, WITH_YAFFS_OOB causes an
operation which is mutually exclusive with the 'usual' way of writing.
Add a check that client code does not specify WITH_YAFFS_OOB along with any
other flags and add a comment indicating that the WITH_YAFFS_OOB flag shou
This series adds a nand write variant which implements the procedure
reccomended in the UBI FAQ [1] of dropping trailing pages of eraseblocks
containing entirely 0xff's.
[1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo
Changes since v3:
* rebased to nand-flash/next where patche
Add a flag to nand_read_skip_bad() such that if true, any trailing
pages in an eraseblock whose contents are entirely 0xff will be
dropped.
The implementation is via a new drop_ffs() function which is
based on the function of the same name from the ubiformat
utility by Artem Bityutskiy.
This is a
Add another nand write. variant, trimffs. This command will request of
nand_write_skip_bad() that all trailing all-0xff pages will be
dropped from eraseblocks when they are written to flash as-per the
reccommended behaviour of the UBI FAQ [1].
The function that implements this timming is the drop_
On Wed, Jun 15, 2011 at 2:31 AM, Fabio Estevam
wrote:
> MX31 Reference Manual states the following possible values for the silicon
> revision:
>
> .srev = 0x00,
> .srev = 0x10,
> .srev = 0x11,
> .srev = 0x12,
> .srev = 0x13,
> .srev = 0x14,
> .srev = 0x15,
> .srev = 0x28,
> .srev = 0x29,
>
> Howe
Rework for AT91SAM9RL SoC, makes it build again.
Based on the work for AT91SAM9260-EK.
Signed-off-by: Hong Xu
---
Changes since V2
- No at91_serial_hw_init, no CONFIG_USARTx anymore.
- Removed SZ_* macros - though I don't have the reason found in code :)
- Add definitions for all ATMEL_BASE_CSx
Rework for AT91SAM9RL-EK, makes it build again.
Based on the work for AT91SAM9260-EK.
Signed-off-by: Hong Xu
---
Makefile| 12
board/atmel/at91sam9rlek/at91sam9rlek.c | 73 --
board/atmel/at91sam9rlek/config.mk |1 -
board
Dear Rob Herring,
On 14 June 2011 23:48, Rob Herring wrote:
> arch/arm/include/asm/arch-s5pc1xx/mmc.h | 73
> --
> arch/arm/include/asm/arch-s5pc2xx/cpu.h | 4 ++
> arch/arm/include/asm/arch-s5pc2xx/mmc.h | 73
> --
> board/sams
Hi Reinhard,
On 06/14/2011 08:43 PM, Reinhard Meyer wrote:
> Dear Hong Xu,
> > Rework for AT91SAM9263 SoC, makes it build again.
> > Based on the work for AT91SAM9260-EK.
> >
> > Signed-off-by: Hong Xu
> > ---
> > arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 2 +-
> > arch/arm/cpu/arm926ej
Dear Fabio Estevam,
In message <1308069108-5438-1-git-send-email-fabio.este...@freescale.com> you
wrote:
...
> However it is possible to find some pre-production silicon on some old
> hardware, such as MX31ADS
> that shows srev = 0x20.
>
> The following message is the currently displayed on suc
On 06/14/2011 06:31 PM, Fabio Estevam wrote:
> MX31 Reference Manual states the following possible values for the silicon
> revision:
>
Hi Fabio,
> However it is possible to find some pre-production silicon on some old
> hardware, such as MX31ADS
> that shows srev = 0x20.
>
> The following me
47 matches
Mail list logo
