Re: New Patchwork beta
On Aug 21, 2008, at 5:52 PM, Josh Boyer wrote: On Thu, 2008-08-21 at 15:32 -0500, Kumar Gala wrote: Some feedback: * Can we increase the font size a bit? NOO. Just use CTRL-SHIFT-+. ok * For the list of patches can we change the background of every other line (light gray) That would work well. thanks this looks better, easier to read. * Parsing subject header for determining state -- [RFC] That is going to fail miserably because people tend to do silly things like post final patches in the middle of an [RFC] thread. gotcha. Now that I can log in, can I get maintainer privileges (user: galak) also is it possible to put the patch controls in a separate frame so they are always visible (dont have to scoll to the bottom to find them). - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC 4XX PCIe MSI support
On Friday 22 August 2008, [EMAIL PROTECTED] wrote:
From: Preetesh Parekh [EMAIL PROTECTED]
Thanks.
First of all, this does not apply on the current Linux kernel version
(2.6.27-rc4). I fixed this manually and tried the patch on my Kilauea. It
does not work. Something seems to be missing. Don't we need a device-tree
integration (MSI node)? How did you test this BTW?
Please find more comments below.
Signed-off-by: Preetesh Parekh [EMAIL PROTECTED]
---
arch/powerpc/platforms/40x/kilauea.c | 13
arch/powerpc/platforms/44x/canyonlands.c | 14
arch/powerpc/sysdev/ppc4xx_pci.c | 115
++ arch/powerpc/sysdev/ppc4xx_pci.h |
45
include/asm-powerpc/dcr-native.h | 12 +++
5 files changed, 199 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/kilauea.c
b/arch/powerpc/platforms/40x/kilauea.c index 1dd24ff..3610be2 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -22,6 +22,11 @@
#include asm/pci-bridge.h
#include asm/ppc4xx.h
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = ibm,plb4, },
{ .compatible = ibm,opb, },
@@ -46,6 +51,14 @@ static int __init kilauea_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+#ifdef CONFIG_PCI_MSI
+ /*
+ * Setting callback functions for MSI support
+ */
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+#endif
This belongs into the (to be written) of_platform driver/interface for the MSI
support.
return 1;
}
diff --git a/arch/powerpc/platforms/44x/canyonlands.c
b/arch/powerpc/platforms/44x/canyonlands.c index 3949289..ee38fb7 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -25,6 +25,12 @@
#include asm/pci-bridge.h
#include asm/ppc4xx.h
+
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
static __initdata struct of_device_id canyonlands_of_bus[] = {
{ .compatible = ibm,plb4, },
{ .compatible = ibm,opb, },
@@ -49,6 +55,14 @@ static int __init canyonlands_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+#ifdef CONFIG_PCI_MSI
+ /*
+ * Setting callback functions for MSI support
+ */
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+#endif
+
return 1;
}
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
b/arch/powerpc/sysdev/ppc4xx_pci.c index fb368df..bdb3663 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -35,6 +35,11 @@
static int dma_offset_set;
+#ifdef CONFIG_PCI_MSI
+#include linux/msi.h
+#include ../../../drivers/pci/msi.h
Is this really needed?
+#endif
+
/* Move that to a useable header */
extern unsigned long total_memory;
@@ -1587,12 +1592,26 @@ static void __init
ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port) out_le16(mbase
+ 0x202, val);
if (!port-endpoint) {
+#ifdef CONFIG_PCI_MSI
+ /* Set MSI enable, multiple msg cap = 4 */
+ /* 4 messages allocated, 64 bit capability */
+ out_le32(mbase + 0x048, in_le32(mbase + 0x048) | 0x00a5);
+
+ /* Enable interrupts in BCR */
+ out_le32(mbase + 0x03C, in_le32(mbase + 0x03C) | 0xFF00);
+#endif
+
/* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
out_le32(mbase + 0x208, 0x06040001);
printk(KERN_INFO PCIE%d: successfully set as root-complex\n,
port-index);
} else {
+#ifdef CONFIG_PCI_MSI
+ /* Enable MSI for End-Point */
+ out_le32(mbase + 0x048, (in_le32(mbase + 0x048) | 0x00a5));
+#endif
+
/* Set Class Code to Processor/PPC */
out_le32(mbase + 0x208, 0x0b21);
@@ -1704,6 +1723,97 @@ static void __init ppc4xx_probe_pciex_bridge(struct
device_node *np) ppc4xx_pciex_port_setup_hose(port);
}
+#ifdef CONFIG_PCI_MSI
+int ppc4xx_setup_peih(void)
+{
+ void __iomem *peih_base;
+
+ printk(KERN_INFO %s \n,__FUNCTION__);
This seems to be a debug output.
+ /* Set base address for PEIH and enable PEIH */
+ SDR_WRITE(PESDR0_4XX_IHS1, PPC4XX_PEIH_REGBASE_HADDR);
+ SDR_WRITE(PESDR0_4XX_IHS2, PPC4XX_PEIH_REGBASE_LADDR);
The SDR_WRITE marcos are relict's from arch/ppc. Don't use them in
arch/powerpc. We have other functions to deal with indirect DCR's now:
mfdcri(SDR0, ...) and mtdcri(SDR0, )
And
Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
On Thu, Aug 21, 2008 at 09:53:34PM -0700, [EMAIL PROTECTED] wrote: From: Tirumala R Marri [EMAIL PROTECTED] During recent tests with PCI-E , it has been found the DRV + De-Emphasis values are not optimum. These new values are tested thouroughly. Signed-off-by: Tirumala R Marri [EMAIL PROTECTED] If you are sending out a patch for someone, you need to include your Signed-off-by as well. Just reply to this with it, no need to resend the just for this. Stefan, this looks good to me. Or at least as far as I can tell from the somewhat magic values :) Any comments? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Add AMCC 4XX PCIe MSI support
On Friday 22 August 2008, [EMAIL PROTECTED] wrote:
Have you taken a look at the implementation of
arch/powerpc/platforms/cell/axon_msi.c? I would guess
that it should be possible to unify the code and put
it into sysdev, because both drivers are made for the
same hardware and the differences should all be
abstracted through the device tree already.
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -22,6 +22,11 @@
#include asm/pci-bridge.h
#include asm/ppc4xx.h
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
These declarations need to be in a header file.
diff --git a/arch/powerpc/platforms/44x/canyonlands.c
b/arch/powerpc/platforms/44x/canyonlands.c
index 3949289..ee38fb7 100644
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -25,6 +25,12 @@
#include asm/pci-bridge.h
#include asm/ppc4xx.h
+
+#ifdef CONFIG_PCI_MSI
+extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
+extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
+#endif
+
static __initdata struct of_device_id canyonlands_of_bus[] = {
{ .compatible = ibm,plb4, },
{ .compatible = ibm,opb, },
same here
@@ -49,6 +55,14 @@ static int __init canyonlands_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+#ifdef CONFIG_PCI_MSI
+ /*
+ * Setting callback functions for MSI support
+ */
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+#endif
+
return 1;
}
If the header file looks like
#ifdef CONFIG_PCI_MSI
extern int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
extern void ppc4xx_teardown_msi_irqs(struct pci_dev *dev);
#else
#define ppc4xx_setup_msi_irqs NULL
#define extern void ppc4xx_teardown_msi_irqs NULL
#endif
Then you don't need this #ifdef either.
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c
b/arch/powerpc/sysdev/ppc4xx_pci.c
index fb368df..bdb3663 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -35,6 +35,11 @@
static int dma_offset_set;
+#ifdef CONFIG_PCI_MSI
+#include linux/msi.h
+#include ../../../drivers/pci/msi.h
+#endif
+
#include should not be inside of #ifdef.
You should also not #include a header from another directory through
a relative path. Why do you think you need this?
@@ -1704,6 +1723,97 @@ static void __init ppc4xx_probe_pciex_bridge(struct
device_node *np)
ppc4xx_pciex_port_setup_hose(port);
}
+#ifdef CONFIG_PCI_MSI
+int ppc4xx_setup_peih(void)
+{
+ void __iomem *peih_base;
+
+ printk(KERN_INFO %s \n,__FUNCTION__);
+ /* Set base address for PEIH and enable PEIH */
+ SDR_WRITE(PESDR0_4XX_IHS1, PPC4XX_PEIH_REGBASE_HADDR);
+ SDR_WRITE(PESDR0_4XX_IHS2, PPC4XX_PEIH_REGBASE_LADDR);
+
+ /* Map in PCI-E Interrupt Handler Registers */
+ peih_base = ioremap(PPC4XX_PEIH_REGBASE, PPC4XX_PEIH_REGSIZE);
+ if(!peih_base) {
+ printk(KERN_ERR %s: ioremap64 failed for addr 0x%08x\n,
+ __FUNCTION__, PPC4XX_PEIH_REGBASE);
+ return -ENODEV;
+ }
Please use of_iomap to map the registers on the device.
+int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
I think this needs to go through ppc_md instead of just overriding
the common function, probably something like
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
if (ppc_md-setup_msi_irq)
return ppc_md-setup_msi_irq(dev, desc);
return 0;
}
So that each platform can provide its own variant of it.
+int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ struct msi_desc *entry;
+ int ret;
+
+ list_for_each_entry(entry, dev-msi_list, list) {
+ ret = arch_setup_msi_irq(dev, entry);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return;
+}
These on the other hand don't look platform specific at all,
so maybe you can put them as a generic implementation into
arch/powerpc/kernel/msi.c.
+#ifdef CONFIG_PCI_MSI
+ ppc4xx_setup_peih();
+#endif
+
Is it ok to call this function unconditionally? I can't see
any check for whether there is an msi-controller device at
all.
/*
+ * 4xx PCIe IRQ Handler register definitions
+ */
+#ifdef CONFIG_PCI_MSI
+
+#if defined(CONFIG_405EX)
+#define PESDR0_4XX_IHS1 0x04B0
+#define PESDR0_4XX_IHS2 0x04B1
+#define PPC4XX_PEIH_REGBASE 0x0EF62
+#define PPC4XX_PEIH_REGBASE_HADDR0x0
+#define PPC4XX_PEIH_REGBASE_LADDR0xEF62
+#define
RE: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
Signed-off-by: Feng Kan [EMAIL PROTECTED] From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Fri 8/22/2008 6:30 AM To: Feng Kan Cc: linuxppc-embedded@ozlabs.org; Tirumala Reddy Marri; [EMAIL PROTECTED] Subject: Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix On Thu, Aug 21, 2008 at 09:53:34PM -0700, [EMAIL PROTECTED] wrote: From: Tirumala R Marri [EMAIL PROTECTED] During recent tests with PCI-E , it has been found the DRV + De-Emphasis values are not optimum. These new values are tested thouroughly. Signed-off-by: Tirumala R Marri [EMAIL PROTECTED] If you are sending out a patch for someone, you need to include your Signed-off-by as well. Just reply to this with it, no need to resend the just for this. Stefan, this looks good to me. Or at least as far as I can tell from the somewhat magic values :) Any comments? josh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Early boot problem with MPC8247 and Linux 2.6.26
Hi all, I have a custom MPC8247 based board which has been running U-boot 1.3.5 and Linux 2.6.26. It has been working fine with ARCH=ppc, but I now want to make it work using ARCH=powerpc. However, using ARCH=powerpc I have encountered a problem. Whatever I do it always appears to reset in the very early stages of booting the kernel. This is before the kernel can print anything on the console, so the last thing you see is this from the bootloader: ## Booting kernel from Legacy Image at 0040 ... Image Name: Linux-2.6.26 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1555842 Bytes = 1.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x07bb6c68 * fdt: cmdline image address = 0x0080 ## Checking for 'FDT'/'FDT Image' at 0080 * fdt: raw FDT blob ## Flattened Device Tree blob at 0080 Booting using the fdt blob at 0x80 of_flat_tree at 0x0080 size 0x0d3d ## device tree at 0x0080 ... 0x00800D3C (len=15677=0x3D3D) Loading Device Tree to 007fc000, end 007ffd3c ... OK ## Transferring control to Linux (at address ) ... Booting using OF flat tree... I am using U-boot to pass a DTB, which could be buggy or incomplete, however, I think it encounters problems before the DTB is accessed by the kernel. Using code to flash an LED I have traced execution from the entry point in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling the cache on the CPU: setup_common_caches: mfspr r11,SPRN_HID0 andi. r0,r11,HID0_DCE ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1: sync /* Chris: Reaches here. */ mtspr SPRN_HID0,r8/* enable and invalidate caches */ sync mtspr SPRN_HID0,r11 /* enable caches */ sync isync /* Chris: Never gets to here. */ blr FWIW, commenting out the lines above causes it to hang when attempting to enable the MMU, which is the next step in the process. I assume it's likely that something has already gone wrong before this point. Has anyone got any idea how the CPU could have got into a state where trying to enable the caches could cause it to reset? Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 kernel with ARCH=powerpc mode? I think it should be, but it would be good to know that someone has tried it. Cheers, Chris. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
On Tuesday 19 August 2008 13:34:04 David H. Lynch Jr. wrote:
Pass II
+ cur_p-phys = (unsigned char *)pci_map_single(NULL,
+ skb-data, skb-len,
+ PCI_DMA_TODEVICE);
+ cur_p-app4 = (unsigned long)skb;
+
+ for (ii = 0; ii num_frag; ii++) {
+ lp-tx_bd_tail++;
+ if (lp-tx_bd_tail = TX_BD_NUM)
+ lp-tx_bd_tail = 0;
+
+ cur_p = lp-tx_bd_v[lp-tx_bd_tail];
+ cur_p-phys = (unsigned char *)pci_map_single(NULL,
+ (void *)page_address(frag-page)
+ + frag-page_offset,
+ frag-size,
+ PCI_DMA_TODEVICE);
1. Why is pci_* API is used instead of dma_*?
2. Why pci_map_single() in skb_shinfo(skb)-frags processing instead of
dma_map_page()?
+ if (ii == (TX_BD_NUM - 1))
+ lp-tx_bd_v[ii].next = lp-tx_bd_p[0];
+ else
+ lp-tx_bd_v[ii].next = lp-tx_bd_p[ii + 1];
3. It would be much simpler to use masking by (TX_BD_NUM - 1) instead of if
(ii == (TX_BD_NUM - 1)) constructs.
4. There is a need of global locking mechanism for indirect registers access,
as according to Xilinx documentation only one hard core at a a time can be
accessed.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
On Tuesday 19 August 2008 13:34:04 David H. Lynch Jr. wrote:
+ switch (ip-protocol) {
+ case IPPROTO_TCP:
+ start = sizeof(struct iphdr) + ETH_HLEN;
+ insert = sizeof(struct iphdr) + ETH_HLEN + 16;
+ length = ip-tot_len - sizeof(struct iphdr);
+ headlen = ETH_HLEN
+ + sizeof(struct iphdr)
+ + sizeof(struct tcphdr);
+ break;
+ case IPPROTO_UDP:
+ start = sizeof(struct iphdr) + ETH_HLEN;
+ insert = sizeof(struct iphdr) + ETH_HLEN + 6;
+ length = ip-tot_len - sizeof(struct iphdr);
+ headlen = ETH_HLEN
+ + sizeof(struct iphdr)
+ + sizeof(struct udphdr);
+ break;
+ default:
+ break;
+ }
Why all these calculations instead of skb_transport_offset(skb) and
skb-csum_offset usage?
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Early boot problem with MPC8247 and Linux 2.6.26
Chris Skepper wrote: Using code to flash an LED I have traced execution from the entry point in head_32.S, through to call_setup_cpu in misc.S, __setup_cpu_603 and into setup_common_caches in cpu_setup_6xx.S. It appears to reset when enabling the cache on the CPU: setup_common_caches: mfsprr11,SPRN_HID0 andi.r0,r11,HID0_DCE orir11,r11,HID0_ICE|HID0_DCE orir8,r11,HID0_ICFI bne1f/* don't invalidate the D-cache */ orir8,r8,HID0_DCI/* unless it wasn't enabled */ 1:sync /* Chris: Reaches here. */ mtsprSPRN_HID0,r8/* enable and invalidate caches */ sync mtsprSPRN_HID0,r11/* enable caches */ sync isync /* Chris: Never gets to here. */ blr FWIW, commenting out the lines above causes it to hang when attempting to enable the MMU, which is the next step in the process. How are you determining that it never gets to that point? If it's via serial I/O or similar, be aware that I/O isn't going to work when caches are enabled but the MMU is not. Also, can anyone confirm that the MPC8247 is supported by a 2.6.26 kernel with ARCH=powerpc mode? I think it should be, but it would be good to know that someone has tried it. I've booted an MPC8248 (and some other 82xx) on 2.6.26. MPC8247 should work. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting linux 2.6.27 to embedded powerpc board
Hi, I still haven't gotten anything to work :-( I'm using Uboot 1.1.4 and Linux 2.6.27 but instead of using uImage, I'm using cuImage.myboard The args to dtc are as listed by David Jander My cmd line args are: setenv bootargs root=/dev/ram0 init=/rescue rw console=ttyS0,9600 ramdisk_size=65536 When I attempt to boot my image it just hangs w/o any output. I dearly wish I could get some console output. Here is the actual display from uboot: ## Booting image at 0080 ... Image Name: Linux-2.6.27-rc2 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1640425 Bytes = 1.6 MB Load Address: 0040 Entry Point: 0040055c Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0100 ... Image Name: flash_root.ext3.gz Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:13450106 Bytes = 12.8 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0f29d000, end 0ff70b7a ... OK Two questions: 1) the load address and entry point for the kernel (see above) are non-zero. When we load via uImage, they are always zero. Is this normal? dtc has not options to set the load address and entry point. 2) When I build my kernel, I get two warnings. Could these be causing a problem? WARNING: mm/built-in.o(.data+0x8ec): Section mismatch in reference from the variable contig_page_data to the variable .init.data:bootmem_node_data The variable contig_page_data references the variable __initdata bootmem_node_data If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, MODPOST vmlinux.o WARNING: vmlinux.o(.data+0xfe74): Section mismatch in reference from the variable contig_page_data to the variable .init.data:bootmem_node_data The variable contig_page_data references the variable __initdata bootmem_node_data If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, thanks so much for your help. LK - Original Message From: David Jander [EMAIL PROTECTED] To: linuxppc-embedded@ozlabs.org Cc: Laxmikant Rashinkar [EMAIL PROTECTED] Sent: Thursday, August 21, 2008 2:43:45 AM Subject: Re: porting linux 2.6.27 to embedded powerpc board On Thursday 21 August 2008 01:24:46 Laxmikant Rashinkar wrote: Hi, I have an embedded PowerPC (MPC8347) board that works fine with uboot and Linux 2.6.15. I am trying to upgrade the kernel so that it runs on the latest release - Linux 2.6.27. So far, I have gotten the kernel to compile on my platform, but of course it does not boot. Well, honestly I don't know where to look for information either (other than the source-code and examples from others), but here is a list with points to look out for (I have just done the same thing as you for a MPC5200B-based board): 1. Upgrade to latest u-boot first (recent git seems to be fine). There have been a lot of changes in u-boot lately about OF and device-tree related things. I suspect you need a fairly recent version of u-boot to go well with the latest kernel. It's also generally a good idea IMHO. 2. I assume you are porting to arch/powerpc (the old arch/ppc you used back in 2.6.15 is obsolete and broken now). 3. Look at other platforms that use the same processor, and pick a simple one as starting point. Look out for the dts (device-tree-source file in arch/powerpc/boot/dts), copy and modify one to reflect your hardware. Recently a lot of changes happend in the kernel, changing device names, obsoleting device-type tags, etc..., so some of the current DTS sources included in the kernel might not even work (wrong device name, missing information, wrong use of device-type, etc...), so watch out for these kind of issues too. 4. Be sure that the device(s) necessary to produce output on your console are correctly placed in the DT. Also make sure that u-boot knows about it (#define OF_STDOUT_PATH... in your u-boot board config file) 5. When compiling the device tree, it may be necessary to add some extra reserved entries to the compiled tree (I am using dtc -p 10240 -R 20, which might be slightly exaggerated), because u-boot may add something to it, and if it can't, linux won't boot. 6. Remember to always specify the rootfstype= option on the commandline if booting from anything other than NFS. This was not necessary back in the 2.6.15-times AFAICR. 7. Boot with a device-tree (in u-boot: bootm $addrofkernel - $addrofdtb, don't forget the dash if you are not using an initrd). If you don't do this, u-boot can't fix your DT, and the kernel probably won't find it either. 8. Be sure to use the correct version of the DTC (DT compiler) for your kernel (the sources are included nowadays,
Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
On Friday 22 August 2008, Josh Boyer wrote: On Thu, Aug 21, 2008 at 09:53:34PM -0700, [EMAIL PROTECTED] wrote: From: Tirumala R Marri [EMAIL PROTECTED] During recent tests with PCI-E , it has been found the DRV + De-Emphasis values are not optimum. These new values are tested thouroughly. Signed-off-by: Tirumala R Marri [EMAIL PROTECTED] If you are sending out a patch for someone, you need to include your Signed-off-by as well. Just reply to this with it, no need to resend the just for this. Stefan, this looks good to me. Or at least as far as I can tell from the somewhat magic values :) Any comments? Looks good for me too, so: Acked-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: porting linux 2.6.27 to embedded powerpc board
On Fri, Aug 22, 2008 at 12:26 PM, Laxmikant Rashinkar [EMAIL PROTECTED] wrote: Hi, I still haven't gotten anything to work :-( I'm using Uboot 1.1.4 and Linux 2.6.27 but instead of using uImage, I'm using cuImage.myboard The args to dtc are as listed by David Jander Please post you .dts file and the filename you are using for it. g. My cmd line args are: setenv bootargs root=/dev/ram0 init=/rescue rw console=ttyS0,9600 ramdisk_size=65536 When I attempt to boot my image it just hangs w/o any output. I dearly wish I could get some console output. Here is the actual display from uboot: ## Booting image at 0080 ... Image Name: Linux-2.6.27-rc2 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1640425 Bytes = 1.6 MB Load Address: 0040 Entry Point: 0040055c Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at 0100 ... Image Name: flash_root.ext3.gz Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:13450106 Bytes = 12.8 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0f29d000, end 0ff70b7a ... OK Two questions: 1) the load address and entry point for the kernel (see above) are non-zero. When we load via uImage, they are always zero. Is this normal? dtc has not options to set the load address and entry point. 2) When I build my kernel, I get two warnings. Could these be causing a problem? WARNING: mm/built-in.o(.data+0x8ec): Section mismatch in reference from the variable contig_page_data to the variable .init.data:bootmem_node_data The variable contig_page_data references the variable __initdata bootmem_node_data If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, MODPOST vmlinux.o WARNING: vmlinux.o(.data+0xfe74): Section mismatch in reference from the variable contig_page_data to the variable .init.data:bootmem_node_data The variable contig_page_data references the variable __initdata bootmem_node_data If the reference is valid then annotate the variable with __init* (see linux/init.h) or name the variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, thanks so much for your help. LK - Original Message From: David Jander [EMAIL PROTECTED] To: linuxppc-embedded@ozlabs.org Cc: Laxmikant Rashinkar [EMAIL PROTECTED] Sent: Thursday, August 21, 2008 2:43:45 AM Subject: Re: porting linux 2.6.27 to embedded powerpc board On Thursday 21 August 2008 01:24:46 Laxmikant Rashinkar wrote: Hi, I have an embedded PowerPC (MPC8347) board that works fine with uboot and Linux 2.6.15. I am trying to upgrade the kernel so that it runs on the latest release - Linux 2.6.27. So far, I have gotten the kernel to compile on my platform, but of course it does not boot. Well, honestly I don't know where to look for information either (other than the source-code and examples from others), but here is a list with points to look out for (I have just done the same thing as you for a MPC5200B-based board): 1. Upgrade to latest u-boot first (recent git seems to be fine). There have been a lot of changes in u-boot lately about OF and device-tree related things. I suspect you need a fairly recent version of u-boot to go well with the latest kernel. It's also generally a good idea IMHO. 2. I assume you are porting to arch/powerpc (the old arch/ppc you used back in 2.6.15 is obsolete and broken now). 3. Look at other platforms that use the same processor, and pick a simple one as starting point. Look out for the dts (device-tree-source file in arch/powerpc/boot/dts), copy and modify one to reflect your hardware. Recently a lot of changes happend in the kernel, changing device names, obsoleting device-type tags, etc..., so some of the current DTS sources included in the kernel might not even work (wrong device name, missing information, wrong use of device-type, etc...), so watch out for these kind of issues too. 4. Be sure that the device(s) necessary to produce output on your console are correctly placed in the DT. Also make sure that u-boot knows about it (#define OF_STDOUT_PATH... in your u-boot board config file) 5. When compiling the device tree, it may be necessary to add some extra reserved entries to the compiled tree (I am using dtc -p 10240 -R 20, which might be slightly exaggerated), because u-boot may add something to it, and if it can't, linux won't boot. 6. Remember to always specify the rootfstype= option on the commandline if booting from anything other than NFS. This was not necessary back in the 2.6.15-times AFAICR. 7. Boot with a device-tree (in u-boot: bootm $addrofkernel - $addrofdtb, don't forget the dash if you are not using an initrd). If you
Re: porting linux 2.6.27 to embedded powerpc board
Add the following to the end of your dts file and see what happens:
chosen {
linux,stdout-path = serial0;
};
On Fri, Aug 22, 2008 at 1:57 PM, Laxmikant Rashinkar
[EMAIL PROTECTED] wrote:
Hi,
my .dts file is called mpc834x_mds.dts. (My processor is MPC8347)
Here are its contents.
/*
* MPC8349E MDS Device Tree Source
*
* Copyright 2005, 2006 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/dts-v1/;
/ {
model = MPC8349EMDS;
compatible = MPC8349EMDS, MPC834xMDS, MPC83xxMDS;
#address-cells = 1;
#size-cells = 1;
aliases {
ethernet0 = enet0;
ethernet1 = enet1;
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
pci1 = pci1;
};
cpus {
#address-cells = 1;
#size-cells = 0;
PowerPC,[EMAIL PROTECTED] {
device_type = cpu;
reg = 0x0;
d-cache-line-size = 32;
i-cache-line-size = 32;
d-cache-size = 32768;
i-cache-size = 32768;
timebase-frequency = 0; // from bootloader
bus-frequency = 0;// from bootloader
clock-frequency = 0; // from bootloader
};
};
memory {
device_type = memory;
reg = 0x 0x1000; // 256MB at 0
};
[EMAIL PROTECTED] {
device_type = board-control;
reg = 0xe240 0x8000;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
compatible = simple-bus;
ranges = 0x0 0xe000 0x0010;
reg = 0xe000 0x0200;
bus-frequency = 0;
[EMAIL PROTECTED] {
device_type = watchdog;
compatible = mpc83xx_wdt;
reg = 0x200 0x100;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl-i2c;
reg = 0x3000 0x100;
interrupts = 14 0x8;
interrupt-parent = ipic;
dfsrr;
[EMAIL PROTECTED] {
compatible = dallas,ds1374;
reg = 0x68;
};
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
compatible = fsl-i2c;
reg = 0x3100 0x100;
interrupts = 15 0x8;
interrupt-parent = ipic;
dfsrr;
};
[EMAIL PROTECTED] {
cell-index = 0;
compatible = fsl,spi;
reg = 0x7000 0x1000;
interrupts = 16 0x8;
interrupt-parent = ipic;
mode = cpu;
};
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc8349-dma, fsl,elo-dma;
reg = 0x82a8 4;
ranges = 0 0x8100 0x1a8;
interrupt-parent = ipic;
interrupts = 71 8;
cell-index = 0;
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
reg = 0 0x80;
interrupt-parent = ipic;
interrupts = 71 8;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
reg = 0x80 0x80;
interrupt-parent = ipic;
interrupts = 71 8;
};
[EMAIL PROTECTED] {
compatible =
Re: porting linux 2.6.27 to embedded powerpc board
Laxmikant Rashinkar wrote: When I attempt to boot my image it just hangs w/o any output. I dearly wish I could get some console output. Make sure you have /chosen/linux,stdout-path in your device tree. For output from the kernel itself, make sure the serial clock-frequency is correct. 1) the load address and entry point for the kernel (see above) are non-zero. When we load via uImage, they are always zero. Is this normal? Yes, it's normal. 2) When I build my kernel, I get two warnings. Could these be causing a problem? Probably not. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
lspci vs scanpci
Hello folks, I have a general question regarding lspci and scanpci. Upon porting a kernel 2.6.24 to a ppc platform, the kernel seems to be working fine. However, upon scaning for PCI devices, we have got reasonable results upon running lspci however scanpci, we are not getting the same results, and scanpci results looks not right (such as INT_LINE=0xFF) in the PCI devices detected. Should I be worried about some hardware problem if lspci is working and scanpci is not? Any advise? -- View this message in context: http://www.nabble.com/lspci-vs-scanpci-tp19116424p19116424.html Sent from the linuxppc-embedded mailing list archive at Nabble.com. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
virt_to_phys() in drivers w/dma - MPC8xxx
A style / function question. I have been seeing conflicting articles and examples on what the proper method would be for some of the Freescale MPC drivers. I am putting together an ATM driver, and 'might' be having some erratic results due to this function. Not sure yet, but wanted to put this out there for comments. In many cases when dealing with TxBD or RxBD pointers a UCC or what not driver will use the virt_to_phys() call to get what I assume is a physical address that can be used for dma? Perhaps not in all cases, but a majority. See ucc_geth.c for an example of the usage. I have also seen some prototype drivers that use this call to get the physical address to place into the QE_MURAM for the PRAM initialization. I then ran across this link: http://mirror.linux.org.au/linux.conf.au/2005/cdrom-beta-1/linux-mandocs-2.6 .12.6/virt_to_phys.html Which states: The returned physical address is the physical (CPU) mapping for the memory address given. It is only valid to use this function on addresses directly mapped or allocated via kmalloc. This function does not give bus mappings for DMA transfers. In almost all conceivable cases a device driver should not be using this function. --- So shouldn't we be using like dma_alloc_coherent, and then tracking the dma address separately as a variable, and use it when necessary instead of calling virt_to_phys()? Or am I confused on what these are doing? -Russ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B
- Original Message From: Wolfram Sang [EMAIL PROTECTED] To: Arnd Bergmann [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Sent: Monday, August 18, 2008 9:18:31 AM Subject: [PATCH V2] MPC52XX: Don't touch pipelining for MPC5200B MPC5200 needs to have pipelining disabled for ATA to work. MPC5200B does not. So, for the latter, don't touch the original setting from the bootloader. Signed-off-by: Wolfram Sang --- Hello Arnd, On Mon, Aug 18, 2008 at 12:49:36PM +0200, Arnd Bergmann wrote: Please make this a run-time conditional instead of compile-time. Like this? .. This needs some testing IMHO. Most configs in U-Boot tend to enable pipelining, which then used to be disabled by the kernel. So, on the one hand, this change would enable what is originally wanted; on the other hand, systems may run under a new configuration and need to be checked for regressions. Especially as there can be puzzling effects, like for one setup here, FEC only works reliably with pipelining enabled. arch/powerpc/platforms/52xx/mpc52xx_common.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: arch/powerpc/platforms/52xx/mpc52xx_common.c === --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig +++ arch/powerpc/platforms/52xx/mpc52xx_common.c @@ -99,11 +99,14 @@ out_be32(xlb-master_pri_enable, 0xff); out_be32(xlb-master_priority, 0x); -/* Disable XLB pipelining +/* + * Disable XLB pipelining * (cfr errate 292. We could do this only just before ATA PIO * transaction and re-enable it afterwards ...) + * Not needed on MPC5200B. */ -out_be32(xlb-config, in_be32(xlb-config) | MPC52xx_XLB_CFG_PLDIS); +if ((mfspr(SPRN_SVR) MPC5200_SVR_MASK) == MPC5200_SVR) +out_be32(xlb-config, in_be32(xlb-config) | MPC52xx_XLB_CFG_PLDIS); iounmap(xlb); } -- Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Hi Since this bug is ATA specific, shouldn't this code be conditioned by CONFIG_IDE ? Thanks -roger ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
no output on screen
hi, all
I am writing a gfxdriver for Fujitsu mb86296 video card under DirectFB. When
I run a example df_fire from DirectFB-examples-1.0.0.tar.gz, there is no
output on the computer screen, it is black completely, and the error result
looks like this:
sh-3.00# ./df_fire
===| DirectFB 1.0.0 |===
(c) 2001-2007 The DirectFB Organization (directfb.org)
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2008-06-03 03:01) [ TRACE ]
(*) Direct/Memcpy: Using ppcasm_memcpy()
(*) Direct/Thread: Running 'VT Switcher' (CRITICAL, 502)...
(*) Direct/Thread: Running 'PS/2 Input' (INPUT, 503)...
(*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org)
(*) Direct/Thread: Running 'Keyboard Input' (INPUT, 504)...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) DirectFB/Graphics: Fujitsu MB86296 0.5 (Atom Create)
(!) [ 493:0.000] -- Caught signal 11 (at (nil), invalid address) --
(-) [ 493: -STACK- ]
#0 0x0fecef48 in signal_handler () from
/mnt/gtkdfb/lib/libdirect-1.0.so.0
[0xfec4000]
#1 0x0ffc5b40 in dfb_screens_initialize () from
/mnt/gtkdfb/lib/libdirectfb-1.0.so.0 [0xff5f000]
#2 0x0ffb3520 in dfb_core_part_initialize () from
/mnt/gtkdfb/lib/libdirectfb-1.0.so.0 [0xff5f000]
#3 0x0ffb2edc in dfb_core_arena_initialize () from
/mnt/gtkdfb/lib/libdirectfb-1.0.so.0 [0xff5f000]
#4 0x0ffb2edc in dfb_core_arena_initialize () from
/mnt/gtkdfb/lib/libdirectfb-1.0.so.0 [0xff5f000]
#5 0x0ff029f8 in fusion_arena_enter () from
/mnt/gtkdfb/lib/libfusion-1.0.so.0 [0xfeff000]
#6 0x0ffb18f4 in dfb_core_create () from
/mnt/gtkdfb/lib/libdirectfb-1.0.so.0 [0xff5f000]
#7 0x100127b4 in DirectFBCreate () from ./df_fire [0x1000]
(-) [ 502: -STACK- 'VT Switcher']
#0 0x0fcf3970 in vt_thread () from
/mnt/gtkdfb/lib/directfb-1.0-0/systems/libdirectfb_fbdev.so [0xfcea000]
(-) [ 503: -STACK- 'PS/2 Input']
#0 0x0fba6c88 in ps2mouseEventThread () from
/mnt/gtkdfb/lib/directfb-1.0-0/inputdrivers/libdirectfb_ps2mouse.so
[0xfba4000]
(-) [ 504: -STACK- 'Keyboard Input']
#0 0x0fc56e84 in keyboardEventThread () from
/mnt/gtkdfb/lib/directfb-1.0-0/inputdrivers/libdirectfb_keyboard.so
[0xfc55000]
Aborted
I wonder if it is wrong in my code in mb86296_screen.c which I refer to
sh7722 gfxdriver, here is the code:
/**/
static DFBResult
mb86296InitScreen( CoreScreen *screen,
CoreGraphicsDevice *device,
void *driver_data,
void *screen_data,
DFBScreenDescription *description )
{
/* Set the screen capabilities. */
description-caps = DSCCAPS_NONE;
/* Set the screen name. */
snprintf( description-name, DFB_SCREEN_DESC_NAME_LENGTH, MB86296
Screen );
return DFB_OK;
}
static DFBResult
mb86296GetScreenSize( CoreScreen *screen,
void *driver_data,
void *screen_data,
int*ret_width,
int*ret_height )
{
*ret_width = MB86296_LCD_WIDTH;
*ret_height = MB86296_LCD_HEIGHT;
return DFB_OK;
}
ScreenFuncs mb86296ScreenFuncs = {
InitScreen:mb86296InitScreen,
GetScreenSize: mb86296GetScreenSize
};
In driver_init_driver(), I called dfb_screens_register( device, driver_data,
mb86296ScreenFuncs ).
anybody can help me??
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
