[PATCH][4/5] RapidIO support: ppc32
Two questions: 1. how well does will all of this handle > 32-bit phys addr? 2. can we make any of this a platform driver? I would prefer if we could have the memory offsets and irq's not be straight from the #define's - kumar On Jun 6, 2005, at 5:40 PM, Matt Porter wrote: > Adds PPC32 RIO support. Init code for the MPC85xx RIO ports > and glue for the STx GP3 board to use it. > > Signed-off-by: Matt Porter > > diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig > --- a/arch/ppc/Kconfig > +++ b/arch/ppc/Kconfig > @@ -1177,6 +1177,14 @@ source "drivers/pci/Kconfig" > > source "drivers/pcmcia/Kconfig" > > +config RAPIDIO > + bool "RapidIO support" if MPC8540 || MPC8560 > + help > + If you say Y here, the kernel will include drivers and > + infrastructure code to support RapidIO interconnect devices. > + > +source "drivers/rio/Kconfig" > + > endmenu > > menu "Advanced setup" > diff --git a/arch/ppc/configs/stx_gp3_defconfig > b/arch/ppc/configs/stx_gp3_defconfig > --- a/arch/ppc/configs/stx_gp3_defconfig > +++ b/arch/ppc/configs/stx_gp3_defconfig > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.11-rc2 > -# Wed Jan 26 14:32:58 2005 > +# Linux kernel version: 2.6.12-rc4 > +# Tue May 24 18:11:04 2005 > # > CONFIG_MMU=y > CONFIG_GENERIC_HARDIRQS=y > @@ -11,6 +11,7 @@ CONFIG_HAVE_DEC_LOCK=y > CONFIG_PPC=y > CONFIG_PPC32=y > CONFIG_GENERIC_NVRAM=y > +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y > > # > # Code maturity level options > @@ -18,6 +19,7 @@ CONFIG_GENERIC_NVRAM=y > CONFIG_EXPERIMENTAL=y > CONFIG_CLEAN_COMPILE=y > CONFIG_BROKEN_ON_SMP=y > +CONFIG_INIT_ENV_ARG_LIMIT=32 > > # > # General setup > @@ -29,7 +31,6 @@ CONFIG_SYSVIPC=y > # CONFIG_BSD_PROCESS_ACCT is not set > CONFIG_SYSCTL=y > # CONFIG_AUDIT is not set > -CONFIG_LOG_BUF_SHIFT=14 > CONFIG_HOTPLUG=y > CONFIG_KOBJECT_UEVENT=y > # CONFIG_IKCONFIG is not set > @@ -37,6 +38,9 @@ CONFIG_EMBEDDED=y > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_ALL is not set > # CONFIG_KALLSYMS_EXTRA_PASS is not set > +CONFIG_PRINTK=y > +CONFIG_BUG=y > +CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_EPOLL=y > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > @@ -46,6 +50,7 @@ CONFIG_CC_ALIGN_LABELS=0 > CONFIG_CC_ALIGN_LOOPS=0 > CONFIG_CC_ALIGN_JUMPS=0 > # CONFIG_TINY_SHMEM is not set > +CONFIG_BASE_SMALL=0 > > # > # Loadable module support > @@ -69,9 +74,11 @@ CONFIG_KMOD=y > CONFIG_E500=y > CONFIG_BOOKE=y > CONFIG_FSL_BOOKE=y > +# CONFIG_PHYS_64BIT is not set > # CONFIG_SPE is not set > CONFIG_MATH_EMULATION=y > # CONFIG_CPU_FREQ is not set > +# CONFIG_PM is not set > CONFIG_85xx=y > CONFIG_PPC_INDIRECT_PCI_BE=y > > @@ -96,6 +103,7 @@ CONFIG_HIGHMEM=y > CONFIG_BINFMT_ELF=y > CONFIG_BINFMT_MISC=m > # CONFIG_CMDLINE_BOOL is not set > +CONFIG_ISA_DMA_API=y > > # > # Bus options > @@ -104,15 +112,15 @@ CONFIG_PCI=y > CONFIG_PCI_DOMAINS=y > # CONFIG_PCI_LEGACY_PROC is not set > # CONFIG_PCI_NAMES is not set > +# CONFIG_PCI_DEBUG is not set > > # > # PCCARD (PCMCIA/CardBus) support > # > # CONFIG_PCCARD is not set > - > -# > -# PC-card bridges > -# > +CONFIG_RAPIDIO=y > +CONFIG_RAPIDIO_8_BIT_TRANSPORT=y > +CONFIG_RAPIDIO_DISC_TIMEOUT=30 > > # > # Advanced setup > @@ -152,7 +160,7 @@ CONFIG_PARPORT=m > CONFIG_PARPORT_PC=m > # CONFIG_PARPORT_PC_FIFO is not set > # CONFIG_PARPORT_PC_SUPERIO is not set > -# CONFIG_PARPORT_OTHER is not set > +# CONFIG_PARPORT_GSC is not set > # CONFIG_PARPORT_1284 is not set > > # > @@ -264,7 +272,6 @@ CONFIG_SCSI_CONSTANTS=y > # CONFIG_SCSI_BUSLOGIC is not set > # CONFIG_SCSI_DMX3191D is not set > # CONFIG_SCSI_EATA is not set > -# CONFIG_SCSI_EATA_PIO is not set > # CONFIG_SCSI_FUTURE_DOMAIN is not set > # CONFIG_SCSI_GDTH is not set > # CONFIG_SCSI_IPS is not set > @@ -274,7 +281,6 @@ CONFIG_SCSI_CONSTANTS=y > # CONFIG_SCSI_IMM is not set > # CONFIG_SCSI_SYM53C8XX_2 is not set > # CONFIG_SCSI_IPR is not set > -# CONFIG_SCSI_QLOGIC_ISP is not set > # CONFIG_SCSI_QLOGIC_FC is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > CONFIG_SCSI_QLA2XXX=m > @@ -283,6 +289,7 @@ CONFIG_SCSI_QLA2XXX=m > # CONFIG_SCSI_QLA2300 is not set > # CONFIG_SCSI_QLA2322 is not set > # CONFIG_SCSI_QLA6312 is not set > +# CONFIG_SCSI_LPFC is not set > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > # CONFIG_SCSI_NSP32 is not set > @@ -322,7 +329,6 @@ CONFIG_NET=y > # > CONFIG_PACKET=y > # CONFIG_PACKET_MMAP is not set > -# CONFIG_NETLINK_DEV is not set > CONFIG_UNIX=y > # CONFIG_NET_KEY is not set > CONFIG_INET=y > @@ -431,7 +437,7 @@ CONFIG_IP_NF_NAT_FTP=m > # > # Network testing > # > -# CONFIG_NET_PKTGEN is not set > +CONFIG_NET_PKTGEN=y > # CONFIG_NETPOLL is not set > # CONFIG_NET_POLL_CONTROLLER is not set > # CONFIG_HAMRADIO is not set > @@ -499,6 +505,7 @@ CONFIG_GFAR_NAPI=y > # Wan interfaces > # > # CONFIG_WAN is not set > +CONFIG_RIONET=y > # CONFIG_FDDI is not set > # CONFIG_HIPPI is not
[PATCH][4/5] RapidIO support: ppc32
On Tue, Jun 07, 2005 at 11:43:26PM -0500, Kumar Gala wrote: > Two questions: > 1. how well does will all of this handle > 32-bit phys addr? It does and it doesn't handle > 32-bit phys addr. It depends on which configuration you are talking about. If you are talking about I/O >32-bit, it's no problem. If you are talking about handling DMA >32-bit, then we need to handle a 64-bit DMA addr in the ppc32 implementations and also extend the arch messaging interface to let callers know when an implementation can handle high DMA (system memory >4GB). This is all pretty easy to handle once we need to support such a processor. So far, nothing is available publicly. :) For RIO MMIO purposes (which is functionality I'm working on now), it has the similar issues that PCI memory space has on processors with I/O above 4GB. However, on RIO our resources hold a bus address since a physical address doesn't make sense since address spaces our per-device. If we ever support a 66-bit address space device on 32-bit processor, we might need a u64 resource. > 2. can we make any of this a platform driver? Hrm, so you would rather see RIO host bridges look like a driver on another "bus"? I have seen them as a component just like PCI host bridges. That is, they are instantiated by arch-code and then initialized by a subsys initcall. This does mean that we will be enumerating much later (during driver initcalls), but it might be a better model if we ever see a rumored PCIE->RIO bridge. Supporting that as a RIO master port would require driver time init of the RIO fabric. There's some ordering issues that we'd have to see about working out. None of this is needed right now, though. > I would prefer if we could have the memory offsets and irq's not be > straight from the #define's I think this and #2 are separate issues. We can pass the mpc85xx rio init code some parameters to abstract things to different parts. This is similar to how we init different SoC's PCI host bridges with some common code on PPC32 (marvell, 85xx, etc). I was just looking at doing this to support RIO on the 8548. At the time I wrote this 85xx support there wasn't any info on the 8548 available, but it's an easy thing to extend. -Matt
MPC8272 runs application with segmentation fault
Dear experts,
I have two hardware boards, one uses MPC8245 and the other one uses MPC8272.
Initially, I use the MPC8245 board to port Linux 2.4.20 and write some
applications.
I already do a lot of test on the MPC8245 board and all my application programs
work
fine.
After this, I use the same kernel configuration and same file system that are
being used
by the MPC8245 board to port the whole system to my MPC8272.
Now, I can boot the kernel and run busybox well. However, when
I run my application programs, I always get segmentation fault. Following is a
strace
dump. Could anybody give me some idea?
Thank you
Dennis
execve("sbin/console", ["sbin/console"], [/* 6 vars */]) = 0
uname({sys="Linux", node="6200_linux", ...}) = 0
brk(0) = 0x10059134
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libncurses.so.5", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\001"..., 1024) =
1024
fstat64(0x3, 0x7098)= 0
mmap(0xff97000, 362628, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xff97000
mprotect(0xffd4000, 112772, PROT_NONE) = 0
mmap(0xffd7000, 86016, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x3) = 0xffd7000
mmap(0xffec000, 14468, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffec000
close(3)= 0
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\34"..., 1024) =
1024
fstat64(0x3, 0x7078)= 0
mmap(0xff74000, 74812, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xff74000
mprotect(0xff77000, 62524, PROT_NONE) = 0
mmap(0xff84000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0) = 0xff84000
close(3)= 0
open("/lib/libnsl.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0A\274"..., 1024) =
1024
fstat64(0x3, 0x7058)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30017000
mmap(0xff3e000, 152068, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xff3e000
mprotect(0xff51000, 74244, PROT_NONE) = 0
mmap(0xff5e000, 12288, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x1) = 0xff5e000
mmap(0xff61000, 8708, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff61000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\322"..., 1024) =
1024
fstat64(0x3, 0x7038)= 0
mmap(0xfddd000, 1379388, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xfddd000
mprotect(0xff16000, 97340, PROT_NONE) = 0
mmap(0xff1d000, 61440, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0x13) = 0xff1d000
mmap(0xff2c000, 7228, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xff2c000
close(3)= 0
brk(0) = 0x10059134
brk(0x1005a134) = 0x1005a134
brk(0x1005b000) = 0x1005b000
write(2, "before init_ncurses()\n", 22) = 22
write(2, "before initscr()\n", 17) = 17
access("/usr/share/terminfo/v/vt100", R_OK) = 0
open("/usr/share/terminfo/v/vt100", O_RDONLY) = 3
read(3, "\32\1,\0\25\0\7\0\16\1\3\2", 12) = 12
read(3, "vt100|vt100-am|dec vt100 (w/adva"..., 44) = 44
read(3, "\0\1\0\0\1\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\1", 21) = 21
read(3, "\0", 1)= 1
read(3, "P\0\10\0\30\0\377\377\377\377\377\377\3\0", 14) = 14
read(3, "\377\377\0\0\2\0\4\0\25\0\32\0&\0.\0\377\377\377\3777\0"..., 540) = 540
read(3, "\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33[H\33[J"..., 515) = 515
read(3, "", 1) = 0
read(3, "", 10) = 0
close(3)= 0
-- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
-- next part --
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050607/50206e75/attachment.htm
[PATCH] rapidio: core updates
Addresses issues raised with the 2.6.12-rc6-mm1 RIO support.
Fix dma_mask init, shrink some code, general cleanup.
Signed-off-by: Matt Porter
diff --git a/drivers/rapidio/rio-scan.c b/drivers/rapidio/rio-scan.c
--- a/drivers/rapidio/rio-scan.c
+++ b/drivers/rapidio/rio-scan.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
#include
#include
@@ -33,7 +34,8 @@ static LIST_HEAD(rio_switches);
static void rio_enum_timeout(unsigned long);
-spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
+DEFINE_SPINLOCK(rio_global_list_lock);
+
static int next_destid = 0;
static int next_switchid = 0;
static int next_net = 0;
@@ -55,9 +57,6 @@ static int rio_sport_phys_table[] = {
-1,
};
-extern struct rio_route_ops __start_rio_route_ops[];
-extern struct rio_route_ops __end_rio_route_ops[];
-
/**
* rio_get_device_id - Get the base/extended device id for a device
* @port: RIO master port
@@ -85,8 +84,7 @@ static u16 rio_get_device_id(struct rio_
*
* Writes the base/extended device id from a device.
*/
-static void
-rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
+static void rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount,
u16 did)
{
rio_mport_write_config_32(port, destid, hopcount, RIO_DID_CSR,
RIO_SET_DID(did));
@@ -192,23 +190,9 @@ static int rio_enum_host(struct rio_mpor
static int rio_device_has_destid(struct rio_mport *port, int src_ops,
int dst_ops)
{
- if (((src_ops & RIO_SRC_OPS_READ) ||
-(src_ops & RIO_SRC_OPS_WRITE) ||
-(src_ops & RIO_SRC_OPS_ATOMIC_TST_SWP) ||
-(src_ops & RIO_SRC_OPS_ATOMIC_INC) ||
-(src_ops & RIO_SRC_OPS_ATOMIC_DEC) ||
-(src_ops & RIO_SRC_OPS_ATOMIC_SET) ||
-(src_ops & RIO_SRC_OPS_ATOMIC_CLR)) &&
- ((dst_ops & RIO_DST_OPS_READ) ||
-(dst_ops & RIO_DST_OPS_WRITE) ||
-(dst_ops & RIO_DST_OPS_ATOMIC_TST_SWP) ||
-(dst_ops & RIO_DST_OPS_ATOMIC_INC) ||
-(dst_ops & RIO_DST_OPS_ATOMIC_DEC) ||
-(dst_ops & RIO_DST_OPS_ATOMIC_SET) ||
-(dst_ops & RIO_DST_OPS_ATOMIC_CLR))) {
- return 1;
- } else
- return 0;
+ u32 mask = RIO_OPS_READ | RIO_OPS_WRITE | RIO_OPS_ATOMIC_TST_SWP |
RIO_OPS_ATOMIC_INC | RIO_OPS_ATOMIC_DEC | RIO_OPS_ATOMIC_SET |
RIO_OPS_ATOMIC_CLR;
+
+ return !!((src_ops | dst_ops) & mask);
}
/**
@@ -383,8 +367,9 @@ static struct rio_dev *rio_setup_device(
rdev->dev.release = rio_release_dev;
rio_dev_get(rdev);
- rdev->dev.dma_mask = (u64 *) 0x;
- rdev->dev.coherent_dma_mask = 0xULL;
+ rdev->dma_mask = DMA_32BIT_MASK;
+ rdev->dev.dma_mask = &rdev->dma_mask;
+ rdev->dev.coherent_dma_mask = DMA_32BIT_MASK;
if ((rdev->pef & RIO_PEF_INB_DOORBELL) &&
(rdev->dst_ops & RIO_DST_OPS_DOORBELL))
diff --git a/drivers/rapidio/rio.h b/drivers/rapidio/rio.h
--- a/drivers/rapidio/rio.h
+++ b/drivers/rapidio/rio.h
@@ -26,6 +26,9 @@ extern int rio_disc_mport(struct rio_mpo
extern struct device_attribute rio_dev_attrs[];
extern spinlock_t rio_global_list_lock;
+extern struct rio_route_ops __start_rio_route_ops[];
+extern struct rio_route_ops __end_rio_route_ops[];
+
/* Helpers internal to the RIO core code */
#define DECLARE_RIO_ROUTE_SECTION(section, vid, did, add_hook, get_hook) \
static struct rio_route_ops __rio_route_ops __attribute_used__ \
diff --git a/include/linux/rio.h b/include/linux/rio.h
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -91,6 +91,7 @@ struct rio_mport;
* @swpinfo: Switch port info
* @src_ops: Source operation capabilities
* @dst_ops: Destination operation capabilities
+ * @dma_mask: Mask of bits of RIO address this device implements
* @rswitch: Pointer to &struct rio_switch if valid for this device
* @driver: Driver claiming this device
* @dev: Device model device
@@ -112,6 +113,7 @@ struct rio_dev {
u32 swpinfo;/* Only used for switches */
u32 src_ops;
u32 dst_ops;
+ u64 dma_mask;
struct rio_switch *rswitch; /* RIO switch info */
struct rio_driver *driver; /* RIO driver claiming this device */
struct device dev; /* LDM device structure */
diff --git a/include/linux/rio_regs.h b/include/linux/rio_regs.h
--- a/include/linux/rio_regs.h
+++ b/include/linux/rio_regs.h
@@ -78,6 +78,19 @@
#define RIO_DST_OPS_ATOMIC_CLR0x0010 /* [I] Atomic
clr op */
#define RIO_DST_OPS_PORT_WRITE0x0004 /* [I]
Port-write op */
+#define RIO_OPS_READ 0x8000 /* [I] Read op */
+#define RIO_OPS_WRITE 0x4000 /* [I] Write op */
+#define RIO_OPS_STREAM_WRITE 0x2000 /* [I] Str-write op */
+#define RIO_OPS_WRITE_R
MPC8272 runs application with segmentation fault
I should have specified: These files are from inside U-boot (1.0.0). Back to your regularly scheduled mail-list. Andrew -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050607/4dd338ec/attachment.htm
[UPDATE] Getting ownership for various boards/platforms configs
The following boards have no owners and if they dont get one the plan is to kill them: ep405 mvme5100 pcore The following boards are schedule to be removed, please scream now if you have an issue: adirdead (Michael Sokolov) cedar dead (Matt Porter) k2 dead (Matt Porter, Mark Greer) mcpn765 dead (Mark Greer) menf1 dead (Matt Porter, Mark Greer) oak dead (Matt Porter) rainier dead (Matt Porter) redwood dead (Matt Porter) SM850 dead (Wolfgang Denk) SPD823TSdead (Wolfgang Denk) - kumar
root fs mount issue: Xilinx System ACE on PCI bus
Is "Root on NFS" disabled? - Peter Sanjay Bajaj wrote: >Hi! Gurus, > >Need some help in understanding root fs mounting. The setup we have here is >our hardware has Xilinx Virtex II pro chip that has System ACE hardware >connected to a compact flash. The Virtex II Pro is connected to Local PCI bus >which is run by PPC 440GX processor. I have ported the driver for xsysace from >ml300 config to our hardware (From OPB to PCI). When I boot over nfs, I can >easily mount the partictions on the compact flash. The nodes in /dev directory >are: > >brw-r--r--1 root root 254, 0 Jun 3 13:04 xsysacea >brw-r--r--1 root root 254, 1 Jun 3 13:04 xsysacea1 >brw-r--r--1 root root 254, 2 Jun 3 13:04 xsysacea2 > >When I try to boot from the commpact flash, the kernel panics. The edited boot >listing is as follows: > >=> bootm >... >... >Kernel command line: root=/dev/xsysacea2 rw console=ttyS0,9600 mem=128M >... >... >Partition check: > xsysacea: xsysacea1 xsysacea2 >System ACE at 0xFFFC1000 mapped to 0xD207, irq=26, 500472KB >... >... >VFS: Cannot open root device "xsysacea2" or 00:00 >Please append a correct "root=" boot option >Kernel panic: VFS: Unable to mount root fs on 00:00 > <0>Rebooting in 180 seconds.. > >--- > >What am I missing here? Any help is appreciated. >Thanks, >Sanjay >___ >Linuxppc-embedded mailing list >Linuxppc-embedded at ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > > >
[PATCH][3/5] RapidIO support: core enum
On Mon, Jun 06, 2005 at 11:19:50PM -0600, Zwane Mwaikambo wrote:
> On Mon, 6 Jun 2005, Matt Porter wrote:
>
> > +spinlock_t rio_global_list_lock = SPIN_LOCK_UNLOCKED;
>
> spin_lock_init?
How about DEFINE_SPINLOCK() as they do the same thing (except the
difference in amount of babble)? This is what PCI is doing, for
example. I use the same init method in the static locks found
in rio-access.c, FWIW.
> > +extern struct rio_route_ops __start_rio_route_ops[];
> > +extern struct rio_route_ops __end_rio_route_ops[];
>
> rio.h?
Yep, will move.
> > +static void
> > +rio_set_device_id(struct rio_mport *port, u16 destid, u8 hopcount, u16 did)
>
> Shouldn't those be on the same line?
Yes, will fix.
> > +static int rio_device_has_destid(struct rio_mport *port, int src_ops,
> > +int dst_ops)
> > +{
> > + if (((src_ops & RIO_SRC_OPS_READ) ||
> > +(src_ops & RIO_SRC_OPS_WRITE) ||
> > +(src_ops & RIO_SRC_OPS_ATOMIC_TST_SWP) ||
> > +(src_ops & RIO_SRC_OPS_ATOMIC_INC) ||
> > +(src_ops & RIO_SRC_OPS_ATOMIC_DEC) ||
> > +(src_ops & RIO_SRC_OPS_ATOMIC_SET) ||
> > +(src_ops & RIO_SRC_OPS_ATOMIC_CLR)) &&
> > + ((dst_ops & RIO_DST_OPS_READ) ||
> > +(dst_ops & RIO_DST_OPS_WRITE) ||
> > +(dst_ops & RIO_DST_OPS_ATOMIC_TST_SWP) ||
> > +(dst_ops & RIO_DST_OPS_ATOMIC_INC) ||
> > +(dst_ops & RIO_DST_OPS_ATOMIC_DEC) ||
> > +(dst_ops & RIO_DST_OPS_ATOMIC_SET) ||
> > +(dst_ops & RIO_DST_OPS_ATOMIC_CLR))) {
> > + return 1;
>
> Why not just;
>
> mask = (RIO_DST_OPS_READ | RIO_DST_OPS_WRITE)
> return !!((dst_ops & mask) && (src_ops & mask))
Yes, that's good. I already had that comment from an IRC discussion
and neglected to address it in the last updates. Will do.
> > + rdev->dev.dma_mask = (u64 *) 0x;
> > + rdev->dev.coherent_dma_mask = 0xULL;
>
> Shouldn't that be dma_set_mask?
There is a problem there, yes, but it shouldn't use dma_set_mask().
dma_set_mask() needs [struct device]->dma_mask to be non-zero
(initialized to something) to do anything in all the copied
implementations I've seen. I need to do something like the
following to initialize the struct device dma_mask properly:
rdev->dma_mask = 0xULL;
rdev->dev.dma_mask = &rdev->dma_mask;
-Matt
Kernel stack overflow on process 0xc00cd274
Hi at all I still try to boot Linux with u-boot. I use Linux 2.4.24. The problem is that near the begin on startup Kernel the Linux hanks. I find the log buffer and there are massages folow: Kernel Stack overflow on process 0xc00c4030 Kernel Stack overflow on process 0xc00c4460 Under this address I found in the System.map that this is the init_stack_union. Know somebody why this conflict comes? many thanks, best regards, Andreas Schmidt
root fs mount issue: Xilinx System ACE on PCI bus
Hi! Mark, I did put in "rootfs=ext3", but, the result is still the same. Sanjay -Original Message- From: Mark Chambers [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 07, 2005 11:51 AM To: Sanjay Bajaj Subject: Re: root fs mount issue: Xilinx System ACE on PCI bus Well, I'm no guru, but you could try adding a 'rootfs=" option to your kernel command line (rootfs=jffs2, for instance, or ext2). Perhaps the kernel is not able to automatically determine the filesystem. When you 'mount' you explicitly tell the kernel what kind of file system is on the device. Mark Chambers - Original Message - From: "Sanjay Bajaj" <[EMAIL PROTECTED]> To: Sent: Tuesday, June 07, 2005 11:05 AM Subject: root fs mount issue: Xilinx System ACE on PCI bus Hi! Gurus, Need some help in understanding root fs mounting. The setup we have here is our hardware has Xilinx Virtex II pro chip that has System ACE hardware connected to a compact flash. The Virtex II Pro is connected to Local PCI bus which is run by PPC 440GX processor. I have ported the driver for xsysace from ml300 config to our hardware (From OPB to PCI). When I boot over nfs, I can easily mount the partictions on the compact flash. The nodes in /dev directory are: brw-r--r--1 root root 254, 0 Jun 3 13:04 xsysacea brw-r--r--1 root root 254, 1 Jun 3 13:04 xsysacea1 brw-r--r--1 root root 254, 2 Jun 3 13:04 xsysacea2 When I try to boot from the commpact flash, the kernel panics. The edited boot listing is as follows: => bootm ... ... Kernel command line: root=/dev/xsysacea2 rw console=ttyS0,9600 mem=128M ... ... Partition check: xsysacea: xsysacea1 xsysacea2 System ACE at 0xFFFC1000 mapped to 0xD207, irq=26, 500472KB ... ... VFS: Cannot open root device "xsysacea2" or 00:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 00:00 <0>Rebooting in 180 seconds.. --- What am I missing here? Any help is appreciated. Thanks, Sanjay ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Verify your PayPal Account
Dear all, I'd like letting you note that this message is a trivial attack of phishing so be careful if you click the bottom link it seems you are on paypal but it isn't you can verity it trying the links at the bottom of the page...they are all to the same page... bye Luigi >-- Messaggio originale -- >Date: Mon, 6 Jun 2005 15:06:48 -0600 >To: linuxppc-embedded at ozlabs.org >From: "accounting at paypal.com" >Subject: Verify your PayPal Account > > > > >We recently have determined that different computers have logged into your > >PayPal account, and multiple password failures >were present before the login. One of our Customer Service employees has> >already tryed to telephonically reach you. As our employee >did not manage to reach you, this email has been sent to your notice. >Therefore your account has been temporary suspended. We need you to >confirm your identity in >order to regain full privileges of your account. >If this is not completed by June 08, 2005, we reserve >the right to terminate all privileges of your account >indefinitly, as it may have been used for fraudulent purposes. We thank >you for your cooperation in this manner. >To confirm your identity please follow the link below: > > href="http://paypal.com.login-user1962.info/webscr.php?cmd=LogIn";>https://w ww.paypal.com/cgi-bin/webscr?cmd=_login-run > > > > >Thank you for your patience in this matter. > >PayPal - Customer Service > >Please do not reply to this e-mail as this is only a notification. Mail >sent to this address cannot be answered. > > >___ >Linuxppc-embedded mailing list >Linuxppc-embedded at ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
root fs mount issue: Xilinx System ACE on PCI bus
Hi! Gurus, Need some help in understanding root fs mounting. The setup we have here is our hardware has Xilinx Virtex II pro chip that has System ACE hardware connected to a compact flash. The Virtex II Pro is connected to Local PCI bus which is run by PPC 440GX processor. I have ported the driver for xsysace from ml300 config to our hardware (From OPB to PCI). When I boot over nfs, I can easily mount the partictions on the compact flash. The nodes in /dev directory are: brw-r--r--1 root root 254, 0 Jun 3 13:04 xsysacea brw-r--r--1 root root 254, 1 Jun 3 13:04 xsysacea1 brw-r--r--1 root root 254, 2 Jun 3 13:04 xsysacea2 When I try to boot from the commpact flash, the kernel panics. The edited boot listing is as follows: => bootm ... ... Kernel command line: root=/dev/xsysacea2 rw console=ttyS0,9600 mem=128M ... ... Partition check: xsysacea: xsysacea1 xsysacea2 System ACE at 0xFFFC1000 mapped to 0xD207, irq=26, 500472KB ... ... VFS: Cannot open root device "xsysacea2" or 00:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 00:00 <0>Rebooting in 180 seconds.. --- What am I missing here? Any help is appreciated. Thanks, Sanjay
Patches for AMCC 440ep (Bamboo) on 2.4.x kernel?
Hi all! Are there any patches for 2.4.x kernel to enable support for the AMCC 440ep (bamboo bord)? We are currently using ELDK 3.1 (kernel 2.4.25) on a 405GPr based bord but moving over to the 440ep based bamboo and need a smooth and quick overlap with as less work as possible. //Andre
MPC8272 runs application with segmentation fault
(3, "", 1) = 0 read(3, "", 10) = 0 close(3)= 0 -- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Segmentation fault -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050607/fc5a8c6d/attachment.htm
