Menu
▾
▴
ipodlinux-devel
|
From: PALFFY D. <dp...@ra...> - 2003-10-20 17:06:47
|
Hi, It seems like the ipodlinux development has slowed down a bit last months... I think it would be nice to accelerate it, since I'll reveive my new g3 ipod this week. I really want to get the kernel running on the new ipods and i will try to do it to my best knowledge, but since I haven't done much low level kernel programming, any help would be appreciated. I think the first two steps would be to revive initrd support and to look if one of the new remote pins was connected to a serial output (I can easily imagine a bigger remote with an LCD display as a future accessory). About the initrd part: Bern, do you have any of the early versions running from initrd? The CVS tree at sourceforge doesn't seem to contain anything except the stub in head-arm-ipod.S. About the serial ports: What should I try to get some 01010101 out on the serial port that I can look for with a scope? If I could boot to an initrd it would be easy, but I haven't ever tried kernel space serial programming... Or should I write a short assembly routine and boot to it directly? And some other thoughts: The current code sets the processor speed to 75MHz, but, according to the specs it should support 90. This increment should help somewhat in vorbis and mp3 decoding. Also, the 96Kb of on-chip SRAM could help. The current development of tremor to support DSPs is trying to reduce memory footprint - so if we could squeeze as much of the critical code into SRAM as possible might help a lot, especially because the main memory seems slooowwww if it only has a 16 bit bus. The slight overhead in CPU cycles should not matter, someone on the tremor development list claimed that a 30-40 MHz ARM should be able to decode vorbis if it had enough fast RAM. By the way, I couldn't find much about the memory map of the iPods. Where is the SRAM memory located? Thanks in advance for any help. PS: does anyone have the archives of the list in mailbox format? It would be nice to be able to read it offline... -- Dani ...and Linux for all. |
|
From: Gilles Boccon-G. <bo...@bo...> - 2003-10-21 01:59:22
|
I've decided to start experimenting with Linux on my iPod. I've installed the kernel and root fs, but now I'm stuck with a small problem: how to I switch off the device ? Holding "menu" and "pause" for 5 seconds allows a reboot, but is there a key combination for force a poweroff ? -- Gilles |
|
From: Bernard L. <le...@bo...> - 2003-10-21 21:59:30
|
Hi Gilles, Unfortunately you can't. The closest you can do is to boot to disk-mode which may use a little less power than in Linux mode... The current CVS version will power down the LCD after some time to reduce the power drain. Note, the normal iPod firmware implements the "power off" as a suspend function so its not a true power off. cheers, bern. On Mon, 2003-10-20 at 20:48, Gilles Boccon-Gibod wrote: > I've decided to start experimenting with Linux on my iPod. I've > installed the kernel and root fs, but now I'm stuck with a small > problem: how to I switch off the device ? Holding "menu" and "pause" for > 5 seconds allows a reboot, but is there a key combination for force a > poweroff ? > > -- Gilles > > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: Bernard L. <le...@bo...> - 2003-10-22 01:00:42
|
Hi Dani, Its great to see some revived interested in the project. Unfortunately my time is fairly limited but I'm willing to try and help out where ever possible. Reviving the initrd may indeed be a good plan - unfortunately I don't have any of the old code hanging around. It should be quite easy to get going though as there are a number of examples with the other uClinux targets using it. The full uClinux "distribution" build has a mechanism to automatically build the disk image. >From what I remember there actually isn't much more required than whats in the head-arm-ipod.S. Once you enable the compile option I think the rest of the code just switches on... As for the serial stuff doing it in the kernel may be kinda hard... however the ipod serial driver is already working so in theory if you just started up a console on the right tty line it would all work! I assume the g2 hardware has one of the UARTs IN line connected up for the remote control. I would assume the g3 has the OUT line for the same UART connected up (the other UART is used for the piezo). Unfortunately I have no idea what pin on the connector might be used (is there a dissection out there somewhere??). Other thoughts; yes the CPU is speced to go up to at least 90MHz. Cranking it up doesn't really improve performance as the problem is more that the memory is not fast enough. The 96KB of on chip ram _is_ fast enough and that does help. The problem is getting balance right between putting code/data in the fast ram and then splitting the workload between the two cpu cores. The SRAM starts at 0x28000000 the on board ram is 0x40000000. Sorry I don't have a mbox archive and it doesnt seem the mailing list software will spit one out... cheers, bern. On Mon, 2003-10-20 at 18:53, PALFFY Daniel wrote: > Hi, > > It seems like the ipodlinux development has slowed down a bit last > months... I think it would be nice to accelerate it, since I'll reveive my > new g3 ipod this week. > > I really want to get the kernel running on the new ipods and i will try to > do it to my best knowledge, but since I haven't done much low level kernel > programming, any help would be appreciated. > > I think the first two steps would be to revive initrd support and to look > if one of the new remote pins was connected to a serial output (I can > easily imagine a bigger remote with an LCD display as a future accessory). > > About the initrd part: Bern, do you have any of the early versions running > from initrd? The CVS tree at sourceforge doesn't seem to contain anything > except the stub in head-arm-ipod.S. > > About the serial ports: What should I try to get some 01010101 out on the > serial port that I can look for with a scope? If I could boot to an initrd > it would be easy, but I haven't ever tried kernel space serial > programming... Or should I write a short assembly routine and boot to it > directly? > > And some other thoughts: > > The current code sets the processor speed to 75MHz, but, according to the > specs it should support 90. This increment should help somewhat in vorbis > and mp3 decoding. > > Also, the 96Kb of on-chip SRAM could help. The current development of > tremor to support DSPs is trying to reduce memory footprint - so if we > could squeeze as much of the critical code into SRAM as possible might > help a lot, especially because the main memory seems slooowwww if it only > has a 16 bit bus. The slight overhead in CPU cycles should not matter, > someone on the tremor development list claimed that a 30-40 MHz ARM should > be able to decode vorbis if it had enough fast RAM. By the way, I couldn't > find much about the memory map of the iPods. Where is the SRAM memory > located? > > Thanks in advance for any help. > > PS: does anyone have the archives of the list in mailbox format? It would > be nice to be able to read it offline... > > -- > Dani > ...and Linux for all. > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo > The Event For Linux Datacenter Solutions & Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: Adam S. <ipo...@ad...> - 2003-10-22 13:25:11
|
Bernard Leach (le...@bo...) wrote: > On Mon, 2003-10-20 at 18:53, PALFFY Daniel wrote: > > PS: does anyone have the archives of the list in mailbox format? It would > > be nice to be able to read it offline... > > Sorry I don't have a mbox archive and it doesnt seem the mailing list > software will spit one out... There must be some way to pull out of the gmame archive to mbox format via NNTP. Does fetchnews do it? |
|
From: Adam S. <ipo...@ad...> - 2003-10-22 15:34:54
|
Adam Spiers (ipo...@ad...) wrote: > Bernard Leach (le...@bo...) wrote: > > On Mon, 2003-10-20 at 18:53, PALFFY Daniel wrote: > > > PS: does anyone have the archives of the list in mailbox format? It would > > > be nice to be able to read it offline... > > > > Sorry I don't have a mbox archive and it doesnt seem the mailing list > > software will spit one out... > > There must be some way to pull out of the gmame archive to mbox format > via NNTP. Does fetchnews do it? Apologies, I thought gmane (note previous typo) was already archiving this list but it doesn't look like it is. Now might be a good time to start ... |
|
From: PALFFY D. <dpa...@ra...> - 2003-10-23 19:18:46
|
Hi! I've got my ipod yesterday... I've just compiled a kernel with firewire support to try playing with it from linux. > Reviving the initrd may indeed be a good plan - unfortunately I don't > have any of the old code hanging around. It should be quite easy to get > going though as there are a number of examples with the other uClinux > targets using it. The full uClinux "distribution" build has a mechanism > to automatically build the disk image. > > From what I remember there actually isn't much more required than whats > in the head-arm-ipod.S. Once you enable the compile option I think the > rest of the code just switches on... Ok, thanks. I will try this in the weekend if everything goes well. > As for the serial stuff doing it in the kernel may be kinda hard... > however the ipod serial driver is already working so in theory if you > just started up a console on the right tty line it would all work! I Ok, I'll try this next week - I don't have a scope at home :( > assume the g2 hardware has one of the UARTs IN line connected up for the > remote control. I would assume the g3 has the OUT line for the same > UART connected up (the other UART is used for the piezo). Unfortunately > I have no idea what pin on the connector might be used (is there a > dissection out there somewhere??). I couldn't find it now. But IIRC I've seen one a a month ago or so, they said that the circuit inside the remote was the same, only the connector changed. But it would be nice if I knew the layout of at least the known pins on the connector. > Other thoughts; yes the CPU is speced to go up to at least 90MHz. > Cranking it up doesn't really improve performance as the problem is more > that the memory is not fast enough. The 96KB of on chip ram _is_ fast > enough and that does help. The problem is getting balance right between > putting code/data in the fast ram and then splitting the workload > between the two cpu cores. Ok, then my feeling about the normal SDRAM being slow was correct. Then still, we should look into the DSP tremor project and find out, how much memory they need, etc. I'll try this when the basic hardware is running. > The SRAM starts at 0x28000000 the on board ram is 0x40000000. Thanks. -- Dani ...and Linux for all. |
|
From: Bernard L. <le...@bo...> - 2003-10-28 21:32:14
|
The iPodding website has a picture of the disected doc connector... That might help a little. <http://www.ipodding.com/modules.php?set_albumName=album07&id=dock_con_labeled&op=modload&name=gallery&file=index&include=view_photo.php> On Thu, 2003-10-23 at 20:54, PALFFY Daniel wrote: > Hi! > > I've got my ipod yesterday... I've just compiled a kernel with firewire > support to try playing with it from linux. > > > Reviving the initrd may indeed be a good plan - unfortunately I don't > > have any of the old code hanging around. It should be quite easy to get > > going though as there are a number of examples with the other uClinux > > targets using it. The full uClinux "distribution" build has a mechanism > > to automatically build the disk image. > > > > From what I remember there actually isn't much more required than whats > > in the head-arm-ipod.S. Once you enable the compile option I think the > > rest of the code just switches on... > > Ok, thanks. I will try this in the weekend if everything goes well. > > > As for the serial stuff doing it in the kernel may be kinda hard... > > however the ipod serial driver is already working so in theory if you > > just started up a console on the right tty line it would all work! I > > Ok, I'll try this next week - I don't have a scope at home :( > > > assume the g2 hardware has one of the UARTs IN line connected up for the > > remote control. I would assume the g3 has the OUT line for the same > > UART connected up (the other UART is used for the piezo). Unfortunately > > I have no idea what pin on the connector might be used (is there a > > dissection out there somewhere??). > > I couldn't find it now. But IIRC I've seen one a a month ago or so, they > said that the circuit inside the remote was the same, only the connector > changed. But it would be nice if I knew the layout of at least the known > pins on the connector. > > > Other thoughts; yes the CPU is speced to go up to at least 90MHz. > > Cranking it up doesn't really improve performance as the problem is more > > that the memory is not fast enough. The 96KB of on chip ram _is_ fast > > enough and that does help. The problem is getting balance right between > > putting code/data in the fast ram and then splitting the workload > > between the two cpu cores. > > Ok, then my feeling about the normal SDRAM being slow was correct. Then > still, we should look into the DSP tremor project and find out, how much > memory they need, etc. I'll try this when the basic hardware is running. > > > The SRAM starts at 0x28000000 the on board ram is 0x40000000. > > Thanks. > > -- > Dani > ...and Linux for all. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: Jeffrey H. <jef...@cl...> - 2003-10-29 09:45:24
|
This may be a little off-topic (not linux related), but I am modifying the Apple firmware (menu items, bitmaps, etc.) I have copied off the 32mb partition and made changes to it as a file. Obviously the next step is loading the new image back onto the ipod. Is it simply a case of copying the new image onto the 32mb partition again, or do I have to set an update flag / modified date / firmware version somewhere so the iPod knows to reload the image? Also, if something goes wrong, how wrong can it go?!? If I kill the firmware somehow, can the ipod still connect to firewire/usb and be updated again? Cheers Jeff |
|
From: Bernard L. <le...@bo...> - 2003-10-29 19:15:32
|
Hi Jeff, When you make changes to the retailOS image you can simply copy (dd) the image back to the filesystem. However, the "image" that is booted by the iPod has a checksum and so unless you correctly patch the firmware with the checksum value the bootloader will reject your modifications. Take a look at the firmware patcher on the ipodlinux website to see how the checksum is calculated. Basically if you copy your modified retailOS portion to a file and then run the patcher on it and your full firmware image you should get something that you can dd back on and boot (assuming everything else is ok!). If it doesn't boot you can always boot the iPod into forced diskmode and then just dd your backup back onto the iPod. I assume the USB mode also works but I have only ever done this with firewire. cheers, bern. On Wed, 2003-10-29 at 23:45, Jeffrey Harris wrote: > This may be a little off-topic (not linux related), but I am modifying the > Apple firmware (menu items, bitmaps, etc.) > > I have copied off the 32mb partition and made changes to it as a file. > Obviously the next step is loading the new image back onto the ipod. > > Is it simply a case of copying the new image onto the 32mb partition again, > or do I have to set an update flag / modified date / firmware version > somewhere so the iPod knows to reload the image? > > Also, if something goes wrong, how wrong can it go?!? If I kill the firmware > somehow, can the ipod still connect to firewire/usb and be updated again? > > Cheers > > Jeff > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > iPodlinux-devel mailing list > iPo...@li... > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel > |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-04 14:12:03
|
Hi! Okay, I finally had a little time to play with the ipod... > > Reviving the initrd may indeed be a good plan - unfortunately I don't > > have any of the old code hanging around. It should be quite easy to get > > going though as there are a number of examples with the other uClinux > > targets using it. The full uClinux "distribution" build has a mechanism > > to automatically build the disk image. Here I had some problems. The vendor Makefile for the iPod to be patched into the distribution seems to generate a blkmem device image (last lines, sth like cat linuxbinary romfs > image). However head-arm-ipod seems to include an initrd. And I couldn't see how blkmem should work. > > From what I remember there actually isn't much more required than whats > > in the head-arm-ipod.S. Once you enable the compile option I think the > > rest of the code just switches on... If you have a good assembler :). The latest toolchain on the uClinux site has an assembler that doesn't support .incbin! However anything I've tried, I couldn't get the initrd mounted. Any fs I've tried to put on it says it can't find a legal filesystem. Ive tried to label an ext2 image, and print the label from the kernel, there were all zeros. May there be something clearing the memory? The fs image seems to be correctly linked into the kernel. > > just started up a console on the right tty line it would all work! I > Ok, I'll try this next week - I don't have a scope at home :( Still haven't tried this... The headphone connector is so fscking small, it's very hard to connect anything there. Does someone have a dead g3 remote? But some other details I've discovered: The disk driver seems to work fine. The problem is with firewire. If I turn on firewire, the kernel boots as long as it's connected to the firewire port (unpowered, on my laptop), but fails to boot when disconnected (freezes at the apple logo). Also, it seems to mess up the IDE controller, because with a firewire enabled kernel the controller is not detected. If I disable firewire, the hard disk and the partitions are also detected correctly. In the current state it's hard to debug firewire, because it's initialized before the framebuffer. I'll try to reverse this if noone has any idea what could go wrong... What works: keyboard (I've only used wait_for_action() to slow down the boot process), IDE, the serial ports seem to be detected (or are they hard coded?), and the fb. patch_fw works well with firmware 2.1 if the check for 1.2x is disabled. BTW, what's the second boot img? A flash updater? When does it get booted? And what's the difference between addr and loadAddr in the image structure? Is it possible to reduce the size of the first partition and make a hda3 on the end of the firmware partition? I'd hate to mess with umsdos, I'd like to make an ext[23] root there... -- Dani ...and Linux for all. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-04 19:46:17
|
Hi! > Is it possible to reduce the size of the first partition and make a hda3 > on the end of the firmware partition? I'd hate to mess with umsdos, I'd > like to make an ext[23] root there... Ok, tried this and it works fine. The first cylinder (~8MB) is enough for both the main firmware or the linux kernel and the second flash-update image. I've made hda4 from the 2nd to the 5th cylinder on the HDD, and formatted it using ext3. This setup seems to work fine with both the apple firmware and linux. So I can now boot to userspace! I've checked, the keyboard and the wheel work fine, contrast setting too. Playing an mp3 with the uClinux mp3play didn't produce any sound, but neither error messages... Do I have to unmute the mixer first? Now I'll have to fix firewire, because it's nice to be able to type llrlrlrlrlrrr on the wheel, but not much useful for debugging :) Are all these 0xcf00xxxx addresses and their functions documented somewhere? Or are they some little known black magic from the original firmware? The main difference between the g1 and g3 ipods seems to be somewhere around these GPIO pins... Thanks -- Dani ...and Linux for all. |
|
From: Bernard L. <le...@bo...> - 2003-11-04 22:17:31
|
On Tue, 2003-11-04 at 15:11, PALFFY Daniel wrote: I'll skip the initrd stuff. Seems you've got a much better solution there :) > > > just started up a console on the right tty line it would all work! I > > Ok, I'll try this next week - I don't have a scope at home :( > > Still haven't tried this... The headphone connector is so fscking small, > it's very hard to connect anything there. Does someone have a dead g3 > remote? I think the remote connector has the same connectors as the 2g iPods, I think the only difference is a re-arrangement. I remember there were some close-up pictures that showed the connectors and didn't think there were any extra contacts. > But some other details I've discovered: > > The disk driver seems to work fine. The problem is with firewire. If I > turn on firewire, the kernel boots as long as it's connected to the > firewire port (unpowered, on my laptop), but fails to boot when > disconnected (freezes at the apple logo). Also, it seems to mess up the > IDE controller, because with a firewire enabled kernel the controller is > not detected. If I disable firewire, the hard disk and the partitions are > also detected correctly. In the current state it's hard to debug firewire, > because it's initialized before the framebuffer. I'll try to reverse this > if noone has any idea what could go wrong... Thats quite interesting but also strange. I hadn't thought either had changed much but if they have it should be easy enough sort out. I will have to have a closer look at the diagnostic in v2. This may also be the reason why the 2.1 firmware doesn't boot on 2g hardware... > What works: keyboard (I've only used wait_for_action() to slow down the > boot process), IDE, the serial ports seem to be detected (or are they hard > coded?), and the fb. patch_fw works well with firmware 2.1 if the check > for 1.2x is disabled. BTW, what's the second boot img? A flash updater? > When does it get booted? And what's the difference between addr and > loadAddr in the image structure? The serial ports have fixed addresses as they are part of the P5002 chip. The second image in the boot table is the flash updater. If you get the original image from the updater program (any version) you will see that its boot table is different to what is on an updated iPod. The difference is in the updater image it has the boot table set to boot the flash loader, the last thing the flash loader does is change the boot table to boot the retailOS. I never fully reverse engineered the fields in the boot loader table. I got those names from the firmware (I think!) but I didnt work it out fully. > > Is it possible to reduce the size of the first partition and make a hda3 > on the end of the firmware partition? I'd hate to mess with umsdos, I'd > like to make an ext[23] root there... Seems so! cheers, bern. |
|
From: Bernard L. <le...@bo...> - 2003-11-04 22:26:51
|
On Tue, 2003-11-04 at 20:46, PALFFY Daniel wrote: > Hi! > > > Is it possible to reduce the size of the first partition and make a hda3 > > on the end of the firmware partition? I'd hate to mess with umsdos, I'd > > like to make an ext[23] root there... > > Ok, tried this and it works fine. The first cylinder (~8MB) is enough for > both the main firmware or the linux kernel and the second flash-update > image. I've made hda4 from the 2nd to the 5th cylinder on the HDD, > and formatted it using ext3. This setup seems to work fine with both the > apple firmware and linux. So I can now boot to userspace! I guess as long as you make it hda4 it can find everything ok. I wonder how that would go with the MAC iPods... That would certainly make the setup a lot easier. I'd imagine the updater program might get a bit confused (although maybe not...). If you have a few minutes to put together a short howto perhaps I could put it up on the website :) > > I've checked, the keyboard and the wheel work fine, contrast setting too. > Playing an mp3 with the uClinux mp3play didn't produce any sound, but > neither error messages... Do I have to unmute the mixer first? The driver should be doing everything right but I guess there may be some slightly different initialisation required there. Especially if its a different D2A chip in the g3 hardware. > Now I'll have to fix firewire, because it's nice to be able to type > llrlrlrlrlrrr on the wheel, but not much useful for debugging :) True enough. I guess the easiest should be to take a look diagnostic firmware to see how it is different between the two. I'll see if I can take a look at that for you. > Are all these 0xcf00xxxx addresses and their functions documented > somewhere? Or are they some little known black magic from the original > firmware? The main difference between the g1 and g3 ipods seems to be > somewhere around these GPIO pins... Not really documented, black magic is about right... you can get some of it out of the source and I have a few other notes but its all pretty disorganised. cheers, bern. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-04 23:26:49
|
> I guess as long as you make it hda4 it can find everything ok. I wonder > how that would go with the MAC iPods... That would certainly make the > setup a lot easier. I'd imagine the updater program might get a bit > confused (although maybe not...). I've chosen hda4 'cause there's a slight chance that when the original firmware looks at the part table and finds no hda3, doesn't continue and get confused... But the updater is another thing :) I haven't tried that. > If you have a few minutes to put together a short howto perhaps I could > put it up on the website :) A really short version: Only tested on 40g ipod, firmware 2.1. On that, the data partition begins at the 6th cylinder. Check this before proceeding! dd if=/dev/sda of=mbr.backup bs=512 count=1 dd if=/dev/sda1 of=fw_2.1.backup fdisk /dev/sda d 1 # delete first part n p 1 1 1 # new first primary, from 1st to 1st cyl a 1 # activate first (dunno if required, originally it was so) t 1 0 # set to type 0 --"-- n p 4 2 5 # new fourth primary from 2nd to 5th cyl w # write mke2fs -j /dev/sda4 dd if=/dev/sda1 of=fw_to_restore.bin cp fw_to_restore.bin fw_to_be_patched.bin Then compile in ext3, copy the root fs to /dev/sda4, set cmdline to "root=/dev/hda4 rw", patch_fw it to fw_to_be_patched, install it and enjoy! I'll write a longer version for the web later... > The driver should be doing everything right but I guess there may be > some slightly different initialisation required there. Especially if > its a different D2A chip in the g3 hardware. This was just a very quick check. I'll try to look into this when firewire works. I could help here much more if I knew the magic addresses of the chips... > Not really documented, black magic is about right... you can get some of > it out of the source and I have a few other notes but its all pretty > disorganised. Ok, then I'd really need your help in the initialization stuff... As soon as I know the mapping between the datasheets of the chips and the 0xcfxxxxxx's, I'll write more code and less email :) Thanks -- Dani ...and Linux for all. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-04 23:07:01
|
> I'll skip the initrd stuff. Seems you've got a much better solution > there :) Yes, I don't have to relink and install the kernel to update a file on the initrd... > I think the remote connector has the same connectors as the 2g iPods, I > think the only difference is a re-arrangement. I remember there were > some close-up pictures that showed the connectors and didn't think there > were any extra contacts. Sure it's different. The new remote has 8 contacts, 4 on the jack plug, and 4 on the side. The old one had only six. > Thats quite interesting but also strange. I hadn't thought either had > changed much but if they have it should be easy enough sort out. I will > have to have a closer look at the diagnostic in v2. This may also be > the reason why the 2.1 firmware doesn't boot on 2g hardware... I'd thank you very much, since I've never done any arm (dis)assembly, so it would take me much more time... > > What works: keyboard (I've only used wait_for_action() to slow down the > > boot process), IDE, the serial ports seem to be detected (or are they hard > > coded?), and the fb. patch_fw works well with firmware 2.1 if the check > > for 1.2x is disabled. BTW, what's the second boot img? A flash updater? > > When does it get booted? And what's the difference between addr and > > loadAddr in the image structure? > I never fully reverse engineered the fields in the boot loader table. I > got those names from the firmware (I think!) but I didnt work it out > fully. OK. The bootloader is in flash. It looks for some key combinations (forced firewire, fsck, diag), if any of these found, loads the appropriate image from flash, else loads the first image from the disk? Do I understand it correctly? Aren't there any more escape sequences? Or some fixed entry points into flash to do basic disk input? Because if there are, it would be much easyer to make a boot loader to load different images. -- Dani ...and Linux for all. |
|
From: Bernard L. <le...@bo...> - 2003-11-05 21:17:01
|
On Wed, 2003-11-05 at 00:06, PALFFY Daniel wrote: > > I'll skip the initrd stuff. Seems you've got a much better solution > > there :) > > Yes, I don't have to relink and install the kernel to update a file on the > initrd... > > > I think the remote connector has the same connectors as the 2g iPods, I > > think the only difference is a re-arrangement. I remember there were > > some close-up pictures that showed the connectors and didn't think there > > were any extra contacts. > > Sure it's different. The new remote has 8 contacts, 4 on the jack plug, > and 4 on the side. The old one had only six. Interesting. I thought they had dropped the extra connectors on the jack. Anyhow have any further info on this? > > Thats quite interesting but also strange. I hadn't thought either had > > changed much but if they have it should be easy enough sort out. I will > > have to have a closer look at the diagnostic in v2. This may also be > > the reason why the 2.1 firmware doesn't boot on 2g hardware... > > I'd thank you very much, since I've never done any arm (dis)assembly, so > it would take me much more time... I'll send you some stuff to try off-list. > > > What works: keyboard (I've only used wait_for_action() to slow down the > > > boot process), IDE, the serial ports seem to be detected (or are they hard > > > coded?), and the fb. patch_fw works well with firmware 2.1 if the check > > > for 1.2x is disabled. BTW, what's the second boot img? A flash updater? > > > When does it get booted? And what's the difference between addr and > > > loadAddr in the image structure? > > > I never fully reverse engineered the fields in the boot loader table. I > > got those names from the firmware (I think!) but I didnt work it out > > fully. > > OK. The bootloader is in flash. It looks for some key combinations (forced > firewire, fsck, diag), if any of these found, loads the appropriate image > from flash, else loads the first image from the disk? Do I understand it > correctly? Aren't there any more escape sequences? Or some fixed entry > points into flash to do basic disk input? Because if there are, it would > be much easyer to make a boot loader to load different images. Thats pretty much right. I don't know of any other sequences though. The fixed entry points into the flash are more likely. My original thought was to just take the existing bootloader and mod it to add in the new key sequence and then just use two boot loaders (or try and flash it in!). Thanks for the partitioning info in the other mail. I'll see if I can give it a shot in the next week or so and then update some documentation. As for the magic numbers I'll see if I can put together some cheet-sheets that cover what I have sofar. cheers, bern. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-10 15:30:44
Attachments:
ipodloader-0.0.tar.gz
|
Hi! > Thats pretty much right. I don't know of any other sequences though. > The fixed entry points into the flash are more likely. My original > thought was to just take the existing bootloader and mod it to add in > the new key sequence and then just use two boot loaders (or try and > flash it in!). Ok, the quick hack i've written about to you in private worked. I'm pleased to announce this loader. Now I can boot either the original firmware or linux. You may want to put it on sourceforge. In short the linux image is appended as a third image to the firmware, after this, a short bootloader is appended. After this the original boot table is moved to 0x3e00, and a third boot record is patched to this boot table. After this, the original first boot entry is modified to load the entire image, and the entry point of this image is set to the loader. It's nice that Apple uses such a simple checksum algorithm, otherwise this would be much harder. This part is done with a heavily modified patch_fw (in fact it's nearly entirely rewritten from scratch). The bootloader simply checks for the ffwd key, and if it's hold, it loads the third image (linux), otherwise the first (Apple image). Some parts of the code are really ugly, there are many assumptions about compiler internals, firmware internals, etc, but works with firmware 2.1. For the adventurous: please try it with other firmware and hardware revisions. But I take no responsibility at all... -- Dani ...and Linux for all. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X