* Re: Linux with data2mem
From: jozsef imrek @ 2007-08-08 3:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF56B29E3B.75AC018C-ON85257330.0055CDE0-85257330.0056CDD1@ct.wec.com>
On Tue, 7 Aug 2007 Glenn.G.Hart@us.westinghouse.com wrote:
> ERROR:Data2MEM:33 - Matching ADDRESS_SPACE for code segment #0 not found in
> 'sys
> tem_bd.bmm'.
> Code segment #0 occupies [0x00400000:0x0062AFFF]
>
...
> ///////////////////////////////////////////////////////////////////////////////
>
> ADDRESS_SPACE plb_bram_if_cntlr_1_bram_combined RAMB16
> [0xFFFFC000:0xFFFFFFFF]
make sure that the memory range your software wants to use is backed
by real memory. it seems that your elf expects itself to be loaded at
0x00400000:0x0062AFFF, but you block memory is at 0xFFFFC000:0xFFFFFFFF
(use readelf -l to find out what address ranges does your software want
to use).
probably what you want is a boot loader in the bram, not the kernel image
(the zImage). the boot loader would load the linux kernel into the main
memory (starting at memory address 0x00000000).
--
mazsi
----------------------------------------------------------------
strawberry fields forever! imrek@atomki.hu
----------------------------------------------------------------
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Tony Breeds @ 2007-08-08 3:16 UTC (permalink / raw)
To: LinuxPPC-dev, David Gibson
In-Reply-To: <20070807062231.GB8351@localhost.localdomain>
On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> Based on BenH's earlier work, this is a new version of the EMAC driver
> for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> same ASIC is also found in the Axon bridge chip. This new version is
> designed to work in the arch/powerpc tree, using the device tree to
> probe the device, rather than the old and ugly arch/ppc OCP layer.
<snip>
Hi David,
I had a look over the patch FWIW, asside from the points below
looks good.
Minor nits:
* Shouldn't ndev->priv accesses, use netdev_priv() ? if not a comment
somewhere about why not will keep the janators off your back.
* c++ style comments
* in emac_probe():
+ /* Wait for dependent devices */
+ err = -ENODEV;
+ err = emac_wait_deps(dev);
The initialisation to -ENODEV is pointless right?
* s/get_property/of_get_property/g or you'll make sfr grumpy ;P
* In drivers/net/ibm_newemac/Makefile, I think the preferred method is
to use ibm_newemac-y rather than ibm_newemac-objs.
Is there any reason to leave config IBM_NEW_EMAC (and IBM_EMAC) in
drivers/net/Kconfig ? It seems to me they'd be nicer to in the
appropriate drivers/net/*Kconfig.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [patch 04/10] 4xx bootwrapper reworks
From: David Gibson @ 2007-08-08 1:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070807081038.06925ccb@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 08:10:38AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 13:05:47 +1000
> David Gibson <dwg@au1.ibm.com> wrote:
>
> > > > Rather than just removing these defines and using hardcoded values,
> > > > I'd prefer to see separate SPRN_DBCR0_40X and SPRN_DBCR0_44X defines.
> > >
> > > Ok. And place them where? In the same file since they aren't DCR defines?
> > > Seems fairly trivial, but ok.
> >
> > Just where the old 44x specific define was. And yes, it is fairly
> > trivial.
>
> Fixed.
>
> > > > [snip]
> > > > > +#define EMAC_RESET 0x20000000
> > > > > +#define MAL_RESET 0x80000000
> > > >
> > > > I think the MAL_RESET definition should go in the same place as the
> > > > DCR number definition.
> > >
> > > Ok. Trivial.
> >
> > Yes.
>
> Fixed.
>
> > > > As I think I said before, I'm not really happy with this being
> > > > hardcoded assuming exactly 2 ethernets.
> > >
> > > Well, it's hardcoded to assume one or two. I know of only one board that has
> > > more than two EMACs. I was hoping we could get this in for 2.6.24 as-is and
> > > change it when needs be. But I'll look at making it var-args or similar.
>
> I'm going to hold off on this for now. I'm not disagreeing with you,
> but there are no upcoming board ports that have more than two EMACs so
> I'd like to focus on getting Bamboo (440EP) and Sequoia (440EPx)
> in-tree first. Perhaps even Walnut, if there's time.
Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] Remove dtc build cruft from DTS files
From: David Gibson @ 2007-08-08 0:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070807122848.6bdf2f43@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 12:28:48PM -0500, Josh Boyer wrote:
> The patch below removes the dtc incantation instructions from the
> in-kernel DTS files. It's not needed, and is prone to being
> out-of-date most of the time.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: David Gibson @ 2007-08-08 1:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070807071539.6dbb49a5@weaponx.rchland.ibm.com>
On Tue, Aug 07, 2007 at 07:15:39AM -0500, Josh Boyer wrote:
> On Tue, 7 Aug 2007 16:22:31 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > Based on BenH's earlier work, this is a new version of the EMAC driver
> > for the built-in ethernet found on PowerPC 4xx embedded CPUs. The
> > same ASIC is also found in the Axon bridge chip. This new version is
> > designed to work in the arch/powerpc tree, using the device tree to
> > probe the device, rather than the old and ugly arch/ppc OCP layer.
> >
> > This driver is designed to sit alongside the old driver (it lies in
> > drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> > old driver is left in place to support arch/ppc until arch/ppc itself
> > reaches its final demise (not too long now, with luck).
> >
> > This driver still has a number of things that could do with cleaning
> > up, but I think they can be fixed up after merging. Specifically:
> > - Should be adjusted to properly use the dma mapping API.
> > Axon needs this.
> > - Probe logic needs reworking, in conjuction with the general
> > probing code for of_platform devices. The dependencies here between
> > EMAC, MAL, ZMII etc. make this complicated. At present, it usually
> > works, because we initialize and register the sub-drivers before the
> > EMAC driver itself, and (being in driver code) runs after the devices
> > themselves have been instantiated from the device tree.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Hm. Should this go through Jeff Garzik or Paul? If it's the latter,
> I'll pull this into my git tree soon.
Through Jeff Garzik, I think. I was planning to send it to him today
or tomorrow if there are no screams from the linuxppc-dev list.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-08 1:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <03211b7766f4a21c90889344f843a564@kernel.crashing.org>
On Tue, Aug 07, 2007 at 06:33:01PM +0200, Segher Boessenkool wrote:
> >>>>> Yeah, better names please -- if possible, something that someone
> >>>>> without knowledge of this SoC will understand what it is.
> >>>>
> >>>> I think the names are probably ok - I'm assuming they're in keeping
> >>>> with the convention I've used of using the same names /
> >>>> abbreviations
> >>>> as in the CPU user manual. I'm asking just for my own information,
> >>>> although a comment might not be a bad idea.
> >>
> >> Fine with me -- I personally prefer "system-device-controller"
> >> and "clock-power-controller" or similar, but that is mostly a
> >> matter of taste. As long as it's human readable it's fine.
> >
> > Actually, it occurs to me that I've only sometimes been using that
> > convention for the names: basically just for the weirdo chip control
> > devices that don't have a more widespread generic name.
>
> It's pretty darn hard to make good sensible "generic names" for
> some of the devices on a SoC; using the acronym that's in the
> documentation for that SoC certainly isn't the worst choice.
My thoughts exactly.
> >>> + Flash partitions
> >>> + - reg :
> >>> + - read-only : (optional)
> >>
> >> I'll hold off commenting on this until you've finish writing it,
> >> you probably know my opinion about it anyway :-)
> >
> > Heh.. actually I was kind of hoping for your input on what's still
> > missing. For example, I don't know what the necessary extra
> > properties for JEDEC chips are.
>
> I meant for the "partitions" stuff only.
>
> For the JEDEC chips, we need a "vendor-id" and "device-id"
> property at least (or similar names -- whatever is general
> practice for this); both are a single byte, encoded as with
> encode-int.
Ok... should those really be separate properties, or should that go in
compatible, i.e. something like:
compatible = "amd,XXXXXX", "jedec,a4-b7", "jedec-flash";
> >> One thing though -- what _exactly_ does "read-only" signify?
> >
> > That's... a good question.
>
> Yeah. It seems to me that the way it is currently used is
> pure policy enforcement, which doesn't belong in the device
> tree.
Well.. not really policy enforcement, but a policy hint.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-08 1:13 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <b055a84cbb23ef7287c1d585c1810a74@kernel.crashing.org>
On Tue, Aug 07, 2007 at 06:51:04PM +0200, Segher Boessenkool wrote:
> >> address-permutation = <0 1 3 2 4 5 7 6 e f d c a b 9 8>;
> >
> > Yes, I was contemplating something like that.
>
> Let's not define this until we need it though :-)
Indeed.
> >> I haven't heard or thought of anything better either. Using "ranges"
> >> is conceptually wrong, even ignoring the technical problems that come
> >> with it.
> >
> > Why is "ranges" conceptually wrong?
>
> The flash partitions aren't separate devices sitting on a
> "flash bus", they are "sub-devices" of their parent.
Well, yes, but nonetheless the partitions show up as part of the
overall physical address space. How do you encode that other than in
'ranges'?
> > To be honest this looks rather to me like another case where having
> > overlapping 'reg' and 'ranges' would actually make sense.
>
> It never makes sense. You should give the "master" device
> the full "reg" range it covers, and have it define its own
> address space; "sub-devices" can carve out their little hunk
> from that. You don't want more than one device owning the
> same address range in the same address space.
Why not? After all, the physical address ranges of the flash
partitions really do overlap with that of the flash device as a whole.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-08 0:48 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <2c959d4df36f91dd9ee900d415c836f9@kernel.crashing.org>
On Tue, Aug 07, 2007 at 06:58:20PM +0200, Segher Boessenkool wrote:
> >> Most characters are allowed in the unit-address... The following
> >> is just fine: "my-secret-base@the-moon". ISA uses letters to
> >> distinguish between its different address spaces, for example.
> >
> > Yeah, I should probably make dtc a bit more flexible about accepting
> > that, too. At present, it only takes hex digits and ',', since those
> > are the common character.
>
> Sounds good. And then the legacy ISA devices in existing
> DTS files should be changed to say @i60 instead of @60, etc.
> (@60 is correct since the default is legacy I/O space, but
> it's good the be more verbose in those cases).
Ok, I'll look into that. No promises that it will be real soon,
though.
> >> David, can multiple devices sit on the same chip-select
> >> on EBC, or on the same "minor" address? If not, you can
> >> simplify your unit address representation.
> >
> > As far as I know, multiple devices could sit on the same chip select:
> > provided there was enough address decoding logic in or around the
> > devices, and that there existing bus timing parameters which would
> > work with all the devices on a chip select (or "bank" in the
> > terminology of the EBC bridge documentation).
>
> Ah, that's what multiple banks are for!
Yes.
> > Devices on different banks can certainly have the same address/offset
> > within the bank - e.g. on Ebony most of the devices are at offset 0.
> > The OPB address range for each bank is separately programmable in the
> > EBC bridge DCRs.
>
> Okay, seems like the <bank,offset> representation is the simplest
> possible, then. Good. <rubber stamp>
Excellent. I should really do a proper write-up for b-o-f.txt, I
guess.
> > (Incidentally, this is why I created the binding in this way, rather
> > than just using the firmware established addresses in OPB space, which
> > are usually fixed for a particular board/platform. This way provides
> > enough information that, if necessary, the kernel or another client
> > can reprogram the EBC from scratch to access the various devices
> > present. Well.. actually fully reprogramming would also need the the
> > bus timing parameters, which I was thinking of adding information
> > before, but I haven't gotten to it yet.)
>
> It gives a full "as simple as possible but no simpler" description
> of the hardware, so it's just fine independent of whether you want
> to reprogram the EBC or not.
That was the idea.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-08 0:35 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <e20238f937f1328cc3db88840b3c7fc3@kernel.crashing.org>
On Tue, Aug 07, 2007 at 06:43:35PM +0200, Segher Boessenkool wrote:
> >>> Aha! Ok, now I understand the sorts of situations you're talking
> >>> about. By "not direct mapped", I thought you were talking about some
> >>> kind of access via address/data registers on some indirect bus
> >>> controller, rather than weird variations on endianness and
> >>> bit-swizzling.
> >>
> >> No, that would be just too ridiculous for a NOR flash -- I hope.
> >> :-)
> >
> > Heh. In my experience, very little is so ridiculous that some
> > embedded vendor won't do it.
>
> True -- but if you can't map the NOR into the CPU address space,
> there are cheaper alternatives. Most embedded vendors care about
> that, too ;-)
>
> >> So, you're saying that the 1:1 address correspondence rule stops
> >> to apply
> >> here?
> >
> > Well.. it all depends what exactly you consider the address space of
> > the flash bank. By which I mean the whole shmozzle represented by the
> > device node, not the individual flash chips. It's not immediately
> > obvious whether or not that should include any swizzling done by the
> > bus wiring.
>
> The parent device/bus shouldn't care, from its viewpoint the flash
> bank is just one linear hunk of address space. For reading or
> writing the flash bank appears linear to the CPU as well (at least
> that's the only thing our current proposed binding supports); the
> only thing that gets "interesting" is sending commands to the flash
> chips.
>
> > It would be possible, I guess, to define a 'swizzled-ranges' property
> > or something which allows child devices to be embedded in the parent's
> > address range in a not-direct way.
>
> Let's not even consider this please.
>
> > However, the swizzling on the
> > flash bank is really a property of the flash bank,
>
> Yeah, it's the "fine structure" of the flash bank. Something
> only the flash driver has to deal with. So no contaminating the
> parent device node, thank you.
Sounds like we're in agreement, then.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] turn on icplus phy in mpc8323rdb defconfig
From: Kim Phillips @ 2007-08-07 23:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
support for the MPC8323E RDB's ICPlus PHY was recently added to the
kernel, so now we can have it turned on by default.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/configs/mpc832x_rdb_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/configs/mpc832x_rdb_defconfig b/arch/powerpc/configs/mpc832x_rdb_defconfig
index 6a83b66..4064d05 100644
--- a/arch/powerpc/configs/mpc832x_rdb_defconfig
+++ b/arch/powerpc/configs/mpc832x_rdb_defconfig
@@ -497,6 +497,7 @@ CONFIG_PHYLIB=y
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
+CONFIG_ICPLUS_PHY=y
# CONFIG_FIXED_PHY is not set
#
--
1.5.2.2
^ permalink raw reply related
* [PATCH] powerpc: fix i2c device string format
From: Guennadi Liakhovetski @ 2007-08-07 22:32 UTC (permalink / raw)
To: Segher Boessenkool, Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <46B0F030.9030007@freescale.com>
On Wed, 1 Aug 2007, Segher Boessenkool wrote:
> strncpy() won't put a terminating zero on there, is everything
> that uses the resulting string okay with that? Also, if the
> name gets cut short, it might match some _other_ expected name.
On Wed, 1 Aug 2007, Scott Wood wrote:
> You could use strlcpy() instead, which always leaves a zero terminator.
The patch below does exactly this - uses strlcpy() to guarantee strings in
i2c device type and driver_name fields are 0-terminated.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
---
Trying to follow the "canonical" patch format: Paul, please queue this
patch for 2.6.24. It is not critical, as there no strings at the moment in
fsl_soc.c, that exceed i2c limits. So, it's just a precaution measure.
Thanks
Guennadi
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 727453d..2ef7036 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -327,8 +327,8 @@ static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
if (!of_device_is_compatible(node, i2c_devices[i].of_device))
continue;
- strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
- strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ strlcpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
+ strlcpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
return 0;
}
return -ENODEV;
^ permalink raw reply related
* Re: [PATCH 2/6] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Jeff Garzik @ 2007-08-07 22:16 UTC (permalink / raw)
To: brking; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <46B8ED10.1060701@linux.vnet.ibm.com>
Brian King wrote:
> Jeff Garzik wrote:
>> Brian King wrote:
>>> This patch adds the appropriate ethtool hooks to allow for enabling/disabling
>>> of hypervisor assisted checksum offload for TCP.
>>>
>>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>>> ---
>>>
>>> linux-2.6-bjking1/drivers/net/ibmveth.c | 118 +++++++++++++++++++++++++++++++-
>>> linux-2.6-bjking1/drivers/net/ibmveth.h | 1
>>> 2 files changed, 117 insertions(+), 2 deletions(-)
>>>
>>> diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
>>> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-08-01 14:55:14.000000000 -0500
>>> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 14:55:14.000000000 -0500
>>> @@ -641,12 +641,125 @@ static u32 netdev_get_link(struct net_de
>>> return 1;
>>> }
>>>
>>> +static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
>>> +{
>>> + struct ibmveth_adapter *adapter = dev->priv;
>>> +
>>> + if (data)
>>> + adapter->rx_csum = 1;
>>> + else {
>>> + adapter->rx_csum = 0;
>>> + dev->features &= ~NETIF_F_IP_CSUM;
>> why does this RX-related code clear a TX-related flag?
>
> Its related to how the pSeries firmware works. The firmware provides an interface
> to enable "checksum offload", which means both tx and rx checksum offload from
> the firmware's point of view. The firmware does not support enabling checksum
> offload for only rx. If I disable it for rx I have to disable it for tx as
> well, otherwise the firmware will reject all future tx buffers I throw at it
> that are not checksummed.
ACK once you add a comment describing this :)
^ permalink raw reply
* Re: [PATCH 2/6] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-08-07 22:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <46B8E891.80403@garzik.org>
Jeff Garzik wrote:
> Brian King wrote:
>> This patch adds the appropriate ethtool hooks to allow for enabling/disabling
>> of hypervisor assisted checksum offload for TCP.
>>
>> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
>> ---
>>
>> linux-2.6-bjking1/drivers/net/ibmveth.c | 118 +++++++++++++++++++++++++++++++-
>> linux-2.6-bjking1/drivers/net/ibmveth.h | 1
>> 2 files changed, 117 insertions(+), 2 deletions(-)
>>
>> diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
>> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-08-01 14:55:14.000000000 -0500
>> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 14:55:14.000000000 -0500
>> @@ -641,12 +641,125 @@ static u32 netdev_get_link(struct net_de
>> return 1;
>> }
>>
>> +static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
>> +{
>> + struct ibmveth_adapter *adapter = dev->priv;
>> +
>> + if (data)
>> + adapter->rx_csum = 1;
>> + else {
>> + adapter->rx_csum = 0;
>> + dev->features &= ~NETIF_F_IP_CSUM;
>
> why does this RX-related code clear a TX-related flag?
Its related to how the pSeries firmware works. The firmware provides an interface
to enable "checksum offload", which means both tx and rx checksum offload from
the firmware's point of view. The firmware does not support enabling checksum
offload for only rx. If I disable it for rx I have to disable it for tx as
well, otherwise the firmware will reject all future tx buffers I throw at it
that are not checksummed.
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 6/6] ibmveth: Remove use of bitfields
From: Jeff Garzik @ 2007-08-07 21:56 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708061942.l76JgmxI031698@d03av01.boulder.ibm.com>
Brian King wrote:
> Removes the use of bitfields from the ibmveth driver. This results
> in slightly smaller object code.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> linux-2.6-bjking1/drivers/net/ibmveth.c | 90 ++++++++++++++++----------------
> linux-2.6-bjking1/drivers/net/ibmveth.h | 56 ++++++++-----------
> 2 files changed, 68 insertions(+), 78 deletions(-)
strong ACK :)
Though I also encourage you to avoid #defines for named constants, in
favor of
enum {
IBMVETH_BUF_VALID = (1U << 31),
IBMVETH_BUF_TOGGLE = (1U << 30),
IBMVETH_BUF_NO_CSUM = (1U << 25),
IBMVETH_BUF_CSUM_GOOD = (1U << 24),
IBMVETH_BUF_LEN_MASK = 0x00FFFFFF,
};
This illustrates:
1) The "1 << n" notation is FAR easier to read and compare with data
sheets. You're just adding to the trouble by requiring the reviewer's
brain to convert hex numbers to bits, even if most engineers can do this
in their sleep.
2) The named constants are available to the C compiler, which is more
friendly to debuggers. It also supplies type information to the C compiler.
3) Similar to #2, wading through C pre-processor output is much easier
when the symbols don't disappear.
These are recommendations, not requirements, but I've found these
techniques superior to cpp in many other drivers.
Jeff
^ permalink raw reply
* Re: [PATCH 4/6] ibmveth: Add ethtool driver stats hooks
From: Jeff Garzik @ 2007-08-07 21:50 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708061942.l76JgZRK020999@d03av03.boulder.ibm.com>
Brian King wrote:
> Add ethtool hooks to ibmveth to retrieve driver statistics.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> drivers/net/ibmveth.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 52 insertions(+), 1 deletion(-)
>
> diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats drivers/net/ibmveth.c
> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats 2007-07-19 11:18:41.000000000 -0500
> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 11:18:41.000000000 -0500
> @@ -112,6 +112,28 @@ MODULE_DESCRIPTION("IBM i/pSeries Virtua
> MODULE_LICENSE("GPL");
> MODULE_VERSION(ibmveth_driver_version);
>
> +struct ibmveth_stat {
> + char name[ETH_GSTRING_LEN];
> + int offset;
> +};
> +
> +#define IBMVETH_STAT_OFF(stat) offsetof(struct ibmveth_adapter, stat)
> +#define IBMVETH_GET_STAT(a, off) *((u64 *)(((unsigned long)(a)) + off))
> +
> +struct ibmveth_stat ibmveth_stats[] = {
> + { "replenish_task_cycles", IBMVETH_STAT_OFF(replenish_task_cycles) },
> + { "replenish_no_mem", IBMVETH_STAT_OFF(replenish_no_mem) },
> + { "replenish_add_buff_failure", IBMVETH_STAT_OFF(replenish_add_buff_failure) },
> + { "replenish_add_buff_success", IBMVETH_STAT_OFF(replenish_add_buff_success) },
> + { "rx_invalid_buffer", IBMVETH_STAT_OFF(rx_invalid_buffer) },
> + { "rx_no_buffer", IBMVETH_STAT_OFF(rx_no_buffer) },
> + { "tx_multidesc_send", IBMVETH_STAT_OFF(tx_multidesc_send) },
> + { "tx_linearized", IBMVETH_STAT_OFF(tx_linearized) },
> + { "tx_linearize_failed", IBMVETH_STAT_OFF(tx_linearize_failed) },
> + { "tx_map_failed", IBMVETH_STAT_OFF(tx_map_failed) },
> + { "tx_send_failed", IBMVETH_STAT_OFF(tx_send_failed) }
> +};
> +
> /* simple methods of getting data from the current rxq entry */
> static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
> {
> @@ -751,6 +773,32 @@ static u32 ibmveth_get_rx_csum(struct ne
> return adapter->rx_csum;
> }
>
> +static void ibmveth_get_strings(struct net_device *dev, u32 stringset, u8 *data)
> +{
> + int i;
> +
> + if (stringset != ETH_SS_STATS)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++, data += ETH_GSTRING_LEN)
> + memcpy(data, ibmveth_stats[i].name, ETH_GSTRING_LEN);
> +}
> +
> +static int ibmveth_get_stats_count(struct net_device *dev)
> +{
> + return ARRAY_SIZE(ibmveth_stats);
> +}
> +
> +static void ibmveth_get_ethtool_stats(struct net_device *dev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + int i;
> + struct ibmveth_adapter *adapter = dev->priv;
> +
> + for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++)
> + data[i] = IBMVETH_GET_STAT(adapter, ibmveth_stats[i].offset);
> +}
> +
> static const struct ethtool_ops netdev_ethtool_ops = {
> .get_drvinfo = netdev_get_drvinfo,
> .get_settings = netdev_get_settings,
> @@ -761,7 +809,10 @@ static const struct ethtool_ops netdev_e
> .get_rx_csum = ibmveth_get_rx_csum,
> .set_rx_csum = ibmveth_set_rx_csum,
> .get_tso = ethtool_op_get_tso,
> - .get_ufo = ethtool_op_get_ufo
> + .get_ufo = ethtool_op_get_ufo,
> + .get_strings = ibmveth_get_strings,
> + .get_stats_count = ibmveth_get_stats_count,
> + .get_ethtool_stats = ibmveth_get_ethtool_stats
ACK, modulo comma-at-end-of-initializer per previous email
^ permalink raw reply
* Re: [PATCH 3/6] ibmveth: Add ethtool TSO handlers
From: Jeff Garzik @ 2007-08-07 21:50 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708061942.l76JgSnp016148@d03av04.boulder.ibm.com>
Brian King wrote:
> Add handlers for get_tso and get_ufo to prevent errors being printed
> by ethtool.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> drivers/net/ibmveth.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-07-19 11:18:38.000000000 -0500
> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 11:18:38.000000000 -0500
> @@ -759,7 +759,9 @@ static const struct ethtool_ops netdev_e
> .get_tx_csum = ethtool_op_get_tx_csum,
> .set_tx_csum = ibmveth_set_tx_csum,
> .get_rx_csum = ibmveth_get_rx_csum,
> - .set_rx_csum = ibmveth_set_rx_csum
> + .set_rx_csum = ibmveth_set_rx_csum,
> + .get_tso = ethtool_op_get_tso,
> + .get_ufo = ethtool_op_get_ufo
ACK, once you add a comma to the end of the final initializer
As you see from this patch, the practice of -not- having commas at the
end of a list of struct initializers is not patch-friendly, since you
must touch an unrelated line each time you patch the end of the struct.
For named initializers particularly, the lack of a comma is even more
useless.
So, it might tweak some C perfectionists, but adding that
seemingly-useless comma at the end of the last entry reduces maintenance
headache and makes patch reviews slightly more clear.
Jeff
^ permalink raw reply
* Re: [PATCH 2/6] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Jeff Garzik @ 2007-08-07 21:48 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708061942.l76JgLrU009242@d01av04.pok.ibm.com>
Brian King wrote:
> This patch adds the appropriate ethtool hooks to allow for enabling/disabling
> of hypervisor assisted checksum offload for TCP.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
> ---
>
> linux-2.6-bjking1/drivers/net/ibmveth.c | 118 +++++++++++++++++++++++++++++++-
> linux-2.6-bjking1/drivers/net/ibmveth.h | 1
> 2 files changed, 117 insertions(+), 2 deletions(-)
>
> diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
> --- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-08-01 14:55:14.000000000 -0500
> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-01 14:55:14.000000000 -0500
> @@ -641,12 +641,125 @@ static u32 netdev_get_link(struct net_de
> return 1;
> }
>
> +static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
> +{
> + struct ibmveth_adapter *adapter = dev->priv;
> +
> + if (data)
> + adapter->rx_csum = 1;
> + else {
> + adapter->rx_csum = 0;
> + dev->features &= ~NETIF_F_IP_CSUM;
why does this RX-related code clear a TX-related flag?
otherwise looks OK
^ permalink raw reply
* Re: [PATCH 1/6] ibmveth: Enable TCP checksum offload
From: Jeff Garzik @ 2007-08-07 21:46 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <11864293333377-patch-mail.ibm.com>
Brian King wrote:
> This patchset enables TCP checksum offload support for IPV4
> on ibmveth. This completely eliminates the generation and checking of
> the checksum for packets that are completely virtual and never
> touch a physical network. A simple TCP_STREAM netperf run on
> a virtual network with maximum mtu set yielded a ~30% increase
> in throughput. This feature is enabled by default on systems that
> support it, but can be disabled with a module option.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
ACK, but does not apply to current netdev-2.6.git#upstream-fixes.
Request resend after the ibmveth fixes hit mainline (24 hours or so
after push, I suppose)
^ permalink raw reply
* Re: Fedora 7 on a non FPU system
From: Clemens Koller @ 2007-08-07 21:43 UTC (permalink / raw)
To: Michael Brian Willis; +Cc: linuxppc-embedded
In-Reply-To: <1186508561.5592.26.camel@louie>
Hi, Michael!
Michael Brian Willis schrieb:
> I'm trying to install a Fedora 7 Root File System on an MPC8540 based
> embedded system with a Denx 2.6.21 kernel. I have read the Denx
> Application note located at:
> http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia.
>
> However this App. Note says that the instructions apply only to
> processors that have a full Floating Point Unit (FPU). My processor does
> not have an FPU and I believe that this is causing some system hangs.
Yes, that won't work.
You can either use FPU emulation or do the floating point stuff on the e500
core's SPE (Signal Processing Engine) which is AFAIK not supported by any
major distribution.
> Has anybody every successfully installed Fedora(or another major distro)
> on a non-FPU system?
CRUX - not a "major distro", because it's targeted at "experienced Linux users".
I am running my selfmade version of "embedded CRUX" on my MPC8540 Boards
based on http://cruxppc.sunsite.dk/wp/index.php which now fully supports
the e500 core features.
> Or, does anybody know what is needed to get it
> working properly on a non FPU system?
... mentioned above.
I bootstrapped the toolchain (binutils, (e)glibc, gcc and friends)
from scratch. See:
http://www.anagramm-technology.com/05_Services/FoxFactSheet.pdf
Current versions: kernel 2.6.23-rc2, gcc-4.2.1, (e)glibc 2.5.1/2.6.1.
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [RESEND][PATCH 1/3] ehea: Fix workqueue handling
From: Jeff Garzik @ 2007-08-07 21:34 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, Stefan Roscher, linux-ppc, Jan-Bernd Themann,
Marcus Eder
In-Reply-To: <200708061354.30653.osstklei@de.ibm.com>
Thomas Klein wrote:
> Fix: Workqueue ehea_driver_wq was not destroyed
>
> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 2 +-
> drivers/net/ehea/ehea_main.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletions(-)
applied 1-3 to #upstream-fixes
^ permalink raw reply
* Re: [GIT PATCH] ucc_geth fixes for 2.6.22-rc1
From: Jeff Garzik @ 2007-08-07 21:19 UTC (permalink / raw)
To: leoli; +Cc: netdev, linuxppc-embedded
In-Reply-To: <1186132075.6230.11.camel@Gundam>
Li Yang wrote:
> Please pull from 'ucc_geth' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/leo/fsl-soc.git ucc_geth
>
> to receive the following fixes:
>
> drivers/net/ucc_geth_ethtool.c | 1 -
> drivers/net/ucc_geth_mii.c | 3 ++-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> Domen Puncer (1):
> ucc_geth: fix section mismatch
>
> Jan Altenberg (1):
> ucc_geth: remove get_perm_addr from ucc_geth_ethtool.c
pulled
^ permalink raw reply
* Re: Telnet on ML410
From: khollan @ 2007-08-07 20:09 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <12039337.post@talk.nabble.com>
Figured it out I needed to make device nodes
cd /dev
mknod ptmx c 5 2
cd /dev/pts
mknod 0 c 136 0
--
View this message in context: http://www.nabble.com/Telnet-on-ML410-tf4231739.html#a12041502
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Fedora 7 on a non FPU system
From: Josh Boyer @ 2007-08-07 19:29 UTC (permalink / raw)
To: Michael Brian Willis; +Cc: linuxppc-embedded
In-Reply-To: <1186508561.5592.26.camel@louie>
On Tue, 07 Aug 2007 12:42:41 -0500
Michael Brian Willis <willis@arlut.utexas.edu> wrote:
> Hello,
>
> I'm trying to install a Fedora 7 Root File System on an MPC8540 based
> embedded system with a Denx 2.6.21 kernel. I have read the Denx
> Application note located at:
> http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia.
>
> However this App. Note says that the instructions apply only to
> processors that have a full Floating Point Unit (FPU). My processor does
> not have an FPU and I believe that this is causing some system hangs.
>
> Has anybody every successfully installed Fedora(or another major distro)
> on a non-FPU system? Or, does anybody know what is needed to get it
> working properly on a non FPU system?
CONFIG_MATH_EMULATION in the kernel will emulate floating point
instructions. Try that.
josh
^ permalink raw reply
* Re: Fedora 7 on a non FPU system
From: Roland Dreier @ 2007-08-07 19:11 UTC (permalink / raw)
To: Michael Brian Willis; +Cc: linuxppc-embedded
In-Reply-To: <1186508561.5592.26.camel@louie>
> Has anybody every successfully installed Fedora(or another major distro)
> on a non-FPU system? Or, does anybody know what is needed to get it
> working properly on a non FPU system?
The simplest thing to do is to use a kernel that has FPU emulation
enabled. Pretty much every ppc binary will use the FPU for spare
registers if nothing else, so your only other alternative would be to
rebuild the whole distribution.
- R.
^ permalink raw reply
* Fedora 7 on a non FPU system
From: Michael Brian Willis @ 2007-08-07 17:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070314065411.GD14658@moe.telargo.com>
Hello,
I'm trying to install a Fedora 7 Root File System on an MPC8540 based
embedded system with a Denx 2.6.21 kernel. I have read the Denx
Application note located at:
http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia.
However this App. Note says that the instructions apply only to
processors that have a full Floating Point Unit (FPU). My processor does
not have an FPU and I believe that this is causing some system hangs.
Has anybody every successfully installed Fedora(or another major distro)
on a non-FPU system? Or, does anybody know what is needed to get it
working properly on a non FPU system?
Any help is greatly appreciated.
Regards,
Michael Willis
Applied Research Labs-University of Texas
willis@arlut.utexas.edu
^ 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