* [PATCH v2] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Zang Roy-r61911 @ 2007-09-24 10:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, David Gibson
In-Reply-To: <1184144056.23579.16.camel@localhost.localdomain>
From: Roy Zang <tie-fei.zang@freescale.com>
This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
This is the third time for me to generate the patch.
I do not get any negative comment since my previous commit .
Hope your guys can pick it up and merge it into 2.6.24.
The original were pasted at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038952.html
Cheers
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-hpc2.c | 48 ++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc7448hpc2.dts | 5 +++
arch/powerpc/platforms/embedded6xx/Kconfig | 1 +
4 files changed, 56 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hpc2.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cffef14..6ed1415 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-hpc2.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,6 +146,7 @@ image-$(CONFIG_8260) += cuImage.pq2
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
+image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
image-$(CONFIG_BAMBOO) += treeImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
new file mode 100644
index 0000000..d333898
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 70e8a2e..0b58136 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -79,6 +79,7 @@
};
ethernet@6200 {
+ linux,network-index = <0>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi109-ethernet", "tsi108-ethernet";
@@ -91,6 +92,7 @@
};
ethernet@6600 {
+ linux,network-index = <1>;
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -184,5 +186,8 @@
};
};
};
+ chosen {
+ linux,stdout-path = "/tsi108@c0000000/serial@7808";
+ };
};
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 2d12f77..6d10e84 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -20,6 +20,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select WANT_DEVICE_TREE
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 0/3] usb: ehci ppc device-tree-aware driver
From: Valentine Barshak @ 2007-09-24 10:33 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <fd46qj$s6r$1@sea.gmane.org>
Hollis Blanchard wrote:
> On Mon, 17 Sep 2007 16:50:39 +0400, Valentine Barshak wrote:
>
>> Some PowerPC systems have a built-in EHCI controller.
>> This is a device tree aware version of the EHCI controller driver.
>> Currently it's been tested on the PowerPC 440EPx Sequoia board.
>> Other platforms can be added later.
>> The code is based on the ehci-ppc-soc driver by Stefan Roese <sr@denx.de>.
>
> We're having a strange issue on our Sequoia where the network stops
> functioning when USB is active. Jerone can supply more detail...
OK.
This possibly could be caused by the plb write pipelining errata.
Please, take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042999.html
>
> Have you seen anything like that?
No, I haven't.
>
Thanks,
Valentine.
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Valentine Barshak @ 2007-09-24 10:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Olof Johansson, Josh Boyer, Stefan Roese,
David Gibson
In-Reply-To: <1190535664.3723.16.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-09-20 at 12:29 -0500, Josh Boyer wrote:
>> On Thu, 20 Sep 2007 12:25:06 -0500
>> Olof Johansson <olof@lixom.net> wrote:
>>
>>> On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
>>>> I was thinking about it. Looks like it's the best place, but the code that
>>>> actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
>>>> cpu_setup functions are defined for ppc32 processors.
>>>> Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>>> Sounds like something that went wrong at the merge of ppc and ppc64.
>>>
>>> Take out the ifdef, even if there's fallout we should deal with it
>>> instead of adding more complex ifdefs.
>> Yeah. Looks like BenH did this in commit:
>>
>> 42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc
>>
>> Ben, any reason you ifdef'd it for ppc64?
>
> I'll have to check on monday what's up there, but isn't setup_cpu called
> from a different place on 32 bits? There are some subtle difference with
> the way the cpu feature stuff is initialized /done between 32 and 64
> bits that we haven't fully reconciled yet.
>
> Ben.
>
From what I've seen, setup_cpu is never called for BOOKE.
Currently It's called from cputable.c for PPC64 and from head_32.S for 6xx.
Thanks,
Valentine.
>
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c
From: Mel Gorman @ 2007-09-24 11:01 UTC (permalink / raw)
To: Satyam Sharma
Cc: jeff, linuxppc-dev, Linux Kernel Mailing List, kamalesh,
linux-ide, Andrew Morton, Alan Cox
In-Reply-To: <alpine.LFD.0.999.0709220816170.14412@enigma.security.iitk.ac.in>
On (22/09/07 08:20), Satyam Sharma didst pronounce:
> Hi,
>
>
> On Thu, 20 Sep 2007, Alan Cox wrote:
> >
> > On Thu, 20 Sep 2007 14:13:15 +0100
> > mel@skynet.ie (Mel Gorman) wrote:
> >
> > > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > > doesn't show up on other arches because this driver is specific to the
> > > architecture.
> > >
> > > drivers/ata/pata_scc.c: In function `scc_bmdma_status'
> >
> > Its not been updated to match the libata core changes. Try something like
> > this. Whoever is maintaining it should also remove the prereset cable handling
> > code and use the proper cable detect method.
>
> It appears you forgot to fix scc_std_softreset() and one of its callsites
> in scc_bdma_stop(). A complete patch is attempted below -- please review.
>
I can confirm it builds without warnings or errors, so thanks. I'm not in
the position to review it for correctness.
>
> [PATCH -mm] pata_scc: Keep up with libata core API changes
>
> Little fixlets, that the build started erroring / warning about:
>
> drivers/ata/pata_scc.c: In function 'scc_bmdma_status':
> drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag'
> drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
> drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from incompatible pointer type
> drivers/ata/pata_scc.c: In function 'scc_error_handler':
> drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' from incompatible pointer type
> drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' from incompatible pointer type
> drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' from incompatible pointer type
> make[2]: *** [drivers/ata/pata_scc.o] Error 1
>
> Signed-off-by: Satyam Sharma <satyam@infradead.org>
> Cc: Alan Cox <alan@redhat.com>
> Cc: Mel Gorman <mel@skynet.ie>
>
> ---
>
> Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
>
> drivers/ata/pata_scc.c | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff -ruNp a/drivers/ata/pata_scc.c b/drivers/ata/pata_scc.c
> --- a/drivers/ata/pata_scc.c 2007-09-22 06:26:37.000000000 +0530
> +++ b/drivers/ata/pata_scc.c 2007-09-22 08:04:42.000000000 +0530
> @@ -594,16 +594,17 @@ static unsigned int scc_bus_softreset(st
> * Note: Original code is ata_std_softreset().
> */
>
> -static int scc_std_softreset (struct ata_port *ap, unsigned int *classes,
> - unsigned long deadline)
> +static int scc_std_softreset(struct ata_link *link, unsigned int *classes,
> + unsigned long deadline)
> {
> + struct ata_port *ap = link->ap;
> unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
> unsigned int devmask = 0, err_mask;
> u8 err;
>
> DPRINTK("ENTER\n");
>
> - if (ata_link_offline(&ap->link)) {
> + if (ata_link_offline(link)) {
> classes[0] = ATA_DEV_NONE;
> goto out;
> }
> @@ -692,7 +693,7 @@ static void scc_bmdma_stop (struct ata_q
> printk(KERN_WARNING "%s: Internal Bus Error\n", DRV_NAME);
> out_be32(bmid_base + SCC_DMA_INTST, INTSTS_BMSINT);
> /* TBD: SW reset */
> - scc_std_softreset(ap, &classes, deadline);
> + scc_std_softreset(&ap->link, &classes, deadline);
> continue;
> }
>
> @@ -731,7 +732,7 @@ static u8 scc_bmdma_status (struct ata_p
> void __iomem *mmio = ap->ioaddr.bmdma_addr;
> u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
> u32 int_status = in_be32(mmio + SCC_DMA_INTST);
> - struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
> + struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
> static int retry = 0;
>
> /* return if IOS_SS is cleared */
> @@ -860,10 +861,10 @@ static void scc_bmdma_freeze (struct ata
> * @deadline: deadline jiffies for the operation
> */
>
> -static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
> +static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
> {
> - ap->cbl = ATA_CBL_PATA80;
> - return ata_std_prereset(ap, deadline);
> + link->ap->cbl = ATA_CBL_PATA80;
> + return ata_std_prereset(link, deadline);
> }
>
> /**
> @@ -874,8 +875,10 @@ static int scc_pata_prereset(struct ata_
> * Note: Original code is ata_std_postreset().
> */
>
> -static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
> +static void scc_std_postreset(struct ata_link *link, unsigned int *classes)
> {
> + struct ata_port *ap = link->ap;
> +
> DPRINTK("ENTER\n");
>
> /* is double-select really necessary? */
>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Mel Gorman @ 2007-09-24 11:12 UTC (permalink / raw)
To: Satyam Sharma
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List, jeff,
Linux Netdev Mailing List
In-Reply-To: <alpine.LFD.0.999.0709221221500.22517@enigma.security.iitk.ac.in>
On (22/09/07 12:24), Satyam Sharma didst pronounce:
>
>
> On Thu, 20 Sep 2007, Satyam Sharma wrote:
> >
> > BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> > IIRC I got build failures in:
>
> > drivers/net/spider_net.c
>
>
> [PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
>
> Unbreak the following:
>
> drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
> drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once
> drivers/net/spider_net.c:818: error: for each function it appears in.)
> drivers/net/spider_net.c: In function 'spider_net_xmit':
> drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
> drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
> drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this function)
> make[2]: *** [drivers/net/spider_net.o] Error 1
>
> Signed-off-by: Satyam Sharma <satyam@infradead.org>
I've confirmed that this patch fixes the build error in question.
Acked-by: Mel Gorman <mel@csn.ul.ie>
>
> ---
>
> drivers/net/spider_net.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
> --- a/drivers/net/spider_net.c 2007-09-22 06:26:39.000000000 +0530
> +++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.000000000 +0530
> @@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
> static int
> spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
> {
> + struct net_device *dev = card->netdev;
> struct spider_net_descr_chain *chain = &card->tx_chain;
> struct spider_net_descr *descr;
> struct spider_net_hw_descr *hwdescr;
> @@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
> spider_net_release_tx_chain(card, 0);
>
> if (spider_net_prepare_tx_descr(card, skb) != 0) {
> - dev->stats.tx_dropped++;
> + netdev->stats.tx_dropped++;
> netif_stop_queue(netdev);
> return NETDEV_TX_BUSY;
> }
> @@ -979,16 +980,12 @@ static void
> spider_net_pass_skb_up(struct spider_net_descr *descr,
> struct spider_net_card *card)
> {
> - struct spider_net_hw_descr *hwdescr= descr->hwdescr;
> - struct sk_buff *skb;
> - struct net_device *netdev;
> - u32 data_status, data_error;
> -
> - data_status = hwdescr->data_status;
> - data_error = hwdescr->data_error;
> - netdev = card->netdev;
> + struct spider_net_hw_descr *hwdescr = descr->hwdescr;
> + struct sk_buff *skb = descr->skb;
> + struct net_device *netdev = card->netdev;
> + u32 data_status = hwdescr->data_status;
> + u32 data_error = hwdescr->data_error;
>
> - skb = descr->skb;
> skb_put(skb, hwdescr->valid_size);
>
> /* the card seems to add 2 bytes of junk in front
> @@ -1015,8 +1012,8 @@ spider_net_pass_skb_up(struct spider_net
> }
>
> /* update netdevice statistics */
> - dev->stats.rx_packets++;
> - dev->stats.rx_bytes += skb->len;
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += skb->len;
>
> /* pass skb up to stack */
> netif_receive_skb(skb);
> @@ -1184,6 +1181,7 @@ static int spider_net_resync_tail_ptr(st
> static int
> spider_net_decode_one_descr(struct spider_net_card *card)
> {
> + struct net_device *dev = card->netdev;
> struct spider_net_descr_chain *chain = &card->rx_chain;
> struct spider_net_descr *descr = chain->tail;
> struct spider_net_hw_descr *hwdescr = descr->hwdescr;
> @@ -1210,7 +1208,7 @@ spider_net_decode_one_descr(struct spide
> (status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
> (status == SPIDER_NET_DESCR_FORCE_END) ) {
> if (netif_msg_rx_err(card))
> - dev_err(&card->netdev->dev,
> + dev_err(&dev->dev,
> "dropping RX descriptor with state %d\n", status);
> dev->stats.rx_dropped++;
> goto bad_desc;
>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Stefan Roese @ 2007-09-24 11:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46F784B0.1040600@windriver.com>
On Monday 24 September 2007, Andrew Liu wrote:
> By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
And that should be correct for PCI interrupts.
> I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE or
> IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
> It displays:
> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
> eth2: no IPv6 routers present
> NETDEV WATCHDOG: eth2: transmit timed out
> eth2: Transmit timeout, status 0c 0005 c07f media 10.
> eth2: Tx queue start entry 4 dirty entry 0.
> eth2: Tx descriptor 0 is 0008a05a. (queue head)
> eth2: Tx descriptor 1 is 0008a04e.
> eth2: Tx descriptor 2 is 0008a046.
> eth2: Tx descriptor 3 is 0008a05a.
> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> and
> root@localhost:/root> ifconfig eth2
> eth2 Link encap:Ethernet HWaddr 00:0E:2E:7E:F5:E6
> inet addr:128.224.149.13 Bcast:128.224.255.255 Mask:255.255.0.0
> inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Interrupt:25 Base address:0x6f00
>
>
> and
> root@localhost:/root> cat /proc/interrupts
> CPU0
> 2: 0 UIC0 Edge IBM IIC
> 7: 0 UIC0 Edge IBM IIC
> 10: 11961 UIC0 Edge MAL TX EOB
> 11: 18471 UIC0 Edge MAL RX EOB
> 25: 0 UIC0 Edge eth2
> 32: 0 UIC1 Edge MAL SERR
> 33: 0 UIC1 Edge MAL TX DE
> 34: 0 UIC1 Edge MAL RX DE
> 40: 32 UIC1 Edge ohci_hcd:usb1
> 60: 0 UIC1 Edge EMAC
> BAD: 0
>
>
> Can PCI slot use level trigger?
>
> give me some advice.
Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even
earlier? Please give it a try and let us know if the same problem occurs.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Valentine Barshak @ 2007-09-24 11:20 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200709241314.18123.sr@denx.de>
Stefan Roese wrote:
> On Monday 24 September 2007, Andrew Liu wrote:
>> By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
>
> And that should be correct for PCI interrupts.
>
>> I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE or
>> IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
>> It displays:
>> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>> eth2: no IPv6 routers present
>> NETDEV WATCHDOG: eth2: transmit timed out
>> eth2: Transmit timeout, status 0c 0005 c07f media 10.
>> eth2: Tx queue start entry 4 dirty entry 0.
>> eth2: Tx descriptor 0 is 0008a05a. (queue head)
>> eth2: Tx descriptor 1 is 0008a04e.
>> eth2: Tx descriptor 2 is 0008a046.
>> eth2: Tx descriptor 3 is 0008a05a.
>> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>>
>> and
>> root@localhost:/root> ifconfig eth2
>> eth2 Link encap:Ethernet HWaddr 00:0E:2E:7E:F5:E6
>> inet addr:128.224.149.13 Bcast:128.224.255.255 Mask:255.255.0.0
>> inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>> Interrupt:25 Base address:0x6f00
>>
>>
>> and
>> root@localhost:/root> cat /proc/interrupts
>> CPU0
>> 2: 0 UIC0 Edge IBM IIC
>> 7: 0 UIC0 Edge IBM IIC
>> 10: 11961 UIC0 Edge MAL TX EOB
>> 11: 18471 UIC0 Edge MAL RX EOB
>> 25: 0 UIC0 Edge eth2
>> 32: 0 UIC1 Edge MAL SERR
>> 33: 0 UIC1 Edge MAL TX DE
>> 34: 0 UIC1 Edge MAL RX DE
>> 40: 32 UIC1 Edge ohci_hcd:usb1
>> 60: 0 UIC1 Edge EMAC
>> BAD: 0
>>
>>
>> Can PCI slot use level trigger?
>>
>> give me some advice.
This could be caused by misseting the IRQ_lEVEL flag in desc->status.
There have been a commit 4dc7b4b0405fd7320940849b6e31ea8ea68fd0df that
fixes the problem.
Thanks,
Valentine.
>
> Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even
> earlier? Please give it a try and let us know if the same problem occurs.
>
> Best regards,
> Stefan
>
> =====================================================================
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
> =====================================================================
^ permalink raw reply
* [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Valentine Barshak @ 2007-09-24 11:36 UTC (permalink / raw)
To: linuxppc-dev
Currently zImage is linked at the 4MB base address.
Some platforms (using cuboot, treeboot) need the zImage's
entry point and base address. They place zImage exactly
at the base address it's been linked to. Sometimes 4MB left
at the start of the memory is simply not enough to unpack zImage.
This could happen with initramfs enabled, since the kernel image
packed along with initramfs.cpio could be over 5MB in size.
This patch checks vmlinux image size and links zImage at
the base address that is equal to the unpacked image size
aligned to 4MB boundary. This way zImage base address is 4MB
only if unpacked kernel image size is less then 4MB.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/wrapper | 6 ++++--
arch/powerpc/boot/zImage.lds.S | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/boot/wrapper linux-2.6/arch/powerpc/boot/wrapper
--- linux-2.6.orig/arch/powerpc/boot/wrapper 2007-09-22 00:48:08.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/wrapper 2007-09-22 04:03:40.000000000 +0400
@@ -215,8 +215,10 @@
fi
if [ "$platform" != "miboot" ]; then
- ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
- $platformo $tmp $object/wrapper.a
+ kstart=0x`${CROSS}nm "$kernel" | grep ' _start$' | cut -d' ' -f1`
+ kend=0x`${CROSS}nm "$kernel" | grep ' _end$' | cut -d' ' -f1`
+ ${CROSS}ld -m elf32ppc --defsym _kstart=$kstart --defsym _kend=$kend \
+ -T $lds -o "$ofile" $platformo $tmp $object/wrapper.a
rm $tmp
fi
diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
--- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
@@ -3,7 +3,7 @@
EXTERN(_zimage_start)
SECTIONS
{
- . = (4*1024*1024);
+ . = ALIGN((_kend - _kstart), (4*1024*1024));
_start = .;
.text :
{
^ permalink raw reply
* multicast in MPC8272ADS
From: Nethra @ 2007-09-24 11:53 UTC (permalink / raw)
To: linuxppc-embedded
hi,
I have written a multicast test application in which there is a multicast
sender and receiver.
The multicast sender sends multicast packets on a specified interface and
the multicast
receiver receives multicast packets. I have tested this application on my
network with
x86 machines. But when I run a multicast receiver (which has been cross
compiled for
MPC8272ADS) on my MPC board, it is unable to receive multicast packets (the
recvfrom
call is waiting for ever for packets to arrive). The MPC board is able to
send multicast
packets to without any problems. The /proc/net/dev_mcast shows the
appropriate
entries for the multicast address being enabled for the interface of
interest(esentially
group joining appear to work).
My configuration is a MPC8272ADS board rp_filter =0 for all interfaces (ie
no source
filtering).I am wondering where the problem could be, configurations or the
ethernet
driver itself? Are there some known issues ?
By the way with loopback enabled the reception of packets works
in case the sender and receiver are on the same machine
waiting for ur comments..
thnks
--
View this message in context: http://www.nabble.com/multicast-in-MPC8272ADS-tf4508713.html#a12858422
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: Josh Boyer @ 2007-09-24 12:03 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46F76C0D.5090006@grandegger.com>
On Mon, 24 Sep 2007 09:49:33 +0200
Wolfgang Grandegger <wg@grandegger.com> wrote:
>
> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
>
> MODPOST vmlinux.o
> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
> .init.text:prom_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
> .init.text:early_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
> .init.text:machine_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
> .init.text:MMU_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD vmlinux
> SYSMAP System.map
> BOOTAS arch/powerpc/boot/string.o
> BOOTAS arch/powerpc/boot/crt0.o
> BOOTCC arch/powerpc/boot/stdio.o
> BOOTCC arch/powerpc/boot/main.o
> BOOTCC arch/powerpc/boot/flatdevtree.o
> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
> BOOTCC arch/powerpc/boot/ns16550.o
> BOOTCC arch/powerpc/boot/serial.o
> BOOTCC arch/powerpc/boot/simple_alloc.o
> BOOTAS arch/powerpc/boot/div64.o
> BOOTAS arch/powerpc/boot/util.o
> BOOTCC arch/powerpc/boot/gunzip_util.o
> BOOTCC arch/powerpc/boot/elf_util.o
> BOOTCC arch/powerpc/boot/inffast.o
> BOOTCC arch/powerpc/boot/inflate.o
> BOOTCC arch/powerpc/boot/inftrees.o
> BOOTCC arch/powerpc/boot/devtree.o
> BOOTCC arch/powerpc/boot/oflib.o
> BOOTCC arch/powerpc/boot/ofconsole.o
> BOOTCC arch/powerpc/boot/4xx.o
> BOOTCC arch/powerpc/boot/ebony.o
> BOOTCC arch/powerpc/boot/mv64x60.o
> BOOTCC arch/powerpc/boot/mpsc.o
> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
> BOOTCC arch/powerpc/boot/cuboot.o
> BOOTCC arch/powerpc/boot/bamboo.o
> BOOTAR arch/powerpc/boot/wrapper.a
> BOOTCC arch/powerpc/boot/of.o
> BOOTCC arch/powerpc/boot/cuboot-83xx.o
> BOOTCC arch/powerpc/boot/cuboot-85xx.o
> BOOTCC arch/powerpc/boot/holly.o
> BOOTCC arch/powerpc/boot/cuboot-ebony.o
> BOOTCC arch/powerpc/boot/treeboot-ebony.o
> BOOTCC arch/powerpc/boot/prpmc2800.o
> BOOTAS arch/powerpc/boot/ps3-head.o
> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> {standard input}: Assembler messages:
> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> make: *** [uImage] Error 2
>
> It looks like the ppc_6xx toolchain does not know the opcode above. I
> wonder why files for other PowerPC sub-archs like 4xx are compiled with
> the wrong compiler. Have I missed something?
No, you haven't missed anything. I need a one line patch to fix it.
Could you try the patch below to make sure it works for you?
> And the WARNING above on "Section mismatch" looks strange as well (still
> present in 2.6.23-rc7).
Those warnings should be gone with Paul's latest tree. (They will
remain for 2.6.23.)
josh
Pass the correct -mcpu option for treeboot-walnut.o to avoid
unrecognized opcodes.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..8e6d36b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,6 +33,7 @@ BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
^ permalink raw reply related
* Re: [patch 6/6] Walnut zImage wrapper
From: Wolfgang Grandegger @ 2007-09-24 12:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070924070312.3dee3dd9@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 24 Sep 2007 09:49:33 +0200
> Wolfgang Grandegger <wg@grandegger.com> wrote:
>> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
>> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
>>
>> MODPOST vmlinux.o
>> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
>> .init.text:prom_init (between '__start' and '__after_mmu_off')
>> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
>> .init.text:early_init (between '__start' and '__after_mmu_off')
>> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
>> .init.text:machine_init (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
>> .init.text:MMU_init (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
>> .init.text:start_kernel (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
>> .init.text:start_kernel (between 'start_here' and 'set_context')
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD vmlinux
>> SYSMAP System.map
>> BOOTAS arch/powerpc/boot/string.o
>> BOOTAS arch/powerpc/boot/crt0.o
>> BOOTCC arch/powerpc/boot/stdio.o
>> BOOTCC arch/powerpc/boot/main.o
>> BOOTCC arch/powerpc/boot/flatdevtree.o
>> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
>> BOOTCC arch/powerpc/boot/ns16550.o
>> BOOTCC arch/powerpc/boot/serial.o
>> BOOTCC arch/powerpc/boot/simple_alloc.o
>> BOOTAS arch/powerpc/boot/div64.o
>> BOOTAS arch/powerpc/boot/util.o
>> BOOTCC arch/powerpc/boot/gunzip_util.o
>> BOOTCC arch/powerpc/boot/elf_util.o
>> BOOTCC arch/powerpc/boot/inffast.o
>> BOOTCC arch/powerpc/boot/inflate.o
>> BOOTCC arch/powerpc/boot/inftrees.o
>> BOOTCC arch/powerpc/boot/devtree.o
>> BOOTCC arch/powerpc/boot/oflib.o
>> BOOTCC arch/powerpc/boot/ofconsole.o
>> BOOTCC arch/powerpc/boot/4xx.o
>> BOOTCC arch/powerpc/boot/ebony.o
>> BOOTCC arch/powerpc/boot/mv64x60.o
>> BOOTCC arch/powerpc/boot/mpsc.o
>> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
>> BOOTCC arch/powerpc/boot/cuboot.o
>> BOOTCC arch/powerpc/boot/bamboo.o
>> BOOTAR arch/powerpc/boot/wrapper.a
>> BOOTCC arch/powerpc/boot/of.o
>> BOOTCC arch/powerpc/boot/cuboot-83xx.o
>> BOOTCC arch/powerpc/boot/cuboot-85xx.o
>> BOOTCC arch/powerpc/boot/holly.o
>> BOOTCC arch/powerpc/boot/cuboot-ebony.o
>> BOOTCC arch/powerpc/boot/treeboot-ebony.o
>> BOOTCC arch/powerpc/boot/prpmc2800.o
>> BOOTAS arch/powerpc/boot/ps3-head.o
>> BOOTAS arch/powerpc/boot/ps3-hvcall.o
>> BOOTCC arch/powerpc/boot/ps3.o
>> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
>> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
>> BOOTCC arch/powerpc/boot/treeboot-walnut.o
>> {standard input}: Assembler messages:
>> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
>> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
>> make: *** [uImage] Error 2
>>
>> It looks like the ppc_6xx toolchain does not know the opcode above. I
>> wonder why files for other PowerPC sub-archs like 4xx are compiled with
>> the wrong compiler. Have I missed something?
>
> No, you haven't missed anything. I need a one line patch to fix it.
> Could you try the patch below to make sure it works for you?
It works for me with one typo corrected (see below).
>
>> And the WARNING above on "Section mismatch" looks strange as well (still
>> present in 2.6.23-rc7).
>
> Those warnings should be gone with Paul's latest tree. (They will
> remain for 2.6.23.)
OK.
> Pass the correct -mcpu option for treeboot-walnut.o to avoid
> unrecognized opcodes.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index c1582b6..8e6d36b 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -33,6 +33,7 @@ BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
>
> $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
> $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
> +$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
^^^^^^^^^ typo, should be BOOTCFLAGS
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: Josh Boyer @ 2007-09-24 12:25 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46F7AB94.9060007@grandegger.com>
On Mon, 24 Sep 2007 14:20:36 +0200
Wolfgang Grandegger <wg@grandegger.com> wrote:
> Josh Boyer wrote:
> > On Mon, 24 Sep 2007 09:49:33 +0200
> > Wolfgang Grandegger <wg@grandegger.com> wrote:
> >> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
> >> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
> >>
> >> MODPOST vmlinux.o
> >> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
> >> .init.text:prom_init (between '__start' and '__after_mmu_off')
> >> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
> >> .init.text:early_init (between '__start' and '__after_mmu_off')
> >> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
> >> .init.text:machine_init (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
> >> .init.text:MMU_init (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
> >> .init.text:start_kernel (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
> >> .init.text:start_kernel (between 'start_here' and 'set_context')
> >> GEN .version
> >> CHK include/linux/compile.h
> >> UPD include/linux/compile.h
> >> CC init/version.o
> >> LD init/built-in.o
> >> LD vmlinux
> >> SYSMAP System.map
> >> BOOTAS arch/powerpc/boot/string.o
> >> BOOTAS arch/powerpc/boot/crt0.o
> >> BOOTCC arch/powerpc/boot/stdio.o
> >> BOOTCC arch/powerpc/boot/main.o
> >> BOOTCC arch/powerpc/boot/flatdevtree.o
> >> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
> >> BOOTCC arch/powerpc/boot/ns16550.o
> >> BOOTCC arch/powerpc/boot/serial.o
> >> BOOTCC arch/powerpc/boot/simple_alloc.o
> >> BOOTAS arch/powerpc/boot/div64.o
> >> BOOTAS arch/powerpc/boot/util.o
> >> BOOTCC arch/powerpc/boot/gunzip_util.o
> >> BOOTCC arch/powerpc/boot/elf_util.o
> >> BOOTCC arch/powerpc/boot/inffast.o
> >> BOOTCC arch/powerpc/boot/inflate.o
> >> BOOTCC arch/powerpc/boot/inftrees.o
> >> BOOTCC arch/powerpc/boot/devtree.o
> >> BOOTCC arch/powerpc/boot/oflib.o
> >> BOOTCC arch/powerpc/boot/ofconsole.o
> >> BOOTCC arch/powerpc/boot/4xx.o
> >> BOOTCC arch/powerpc/boot/ebony.o
> >> BOOTCC arch/powerpc/boot/mv64x60.o
> >> BOOTCC arch/powerpc/boot/mpsc.o
> >> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
> >> BOOTCC arch/powerpc/boot/cuboot.o
> >> BOOTCC arch/powerpc/boot/bamboo.o
> >> BOOTAR arch/powerpc/boot/wrapper.a
> >> BOOTCC arch/powerpc/boot/of.o
> >> BOOTCC arch/powerpc/boot/cuboot-83xx.o
> >> BOOTCC arch/powerpc/boot/cuboot-85xx.o
> >> BOOTCC arch/powerpc/boot/holly.o
> >> BOOTCC arch/powerpc/boot/cuboot-ebony.o
> >> BOOTCC arch/powerpc/boot/treeboot-ebony.o
> >> BOOTCC arch/powerpc/boot/prpmc2800.o
> >> BOOTAS arch/powerpc/boot/ps3-head.o
> >> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> >> BOOTCC arch/powerpc/boot/ps3.o
> >> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> >> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> >> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> >> {standard input}: Assembler messages:
> >> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> >> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> >> make: *** [uImage] Error 2
> >>
> >> It looks like the ppc_6xx toolchain does not know the opcode above. I
> >> wonder why files for other PowerPC sub-archs like 4xx are compiled with
> >> the wrong compiler. Have I missed something?
> >
> > No, you haven't missed anything. I need a one line patch to fix it.
> > Could you try the patch below to make sure it works for you?
>
> It works for me with one typo corrected (see below).
Ah, yes. That's what I get for coding before coffee.
Thanks Wolfgang.
josh
^ permalink raw reply
* 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Andy Whitcroft @ 2007-09-24 12:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070924021716.9bfe7dfb.akpm@linux-foundation.org>
Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000047ac8
cpu 0x0: Vector: 300 (Data Access) at [c00000000058f750]
pc: c000000000047ac8: .pSeries_log_error+0x364/0x420
lr: c000000000047a4c: .pSeries_log_error+0x2e8/0x420
sp: c00000000058f9d0
msr: 8000000000001032
dar: 0
dsisr: 42000000
current = 0xc0000000004a9b30
paca = 0xc0000000004aa700
pid = 0, comm = swapper
enter ? for help
[c00000000058faf0] c000000000021164 .rtas_call+0x200/0x250
[c00000000058fba0] c000000000049cd0 .early_enable_eeh+0x168/0x360
[c00000000058fc70] c00000000002f674 .traverse_pci_devices+0x8c/0x138
[c00000000058fd10] c000000000460ce8 .eeh_init+0x1a8/0x200
[c00000000058fdb0] c00000000045fb70 .pSeries_setup_arch+0x128/0x234
[c00000000058fe40] c00000000044f830 .setup_arch+0x214/0x24c
[c00000000058fee0] c000000000446a38 .start_kernel+0xd4/0x3e4
[c00000000058ff90] c000000000373194 .start_here_common+0x54/0x58
This machine is a:
processor : 0
cpu : POWER4+ (gq)
clock : 1703.965296MHz
revision : 19.0
[...]
timebase : 212995662
machine : CHRP IBM,7040-681
-apw
^ permalink raw reply
* Re: [PATCH0/4] Various bug fixes
From: Marcelo Tosatti @ 2007-09-24 12:43 UTC (permalink / raw)
To: Jochen Friedrich, Paul Mackerras; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F6C9B0.8020200@scram.de>
Paul, please apply.
On Sun, Sep 23, 2007 at 10:16:48PM +0200, Jochen Friedrich wrote:
> Here is a series fixing some bugs for 8xx powerpc CPUs.
>
> 1. [POWERPC] Fix copy'n'paste typo in commproc.c
> 2. [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
> 3. [PPC] Compile fix for 8xx CPM Ehernet driver
> 4. [POWERPC] Fix cpm_uart driver
>
> This series can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
>
> Thanks,
> Jochen
^ permalink raw reply
* DMA Generic Task API
From: Pedro Luis D. L. @ 2007-09-24 14:06 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
As I wrote before, I'm trying to use the DMA API to copy audio data to the =
PSC1 which has a digital - analog - converter attached to it.
I read the explanation that Sylvain wrote at: http://ozlabs.org/pipermail/l=
inuxppc-dev/2007-May/036229.html and programmed the following code:
static void SPI_setup(void)
{
int psc_num =3D 1;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
struct bcom_bd *bd;
uint32 SICR;
psc =3D ioremap(MPC52xx_PA(MPC52xx_PSCx_OFFSET(1)), MPC52xx_PSC_SIZE);
=09
gpio =3D ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
=09
cdm =3D ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
switch(psc_num) {
case 1:
initiator_tx =3D BCOM_INITIATOR_PSC1_TX;
initiator_rx =3D BCOM_INITIATOR_PSC1_RX;
break;
case 2:
initiator_tx =3D BCOM_INITIATOR_PSC2_TX;
initiator_rx =3D BCOM_INITIATOR_PSC2_RX;
break;
default:
panic("snd-SPImgt.o: invalid value for psc_num (%i)\n",psc_num);
break;
};
=09
printk("Before gpio->port_config\n");
gpio->port_config |=3D PORT_CONFIG_PSC1;
printk("Before cdm->clk_enables\n");
cdm->clk_enables |=3D PSC1_CLK_EN;
printk("Before cdm->mclken_div_psc1\n");
cdm->mclken_div_psc1 =3D MCLKEN_DIV;
=09
SICR =3D 0x02000000;
SICR |=3D 0x00002000;
SICR |=3D 0x0090C000;
=09
psc->command =3D 0x0A;
psc->sicr =3D SICR;
psc->ctur =3D 0x00;
psc->ctlr =3D 0x84;
psc->ccr &=3D 0xFF0000FF;
psc->rfalarm =3D 0x000C; /* alarm occurs if 12 bytes space in the RxFIFO =
*/
psc->tfalarm =3D 0x0010; /* alarm occurs if 16 bytes are in the TxFIFO */
psc->rfcntl &=3D 0xF8; /* set granularity to 0 */
psc->tfcntl &=3D 0xF8; /* set granularity to 0 */
psc->isr_imr.isr =3D 0x01;
psc->isr_imr.imr =3D 0x00; /* enable TxRDY interrupt */=20
psc->mode =3D 0x00; /* set RX interrupt to RxRDY */
psc->command =3D 0x05; /* enable Tx and Rx */
psc->tfdata =3D 0xF001;
wait(1000);
psc->tfdata =3D 0xF000;
printk("Before bcom_gen_bd_rx_init\n");
rx_bcom =3D bcom_gen_bd_rx_init(64, (phys_addr_t)&(psc->rfdata), initiato=
r_rx, 6, 1024);
printk("Before bcom_gen_bd_tx_init\n");
tx_bcom =3D bcom_gen_bd_tx_init(64, (phys_addr_t)&(psc->tfdata), initiato=
r_tx, 6);
printk("txtask is %d rxtask is %d\n", tx_bcom->tasknum, rx_bcom->tasknum);
r_irq =3D bcom_get_task_irq(rx_bcom);
t_irq =3D bcom_get_task_irq(tx_bcom);
=09
printk("t_irq is %d r_irq is %d\n", t_irq, r_irq);
if (request_irq(r_irq, &SPI_rx_irq, IRQF_DISABLED, "SPI rx dma", NULL)) {
printk(KERN_ERR "SPI: SDMA rx irq allocation failed\n");
return;
} else printk("SPI: SDA rx irq allocation succeded\n");
if (request_irq(t_irq, &SPI_tx_irq, IRQF_DISABLED, "SPI tx dma", NULL)) {
printk(KERN_ERR "SPI: SDMA tx irq allocation failed\n");
return;
} else printk("SPI: SDA tx irq allocation succeded\n");
bcom_gen_bd_tx_reset(tx_bcom);
bcom_gen_bd_rx_reset(rx_bcom);
bcom_retrieve_buffer(tx_bcom, NULL, NULL);
bd =3D bcom_prepare_next_buffer(tx_bcom);
bd->status =3D 1024;
bd->data[0] =3D (void *)SPI_tx_silence.pa;
bcom_submit_next_buffer(tx_bcom, (void *)SPI_tx_silence.pa);
bcom_dump_bdring(tx_bcom);
bcom_dump_bdring(rx_bcom);
printk("Tasks enabled\n");
psc->command =3D MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE;
=09
}
Although everything seems to be executed without problems, the interrupt ro=
utines are never called, and no data seems to be copied to the PSC.
Could it be that I don=B4t understand the purpose of bd->data and bd->stat=
us correctly? Is there any other Documentation or example code I can take a=
look and learn how to use the API?
Thanks,
Pedro L. Dominguez
carcadiz@hotmail.com
_________________________________________________________________
Consigue el nuevo Windows Live Messenger
http://get.live.com/messenger/overview=
^ permalink raw reply
* Cypress C67x00 driver connects ?
From: Robertson, Joseph M. @ 2007-09-24 14:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]
Hi,
Can I connect the c67x00 driver directly to the USB bus?
I have a device, a virtex4 fpga, with no PCI bus. I have a fpga bus to the cypress chip (c67300).
I have compiled the core USB code (but no uhci ohci).
It loads ok, detects and loads 2 host sies. I get interrupts for all that (and the 3 mailbox puts I do).
But I was just connecting to 'platfom_bus_type'. After all that I get no more interrupts.
The kernel drivers textbook doesn't quite match anymore, links to .hotplug in structs have moved.
Pointers to websites and papers appreciated.
I am using a custom kernel tree, 2.6.17.1, some of Grant Likely stuff is already in there (from the original developer on this project).
Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2423 bytes --]
^ permalink raw reply
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: Scott Wood @ 2007-09-24 14:52 UTC (permalink / raw)
To: Peter Korsgaard, Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20070924050709.GM8058@localhost.localdomain>
David Gibson wrote:
>> i2c@3100 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> device_type = "i2c";
>
> Hrm... we probably want an "i2c" device_type class, but I don't think
> we've actually defined one, which is a problem
Right... but we need to get the kernel to stop expecting the device type
to be there before we yell at people for including it. :-)
> The fact that NVRAM+RTC chips are so common is a bit of an issue from
> the point of view of defining a device class binding - a device can't
> have type "rtc" and "nvram".
This is one of the reasons that I'd prefer to use compatible for such
things.
-Scott
^ permalink raw reply
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-24 15:57 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F6C9DC.90008@scram.de>
Jochen Friedrich wrote:
>
> In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc
> an offset into DP RAM is calculated by substracting a physical
> memory constant from an virtual address. This patch fixes the
> problem by converting the virtual address into a physical
> first.
Huh? DPRAM_BASE is a virtual address. With this patch, you'd be
subtracting a virtual address from a physical address.
-Scott
^ permalink raw reply
* Problems compiling Linux for MPC8272ADS
From: Manil Gaouar @ 2007-09-24 16:26 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I am trying to compile the latest Linux from the git repos: git clone
git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
the code a few weeks ago and was able to build my uImage no problems. I
did a git pull this morning and I can not compile anymore, here is the
error message I have:
BOOTCC arch/powerpc/boot/ps3.o
BOOTCC arch/powerpc/boot/treeboot-bamboo.o
BOOTCC arch/powerpc/boot/cuboot-sequoia.o
BOOTCC arch/powerpc/boot/treeboot-walnut.o
{standard input}: Assembler messages:
{standard input}:184: Error: Unrecognized opcode: `mfdcr'
{standard input}:185: Error: Unrecognized opcode: `mfdcr'
{standard input}:186: Error: Unrecognized opcode: `mfdcr'
{standard input}:217: Error: Unrecognized opcode: `mtdcr'
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
make: *** [uImage] Error 2
here are the commands I am using:
make mrproper
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- mpc8272_ads_defconfig
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- uImage
Do you have any ideas, or I should check out the 2.6.22 stable release
instead and try again???
Thx
^ permalink raw reply
* Re: Problems compiling Linux for MPC8272ADS
From: Alan Bennett @ 2007-09-24 16:46 UTC (permalink / raw)
To: Manil Gaouar; +Cc: linuxppc-dev
In-Reply-To: <9A1468054ED2FD40907CC3B2C1871D400106CC90@hermes.versatel.com>
I added this to my boot/Makefile near the other mcpu=440 lines. I
believe there may be a fix coming?
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=440
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
On 9/24/07, Manil Gaouar <mgaouar@solacom.com> wrote:
> Hi there,
>
> I am trying to compile the latest Linux from the git repos: git clone
> git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
> the code a few weeks ago and was able to build my uImage no problems. I
> did a git pull this morning and I can not compile anymore, here is the
> error message I have:
>
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> {standard input}: Assembler messages:
> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> make: *** [uImage] Error 2
>
> here are the commands I am using:
>
> make mrproper
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage
>
> Do you have any ideas, or I should check out the 2.6.22 stable release
> instead and try again???
>
> Thx
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Problems compiling Linux for MPC8272ADS
From: Josh Boyer @ 2007-09-24 16:56 UTC (permalink / raw)
To: Manil Gaouar; +Cc: linuxppc-dev
In-Reply-To: <9A1468054ED2FD40907CC3B2C1871D400106CC90@hermes.versatel.com>
On Mon, 24 Sep 2007 12:26:24 -0400
"Manil Gaouar" <mgaouar@solacom.com> wrote:
> Hi there,
>
> I am trying to compile the latest Linux from the git repos: git clone
> git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
> the code a few weeks ago and was able to build my uImage no problems. I
> did a git pull this morning and I can not compile anymore, here is the
> error message I have:
>
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> {standard input}: Assembler messages:
> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> make: *** [uImage] Error 2
>
> here are the commands I am using:
>
> make mrproper
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- mpc8272_ads_defconfig
> make ARCH=powerpc CROSS_COMPILE=ppc_6xx- uImage
>
> Do you have any ideas, or I should check out the 2.6.22 stable release
> instead and try again???
Apply this:
[POWERPC] 4xx: Fix Walnut wrapper compile errors
Pass the appropriate -mcpu flag to the treeboot-walnut.o object to prevent
some toolchains from erroring out with unknown opcodes
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..ac516a1 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,6 +33,7 @@ BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
^ permalink raw reply related
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Jochen Friedrich @ 2007-09-24 17:06 UTC (permalink / raw)
To: Scott Wood; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F7DE85.7000401@freescale.com>
Scott Wood schrieb:
> Jochen Friedrich wrote:
>>
>> In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc
>> an offset into DP RAM is calculated by substracting a physical
>> memory constant from an virtual address. This patch fixes the
>> problem by converting the virtual address into a physical
>> first.
>
> Huh? DPRAM_BASE is a virtual address. With this patch, you'd be
> subtracting a virtual address from a physical address.
Thanks for pointing me to it. So the bug is in cpm_uart_cpm1.h assigning
a physical memory to DPRAM_BASE (at least on ARC=ppc). cpm_uart_cpm2.h
seems to be correct though. I'll submit a new patch for this.
Thanks,
Jochen
^ permalink raw reply
* [PATCH#2 0/4] Various bug fixes
From: Jochen Friedrich @ 2007-09-24 17:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
Here is a series fixing some bugs for 8xx powerpc CPUs.
1. [POWERPC] Fix copy'n'paste typo in commproc.c
2. [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
3. [PPC] Compile fix for 8xx CPM Ehernet driver
4. [POWERPC] Fix cpm_uart driver (updated)
This series can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
Thanks,
Jochen
^ permalink raw reply
* [PATCH#2 1/4] [POWERPC] Fix copy'n'paste typo in commproc.c
From: Jochen Friedrich @ 2007-09-24 17:13 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 984 bytes --]
The powerpc version of commproc.c exports cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/commproc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: ef0b35e6f35cd911148c86f0b73cce536968d5b5.diff --]
[-- Type: text/x-patch, Size: 355 bytes --]
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
^ permalink raw reply related
* [PATCH#2 2/4] [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
From: Jochen Friedrich @ 2007-09-24 17:14 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.
This patch fixes the problem (copied from the powerpc tree).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/ppc/8xx_io/commproc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
[-- Attachment #2: e99a679ff14fb0073efd9220f5aa933e47516202.diff --]
[-- Type: text/x-patch, Size: 399 bytes --]
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..9da880b 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -459,7 +459,7 @@ EXPORT_SYMBOL(cpm_dpdump);
void *cpm_dpram_addr(unsigned long offset)
{
- return ((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem + offset;
+ return (void *)(dpram_vbase + offset);
}
EXPORT_SYMBOL(cpm_dpram_addr);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox