From: PALFFY D. <dp...@ra...> - 2004-02-10 13:46:16
|
Hi! The problem with the 3g ipod forewire driver seems to be found. The hardware is capable to do direct DMA transfers between the firewire controller and the hard disk, and to support this, we think that the apple firmware does some interrupt setup in the firewire init routine. This kills the ide driver under linux (and is not used anyways), so it had to be removed. Quick howto: - Take the 2.4.24-uc0 kernel, and use the current ipodlinux CVS (older versions wont work). - edit arch/armnommu/mach-ipod/tsb42aa82.c: #undef IPOD_2G, and #define IPOD_3G on lines 37-38 comment out lines 1036-1038: (Bern, you might want to commit this) /* outl(inl(0xcf00000c) | (1<<7), 0xcf00000c); outl(inl(0xcf00001c) | (1<<7), 0xcf00001c); outl(inl(0xcf00002c) & ~(1<<7), 0xcf00002c); */ - build the kernel and modules and install these. On the host side you will need a 2.4 kernel (2.6 doesn't work and causes panics on the ipod!). If you have 2.4.21 or later (IIRC), put an #if 0 around the body of nodemgr_do_irm_duties() in drivers/ieee1394/nodemgr.c. Copy drivers/ieee1394/eth1394.[ch] over from the ipodlinux CVS tree into your kernel sources (the stock version doesn't work). Apply the patch from http://ipodlinux.sourceforge.net/manual.shtml to eth1394.c and build the kernel for the host. Now everything should work as described in the docs, telnet, etc work fine. -- Daniel ...and Linux for all. |
From: Robert D <ro...@op...> - 2004-02-11 08:13:44
|
As soon as i get my linux system up and running properly (i might even boot up a knoppix cd just so i can try this out :D) i will test this out. If it works i am very very very excited. Has anyone else tested the new patches? By the way, how did you find out that that is what was wrong? Robert D > ----- Original Message ----- > From: "PALFFY Daniel" <dp...@ra...> > To: <ipo...@li...> > Cc: "Bernard Leach" <le...@bo...> > Sent: Wednesday, February 11, 2004 12:46 AM > Subject: [Ipodlinux-devel] 3g firewire success > > > > > > Hi! > > > > The problem with the 3g ipod forewire driver seems to be found. > > > > The hardware is capable to do direct DMA transfers between the firewire > > controller and the hard disk, and to support this, we think that the apple > > firmware does some interrupt setup in the firewire init routine. This > > kills the ide driver under linux (and is not used anyways), so it had to > > be removed. > > > > Quick howto: > > > > - Take the 2.4.24-uc0 kernel, and use the current ipodlinux CVS (older > > versions wont work). > > - edit arch/armnommu/mach-ipod/tsb42aa82.c: > > #undef IPOD_2G, and #define IPOD_3G on lines 37-38 > > comment out lines 1036-1038: (Bern, you might want to commit this) > > /* outl(inl(0xcf00000c) | (1<<7), 0xcf00000c); > > outl(inl(0xcf00001c) | (1<<7), 0xcf00001c); > > outl(inl(0xcf00002c) & ~(1<<7), 0xcf00002c); */ > > - build the kernel and modules and install these. > > > > On the host side you will need a 2.4 kernel (2.6 doesn't work and causes > > panics on the ipod!). If you have 2.4.21 or later (IIRC), put an #if 0 > > around the body of nodemgr_do_irm_duties() in drivers/ieee1394/nodemgr.c. > > Copy drivers/ieee1394/eth1394.[ch] over from the ipodlinux CVS tree into > > your kernel sources (the stock version doesn't work). Apply the patch from > > http://ipodlinux.sourceforge.net/manual.shtml to eth1394.c and build the > > kernel for the host. Now everything should work as described in the > > docs, telnet, etc work fine. > > > > -- > > Daniel > > ...and Linux for all. > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > iPodlinux-devel mailing list > > iPo...@li... > > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
From: Bernard L. <le...@bo...> - 2004-02-10 21:33:30
|
Hey Daniel, Thanks for the testing. I've commited the fix to the iPod firewire driver now so once the public CVS server is updated (v1.6 has the fix) only the #define needs to be modified. On the server side I will see about updating the documentation shortly. But basically the host nodemgr.c needs to be patched (commenting out the do_irm_duties) and the eth1394.c driver replaced with the one from the ipodlinux CVS (this already contains the patch mentioned in the manual). cheers, bern. On Tue, 2004-02-10 at 14:46, PALFFY Daniel wrote: > Hi! > > The problem with the 3g ipod forewire driver seems to be found. > > The hardware is capable to do direct DMA transfers between the firewire > controller and the hard disk, and to support this, we think that the apple > firmware does some interrupt setup in the firewire init routine. This > kills the ide driver under linux (and is not used anyways), so it had to > be removed. > > Quick howto: > > - Take the 2.4.24-uc0 kernel, and use the current ipodlinux CVS (older > versions wont work). > - edit arch/armnommu/mach-ipod/tsb42aa82.c: > #undef IPOD_2G, and #define IPOD_3G on lines 37-38 > comment out lines 1036-1038: (Bern, you might want to commit this) > /* outl(inl(0xcf00000c) | (1<<7), 0xcf00000c); > outl(inl(0xcf00001c) | (1<<7), 0xcf00001c); > outl(inl(0xcf00002c) & ~(1<<7), 0xcf00002c); */ > - build the kernel and modules and install these. > > On the host side you will need a 2.4 kernel (2.6 doesn't work and causes > panics on the ipod!). If you have 2.4.21 or later (IIRC), put an #if 0 > around the body of nodemgr_do_irm_duties() in drivers/ieee1394/nodemgr.c. > Copy drivers/ieee1394/eth1394.[ch] over from the ipodlinux CVS tree into > your kernel sources (the stock version doesn't work). Apply the patch from > http://ipodlinux.sourceforge.net/manual.shtml to eth1394.c and build the > kernel for the host. Now everything should work as described in the > docs, telnet, etc work fine. > > -- > Daniel > ...and Linux for all. > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
From: PALFFY D. <dpa...@ra...> - 2004-02-11 14:59:47
|
Hi! > Thanks for the testing. I've commited the fix to the iPod firewire > driver now so once the public CVS server is updated (v1.6 has the fix) > only the #define needs to be modified. Thanks. I've looked at your other changes. Some comments about keyboard.c: The 3G HOLD_SWITCH_IS_ON macro has a typo - you meant &, not &&. Otherwise, the hold botton works a little bit more complicated than before. Hold on generates two interrupts - source/state: 0xX0/0xff; 0xff/0x00, where X was 4, 8 or c depending on the current wheel state. Hold off generates three: 0x20/0x20; 0xdf/0xff; 0x40/0xbf. The first interrupt from hold on won't be easy to block since it's a perfectly valid input from wheel motion, too. What does the apple firmware do? > On the server side I will see about updating the documentation shortly. > But basically the host nodemgr.c needs to be patched (commenting out the > do_irm_duties) and the eth1394.c driver replaced with the one from the > ipodlinux CVS (this already contains the patch mentioned in the manual). eth1394.c doesn't seem to contain the patch from the manual. -- Daniel ...and Linux for all. |
From: Bernard L. <le...@bo...> - 2004-02-11 16:30:56
|
PALFFY Daniel <dpa...@ra...> said: > > Hi! > > > Thanks for the testing. I've commited the fix to the iPod firewire > > driver now so once the public CVS server is updated (v1.6 has the fix) > > only the #define needs to be modified. > > Thanks. I've looked at your other changes. Some comments about keyboard.c: > The 3G HOLD_SWITCH_IS_ON macro has a typo - you meant &, not &&. > Otherwise, the hold botton works a little bit more complicated than > before. Hold on generates two interrupts - source/state: 0xX0/0xff; > 0xff/0x00, where X was 4, 8 or c depending on the current wheel state. > Hold off generates three: 0x20/0x20; 0xdf/0xff; 0x40/0xbf. The first > interrupt from hold on won't be easy to block since it's a perfectly valid > input from wheel motion, too. What does the apple firmware do? Typo fixed... thanks. As for the interrupts, the multiple interrupts are caused by incorrect processing in the keyboard driver. Could you try this patch: RCS file: /cvsroot/ipodlinux/linux/arch/armnommu/mach-ipod/keyboard.c,v retrieving revision 1.4 diff -u -r1.4 keyboard.c --- keyboard.c 11 Feb 2004 15:59:48 -0000 1.4 +++ keyboard.c 11 Feb 2004 16:25:56 -0000 @@ -63,7 +63,6 @@ /* get current keypad status */ state = inb(0xcf000030); - outb(~state, 0xcf000060); #ifdef CONFIG_VT kbd_pt_regs = regs; @@ -81,6 +80,8 @@ #ifdef IPOD_3G /* hold switch on 3g causes all outputs to go low */ /* we shouldn't interpret these as key presses */ + /* nor should we flip the interrupt levels */ + outb(state ^ 0x20, 0xcf000060); goto done; #endif } @@ -95,6 +96,8 @@ } } + outb(~state, 0xcf000060); + if ( source & 0x1 ) { if ( state & 0x1 ) { #if defined(DO_SCROLLBACK) > > On the server side I will see about updating the documentation shortly. > > But basically the host nodemgr.c needs to be patched (commenting out the > > do_irm_duties) and the eth1394.c driver replaced with the one from the > > ipodlinux CVS (this already contains the patch mentioned in the manual). > > eth1394.c doesn't seem to contain the patch from the manual. Thats right.... on the iPod side the broadcast _write_ and subsequent reply are fine but it needs to translate the incoming arp requests to look like coming from a broadcast address. On the PC side we need to make sure we don't write to broadcast addresses or the iPod pukes. I could just put that patch in eth1394.c on the iPod too, perhaps that would simplify things.... BTW The Darwin equivalent of eth1394 is open source so in theory it could be modified to be compatible with our hacked up version. Any OSX hackers out there up for a challenge? cheers, bern. |