--- Log opened Mon Jul 12 02:35:06 2010 02:35 *** TheSeven has joined #linux4nano-dev 04:02 *** Utchybann has joined #linux4nano-dev 04:53 *** Utchybann has joined #linux4nano-dev 05:05 *** Utchybann has joined #linux4nano-dev 05:09 *** TheSeven has joined #linux4nano-dev 07:48 *** fergofrog has joined #linux4nano-dev 10:56 *** watto has joined #linux4nano-dev 12:29 *** n1s has joined #linux4nano-dev 12:56 *** n1s has joined #linux4nano-dev 13:44 *** Jiss has joined #linux4nano-dev 14:30 *** TheSeven has joined #linux4nano-dev 14:41 *** stooo has joined #linux4nano-dev 15:55 *** n00b81 has joined #linux4nano-dev 16:11 *** scorche|sh has joined #linux4nano-dev 17:17 *** Utchybann has joined #linux4nano-dev 17:33 *** Inglor has joined #linux4nano-dev 18:53 *** Inglor has joined #linux4nano-dev 19:15 *** watto has left #linux4nano-dev 19:36 *** Stephen__ has joined #linux4nano-dev 20:17 *** AFtree has joined #linux4nano-dev 20:19 < AFtree> What is the difference between iBugger's loader and sram loader? 20:22 < TheSeven> while the loader normally runs from SDRAM (to load a core to SRAM), the sramloader will run from SRAM (needed for DFU) 20:22 < TheSeven> also the SDRAM isn't properly initialized at that stage of boot where the DFU exploit kicks in 20:23 < TheSeven> so the sramloader is more or less a stripped-down version we're trying to get up and running on newer generations where we don't know much about the hardware yet 20:23 < TheSeven> diff the asm files for further details 20:24 < AFtree> the sramloader worked on my classic, is this new? 20:24 < TheSeven> yes, that's great news 20:25 < TheSeven> i wasn't aware of this 20:25 < TheSeven> however, the normal loader should actually work, too, if executed through the notes exploit, so I'm a bit confused 20:25 < AFtree> is there some sort of driver so my pc will know what to do with it? 20:26 < TheSeven> yes 20:26 < TheSeven> you're using windows, right? 20:26 < AFtree> yep 20:27 < TheSeven> http://l4n.clustur.com/data/theseven/releases/iBugger%20Windows%20Driver.7z 20:32 < TheSeven> hahahahahaha 20:32 < TheSeven> look at line 27 of tools/ibugger/classic/loader/loader.asm 20:33 < TheSeven> that debugging leftover explains quite a lot :P 20:33 < AFtree> so you cac fix it? 20:34 < TheSeven> just kill that line 20:34 < TheSeven> also, the phy clock of the normal loader is wrong 20:34 < TheSeven> looks like i haven't updated that one when backporting my findings from the nano3g 20:35 < TheSeven> hm, basically forget about the normal loader 20:36 < AFtree> ok the driver is installed, what do I do now? 20:36 < TheSeven> it's full of debug crap and ancient bugs, and has exactly the same functionality as the sramloader, the only difference being the place it is executed from 20:36 < TheSeven> use ibugger.py to control it 20:36 < TheSeven> the upload/download/execute commands will probably work, but not much else 20:37 < AFtree> I don't have ibugger.py 20:37 < TheSeven> hm, it should be in the tools folder 20:40 < AFtree> OK I found it, do I have to use it in cmd? 20:41 < TheSeven> yes 20:41 < AFtree> what is the syntax? is there a file discribing how to use it? 20:42 < TheSeven> just run it, it will print a syntax summary 20:43 < AFtree> thanks 21:00 *** stooo has joined #linux4nano-dev 21:02 *** stooo has left #linux4nano-dev 21:03 *** _hans has joined #linux4nano-dev 21:07 *** _hc has joined #linux4nano-dev 21:22 *** AFtree has joined #linux4nano-dev 21:22 *** Inglor has joined #linux4nano-dev 21:23 < AFtree> Traceback (most recent call last): 21:23 < AFtree> File "D:\iPod dev\tools\ibugger.py", line 27, in 21:23 < AFtree> import libibugger 21:23 < AFtree> File "D:\iPod dev\tools\libibugger.py", line 29, in 21:23 < AFtree> import usb 21:23 < AFtree> ImportError: No module named usb 21:24 *** cmwslw has joined #linux4nano-dev 21:24 < AFtree> That is what I got when I typed ibugger.py 21:24 < AFtree> Traceback (most recent call last): 21:24 < AFtree> File "D:\iPod dev\tools\ibugger.py", line 27, in 21:24 < AFtree> import libibugger 21:24 < AFtree> File "D:\iPod dev\tools\libibugger.py", line 29, in 21:24 < AFtree> import usb 21:24 < AFtree> ImportError: No module named usb 21:26 < TheSeven> yes, you'll have to install pyusb 21:28 < cmwslw> TheSeven: when i upload the .dfu file using ipoddfu.py, does it copy the dfu file to 0x22000000? 21:29 *** Xqtftqx has joined #linux4nano-dev 21:29 *** Kebianizao has joined #linux4nano-dev 21:30 < TheSeven> yes 21:30 < TheSeven> it might eat the header though 21:30 < TheSeven> so it could be that 0x22000000 maps to 0x600 in the file or something like this 21:30 < TheSeven> let me check 21:31 < TheSeven> you're dealing with an S5L8720? 21:31 < cmwslw> yea 4g 21:32 < cmwslw> i want to write up a guide that works for every applicable gen 21:36 < TheSeven> those offsets were different across bootroms 21:38 < TheSeven> hmm 21:38 < TheSeven> on the 8720, the file maps to 0x22000000 21:38 < cmwslw> is that including the header? 21:39 < TheSeven> so you can place your code at 0x800 and pass 0x22000800 to fucc 21:42 < cmwslw> ok i'll try and get this working by tonight 21:45 < cmwslw> do you have the offsets for any other gens? 21:46 < TheSeven> the offset was probably zero for all of them, just different header sizes 21:46 < TheSeven> 0x800 should be a safe code start offset for all of them 21:46 < TheSeven> IIRC some had 0x600-sized headers 21:47 < cmwslw> but the .dfu file (including the header) is always put at 0x22000000? 21:48 *** clustur has joined #linux4nano-dev 22:05 *** scorche has joined #linux4nano-dev 22:24 < TheSeven> cmwslw: seems like that's the case 22:33 *** n1s has joined #linux4nano-dev 23:03 *** _hc has joined #linux4nano-dev 23:19 *** Jiss has joined #linux4nano-dev 23:25 *** _hc has joined #linux4nano-dev --- Log closed Tue Jul 13 00:04:37 2010