So basically, I'm screwed?
No, not at all.
But, it depends on how much effort you're wanting to put into this. There are a few options:
1 - Get dual-boot working on the iPod Classic
2 - Smash it with a hammer
3 - Give up
4 - Patch out the devices VID/PID and re-compile a build with a new VID/PID combination so things stop thinking it is an iPod.
Options 1 through 3 are either insanely difficult, rather destructive, or defeatist...so lets roll with option 4.
Basically, what is happening is that Rockbox is using the original V/PID combination:
(
/rockbox/firmware/export/config/ipod6g.h line(s) 241-242)
#define USB_VENDOR_ID 0x05AC
This is the vendor ID for Apple Inc.
#define USB_PRODUCT_ID 0x1261
This product ID tells us it is an iPod Classic 6G - which we already knew.
Some software (rightfully) sees this combination of vendor and product IDs and makes certain assumptions about it, expecting to be able to talk to the device in a very specific way. A Rockboxed iPod Classic pretty much breaks all these assumptions. The firmware partition is resized, the original firmware is not present at all, Rockbox has no IAP (iPod Accessory Protocol) support on this device (yet), there's no serial connection (yet)...like I said earlier, it pretty much isn't an iPod anymore.
There several ways to deal with this:
1 - Rockbox gets its own vendor and batch of process IDs from the
Openmoko project and uses this exclusively.
2 - Rockbox gets its own vendor and batch of process IDs from the
Openmoko project and allows the user to select between this and the original V/PID.
3 - Rockbox allows the user to provide their own arbitrary V/PID combination.
4 - Rockbox does nothing and users are required to make the required changes themselves when/if they encounter such issues.
5 - The Sun explodes making none of this relevant as man battles to survive as it is forced underground into a Matrix-style subterranean land.
In my mind, option 2 is the "right" way to handle this (...but, option 5 would be pretty cool too, except for the killer robots and all), but these things take time, and someone with a willingness to make it happen.
What we are looking at here however, is what will help you right now...and that is option number 4.
To do this, you will need to set up a Rockbox development environment to build Rockbox yourself.
The easiest way to do this is with a
Live CD/DVD/USB or a
virtual machine.
Rockbox provides a pre-built
VirtualBox Ubuntu virtual machine image you may use for this. This image comes with
git and the ARM toolchain pre-installed.
After setting up either a virtual machine or a LiveCD (If you do not use the supplied VirtualBox image or use a LiveCD, you will first need to configure the environment using the "getting started" section of our
Linux Simple Guide to Compiling) you will then need to
checkout the Rockbox source code.
However way you went about it, you should now have either a LiveCD or VirtualBox virtual machine with the required dependencies, the ARM toolchain, and the Rockbox source code and are now ready to make the changes to the source and recompile. From your git checkout of the Rockbox source repository, navigate to the small snippet of code I pointed to earlier in /rockbox/firmware/export/config/ipod6g.h (lines 241 and 242).
Now, we know we want to change the V/PID, but...what do we change it to?
Well. That's actually a tough question. Do we invent an arbitrary value? Do we use a
known value from an existing device? ...both may potentially have undesirable consequences. What I had done myself in the past (to avoid similar detection problems with an iPod and a car audio head unit) is use the V/PID of a generic USB mass storage device.
The process of finding USB V/PIDs is describes briefly
here. On linux (for instance, in your new virtual machine or LiveCD), it would look something like this:
saint@saint-desktop:~$ lsusb
Bus 001 Device 001: ID 123a:456b Imaginary Devices Inc.
In this example, the USB_VENDOR_ID is 123a, and the USB_Product_ID is 456b. These are the values you would use to replace the original values in ipod6g.h.
Now that the V/PID is changed in the device config in the source, we can
compile our build!
Assuming all went well, in a minute or so (depending greatly on the speed of your machine) you should end up with a newly compiled Rockbox binary which is a dirty, dirty liar and tells the host it is nothing more than <whatever_device_you_burgled_the_V/PID_combination_from>. Mount the device and extract this build to the root of the device (you can use your virtual machine for this - since your Mac not playing nice is the reason we're here in the first place), safely eject, and restart the device.
All going to plan, your Mac, car head units, Amarok, and a whole host of other things that rely on detecting an iPod in such a fashion should now see the device as generic removable storage and all should be well with the world.
If you get stuck at any point, don't hesitate to ask questions. Its how we learn things.
If you prefer, you may be able to get hold of myself (or others willing to help you) over at our IRC channel (#rockbox) on Freenode, there is an IRC web-client
available here. I go by the nick [Saint] there also, good luck, take care.
[Saint]
Rockbox Technical Forums
Topic: Problems with Rockboxed iPod classic (6g slim 160gb) with Mac (Read 33934 times)