B0Ti: 2.6.12-rc3-mm2 is stable and you should develop against that now. 2.6.11 is bugfixes only I sorted out the kernel size problems RP: usbcore is stable on 2.6.12 as well? RP: you recommend upgrade from 2.6.11 to 2.6.12-rc3-mm2? B0Ti: I'm not sure about the status if usbcore I get a weird oops on an interrupt (insert) and I'm not sure where the problem lies. oops: http://pastebin.ca/10926 source: http://lxr.linux.no/source/drivers/usb/core/hub.c#L2079 objdump: http://siliconium.net/usbcore.objdump * B0Ti having a hard time with ARM asm B0Ti: I'll repeat again, I really doubt usb support will work on the pxa270 B0Ti: That oops is from the SL811HD usb driver. Does spitz have one of them in it? RP: ok, so should I give up porting the CFU1 usb host card pcmcia driver? RP: that's in the ratoc rex usb cf card. B0Ti: isn't that driver ported already? I thought koen did that weeks ago. B0Ti: That might be different then. I assumed you were trying to access the pxa's inbuilt usb functions pb_: tell me if it is ;) hrw: hrm... I'd be willing to do a relay thing if they still had it and it was worth it for you (no idea how much shipping would be) B0Ti: I really have no knowledge of usb cf cards though. It would assume you have a working pcmcia interface under 2.6... RP: The initial release of the sl811-hcd code had a comment that it works on pxa. B0Ti: What did you do about scoop/pcmcia code? RP: now the pcmcia glue works ok. I can insert and remove the card. It gets detected and listed under /proc/bus/usb RP: This bug happens when I plug in an usb device into the hub. mickeyl: hrw: so... any idea which libsigc++ glibmm *should* be depending on? :) How does a memory card work? B0Ti: Did you have to make many changes to get scoop/pcmcia working out of interest? RP: the pcmcia part was easy, and just needed to add a platform_device structure to pass on to the sl811-hcd driver. I also modified the sl811h a bit, pcmcia io address wasn't the same as expected for example B0Ti: You did nothing with scoop or pxa2xx_sharpsl.c? RP: nope luke-jr_: done B0Ti: That sounds extemely wrong then RP: why so? B0Ti: If you post your machine patches somewhere, I'll take a look even CVS commits are usually immidiately available... B0Ti: Sharp pcmcia access is done via these SCOOP chips they put in the device. If you aren't setting that up, I can't see any way it could be expected to work What does the scoop actually do? Surely the pxa255 deals with about 98% of the pcmcia bus on its own. RP: the old code (for 2.4) had the io/irq detection stuff in place, and it seems to work. RP: http://siliconium.net/cfu1-driver-2.6.11-20050505.tar.gz RP: not a patch though. RP: in data.py you see three 'factory' methods B0Ti: where's it crashing? B0Ti: I don't think you have any pcmcia/scoop interface setup so accessing a CF card is never going to work B0Ti: oh, right. it looks like the sl811-hcd is forgetting to set up some data structure that the core needs. can you tell what line of code in hub.c it's crashing at/ s:/:?: pb_: that's what I don't know how to do on arm. B0Ti: if you have a kernel with debug info, you can probably use gdb or addr2line, just like on any other platform. if not, you'll have to disassemble the code and match it up with the oops. pb_: I have disassembled it, but still couldn't figure out the line number yet. http://siliconium.net/usbcore.objdump pb_: I'll need to set up the kernel to use usb-serial as the console, if that's possible. I don't have a normal serial cable. zecke: ok, thanks. I was thinking the cow patch did something a bit different from what it does :) B0Ti: can you do a dissassembly with relocs included (objdump -dr)? pb_ For a start, scoop controls power to the card pb_: updated with -dr -> http://siliconium.net/usbcore.objdump RP: no, but I certainly haven't seen anything to suggest that it can't. pb_: It doesn't need power then? RP: it does, but clearly the power is enabled since the device is being detected correctly. and, if it detects a hub being plugged in, the HCD itself must also be running. pb_: There's also some interrupt control in scoop pb_: sorry I made a typo in the filename, this should be ok: http://siliconium.net/usbcore.objdump.dr ah, that's more like it RP: When I connect a USB device (my camera) it sees the connection, so there is power. RP: also I ported a register test routine from the old drivers, and it passes too. oh, heh, it looks like udev->bus->controller->driver->name is probably NULL. that'd be a bit dumb. B0Ti: fair enough, if it works, go for it. I remain sceptical though ;-) pb_: thanks, I thought I did that, but that was only for the bus_name RP: if there is interrupt control in the scoop, that might pose some problems. We'll see ;) B0Ti: I think your irqs are probably working if it can detect peripheral in/out events. pb_: that's good to know. Can you tell me how you figured out udev->bus->controller->driver->name from the objdump? offroadgeek: loadkeys flip_flop_madmess? B0Ti: well, it was mostly a guess. but, if you look at the code, udev arrives in r1 and then gets shuffled into r6. then it does r2=*(r6+64); r3=*(r2); r1=*(r3+112); ip=*(r1), and the last load is the one that crashes. yeah so obvious ~hail pb_ * ibot bows down to pb_ and chants, "I'M NOT WORTHY!!" also, if you look at that big printk() call, the value that it was attempting to load is what it would have used as the second-to-last argument. pb_: thanx, it'll take some time till I can think in arm asm this fast, last time I coded in asm was for 286 =) heh java made me forget all that too :) fuck me. it works. ~hail pb_ * ibot bows down to pb_ and chants, "I'M NOT WORTHY!!" http://pastebin.ca/11067 need to test transfers though. B0Ti: no heureka? fuck me instead? this youth... B0Ti: ah, very good hehe, I can plug the usb cable from the z into itself (into the usb cf card), and get a usb0 interface. This is a real loopback device!! hehe B0Ti: I can't even plug it from my Z into my desktop and get it to work :(