virtex 4 linux driver bus error
hello at all,
at the moment I use development board ML410 with montavistalinux.
I have a problem, please help me!
I try to write a linux-driver for writing or reading registers.
I have a ace-file, which contents Linux and EDK-project with a component
(IP-wizard) which is added on a PLB-bus.
I also have a driver-construct which I can register (insmod driver.ko) into the
linux-Kernel only if i do not use functions to write or read the bus
(XIO_out32() or XIO_in32 () ). If I use this function after registering the
driver I got an error.
If I try to insert the modul with Insmod driver.ko I get a bus error!
my driver is similar to
http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021578.html
her the two importent functions of the driver:
#define REG_BASE(u32) XPAR_komponente_0_BASEADDR // defined in
xparameters_ml41x.h
#define REG_HIGH(u32) XPAR_komponente_0_HIGHADDR // defined in
xparameters_ml41x.h
#define reg0_upper (u32) komponente_SLV_REG0_OFFSET // 32-bit register /
defined in komponente.h
#define reg1_upper (u32) komponente_SLV_REG1_OFFSET // 32-bit register /
defined in komponente.h
#define reg2_upper (u32) komponente_SLV_REG2_OFFSET // 32-bit register /
defined in komponente.h
const static long remap_size = REG_HIGH - REG_BASE + 1;
static void read_register_values(void)
{
static u32 upper;
printk(%s:\n,DRIVERNAME);
printk(%s: | upper |\n,DRIVERNAME);
printk(%s:--|---|\n,DRIVERNAME);
upper = XIo_In32(reg_remapped_address + reg1_upper);
printk(%s: Daten im Register 35 |%15X |\n, DRIVERNAME, upper );
}
static int __init meintreiber_init(void)
reg_remapped_address = (u32) ioremap(REG_BASE, remap_size);
rtn = misc_register(miscdev);
if (rtn)
{
printk(%s: %s error driver not reg. \n,DRIVERNAME,
miscdev.name);
return rtn;
}
read2_register_values();
in the messeges log file i got the 3 printk lins and this line
upper = XIo_In32(reg_remapped_address + reg1_upper);
creates a error
Thank you very much for your kind help!
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: virtex 4 linux driver bus error
See the inline comments.
-Original Message-
From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-
[EMAIL PROTECTED] On Behalf Of Mirsad Vejseli
Sent: Wednesday, October 22, 2008 6:10 AM
To: linuxppc-embedded@ozlabs.org
Subject: virtex 4 linux driver bus error
hello at all,
at the moment I use development board ML410 with montavistalinux.
I have a problem, please help me!
I try to write a linux-driver for writing or reading registers.
I have a ace-file, which contents Linux and EDK-project with a component
(IP-wizard) which is added
on a PLB-bus.
I also have a driver-construct which I can register (insmod driver.ko) into
the linux-Kernel only if
i do not use functions to write or read the bus (XIO_out32() or XIO_in32 ()
). If I use this
I don't know MontaVista Linux, but in general these are functions provided by
Xilinx for standalone (no RTOS) operation unless MontaVista has changed them.
I would recommend that you go look at other Linux drivers to see the pattern
for I/O such as the uartlite serial driver or the xilinx_ps2.c driver. I
realize each driver already in the mainline can be different but they are
working.
I would also add some debug to print out the virtual address after the ioremap.
You aren't checking the result of the ioremap to make sure it didn't fail.
Is the ioremap bad or the I/O operation is the question.
function after registering the driver I got an error.
If I try to insert the modul with Insmod driver.ko I get a bus error!
my driver is similar to
http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021578.html
her the two importent functions of the driver:
#define REG_BASE (u32) XPAR_komponente_0_BASEADDR // defined in
xparameters_ml41x.h
#define REG_HIGH (u32) XPAR_komponente_0_HIGHADDR // defined in
xparameters_ml41x.h
#define reg0_upper(u32) komponente_SLV_REG0_OFFSET // 32-bit register /
defined in komponente.h
#define reg1_upper(u32) komponente_SLV_REG1_OFFSET // 32-bit register /
defined in komponente.h
#define reg2_upper(u32) komponente_SLV_REG2_OFFSET // 32-bit register /
defined in komponente.h
const static long remap_size = REG_HIGH - REG_BASE + 1;
static void read_register_values(void)
{
static u32 upper;
printk(%s:\n,DRIVERNAME);
printk(%s: | upper |\n,DRIVERNAME);
printk(%s:--|---|\n,DRIVERNAME);
upper = XIo_In32(reg_remapped_address + reg1_upper);
printk(%s: Daten im Register 35 |%15X |\n, DRIVERNAME, upper );
}
static int __init meintreiber_init(void)
reg_remapped_address = (u32) ioremap(REG_BASE, remap_size);
rtn = misc_register(miscdev);
if (rtn)
{
printk(%s: %s error driver not reg. \n,DRIVERNAME,
miscdev.name);
return rtn;
}
read2_register_values();
in the messeges log file i got the 3 printk lins and this line
upper = XIo_In32(reg_remapped_address + reg1_upper);
creates a error
Thank you very much for your kind help!
Schon gehört? Bei WEB.DE gibt' s viele kostenlose Spiele:
http://games.entertainment.web.de/de/entertainment/games/free/index.html
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: virtex 4 linux driver bus error
On Wed, Oct 22, 2008 at 02:10:12PM +0200, Mirsad Vejseli wrote:
hello at all,
at the moment I use development board ML410 with montavistalinux.
I have a problem, please help me!
I try to write a linux-driver for writing or reading registers.
I have a ace-file, which contents Linux and EDK-project with a component
(IP-wizard) which is added on a PLB-bus.
I also have a driver-construct which I can register (insmod driver.ko) into
the linux-Kernel only if i do not use functions to write or read the bus
(XIO_out32() or XIO_in32 () ). If I use this function after registering the
driver I got an error.
If I try to insert the modul with Insmod driver.ko I get a bus error!
my driver is similar to
http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021578.html
her the two importent functions of the driver:
Try something like this:
#define REG_BASE(u32) XPAR_komponente_0_BASEADDR // defined in
xparameters_ml41x.h
#define REG_HIGH(u32) XPAR_komponente_0_HIGHADDR // defined in
xparameters_ml41x.h
#define reg0_upper (u32) komponente_SLV_REG0_OFFSET // 32-bit register /
defined in komponente.h
#define reg1_upper (u32) komponente_SLV_REG1_OFFSET // 32-bit register /
defined in komponente.h
#define reg2_upper (u32) komponente_SLV_REG2_OFFSET // 32-bit register /
defined in komponente.h
static int __init meintreiber_init(void)
{
int rtn, upper;
reg_remapped_address = (u32) ioremap(REG_BASE, REG_HIGH - REG_BASE + 1);
if (!reg_remapped_address) {
printk(error mapping registers\n);
return -ENOMEM;
}
upper = in_be32(reg_mapped_address + reg1_upper);
printk(Data in: %.8X\n, upper);
return 0;
}
g.
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: [techfield] GPIO causing bus error
Hi Chris, I'm going to look at this problem from the FPGA hardware level because I used to work for one of the FPGA companies. I'm not familiar with your PPC440GX board, so some of my suggestions may be difficult to implement or totally unreasonable, especially if it requires soldering to an FPGA in a ball grid array or extermely fine pitch pins. (1) You should capture the configuration sequence on FPGA's JTAG pins using a logic analyzer in functional mode. In functional mode, you can capture an extermely long sequence of configuration events. Also, in the past, I've used this mode and found that when the FPGA doesn't configure, usually there are too few or too many clocks on the TCK line. (2) Sometimes, rarely, the FPGA design itself can cause a boot up problem. Instead of using the real design, send a 'blank' design with no logic implemented at all. If this works, then it's the FPGA design itself that is causing the boot problem. (3) When the boot process happens, what is the power sequence of the FPGA? Most FPGA's out there like a nice smooth power profile that ramps up quickly. Check and see if the profile is quick and smooth vs. spikey and erratic. Also, sometimes configuration data gets sent before the FPGA is ready to receive data. Try delaying the sending of configuration data by a millisecond or so. (4) Manually delay the configuration of the FPGA. In other words, let the system boot, but modify the code to allow the FPGA to configure only after a button is pushed. In theory, if the FPGA power has properply initialized the FPGA, you could keep the system this way forever until a 'button' is pushed to configure the FPGA. if this works, this tends to imply that there is a timing issue. If it doesn't work, it's possible that the FPGA's JTAG tap is actually in a state that won't allow configuration to complete, such as non shift-dr or non shift-ir state. (5) If your FPGA is using one of the SVF-based software configuration methods via JTAG, make sure you are using the latest SVF player and latest software for generating the FPGA bitstream. The configuration method may have changed. The FPGA silicon you are using may be newer than the configuration algorithm that has been implemented. I hope this helps! Regards, Bernie Elayda the ex-X guy From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wyse, Chris Sent: Friday, December 21, 2007 7:55 AM To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org; +techfield; +linux-embedded; +linux-eng; linux-kernel; Wessel, Jason; [EMAIL PROTECTED] Cc: Touron, Emmanuel; Read, Tricia; Ayer, Charles; Slimm, Rob Subject: [techfield] GPIO causing bus error Hi, I'm having trouble with an unusual problem. I'm working on relatively new hardware, so it's possible that there could be a hardware issue involved. I have an FPGA on my PPC440GX board that gets loaded via JTAG during the kernel boot process (Linux 2.6.10). It uses the 440GX GPIO lines to send the necessary JTAG commands to the FPGA to perform the initial load. This process is USUALLY functional, but on some of the boards (which we produce), the GPIO write fails with a bus error. On the boards that fail, it only occurs after a cold boot, and only if the board has been powered off for a few minutes. A quick hard reboot will not generate the problem. When I issue the failing write to the GPIO lines, some of the SDRAM gets corrupted. I don't appear to be taking any interrupts that might have corrupted the RAM. I've checked the TLB entries, and it maps correctly to the PPC register area. Additionally, I can read and write to other registers using the same TLB mapping WITHOUT any error. I can also READ the GPIO lines without an error - the error is only on the write. I've checked the SDR0_PFC0 bits to make sure everything is set properly (it is). The bus error indicates PLB Timeout Error Status Master 2, Master 2 slave error occurred (Master 2 is the write-only data cache unit (DCU)) and Write Error Interrupt Master 2, Write error detected - master 2 interrupt request is active. I'm not sure why there would be any error in the DCU, since the region I'm writing to is cache inhibited and guarded. If I issue a soft reset of the GPIO subsystem, I can read and write to the GPIO lines again. The error does not occur on the first write to the GPIO. I go through the failing routine several times before it fails. However, when it fails, it consistently fails at the same spot, after the same number of passes through the code. I'm using RGMII ethernet on EMAC2 (Group 4), but the GPIO lines that I'm using are not the Trace/GPIO lines (26-31) so I believe that they should work fine (and they usually do). Also, the errata mentions that SDR0_PFC0[G11E] has no effect - but I'm not using GPIO 11 anyway. Here are some relevant register values after the error: SDR0_PFC0 : 0x083FFE00 POB0_BESR0: 0x8400 POB0_BEARH
'mmap' memory access causes Bus Error
Hi, I got an 'Bus Error' when tried to access 'mmap' PCI memory on PPC440GX machine. I verified this behavior with D-Link Ethernet Network card and Broadcom device. I have appeneded the log for reference. But the same program works fine on i386 machine i.e. accessing 'mmap' PCI memory works fine. Any clue or solution for this problem on PPC440GX machine? Regards, Sachin Rane 8 Machine check in kernel mode. Data Write PLB Error PLB0: BEAR=0xfffe ACR= 0x9b00 BESR= 0x0080 POB0: BEAR=0x0005dfff74df BESR0=0x BESR1=0x OPB0: BEAR=0x000f7fef BSTAT=0x Oops: machine check, sig: 7 [#3] NIP: C0002420 LR: C00022C4 CTR: REGS: c020ff50 TRAP: 0202 Not tainted (2.6.16.1) MSR: 00029000 EE,ME CR: 22000484 XER: TASK = c7d63450[40] 'cdksim' THREAD: c79dc000 GPR00: C79DDF40 C7D63450 4000 0001 C785B940 7FA18498 GPR08: 0004 00029002 22000482 100AFAA0 07FF5000 007FFF3C GPR16: 0001 7FA18480 10195BA0 7FA18498 10195BB8 GPR24: 0001 30021800 7FD75C50 10047234 7FD745E0 NIP [C0002420] do_user_signal+0x8/0xc4 LR [C00022C4] ret_from_mcheck_exc+0x0/0xe0 Call Trace: [C79DDF40] [C00022C4] ret_from_mcheck_exc+0x0/0xe0 (unreliable) Instruction dump: 48182ccd 3d42 614a1002 7d400124 54290024 81290024 7128 40a2ffdc 7124 4182fc74 614a8000 7d400124 806100b0 7061 41820058 91a10044 8 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MontaVista 2.4.30 kernel support for bus error status registers on Xilinx VirtexIIPro?
Hello, I am running a 2.4.30 kernel rsynced from Monta Vista on a Xilinx VirtexIIPro FPGA. My design includes a PLB2OPB (Processor Local Bus to On chip Peripheral Bus) bridge that is capable of generating a bus error interrupt when an OPM slave device asserts it's bus error signal. The PLB2OPB bridge also has a set of bus error status and address registers that are capable of capturing information regarding the type of error that occurred. Has anyone implemented support for this functionality in a 2.4.x kernel running on VirtexIIPro FPGAs? Thanks! Keith
bus error
//test.c
#include stdio.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include sys/mman.h
int main(void)
{
static volatile char *reg_mem;
static int axs_mem_fd = -1;
axs_mem_fd = open(/dev/mem, O_RDWR|O_SYNC);
if (axs_mem_fd 0) {
perror(AXS: can't open /dev/mem);
return NULL;
}
/* memory map */
reg_mem =(volatile char*)mmap(
(caddr_t)reg_mem,
0x4,
PROT_READ|PROT_WRITE,
MAP_SHARED,
axs_mem_fd,
0x0460
);
if(reg_mem[0]==0x10) printf(OK);
else printf(sorry);
}
host:
ppc_6xx-gcc -o test test.c
target:
./test
Bus error
need help,thanks
--
?Sogou.com?2G??!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitations_EMAIL=zengshuai%40sogou.comusername=linuxppc-embeddedFullName=linuxppc-embeddedEmail=linuxppc-embedded%40ozlabs.orgverify=755eff4e640bdcfc57d93cbd8b0a9cb7
does in_be32{twi, isync} cause a bus error?
I noticed that in_be32 in 2.4.21 has been changed from 2.4.17 kernel.
In io.h in 2.4.17,
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__(lwz%U1%X1 %0,%1; eieio : =r (ret) : m (*addr));
return ret;
}
whereas io.h in 2.4.21 is,
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__(lwz%U1%X1 %0,%1;\n
twi 0,%0,0;\n
isync : =r (ret) : m (*addr));
return ret;
}
and with this in_be32, I get data machine check in kernel mode and the kernel
oops sending SIGBUS to the process.
Oops: machine check, sig: 7
NIP: C500A0A4 XER: LR: C500A090 SP: C39B7EE0 REGS: c39b7e30 TRAP: 0200
Not tainted
MSR: 9030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c39b6000[111] 'a.out' Last syscall: 3
last math last altivec
PLB0: bear= 0x acr= 0x besr= 0x
PLB0 to OPB: bear= 0x4006 besr0= 0x03c0 besr1= 0x
GPR00: C500A090 C39B7EE0 C39B6000 0056 1030 0001 0030 C019
GPR08: 22DC C501 C500D000 48000868 10019824
GPR16: 9032 039B7F40 C00049B0
GPR24: C0004720 10001240 3002A7CC 0FFEA818 7D28 0004 7D28 05050505
Call backtrace:
C500A090 C500A1F0 C0038BAC C000477C 1A38 100010F0 0FED5FDC
can someone explain me why this change was made and suggest me what I should do
to work around this problem? (don't use 'in_be32', just dereference the
pointer and eieio)
any help would be GREATLY appreciated...
Q-ha Park
- Original Message -
From: Q-ha Park [EMAIL PROTECTED]
To: linuxppc-embedded at lists.linuxppc.org
Sent: Friday, March 21, 2003 12:48 PM
Subject: kernel oops when trying to read/write the ioremapped GPIO address.
Hi,
I have a 405 based custom board (STB04), and I've been using the
2.4.17-mvl21 kernel that came with mvista
preview kit.
I wrote a gpio driver that gives userland apps to control gpio ports. (no, i
didn't use the IBM OCP gpio driver) It
simply ioremaps the gpio's physical address and read and write registers by
calling in_be32, out_be32. is this
something i shouldn't do? anyways, it worked well with 2.4.17 kernel.
however, with the kernel version 2.4.21-pre4, it oops on calling in_be32 or
out_be32. the same once happened with
the kernel 2.4.2 that also came with the monta vista preview kit.
right before the kernel oops, it gives a message, Data machine check in
kernel mode, which i didn't see before.
and NIP is at NIP; c300a0a4 [gpio_driver-dbg]__module_license+38/13c
after examining the output of ksymoops. i
don't know why it's at __module_license
not only that this driver doens't work, also a couple of other drivers (not
all) don't work (causing oops) anymore
after the kernel is upgraded to 2.4.21-pre4 from 2.4.17. it's funny that
other drivers that failed to be insmoded
are failed at __module_license..
hmmm, i'm clueless as to why this happens.. can someone help me with this?
your help would be greatly appreciated.
thanks in advance.
Q-ha Park
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
