Re: Using DMA
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote on 11/07/2008 01:46:42 PM: Whether or not using async dma is worth the effort can only be determined by profiling the code. Either it's better, or it's not. There's no real way to tell in advance. Pretty much the answer I expected :), I was just hoping that wiser and more experienced minds would say oh, well to do what you want you should go in this direction. Ah well, such is the life of a kernel hacker. So it sounds like the async dma is the way to go, since I want to off load as much as possible from the core. One thing to watch out for is an increase in interrupt latency. If the DMA grabs the bus and won't turn loose until the whole transfer is finished, your interrupts will wait along with everything else. Many DMA controllers support a cycle steal mode, which lets them get interrupted by more important things. It slows the DMA transfer down, but does less damage to the rest of the system. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using DMA
Scott Wood wrote: [EMAIL PROTECTED] wrote: In the Cafe driver, Linux Device Drivers 3rd Edition, and DMA-mapping.txt everyone talks about how to allocate buffers using dma/pci_alloc_coherent(), but no one talks about how to actually use it. I'm pretty sure (even in my ignorance) that just allocating a DMA coherent buffer and then copying in and out of it does NOT actually engage the underlying hardware and perform a DMA transfer. Does the adma stuff address this any? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Using DMA
[EMAIL PROTECTED] wrote: Bill Gatliff [EMAIL PROTECTED] wrote on 11/06/2008 10:36:58 AM: Scott Wood wrote: [EMAIL PROTECTED] wrote: In the Cafe driver, Linux Device Drivers 3rd Edition, and DMA-mapping.txt everyone talks about how to allocate buffers using dma/pci_alloc_coherent(), but no one talks about how to actually use it. I'm pretty sure (even in my ignorance) that just allocating a DMA coherent buffer and then copying in and out of it does NOT actually engage the underlying hardware and perform a DMA transfer. Does the adma stuff address this any? What is adma? Bruce ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded Asynchronous DMA. See this paper, for example: http://www.power.org/devcon/07/Session_Downloads/PADC07_Aytac_Haluk_09_13_07_layout_FINAL.pdf It looks like the structure of interest is async_tx_submit. Beyond that, I can't offer much because I haven't used it. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Proposal for a Generic PWM Device API posted on linux-embedded
Greetings, all! I just posted code to implement a Generic PWM Device API to linux-embedded. If you need them, archives of that mailing list are available at the following link (and elsewhere): http://www.mail-archive.com/[EMAIL PROTECTED]/ Previous versions of this code were posted on linux-arm-kernel, linuxppc-dev, avr32linux.org and elsewhere. It's an API that cuts across machine architectures--- not unlike the GPIO API--- and I really appreciate the constructive feedback I have received from all corners of the architecture globe. Multiple reviewers suggested that the best place to review the final code is linux-embedded, rather than cross-posting all over the place. I encourage you to submit your feedback there. I would love to see this code included in the mainline kernel at some point in the not-too-distant future. It has proven very useful to me, I think it will be useful for many others as well. Kindest regards, b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: performance: memcpy vs. __copy_tofrom_user
Dominik Bozek wrote: Hi all, I have done a test of memcpy() and __copy_tofrom_user() on the mpc8313. And the major conclusion is that __copy_tofrom_user is more efficient than memcpy. Sometimes about 40%. Have you looked at the two implementations? I'm not as well-versed on PPC as ARM, but I know the latter's __copy_* functions are optimized to be almost unintelligible. If your benchmark memcpy() implementation isn't, then you aren't comparing apples-to-apples. 40% improvement is within what I could imagine getting from a hand-crafted, no-holds-barred memcpy() implementation. I'd look more carefully at that code. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: Look around do_signal: regs-nip -= 4; /* Back up retry system call */ If your kernel has corrupted the register containing the syscall number at this point, that would explain your problem. It will then do the wrong syscall. I guess PPC only backs up one instruction. Found the code in do_signal, right where you said it would be. I threw in a printk or two to see what's up when an ERESTARTSYS is detected, and started getting OOPSes all over the place. Apparently that's not a good place for printk. :) Before I go on, can anyone confirm that gdbserver and/or strace _ever_ worked with circa 2.4.16 PPC kernels? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote: Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM lately), but it looks to me like the kernel is setting bit 0 in CR0 (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure after reading Sections 1.2 and 2.1 of the Programming Environments manual. It's not checking for restart here - userspace isn't supposed to have to. It's probably checking for error. Check for the bit of kernel code that's supposed to back you up two instructions. I don't see it in this kernel. What I see is this after the call to the syscall handler: lir10,-_LAST_ERRNO cmpl0,r3,r10 blt30f negr3,r3 cmpi0,r3,ERESTARTNOHAND bne22f lir3,EINTR 22:lwzr10,_CCR(r1)/* Set SO bit in CR */ orisr10,r10,0x1000 stwr10,_CCR(r1) 30:stwr3,GPR3(r1)/* Update return value */ bret_from_except 66:lir3,ENOSYS b22b ? -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote: Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM lately), but it looks to me like the kernel is setting bit 0 in CR0 (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure after reading Sections 1.2 and 2.1 of the Programming Environments manual. It's not checking for restart here - userspace isn't supposed to have to. It's probably checking for error. Check for the bit of kernel code that's supposed to back you up two instructions. I don't see it in this kernel. What I see is this after the call to the syscall handler: lir10,-_LAST_ERRNO cmpl0,r3,r10 blt30f negr3,r3 cmpi0,r3,ERESTARTNOHAND bne22f lir3,EINTR 22:lwzr10,_CCR(r1)/* Set SO bit in CR */ orisr10,r10,0x1000 stwr10,_CCR(r1) 30:stwr3,GPR3(r1)/* Update return value */ bret_from_except 66:lir3,ENOSYS b22b ? -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote: Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM lately), but it looks to me like the kernel is setting bit 0 in CR0 (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure after reading Sections 1.2 and 2.1 of the Programming Environments manual. It's not checking for restart here - userspace isn't supposed to have to. It's probably checking for error. Check for the bit of kernel code that's supposed to back you up two instructions. I don't see it in this kernel. What I see is this after the call to the syscall handler: lir10,-_LAST_ERRNO cmpl0,r3,r10 blt30f negr3,r3 cmpi0,r3,ERESTARTNOHAND bne22f lir3,EINTR 22:lwzr10,_CCR(r1)/* Set SO bit in CR */ orisr10,r10,0x1000 stwr10,_CCR(r1) 30:stwr3,GPR3(r1)/* Update return value */ bret_from_except 66:lir3,ENOSYS b22b ? -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote: recv(4, 0x7d60, 1, 0) = ? ERESTARTSYS (To be restarted) --- SIGIO (I/O possible) @ 0 (0) --- syscall_4294966784(0xa, 0x7d34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, That's -512, a.k.a. the errno value used by syscall restarting. I'd say your glibc does not obey the restartable syscall convention used by your kernel, and when it tries to restart the syscall the errno value is not being replaced by the syscall number. Check the assembly for recv. Very good catch! Thanks s much. Here's the code, from my libc.a: __libc_recv: 0: 94 21 ff d0 stwur1,-48(r1) 4: 90 61 00 14 stw r3,20(r1) 8: 90 81 00 18 stw r4,24(r1) c: 90 a1 00 1c stw r5,28(r1) 10: 90 c1 00 20 stw r6,32(r1) 14: 81 42 00 0c lwz r10,12(r2) 18: 2c 0a 00 00 cmpwi r10,0 1c: 40 82 00 20 bne-3c __libc_recv+0x3c 20: 38 60 00 0a li r3,10 24: 38 81 00 14 addir4,r1,20 28: 38 00 00 66 li r0,102 2c: 44 00 00 02 sc 30: 38 21 00 30 addir1,r1,48 34: 4c a3 00 20 bnslr+ 38: 48 00 00 00 b 38 __libc_recv+0x38 Again, this is 603e on linux-2.4.16 glibc-2.2.5 gcc-2.95.3. (Odd, I can't seem to find this function in a statically-linked gdbserver, nor any reference to it in the gdbserver-6.5 source code). On the kernel side: _GLOBAL(DoSyscall) ... blrl/* Call handler */ .globl ret_from_syscall_1 ret_from_syscall_1: 20: stw r3,RESULT(r1) /* Save result */ li r10,-_LAST_ERRNO cmpl0,r3,r10 blt 30f neg r3,r3 cmpi0,r3,ERESTARTNOHAND bne 22f li r3,EINTR 22: lwz r10,_CCR(r1)/* Set SO bit in CR */ orisr10,r10,0x1000 stw r10,_CCR(r1) 30: stw r3,GPR3(r1) /* Update return value */ b ret_from_except ... ret_from_except: ... lwz r3,_CCR(r1) ... mtcrf 0xFF,r3 ... RFI Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM lately), but it looks to me like the kernel is setting bit 0 in CR0 (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure after reading Sections 1.2 and 2.1 of the Programming Environments manual. Or am I misinterpreting something? I must be, this is well-trodden code I'm thinking... The readchar() in gdbserver's remote-utils.c just calls read() on the file descriptor for the socket. Still trying to track that code down... b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Gdbserver syscall clobber
Daniel Jacobowitz wrote: On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote: recv(4, 0x7d60, 1, 0) = ? ERESTARTSYS (To be restarted) --- SIGIO (I/O possible) @ 0 (0) --- syscall_4294966784(0xa, 0x7d34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, That's -512, a.k.a. the errno value used by syscall restarting. I'd say your glibc does not obey the restartable syscall convention used by your kernel, and when it tries to restart the syscall the errno value is not being replaced by the syscall number. Check the assembly for recv. Very good catch! Thanks s much. Here's the code, from my libc.a: __libc_recv: 0: 94 21 ff d0 stwur1,-48(r1) 4: 90 61 00 14 stw r3,20(r1) 8: 90 81 00 18 stw r4,24(r1) c: 90 a1 00 1c stw r5,28(r1) 10: 90 c1 00 20 stw r6,32(r1) 14: 81 42 00 0c lwz r10,12(r2) 18: 2c 0a 00 00 cmpwi r10,0 1c: 40 82 00 20 bne-3c __libc_recv+0x3c 20: 38 60 00 0a li r3,10 24: 38 81 00 14 addir4,r1,20 28: 38 00 00 66 li r0,102 2c: 44 00 00 02 sc 30: 38 21 00 30 addir1,r1,48 34: 4c a3 00 20 bnslr+ 38: 48 00 00 00 b 38 __libc_recv+0x38 Again, this is 603e on linux-2.4.16 glibc-2.2.5 gcc-2.95.3. (Odd, I can't seem to find this function in a statically-linked gdbserver, nor any reference to it in the gdbserver-6.5 source code). On the kernel side: _GLOBAL(DoSyscall) ... blrl/* Call handler */ .globl ret_from_syscall_1 ret_from_syscall_1: 20: stw r3,RESULT(r1) /* Save result */ li r10,-_LAST_ERRNO cmpl0,r3,r10 blt 30f neg r3,r3 cmpi0,r3,ERESTARTNOHAND bne 22f li r3,EINTR 22: lwz r10,_CCR(r1)/* Set SO bit in CR */ orisr10,r10,0x1000 stw r10,_CCR(r1) 30: stw r3,GPR3(r1) /* Update return value */ b ret_from_except ... ret_from_except: ... lwz r3,_CCR(r1) ... mtcrf 0xFF,r3 ... RFI Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM lately), but it looks to me like the kernel is setting bit 0 in CR0 (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0 (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure after reading Sections 1.2 and 2.1 of the Programming Environments manual. Or am I misinterpreting something? I must be, this is well-trodden code I'm thinking... The readchar() in gdbserver's remote-utils.c just calls read() on the file descriptor for the socket. Still trying to track that code down... b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Gdbserver syscall clobber
Guys: I'm trying to track down a problem where gdbserver is issuing a bogus syscall at the onset of a debugging session. I'm using gdb-6.6, on an (ancient, I know) linux-2.4.16 kernel, pc603e machine. Gcc-3.4.5, glibc-2.2.5 (both built with crosstools-0.43). Gdbserver is statically linked. When I run gdbserver under strace on the target, I see these in the log shortly after initiating the connection from my workstation: ... ptrace(PTRACE_PEEKTEXT, 947, 0x10405394, [0x103e0cb0]) = 0 ptrace(PTRACE_PEEKTEXT, 947, 0x10405398, [0x103e0ce4]) = 0 ptrace(PTRACE_PEEKTEXT, 947, 0x1040539c, [0x103e0ce8]) = 0 send(4, $103df2cc103df2e8103df2ec103df2f..., 644, 0) = 644 recv(4, 0x7d60, 1, 0) = ? ERESTARTSYS (To be restarted) --- SIGIO (I/O possible) @ 0 (0) --- syscall_4294966784(0xa, 0x7d34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4, 0, 0x1, 0x80808080, 0x1008e778, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x1008, 0x1008, 0x1008, 0x1008b5a3, 0x1008, 0x1008b320, 0x100291a4, 0xd032, 0xa) = -1 (errno 38) write(2, putpkt(read): Function not imple..., 39) = 39 ... Note the bogus syscall argument 4294966784. It isn't *completely* bogus, interestingly, since if you google for that you come up with a few hits. But no resolutions. I'm stumped. Does this problem sound familiar to anyone? Had the same problem with gcc-2.95.3. Kindest regards, b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Linux 2.6.x, MTD drivers and NAND flashes
Laurent Lagrange wrote: Hello, I use a Linux 2.6.9 on a 85xx custom board with a NAND flash. This flash has some bad blocks. NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit) Scanning device for bad blocks Bad eraseblock 8 at 0x0010 Bad eraseblock 430 at 0x035c ... Creating 1 MTD partitions on NAND 128MiB 3,3V 8-bit: 0x-0x0800 : flash partition 1. I have selected in the kernel : 1) the MTD character and block supports for NAND, 2) the CRAMFS and JFFS2 supports for NAND. I can erase the flash but receive IO errors for each bad blocks (that seems right). I can mount an empty JFFS2 partition on the NAND and untar some directories and files in it. I would like to generate some JFFS2 images and program them in the flash with a character command like cat img /dev/mtd/0. If I dont encounter a bad block, it runs right else the command fails. This is a little bit annoying. So my question is simple : Is there a MTD character driver which can detect and ignore the bad blocks in a NAND flash ? Wrong question. :) With NAND, working directly with the media is indeed a pain because of bad blocks. What's done instead is to leave that to the filesystem. Pick a NAND-aware one like YAFFS. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Compiling interrupt controller code as a module
Laurent Pinchart wrote: Hi everybody. I wrote a kernel driver for a custom bus (using arch/ppc). The hardware has a cascaded interrupt controller wired to one of the CPU interrupts. The interrupt controller IRQ handler calls __do_IRQ() to dispatch interrupts. Everything worked fine until I tried to compile the code as a module because __do_IRQ() is not exported. Is there a way to compile an interrupt controller as a module, or must it be included in the kernel ? Could you just export __do_IRQ()? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: JTAG emulator for MPC8548E (v2)
Guys: Mark A. Greer wrote: FWIW, I've had top-notch support from Abatron. Also, back when my company bought a bunch of BDI's they were around half the price of the nearest competitor and less cumbersome to use. Maybe there are cheaper alternatives now, I don't know. Obviously, YMMV. I've had excellent support from Abatron as well. I've owned one of their units for several years, bought it with my own money (which says a lot, since I'm a freelancer!). And I've brought a few obscure issues to them over the years, all of which were addressed to my satisfaction. The BDI2000 has been solid, significantly easier to setup and more reliable in use than several other systems I've tried. One thing to keep in mind is that they're really constrained by not having intimate knowledge of _your_ platform. If your memory bus configuration is wrong, for example, there isn't a whole lot that they can do to rule that out from their end since they don't have your hardware. JTAG in general gets easily tripped up with power problems, etc. that are a natural part of untested circuits. If this stuff was easy, we'd have to find work elsewhere! And no, I don't get a kickback from them... :) Me neither. But if someone from Abatron has an unused unit sitting around, I sure could use one! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
