Dear Albert ARIBAUD,
Am 24.01.2011 um 08:24 schrieb Albert ARIBAUD:
> Le 24/01/2011 02:42, J. William Campbell a écrit :
>
>> Hi All,
>>In order to avoid doing 64 bit math, we can define a "jiffie"
>> or a "bogo_ms" that is the 64 bit timebase shifted right such that the
>> lsb of th
config.mk in board directory is obsolete and should be removed.
The patch allows to get rid of own config.mk adding the imximage.cfg
file to the options in the boards.cfg
Signed-off-by: Stefano Babic
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile
The config.mk file in board directory is now obsolete and
should be removed. Add option for the IMX image into
boards.cfg
Signed-off-by: Stefano Babic
---
board/freescale/mx51evk/config.mk | 25 -
boards.cfg|2 +-
include/configs/mx51evk.h
Hello Reinhard,
...
>>
>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>> very end
>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>> AT91Bootstrap
>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the very begin
>> of DRAM
>> for our boa
Hi Andreas,
Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>> That's where I come back to one point of my proposal: if we can get a
>> general framework for get_timer() to return a 64-bit free-running tick
>> value, then we might not need a ms-based get_time() at all, because we
>> could use get
Le 24/01/2011 12:58, Albert ARIBAUD a écrit :
> For instance, if at loop entry get_timer() was, say, 10 ticks to
> rollover and the loop timing was 12 ticks, you end up with an end date
> of 2. If your loop body runs long enough, get_timer() may already have
> gone past this and will this stay gre
Dear Daniel Gorsulowski,
> Hello Reinhard,
>
> ...
>>>
>>> Check that your AT91Bootstrap loads u-boot to a sane address not at the
>>> very end
>>> of DRAM, and that CONFIG_SYS_TEXT_BASE is exactly the address where
>>> AT91Bootstrap
>>> loads u-boot. (I changed AT91Bootstrap to load u-boot to the
Hi
I am trying to boot a MPC8XXX based board using uboot version 1.1.3.
I am able to get the serial console up. But when I try to ping it
gives me a time out error.
On trying "mii info" and enabling debug messages I see that all the
mii read messages are
returning 0x. Could any one please sugg
Dear Haiying Wang,
In message <1295840749.2196.3.camel@haiying-laptop> you wrote:
>
> > > +#ifdef CONFIG_FSL_CORENET
> > > + return (gd->bus_clk + 8) / 16;
> > > +#else
> > > + return (gd->bus_clk + 4UL)/8UL;
> > > +#endif
> >
> > This looks inconsistent. Either this should be "... +8UL) / 16UL"
On 01/24/2011 01:12 PM, saugat mitra wrote:
> Hi
>
Hi,
> I am trying to boot a MPC8XXX based board using uboot version 1.1.3.
> I am able to get the serial console up. But when I try to ping it
> gives me a time out error.
> On trying "mii info" and enabling debug messages I see that all the
> m
Although most IDE controller is designed to be connected to PCI bridge,
there are still some IDE controller support AHB interface for SoC design.
The driver implementation of these IDE-AHB controllers differ from other
IDE-PCI controller, some additional registers and commands access is required
d
Faraday's ftide020_s is an IDE-AHB controller for SoC design.
This patch ported the u-boot driver (PIO) of ftide020 ATA (IDE) driver
from Linux kernel. IDE commands include read, info, and other functions
has been implemented.
Because this IDE controller support AHB interface only which is differ
Dear Haiying Wang,
In message <1295842861.2196.38.camel@haiying-laptop> you wrote:
> On Sat, 2011-01-22 at 23:04 +0100, Wolfgang Denk wrote:
> > > diff --git a/Makefile b/Makefile
> > > index 87a383d..94af465 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -290,6 +290,10 @@ LDPPFLAGS +=
Dear Albert ARIBAUD,
In message <4d3d2942.4060...@free.fr> you wrote:
>
> - get_timer() works in pure ticks, not ms, and thus does not need
> multiply/divide; it may at most need to implement a carry over from 32
> bit to 64 bits *if* the HW counter is 32 bits *and if* we want a 64-bit
> virtual c
Hi Albert,
Am 24.01.2011 12:58, schrieb Albert ARIBAUD:
> Hi Andreas,
>
> Le 24/01/2011 09:25, Andreas Bießmann a écrit :
>
>>> That's where I come back to one point of my proposal: if we can get a
>>> general framework for get_timer() to return a 64-bit free-running tick
>>> value, then we migh
Dear Reinhard Meyer,
In message <4d3d2f34.6020...@emk-elektronik.de> you wrote:
> Dear all,
>
> its quite funny to see how we go around in circles here, this proposal of
> Albert
> now is quite close to my original proposal. Only that I factored the
> ms_to_ticks
> AND the comparison into the t
Dear Albert ARIBAUD,
In message <4d3d2942.4060...@free.fr> you wrote:
>
> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't >
> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would >
> not go through the full 32-bit range, which would cause issues with the
Dear Albert ARIBAUD,
In message <4d3b3cb9.2060...@free.fr> you wrote:
>
> > Thanks - but I also think that Dirk's proposal to create a v2010.12.1
> > bug fix release makes sense. What do you think?
>
> I didn't comment on this point as it was not for me to decide upon
> releasing an interim U-b
On 01/19/11 23:19, Tom Warren wrote:
> Signed-off-by: Tom Warren
> ---
> Changes for V2:
> - Coding style cleanup
> - Move serial driver changes to separate patch
> - Use board/nvidia/ instead of /board/tegra
> - Remove TRUE/FALSE defines
> - Use standard NS
On 01/19/11 23:19, Tom Warren wrote:
> Signed-off-by: Tom Warren
> ---
> Changes for V2:
> - Use board/nvidia/ instead of /board/tegra
> - Change nv-common.h config file to tegra2-common.h
>
> MAINTAINERS |4 +
> board/nvidia/harmony/Makefile | 50
Using optimized versions of memset and memcpy from linux brings a quite
noticeable speed (x2 or better) improvement for these two functions.
Size impact:
C version:
textdata bss dec hex filename
202862 18912 266456 488230 77326 u-boot
ASM version:
textdata bs
Dear Matthias Weisser,
In message <1295884607-9044-1-git-send-email-weiss...@arcor.de> you wrote:
> Using optimized versions of memset and memcpy from linux brings a quite
> noticeable speed (x2 or better) improvement for these two functions.
>
> Size impact:
>
> C version:
>textdata
On 1/24/2011 5:02 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4d3d2942.4060...@free.fr> you wrote:
>> That is assuming a 64-bit timebase, isn't it? for CPUs / SoCs that don't>
>> have such a timebase but only a 32-bit timer, the bogo_ms/jiffy would>
>> not go through the full 32
Mike,
On Mon, Jan 24, 2011 at 4:55 AM, Mike Rapoport wrote:
> On 01/19/11 23:19, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Coding style cleanup
>> - Move serial driver changes to separate patch
>> - Use board/nvidia/ instead of /board/t
Mike,
On Mon, Jan 24, 2011 at 4:58 AM, Mike Rapoport wrote:
> On 01/19/11 23:19, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Use board/nvidia/ instead of /board/tegra
>> - Change nv-common.h config file to tegra2-common.h
>>
>> MAINTAINERS
Peter,
On Fri, Jan 21, 2011 at 4:46 PM, Peter Tyser wrote:
> Hi Tom,
>
> On Fri, 2011-01-21 at 16:06 -0700, Tom Warren wrote:
>> Signed-off-by: Tom Warren
>> ---
>> Changes for V2:
>> - Move serial driver to separate patch
>>
>> Changes for V5:
>> - Move arch/arm/cpu/armv7/uart.c & b
> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
> > moved in this patch. It'd be ideal to just add them once in the proper
> > location.
> >
> > On a side note, if you pass "git format-patch" the -M and -C options it
Peter,
On Mon, Jan 24, 2011 at 10:51 AM, Peter Tyser wrote:
>
>
>> > It looks like arch/arm/cpu/armv7/tegra2/board.h and
>> > arch/arm/cpu/armv7/tegra2/uart.c are added in the first patch, then
>> > moved in this patch. It'd be ideal to just add them once in the proper
>> > location.
>> >
>> >
Le 24/01/2011 14:03, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4d3b3cb9.2060...@free.fr> you wrote:
>>
>>> Thanks - but I also think that Dirk's proposal to create a v2010.12.1
>>> bug fix release makes sense. What do you think?
>>
>> I didn't comment on this point as it was n
According with this discussion [1] the new assemblers need
-march=armv7-a+sec on command line or .arch_extension sec inline to
enable use of the smc instruction.
In the sakoman's u-boot repository there is branch for the omap4 [2]
which uses the smc instruction with the -march=armv7-a, and it will
Dear Mike Rapoport,
In message <4d3d68a9.4040...@compulab.co.il> you wrote:
>
> Besides, since you're using I/O accessors anyway, the struct can replaces with
> base address and offset definitions.
We do not allow such construtcs in U-Boot. With C structs, you can
have proper type checking by the
On Mon, 2011-01-24 at 19:36 +0100, Víctor Manuel Jáquez Leal wrote:
> According with this discussion [1] the new assemblers need
> -march=armv7-a+sec on command line or .arch_extension sec inline to
> enable use of the smc instruction.
>
> In the sakoman's u-boot repository there is branch for the
Dear Tom Warren,
In message <1295651217-32421-2-git-send-email-twar...@nvidia.com> you wrote:
> Signed-off-by: Tom Warren
>...
...
> +/* Clock/Reset Controller (CLK_RST_CONTROLLER_) regs */
> +typedef volatile struct clk_rst_ctlr {
...
> +/* APB MISC Pin Mux and Tristate (APB_MISC_PP_) registers
Dear Tom Warren,
In message you
wrote:
>
...
> >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
> >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
> >> +#define NV_PA_PMC_BASE 0x7000E400
> >
> > what is the purpose of NV_PA prefix here?
> NV_Physical_
Dear Peter Tyser,
In message <1295891506.2045.146.camel@petert> you wrote:
>
> > I'll use those options in the future (thanks!) to keep things cleaner.
> > Hopefully we can just go with this set of patches so I can get to the
> > other, more interesting code (drivers, A9 CPU init, etc.).
>
> Its
Dear Tom Warren,
In message you
wrote:
>
> Correct, again (need more coffee!) Your if defined construct wouldn't work
> as written, though, because CONFIG_TEGRA2_ENABLE_UARTx is always
> defined (as 0 or 1). I'd have to rework it.
Please try and avoid relying on specific values.
Rather use "#
Dear Steve Sakoman,
In message <1295895368.1999.14.camel@quadra> you wrote:
> On Mon, 2011-01-24 at 19:36 +0100, Víctor Manuel Jáquez Leal wrote:
> > According with this discussion [1] the new assemblers need
> > -march=armv7-a+sec on command line or .arch_extension sec inline to
> > enable use of
> I see what you're talking about now - I've got uart.c in 2 patch files -
> created
> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
> happened when I applied my V4 patches to a new branch to get the V5 patchset
> built. I'll fix it and resubmit.
>
> As to 0002 not
Am 24.01.2011 17:13, schrieb Wolfgang Denk:
> Dear Matthias Weisser,
>
> In message <1295884607-9044-1-git-send-email-weiss...@arcor.de> you wrote:
>> Using optimized versions of memset and memcpy from linux brings a quite
>> noticeable speed (x2 or better) improvement for these two functions.
>>
On Mon, 24 Jan 2011 13:49:19 +0100
Wolfgang Denk wrote:
> > > > + CONFIG_TPL_U_BOOT
> > > > +
> > > > + Builds a U-Boot image that contains a loader stub
> > > > (tertiary
> > > > + program loader -- TPL) that boots out of some type of
> > > > RAM,
> >
Hi,
I am new to the list, any info. Or help is appreciated!
I went through C code of Ethernet initialization of U-boot(version
u-boot-2010_09.tar.gz ) in the board of db64360 under the board name
Marvell and found that there maybe is an obvious coding error in the
function void mv64360_e
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Tim Liu
> Sent: Monday, January 24, 2011 11:27 AM
> To: u-boot@lists.denx.de
> Subject: Re: [U-Boot] board/Marvell/DB64360
>
> Hi,
>
>
>
> I am new to the list, any info. Or
Hi,
I sort of have USB device functionality working on the SAM9G45.
I mention "sort of" because I stripped the Linux driver down to a bare minimum
I would say.
It boots a kernel image over USB using tftpboot.
As mentioned before I disabled all DMA and have implemented the driver with
bits and
Dear =?ISO-8859-1?Q?Matthias_Wei=DFer?=,
In message <4d3dd1ec.7010...@arcor.de> you wrote:
>
> >> C version:
> >>textdata bss dec hex filename
> >> 202862 18912 266456 488230 77326 u-boot
> >>
> >> ASM version:
> >>textdata bss dec hex filename
> >>
Dear Scott Wood,
In message <20110124133835.5b26b...@udp111988uds.am.freescale.net> you wrote:
>
> Now, the naming could be clearer. Changing CONFIG_TPL_BOOT into
> CONFIG_TPL would make it look more like the existing SPL names. Or we
> could do something like:
>
> CONFIG_HAS_SPL /* set in all
Wolfgang (& Mike),
On Mon, Jan 24, 2011 at 12:00 PM, Wolfgang Denk wrote:
> Dear Tom Warren,
>
> In message you
> wrote:
>>
> ...
>> >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
>> >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
>> >> +#define NV_PA_PMC_BASE
Peter,
On Mon, Jan 24, 2011 at 12:14 PM, Peter Tyser wrote:
>
>
>> I see what you're talking about now - I've got uart.c in 2 patch files -
>> created
>> in 0001 and then moved in 0002. My bad - that wasn't the intent, just what
>> happened when I applied my V4 patches to a new branch to get th
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
wrote:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols
> found in archive libraries
> when linking with recent version
Le 20/12/2010 10:00, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang
>
> timer.c used static data and are called before relocation.
> Move all static variables into global_data structure. Also cleanup
> timer.c from unused stubs and make it truly use 64 bit tick values.
>
> Based on Reinhard Meyer's pa
Dear Tom Warren,
In message you
wrote:
>
> >> >> +#define NV_PA_APB_UARTD_BASE (NV_PA_APB_MISC_BASE + 0x6300)
> >> >> +#define NV_PA_APB_UARTE_BASE (NV_PA_APB_MISC_BASE + 0x6400)
> >> >> +#define NV_PA_PMC_BASE 0x7000E400
> >> >
> >> > what is the purpose of NV_PA prefix here?
> >
Le 20/12/2010 10:07, Po-Yu Chuang a écrit :
> From: Po-Yu Chuang
>
> * add CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR
> * do not update gd->bd in dram_init() because bd is unavailable then
> * move CONFIG_SYS_TEXT_BASE from config.mk to a320evb.h
> * remove config.mk
>
> Signed-off-by: Po-Yu
Dear Haiying Wang,
In message <1295906076.2051.127.camel@haiying-laptop> you wrote:
>
> > What I do not understand is what the TPL_BOOT variable in the
> > Makefile is good for. I cannot understand the current use.
>
> Well, it was used to generate the tpl image under tpl/ directory. Maybe
> TP
On Mon, 2011-01-24 at 13:49 +0100, Wolfgang Denk wrote:
> > > >
> > > > +ifeq ($(CONFIG_TPL_U_BOOT),y)
> > > > +TPL_BOOT = tpl
> > > > +endif
> > >
> > > I don't understand what the "TPL_BOOT" is good for, or how it's
> > > supposed to work.
> > TPL_BOOT works like NAND_SPL but after NAND_SPL is
> -Original Message-
> From: Lei Wen [mailto:lei...@marvell.com]
> Sent: Wednesday, January 19, 2011 12:13 AM
> To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang;
> Ashish Karkare; Prabhanjan Sarnaik; Lei Wen
> Subject: [PATCH 5/5] Pantheon: Add Board Support for Marvell
On Mon, 2011-01-24 at 23:09 +0100, Wolfgang Denk wrote:
> Dear Haiying Wang,
>
> In message <1295906076.2051.127.camel@haiying-laptop> you wrote:
> >
> > > What I do not understand is what the TPL_BOOT variable in the
> > > Makefile is good for. I cannot understand the current use.
> >
> > Well,
Dear Haiying Wang,
In message <1295907459.2051.158.camel@haiying-laptop> you wrote:
>
> > It's not the name. But you use it ina few places here, buth then hard
> > encode "tpl" in a number of other paces there. Which means that you
> > cannot change TPL_BOOT to any other value, or building would
Using the new env import command it is possible to use plain text files instead
of script-images. Plain text files are much easier to handle.
E.g. If your boot.scr contains the following:
---
setenv dvimode 1024x768-16@60
run loaduimage
run mmcboot
-
On Mon, 24 Jan 2011 23:29:45 +0100
Wolfgang Denk wrote:
> Dear Haiying Wang,
>
> In message <1295907459.2051.158.camel@haiying-laptop> you wrote:
> >
> > > It's not the name. But you use it ina few places here, buth then hard
> > > encode "tpl" in a number of other paces there. Which means tha
On Jan 24, 2011, at 2:54 PM, Timur Tabi wrote:
> On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
> wrote:
>> NOTE: This does not include the actual patch as it is too large for the
>> mailing list (418 kB).
>>
>> Before this commit, weak symbols were not overridden by non-weak symbols
>> fo
Fix the problem which cannot build the U-boot, if we only set
the CONFIG_ENV_IS_IN_SPI_FLASH.
Signed-off-by: Yoshihiro Shimoda
---
about V2:
- list sorted
include/environment.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/include/environment.h b/include/environm
Hi,
2011/1/19 Wolfgang Denk :
> Dear Yoshihiro Shimoda,
>
> In message <4d33c15c.9030...@renesas.com> you wrote:
>> The R0P7757LC0030RL board has SH7757, 256MB DDR3-SDRAM, SPI ROM,
>> Ethernet, and more.
>>
>> This patch supports the following functions:
>> - 256MB DDR3-SDRAM
>> - SPI ROM
>> -
Add support for Bluewater Systems Snapper9260/9G20 modules. The
modules are based on the AT91SAM9260 and AT91SAM9G20 processors
respectively and support NAND flash and Ethernet.
Ryan Mallon (3):
Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver.
Add support for Bluewater Systems S
Signed-off-by: Ryan Mallon
---
Makefile | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index fd21ef3..7d4ba28 100644
--- a/Makefile
+++ b/Makefile
@@ -901,6 +901,19 @@ TNY_A9260_config : unconfig
@$(MKCONFIG) -n $@ -a tny_
Signed-off-by: Ryan Mallon
---
drivers/i2c/soft_i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index 1a1809a..0a21d02 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -32,7 +32,7 @@
#endif
#if de
Signed-off-by: Ryan Mallon
---
board/bluewater/snapper9260/Makefile | 55 +
board/bluewater/snapper9260/config.mk |1 +
board/bluewater/snapper9260/snapper9260.c | 177 +
3 files changed, 233 insertions(+), 0 deletions(-)
create mode 100644 boa
LinkedIn
Jason Liu requested to add you as a connection on LinkedIn:
--
Srinath,
I'd like to add you to my professional network on LinkedIn.
- Jason
Accept invitation from Jason Liu
http://www.linkedin.com/e/fds2np-gjc5t69w-7/YhLefj14Y3m-0E8v1
Hi Prafulla,
On Tue, Jan 25, 2011 at 6:16 AM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Lei Wen [mailto:lei...@marvell.com]
>> Sent: Wednesday, January 19, 2011 12:13 AM
>> To: Wolfgang Denk; u-boot@lists.denx.de; Prafulla Wadaskar; Yu Tang;
>> Ashish Karkare; Prabhanjan
This patch set add the Pantheon soc and dkb board support.
V2:
This patch seris update the seperate mv_common part as suggested.
V3:
Fix config.h include place and copyright claim year.
V4:
Add change log to each patch.
V5:
Add doc in Readme for new CONFIG_SYS_MVFS.
code style fix.
V6:
Rebase
Since there are lots of difference between kirkwood and armada series,
it is better to seperate them but still keep the most common file
shared by all marvell platform in the mv-common configure file.
This patch move the kirkwood only driver definitoin in mv-common to
the /config.h.
This patch is
Pantheon Family processors are highly integrated SoCs
based on Sheeva_88SV331x-v5 PJ1 cpu core.
Ref:
http://www.marvell.com/products/processors/communications/marvell_pantheon_910_920_pb.pdf
SoC versions Supported:
1) PANTHEON920 (TD)
2) PANTHEON910 (TTC)
Signed-off-by: Lei Wen
Signed-off-by: Lei Wen
---
V2:
V3:
Fix copyright claim year.
V4:
Add change log to each patch.
V5:
V6:
Rebase patch on latest u-boot-marvell.git.
drivers/serial/serial.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
This patch adds the support MFP support for Marvell PANTHEON SoCs
Signed-off-by: Lei Wen
---
V2:
V3:
Fix copyright claim year.
V4:
Add change log to each patch.
V5:
coding style fix.
V6:
Rebase patch on latest u-boot-marvell.git.
arch/arm/include/asm/arch-pantheon/mfp.h | 41 +
DKB is a Development Board for PANTHEON TD/TTC(pxa920/pxa910) with
* Processor upto 806Mhz
* LPDDR1/2
* x8/x16 SLC/MLC NAND
* Footprints for eMMC & MMC x8 card
With Peripherals:
* Parallel LCD I/F
* Audio codecs (88PM8607)
* MIPI CSI-2 camera
* Marvell 88W8787 802.11n/BT module
* Marvell 2G/3G RF
Dear Ryan Mallon,
> Add support for Bluewater Systems Snapper9260/9G20 modules. The
> modules are based on the AT91SAM9260 and AT91SAM9G20 processors
> respectively and support NAND flash and Ethernet.
>
> Ryan Mallon (3):
>Add AT91SAM9G20 to list of AT91 processors in soft_i2c driver.
>Add
Dear Ryan Mallon,
> Signed-off-by: Ryan Mallon
> ---
> drivers/i2c/soft_i2c.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
> index 1a1809a..0a21d02 100644
> --- a/drivers/i2c/soft_i2c.c
> +++ b/drivers/i2c/soft_i2c
Dear Ryan Mallon,
> Signed-off-by: Ryan Mallon
> ---
> board/bluewater/snapper9260/Makefile | 55 +
> board/bluewater/snapper9260/config.mk |1 +
See comment in your patch 0/3.
> board/bluewater/snapper9260/snapper9260.c | 177
> +
> 3 fil
Dear Ryan Mallon,
> Signed-off-by: Ryan Mallon
> ---
> Makefile | 13 +
> 1 files changed, 13 insertions(+), 0 deletions(-)
New boards must be added to boards.cfg. See how it is done for
the at91sam9260ek boards in the rework branch.
Best Regards,
Reinhard
___
Dear Kumar Gala,
In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you wrote:
>
> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>
> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
> CFLAGS += -mhard-float -fkeep-inline-functions
>
> We ne
The min and max macros break if x is 32-bit and y is 64-bit. y will always get
truncated to 32-bit and it will fail.
-Aaron
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi, Wolfgang,
2011/1/20 Jason Liu :
> This patch add the MX53 boot image support.
>
> This patch has been tested on Freescale MX53EVK board
> and MX51EVK board.
>
> Signed-off-by: Jason Liu
>
> ---
> Changes for v2:
> - Address the following comments from Stefano,
> - Get rid of #ifdef in the i
80 matches
Mail list logo
