On 13/10/2010 9:25 PM, Xie Shaohui-B21989 wrote:
Hi Can,
Are there any differences between your patches and
http://lists.denx.de/pipermail/u-boot/2009-March/049093.html ?
Best Regards,
Shaohui Xie
Hello Shaohui,
Firstly, I apologize for responding so late, we've been having some
Driver for the Freescale eSPI controller found in 85xx, P1/P2 and P4xx SoCs.
Signed-off-by: Can Aydin can.ay...@locatacorp.com
---
Changes for v2:
- Coding style cleanup
- Removed modifications to common code
Changes for v3:
- fixed whitespace between function calls
Add support for Freescale eSPI driver in P1/P2 board configuration
Signed-off-by: Can Aydin can.ay...@locatacorp.com
---
Changes for v2:
- Coding style cleanup
- Removed modifications to common code
Changes for v3:
- fixed whitespace between function calls and parameters
Dear Wolfgang Denk,
On 24/10/2010 11:21 PM, Wolfgang Denk wrote:
Dear Can Aydin,
In message1287920728-6458-1-git-send-email-can.ay...@locatacorp.com you
wrote:
Driver for the Freescale eSPI controller found in 85xx, P1/P2 and P4xx SoCs.
...
+static inline void write_u32_part (u32
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 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
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.
.
+ * Author: Can Aydin can.ay...@locatacorp.com
+ * Collab: Clayton Gumbrellclayton.gumbr...@locatacorp.com
+ *
+ * Adapted from Freescale ltib code by Mingkai Hu (mingkai...@freescale.com)
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can
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
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 conflicts
On 9/08/2010 5:57 AM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message57cdb146-383a-4629-b7e4-c2729200a...@kernel.crashing.org you
wrote:
On Jun 23, 2010, at 8:56 AM, Poonam Aggrwal wrote:
This patch enables the eSPI configuration to use
the Spansion Flash on P1 and P2 RDB Platforms
Has anyone come across (or written) a tool/script/makefile target to
pack u-boot into a SPI boot image (i.e. with boot header and config
symbols) to boot directly from SPI on the P2020RDB (or P1020 etc.)
and/or MPC8536DS? Would it be within the scope of u-boot to have such an
option?
Can
location from the signals, and more importantly, override any
erroneus signals that the hardware on the platform (P2020RDB and later,
the prototype) might be providing (or failing to provide) it. (without
using an oscilloscope and a soldering iron that is).
Regards,
Can Aydin
--
*Can Aydin
13 matches
Mail list logo
