Hello Lei,
Lei Wen wrote:
> Add i2c support to dkb board with pantheon soc.
>
> Signed-off-by: Lei Wen
> ---
> arch/arm/cpu/arm926ejs/pantheon/cpu.c| 10 ++
> arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
> arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
> board/Marvel
Hello Lei,
Lei Wen wrote:
> Signed-off-by: Lei Wen
> ---
> arch/arm/cpu/pxa/cpu.c | 11 +++
> arch/arm/include/asm/arch-pxa/pxa-regs.h | 56
> board/innokom/innokom.c |9 +--
> drivers/i2c/mvi2c.c | 139
>
Hello Lei,
Lei Wen wrote:
> For better sharing with other platform other than pxa's,
> it is more convenient to put the driver to the common place.
>
> Signed-off-by: Lei Wen
> ---
> Changelog:
> v2: rename previous pxa_i2c to mvi2c.
Maybe a Coding Style cleanup would be good for this file ...
The following changes since commit cc1dd33f273f8c96cbd7539b4a2d1d7aa12773cd:
mpc8[5/6]xx: Ensure POST word does not get reset (2011-03-13 11:24:44 -0500)
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx.git master
Kumar Gala (1):
powerpc/85xx: Fix synchronizatio
On Mar 15, 2011, at 1:25 AM, Kumar Gala wrote:
> There is a small ordering issue in the master core in that we need to
> make sure the disabling of the timebase in the SoC is visible before we
> set the value to 0. We can simply just read back the value to
> synchronizatize the write, before we
Hi,
On Tue, Mar 15, 2011 at 11:07:46, Sanjeeva Kumara wrote:
> Hi pls help me...
> How the boot image is read into memory from where exactly execution
> starts...
>
1. what is your board configuration (memory, Processor, ram, etc..)
2. Is your board inside u-boot repository ?. what is t
There is a small ordering issue in the master core in that we need to
make sure the disabling of the timebase in the SoC is visible before we
set the value to 0. We can simply just read back the value to
synchronizatize the write, before we set TB to 0.
Reported-by: Dan Hettena
Tested-by: Dan Het
On Mar 14, 2011, at 4:37 PM, Scott Wood wrote:
> On Mon, 14 Mar 2011 16:25:54 -0500
> Kumar Gala wrote:
>
>>
>> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>>
>>> On Sat, 12 Mar 2011 16:56:09 -0600
>>> Kumar Gala wrote:
>>>
On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
On Mar 14, 2011, at 2:39 PM, Jimi Xenidis wrote:
> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>>
>> On Sat, 12 Mar 2011 16:56:09 -0600
>> Kumar Gala wrote:
>>
>>>
>>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>>>
I was surprised to find myself at the decrement interrupt when r
This patch enables compiler debug option for powerpc platforms
by default. Patch is tested on 85xx/QorIQ platforms in u-boot
with CodeWarrior.
Signed-off-by: Roy Zang
Cc: Wood Scott-B07421
Cc: Kumar Gala
---
Consider the comments
http://lists.denx.de/pipermail/u-boot/2010-October/080689.html
Loic,
On Monday 14 March 2011 09:41 PM, Loïc Minier wrote:
> On Mon, Mar 14, 2011, Aneesh V wrote:
>> +- ARM Options:
>> +CONFIG_SYS_THUMB_BUILD
>> +
>> +Use this flag to build U-Boot using the Thumb instruction
>> +set for ARM architectures. Thumb instruction s
For better sharing with other platform other than pxa's,
it is more convenient to put the driver to the common place.
Signed-off-by: Lei Wen
---
Changelog:
v2: rename previous pxa_i2c to mvi2c.
arch/arm/cpu/pxa/Makefile |1 -
arch/arm/cpu/pxa/i2c.c| 469
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/armada100/cpu.c| 14 ++
arch/arm/include/asm/arch-armada100/mfp.h |4
board/Marvell/aspenite/aspenite.c |5 +
include/configs/aspenite.h| 12
4 files changed, 35 insertions(
Signed-off-by: Lei Wen
---
drivers/i2c/mvi2c.c | 37 -
1 files changed, 36 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/mvi2c.c b/drivers/i2c/mvi2c.c
index 0e37417..ca1add8 100644
--- a/drivers/i2c/mvi2c.c
+++ b/drivers/i2c/mvi2c.c
@@ -131,9 +131,3
Add i2c support to dkb board with pantheon soc.
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/pantheon/cpu.c| 10 ++
arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
board/Marvell/dkb/dkb.c |4
i
Signed-off-by: Lei Wen
---
arch/arm/cpu/pxa/cpu.c | 11 +++
arch/arm/include/asm/arch-pxa/pxa-regs.h | 56
board/innokom/innokom.c |9 +--
drivers/i2c/mvi2c.c | 139 +-
include/configs/innoko
V2:
rename the previous pxa_i2c to mvi2c, since this driver would be shared
by many other Marvell platforms.
Lei Wen (5):
pxa: move i2c driver to the common place
mvi2c: use structure to replace the direclty define
I2C: add i2c support for Pantheon platform
I2C: mvi2c: add multi bus suppor
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> diff --git a/Makefile b/Makefile
> index dc2e3d8..758daf2 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1093,6 +1093,19 @@ smdk6400_config: unconfig
> @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
>
> #
Some board of SH does not have flash memoy.
This revises it to initialize Flash when CONFIG_SYS_NO_FLASH is not
defined.
Signed-off-by: Nobuhiro Iwamatsu
Signed-off-by: Nobuhiro Iwamatsu
---
arch/sh/lib/board.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> arch/mips/cpu/xburst/Makefile| 50 +++
> arch/mips/cpu/xburst/config.mk | 33 ++
> arch/mips/cpu/xburst/cpu.c | 160
> arch/mips/cpu/xburst/jz4740.c| 264
> arch/mips/cpu/xburst/jz_serial.c | 114 +
> arc
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> this is jz4740 base head file
>
> Signed-off-by: Xiangfu Liu
> Acked-by: Daniel
> ---
> Changes for v2:
> - remove useless code, prepare for using io.h
> - delete all base + offset. using C struct
>
> arch/mips/include/asm/jz4740.h | 1102
On 02/28/2011 03:57 PM, Xiangfu Liu wrote:
> diff --git a/arch/mips/cpu/xburst/jz_serial.c
> b/arch/mips/cpu/xburst/jz_serial.c
> new file mode 100644
> index 000..65ce993
> --- /dev/null
> +++ b/arch/mips/cpu/xburst/jz_serial.c
[...]
> +/*
> + * serial_init - initialize a channel
> + *
> + *
Dear Wolfgang,
On 14 March 2011 04:50, Wolfgang Denk wrote:
> Dear Minkyu Kang,
>
> In message <4d75b591.3040...@samsung.com> you wrote:
>> If FB address is defined specific address then don't grab memory for LCD
>>
>> Signed-off-by: Minkyu Kang
>> Cc: Albert Aribaud
>> ---
>> arch/arm/lib/boa
Hi Prafulla,
On Mon, Mar 14, 2011 at 8:03 PM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Lei Wen [mailto:lei...@marvell.com]
>> Sent: Monday, March 14, 2011 3:46 PM
>> To: u-boot@lists.denx.de; Marek Vasut; Prafulla Wadaskar; Lei Wen
>> Subject: [PATCH 1/8] pxa: move i2c
Seperating the SOCs solves most of my problems with the exception of board.c,
but then again, we're rather a special case there due to some of the stuff we
do.
Not counting our SDK we have around 27Kloc for our platform, a large chunk of
that being DDR2/3 memory initialization code. Our SDK cur
On 3/15/11 6:14 AM, daniel.schwierz...@googlemail.com wrote:
> Replace the current MIPSFLAGS code by cc-option macro and use
> -march=mips32r2 as default optimization level for all Mips32 CPUs.
> Replace the endianess determination code from toolchain prefix by
> a more generic one inspired by the
On Mon, Mar 14, 2011 at 6:28 PM, Wolfgang Denk wrote:
>> We are trying to access the I2C bus before relocation from flash to read
>> switch settings. Using the current CONFIG_SYS_SPD_BUS_NUM define to do this
>> is fine for our needs however I would like to ask if we wanted to change
>> this to a
Wolfgang Denk wrote:
> Looks as if this was a Freescale specific implementation?
Yes.
> Can this not be turned into generic code, usable for other boards /
> systems as well?
Possibly, but I would like to fix one bug at a time.
> Please see the discussion we had about video modes for the i.MX
>
Dear Timur Tabi,
In message <1300133949-1115-1-git-send-email-ti...@freescale.com> you wrote:
> Update the "monitor" environment variable (for Freescale chips that have a
> DIU display controller) to designate the full video configuration, instead
> of just the output monitor.
>
> The old definit
Dear Matthew McClintock,
In message <1300135645-21544-1-git-send-email-...@freescale.com> you wrote:
> The bus that the i2c api can access before relocating from flash
> is defined via CONFIG_SYS_SPD_BUS_NUM, however we want to use
> the i2c bus before relocating from flash for non-SPD related
> r
Peter,
On Mon, Mar 14, 2011 at 3:20 PM, Peter Tyser wrote:
> Hi Tom,
>
>
>
>> >> +static void init_pll_x(void)
>> >> +{
>> >> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr *)NV_PA_CLK_RST
>> >> _BASE;
>> >> + u32 reg;
>> >
>> > The spaces in front of "reg" can be removed. Di
Hi Tom,
> >> +static void init_pll_x(void)
> >> +{
> >> + struct clk_rst_ctlr *clkrst = (struct clk_rst_ctlr
> >> *)NV_PA_CLK_RST_BASE;
> >> + u32 reg;
> >
> > The spaces in front of "reg" can be removed. Ditto for all
> > functions/variables.
> Not sure what you mean, here, Peter.
Dear "Moffett, Kyle D",
In message <44a75130-ed4f-46d6-b0e4-12433cc15...@boeing.com> you wrote:
>
> Oh, absolutely. I do think there still needs to be a separation
> between a "normal user-initiated restart" and an "panic-time
> emergency restart" though, see further on in this email.
These term
On Mon, 14 Mar 2011 16:25:54 -0500
Kumar Gala wrote:
>
> On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>
> > On Sat, 12 Mar 2011 16:56:09 -0600
> > Kumar Gala wrote:
> >
> >>
> >> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
> >>
> >>> I was surprised to find myself at the decrement int
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
>
> Since all of the inputs to this are 32-bit (
On Mar 14, 2011, at 16:22, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> + * Now divide by 5^12 and track the 32-bit remainder, then divide
>> + * by 2*(2^12) using shifts (and updating the remainder).
>> + */
>> +clks_rem = do_div(clks, UL_5pow12);
>>
On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
> On Sat, 12 Mar 2011 16:56:09 -0600
> Kumar Gala wrote:
>
>>
>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>>
>>> I was surprised to find myself at the decrement interrupt when running my
>>> new stuff.
>>> That is against ePAPR, right?
>>
IncaIP is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Wolfgang Denk
---
arch/mips/cpu/mips32/Makefile|2 -
arch/mips/cpu/mips32/incaip/M
On Mar 14, 2011, at 16:38, Wolfgang Denk wrote:
> In message <613c8f89-3ce5-4c28-a48e-d5c3e8143...@boeing.com> you wrote:
>>
>> If just *one* of the 2 CPUs triggers the reset then only *some* of
>> the attached hardware will be properly reset due to a hardware
>> errata, and as a result the board
Peter,
On Mon, Mar 14, 2011 at 8:33 AM, Peter Tyser wrote:
> Hi Tom,
> I'm not too familiar with the architecture, so many comments are
> aesthetic. It would be a good idea to run the patch through
> checkpatch.pl too.
I run checkpatch on every submission. Only 1 warning was generated
(about an
The current Mips CPU config.mk code always expects a Mips 4kc
core and toolchain. This is not appropiate for other toolchains
and CPUs/SoCs.
Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Replace the endianess determ
Au1x00 is a SoC and its specific code should reside in an own
SoC subdirectory. Also add -mtune=4kc flag for CPU optimization.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Thomas Lange
---
arch/mips/cpu/mips32/Makefile |2 -
arch/mips/cpu/mips32/au1x00/
All current CPUs and SoCs are based on Mips32 arch. The complete
code resides in the global arch/mips/cpu directory. This is not
suitable if other Mips architectures like Mips64 or Octeon should
be supported in the future.
To achieve this the current CPU code is moved to its own mips32
subdirector
The Purple SoC and eval board are not actively maintained since years.
This patch removes the support completely as aggreed with Wolfgang Denk.
Signed-off-by: Daniel Schwierzeck
Cc: Shinya Kuribayashi
Cc: Wolfgang Denk
---
MAINTAINERS |1 -
MAKEALL
All current Mips CPUs and SoCs except Purple are based on Mips32 arch.
The complete code resides in the global arch/mips/cpu directory.
All SoC specific code resides in this directory too. This is not suitable
if other Mips architectures like Mips64 or Octeon or new SoCs should be
supported in the
The bus that the i2c api can access before relocating from flash
is defined via CONFIG_SYS_SPD_BUS_NUM, however we want to use
the i2c bus before relocating from flash for non-SPD related
reasons. Therefore, we rename this define to something more
appropriate
---
We are trying to access the I2C bu
Dear "Moffett, Kyle D",
In message <613c8f89-3ce5-4c28-a48e-d5c3e8143...@boeing.com> you wrote:
>
> On our boards, when the "reset" button is pressed in hardware, both
> processor modules on the board and all the attached hardware reset at
> the same time.
OK. So a sane design would provide a wa
Update the "monitor" environment variable (for Freescale chips that have a
DIU display controller) to designate the full video configuration, instead
of just the output monitor.
The old definition of the "monitor" environment variable only determines
which video port to use for output. This varia
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> + * Now divide by 5^12 and track the 32-bit remainder, then divide
> + * by 2*(2^12) using shifts (and updating the remainder).
> + */
> + clks_rem = do_div(clks, UL_5pow12);
> + clks_rem <<= 13;
Shouldn't this be clks
On Mar 14, 2011, at 14:19, York Sun wrote:
> On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
>> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
>> integer divide operations to convert between nanoseconds and DDR clock
>> cycles given arbitrary DDR clock frequencies.
>
On Mar 14, 2011, at 15:41, York Sun wrote:
> Kyle,
>
> On Mon, 2011-03-14 at 14:04 -0500, Moffett, Kyle D wrote:
>> On 64-bit this change is basically a no-op, because do_div() is implemented
>> as a literal 64-bit divide operation and the instruction scheduling works
>> out almost the same.
>>
Kyle,
On Mon, 2011-03-14 at 14:04 -0500, Moffett, Kyle D wrote:
> On 64-bit this change is basically a no-op, because do_div() is implemented
> as a literal 64-bit divide operation and the instruction scheduling works out
> almost the same.
>
> On 32-bit PowerPC a fully accurate 64/64 divide (_
On Mar 14, 2011, at 14:59, Wolfgang Denk wrote:
> In message you wrote:
>> My own board needs both processor modules to synchronize resets to allow
>> them to come back up at all, which means that a "reset" may block for an
>> arbitrary amount of time waiting for the other module to cleanly shut d
On Mar 14, 2011, at 1:09 PM, Scott Wood wrote:
>
> On Sat, 12 Mar 2011 16:56:09 -0600
> Kumar Gala wrote:
>
>>
>> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>>
>>> I was surprised to find myself at the decrement interrupt when running my
>>> new stuff.
>>> That is against ePAPR, right?
>
Dear Kumar Gala,
In message you
wrote:
> A few fixes for v2011.03 release.
>
> The following changes since commit c7977858dcf1f656cbe91ea0dc3cb9139c6a8cc8:
>
> ARM: Update mach-types (2011-02-21 08:30:55 +0100)
>
> are available in the git repository at:
> git://git.denx.de/u-boot-mpc85xx
Dear "Moffett, Kyle D",
In message you wrote:
>
> >> The new wrapper functions are:
> >> system_restart() - Normal system reboot (IE: user request)
> >> emergency_restart() - Critical error response (IE: panic(), etc)
> >
> > What is the difference between these two - and why do we nee
On Mon, 2011-03-14 at 12:38 -0400, Kyle Moffett wrote:
> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header. This dramatically improves the
> readability of the switch statments.
>
> In addition, a few of the longer lines were cleaned up
On Mon, 2011-03-14 at 12:38 -0400, Kyle Moffett wrote:
> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header. This dramatically improves the
> readability of the switch statments.
>
> In addition, a few of the longer lines were cleaned up
On Sat, 12 Mar 2011 16:56:09 -0600
Kumar Gala wrote:
>
> On Mar 3, 2011, at 8:59 AM, Jimi Xenidis wrote:
>
> > I was surprised to find myself at the decrement interrupt when running my
> > new stuff.
> > That is against ePAPR, right?
> > Does u-boot at least make sure that the DEC is set to so
On Thu, 2011-03-10 at 16:54 -0600, Peter Tyser wrote:
> From: John Schmoller
>
> The JEDEC DDR3 specification states that the above parameters should
> be set to a minimum of 4 clocks. The SPD defines the values in
> nanoseconds, and depending on the clock frequency the value in the
> SPD can be
On Wed, 2011-02-23 at 11:35 -0500, Kyle Moffett wrote:
> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
>
> Since all of the inputs to this are 32-bit (
The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis
with 3 independent TEMPEST zones. Two independent P2020 computers may
be found inside each zone. Complete hardware support is included.
High-level hardware overview:
* DO-160 certified for passenger aircraft (noncritical)
* T
The numeric constants in the switch statements are replaced by #defines
added to the common ddr_spd.h header. This dramatically improves the
readability of the switch statments.
In addition, a few of the longer lines were cleaned up, and the DDR2
type for an SO-RDIMM module was added to the DDR2
To ease the implementation of other MPC85xx board ports, several common
GPIO helpers are added to .
Since each of these compiles to no more than 4-5 instructions it would
be very inefficient to call them out of line, therefore we put them
entirely in the header file.
The HWW-1U-1A board port whic
This is the latest respin of the eXMeritus HWW-1U-1A board support patches.
It's down to just a 3-patch series, with all of the other patches submitted
separately.
This series techncially depends on the reset rework, the "reset" command
will not work properly on the HWW-1U-1A hardware without thos
Hi!
On Mar 13, 2011, at 15:24, Wolfgang Denk wrote:
> In message <1299519462-25320-2-git-send-email-kyle.d.moff...@boeing.com> you
> wrote:
>> In preparation for making system restart use a generic set of hooks for
>> boards and architectures, we define some wrappers and weak stubs.
>>
>> The ne
On Mon, Mar 14, 2011, Aneesh V wrote:
> +- ARM Options:
> + CONFIG_SYS_THUMB_BUILD
> +
> + Use this flag to build U-Boot using the Thumb instruction
> + set for ARM architectures. Thumb instruction set provides
> + better code density. For ARM archite
Albert,
On Sun, Mar 13, 2011 at 10:46 AM, Albert ARIBAUD wrote:
> Le 16/02/2011 21:26, Tom Warren a écrit :
>>
>> Signed-off-by: Tom Warren
>> ---
>> arch/arm/cpu/armv7/start.S | 6 +
>> arch/arm/cpu/armv7/tegra2/Makefile | 2 +-
>
>> arch/arm/cpu/armv7/tegra2/ap20.
Hi Tom,
I'm not too familiar with the architecture, so many comments are
aesthetic. It would be a good idea to run the patch through
checkpatch.pl too.
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index 684f2d2..50a1725 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b
Some ubi commands returned negative error codes, resulting in
the following error message on the prompt:
"exit not allowed from main input shell."
Negative error codes are not allowed.
This patch now changes the UBI code to return positive error codes.
Additionally "better" error codes are used,
Hi David,
It'd be good to include "smdk2410" in this patch titles, eg "smdk2410:
Various cleanups/code style fixes". or "arm: smdk2410: Various..."
Without the prefix, its unclear what code these patches affect, and
somewhat implies you are changing common code.
> -#define CONFIG_RTC_S3C24
On 03/14/11 14:37, Stefano Babic wrote:
> On 03/14/2011 02:15 PM, Elie De Brauwer wrote:
>> Hi List,
>>
>> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept
>> ending with a natively compiled version of fw_printenv. When looking at
>> the tools/env/Makefile I saw it was using $(
Dear Elie De Brauwer,
In message <4d7e14ed.1050...@gmail.com> you wrote:
>
> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept
> ending with a natively compiled version of fw_printenv. When looking at
> the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly
On 03/14/2011 02:15 PM, Elie De Brauwer wrote:
> Hi List,
>
> I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept
> ending with a natively compiled version of fw_printenv. When looking at
> the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly
> ever since:
Signed-off-by: Aneesh V
---
README |9 +
arch/arm/cpu/armv7/config.mk |5 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/README b/README
index f1547a4..ff3a345 100644
--- a/README
+++ b/README
@@ -370,6 +370,15 @@ The following options
Enable -march=armv7-a and Thumb build for OMAP4. This results in
Thumb2 code generated for OMAP4.
The newly added compiler switches are put under cc-option so
that it doesn't break old compilers.
Signed-off-by: Aneesh V
---
arch/arm/cpu/armv7/omap4/config.mk | 25 +
in
Hi List,
I tried crosscompiling fw_printenv lately (on 2011.03 RC1) but I kept
ending with a natively compiled version of fw_printenv. When looking at
the tools/env/Makefile I saw it was using $(HOSTCC) and friends, basicly
ever since:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=abd315a135
Dear Daniel Schwierzeck,
In message you
wrote:
>
> > OTOH, the purple board has not been actively maintained for several
> > years, and I'm not aware of anybody who still has access to the
> > hardware. =C2=A0If it should cause trouble, it would probably most
> > appropriate to drop the purple
Dear Heiko,
In message <4d7dc1c1.4060...@denx.de> you wrote:
>
> >> + im->sysconf.ddrlaw[0].bar = CONFIG_SYS_DDR_BASE & LAWBAR_BAR;
> >> + msize = fixed_sdram ();
> >
> > Can we not use get_ram_size() ?
>
> fixed_sdram calls this.
I see, thanks.
> > I see this:
> >
> > [PATCH 01/20] keymil
Hello Wolfgang,
2011/3/13 Wolfgang Denk :
> Dear Daniel Schwierzeck,
>
> In message <4d7c147a.5060...@gmail.com> you wrote:
>>
>> >> All current CPUs and SoCs are based on Mips32 arch. The complete
>> >
>> > Is that true? What about purple SoC? IIUC It's based on MIPS 5Kc
>> > and capable of 64-bi
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Monday, March 14, 2011 3:46 PM
> To: u-boot@lists.denx.de; Marek Vasut; Prafulla Wadaskar; Lei Wen
> Subject: [PATCH 1/8] pxa: move i2c driver to the common place
>
> For better sharing with other platform other tha
On 03/12/2011 02:15 PM, Anatolij Gustschin wrote:
> The reason for using wrsr register is that when reading this register,
> we can also recognize the software reset cause (SWFT, bit 0 is set).
> In our use case we have this requirement.
Ok, understood.
>> I do not think printing the reset cause
On Mar 14, 2011, at 1:27 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message you
> wrote:
>>
We don't use disable_law in the SPL code so only build it if
!CONFIG_NAND_SPL.
>>>
>>> Does -ffunction-sections / --gc-sections not catch this automatically?
>>
>> Doesn't appear to
Add support for the Ethernut 5 open hardware design, based
on Atmel's AT91SAM9XE512 SoC.
Signed-off-by: Harald Kipp
---
V2:
- Fix several coding style issues.
- Remove Ethernet MAC address from default environment.
MAINTAINERS |3 +
board/egnite/ethernut5/Ma
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/armada100/cpu.c| 14 ++
arch/arm/include/asm/arch-armada100/mfp.h |4
board/Marvell/aspenite/aspenite.c |5 +
include/configs/aspenite.h| 12
4 files changed, 35 insertions(
For better sharing with other platform other than pxa's,
it is more convenient to put the driver to the common place.
Signed-off-by: Lei Wen
---
arch/arm/cpu/pxa/Makefile |1 -
arch/arm/cpu/pxa/i2c.c| 469 -
drivers/i2c/Makefile |1 +
Signed-off-by: Lei Wen
---
drivers/i2c/pxa_i2c.c | 38 --
include/configs/dkb.h |4 +++-
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/pxa_i2c.c b/drivers/i2c/pxa_i2c.c
index 0e37417..17b83ab 100644
--- a/drivers/i2c/pxa_i2c.
Signed-off-by: Lei Wen
---
arch/arm/cpu/pxa/cpu.c | 11 +++
arch/arm/include/asm/arch-pxa/pxa-regs.h | 56
board/innokom/innokom.c |9 +--
drivers/i2c/pxa_i2c.c| 139 +-
include/configs/innoko
Add i2c support to dkb board with pantheon soc.
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/pantheon/cpu.c| 10 ++
arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
arch/arm/include/asm/arch-pantheon/mfp.h |2 ++
board/Marvell/dkb/dkb.c |4
i
Hi,
2011/3/13 Wolfgang Denk :
> Dear Nobuhiro Iwamatsu,
>
> In message
> <1299484258-6042-1-git-send-email-nobuhiro.iwamatsu...@renesas.com> you wrote:
>> Some board of SH does not have flash memoy.
>> This change initializes bi_flashstart, when CONFIG_SYS_FLASH_BASE was
>> defined,
>>
>> Signed
On 3/13/2011 12:41 PM, Harald Kipp wrote:
> Add support for the Ethernut 5 open hardware design, based on Atmel's
> AT91SAM9XE512 SoC.
NAK.
Too many trailing whitespaces and some more style issues. I haven't been
aware of the checkpatch script.
Regards,
Harald
PS: Seems to become a confirmed
Hello Wolfgang,
Wolfgang Denk wrote:
> Dear Heiko Schocher,
>
> In message <1299591018-8944-3-git-send-email...@denx.de> you wrote:
>> - serial console on UART1
>> - Ethernet RMII over UCC4
>> - PHY SMSC LAN8700
>> - 64MB Flash
>> - 128 MB DDR2 RAM
>> - I2C
>> - bootcount
>>
>> This board is simi
Hello Wolfgang,
Wolfgang Denk wrote:
> In message <1299591018-8944-2-git-send-email...@denx.de> you wrote:
>> - This patch reworks all headerfiles for keymile boards (coge, supx4,
>> eter1, suen3).
>> Furthermore, a refactoring on the whole environment variables has been
>> acomplished.
>
>
93 matches
Mail list logo
