Dear Albert ARIBAUD,
In message <4ca2d6d0.1080...@free.fr> you wrote:
>
> > Tested-by: Heiko Schocher
>
> Thanks Heiko.
>
> BTW, I forgot to mention that patch 2/2 of this set, being partly =
>
> written by Heiko for the tx25 part, is
>
> Signed-off-by: Heiko Schocher
Do you expect any furthe
Le 28/09/2010 15:57, Heiko Schocher a écrit :
> Hello Albert,
>
> Albert Aribaud wrote:
>> Add -msingle-pic-base to the relocation flags, and compute the pic base
>> in start.S twice and for all -- once before relocation to run board_init_f,
>> and once after relocation to run board_init_r and the
Le 28/09/2010 15:39, Ben Gardiner a écrit :
> On Tue, Sep 28, 2010 at 9:14 AM, Albert Aribaud
> wrote:
>> Add -msingle-pic-base to the relocation flags, and compute the pic base
>> in start.S twice and for all -- once before relocation to run board_init_f,
>> and once after relocation to run boar
Hi Ben,
On Tue, Sep 28, 2010 at 19:31:02, Ben Gardiner wrote:
> On Fri, Sep 24, 2010 at 1:10 AM, Nori, Sekhar wrote:
> > Hello All,
> >
> > On Fri, Aug 27, 2010 at 10:44:58, Nori, Sekhar wrote:
> >> The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> >> having different maximum allow
Dear Wolfgang,
On 28/09/2010 10:46 PM, Wolfgang Denk wrote:
>
>
>> People could also choose to bitbang the SPI on their custom hardware but
>> again I feel that might defeat the purpose and spirit of u-boot. (Then
>> again, I'm new so don't quote me on that).
> Oops? Where exactly do you see co
On 28/09/2010 11:22 PM, Reinhard Meyer wrote:
Dear Wolfgang Denk, Can Aydin,
True, a GPIO pin could be re-purposed to serve as chip select, but that
would involve a soldering iron and a steady hand as the P1/P2xxRDB
That was not the question.
Reinhard asked if the SPI Chip Select Pins could
From: Sukumar Ghorai
The SDP4430 does not have onboard NAND, it has eMMC on the second
MMC slot. This patch adds support for saving the u-boot environment
to eMMC.
Signed-off-by: Aneesh V
Signed-off-by: Sukumar Ghorai
Tested-by: Steve Sakoman
---
include/configs/omap4_sdp4430.h | 13 +
This patch switches from the legacy mmc driver to the new generic mmc driver
Signed-off-by: Steve Sakoman
---
board/overo/overo.c |9 +
include/configs/omap3_overo.h | 10 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/board/overo/overo.c b/boa
This patch switches from the legacy mmc driver to the new generic mmc driver
Signed-off-by: Steve Sakoman
---
board/ti/beagle/beagle.c |9 +
include/configs/omap3_beagle.h | 10 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/board/ti/beagle/beagle.
From: Sukumar Ghorai
This patch switches from the legacy mmc driver to the new generic mmc driver
Signed-off-by: Sukumar Ghorai
Tested-by: Steve Sakoman
---
board/ti/sdp4430/sdp.c | 10 ++
include/configs/omap4_sdp4430.h | 10 +-
2 files changed, 15 insertions(+),
From: Sukumar Ghorai
This patch switches from the legacy mmc driver to the new generic mmc driver
Signed-off-by: Sukumar Ghorai
Tested-by: Steve Sakoman
---
board/ti/panda/panda.c|9 +
include/configs/omap4_panda.h |9 -
2 files changed, 13 insertions(+), 5 del
From: Sukumar Ghorai
The current mmc driver returns erroneous capacity information for
eMMC. The capacity of eMMC devices is available only in the ext-CSD
register. This patch add code to read the ext-CDSD register and
correctly calculate eMMC capacity.
Signed-off-by: Sukumar Ghorai
A
From: Sukumar Ghorai
OMAP boards currently use a legacy mmc driver. This patch adds a new
mmc driver which will work with the generic mmc driver in u-boot.
This new driver will work with both OMAP3 and OMAP4 boards.
This patch does not remove the old driver. It should remain in the
tree until
This patch series implements a number of cleanups for the OMAP MMC support.
The first patch fixes a bug in the generic MMC driver that results in
erroneous capacity calculations for eMMC.
The second patch adds a CONFIG_GENERIC_MMC compatible driver for OMAP3
and OMAP4. The old legacy OMAP MMC dr
Signed-off-by: York Sun
---
include/configs/corenet_ds.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index cbe5024..5ce0efd 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -86,
Using PIC TFRR register for post word load/store for generic MPC85xx.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/cpu.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index fc5d9
Add weak functions to enable architecture depended preparation, address
advancing, cleaning up and error handling.
These weak functions provides the framwork to implemente arch/platform
dependent code for initializing/maintenance/restore the start address, size,
physical address as well as memory
Signed-off-by: York Sun
---
include/configs/P2020DS.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h
index 79ce2c0..923072a 100644
--- a/include/configs/P2020DS.h
+++ b/include/configs/P2020DS.h
@@ -73,8 +73,9 @@
A worker function setup_ddr_tlbs_phys() is introduced to implement more
control on physical address mapping.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/tlb.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/p
The memory test is performed after DDR initialization when U-boot stills runs
in flash and cache. On recent mpc85xx platforms, the total memory can be more
than 2GB. To cover whole memory, it needs be mapped 2GB at a time using a
sliding TLB window. After the testing, DDR is remapped with up to 2GB
The address used for post_word_load and post_word_store is in the dual port
RAM for processors with CPM.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/commproc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/commproc.c
b/arch/pow
Dear tma...@apm.com,
In message <1285708521-5747-1-git-send-email-tma...@apm.com> you wrote:
> From: Tirumala Marri
>
> Add support code for bluestone board wth APM821XX processor based.
> This patch includes early board init, misc init, configure EBC,
> initializes UIC, MAKEALL, board.cfg and M
Dear tma...@apm.com,
In message <1285708514-5713-1-git-send-email-tma...@apm.com> you wrote:
> From: Tirumala Marri
>
> APM821XX is a new line of SoCs which are derivatives of
> PPC44X family of processors. This patch adds support of CPU, cache,
> tlb, 32k ocm, bootstraps, PLB and AHB bus.
>
>
From: Tirumala Marri
Add support code for bluestone board wth APM821XX processor based.
This patch includes early board init, misc init, configure EBC,
initializes UIC, MAKEALL, board.cfg and MAINTAINERS file.
Signed-off-by: Tirumala R Marri
inka4x0 MPC5200
+Tirumala Marri
From: Tirumala Marri
APM821XX is a new line of SoCs which are derivatives of
PPC44X family of processors. This patch adds support of CPU, cache,
tlb, 32k ocm, bootstraps, PLB and AHB bus.
Signed-off-by: Tirumala R Marri
---
V6:
* Correcting indentation.
V7:
* Ordering defined(APM821XX) in c
From: Tirumala Marri
APM821XX is Applied Micro Circuits Corporations naming
convention for new line of SoCs.
V6:
* Correcting indentation.
V7:
* Ordering defined(APM821XX) in cpu_init.c.
* Correcting Typo Bloustone to Bluestone.
Tirumala Marri (2):
APM821xx: Add CPU support
APM821xx:
Commit 800eb0964 "POST cleanup." removed file
arch/powerpc/cpu/mpc512x/common.c but failed to remove the reference
to it from arch/powerpc/cpu/mpc512x/Makefile which causes somewhat
obscure build errors:
make[1]: *** No rule to make target
`/work/wd/tmp-ppc/arch/powerpc/cpu/mpc512x/.depend', need
Dear s-paul...@ti.com,
In message <1285697020-10191-1-git-send-email-s-paul...@ti.com> you wrote:
> The following changes since commit 85d3eba90df54bac27844221e2436550984c4d58:
> Thomas Weber (1):
> ixp/npe: Remove duplicated comment
>
> are available in the git repository at:
>
> gi
Dear York Sun,
In message <1285701869.30239.16.ca...@oslab-l1> you wrote:
>
> > > The phys_offset is not used by _this_ weak function but it is used by
> > > another function implemented in the third patch. Is it OK to leave the
> > > unused phys_offset here?
> >
> > What does the compiler say?
>
On Tue, 2010-09-28 at 20:50 +0200, Wolfgang Denk wrote:
> Dear York Sun,
>
> In message <1285696512.30239.14.ca...@oslab-l1> you wrote:
> > On Tue, 2010-09-28 at 19:31 +0200, Wolfgang Denk wrote:
> >
> > > > -int memory_post_test (int flags)
> > > > +__attribute__((weak))
> > > > +int arch_memory
Dear tma...@apm.com,
In message <1285698755-4972-1-git-send-email-tma...@apm.com> you wrote:
> From: Tirumala Marri
>
> Add support code for bluestone board wth APM821XX processor based.
> This patch includes early board init, misc init, configure EBC,
> initializes UIC, MAKEALL, board.cfg and M
Dear tma...@apm.com,
In message <1285698750-4943-1-git-send-email-tma...@apm.com> you wrote:
> From: Tirumala Marri
>
> APM821XX is a new line of SoCs which are derivatives of
> PPC44X family of processors. This patch adds support of CPU, cache,
> tlb, 32k ocm, bootstraps, PLB and AHB bus.
...
>
On Tue, 28 Sep 2010 19:31:30 +0200
Wolfgang Denk wrote:
> > +__attribute__((weak))
> > +int arch_memory_test_advance(u32 *vstart, u32 *size, phys_addr_t
> > *phys_offset)
> > +{
> > + return 1;
> > +}
>
> Unused arguments?
>
> Don't you get compiler warnings for these?
Such warnings are not
Dear York Sun,
In message <1285696512.30239.14.ca...@oslab-l1> you wrote:
> On Tue, 2010-09-28 at 19:31 +0200, Wolfgang Denk wrote:
>
> > > -int memory_post_test (int flags)
> > > +__attribute__((weak))
> > > +int arch_memory_test_prepare(u32 *vstart, u32 *size, phys_addr_t
> > > *phys_offset)
>
From: Tirumala Marri
Add support code for bluestone board wth APM821XX processor based.
This patch includes early board init, misc init, configure EBC,
initializes UIC, MAKEALL, board.cfg and MAINTAINERS file.
Signed-off-by: Tirumala R Marri
inka4x0 MPC5200
+Tirumala Marri
From: Tirumala Marri
APM821XX is a new line of SoCs which are derivatives of
PPC44X family of processors. This patch adds support of CPU, cache,
tlb, 32k ocm, bootstraps, PLB and AHB bus.
Signed-off-by: Tirumala R Marri
---
V5:
* Move CONFIG_SYS_PERIPHERAL_BASE to apm821xx.h
V6:
* Correcti
From: Tirumala Marri
APM821XX is Applied Micro Circuits Corporations naming
convention for new line of SoCs.
V5:
* Move CONFIG_SYS_PERIPHERAL_BASE to apm821xx.h
* MAKEALL change is not needed anymore
* CONFIG_SYS_NOR_CS is not used anywhere.
* CONFIG_PHY_RESET_R is not used anywhere
V6:
The following changes since commit 85d3eba90df54bac27844221e2436550984c4d58:
Thomas Weber (1):
ixp/npe: Remove duplicated comment
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
Aneesh V (1):
ARMV7: OMAP4: Calculate SDRAM size
Steve Sakoman (2):
On Tue, 2010-09-28 at 19:31 +0200, Wolfgang Denk wrote:
> > -int memory_post_test (int flags)
> > +__attribute__((weak))
> > +int arch_memory_test_prepare(u32 *vstart, u32 *size, phys_addr_t
> > *phys_offset)
>
> phys_offset is unused here. Drop it?
>
The phys_offset is not used by _this_ weak
> > Thanks Wolfgang.
> >
> > Copying Sandeep so he knows he has to work fast :-)
>
> Ping???
Its coming in a few minutes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Ben,
ping again...
In message <20100913093325.a8a84152...@gemini.denx.de> I wrote:
> Dear Ben,
>
> In message <1282208946-18823-1-git-send-email-ya...@emcraft.com> Ilya Yanok
> wrote:
> > Some boards need their board-specific PHY quirks to be called
> > to PHY to work normally. As mpc5xxx_
Dear Sandeep,
In message <1285623705.4705.45.ca...@quadra> Steve Sakoman wrote:
> On Mon, 2010-09-27 at 23:37 +0200, Wolfgang Denk wrote:
> > Dear Steve Sakoman,
> >
> > In message <1285622277.4705.43.ca...@quadra> you wrote:
> > >
> > > The subject patch does indeed set the ram size properly in
Dear York Sun,
In message <1285691891-32700-3-git-send-email-york...@freescale.com> you wrote:
> The memory test is performed after DDR initialization when U-boot stills runs
> in flash and cache. Whole memory can be tested. It is mapped 2GB at a time
> using a sliding TLB window. After the testin
Dear York Sun,
In message <1285691891-32700-2-git-send-email-york...@freescale.com> you wrote:
> A worker function __setup_ddr_tlbs() is introduced to implement more
> control on physical address mapping.
The __ name prefix has a special, reserved meaning. What is your
rationale for using it here
TI hasn't reserved a USB Product ID for gadgets, so use the default
vendor and product ID to avoid confusion.
Signed-off-by: Steve Sakoman
---
include/configs/omap3_beagle.h |5 -
include/configs/omap4_panda.h |5 -
include/configs/omap4_sdp4430.h |5 -
3 files changed
Dear York Sun,
In message <1285691891-32700-1-git-send-email-york...@freescale.com> you wrote:
> Add weak functions to enable architecture depended preparation, address
> advancing, cleaning up and error handling.
>
> Signed-off-by: York Sun
This needs some comments to explain the interfaces yo
Dear "SANCHEZ VITORICA, GUILLERMO",
In message <3694e0885cb1d844aaf54f75dbdc255834d...@mail1.usr.corp.gamesa.es>
you wrote:
>
> I feel a little bit silly for asking this but, is the Coldfire
> Architecture supported by ELDK?
No, it is not. We support ARM, Power, and MIPS.
Best regards,
Wolfga
The memory test is performed after DDR initialization when U-boot stills runs
in flash and cache. Whole memory can be tested. It is mapped 2GB at a time
using a sliding TLB window. After the testing, DDR is remapped with up to 2GB
memory from the lowest address as normal.
If memory test fails, DDR
Signed-off-by: York Sun
---
include/configs/P2020DS.h |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h
index 79ce2c0..923072a 100644
--- a/include/configs/P2020DS.h
+++ b/include/configs/P2020DS.h
@@ -73,8 +73,9 @@
Using PIC TFRR register for post word load/store for generic MPC85xx.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/cpu.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index f60fa47
Signed-off-by: York Sun
---
include/configs/corenet_ds.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index cbe5024..5ce0efd 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -86,
The address used for post_word_load and post_word_store is in the dual port
RAM for processors with CPM.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/commproc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/commproc.c
b/arch/powerpc
A worker function __setup_ddr_tlbs() is introduced to implement more
control on physical address mapping.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/tlb.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powe
Add weak functions to enable architecture depended preparation, address
advancing, cleaning up and error handling.
Signed-off-by: York Sun
---
post/drivers/memory.c | 65 +++-
1 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/post/driv
Hi Shashidhar.H.G,
> I'm trying to port uCLinux on to the LPC 2468-16 OEM Board.
You may have noticed that this is the U-Boot mailing list. If you have
trouble with uCLinux, the linux-arm mailing list is more to the point.
> .HEX file is been generated by following the steps (Section 10) given
Hello all,
I feel a little bit silly for asking this but, is the Coldfire
Architecture supported by ELDK?
Kind regards,
Guillermo Sanchez Vitorica
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Roland,
> regarding the status of the dockstar integration:
>
>> Yes, indeed - the feedback only touched some formal points. Reworking
>> the patches should be easy.
>
> taken from http://forum.doozan.com/read.php?3,881,978#msg-978 :
>
> "Cool. I'm currently hung up on making my patches work w
Hi Roland,
[...]
>> See, that's another reason why we still have such problems - once a
>> hardware replacement is found, the problem is no longer pursued.
>
> Oh, have a look on the linux bugtracker or other linux communities.
USB support in Linux is way better than what we have in U-Boot and t
Hi Feng,
[general remark - isn't it possible that you quote mails "the regular
way"[1]? I'm having a hard time to distinguish the new text from the
original text].
> On Fri, Sep 24, 2010 at 10:43 AM, Wolfgang Denk wrote:
>> Dear Feng Kan,
>>
>> In message
>> you wrote:
>>>
>>> FKAN: Dear Wolf
On Fri, Sep 24, 2010 at 1:10 AM, Nori, Sekhar wrote:
> Hello All,
>
> On Fri, Aug 27, 2010 at 10:44:58, Nori, Sekhar wrote:
>> The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
>> having different maximum allowed CPU clock rating.
>>
>> The maximum clock the chip can support can only
Hello Albert,
Albert Aribaud wrote:
> Add -msingle-pic-base to the relocation flags, and compute the pic base
> in start.S twice and for all -- once before relocation to run board_init_f,
> and once after relocation to run board_init_r and the rest of u-boot.
> This further reduces code size by 2.
Hello Albert,
Albert Aribaud wrote:
> Replace GOT indirect addressing with more efficient pic-base
> relative addressing for initialized data (uninitialized data
> still use GOTi indirect addressing). This also reduces code
> size by 0.4% compared to -fPIC.
>
> Signed-off-by: Albert Aribaud
Te
On Tue, Sep 28, 2010 at 9:14 AM, Albert Aribaud wrote:
> Add -msingle-pic-base to the relocation flags, and compute the pic base
> in start.S twice and for all -- once before relocation to run board_init_f,
> and once after relocation to run board_init_r and the rest of u-boot.
> This further redu
On Tue, Sep 28, 2010 at 9:14 AM, Albert Aribaud wrote:
> Replace GOT indirect addressing with more efficient pic-base
> relative addressing for initialized data (uninitialized data
> still use GOTi indirect addressing). This also reduces code
> size by 0.4% compared to -fPIC.
>
> Signed-off-by: A
Dear Wolfgang Denk, Can Aydin,
>> True, a GPIO pin could be re-purposed to serve as chip select, but that
>> would involve a soldering iron and a steady hand as the P1/P2xxRDB
>
> That was not the question.
>
> Reinhard asked if the SPI Chip Select Pins could be configured such so
> that they c
Add -msingle-pic-base to the relocation flags, and compute the pic base
in start.S twice and for all -- once before relocation to run board_init_f,
and once after relocation to run board_init_r and the rest of u-boot.
This further reduces code size by 2.5% compared to -fPIE alone.
Signed-off-by: A
Replace GOT indirect addressing with more efficient pic-base
relative addressing for initialized data (uninitialized data
still use GOTi indirect addressing). This also reduces code
size by 0.4% compared to -fPIC.
Signed-off-by: Albert Aribaud
---
SUMMARY
This patch aims at optimizing relocatab
Dear Thomas Weber,
In message <1285675413-13865-1-git-send-email-we...@corscience.de> you wrote:
> Signed-off-by: Thomas Weber
> ---
> arch/arm/cpu/ixp/npe/IxNpeDlNpeMgr.c |5 -
> 1 files changed, 0 insertions(+), 5 deletions(-)
Applied, because it's such a trivial patch - otoh, don;t w
Dear Thomas Weber,
In message <1285675413-13865-2-git-send-email-we...@corscience.de> you wrote:
> Signed-off-by: Thomas Weber
> ---
> board/bmw/bmw.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH,
Dear Can Aydin,
In message <4ca1d63e.3090...@locatacorp.com> you wrote:
>
> > Can the Chip Select Pins be used as GPIO? It might be simpler to do
> > that than
> > adding a speciality to common code.
> True, a GPIO pin could be re-purposed to serve as chip select, but that
> would involve a sol
Dear Torkel Lundgren,
In message <1285664736-21181-1-git-send-email-torkel.lundg...@enea.com> you
wrote:
> Add OSE as operating system for mkimage and bootm.
>
> Signed-off-by: Torkel Lundgren
> ---
> common/cmd_bootm.c| 39 +++
> common/image.c
Dear Thomas Weber,
In message <1285653985-11796-1-git-send-email-we...@corscience.de> you wrote:
> The version numbering scheme was changed in Oct, 2008.
> This patch brings the documentation to the actual level.
> The description is taken from:
> http://www.denx.de/wiki/U-Boot/ReleaseCycle
>
>
>> Can the Chip Select Pins be used as GPIO? It might be simpler to do
>> that than
>> adding a speciality to common code.
> True, a GPIO pin could be re-purposed to serve as chip select, but that
> would involve a soldering iron and a steady hand as the P1/P2xxRDB
> boards are reference design b
Signed-off-by: Thomas Weber
---
arch/arm/cpu/ixp/npe/IxNpeDlNpeMgr.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/ixp/npe/IxNpeDlNpeMgr.c
b/arch/arm/cpu/ixp/npe/IxNpeDlNpeMgr.c
index f5a4c5f..a9ea8bc 100644
--- a/arch/arm/cpu/ixp/npe/IxNpeDlNpeMgr.c
+
Signed-off-by: Thomas Weber
---
board/bmw/bmw.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/board/bmw/bmw.c b/board/bmw/bmw.c
index 4039145..5ba6c09 100644
--- a/board/bmw/bmw.c
+++ b/board/bmw/bmw.c
@@ -22,7 +22,6 @@
*/
#include
-#include
#include
#include
Dear Reinhard,
On 28/09/2010 9:02 PM, Reinhard Meyer wrote:
> Dear Can Aydin,
>> The reason this is an RFC is that unfortunately the hardware on these
>> chips does not permit indefinite SPI transactions on a given chip
>> select. A chip select is asserted only when a 'transaction length' has
>>
Dear Can Aydin,
> The reason this is an RFC is that unfortunately the hardware on these
> chips does not permit indefinite SPI transactions on a given chip
> select. A chip select is asserted only when a 'transaction length' has
> been passed to the controller. Once the number of characters specifi
Hi Marri,
On Monday 27 September 2010 21:47:04 tma...@apm.com wrote:
> From: Tirumala Marri
>
> APM821XX is a new line of SoCs which are derivatives of
> PPC44X family of processors. This patch adds support of CPU, cache,
> tlb, 32k ocm, bootstraps, PLB and AHB bus.
Hopefully the last (coding s
Add FSL eSPI support on P1/P2 RDB platforms
Signed-off-by: Can Aydin
---
include/configs/P1_P2_RDB.h | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 7e901e1..d830b4a 100644
--- a/include
Driver for the Freescale eSPI controller found in 85xx, P1/P2 and P4xx SoCs.
Signed-off-by: Can Aydin
---
drivers/spi/Makefile |1 +
drivers/spi/fsl_espi.c | 251
include/fsl_espi.h | 50 ++
3 files changed, 302 insertion
Modify Spansion flash driver to add support for the FSL eSPI controller.
Due to the nature of the eSPI controller the upper level drivers must
ensure to use single frame transactions (i.e. that have begin and end
flags set) and keep the size of each frame below maximum length.
Signed-off-b
Add a single-hit transaction to the spi flash framework.
Useful for when the hardware makes it impossible to maintain CS
state between disparate command and data calls by requiring a
'frame length' (thus pre-determining how many clock cycles the
CS will stay asserted).
Such is the case
Hi All,
This patch series adds support for the eSPI controller found on the
newer range of Freescale SoCs including the 85xx, P1/P2xx (and I believe
the P4xx) series.
The reason this is an RFC is that unfortunately the hardware on these
chips does not permit indefinite SPI transactions on a
Add OSE as operating system for mkimage and bootm.
Signed-off-by: Torkel Lundgren
---
common/cmd_bootm.c| 39 +++
common/image.c|1 +
include/config_defaults.h |1 +
include/image.h |1 +
4 files changed, 42 insertio
Hi Sergio,
On Tuesday 28 September 2010 10:10:52 Sergio Navarrez wrote:
> I’m working with AMCC Sequioa board. Nor and Nand memories was erased, and
> I’m trying to program the Nand flash with the last u-boot version via
> debugger. I followed the respective steps from your manual and compiled
> u
Dear all:
I’m working with AMCC Sequioa board. Nor and Nand memories was erased, and
I’m trying to program the Nand flash with the last u-boot version via
debugger. I followed the respective steps from your manual and compiled
u-boot with ELDK. But u-boot doesn’t work.
What can I do, to solve
Hi,
On Tue, Sep 28, 2010 at 09:09:56AM +0200, SANCHEZ VITORICA, GUILLERMO wrote:
>
> Hello,
>
> One last thing on this topic. Could I use also CoudeSourcery Lite +
> Coldfire toolchain ?
for U-Boot: yes
For Linux (ELDK/LTIB), it is IMHO better to rely on the toolchain
provided with the ELDK/LT
Hello,
One last thing on this topic. Could I use also CoudeSourcery Lite +
Coldfire toolchain ?
Kind regards,
Guillermo
-Mensaje original-
De: Ben Warren [mailto:biggerbadder...@gmail.com]
Enviado el: martes, 28 de septiembre de 2010 4:30
Para: SANCHEZ VITORICA, GUILLERMO
CC: Wolfga
88 matches
Mail list logo
