* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: David Miller @ 2011-01-28 19:59 UTC (permalink / raw)
To: scottwood; +Cc: netdev, David.Laight, linuxppc-dev
In-Reply-To: <20110128105610.4a518456@udp111988uds.am.freescale.net>
From: Scott Wood <scottwood@freescale.com>
Date: Fri, 28 Jan 2011 10:56:10 -0600
> On Fri, 28 Jan 2011 09:10:46 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
>
>>
>> > + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
>> > + && ((unsigned long)fcb % 0x20) > 0x18)) {
>>
>> You need to check the generated code, but I think you need:
>>
>> if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
>> && unlikely(((unsigned long)fcb % 0x20) > 0x18))
>>
>> ie unlikely() around both the primitive comparisons.
>
> Is the first condition actually unlikely? If you've got affected
> hardware, you'll hit it every time.
>
> If packets with the problematic alignment are rare, seems like it'd be
> better to check that first.
In cases like this gfar_has_errata() case, better to leave it's
likelyhood unmarked.
And yes, since it's cheaper, checking the alignment should be done
first.
^ permalink raw reply
* PCIe end-point on FPGA doesn't show up on PCI bus when configured
From: Matias Garcia @ 2011-01-28 18:37 UTC (permalink / raw)
To: linuxppc-dev
I'm running a vanilla linux 2.6.37 kernel on a Freescale P2020 dual-core
processor, and have the following conundrum: I configure the FPGA which
brings up a PCIe interface to the processor. I scan both PCI buses on
the system (I believe the second bus is behind the Freescale integrated
bridge on the first), and it doesn't show up. I initiate a reset on the
processor, and both U-boot and Linux now see the FPGA PCI device at
0000:01:00.00. I've noticed some of the memory mappings in the PCI
bridge windows are different between the two boot sequences. I've tried
all manner of pci calls (including the pcibios_fixup routines) on the
bridge device (including removing and re-scanning it), and on bus 1,
which is otherwise empty, to no avail. Following are some debug listings
from dmesg; any help/ideas in tracking down the problem (hardware or
software) is greatly appreciated.
#Boot without FPGA configured:
<snip>
Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number: 0->255
PCI host bridge /pcie@8ff70a000 ranges:
MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
/pcie@8ff70a000: PCICSRBAR @ 0xfff00000
/pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
Adjusting the memory map could reduce unnecessary bounce buffering.
/pcie@8ff70a000: DMA window size is 0x80000000
MPC85xx RDB board from Freescale Semiconductor
<...>
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref]
(disabled)
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
#Reset with FPGA configured:
<snip>
Found FSL PCI host bridge at 0x00000008ff70a000. Firmware bus number: 0->255
PCI host bridge /pcie@8ff70a000 ranges:
MEM 0x0000000880000000..0x000000088fffffff -> 0x0000000080000000
IO 0x00000008a0000000..0x00000008a000ffff -> 0x0000000000000000
/pcie@8ff70a000: PCICSRBAR @ 0xfff00000
/pcie@8ff70a000: WARNING: Outbound window cfg leaves gaps in memory map.
Adjusting the memory map could reduce unnecessary bounce buffering.
/pcie@8ff70a000: DMA window size is 0x80000000
MPC85xx RDB board from Freescale Semiconductor
<...>
PCI: Probing PCI hardware
pci 0000:00:00.0: [1957:0070] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
pci 0000:01:00.0: [1172:0004] type 0 class 0x001000
pci 0000:01:00.0: reg 10: [mem 0x80000000-0x80ffffff]
pci 0000:01:00.0: reg 14: [mem 0x81000000-0x81ffffff]
pci 0000:01:00.0: reg 18: [mem 0x82000000-0x82ffffff]
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x80000000-0x82ffffff]
pci 0000:00:00.0: bridge window [mem 0x10000000-0x000fffff pref]
(disabled)
irq: irq 0 on host /soc@8ff700000/pic@40000 mapped to virtual irq 16
PCI 0000:00 Cannot reserve Legacy IO [io 0xffbed000-0xffbedfff]
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xffbed000-0xffbfcfff]
pci 0000:00:00.0: bridge window [mem 0x880000000-0x88fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:00: resource 1 [mem 0x880000000-0x88fffffff]
pci_bus 0000:01: resource 0 [io 0xffbed000-0xffbfcfff]
pci_bus 0000:01: resource 1 [mem 0x880000000-0x88fffffff]
Cheers,
Matias
--
*Matias Garcia*
/Embedded Software Developer/
Ross Video | Live Production Technology
www.rossvideo.com <http://www.rossvideo.com>
+1 (613) 228 1198 x4264
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: Scott Wood @ 2011-01-28 16:56 UTC (permalink / raw)
To: David Laight; +Cc: netdev, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC2E@saturn3.aculab.com>
On Fri, 28 Jan 2011 09:10:46 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
>
> > + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
> > + && ((unsigned long)fcb % 0x20) > 0x18)) {
>
> You need to check the generated code, but I think you need:
>
> if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
> && unlikely(((unsigned long)fcb % 0x20) > 0x18))
>
> ie unlikely() around both the primitive comparisons.
Is the first condition actually unlikely? If you've got affected
hardware, you'll hit it every time.
If packets with the problematic alignment are rare, seems like it'd be
better to check that first.
-Scott
^ permalink raw reply
* Need help for USB OTG feature for Canyonlands PPC460EX Board
From: sunny bhayani @ 2011-01-28 13:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
Hi All,
I am trying to enable the USB DWC OTG feature for Canyonlands PPC460EX
Board, and am using the 2.6.30 kernel from denx.
Now the issue is I am selecting the "USB Gadget" feature from the kernel
menuconfig, but the kernel log only shows,
dwc_otg: version 2.60a 22-NOV-2006
The probe() function in "drivers/usb/gadged/dwc_otg/dwc_otg_driver.c" is not
getting called. So I am not getting the following kernel boot messages:
dwc_otg: Shared Tx FIFO mode
dwc_otg: Using Slave mode
dwc_otg dwc_otg.0: DWC OTG Controller
dwc_otg dwc_otg.0: new USB bus registered, assigned bus number 2
dwc_otg dwc_otg.0: irq 28, io mem 0x00000000
dwc_otg: dwc_otg_core_host_init: Unable to clear halt on channel 1
dwc_otg: Init: Port Power? op_state=4
Can you please let me know, what might be the problem.
Regards,
Sunny Bhayani
+91-88921-80558
[-- Attachment #2: Type: text/html, Size: 1584 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: Coly Li @ 2011-01-28 11:02 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeremy Fitzhardinge, Coly Li, David Daney, linux-kernel,
Yong Zhang, David Laight, Wang Cong, linuxppc-dev
In-Reply-To: <m31v3xxrlz.fsf@redhat.com>
On 2011年01月28日 18:14, Andreas Schwab Wrote:
> "David Laight"<David.Laight@ACULAB.COM> writes:
>
>> Also, as (I think) in some of the generated code quoted,
>> use of __builtin_expect() with a boolean expression can
>> force some versions of gcc to generate the integer
>> value of the expression
>
> That's more likely a side effect of the definition of likely/unlikely:
> they expand to !!(x).
>
It seems whether or not using unlikely() inside arch implemented BUG_ON() is arch dependent. Maybe a reasonable method
to use BUG_ON() is,
1) do not explicitly use unlikely() when using macro BUG_ON().
2) whether or not using unlikely() inside BUG_ON(), it depends on the implementation of BUG_ON(), including arch
implementation.
So from current feed back, doing "unlikely() optimization" here doesn't make anything better.
Thanks for all of your feed back :-)
--
Coly Li
^ permalink raw reply
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: Andreas Schwab @ 2011-01-28 10:14 UTC (permalink / raw)
To: David Laight
Cc: Jeremy Fitzhardinge, Coly Li, David Daney, linux-kernel,
Yong Zhang, Wang Cong, linuxppc-dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AC2D__37237.0892241181$1296205746$gmane$org@saturn3.aculab.com>
"David Laight" <David.Laight@ACULAB.COM> writes:
> Also, as (I think) in some of the generated code quoted,
> use of __builtin_expect() with a boolean expression can
> force some versions of gcc to generate the integer
> value of the expression
That's more likely a side effect of the definition of likely/unlikely:
they expand to !!(x).
Andreas.
--
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
^ permalink raw reply
* RE: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on oldercontrollers
From: David Laight @ 2011-01-28 9:10 UTC (permalink / raw)
Cc: netdev, linuxppc-dev
In-Reply-To: <640295.36173.qm@web37608.mail.mud.yahoo.com>
=20
> + if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
> + && ((unsigned long)fcb % 0x20) > 0x18)) {
You need to check the generated code, but I think you need:
if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
&& unlikely(((unsigned long)fcb % 0x20) > 0x18))
ie unlikely() around both the primitive comparisons.
David
^ permalink raw reply
* RE: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: David Laight @ 2011-01-28 9:05 UTC (permalink / raw)
To: David Daney, Coly Li
Cc: Wang Cong, Jeremy Fitzhardinge, linuxppc-dev, linux-kernel,
Yong Zhang
In-Reply-To: <4D41B213.4070606@caviumnetworks.com>
=20
> > +#define __BUG_ON(x) do { \
> > if (__builtin_constant_p(x)) { \
> > if (x) \
> > BUG(); \
> > @@ -85,6 +86,8 @@
> > } \
> > } while (0)
> >
> > +#define BUG_ON(x) __BUG_ON(unlikely(x))
> > +
>From my experiments, adding an 'unlikely' at that point isn't
enough for non-trivial conditions - so its presence will
give a false sense the the optimisation is present!
In particular 'if (unlikely(x && y))' needs to be
'if (unlikely(x) && unlikely(y))' in order to avoid
mispredicted branches when 'x' is false.
Also, as (I think) in some of the generated code quoted,
use of __builtin_expect() with a boolean expression can
force some versions of gcc to generate the integer
value of the expression - rather than just selecting the
branch instructions that statically predict the
normal code path.
Sometimes I've also also had to add an asm() statement
that generates no code in order to actually force a
forwards branch (so it has something to place at the
target).
(I've been counting clocks ....)
David
^ permalink raw reply
* [PATCH v2] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Alex Dubov @ 2011-01-28 4:37 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: netdev, linuxppc-dev, davem, mlcreech
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,=0A=
older revisions of gianfar controllers will be unable to calculate a TCP/UD=
P=0Apacket checksum for some alignments of the appropriate FCB. This patch =
checks=0Afor FCB alignment on such controllers and falls back to software c=
hecksumming=0Aif the alignment is known to be bad.=0A=0ASigned-off-by: Alex=
Dubov <oakad@yahoo.com>=0A---=0AChanges for v2:=0A - Make indentation sl=
ightly more consistent.=0A - Replace bizarre switch-based condition with =
plain boring one.=0A=0A drivers/net/gianfar.c | 16 ++++++++++++++--=0A dr=
ivers/net/gianfar.h | 1 +=0A 2 files changed, 15 insertions(+), 2 deleti=
ons(-)=0A=0Adiff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c=0Ain=
dex 5ed8f9f..3da19a5 100644=0A--- a/drivers/net/gianfar.c=0A+++ b/drivers/n=
et/gianfar.c=0A@@ -950,6 +950,11 @@ static void gfar_detect_errata(struct g=
far_private *priv)=0A =09=09=09(pvr =3D=3D 0x80861010 && (mod & 0xfff9) =3D=
=3D 0x80c0))=0A =09=09priv->errata |=3D GFAR_ERRATA_A002;=0A =0A+=09/* MPC8=
313 Rev < 2.0, MPC8548 rev 2.0 */=0A+=09if ((pvr =3D=3D 0x80850010 && mod =
=3D=3D 0x80b0 && rev < 0x0020) ||=0A+=09=09=09(pvr =3D=3D 0x80210020 && mod=
=3D=3D 0x8030 && rev =3D=3D 0x0020))=0A+=09=09priv->errata |=3D GFAR_ERRAT=
A_12;=0A+=0A =09if (priv->errata)=0A =09=09dev_info(dev, "enabled errata wo=
rkarounds, flags: 0x%x\n",=0A =09=09=09 priv->errata);=0A@@ -2156,8 +2161,1=
5 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev=
)=0A =09/* Set up checksumming */=0A =09if (CHECKSUM_PARTIAL =3D=3D skb->ip=
_summed) {=0A =09=09fcb =3D gfar_add_fcb(skb);=0A-=09=09lstatus |=3D BD_LFL=
AG(TXBD_TOE);=0A-=09=09gfar_tx_checksum(skb, fcb);=0A+=09=09/* as specified=
by errata */=0A+=09=09if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)=
=0A+=09=09=09 && ((unsigned long)fcb % 0x20) > 0x18)) {=0A+=09=09=09__s=
kb_pull(skb, GMAC_FCB_LEN);=0A+=09=09=09skb_checksum_help(skb);=0A+=09=09} =
else {=0A+=09=09=09lstatus |=3D BD_LFLAG(TXBD_TOE);=0A+=09=09=09gfar_tx_che=
cksum(skb, fcb);=0A+=09=09}=0A =09}=0A =0A =09if (vlan_tx_tag_present(skb))=
{=0Adiff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h=0Aindex 54d=
e413..ec5d595 100644=0A--- a/drivers/net/gianfar.h=0A+++ b/drivers/net/gian=
far.h=0A@@ -1039,6 +1039,7 @@ enum gfar_errata {=0A =09GFAR_ERRATA_74=09=09=
=3D 0x01,=0A =09GFAR_ERRATA_76=09=09=3D 0x02,=0A =09GFAR_ERRATA_A002=09=3D =
0x04,=0A+=09GFAR_ERRATA_12=09=09=3D 0x08, /* a.k.a errata eTSEC49 */=0A };=
=0A =0A /* Struct stolen almost completely (and shamelessly) from the FCC e=
net source=0A-- =0A1.7.3.2=0A=0A=0A=0A=0A
^ permalink raw reply
* AUTO: Michael Barry is out of the office (returning 08/02/2011)
From: Michael Barry @ 2011-01-28 4:00 UTC (permalink / raw)
To: linuxppc-dev
I am out of the office until 08/02/2011.
Note: This is an automated response to your message "Linuxppc-dev Digest,
Vol 77, Issue 92" sent on 27/1/11 20:32:14.
This is the only notification you will receive while this person is away.
^ permalink raw reply
* Re: [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Alex Dubov @ 2011-01-28 2:43 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, davem, mlcreech
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
> > -=A0=A0=A0 =A0=A0=A0=0A> gfar_tx_checksum(skb, fcb);=0A> > +=A0=A0=A0 =
=A0=A0=A0 switch=0A> (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))=0A> >=
+=A0=A0=A0 =A0=A0=A0=0A> =A0=A0=A0 ? 1 : 0) {=0A> =0A> The switch construc=
tion is quite bizarre. ;-) Why not=0A> =0A=0AMy testing shows that even on =
broken chips unaligned packets are quite rare=0A(only some SYN packets seem=
to be affected). So I tried to leave the=0Achecksum offload path as the mo=
st preferred one.=0A=0A=0A=0A
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
From: Meador Inge @ 2011-01-27 23:50 UTC (permalink / raw)
To: Yoder Stuart-B08248
Cc: Blanchard, Hollis, Wood Scott-B07421,
devicetree-discuss@lists.ozlabs.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <9F6FE96B71CF29479FF1CDC8046E150307A5C8@039-SN1MPN1-004.039d.mgd.msft.net>
On 01/20/2011 09:50 AM, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Meador Inge [mailto:meador_inge@mentor.com]
>> Sent: Wednesday, January 19, 2011 6:08 PM
>> To: Yoder Stuart-B08248
>> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; devicetree-
>> discuss@lists.ozlabs.org; Blanchard, Hollis
>> Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding
>>
>> On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote:
>>>
>>>> +** Optional properties:
>>>> +
>>>> + - no-reset : The presence of this property indicates that the MPIC
>>>> + should not be reset during runtime initialization.
>>>> + - protected-sources : Specifies a list of interrupt sources that
>>>> + are not
>>>> + available for use and whose corresponding
>>>> + vectors
>>>> + should not be initialized. A typical use
>>>> + case for
>>>> + this property is in AMP systems where multiple
>>>> + independent operating systems need to share
>>>> + the MPIC
>>>> + without clobbering each other.
>>>
>>> Is "protected-sources" really needed for AMP systems to tell the OSes
>>> not to clobber each other? Won't each OS be given a device tree with
>>> only its interrupt sources? ...so you know what you are allowed to
>>> touch.
>>
>> This was discussed a little bit already [1, 2]. The MPIC driver currently
>> initializes the VECPRI register for all interrupt sources, which can lead
>> to the aforementioned clobbering.
>
> For sources that are protected and not to be touched, it seems
> that the other need is for the OS to know (be guaranteed?) that
> those sources have been put in state where the source is masked
> or directed to other cores. You can't have interrupts occurring
> on sources that you are not allowed to initialize.
>
> So the "no-reset" property could potentially cover this as well-- if it was
> defined to mean "don't reset the mpic" and boot firmware has put all sources
> in a sane initial state. And we wouldn't need the "protected-sources"
> property any longer.
>
This seems reasonable to me. If "no-reset" is there, then we will not
reset the MPIC and *only* sources explicitly listed in "interrupts"
properties are up for any sort of initialization (e.g. the VECPRI init).
If "no-reset" is not there, then anything is free game.
In terms of implementation, I think we can (1) pull the protected
sources code, (2) keep the VECPRI initialization in 'mpic_init' from
happening when "no-reset" is present, and (3) "lazily" perform the
VECPRI initialization in 'mpic_host_map' (this way only sources
mentioned in the device tree are initialized).
I will send out a patch with these updates tomorrow. I also CC'd Ben,
who wrote the original protected sources work, to make sure something
about the original use case is not being missed.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* Re: [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: David Miller @ 2011-01-27 22:23 UTC (permalink / raw)
To: cbouatmailru; +Cc: linuxppc-dev, mlcreech, oakad
In-Reply-To: <20110127095100.GA5411@oksana.dev.rtsoft.ru>
Please CC: netdev on future submissions of this patch, otherwise I
won't see it in my queue.
^ permalink raw reply
* [PATCH] powerpc: fix memory limits when starting at a non-zero address
From: Scott Wood @ 2011-01-27 20:30 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
memblock_enforce_memory_limit() takes the desired maximum quantity of memory
to end up with, not an address above which memory will not be used.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/prom.c | 2 +-
arch/powerpc/mm/init_32.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 7185f0d..05b7139 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -97,7 +97,7 @@ static void __init move_device_tree(void)
start = __pa(initial_boot_params);
size = be32_to_cpu(initial_boot_params->totalsize);
- if ((memory_limit && (start + size) > memory_limit) ||
+ if ((memory_limit && (start + size) > PHYSICAL_START + memory_limit) ||
overlaps_crashkernel(start, size)) {
p = __va(memblock_alloc(size, PAGE_SIZE));
memcpy(p, initial_boot_params, size);
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 742da43..d65b591 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -148,7 +148,7 @@ void __init MMU_init(void)
lowmem_end_addr = memstart_addr + total_lowmem;
#ifndef CONFIG_HIGHMEM
total_memory = total_lowmem;
- memblock_enforce_memory_limit(lowmem_end_addr);
+ memblock_enforce_memory_limit(total_lowmem);
memblock_analyze();
#endif /* CONFIG_HIGHMEM */
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: David Daney @ 2011-01-27 20:32 UTC (permalink / raw)
To: Scott Wood
Cc: Jeremy Fitzhardinge, Coly Li, linux-kernel, Yong Zhang, Wang Cong,
linuxppc-dev
In-Reply-To: <20110127140420.2c727f36@udp111988uds.am.freescale.net>
On 01/27/2011 12:04 PM, Scott Wood wrote:
> On Thu, 27 Jan 2011 09:57:39 -0800
> David Daney<ddaney@caviumnetworks.com> wrote:
>
>> On 01/27/2011 04:12 AM, Coly Li wrote:
>>> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
>>> index 065c590..10889a6 100644
>>> --- a/arch/powerpc/include/asm/bug.h
>>> +++ b/arch/powerpc/include/asm/bug.h
>>> @@ -2,6 +2,7 @@
>>> #define _ASM_POWERPC_BUG_H
>>> #ifdef __KERNEL__
>>>
>>> +#include<linux/compiler.h>
>>> #include<asm/asm-compat.h>
>>>
>>> /*
>>> @@ -71,7 +72,7 @@
>>> unreachable(); \
>>> } while (0)
>>>
>>> -#define BUG_ON(x) do { \
>>> +#define __BUG_ON(x) do { \
>>> if (__builtin_constant_p(x)) { \
>>> if (x) \
>>> BUG(); \
>>> @@ -85,6 +86,8 @@
>>> } \
>>> } while (0)
>>>
>>> +#define BUG_ON(x) __BUG_ON(unlikely(x))
>>> +
>>
>> This is the same type of frobbing you were trying to do to MIPS.
>>
>> I will let the powerpc maintainers weigh in on it, but my opinion is
>> that, as with MIPS, BUG_ON() is expanded to a single machine
>> instruction, and this unlikely() business will not change the generated
>> code in any useful way. It is thus gratuitous code churn and
>> complexification.
>
> What about just doing this:
>
> #define BUG() __builtin_trap()
>
> #define BUG_ON(x) do { \
> if (x) \
> BUG(); \
> } while (0)
>
> GCC should produce better code than forcing it into twnei. A simple
> BUG_ON(x != y) currently generates something like this (GCC 4.3):
>
> xor r0,r11,r0
> addic r10,r0,-1
> subfe r9,r10,r0
> twnei r9,0
>
> Or this (GCC 4.5):
>
> xor r0,r11,r0
> cntlzw r0,r0
> srwi r0,r0,5
> xori r0,r0,1
> twnei r0,0
>
> Instead of:
>
> twne r0,r11
>
> And if GCC doesn't treat code paths that lead to __builtin_trap() as
> unlikely (which could make a difference with complex expressions,
> even with a conditional trap instruction), that's something that could
> and should be fixed in GCC.
>
> The downside is that GCC says, "The mechanism used may vary from
> release to release so you should not rely on any particular
> implementation." However, some architectures (sparc, m68k, ia64)
> already use __builtin_trap() for this, it seems unlikely that future GCC
> versions would switch away from using the trap instruction[1], and there
> doesn't seem to be a better-defined way to make GCC generate trap
> instructions intelligently.
>
This is good in theory, however powerpc has this _EMIT_BUG_ENTRY
business that wouldn't work with __builtin_trap().
David Daney
> -Scott
>
> [1] A more likely possibility is that an older compiler just generates a
> call to abort() or similar, and later versions implemented trap -- need
> to check what the oldest supported GCC does.
>
^ permalink raw reply
* [PATCH] powerpc: fix pfn_valid() when memory starts at a non-zero address
From: Scott Wood @ 2011-01-27 20:31 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
max_mapnr is a pfn, not an index innto mem_map[]. So don't add
ARCH_PFN_OFFSET a second time.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/include/asm/page.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 53b64be..da4b200 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -101,7 +101,7 @@ extern phys_addr_t kernstart_addr;
#ifdef CONFIG_FLATMEM
#define ARCH_PFN_OFFSET (MEMORY_START >> PAGE_SHIFT)
-#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < (ARCH_PFN_OFFSET + max_mapnr))
+#define pfn_valid(pfn) ((pfn) >= ARCH_PFN_OFFSET && (pfn) < max_mapnr)
#endif
#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
--
1.7.0.4
^ permalink raw reply related
* [PATCH] powerpc/book3e: protect complex macro args in mmu-book3e.h with parens
From: Scott Wood @ 2011-01-27 20:30 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Ran into trouble with this when working on some KVM code.
arch/powerpc/include/asm/mmu-book3e.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-book3e.h b/arch/powerpc/include/asm/mmu-book3e.h
index 8eaed81..17194fc 100644
--- a/arch/powerpc/include/asm/mmu-book3e.h
+++ b/arch/powerpc/include/asm/mmu-book3e.h
@@ -40,8 +40,8 @@
/* MAS registers bit definitions */
-#define MAS0_TLBSEL(x) ((x << 28) & 0x30000000)
-#define MAS0_ESEL(x) ((x << 16) & 0x0FFF0000)
+#define MAS0_TLBSEL(x) (((x) << 28) & 0x30000000)
+#define MAS0_ESEL(x) (((x) << 16) & 0x0FFF0000)
#define MAS0_NV(x) ((x) & 0x00000FFF)
#define MAS0_HES 0x00004000
#define MAS0_WQ_ALLWAYS 0x00000000
@@ -50,12 +50,12 @@
#define MAS1_VALID 0x80000000
#define MAS1_IPROT 0x40000000
-#define MAS1_TID(x) ((x << 16) & 0x3FFF0000)
+#define MAS1_TID(x) (((x) << 16) & 0x3FFF0000)
#define MAS1_IND 0x00002000
#define MAS1_TS 0x00001000
#define MAS1_TSIZE_MASK 0x00000f80
#define MAS1_TSIZE_SHIFT 7
-#define MAS1_TSIZE(x) ((x << MAS1_TSIZE_SHIFT) & MAS1_TSIZE_MASK)
+#define MAS1_TSIZE(x) (((x) << MAS1_TSIZE_SHIFT) & MAS1_TSIZE_MASK)
#define MAS2_EPN 0xFFFFF000
#define MAS2_X0 0x00000040
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: Scott Wood @ 2011-01-27 20:04 UTC (permalink / raw)
To: David Daney
Cc: Jeremy Fitzhardinge, Coly Li, linux-kernel, Yong Zhang, Wang Cong,
linuxppc-dev
In-Reply-To: <4D41B213.4070606@caviumnetworks.com>
On Thu, 27 Jan 2011 09:57:39 -0800
David Daney <ddaney@caviumnetworks.com> wrote:
> On 01/27/2011 04:12 AM, Coly Li wrote:
> > diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
> > index 065c590..10889a6 100644
> > --- a/arch/powerpc/include/asm/bug.h
> > +++ b/arch/powerpc/include/asm/bug.h
> > @@ -2,6 +2,7 @@
> > #define _ASM_POWERPC_BUG_H
> > #ifdef __KERNEL__
> >
> > +#include<linux/compiler.h>
> > #include<asm/asm-compat.h>
> >
> > /*
> > @@ -71,7 +72,7 @@
> > unreachable(); \
> > } while (0)
> >
> > -#define BUG_ON(x) do { \
> > +#define __BUG_ON(x) do { \
> > if (__builtin_constant_p(x)) { \
> > if (x) \
> > BUG(); \
> > @@ -85,6 +86,8 @@
> > } \
> > } while (0)
> >
> > +#define BUG_ON(x) __BUG_ON(unlikely(x))
> > +
>
> This is the same type of frobbing you were trying to do to MIPS.
>
> I will let the powerpc maintainers weigh in on it, but my opinion is
> that, as with MIPS, BUG_ON() is expanded to a single machine
> instruction, and this unlikely() business will not change the generated
> code in any useful way. It is thus gratuitous code churn and
> complexification.
What about just doing this:
#define BUG() __builtin_trap()
#define BUG_ON(x) do { \
if (x) \
BUG(); \
} while (0)
GCC should produce better code than forcing it into twnei. A simple
BUG_ON(x != y) currently generates something like this (GCC 4.3):
xor r0,r11,r0
addic r10,r0,-1
subfe r9,r10,r0
twnei r9,0
Or this (GCC 4.5):
xor r0,r11,r0
cntlzw r0,r0
srwi r0,r0,5
xori r0,r0,1
twnei r0,0
Instead of:
twne r0,r11
And if GCC doesn't treat code paths that lead to __builtin_trap() as
unlikely (which could make a difference with complex expressions,
even with a conditional trap instruction), that's something that could
and should be fixed in GCC.
The downside is that GCC says, "The mechanism used may vary from
release to release so you should not rely on any particular
implementation." However, some architectures (sparc, m68k, ia64)
already use __builtin_trap() for this, it seems unlikely that future GCC
versions would switch away from using the trap instruction[1], and there
doesn't seem to be a better-defined way to make GCC generate trap
instructions intelligently.
-Scott
[1] A more likely possibility is that an older compiler just generates a
call to abort() or similar, and later versions implemented trap -- need
to check what the oldest supported GCC does.
^ permalink raw reply
* Re: [PATCH 2/7] PowerPC: add unlikely() to BUG_ON()
From: David Daney @ 2011-01-27 17:57 UTC (permalink / raw)
To: Coly Li
Cc: Wang Cong, Jeremy Fitzhardinge, linuxppc-dev, linux-kernel,
Yong Zhang
In-Reply-To: <1296130356-29896-3-git-send-email-bosong.ly@taobao.com>
Why not also CC the PPC maintainers as well? I am not certain, but I
think they may be reached at:
linuxppc-dev@lists.ozlabs.org
On 01/27/2011 04:12 AM, Coly Li wrote:
> Current BUG_ON() arch/powerpc/include/asm/bug.h does not use unlikely(),
> in order to get better branch predict result, source code may have to call
> BUG_ON() with unlikely() explicitly. This is not a suggested method
> to use BUG_ON().
>
> This patch adds unlikely() inside BUG_ON implementation on PPC
> code, callers can use BUG_ON without explicit unlikely() now.
>
> I don't have any PPC hardware to compile and test this fix, any feedback
> of this patch is welcome.
>
> Signed-off-by: Coly Li<bosong.ly@taobao.com>
> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> Cc: David Daney<ddaney@caviumnetworks.com>
> Cc: Wang Cong<xiyou.wangcong@gmail.com>
> Cc: Yong Zhang<yong.zhang0@gmail.com>
> diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
> index 065c590..10889a6 100644
> --- a/arch/powerpc/include/asm/bug.h
> +++ b/arch/powerpc/include/asm/bug.h
> @@ -2,6 +2,7 @@
> #define _ASM_POWERPC_BUG_H
> #ifdef __KERNEL__
>
> +#include<linux/compiler.h>
> #include<asm/asm-compat.h>
>
> /*
> @@ -71,7 +72,7 @@
> unreachable(); \
> } while (0)
>
> -#define BUG_ON(x) do { \
> +#define __BUG_ON(x) do { \
> if (__builtin_constant_p(x)) { \
> if (x) \
> BUG(); \
> @@ -85,6 +86,8 @@
> } \
> } while (0)
>
> +#define BUG_ON(x) __BUG_ON(unlikely(x))
> +
This is the same type of frobbing you were trying to do to MIPS.
I will let the powerpc maintainers weigh in on it, but my opinion is
that, as with MIPS, BUG_ON() is expanded to a single machine
instruction, and this unlikely() business will not change the generated
code in any useful way. It is thus gratuitous code churn and
complexification.
David Daney
> #define __WARN_TAINT(taint) do { \
> __asm__ __volatile__( \
> "1: twi 31,0,0\n" \
^ permalink raw reply
* Re: FSL DMA engine transfer to PCI memory
From: Ira W. Snyder @ 2011-01-27 16:34 UTC (permalink / raw)
To: Felix Radensky; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <4D412D93.6040506@embedded-sol.com>
On Thu, Jan 27, 2011 at 10:32:19AM +0200, Felix Radensky wrote:
> Hi Ira,
>
> On 01/25/2011 06:29 PM, Ira W. Snyder wrote:
> > On Tue, Jan 25, 2011 at 04:32:02PM +0200, Felix Radensky wrote:
> >> Hi Ira,
> >>
> >> On 01/25/2011 02:18 AM, Ira W. Snyder wrote:
> >>> On Tue, Jan 25, 2011 at 01:39:39AM +0200, Felix Radensky wrote:
> >>>> Hi Ira, Scott
> >>>>
> >>>> On 01/25/2011 12:26 AM, Ira W. Snyder wrote:
> >>>>> On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'm trying to use FSL DMA engine to perform DMA transfer from
> >>>>>> memory buffer obtained by kmalloc() to PCI memory. This is on
> >>>>>> custom board based on P2020 running linux-2.6.35. The PCI
> >>>>>> device is Altera FPGA, connected directly to SoC PCI-E controller.
> >>>>>>
> >>>>>> 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device
> >>>>>> 0004 (rev 01)
> >>>>>> Subsystem: Altera Corporation Unknown device 0004
> >>>>>> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> >>>>>> ParErr- Stepping- SERR- FastB2B-
> >>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
> >>>>>> >TAbort-<TAbort-<MAbort->SERR-<PERR-
> >>>>>> Interrupt: pin A routed to IRQ 16
> >>>>>> Region 0: Memory at c0000000 (32-bit, non-prefetchable)
> >>>>>> [size=128K]
> >>>>>> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
> >>>>>> Queue=0/0 Enable-
> >>>>>> Address: 0000000000000000 Data: 0000
> >>>>>> Capabilities: [78] Power Management version 3
> >>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> >>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> >>>>>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> >>>>>> Capabilities: [80] Express Endpoint IRQ 0
> >>>>>> Device: Supported: MaxPayload 256 bytes, PhantFunc 0,
> >>>>>> ExtTag-
> >>>>>> Device: Latency L0s<64ns, L1<1us
> >>>>>> Device: AtnBtn- AtnInd- PwrInd-
> >>>>>> Device: Errors: Correctable- Non-Fatal- Fatal-
> >>>>>> Unsupported-
> >>>>>> Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> >>>>>> Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
> >>>>>> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1
> >>>>>> Link: Latency L0s unlimited, L1 unlimited
> >>>>>> Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
> >>>>>> Link: Speed 2.5Gb/s, Width x1
> >>>>>> Capabilities: [100] Virtual Channel
> >>>>>>
> >>>>>>
> >>>>>> I can successfully writel() to PCI memory via address obtained from
> >>>>>> pci_ioremap_bar().
> >>>>>> Here's my DMA transfer routine
> >>>>>>
> >>>>>> static int dma_transfer(struct dma_chan *chan, void *dst, void *src,
> >>>>>> size_t len)
> >>>>>> {
> >>>>>> int rc = 0;
> >>>>>> dma_addr_t dma_src;
> >>>>>> dma_addr_t dma_dst;
> >>>>>> dma_cookie_t cookie;
> >>>>>> struct completion cmp;
> >>>>>> enum dma_status status;
> >>>>>> enum dma_ctrl_flags flags = 0;
> >>>>>> struct dma_device *dev = chan->device;
> >>>>>> struct dma_async_tx_descriptor *tx = NULL;
> >>>>>> unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS);
> >>>>>>
> >>>>>> dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE);
> >>>>>> if (dma_mapping_error(dev->dev, dma_src)) {
> >>>>>> printk(KERN_ERR "Failed to map src for DMA\n");
> >>>>>> return -EIO;
> >>>>>> }
> >>>>>>
> >>>>>> dma_dst = (dma_addr_t)dst;
> >>>>>>
> >>>>>> flags = DMA_CTRL_ACK |
> >>>>>> DMA_COMPL_SRC_UNMAP_SINGLE |
> >>>>>> DMA_COMPL_SKIP_DEST_UNMAP |
> >>>>>> DMA_PREP_INTERRUPT;
> >>>>>>
> >>>>>> tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags);
> >>>>>> if (!tx) {
> >>>>>> printk(KERN_ERR "%s: Failed to prepare DMA transfer\n",
> >>>>>> __FUNCTION__);
> >>>>>> dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE);
> >>>>>> return -ENOMEM;
> >>>>>> }
> >>>>>>
> >>>>>> init_completion(&cmp);
> >>>>>> tx->callback = dma_callback;
> >>>>>> tx->callback_param =&cmp;
> >>>>>> cookie = tx->tx_submit(tx);
> >>>>>>
> >>>>>> if (dma_submit_error(cookie)) {
> >>>>>> printk(KERN_ERR "%s: Failed to start DMA transfer\n",
> >>>>>> __FUNCTION__);
> >>>>>> return -ENOMEM;
> >>>>>> }
> >>>>>>
> >>>>>> dma_async_issue_pending(chan);
> >>>>>>
> >>>>>> tmo = wait_for_completion_timeout(&cmp, tmo);
> >>>>>> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
> >>>>>>
> >>>>>> if (tmo == 0) {
> >>>>>> printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__);
> >>>>>> rc = -ETIMEDOUT;
> >>>>>> } else if (status != DMA_SUCCESS) {
> >>>>>> printk(KERN_ERR "%s: Transfer failed: status is %s\n",
> >>>>>> __FUNCTION__,
> >>>>>> status == DMA_ERROR ? "error" : "in progress");
> >>>>>>
> >>>>>> dev->device_control(chan, DMA_TERMINATE_ALL, 0);
> >>>>>> rc = -EIO;
> >>>>>> }
> >>>>>>
> >>>>>> return rc;
> >>>>>> }
> >>>>>>
> >>>>>> The destination address is PCI memory address returned by
> >>>>>> pci_ioremap_bar().
> >>>>>> The transfer silently fails, destination buffer doesn't change
> >>>>>> contents, but no
> >>>>>> error condition is reported.
> >>>>>>
> >>>>>> What am I doing wrong ?
> >>>>>>
> >>>>>> Thanks a lot in advance.
> >>>>>>
> >>>>> Your destination address is wrong. The device_prep_dma_memcpy() routine
> >>>>> works in physical addresses only (dma_addr_t type). Your source address
> >>>>> looks fine: you're using the result of dma_map_single(), which returns a
> >>>>> physical address.
> >>>>>
> >>>>> Your destination address should be something that comes from struct
> >>>>> pci_dev.resource[x].start + offset if necessary. In your lspci output
> >>>>> above, that will be 0xc0000000.
> >>>>>
> >>>>> Another possible problem: AFAIK you must use the _ONSTACK() variants
> >>>>> from include/linux/completion.h for struct completion which are on the
> >>>>> stack.
> >>>>>
> >>>>> Hope it helps,
> >>>>> Ira
> >>>> Thanks for your help. I'm now passing the result of
> >>>> pci_resource_start(pdev, 0)
> >>>> as destination address, and destination buffer changes after the
> >>>> transfer. But
> >>>> the contents of source and destination buffers are different. What
> >>>> else could
> >>>> be wrong ?
> >>>>
> >>> After you changed the dst address to pci_resource_start(pdev, 0), I
> >>> don't see anything wrong with the code.
> >>>
> >>> Try using memcpy_toio() to copy some bytes to the FPGA. Also try writing
> >>> a single byte at a time (writeb()?) in a loop. This should help
> >>> establish that your device is working.
> >>>
> >>> If you put some pattern in your src buffer (such as 0x0, 0x1, 0x2, ...
> >>> 0xff, repeat) does the destination show some pattern after the DMA
> >>> completes? (Such as, every 4th byte is correct.)
> >>>
> >>> Ira
> >> memcpy_toio() works fine, the data is written correctly. After
> >> DMA, the correct data appears at offsets 0xC, 0x1C, 0x2C, etc.
> >> of the destination buffer. I have 12 bytes of junk, 4 bytes of
> >> correct data, then again 12 bytes of junk and so on.
> >>
> > This sounds like your FPGA doesn't handle burst mode accesses correctly.
> > A logic analyzer will help you prove it.
> >
> > Another quick test to try is using an unaligned transfer and see what
> > happens. The 83xx DMA controller handles unaligned transfers by doing
> > several small, non-burst transfers until the src and dst are aligned,
> > and then does cacheline size burst transfers until complete. I hunch the
> > 85xx/86xx controller behaves the same way.
> >
> > Something like this:
> >
> > dma_src = dma_map_single(...);
> > dma_dst = pci_resource_start(pdev, 0) + 1;
> >
> > Notice that the dst address is offset by one byte, so you'll need to
> > take that into account when comparing data after the transfer.
> >
> > Ira
>
> Thanks a lot for your help. It seems the problem was in fsldma.c code,
> which was fixed in later kernels (I'm using 2.6.35). The BWC field
> in MR register was not set, resulting in single-byte transfers. This
> did not work well with FPGA which implements a FIFO with minimal
> transfer unit of 32 bits. After setting BWC field DMA works fine.
>
I'm glad to hear it works.
Ira
^ permalink raw reply
* [PATCH -mm 2/6] powerpc: convert little-endian bitops macros to static inline functions
From: Akinobu Mita @ 2011-01-27 13:56 UTC (permalink / raw)
To: linux-kernel, linux-arch, akpm; +Cc: linuxppc-dev, Paul Mackerras, Akinobu Mita
In-Reply-To: <1296136583-13815-1-git-send-email-akinobu.mita@gmail.com>
(This patch is intended to be folded into the patch in -mm:
powerpc-introduce-little-endian-bitops.patch)
The little-endian bitops on powerpc are written as preprocessor
macros with the cast to "unsigned long *".
This means that even non-pointers will be accepted without an error, and
that is a Very Bad Thing.
This converts the little-endian bitops macros to static inline functions
with proper prototypes.
Suggested-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/bitops.h | 43 +++++++++++++++++++++++++------------
1 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h b/arch/powerpc/include/asm/bitops.h
index fe67024..2e56187 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -288,20 +288,35 @@ static __inline__ int test_bit_le(unsigned long nr,
return (tmp[nr >> 3] >> (nr & 7)) & 1;
}
-#define __set_bit_le(nr, addr) \
- __set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-#define __clear_bit_le(nr, addr) \
- __clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-
-#define test_and_set_bit_le(nr, addr) \
- test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-#define test_and_clear_bit_le(nr, addr) \
- test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-
-#define __test_and_set_bit_le(nr, addr) \
- __test_and_set_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
-#define __test_and_clear_bit_le(nr, addr) \
- __test_and_clear_bit((nr) ^ BITOP_LE_SWIZZLE, (unsigned long *)(addr))
+static inline void __set_bit_le(int nr, void *addr)
+{
+ __set_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
+
+static inline void __clear_bit_le(int nr, void *addr)
+{
+ __clear_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
+
+static inline int test_and_set_bit_le(int nr, void *addr)
+{
+ return test_and_set_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
+
+static inline int test_and_clear_bit_le(int nr, void *addr)
+{
+ return test_and_clear_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
+
+static inline int __test_and_set_bit_le(int nr, void *addr)
+{
+ return __test_and_set_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
+
+static inline int __test_and_clear_bit_le(int nr, void *addr)
+{
+ return __test_and_clear_bit(nr ^ BITOP_LE_SWIZZLE, addr);
+}
#define find_first_zero_bit_le(addr, size) \
find_next_zero_bit_le((addr), (size), 0)
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Anton Vorontsov @ 2011-01-27 9:51 UTC (permalink / raw)
To: Alex Dubov; +Cc: linuxppc-dev, davem, mlcreech
In-Reply-To: <468529.34173.qm@web37605.mail.mud.yahoo.com>
Hello Alex,
On Thu, Jan 27, 2011 at 12:14:21AM -0800, Alex Dubov wrote:
> As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,
> older revisions of gianfar controllers will be unable to calculate a TCP/UDP
> packet checksum for some aligments of the appropriate FCB. This patch checks
> for FCB alignment on such controllers and falls back to software checksumming
> if the aligment is known to be bad.
>
> Signed-off-by: Alex Dubov <oakad@yahoo.com>
> ---
> This is my, somewhat different approach to Matthew Creech proposed solution.
>
> drivers/net/gianfar.c | 21 +++++++++++++++++++--
> drivers/net/gianfar.h | 1 +
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
> index 5ed8f9f..b4f0e99 100644
> --- a/drivers/net/gianfar.c
> +++ b/drivers/net/gianfar.c
> @@ -950,6 +950,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
> (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
> priv->errata |= GFAR_ERRATA_A002;
>
> + /* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */
> + if ((pvr == 0x80850010 && mod == 0x80b0 && rev < 0x0020)
> + || (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020))
Please indent it like the above: with two tabs. This is
to keep things consistent.
> + priv->errata |= GFAR_ERRATA_12;
> +
> if (priv->errata)
> dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
> priv->errata);
> @@ -2156,8 +2161,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
> /* Set up checksumming */
> if (CHECKSUM_PARTIAL == skb->ip_summed) {
> fcb = gfar_add_fcb(skb);
> - lstatus |= BD_LFLAG(TXBD_TOE);
> - gfar_tx_checksum(skb, fcb);
> + switch (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
> + ? 1 : 0) {
The switch construction is quite bizarre. ;-) Why not
if (gfar_has_errata() && (ulong)fcb % 0x20 > 18) {
csum_help();
} else {
lstatus |=...
tx_csum();
}
?
Thanks,
> + case 1:
> + /* as specified by errata */
> + if (((unsigned long)fcb % 0x20) > 0x18) {
> + __skb_pull(skb, GMAC_FCB_LEN);
> + skb_checksum_help(skb);
> + break;
> + }
> + /* otherwise, fall through */
> + default:
> + lstatus |= BD_LFLAG(TXBD_TOE);
> + gfar_tx_checksum(skb, fcb);
> + }
> }
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: FSL DMA engine transfer to PCI memory
From: Felix Radensky @ 2011-01-27 8:32 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20110125162946.GA13438@ovro.caltech.edu>
Hi Ira,
On 01/25/2011 06:29 PM, Ira W. Snyder wrote:
> On Tue, Jan 25, 2011 at 04:32:02PM +0200, Felix Radensky wrote:
>> Hi Ira,
>>
>> On 01/25/2011 02:18 AM, Ira W. Snyder wrote:
>>> On Tue, Jan 25, 2011 at 01:39:39AM +0200, Felix Radensky wrote:
>>>> Hi Ira, Scott
>>>>
>>>> On 01/25/2011 12:26 AM, Ira W. Snyder wrote:
>>>>> On Mon, Jan 24, 2011 at 11:47:22PM +0200, Felix Radensky wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to use FSL DMA engine to perform DMA transfer from
>>>>>> memory buffer obtained by kmalloc() to PCI memory. This is on
>>>>>> custom board based on P2020 running linux-2.6.35. The PCI
>>>>>> device is Altera FPGA, connected directly to SoC PCI-E controller.
>>>>>>
>>>>>> 01:00.0 Unassigned class [ff00]: Altera Corporation Unknown device
>>>>>> 0004 (rev 01)
>>>>>> Subsystem: Altera Corporation Unknown device 0004
>>>>>> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
>>>>>> ParErr- Stepping- SERR- FastB2B-
>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
>>>>>> >TAbort-<TAbort-<MAbort->SERR-<PERR-
>>>>>> Interrupt: pin A routed to IRQ 16
>>>>>> Region 0: Memory at c0000000 (32-bit, non-prefetchable)
>>>>>> [size=128K]
>>>>>> Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
>>>>>> Queue=0/0 Enable-
>>>>>> Address: 0000000000000000 Data: 0000
>>>>>> Capabilities: [78] Power Management version 3
>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>>>>> Capabilities: [80] Express Endpoint IRQ 0
>>>>>> Device: Supported: MaxPayload 256 bytes, PhantFunc 0,
>>>>>> ExtTag-
>>>>>> Device: Latency L0s<64ns, L1<1us
>>>>>> Device: AtnBtn- AtnInd- PwrInd-
>>>>>> Device: Errors: Correctable- Non-Fatal- Fatal-
>>>>>> Unsupported-
>>>>>> Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>>>>>> Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
>>>>>> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 1
>>>>>> Link: Latency L0s unlimited, L1 unlimited
>>>>>> Link: ASPM Disabled RCB 64 bytes CommClk- ExtSynch-
>>>>>> Link: Speed 2.5Gb/s, Width x1
>>>>>> Capabilities: [100] Virtual Channel
>>>>>>
>>>>>>
>>>>>> I can successfully writel() to PCI memory via address obtained from
>>>>>> pci_ioremap_bar().
>>>>>> Here's my DMA transfer routine
>>>>>>
>>>>>> static int dma_transfer(struct dma_chan *chan, void *dst, void *src,
>>>>>> size_t len)
>>>>>> {
>>>>>> int rc = 0;
>>>>>> dma_addr_t dma_src;
>>>>>> dma_addr_t dma_dst;
>>>>>> dma_cookie_t cookie;
>>>>>> struct completion cmp;
>>>>>> enum dma_status status;
>>>>>> enum dma_ctrl_flags flags = 0;
>>>>>> struct dma_device *dev = chan->device;
>>>>>> struct dma_async_tx_descriptor *tx = NULL;
>>>>>> unsigned long tmo = msecs_to_jiffies(FPGA_DMA_TIMEOUT_MS);
>>>>>>
>>>>>> dma_src = dma_map_single(dev->dev, src, len, DMA_TO_DEVICE);
>>>>>> if (dma_mapping_error(dev->dev, dma_src)) {
>>>>>> printk(KERN_ERR "Failed to map src for DMA\n");
>>>>>> return -EIO;
>>>>>> }
>>>>>>
>>>>>> dma_dst = (dma_addr_t)dst;
>>>>>>
>>>>>> flags = DMA_CTRL_ACK |
>>>>>> DMA_COMPL_SRC_UNMAP_SINGLE |
>>>>>> DMA_COMPL_SKIP_DEST_UNMAP |
>>>>>> DMA_PREP_INTERRUPT;
>>>>>>
>>>>>> tx = dev->device_prep_dma_memcpy(chan, dma_dst, dma_src, len, flags);
>>>>>> if (!tx) {
>>>>>> printk(KERN_ERR "%s: Failed to prepare DMA transfer\n",
>>>>>> __FUNCTION__);
>>>>>> dma_unmap_single(dev->dev, dma_src, len, DMA_TO_DEVICE);
>>>>>> return -ENOMEM;
>>>>>> }
>>>>>>
>>>>>> init_completion(&cmp);
>>>>>> tx->callback = dma_callback;
>>>>>> tx->callback_param =&cmp;
>>>>>> cookie = tx->tx_submit(tx);
>>>>>>
>>>>>> if (dma_submit_error(cookie)) {
>>>>>> printk(KERN_ERR "%s: Failed to start DMA transfer\n",
>>>>>> __FUNCTION__);
>>>>>> return -ENOMEM;
>>>>>> }
>>>>>>
>>>>>> dma_async_issue_pending(chan);
>>>>>>
>>>>>> tmo = wait_for_completion_timeout(&cmp, tmo);
>>>>>> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
>>>>>>
>>>>>> if (tmo == 0) {
>>>>>> printk(KERN_ERR "%s: Transfer timed out\n", __FUNCTION__);
>>>>>> rc = -ETIMEDOUT;
>>>>>> } else if (status != DMA_SUCCESS) {
>>>>>> printk(KERN_ERR "%s: Transfer failed: status is %s\n",
>>>>>> __FUNCTION__,
>>>>>> status == DMA_ERROR ? "error" : "in progress");
>>>>>>
>>>>>> dev->device_control(chan, DMA_TERMINATE_ALL, 0);
>>>>>> rc = -EIO;
>>>>>> }
>>>>>>
>>>>>> return rc;
>>>>>> }
>>>>>>
>>>>>> The destination address is PCI memory address returned by
>>>>>> pci_ioremap_bar().
>>>>>> The transfer silently fails, destination buffer doesn't change
>>>>>> contents, but no
>>>>>> error condition is reported.
>>>>>>
>>>>>> What am I doing wrong ?
>>>>>>
>>>>>> Thanks a lot in advance.
>>>>>>
>>>>> Your destination address is wrong. The device_prep_dma_memcpy() routine
>>>>> works in physical addresses only (dma_addr_t type). Your source address
>>>>> looks fine: you're using the result of dma_map_single(), which returns a
>>>>> physical address.
>>>>>
>>>>> Your destination address should be something that comes from struct
>>>>> pci_dev.resource[x].start + offset if necessary. In your lspci output
>>>>> above, that will be 0xc0000000.
>>>>>
>>>>> Another possible problem: AFAIK you must use the _ONSTACK() variants
>>>>> from include/linux/completion.h for struct completion which are on the
>>>>> stack.
>>>>>
>>>>> Hope it helps,
>>>>> Ira
>>>> Thanks for your help. I'm now passing the result of
>>>> pci_resource_start(pdev, 0)
>>>> as destination address, and destination buffer changes after the
>>>> transfer. But
>>>> the contents of source and destination buffers are different. What
>>>> else could
>>>> be wrong ?
>>>>
>>> After you changed the dst address to pci_resource_start(pdev, 0), I
>>> don't see anything wrong with the code.
>>>
>>> Try using memcpy_toio() to copy some bytes to the FPGA. Also try writing
>>> a single byte at a time (writeb()?) in a loop. This should help
>>> establish that your device is working.
>>>
>>> If you put some pattern in your src buffer (such as 0x0, 0x1, 0x2, ...
>>> 0xff, repeat) does the destination show some pattern after the DMA
>>> completes? (Such as, every 4th byte is correct.)
>>>
>>> Ira
>> memcpy_toio() works fine, the data is written correctly. After
>> DMA, the correct data appears at offsets 0xC, 0x1C, 0x2C, etc.
>> of the destination buffer. I have 12 bytes of junk, 4 bytes of
>> correct data, then again 12 bytes of junk and so on.
>>
> This sounds like your FPGA doesn't handle burst mode accesses correctly.
> A logic analyzer will help you prove it.
>
> Another quick test to try is using an unaligned transfer and see what
> happens. The 83xx DMA controller handles unaligned transfers by doing
> several small, non-burst transfers until the src and dst are aligned,
> and then does cacheline size burst transfers until complete. I hunch the
> 85xx/86xx controller behaves the same way.
>
> Something like this:
>
> dma_src = dma_map_single(...);
> dma_dst = pci_resource_start(pdev, 0) + 1;
>
> Notice that the dst address is offset by one byte, so you'll need to
> take that into account when comparing data after the transfer.
>
> Ira
Thanks a lot for your help. It seems the problem was in fsldma.c code,
which was fixed in later kernels (I'm using 2.6.35). The BWC field
in MR register was not set, resulting in single-byte transfers. This
did not work well with FPGA which implements a FIFO with minimal
transfer unit of 32 bits. After setting BWC field DMA works fine.
Felix.
^ permalink raw reply
* [PATCH] gianfar: Fall back to software tcp/udp checksum on older controllers
From: Alex Dubov @ 2011-01-27 8:14 UTC (permalink / raw)
To: mlcreech; +Cc: linuxppc-dev, davem
As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,=0A=
older revisions of gianfar controllers will be unable to calculate a TCP/UD=
P=0Apacket checksum for some aligments of the appropriate FCB. This patch c=
hecks=0Afor FCB alignment on such controllers and falls back to software ch=
ecksumming=0Aif the aligment is known to be bad.=0A=0ASigned-off-by: Alex D=
ubov <oakad@yahoo.com>=0A---=0AThis is my, somewhat different approach to M=
atthew Creech proposed solution.=0A=0A drivers/net/gianfar.c | 21 +++++++=
++++++++++++--=0A drivers/net/gianfar.h | 1 +=0A 2 files changed, 20 ins=
ertions(+), 2 deletions(-)=0A=0Adiff --git a/drivers/net/gianfar.c b/driver=
s/net/gianfar.c=0Aindex 5ed8f9f..b4f0e99 100644=0A--- a/drivers/net/gianfar=
.c=0A+++ b/drivers/net/gianfar.c=0A@@ -950,6 +950,11 @@ static void gfar_de=
tect_errata(struct gfar_private *priv)=0A =09=09=09(pvr =3D=3D 0x80861010 &=
& (mod & 0xfff9) =3D=3D 0x80c0))=0A =09=09priv->errata |=3D GFAR_ERRATA_A00=
2;=0A =0A+=09/* MPC8313 Rev < 2.0, MPC8548 rev 2.0 */=0A+=09if ((pvr =3D=3D=
0x80850010 && mod =3D=3D 0x80b0 && rev < 0x0020)=0A+=09 || (pvr =3D=3D =
0x80210020 && mod =3D=3D 0x8030 && rev =3D=3D 0x0020))=0A+=09=09priv->errat=
a |=3D GFAR_ERRATA_12;=0A+=0A =09if (priv->errata)=0A =09=09dev_info(dev, "=
enabled errata workarounds, flags: 0x%x\n",=0A =09=09=09 priv->errata);=0A@=
@ -2156,8 +2161,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struc=
t net_device *dev)=0A =09/* Set up checksumming */=0A =09if (CHECKSUM_PARTI=
AL =3D=3D skb->ip_summed) {=0A =09=09fcb =3D gfar_add_fcb(skb);=0A-=09=09ls=
tatus |=3D BD_LFLAG(TXBD_TOE);=0A-=09=09gfar_tx_checksum(skb, fcb);=0A+=09=
=09switch (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))=0A+=09=09=09? 1 =
: 0) {=0A+=09=09case 1:=0A+=09=09=09/* as specified by errata */=0A+=09=09=
=09if (((unsigned long)fcb % 0x20) > 0x18) { =0A+=09=09=09=09__skb_pull(skb=
, GMAC_FCB_LEN);=0A+=09=09=09=09skb_checksum_help(skb);=0A+=09=09=09=09brea=
k;=0A+=09=09=09}=0A+=09=09=09/* otherwise, fall through */=0A+=09=09default=
:=0A+=09=09=09lstatus |=3D BD_LFLAG(TXBD_TOE);=0A+=09=09=09gfar_tx_checksum=
(skb, fcb);=0A+=09=09}=0A =09}=0A =0A =09if (vlan_tx_tag_present(skb)) {=0A=
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h=0Aindex 54de413.=
.ec5d595 100644=0A--- a/drivers/net/gianfar.h=0A+++ b/drivers/net/gianfar.h=
=0A@@ -1039,6 +1039,7 @@ enum gfar_errata {=0A =09GFAR_ERRATA_74=09=09=3D 0=
x01,=0A =09GFAR_ERRATA_76=09=09=3D 0x02,=0A =09GFAR_ERRATA_A002=09=3D 0x04,=
=0A+=09GFAR_ERRATA_12=09=09=3D 0x08, /* a.k.a errata eTSEC49 */=0A };=0A =
=0A /* Struct stolen almost completely (and shamelessly) from the FCC enet =
source=0A-- =0A1.7.3.2=0A=0A=0A=0A=0A
^ permalink raw reply
* Busybox for powerpc not compiling
From: Giriprasad Deviprasad @ 2011-01-27 6:11 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5201 bytes --]
Hi All,
I am trying to compile busybox-1.17.1 for mpc8250 based powerpc architecture. My settings are as :
export LDFLAGS="-nostdlib -L/opt/mpc8250/tools/ppc_6xx/usr/lib/"
export LIBRARY_PATH=/opt/mpc8250/tools/ppc_6xx/usr/lib/
echo $PATH
/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/opt/mpc8250/tools/usr/bin/:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/root/bin
I specified in menuconfig:
CFLAGS as -I/opt/mpc8250/tools/ppc_6xx/usr/include/ -L/opt/mpc8250/tools/ppc_6xx/usr/lib/
make ARCH=powerpc CROSS_COMPILE=powerpc-linux- --include-dir=/opt/mpc8250/tools/ppc_6xx/usr/include/ PREFIX=/home/user/target/mpc8250/rootfs
LD applets/built-in.o
LINK busybox_unstripped
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
powerpc-linux-gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -I/opt/mpc8250/tools/ppc_6xx/usr/include/ -L/opt/mpc8250/tools/ppc_6xx/usr/lib/ -static -nostdlib -L/opt/mpc8250/tools/ppc_6xx/usr/lib/ -o busybox_unstripped -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a
networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
/opt/mpc8250/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/../../../../powerpc-linux/bin/ld: cannot find -lcrypt
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1
Also tried:
make ARCH=powerpc CROSS=powerpc-linux- --include-dir=/opt/mpc8250/tools/ppc_6xx/usr/include/ PREFIX=/home/user/target/mpc8250/rootfs
LINK busybox_unstripped
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
powerpc-linux-gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -I/opt/mpc8250/tools/ppc_6xx/usr/include/ -L/opt/mpc8250/tools/ppc_6xx/usr/lib/ -static -nostdlib -L/opt/mpc8250/tools/ppc_6xx/usr/lib/ -o busybox_unstripped -Wl,--start-group applets/built-in.o archival/lib.a archival/libunarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a
networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libunarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
/opt/mpc8250/tools/usr/bin/../lib/gcc/powerpc-linux/4.2.2/../../../../powerpc-linux/bin/ld: cannot find -lcrypt
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] Error 1
Any clues as to why this happens?
Thanks & Regards,
D.Giriprasad
[-- Attachment #2: Type: text/html, Size: 5494 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox