* Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
From: Josh Boyer @ 2008-08-22 13:30 UTC (permalink / raw)
To: fkan; +Cc: sr, Tirumala R Marri, linuxppc-embedded
In-Reply-To: <1219380814-17229-1-git-send-email-fkan@amcc.com>
On Thu, Aug 21, 2008 at 09:53:34PM -0700, fkan@amcc.com wrote:
>From: Tirumala R Marri <tmarri@amcc.com>
>
>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 <tmarri@amcc.com>
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
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Jimi Xenidis @ 2008-08-22 13:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, kvm-ppc, hollisb, linuxppc-dev
In-Reply-To: <542DF8C9-8EB7-40D9-AC66-67D4CF7598F6@kernel.crashing.org>
On Aug 22, 2008, at 4:17 AM, Kumar Gala wrote:
>
> On Aug 22, 2008, at 3:08 AM, Christian Ehrhardt wrote:
>
>> Scott Wood wrote:
>>> On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote:
>>>
>>>> Where is the other discussion? I'd like to understand what's
>>>> going on here.. (especially since I added the wrtee[i] changes
>>>> to kernel way back when).
>>>>
>>>
>>> Presumably, they want to be able to replace wrtee with a store to a
>>> hypervisor/guest shared memory area, and there's no store-immediate
>>> instruction.
>>>
>>> -Scott
>>>
>> Exactly Scott
>>
>> And for your question Kumar, in the last submission I was asked to
>> split host and guest patches.
>> So the host discussion lives on kvm-ppc@vger.kernel.org as I
>> mentioned (maybe a bit too hidden)
>> in the [0/4] mail of this series.
>
> Maybe I'm missing something but it seems like just changing the code
> to wrtee isn't the best way to ensure you have enough space to put
> the set of instructions you guys want.
>
Sorry, I have not really been following this, I assume you are
replacing SPR accesses with load/stores that do not trap.
I believe thats fine for reading any SPR, but not true for modifying
some SPRs, particularly MSR.
IMHO you must trap on any instruction that modifies the MSR.
So you should prolly not rewrite mtmsr or wrtee* but let them trap.
BTW: actually moving problem SPRs (like MSRs) to a read only page
makes decoding far more efficient, but it does burn another TLB entry.
-JX
> - k
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
From: Hollis Blanchard @ 2008-08-22 14:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: Yoder Stuart, kvm-ppc, ppc-dev list
In-Reply-To: <0AFFA88B-E4B4-4B27-8B6F-8BA0463D7245@kernel.crashing.org>
On Friday 22 August 2008 05:38:54 Kumar Gala wrote:
>
> On Aug 19, 2008, at 5:36 AM, ehrhardt@linux.vnet.ibm.com wrote:
>
> > From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> >
> > This adds the guest portion of the hypercall infrastructure,
> > basically an
> > illegal instruction with a defined layout.
> > See http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI for more
> > detail
> > on the hypercall ABI for powerpc.
> >
> > Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> > ---
> >
> > [diffstat]
> > kvm_para.h | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > [diff]
>
> Can we make this more generic (naming) and location. I believe there
> is some interesting in using the same ABI on the Freescale HV so it
> seems like have the wrappers be a bit more generic saves us.
Agreed. Maybe something like epapr_hcalls.h .
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] Add AMCC 4XX PCIe MSI support
From: Arnd Bergmann @ 2008-08-22 14:03 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Preetesh Parekh, Michael Ellerman, fkan
In-Reply-To: <1219380144-17175-1-git-send-email-fkan@amcc.com>
On Friday 22 August 2008, fkan@amcc.com 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 0x0EF620000
> +#define PPC4XX_PEIH_REGBASE_HADDR 0x0
> +#define PPC4XX_PEIH_REGBASE_LADDR 0xEF620000
> +#define PPC4XX_PCIE_MSI_ADDR 0x080000000
> +#define PPC4XX_PCIE_MSI_HADDR 0x0
> +#define PPC4XX_PCIE_MSI_LADDR 0x80000000
> +
> +#elif defined(CONFIG_460EX)
> +#define PESDR0_4XX_IHS1 0x036C
> +#define PESDR0_4XX_IHS2 0x036D
> +#define PPC4XX_PEIH_REGBASE 0xC10000000
> +#define PPC4XX_PEIH_REGBASE_HADDR 0xC
> +#define PPC4XX_PEIH_REGBASE_LADDR 0x10000000
> +#define PPC4XX_PCIE_MSI_ADDR 0xe80000000
> +#define PPC4XX_PCIE_MSI_HADDR 0xe
> +#define PPC4XX_PCIE_MSI_LADDR 0x80000000
> +#endif
These should be read from the msi-controller node in the device tree.
> diff --git a/include/asm-powerpc/dcr-native.h b/include/asm-powerpc/dcr-native.h
> index 72d2b72..357ba36 100644
> --- a/include/asm-powerpc/dcr-native.h
> +++ b/include/asm-powerpc/dcr-native.h
> @@ -111,6 +111,18 @@ static inline void __dcri_clrset(int base_addr, int base_data, int reg,
> DCRN_ ## base ## _CONFIG_DATA, \
> reg, clr, set)
>
> +/* SDR read/write helper macros */
> +
> +#define DCRN_SDR_CONFIG_ADDR 0x00E
> +#define DCRN_SDR_CONFIG_DATA 0x00F
> +
> +#define SDR_READ(offset) ({ \
> + mtdcr(DCRN_SDR_CONFIG_ADDR, offset); \
> + mfdcr(DCRN_SDR_CONFIG_DATA);})
> +#define SDR_WRITE(offset, data) ({ \
> + mtdcr(DCRN_SDR_CONFIG_ADDR, offset); \
> + mtdcr(DCRN_SDR_CONFIG_DATA, data);})
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_NATIVE_H */
You should use dcr_map and friends to find the SDR register and define it in a
platform independent way. There are systems using SDR that do not use dcr-native
but dcr-mmio.
Arnd <><
^ permalink raw reply
* Re: [PATCH] POWERPC: Change total_memory to phys_addr_t
From: Becky Bruce @ 2008-08-22 15:26 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1219349438-21436-1-git-send-email-becky.bruce@freescale.com>
Gah, I just noticed that part of this patch is missing - I will
resubmit as soon as I figure out what the heck happened.
-Becky
On Aug 21, 2008, at 3:10 PM, Becky Bruce wrote:
> Also change consumers of various lmb funcs/arrays that are now
> phys_addr_t to also be phys_addr_t.
>
> Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
> ---
> arch/powerpc/mm/mem.c | 19 ++++++++++---------
> 1 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 1c93c25..89dc32b 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -75,14 +75,14 @@ static inline pte_t *virt_to_kpte(unsigned long
> vaddr)
>
> int page_is_ram(unsigned long pfn)
> {
> - unsigned long paddr = (pfn << PAGE_SHIFT);
> + phys_addr_t paddr = ((phys_addr_t)pfn << PAGE_SHIFT);
>
> #ifndef CONFIG_PPC64 /* XXX for now */
> return paddr < __pa(high_memory);
> #else
> int i;
> for (i=0; i < lmb.memory.cnt; i++) {
> - unsigned long base;
> + phys_addr_t base;
>
> base = lmb.memory.region[i].base;
>
> @@ -195,7 +195,8 @@ EXPORT_SYMBOL_GPL(walk_memory_resource);
> void __init do_init_bootmem(void)
> {
> unsigned long i;
> - unsigned long start, bootmap_pages;
> + phys_addr_t start;
> + unsigned long bootmap_pages;
> unsigned long total_pages;
> int boot_mapsize;
>
> @@ -234,8 +235,8 @@ void __init do_init_bootmem(void)
>
> /* reserve the sections we're already using */
> for (i = 0; i < lmb.reserved.cnt; i++) {
> - unsigned long addr = lmb.reserved.region[i].base +
> - lmb_size_bytes(&lmb.reserved, i) - 1;
> + phys_addr_t addr = lmb.reserved.region[i].base +
> + lmb_size_bytes(&lmb.reserved, i) - 1;
> if (addr < lowmem_end_addr)
> reserve_bootmem(lmb.reserved.region[i].base,
> lmb_size_bytes(&lmb.reserved, i),
> @@ -290,7 +291,7 @@ static int __init mark_nonram_nosave(void)
> */
> void __init paging_init(void)
> {
> - unsigned long total_ram = lmb_phys_mem_size();
> + phys_addr_t total_ram = lmb_phys_mem_size();
> phys_addr_t top_of_ram = lmb_end_of_DRAM();
> unsigned long max_zone_pfns[MAX_NR_ZONES];
>
> @@ -310,10 +311,10 @@ void __init paging_init(void)
> kmap_prot = PAGE_KERNEL;
> #endif /* CONFIG_HIGHMEM */
>
> - printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
> - (unsigned long long)top_of_ram, total_ram);
> + printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
> + (unsigned long long)top_of_ram, (unsigned long
> long)total_ram);
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
> - (long int)((top_of_ram - total_ram) >> 20));
> + (unsigned long)((top_of_ram - total_ram) >> 20));
> memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
> #ifdef CONFIG_HIGHMEM
> max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
> --
> 1.5.5.1
^ permalink raw reply
* RE: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
From: Feng Kan @ 2008-08-22 15:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: sr, Tirumala Reddy Marri, linuxppc-embedded
In-Reply-To: <20080822133020.GE22283@yoda.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Signed-off-by: Feng Kan fkan@amcc.com
________________________________
From: Josh Boyer [mailto:jwboyer@gmail.com]
Sent: Fri 8/22/2008 6:30 AM
To: Feng Kan
Cc: linuxppc-embedded@ozlabs.org; Tirumala Reddy Marri; sr@denx.de
Subject: Re: [PATCH] AMCC PPC460GT/EX PCI-E de-emphasis adjustment fix
On Thu, Aug 21, 2008 at 09:53:34PM -0700, fkan@amcc.com wrote:
>From: Tirumala R Marri <tmarri@amcc.com>
>
>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 <tmarri@amcc.com>
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
[-- Attachment #2: Type: text/html, Size: 1508 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Scott Wood @ 2008-08-22 15:49 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: kvm-ppc, hollisb, linuxppc-dev
In-Reply-To: <08A55D0E-C75A-49F4-9DBF-EB80E1C7755E@pobox.com>
On Fri, Aug 22, 2008 at 09:56:16AM -0400, Jimi Xenidis wrote:
> Sorry, I have not really been following this, I assume you are
> replacing SPR accesses with load/stores that do not trap.
> I believe thats fine for reading any SPR, but not true for modifying
> some SPRs, particularly MSR.
> IMHO you must trap on any instruction that modifies the MSR.
> So you should prolly not rewrite mtmsr or wrtee* but let them trap.
You only need to trap when changing MSR[EE] if there's a pending
interrupt. The hypervisor can change the mapping of the shared page when
it is unable to deliver an interrupt due to the virtual EE value being
zero.
-Scott
^ permalink raw reply
* Early boot problem with MPC8247 and Linux 2.6.26
From: Chris Skepper @ 2008-08-22 15:29 UTC (permalink / raw)
To: linuxppc-embedded
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 00400000 ...
Image Name: Linux-2.6.26
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1555842 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x07bb6c68
* fdt: cmdline image address = 0x00800000
## Checking for 'FDT'/'FDT Image' at 00800000
* fdt: raw FDT blob
## Flattened Device Tree blob at 00800000
Booting using the fdt blob at 0x800000
of_flat_tree at 0x00800000 size 0x00000d3d
## device tree at 0x00800000 ... 0x00800D3C (len=15677=0x3D3D)
Loading Device Tree to 007fc000, end 007ffd3c ... OK
## Transferring control to Linux (at address 00000000) ...
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.
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Scott Wood @ 2008-08-22 15:58 UTC (permalink / raw)
To: Jon Smirl
Cc: devicetree-discuss, linuxppc-dev, paulus, sparclinux,
David Miller
In-Reply-To: <9e4733910808211939s24f1b2f0tc470aaf3831ebcca@mail.gmail.com>
On Thu, Aug 21, 2008 at 10:39:40PM -0400, Jon Smirl wrote:
> I see, the old support needed the drivers to be built-in. The newer
> code dynamically loads the correct i2c driver and set its parameters.
>
> Did the old code use anything besides compatible?
Yes.
> It would have been using the older i2c system that probed for the
> address.
No, it wouldn't have. It used glue code to generate i2c_board_info
structs.
> > See commit id d13ae8620dfdedfa7e9ab6d1eec294adc0516065.
As shown in the above commit id. :-)
-Scott
^ permalink raw reply
* RE: [PATCH 0/3]: Sparc OF I2C support.
From: Yoder Stuart @ 2008-08-22 16:00 UTC (permalink / raw)
To: Mitch Bradley, David Miller
Cc: sparclinux, linuxppc-dev, devicetree-discuss, WOOD SCOTT
In-Reply-To: <48AE4C4A.8040804@firmworks.com>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Mitch Bradley
> Sent: Friday, August 22, 2008 12:19 AM
> To: David Miller
> Cc: linuxppc-dev@ozlabs.org; sparclinux@vger.kernel.org;=20
> devicetree-discuss@ozlabs.org; Wood Scott
> Subject: Re: [PATCH 0/3]: Sparc OF I2C support.
>=20
>=20
>=20
> David Miller wrote:
> > From: "Grant Likely" <grant.likely@secretlab.ca>
> > Date: Thu, 21 Aug 2008 22:34:31 -0600
> >
> > =20
> >> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
> >> <grant.likely@secretlab.ca> wrote:
> >> =20
> >>> On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley=20
> <wmb@firmworks.com> wrote:
> >>> =20
> >>>> Hi, I wrote most of 1275.
> >>>>
> >>>> Mitch Bradley (wmb@firmworks.com)
> >>>> =20
> >>> Hi Mitch,
> >>>
> >>> What is your suggestion. Where should we be discussing new device
> >>> tree bindings? Whether it be real Open Firmware, or=20
> flattened device
> >>> tree, or something in between
> >>> =20
> >> ...and along those lines: is there a place for documenting new
> >> bindings? Lacking anything better, those of us in=20
> PowerPC-Linux-land
> >> have been adding documentation to=20
> Documentation/powerpc/dts-bindings/*
> >> in the Linux kernel tree.
> >> =20
> >
> > In a discussion I am having with Greg Onufer, David K. and Tayfun
> > at Sun, Greg said the some of the newer binding documents are
> > being published on the opensolaris site, and he is trying to
> > get some of the older cases (like this I2C one) published there
> > too.
> >
> > =20
>=20
> This collection of mailing lists is as good a place as any to discuss=20
> new bindings. I don't know how many Sun people are on the=20
> lists, but we=20
> might be able to persuade various Sun people to lurk on one=20
> or more of=20
> them; I lurk on devicetree-discuss.
>=20
> The opensolaris site seems as good as anywhere for publishing the=20
> bindings, especially if they can pull over the old ones from e.g.=20
> playground.sun.com .
>=20
> Another possible site might be openbios.org .
I agree that the linuxppc-dev and devicetree-discuss mailing
lists are probably the best place to discuss bindings. (I'm
not aware of other good options).
Once there is consensus as to what a binding should be, and publishing
is needed-- for general, common bindings some single place is needed.
Something that is ideally authoritative, with a committed organization
behind it. One suggestion would be the power.org and follow on
versions of the ePAPR. ePAPR 1.0 is out now and currently is a base
document-- defines the flat device tree concept, and basically extracts
the relevant parts of 1275 for how this is used in the embedded space.
There are a few bindings specified in the ePAPR, based on the old
Open Firmware working group stuff:
-cpu
-interrupt controllers
-PCI
-network devices
-DCR devices
-serial devices
ePAPR doc is at:
http://www.power.org/resources/downloads/
It's obvious that more bindings are needed, and the expecation from
those who worked on the ePAPR (most or all of which are on this
mailing list) was that as bindings are codified they could be
added to the ePAPR.
The best way to publish bindings will be on the web. I've been
looking into getting power.org to host a wiki-based site
that could be used as a repository for bindings. We could have
both an area for general bindings and company specific ones.
I've made some progress here and actually have a sandbox wiki
that I'm playing with.
Stuart Yoder
Freescale
^ permalink raw reply
* Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
From: Sergey Temerkhanov @ 2008-08-22 16:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <48AA938C.4060309@dlasys.net>
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.
^ permalink raw reply
* Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
From: Sergey Temerkhanov @ 2008-08-22 16:14 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <48AA938C.4060309@dlasys.net>
T24gVHVlc2RheSAxOSBBdWd1c3QgMjAwOCAxMzozNDowNCBEYXZpZCBILiBMeW5jaCBKci4gd3Jv
dGU6Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHN3aXRjaCAoaXAtPnByb3RvY29s
KSB7Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNhc2UgSVBQUk9UT19UQ1A6Cj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBzdGFydCA9IHNp
emVvZihzdHJ1Y3QgaXBoZHIpICsgRVRIX0hMRU47Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBpbnNlcnQgPSBzaXplb2Yoc3RydWN0IGlwaGRyKSArIEVU
SF9ITEVOICsgMTY7Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqBsZW5ndGggPSBpcC0+dG90X2xlbiAtIHNpemVvZihzdHJ1Y3QgaXBoZHIpOwo+ICvCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgaGVhZGxlbiA9IEVUSF9I
TEVOCj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgKyBzaXplb2Yoc3RydWN0IGlwaGRyKQo+ICvCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCsgc2l6ZW9mKHN0cnVj
dCB0Y3BoZHIpOwo+ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgYnJlYWs7Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNhc2UgSVBQUk9UT19V
RFA6Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBzdGFy
dCA9IHNpemVvZihzdHJ1Y3QgaXBoZHIpICsgRVRIX0hMRU47Cj4gK8KgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBpbnNlcnQgPSBzaXplb2Yoc3RydWN0IGlwaGRy
KSArIEVUSF9ITEVOICsgNjsKPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoGxlbmd0aCA9IGlwLT50b3RfbGVuIC0gc2l6ZW9mKHN0cnVjdCBpcGhkcik7Cj4g
K8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBoZWFkbGVuID0g
RVRIX0hMRU4KPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqArIHNpemVvZihzdHJ1Y3QgaXBoZHIpCj4gK8KgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgKyBzaXplb2Yo
c3RydWN0IHVkcGhkcik7Cj4gK8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqBicmVhazsKPiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgZGVmYXVsdDoK
PiArwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGJyZWFrOwo+
ICvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqB9CgpXaHkgYWxsIHRoZXNlIGNhbGN1bGF0
aW9ucyBpbnN0ZWFkIG9mIHNrYl90cmFuc3BvcnRfb2Zmc2V0KHNrYikgYW5kIApza2ItPmNzdW1f
b2Zmc2V0IHVzYWdlPwoK
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Josh Boyer @ 2008-08-22 16:13 UTC (permalink / raw)
To: Yoder Stuart
Cc: devicetree-discuss, linuxppc-dev, WOOD SCOTT, sparclinux,
Mitch Bradley, David Miller
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA304461060@az33exm25.fsl.freescale.net>
On Fri, Aug 22, 2008 at 09:00:09AM -0700, Yoder Stuart wrote:
>There are a few bindings specified in the ePAPR, based on the old
>Open Firmware working group stuff:
> -cpu
> -interrupt controllers
> -PCI
> -network devices
> -DCR devices
Er, I don't think that one is based on the old workgroup. DCR is only
applicable to PowerPC 4xx devices, and those have never had open firmware.
>The best way to publish bindings will be on the web. I've been
>looking into getting power.org to host a wiki-based site
>that could be used as a repository for bindings. We could have
>both an area for general bindings and company specific ones.
>I've made some progress here and actually have a sandbox wiki
>that I'm playing with.
That sounds good, but I have one suggestion. Use the wiki for
submission and discussion of new binding proposals, but once they
are agreed upon put them in a static webpage somewhere until they
are incorporated into the next ePAPR revision. Wikis are awesome
for changing stuff, but you don't want people to go back and change
a binding that has already been approved (for whatever definition
of approved we come up with.)
Also, you might want to have some kind of Licensing or copyright
assignment for all wiki contributions. Talk to your legal team or
the power.org legal team about that if you haven't already.
josh
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
From: Scott Wood @ 2008-08-22 16:14 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080822104620.11984.30369.stgit@ubuntu8041.localdomain>
On Fri, Aug 22, 2008 at 06:46:20AM -0400, Martyn Welch wrote:
> + enet0: ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x00024000 0x00001000>;
> + mac-address = [ 00 00 00 00 00 00 ]; // set by u-boot
local-mac-address
-Scott
^ permalink raw reply
* Re: [PATCH 0/3]: Sparc OF I2C support.
From: Grant Likely @ 2008-08-22 16:44 UTC (permalink / raw)
To: Jon Smirl
Cc: devicetree-discuss, linuxppc-dev, sparclinux, paulus, Scott Wood,
David Miller
In-Reply-To: <9e4733910808211939s24f1b2f0tc470aaf3831ebcca@mail.gmail.com>
On Thu, Aug 21, 2008 at 8:39 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 8/21/08, Grant Likely <grant.likely@secretlab.ca> wrote:
>> It was over a year ago when support for i2c devices in the device tree
>> was merged.
>
> I see, the old support needed the drivers to be built-in. The newer
> code dynamically loads the correct i2c driver and set its parameters.
>
> Did the old code use anything besides compatible? It would have been
> using the older i2c system that probed for the address.
I think you're confusing binding with implementation. The binding is
the layout of data in the device tree. The implementation uses that
data. Your right that the current implementation is new, but it
replaces older implementation that uses the same binding.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] POWERPC: Change mem.c to support large physical addresses on 32-bit
From: Becky Bruce @ 2008-08-22 16:49 UTC (permalink / raw)
To: linuxppc-dev
Use phys_addr_t for sizes and addresses where appropriate.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/mm/mem.c | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 1c93c25..89dc32b 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -75,14 +75,14 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
- unsigned long paddr = (pfn << PAGE_SHIFT);
+ phys_addr_t paddr = ((phys_addr_t)pfn << PAGE_SHIFT);
#ifndef CONFIG_PPC64 /* XXX for now */
return paddr < __pa(high_memory);
#else
int i;
for (i=0; i < lmb.memory.cnt; i++) {
- unsigned long base;
+ phys_addr_t base;
base = lmb.memory.region[i].base;
@@ -195,7 +195,8 @@ EXPORT_SYMBOL_GPL(walk_memory_resource);
void __init do_init_bootmem(void)
{
unsigned long i;
- unsigned long start, bootmap_pages;
+ phys_addr_t start;
+ unsigned long bootmap_pages;
unsigned long total_pages;
int boot_mapsize;
@@ -234,8 +235,8 @@ void __init do_init_bootmem(void)
/* reserve the sections we're already using */
for (i = 0; i < lmb.reserved.cnt; i++) {
- unsigned long addr = lmb.reserved.region[i].base +
- lmb_size_bytes(&lmb.reserved, i) - 1;
+ phys_addr_t addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < lowmem_end_addr)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved, i),
@@ -290,7 +291,7 @@ static int __init mark_nonram_nosave(void)
*/
void __init paging_init(void)
{
- unsigned long total_ram = lmb_phys_mem_size();
+ phys_addr_t total_ram = lmb_phys_mem_size();
phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
@@ -310,10 +311,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
- (unsigned long long)top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%llx\n",
+ (unsigned long long)top_of_ram, (unsigned long long)total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (long int)((top_of_ram - total_ram) >> 20));
+ (unsigned long)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH] POWERPC: Change total_memory to phys_addr_t
From: Becky Bruce @ 2008-08-22 16:52 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <0718A6AE-8C34-4E36-9365-A893285D3D01@freescale.com>
It turns out that the commit message was out of date, and the patch
itself was correct. I have resubmitted with a different title/log, so
this patch can be ignored.
Cheers,
B
On Aug 22, 2008, at 10:26 AM, Becky Bruce wrote:
> Gah, I just noticed that part of this patch is missing - I will
> resubmit as soon as I figure out what the heck happened.
>
> -Becky
>
^ permalink raw reply
* Re: Early boot problem with MPC8247 and Linux 2.6.26
From: Scott Wood @ 2008-08-22 17:06 UTC (permalink / raw)
To: skepper; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.62.0808221515450.31216@chara.vm.bytemark.co.uk>
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:
> 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.
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
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
From: Scott Wood @ 2008-08-22 17:11 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <20080822122601.162dddd4.martyn.welch@gefanuc.com>
On Fri, Aug 22, 2008 at 12:26:01PM +0100, Martyn Welch wrote:
> > > drop device_type.
> > >
> >
> > Ah - _all_ device_type!
> >
>
> Um, not all - just the ones where the name of the block matches the
> device type(?)
All except "cpu" and "memory".
-Scott
^ permalink raw reply
* Re: libfreevec benchmarks
From: Ryan S. Arnold @ 2008-08-22 17:44 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: linuxppc-dev
In-Reply-To: <200808211909.16852.markos@codex.gr>
On Thu, 2008-08-21 at 19:09 +0300, Konstantinos Margaritis wrote:
> Benh suggested that I made this more known, and in particular to this list, so
> I send this mail in hope that some people might be interested. In particular,
> I ran the following benchmarks against libfreevec/glibc:
>
> http://www.freevec.org/content/libfreevec_104_benchmarks_updated
Nice results.
> libfreevec has reached a very stable point, where me and a couple of others
> (the OpenSuse PowerPC port developer being one) have been using it for weeks
> (personally I've been using it for months), using the LD_PRELOAD mechanism (as
> explained here:
> http://www.freevec.org/content/howto_using_libfreevec_using_ld_preload).
> The OpenSuse guys even consider using it by default on the ppc port even, but
> that's not final of course.
>
> glibc integration _might_ happen if glibc developers change their attitude (my
> mails have been mostly ignored).
Konstantinos,
Do you have FSF (Free Software Foundation) copyright assignment yet?
How've you implemented the optimizations?
Vector insns are allowed in the PowerPC code in GLIBC if guarded by
PPC_FEATURE_HAS_ALTIVEC (look at setjmp/_longjmp).
The use of unguarded vector code is allowed in --with-cpu powerpc-cpu
override directories for cpus that support altivec/VMX.
Optimizations for individual architectures should follow the powerpc-cpu
precedent for providing these routines, e.g.
sysdeps/powerpc/powerpc32/power6/memcpy.S
sysdeps/powerpc/powerpc64/power6/memcpy.S
I believe that optimizations for the G5 processor would go into the
existing 970 directories:
sysdeps/powerpc/powerpc32/970
sysdeps/powerpc/powerpc64/970
Today, if glibc is configure with --with-cpu=970 it will actually
default to the power optimizations for the string routines, as indicated
by the sysdeps/powerpc/powerpc[32|64]/970/Implies files. It'd be worth
verifying that your baseline glibc runs are against existing optimized
versions of glibc. If they're not then this is a fault of the distro
you're testing on.
I'm not aware of the status of some of the embedded PowerPC processors
with-regard to powerpc-cpu optimizations.
Our research found that for some tasks on some PowerPC processors the
expense of reserving the floating point pipeline for vector operations
exceeds the benefit of using vector insns for the task.
In these cases we tend to optimize based on pipeline characteristics
rather than using the vector facility.
Generally our optimizations tend to favor data an average of 12 bytes
with 1000 byte max. We also favor aligned data and use the existing
implementation as a model as a baseline for where we try to keep
unaligned data performance from dropping below.
> Last, I've also been working on a libm rewrite, though this will take some
> time still. I've reimplemented most math functions at the algorithm level, eg.
> so far, most functions achieve 50%-200% speed increase at full IEEE754
> accuracy (mathematically proven, soon to be published online) without using
> Altivec yet, just by choosing a different approximation method (Taylor
> approximation is pretty dumb if you ask me anyway).
This research would be a good candidate for selectively replacing some
of the existing libm functionality. Do these results hold for all
permutations of long double support? Do they hold for x86/x86_64 as
well as PowerPC? I would suggest against a massive patch to libc-alpha
and would instead recommend selective, individual replacement of
fundamental routines to start with accompanied by exhaustive profile
data. You have to show that you're dedicated to maintenance of these
routines and you can't overwhelm the reviewers with massive patches.
Any submission to GLIBC is going to require that you and your code
follow the GLIBC process or it'll probably be ignored. You can engage
me directly via CC and I can help you understand how to integrate the
code but I can't give you a free pass or do the work for you.
The new libc-help mailing list was also created as a place for people to
learn the process and get the patches in a state where they're ready to
be submitted to libc-alpha.
Regards,
Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development
^ permalink raw reply
* Re: libfreevec benchmarks
From: Ryan S. Arnold @ 2008-08-22 17:50 UTC (permalink / raw)
To: Konstantinos Margaritis; +Cc: linuxppc-dev
In-Reply-To: <1219427047.7917.38.camel@localhost>
On Fri, 2008-08-22 at 12:44 -0500, Ryan S. Arnold wrote:
> Today, if glibc is configure with --with-cpu=970 it will actually
> default to the power optimizations for the string routines, as
> indicated
> by the sysdeps/powerpc/powerpc[32|64]/970/Implies files. It'd be
> worth
> verifying that your baseline glibc runs are against existing optimized
> versions of glibc. If they're not then this is a fault of the distro
> you're testing on.
I intended to say that "it will actually default to the POWER4
optimizations"
Regards,
Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development
^ permalink raw reply
* Why does one "stw" fail with address translation disabled in PPC405EP?
From: Zhou Rui @ 2008-08-22 18:27 UTC (permalink / raw)
To: linuxppc-dev
Hi, all:
I think I meet an odd problem with PPC405EP (PPChameleonEVB Board).
I am running a kernel module which will execute a user space
application. The entry point of the application is 0x100000a0. At the
moment when the processor tries to execute the application, 0x100000a0
is not in TLB (this can be seen from BDI by printing out TLB entries),
so DTLBMiss is called automatically and then finish_tlb_load. However,
InstructionAccess is followed and the problem arises here.
InstructionAccess starts from 0x400, and after instruction "0xc0000434
<InstructionAccess+52>: stw r12,64(r11)", machine check occurs.
This instruction will store the value of r12, which is 0x0 at this
moment, to address 0x03072de0. I am puzzled why this action leads to
machine check. Is it illegal to store 0x0 in a memory address? Or is
there some other cause of the machine check here?
405EP>r
GPR00: c31c5200 c3072da0 c03a97b0 100000a0
GPR04: c306a000 c306e000 c31c51b8 c306a000
GPR08: c0a64000 c0a64000 40000000 03072da0
GPR12: 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000
GPR20: 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000
GPR28: 00000000 c31d0000 100000a0 c306a000
CR : 20000000 MSR: 00001000
405EP>t
Core number : 0
Core state : debug mode
Debug entry cause : single step
Current PC : 0x00000434
Current CR : 0x20000000
Current MSR : 0x00001000
Current LR : 0xc31c478c
405EP>r
GPR00: c31c5200 c3072da0 c03a97b0 100000a0
GPR04: c306a000 c306e000 c31c51b8 c306a000
GPR08: c0a64000 c0a64000 40000000 03072da0
GPR12: 00000000 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000
GPR20: 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 00000000
GPR28: 00000000 c31d0000 100000a0 c306a000
CR : 20000000 MSR: 00001000
405EP>t
Core number : 0
Core state : debug mode
Debug entry cause : single step
Current PC : 0x00000200
Current CR : 0x20000000
Current MSR : 0x00001000
Current LR : 0xc31c478c
405EP>
The error message shows more information. I am also puzzled why NIP here
is 0x440 but not 0x434:
Data machine check in kernel mode.
PLB0: BEAR= 0x03072dd4 ACR= 0x00000000 BESR= 0x00c00000
PLB0 to OPB: BEAR= 0x04000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000440 LR: C31C478C CTR: 100000A0
REGS: c02a8f50 TRAP: 0202 Not tainted (2.6.19.2)
MSR: 00021000 <ME> CR: 20000000 XER: 00000000
TASK = c0399490[987] 'loader.xm' THREAD: c028a000
GPR00: C31C5200 C3072DA0 C0399490 100000A0 C306A000 C306E000 C31C51B8
C306A000
GPR08: C0413000 C0413000 FFFFFFFF 03072DA0 00000000 00000000 00000000
00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
GPR24: 00000000 00000000 00000000 00000000 00000000 C31D0000 100000A0
C306A000
NIP [00000440] 0x440
LR [C31C478C] jump_xm_dom+0x2c/0x48 [xm]
Call Trace:
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Data machine check in kernel mode.
PLB0: BEAR= 0x03072dc0 ACR= 0x00000000 BESR= 0x00800000
PLB0 to OPB: BEAR= 0x04000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#2]
NIP: C0002EA8 LR: C0002E94 CTR: C31C3094
REGS: c02a8f50 TRAP: 0202 Not tainted (2.6.19.2)
MSR: 00021030 <ME,IR,DR> CR: 22002022 XER: 00000000
TASK = c03990d0[905] 'klogd' THREAD: c0e34000
GPR00: C0002E94 C0E35F40 C03990D0 00000FFF 00000001 00000000 00000FFF
00000000
GPR08: 00000000 00000000 00021032 00000000 C0E34000 0804E364 100F0000
00000000
GPR16: 101009E8 1009DF98 100F0000 08046368 08046364 07FEF08C 08046130
08004B74
GPR24: 08004FA4 08046130 08004DB4 08004DB8 08004F70 080466BC 08046358
08046AC0
NIP [C0002EA8] ret_from_syscall+0x14/0x3c
LR [C0002E94] ret_from_syscall+0x0/0x3c
Call Trace:
[C0E35F40] [C0002E94] ret_from_syscall+0x0/0x3c (unreliable)
Instruction dump:
614a9634 5400103a 408000a0 7d4a002e 7d4803a6 39210010 4e800021 7c661b78
542c0024 3d400002 614a1032 7d400124 <812c0028> 3900fdfc 7120db0f
408201a4
Another question is when 0x100000a0 is missed in TLB, why the order of
calling kernel functions is DTLBMiss -- finish_tlb_load --
InstructionAccess?
Appreciate in advance for any advice!!!
Best Wishes
Zhou Rui
2008-08-22
__________________________________________________
¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] POWERPC: Allow 32-bit pgtable code to support 36-bit physical
From: Becky Bruce @ 2008-08-22 18:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B835DA11-AB52-476B-8DD9-327235DACB65@kernel.crashing.org>
On Aug 21, 2008, at 4:40 PM, Kumar Gala wrote:
>> #define _PMD_PRESENT 0
>> #define _PMD_PRESENT_MASK (PAGE_MASK)
>> @@ -517,7 +522,13 @@ extern unsigned long
>> bad_call_to_PMD_PAGE_SIZE(void);
>>
>> #define pte_none(pte) ((pte_val(pte) & ~_PTE_NONE_MASK) == 0)
>> #define pte_present(pte) (pte_val(pte) & _PAGE_PRESENT)
>> +
>> +#if (defined(CONFIG_PTE_64BIT) && (_PAGE_HASHPTE != 0))
>> +#define pte_clear(mm, addr, ptep) \
>> + do { pte_update((ptep), (~_PAGE_HASHPTE), __pte(0)); } while (0)
>
> drop the __pte(0), doesn't make sense for pte_update
Cut-and-paste strikes again :) Will fix, thanks.
>
>>
>> +#else
>> #define pte_clear(mm,addr,ptep) do { set_pte_at((mm), (addr),
>> (ptep), __pte(0)); } while (0)
>> +#endif
>
> Can we just always (for all ppc32) do:
>
> #define pte_clear(mm,addr,ptep) do { pte_update(ptep,
> (~_PAGE_HASHPTE), 0); } while (0)
>
> I've already changed this to be:
>
> #define pte_clear(mm,addr,ptep) do { pte_update(ptep, ~0, 0); }
> while (0)
That's fine, but it makes me dependent on your tree. Shall I respin
on top of your tree and have you pick this up, or are you going to
push your changes to Paulus?
>
>
>
>> /*
>> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/
>> include/asm/types.h
>> index d3374bc..a9a9262 100644
>> --- a/arch/powerpc/include/asm/types.h
>> +++ b/arch/powerpc/include/asm/types.h
>> @@ -55,7 +55,7 @@ typedef u64 phys_addr_t;
>> typedef u32 phys_addr_t;
>> #endif
>>
>> -#ifdef __powerpc64__
>> +#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
>> typedef u64 dma_addr_t;
>> #else
>> typedef u32 dma_addr_t;
>
> is this really part of this patchset of the IOMMU changes?
It doesn't really belong here - I'll move it.
Thanks,
B
^ permalink raw reply
* Re: porting linux 2.6.27 to embedded powerpc board
From: Laxmikant Rashinkar @ 2008-08-22 18:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]
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 00800000 ...
Image Name: Linux-2.6.27-rc2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1640425 Bytes = 1.6 MB
Load Address: 00400000
Entry Point: 0040055c
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01000000 ...
Image Name: flash_root.ext3.gz
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 13450106 Bytes = 12.8 MB
Load Address: 00000000
Entry Point: 00000000
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 <david.jander@protonic.nl>
To: linuxppc-embedded@ozlabs.org
Cc: Laxmikant Rashinkar <lk.atwork@yahoo.com>
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, somewhere in arch/powerpc/boot IIRC). The
command used to compile, should probably be something like this:
$ ./dtc -p 10240 -R 20 -I dts -o myplatform.dtb -O dtb -b 0 dts/myplatform.dts
Load the resulting .dtb file directly with u-boot (don't make an u-image out
of it).
That's all I remember right now... hope it helps.
Regards,
--
David Jander
[-- Attachment #2: Type: text/html, Size: 6395 bytes --]
^ permalink raw reply
* Re: Why does one "stw" fail with address translation disabled in PPC405EP?
From: Josh Boyer @ 2008-08-22 18:42 UTC (permalink / raw)
To: Zhou Rui; +Cc: linuxppc-dev
In-Reply-To: <1219429635.8882.22.camel@zr.gii.upv.es>
On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote:
>Hi, all:
> I think I meet an odd problem with PPC405EP (PPChameleonEVB Board).
What kernel version are you using?
> I am running a kernel module which will execute a user space
>application. The entry point of the application is 0x100000a0. At the
That should be the first clue that you are doing it wrong. Don't do
stuff like that in modules...
>moment when the processor tries to execute the application, 0x100000a0
>is not in TLB (this can be seen from BDI by printing out TLB entries),
>so DTLBMiss is called automatically and then finish_tlb_load. However,
>InstructionAccess is followed and the problem arises here.
>InstructionAccess starts from 0x400, and after instruction "0xc0000434
><InstructionAccess+52>: stw r12,64(r11)", machine check occurs.
>This instruction will store the value of r12, which is 0x0 at this
>moment, to address 0x03072de0. I am puzzled why this action leads to
>machine check. Is it illegal to store 0x0 in a memory address? Or is
>there some other cause of the machine check here?
I have no idea if you're using physical or virtual addresses here, so
there isn't much we can do to help you.
Do you have enough DRAM to cover that? Some of those boards only come
with 32MiB of DRAM.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox