* RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Liu Dave-R63238 @ 2009-03-09 2:33 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Ben Menchaca, linuxppc-dev
In-Reply-To: <ed82fe3e0903080819g166e5651rd07956d8f26c0f5a@mail.gmail.com>
Timur,
See the section 14.7.1 DMA Description Format at page 14-112
of MPC8315ERM rev.1.
> -----Original Message-----
> From: timur.tabi@gmail.com [mailto:timur.tabi@gmail.com] On=20
> Behalf Of Tabi Timur-B04825
> Sent: Sunday, March 08, 2009 11:20 PM
> To: Liu Dave-R63238
> Cc: Ben Menchaca; linuxppc-dev@ozlabs.org
> Subject: Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
>=20
> On Fri, Mar 6, 2009 at 12:49 AM, Liu Dave-R63238=20
> <DaveLiu@freescale.com> wrote:
> > could you try to set '1' to DMA description bit3?
>=20
> Dave,
>=20
> I'm looking at the 8315e reference manual. What is "DMA=20
> description bit 3"?
>=20
> --
> Timur Tabi
> Linux kernel developer at Freescale
>=20
>=20
^ permalink raw reply
* RE: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Liu Dave-R63238 @ 2009-03-09 2:30 UTC (permalink / raw)
To: Ben Menchaca; +Cc: linuxppc-dev
In-Reply-To: <64ac01180903060830m1e5927c6y76b8302b0fb68eb6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6343 bytes --]
Hi Ben,
The second issue. you told me "some hosts" has problem,
and some hosts worked well.
what is the problem-hosts?
The issue seems like the hosts did set the NO SNOOP attribute
bit at TLP.
The PEX_DEVICE_CONTROL is standard PCI configuration space
register, it controls the behavior of the initiator's transaction.
For 8315, it is outbound, not inbound transaction.
Thanks, Dave
________________________________
From: Ben Menchaca [mailto:ben.menchaca@gmail.com]
Sent: Saturday, March 07, 2009 12:30 AM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating Pages as
Cache-Inhibited
Thank you for your help! That bit resolved all of the RDMA/WDMA
coherency issues on the CSB side...except:
We expose a 1MB region of memory from CSB via a BAR (BAR1, if it
matters) to the Host. This region is also not behaving correctly with
respect to coherency on SOME hosts; again, disabling our cache makes it
work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E
Config Space (0x54) to 0x2010 (sorry about the endianness below). We
thought that CLEARING the no-snoop bit here would indicate that snooping
was required for this region...is this a similar issue?
- Ben
On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca
<ben.menchaca@gmail.com> wrote:
Testing now...it looks like it (almost) works, though!
Why does setting no-snoop cause snooping to work? More on the effect on
setting that bit in a few minutes...need more testing.
ACR is 0x00030300.
- Ben
On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238
<DaveLiu@freescale.com> wrote:
Did you enable the descriptor bit 3 to have a
try?
________________________________
From: Ben Menchaca
[mailto:ben.menchaca@gmail.com]
Sent: Friday, March 06, 2009 2:10 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited
I can look at ACR morning...although I
can say with a fair amount of certainty that I have not changed it from
the POR value.
I will try enabling No Snoop for CSB in
the descriptor (bit 3, yes?)...this seems a bit counterintuitive to me.
What is the hope regarding these two?
Some combination I am not seeing?
On Thu, Mar 5, 2009 at 11:40 PM, Liu
Dave-R63238 <DaveLiu@freescale.com> wrote:
what is the value of ACR register?
________________________________
From: Ben Menchaca
[mailto:ben.menchaca@gmail.com]
Sent: Friday, March 06, 2009 1:38 PM
To: Liu Dave-R63238
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx: Marking or Allocating
Pages as Cache-Inhibited
1. BAT2 in linux is set to WIMG=0010,
and covers all 64M
2. PEX_DEVICE_CONTROL in PCI-E Config
Space (0x54): 0x1020
3. PEX_xDMA_CTRL is set to 0x00000401
at the initiation of the DMA.
4. OWAR0 is set to 0xFFFFF005, so NSNP
is 0.
5. The DMA descriptor (randomly chosen
when I hit a trigger...just ignore the size...) contains 0002AFF3 at
offset 0, so nosnoops are cleared.
Core is 400MHz, and CSB is 133MHz.
- Ben
On Thu, Mar 5, 2009 at 11:27 PM, Liu
Dave-R63238 <DaveLiu@freescale.com> wrote:
and what settings is DMA description
bit 3?
> -----Original Message-----
> From:
linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale.com@ozlabs.org]
> On Behalf Of Liu Dave-R63238
> Sent: Friday, March 06, 2009 1:22 PM
> To: Ben Menchaca;
linuxppc-dev@ozlabs.org
> Subject: RE: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
> Did you enable the snoop bit at
PEX_WDMA_CTRL[SNOOP] and
> PEX_RDMA_CTRL[SNOOP]?
>
> What is the freq settings? CORE/CSB
bus.
>
> Thanks, Dave
>
> ________________________________
>
> From:
linuxppc-dev-bounces+daveliu=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+daveliu
<mailto:linuxppc-dev-bounces%2Bdaveliu> =freescale.com@ozlabs.org]
> On Behalf Of Ben Menchaca
> Sent: Friday, March 06, 2009
12:33 PM
> To: linuxppc-dev@ozlabs.org
> Subject: 83xx: Marking or
Allocating Pages as Cache-Inhibited
>
>
> I am working on a Freescale
8314e design, and the
> embedded device is configured as a
PCI-e endpoint running a
> 2.6.27-5 kernel. For context, we have
written a kernel
> module which, among other things, uses
the RDMA/WDMA engine
> in the PCI-e IP block. On the host
side, these DMAs are
> coherent. However, on the embedded
side, things are quite a
> bit less rosy; we must manually
flush/invalidate cache lines
> for WDMA/RDMAs to occur successfully.
After speaking with
> (several) FAEs at Freescale, we
believe there is a
> configuration issue that is the cause,
but we have yet to
> have anyone successfully point to it.
>
> Disabling the data cache
altogether resolves the issue
> entirely, but of course, also
completely tanks performance.
> As a temporary workaround, I would
like to simply mark the
> pages (obtained currently via
dma_alloc_coherent) involved as
> cache-inhibited. I have attempted to
do this via some
> snippets remaining in fec.c
(va_to_pte, uncache_pte to set
> _PAGE_NO_CACHE, flush_tlb_page, then
unmap_pte), but this is
> almost certainly braindead; va_to_pte
is not a part of the
> 83xx source, as far as I can tell; 8xx
only.
>
> A quick pointer in the correct
direction for marking
> pages as cache-inhibited on a 2.6.27-5
kernel would be
> appreciated, or if my approach to a
workaround is flawed, a
> pointer to the correct way would be
great.
>
> Ben Menchaca
>
>
>
_______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 14731 bytes --]
^ permalink raw reply
* Ethernet problem on 405EXr
From: Felix Radensky @ 2009-03-08 20:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm experiencing a strange problem with ethernet on custom
405EXr based board with 10/100 Micrel PHY in MII mode. I ran
u-boot 2009.01 and linux-2.6.27. In u-boot ethernet works flawlessly.
I didn't have to add any u-boot code to initialize the PHY. In linux
ethernet works only if there was some network activity in u-boot.
In this case NFS root works fine. Otherwise only TX side works
in Linux, ethtool does not report any errors, and resetting the PHY
via mii-tool doesn't help. Autonegotiation seems to work properly.
The only modification I did in linux is to change phy-mode to "mii"
in device tree.
Any help in debugging this is very much appreciated.
Felix.
--
View this message in context: http://www.nabble.com/Ethernet-problem-on-405EXr-tp22402565p22402565.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH, RFC]
From: Sean MacLennan @ 2009-03-08 19:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: eddie
In-Reply-To: <60088.70.162.219.205.1236438881.squirrel@oz.embeddedx86.com>
On Sat, 7 Mar 2009 08:14:41 -0700 (MST)
"Eddie Dawydiuk" <eddie@embeddedarm.com> wrote:
> On another note, can you tell me/point me to some documentation on
> how to get a unique machine ID for a new board?
Do you mean the model in the dts, like "amcc,yosemite"? You just pick
one.
It is just company name, board name. We based the Pika Warp on the
yosemite board but our model name is pika,warp since it is too far
removed to use the stock yosemite to use the same DTS.
Cheers,
Sean
^ permalink raw reply
* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Timur Tabi @ 2009-03-08 15:19 UTC (permalink / raw)
To: Liu Dave-R63238; +Cc: Ben Menchaca, linuxppc-dev
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208916CF87@zch01exm21.fsl.freescale.net>
On Fri, Mar 6, 2009 at 12:49 AM, Liu Dave-R63238 <DaveLiu@freescale.com> wrote:
> could you try to set '1' to DMA description bit3?
Dave,
I'm looking at the 8315e reference manual. What is "DMA description bit 3"?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 11/11] mmc: Add OpenFirmware bindings for SDHCI driver
From: Pierre Ossman @ 2009-03-08 14:44 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel, Pierre Ossman
In-Reply-To: <20090305202850.GK28709@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
On Thu, 5 Mar 2009 23:28:50 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> This patch adds a new driver: sdhci-of. The driver is similar to
> the sdhci-pci, it contains common probe code, and controller-specific
> ops and quirks.
>
> So far there are only Freescale eSDHC ops and quirks.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/mmc/host/Kconfig | 10 ++
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-of.c | 309 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 320 insertions(+), 0 deletions(-)
> create mode 100644 drivers/mmc/host/sdhci-of.c
>
I'd like a MAINTAINERS entry for this (sub)driver.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 12/13] sdhci: Add quirk for controllers with max. block size up to 4096 bytes
From: Pierre Ossman @ 2009-03-08 14:21 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090304174744.GB7477@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]
On Wed, 4 Mar 2009 20:47:44 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> I'll get rid of this particular patch, and put some BLOCK_SIZE
> magic into the writew accessor (to clean the DMA bits) instead.
>
> Though, I'll prepare another patch to force blksz to 2048, since
> eSDHC specifies "3" in the blksz capability bitfield, and that
> causes SDHCI core to fall back to the 512 byte blocks.
>
Ok.
> > After all, is it ever used?
>
> Not sure, maybe `dd bs=' can use it? A bit lazy to check this
> right now, but from the quick tests, enabling/disabling "blksz
> of 4096 bytes" doesn't cause any performance change. At least
> with the ordinary SD cards.
>
Memory cards will not use this (at least not with the current
standards), as the block layer thinks in 512 byte blocks. Also, the
sector size propagates to user space in a way that causes filesystems
to behave differently, making cards incompatible with all other
operating systems (i.e. if we don't use 512 byte blocks).
So the only scenario where this might be used is SDIO, and I'm not sure
such big blocks are a win there either because of the overhead of
changing block size.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 07/13] sdhci: Add support for hosts with strict 32 bit addressing
From: Pierre Ossman @ 2009-03-08 14:17 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090304174845.GC7477@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Wed, 4 Mar 2009 20:48:45 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> But I see the point of confusion... Instead of teaching
> "SDHCI core" to work with 32 bits hosts, we'd better handle this
> in the eSDHC part, in the accessors.
>
> This is relatively trivial and should not cause much overhead
> (at least when using DMA), just a small state machine with
> the xfer mode register shadowed in software (plus, notice that
> this also handles BLOCK_SIZE, as I promised in another email):
>
Me like. Keeps my life a lot saner. :)
Just be aware that there is a remote risk of breakage as people hacking
on sdhci-core won't be aware of esdhc's, let's call it unique,
behaviour. Some testing now and then on your part would be prudent. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 05/13] sdhci: Add support for card-detection polling
From: Pierre Ossman @ 2009-03-08 14:11 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090304174917.GD7477@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On Wed, 4 Mar 2009 20:49:17 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Sat, Feb 21, 2009 at 04:58:21PM +0100, Pierre Ossman wrote:
> > Just modify the if-clause and
> > things will work.
>
> That would look horrid...
>
> if ((!(host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) &&
> !(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> SDHCI_CARD_PRESENT)) ||
> (host->flags & SDHCI_DEVICE_DEAD)) {
>
There are worse ones in that code, but I see your point. :)
> > Might want to add a comment also to make it more obvious what the
> > if-clause does.
>
> Let's try to avoid the if-clause above? How about this:
>
Looks ok.
> @@ -1096,6 +1099,7 @@ out:
> static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
> {
> struct sdhci_host *host;
> + bool present;
> unsigned long flags;
>
> host = mmc_priv(mmc);
Can we use bool in the kernel?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 02/11] sdhci: Add support for bus-specific IO memory accessors
From: Pierre Ossman @ 2009-03-08 14:08 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
sdhci-devel
In-Reply-To: <20090304174658.GA7477@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --]
On Wed, 4 Mar 2009 20:46:58 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On Sat, Feb 21, 2009 at 04:57:57PM +0100, Pierre Ossman wrote:
> >
> > We can most likely do some micro-optimisation do make the compare part
> > cheaper, but the point was to avoid a function call for all the
> > properly implemented controllers out there. We could have a flag so
> > that it only has to check host->flags, which will most likely be in the
> > cache anyway.
> >
> > Overhead for eSDHC is not a concern in my book, what is interesting is
> > how much this change slows things down for other controllers.
>
> OK, I see. Will the patch down below make you a little bit more happy
> wrt normal controllers? Two #ifdefs, but then there is absolutely
> zero overhead for the fully compliant SDHCI controllers.
>
I can't say this makes me happy either, but I think it's acceptable for
now so that we can move forward. I'd like a common code path for this
thing, but I think I'm going to have to put a bit more time into it
myself than I currently have available.
> (So far it's just on top of this series, but I can incorporate it
> into the "sdhci: Add support for bus-specific IO memory accessors"
> patch, if you like).
>
Please do. Have one patch add some code and another remove it in the
same set is just silly. :)
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* where can i get a good linux kernel source tree for xilinx ml403 board?
From: Li Jun (Aaron) @ 2009-03-08 12:39 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi,
I tried to download the linux-2.6-xlnx from
git://git.xilinx.com/linux-2.6-xlnx.git.
It seems that the git server of Xilinx was down, so I cannot connect to it.
I also tried to download the
git://git.secretlab.ca/git/linux-2.6-virtex.git.
But it shows that:
last change
Fri, 30 Nov 2007 23:31:10 +0000
URL
git://git.jdl.com/software/linux-2.6-virtex.git
http://git.jdl.com/software/linux-2.6-virtex.git
I am afraid it is a little old version.
Could anybody give me some advice?
Thanks!
Best regards
[-- Attachment #2: Type: text/html, Size: 4738 bytes --]
^ permalink raw reply
* Re: PHY not found after migration of gianfar driver to an of_platform_driver
From: Wolfgang Ocker @ 2009-03-08 12:18 UTC (permalink / raw)
To: Michael Guntsche; +Cc: linuxppc-dev
In-Reply-To: <D5EBE54F-FD6D-4973-8835-33541ADCBABD@it-loops.com>
On Thu, 2009-02-26 at 20:15 +0100, Michael Guntsche wrote:
> For testing purposes I tried a recent git snapshot and noticed
> that the gianfar driver had problems.
> While the the Gianfar was detected
> [...]
> trying to up either of the devices gave me
>
> [ 8.724818] mdio@24520:01 not found
> [ 8.728330] eth1: Could not attach to PHY
> [ 8.732945] mdio@24520:01 not found
> [ 8.737720] eth1: Could not attach to PHY
I saw exactly the same symptoms on an 8560 board, and the patch below
helped. But I have no idea what's going on there ...
Wolfgang
From: Wolfgang Ocker <weo@reccoware.de>
Date: Sat, 7 Mar 2009 14:27:50 +0100
Subject: [PATCH] fsl-gianfar: improved detection of unoccupied PHY address
At least on one 8560 board the id 0x000ffff is returned at an
unoccupied PHY address.
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
drivers/net/gianfar_mii.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index f49a426..9c5e0c1 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -211,7 +211,7 @@ static int gfar_mdio_find_free(struct mii_bus *new_bus)
if (get_phy_id(new_bus, i, &phy_id))
return -1;
- if (phy_id == 0xffffffff)
+ if (phy_id == 0xffffffff || phy_id == 0x0000ffff)
break;
}
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH, RFC]
From: Grant Likely @ 2009-03-08 7:35 UTC (permalink / raw)
To: eddie; +Cc: linuxppc-dev
In-Reply-To: <62692.70.162.219.205.1236443872.squirrel@oz.embeddedx86.com>
On Sat, Mar 7, 2009 at 9:37 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
>>> So if you have any suggestions on
>>> this approach using the simpleImage please let me know.
>>
>> Before I answer this, what bootloader are you using?
>
> We are using a custom bootloader we developed ourselves. The bootloader i=
s
> very minimal as one of our primary design goals is a fast boot time. We d=
o
> some basic initialization of the AMCC 440EP, then load the simpleImage
> into RAM at address 0 and jump into it. In my mind I had considered our
> code as more of a bootrom and the simpleboot.c as a bootloader ;)
>
>>> On another note, can you tell me/point me to some documentation on how
>>> to get a unique machine ID for a new board?
>>
>> What do you mean? =A0Are you referring to the top level compatible and
>> model properties?
>
> I think I might be getting ahead of myself, as I'm not yet up to speed on
> how the powerpc code base identifies unique machines. For instance the AR=
M
> codebase required that each new machine have a unique machine ID. When
> bringing up a new platform one had to request a new unique machine ID. Th=
e
> bootloader was required to pass this unique machine id to the kernel.
> We're still using quite a bit of the Yosemite code base and so I had
> assumed we are probably using the Yosemite boards "unique machine id" for
> our custom hardware. Although based on your response it sounds like
> powerpc =A0uses a different approach.
The powerpc kernel completely trusts the device tree blob that is
passed to it at boot time. Most of the platform support code simply
reads the top level 'compatible' property to decide whether or not it
can support the board. For example,
arch/powerpc/platforms/44x/ppc4xx_simple.c supports a bunch of boards,
including yosemite, and arch/powerpc/platforms/44x/ebony.c only
supports the ebony board. ppc4xx_simple.c, ebony.c, and other
platform support files can selected at the same time to build a kernel
which supports multiple boards (multi-platform).
Since there is no common boot mechanism shared between all powerpc
platforms, the bootwrapper is the adapter layer from whatever data is
provided by firmware to the form required by the kernel. As long as
the kernel-proper (vmlinux) receives a fully formed device tree at the
end, it is happy. Both firmware and the boot wrapper have the option
of modifying the device tree before passing it on to the next step.
One of the boot methods (uImage) even bypasses the bootwrapper step
entirely since U-Boot is able to pass a fully formed device tree
directly to the kernel.
One of the advantages of the device tree scheme is that the kernel
image format no longer needs to be board dependent. There is no need
to encode a board specific format anymore. Sure, you *can* use
simpleImage or dtbImage to build an image with an embedded dtb, but
those images are really just compatibility layers for existing
firmware, and using them throws away the advantage of splitting the
hardware description from the kernel image. Not to mention that the
building of board specific images is a maze of special cases and
barely documented heuristics in arch/powerpc/boot/wrapper.
If you've got control over your boot firmware, and you don't want to
use U-Boot, then I strongly recommend that at the very least you keep
the .dtb separate from the kernel image and don't write any board
specific code in the boot wrapper. Keep your board specific code in
arch/powerpc/platforms/44x/* where it is easy for mere mortals to
comprehend. Get the firmware to copy both the dtb and kernel into RAM
and pass the dtb pointer to the kernel. Ideally, you should use the
existing uImage format so you don't need to define something new (and
incompatible with anything else). However, parsing uImage requires
your firmware to include gunzip code.
Failing that, create a new zImage target (perhaps 'zImage.fdt') that
accepts a pointer to the .dtb blob in memory. Use the calling
convention described in Documentation/powerpc/booting-without-of.txt
for direct flattened device tree booting. At least that way your code
has a fighting chance of being useful to someone else. Code to do
this should be pretty trivial. In fact the simpleImage platform_init
could be refactored to provide a large chunk of common code. Only
difference really being the source pointer to the dtb.
Heck, you could even eliminate the boot wrapper entirely and use the
vmlinux image directly; but the kernel image can be quite large and
then you'd probably want it gzipped (which means our firmware must be
able to gunzip it).
One last think. It's not a good idea to link the .dtb image into the
firmware either. Many people have learned the hard way that device
trees often need to be tweaked after the firmware is deployed. Make
the dtb a separate image that can be updated in the same way that the
kernel image can be updated.
Have fun,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Ben Menchaca @ 2009-03-08 3:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Liu Dave-R63238
In-Reply-To: <1236462686.7260.161.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Sat, Mar 7, 2009 at 3:51 PM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Fri, 2009-03-06 at 10:12 -0600, Ben Menchaca wrote:
> > Testing now...it looks like it (almost) works, though! Why does
> > setting no-snoop cause snooping to work? More on the effect on
> > setting that bit in a few minutes...need more testing.
>
> Maybe they got the documentation for that bit backward ? :-)
For posterity...it does appear that this is the case. I don't have a bus
analyzer to watch the transaction, but a JTAG trigger caught the update
happening if and only if bit 3 was set in the (R|W)DMA descriptor. My FAE
at FS said he is watching this thread, so hopefully some doc errata can be
generated so others can avoid my confusion :-).
- Ben
[-- Attachment #2: Type: text/html, Size: 1091 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/usb: Fix 440EPx USBH_3 & USBH_5 EHCI errata
From: Benjamin Herrenschmidt @ 2009-03-07 22:00 UTC (permalink / raw)
To: - Reyneke; +Cc: linuxppc-dev, dbrownell, Alan Stern
In-Reply-To: <BAY101-W12966ECAF38C4FD6F26513BEA50@phx.gbl>
On Fri, 2009-03-06 at 11:30 +0000, - Reyneke wrote:
> Patch applies to 440EPx devices in USB EHCI host mode (USB 2.0).
>
> >From the 440EPx errata:
>
> USBH_3: Host hangs after underrun or overrun occurs
> USBH_5: EHCI0_INSNREGxx registers are reset by a Soft or Light Host Controller Reset
>
> Workround for USBH_3 is to enable Break Memory Transfer (BMT) in INSNREG3. But the controller is reset after this fix is applied, and thus the current workround is lost. The following short patch ensures INSNREG3 is correctly set after reset.
> Signed-off-by: Jan Reyneke
Please provide a valid email address here.
> ---
> ehci-hcd.c | 7 +++++++
> ehci-ppc-of.c | 30 +++++++++++++++++++-----------
> ehci.h | 5 +++++
> 3 files changed, 31 insertions(+), 11 deletions(-)
>
> diff -uprN a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> --- a/drivers/usb/host/ehci.h 2009-03-04 01:05:22.000000000 +0000
> +++ b/drivers/usb/host/ehci.h 2009-03-06 10:52:53.000000000 +0000
> @@ -137,6 +137,11 @@ struct ehci_hcd { /* one per controlle
>
> u8 sbrn; /* packed release number */
>
> +#if defined(CONFIG_440EPX)
> + #define PPC440EPX_EHCI0_INSREG_BMT (0x1 << 0)
> + __iomem u32 *insn_regs; /* INSNREGx device memory/io */
> +#endif
I don't think you need the above based on what you do later on...
(see comments below)
> /* irq statistics */
> #ifdef EHCI_STATS
> struct ehci_stats stats;
> diff -uprN a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> --- a/drivers/usb/host/ehci-hcd.c 2009-03-04 01:05:22.000000000 +0000
> +++ b/drivers/usb/host/ehci-hcd.c 2009-03-06 10:54:36.000000000 +0000
> @@ -217,6 +217,13 @@ static int ehci_reset (struct ehci_hcd *
> if (ehci_is_TDI(ehci))
> tdi_reset (ehci);
>
> +#if defined(CONFIG_440EPX)
> + /* USBH_5: INSN values are lost on reset -> redo USBH_3.
> + See also ppc44x_enable_bmt.*/
> + if (ehci->insn_regs)
> + out_be32(ehci->insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
> +#endif
A few issues here. First, it would be preferable to have this in the
ehci-ppc-of.c file. If you can't stick that in such a place that it will
be called after ehci_reset, then maybe you can add a reset "hook" so
that ehci-ppc-of.c gets to wrap the real ehci_reset().
Also, while the ifdef CONFIG_440EPX is good to prevent building the code
on machines that don't need it, it's also not enough. We allow building
kernels that support multiple boards and SoC's within the same major CPU
family and thus you -also- need runtime detection. Either using a quirk
(I think the USB drivers have quirk flags) or just always doing the
of_device_is_compatible() thingy which is yet another reason for finding
a way to move that up into ehci-ppc-of.c
That would also avoid some duplication...
> /*
> - * 440EPx Errata USBH_3
> - * Fix: Enable Break Memory Transfer (BMT) in INSNREG3
> - */
> -#define PPC440EPX_EHCI0_INSREG_BMT (0x1 << 0)
> + * 440EPx Errata USBH_3 & USBH_5
> + * Fix: Enable Break Memory Transfer (BMT) in INSNREG3. Also cache
> + * the registers so we can redo the USBH_3 fix on future resets */
> static int __devinit
> -ppc44x_enable_bmt(struct device_node *dn)
> +ppc44x_enable_bmt(struct device_node *dn, struct ehci_hcd* ehci)
> {
> - __iomem u32 *insreg_virt;
>
> - insreg_virt = of_iomap(dn, 1);
> - if (!insreg_virt)
> +#if defined(CONFIG_440EPX)
> +
> + ehci->insn_regs = of_iomap(dn, 1);
> + if (!ehci->insn_regs)
> return -EINVAL;
>
> - out_be32(insreg_virt + 3, PPC440EPX_EHCI0_INSREG_BMT);
> + out_be32(ehci->insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
>
> - iounmap(insreg_virt);
> +#endif
> return 0;
> +
> }
So if you manage to move the quirk here, you can thus re-use the
existing code, or is the reset always called in a context where you
can't iomap ? (ie with a spinlock held).
In any case, I don't like adding a specific field to the generic ehci
structure like that. If that's what it takes, add a void
*platform_private to it, and use -that- to stick a host specific data
structure, but for something not performance sensitive such as a reset,
if you can get away with always mapping/unmapping, it's probably better.
Cheers,
Ben.
^ permalink raw reply
* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
From: Benjamin Herrenschmidt @ 2009-03-07 21:51 UTC (permalink / raw)
To: Ben Menchaca; +Cc: linuxppc-dev, Liu Dave-R63238
In-Reply-To: <64ac01180903060812n1f355207lb3fa6de3ed17ae41@mail.gmail.com>
On Fri, 2009-03-06 at 10:12 -0600, Ben Menchaca wrote:
> Testing now...it looks like it (almost) works, though! Why does
> setting no-snoop cause snooping to work? More on the effect on
> setting that bit in a few minutes...need more testing.
Maybe they got the documentation for that bit backward ? :-)
Cheers,
Ben.
> ACR is 0x00030300.
>
> - Ben
>
> On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238
> <DaveLiu@freescale.com> wrote:
> Did you enable the descriptor bit 3 to have a try?
>
>
> ______________________________________________________
> From: Ben Menchaca [mailto:ben.menchaca@gmail.com]
>
> Sent: Friday, March 06, 2009 2:10 PM
>
>
> To: Liu Dave-R63238
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: 83xx: Marking or Allocating Pages as
> Cache-Inhibited
>
>
>
>
>
> I can look at ACR morning...although I can say with a
> fair amount of certainty that I have not changed it
> from the POR value.
>
> I will try enabling No Snoop for CSB in the descriptor
> (bit 3, yes?)...this seems a bit counterintuitive to
> me.
>
> What is the hope regarding these two? Some
> combination I am not seeing?
>
>
> On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238
> <DaveLiu@freescale.com> wrote:
> what is the value of ACR register?
>
>
> ______________________________________
> From: Ben Menchaca
> [mailto:ben.menchaca@gmail.com]
> Sent: Friday, March 06, 2009 1:38 PM
> To: Liu Dave-R63238
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: 83xx: Marking or
> Allocating Pages as Cache-Inhibited
>
>
>
>
> 1. BAT2 in linux is set to WIMG=0010,
> and covers all 64M
> 2. PEX_DEVICE_CONTROL in PCI-E Config
> Space (0x54): 0x1020
> 3. PEX_xDMA_CTRL is set to 0x00000401
> at the initiation of the DMA.
> 4. OWAR0 is set to 0xFFFFF005, so
> NSNP is 0.
> 5. The DMA descriptor (randomly
> chosen when I hit a trigger...just
> ignore the size...) contains 0002AFF3
> at offset 0, so nosnoops are
> cleared.
>
> Core is 400MHz, and CSB is 133MHz.
>
> - Ben
>
> On Thu, Mar 5, 2009 at 11:27 PM, Liu
> Dave-R63238 <DaveLiu@freescale.com>
> wrote:
> and what settings is DMA
> description bit 3?
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces
> +daveliu=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces
> +daveliu=freescale.com@ozlabs.org]
>
>
> > On Behalf Of Liu
> Dave-R63238
> > Sent: Friday, March 06, 2009
> 1:22 PM
> > To: Ben Menchaca;
> linuxppc-dev@ozlabs.org
> > Subject: RE: 83xx: Marking
> or Allocating Pages as
> Cache-Inhibited
> >
> > Did you enable the snoop bit
> at PEX_WDMA_CTRL[SNOOP] and
> > PEX_RDMA_CTRL[SNOOP]?
> >
> > What is the freq settings?
> CORE/CSB bus.
> >
> > Thanks, Dave
> >
> >
> ________________________________
> >
> > From:
> linuxppc-dev-bounces
> +daveliu=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces
> +daveliu=freescale.com@ozlabs.org]
> > On Behalf Of Ben Menchaca
> > Sent: Friday, March
> 06, 2009 12:33 PM
> > To:
> linuxppc-dev@ozlabs.org
> > Subject: 83xx: Marking
> or Allocating Pages as
> Cache-Inhibited
> >
> >
> > I am working on a
> Freescale 8314e design, and
> the
> > embedded device is
> configured as a PCI-e endpoint
> running a
> > 2.6.27-5 kernel. For
> context, we have written a
> kernel
> > module which, among other
> things, uses the RDMA/WDMA
> engine
> > in the PCI-e IP block. On
> the host side, these DMAs are
> > coherent. However, on the
> embedded side, things are
> quite a
> > bit less rosy; we must
> manually flush/invalidate
> cache lines
> > for WDMA/RDMAs to occur
> successfully. After speaking
> with
> > (several) FAEs at Freescale,
> we believe there is a
> > configuration issue that is
> the cause, but we have yet to
> > have anyone successfully
> point to it.
> >
> > Disabling the data
> cache altogether resolves the
> issue
> > entirely, but of course,
> also completely tanks
> performance.
> > As a temporary workaround, I
> would like to simply mark the
> > pages (obtained currently
> via dma_alloc_coherent)
> involved as
> > cache-inhibited. I have
> attempted to do this via some
> > snippets remaining in fec.c
> (va_to_pte, uncache_pte to set
> > _PAGE_NO_CACHE,
> flush_tlb_page, then
> unmap_pte), but this is
> > almost certainly braindead;
> va_to_pte is not a part of the
> > 83xx source, as far as I can
> tell; 8xx only.
> >
> > A quick pointer in the
> correct direction for marking
> > pages as cache-inhibited on
> a 2.6.27-5 kernel would be
> > appreciated, or if my
> approach to a workaround is
> flawed, a
> > pointer to the correct way
> would be great.
> >
> > Ben Menchaca
> >
> >
>
> >
> _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> >
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
>
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH, RFC]
From: Eddie Dawydiuk @ 2009-03-07 16:37 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev
Hello,
>> So if you have any suggestions on
>> this approach using the simpleImage please let me know.
>
> Before I answer this, what bootloader are you using?
We are using a custom bootloader we developed ourselves. The bootloader is
very minimal as one of our primary design goals is a fast boot time. We do
some basic initialization of the AMCC 440EP, then load the simpleImage
into RAM at address 0 and jump into it. In my mind I had considered our
code as more of a bootrom and the simpleboot.c as a bootloader ;)
>> On another note, can you tell me/point me to some documentation on how
>> to get a unique machine ID for a new board?
>
> What do you mean? Are you referring to the top level compatible and
> model properties?
I think I might be getting ahead of myself, as I'm not yet up to speed on
how the powerpc code base identifies unique machines. For instance the ARM
codebase required that each new machine have a unique machine ID. When
bringing up a new platform one had to request a new unique machine ID. The
bootloader was required to pass this unique machine id to the kernel.
We're still using quite a bit of the Yosemite code base and so I had
assumed we are probably using the Yosemite boards "unique machine id" for
our custom hardware. Although based on your response it sounds like
powerpc uses a different approach.
//Eddie
^ permalink raw reply
* Re: [PATCH, RFC]
From: Grant Likely @ 2009-03-07 16:06 UTC (permalink / raw)
To: eddie; +Cc: linuxppc-dev
In-Reply-To: <60088.70.162.219.205.1236438881.squirrel@oz.embeddedx86.com>
On Sat, Mar 7, 2009 at 8:14 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
> Hello,
>
>> But the question remains: Why do you need simpleboot support for
>> Yosemite when you can use a uImage or cuImage with u-boot?
>
> We are developing a new board based upon the Yosemite board. Seeing as
> though the Yosemite board was supported in the mainline kernel I decided
> to start with that code base. After looking at what different
> options/images were available for device trees vs open firmware I decided
> the simpleImage would be the ideal format for our new board. I then read
> how to build a simpleImage for the Yosemite board, which build without any
> compiler errors. Although I found the image didn't work, so I figured it
> might be helpful for others if the image just worked without
> modifications. Although shortly I will be submitting support for our
> custom board using this same approach. So if you have any suggestions on
> this approach using the simpleImage please let me know.
Before I answer this, what bootloader are you using?
> On another note, can you tell me/point me to some documentation on how to
> get a unique machine ID for a new board?
What do you mean? Are you referring to the top level compatible and
model properties?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH, RFC]
From: Grant Likely @ 2009-03-07 16:04 UTC (permalink / raw)
To: eddie; +Cc: linuxppc-dev
In-Reply-To: <60135.70.162.219.205.1236439301.squirrel@oz.embeddedx86.com>
On Sat, Mar 7, 2009 at 8:21 AM, Eddie Dawydiuk <eddie@embeddedarm.com> wrot=
e:
> Hello,
>
>> On a more general note; this patch also diverges from the original
>> model for simple image. =A0The idea behind simpleimage was that it would
>> contain a fully formed device tree, with no fixups necessary. =A0I want
>> to think carefully before diverging from that.
>
> I wasn't aware of these design goals... I believe one can also modify the
> default dts file such that the RAM size is not dynamically detected so th=
e
> fixups aren't required(although keep in mind I haven't tested this).
Just to be clear, I'm not saying 'no'. I'm just not saying 'yes' yet
either. However, if you can fully form the dts file then that is
definitely my preference.
> Although it is quite convenient to add the fixed-head.o so one can jump
> into the simpleImage at offset 0 rather than having to check what the
> offset should be each time a change is made.
The missing fixed-head thing is a bug. I have no issue with that change.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* KGDB over serial on xilinx virtex-5 (ppc440)
From: srikanth krishnakar @ 2009-03-07 15:59 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]
Hi all,
Has anybody tested KGDBOC in linux-2.6.28 for Xilinx Virtex-5 PowerPC
target boards..
I just see that KGDB waits for remote connection from GDB host, but
unfortunately
Command line arguments were :
console=ttyS0 ip=bootp root=/dev/nfs rw kgdboc=ttyS0 kgdbwait
The test is been done on xilinx virtex-5 ppc440 target
Target side:
----------------
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = 16) is a 16550A
console [ttyS0] enabled
kgdb: Registered I/O driver kgdboc.
kgdb: Waiting for connection from remote gdb...
------------------
Host side
------------------
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $qSupported#37...Sending packet: $qSupported#37...Sending
packet: $qSupported#37...Sending packet: $qSupported#37...Timed out.
Timed out.
Timed out
.....
.....
------------------
Is anything else need to be implemented for ppc44x for KGDB to work ?
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #2: Type: text/html, Size: 1236 bytes --]
^ permalink raw reply
* Re: [PATCH, RFC]
From: Eddie Dawydiuk @ 2009-03-07 15:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eddie Dawydiuk
In-Reply-To: <fa686aa40903062141n210f81d7g9f11154f3c78cadc@mail.gmail.com>
Hello,
> On a more general note; this patch also diverges from the original
> model for simple image. The idea behind simpleimage was that it would
> contain a fully formed device tree, with no fixups necessary. I want
> to think carefully before diverging from that.
I wasn't aware of these design goals... I believe one can also modify the
default dts file such that the RAM size is not dynamically detected so the
fixups aren't required(although keep in mind I haven't tested this).
Although it is quite convenient to add the fixed-head.o so one can jump
into the simpleImage at offset 0 rather than having to check what the
offset should be each time a change is made.
//Eddie
^ permalink raw reply
* Re: [PATCH, RFC]
From: Eddie Dawydiuk @ 2009-03-07 15:14 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903062022i2211ccdfu1bffab54749615d8@mail.gmail.com>
Hello,
> But the question remains: Why do you need simpleboot support for
> Yosemite when you can use a uImage or cuImage with u-boot?
We are developing a new board based upon the Yosemite board. Seeing as
though the Yosemite board was supported in the mainline kernel I decided
to start with that code base. After looking at what different
options/images were available for device trees vs open firmware I decided
the simpleImage would be the ideal format for our new board. I then read
how to build a simpleImage for the Yosemite board, which build without any
compiler errors. Although I found the image didn't work, so I figured it
might be helpful for others if the image just worked without
modifications. Although shortly I will be submitting support for our
custom board using this same approach. So if you have any suggestions on
this approach using the simpleImage please let me know.
On another note, can you tell me/point me to some documentation on how to
get a unique machine ID for a new board?
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: [PATCH] powerpc/5200: remove sysfs debug file from GPT driver
From: Wolfram Sang @ 2009-03-07 10:13 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903061231h5d9ef9f4i3d080bf00b6e99fb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, Mar 06, 2009 at 01:31:41PM -0700, Grant Likely wrote:
> Wolfram, you were right. This was a bad idea. I just took me a bit
> longer to clue into it.
Instant ACK :D Thanks!
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
From: Juergen Beisert @ 2009-03-07 10:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Henk Stegeman
In-Reply-To: <ae4f76fd0902200151m461f9336x1e2bbec61f815fde@mail.gmail.com>
Henk,
On Freitag, 20. Februar 2009, Henk Stegeman wrote:
> - Any suggestions to what could be wrong here? Or does the MPC5200 in
> this case only byte swap u16 reads, but a u8 read is unchanged?
You should not follow the Freescale bus signal names when you connect your
external little endian device. Otherwise the offsets are always wrong.
Do it in this way instead:
MPC LE Device
D[0..7] <-> D[24..31]
D[8..15] <-> D[16..23]
D[16..23] <-> D[8..15]
D[24..31] <-> D[0..7]
If you connect your device in such a way, just enable CS's byte swap feature
depending on your bus size and you are done (no additional software
manipulation required). Now you can write bytes, words or longs and you will
always write the correct data into the corresponding device register.
Hope it helps
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH, RFC]
From: Grant Likely @ 2009-03-07 5:41 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40903062022i2211ccdfu1bffab54749615d8@mail.gmail.com>
On Fri, Mar 6, 2009 at 9:22 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Mar 6, 2009 at 3:32 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
>> Hello,
>>
>> Let's try this one more time. The last patch was using the clocks for a
>> custom board based on the Yosemite board and was referencing a non-existent
>> ethNadr( I forgot to pull out this code out).
>
> But the question remains: Why do you need simpleboot support for
> Yosemite when you can use a uImage or cuImage with u-boot?
On a more general note; this patch also diverges from the original
model for simple image. The idea behind simpleimage was that it would
contain a fully formed device tree, with no fixups necessary. I want
to think carefully before diverging from that.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox