* Re: [PATCH] mpc5200: add cuimage support for mpc5200 boards
From: Grant Likely @ 2007-08-30 21:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830210507.GA7757@ld0162-tx32.am.freescale.net>
On 8/30/07, Scott Wood <scottwood@freescale.com> wrote:
> On Thu, Aug 30, 2007 at 02:57:40PM -0600, Grant Likely wrote:
> > diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
> > new file mode 100644
> > index 0000000..46eecf0
> > --- /dev/null
> > +++ b/arch/powerpc/boot/mpc52xx-psc.c
> > @@ -0,0 +1,89 @@
> > +/*
> > + * CPM serial console support.
> > + *
> > + * Copyright 2007 Freescale Semiconductor, Inc.
> > + * Author: Scott Wood <scottwood@freescale.com>
> > + *
> > + * It is assumed that the firmware (or the platform file) has already set
> > + * up the port.
>
> Might want to update that comment block... :-)
HAHAHAHAHAHAHA! Yeah, I'll fix that. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] mpc5200: add cuimage support for mpc5200 boards
From: Matt Sealey @ 2007-08-30 21:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40708301415g15df8bf1na84f437ac8f17dcb@mail.gmail.com>
+/*
+ * Old U-boot compatibility for 8200
+ *
And this one?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> On 8/30/07, Scott Wood <scottwood@freescale.com> wrote:
>> On Thu, Aug 30, 2007 at 02:57:40PM -0600, Grant Likely wrote:
>>> diff --git a/arch/powerpc/boot/mpc52xx-psc.c b/arch/powerpc/boot/mpc52xx-psc.c
>>> new file mode 100644
>>> index 0000000..46eecf0
>>> --- /dev/null
>>> +++ b/arch/powerpc/boot/mpc52xx-psc.c
>>> @@ -0,0 +1,89 @@
>>> +/*
>>> + * CPM serial console support.
>>> + *
>>> + * Copyright 2007 Freescale Semiconductor, Inc.
>>> + * Author: Scott Wood <scottwood@freescale.com>
>>> + *
>>> + * It is assumed that the firmware (or the platform file) has already set
>>> + * up the port.
>> Might want to update that comment block... :-)
>
> HAHAHAHAHAHAHA! Yeah, I'll fix that. :-)
>
> g.
>
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Linas Vepstas @ 2007-08-30 21:28 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Q Klein, Jan-Bernd Themann, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Nathan Lynch, Paul Mackerras,
Stefan Roscher
In-Reply-To: <OF9D1ED44F.896DCCC5-ONC1257347.0044D256-C1257347.004CFB07@de.ibm.com>
On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote:
>
> Plus, I rather like using
> the full_name since it also contains a descriptive name as opposed to
> being just nondescript numbers, helping the layman (ie user) to make sense
> out of a dev_id.
Yes, well, but no. The location code is useful as a geographical
location: slots and devices are physically labelled with stickers
so you can tell which is which. Handy when you have to unplug stuff.
By contrast, the device-tree full_name is mostly just gobldy-gook,
with some crazy phb numbering in there that, after four years of
staring at them, I still can't reliably do anything useful with.
Location codes are nice.
--linas
^ permalink raw reply
* Re: [PATCH 2/9] cpm2: Fix off-by-one error in setbrg().
From: Vitaly Bordug @ 2007-08-30 21:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830201311.GA5144@ld0162-tx32.am.freescale.net>
On Thu, 30 Aug 2007 15:13:12 -0500
Scott Wood wrote:
> On Thu, Aug 30, 2007 at 02:09:07AM +0400, Vitaly Bordug wrote:
> > On Tue, 28 Aug 2007 15:19:21 -0500
> > Scott Wood wrote:
> >
> > > The hardware adds one to the BRG value to get the divider, so it
> > > must be subtracted by software.
> >
> > Prolly a note why it used to work, or what exactly this is
> > resulting in the code. IIRC this was just fw-ported so arch/ppc
> > should have this as well.
>
> It *didn't* work before -- hence the fix.
>
It used to work at least at the time I did initial port, but I am not going to argue.
> The failure mode from being off by just one isn't total
> nonfunctionality, but rather a corrupted character now and then,
> which could explain why it wasn't fixed before.
Can this be added to description please? Someone may be grepping for such a weirdness in some custom code forked off
some kernel.org revision, and will be happy to know it is addressed.
>
> As for arch/ppc, I'm just trying to not break it more than it already
> is.
I mean, when powerpc/ was nearly empty, same issue in ppc/ went unnoticed for years...
--
Sincerely, Vitaly
^ permalink raw reply
* The question about the relocate_code on u-boot for MPC8360?
From: 郭劲 @ 2007-08-31 2:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi, Friends,
I am debuging the u-boot on freescale MPC8360, the version of u-boot is 1.2.0, the
code on flash is OK,but the code from FLASH to DDR is broken, that is, after the
relocate_code function, the u-boot start again. I tested the DDR on u-boot, it's
OK. I was wondering that hot to deal with this problem? follow is the COM output
from u-boot. Thanks.
U-Boot 1.2.0 (Aug 29 2007 - 20:50:37) MPC83XX
Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 198 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
SEC: 88 MHz
I2C1: 264 MHz
I2C2: 264 MHz
CPU: Rev: Unknown guojing modified source code
Rev: 20 at 528 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM:
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
DDR test phase 1:
DDR test phase 2:
DDR test passed.
init_sequence finished
begin set up a new stack
beginning memcpy
ended memcpy,beginning relocate_code
U-Boot 1.2.0 (Aug 29 2007 - 20:50:37) MPC83XX
Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 198 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
SEC: 88 MHz
I2C1: 264 MHz
I2C2: 264 MHz
CPU: Rev: Unknown guojing modified source code
Rev: 20 at 528 MHz
Board: Freescale MPC8360EMDS
I2C: ready
DRAM:
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
DDR test phase 1:
DDR test phase 2:
DDR test passed.
init_sequence finished
begin set up a new stack
beginning memcpy
ended memcpy,beginning relocate_code
^ permalink raw reply
* Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree
From: David Gibson @ 2007-08-31 2:43 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070830202618.9927.32588.stgit@trillian.cg.shawcable.net>
On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: Scott Wood <scottwood@freescale.com>
> CC: Kumar Gala <galak@kernel.crashing.org>
> CC: David Gibson <david@gibson.dropbear.id.au>
Hrm... I thought Scott had deliberately removed that message in his
patch set, to work with the way PlanetCore generates Ethernet
addresses.
> ---
>
> arch/powerpc/boot/devtree.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
> index e1b8122..8451a1c 100644
> --- a/arch/powerpc/boot/devtree.c
> +++ b/arch/powerpc/boot/devtree.c
> @@ -99,14 +99,14 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
> while ((addr = va_arg(ap, const u8 *))) {
> devp = find_node_by_prop_value(NULL, "linux,network-index",
> (void*)&index, sizeof(index));
> -
> - printf("ENET%d: local-mac-address <-"
> - " %02x:%02x:%02x:%02x:%02x:%02x\n\r", index,
> - addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
> -
> - if (devp)
> + if (devp) {
> + printf("ENET%d: local-mac-address <-"
> + " %02x:%02x:%02x:%02x:%02x:%02x\n\r", index,
> + addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
> setprop(devp, "local-mac-address", addr, 6);
> -
> + } else {
> + printf("ENET%d: no device in tree\n\r", index);
> + }
> index++;
> }
> va_end(ap);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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/3] mpc8349: Add linux, network-index to ethernet nodes in device tree
From: David Gibson @ 2007-08-31 2:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070830202624.9927.50088.stgit@trillian.cg.shawcable.net>
On Thu, Aug 30, 2007 at 02:26:24PM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> cuImage need to know the logical index of the ethernet devices in order
> to assign mac addresses. This patch adds the needed properties
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: Scott Wood <scottwood@freescale.com>
> CC: Kumar Gala <galak@kernel.crashing.org>
> CC: Timur Tabi <timur@freescale.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: [PATCH 2/3] Introduce new CPM device bindings.
From: David Gibson @ 2007-08-31 2:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830141046.GA24123@ld0162-tx32.am.freescale.net>
On Thu, Aug 30, 2007 at 09:10:46AM -0500, Scott Wood wrote:
> On Thu, Aug 30, 2007 at 03:58:12PM +1000, David Gibson wrote:
> > On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
> > > On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> > > > Am I correct in thinking that it's basically an arch/ppc versus
> > > > arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> > > > instead?
> > >
> > > The idea was to allow boards to be converted incrementally, as I don't
> > > have access to test 100% of the boards that use the CPM code.
> >
> > Hrm. Right. This is still problematical, because what happens if you
> > have both old-binding and new-binding boards configured simultaneously?
>
> Multiplatform will not be supported for old-binding boards.
Hmm, ok. Well, let's try to kill the old binding off as fast as we
can, at least the portions that still infect arch/powerpc.
--
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: Document and implement an improved flash device binding for powerpc (v4)
From: David Gibson @ 2007-08-31 2:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830172932.GA3317@ld0162-tx32.am.freescale.net>
On Thu, Aug 30, 2007 at 12:29:33PM -0500, Scott Wood wrote:
> On Thu, Aug 30, 2007 at 11:21:18AM +1000, David Gibson wrote:
> > + For JEDEC compatible devices, the following additional properties
> > + are defined:
> > +
> > + - vendor-id : Contains the flash chip's vendor id (1 byte).
> > + - device-id : Contains the flash chip's device id (1 byte).
>
> Are these required, or recommended?
Heh.. that's an interesting question. I think they're a "SHOULD" in
rfc terminology. According to Segher, this information should be
provided for any JEDEC chip. However, it can, in practice, be probed
by the mtd code, and in fact there's no obvious way of actually
specifying these to the mtd code, so these properties aren't ever
actually used (at present, anyway).
> > + In addition to the information on the flash bank itself, the
> > + device tree may optionally contain additional information
> > + describing partitions of the flash address space. This can be
> > + used on platforms which have strong conventions about which
> > + portions of the flash are used for what purposes, but which don't
> > + use an on-flash partition table such as RedBoot.
> > +
> > + Each partition is represented as a sub-node of the flash device.
> > + Each node's name represents the name of the corresponding
> > + partition of the flash device.
>
> Hmm... I'm not thrilled with using the node name for this. For one, the
> node name usually functions more as a node type than a label. It also
> means that spaces can't be used in the name, which is fairly common for
> existing partition maps.
>
> This might be a good time to introduce a standard "label" property.
Hrm, yeah, that's not a bad idea. I'm thinking 'label' is used if
present, otherwise it falls back to the node name.
--
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 6/9] bootwrapper: Add a zImage.bin.<platform> target.
From: David Gibson @ 2007-08-31 3:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070830142115.GB24123@ld0162-tx32.am.freescale.net>
On Thu, Aug 30, 2007 at 09:21:15AM -0500, Scott Wood wrote:
> On Thu, Aug 30, 2007 at 10:34:09AM +1000, David Gibson wrote:
> > Hrm.. I think the --binary option at least should be removed, and
> > subsumed into the platform id - all other binary formats are selected
> > by the platform name at present.
> >
> > And I think it's probably best to do that for --fixed-entry as well,
> > although it's a bit less clear there.
>
> I'm not particularly fond of having huge platform switch blocks in the
> wrapper script -- if it can be reasonably parameterized, why not do so?
Because I'd prefer to keep as much of the per-platform details (what
binary format is needed and so forth) concentrated in wrapper, rather
than scattered across multiple places. I agree we're not really doing
it the best way - I had some ideas for a nicer way to rewrite wrapper,
but I haven't had a chance to implement it yet.
--
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 -mm] pcmcia: Updates to electra_cf driver
From: Olof Johansson @ 2007-08-31 2:43 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, linux-pcmcia, linux-kernel
In-Reply-To: <20070705144914.GA14284@lixom.net>
Fix build of electra_cf, since the IO space setup interfaces were
changed when BenH rewrote it.
Also clean it up a bit, add 5V support, make it unloadable, remove some
dead variables, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
Andrew,
I did this as an incremental patch that you can just merge into the base
one that's already in -mm, but I could merge and resubmit the base patch
instead if you prefer.
(The base patch is
pcmcia-compactflash-driver-for-pa-semi-electra-boards.patch)
-Olof
Index: linux-2.6/drivers/pcmcia/electra_cf.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/electra_cf.c
+++ linux-2.6/drivers/pcmcia/electra_cf.c
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/interrupt.h>
+#include <linux/vmalloc.h>
#include <pcmcia/ss.h>
#include <asm/of_platform.h>
@@ -105,10 +106,8 @@ static int electra_cf_get_status(struct
/* NOTE CF is always 3VCARD */
if (electra_cf_present(cf)) {
- struct electra_cf_socket *cf;
-
*sp = SS_READY | SS_DETECT | SS_POWERON | SS_3VCARD;
- cf = container_of(s, struct electra_cf_socket, socket);
+
s->pci_irq = cf->irq;
} else
*sp = 0;
@@ -134,8 +133,10 @@ static int electra_cf_set_socket(struct
case 33:
gpio = (1 << cf->gpio_3v);
break;
+ case 5:
+ gpio = (1 << cf->gpio_5v);
+ break;
default:
- /* CF is 3.3V only */
return -EINVAL;
}
@@ -188,6 +189,7 @@ static int __devinit electra_cf_probe(st
int status;
const unsigned int *prop;
int err;
+ struct vm_struct *area;
err = of_address_to_resource(np, 0, &mem);
if (err)
@@ -206,22 +208,27 @@ static int __devinit electra_cf_probe(st
cf->ofdev = ofdev;
cf->mem_phys = mem.start;
- cf->mem_base = ioremap(mem.start, mem.end - mem.start);
+ cf->mem_size = PAGE_ALIGN(mem.end - mem.start);
+ cf->mem_base = ioremap(cf->mem_phys, cf->mem_size);
cf->io_size = PAGE_ALIGN(io.end - io.start);
- cf->io_virt = reserve_phb_iospace(cf->io_size);
+ area = __get_vm_area(cf->io_size, 0, PHB_IO_BASE, PHB_IO_END);
+ if (area == NULL)
+ return -ENOMEM;
+
+ cf->io_virt = (void __iomem *)(area->addr);
cf->gpio_base = ioremap(0xfc103000, 0x1000);
dev_set_drvdata(device, cf);
- if (!cf->mem_base || !cf->io_virt || !cf->gpio_base) {
+ if (!cf->mem_base || !cf->io_virt || !cf->gpio_base ||
+ (__ioremap_at(io.start, cf->io_virt, cf->io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED) == NULL)) {
dev_err(device, "can't ioremap ranges\n");
status = -ENOMEM;
goto fail1;
}
- __ioremap_explicit(io.start, (unsigned long)cf->io_virt, cf->io_size,
- _PAGE_NO_CACHE | _PAGE_GUARDED);
cf->io_base = (unsigned long)cf->io_virt - VMALLOC_END;
@@ -263,8 +270,7 @@ static int __devinit electra_cf_probe(st
cf->socket.io_offset = cf->io_base;
/* reserve chip-select regions */
- if (!request_mem_region(mem.start, mem.end + 1 - mem.start,
- driver_name)) {
+ if (!request_mem_region(cf->mem_phys, cf->mem_size, driver_name)) {
status = -ENXIO;
dev_err(device, "Can't claim memory region\n");
goto fail1;
@@ -291,21 +297,22 @@ static int __devinit electra_cf_probe(st
}
dev_info(device, "at mem 0x%lx io 0x%lx irq %d\n",
- mem.start, io.start, cf->irq);
+ cf->mem_phys, io.start, cf->irq);
cf->active = 1;
electra_cf_timer((unsigned long)cf);
return 0;
fail3:
- release_mem_region(io.start, io.end + 1 - io.start);
+ release_region(cf->io_base, cf->io_size);
fail2:
- release_mem_region(mem.start, mem.end + 1 - mem.start);
+ release_mem_region(cf->mem_phys, cf->mem_size);
fail1:
if (cf->irq != NO_IRQ)
free_irq(cf->irq, cf);
- /* XXX No way to undo the ioremap_explicit at this time */
+ if (cf->io_virt)
+ __iounmap_at(cf->io_virt, cf->io_size);
if (cf->mem_base)
iounmap(cf->mem_base);
if (cf->gpio_base)
@@ -328,6 +335,7 @@ static int __devexit electra_cf_remove(s
free_irq(cf->irq, cf);
del_timer_sync(&cf->timer);
+ __iounmap_at(cf->io_virt, cf->io_size);
iounmap(cf->mem_base);
iounmap(cf->gpio_base);
release_mem_region(cf->mem_phys, cf->mem_size);
Index: linux-2.6/drivers/pcmcia/Kconfig
===================================================================
--- linux-2.6.orig/drivers/pcmcia/Kconfig
+++ linux-2.6/drivers/pcmcia/Kconfig
@@ -272,8 +272,8 @@ config AT91_CF
Or choose M to compile the driver as a module named "at91_cf".
config ELECTRA_CF
- bool "Electra CompactFlash Controller"
- depends on PCMCIA=y && PPC_PASEMI
+ tristate "Electra CompactFlash Controller"
+ depends on PCMCIA && PPC_PASEMI
help
Say Y here to support the CompactFlash controller on the
PA Semi Electra eval board.
^ permalink raw reply
* [PATCH] Remove unused variables in driver/ide/ppc/pmac.c
From: Tony Breeds @ 2007-08-31 3:37 UTC (permalink / raw)
To: LinuxPPC-dev, Paul Mackerras, Andrew Morton
Fixes:
CC [M] drivers/ide/ppc/pmac.o
/scratch/tony/tmp/drivers/ide/ppc/pmac.c: In function 'pmac_ide_dma_check':
/scratch/tony/tmp/drivers/ide/ppc/pmac.c:1815: warning: unused variable 'map'
/scratch/tony/tmp/drivers/ide/ppc/pmac.c:1813: warning: unused variable 'pmif'
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/ide/ppc/pmac.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/ide/ppc/pmac.c b/drivers/ide/ppc/pmac.c
index 33630ad..0f5a6b4 100644
--- a/drivers/ide/ppc/pmac.c
+++ b/drivers/ide/ppc/pmac.c
@@ -1810,9 +1810,7 @@ pmac_ide_dma_check(ide_drive_t *drive)
{
struct hd_driveid *id = drive->id;
ide_hwif_t *hwif = HWIF(drive);
- pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
int enable = 1;
- int map;
drive->using_dma = 0;
if (drive->media == ide_floppy)
--
1.5.2.5
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 related
* Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree
From: Grant Likely @ 2007-08-31 4:14 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, Scott Wood
In-Reply-To: <20070831024356.GA19271@localhost.localdomain>
On 8/30/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > CC: Scott Wood <scottwood@freescale.com>
> > CC: Kumar Gala <galak@kernel.crashing.org>
> > CC: David Gibson <david@gibson.dropbear.id.au>
>
> Hrm... I thought Scott had deliberately removed that message in his
> patch set, to work with the way PlanetCore generates Ethernet
> addresses.
I'm confused then. The code either sets the property or it doesn't.
>From what I can see, the message doesn't make any sense in the context
of *not* calling setprop(). How does PlanetCore work? Scott?
g.
>
> > ---
> >
> > arch/powerpc/boot/devtree.c | 14 +++++++-------
> > 1 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
> > index e1b8122..8451a1c 100644
> > --- a/arch/powerpc/boot/devtree.c
> > +++ b/arch/powerpc/boot/devtree.c
> > @@ -99,14 +99,14 @@ void __dt_fixup_mac_addresses(u32 startindex, ...)
> > while ((addr = va_arg(ap, const u8 *))) {
> > devp = find_node_by_prop_value(NULL, "linux,network-index",
> > (void*)&index, sizeof(index));
> > -
> > - printf("ENET%d: local-mac-address <-"
> > - " %02x:%02x:%02x:%02x:%02x:%02x\n\r", index,
> > - addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
> > -
> > - if (devp)
> > + if (devp) {
> > + printf("ENET%d: local-mac-address <-"
> > + " %02x:%02x:%02x:%02x:%02x:%02x\n\r", index,
> > + addr[0], addr[1], addr[2], addr[3], addr[4], addr[5]);
> > setprop(devp, "local-mac-address", addr, 6);
> > -
> > + } else {
> > + printf("ENET%d: no device in tree\n\r", index);
> > + }
> > index++;
> > }
> > va_end(ap);
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
> --
> 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
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/3] bootwrapper: In cuImage, print message for ENET devices not found in tree
From: David Gibson @ 2007-08-31 4:25 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40708302114g77b916bftb01c14e1b3357506@mail.gmail.com>
On Thu, Aug 30, 2007 at 10:14:41PM -0600, Grant Likely wrote:
> On 8/30/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > On Thu, Aug 30, 2007 at 02:26:18PM -0600, Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > > CC: Scott Wood <scottwood@freescale.com>
> > > CC: Kumar Gala <galak@kernel.crashing.org>
> > > CC: David Gibson <david@gibson.dropbear.id.au>
> >
> > Hrm... I thought Scott had deliberately removed that message in his
> > patch set, to work with the way PlanetCore generates Ethernet
> > addresses.
>
> I'm confused then. The code either sets the property or it doesn't.
> >From what I can see, the message doesn't make any sense in the context
> of *not* calling setprop(). How does PlanetCore work? Scott?
Sorry, I was misleading. Scott moved the printf() into the if (devp)
as you do, but *didn't* add the alternative warning message in the
else.
The reason for this is that Planetcore only supplies the first MAC
address, and the bootwrapper must derive the addresses for all the
ENETs from that. That in turn means it is much more convenient to
call fixup_mac_addresses() with more addresses than there are
ethernets, so we don't want a warning message when that happens.
--
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
* libfdt: Fix use of uninitialized variable in fdt_get_path()
From: David Gibson @ 2007-08-31 4:30 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
My recent implemenetation of fdt_get_path() had a bug - the while loop
tested offset which was unitialized on the first iteration. Depending
on code surrounding the call, this could cause fdt_get_path() to
return incorrect results.
This patch corrects the problem by applying some more correct thinking
to the loop condition.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-08-31 14:26:26.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-08-31 14:26:31.000000000 +1000
@@ -302,7 +302,7 @@
buf[0] = '/';
p = 1;
- while (offset < nodeoffset) {
+ while (nextoffset <= nodeoffset) {
offset = nextoffset;
tag = _fdt_next_tag(fdt, offset, &nextoffset);
switch (tag) {
--
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] export new __io{re,un}map_at() symbols
From: Olof Johansson @ 2007-08-31 3:58 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Export new __io{re,un}map_at() symbols so modules can use them.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: mainline/arch/powerpc/mm/pgtable_64.c
===================================================================
--- mainline.orig/arch/powerpc/mm/pgtable_64.c
+++ mainline/arch/powerpc/mm/pgtable_64.c
@@ -228,5 +228,7 @@ void iounmap(volatile void __iomem *toke
EXPORT_SYMBOL(ioremap);
EXPORT_SYMBOL(ioremap_flags);
EXPORT_SYMBOL(__ioremap);
+EXPORT_SYMBOL(__ioremap_at);
EXPORT_SYMBOL(iounmap);
EXPORT_SYMBOL(__iounmap);
+EXPORT_SYMBOL(__iounmap_at);
^ permalink raw reply
* RE: STK5200 pci_enable_device problem
From: Mustafa Cayir @ 2007-08-31 5:38 UTC (permalink / raw)
To: Oliver Rutsch, linuxppc-embedded
In-Reply-To: <46D68BA6.4020102@sympatec.com>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hello Oliver,
My problems continue, could you summarize your steps to bring up the board?
which u-boot version is used?
how build tqm5200.dts file?
did you test pci bus?
Thanks.
-----Original Message-----
From: linuxppc-embedded-bounces+mustafa.cayir=bte.mam.gov.tr@ozlabs.org on behalf of Oliver Rutsch
Sent: Thu 8/30/2007 12:19 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: STK5200 pci_enable_device problem
Hi again,
>
> As mentioned above, with arch/powerpc you always need a device tree
> blob.
>
> Best regards,
>
> Wolfgang Denk
>
Thanks, Wolfang, now it's booting fine!
I've updated u-boot to the newest git version, builded the device tree
file and now everything's working.
Bye,
--
Dipl. Ing. Oliver Rutsch
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 1575 bytes --]
^ permalink raw reply
* dtc: Make make print a message when linking testcases
From: David Gibson @ 2007-08-31 6:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Currently, dtc relies on make's implicit rule to build the testcases.
This means that when not making verbosely (V=0, the default) there is
no message at all while relinking the testsuites. This can be very
confusing when updating libfdt.a (upon which the testcases depend) and
make appears to do nothing.
This patch corrects the situation, borrowing the rule used to link dtc
itself to link all the testcases as well.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-08-31 15:58:40.000000000 +1000
+++ dtc/Makefile 2007-08-31 15:58:59.000000000 +1000
@@ -101,8 +101,6 @@
$(LEX) $<
dtc: $(DTC_OBJS)
- @$(VECHO) LD $@
- $(LINK.c) -o $@ $^
ftdump: ftdump.o
@@ -168,6 +166,10 @@
#
# Generic compile rules
#
+%: %.o
+ @$(VECHO) LD $@
+ $(LINK.c) -o $@ $^
+
%.o: %.c
@$(VECHO) CC $@
$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ -c $<
--
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
* dtc: Optimise by default, fix warnings thus uncovered
From: David Gibson @ 2007-08-31 6:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch turns on optimisation in the Makefile by default. With the
optimizer on, some uninitialized variable warnings (one real, two
bogus) are now generated. This patch also squashes those again.
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-08-31 16:00:25.000000000 +1000
+++ dtc/Makefile 2007-08-31 16:00:28.000000000 +1000
@@ -45,7 +45,7 @@
CPPFLAGS = -I libfdt
-CFLAGS = -Wall -g
+CFLAGS = -Wall -g -Os
LDFLAGS = -Llibfdt
BISON = bison
Index: dtc/tests/truncated_property.c
===================================================================
--- dtc.orig/tests/truncated_property.c 2007-08-31 16:05:27.000000000 +1000
+++ dtc/tests/truncated_property.c 2007-08-31 16:05:38.000000000 +1000
@@ -33,7 +33,6 @@
{
void *fdt = &_truncated_property;
const void *prop;
- int err;
int len;
test_init(argc, argv);
@@ -43,7 +42,7 @@
FAIL("fdt_getprop() succeeded on truncated property");
if (len != -FDT_ERR_BADSTRUCTURE)
FAIL("fdt_getprop() failed with \"%s\" instead of \"%s\"",
- fdt_strerror(err), fdt_strerror(-FDT_ERR_BADSTRUCTURE));
+ fdt_strerror(len), fdt_strerror(-FDT_ERR_BADSTRUCTURE));
PASS();
}
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-08-31 16:08:06.000000000 +1000
+++ dtc/flattree.c 2007-08-31 16:09:29.000000000 +1000
@@ -909,6 +909,7 @@
fprintf(stderr, "\tboot_cpuid_phys:\t0x%x\n",
be32_to_cpu(bph->boot_cpuid_phys));
+ size_str = -1;
if (version >= 3) {
size_str = be32_to_cpu(bph->size_dt_strings);
fprintf(stderr, "\tsize_dt_strings:\t%d\n", size_str);
@@ -932,10 +933,10 @@
inbuf_init(&memresvbuf,
blob + off_mem_rsvmap, blob + totalsize);
inbuf_init(&dtbuf, blob + off_dt, blob + totalsize);
- inbuf_init(&strbuf, blob + off_str, blob + totalsize);
-
- if (version >= 3)
- strbuf.limit = strbuf.base + size_str;
+ if (size_str >= 0)
+ inbuf_init(&strbuf, blob + off_str, blob + off_str + size_str);
+ else
+ inbuf_init(&strbuf, blob + off_str, blob + totalsize);
reservelist = flat_read_mem_reserve(&memresvbuf);
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2007-08-31 16:10:23.000000000 +1000
+++ dtc/dtc.c 2007-08-31 16:12:44.000000000 +1000
@@ -71,7 +71,7 @@
fill_fullpaths(child, tree->fullpath);
}
-static void usage(void)
+static void __attribute__ ((noreturn)) usage(void)
{
fprintf(stderr, "Usage:\n");
fprintf(stderr, "\tdtc [options] <input file>\n");
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2007-08-31 16:13:01.000000000 +1000
+++ dtc/dtc.h 2007-08-31 16:13:07.000000000 +1000
@@ -43,7 +43,7 @@
extern int reservenum; /* Number of memory reservation slots */
extern int minsize; /* Minimum blob size */
-static inline void die(char * str, ...)
+static inline void __attribute__((noreturn)) die(char * str, ...)
{
va_list ap;
--
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: ML403 Hard TEMAC, PLB and Linux 2.6
From: linux-ppc @ 2007-08-31 7:52 UTC (permalink / raw)
To: Mohammad Sadegh Sadri; +Cc: Rick Moleres, linuxppc-embedded
In-Reply-To: <BAY115-W3E40B1AA7056BDABCB768B2F40@phx.gbl>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB2312", Size: 11686 bytes --]
Well, our board is a custom board and we have no problem on inplementing
both TEMAC.
we have
2 TEMAC with related separated hw phy.
sdram controller
can controller
2 uartlite
sysace
graphics lcd interface
and other custom peripherals
external peripheral interface
no problem to fit into FX12..
Mohammad Sadegh Sadri <mamsadegh@hotmail.com>
20/07/2007 11.27
To
Rick Moleres <rick.moleres@xilinx.com>, <linux-ppc@eurotel.it>
cc
Ming Liu <eemingliu@hotmail.com>, <linuxppc-embedded@ozlabs.org>
Subject
RE: ML403 Hard TEMAC, PLB and Linux 2.6
Dear Massimiliano
Well I do not know the solution to the problem, but just,
In your post, there is some thing interesting for me,
How could you implement such large circuit on one FX12 FPGA?
We have done many experineces with both of AVNET MM and ML403,
you have, DDR SDRAM Controller, GPIO, UART, SYSACE and two intances of
Tri-mode TEMAC GMII,
In our tests, with one instance of Tri mode TEMAC and UART and DDR
controller, the whole FPGA resource were consumed we could not even put
sysace interface.
For me, another important question is, how many PHY chips are available on
your board? Each of Tri-mode temac modules are connected to a separate phy
chip, yes?
________________________________
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Date: Thu, 19 Jul 2007 09:00:33 -0600
> From: Rick.Moleres@xilinx.com
> To: linux-ppc@eurotel.it
> CC: eemingliu@hotmail.com; linuxppc-embedded@ozlabs.org;
mamsadegh@hotmail.com
>
> Hi,
> The first thing I would try is to make sure eth1 comes up without first
bringing up eth0. In other words, does it come up independently? If not,
there could be something wrong with its configuration in the kernel or
perhaps a hardware design issue. If both interfaces come up
independently, but not together, then there¡¯s likely a driver issue as we
have not tested dual channel TEMAC with the Linux plb_temac driver.
Perhaps others on the list have. The areas that I would look at would be:
make sure each interface is getting a unique and correct PHY address;
make sure any calls to the shared registers of the two channels are
protected with semaphores/spinlocks. For example, I¡¯m pretty sure the PHY
registers are shared, so any PHY accesses should be protected. I would
think other Xilinx driver accesses like Start/Stop/Reset/Get or
SetOptions/etc¡ should be protected as they may access shared registers.
> -Rick
> ________________________________
> From: Massimiliano.Patriarca@eurotel.it
[mailto:Massimiliano.Patriarca@eurotel.it] On Behalf Of
linux-ppc@eurotel.it
> Sent: Thursday, July 19, 2007 7:51 AM
> To: Rick Moleres
> Cc: Ming Liu; linuxppc-embedded@ozlabs.org;
linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org;
mamsadegh@hotmail.com
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi, we are trying to use both side of an hard temac + 2 plb temac in a
Virtex4FX12 project.
> we succesfull implemented a single temac Montavista tree with eth0.
> when trying to use both temac, devices are correctly registered with
kernel-
> eth0 comes up and working ok-
> when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without
any error or info in the console
> # dmesg
> Linux version 2.6.10_mvl401-ml40x (massimiliano@linux-yhbz) (gcc version
3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18
12:20:43 CEST 2007
> Eurotel motherboard init
> Port by MontaVista Software, Inc. (source@mvista.com)
> On node 0 totalpages: 7812
> DMA zone: 7812 pages, LIFO batch:1
> Normal zone: 0 pages, LIFO batch:1
> HighMem zone: 0 pages, LIFO batch:1
> Built 1 zonelists
> Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off
> Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> PID hash table entries: 128 (order: 7, 2048 bytes)
> hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k
highmem)
> Calibrating delay loop... 252.92 BogoMIPS (lpj=126464)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
> Registering platform device 'xilinx_temac.0'. Parent at platform
> Registering platform device 'xilinx_temac.1'. Parent at platform
> Registering platform device 'xilinx_sysace.0'. Parent at platform
> Registering platform device 'xilinx_gpio.0'. Parent at platform
> Registering platform device 'xilinx_gpio.1'. Parent at platform
> Registering platform device 'oled_fb.0'. Parent at platform
> Generic PHY: Registered new driver
> oled_fb: 4096 video memory mapped to c2011000
> Console: switching to colour frame buffer device 16x8
> xgpio #0 at 0x40000000 mapped to 0xC2020000
> xgpio #1 at 0x40020000 mapped to 0xC2040000
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> loop: loaded (max 8 devices)
> elevator: using anticipatory as default io scheduler
> System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB
> xsysace: xsysace1 xsysace2
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> XTemac: using FIFO direct interrupt driven mode.
> eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0
> eth0: XTemac id 1.0f, block id 5, type 8
> XTemac: using FIFO direct interrupt driven mode.
> eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10
> eth1: XTemac id 1.0f, block id 5, type 8
> i2c /dev entries driver
> i2c-xil_custom: registered with I2C (0)
> i2c-xil_custom: registered with I2C (1)
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on xsysace2, internal journal
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem).
> Freeing unused kernel memory: 124k init
> eth0: XTemac: Options: 0xb8f2
> eth0: XTemac: speed set to 100Mb/s
> eth0: XTemac: PHY Link carrier lost.
> # /sbin/ifconfig eth1 up
> # eth1: XTemac: Options: 0xb8f2
> Any suggestion?
> "Rick Moleres"
> Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org
> 08/02/2007 17.23
> To
> "Ming Liu" ,
> cc
> linuxppc-embedded@ozlabs.org
> Subject
> RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2
as part of the BSP and Libraries generation for Linux 2.6. Note that we
made a recent fix for better PHY address detection and speed negotiation.
I've attached the adapter here, and it will be available in EDK 9.1.1 when
that's released.
> Thanks,
> Rick
> -----Original Message-----
> From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On Behalf
Of Ming Liu
> Sent: Thursday, February 08, 2007 2:31 AM
> To: mamsadegh@hotmail.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> In xapp902, they are using the old cores for Temac. So it will be easier
to
> generate a project in EDK 8.2. Not only the cores there are new, but
also
> it can generate the driver for linux 2.6.
> BR
> Ming
> >From: Mohammad Sadegh Sadri
> >To:
> >CC: linuxppc-embedded@ozlabs.org
> >Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> >Date: Thu, 8 Feb 2007 07:13:47 +0000
> >
> >
> >Hi
> >Thanks for reply
> >Well, regarding xapp902, there is a very simple question, Where can I
find
> it? It seems that Xilinx has deleted all of the links to these files.
> >
> >
> >
> >
> >
> >----------------------------------------
> > > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > > From: christophe.alayrac@cresitt.com
> > > To: mamsadegh@hotmail.com
> > > CC: linuxppc-embedded@ozlabs.org
> > > Date: Thu, 8 Feb 2007 06:51:45 +0100
> > >
> > > Le mercredi 07 février 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > > écrit :
> > > Hi Mohammad,
> > >
> > > Please find here after some answer
> > >
> > > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there
any
> ready to use design, or any reference design available for this?
> > > > I'm using EDK 8.1 and I understood that, when I choose the ML403
> board , EDK does not use hard temac, so , should I add it manually? (
well
> this is funny, but the wizard does not use hard temac , is it true? )
> > > > Is there any ready EDK projects for ML403, with TEMAC and PLB
TEMAC
> modules already inserted and cofigured? (I don't want to use GSRD ) ( If
> yes would you please put the link here )
> > > >
> > > You can start from XAPP 902 from Xilinx, this design demonstrate
TEMAC
> > > use in loopback mode. Some memers from that community have tried
from
> > > that design as a starting point. I did not nknow if the succeed.
> > > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a
new
> > > design with TEMAC.
> > >
> > > > 2- Simply, Is there any driver available for linux 2.6 , for PLB
> TEMAC and Hard TEMAC modules? If yes , can you put the link here, so
that I
> can download it?
> > > >
> > > For the kernel you can get it from Montavista source code site using
> GIT
> > > to download it (linux-xilinx-26). This is 2.6.17.4 version (last
week!)
> > >
> > > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > > TEMAC PAULUS MVISTA with google, or follow my messages in that
mailing
> > > list)
> > > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC,
use
> > > FIFO.
> > >
> > > > thanks
> > > Regards
> > >
> > > Chris
> > > > _________________________________________________________________
> > > > Personalize your Live.com homepage with the news, weather, and
photos
> you care about.
> > > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded@ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >_________________________________________________________________
> >Live Search: New search found
> >http://get.live.com/search/overview
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
[-- Attachment #2: Type: text/html, Size: 14805 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-31 8:57 UTC (permalink / raw)
To: Linas Vepstas
Cc: Thomas Q Klein, Jan-Bernd Themann, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Nathan Lynch, Paul Mackerras,
Stefan Roscher
In-Reply-To: <20070830212816.GA4263@austin.ibm.com>
linas@austin.ibm.com (Linas Vepstas) wrote on 30.08.2007 23:28:16:
> On Thu, Aug 30, 2007 at 04:00:56PM +0200, Joachim Fenkes wrote:
> >
> > Plus, I rather like using
> > the full_name since it also contains a descriptive name as opposed to
> > being just nondescript numbers, helping the layman (ie user) to make
sense
> > out of a dev_id.
>
> [...]
> Location codes are nice.
I sure agree with you. Still, they're not unique, so we can't use them as
bus_id. That's why we're having this discussion at all.
What I meant was "I like using the full_name over using the device address
/ DRC index / you-name-it only". Location code is right out.
Cheers,
Joachim
^ permalink raw reply
* U-Boot + Linux 2.6 on MPC8270
From: eha @ 2007-08-31 8:59 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I need to get a rather current kernel (2.6.22.3 to be precise) to boot on a MPC8270 based embedded target.
What is the right way to adapt to the devtree approach of arch/powerpc? I have an old U-Boot (1.1.2) running on target, able to boot 2.4 kernels.
Best regards,
Esben Haabendal
^ permalink raw reply
* Section mismatch in 2.6.23-rc4
From: Hommel, Thomas (GE Indust, GE Fanuc) @ 2007-08-31 12:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
When compiling a kernel, I get the warnings below.=20
I am using ARCH=3Dpowerpc and 'make mpc8641_hpcn_defconfig', 'make
uImage'. This didn't appear in 2.6.22, but in
arch/powerpc/kernel/head_32.S and setup_32.c, the section info
apparently didn't change.=20
LD vmlinux.o
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x18): Section mismatch: reference to
.init.text:early_init (between '__start' and '__after_mmu_off')
WARNING: vmlinux.o(.text+0x3788): Section mismatch: reference to
.init.text:machine_init (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x3790): Section mismatch: reference to
.init.text:MMU_init (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x37ba): Section mismatch: reference to
.init.text:start_kernel (between 'start_here' and 'set_context')
WARNING: vmlinux.o(.text+0x37be): Section mismatch: reference to
.init.text:start_kernel (between 'start_here' and 'set_context')
LD vmlinux
SYSMAP System.map
^ permalink raw reply
* Re: [PATCH 3/6] ibmveth: Add ethtool TSO handlers
From: Jeff Garzik @ 2007-08-31 13:14 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, rcjenn, santil, netdev
In-Reply-To: <200708171416.l7HEGbwx003958@d01av02.pok.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>
> ---
>
> linux-2.6-bjking1/drivers/net/ibmveth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> 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-08-08 10:46:28.000000000 -0500
> +++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-08-08 10:46:28.000000000 -0500
> @@ -767,6 +767,8 @@ static const struct ethtool_ops netdev_e
> .set_tx_csum = ibmveth_set_tx_csum,
> .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,
This patch is fine, but I wonder if we shouldn't add some code to
net/core/ethtool.c along the lines of...
if (!netdev->ethtool_ops->get_tso)
ethtool_op_get_tso(args);
else
netdev->ethtool_ops->get_tso(args);
Because this certainly seems like desirable behavior across all devices.
^ permalink raw reply
* Re: [PATCH 2/7] fs_enet: Whitespace cleanup.
From: Jeff Garzik @ 2007-08-31 13:19 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, linuxppc-dev
In-Reply-To: <20070817175359.GB9218@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 85 ++++++++++++++++-------------------
> drivers/net/fs_enet/fs_enet.h | 4 +-
> drivers/net/fs_enet/mac-fcc.c | 1 -
> drivers/net/fs_enet/mii-fec.c | 1 -
> 4 files changed, 41 insertions(+), 50 deletions(-)
ACK patches 2-7
^ 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