Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
97 lines (73 sloc) 4.46 KB
Here's a list of things we need
This is just my personal WISHLIST. You might have different priorities. If you
want to help, just submit patches that you think are helpful. If you need ideas,
just refer to this list. Take it off the list in your patch when you finish
something off the list. I'll try to give as much help and guidance as I have
time to (which may not be much).
This is not an exhaustive list, but just stuff I think people can actually
deliver on reasonable timescales. For example, notice the conspicuous absence of
"figure out how to make phone calls". It's roughly divided based on skillset.
Jobs for C coders that may not have much RE or driver experience
1. Simplify driver code: An early goal of this project is to remain faithful to
how the iPhone firmware operates the hardware. Some of it does not actually make
sense or is otherwise not very efficient. We have a better understanding of the
hardware now and can afford to write better drivers with that understanding.
This is essentially refactoring.
2. Refactor openiboot: I'm not sure I like the way openiboot is laid out right
now. There's got to be a neater way to organize this. I'd like something that
has less messy defines and a more consistent style so it's easier to read,
perhaps individual folders for each module, and the ability to easily include or
not include any individual module. An emphasis should be put on ease of porting.
3. Add multitasking: A great project for students in or just out of OS classes.
I've been too lazy to add true multithreading primitives: mutexes, semaphores,
condition variables, and also multitasking in general. A lot of stuff is run in
interrupt contexes or interrupt-disabled contexes. Writing drivers requiring
blocking I/O is a pain. It's time for a true multitasking kernel. Should be done
in coordination with #2.
4. Write a gdb stub for openiboot: Those things are tiny and it shouldn't be
that bad. Just have it communicate over the existing USB driver now. We wouldn't
be able to debug interrupt contexts for now, but it's better than nothing.
5. Someone needs to MAINTAIN the build script for the toolchain. Or else figure
out if/how we can just build everything using Apple's or the community's iPhone
OS toolchain. I'm pretty sure we can. It's not like we use the elf wrapper
6. It might be cool to be able to parse the iPhone's own device tree for some
of base addresses. Might make porting less of a pain.
7. Implement interactive mode for new loadibec.
8. Figure out the serial mux protocol so we can have multiple DLCs. This
ought to be documented in GSM.
Jobs for people who want to get their hands dirty with drivers
1. Write a new USB driver: I hate the current one. TheSeven might have some
better code.
2. Can we steal some code from that userland bluetooth stack and put it on top
of our UART code? It might be even cleaner than USB, ironically, since we can
probably do it all without interrupts.
Jobs for reverse engineers
1. Port openiboot to unsupported platforms like ipt2g, ipt3g and iPhone 3GS.
2. Get multitouch working for Zephyr2. It's a subclass of the Zephyr1 that I
investigated, and at least some functions are shared, so it shouldn't be
3. Figure out the new FTL they're using on the newer devices. That's going to be
a pain.
4. I managed to boost the uart1 baud rate to 750000, which is half of what
ioreg advertised (though it also advertised a data width of 16). 750000 IS the
baud that CommCenter sets though, and I don't see it ever changing that, so I
don't know what's going on. at+ipr advertises as the maximum speed. Someone
check if the 16-bit data width and 1500000 baud rate is real or not or maybe
some sort of software compression?
"serial data width" = 0x10
"serial parity" = 0x1
"serial flow control" = 0x24
"serial baud rate" = 0x16e360
"serial stop bits" = 0x2
5. Reverse AppleH1CameraInterface to figure out how to get data from the camera.
6. Find out what all the various at+xdrv commands do, or at least which
systems they are related to. CommCenter probably will have some idea.
at+xdrv=0,* is speakers/sound, at+xdrv=4,* is the vibrator. 7 seems to be
triggered whenever you turn Bluetooth on, 9 seems to be bb nvram related.
What about 5 or 10? Which are also prominently featured in baseband init.
Thanks for reading all this. I'm impressed.