Menu
▾
▴
ipodlinux-devel
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(9) |
Mar
(21) |
Apr
(12) |
May
(11) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
(10) |
Oct
(20) |
Nov
(32) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(48) |
Feb
(27) |
Mar
(120) |
Apr
(69) |
May
(15) |
Jun
(1) |
Jul
(6) |
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
(2) |
Dec
(4) |
| 2005 |
Jan
|
Feb
(10) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
(3) |
Feb
(4) |
Mar
(9) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ben <ro...@no...> - 2003-11-19 13:04:36
|
Hello all, Just received my beutiful little iPod, acktually a week ago, one of the 3rd generation 40 GB versions. Looks nice, good batery time, and I have to admit the wheel is a grand idea, as I am certain you all know that the neatness of all these things are canceld out by the crapy idea of using this Music match box system. They should have lernt from arcos and just used a simple mp3 player with a file system interface, not the database (dont know exactly how it works, havent had time to look at it), so off cause I am going to install the Linux version, acktually not only because I find theire interface solution idiotic, but because I can, or can I. Read somthing about G3 kernel being a bit strange, tried to check it before I bought the machine, but never managed to find anything about it, and just wanted to check that I understod it correctly from dear mister Bernard Leach comment. > Note, although this bootloader will run on the newer iPods the Linux > kernel still doesn't boot correctly there (if you disable firewire it > probably works a little bit though :). And I know that I should have looked a bit longer to try to find assurance that it supports the 3 generation versions. But at least I have somthing to play with now :) Regards Ben Bernard Leach writes: > > Hi all, > > just a short note to announce the "official" release of the iPod boot > loader. After some great work by Daniel we've managed to get a stable > and workable bootloader that allows you to selectively boot either the > Apple or the Linux firmware. Not only that but I've included a simple > image display to bring Tux back to your iPod! > > <http://sourceforge.net/project/showfiles.php?group_id=73079> > > Note, although this bootloader will run on the newer iPods the Linux > kernel still doesn't boot correctly there (if you disable firewire it > probably works a little bit though :). > > cheers, > bern. > > > > > ------------------------------------------------------- > 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: Bernard L. <le...@bo...> - 2003-11-18 22:10:57
|
Hi all, just a short note to announce the "official" release of the iPod boot loader. After some great work by Daniel we've managed to get a stable and workable bootloader that allows you to selectively boot either the Apple or the Linux firmware. Not only that but I've included a simple image display to bring Tux back to your iPod! <http://sourceforge.net/project/showfiles.php?group_id=73079> Note, although this bootloader will run on the newer iPods the Linux kernel still doesn't boot correctly there (if you disable firewire it probably works a little bit though :). cheers, bern. |
|
From: David P. <dpi...@ma...> - 2003-11-12 05:22:47
|
Just thought you'd like to know that I also had success installing the bootloader. It worked with both firmware versions 1.22 and 2.1. It took me a while because the compiler I was using had some trouble with the while loop that traverses through the command line options. I had to compile it on a redhat machine instead of yellowdoglinux, and then it worked fine. Very cool! I'm still having trouble with accessing the root filesystem. I'll try doing everything from scratch again and see if I can't get it to work. Thanks for the tip on porting the kernel. I suppose I'll leave that to the experts to hammer out. I thought it would be good to have, but I suppose it'll come soon enough. Dave |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-11 21:54:21
|
Hi! > Ok, just tried that with my 2nd generation iPod and it all worked fine! Nice. I hoped they're similar enough to work with this loader. > One note, in the HOWTO: > > "6. Copy it back to the iPod. The file will be only the required size. > This > is about 4.5 MB for the 2.1 Apple sw and one linux image. > > $ sudo dd if=firmware.bin of=/dev/sda1" > > This should say if=my_sw.bin not if=firmware.bin. Thanks, I'll correct it. There are typos, too. And some bugs in the c code that don't appear with my gcc 2.95.3 but might appear with a different gcc or different optimizations, mostly regarding the last assembly bx. entry should be a global bound to a specific register. That way the bx could use a fixed register and would be no danger of the generated code trying to read entry again from (already overwritten) memory. Or the entry address could be written to somewhere in the sram and loaded after memmove again. > Regarding the 2.6 kernel. I think it should be a really good kernel for > embedded devices but at the moment without the armnommu port its not > really practical. Or rather, I'd prefer to spend my time directly on > the iPod stuff and leave the armnommu stuff to the arm gurus ;) That's what I think, too. -- Dani ...and Linux for all. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-11 21:45:04
|
On Tue, 11 Nov 2003, Bernard Leach wrote: > That reference in the bootloader is for the pdisk command which I would > assume to be a command to partition the disk. Its not called by the > startup. I can't see any other references to it in the bootloader... Dunno, haven't looked at it much. However with an empty first sector I get the folder icon. I still think there's something between 0x100 and 0x110. There are some non-zero bytes that don't yet make me much sense. > > PS: I should really read ARM documentation before writing a boot loader... > > It's really funny to find out the hard way that the address of the > > current instruction is (pc & ~3) - 8 > > :) > > <http://www.arm.com/techdocs.nsf/html/ARM7Docs> > > The one called ARM7TDM_Rev4.pdf covers pretty much everything you need > to know. I know, I was just lazy to read all of it... -- Dani ...and Linux for all. |
|
From: Bernard L. <le...@bo...> - 2003-11-11 21:24:06
|
Ok, just tried that with my 2nd generation iPod and it all worked fine!
One note, in the HOWTO:
"6. Copy it back to the iPod. The file will be only the required size.
This
is about 4.5 MB for the 2.1 Apple sw and one linux image.
$ sudo dd if=firmware.bin of=/dev/sda1"
This should say if=my_sw.bin not if=firmware.bin.
Regarding the 2.6 kernel. I think it should be a really good kernel for
embedded devices but at the moment without the armnommu port its not
really practical. Or rather, I'd prefer to spend my time directly on
the iPod stuff and leave the armnommu stuff to the arm gurus ;)
On Tue, 2003-11-11 at 20:07, PALFFY Daniel wrote:
> On Mon, 10 Nov 2003, David Piasecki wrote:
>
> > Dani,
> >
> > That's terrific that you got a bootloader working! After reading the
> > list archives more carefully, now I think I see why my install wasn't
> > working. I didn't disable the firewire.
>
> Please try the next version too, it should be much better.
>
> > Kind of a side note to what you guys are working on, but I'd like to
> > attempt an update of the kernel to version 2.6. The latest uClinux
> > patch (2.6.0-test4) does not have the armnommu supported. Can you offer
> > any advice with regard to what is involved in porting uClinux for the
> > 2.6 kernel to the g3 iPod?
>
> I didn't look at it yet. Even if we had an armnommu patch for 2.6, we
> should convert many drivers to new APIs... So I think it's not for the
> faint of heart... I know the framebuffer, the input layer and soundcard
> support has changed much. Also, you should look at the generic parts of
> {arch/,include/asm-}m68knommu to have an ide about what the generic arch
> stuff changed.
>
> > Also, how are you able to look at the firmware? It just seems like a
> > binary file to me, but I assume there is some way to take a look inside
> > if you guys are able to look at it for clues.
>
> Take the part of the binary you want to look at (using dd), and
> $ arm-elf-objdump -D -b binary -m arm -z binary_file
> to see the assembly dump.
>
> --
> Dani
> ...and Linux for all.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
>
|
|
From: Bernard L. <le...@bo...> - 2003-11-11 21:03:54
|
Hi Dani, On Tue, 2003-11-11 at 18:59, PALFFY Daniel wrote: > > > I think you can just re-write the boot table completely though (e.g without > > caring for the flashupd image). If you want to update the flash then dd in > > the original and run the updater.exe... Assuming people screw up and don't > > save a backup I think the updater.exe does the equivalent of a dd anyhow. > > Ok, I'm doing this. However the first 512 bytes still have to be copied in > from an original firmware. Do you know the meaning of those few bytes at > 0x100? The text before doesn't seem to be important, but the first dword > seems to be some magic number (it's included as a literal in the loader > right after 0x55aa - the PC boot sector magic. I haven't disassembled it > further yet). The other values seem to be required, too. That reference in the bootloader is for the pdisk command which I would assume to be a command to partition the disk. Its not called by the startup. I can't see any other references to it in the bootloader... > > Anyhow I'll take a look see in a few hours and see about giving it a whirl. > > Try this instead! > > Oh, I've nearly forgotten: This version can load up to 5 images, any of > which can be the default, the others are load for the four keys on the top > (or around the wheel). > > PS: I should really read ARM documentation before writing a boot loader... > It's really funny to find out the hard way that the address of the > current instruction is (pc & ~3) - 8 :) <http://www.arm.com/techdocs.nsf/html/ARM7Docs> The one called ARM7TDM_Rev4.pdf covers pretty much everything you need to know. cheers, bern. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-11 19:07:48
|
On Mon, 10 Nov 2003, David Piasecki wrote:
> Dani,
>
> That's terrific that you got a bootloader working! After reading the
> list archives more carefully, now I think I see why my install wasn't
> working. I didn't disable the firewire.
Please try the next version too, it should be much better.
> Kind of a side note to what you guys are working on, but I'd like to
> attempt an update of the kernel to version 2.6. The latest uClinux
> patch (2.6.0-test4) does not have the armnommu supported. Can you offer
> any advice with regard to what is involved in porting uClinux for the
> 2.6 kernel to the g3 iPod?
I didn't look at it yet. Even if we had an armnommu patch for 2.6, we
should convert many drivers to new APIs... So I think it's not for the
faint of heart... I know the framebuffer, the input layer and soundcard
support has changed much. Also, you should look at the generic parts of
{arch/,include/asm-}m68knommu to have an ide about what the generic arch
stuff changed.
> Also, how are you able to look at the firmware? It just seems like a
> binary file to me, but I assume there is some way to take a look inside
> if you guys are able to look at it for clues.
Take the part of the binary you want to look at (using dd), and
$ arm-elf-objdump -D -b binary -m arm -z binary_file
to see the assembly dump.
--
Dani
...and Linux for all.
|
|
From: PALFFY D. <dp...@ra...> - 2003-11-11 18:10:01
|
Again, with attachment :) -- Dani ...and Linux for all. |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-11 17:59:45
|
Hi! > Yeah I think those few optimisations would make things a little less painless. > In fact it would be nice to be able to switch either the Linux or the Apple > firmware first so you could choose your default for load speed :) Ok, here's the next version. It's optimized enough for our needs I think. It loads from 0x4400, so the first image doesn't have to be moved. However moving is optimized now, too. > I think you can just re-write the boot table completely though (e.g without > caring for the flashupd image). If you want to update the flash then dd in > the original and run the updater.exe... Assuming people screw up and don't > save a backup I think the updater.exe does the equivalent of a dd anyhow. Ok, I'm doing this. However the first 512 bytes still have to be copied in from an original firmware. Do you know the meaning of those few bytes at 0x100? The text before doesn't seem to be important, but the first dword seems to be some magic number (it's included as a literal in the loader right after 0x55aa - the PC boot sector magic. I haven't disassembled it further yet). The other values seem to be required, too. > The best location for the stack is 0x40000000+stack_size. Thats the fast ram. Ok, done. > I haven't looked at the arm memmove in Linux but something using the > ldmia/stdmia and 4 or more registers should be pretty quick :) I've converted the memmove to move multiplies of 16 bytes (all images are aligned to sector boundaries, so it doesn't hurt), this is optimized to ldmia/stmia by gcc, and seems to be much faster than the original version. > Anyhow I'll take a look see in a few hours and see about giving it a whirl. Try this instead! Oh, I've nearly forgotten: This version can load up to 5 images, any of which can be the default, the others are load for the four keys on the top (or around the wheel). PS: I should really read ARM documentation before writing a boot loader... It's really funny to find out the hard way that the address of the current instruction is (pc & ~3) - 8 -- Dani ...and Linux for all. |
|
From: David P. <dpi...@ma...> - 2003-11-11 07:37:30
|
Dani, That's terrific that you got a bootloader working! After reading the list archives more carefully, now I think I see why my install wasn't working. I didn't disable the firewire. Kind of a side note to what you guys are working on, but I'd like to attempt an update of the kernel to version 2.6. The latest uClinux patch (2.6.0-test4) does not have the armnommu supported. Can you offer any advice with regard to what is involved in porting uClinux for the 2.6 kernel to the g3 iPod? Also, how are you able to look at the firmware? It just seems like a binary file to me, but I assume there is some way to take a look inside if you guys are able to look at it for clues. Thanks, Dave |
|
From: PALFFY D. <dpa...@ra...> - 2003-11-10 15:30:44
|
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. |
|
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-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-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: 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: PALFFY D. <dpa...@ra...> - 2003-11-04 19:58:58
|
Hi! > I've noticed that the current version of the audio driver only supports > 44100kHz, 16 bits, stereo. Is this because the DAC chip only supports > this, or because the driver does not yet support changing the format ? > If there is enough doc on the chip, I could work on the driver to add > support for it. Is that documentation available ? AFAIK the chip (at least that of the new ipods) supports quite everything up to 96kHz, so it should be a driver issue. Also, probably the driver won't support recording, that the new ipods do. The documentation for the Wolfson WM8721 (old ipods) is at http://www.wolfsonmicro.com/products/digital_audio/dacs/WM8721/ , for the WM8731 (new ipods) at http://www.wolfsonmicro.com/products/digital_audio/codecs/WM8731/ . -- 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: 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: Gilles Boccon-G. <bo...@bo...> - 2003-11-03 22:18:20
|
I've noticed that the current version of the audio driver only supports 44100kHz, 16 bits, stereo. Is this because the DAC chip only supports this, or because the driver does not yet support changing the format ? If there is enough doc on the chip, I could work on the driver to add support for it. Is that documentation available ? -- Gilles |
|
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: 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-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: Bernard L. <le...@bo...> - 2003-10-28 21:23:51
|
Good work on getting things up and running. I think your best bet is to look at Microwindows. It is already running on some uClinux targets and is actually a part of the uClinux distribution. To get it running on the iPod you will need to write a "microwindows graphic driver" which will put the screen updates on the screen. Just take a look at the existing drivers and it should be fairly easy. Microwindows will also run on your desktop Linux box so you can write test programs there and then simply recompile for the iPod! cheers, bern. On Tue, 2003-10-28 at 04:43, dj...@ca... wrote: > HI. > > I am working with 2 other OS students on either porting or designing a GUI for the iPod and today we successfully booted our iPod with the Linux kernel(yeah!!!). Currently, we are trying to figure out what exactly does not work with the mmap() call that writes to the framebuffer. From what I read on the ipodlinux site, this would limit the use of X Windows. So my questions are ... > > - Should we look into hacking mmap() so that it will function properly with the framebuffer? Or is there a workaround to this problem that we as NEWBIES are not aware off? > > - How much will the framebuffer issues affect us if we try to design our own GUI? > > - Bernard mentioned looking into alternatives like porting MicroWindows or GTK++, how could we get started on this? > > - I looked at the fbcon.c and fbmem.c files in the CVS tree ... am I on the right track? > > Any technical suggestions would be great! > > Thanx. > ant > > > > ------------------------------------------------------- > 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 > |
5 messages has been excluded from this view by a project administrator.
