* [PATCH 08/14] spufs: remove support for ancient firmware
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
Any firmware that still uses the 'spc' nodes already
stopped running for other reasons, so lets get rid of this.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6/arch/powerpc/platforms/cell/spu_base.c
@@ -791,18 +791,6 @@ static int __init init_spu_base(void)
break;
}
}
- /* in some old firmware versions, the spe is called 'spc', so we
- look for that as well */
- for (node = of_find_node_by_type(NULL, "spc");
- node; node = of_find_node_by_type(node, "spc")) {
- ret = create_spu(node);
- if (ret) {
- printk(KERN_WARNING "%s: Error initializing %s\n",
- __FUNCTION__, node->name);
- cleanup_spu_base();
- break;
- }
- }
return ret;
}
module_init(init_spu_base);
--
^ permalink raw reply
* [PATCH 09/14] spufs: add support for read/write on cntl
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
Writing to cntl can be used to stop execution on the
spu and to restart it, reading from cntl gives the
contents of the current status register.
The access is always in ascii, as for most other files.
This was always meant to be there, but we had a little
problem with writing to runctl so it was left out so
far.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/file.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
@@ -211,37 +211,43 @@ static int spufs_cntl_mmap(struct file *
#define spufs_cntl_mmap NULL
#endif /* !SPUFS_MMAP_4K */
-static int spufs_cntl_open(struct inode *inode, struct file *file)
+static u64 spufs_cntl_get(void *data)
{
- struct spufs_inode_info *i = SPUFS_I(inode);
- struct spu_context *ctx = i->i_ctx;
+ struct spu_context *ctx = data;
+ u64 val;
- file->private_data = ctx;
- file->f_mapping = inode->i_mapping;
- ctx->cntl = inode->i_mapping;
- return 0;
+ spu_acquire(ctx);
+ val = ctx->ops->status_read(ctx);
+ spu_release(ctx);
+
+ return val;
}
-static ssize_t
-spufs_cntl_read(struct file *file, char __user *buffer,
- size_t size, loff_t *pos)
+static void spufs_cntl_set(void *data, u64 val)
{
- /* FIXME: read from spu status */
- return -EINVAL;
+ struct spu_context *ctx = data;
+
+ spu_acquire(ctx);
+ ctx->ops->runcntl_write(ctx, val);
+ spu_release(ctx);
}
-static ssize_t
-spufs_cntl_write(struct file *file, const char __user *buffer,
- size_t size, loff_t *pos)
+static int spufs_cntl_open(struct inode *inode, struct file *file)
{
- /* FIXME: write to runctl bit */
- return -EINVAL;
+ struct spufs_inode_info *i = SPUFS_I(inode);
+ struct spu_context *ctx = i->i_ctx;
+
+ file->private_data = ctx;
+ file->f_mapping = inode->i_mapping;
+ ctx->cntl = inode->i_mapping;
+ return simple_attr_open(inode, file, spufs_cntl_get,
+ spufs_cntl_set, "0x%08lx");
}
static struct file_operations spufs_cntl_fops = {
.open = spufs_cntl_open,
- .read = spufs_cntl_read,
- .write = spufs_cntl_write,
+ .read = simple_attr_read,
+ .write = simple_attr_write,
.mmap = spufs_cntl_mmap,
};
--
^ permalink raw reply
* [PATCH 10/14] spufs: support new OF device tree format
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
The properties we used traditionally in the device tree
are somewhat nonstandard, this adds support for a more
conventional format using 'interrupts' and 'reg'
properties.
The interrupts are specified in three cells (class 0,
1 and 2) and registered at the interrupt-parent.
The reg property contains either three or four register
areas in the order 'local-store', 'problem', 'priv2',
and 'priv1', so the priv1 one can be left out in
case of hypervisor driven systems that access these
through hcalls.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spu_base.c
+++ linux-2.6/arch/powerpc/platforms/cell/spu_base.c
@@ -25,11 +25,13 @@
#include <linux/interrupt.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/pci.h>
#include <linux/poll.h>
#include <linux/ptrace.h>
#include <linux/slab.h>
#include <linux/wait.h>
+#include <asm/firmware.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <linux/mutex.h>
@@ -576,7 +578,7 @@ static void spu_unmap(struct spu *spu)
}
/* This function shall be abstracted for HV platforms */
-static int __init spu_map_interrupts(struct spu *spu, struct device_node *np)
+static int __init spu_map_interrupts_old(struct spu *spu, struct device_node *np)
{
unsigned int isrc;
const u32 *tmp;
@@ -600,7 +602,7 @@ static int __init spu_map_interrupts(str
return spu->irqs[2] == NO_IRQ ? -EINVAL : 0;
}
-static int __init spu_map_device(struct spu *spu, struct device_node *node)
+static int __init spu_map_device_old(struct spu *spu, struct device_node *node)
{
const char *prop;
int ret;
@@ -645,6 +647,88 @@ out:
return ret;
}
+static int __init spu_map_interrupts(struct spu *spu, struct device_node *np)
+{
+ struct of_irq oirq;
+ int ret;
+ int i;
+
+ for (i=0; i < 3; i++) {
+ ret = of_irq_map_one(np, i, &oirq);
+ if (ret)
+ goto err;
+
+ ret = -EINVAL;
+ spu->irqs[i] = irq_create_of_mapping(oirq.controller,
+ oirq.specifier, oirq.size);
+ if (spu->irqs[i] == NO_IRQ)
+ goto err;
+ }
+ return 0;
+
+err:
+ pr_debug("failed to map irq %x for spu %s\n", *oirq.specifier, spu->name);
+ for (; i >= 0; i--) {
+ if (spu->irqs[i] != NO_IRQ)
+ irq_dispose_mapping(spu->irqs[i]);
+ }
+ return ret;
+}
+
+static int spu_map_resource(struct device_node *node, int nr,
+ void __iomem** virt, unsigned long *phys)
+{
+ struct resource resource = { };
+ int ret;
+
+ ret = of_address_to_resource(node, 0, &resource);
+ if (ret)
+ goto out;
+
+ if (phys)
+ *phys = resource.start;
+ *virt = ioremap(resource.start, resource.end - resource.start);
+ if (!*virt)
+ ret = -EINVAL;
+
+out:
+ return ret;
+}
+
+static int __init spu_map_device(struct spu *spu, struct device_node *node)
+{
+ int ret = -ENODEV;
+ spu->name = get_property(node, "name", NULL);
+ if (!spu->name)
+ goto out;
+
+ ret = spu_map_resource(node, 0, (void __iomem**)&spu->local_store,
+ &spu->local_store_phys);
+ if (ret)
+ goto out;
+ ret = spu_map_resource(node, 1, (void __iomem**)&spu->problem,
+ &spu->problem_phys);
+ if (ret)
+ goto out_unmap;
+ ret = spu_map_resource(node, 2, (void __iomem**)&spu->priv2,
+ NULL);
+ if (ret)
+ goto out_unmap;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ ret = spu_map_resource(node, 3, (void __iomem**)&spu->priv1,
+ NULL);
+ if (ret)
+ goto out_unmap;
+ return 0;
+
+out_unmap:
+ spu_unmap(spu);
+out:
+ pr_debug("failed to map spe %s: %d\n", spu->name, ret);
+ return ret;
+}
+
struct sysdev_class spu_sysdev_class = {
set_kset_name("spu")
};
@@ -698,6 +782,9 @@ static int __init create_spu(struct devi
goto out;
ret = spu_map_device(spu, spe);
+ /* try old method */
+ if (ret)
+ ret = spu_map_device_old(spu, spe);
if (ret)
goto out_free;
@@ -707,6 +794,8 @@ static int __init create_spu(struct devi
spu->nid = 0;
ret = spu_map_interrupts(spu, spe);
if (ret)
+ ret = spu_map_interrupts_old(spu, spe);
+ if (ret)
goto out_unmap;
spin_lock_init(&spu->register_lock);
spu_mfc_sdr_set(spu, mfspr(SPRN_SDR1));
@@ -716,7 +805,7 @@ static int __init create_spu(struct devi
spu->number = number++;
ret = spu_request_irqs(spu);
if (ret)
- goto out_unmap;
+ goto out_unlock;
ret = spu_create_sysdev(spu);
if (ret)
@@ -732,9 +821,9 @@ static int __init create_spu(struct devi
out_free_irqs:
spu_free_irqs(spu);
-
-out_unmap:
+out_unlock:
mutex_unlock(&spu_mutex);
+out_unmap:
spu_unmap(spu);
out_free:
kfree(spu);
--
^ permalink raw reply
* [PATCH 11/14] spufs: add infrastructure for finding elf objects
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
This adds an 'object-id' file that the spe library can
use to store a pointer to its ELF object. This was
originally meant for use by oprofile, but is now
also used by the GNU debugger, if available.
In order for oprofile to find the location in an spu-elf
binary where an event counter triggered, we need a way
to identify the binary in the first place.
Unfortunately, that binary itself can be embedded in a
powerpc ELF binary. Since we can assume it is mapped into
the effective address space of the running process,
have that one write the pointer value into a new spufs
file.
When a context switch occurs, pass the user value to
the profiler so that can look at the mapped file (with
some care).
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/file.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
@@ -1487,6 +1487,21 @@ static u64 spufs_id_get(void *data)
}
DEFINE_SIMPLE_ATTRIBUTE(spufs_id_ops, spufs_id_get, NULL, "0x%llx\n")
+static u64 spufs_object_id_get(void *data)
+{
+ struct spu_context *ctx = data;
+ return ctx->object_id;
+}
+
+static void spufs_object_id_set(void *data, u64 id)
+{
+ struct spu_context *ctx = data;
+ ctx->object_id = id;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(spufs_object_id_ops, spufs_object_id_get,
+ spufs_object_id_set, "0x%llx\n");
+
struct tree_descr spufs_dir_contents[] = {
{ "mem", &spufs_mem_fops, 0666, },
{ "regs", &spufs_regs_fops, 0666, },
@@ -1510,7 +1525,8 @@ struct tree_descr spufs_dir_contents[] =
{ "spu_tag_mask", &spufs_spu_tag_mask_ops, 0666, },
{ "event_mask", &spufs_event_mask_ops, 0666, },
{ "srr0", &spufs_srr0_ops, 0666, },
- { "phys-id", &spufs_id_ops, 0666, },
{ "psmap", &spufs_psmap_fops, 0666, },
+ { "phys-id", &spufs_id_ops, 0666, },
+ { "object-id", &spufs_object_id_ops, 0666, },
{},
};
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/spufs.h
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/spufs.h
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/spufs.h
@@ -50,6 +50,7 @@ struct spu_context {
struct address_space *cntl; /* 'control' area mappings. */
struct address_space *signal1; /* 'signal1' area mappings. */
struct address_space *signal2; /* 'signal2' area mappings. */
+ u64 object_id; /* user space pointer for oprofile */
enum { SPU_STATE_RUNNABLE, SPU_STATE_SAVED } state;
struct rw_semaphore state_sema;
Index: linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/sched.c
+++ linux-2.6/arch/powerpc/platforms/cell/spufs/sched.c
@@ -35,6 +35,7 @@
#include <linux/unistd.h>
#include <linux/numa.h>
#include <linux/mutex.h>
+#include <linux/notifier.h>
#include <asm/io.h>
#include <asm/mmu_context.h>
@@ -75,6 +76,25 @@ static inline void mm_needs_global_tlbie
__cpus_setall(&mm->cpu_vm_mask, nr);
}
+static BLOCKING_NOTIFIER_HEAD(spu_switch_notifier);
+
+static void spu_switch_notify(struct spu *spu, struct spu_context *ctx)
+{
+ blocking_notifier_call_chain(&spu_switch_notifier,
+ ctx ? ctx->object_id : 0, spu);
+}
+
+int spu_switch_event_register(struct notifier_block * n)
+{
+ return blocking_notifier_chain_register(&spu_switch_notifier, n);
+}
+
+int spu_switch_event_unregister(struct notifier_block * n)
+{
+ return blocking_notifier_chain_unregister(&spu_switch_notifier, n);
+}
+
+
static inline void bind_context(struct spu *spu, struct spu_context *ctx)
{
pr_debug("%s: pid=%d SPU=%d NODE=%d\n", __FUNCTION__, current->pid,
@@ -97,12 +117,14 @@ static inline void bind_context(struct s
spu_restore(&ctx->csa, spu);
spu->timestamp = jiffies;
spu_cpu_affinity_set(spu, raw_smp_processor_id());
+ spu_switch_notify(spu, ctx);
}
static inline void unbind_context(struct spu *spu, struct spu_context *ctx)
{
pr_debug("%s: unbind pid=%d SPU=%d NODE=%d\n", __FUNCTION__,
spu->pid, spu->number, spu->node);
+ spu_switch_notify(spu, NULL);
spu_unmap_mappings(ctx);
spu_save(&ctx->csa, spu);
spu->timestamp = jiffies;
Index: linux-2.6/include/asm-powerpc/spu.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/spu.h
+++ linux-2.6/include/asm-powerpc/spu.h
@@ -201,6 +201,24 @@ static inline void unregister_spu_syscal
/*
+ * Notifier blocks:
+ *
+ * oprofile can get notified when a context switch is performed
+ * on an spe. The notifer function that gets called is passed
+ * a pointer to the SPU structure as well as the object-id that
+ * identifies the binary running on that SPU now.
+ *
+ * For a context save, the object-id that is passed is zero,
+ * identifying that the kernel will run from that moment on.
+ *
+ * For a context restore, the object-id is the value written
+ * to object-id spufs file from user space and the notifer
+ * function can assume that spu->ctx is valid.
+ */
+int spu_switch_event_register(struct notifier_block * n);
+int spu_switch_event_unregister(struct notifier_block * n);
+
+/*
* This defines the Local Store, Problem Area and Privlege Area of an SPU.
*/
--
^ permalink raw reply
* [PATCH 12/14] powerpc: update cell_defconfig
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
This adds defaults for new configuration options added since
2.6.18 and it enables the option for 64kb pages by default.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/configs/cell_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/cell_defconfig
+++ linux-2.6/arch/powerpc/configs/cell_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.18-rc6
-# Sun Sep 10 10:20:32 2006
+# Linux kernel version: 2.6.18
+# Wed Oct 4 15:30:50 2006
#
CONFIG_PPC64=y
CONFIG_64BIT=y
@@ -22,6 +22,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
# CONFIG_DEFAULT_UIMAGE is not set
#
@@ -52,10 +53,11 @@ CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
+# CONFIG_IPC_NS is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
-CONFIG_SYSCTL=y
+# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
@@ -63,7 +65,9 @@ CONFIG_CPUSETS=y
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
+# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
@@ -72,12 +76,12 @@ CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
-CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
@@ -96,6 +100,7 @@ CONFIG_STOP_MACHINE=y
#
# Block layer
#
+CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
#
@@ -115,12 +120,13 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
-# CONFIG_PPC_ISERIES is not set
# CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
# CONFIG_PPC_PSERIES is not set
+# CONFIG_PPC_ISERIES is not set
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
+# CONFIG_PPC_PASEMI is not set
CONFIG_PPC_CELL=y
CONFIG_PPC_CELL_NATIVE=y
CONFIG_PPC_IBM_CELL_BLADE=y
@@ -142,7 +148,6 @@ CONFIG_MMIO_NVRAM=y
#
CONFIG_SPU_FS=m
CONFIG_SPU_BASE=y
-CONFIG_SPUFS_MMAP=y
CONFIG_CBE_RAS=y
#
@@ -158,7 +163,7 @@ CONFIG_PREEMPT_NONE=y
CONFIG_PREEMPT_BKL=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
-CONFIG_FORCE_MAX_ZONEORDER=13
+CONFIG_FORCE_MAX_ZONEORDER=9
# CONFIG_IOMMU_VMERGE is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_KEXEC=y
@@ -168,6 +173,7 @@ CONFIG_NUMA=y
CONFIG_NODES_SHIFT=4
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
@@ -178,12 +184,12 @@ CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_MEMORY_HOTPLUG=y
+CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
-CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y
CONFIG_ARCH_MEMORY_PROBE=y
-# CONFIG_PPC_64K_PAGES is not set
+CONFIG_PPC_64K_PAGES=y
CONFIG_SCHED_SMT=y
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
@@ -201,6 +207,7 @@ CONFIG_GENERIC_ISA_DMA=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
+# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
#
@@ -228,6 +235,7 @@ CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
+# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
@@ -249,7 +257,8 @@ CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
-CONFIG_TCP_CONG_BIC=y
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
#
# IP: Virtual Server Configuration
@@ -261,11 +270,15 @@ CONFIG_IPV6=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
+# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
+# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_TUNNEL=m
+# CONFIG_IPV6_SUBTREES is not set
+# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
@@ -322,7 +335,6 @@ CONFIG_IP_NF_QUEUE=m
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
-# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
@@ -434,6 +446,7 @@ CONFIG_BLK_DEV_AEC62XX=y
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
+# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
@@ -456,6 +469,12 @@ CONFIG_IDEDMA_AUTO=y
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
+# CONFIG_SCSI_NETLINK is not set
+
+#
+# Serial ATA (prod) and Parallel ATA (experimental) drivers
+#
+# CONFIG_ATA is not set
#
# Multi-device support (RAID and LVM)
@@ -470,6 +489,7 @@ CONFIG_MD_RAID1=m
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
+# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
@@ -504,7 +524,7 @@ CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_BONDING=y
# CONFIG_EQUALIZER is not set
-# CONFIG_TUN is not set
+CONFIG_TUN=y
#
# ARCnet devices
@@ -552,7 +572,7 @@ CONFIG_SKGE=m
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
CONFIG_SPIDER_NET=m
-# CONFIG_MV643XX_ETH is not set
+# CONFIG_QLA3XXX is not set
#
# Ethernet (10000 Mbit)
@@ -599,6 +619,7 @@ CONFIG_SPIDER_NET=m
# Input device support
#
CONFIG_INPUT=y
+# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
@@ -865,6 +886,7 @@ CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
+# CONFIG_INFINIBAND_AMSO1100 is not set
CONFIG_INFINIBAND_IPOIB=m
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
@@ -916,7 +938,7 @@ CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
-# CONFIG_AUTOFS4_FS is not set
+CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
@@ -943,8 +965,10 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
+CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
+# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
@@ -1084,6 +1108,7 @@ CONFIG_PLIST=y
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
@@ -1102,6 +1127,7 @@ CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
+# CONFIG_DEBUG_LIST is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
@@ -1123,6 +1149,10 @@ CONFIG_IRQSTACKS=y
# Cryptographic options
#
CONFIG_CRYPTO=y
+CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_BLKCIPHER=m
+CONFIG_CRYPTO_HASH=y
+# CONFIG_CRYPTO_MANAGER is not set
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
@@ -1132,6 +1162,8 @@ CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
+CONFIG_CRYPTO_ECB=m
+CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
--
^ permalink raw reply
* [PATCH 13/14] spiderpic: enable new style devtree support
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
This enables support for new firmware test releases.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linux-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -244,7 +244,6 @@ static unsigned int __init spider_find_c
int imaplen, intsize, unit;
struct device_node *iic;
-#if 0 /* Enable that when we have a way to retreive the node as well */
/* First, we check wether we have a real "interrupts" in the device
* tree in case the device-tree is ever fixed
*/
@@ -252,9 +251,8 @@ static unsigned int __init spider_find_c
if (of_irq_map_one(pic->of_node, 0, &oirq) == 0) {
virq = irq_create_of_mapping(oirq.controller, oirq.specifier,
oirq.size);
- goto bail;
+ return virq;
}
-#endif
/* Now do the horrible hacks */
tmp = get_property(pic->of_node, "#interrupt-cells", NULL);
--
^ permalink raw reply
* [PATCH 14/14] cell: fix bugs found by sparse
From: Arnd Bergmann @ 2006-10-04 15:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20061004152610.151599000@dyn-9-152-242-103.boeblingen.de.ibm.com>
- Some long constants should be marked 'ul'.
- When using desc->handler_data to pass an __iomem
register area, we need to add casts to and from
__iomem.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/interrupt.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/interrupt.c
+++ linux-2.6/arch/powerpc/platforms/cell/interrupt.c
@@ -101,7 +101,7 @@ static void iic_ioexc_eoi(unsigned int i
static void iic_ioexc_cascade(unsigned int irq, struct irq_desc *desc,
struct pt_regs *regs)
{
- struct cbe_iic_regs *node_iic = desc->handler_data;
+ struct cbe_iic_regs __iomem *node_iic = (void __iomem *)desc->handler_data;
unsigned int base = (irq & 0xffffff00) | IIC_IRQ_TYPE_IOEXC;
unsigned long bits, ack;
int cascade;
@@ -320,7 +320,7 @@ static int __init setup_iic(void)
struct device_node *dn;
struct resource r0, r1;
unsigned int node, cascade, found = 0;
- struct cbe_iic_regs *node_iic;
+ struct cbe_iic_regs __iomem *node_iic;
const u32 *np;
for (dn = NULL;
@@ -357,7 +357,11 @@ static int __init setup_iic(void)
cascade = irq_create_mapping(iic_host, cascade);
if (cascade == NO_IRQ)
continue;
- set_irq_data(cascade, node_iic);
+ /*
+ * irq_data is a generic pointer that gets passed back
+ * to us later, so the forced cast is fine.
+ */
+ set_irq_data(cascade, (void __force *)node_iic);
set_irq_chained_handler(cascade , iic_ioexc_cascade);
out_be64(&node_iic->iic_ir,
(1 << 12) /* priority */ |
Index: linux-2.6/arch/powerpc/platforms/cell/iommu.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/iommu.c
+++ linux-2.6/arch/powerpc/platforms/cell/iommu.c
@@ -345,8 +345,8 @@ static int cell_map_iommu_hardcoded(int
/* node 0 */
iommu = &cell_iommus[0];
- iommu->mapped_base = ioremap(0x20000511000, 0x1000);
- iommu->mapped_mmio_base = ioremap(0x20000510000, 0x1000);
+ iommu->mapped_base = ioremap(0x20000511000ul, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x20000510000ul, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
@@ -358,8 +358,8 @@ static int cell_map_iommu_hardcoded(int
/* node 1 */
iommu = &cell_iommus[1];
- iommu->mapped_base = ioremap(0x30000511000, 0x1000);
- iommu->mapped_mmio_base = ioremap(0x30000510000, 0x1000);
+ iommu->mapped_base = ioremap(0x30000511000ul, 0x1000);
+ iommu->mapped_mmio_base = ioremap(0x30000510000ul, 0x1000);
enable_mapping(iommu->mapped_base, iommu->mapped_mmio_base);
Index: linux-2.6/arch/powerpc/platforms/cell/spider-pic.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/spider-pic.c
+++ linux-2.6/arch/powerpc/platforms/cell/spider-pic.c
@@ -367,7 +367,7 @@ void __init spider_init_IRQ(void)
} else if (device_is_compatible(dn, "sti,platform-spider-pic")
&& (chip < 2)) {
static long hard_coded_pics[] =
- { 0x24000008000, 0x34000008000 };
+ { 0x24000008000ul, 0x34000008000ul};
r.start = hard_coded_pics[chip];
} else
continue;
--
^ permalink raw reply
* Re: uboot-1.1.4 linux-2.6.10: Image bootproblems
From: Wolfgang Denk @ 2006-10-04 15:40 UTC (permalink / raw)
To: Armin Steck; +Cc: linuxppc-embedded
In-Reply-To: <20061004090425.57760@gmx.net>
In message <20061004090425.57760@gmx.net> you wrote:
>
> uboot==> bootm 0x00040000
> ## Booting image at 00040000 ...
> Image Name: Linux-2.6.10
> Image Type: ARM Linux Kernel Image (gzip compressed)
You are off topic here. This is the PowerPC list.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You see things; and you say ``Why?'' But I dream things that never
were; and I say ``Why not?''
- George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1
^ permalink raw reply
* [PATCH] Add DTS for MPC8349E-mITX board
From: timur @ 2006-10-04 16:03 UTC (permalink / raw)
To: linuxppc-dev
From: Timur Tabi <timur@freescale.com>
Add the DTS for the Freescale MPC 8349E-mITX reference board. Contact
Vitesse for the driver for the VSC 7385.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 246 ++++++++++++++++++++++++++++++++
1 files changed, 246 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts b/arch/powerpc/boot/dts/mpc8349emitx.dts
new file mode 100644
index 0000000..27807fc
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -0,0 +1,246 @@
+/*
+ * MPC8349E-mITX Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+/ {
+ model = "MPC8349EMITX";
+ compatible = "MPC834xMITX";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8349@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>;
+ i-cache-line-size = <20>;
+ d-cache-size = <8000>;
+ i-cache-size = <8000>;
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>; // from bootloader
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 10000000>;
+ };
+
+ soc8349@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 e0000000 00100000>;
+ reg = <e0000000 00000200>;
+ bus-frequency = <0>; // from bootloader
+
+ wdt@200 {
+ device_type = "watchdog";
+ compatible = "mpc83xx_wdt";
+ reg = <200 100>;
+ };
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <e 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <f 8>;
+ interrupt-parent = <700>;
+ dfsrr;
+ };
+
+ spi@7000 {
+ device_type = "spi";
+ compatible = "mpc83xx_spi";
+ reg = <7000 1000>;
+ interrupts = <10 8>;
+ interrupt-parent = <700>;
+ mode = <0>;
+ };
+
+ usb@22000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-mph";
+ reg = <22000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <27 2>;
+ phy_type = "ulpi";
+ port1;
+ };
+
+ usb@23000 {
+ device_type = "usb";
+ compatible = "fsl-usb2-dr";
+ reg = <23000 1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <700>;
+ interrupts = <26 2>;
+ phy_type = "ulpi";
+ };
+
+ mdio@24520 {
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ linux,phandle = <24520>;
+
+ /* Vitesse 8201 */
+ ethernet-phy@1c {
+ linux,phandle = <245201c>;
+ interrupt-parent = <700>;
+ interrupts = <12 2>;
+ reg = <1c>;
+ device_type = "ethernet-phy";
+ };
+
+ /* Vitesse 7385 */
+ ethernet-phy@1f {
+ linux,phandle = <245201f>;
+ interrupt-parent = <700>;
+ interrupts = <12 2>;
+ reg = <1f>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <20 8 21 8 22 8>;
+ interrupt-parent = <700>;
+ phy-handle = <245201c>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ address = [ 00 00 00 00 00 00 ];
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <23 8 24 8 25 8>;
+ interrupt-parent = <700>;
+ phy-handle = <245201f>;
+ };
+
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>; // from bootloader
+ interrupts = <9 8>;
+ interrupt-parent = <700>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>; // from bootloader
+ interrupts = <a 8>;
+ interrupt-parent = <700>;
+ };
+
+ pci@8500 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x10 - SATA */
+ 8000 0 0 1 700 16 8 /* SATA_INTA */
+ >;
+ interrupt-parent = <700>;
+ interrupts = <42 8>;
+ bus-range = <0 0>;
+ ranges = <42000000 0 80000000 80000000 0 10000000
+ 02000000 0 90000000 90000000 0 10000000
+ 01000000 0 00000000 e2000000 0 01000000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8500 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ pci@8600 {
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0E - MiniPCI Slot */
+ 7000 0 0 1 700 15 8 /* PCI_INTA */
+
+ /* IDSEL 0x0F - PCI Slot */
+ 7800 0 0 1 700 14 8 /* PCI_INTA */
+ 7800 0 0 2 700 15 8 /* PCI_INTB */
+ >;
+ interrupt-parent = <700>;
+ interrupts = <43 8>;
+ bus-range = <1 1>;
+ ranges = <42000000 0 a0000000 a0000000 0 10000000
+ 02000000 0 b0000000 b0000000 0 10000000
+ 01000000 0 00000000 e3000000 0 01000000>;
+ clock-frequency = <3f940aa>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8600 100>;
+ compatible = "83xx";
+ device_type = "pci";
+ };
+
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <b 8>;
+ interrupt-parent = <700>;
+ num-channels = <4>;
+ channel-fifo-len = <18>;
+ exec-units-mask = <0000007e>;
+ descriptor-types-mask = <01010ebf>;
+ };
+
+ pic@700 {
+ linux,phandle = <700>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <700 100>;
+ built-in;
+ device_type = "ipic";
+ };
+ };
+};
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Jerry Van Baren @ 2006-10-04 16:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <80EE3621-ED80-408E-BF04-BA3CB985C769@embeddedalley.com>
Dan Malek wrote:
> On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:
>
>> I don't see how a mecanism of feature call at the board support
>> level is
>> in any way incompatible with the device-tree thing.
>
> It isn't.
>
>> ... I'm happy mixing
>> both on powermac :)
>
> I know. This was just an opportunity to make people
> realize that a board port does require the writing of
> some board specific code. Using the feature call is
> an excellent model of portability and flexibility. My
> point was that any BCSR access is necessary to be
> hidden behind such a function, because it is truly
> board specific. You can't require the drivers to
> have this kind of logic in them, they must call out
> to board support functions for assistance.
>
> Just like the powermac ports, embedded drivers
> will need a feature call at some points during
> their processing (set up clock routing, IO pin
> configuration, board specific bus connections,
> power management, etc). Some board ports
> may do nothing, others may do lots of work.
>
> Therefore, I see no reason why a BSCR address
> and all of it's associated format can't simply
> be a #define in a board specific file. There is no
> need for this in the device tree.
>
>
> -- Dan
The promise of OF for me is that it promises to keep configuration
information in _one place_. My experience to date is that my u-boot has
a bunch of semi-hardcoded constants, my linux drivers have a bunch of
semi-hardcoded constants that likely do not match 1:1 (name and
definitely not location) with the equivalent u-boot constants, and some
constants are passed from u-boot to linux using the BD structure, which
is never defined the same (for me) in u-boot and linux.
The result is that, when I upgrade my u-boot and/or linux sources, I end
up having to re-find all the places where the constants live (and find
some new places), fix them, and then make the u-boot and linux BD
structures match. Granted, this isn't insurmountable, but it is a major
hassle and should be unnecessary.
In a perfect world perhaps we would have one (set of) #include file(s)
that had all the configuration information necessary to build u-boot and
linux. In the current world, u-boot and linux are in different
repositories with different people with different machines (and agendas)
doing different development on them, and the result is disjoint.
I look at OF to be the /lingua franca/ of PowerPC bootloaders and linux.
gvb
^ permalink raw reply
* Re: [PATCH] Add of_platform_device_scan().
From: Scott Wood @ 2006-10-04 16:32 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200610040118.09416.arnd@arndb.de>
Arnd Bergmann wrote:
> I think it would be much more helpful to have working probing of all
> SOC buses during bootup.
I agree; I avoided doing that for now because I was uneasy about
duplicating device nodes for SOC devices covered under the non-OF
platform bus via code in sysdev/fsl_soc.c. It probably won't cause any
real problems unless a single device matches drivers on both buses (in
which case the of_device driver would probably be calling
of_platform_device_scan() anyway), but still...
What I'd really like (long-term, of course) is if platform_device and
of_device were merged, with device tree support (or at least a means of
passing on properties that *could* come from a device tree without
special glue code that knows about each property) in arch-neutral code;
the mechanism for discovering devices ideally shouldn't depend on the
CPU's instruction set.
> + for (child = NULL; (child = of_get_next_child(root, child)); ) {
> + if (strcmp(child->type, "spider") == 0) {
> + ret = of_soc_device_create(child, NULL);
> + if (ret)
> + goto out3;
> + }
> + }
Why only spider?
-Scott
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Pradeep Sampath @ 2006-10-04 16:35 UTC (permalink / raw)
To: Ming Liu, ammubhai; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F79748D36D754E6D6B2A99B21D0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 3338 bytes --]
Hello Ameet/Ming,
First of all really appreciate your inputs on this...
Problem 1 :
I was using the factory shipped compact flash as is which comes with a DOS FAT16 partition and a linux 83 partition with ext3 filesystem. I tried it on 2 factory shipped CFs and its the same behavior - . When i plug-in the CF card reader to the linux box it always reads it as "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the device file for SCSI disk devices. Wonerding how you guys configured the root option as "/dev/xsa".
Now i re-formatted my CF, created a ext2 filesystem using busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF card 1. FAT16 partition & 2. linux partition and then created 1. dos file system using mkdosfs and 2. linux ext2 filesystem using mke2fs.
But the problem still persists and i get "Please append a correct "root=" boot option :"
:(
Problem 2: After i included the TEMAC driver and sysace drivers, the kernel just hangs. I thought i'll fix problem 1 before i get to problem 2...
With your help i am getting the confidence that i can make this all work!
thanks once again.
-Pradeep
Ming Liu <eemingliu@hotmail.com> wrote:
Hello Ameet,
I am using that driver very well now. There is only one problem. It seems
that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M
adapted. But because I want to use the Gigabit enet, I don't care that. So
it's OK, at lease for 1Gbit/s.
So I don't think Pradeep's problem is caused by Temac. I still suspect that
he didn't pass a right parameter to "root=", just like what I posted
before.
Regards
Ming
>From: Ameet Patil
>To: Ming Liu
>CC: pradeepsampath@yahoo.com, linuxppc-embedded@ozlabs.org
>Subject: Re: booting 2.6 kernel on ML403
>Date: Wed, 04 Oct 2006 09:35:07 +0100
>
>Ming Liu wrote:
> > Hi,
> >
> >> [ 3.093694] TCP bic registered
> >> [ 3.129458] NET: Registered protocol family 8
> >> [ 3.181412] NET: Registered protocol family 20
> >> [ 3.236744] VFS: Cannot open root device "xsa2" or unknown-block(0,0)
> >> [ 3.313092] Please append a correct "root=" boot option
> >
> > It looks that some errors still exist in the parameters you passed to
> > "root=". Please double check it, or post it in the maillist for deep
> > analysis.
> > Regards
> > Ming
> >
> > _________________________________________________________________
> > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>Hi Ming,
>IIRC, you are or were using the TEMAC driver along with my System Ace
>driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for
>you? I ask this because Pradeep is having some problems using it (see
>Problem 2 in his email). Could you please update on this?
>
>Thanks,
>-Ameet
_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4112 bytes --]
^ permalink raw reply
* Re: [PATCH] Add of_platform_device_scan().
From: Arnd Bergmann @ 2006-10-04 16:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4523E214.5060404@freescale.com>
On Wednesday 04 October 2006 18:32, Scott Wood wrote:
> What I'd really like (long-term, of course) is if platform_device and=20
> of_device were merged, with device tree support (or at least a means of=20
> passing on properties that *could* come from a device tree without=20
> special glue code that knows about each property) in arch-neutral code;=20
> the mechanism for discovering devices ideally shouldn't depend on the=20
> CPU's instruction set.
My guess is that this won't happen, because other architectures
normally don't describe their platform devices in a way that is
anywhere near what we have on powerpc.
Benh suggested moving some of the functionality of of_platform_device
into the common of_device so we don't really have to use an
of_platform_device for stuff that can be automatically probed.
I guess we'll see a patch from him soon.
> > +=A0=A0=A0=A0=A0for (child =3D NULL; (child =3D of_get_next_child(root,=
child)); ) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (strcmp(child->type, "spider=
") =3D=3D 0) {
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ret =3D=
of_soc_device_create(child, NULL);
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (ret)
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0goto out3;
> > +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
> > +=A0=A0=A0=A0=A0}
>=20
> Why only spider?
Mistake on my side. That's what I have in my experimental device tree.
It should be more generic.
Arnd <><
^ permalink raw reply
* Re: booting 2.6 kernel on ML403
From: Pradeep Sampath @ 2006-10-04 16:47 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <45236A0F.6000204@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 425 bytes --]
Ameet,
loaded at: 00400000 0051513C
board data at: 00513124 0051313C
relocated to: 004050E8 00405100
zimage at: 004057FD 0051230A
avail ram: 00516000 04000000
Linux/PPC load: console=ttyS0,9600 root=/dev/xsa2
Uncompressing Linux...done.
Now booting the kernel
Please could send me all the boot messages until the point where it
stops. This will help me better identify the problem.
Thanks,
-Ameet
[-- Attachment #2: Type: text/html, Size: 583 bytes --]
^ permalink raw reply
* Problem with initrd
From: Glenn.G.Hart @ 2006-10-04 16:55 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to get Linux running on the PPC of a Xilinx V4-FX12 FPGA. I am
using the Linux 2.6.17.9 kernel (I have also tried 2.6.17.1 with the same
results) and have gotten through the kernel initialization to the point
where it mounts the root file system. At this point I can an Oops and a
kernel panic. I traced the kernel and found it was happening on the gunzip
of the ramdisk image. I tried without compressing the ramdisk image and I
got a slightly different error. I have attached this output as well. I am
not a kernel expert, but I am guessing it is having trouble accessing the
RAM for the ramdisk. Can anybody offer some advice?
Thanks,
Glenn
With compress ramdisk image:
loaded at: 00400000 0052B13C
board data at: 00529124 0052913C
relocated to: 004050F0 00405108
zimage at: 00405805 004D072E
initrd at: 004D1000 00528981
avail ram: 0052C000 10000000
Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
initrd start c04d1000 end c0528981
Linux version 2.6.17.9 (root@AFedora3) (gcc version 3.4.5) #32 PREEMPT Tue
Oct 3 23:25:12 EDT 2006
Xilinx Virtex-II Pro port
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,9600 console=tty0 root=/dev/ram rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 257408k available (1424k kernel code, 368k data, 80k init, 0k
highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 350k freed
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 1) is a 16450
RAMDISK driver initialized: 1 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 2 devices)
nbd: registered device at major 43
eth0: using fifo mode.
eth0: Xilinx EMAC #0 at 0x80400000 mapped to 0xD1000000, irq=0
eth0: id 2.0a; block id 0, type 8
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
allocated in buffer
allocated window buffer
make crc
gunzip
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C004115C LR: C0041148 CTR: C00FA29C
REGS: c0421610 TRAP: 0300 Not tainted (2.6.17.9)
MSR: 00029030 <EE,ME,IR,DR> CR: 35035093 XER: E0000000
DAR: 00001000, DSISR: 00800000
TASK = c0529b10[1] 'swapper' THREAD: c0420000
GPR00: C0041148 C04216C0 C0529B10 00000000 00000001 00000001 C04216A8
00000000
GPR08: 00000000 00001000 00000400 00000000 35035099 FFFF9620 00000001
C04216D0
GPR16: C018CD50 C04C88A0 C052FC08 00000000 00001000 00010000 C052FCA8
00000000
GPR24: 00140000 C0450000 00000000 00001000 C01E3F20 00001000 00001000
00000000
NIP [C004115C] generic_file_buffered_write+0x4ec/0x5bc
LR [C0041148] generic_file_buffered_write+0x4d8/0x5bc
Call Trace:
[C04216C0] [C0041148] generic_file_buffered_write+0x4d8/0x5bc (unreliable)
[C0421780] [C0041A10] __generic_file_aio_write_nolock+0x4d4/0x50c
[C0421810] [C0041DB8] generic_file_aio_write_nolock+0x28/0x98
[C0421830] [C0041EA0] generic_file_write_nolock+0x78/0xa8
[C04218D0] [C00657F8] blkdev_file_write+0x20/0x30
[C04218E0] [C005B400] vfs_write+0xc8/0x190
[C0421900] [C005B5A0] sys_write+0x4c/0x8c
[C0421930] [C01AD2D4] flush_window+0x34/0xe4
[C0421950] [C01AD8B8] inflate_codes+0x468/0x4b0
[C04219A0] [C01AE0E0] inflate_dynamic+0x64c/0x690
[C0421EE0] [C01AEA1C] rd_load_image+0x8f4/0x106c
[C0421F40] [C01AF33C] initrd_load+0x4c/0x304
[C0421F70] [C01ACCB8] prepare_namespace+0xa8/0x11c
[C0421F90] [C0002580] init+0x1b4/0x280
[C0421FF0] [C00051FC] kernel_thread+0x44/0x60
Instruction dump:
48006591 2f9d0000 419c001c 7ec3b378 38800001 4800441d 48120851 2f930000
409efbe8 8061005c 81210064 2f830000 <92e90000> 93090004 41be0008 48006555
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds.
With uncompress ramdisk image:
loaded at: 00400000 008D313C
board data at: 008D1124 008D113C
relocated to: 004050F0 00405108
zimage at: 00405805 004D072C
initrd at: 004D1000 008D1000
avail ram: 008D4000 10000000
Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
initrd start c04d1000 end c08d1000
Linux version 2.6.17.9 (root@AFedora3) (gcc version 3.4.5) #33 PREEMPT Wed
Oct 4 00:18:59 EDT 2006
Xilinx Virtex-II Pro port
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,9600 console=tty0 root=/dev/ram rw
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 253696k available (1424k kernel code, 368k data, 80k init, 0k
highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (bad gzip magic numbers); looks
like an initrd
Freeing initrd memory: 4096k freed
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
io scheduler noop registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 1) is a 16450
RAMDISK driver initialized: 1 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 2 devices)
nbd: registered device at major 43
eth0: using fifo mode.
eth0: Xilinx EMAC #0 at 0x80400000 mapped to 0xD1000000, irq=0
eth0: id 2.0a; block id 0, type 8
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: ext2 filesystem found at block 0
found ramdisk # blocks = 4096 /initrd.image
RAMDISK: Loading 4096KiB [1 disk] into ram disk... Oops: Exception in
kernel mode, sig: 4 [#1]
PREEMPT
NIP: C0079058 LR: C0079018 CTR: 00000000
REGS: c08e1c20 TRAP: 0700 Not tainted (2.6.17.9)
MSR: 00029030 <EE,ME,IR,DR> CR: 35005093 XER: C0000000
TASK = c04c9b10[1] 'swapper' THREAD: c08e0000
GPR00: 11A49A00 C08E1CD0 C04C9B10 C08E1CD8 C08E1CB8 00000001 C08D4C00
00000003
GPR08: 11A49A00 11A49A00 11A49A00 C08D26AC 00000400 FFFF9620 00000002
C08D2664
GPR16: 00000002 00000001 C08E1EC0 C04C26C0 00000000 C08E1DA0 000003FF
C08D2704
GPR24: 00001000 00000000 00400000 00000400 00000001 00000400 00000000
C08D2664
NIP [C0079058] touch_atime+0xc4/0xd8
LR [C0079018] touch_atime+0x84/0xd8
Call Trace:
[C08E1CD0] [C0079018] touch_atime+0x84/0xd8 (unreliable)
[C08E1CF0] [C003FBF0] do_generic_mapping_read+0x490/0x4a4
[C08E1D90] [C00420BC] __generic_file_aio_read+0x1ec/0x238
[C08E1DE0] [C0042238] generic_file_read+0x88/0xb8
[C08E1E90] [C005B16C] vfs_read+0xc8/0x190
[C08E1EB0] [C005B514] sys_read+0x4c/0x8c
[C08E1EE0] [C01AF100] rd_load_image+0xfd8/0x106c
[C08E1F40] [C01AF33C] initrd_load+0x4c/0x304
[C08E1F70] [C01ACCB8] prepare_namespace+0xa8/0x11c
[C08E1F90] [C0002580] init+0x1b4/0x280
[C08E1FF0] [C00051FC] kernel_thread+0x44/0x60
Instruction dump:
409e0014 800b0004 8121000c 7f804800 419e0020 81210008 8141000c 7fe3fb78
913f0048 915f004c 38800001 4800b1a1 <00000000> 00000800 7c0803a6 38210020
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ permalink raw reply
* RE: booting 2.6 kernel on ML403
From: John Bonesio @ 2006-10-04 17:17 UTC (permalink / raw)
To: Pradeep Sampath, Ming Liu, ammubhai; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4496 bytes --]
A quick amendment to my previous email:
The device name you should use in the CONFIG_CMDLINE "root=..." can be found in the routine call to register_blkdev() in the driver source code. The first parameter to register_blkdev() is the major number of the device. The second parameter is the name of the device, as in /dev/xsda2, or /dev/xsysace2. This second parameter will contain just the 'xsda' or 'xsysace' in it, and it may be a preprocessor constant defined earlier in the file, such as #define MAJOR_NAME "xsda", but it might not be a constant either. It depends on the code.
Hopefully this clears things up a bit.
- John
________________________________
From: linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org [mailto:linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org] On Behalf Of Pradeep Sampath
Sent: Wednesday, October 04, 2006 10:35 AM
To: Ming Liu; ammubhai@gmail.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: booting 2.6 kernel on ML403
Hello Ameet/Ming,
First of all really appreciate your inputs on this...
Problem 1 :
I was using the factory shipped compact flash as is which comes with a DOS FAT16 partition and a linux 83 partition with ext3 filesystem. I tried it on 2 factory shipped CFs and its the same behavior - . When i plug-in the CF card reader to the linux box it always reads it as "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the device file for SCSI disk devices. Wonerding how you guys configured the root option as "/dev/xsa".
Now i re-formatted my CF, created a ext2 filesystem using busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF card 1. FAT16 partition & 2. linux partition and then created 1. dos file system using mkdosfs and 2. linux ext2 filesystem using mke2fs.
But the problem still persists and i get "Please append a correct "root=" boot option :"
:(
Problem 2: After i included the TEMAC driver and sysace drivers, the kernel just hangs. I thought i'll fix problem 1 before i get to problem 2...
With your help i am getting the confidence that i can make this all work!
thanks once again.
-Pradeep
Ming Liu <eemingliu@hotmail.com> wrote:
Hello Ameet,
I am using that driver very well now. There is only one problem. It seems
that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M
adapted. But because I want to use the Gigabit enet, I don't care that. So
it's OK, at lease for 1Gbit/s.
So I don't think Pradeep's problem is caused by Temac. I still suspect that
he didn't pass a right parameter to "root=", just like what I posted
before.
Regards
Ming
>From: Ameet Patil
>To: Ming Liu
>CC: pradeepsampath@yahoo.com, linuxppc-embedded@ozlabs.org
>Subject: Re: booting 2.6 kernel on ML403
>Date: Wed, 04 Oct 2006 09:35:07 +0100
>
>Ming Liu wrote:
> > Hi,
> >
> >> [ 3.093694] TCP bic registered
> >> [ 3.129458] NET: Registered protocol family 8
> >> [ 3.181412] NET: Registered protocol family 20
> >> [ 3.236744] VFS: Cannot open root device "xsa2" or unknown-block(0,0)
> >> [ 3.313092] Please append a correct "root=" boot option
> >
> > It looks that some errors still exist in the parameters you passed to
> > "root=". Please double check it, or post it in the maillist for deep
> > analysis.
> > Regards
> > Ming
> >
> > _________________________________________________________________
> > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>Hi Ming,
>IIRC, you are or were using the TEMAC driver along with my System Ace
>driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for
>you? I ask this because Pradeep is having some problems using it (see
>Problem 2 in his email). Could you please update on this?
>
>Thanks,
>-Ameet
_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 10901 bytes --]
^ permalink raw reply
* RE: booting 2.6 kernel on ML403
From: John Bonesio @ 2006-10-04 17:09 UTC (permalink / raw)
To: Pradeep Sampath, Ming Liu, ammubhai; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5110 bytes --]
Hi Pradeep,
If you are using the MontaVista/Xilinx driver for sysace for linux 2.6, the CONFIG_CMDLINE item in .config should have
root=/dev/xsysace2 rw
in it. From the text below it's not clear what driver you are using. If you are using a different driver, you may be able to search for
#define MAJOR_NAME
in the source code of the sysace driver. I believe that will indicate which device name you should use in the CONFIG_CMDLINE.
As you probably already know, the '2' in '/dev/xsysace2' refers to the partition number it should use - partition 2 in this case.
For Problem 2: Do you see any error leds light up on the board? It's possible that the drivers you are using for one or both of those cores is not meant for the version of the cores you are using. The core most likely to be suspect is the TEMAC soft core, as that has changed recently. Even though you are using the hard TEMAC core, there is a soft wrapper around it to connect it up to the bus and what not. This soft wrapper has changed from version 2 to version 3 not too long ago. While the TEMAC driver that MontaVista has (and I believe posted to this mailing list) is for version 2 of the soft TEMAC core.
Hope this helps,
- John
________________________________
From: linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org [mailto:linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org] On Behalf Of Pradeep Sampath
Sent: Wednesday, October 04, 2006 10:35 AM
To: Ming Liu; ammubhai@gmail.com
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: booting 2.6 kernel on ML403
Hello Ameet/Ming,
First of all really appreciate your inputs on this...
Problem 1 :
I was using the factory shipped compact flash as is which comes with a DOS FAT16 partition and a linux 83 partition with ext3 filesystem. I tried it on 2 factory shipped CFs and its the same behavior - . When i plug-in the CF card reader to the linux box it always reads it as "sda" and in the linux2.6.17.1/Documentation/devices.txt - sda is the device file for SCSI disk devices. Wonerding how you guys configured the root option as "/dev/xsa".
Now i re-formatted my CF, created a ext2 filesystem using busybox-1.1.0 like the BYU instructions. Created 2 partitions on CF card 1. FAT16 partition & 2. linux partition and then created 1. dos file system using mkdosfs and 2. linux ext2 filesystem using mke2fs.
But the problem still persists and i get "Please append a correct "root=" boot option :"
:(
Problem 2: After i included the TEMAC driver and sysace drivers, the kernel just hangs. I thought i'll fix problem 1 before i get to problem 2...
With your help i am getting the confidence that i can make this all work!
thanks once again.
-Pradeep
Ming Liu <eemingliu@hotmail.com> wrote:
Hello Ameet,
I am using that driver very well now. There is only one problem. It seems
that the driver for TEMAC only support Gigabit Enet, not 10/100/1000M
adapted. But because I want to use the Gigabit enet, I don't care that. So
it's OK, at lease for 1Gbit/s.
So I don't think Pradeep's problem is caused by Temac. I still suspect that
he didn't pass a right parameter to "root=", just like what I posted
before.
Regards
Ming
>From: Ameet Patil
>To: Ming Liu
>CC: pradeepsampath@yahoo.com, linuxppc-embedded@ozlabs.org
>Subject: Re: booting 2.6 kernel on ML403
>Date: Wed, 04 Oct 2006 09:35:07 +0100
>
>Ming Liu wrote:
> > Hi,
> >
> >> [ 3.093694] TCP bic registered
> >> [ 3.129458] NET: Registered protocol family 8
> >> [ 3.181412] NET: Registered protocol family 20
> >> [ 3.236744] VFS: Cannot open root device "xsa2" or unknown-block(0,0)
> >> [ 3.313092] Please append a correct "root=" boot option
> >
> > It looks that some errors still exist in the parameters you passed to
> > "root=". Please double check it, or post it in the maillist for deep
> > analysis.
> > Regards
> > Ming
> >
> > _________________________________________________________________
> > ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£ http://www.hotmail.com
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>Hi Ming,
>IIRC, you are or were using the TEMAC driver along with my System Ace
>driver, isn't it? Does my driver patch ***-after-TEMAC.patch work for
>you? I ask this because Pradeep is having some problems using it (see
>Problem 2 in his email). Could you please update on this?
>
>Thanks,
>-Ameet
_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 12833 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Tim Bird @ 2006-10-04 17:28 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <2867EA41-5135-43F7-9873-044C617EAC1B@embeddedalley.com>
Dan Malek wrote:
> I'm not against using the device tree (or platform data
> or #defines) when it's appropriate to do so. I think our
> obsession to represent everything there is what is
> creating the complexity. If a #define in a board
> specific port file makes sense, then just do that,
> even if it is a BSCR address. The device tree just
> seems like the new toy that everyone wants to play
> with, and we are forgetting that the old fashioned way
> of just writing some C code may be the way
> to implement what we need.
I'd like to "second" a lot of what Dan is saying.
Linux increasingly drifts away from simple, adequate
solutions (that admittedly require a bit of embedded
developer elbow grease), towards these types of
"grand unification" schemes, which actually interfere
with goals in the embedded space.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
^ permalink raw reply
* [PATCH] use-generic-bug-for-ppc
From: Judith Lebzelter @ 2006-10-04 18:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, jeremy, linux-kernel
For 2.6.18-mm3, the 32-bit 'ppc' architectures won't compile due to errors:
arch/ppc/kernel/built-in.o: In function `find_bug':
arch/ppc/kernel/traps.c:582: undefined reference to `module_find_bug'
arch/powerpc/kernel/built-in.o: In function `module_arch_cleanup':
arch/powerpc/kernel/module_32.c:282: undefined reference to `module_bug_cleanup'
arch/powerpc/kernel/built-in.o: In function `module_finalize':
arch/powerpc/kernel/module_32.c:277: undefined reference to `module_bug_finalize'
make: [.tmp_vmlinux3] Error 1 (ignored)
KSYM .tmp_kallsyms3.S
powerpc-750-linux-gnu-nm: '.tmp_vmlinux3': No such file
No valid symbol.
make: [.tmp_kallsyms3.S] Error 1 (ignored)
AS .tmp_kallsyms3.o
LD vmlinux
arch/ppc/kernel/built-in.o: In function `find_bug':
arch/ppc/kernel/traps.c:582: undefined reference to `module_find_bug'
arch/powerpc/kernel/built-in.o: In function `module_arch_cleanup':
arch/powerpc/kernel/module_32.c:282: undefined reference to `module_bug_cleanup'
arch/powerpc/kernel/built-in.o: In function `module_finalize':
arch/powerpc/kernel/module_32.c:277: undefined reference to `module_bug_finalize'
make: [vmlinux] Error 1 (ignored)
These changes match changes for using the generic bug libraries as in
'use-generic-bug-for-powerpc.patch' and gets rid of the compile errors.
Signed-off-by: Judith Lebzelter <judith@osdl.org>
---
Files Edited:
arch/ppc/kernel/traps.c
arch/ppc/Kconfig
Index: linux/arch/ppc/Kconfig
===================================================================
--- linux.orig/arch/ppc/Kconfig 2006-10-03 16:11:26.456655259 -0700
+++ linux/arch/ppc/Kconfig 2006-10-03 17:10:09.398320057 -0700
@@ -52,6 +52,11 @@
bool
default y
+config GENERIC_BUG
+ bool
+ default y
+ depends on BUG
+
source "init/Kconfig"
menu "Processor"
Index: linux/arch/ppc/kernel/traps.c
===================================================================
--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.461653713 -0700
+++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/prctl.h>
+#include <linux/bug.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -568,55 +569,9 @@
*/
extern struct bug_entry __start___bug_table[], __stop___bug_table[];
-#ifndef CONFIG_MODULES
-#define module_find_bug(x) NULL
-#endif
-
-struct bug_entry *find_bug(unsigned long bugaddr)
+int is_valid_bugaddr(unsigned long addr)
{
- struct bug_entry *bug;
-
- for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
- if (bugaddr == bug->bug_addr)
- return bug;
- return module_find_bug(bugaddr);
-}
-
-int check_bug_trap(struct pt_regs *regs)
-{
- struct bug_entry *bug;
- unsigned long addr;
-
- if (regs->msr & MSR_PR)
- return 0; /* not in kernel */
- addr = regs->nip; /* address of trap instruction */
- if (addr < PAGE_OFFSET)
- return 0;
- bug = find_bug(regs->nip);
- if (bug == NULL)
- return 0;
- if (bug->line & BUG_WARNING_TRAP) {
- /* this is a WARN_ON rather than BUG/BUG_ON */
-#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
-#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
- dump_stack();
- return 1;
- }
-#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
- xmon(regs);
-#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
-
- return 0;
+ return addr >= PAGE_OFFSET;
}
void program_check_exception(struct pt_regs *regs)
@@ -671,7 +626,9 @@
/* trap exception */
if (debugger_bpt(regs))
return;
- if (check_bug_trap(regs)) {
+
+ if (!(regs->msr & MSR_PR) && /* not user-mode */
+ report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
^ permalink raw reply
* Re: [PATCH] Add of_platform_device_scan().
From: Scott Wood @ 2006-10-04 19:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200610041837.47317.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 04 October 2006 18:32, Scott Wood wrote:
>
>>What I'd really like (long-term, of course) is if platform_device and
>>of_device were merged, with device tree support (or at least a means of
>>passing on properties that *could* come from a device tree without
>>special glue code that knows about each property) in arch-neutral code;
>>the mechanism for discovering devices ideally shouldn't depend on the
>>CPU's instruction set.
>
>
> My guess is that this won't happen, because other architectures
> normally don't describe their platform devices in a way that is
> anywhere near what we have on powerpc.
They wouldn't need to, unless they want to support a driver that
requires it. It would simply be an architecture-neutral mechanism for
attaching a dynamic list of properties and OF-compatible matching
criteria (or more generally the ability to match on any set of dynamic
properties) to platform devices; the source of the platform data could
choose to use it to represent an OF device tree, to supply a few
properties needed by a specific driver, or not at all.
Ideally, users of static structure-based platform data would gradually
migrate to dynamic properties, but there's a benefit to the integration
even if they don't. The main issue that I forsee being a problem is
clashing with another standard for the naming and content of properties.
There could be tagging to indicate which standard is being followed by
a given property, but that could lead to some ugliness in drivers that
need to support more than one if the differences can't be easily
abstracted by get-me-this-piece-of-information accessor functions (or by
code that generically converts properties from one standard to
another, which is similar to what we've already got in fsl_soc.c, but
hopefully less device-specific).
-Scott
^ permalink raw reply
* Re: [PATCH] use-generic-bug-for-ppc
From: Jeremy Fitzhardinge @ 2006-10-04 20:15 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: Andrew Morton, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20061004184927.GH665@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Index: linux/arch/ppc/kernel/traps.c
> ===================================================================
> --- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.461653713 -0700
> +++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
> @@ -28,6 +28,7 @@
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/prctl.h>
> +#include <linux/bug.h>
>
> #include <asm/pgtable.h>
> #include <asm/uaccess.h>
> @@ -568,55 +569,9 @@
> */
> extern struct bug_entry __start___bug_table[], __stop___bug_table[];
>
> -#ifndef CONFIG_MODULES
> -#define module_find_bug(x) NULL
> -#endif
>
Looks like you need to delete a bit more here - the extern struct
bug_entry, and the comment above.
J
^ permalink raw reply
* Re: [PATCH 4/7] Add MPC8360EMDS board support (try 2)
From: Kim Phillips @ 2006-10-04 21:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <CEA95FBE-ED7E-4512-A6C5-6362DAE69744@kernel.crashing.org>
On Tue, 3 Oct 2006 23:27:42 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 3, 2006, at 11:17 PM, Kim Phillips wrote:
>
<snip>
> > arch/powerpc/platforms/83xx/mpc8360e_pb.c | 220 ++++++
> > arch/powerpc/platforms/83xx/mpc8360e_pb.h | 23 +
> > 3 files changed, 1261 insertions(+), 0 deletions(-)
>
> What's the point of the mpc8360e_pb.h if there's nothing in it?
>
well I thought I was being consistent with the other 83xx boards ;)
> Also, any reason the files are _pb and config is emds?
>
_pb == processor board, the core of the mds (modular development system). The pb can be operated independently of the rest of what comprises the mds.
I used mds nomenclature in 832x since the support includes parts of the mds that are separate from just the pb, e.g. the pci bits in the device tree.
but we need to be more consistent, I agree.
also, there is a wealth of duplicated platform code among each of the four 83xx platforms. Somethings wrong when one duplicates a file just to s/836/832/g. How about consolidating them all down to one mpc83xx_mach.c file that enables potential board quirks based on the dev tree root's model property? That will eliminate all the redundant code, and get rid of the file naming inconsistencies.
Kim
^ permalink raw reply
* bdm/jtag interface for MPC834x with gdb access
From: Reeve Yang @ 2006-10-04 22:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
Can anyone share experience on bcm/jtag interface for MPC834x with gdb
access? I'm using windriver usb jtag probe. Is there any bdm interface with
gdb access available for it?
Thanks.
- Reeve
[-- Attachment #2: Type: text/html, Size: 214 bytes --]
^ permalink raw reply
* Re: [PATCH] use-generic-bug-for-ppc resubmitted
From: Judith Lebzelter @ 2006-10-04 23:29 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Andrew Morton, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <45241659.301@goop.org>
On Wed, Oct 04, 2006 at 01:15:21PM -0700, Jeremy Fitzhardinge wrote:
> Judith Lebzelter wrote:
> >Index: linux/arch/ppc/kernel/traps.c
> >===================================================================
> >--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03
> >16:11:26.461653713 -0700
> >+++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
> >@@ -28,6 +28,7 @@
> > #include <linux/init.h>
> > #include <linux/module.h>
> > #include <linux/prctl.h>
> >+#include <linux/bug.h>
> >
> > #include <asm/pgtable.h>
> > #include <asm/uaccess.h>
> >@@ -568,55 +569,9 @@
> > */
> > extern struct bug_entry __start___bug_table[], __stop___bug_table[];
> >
> >-#ifndef CONFIG_MODULES
> >-#define module_find_bug(x) NULL
> >-#endif
> >
> Looks like you need to delete a bit more here - the extern struct
> bug_entry, and the comment above.
> J
Here is the generic bug ppc patch with the suggested change. It compiles
without error.
Signed-off-by: Judith Lebzelter <judith@osdl.org>
---
arch/ppc/kernel/traps.c
arch/ppc/Kconfig
Index: linux/arch/ppc/Kconfig
===================================================================
--- linux.orig/arch/ppc/Kconfig 2006-10-03 16:11:26.000000000 -0700
+++ linux/arch/ppc/Kconfig 2006-10-03 17:10:09.000000000 -0700
@@ -52,6 +52,11 @@
bool
default y
+config GENERIC_BUG
+ bool
+ default y
+ depends on BUG
+
source "init/Kconfig"
menu "Processor"
Index: linux/arch/ppc/kernel/traps.c
===================================================================
--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.000000000 -0700
+++ linux/arch/ppc/kernel/traps.c 2006-10-04 15:37:46.674644563 -0700
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/prctl.h>
+#include <linux/bug.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -559,64 +560,9 @@
}
}
-/*
- * Look through the list of trap instructions that are used for BUG(),
- * BUG_ON() and WARN_ON() and see if we hit one. At this point we know
- * that the exception was caused by a trap instruction of some kind.
- * Returns 1 if we should continue (i.e. it was a WARN_ON) or 0
- * otherwise.
- */
-extern struct bug_entry __start___bug_table[], __stop___bug_table[];
-
-#ifndef CONFIG_MODULES
-#define module_find_bug(x) NULL
-#endif
-
-struct bug_entry *find_bug(unsigned long bugaddr)
-{
- struct bug_entry *bug;
-
- for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
- if (bugaddr == bug->bug_addr)
- return bug;
- return module_find_bug(bugaddr);
-}
-
-int check_bug_trap(struct pt_regs *regs)
+int is_valid_bugaddr(unsigned long addr)
{
- struct bug_entry *bug;
- unsigned long addr;
-
- if (regs->msr & MSR_PR)
- return 0; /* not in kernel */
- addr = regs->nip; /* address of trap instruction */
- if (addr < PAGE_OFFSET)
- return 0;
- bug = find_bug(regs->nip);
- if (bug == NULL)
- return 0;
- if (bug->line & BUG_WARNING_TRAP) {
- /* this is a WARN_ON rather than BUG/BUG_ON */
-#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
-#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
- dump_stack();
- return 1;
- }
-#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
- xmon(regs);
-#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
-
- return 0;
+ return addr >= PAGE_OFFSET;
}
void program_check_exception(struct pt_regs *regs)
@@ -671,7 +617,9 @@
/* trap exception */
if (debugger_bpt(regs))
return;
- if (check_bug_trap(regs)) {
+
+ if (!(regs->msr & MSR_PR) && /* not user-mode */
+ report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
^ permalink raw reply
* Please pull powerpc.git 'master' branch
From: Paul Mackerras @ 2006-10-04 23:36 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
again, to get a Cell update. I apologize on Arnd's behalf for the
lateness of this update.
Thanks,
Paul.
arch/powerpc/configs/cell_defconfig | 60 +++
arch/powerpc/platforms/cell/Kconfig | 5
arch/powerpc/platforms/cell/interrupt.c | 10 -
arch/powerpc/platforms/cell/iommu.c | 8
arch/powerpc/platforms/cell/spider-pic.c | 6
arch/powerpc/platforms/cell/spu_base.c | 168 ++++++++--
arch/powerpc/platforms/cell/spufs/Makefile | 2
arch/powerpc/platforms/cell/spufs/context.c | 6
arch/powerpc/platforms/cell/spufs/file.c | 354 +++++++++++++++-----
arch/powerpc/platforms/cell/spufs/gang.c | 81 +++++
arch/powerpc/platforms/cell/spufs/inode.c | 232 +++++++++++--
arch/powerpc/platforms/cell/spufs/run.c | 48 ++-
arch/powerpc/platforms/cell/spufs/sched.c | 450 ++++++++++----------------
arch/powerpc/platforms/cell/spufs/spufs.h | 29 ++
arch/powerpc/platforms/cell/spufs/switch.c | 9 +
arch/powerpc/platforms/cell/spufs/syscalls.c | 9 -
include/asm-powerpc/spu.h | 36 ++
17 files changed, 1017 insertions(+), 496 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spufs/gang.c
Arnd Bergmann:
[POWERPC] spufs: implement error event delivery to user space
[POWERPC] spufs: Add infrastructure needed for gang scheduling
[POWERPC] spufs: use correct pg_prot for mapping SPU local store
[POWERPC] spufs: make mailbox functions handle multiple elements
[POWERPC] spufs: remove support for ancient firmware
[POWERPC] spufs: add support for read/write on cntl
[POWERPC] spufs: support new OF device tree format
[POWERPC] spufs: add infrastructure for finding elf objects
[POWERPC] Update cell_defconfig
[POWERPC] spiderpic: enable new style devtree support
[POWERPC] cell: fix bugs found by sparse
Benjamin Herrenschmidt:
[POWERPC] spufs: cell spu problem state mapping updates
HyeonSeung Jang:
[POWERPC] spufs: fix context switch during page fault
Mark Nutter:
[POWERPC] spufs: scheduler support for NUMA.
^ 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