* [PATCH 5/4] [POWERPC] Exception numbers are not relevent to iSeries
From: Stephen Rothwell @ 2007-08-21 6:39 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20070821145549.61a842d5.sfr@canb.auug.org.au>
so remove them from the macros.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/exception.h | 4 ++--
arch/powerpc/platforms/iseries/head.S | 24 ++++++++++++------------
2 files changed, 14 insertions(+), 14 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/exception.h b/arch/powerpc/platforms/iseries/exception.h
index 5b3f285..ced45a8 100644
--- a/arch/powerpc/platforms/iseries/exception.h
+++ b/arch/powerpc/platforms/iseries/exception.h
@@ -34,7 +34,7 @@
ori r10,r10,MSR_RI; \
mtmsrd r10,1
-#define STD_EXCEPTION_ISERIES(n, label, area) \
+#define STD_EXCEPTION_ISERIES(label, area) \
.globl label##_iSeries; \
label##_iSeries: \
HMT_MEDIUM; \
@@ -43,7 +43,7 @@ label##_iSeries: \
EXCEPTION_PROLOG_ISERIES_1; \
b label##_common
-#define MASKABLE_EXCEPTION_ISERIES(n, label) \
+#define MASKABLE_EXCEPTION_ISERIES(label) \
.globl label##_iSeries; \
label##_iSeries: \
HMT_MEDIUM; \
diff --git a/arch/powerpc/platforms/iseries/head.S b/arch/powerpc/platforms/iseries/head.S
index e9a3435..5381038 100644
--- a/arch/powerpc/platforms/iseries/head.S
+++ b/arch/powerpc/platforms/iseries/head.S
@@ -88,7 +88,7 @@ iSeries_secondary_smp_loop:
/*** ISeries-LPAR interrupt handlers ***/
- STD_EXCEPTION_ISERIES(0x200, machine_check, PACA_EXMC)
+ STD_EXCEPTION_ISERIES(machine_check, PACA_EXMC)
.globl data_access_iSeries
data_access_iSeries:
@@ -137,7 +137,7 @@ data_access_slb_iSeries:
ld r12,LPPACASRR1(r12)
b .slb_miss_realmode
- STD_EXCEPTION_ISERIES(0x400, instruction_access, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(instruction_access, PACA_EXGEN)
.globl instruction_access_slb_iSeries
instruction_access_slb_iSeries:
@@ -176,13 +176,13 @@ slb_miss_user_iseries:
b slb_miss_user_common
#endif
- MASKABLE_EXCEPTION_ISERIES(0x500, hardware_interrupt)
- STD_EXCEPTION_ISERIES(0x600, alignment, PACA_EXGEN)
- STD_EXCEPTION_ISERIES(0x700, program_check, PACA_EXGEN)
- STD_EXCEPTION_ISERIES(0x800, fp_unavailable, PACA_EXGEN)
- MASKABLE_EXCEPTION_ISERIES(0x900, decrementer)
- STD_EXCEPTION_ISERIES(0xa00, trap_0a, PACA_EXGEN)
- STD_EXCEPTION_ISERIES(0xb00, trap_0b, PACA_EXGEN)
+ MASKABLE_EXCEPTION_ISERIES(hardware_interrupt)
+ STD_EXCEPTION_ISERIES(alignment, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(program_check, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(fp_unavailable, PACA_EXGEN)
+ MASKABLE_EXCEPTION_ISERIES(decrementer)
+ STD_EXCEPTION_ISERIES(trap_0a, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(trap_0b, PACA_EXGEN)
.globl system_call_iSeries
system_call_iSeries:
@@ -191,9 +191,9 @@ system_call_iSeries:
EXCEPTION_PROLOG_ISERIES_1
b system_call_common
- STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN)
- STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN)
- STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(single_step, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(trap_0e, PACA_EXGEN)
+ STD_EXCEPTION_ISERIES(performance_monitor, PACA_EXGEN)
decrementer_iSeries_masked:
/* We may not have a valid TOC pointer in here. */
--
1.5.2.4
^ permalink raw reply related
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-21 7:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <929bf310708210055k3970c3chfc097ff776af439a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
Hi again,
After some googling I came to the conclusion that the best approach to
understanding how to write a driver for a device behind a PCI-XXX bridge is
to look at the source for the USB subsystem, although the USB subsystem is
actually a bus subssytem and not a class.
Correct me if I'm wrong.
Regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 501 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Johan Borkhuis @ 2007-08-21 8:32 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310708210056s2b699500x36c6b1ae83881496@mail.gmail.com>
Konstantin Boyanov wrote:
>
> Hi again,
>
> After some googling I came to the conclusion that the best approach to
> understanding how to write a driver for a device behind a PCI-XXX
> bridge is to look at the source for the USB subsystem, although the
> USB subsystem is actually a bus subssytem and not a class.
I also work with devices on the VME bus. The approach we took is to map
all the devices into userspace, and use Xenomai for RT performance. This
avoids the need to write drivers for all the devices. The RT-performance
of Xenomai is quite good: the jitter on a timer-interrupt is always less
than 20usec, even under high load, where standard Linux only achieves
this in a no load situatieo, under high load standard Linux has a jitter
of over 10 msec.
The setup we choose was to have a RT-interrupt handler and a RT IOCTL
call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the
Motorola driver (I guess that you also use the Tundra chipset to access
the VME-bus). Here you can wait for a specific VME interrupt-level, and
it returns the vector number. So you can have several applications
connect to the same VME driver, but all on different levels.
Kind regards,
Johan Borkhuis
^ permalink raw reply
* RE: Xilinx Virtex4 FX PPC
From: Stelios Koroneos @ 2007-08-21 8:52 UTC (permalink / raw)
To: Robert Woodworth, linuxppc-embedded
In-Reply-To: <1187625654.6336.28.camel@PisteOff>
> Question 1:
> Do I need a special glibc for the Xilinx PPC 405????
FYI we are at the last stage of implementing OpenEmbedded support for the
Xilinx ml403 (and hopefully other Xilinx boards in the near future)
It also handles the EDK header copying procedure "automagically" i.e you
point to your EDK project dir and pulls the file(s) it needs for the kernel.
We will be working to "automate" the generation of ACE files also, since OE
generates a full image (kernel+fs) and not just the toolchain.
Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28.
There is some work done by other OE developers to get eglibc going (omap
works according to the latest info i have)
OpenEmbedded supports a number of ppc targets currently walnut
(405),sequoia(440e),efika(603e) just to mention a few
I will be speaking at the Power.org dev conference about OE and power
architecure so if anyone will be there and wishes to get some knowledge
about OE in "advance" , feel free to drop me a mail, as we will releasing a
beta of our OE based distro soon.
Stelios S. Koroneos
Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
^ permalink raw reply
* Re: [PATCH 6/7 v2] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.
From: Vitaly Bordug @ 2007-08-21 9:01 UTC (permalink / raw)
To: Scott Wood; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070817181718.GA15792@ld0162-tx32.am.freescale.net>
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it,
> it will be removed, and the ethernet driver now talks to the device
> tree directly.
>
A bit short description, I'd rather expect some specific improvements list,
that are now up and running using device tree. Or if it is just move to new
infrastucture, let's state that, too.
Some other notes below.
> The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
> platforms are dropped from arch/ppc (which will hopefully be soon),
> and existing arch/powerpc boards that I wasn't able to test on for
> this patchset get converted (which should be even sooner).
>
> mii-bitbang.c now also uses the generic bitbang code.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Sorry, the previous version of this patch had bb_ops in the wrong
> place, and wouldn't build when not using the new binding.
>
> drivers/net/fs_enet/Kconfig | 1 +
> drivers/net/fs_enet/fs_enet-main.c | 286 ++++++++++++++++++++++--
> drivers/net/fs_enet/fs_enet.h | 55 +-----
> drivers/net/fs_enet/mac-fcc.c | 89 ++++++--
> drivers/net/fs_enet/mac-fec.c | 23 ++-
> drivers/net/fs_enet/mac-scc.c | 55 +++--
> drivers/net/fs_enet/mii-bitbang.c | 438
> ++++++++++++++++-------------------
> drivers/net/fs_enet/mii-fec.c | 140 ++++++++++++-
> include/linux/fs_enet_pd.h | 5 + 9 files changed, 740
> insertions(+), 352 deletions(-)
>
> diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
> index e27ee21..2765e49 100644
> --- a/drivers/net/fs_enet/Kconfig
> +++ b/drivers/net/fs_enet/Kconfig
> @@ -11,6 +11,7 @@ config FS_ENET_HAS_SCC
> config FS_ENET_HAS_FCC
> bool "Chip has an FCC usable for ethernet"
> depends on FS_ENET && CPM2
> + select MDIO_BITBANG
> default y
>
> config FS_ENET_HAS_FEC
> diff --git a/drivers/net/fs_enet/fs_enet-main.c
> b/drivers/net/fs_enet/fs_enet-main.c index 0ec30a8..7bf29a2 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -44,12 +44,18 @@
> #include <asm/irq.h>
> #include <asm/uaccess.h>
>
> +#ifdef CONFIG_PPC_CPM_NEW_BINDING
> +#include <linux/of_platform.h>
> +#endif
> +
> #include "fs_enet.h"
>
> /*************************************************/
>
> +#ifndef CONFIG_PPC_CPM_NEW_BINDING
> static char version[] __devinitdata =
> DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " ("
> DRV_MODULE_RELDATE ")" "\n"; +#endif
>
> MODULE_AUTHOR("Pantelis Antoniou <panto@intracom.gr>");
> MODULE_DESCRIPTION("Freescale Ethernet Driver");
> @@ -953,6 +959,7 @@ static int fs_ioctl(struct net_device *dev,
> struct ifreq *rq, int cmd) extern int fs_mii_connect(struct
> net_device *dev); extern void fs_mii_disconnect(struct net_device
> *dev);
> +#ifndef CONFIG_PPC_CPM_NEW_BINDING
> static struct net_device *fs_init_instance(struct device *dev,
> struct fs_platform_info *fpi)
> {
> @@ -1132,6 +1139,7 @@ static int fs_cleanup_instance(struct
> net_device *ndev)
> return 0;
> }
> +#endif
>
> /**************************************************************************************/
>
> @@ -1140,35 +1148,279 @@ void *fs_enet_immap = NULL;
>
> static int setup_immap(void)
> {
> - phys_addr_t paddr = 0;
> - unsigned long size = 0;
> -
> #ifdef CONFIG_CPM1
> - paddr = IMAP_ADDR;
> - size = 0x10000; /* map 64K */
> +#ifdef CONFIG_PPC_CPM_NEW_BINDING
> + fs_enet_immap = mpc8xx_immr;
> +#else
> + fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
> + WARN_ON(!fs_enet_immap);
> #endif
> -
> -#ifdef CONFIG_CPM2
> - paddr = CPM_MAP_ADDR;
> - size = 0x40000; /* map 256 K */
> +#elif defined(CONFIG_CPM2)
> + fs_enet_immap = cpm2_immr;
> #endif
> - fs_enet_immap = ioremap(paddr, size);
> - if (fs_enet_immap == NULL)
> - return -EBADF; /* XXX ahem; maybe just
> BUG_ON? */
> return 0;
> }
>
> +#ifndef CONFIG_PPC_CPM_NEW_BINDING
> static void cleanup_immap(void)
> {
> - if (fs_enet_immap != NULL) {
> - iounmap(fs_enet_immap);
> - fs_enet_immap = NULL;
> - }
> +#if defined(CONFIG_CPM1)
> + iounmap(fs_enet_immap);
> +#endif
> }
> +#endif
>
> /**************************************************************************************/
>
> +#ifdef CONFIG_PPC_CPM_NEW_BINDING
> +static int __devinit find_phy(struct device_node *np,
> + struct fs_platform_info *fpi)
> +{
> + struct device_node *phynode, *mdionode;
> + struct resource res;
> + int ret = 0, len;
> +
> + const u32 *data = of_get_property(np, "phy-handle", &len);
> + if (!data || len != 4)
> + return -EINVAL;
> +
> + phynode = of_find_node_by_phandle(*data);
> + if (!phynode)
> + return -EINVAL;
> +
> + mdionode = of_get_parent(phynode);
> + if (!phynode)
> + goto out_put_phy;
> +
> + ret = of_address_to_resource(mdionode, 0, &res);
> + if (ret)
> + goto out_put_mdio;
> +
> + data = of_get_property(phynode, "reg", &len);
> + if (!data || len != 4)
> + goto out_put_mdio;
> +
> + snprintf(fpi->bus_id, 16, PHY_ID_FMT, res.start, *data);
> +
> +out_put_mdio:
> + of_node_put(mdionode);
> +out_put_phy:
> + of_node_put(phynode);
> + return ret;
> +}
And without phy node?
> +
> +#ifdef CONFIG_FS_ENET_HAS_FEC
> +#define IS_FEC(match) ((match)->data == &fs_fec_ops)
> +#else
> +#define IS_FEC(match) 0
> +#endif
> +
Since we're talking directly with device tree, why bother with CONFIG_ stuff? We are able to figure it out from dts..
> +static int __devinit fs_enet_probe(struct of_device *ofdev,
> + const struct of_device_id *match)
> +{
> + struct net_device *ndev;
> + struct fs_enet_private *fep;
> + struct fs_platform_info *fpi;
> + const u32 *data;
> + const u8 *mac_addr;
> + int privsize, len, ret = -ENODEV;
> +
> + fpi = kzalloc(sizeof(*fpi), GFP_KERNEL);
> + if (!fpi)
> + return -ENOMEM;
> +
> + if (!IS_FEC(match)) {
> + data = of_get_property(ofdev->node,
> "fsl,cpm-command", &len);
> + if (!data || len != 4)
> + goto out_free_fpi;
> +
> + fpi->cp_command = *data;
> + }
> +
> + fpi->rx_ring = 32;
> + fpi->tx_ring = 32;
> + fpi->rx_copybreak = 240;
> + fpi->use_napi = 0;
> + fpi->napi_weight = 17;
> +
move params over to dts?
> + ret = find_phy(ofdev->node, fpi);
> + if (ret)
> + goto out_free_fpi;
> +
so we're hosed without phy node.
> + privsize = sizeof(*fep) +
> + sizeof(struct sk_buff **) *
> + (fpi->rx_ring + fpi->tx_ring);
> +
> + ndev = alloc_etherdev(privsize);
> + if (!ndev) {
> + ret = -ENOMEM;
> + goto out_free_fpi;
> + }
> +
> + SET_MODULE_OWNER(ndev);
> + dev_set_drvdata(&ofdev->dev, ndev);
> +
> + fep = netdev_priv(ndev);
> + fep->dev = &ofdev->dev;
> + fep->fpi = fpi;
> + fep->ops = match->data;
> +
> + ret = fep->ops->setup_data(ndev);
> + if (ret)
> + goto out_free_dev;
> +
> + fep->rx_skbuff = (struct sk_buff **)&fep[1];
> + fep->tx_skbuff = fep->rx_skbuff + fpi->rx_ring;
> +
> + spin_lock_init(&fep->lock);
> + spin_lock_init(&fep->tx_lock);
> +
> + mac_addr = of_get_mac_address(ofdev->node);
> + if (mac_addr)
> + memcpy(ndev->dev_addr, mac_addr, 6);
> +
> + ret = fep->ops->allocate_bd(ndev);
> + if (ret)
> + goto out_cleanup_data;
> +
> + fep->rx_bd_base = fep->ring_base;
> + fep->tx_bd_base = fep->rx_bd_base + fpi->rx_ring;
> +
> + fep->tx_ring = fpi->tx_ring;
> + fep->rx_ring = fpi->rx_ring;
> +
> + ndev->open = fs_enet_open;
> + ndev->hard_start_xmit = fs_enet_start_xmit;
> + ndev->tx_timeout = fs_timeout;
> + ndev->watchdog_timeo = 2 * HZ;
> + ndev->stop = fs_enet_close;
> + ndev->get_stats = fs_enet_get_stats;
> + ndev->set_multicast_list = fs_set_multicast_list;
> + if (fpi->use_napi) {
> + ndev->poll = fs_enet_rx_napi;
> + ndev->weight = fpi->napi_weight;
> + }
> + ndev->ethtool_ops = &fs_ethtool_ops;
> + ndev->do_ioctl = fs_ioctl;
> +
> + init_timer(&fep->phy_timer_list);
> +
> + netif_carrier_off(ndev);
> +
> + ret = register_netdev(ndev);
> + if (ret)
> + goto out_free_bd;
> +
> + printk(KERN_INFO "%s: fs_enet:
> %02x:%02x:%02x:%02x:%02x:%02x\n",
> + ndev->name,
> + ndev->dev_addr[0], ndev->dev_addr[1],
> ndev->dev_addr[2],
> + ndev->dev_addr[3], ndev->dev_addr[4],
> ndev->dev_addr[5]); +
> + return 0;
> +
> +out_free_bd:
> + fep->ops->free_bd(ndev);
> +out_cleanup_data:
> + fep->ops->cleanup_data(ndev);
> +out_free_dev:
> + free_netdev(ndev);
> + dev_set_drvdata(&ofdev->dev, NULL);
> +out_free_fpi:
> + kfree(fpi);
> + return ret;
> +}
> +
> +static int fs_enet_remove(struct of_device *ofdev)
> +{
> + struct net_device *ndev = dev_get_drvdata(&ofdev->dev);
> + struct fs_enet_private *fep = netdev_priv(ndev);
> +
> + unregister_netdev(ndev);
> +
> + fep->ops->free_bd(ndev);
> + fep->ops->cleanup_data(ndev);
> + dev_set_drvdata(fep->dev, NULL);
> +
> + free_netdev(ndev);
> + return 0;
> +}
> +
> +static struct of_device_id fs_enet_match[] = {
> +#ifdef CONFIG_FS_ENET_HAS_SCC
same nagging. Are we able to get rid of Kconfig arcane defining which SoC currently plays the game for fs_enet?
[snip]...
--
Sincerely, Vitaly
^ permalink raw reply
* (no subject)
From: ramesh mrm @ 2007-08-21 9:24 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc
directory we don't have that types of file and the function
pciauto_bus_scan() also removed.
I want to know where the function was moved in arch/powerpc directory ?
How the host bridge was skip in the arch/powerpc directory.
Thanks and Regards
Ramesh
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply
* (no subject)
From: ramesh mrm @ 2007-08-21 9:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc
directory we don't have that types of file and the function
pciauto_bus_scan() also removed.
I want to know where the function was moved in arch/powerpc directory ?
How the host bridge was skip in the arch/powerpc directory.
Thanks and Regards
Ramesh
[-- Attachment #2: Type: text/html, Size: 553 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-21 9:49 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46CAA332.9060907@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
Hi again,
I also work with devices on the VME bus. The approach we took is to map
> all the devices into userspace, and use Xenomai for RT performance. This
> avoids the need to write drivers for all the devices. The RT-performance
> of Xenomai is quite good: the jitter on a timer-interrupt is always less
> than 20usec, even under high load, where standard Linux only achieves
> this in a no load situatieo, under high load standard Linux has a jitter
> of over 10 msec.
Good advice, I will investigate in this direction.
The setup we choose was to have a RT-interrupt handler and a RT IOCTL
> call "WAIT_FOR_INTERRUPT". This is a slightly modified version from the
> Motorola driver (I guess that you also use the Tundra chipset to access
> the VME-bus).
Yes, I do. It is the Tsi148 in fact. I'll be interested to see some sample
code of yours, if it doesn't violate some restrictions ofcourse.
Here you can wait for a specific VME interrupt-level, and
> it returns the vector number. So you can have several applications
> connect to the same VME driver, but all on different levels.
So, if I understand you correctly, you altered the Motorola driver in order
for it to be able to communicate with user spae programms through Xenomai.
Which version of Xenomai ws that? I tried to test Xemonai 2.0 on my setup
but it iterfred somehow with SSH configuration and thats why i dropped it.
Many thanks,
Konstantin
[-- Attachment #2: Type: text/html, Size: 2017 bytes --]
^ permalink raw reply
* OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 11:12 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
Hi guys,
Just a query here, there was a patch for /chosen/initrd,start and initrd,end
variables gained from firmware or so, which allowed booting without getting
those values into r3/r4, does anyone know the maintainer/author of that
patch?
Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine
it's fairly useful (at least it is to me)..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 11:21 UTC (permalink / raw)
To: ppc-dev, linuxppc-embedded
In-Reply-To: <46CAC89F.2040100@genesi-usa.com>
Damn, I should use patchwork more efficiently;
http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
Does anyone have any suggestion on the best way to integrate this so that
it "just works" on OF platforms? It seems only to be usable way too late
in boot to work, this code would have to be called in boot/main.c which seems
relatively.. impossible to achieve.. or called in some specialised platform
init code..
I hacked up a patch initially before I saw Milton's work and did it all
in main.c (and did the same to mkvmlinuz..) and it seemed to work okay
there.
I'm really curious as to the status and usefulness of this here.. :(
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Matt Sealey wrote:
> Hi guys,
>
> Just a query here, there was a patch for /chosen/initrd,start and initrd,end
> variables gained from firmware or so, which allowed booting without getting
> those values into r3/r4, does anyone know the maintainer/author of that
> patch?
>
> Also, what are the chances of pushing it for 2.6.23 or 2.6.24? I can imagine
> it's fairly useful (at least it is to me)..
>
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 11:32 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CACAAE.5000304@genesi-usa.com>
On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
> Damn, I should use patchwork more efficiently;
>
> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
>
> Does anyone have any suggestion on the best way to integrate this so that
> it "just works" on OF platforms? It seems only to be usable way too late
> in boot to work, this code would have to be called in boot/main.c which seems
> relatively.. impossible to achieve.. or called in some specialised platform
> init code..
It would have to be called from platform_init(). If called in main()
it would clobber any other platform-specific initialization of the
initrd parameters in loader_info.
> I hacked up a patch initially before I saw Milton's work and did it all
> in main.c (and did the same to mkvmlinuz..) and it seemed to work okay
> there.
>
> I'm really curious as to the status and usefulness of this here.. :(
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: PS3 improved video mode autodetection for HDMI/DVI
From: Stefan Assmann @ 2007-08-21 11:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development,
Ben Collins
In-Reply-To: <Pine.LNX.4.62.0708201740080.6197@pademelon.sonytel.be>
Geert Uytterhoeven schrieb:
> I know you could get the PS3AV_CID_AV_VIDEO_DISABLE_SIG message in some cases
> when booting immediately into a VESA mode.
>
> I see you have
>
> CONFIG_CMDLINE="quiet sysrq=1 panic=42 video=ps3fb:mode:0"
>
> Does it go away if you remove the `video=...'?
>
removing video=ps3fb:mode:0 from CONFIG_CMDLINE has no effect.
Stefan
^ permalink raw reply
* Regarding PCIExpress Problem in MPC8641D
From: sivaji @ 2007-08-21 12:09 UTC (permalink / raw)
To: linuxppc-dev
Hai,
Currently I am involved in the testing of a MPC8641D based board designed by
us. We have planned to test the PCI Express interface through a back to back
interface, host being mpc8641d and target is mpc8548.
When trying a target DMA transaction we are not able to access the host
memory using pci Express bus. We are facingDMA Transfer Error. Without DMA
we are able to access the host memory from the target and target memory from
the host.
The processor rev number is 2.0. The external irq[0-3] are pulled down and
the polarity is active low and it is level sensitive.
Memory base address : 0x80000000 size:512MB
I/O base address : 0xe2000000 size:16MB.
Kernel Version : 2.6.21
PCI Express device node in the device tree:
pci@8000 {
compatible = "fsl,mpc86xx-pciex";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8000 1000>;
bus-range = <0 fe>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 01000000>;
clock-frequency = <1fca055>;
interrupt-parent = <40000>;
interrupts = <18 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 (PEX) */
0000 0 0 1 40000 30 2
0000 0 0 2 40000 31 2
0000 0 0 3 40000 32 2
0000 0 0 4 40000 33 2 >;
};
lspci result:
00:00.0 Class 0b20: 1957:7011 (rev 20)
!!! Invalid class 0b20 for header type 01
Flags: bus master, fast devsel, latency 0
Memory at 80400000 (32-bit, non-prefetchable) [size=1M]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 9ff00000-9fffffff
Prefetchable memory behind bridge: 000000009fe00000-000000009fe00000
Capabilities: [44] Power Management version 2
Capabilities: [4c] #10 [0041]
00: 57 19 11 70 06 01 10 00 20 00 20 0b 00 00 01 00
10: 00 00 40 80 00 00 00 00 00 01 01 00 00 00 00 20
20: f0 9f f0 9f e1 9f e1 9f 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 00 00
01:00.0 Class 0b20: 1957:0012 (rev 20) (prog-if 01)
Flags: bus master, fast devsel, latency 0, IRQ 48
Memory at 80000000 (32-bit, non-prefetchable) [size=1M]
Memory at 80100000 (32-bit, non-prefetchable) [size=1M]
Memory at 80200000 (64-bit, non-prefetchable) [size=1M]
Memory at 80300000 (64-bit, non-prefetchable) [size=1M]
Capabilities: [44] Power Management version 2
Capabilities: [4c] #10 [0001]
Capabilities: [70] Message Signalled Interrupts: 64bit+ Queue=0/4
Enable-
00: 57 19 12 00 06 00 10 00 20 01 20 0b 08 00 00 00
10: 00 00 00 80 00 00 10 80 04 00 20 80 00 00 00 00
20: 04 00 30 80 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 44 00 00 00 00 00 00 00 00 01 00 00
Host config space result(the value was taken in the kernel):
Vendor ID = 0x1957
Device ID = 0x7011
Command Register = 0x106
Status Register = 0x10
Revision ID = 0x20
Base class = 0x0
Sub Class = 0x20
Programming Interface = 0xb
Cache line register = 0x0
Latency Timer = 0x0
Header type = 0x1
BAR Address Register 0 = 0x80400000
Primary Bus Number Register = 0x0
Secondary Bus Number Register = 0x1
Subordinate Bus Number Register = 0x1
PCI Express I/O Base Register :0x0
PCI Express I/O Limit Register = 0x0
PCI Express Secondary Status Register = 0x2000
PCI Express Memory Base Register = 0x9ff0
PCI Express Memory I/O Limit Register = 0x9ff0
PCI Express Prefetchable Memory Base Register = 0x9fe1
PCI Express Prefetchable Memory Limit Register = 0x9fe1
PCI Express Prefetchable Base Upper 32 BitsRegister = 0x0
PCI Express Prefetchable Limite Upper 32 BitsRegister = 0x0
PCI Express I/O Base upper 16 BitsRegister = 0x0
PCI Express I/O Limit upper 16 BitsRegister = 0x0
PCI Express Capabilites pointer Register = 0x44
PCI Express Interrupt Line Register = 0x0
PCI Express Interrupt Pin Register = 0x0
PCI Express Bridge Control Register = 0x0
Please advice me.
--
View this message in context: http://www.nabble.com/Regarding-PCIExpress-Problem-in-MPC8641D-tf4304754.html#a12253307
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Skipping the host bridge in arch/powerpc
From: sivaji @ 2007-08-21 12:13 UTC (permalink / raw)
To: linuxppc-dev
Hai,
I am using the kernel 2.6.21. In the file
(arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan(). In
this function it will skip the host birdge. But in the arch/powepc directory
we don't have that types of file and the function pciauto_bus_scan() also
removed.
I want to know where the function was moved in arch/powerpc directory ?
How the host bridge was skip in the arch/powerpc directory.
--
View this message in context: http://www.nabble.com/Skipping-the-host-bridge-in-arch-powerpc-tf4304798.html#a12253417
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Linux 2.6.23.rc3 boot issues on XUPV2P
From: Computer - Service @ 2007-08-21 12:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070821113232.GB1111@localhost.localdomain>
Hi all.
I try to port Linux 2.6 on my XUPV2P Board which is based on ML300.
It runs sometimes, but for the usual case it just doesn't.
My problem is the initialization.
I have no clue why I get different values almost every time.
This is a log from the same zImage.elf, which is just loaded certain
times in the row:
loaded at: 00400000 005331A0
board data at: 0000000E 0000008A
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 3B784800
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
loaded at: 00400000 005331A0
board data at: 00000000 0000007C
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 7C9E2378
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
loaded at: 00400000 005331A0
board data at: 40000000 4000007C
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 00000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...oops... out of memory
pause
loaded at: 00400000 005331A0
board data at: 00000001 0000007D
relocated to: 00404084 00404100
zimage at: 00404EB9 00530A50
avail ram: 00534000 9E23787C
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.23-rc3 (warkentin@iss2) (gcc version
4.1.1) #1 Tue Aug 21 14:01:45
CEST 2007
[ 0.000000] Xilinx ML300 Reference System (Virtex-II Pro)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 196608
and just if the "avial ram" is about 10000000 it boots.
Anyone some idea why it could happens?
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 12:36 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821113232.GB1111@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
>> Damn, I should use patchwork more efficiently;
>>
>> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
>>
>> Does anyone have any suggestion on the best way to integrate this so that
>> it "just works" on OF platforms? It seems only to be usable way too late
>> in boot to work, this code would have to be called in boot/main.c which seems
>> relatively.. impossible to achieve.. or called in some specialised platform
>> init code..
>
> It would have to be called from platform_init(). If called in main()
> it would clobber any other platform-specific initialization of the
> initrd parameters in loader_info.
So just to get this straight.. platform_init would be the function called from
md.init or would be better at md.setup_arch?
My goal right now is get something for CHRP (Pegasos) and Efika and try not
to cause problems for anything else, but also really try not to clutter the
thing with config checks, platform checks etc.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: David Gibson @ 2007-08-21 12:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev, linuxppc-embedded
In-Reply-To: <46CADC61.3050506@genesi-usa.com>
On Tue, Aug 21, 2007 at 01:36:49PM +0100, Matt Sealey wrote:
> David Gibson wrote:
> > On Tue, Aug 21, 2007 at 12:21:18PM +0100, Matt Sealey wrote:
> >> Damn, I should use patchwork more efficiently;
> >>
> >> http://patchwork.ozlabs.org/linuxppc/patch?q=initrd&filter=none&id=12168
> >>
> >> Does anyone have any suggestion on the best way to integrate this so that
> >> it "just works" on OF platforms? It seems only to be usable way too late
> >> in boot to work, this code would have to be called in boot/main.c which seems
> >> relatively.. impossible to achieve.. or called in some specialised platform
> >> init code..
> >
> > It would have to be called from platform_init(). If called in main()
> > it would clobber any other platform-specific initialization of the
> > initrd parameters in loader_info.
>
> So just to get this straight.. platform_init would be the function
> called from md.init or would be better at md.setup_arch?
Uh... no... this is in the bootwrapper, long before ppc_md even
exists. platform_init() is called from arch/powerpc/boot/crt0.S,
immediately before main().
> My goal right now is get something for CHRP (Pegasos) and Efika and try not
> to cause problems for anything else, but also really try not to clutter the
> thing with config checks, platform checks etc.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: Arnd Bergmann @ 2007-08-21 12:05 UTC (permalink / raw)
To: Josh Boyer, Scott Wood, linuxppc-dev
In-Reply-To: <20070821025015.GN15469@localhost.localdomain>
On Tuesday 21 August 2007, David Gibson wrote:
>=20
> > > > The point would be to keep the two trees separate, so that one
> > > > doesn't need to worry about breaking arch/ppc when making a change
> > > > to arch/powerpc.
> > >=20
> > > Exactly so. =A0Having to be careful about not breaking arch/ppc when
> > > doing cleanups for arch/powerpc is a pain in the bum.
> >=20
> > How many times has that happened recently? =A0If it's fairly infrequent,
>=20
> It's infrequent because I've shyed away from cleaning up shared files,
> precisely because I'm afraid of breaking arch/ppc.
How about splitting the files on a per-case bases then? There are at least
95 files that would need to be duplicated (again) to make ppc independent
from powerpc, and most of these files are about userland interfaces where
duplication makes no sense at all.
Some files in there (irq.h, ipic.h, dcr.h, i8259.h) already have large
parts hidden in #ifdef CONFIG_PPC_MERGE, so I guess for those it may
actually be interesting to split them in two again.
Arnd <><
^ permalink raw reply
* Re: Linux 2.6.23.rc3 boot issues on XUPV2P
From: Grant Likely @ 2007-08-21 12:52 UTC (permalink / raw)
To: Computer - Service; +Cc: linuxppc-embedded
In-Reply-To: <46CAD865.3030107@gmx.de>
On 8/21/07, Computer - Service <computer-service@gmx.de> wrote:
> Hi all.
>
> I try to port Linux 2.6 on my XUPV2P Board which is based on ML300.
>
> It runs sometimes, but for the usual case it just doesn't.
> My problem is the initialization.
> I have no clue why I get different values almost every time.
> This is a log from the same zImage.elf, which is just loaded certain
> times in the row:
Check that the Virtex support code in
arch/ppc/boot/simple/embed_config.c is getting compiled in (hint:
search for ML403). If it's configured out, then your board info
structure won't get setup correctly.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/3 v2] Remove need for include/asm-ppc
From: Josh Boyer @ 2007-08-21 12:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200708211405.59226.arnd@arndb.de>
On Tue, 21 Aug 2007 14:05:58 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 21 August 2007, David Gibson wrote:
> >=20
> > > > > The point would be to keep the two trees separate, so that one
> > > > > doesn't need to worry about breaking arch/ppc when making a change
> > > > > to arch/powerpc.
> > > >=20
> > > > Exactly so. =C2=A0Having to be careful about not breaking arch/ppc =
when
> > > > doing cleanups for arch/powerpc is a pain in the bum.
> > >=20
> > > How many times has that happened recently? =C2=A0If it's fairly infre=
quent,
> >=20
> > It's infrequent because I've shyed away from cleaning up shared files,
> > precisely because I'm afraid of breaking arch/ppc.
>=20
> How about splitting the files on a per-case bases then? There are at least
> 95 files that would need to be duplicated (again) to make ppc independent
> from powerpc, and most of these files are about userland interfaces where
> duplication makes no sense at all.
Sure. I said that in my previous reply too.
> Some files in there (irq.h, ipic.h, dcr.h, i8259.h) already have large
> parts hidden in #ifdef CONFIG_PPC_MERGE, so I guess for those it may
> actually be interesting to split them in two again.
Yeah, for those it might.
josh
^ permalink raw reply
* Re: Xilinx Virtex4 FX PPC
From: Josh Boyer @ 2007-08-21 12:57 UTC (permalink / raw)
To: Stelios Koroneos; +Cc: linuxppc-embedded
In-Reply-To: <HOECLKEKOHLAMMGDLLBHEEGHMAAA.stelios@stelioscellar.com>
On Tue, 21 Aug 2007 11:52:35 +0300
"Stelios Koroneos" <stelios@stelioscellar.com> wrote:
> > Question 1:
> > Do I need a special glibc for the Xilinx PPC 405????
>
> FYI we are at the last stage of implementing OpenEmbedded support for the
> Xilinx ml403 (and hopefully other Xilinx boards in the near future)
Cool.
> It also handles the EDK header copying procedure "automagically" i.e you
> point to your EDK project dir and pulls the file(s) it needs for the kernel.
> We will be working to "automate" the generation of ACE files also, since OE
> generates a full image (kernel+fs) and not just the toolchain.
> Currently toolchain is gcc 4.1.1 with glibc 2.5 and/or uclibc 0.9.28.
> There is some work done by other OE developers to get eglibc going (omap
> works according to the latest info i have)
>
> OpenEmbedded supports a number of ppc targets currently walnut
> (405),sequoia(440e),efika(603e) just to mention a few
>
> I will be speaking at the Power.org dev conference about OE and power
> architecure so if anyone will be there and wishes to get some knowledge
> about OE in "advance" , feel free to drop me a mail, as we will releasing a
> beta of our OE based distro soon.
I'm hoping to attend as well. Should be interesting.
josh
^ permalink raw reply
* Re: OF /chosen/initrd,* variables - patch, official?
From: Matt Sealey @ 2007-08-21 12:58 UTC (permalink / raw)
To: Matt Sealey, ppc-dev, linuxppc-embedded
In-Reply-To: <20070821124253.GC1111@localhost.localdomain>
David Gibson wrote:
> Uh... no... this is in the bootwrapper, long before ppc_md even
> exists. platform_init() is called from arch/powerpc/boot/crt0.S,
> immediately before main().
Oh *THAT* platform init.
So I could just drop a
} else {
dt_find_initrd();
}
.. at the end and nobody would be too disgusted or have any problems?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Regarding PCIExpress Problem in MPC8641D
From: Kumar Gala @ 2007-08-21 13:15 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12253307.post@talk.nabble.com>
On Aug 21, 2007, at 7:09 AM, sivaji wrote:
>
> Hai,
>
> Currently I am involved in the testing of a MPC8641D based board
> designed by
> us. We have planned to test the PCI Express interface through a
> back to back
> interface, host being mpc8641d and target is mpc8548.
>
> When trying a target DMA transaction we are not able to access the
> host
> memory using pci Express bus. We are facingDMA Transfer Error.
> Without DMA
> we are able to access the host memory from the target and target
> memory from
> the host.
>
>
> The processor rev number is 2.0. The external irq[0-3] are pulled
> down and
> the polarity is active low and it is level sensitive.
>
> Memory base address : 0x80000000 size:512MB
> I/O base address : 0xe2000000 size:16MB.
> Kernel Version : 2.6.21
I suggest upgrading to 2.6.23-rc3. There are a number of PCIe
related fixes that have gone in.
- k
^ permalink raw reply
* Re: Skipping the host bridge in arch/powerpc
From: Kumar Gala @ 2007-08-21 13:17 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12253417.post@talk.nabble.com>
On Aug 21, 2007, at 7:13 AM, sivaji wrote:
>
> Hai,
> I am using the kernel 2.6.21. In the file
> (arch/ppc/syslib/pci_auto.c) we have the function pciauto_bus_scan
> (). In
> this function it will skip the host birdge. But in the arch/powepc
> directory
> we don't have that types of file and the function pciauto_bus_scan
> () also
> removed.
> I want to know where the function was moved in arch/powerpc
> directory ?
This code doesn't exist in arch/powerpc we use more of the generic
drivers/pci code
> How the host bridge was skip in the arch/powerpc directory.
Again, if you look 2.6.23-rc3 there have been some fixes so you don't
need to skip the host bridge anymore for Freescale PPC.
- k
^ permalink raw reply
* [PATCH v4 0/2] SPI support for fsl_soc and mpc832x_rdb
From: Anton Vorontsov @ 2007-08-21 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Thanks for the previous reviews, this is v4 against Linus' tree,
as of today.
Changelog:
v3 -> v4
- removed fsl,device-id property from SPI nodes;
- instead of fsl_spi_info structure, now fsl_spi_init() accepting
four arguments;
- machine_is(mpc832x_rdb) added in the beginning of
mpc832x_spi_init().
v2 -> v3
o Device tree:
- completely removed mmc node;
- removed pio-handles and pio-maps.
o board file:
- Instead of par_io_of_config(), now par_io_config_pin() used to
configure GPIO pins, which does not require device tree node.
v1 -> v2
o Device tree:
- cosmetic cleanups (@01 -> @1);
- device-id renamed to fsl,device-id;
- removed max-chipselect and sysclk properties from spi node;
- removed chipselect property from mmc node, now reg property
used for this purpose, thereby address-cells and size-cells
added to the spi node;
- other non-mandatory (device-id, device_type, compatible, ...)
properties removed from mmc node, today board file is using
of_find_node_by_name(), instead of of_find_compatible_node();
- "qe" mode renamed to "cpu-qe".
o board file <-> fsl_soc interaction
- fsl_soc no longer scans for SPI nodes in the arch initcall.
Also it's no longer exports any global variables. Instead, it's
export fsl_spi_init function now, which accepts pointer to the
fsl_spi_board_info structure;
- board file fills fsl_spi_board_info structure and issues
fsl_spi_init(), which register SPI devices and SPI board infos.
Various sanity checks also perfromed.
I'd want to note that if spi_mpc83xx will be converted to
of_platform_driver then the scheme described above will not
work anymore, and I'll have to revert back ugly hacks:
global variables for activate/deactivate_cs functions. I see
no other options.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ 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