* Re: [PATCH] ibm_newemac: Fixes entry of short packets
From: SathyaNarayanan @ 2008-06-27 6:36 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <1214263257.8011.278.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]
Hi benh,
Please find my comments inline.
On Tue, Jun 24, 2008 at 4:50 AM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Mon, 2008-06-23 at 14:55 +0200, Stefan Roese wrote:
> > From: Sathya Narayanan <sathyan@teamf1.com>
> >
> > Short packets has to be discarded by the driver. So this patch addresses
> the
> > issue of discarding the short packets of size lesser then ethernet header
> > size.
>
> You are freeing the skb, why ? Shouldn't we just keep the skb in the
> ring for further rx ?
Actually , short packets are not allowed to flow through the higher layers,
If any of the layer tried to use the extra room available may hit wit crash
.
Since it is a invalid packet it has to be dropped and freed in driver.
Actually if you see in code, the other invalid packets are also handelled
similar.
>
> > Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > drivers/net/ibm_newemac/core.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/ibm_newemac/core.c
> b/drivers/net/ibm_newemac/core.c
> > index 6dfc2c9..aa407b2 100644
> > --- a/drivers/net/ibm_newemac/core.c
> > +++ b/drivers/net/ibm_newemac/core.c
> > @@ -1652,6 +1652,13 @@ static int emac_poll_rx(void *param, int budget)
> >
> > skb_put(skb, len);
> > push_packet:
> > + if (skb->len < ETH_HLEN) {
> > + dev_kfree_skb(skb);
> > + printk(KERN_WARNING "%s: short packets dropped\n",
> > + dev->ndev->name);
> > + ++dev->estats.rx_dropped_stack;
> > + goto next;
> > + }
> > skb->dev = dev->ndev;
> > skb->protocol = eth_type_trans(skb, dev->ndev);
> > emac_rx_csum(dev, skb, ctrl);
>
>
[-- Attachment #2: Type: text/html, Size: 3259 bytes --]
^ permalink raw reply
* Re: Rapidio interface in recent kernels
From: Alex Dubov @ 2008-06-27 6:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <1CE525D1-51A1-4A12-9059-441B133FA959@kernel.crashing.org>
--- On Thu, 6/26/08, Kumar Gala <galak@kernel.crashing.org> wrote:
> From: Kumar Gala <galak@kernel.crashing.org>
> Subject: Re: Rapidio interface in recent kernels
> To: oakad@yahoo.com
> Cc: linuxppc-embedded@ozlabs.org
> Date: Thursday, June 26, 2008, 6:35 AM
> On Jun 25, 2008, at 11:33 PM, Alex Dubov wrote:
>=20
> > Greetings.
> >
> > I was trying to make use of rapidio on recent (2.6.25)
> kernel (I =20
> > have a 8548
> > cpu). However, it seems that changes to the powerpc
> arch had broken =20
> > it.
> >
> > Therefore, the question: is there an anticipated fix
> or I'm on my =20
> > own here?
>=20
> Is there a compile error? if so please post it.
>=20
> - k
I'm using 2.6.25.8, but I think it's the same for all 2.6.25 kernels.
I set: ARCH=3Dpowerpc, CROSS_COMPILE=3Dpowerpc-linux-gnuspe-
The cpu is Freescale 8548, so "Processor Type" is Freescale 85xx
First, there's no Kconfig entry for rapidio, as it seems stuck in the
ppc subtree, with bad guarding condition (around line 1097 in
arch/ppc/Kconfig), so I just copied it into arch/powerpc/Kconfig (without
the conditional for now).
And now for the build errors:
Stage 1:
arch/powerpc/kernel/rio.c:17:21: error: asm/rio.h: No such file or=20
directory
Stage 2 (after fixing stage 1):
arch/powerpc/sysdev/fsl_rio.c: In function =E2rio_open_outb_mbox=E2:
arch/powerpc/sysdev/fsl_rio.c:455: error: =E2MPC85xx_IRQ_RIO_TX=E2 undeclar=
ed=20
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c:455: error: (Each undeclared identifier is=20
reported only once
arch/powerpc/sysdev/fsl_rio.c:455: error: for each function it appears in.)
arch/powerpc/sysdev/fsl_rio.c: In function =E2rio_close_outb_mbox=E2:
arch/powerpc/sysdev/fsl_rio.c:510: error: =E2MPC85xx_IRQ_RIO_TX=E2 undeclar=
ed=20
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c: In function =E2rio_open_inb_mbox=E2:
arch/powerpc/sysdev/fsl_rio.c:600: error: =E2MPC85xx_IRQ_RIO_RX=E2 undeclar=
ed=20
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c: In function =E2rio_close_inb_mbox=E2:
arch/powerpc/sysdev/fsl_rio.c:647: error: =E2MPC85xx_IRQ_RIO_RX=E2 undeclar=
ed=20
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c: In function =E2mpc85xx_rio_doorbell_init=E2:
arch/powerpc/sysdev/fsl_rio.c:838: error: =E2MPC85xx_IRQ_RIO_BELL=E2 undecl=
ared (first use in this function)
arch/powerpc/sysdev/fsl_rio.c: In function =E2mpc85xx_rio_setup=E2:
arch/powerpc/sysdev/fsl_rio.c:916: error: =E2CCSRBAR=E2 undeclared (first u=
se=20
in this function)
And the worst thing is - those macros are defined using old style ppc
register defines and I don't have a nearest idea how to fix it on a new=20
style kernel (for one - CCSRBAR is replaced with some runtime thingie).
=0A=0A=0A
^ permalink raw reply
* Re: [PATCH 01/12] pata_mpc52xx: use linux/of_platform.h instead of asm
From: Jeff Garzik @ 2008-06-27 6:37 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Tejun Heo, Sylvain Munaut
In-Reply-To: <20080523161627.a75d5010.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/ata/pata_mpc52xx.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> I am not sure who wants to take this.
>
> diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
> index bc79df6..a9e8273 100644
> --- a/drivers/ata/pata_mpc52xx.c
> +++ b/drivers/ata/pata_mpc52xx.c
> @@ -16,10 +16,10 @@
> #include <linux/slab.h>
> #include <linux/delay.h>
> #include <linux/libata.h>
> +#include <linux/of_platform.h>
>
> #include <asm/types.h>
> #include <asm/prom.h>
> -#include <asm/of_platform.h>
> #include <asm/mpc52xx.h>
ACK. send it via an arch tree
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
From: SathyaNarayanan @ 2008-06-27 6:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <1214263216.8011.276.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]
Hi benh,
Please find my comments inline.
Thanks and regards,
SathyaNarayanan
On Tue, Jun 24, 2008 at 4:50 AM, Benjamin Herrenschmidt <
benh@kernel.crashing.org> wrote:
> On Mon, 2008-06-23 at 14:54 +0200, Stefan Roese wrote:
> > From: Sathya Narayanan <sathyan@teamf1.com>
> >
> > The descriptor pointers were not initialized to NIL values, so it was
> > poiniting to some random addresses which was completely invalid. This
> > fix takes care of initializing the descriptor to NIL values and clearing
> > the valid descriptors on clean ring operation.
> >
> > Signed-off-by: Sathya Narayanan <sathyan@teamf1.com>
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > ---
> > drivers/net/ibm_newemac/core.c | 6 +++++-
> > 1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/ibm_newemac/core.c
> b/drivers/net/ibm_newemac/core.c
> > index 5d2108c..6dfc2c9 100644
> > --- a/drivers/net/ibm_newemac/core.c
> > +++ b/drivers/net/ibm_newemac/core.c
> > @@ -1025,7 +1025,7 @@ static void emac_clean_tx_ring(struct emac_instance
> *dev)
> > int i;
> >
> > for (i = 0; i < NUM_TX_BUFF; ++i) {
> > - if (dev->tx_skb[i]) {
> > + if (dev->tx_skb[i] && dev->tx_desc[i].data_ptr) {
>
> Why changing the test above ?
The reason for changing this condition is , In any of the case if the
dev->tx_skb is not containing valid address, Then while clearing it you may
be resulted in "address voilations". This additional condition ensures that
we are clearing the valid skbs.
Further this condition is not in general data flow, So this additional
condition should not have any impact on performance.
>
>
> > dev_kfree_skb(dev->tx_skb[i]);
> > dev->tx_skb[i] = NULL;
> > if (dev->tx_desc[i].ctrl & MAL_TX_CTRL_READY)
> > @@ -2719,6 +2719,10 @@ static int __devinit emac_probe(struct of_device
> *ofdev,
> > /* Clean rings */
> > memset(dev->tx_desc, 0, NUM_TX_BUFF * sizeof(struct
> mal_descriptor));
> > memset(dev->rx_desc, 0, NUM_RX_BUFF * sizeof(struct
> mal_descriptor));
> > + for (i = 0; i <= NUM_TX_BUFF; i++)
> > + dev->tx_skb[i] = NULL;
> > + for (i = 0; i <= NUM_RX_BUFF; i++)
> > + dev->rx_skb[i] = NULL;
>
> Why not use memset here too ?
Yes, It was valid to use memset here. I can send the modified patch for
it.
>
>
> > /* Attach to ZMII, if needed */
> > if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII) &&
>
>
[-- Attachment #2: Type: text/html, Size: 4135 bytes --]
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
From: Benjamin Herrenschmidt @ 2008-06-27 8:54 UTC (permalink / raw)
To: SathyaNarayanan; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <1946a170806262354k582ad86asc9a1a8383aad45a4@mail.gmail.com>
>
> > for (i = 0; i < NUM_TX_BUFF; ++i) {
> > - if (dev->tx_skb[i]) {
> > + if (dev->tx_skb[i] &&
> dev->tx_desc[i].data_ptr) {
>
>
> Why changing the test above ?
>
> The reason for changing this condition is , In any of the case if
> the dev->tx_skb is not containing valid address, Then while clearing
> it you may be resulted in "address voilations". This additional
> condition ensures that we are clearing the valid skbs.
> Further this condition is not in general data flow, So this additional
> condition should not have any impact on performance.
Do you see -any- case where tx_skb[i] and dev->tx_desc[i].data_ptr would
be out of sync ? If that's the case, shouldn't we cleanup instead of
leaving some kind of stale entry in the ring ?
In addition, in pure theory, data_ptr == 0 is a valid DMA address :-) So
I think that part of the patch shouldn't be there.
>
> > dev_kfree_skb(dev->tx_skb[i]);
> > dev->tx_skb[i] = NULL;
> > if (dev->tx_desc[i].ctrl &
> MAL_TX_CTRL_READY)
> > @@ -2719,6 +2719,10 @@ static int __devinit
> emac_probe(struct of_device *ofdev,
> > /* Clean rings */
> > memset(dev->tx_desc, 0, NUM_TX_BUFF * sizeof(struct
> mal_descriptor));
> > memset(dev->rx_desc, 0, NUM_RX_BUFF * sizeof(struct
> mal_descriptor));
> > + for (i = 0; i <= NUM_TX_BUFF; i++)
> > + dev->tx_skb[i] = NULL;
> > + for (i = 0; i <= NUM_RX_BUFF; i++)
> > + dev->rx_skb[i] = NULL;
>
>
> Why not use memset here too ?
> Yes, It was valid to use memset here. I can send the modified
> patch for it.
Please do, thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fixes entry of short packets
From: Benjamin Herrenschmidt @ 2008-06-27 8:58 UTC (permalink / raw)
To: SathyaNarayanan; +Cc: linuxppc-dev, Stefan Roese, netdev
In-Reply-To: <1946a170806262336y4aa3621at16520fc546bbe4b1@mail.gmail.com>
>
>
> Actually , short packets are not allowed to flow through the higher
> layers, If any of the layer tried to use the extra room available may
> hit wit crash .
> Since it is a invalid packet it has to be dropped and freed in driver.
> Actually if you see in code, the other invalid packets are also
> handelled similar.
My point is they should not. The rx skb should be kept in the ring for
further rx (ie, the data ignored and re-use the skb). A bit like we do
when we decide the packet is small enough to be copied to a new skb.
Ie. Move you test above the threshold test and recycle the skb.
We need to fix the usage of the dma operations in this driver anyway
and this will make it easier as we'll be able to avoid re-mapping an
skb we just recycle. (the current driver never unmaps which means it
can't be used with an iommu, which is a problem on some cell based
platforms).
Ben.
^ permalink raw reply
* Re: [PATCH 26/60] microblaze_v4: time support
From: Thomas Gleixner @ 2008-06-27 10:43 UTC (permalink / raw)
To: monstr
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <1214483429-32360-27-git-send-email-monstr@seznam.cz>
On Thu, 26 Jun 2008, monstr@seznam.cz wrote:
> +
> +static inline void udelay(unsigned long usec)
> +{
> +}
shouldnt this function be named zerodelay() ?
Thanks,
tglx
^ permalink raw reply
* Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree
From: Arnd Bergmann @ 2008-06-27 11:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Rigby
In-Reply-To: <4b73d43f0806262040s7993dcb7vd8a3d05793ea8a7@mail.gmail.com>
On Friday 27 June 2008, John Rigby wrote:
> On Thu, Jun 26, 2008 at 7:42 PM, David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > [snip]
> >> soc@80000000 {
> >> compatible = "fsl,mpc5121-immr";
> >> + device_type = "soc";
> >
> > I realise we still need the unwanted device_type value on the soc in
> > some cases for backwards compatibility, but why are you adding it
> > where it wasn't before..?
> >
> Because get_immrbase in fsl_soc.c does not work without it.
>
I guess that's not much of a problem in the future any more, since with the
move to arch/powerpc, the few remaining drivers that still use it can
finally be converted to use of_iomap on the actual device instead of
the immrbase hack.
Arnd <><
^ permalink raw reply
* Re: Please pull from 'powerpc-next' branch
From: Paul Mackerras @ 2008-06-27 11:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <98D3041A-F888-4991-9B10-CF4A9AD4A5BD@kernel.crashing.org>
Kumar Gala writes:
> Paul, any update on when we might see some of the various patches
> pulled into powerpc-next?
This weekend assuming I get over this gastric flu-like lurgy that I
have at the moment.
> I've got some work I'd like to see in .27 but it needs Michael's code
> patching patches.
I thought you had some concerns about patches 5/14 and 12/14 of his
series?
Paul.
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Adrian Bunk @ 2008-06-27 11:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, alan, Michal Simek, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, john.williams
In-Reply-To: <200806270123.06669.arnd@arndb.de>
On Fri, Jun 27, 2008 at 01:23:05AM +0200, Arnd Bergmann wrote:
> On Thursday 26 June 2008, Adrian Bunk wrote:
> > Honestly, I do not completely like your approach of getting the
> > microblaze port submitter to create the asm-generic files - I would
> > personally prefer if the microblaze port would look exactly like all
> > other ports and the (reasonable) changes you have in mind were not
> > being discussed and done as part of the submission of a new port.
>
> But it works really well this way ;-). My point is that a new port
> should look just like all the other ports should have looked as
> well, not like they did. When it comes to the ABI, you
> cannot make incompatible changes after it's merged, so IMHO all
> ABI defining headers should go to asm-generic if possible.
>...
For the ABI it doesn't matter where the headers are.
> > After all, it won't matter whether we'll unify resp. remove
> > 22 or 23 files.
>
> That wasn't my idea. The logic was that if one more file exists
> in asm-generic that can be removed from the architectures,
> we get 22 more files to remove without anyone having to look
> at the big picture. When microblaze is in,
Discussions of the "big picture" should be in an own thread, not as
part of a merge of a new architecture.
I am not an architecture maintainer, but I do not like the way you want
to couple the microblaze merge with the move of stuff to asm-generic.
They both make sense, but they are clearly separate issues.
> I can compile a list
> with asm-generic files that can be used to replace the architecture
> specific files, so the arch maintainers can decide on their own
> whether to clean their own stuff up or not.
>...
We need either all architectures changed or none at all - we do need the
arch headers to become more similar, not more different.
And this is why we need an agreement _before_ an asm-generic header gets
added, not after it.
> Arnd <><
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [RFC 1/3] powerpc: __copy_tofrom_user tweaked for Cell
From: Gunnar von Boehn @ 2008-06-27 13:30 UTC (permalink / raw)
To: Paul Mackerras
Cc: Mark Nelson, Arnd Bergmann, sanjay3000, linuxppc-dev,
Michael Ellerman, cbe-oss-dev
In-Reply-To: <18528.13965.55621.496788@cargo.ozlabs.ibm.com>
Hi Paul,
> In my experience, dcbz slows down the hot-cache case because it adds a
> few cycles to the execution time of the inner loop, and on most 64-bit
> PowerPC implementations, it doesn't actually help even in the
> cold-cache case because the store queue does enough write combining
I agree with you that on POWER the dcbz is probably not helping.
On PowerPC my experience is different.
>From what I have seen DCBZ help enormously on 970,PA-Semi and CELL.
Cheers
Gunnar
Paul Mackerras
<paulus@samba.org
> To
Gunnar von
24/06/2008 01:49 Boehn/Germany/Contr/IBM@IBMDE
cc
sanjay3000@yahoo.com, Mark Nelson
<markn@au1.ibm.com>,
linuxppc-dev@ozlabs.org, Michael
Ellerman <ellerman@au1.ibm.com>,
cbe-oss-dev@ozlabs.org, Arnd
Bergmann <arnd@arndb.de>
Subject
Re: [RFC 1/3] powerpc:
__copy_tofrom_user tweaked for Cell
Gunnar von Boehn writes:
> Interesting points.
> Can you help me to understand where the negative effect of DCBZ does come
> from?
In my experience, dcbz slows down the hot-cache case because it adds a
few cycles to the execution time of the inner loop, and on most 64-bit
PowerPC implementations, it doesn't actually help even in the
cold-cache case because the store queue does enough write combining
that the cache doesn't end up reading the line from memory. I don't
know whether the Cell PPE can do that, but I could believe that it
can't.
Paul.
^ permalink raw reply
* [PATCH]: [MPC5200] (v2) Add ATA DMA support
From: Tim Yamin @ 2008-06-27 12:44 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Changes from previous version:
- Add FIFO status error checking code before a DMA transaction starts
and after it is completed.
- Fix an incorrect check in the previous patch causing spurious "dma
table too small" errors.
Tim
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 1050-mpc5200-add-ATA-DMA.patch --]
[-- Type: text/x-patch; name=1050-mpc5200-add-ATA-DMA.patch, Size: 24397 bytes --]
This patch adds MDMA/UDMA support (using BestComm for DMA) on the MPC5200
platform.
Based heavily on previous work by Freescale (Bernard Kuhn, John Rigby)
and Domen Puncer.
Using a SanDisk Extreme IV CF card I get read speeds of approximately
26.70 MB/sec.
The BestComm ATA task priority was changed to maximum in bestcomm_priv.h;
this fixes a deadlock issue I was experiencing when heavy DMA was
occuring on both the ATA and Ethernet BestComm tasks, e.g. when
downloading a large file over a LAN to disk.
There's also what I believe to be a hardware bug if you have high levels
of BestComm ATA DMA activity along with heavy LocalPlus Bus activity;
the address bus seems to sometimes get corrupted with ATA commands while
the LocalPlus Bus operation is still active (i.e. Chip Select is asserted).
I've asked Freescale about this but have not received a reply yet -- if
anybody from Freescale has any ideas please contact me; I can supply some
analyzer traces if needed. Therefore, for now, do not enable DMA if you
need reliable LocalPlus Bus unless you do a fixup in your driver as
follows:
Locking example:
while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
{
struct bcom_task_2 *tsk = pata_mpc52xx_ata_dma_task;
if(bcom_buffer_done_2(tsk))
return 1;
}
return 0;
(Save the return value to `flags`)
Unlocking example:
if(flags == 0)
clear_bit(0, &pata_mpc52xx_ata_dma_lock);
Comments and testing would of course be very welcome.
Thanks,
Signed-off-by: Tim Yamin <plasm@roo.me.uk>
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/ata.h linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/ata.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/ata.h 2008-03-18 15:49:53.000000000 +0000
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/ata.h 2008-04-15 10:42:38.000000000 +0100
@@ -16,8 +16,8 @@
struct bcom_ata_bd {
u32 status;
- u32 dst_pa;
u32 src_pa;
+ u32 dst_pa;
};
extern struct bcom_task *
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-03-18 15:49:53.000000000 +0000
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-04-15 10:42:38.000000000 +0100
@@ -330,11 +330,10 @@
/* Init 'always' initiator */
out_8(&bcom_eng->regs->ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS);
- /* Disable COMM Bus Prefetch on the original 5200; it's broken */
- if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) == MPC5200_SVR) {
- regval = in_be16(&bcom_eng->regs->PtdCntrl);
- out_be16(&bcom_eng->regs->PtdCntrl, regval | 1);
- }
+ /* Disable COMM Bus Prefetch; ATA DMA does not work properly with it
+ enabled. */
+ regval = in_be16(&bcom_eng->regs->PtdCntrl);
+ out_be16(&bcom_eng->regs->PtdCntrl, regval | 1);
/* Init lock */
spin_lock_init(&bcom_eng->lock);
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-03-18 15:49:53.000000000 +0000
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-04-15 10:42:38.000000000 +0100
@@ -17,6 +17,7 @@
#define __BESTCOMM_H__
struct bcom_bd; /* defined later on ... */
+struct bcom_bd_2;
/* ======================================================================== */
@@ -49,6 +50,22 @@
void* priv;
};
+struct bcom_task_2 {
+ unsigned int tasknum;
+ unsigned int flags;
+ int irq;
+
+ struct bcom_bd_2 *bd;
+ phys_addr_t bd_pa;
+ void **cookie;
+ unsigned short index;
+ unsigned short outdex;
+ unsigned int num_bd;
+ unsigned int bd_size;
+
+ void* priv;
+};
+
#define BCOM_FLAGS_NONE 0x00000000ul
#define BCOM_FLAGS_ENABLE_TASK (1ul << 0)
@@ -95,6 +112,11 @@
u32 data[1]; /* variable, but at least 1 */
};
+struct bcom_bd_2 {
+ u32 status;
+ u32 data[2]; /* variable, but at least 2 */
+};
+
#define BCOM_BD_READY 0x40000000ul
/** _bcom_next_index - Get next input index.
@@ -108,6 +130,12 @@
return ((tsk->index + 1) == tsk->num_bd) ? 0 : tsk->index + 1;
}
+static inline int
+_bcom_next_index_2(struct bcom_task_2 *tsk)
+{
+ return ((tsk->index + 1) == tsk->num_bd) ? 0 : tsk->index + 1;
+}
+
/** _bcom_next_outdex - Get next output index.
* @tsk: pointer to task structure
*
@@ -129,6 +157,12 @@
return tsk->index == tsk->outdex;
}
+static inline int
+bcom_queue_empty_2(struct bcom_task_2 *tsk)
+{
+ return tsk->index == tsk->outdex;
+}
+
/**
* bcom_queue_full - Checks if a BestComm task BD queue is full
* @tsk: The BestComm task structure
@@ -151,6 +185,14 @@
return !(tsk->bd[tsk->outdex].status & BCOM_BD_READY);
}
+static inline int
+bcom_buffer_done_2(struct bcom_task_2 *tsk)
+{
+ if (bcom_queue_empty_2(tsk))
+ return 0;
+ return !(tsk->bd[tsk->outdex].status & BCOM_BD_READY);
+}
+
/**
* bcom_prepare_next_buffer - clear status of next available buffer.
* @tsk: The BestComm task structure
@@ -175,6 +217,22 @@
bcom_enable(tsk);
}
+static inline struct bcom_bd_2 *
+bcom_prepare_next_buffer_2(struct bcom_task_2 *tsk)
+{
+ tsk->bd[tsk->index].status = 0; /* cleanup last status */
+ return &tsk->bd[tsk->index];
+}
+
+static inline void
+bcom_submit_next_buffer_2(struct bcom_task_2 *tsk, void *cookie)
+{
+ tsk->cookie[tsk->index] = cookie;
+ mb(); /* ensure the bd is really up-to-date */
+ tsk->bd[tsk->index].status |= BCOM_BD_READY;
+ tsk->index = _bcom_next_index_2(tsk);
+}
+
static inline void *
bcom_retrieve_buffer(struct bcom_task *tsk, u32 *p_status, struct bcom_bd **p_bd)
{
diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
--- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h 2008-03-18 15:49:53.000000000 +0000
+++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h 2008-04-15 10:42:38.000000000 +0100
@@ -198,8 +198,8 @@ struct bcom_task_header {
#define BCOM_IPR_SCTMR_1 2
#define BCOM_IPR_FEC_RX 6
#define BCOM_IPR_FEC_TX 5
-#define BCOM_IPR_ATA_RX 4
-#define BCOM_IPR_ATA_TX 3
+#define BCOM_IPR_ATA_RX 7
+#define BCOM_IPR_ATA_TX 7
#define BCOM_IPR_SCPCI_RX 2
#define BCOM_IPR_SCPCI_TX 2
#define BCOM_IPR_PSC3_RX 2
diff -Nurp linux-2.6.26-rc6/drivers/ata/Kconfig linux-2.6.26-rc6.new/drivers/ata/Kconfig
--- linux-2.6.26-rc6/drivers/ata/Kconfig 2008-03-18 15:49:33.000000000 +0000
+++ linux-2.6.26-rc6.new/drivers/ata/Kconfig 2008-04-15 10:41:51.000000000 +0100
@@ -462,6 +462,15 @@
If unsure, say N.
+config PATA_MPC52xx_DMA
+ tristate "Freescale MPC52xx SoC internal IDE DMA"
+ depends on PATA_MPC52xx
+ help
+ This option enables support for DMA on the MPC52xx SoC PATA
+ controller.
+
+ If unsure, say N.
+
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
depends on PCI
diff -Nurp linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c
--- linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c 2008-03-18 15:49:33.000000000 +0000
+++ linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c 2008-04-15 10:41:49.000000000 +0100
@@ -6,6 +6,9 @@
* Copyright (C) 2006 Sylvain Munaut <tnt@246tNt.com>
* Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt
*
+ * UDMA support based on patches by Freescale (Bernard Kuhn, John Rigby),
+ * Domen Puncer and Tim Yamin.
+ *
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
* kind, whether express or implied.
@@ -17,28 +20,47 @@
#include <linux/delay.h>
#include <linux/libata.h>
+#include <asm/cacheflush.h>
#include <asm/types.h>
#include <asm/prom.h>
#include <asm/of_platform.h>
#include <asm/mpc52xx.h>
+#include <sysdev/bestcomm/bestcomm.h>
+#include <sysdev/bestcomm/bestcomm_priv.h>
+#include <sysdev/bestcomm/ata.h>
#define DRV_NAME "mpc52xx_ata"
#define DRV_VERSION "0.1.2"
-
/* Private structures used by the driver */
struct mpc52xx_ata_timings {
u32 pio1;
u32 pio2;
+ u32 mdma1;
+ u32 mdma2;
+ u32 udma1;
+ u32 udma2;
+ u32 udma3;
+ u32 udma4;
+ u32 udma5;
+ int using_udma;
};
struct mpc52xx_ata_priv {
unsigned int ipb_period;
struct mpc52xx_ata __iomem * ata_regs;
+ struct mpc52xx_ata __iomem * ata_regs_pa;
int ata_irq;
struct mpc52xx_ata_timings timings[2];
int csel;
+
+ /* DMA */
+ struct bcom_task * dmatsk;
+ const struct udmaspec * udmaspec;
+ const struct mdmaspec * mdmaspec;
+ int mpc52xx_ata_dma_last_write;
+ int waiting_for_dma;
};
@@ -53,6 +75,102 @@
#define CALC_CLKCYC(c,v) ((((v)+(c)-1)/(c)))
+/* ATAPI-4 MDMA specs (in clocks) */
+struct mdmaspec {
+ u32 t0M[3];
+ u32 td[3];
+ u32 th[3];
+ u32 tj[3];
+ u32 tkw[3];
+ u32 tm[3];
+ u32 tn[3];
+};
+
+// -----------------------------------------------------------------------------------------------
+
+static const struct mdmaspec mdmaspec66 = {
+ {32, 10, 8},
+ {15, 6, 5},
+ {2, 1, 1},
+ {2, 1, 1},
+ {15, 4, 2},
+ {4, 2, 2},
+ {1, 1, 1}
+};
+
+static const struct mdmaspec mdmaspec132 = {
+ {64, 20, 16},
+ {29, 11, 10},
+ {3, 2, 2},
+ {3, 1, 1},
+ {29, 7, 4},
+ {7, 4, 4},
+ {2, 1, 1}
+};
+
+
+/* ATAPI-4 UDMA specs (in clocks) */
+struct udmaspec {
+ u32 tcyc[6];
+ u32 t2cyc[6];
+ u32 tds[6];
+ u32 tdh[6];
+ u32 tdvs[6];
+ u32 tdvh[6];
+ u32 tfs_min[6];
+ u32 tli_max[6];
+ u32 tmli[6];
+ u32 taz[6];
+ u32 tzah[6];
+ u32 tenv_min[6];
+ u32 tsr[6];
+ u32 trfs[6];
+ u32 trp[6];
+ u32 tack[6];
+ u32 tss[6];
+};
+
+static const struct udmaspec udmaspec66 = {
+ { 8, 5, 4, 3, 2, 2},
+ {16, 11, 8, 6, 4 , 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ { 5, 4, 3, 2, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {16, 14, 12, 9, 8, 6},
+ {10, 10, 10, 7, 8, 5},
+ { 2, 2, 2, 2, 2, 2},
+ { 1, 1, 1, 1, 1, 1},
+ { 2, 2, 2, 2, 2, 2},
+ { 2, 2, 2, 2, 2, 2},
+ { 3, 2, 2, 2, 2, 2},
+ { 5, 5, 4, 4, 4, 4},
+ {11, 9, 7, 7, 7, 6},
+ { 2, 2, 2, 2, 2, 2},
+ { 4, 4, 4, 4, 4, 4}
+};
+
+static const struct udmaspec udmaspec132 = {
+ {15, 10, 6, 7, 2, 3},
+ {31, 21, 12, 12, 5, 6},
+ { 2, 2, 1, 1, 0, 1},
+ { 1, 1, 1, 1, 0, 1},
+ {10, 7, 5, 3, 1, 1},
+ { 1, 1, 1, 1, 1, 1},
+ {30, 27, 23, 15, 16, 12},
+ {20, 20, 20, 13, 14, 10},
+ { 3, 3, 3, 3, 2, 3},
+ { 2, 2, 2, 2, 1, 2},
+ { 3, 3, 3, 3, 2, 3},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 4, 3, 3, 2, 3},
+ {10, 10, 8, 8, 7, 7},
+ {22, 17, 14, 14, 13, 12},
+ { 3, 3, 3, 3, 2, 3},
+ { 7, 7, 7, 7, 6, 7},
+};
+
+// -----------------------------------------------------------------------------------------------
/* Bit definitions inside the registers */
#define MPC52xx_ATA_HOSTCONF_SMR 0x80000000UL /* State machine reset */
@@ -66,6 +184,7 @@
#define MPC52xx_ATA_HOSTSTAT_WERR 0x01000000UL /* Write Error */
#define MPC52xx_ATA_FIFOSTAT_EMPTY 0x01 /* FIFO Empty */
+#define MPC52xx_ATA_FIFOSTAT_ERROR 0x40 /* FIFO Error */
#define MPC52xx_ATA_DMAMODE_WRITE 0x01 /* Write DMA */
#define MPC52xx_ATA_DMAMODE_READ 0x02 /* Read DMA */
@@ -75,6 +194,8 @@
#define MPC52xx_ATA_DMAMODE_FR 0x20 /* FIFO Reset */
#define MPC52xx_ATA_DMAMODE_HUT 0x40 /* Host UDMA burst terminate */
+#define MAX_DMA_BUFFERS 128
+#define MAX_DMA_BUFFER_SIZE 0x20000u
/* Structure of the hardware registers */
struct mpc52xx_ata {
@@ -133,6 +254,9 @@
u8 reserved21[2];
};
+/* BestComm locking */
+unsigned long pata_mpc52xx_ata_dma_lock = 0;
+struct bcom_task_2 *pata_mpc52xx_ata_dma_task;
/* ======================================================================== */
/* Aux fns */
@@ -141,6 +265,19 @@
/* MPC52xx low level hw control */
+static inline void
+mpc52xx_ata_wait_tip_bit_clear(struct mpc52xx_ata __iomem *regs)
+{
+ int timeout = 1000;
+
+ while (in_be32(®s->host_status) & MPC52xx_ATA_HOSTSTAT_TIP)
+ if (timeout-- == 0) {
+ printk(KERN_ERR "mpc52xx-ide: Timeout waiting for TIP clear\n");
+ break;
+ }
+ udelay(10); /* FIXME: Necessary ??? */
+}
+
static int
mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv *priv, int dev, int pio)
{
@@ -165,6 +302,95 @@
return 0;
}
+static int
+mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t0M, td, tkw, tm, th, tj, tn;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t0M = priv->mdmaspec->t0M[speed];
+ td = priv->mdmaspec->td[speed];
+ tkw = priv->mdmaspec->tkw[speed];
+ tm = priv->mdmaspec->tm[speed];
+ th = priv->mdmaspec->th[speed];
+ tj = priv->mdmaspec->tj[speed];
+ tn = priv->mdmaspec->tn[speed];
+
+ DPRINTK ("t0M = %d\n", t0M);
+ DPRINTK ("td = %d\n", td);
+ DPRINTK ("tkw = %d\n", tkw);
+ DPRINTK ("tm = %d\n", tm);
+ DPRINTK ("th = %d\n", th);
+ DPRINTK ("tj = %d\n", tj);
+ DPRINTK ("tn = %d\n", tn);
+
+ timing->mdma1 = (t0M << 24) | (td << 16) | (tkw << 8) | (tm);
+ timing->mdma2 = (th << 24) | (tj << 16) | (tn << 8);
+
+ timing->using_udma = 0;
+
+ return 0;
+}
+
+static int
+mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_priv *priv, int dev, int speed)
+{
+ struct mpc52xx_ata_timings *timing = &priv->timings[dev];
+ u32 t2cyc, tcyc, tds, tdh, tdvs, tdvh, tfs, tli, tmli, taz, tenv, tsr, tss, trfs, trp, tack, tzah;
+
+ if (speed < 0 || speed > 2)
+ return -EINVAL;
+
+ t2cyc = priv->udmaspec->t2cyc[speed];
+ tcyc = priv->udmaspec->tcyc[speed];
+ tds = priv->udmaspec->tds[speed];
+ tdh = priv->udmaspec->tdh[speed];
+ tdvs = priv->udmaspec->tdvs[speed];
+ tdvh = priv->udmaspec->tdvh[speed];
+ tfs = priv->udmaspec->tfs_min[speed];
+ tmli = priv->udmaspec->tmli[speed];
+ tenv = priv->udmaspec->tenv_min[speed];
+ tss = priv->udmaspec->tss[speed];
+ trp = priv->udmaspec->trp[speed];
+ tack = priv->udmaspec->tack[speed];
+ tzah = priv->udmaspec->tzah[speed];
+ taz = priv->udmaspec->taz[speed];
+ trfs = priv->udmaspec->trfs[speed];
+ tsr = priv->udmaspec->tsr[speed];
+ tli = priv->udmaspec->tli_max[speed];
+
+ DPRINTK ("UDMA t2cyc = %d\n", t2cyc);
+ DPRINTK ("UDMA tcyc = %d\n", tcyc);
+ DPRINTK ("UDMA tds = %d\n", tds);
+ DPRINTK ("UDMA tdh = %d\n", tdh);
+ DPRINTK ("UDMA tdvs = %d\n", tdvs);
+ DPRINTK ("UDMA tdvh = %d\n", tdvh);
+ DPRINTK ("UDMA tfs = %d\n", tfs);
+ DPRINTK ("UDMA tli = %d\n", tli);
+ DPRINTK ("UDMA tmli = %d\n", tmli);
+ DPRINTK ("UDMA taz = %d\n", taz);
+ DPRINTK ("UDMA tenv = %d\n", tenv);
+ DPRINTK ("UDMA tsr = %d\n", tsr);
+ DPRINTK ("UDMA tss = %d\n", tss);
+ DPRINTK ("UDMA trfs = %d\n", trfs);
+ DPRINTK ("UDMA trp = %d\n", trp);
+ DPRINTK ("UDMA tack = %d\n", tack);
+ DPRINTK ("UDMA tzah = %d\n", tzah);
+
+ timing->udma1 = (t2cyc << 24) | (tcyc << 16) | (tds << 8) | (tdh);
+ timing->udma2 = (tdvs << 24) | (tdvh << 16) | (tfs << 8) | (tli);
+ timing->udma3 = (tmli << 24) | (taz << 16) | (tenv << 8) | (tsr);
+ timing->udma4 = (tss << 24) | (trfs << 16) | (trp << 8) | (tack);
+ timing->udma5 = (tzah << 24);
+
+ timing->using_udma = 1;
+
+ return 0;
+}
+
static void
mpc52xx_ata_apply_timings(struct mpc52xx_ata_priv *priv, int device)
{
@@ -173,14 +399,13 @@
out_be32(®s->pio1, timing->pio1);
out_be32(®s->pio2, timing->pio2);
- out_be32(®s->mdma1, 0);
- out_be32(®s->mdma2, 0);
- out_be32(®s->udma1, 0);
- out_be32(®s->udma2, 0);
- out_be32(®s->udma3, 0);
- out_be32(®s->udma4, 0);
- out_be32(®s->udma5, 0);
-
+ out_be32(®s->mdma1, timing->mdma1);
+ out_be32(®s->mdma2, timing->mdma2);
+ out_be32(®s->udma1, timing->udma1);
+ out_be32(®s->udma2, timing->udma2);
+ out_be32(®s->udma3, timing->udma3);
+ out_be32(®s->udma4, timing->udma4);
+ out_be32(®s->udma5, timing->udma5);
priv->csel = device;
}
@@ -245,6 +470,28 @@
mpc52xx_ata_apply_timings(priv, adev->devno);
}
static void
+mpc52xx_ata_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ int rv;
+
+ if (adev->dma_mode >= XFER_UDMA_0) {
+ int dma = adev->dma_mode - XFER_UDMA_0;
+ rv = mpc52xx_ata_compute_udma_timings(priv, adev->devno, dma);
+ } else {
+ int dma = adev->dma_mode - XFER_MW_DMA_0;
+ rv = mpc52xx_ata_compute_mdma_timings(priv, adev->devno, dma);
+ }
+
+ if (rv) {
+ printk(KERN_ERR DRV_NAME
+ ": Trying to select invalid DMA mode %d\n", adev->dma_mode);
+ return;
+ }
+
+ mpc52xx_ata_apply_timings(priv, adev->devno);
+}
+static void
mpc52xx_ata_dev_select(struct ata_port *ap, unsigned int device)
{
struct mpc52xx_ata_priv *priv = ap->host->private_data;
@@ -255,16 +502,208 @@
ata_sff_dev_select(ap,device);
}
+static void
+mpc52xx_sff_exec_command(struct ata_port *ap, const struct ata_taskfile *tf)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ mpc52xx_ata_wait_tip_bit_clear(priv->ata_regs);
+ ata_sff_exec_command(ap, tf);
+}
+
+static int
+mpc52xx_ata_build_dmatable(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs_pa = priv->ata_regs_pa;
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE), si;
+ struct scatterlist *sg;
+ int count = 0;
+
+ if (read)
+ bcom_ata_rx_prepare(priv->dmatsk);
+ else
+ bcom_ata_tx_prepare(priv->dmatsk);
+
+ for_each_sg(qc->sg, sg, qc->n_elem, si) {
+ u32 cur_addr = sg_dma_address(sg);
+ u32 cur_len = sg_dma_len(sg);
+
+ while (cur_len) {
+ unsigned int tc = min(cur_len, MAX_DMA_BUFFER_SIZE);
+ struct bcom_ata_bd *bd = (struct bcom_ata_bd *) bcom_prepare_next_buffer_2((struct bcom_task_2 *) priv->dmatsk);
+
+ if (read) {
+ bd->status = tc;
+ bd->src_pa = (__force u32) ®s_pa->fifo_data;
+ bd->dst_pa = cur_addr;
+
+ invalidate_dcache_range((__force u32) phys_to_virt(cur_addr), (__force u32) phys_to_virt(cur_addr) + (__force u32) cur_len);
+ } else {
+ bd->status = tc;
+ bd->src_pa = cur_addr;
+ bd->dst_pa = (__force u32) ®s_pa->fifo_data;
+
+ flush_dcache_range((__force u32) phys_to_virt(cur_addr), (__force u32) phys_to_virt(cur_addr) + (__force u32) cur_len);
+ }
+
+ bcom_submit_next_buffer_2((struct bcom_task_2 *) priv->dmatsk, NULL);
+
+ cur_addr += tc;
+ cur_len -= tc;
+ count++;
+
+ if (count > MAX_DMA_BUFFERS) {
+ printk(KERN_ALERT "%s: %i dma table too small\n", __func__, __LINE__);
+ goto use_pio_instead;
+ }
+ }
+ }
+ return 1;
+
+use_pio_instead:
+ bcom_ata_reset_bd(priv->dmatsk);
+
+ return 0;
+}
+
+static void
+mpc52xx_bmdma_setup(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+ struct mpc52xx_ata __iomem *regs = priv->ata_regs;
+
+ unsigned int read = !(qc->tf.flags & ATA_TFLAG_WRITE);
+ u8 dma_mode;
+
+ if (!mpc52xx_ata_build_dmatable(qc)) {
+ printk(KERN_ALERT "%s: %i, return 1?\n", __func__, __LINE__);
+ }
+
+ /* Check FIFO is OK... */
+ if(in_8(&priv->ata_regs->fifo_status) & MPC52xx_ATA_FIFOSTAT_ERROR)
+ printk("WARNING: pata_mpc52xx FIFO error detected: 0x%02x!\n", in_8(&priv->ata_regs->fifo_status));
+
+ if (read) {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_READ |
+ MPC52xx_ATA_DMAMODE_FE;
+
+ /* Setup FIFO if direction changed */
+ if (priv->mpc52xx_ata_dma_last_write != 0) {
+ priv->mpc52xx_ata_dma_last_write = 0;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+
+ /* Configure FIFO with granularity to 7 like sample code */
+ out_8(®s->fifo_control, 7);
+ out_be16(®s->fifo_alarm, 128);
+
+ /* Set FIFO Reset bit (FR) */
+ out_8(®s->dma_mode, MPC52xx_ATA_DMAMODE_FR);
+ }
+ } else {
+ dma_mode = MPC52xx_ATA_DMAMODE_IE | MPC52xx_ATA_DMAMODE_WRITE;
+
+ /* Setup FIFO if direction changed */
+ if (priv->mpc52xx_ata_dma_last_write != 1) {
+ priv->mpc52xx_ata_dma_last_write = 1;
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+
+ /* Configure FIFO with granularity to 4 like sample code */
+ out_8(®s->fifo_control, 4);
+ out_be16(®s->fifo_alarm, 128);
+ }
+ }
+
+ if (priv->timings[qc->dev->devno].using_udma)
+ dma_mode |= MPC52xx_ATA_DMAMODE_UDMA;
+
+ mpc52xx_ata_wait_tip_bit_clear(regs);
+ out_8(®s->dma_mode, dma_mode);
+
+ priv->waiting_for_dma = ATA_DMA_ACTIVE;
+
+ ata_wait_idle(ap);
+ ap->ops->sff_exec_command(ap, &qc->tf);
+}
+
+static void
+mpc52xx_bmdma_start(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ /* LocalBus lock */
+ while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) != 0)
+ ;
+
+ bcom_set_task_auto_start(priv->dmatsk->tasknum, priv->dmatsk->tasknum | 0x40);
+ bcom_enable(priv->dmatsk);
+}
+
+static void
+mpc52xx_bmdma_stop(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ bcom_disable(priv->dmatsk);
+ bcom_ata_reset_bd(priv->dmatsk);
+
+ /* LocalBus unlock*/
+ clear_bit(0, &pata_mpc52xx_ata_dma_lock);
+
+ priv->waiting_for_dma = 0;
+
+ /* Check FIFO is OK... */
+ if(in_8(&priv->ata_regs->fifo_status) & MPC52xx_ATA_FIFOSTAT_ERROR)
+ printk("WARNING: pata_mpc52xx FIFO error detected: 0x%02x!\n", in_8(&priv->ata_regs->fifo_status));
+}
+
+static u8
+mpc52xx_bmdma_status(struct ata_port *ap)
+{
+ struct mpc52xx_ata_priv *priv = ap->host->private_data;
+
+ /* Check FIFO is OK... */
+ if(in_8(&priv->ata_regs->fifo_status) & MPC52xx_ATA_FIFOSTAT_ERROR)
+ {
+ printk("WARNING: pata_mpc52xx FIFO error detected: 0x%02x!\n", in_8(&priv->ata_regs->fifo_status));
+ return priv->waiting_for_dma | ATA_DMA_ERR;
+ }
+
+ return priv->waiting_for_dma;
+}
+
+static irqreturn_t
+mpc52xx_ata_task_irq(int irq, void *vpriv)
+{
+ struct mpc52xx_ata_priv *priv = vpriv;
+ priv->waiting_for_dma |= ATA_DMA_INTR;
+
+ return IRQ_HANDLED;
+}
+
static struct scsi_host_template mpc52xx_ata_sht = {
ATA_PIO_SHT(DRV_NAME),
};
static struct ata_port_operations mpc52xx_ata_port_ops = {
.inherits = &ata_sff_port_ops,
- .sff_dev_select = mpc52xx_ata_dev_select,
- .cable_detect = ata_cable_40wire,
+
.set_piomode = mpc52xx_ata_set_piomode,
- .post_internal_cmd = ATA_OP_NULL,
+ .set_dmamode = mpc52xx_ata_set_dmamode,
+
+ .sff_exec_command = mpc52xx_sff_exec_command,
+ .sff_dev_select = mpc52xx_ata_dev_select,
+
+ .bmdma_setup = mpc52xx_bmdma_setup,
+ .bmdma_start = mpc52xx_bmdma_start,
+ .bmdma_stop = mpc52xx_bmdma_stop,
+ .bmdma_status = mpc52xx_bmdma_status,
+
+ .qc_prep = ata_noop_qc_prep,
};
static int __devinit
@@ -281,9 +720,14 @@
ap = host->ports[0];
ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->pio_mask = 0x1f; /* Up to PIO4 */
- ap->mwdma_mask = 0x00; /* No MWDMA */
- ap->udma_mask = 0x00; /* No UDMA */
+ ap->pio_mask = ATA_PIO4; /* Up to PIO4 */
+#ifdef CONFIG_PATA_MPC52xx_DMA
+ ap->mwdma_mask = 0x07; /* Up to MWDMA2 */
+ ap->udma_mask = ATA_UDMA2; /* Up to UDMA2 */
+#else
+ ap->mwdma_mask = 0x00; /* No MWDMA */
+ ap->udma_mask = 0x00; /* No UDMA */
+#endif
ap->ops = &mpc52xx_ata_port_ops;
host->private_data = priv;
@@ -333,7 +777,7 @@
int ata_irq;
struct mpc52xx_ata __iomem *ata_regs;
struct mpc52xx_ata_priv *priv;
- int rv;
+ int rv, ret, task_irq;
/* Get ipb frequency */
ipb_freq = mpc52xx_find_ipb_freq(op->node);
@@ -389,8 +833,31 @@
priv->ipb_period = 1000000000 / (ipb_freq / 1000);
priv->ata_regs = ata_regs;
+ priv->ata_regs_pa = (struct mpc52xx_ata __iomem *) res_mem.start;
priv->ata_irq = ata_irq;
priv->csel = -1;
+ priv->mpc52xx_ata_dma_last_write = -1;
+
+ if (ipb_freq/1000000 == 66) {
+ priv->mdmaspec = &mdmaspec66;
+ priv->udmaspec = &udmaspec66;
+ } else {
+ priv->mdmaspec = &mdmaspec132;
+ priv->udmaspec = &udmaspec132;
+ }
+
+ priv->dmatsk = bcom_ata_init(MAX_DMA_BUFFERS, MAX_DMA_BUFFER_SIZE);
+ pata_mpc52xx_ata_dma_task = (struct bcom_task_2 *) priv->dmatsk;
+ if (!priv->dmatsk) {
+ printk(KERN_ALERT "%s: %i\n", __func__, __LINE__);
+ rv = -ENOMEM;
+ goto err;
+ }
+
+ task_irq = bcom_get_task_irq(priv->dmatsk);
+ ret = request_irq(task_irq, &mpc52xx_ata_task_irq, IRQF_DISABLED, "ATA task", priv);
+ if (ret)
+ printk(KERN_ALERT "%s: request_irq failed with: %i\n", __func__, ret);
/* Init the hw */
rv = mpc52xx_ata_hw_init(priv);
^ permalink raw reply
* RE: Linux on Virtex board with ARCH=powerpc
From: John Linn @ 2008-06-27 13:25 UTC (permalink / raw)
To: Peter Mendham; +Cc: linuxppc-embedded
In-Reply-To: <4864DD66.5040909@computing.dundee.ac.uk>
Hi Peter, =
With regard to CONFIG_PPC_UDBG... we have a patch ready that I need to
apply to the Git tree and I'll expedite that.
With the console and UART Lite, the only thing I could think of is
making sure you have a dev entry for the UART Lite.
I'm assuming all the boot messages about the console, "enabled", look
the same as the 550 as I have seen that give hints to problems
sometimes.
Thanks,
John
-----Original Message-----
From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk] =
Sent: Friday, June 27, 2008 6:31 AM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Linux on Virtex board with ARCH=3Dpowerpc
Hi John,
Yes, with regard to the non-functional sysace, I was being an idiot: I =
had a small hw problem which now that I have fixed it, the kernel now =
reports that my drive is mounted.
I now have a new and rather bizarre problem, which maybe you or someone =
else has met before. I have a simple FPGA design with memory, a sysace =
and a uart16550 on an ML405 (I've put my hardware to one side for the =
moment). It works just fine. If I swap the uart16550 for a uartlite =
(remaking the kernel with the correct device tree) I see all the boot =
messages and the kernel seems to start OK, the root partition is mounted
but then I see nothing from /sbin/init. This is the same root fs that I
was using with the uart16550 example I just mentioned. So it's a known =
good root fs, but it doesn't appear to be able to output to /dev/console
when I have a uartlite instead of a uart16550. I have selected console =
support for uartlite. Any ideas?
Incidentally, the uart16550 solution did not work until I removed =
CONFIG_PPC_UDBG_16550 - the kernel was getting stuck in udbg_550_putc =
indefinitely.
Thanks,
-- Peter
John Linn wrote:
> Hi Peter,
>
> I think you'll get a baseline quicker this way and then you can go on
> other less known paths after that.
>
> In my experience, this message happens when there is no compact flash
in
> the slot of the board.
>
> I have the system ace device as /dev/xsa2 in my notes, but I have only
> used it much. Sorry it's not one of my primary test cases at this
point
> in time.
>
> Thanks,
> John
>
> -----Original Message-----
> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk] =
> Sent: Thursday, June 26, 2008 7:24 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on Virtex board with ARCH=3Dpowerpc
>
> Hi John,
>
> OK, I've given in and I'm using the xilinx git code now :) It now
shows
>
> some signs of life, thanks, but the sysace driver is not happy. My
root
>
> fs is on cf and I'm not using initrd. The driver loads then gets
stuck,
>
> repeatedly saying:
>
> xsysace 80030000.sysace: kicking stalled fsm; state=3D2 task=3D0 iter=3D1=
dc=3D0
>
> I notice from the driver source that state 2 is the driver attempting
to
>
> acquire the mpu lock. I have tried the standard xilinx sysace
selftest =
> code which just acquires and frees the lock (which is fine) so the =
> hardware should be OK (I hope). I have the sysace hooked up to an irq
> (the only one), I have no idea whether the dts is correct but it seems
> to compare favourably with the ml405 one; mine says (the important
> bits):
>
> intc: interrupt-controller@80010000 {
> #interrupt-cells =3D <2>;
> compatible =3D "xlnx,xps-intc-1.00.a";
> interrupt-controller ;
> reg =3D < 80010000 10000 >;
> xlnx,num-intr-inputs =3D <1>;
> } ;
> sysace: sysace@80030000 {
> compatible =3D "xlnx,xps-sysace-1.00.a";
> interrupt-parent =3D <&intc>;
> interrupts =3D < 0 2 >;
> reg =3D < 80030000 10000 >;
> xlnx,family =3D "virtex4";
> xlnx,mem-width =3D <10>;
> } ;
>
> Do you have any ideas?
>
> Thanks,
> -- Peter
>
> John Linn wrote:
> =
>> Hi Peter,
>>
>> To some extent I think you're trying to re-invent the wheel here, but
>> =
> I
> =
>> understand why.
>>
>> Ideally, you would be able to pull from the mainline kernel to build
>> this, but Xilinx hasn't got our code into the mainline. We are
>> =
> working
> =
>> on it more proactively now.
>>
>> So, in the meantime, it would be easier for you to pull from the
>> =
> Xilinx
> =
>> git tree as we have solved the problems you are solving I believe.
>>
>> Git://git.xilinx.com/linux-2.6-xlnx or http://git.xilinx.com/... =
>>
>> We supply the device tree files and kernel configurations for the
>> =
> ML405
> =
>> and ML507 boards to help get started.
>>
>> Thanks and sorry for the inconvenience,
>> John
>>
>> -----Original Message-----
>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk] =
>> Sent: Wednesday, June 25, 2008 10:18 AM
>> To: John Linn
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: Linux on Virtex board with ARCH=3Dpowerpc
>>
>> OK, this is all new to me, so please bear with me if I've made a
major
>> =
>
> =
>> mistake. I ran the kernel until it didn't give me anymore output and
>> then told xmd to "stop", mrd from any location gave me exactly the
>> =
> same =
> =
>> 32-bit word of garbage. I then reset the processor and mrd would
give
>> =
>
> =
>> me what looked like reasonable values. I found the __log_buf symbol
>> =
> in =
> =
>> the System.map file (0xc024a108) and tried mrd on what I assume is
the
>> =
>
> =
>> corresponding physical address of 0x0024a108. I get the following:
>>
>> <6>Using Xilinx Virtex machine description
>> <5>Linux version 2.6.26-rc6 (peter@eris) (gcc version 4.2.4) #9
>> =
> PREEMPT =
> =
>> Wed Jun 25 16:27:33 BST 2008
>> <7>Entering add_active_range(0, 0, 131072) 0 entries of 256 used
>> <7>Top of RAM: 0x20000000, Total RAM: 0x20000000
>> <7>Memory hole size: 0MB
>> <4>Zone PFN ranges:
>> <4> DMA 0 -> 131072
>> <4> Normal 131072 -> 131072
>> <4>Movable zone start PFN for each node
>> <4>early_node_map[1] active PFN ranges
>> <4> 0: 0 -> 131072
>> <7>On node 0 totalpages: 131072
>> <7> DMA zone: 1024 pages used for memmap
>> <7> DMA zone: 0 pages reserved
>> <7> DMA zone: 130048 pages, LIFO batch:31
>> <7> Normal zone: 0 pages used for memmap
>> <7> Movable zone: 0 pages used for memmap
>> <4>Built 1 zonelists in Zone order, mobility grouping on. Total
>> =
> pages: =
> =
>> 130048
>> <5>Kernel command line: console=3DttyUL0 root=3D/dev/xsa2 rw
>> <6>Xilinx intc at 0xFDFFF000C025CFFC mapped to 0x0000025d
>> <4>PID hash table entries: 2048 (order: 11, 8192 bytes)
>>
>> xmd tells me that the processor stopped at 0xc000fe50, and subsequent
>> "con" and "stop" sequences do no move this on (it reports the same
>> =
> each =
> =
>> time). Below is a choice excerpt of my System.map:
>>
>> c000fdc4 t src_error
>> c000fddc t dst_error
>> c000fdf4 T __div64_32
>> c000fe94 T cacheable_memzero
>> c000ff38 T memset
>>
>> So I guess that means it's in __div64_32?
>>
>> Any ideas?
>>
>> Thanks in advance,
>> -- Peter
>>
>> John Linn wrote:
>> =
>> =
>>> Sounds like the bootstrap loader has loaded the kernel and passed
off
>>> execution to it, but there's no console working on the kernel.
>>>
>>> You can confirm that since you have a probe as you can dump the
>>> __log_buf by getting the address of it using objdump on the elf
>>> =
> image.
> =
>>> It's a pain to convert to readable form, but can help to see that
>>> =
>>> =
>> things
>> =
>> =
>>> are indeed running. Stop the processor, then do the memory read
>>> =
>>> =
>> command,
>> =
>> =
>>> mrd, in xmd. =
>>>
>>> For the console to work with UART Lite, CONFIG_OF must be on in the
>>> kernel configuration, I would check that.
>>>
>>> The file, arch/powerpc/boot/virtex.c, has the startup code for the
>>> virtex specific processing. It checks to make sure there is
>>> =
>>> =
>> compatible
>> =
>> =
>>> hardware based on the device tree. If your device tree doesn't
match
>>> that hardware you could have a problem. I have not found the
powerup
>>> =
>>> =
>> of
>> =
>> =
>>> the kernel to be very informative if the device tree is wrong.
>>>
>>> I pasted in our ML405 device tree below to allow you to compare to
>>> =
> it.
> =
>>> Hope that helps,
>>> John
>>>
>>>
>>>
>>> /*
>>> * (C) Copyright 2007 Michal Simek
>>> *
>>> * Michal SIMEK <monstr@monstr.eu>
>>> *
>>> * This program is free software; you can redistribute it and/or
>>> * modify it under the terms of the GNU General Public License as
>>> * published by the Free Software Foundation; either version 2 of
>>> * the License, or (at your option) any later version.
>>> *
>>>
>>> * This program is distributed in the hope that it will be useful,
>>> * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> * GNU General Public License for more details.
>>> *
>>> * You should have received a copy of the GNU General Public License
>>> * along with this program; if not, write to the Free Software
>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>> * MA 02111-1307 USA
>>> *
>>> * CAUTION: This file is automatically generated by libgen.
>>> * Version: Xilinx EDK 10.1.1 EDK_K_SP1.1
>>> */
>>>
>>> / {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <1>;
>>> compatible =3D "xlnx,virtex";
>>> model =3D "testing";
>>> DDR_SDRAM: memory@0 {
>>> device_type =3D "memory";
>>> reg =3D < 0 8000000 >;
>>> } ;
>>> chosen {
>>> bootargs =3D "console=3DttyS0 ip=3Don root=3D/dev/ram";
>>> linux,stdout-path =3D "/plb@0/serial@83e00000";
>>> } ;
>>> cpus {
>>> #address-cells =3D <1>;
>>> #cpus =3D <1>;
>>>
>>> #size-cells =3D <0>;
>>> ppc405_0: cpu@0 {
>>> clock-frequency =3D <11e1a300>;
>>> compatible =3D "PowerPC,405", "ibm,ppc405";
>>>
>>> d-cache-line-size =3D <20>;
>>> d-cache-size =3D <4000>;
>>> device_type =3D "cpu";
>>> i-cache-line-size =3D <20>;
>>>
>>> i-cache-size =3D <4000>;
>>> model =3D "PowerPC,405";
>>> reg =3D <0>;
>>> timebase-frequency =3D <11e1a300>;
>>> xlnx,apu-control =3D <de00>;
>>> xlnx,apu-udi-1 =3D <a18983>;
>>> xlnx,apu-udi-2 =3D <a38983>;
>>> xlnx,apu-udi-3 =3D <a589c3>;
>>> xlnx,apu-udi-4 =3D <a789c3>;
>>> xlnx,apu-udi-5 =3D <a98c03>;
>>> xlnx,apu-udi-6 =3D <ab8c03>;
>>> xlnx,apu-udi-7 =3D <ad8c43>;
>>> xlnx,apu-udi-8 =3D <af8c43>;
>>> xlnx,deterministic-mult =3D <0>;
>>> xlnx,disable-operand-forwarding =3D <1>;
>>> xlnx,fastest-plb-clock =3D "DPLB0";
>>> xlnx,generate-plb-timespecs =3D <1>;
>>> xlnx,mmu-enable =3D <1>;
>>> xlnx,pvr-high =3D <0>;
>>> xlnx,pvr-low =3D <0>;
>>> } ;
>>> } ;
>>> plb: plb@0 {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <1>;
>>> compatible =3D "xlnx,plb-v46-1.02.a";
>>> ranges ;
>>> IIC_EEPROM: i2c@81600000 {
>>> compatible =3D "xlnx,xps-iic-2.00.a";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 4 2 >;
>>> reg =3D < 81600000 10000 >;
>>> xlnx,clk-freq =3D <5f5e100>;
>>> xlnx,family =3D "virtex4";
>>> xlnx,gpo-width =3D <1>;
>>> xlnx,iic-freq =3D <186a0>;
>>> xlnx,scl-inertial-delay =3D <0>;
>>> xlnx,sda-inertial-delay =3D <0>;
>>> xlnx,ten-bit-adr =3D <0>;
>>> } ;
>>> LEDs_4Bit: gpio@81400000 {
>>> compatible =3D "xlnx,xps-gpio-1.00.a";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 5 2 >;
>>> reg =3D < 81400000 10000 >;
>>> xlnx,all-inputs =3D <0>;
>>> xlnx,all-inputs-2 =3D <0>;
>>> xlnx,dout-default =3D <0>;
>>> xlnx,dout-default-2 =3D <0>;
>>> xlnx,family =3D "virtex4";
>>> xlnx,gpio-width =3D <4>;
>>> xlnx,interrupt-present =3D <1>;
>>> xlnx,is-bidir =3D <1>;
>>> xlnx,is-bidir-2 =3D <1>;
>>> xlnx,is-dual =3D <0>;
>>> xlnx,tri-default =3D <ffffffff>;
>>> xlnx,tri-default-2 =3D <ffffffff>;
>>> } ;
>>> RS232_Uart: serial@83e00000 {
>>> compatible =3D "ns16550";
>>> device_type =3D "serial";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 6 2 >;
>>> reg =3D < 83e00000 10000 >;
>>> reg-offset =3D <3>;
>>> reg-shift =3D <2>; =
>>> clock-frequency =3D <05f5e100>;
>>> xlnx,family =3D "virtex4";
>>> xlnx,has-external-rclk =3D <0>;
>>> xlnx,has-external-xin =3D <0>;
>>> xlnx,is-a-16550 =3D <1>;
>>> } ;
>>> SysACE_CompactFlash: sysace@83600000 {
>>> compatible =3D "xlnx,xps-sysace-1.00.a";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 3 2 >;
>>> reg =3D < 83600000 10000 >;
>>> xlnx,family =3D "virtex4";
>>> xlnx,mem-width =3D <10>;
>>> } ;
>>> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <1>;
>>> compatible =3D "xlnx,compound";
>>> ethernet@81c00000 {
>>> compatible =3D "xlnx,xps-ll-temac-1.01.a";
>>> device_type =3D "network";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 2 2 >;
>>> llink-connected =3D <&PIM2>;
>>> local-mac-address =3D [ 02 00 00 00 00 01
>>> ];
>>> reg =3D < 81c00000 40 >;
>>> xlnx,bus2core-clk-ratio =3D <1>;
>>> xlnx,phy-type =3D <1>;
>>> xlnx,phyaddr =3D <1>;
>>> xlnx,rxcsum =3D <0>;
>>> xlnx,rxfifo =3D <1000>;
>>> xlnx,temac-type =3D <1>;
>>> xlnx,txcsum =3D <0>;
>>> xlnx,txfifo =3D <1000>;
>>> } ;
>>> } ;
>>> mpmc@0 {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <1>;
>>> compatible =3D "xlnx,mpmc-4.00.a";
>>> PIM2: sdma@84600100 {
>>> compatible =3D "xlnx,ll-dma-1.00.a";
>>> interrupt-parent =3D <&xps_intc_0>;
>>> interrupts =3D < 1 2 0 2 >;
>>> reg =3D < 84600100 80 >;
>>> } ;
>>> } ;
>>> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>>> compatible =3D "xlnx,xps-bram-if-cntlr-1.00.a";
>>> reg =3D < ffffe000 2000 >;
>>> xlnx,family =3D "virtex4";
>>> } ;
>>> xps_intc_0: interrupt-controller@81800000 {
>>> #interrupt-cells =3D <2>;
>>> compatible =3D "xlnx,xps-intc-1.00.a";
>>> interrupt-controller ;
>>> reg =3D < 81800000 10000 >;
>>> xlnx,num-intr-inputs =3D <7>;
>>> } ;
>>> } ;
>>> ppc405_0_dplb1: plb@1 {
>>> #address-cells =3D <1>;
>>> #size-cells =3D <1>;
>>> compatible =3D "xlnx,plb-v46-1.02.a";
>>> ranges ;
>>> } ;
>>> } ;
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk] =
>>> Sent: Tuesday, June 24, 2008 1:21 PM
>>> To: John Linn
>>> Cc: linuxppc-embedded@ozlabs.org
>>> Subject: Re: Linux on Virtex board with ARCH=3Dpowerpc
>>>
>>> Hi John,
>>>
>>> Thanks for your reply, that's really helpful. I'm actually using
the
>>> =
>
> =
>>> mainline kernel, rather than the one from the xilinx git tree, but
>>> =
>>> =
>> your =
>> =
>> =
>>> information has really moved me on. My first problem was that the =
>>> Xilinx utility (from the git tree) for device tree dts generation
>>> =
>>> =
>> didn't
>> =
>> =
>>> insert a "linux,stdout-path" node under "chosen". I spotted that
the
>>> =
>
> =
>>> ml403 example had this, so after adding it I got early console =
>>> messages. Everything now grinds to a halt after I get the message
>>> =
>>> =
>> "flat
>> =
>> =
>>> tree at 0x40ad60" which is just before it calls the kernel, so I
>>> =
>>> =
>> assume =
>> =
>> =
>>> it's that call that is killing it. I have "console=3DttyUL0" for my =
>>> uartlite, so I should be getting messages, shouldn't I? Do you know
>>> where the next execution point is? Maybe I could find out where
it's
>>> =
>
> =
>>> getting stuck.
>>>
>>> I haven't managed to generate an ACE file, I'm just loading the
>>> =
> kernel
> =
>>> =
>>> =
>> =
>> =
>>> image from xmd ATM, genace won't play ball for me, it complains
about
>>> =
>
> =
>>> -board user not being valid, it won't even run on the examples
copied
>>> =
>
> =
>>> directly from the user manual. Anyway, I think genace is a bit OT,
>>> =
>>> =
>> and =
>> =
>> =
>>> I can manage with xmd for now.
>>>
>>> Thanks,
>>> -- Peter
>>>
>>> John Linn wrote:
>>> =
>>> =
>>> =
>>>> Hi Peter,
>>>>
>>>> I'm not up on what can be done with the simple image you refer to
in
>>>> =
>>>>
>>>> =
>>> 1.
>>> =
>>> =
>>> =
>>>> I'm sure I should be, but there's a lot to learn.
>>>>
>>>> With regards to 2, the elf image, zImage (without the elf
>>>> =
> extension),
> =
>>>> =
>>>> =
>>>> =
>>> is
>>> =
>>> =
>>> =
>>>> located in arch/powerpc/boot.
>>>>
>>>> You can make a SystemACE file from that elf image just as you did
in
>>>> arch/ppc. We have a default device tree file, ml405.dts, in the
>>>> arch/powerpc/boot/dts directory for our ml405 board. The kernel
>>>> configuration has a config, DEVICE_TREE, that specifies the name of
>>>> =
>>>> =
>>>> =
>>> the
>>> =
>>> =
>>> =
>>>> device tree file. I normally compile the device tree into the
kernel
>>>> which is the default build, make ARCH=3Dpowerpc zImage. That image
>>>> =
> does
> =
>>>> not require a boot loader.
>>>>
>>>> I inserted the text below from a document that I have about
building
>>>> =
>>>> =
>>>> =
>>> the
>>> =
>>> =
>>> =
>>>> arch/ppc and arch/powerpc kernels.
>>>>
>>>> Hope that helps,
>>>> John
>>>>
>>>>
>>>> Notation
>>>>
>>>> The phrase "<ppc or powerpc>" is used throughput the text and means
>>>> =
>>>> =
>>>> =
>>> that
>>> =
>>> =
>>> =
>>>> one or the other, "ppc" or "powerpc" is to be typed depending on
the
>>>> architecture you are building.
>>>>
>>>> Commands that are used in a bash shell are preceded by ">".
>>>>
>>>> Getting Ready To Build the Kernel
>>>>
>>>> This assumes you installed the ELDK tools and assumes you'll be
>>>> =
> using
> =
>>>> =
>>>> =
>>>> =
>>> a
>>> =
>>> =
>>> =
>>>> bash shell.
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> bash
>>>>> export CROSS_COMPILE=3Dppc_4xx-
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> Setting Up the Kernel Tree
>>>>
>>>> If you have previously built this kernel for another architecture,
>>>> =
>>>> =
>> ppc
>> =
>> =
>>>> or powerpc, then the tree needs to be setup correctly for the new
>>>> architecture. Assuming you have not previously built it, this does
>>>> =
>>>> =
>>>> =
>>> not
>>> =
>>> =
>>> =
>>>> need to be done.
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> make ARCH=3D<ppc or powerpc> mrproper
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> Configuring the Kernel
>>>>
>>>> The kernel should be configured to run on the ML405 or ML507 board
>>>> =
>>>> =
>>>> =
>>> from
>>> =
>>> =
>>> =
>>>> Xilinx. =
>>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> make ARCH=3D<ppc or powerpc> ml405_defconfig
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> or =
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> make ARCH=3D<ppc or powerpc> ml507_defconfig
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> Building the Kernel
>>>>
>>>> The following command will build the Linux kernel assuming you are
>>>> =
> in
> =
>>>> the root directory of the kernel. The root directory of the kernel
>>>> =
>>>> =
>>>> =
>>> from
>>> =
>>> =
>>> =
>>>> the Xilinx Git tree is linux-2.6-xlnx. An elf file, zImage.elf, is
>>>> created in the arch/ppc/boot/images directory for ppc architecture.
>>>> =
>>>> =
>> An
>> =
>> =
>>>> elf file, zImage, is created in the the arch/powerpc/boot directory
>>>> =
>>>> =
>>>> =
>>> for
>>> =
>>> =
>>> =
>>>> the powerpc architecture.
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> make ARCH=3D<ppc or powerpc> zImage
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> =
>>>> Building the Kernel With Ramdisk
>>>>
>>>> A ram disk image, a file named *.gz, must be placed into the
>>>> arch/ppc/boot/images or arch/powerpc/boot directory, depending on
>>>> =
> the
> =
>>>> architecture, prior to building the kernel.
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> make ARCH=3D<ppc or powerpc> zImage.initrd
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> An elf file, zImage.initrd.elf, is created in arch/ppc/boot/images
>>>> directory for the ppc architecture. An elf file file,
zImage.initrd,
>>>> =
>>>> =
>>>> =
>>> is
>>> =
>>> =
>>> =
>>>> created in arch/powerpc/boot directory for the powerpc
architecture.
>>>>
>>>> Generating An Ace File
>>>>
>>>> The elf file generated for the kernel and the bit stream can be
>>>> =
>>>> =
>>>> =
>>> combined
>>> =
>>> =
>>> =
>>>> to create an ACE file for compact flash. The following assumes a
>>>> =
>>>> =
>> bash
>> =
>>
>>>> shell where XMD is accessible and a xilinx probe attached to the
>>>> =
>>>> =
>> board
>> =
>> =
>>>> for which you are generating an ace file.
>>>>
>>>> =
>>>> =
>>>> =
>>>> =
>>>>> xmd -tcl genace.tcl -jprog -target ppc_hw -hw <bit file name> -elf
>>>>> =
>>>>> =
>>>>> =
>>> <elf
>>> =
>>> =
>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>> file name> -board <ml405 or ml507> -ace <desired ace file name>
>>>>
>>>> -----Original Message-----
>>>> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
>>>> [mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org]
>>>> =
> On
> =
>>>> Behalf Of Peter Mendham
>>>> Sent: Tuesday, June 24, 2008 3:02 AM
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: Linux on Virtex board with ARCH=3Dpowerpc
>>>>
>>>> Dear all,
>>>>
>>>> I'm trying to boot a 2.6.26-rc6 kernel on a custom Virtex 4 board.
>>>> =
> I
> =
>>>> =
>>>> =
>> =
>> =
>>>> have used the Xilinx utility to generate a device tree and now want
>>>> =
>>>> =
>> to
>> =
>> =
>>>> =
>>>> =
>>>> =
>>> =
>>> =
>>> =
>>>> generate an image for throwing onto CF for use with a SystemACE
>>>> =
> (just
> =
>>>> =
>>>> =
>> =
>> =
>>>> like on the the ML3/4xx boards). I don't want to use a bootloader
>>>> =
> (I
> =
>>>> =
>>>> =
>> =
>> =
>>>> don't really need one). I saw something on this list about
>>>> =
>>>> =
>>>> =
>>> simpleImage,
>>> =
>>> =
>>> =
>>>> "simple" sounded good to me so I thought I'd try that (or did I =
>>>> misinterpret what this is for?). I also don't want the image to be
>>>> =
>>>> =
>>>> =
>>> too =
>>> =
>>> =
>>> =
>>>> big, I always used to use a zImage under ARCH=3Dppc. So, two
>>>> =
> questions,
> =
>>>> =
>>>> =
>> =
>> =
>>>> which hopefully are easy ones:
>>>> 1. I did what Grant said in a post to this list about simpleImage,
>>>> =
>>>> =
>> and
>> =
>> =
>>>> =
>>>> =
>>>> =
>>> =
>>> =
>>> =
>>>> dumped my dts into arch/powerpc/boot/dts and I called it system.dts
>>>> =
>>>> =
>>>> =
>>> (for
>>> =
>>> =
>>> =
>>>> now). I then tried to do make simpleImage.system which ran right =
>>>> through to final link then moaned about a missing
simpleboot-system.
>>>> =
>>>> =
>> =
>> =
>>>> Where is this supposed to come from? What am I doing wrong? I
>>>> =
>>>> =
>>>> =
>>> naively =
>>> =
>>> =
>>> =
>>>> tried copying simpleboot.o to simpleboot-system.o and the error
went
>>>> =
>
> =
>>>> away. Hmm.
>>>> 2. I need an ELF to give to my SystemACE file generator. This used
>>>> =
>>>> =
>> to
>> =
>> =
>>>> =
>>>> =
>>>> =
>>> =
>>> =
>>> =
>>>> pop up in arch/ppc/boot/images and be called zImage.elf, which made
>>>> sense to me. What's the deal now with powerpc? What should I be
>>>> =
>>>> =
>>>> =
>>> using?
>>> =
>>> =
>>> =
>>>> Finally, can anyone give me a heads-up on any gotchas with what I'm
>>>> trying to do. As you can tell, I don't entirely know what I'm
>>>> =
> doing,
> =
>>>> =
>>>> =
>>>> =
>>> so
>>> =
>>> =
>>> =
>>>> any pointers would be gratefully received.
>>>>
>>>> Thanks,
>>>> -- Peter
>>>>
>>>>
>>>> The University of Dundee is a Scottish Registered Charity, No.
>>>> =
>>>> =
>>>> =
>>> SC015096.
>>> =
>>> =
>>> =
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>> This email and any attachments are intended for the sole use of the
>>>> =
>>>> =
>>>> =
>>> named recipient(s) and contain(s) confidential information that may
>>> =
> be
> =
>>> proprietary, privileged or copyrighted under applicable law. If you
>>> =
>>> =
>> are
>> =
>> =
>>> not the intended recipient, do not read, copy, or forward this email
>>> message or any attachments. Delete this email message and any
>>> attachments immediately.
>>> =
>>> =
>>> =
>>>> =
>>>> =
>>>> =
>>>> =
>>> The University of Dundee is a Scottish Registered Charity, No.
>>> =
>>> =
>> SC015096.
>> =
>> =
>>> This email and any attachments are intended for the sole use of the
>>> =
>>> =
>> named recipient(s) and contain(s) confidential information that may
be
>> proprietary, privileged or copyrighted under applicable law. If you
>> =
> are
> =
>> not the intended recipient, do not read, copy, or forward this email
>> message or any attachments. Delete this email message and any
>> attachments immediately.
>> =
>> =
>>> =
>>> =
>>> =
>> The University of Dundee is a Scottish Registered Charity, No.
>> =
> SC015096.
> =
>>
>>
>> This email and any attachments are intended for the sole use of the
>> =
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you
are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any
> attachments immediately.
> =
>> =
>> =
>
>
> The University of Dundee is a Scottish Registered Charity, No.
SC015096.
>
>
>
>
> This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you are
not the intended recipient, do not read, copy, or forward this email
message or any attachments. Delete this email message and any
attachments immediately.
>
>
> =
The University of Dundee is a Scottish Registered Charity, No. SC015096.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: Linux on Virtex board with ARCH=powerpc
From: Peter Mendham @ 2008-06-27 12:30 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-embedded
In-Reply-To: <20080626132905.2779E1F007F@mail24-dub.bigfish.com>
Hi John,
Yes, with regard to the non-functional sysace, I was being an idiot: I
had a small hw problem which now that I have fixed it, the kernel now
reports that my drive is mounted.
I now have a new and rather bizarre problem, which maybe you or someone
else has met before. I have a simple FPGA design with memory, a sysace
and a uart16550 on an ML405 (I've put my hardware to one side for the
moment). It works just fine. If I swap the uart16550 for a uartlite
(remaking the kernel with the correct device tree) I see all the boot
messages and the kernel seems to start OK, the root partition is mounted
but then I see nothing from /sbin/init. This is the same root fs that I
was using with the uart16550 example I just mentioned. So it's a known
good root fs, but it doesn't appear to be able to output to /dev/console
when I have a uartlite instead of a uart16550. I have selected console
support for uartlite. Any ideas?
Incidentally, the uart16550 solution did not work until I removed
CONFIG_PPC_UDBG_16550 - the kernel was getting stuck in udbg_550_putc
indefinitely.
Thanks,
-- Peter
John Linn wrote:
> Hi Peter,
>
> I think you'll get a baseline quicker this way and then you can go on
> other less known paths after that.
>
> In my experience, this message happens when there is no compact flash in
> the slot of the board.
>
> I have the system ace device as /dev/xsa2 in my notes, but I have only
> used it much. Sorry it's not one of my primary test cases at this point
> in time.
>
> Thanks,
> John
>
> -----Original Message-----
> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
> Sent: Thursday, June 26, 2008 7:24 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on Virtex board with ARCH=powerpc
>
> Hi John,
>
> OK, I've given in and I'm using the xilinx git code now :) It now shows
>
> some signs of life, thanks, but the sysace driver is not happy. My root
>
> fs is on cf and I'm not using initrd. The driver loads then gets stuck,
>
> repeatedly saying:
>
> xsysace 80030000.sysace: kicking stalled fsm; state=2 task=0 iter=1 dc=0
>
> I notice from the driver source that state 2 is the driver attempting to
>
> acquire the mpu lock. I have tried the standard xilinx sysace selftest
> code which just acquires and frees the lock (which is fine) so the
> hardware should be OK (I hope). I have the sysace hooked up to an irq
> (the only one), I have no idea whether the dts is correct but it seems
> to compare favourably with the ml405 one; mine says (the important
> bits):
>
> intc: interrupt-controller@80010000 {
> #interrupt-cells = <2>;
> compatible = "xlnx,xps-intc-1.00.a";
> interrupt-controller ;
> reg = < 80010000 10000 >;
> xlnx,num-intr-inputs = <1>;
> } ;
> sysace: sysace@80030000 {
> compatible = "xlnx,xps-sysace-1.00.a";
> interrupt-parent = <&intc>;
> interrupts = < 0 2 >;
> reg = < 80030000 10000 >;
> xlnx,family = "virtex4";
> xlnx,mem-width = <10>;
> } ;
>
> Do you have any ideas?
>
> Thanks,
> -- Peter
>
> John Linn wrote:
>
>> Hi Peter,
>>
>> To some extent I think you're trying to re-invent the wheel here, but
>>
> I
>
>> understand why.
>>
>> Ideally, you would be able to pull from the mainline kernel to build
>> this, but Xilinx hasn't got our code into the mainline. We are
>>
> working
>
>> on it more proactively now.
>>
>> So, in the meantime, it would be easier for you to pull from the
>>
> Xilinx
>
>> git tree as we have solved the problems you are solving I believe.
>>
>> Git://git.xilinx.com/linux-2.6-xlnx or http://git.xilinx.com/...
>>
>> We supply the device tree files and kernel configurations for the
>>
> ML405
>
>> and ML507 boards to help get started.
>>
>> Thanks and sorry for the inconvenience,
>> John
>>
>> -----Original Message-----
>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
>> Sent: Wednesday, June 25, 2008 10:18 AM
>> To: John Linn
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: Linux on Virtex board with ARCH=powerpc
>>
>> OK, this is all new to me, so please bear with me if I've made a major
>>
>
>
>> mistake. I ran the kernel until it didn't give me anymore output and
>> then told xmd to "stop", mrd from any location gave me exactly the
>>
> same
>
>> 32-bit word of garbage. I then reset the processor and mrd would give
>>
>
>
>> me what looked like reasonable values. I found the __log_buf symbol
>>
> in
>
>> the System.map file (0xc024a108) and tried mrd on what I assume is the
>>
>
>
>> corresponding physical address of 0x0024a108. I get the following:
>>
>> <6>Using Xilinx Virtex machine description
>> <5>Linux version 2.6.26-rc6 (peter@eris) (gcc version 4.2.4) #9
>>
> PREEMPT
>
>> Wed Jun 25 16:27:33 BST 2008
>> <7>Entering add_active_range(0, 0, 131072) 0 entries of 256 used
>> <7>Top of RAM: 0x20000000, Total RAM: 0x20000000
>> <7>Memory hole size: 0MB
>> <4>Zone PFN ranges:
>> <4> DMA 0 -> 131072
>> <4> Normal 131072 -> 131072
>> <4>Movable zone start PFN for each node
>> <4>early_node_map[1] active PFN ranges
>> <4> 0: 0 -> 131072
>> <7>On node 0 totalpages: 131072
>> <7> DMA zone: 1024 pages used for memmap
>> <7> DMA zone: 0 pages reserved
>> <7> DMA zone: 130048 pages, LIFO batch:31
>> <7> Normal zone: 0 pages used for memmap
>> <7> Movable zone: 0 pages used for memmap
>> <4>Built 1 zonelists in Zone order, mobility grouping on. Total
>>
> pages:
>
>> 130048
>> <5>Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
>> <6>Xilinx intc at 0xFDFFF000C025CFFC mapped to 0x0000025d
>> <4>PID hash table entries: 2048 (order: 11, 8192 bytes)
>>
>> xmd tells me that the processor stopped at 0xc000fe50, and subsequent
>> "con" and "stop" sequences do no move this on (it reports the same
>>
> each
>
>> time). Below is a choice excerpt of my System.map:
>>
>> c000fdc4 t src_error
>> c000fddc t dst_error
>> c000fdf4 T __div64_32
>> c000fe94 T cacheable_memzero
>> c000ff38 T memset
>>
>> So I guess that means it's in __div64_32?
>>
>> Any ideas?
>>
>> Thanks in advance,
>> -- Peter
>>
>> John Linn wrote:
>>
>>
>>> Sounds like the bootstrap loader has loaded the kernel and passed off
>>> execution to it, but there's no console working on the kernel.
>>>
>>> You can confirm that since you have a probe as you can dump the
>>> __log_buf by getting the address of it using objdump on the elf
>>>
> image.
>
>>> It's a pain to convert to readable form, but can help to see that
>>>
>>>
>> things
>>
>>
>>> are indeed running. Stop the processor, then do the memory read
>>>
>>>
>> command,
>>
>>
>>> mrd, in xmd.
>>>
>>> For the console to work with UART Lite, CONFIG_OF must be on in the
>>> kernel configuration, I would check that.
>>>
>>> The file, arch/powerpc/boot/virtex.c, has the startup code for the
>>> virtex specific processing. It checks to make sure there is
>>>
>>>
>> compatible
>>
>>
>>> hardware based on the device tree. If your device tree doesn't match
>>> that hardware you could have a problem. I have not found the powerup
>>>
>>>
>> of
>>
>>
>>> the kernel to be very informative if the device tree is wrong.
>>>
>>> I pasted in our ML405 device tree below to allow you to compare to
>>>
> it.
>
>>> Hope that helps,
>>> John
>>>
>>>
>>>
>>> /*
>>> * (C) Copyright 2007 Michal Simek
>>> *
>>> * Michal SIMEK <monstr@monstr.eu>
>>> *
>>> * This program is free software; you can redistribute it and/or
>>> * modify it under the terms of the GNU General Public License as
>>> * published by the Free Software Foundation; either version 2 of
>>> * the License, or (at your option) any later version.
>>> *
>>>
>>> * This program is distributed in the hope that it will be useful,
>>> * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> * GNU General Public License for more details.
>>> *
>>> * You should have received a copy of the GNU General Public License
>>> * along with this program; if not, write to the Free Software
>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>> * MA 02111-1307 USA
>>> *
>>> * CAUTION: This file is automatically generated by libgen.
>>> * Version: Xilinx EDK 10.1.1 EDK_K_SP1.1
>>> */
>>>
>>> / {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "xlnx,virtex";
>>> model = "testing";
>>> DDR_SDRAM: memory@0 {
>>> device_type = "memory";
>>> reg = < 0 8000000 >;
>>> } ;
>>> chosen {
>>> bootargs = "console=ttyS0 ip=on root=/dev/ram";
>>> linux,stdout-path = "/plb@0/serial@83e00000";
>>> } ;
>>> cpus {
>>> #address-cells = <1>;
>>> #cpus = <1>;
>>>
>>> #size-cells = <0>;
>>> ppc405_0: cpu@0 {
>>> clock-frequency = <11e1a300>;
>>> compatible = "PowerPC,405", "ibm,ppc405";
>>>
>>> d-cache-line-size = <20>;
>>> d-cache-size = <4000>;
>>> device_type = "cpu";
>>> i-cache-line-size = <20>;
>>>
>>> i-cache-size = <4000>;
>>> model = "PowerPC,405";
>>> reg = <0>;
>>> timebase-frequency = <11e1a300>;
>>> xlnx,apu-control = <de00>;
>>> xlnx,apu-udi-1 = <a18983>;
>>> xlnx,apu-udi-2 = <a38983>;
>>> xlnx,apu-udi-3 = <a589c3>;
>>> xlnx,apu-udi-4 = <a789c3>;
>>> xlnx,apu-udi-5 = <a98c03>;
>>> xlnx,apu-udi-6 = <ab8c03>;
>>> xlnx,apu-udi-7 = <ad8c43>;
>>> xlnx,apu-udi-8 = <af8c43>;
>>> xlnx,deterministic-mult = <0>;
>>> xlnx,disable-operand-forwarding = <1>;
>>> xlnx,fastest-plb-clock = "DPLB0";
>>> xlnx,generate-plb-timespecs = <1>;
>>> xlnx,mmu-enable = <1>;
>>> xlnx,pvr-high = <0>;
>>> xlnx,pvr-low = <0>;
>>> } ;
>>> } ;
>>> plb: plb@0 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "xlnx,plb-v46-1.02.a";
>>> ranges ;
>>> IIC_EEPROM: i2c@81600000 {
>>> compatible = "xlnx,xps-iic-2.00.a";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 4 2 >;
>>> reg = < 81600000 10000 >;
>>> xlnx,clk-freq = <5f5e100>;
>>> xlnx,family = "virtex4";
>>> xlnx,gpo-width = <1>;
>>> xlnx,iic-freq = <186a0>;
>>> xlnx,scl-inertial-delay = <0>;
>>> xlnx,sda-inertial-delay = <0>;
>>> xlnx,ten-bit-adr = <0>;
>>> } ;
>>> LEDs_4Bit: gpio@81400000 {
>>> compatible = "xlnx,xps-gpio-1.00.a";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 5 2 >;
>>> reg = < 81400000 10000 >;
>>> xlnx,all-inputs = <0>;
>>> xlnx,all-inputs-2 = <0>;
>>> xlnx,dout-default = <0>;
>>> xlnx,dout-default-2 = <0>;
>>> xlnx,family = "virtex4";
>>> xlnx,gpio-width = <4>;
>>> xlnx,interrupt-present = <1>;
>>> xlnx,is-bidir = <1>;
>>> xlnx,is-bidir-2 = <1>;
>>> xlnx,is-dual = <0>;
>>> xlnx,tri-default = <ffffffff>;
>>> xlnx,tri-default-2 = <ffffffff>;
>>> } ;
>>> RS232_Uart: serial@83e00000 {
>>> compatible = "ns16550";
>>> device_type = "serial";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 6 2 >;
>>> reg = < 83e00000 10000 >;
>>> reg-offset = <3>;
>>> reg-shift = <2>;
>>> clock-frequency = <05f5e100>;
>>> xlnx,family = "virtex4";
>>> xlnx,has-external-rclk = <0>;
>>> xlnx,has-external-xin = <0>;
>>> xlnx,is-a-16550 = <1>;
>>> } ;
>>> SysACE_CompactFlash: sysace@83600000 {
>>> compatible = "xlnx,xps-sysace-1.00.a";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 3 2 >;
>>> reg = < 83600000 10000 >;
>>> xlnx,family = "virtex4";
>>> xlnx,mem-width = <10>;
>>> } ;
>>> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "xlnx,compound";
>>> ethernet@81c00000 {
>>> compatible = "xlnx,xps-ll-temac-1.01.a";
>>> device_type = "network";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 2 2 >;
>>> llink-connected = <&PIM2>;
>>> local-mac-address = [ 02 00 00 00 00 01
>>> ];
>>> reg = < 81c00000 40 >;
>>> xlnx,bus2core-clk-ratio = <1>;
>>> xlnx,phy-type = <1>;
>>> xlnx,phyaddr = <1>;
>>> xlnx,rxcsum = <0>;
>>> xlnx,rxfifo = <1000>;
>>> xlnx,temac-type = <1>;
>>> xlnx,txcsum = <0>;
>>> xlnx,txfifo = <1000>;
>>> } ;
>>> } ;
>>> mpmc@0 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "xlnx,mpmc-4.00.a";
>>> PIM2: sdma@84600100 {
>>> compatible = "xlnx,ll-dma-1.00.a";
>>> interrupt-parent = <&xps_intc_0>;
>>> interrupts = < 1 2 0 2 >;
>>> reg = < 84600100 80 >;
>>> } ;
>>> } ;
>>> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>>> compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
>>> reg = < ffffe000 2000 >;
>>> xlnx,family = "virtex4";
>>> } ;
>>> xps_intc_0: interrupt-controller@81800000 {
>>> #interrupt-cells = <2>;
>>> compatible = "xlnx,xps-intc-1.00.a";
>>> interrupt-controller ;
>>> reg = < 81800000 10000 >;
>>> xlnx,num-intr-inputs = <7>;
>>> } ;
>>> } ;
>>> ppc405_0_dplb1: plb@1 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "xlnx,plb-v46-1.02.a";
>>> ranges ;
>>> } ;
>>> } ;
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
>>> Sent: Tuesday, June 24, 2008 1:21 PM
>>> To: John Linn
>>> Cc: linuxppc-embedded@ozlabs.org
>>> Subject: Re: Linux on Virtex board with ARCH=powerpc
>>>
>>> Hi John,
>>>
>>> Thanks for your reply, that's really helpful. I'm actually using the
>>>
>
>
>>> mainline kernel, rather than the one from the xilinx git tree, but
>>>
>>>
>> your
>>
>>
>>> information has really moved me on. My first problem was that the
>>> Xilinx utility (from the git tree) for device tree dts generation
>>>
>>>
>> didn't
>>
>>
>>> insert a "linux,stdout-path" node under "chosen". I spotted that the
>>>
>
>
>>> ml403 example had this, so after adding it I got early console
>>> messages. Everything now grinds to a halt after I get the message
>>>
>>>
>> "flat
>>
>>
>>> tree at 0x40ad60" which is just before it calls the kernel, so I
>>>
>>>
>> assume
>>
>>
>>> it's that call that is killing it. I have "console=ttyUL0" for my
>>> uartlite, so I should be getting messages, shouldn't I? Do you know
>>> where the next execution point is? Maybe I could find out where it's
>>>
>
>
>>> getting stuck.
>>>
>>> I haven't managed to generate an ACE file, I'm just loading the
>>>
> kernel
>
>>>
>>>
>>
>>
>>> image from xmd ATM, genace won't play ball for me, it complains about
>>>
>
>
>>> -board user not being valid, it won't even run on the examples copied
>>>
>
>
>>> directly from the user manual. Anyway, I think genace is a bit OT,
>>>
>>>
>> and
>>
>>
>>> I can manage with xmd for now.
>>>
>>> Thanks,
>>> -- Peter
>>>
>>> John Linn wrote:
>>>
>>>
>>>
>>>> Hi Peter,
>>>>
>>>> I'm not up on what can be done with the simple image you refer to in
>>>>
>>>>
>>>>
>>> 1.
>>>
>>>
>>>
>>>> I'm sure I should be, but there's a lot to learn.
>>>>
>>>> With regards to 2, the elf image, zImage (without the elf
>>>>
> extension),
>
>>>>
>>>>
>>>>
>>> is
>>>
>>>
>>>
>>>> located in arch/powerpc/boot.
>>>>
>>>> You can make a SystemACE file from that elf image just as you did in
>>>> arch/ppc. We have a default device tree file, ml405.dts, in the
>>>> arch/powerpc/boot/dts directory for our ml405 board. The kernel
>>>> configuration has a config, DEVICE_TREE, that specifies the name of
>>>>
>>>>
>>>>
>>> the
>>>
>>>
>>>
>>>> device tree file. I normally compile the device tree into the kernel
>>>> which is the default build, make ARCH=powerpc zImage. That image
>>>>
> does
>
>>>> not require a boot loader.
>>>>
>>>> I inserted the text below from a document that I have about building
>>>>
>>>>
>>>>
>>> the
>>>
>>>
>>>
>>>> arch/ppc and arch/powerpc kernels.
>>>>
>>>> Hope that helps,
>>>> John
>>>>
>>>>
>>>> Notation
>>>>
>>>> The phrase "<ppc or powerpc>" is used throughput the text and means
>>>>
>>>>
>>>>
>>> that
>>>
>>>
>>>
>>>> one or the other, "ppc" or "powerpc" is to be typed depending on the
>>>> architecture you are building.
>>>>
>>>> Commands that are used in a bash shell are preceded by ">".
>>>>
>>>> Getting Ready To Build the Kernel
>>>>
>>>> This assumes you installed the ELDK tools and assumes you'll be
>>>>
> using
>
>>>>
>>>>
>>>>
>>> a
>>>
>>>
>>>
>>>> bash shell.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> bash
>>>>> export CROSS_COMPILE=ppc_4xx-
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Setting Up the Kernel Tree
>>>>
>>>> If you have previously built this kernel for another architecture,
>>>>
>>>>
>> ppc
>>
>>
>>>> or powerpc, then the tree needs to be setup correctly for the new
>>>> architecture. Assuming you have not previously built it, this does
>>>>
>>>>
>>>>
>>> not
>>>
>>>
>>>
>>>> need to be done.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> make ARCH=<ppc or powerpc> mrproper
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Configuring the Kernel
>>>>
>>>> The kernel should be configured to run on the ML405 or ML507 board
>>>>
>>>>
>>>>
>>> from
>>>
>>>
>>>
>>>> Xilinx.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> make ARCH=<ppc or powerpc> ml405_defconfig
>>>>>
>>>>>
>>>>>
>>>>>
>>>> or
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> make ARCH=<ppc or powerpc> ml507_defconfig
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Building the Kernel
>>>>
>>>> The following command will build the Linux kernel assuming you are
>>>>
> in
>
>>>> the root directory of the kernel. The root directory of the kernel
>>>>
>>>>
>>>>
>>> from
>>>
>>>
>>>
>>>> the Xilinx Git tree is linux-2.6-xlnx. An elf file, zImage.elf, is
>>>> created in the arch/ppc/boot/images directory for ppc architecture.
>>>>
>>>>
>> An
>>
>>
>>>> elf file, zImage, is created in the the arch/powerpc/boot directory
>>>>
>>>>
>>>>
>>> for
>>>
>>>
>>>
>>>> the powerpc architecture.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> make ARCH=<ppc or powerpc> zImage
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> Building the Kernel With Ramdisk
>>>>
>>>> A ram disk image, a file named *.gz, must be placed into the
>>>> arch/ppc/boot/images or arch/powerpc/boot directory, depending on
>>>>
> the
>
>>>> architecture, prior to building the kernel.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> make ARCH=<ppc or powerpc> zImage.initrd
>>>>>
>>>>>
>>>>>
>>>>>
>>>> An elf file, zImage.initrd.elf, is created in arch/ppc/boot/images
>>>> directory for the ppc architecture. An elf file file, zImage.initrd,
>>>>
>>>>
>>>>
>>> is
>>>
>>>
>>>
>>>> created in arch/powerpc/boot directory for the powerpc architecture.
>>>>
>>>> Generating An Ace File
>>>>
>>>> The elf file generated for the kernel and the bit stream can be
>>>>
>>>>
>>>>
>>> combined
>>>
>>>
>>>
>>>> to create an ACE file for compact flash. The following assumes a
>>>>
>>>>
>> bash
>>
>>
>>>> shell where XMD is accessible and a xilinx probe attached to the
>>>>
>>>>
>> board
>>
>>
>>>> for which you are generating an ace file.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> xmd -tcl genace.tcl -jprog -target ppc_hw -hw <bit file name> -elf
>>>>>
>>>>>
>>>>>
>>> <elf
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> file name> -board <ml405 or ml507> -ace <desired ace file name>
>>>>
>>>> -----Original Message-----
>>>> From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
>>>> [mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org]
>>>>
> On
>
>>>> Behalf Of Peter Mendham
>>>> Sent: Tuesday, June 24, 2008 3:02 AM
>>>> To: linuxppc-embedded@ozlabs.org
>>>> Subject: Linux on Virtex board with ARCH=powerpc
>>>>
>>>> Dear all,
>>>>
>>>> I'm trying to boot a 2.6.26-rc6 kernel on a custom Virtex 4 board.
>>>>
> I
>
>>>>
>>>>
>>
>>
>>>> have used the Xilinx utility to generate a device tree and now want
>>>>
>>>>
>> to
>>
>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>> generate an image for throwing onto CF for use with a SystemACE
>>>>
> (just
>
>>>>
>>>>
>>
>>
>>>> like on the the ML3/4xx boards). I don't want to use a bootloader
>>>>
> (I
>
>>>>
>>>>
>>
>>
>>>> don't really need one). I saw something on this list about
>>>>
>>>>
>>>>
>>> simpleImage,
>>>
>>>
>>>
>>>> "simple" sounded good to me so I thought I'd try that (or did I
>>>> misinterpret what this is for?). I also don't want the image to be
>>>>
>>>>
>>>>
>>> too
>>>
>>>
>>>
>>>> big, I always used to use a zImage under ARCH=ppc. So, two
>>>>
> questions,
>
>>>>
>>>>
>>
>>
>>>> which hopefully are easy ones:
>>>> 1. I did what Grant said in a post to this list about simpleImage,
>>>>
>>>>
>> and
>>
>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>> dumped my dts into arch/powerpc/boot/dts and I called it system.dts
>>>>
>>>>
>>>>
>>> (for
>>>
>>>
>>>
>>>> now). I then tried to do make simpleImage.system which ran right
>>>> through to final link then moaned about a missing simpleboot-system.
>>>>
>>>>
>>
>>
>>>> Where is this supposed to come from? What am I doing wrong? I
>>>>
>>>>
>>>>
>>> naively
>>>
>>>
>>>
>>>> tried copying simpleboot.o to simpleboot-system.o and the error went
>>>>
>
>
>>>> away. Hmm.
>>>> 2. I need an ELF to give to my SystemACE file generator. This used
>>>>
>>>>
>> to
>>
>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>> pop up in arch/ppc/boot/images and be called zImage.elf, which made
>>>> sense to me. What's the deal now with powerpc? What should I be
>>>>
>>>>
>>>>
>>> using?
>>>
>>>
>>>
>>>> Finally, can anyone give me a heads-up on any gotchas with what I'm
>>>> trying to do. As you can tell, I don't entirely know what I'm
>>>>
> doing,
>
>>>>
>>>>
>>>>
>>> so
>>>
>>>
>>>
>>>> any pointers would be gratefully received.
>>>>
>>>> Thanks,
>>>> -- Peter
>>>>
>>>>
>>>> The University of Dundee is a Scottish Registered Charity, No.
>>>>
>>>>
>>>>
>>> SC015096.
>>>
>>>
>>>
>>>> _______________________________________________
>>>> Linuxppc-embedded mailing list
>>>> Linuxppc-embedded@ozlabs.org
>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>> This email and any attachments are intended for the sole use of the
>>>>
>>>>
>>>>
>>> named recipient(s) and contain(s) confidential information that may
>>>
> be
>
>>> proprietary, privileged or copyrighted under applicable law. If you
>>>
>>>
>> are
>>
>>
>>> not the intended recipient, do not read, copy, or forward this email
>>> message or any attachments. Delete this email message and any
>>> attachments immediately.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>> The University of Dundee is a Scottish Registered Charity, No.
>>>
>>>
>> SC015096.
>>
>>
>>> This email and any attachments are intended for the sole use of the
>>>
>>>
>> named recipient(s) and contain(s) confidential information that may be
>> proprietary, privileged or copyrighted under applicable law. If you
>>
> are
>
>> not the intended recipient, do not read, copy, or forward this email
>> message or any attachments. Delete this email message and any
>> attachments immediately.
>>
>>
>>>
>>>
>>>
>> The University of Dundee is a Scottish Registered Charity, No.
>>
> SC015096.
>
>>
>>
>> This email and any attachments are intended for the sole use of the
>>
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any
> attachments immediately.
>
>>
>>
>
>
> The University of Dundee is a Scottish Registered Charity, No. SC015096.
>
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>
The University of Dundee is a Scottish Registered Charity, No. SC015096.
^ permalink raw reply
* Re: [RFC/PATCH 0/3] sched: allow arch override of cpu power
From: Nathan Lynch @ 2008-06-27 14:23 UTC (permalink / raw)
To: Breno Leitao
Cc: linuxppc-dev, Ingo Molnar, Paul Mackerras, linux-kernel,
Anton Blanchard
In-Reply-To: <4863F2CC.1030907@linux.vnet.ibm.com>
Breno Leitao wrote:
> Nathan Lynch wrote:
>> There is an "interesting" quality of POWER6 cores, which each have 2
>> hardware threads: assuming one thread on the core is idle, the primary
>> thread is a little "faster" than the secondary thread. To illustrate:
>>
> I found this feature interesting and decided to do some tests.
> After some tests I found that the example you post really runs fast in
> the first CPU, but a more "elaborated" application runs slower on the
> first CPU.
> Here is a small example:
>
> # taskset 0x1 time -f "%e, %U, %S" ./a.out ; taskset 0x2 time -f "%e,
> %U, %S" ./a.out
> 10.77, 10.72, 0.01
> 10.53, 10.48, 0.01
>
> # taskset 0x2 time -f "%e, %U, %S" ./a.out ; taskset 0x1 time -f "%e,
> %U, %S" ./a.out
> 10.55, 10.50, 0.01
> 10.77, 10.72, 0.01
I've been able to duplicate your results, thanks for the testcase.
Guess I'll need to understand what's going on before continuing with
this...
^ permalink raw reply
* Re: [PATCH 26/60] microblaze_v4: time support
From: Michal Simek @ 2008-06-27 13:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-arch, alan, Michal Simek, vapier.adi, arnd, matthew,
microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, John.Linn, john.williams
In-Reply-To: <alpine.LFD.1.10.0806271240461.3297@apollo.tec.linutronix.de>
>> +
>> +static inline void udelay(unsigned long usec)
>> +{
>> +}
>
>shouldnt this function be named zerodelay() ?
>
>Thanks,
> tglx
I have prepared implementation of this function which sent me JW.
I did some changes which I test it because I found problem there.
M
^ permalink raw reply
* Re: dtc: Address an assortment of portability problems
From: Scott Wood @ 2008-06-27 14:53 UTC (permalink / raw)
To: Scott Wood, Jon Loeliger, linuxppc-dev, Benno Rice
In-Reply-To: <20080626234743.GA16169@yookeroo.seuss>
David Gibson wrote:
> On Thu, Jun 26, 2008 at 10:25:28AM -0500, Scott Wood wrote:
>> On Thu, Jun 26, 2008 at 11:03:49AM +1000, David Gibson wrote:
>>> - the endian handling functions in libfdt_env.h, based on
>>> endian.h and byteswap.h are replaced with some portable open-coded
>>> versions. Unfortunately, these result in fairly crappy code when
>>> compiled, but as far as I can determine there doesn't seem to be any
>>> POSIX, SUS or de facto standard way of determining endianness at
>>> compile time, nor standard names for byteswapping functions.
>> Since device-tree and network byte order happen to be the same, we could use
>> ntohl/htonl.
>
> Not for the 64-bit version.
Why? They operate on uint32_t despite the "l" in the name, and there
are no 64-bit fields in the device tree...
-Scott
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Michal Simek @ 2008-06-27 13:19 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, Michal Simek, Arnd Bergmann, vapier.adi, matthew,
microblaze-uclinux, linux-kernel, John.Linn, linuxppc-dev,
will.newton, john.williams, hpa, drepper, alan
In-Reply-To: <20080627115936.GA18644@cs181140183.pp.htv.fi>
Hi Adrian and Arnd,
>> > After all, it won't matter whether we'll unify resp. remove
>> > 22 or 23 files.
>>
>> That wasn't my idea. The logic was that if one more file exists
>> in asm-generic that can be removed from the architectures,
>> we get 22 more files to remove without anyone having to look
>> at the big picture. When microblaze is in,
>
>Discussions of the "big picture" should be in an own thread, not as
>part of a merge of a new architecture.
>
>I am not an architecture maintainer, but I do not like the way you want
>to couple the microblaze merge with the move of stuff to asm-generic.
>
>They both make sense, but they are clearly separate issues.
>
>> I can compile a list
>> with asm-generic files that can be used to replace the architecture
>> specific files, so the arch maintainers can decide on their own
>> whether to clean their own stuff up or not.
>>...
>
>We need either all architectures changed or none at all - we do need the
>arch headers to become more similar, not more different.
>
>And this is why we need an agreement _before_ an asm-generic header gets
>added, not after it.
I moved some headers to asm-generic how Arnd recommended to me. The same style
is applied to of files. If you think that is good idea to start with new topic what is necessary to move
to asm-generic, I agree. For me is not hard to move these files back to asm-microblaze and then
someone can do big patch among all archs.
If you want to managed, please open new discussion about and cc me.
Michal
^ permalink raw reply
* [PATCH] powerpc/booke: don't reinitialize time base
From: Kumar Gala @ 2008-06-27 13:10 UTC (permalink / raw)
To: linuxppc-dev
For some reason long ago I decided that we should zero out the time base
when we calibrate the decrementer. The problem is that this can be
harmful in SMP systems where the firmware has already synchronized the
time bases on the various cores.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/kernel/time.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index c73fc33..eb93880 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -742,10 +742,6 @@ void __init generic_calibrate_decr(void)
}
#if defined(CONFIG_BOOKE) || defined(CONFIG_40x)
- /* Set the time base to zero */
- mtspr(SPRN_TBWL, 0);
- mtspr(SPRN_TBWU, 0);
-
/* Clear any pending timer interrupts */
mtspr(SPRN_TSR, TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS);
--
1.5.5.1
^ permalink raw reply related
* Re: Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-06-27 13:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <18532.52894.698980.899308@cargo.ozlabs.ibm.com>
On Jun 27, 2008, at 6:27 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Paul, any update on when we might see some of the various patches
>> pulled into powerpc-next?
>
> This weekend assuming I get over this gastric flu-like lurgy that I
> have at the moment.
Uugh, that sucks.
>> I've got some work I'd like to see in .27 but it needs Michael's code
>> patching patches.
>
> I thought you had some concerns about patches 5/14 and 12/14 of his
> series?
5/14 needs some better comments but nothing that should hold up the
acceptance and 12/14 or should be merged with 11/14 if he reposts the
patch set. But again, nothing to hold things up.
- k
^ permalink raw reply
* Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic
From: Sam Ravnborg @ 2008-06-27 13:55 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-arch, alan, Michal Simek, vapier.adi, Arnd Bergmann,
matthew, microblaze-uclinux, linux-kernel, drepper, linuxppc-dev,
will.newton, hpa, monstr, John.Linn, john.williams
In-Reply-To: <20080627115936.GA18644@cs181140183.pp.htv.fi>
>
> We need either all architectures changed or none at all - we do need the
> arch headers to become more similar, not more different.
>
> And this is why we need an agreement _before_ an asm-generic header gets
> added, not after it.
We already have the agreement..
Files which are equal among archs should be in asm-generic.
And there is simply no gain in adding files for an arch when can put
them in asm-generic.
When they are in asm-generic than we can fix the other archs one-by-one.
Sam
^ permalink raw reply
* Re: Linux on Virtex board with ARCH=powerpc
From: Peter Mendham @ 2008-06-27 15:06 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-embedded
In-Reply-To: <20080627132505.AD38611E80F9@mail35-sin.bigfish.com>
Hi John,
> With regard to CONFIG_PPC_UDBG... we have a patch ready that I need to
> apply to the Git tree and I'll expedite that.
>
Great, thanks.
> With the console and UART Lite, the only thing I could think of is
> making sure you have a dev entry for the UART Lite.
>
I do. I used the major and minor numbers from the driver source.
> I'm assuming all the boot messages about the console, "enabled", look
> the same as the 550 as I have seen that give hints to problems
> sometimes.
>
I'm not really getting anything illuminating. I turned debugging
messages on and I see the following:
Console: colour dummy device
80x25
console [ttyUL0]
enabled
<snip>
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
uartlite: calling
uart_register_driver()
uartlite: calling
of_register_platform_driver()
uartlite 800f0000.serial: ulite_of_probe(c7846800,
c019713c)
ulite console: port=c01aef38;
port->mapbase=800f0003
800f0000.serial: ttyUL0 at MMIO 0x800f0003 (irq = 0) is a
uartlite
uartlite: calling platform_driver_register()
The only thing that I notice is that the "console [x] enabled" line
comes way before the uartlite driver registers, whereas on the 16550
version it's straight afterwards. Does that matter?
Thanks,
-- Peter
> Thanks,
> John
>
> -----Original Message-----
> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
> Sent: Friday, June 27, 2008 6:31 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux on Virtex board with ARCH=powerpc
>
> Hi John,
>
> Yes, with regard to the non-functional sysace, I was being an idiot: I
> had a small hw problem which now that I have fixed it, the kernel now
> reports that my drive is mounted.
>
> I now have a new and rather bizarre problem, which maybe you or someone
> else has met before. I have a simple FPGA design with memory, a sysace
> and a uart16550 on an ML405 (I've put my hardware to one side for the
> moment). It works just fine. If I swap the uart16550 for a uartlite
> (remaking the kernel with the correct device tree) I see all the boot
> messages and the kernel seems to start OK, the root partition is mounted
>
> but then I see nothing from /sbin/init. This is the same root fs that I
>
> was using with the uart16550 example I just mentioned. So it's a known
> good root fs, but it doesn't appear to be able to output to /dev/console
>
> when I have a uartlite instead of a uart16550. I have selected console
> support for uartlite. Any ideas?
>
> Incidentally, the uart16550 solution did not work until I removed
> CONFIG_PPC_UDBG_16550 - the kernel was getting stuck in udbg_550_putc
> indefinitely.
>
> Thanks,
> -- Peter
>
>
> John Linn wrote:
>
>> Hi Peter,
>>
>> I think you'll get a baseline quicker this way and then you can go on
>> other less known paths after that.
>>
>> In my experience, this message happens when there is no compact flash
>>
> in
>
>> the slot of the board.
>>
>> I have the system ace device as /dev/xsa2 in my notes, but I have only
>> used it much. Sorry it's not one of my primary test cases at this
>>
> point
>
>> in time.
>>
>> Thanks,
>> John
>>
>> -----Original Message-----
>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
>> Sent: Thursday, June 26, 2008 7:24 AM
>> To: John Linn
>> Cc: linuxppc-embedded@ozlabs.org
>> Subject: Re: Linux on Virtex board with ARCH=powerpc
>>
>> Hi John,
>>
>> OK, I've given in and I'm using the xilinx git code now :) It now
>>
> shows
>
>> some signs of life, thanks, but the sysace driver is not happy. My
>>
> root
>
>> fs is on cf and I'm not using initrd. The driver loads then gets
>>
> stuck,
>
>> repeatedly saying:
>>
>> xsysace 80030000.sysace: kicking stalled fsm; state=2 task=0 iter=1
>>
> dc=0
>
>> I notice from the driver source that state 2 is the driver attempting
>>
> to
>
>> acquire the mpu lock. I have tried the standard xilinx sysace
>>
> selftest
>
>> code which just acquires and frees the lock (which is fine) so the
>> hardware should be OK (I hope). I have the sysace hooked up to an irq
>>
>
>
>> (the only one), I have no idea whether the dts is correct but it seems
>>
>
>
>> to compare favourably with the ml405 one; mine says (the important
>> bits):
>>
>> intc: interrupt-controller@80010000 {
>> #interrupt-cells = <2>;
>> compatible = "xlnx,xps-intc-1.00.a";
>> interrupt-controller ;
>> reg = < 80010000 10000 >;
>> xlnx,num-intr-inputs = <1>;
>> } ;
>> sysace: sysace@80030000 {
>> compatible = "xlnx,xps-sysace-1.00.a";
>> interrupt-parent = <&intc>;
>> interrupts = < 0 2 >;
>> reg = < 80030000 10000 >;
>> xlnx,family = "virtex4";
>> xlnx,mem-width = <10>;
>> } ;
>>
>> Do you have any ideas?
>>
>> Thanks,
>> -- Peter
>>
>> John Linn wrote:
>>
>>
>>> Hi Peter,
>>>
>>> To some extent I think you're trying to re-invent the wheel here, but
>>>
>>>
>> I
>>
>>
>>> understand why.
>>>
>>> Ideally, you would be able to pull from the mainline kernel to build
>>> this, but Xilinx hasn't got our code into the mainline. We are
>>>
>>>
>> working
>>
>>
>>> on it more proactively now.
>>>
>>> So, in the meantime, it would be easier for you to pull from the
>>>
>>>
>> Xilinx
>>
>>
>>> git tree as we have solved the problems you are solving I believe.
>>>
>>> Git://git.xilinx.com/linux-2.6-xlnx or http://git.xilinx.com/...
>>>
>>> We supply the device tree files and kernel configurations for the
>>>
>>>
>> ML405
>>
>>
>>> and ML507 boards to help get started.
>>>
>>> Thanks and sorry for the inconvenience,
>>> John
>>>
>>> -----Original Message-----
>>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
>>> Sent: Wednesday, June 25, 2008 10:18 AM
>>> To: John Linn
>>> Cc: linuxppc-embedded@ozlabs.org
>>> Subject: Re: Linux on Virtex board with ARCH=powerpc
>>>
>>> OK, this is all new to me, so please bear with me if I've made a
>>>
> major
>
>>>
>>>
>>
>>
>>> mistake. I ran the kernel until it didn't give me anymore output and
>>>
>
>
>>> then told xmd to "stop", mrd from any location gave me exactly the
>>>
>>>
>> same
>>
>>
>>> 32-bit word of garbage. I then reset the processor and mrd would
>>>
> give
>
>>>
>>>
>>
>>
>>> me what looked like reasonable values. I found the __log_buf symbol
>>>
>>>
>> in
>>
>>
>>> the System.map file (0xc024a108) and tried mrd on what I assume is
>>>
> the
>
>>>
>>>
>>
>>
>>> corresponding physical address of 0x0024a108. I get the following:
>>>
>>> <6>Using Xilinx Virtex machine description
>>> <5>Linux version 2.6.26-rc6 (peter@eris) (gcc version 4.2.4) #9
>>>
>>>
>> PREEMPT
>>
>>
>>> Wed Jun 25 16:27:33 BST 2008
>>> <7>Entering add_active_range(0, 0, 131072) 0 entries of 256 used
>>> <7>Top of RAM: 0x20000000, Total RAM: 0x20000000
>>> <7>Memory hole size: 0MB
>>> <4>Zone PFN ranges:
>>> <4> DMA 0 -> 131072
>>> <4> Normal 131072 -> 131072
>>> <4>Movable zone start PFN for each node
>>> <4>early_node_map[1] active PFN ranges
>>> <4> 0: 0 -> 131072
>>> <7>On node 0 totalpages: 131072
>>> <7> DMA zone: 1024 pages used for memmap
>>> <7> DMA zone: 0 pages reserved
>>> <7> DMA zone: 130048 pages, LIFO batch:31
>>> <7> Normal zone: 0 pages used for memmap
>>> <7> Movable zone: 0 pages used for memmap
>>> <4>Built 1 zonelists in Zone order, mobility grouping on. Total
>>>
>>>
>> pages:
>>
>>
>>> 130048
>>> <5>Kernel command line: console=ttyUL0 root=/dev/xsa2 rw
>>> <6>Xilinx intc at 0xFDFFF000C025CFFC mapped to 0x0000025d
>>> <4>PID hash table entries: 2048 (order: 11, 8192 bytes)
>>>
>>> xmd tells me that the processor stopped at 0xc000fe50, and subsequent
>>>
>
>
>>> "con" and "stop" sequences do no move this on (it reports the same
>>>
>>>
>> each
>>
>>
>>> time). Below is a choice excerpt of my System.map:
>>>
>>> c000fdc4 t src_error
>>> c000fddc t dst_error
>>> c000fdf4 T __div64_32
>>> c000fe94 T cacheable_memzero
>>> c000ff38 T memset
>>>
>>> So I guess that means it's in __div64_32?
>>>
>>> Any ideas?
>>>
>>> Thanks in advance,
>>> -- Peter
>>>
>>> John Linn wrote:
>>>
>>>
>>>
>>>> Sounds like the bootstrap loader has loaded the kernel and passed
>>>>
> off
>
>>>> execution to it, but there's no console working on the kernel.
>>>>
>>>> You can confirm that since you have a probe as you can dump the
>>>> __log_buf by getting the address of it using objdump on the elf
>>>>
>>>>
>> image.
>>
>>
>>>> It's a pain to convert to readable form, but can help to see that
>>>>
>>>>
>>>>
>>> things
>>>
>>>
>>>
>>>> are indeed running. Stop the processor, then do the memory read
>>>>
>>>>
>>>>
>>> command,
>>>
>>>
>>>
>>>> mrd, in xmd.
>>>>
>>>> For the console to work with UART Lite, CONFIG_OF must be on in the
>>>> kernel configuration, I would check that.
>>>>
>>>> The file, arch/powerpc/boot/virtex.c, has the startup code for the
>>>> virtex specific processing. It checks to make sure there is
>>>>
>>>>
>>>>
>>> compatible
>>>
>>>
>>>
>>>> hardware based on the device tree. If your device tree doesn't
>>>>
> match
>
>>>> that hardware you could have a problem. I have not found the
>>>>
> powerup
>
>>>>
>>>>
>>>>
>>> of
>>>
>>>
>>>
>>>> the kernel to be very informative if the device tree is wrong.
>>>>
>>>> I pasted in our ML405 device tree below to allow you to compare to
>>>>
>>>>
>> it.
>>
>>
>>>> Hope that helps,
>>>> John
>>>>
>>>>
>>>>
>>>> /*
>>>> * (C) Copyright 2007 Michal Simek
>>>> *
>>>> * Michal SIMEK <monstr@monstr.eu>
>>>> *
>>>> * This program is free software; you can redistribute it and/or
>>>> * modify it under the terms of the GNU General Public License as
>>>> * published by the Free Software Foundation; either version 2 of
>>>> * the License, or (at your option) any later version.
>>>> *
>>>>
>>>> * This program is distributed in the hope that it will be useful,
>>>> * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> * GNU General Public License for more details.
>>>> *
>>>> * You should have received a copy of the GNU General Public License
>>>> * along with this program; if not, write to the Free Software
>>>> * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>>>> * MA 02111-1307 USA
>>>> *
>>>> * CAUTION: This file is automatically generated by libgen.
>>>> * Version: Xilinx EDK 10.1.1 EDK_K_SP1.1
>>>> */
>>>>
>>>> / {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "xlnx,virtex";
>>>> model = "testing";
>>>> DDR_SDRAM: memory@0 {
>>>> device_type = "memory";
>>>> reg = < 0 8000000 >;
>>>> } ;
>>>> chosen {
>>>> bootargs = "console=ttyS0 ip=on root=/dev/ram";
>>>> linux,stdout-path = "/plb@0/serial@83e00000";
>>>> } ;
>>>> cpus {
>>>> #address-cells = <1>;
>>>> #cpus = <1>;
>>>>
>>>> #size-cells = <0>;
>>>> ppc405_0: cpu@0 {
>>>> clock-frequency = <11e1a300>;
>>>> compatible = "PowerPC,405", "ibm,ppc405";
>>>>
>>>> d-cache-line-size = <20>;
>>>> d-cache-size = <4000>;
>>>> device_type = "cpu";
>>>> i-cache-line-size = <20>;
>>>>
>>>> i-cache-size = <4000>;
>>>> model = "PowerPC,405";
>>>> reg = <0>;
>>>> timebase-frequency = <11e1a300>;
>>>> xlnx,apu-control = <de00>;
>>>> xlnx,apu-udi-1 = <a18983>;
>>>> xlnx,apu-udi-2 = <a38983>;
>>>> xlnx,apu-udi-3 = <a589c3>;
>>>> xlnx,apu-udi-4 = <a789c3>;
>>>> xlnx,apu-udi-5 = <a98c03>;
>>>> xlnx,apu-udi-6 = <ab8c03>;
>>>> xlnx,apu-udi-7 = <ad8c43>;
>>>> xlnx,apu-udi-8 = <af8c43>;
>>>> xlnx,deterministic-mult = <0>;
>>>> xlnx,disable-operand-forwarding = <1>;
>>>> xlnx,fastest-plb-clock = "DPLB0";
>>>> xlnx,generate-plb-timespecs = <1>;
>>>> xlnx,mmu-enable = <1>;
>>>> xlnx,pvr-high = <0>;
>>>> xlnx,pvr-low = <0>;
>>>> } ;
>>>> } ;
>>>> plb: plb@0 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "xlnx,plb-v46-1.02.a";
>>>> ranges ;
>>>> IIC_EEPROM: i2c@81600000 {
>>>> compatible = "xlnx,xps-iic-2.00.a";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 4 2 >;
>>>> reg = < 81600000 10000 >;
>>>> xlnx,clk-freq = <5f5e100>;
>>>> xlnx,family = "virtex4";
>>>> xlnx,gpo-width = <1>;
>>>> xlnx,iic-freq = <186a0>;
>>>> xlnx,scl-inertial-delay = <0>;
>>>> xlnx,sda-inertial-delay = <0>;
>>>> xlnx,ten-bit-adr = <0>;
>>>> } ;
>>>> LEDs_4Bit: gpio@81400000 {
>>>> compatible = "xlnx,xps-gpio-1.00.a";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 5 2 >;
>>>> reg = < 81400000 10000 >;
>>>> xlnx,all-inputs = <0>;
>>>> xlnx,all-inputs-2 = <0>;
>>>> xlnx,dout-default = <0>;
>>>> xlnx,dout-default-2 = <0>;
>>>> xlnx,family = "virtex4";
>>>> xlnx,gpio-width = <4>;
>>>> xlnx,interrupt-present = <1>;
>>>> xlnx,is-bidir = <1>;
>>>> xlnx,is-bidir-2 = <1>;
>>>> xlnx,is-dual = <0>;
>>>> xlnx,tri-default = <ffffffff>;
>>>> xlnx,tri-default-2 = <ffffffff>;
>>>> } ;
>>>> RS232_Uart: serial@83e00000 {
>>>> compatible = "ns16550";
>>>> device_type = "serial";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 6 2 >;
>>>> reg = < 83e00000 10000 >;
>>>> reg-offset = <3>;
>>>> reg-shift = <2>;
>>>> clock-frequency = <05f5e100>;
>>>> xlnx,family = "virtex4";
>>>> xlnx,has-external-rclk = <0>;
>>>> xlnx,has-external-xin = <0>;
>>>> xlnx,is-a-16550 = <1>;
>>>> } ;
>>>> SysACE_CompactFlash: sysace@83600000 {
>>>> compatible = "xlnx,xps-sysace-1.00.a";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 3 2 >;
>>>> reg = < 83600000 10000 >;
>>>> xlnx,family = "virtex4";
>>>> xlnx,mem-width = <10>;
>>>> } ;
>>>> TriMode_MAC_GMII: xps-ll-temac@81c00000 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "xlnx,compound";
>>>> ethernet@81c00000 {
>>>> compatible = "xlnx,xps-ll-temac-1.01.a";
>>>> device_type = "network";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 2 2 >;
>>>> llink-connected = <&PIM2>;
>>>> local-mac-address = [ 02 00 00 00 00 01
>>>> ];
>>>> reg = < 81c00000 40 >;
>>>> xlnx,bus2core-clk-ratio = <1>;
>>>> xlnx,phy-type = <1>;
>>>> xlnx,phyaddr = <1>;
>>>> xlnx,rxcsum = <0>;
>>>> xlnx,rxfifo = <1000>;
>>>> xlnx,temac-type = <1>;
>>>> xlnx,txcsum = <0>;
>>>> xlnx,txfifo = <1000>;
>>>> } ;
>>>> } ;
>>>> mpmc@0 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "xlnx,mpmc-4.00.a";
>>>> PIM2: sdma@84600100 {
>>>> compatible = "xlnx,ll-dma-1.00.a";
>>>> interrupt-parent = <&xps_intc_0>;
>>>> interrupts = < 1 2 0 2 >;
>>>> reg = < 84600100 80 >;
>>>> } ;
>>>> } ;
>>>> xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffe000 {
>>>> compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
>>>> reg = < ffffe000 2000 >;
>>>> xlnx,family = "virtex4";
>>>> } ;
>>>> xps_intc_0: interrupt-controller@81800000 {
>>>> #interrupt-cells = <2>;
>>>> compatible = "xlnx,xps-intc-1.00.a";
>>>> interrupt-controller ;
>>>> reg = < 81800000 10000 >;
>>>> xlnx,num-intr-inputs = <7>;
>>>> } ;
>>>> } ;
>>>> ppc405_0_dplb1: plb@1 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> compatible = "xlnx,plb-v46-1.02.a";
>>>> ranges ;
>>>> } ;
>>>> } ;
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Peter Mendham [mailto:petermendham@computing.dundee.ac.uk]
>>>> Sent: Tuesday, June 24, 2008 1:21 PM
>>>> To: John Linn
>>>> Cc: linuxppc-embedded@ozlabs.org
>>>> Subject: Re: Linux on Virtex board with ARCH=powerpc
>>>>
>>>> Hi John,
>>>>
>>>> Thanks for your reply, that's really helpful. I'm actually using
>>>>
> the
>
>>>>
>>>>
>>
>>
>>>> mainline kernel, rather than the one from the xilinx git tree, but
>>>>
>>>>
>>>>
>>> your
>>>
>>>
>>>
>>>> information has really moved me on. My first problem was that the
>>>> Xilinx utility (from the git tree) for device tree dts generation
>>>>
>>>>
>>>>
>>> didn't
>>>
>>>
>>>
>>>> insert a "linux,stdout-path" node under "chosen". I spotted that
>>>>
> the
>
>>>>
>>>>
>>
>>
>>>> ml403 example had this, so after adding it I got early console
>>>> messages. Everything now grinds to a halt after I get the message
>>>>
>>>>
>>>>
>>> "flat
>>>
>>>
>>>
>>>> tree at 0x40ad60" which is just before it calls the kernel, so I
>>>>
>>>>
>>>>
>>> assume
>>>
>>>
>>>
>>>> it's that call that is killing it. I have "console=ttyUL0" for my
>>>> uartlite, so I should be getting messages, shouldn't I? Do you know
>>>>
>
>
>>>> where the next execution point is? Maybe I could find out where
>>>>
> it's
>
>>>>
>>>>
>>
>>
>>>> getting stuck.
>>>>
>>>> I haven't managed to generate an ACE file, I'm just loading the
>>>>
>>>>
>> kernel
>>
>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>> image from xmd ATM, genace won't play ball for me, it complains
>>>>
> about
>
>>>>
>>>>
>>
>>
>>>> -board user not being valid, it won't even run on the examples
>>>>
> copied
>
>>>>
>>>>
>>
>>
>>>> directly from the user manual. Anyway, I think genace is a bit OT,
>>>>
>>>>
>>>>
>>> and
>>>
>>>
>>>
>>>> I can manage with xmd for now.
>>>>
>>>> Thanks,
>>>> -- Peter
>>>>
>>>> John Linn wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> I'm not up on what can be done with the simple image you refer to
>>>>>
> in
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> 1.
>>>>
>>>>
>>>>
>>>>
>>>>> I'm sure I should be, but there's a lot to learn.
>>>>>
>>>>> With regards to 2, the elf image, zImage (without the elf
>>>>>
>>>>>
>> extension),
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> is
>>>>
>>>>
>>>>
>>>>
>>>>> located in arch/powerpc/boot.
>>>>>
>>>>> You can make a SystemACE file from that elf image just as you did
>>>>>
> in
>
>>>>> arch/ppc. We have a default device tree file, ml405.dts, in the
>>>>> arch/powerpc/boot/dts directory for our ml405 board. The kernel
>>>>> configuration has a config, DEVICE_TREE, that specifies the name of
>>>>>
>>>>>
>>>>>
>>>>>
>>>> the
>>>>
>>>>
>>>>
>>>>
>>>>> device tree file. I normally compile the device tree into the
>>>>>
> kernel
>
>>>>> which is the default build, make ARCH=powerpc zImage. That image
>>>>>
>>>>>
>> does
>>
>>
>>>>> not require a boot loader.
>>>>>
>>>>> I inserted the text below from a document that I have about
>>>>>
> building
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> the
>>>>
>>>>
>>>>
>>>>
>>>>> arch/ppc and arch/powerpc kernels.
>>>>>
>>>>> Hope that helps,
>>>>> John
>>>>>
>>>>>
>>>>> Notation
>>>>>
>>>>> The phrase "<ppc or powerpc>" is used throughput the text and means
>>>>>
>>>>>
>>>>>
>>>>>
>>>> that
>>>>
>>>>
>>>>
>>>>
>>>>> one or the other, "ppc" or "powerpc" is to be typed depending on
>>>>>
> the
>
>>>>> architecture you are building.
>>>>>
>>>>> Commands that are used in a bash shell are preceded by ">".
>>>>>
>>>>> Getting Ready To Build the Kernel
>>>>>
>>>>> This assumes you installed the ELDK tools and assumes you'll be
>>>>>
>>>>>
>> using
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> a
>>>>
>>>>
>>>>
>>>>
>>>>> bash shell.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> bash
>>>>>> export CROSS_COMPILE=ppc_4xx-
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Setting Up the Kernel Tree
>>>>>
>>>>> If you have previously built this kernel for another architecture,
>>>>>
>>>>>
>>>>>
>>> ppc
>>>
>>>
>>>
>>>>> or powerpc, then the tree needs to be setup correctly for the new
>>>>> architecture. Assuming you have not previously built it, this does
>>>>>
>>>>>
>>>>>
>>>>>
>>>> not
>>>>
>>>>
>>>>
>>>>
>>>>> need to be done.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> make ARCH=<ppc or powerpc> mrproper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Configuring the Kernel
>>>>>
>>>>> The kernel should be configured to run on the ML405 or ML507 board
>>>>>
>>>>>
>>>>>
>>>>>
>>>> from
>>>>
>>>>
>>>>
>>>>
>>>>> Xilinx.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> make ARCH=<ppc or powerpc> ml405_defconfig
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> or
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> make ARCH=<ppc or powerpc> ml507_defconfig
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Building the Kernel
>>>>>
>>>>> The following command will build the Linux kernel assuming you are
>>>>>
>>>>>
>> in
>>
>>
>>>>> the root directory of the kernel. The root directory of the kernel
>>>>>
>>>>>
>>>>>
>>>>>
>>>> from
>>>>
>>>>
>>>>
>>>>
>>>>> the Xilinx Git tree is linux-2.6-xlnx. An elf file, zImage.elf, is
>>>>> created in the arch/ppc/boot/images directory for ppc architecture.
>>>>>
>>>>>
>>>>>
>>> An
>>>
>>>
>>>
>>>>> elf file, zImage, is created in the the arch/powerpc/boot directory
>>>>>
>>>>>
>>>>>
>>>>>
>>>> for
>>>>
>>>>
>>>>
>>>>
>>>>> the powerpc architecture.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> make ARCH=<ppc or powerpc> zImage
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Building the Kernel With Ramdisk
>>>>>
>>>>> A ram disk image, a file named *.gz, must be placed into the
>>>>> arch/ppc/boot/images or arch/powerpc/boot directory, depending on
>>>>>
>>>>>
>> the
>>
>>
>>>>> architecture, prior to building the kernel.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> make ARCH=<ppc or powerpc> zImage.initrd
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> An elf file, zImage.initrd.elf, is created in arch/ppc/boot/images
>>>>> directory for the ppc architecture. An elf file file,
>>>>>
> zImage.initrd,
>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> is
>>>>
>>>>
>>>>
>>>>
>>>>> created in arch/powerpc/boot directory for the powerpc
>>>>>
> architecture.
>
>>>>> Generating An Ace File
>>>>>
>>>>> The elf file generated for the kernel and the bit stream can be
>>>>>
>>>>>
>>>>>
>>>>>
>>>> combined
>>>>
>>>>
>>>>
>>>>
>>>>> to create an ACE file for compact flash. The following assumes a
>>>>>
>>>>>
>>>>>
>>> bash
>>>
>>>
>>>
>>>>> shell where XMD is accessible and a xilinx probe attached to the
>>>>>
>>>>>
>>>>>
>>> board
>>>
>>>
>>>
>>>>> for which you are generating an ace file.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> xmd -tcl genace.tcl -jprog -target ppc_hw -hw <bit file name> -elf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> <elf
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> file name> -board <ml405 or ml507> -ace <desired ace file name>
>>>>>
>>>>> -----Original Message-----
>>>>> From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
>>>>> [mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org]
>>>>>
>>>>>
>> On
>>
>>
>>>>> Behalf Of Peter Mendham
>>>>> Sent: Tuesday, June 24, 2008 3:02 AM
>>>>> To: linuxppc-embedded@ozlabs.org
>>>>> Subject: Linux on Virtex board with ARCH=powerpc
>>>>>
>>>>> Dear all,
>>>>>
>>>>> I'm trying to boot a 2.6.26-rc6 kernel on a custom Virtex 4 board.
>>>>>
>>>>>
>> I
>>
>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> have used the Xilinx utility to generate a device tree and now want
>>>>>
>>>>>
>>>>>
>>> to
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> generate an image for throwing onto CF for use with a SystemACE
>>>>>
>>>>>
>> (just
>>
>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> like on the the ML3/4xx boards). I don't want to use a bootloader
>>>>>
>>>>>
>> (I
>>
>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> don't really need one). I saw something on this list about
>>>>>
>>>>>
>>>>>
>>>>>
>>>> simpleImage,
>>>>
>>>>
>>>>
>>>>
>>>>> "simple" sounded good to me so I thought I'd try that (or did I
>>>>> misinterpret what this is for?). I also don't want the image to be
>>>>>
>>>>>
>>>>>
>>>>>
>>>> too
>>>>
>>>>
>>>>
>>>>
>>>>> big, I always used to use a zImage under ARCH=ppc. So, two
>>>>>
>>>>>
>> questions,
>>
>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> which hopefully are easy ones:
>>>>> 1. I did what Grant said in a post to this list about simpleImage,
>>>>>
>>>>>
>>>>>
>>> and
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> dumped my dts into arch/powerpc/boot/dts and I called it system.dts
>>>>>
>>>>>
>>>>>
>>>>>
>>>> (for
>>>>
>>>>
>>>>
>>>>
>>>>> now). I then tried to do make simpleImage.system which ran right
>>>>> through to final link then moaned about a missing
>>>>>
> simpleboot-system.
>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>>> Where is this supposed to come from? What am I doing wrong? I
>>>>>
>>>>>
>>>>>
>>>>>
>>>> naively
>>>>
>>>>
>>>>
>>>>
>>>>> tried copying simpleboot.o to simpleboot-system.o and the error
>>>>>
> went
>
>>>>>
>>>>>
>>
>>
>>>>> away. Hmm.
>>>>> 2. I need an ELF to give to my SystemACE file generator. This used
>>>>>
>>>>>
>>>>>
>>> to
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> pop up in arch/ppc/boot/images and be called zImage.elf, which made
>>>>>
>
>
>>>>> sense to me. What's the deal now with powerpc? What should I be
>>>>>
>>>>>
>>>>>
>>>>>
>>>> using?
>>>>
>>>>
>>>>
>>>>
>>>>> Finally, can anyone give me a heads-up on any gotchas with what I'm
>>>>>
>
>
>>>>> trying to do. As you can tell, I don't entirely know what I'm
>>>>>
>>>>>
>> doing,
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> so
>>>>
>>>>
>>>>
>>>>
>>>>> any pointers would be gratefully received.
>>>>>
>>>>> Thanks,
>>>>> -- Peter
>>>>>
>>>>>
>>>>> The University of Dundee is a Scottish Registered Charity, No.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> SC015096.
>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>> This email and any attachments are intended for the sole use of the
>>>>>
>>>>>
>>>>>
>>>>>
>>>> named recipient(s) and contain(s) confidential information that may
>>>>
>>>>
>> be
>>
>>
>>>> proprietary, privileged or copyrighted under applicable law. If you
>>>>
>>>>
>>>>
>>> are
>>>
>>>
>>>
>>>> not the intended recipient, do not read, copy, or forward this email
>>>> message or any attachments. Delete this email message and any
>>>> attachments immediately.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> The University of Dundee is a Scottish Registered Charity, No.
>>>>
>>>>
>>>>
>>> SC015096.
>>>
>>>
>>>
>>>> This email and any attachments are intended for the sole use of the
>>>>
>>>>
>>>>
>>> named recipient(s) and contain(s) confidential information that may
>>>
> be
>
>>> proprietary, privileged or copyrighted under applicable law. If you
>>>
>>>
>> are
>>
>>
>>> not the intended recipient, do not read, copy, or forward this email
>>> message or any attachments. Delete this email message and any
>>> attachments immediately.
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>> The University of Dundee is a Scottish Registered Charity, No.
>>>
>>>
>> SC015096.
>>
>>
>>> This email and any attachments are intended for the sole use of the
>>>
>>>
>> named recipient(s) and contain(s) confidential information that may be
>> proprietary, privileged or copyrighted under applicable law. If you
>>
> are
>
>> not the intended recipient, do not read, copy, or forward this email
>> message or any attachments. Delete this email message and any
>> attachments immediately.
>>
>>
>>>
>>>
>>>
>> The University of Dundee is a Scottish Registered Charity, No.
>>
> SC015096.
>
>>
>>
>> This email and any attachments are intended for the sole use of the
>>
> named recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are
> not the intended recipient, do not read, copy, or forward this email
> message or any attachments. Delete this email message and any
> attachments immediately.
>
>>
>>
>
>
> The University of Dundee is a Scottish Registered Charity, No. SC015096.
>
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
>
The University of Dundee is a Scottish Registered Charity, No. SC015096.
^ permalink raw reply
* Re: Linux on Virtex board with ARCH=powerpc
From: Peter Mendham @ 2008-06-27 15:24 UTC (permalink / raw)
To: Aaron Sells; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <486504DC.9040503@zin-tech.com>
Hi Aaron,
Thanks - you spotted my mistake when I said "the same root fs" - I was
indeed changing inittab to use ttyUL0. For a while I mistakenly had
ttyUL0 on the 16550 system and that showed me init messages (like
"mounting file systems") and then when it was done with the rc scripts
it complained about ttyUL0. With my uartlite system I see none of
that. The early messages go to /dev/console AFAIK, which suggests
there's something a bit more fundamental going on?
Thanks,
-- Peter
Aaron Sells wrote:
> Peter,
>
> Peter Mendham wrote:
>> I now have a new and rather bizarre problem, which maybe you or
>> someone else has met before. I have a simple FPGA design with
>> memory, a sysace and a uart16550 on an ML405 (I've put my hardware to
>> one side for the moment). It works just fine. If I swap the
>> uart16550 for a uartlite (remaking the kernel with the correct device
>> tree) I see all the boot messages and the kernel seems to start OK,
>> the root partition is mounted but then I see nothing from
>> /sbin/init. This is the same root fs that I was using with the
>> uart16550 example I just mentioned. So it's a known good root fs,
>> but it doesn't appear to be able to output to /dev/console when I
>> have a uartlite instead of a uart16550. I have selected console
>> support for uartlite. Any ideas?
>>
>
> I had to modify /etc/inittab on my OpenEmbedded rootfs and replace
> ttyS0 with ttyUL0 to get the console working with uartlite on my ML403.
>
>> Thanks,
>> -- Peter
>>
>
> Regards,
> Aaron
>
The University of Dundee is a Scottish Registered Charity, No. SC015096.
^ permalink raw reply
* Re: Linux on Virtex board with ARCH=powerpc
From: Aaron Sells @ 2008-06-27 15:18 UTC (permalink / raw)
To: Peter Mendham; +Cc: John Linn, linuxppc-embedded
In-Reply-To: <4864DD66.5040909@computing.dundee.ac.uk>
Peter,
Peter Mendham wrote:
> I now have a new and rather bizarre problem, which maybe you or someone
> else has met before. I have a simple FPGA design with memory, a sysace
> and a uart16550 on an ML405 (I've put my hardware to one side for the
> moment). It works just fine. If I swap the uart16550 for a uartlite
> (remaking the kernel with the correct device tree) I see all the boot
> messages and the kernel seems to start OK, the root partition is mounted
> but then I see nothing from /sbin/init. This is the same root fs that I
> was using with the uart16550 example I just mentioned. So it's a known
> good root fs, but it doesn't appear to be able to output to /dev/console
> when I have a uartlite instead of a uart16550. I have selected console
> support for uartlite. Any ideas?
>
I had to modify /etc/inittab on my OpenEmbedded rootfs and replace ttyS0
with ttyUL0 to get the console working with uartlite on my ML403.
> Thanks,
> -- Peter
>
Regards,
Aaron
^ permalink raw reply
* [PATCH] powerpc: Add 83xx and 86xx to 6xx Multiplatform
From: Kumar Gala @ 2008-06-27 16:36 UTC (permalink / raw)
To: linuxppc-dev
There isn't any reason at this point that we can't build 83xx & 86xx support
in with the other 6xx based boards. Twiddle the Kconfigs to allow this.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/83xx/Kconfig | 10 ++++++----
arch/powerpc/platforms/86xx/Kconfig | 16 +++++++++++-----
arch/powerpc/platforms/Kconfig | 14 --------------
3 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index fe75b2a..27d9bf8 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -1,10 +1,12 @@
-menuconfig MPC83xx
- bool "83xx Board Type"
- depends on PPC_83xx
+menuconfig PPC_83xx
+ bool "83xx-based boards"
+ depends on 6xx && PPC_MULTIPLATFORM
select PPC_UDBG_16550
select PPC_INDIRECT_PCI
+ select FSL_SOC
+ select IPIC
-if MPC83xx
+if PPC_83xx
config MPC831x_RDB
bool "Freescale MPC831x RDB"
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 053f49a..80a81e0 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -1,7 +1,13 @@
-choice
- prompt "86xx Board Type"
- depends on PPC_86xx
- default MPC8641_HPCN
+config PPC_86xx
+menuconfig PPC_86xx
+ bool "86xx-based boards"
+ depends on 6xx && PPC_MULTIPLATFORM
+ select FSL_SOC
+ select ALTIVEC
+ help
+ The Freescale E600 SoCs have 74xx cores.
+
+if PPC_86xx
config MPC8641_HPCN
bool "Freescale MPC8641 HPCN"
@@ -24,7 +30,7 @@ config MPC8610_HPCD
help
This option enables support for the MPC8610 HPCD board.
-endchoice
+endif
config MPC8641
bool
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 87454c5..3e2b645 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -16,20 +16,6 @@ config PPC_82xx
bool "Freescale 82xx"
depends on 6xx
-config PPC_83xx
- bool "Freescale 83xx"
- depends on 6xx
- select FSL_SOC
- select MPC83xx
- select IPIC
-
-config PPC_86xx
- bool "Freescale 86xx"
- depends on 6xx
- select FSL_SOC
- select ALTIVEC
- help
- The Freescale E600 SoCs have 74xx cores.
endchoice
config CLASSIC32
--
1.5.5.1
^ permalink raw reply related
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