Free Soft

I had a lot of trouble getting the LCD driver to work. Everything seems to be fine except that when I try to write to the memory address range reserved for the LCD's gamma tables, it doesn't register. It's as if some clock or some device hadn't gotten turned on or something. Therefore, after loading openiboot from iBoot, the screen gets all screwed up.

However, if you load iBEC from iBoot, the screen doesn't get screwed up: you can still use bgcolor and everything works. I thought that meant at first there was something wrong with my LCD init code. I spent a frustrating day carefully auditing it for errors, and I did find two bugs that I fixed, but unfortunately it did not have any effect on the main problem. I got as far as I could with static methods so I decided to perform a series of experiments.

First, I had some trouble chainloading iBoot and iBEC from openiboot. There was a series of fails that I fixed along the way: trouble with USB send (just a silly typo in the client), trouble getting the resulting thing to execute in memory (you've gotta turn off the CPU caches, disable MMU and interrupts for it to work properly. It also can't be run as part of an ISR because, well, iBoot expects to be able to receive interrupts, so I had to move the command processor onto the main thread and just have the ISR queue up commands for the main thread to process). Anyway, those were eventually fixed.

My experiments showed that after openiboot did its inits, chainloaded iBoot and iBEC was unable to reinit the LCD properly (they had the same problem). I narrowed the problem down to the place in power.c where I "turn off" the LCD controller. This happened in the 114 iBoot, so I thought it was necessary. Analyzing the newer 2.x iBoots, that routine was actually removed. Since I am reasonably confident that my syrah_init is functionally identical to their merlot_init and this that power init that when present, causes LCD init to fail in all cases and when absent, allows LCD init to succeed in all cases, I'm pretty sure that's the problem.

So I went ahead and removed it. This may or may not mean I am actually depending on the iBoot that I chainloaded openiboot from for the LCD init. We'll see after I try to replace iBoot entirely in the bootchain.

Anyway, USB is solid as a rock now seemingly and chainloading seems to be working quite well. I'm actually able to load iBoot from NOR, patch it in memory, and then execute it from openiboot. This probably means I'm ready to try flashing the thing again.

Then we'll see how well it truly works.

Tagi: cpu caches, memory address, lcd driver, command processor, power c, static methods, wrg, address range, mmu, syrah, bgcolor, iboot, ibec, prob, typo, queue, gamma, ace, bugs, clock

Remember we warned you to stay away from any updates to 3.1 if you want to be able to jailbreak or unlock your 3GS.

Well this is an additional message to all you 3GS owners that would like to jailbreak your device sometime soon, but this advice comes with a warning! A warning that if you accidentally upgrade to 3.1, you will not be able to use Ultransn0w, so please re-read and double check this warning at the bottom of this post before proceeding.

You may have read or heard about techniques to capture files during the iTunes restore process. These will be required to jailbreak your phone in the near future, most of the methods involve icky USB snoops. Well, there is an even better and more reliable method to get your hands on those lovely files.

During the restore process iTunes nicely keeps these oh-so-top-secret-files in a lovely accessible place for us to copy out and backup, that place? /tmp on Mac OS X or %TEMP% on Windows. Thanks Apple — handy!

The downside to this approach is that you actually need to go through the restore process to get these signed files, which has risks if you are anywhere near 3.1 or 3.1 beta :-)

If you are ready to proceed and you know the risks we’ll get down to the nitty-gritty -

So during a usual recovery with iTunes, your signed iBEC is written to /tmp and during a DFU mode restore the signed iBSS is written there also. To be sure, restore in both modes one after another to be able to grab them both. You’ll need to keep an eye on the temp directory and copy it before it is deleted again by iTunes. I’m sure some nice folks will create a tutorial about this, we’ll link to the first person who makes a good one.

Should you choose to accept this mission, act fast, this needs to be done quickly! But again, always, always double check here to see if 3.1 has been released, if is has, then don’t do this.

WARNING!! - DANGER, WILL ROBINSON! - NB! - REMEMBER!

IF YOU CARE ABOUT ULTRASN0W, BE VERY CAREFUL WITH THIS METHOD! Do not attempt this if you have downloaded the 3.1 beta. You do NOT WANT TO accidentally restore your device to 3.1 beta — you’ll lose ultrasn0w if you do! BE WARNED :-)

Update: iClarified has come up with a good picture-filled guide for doing this on a Mac and also one for Windows. Good luck!

Tagi: mac os x, check th, warning danger, temp directory, phe, downside, itunes, ibec, tmp, ace, os x, beta, modes, pers