--- Log opened Wed Aug 11 00:07:23 2010 00:07 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #freemyipod 00:07 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Remote host closed the connection] 00:17 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 00:25 < angelwolf71885> GUID's are the apple API's right? for access ing diffrent HW i just saw the new section on the wiki and was curios 00:39 < angelwolf71885> or is it just the HW regasters? 01:04 < Farthen> anyone of you already tried out libusb 1.0 on windows with pyusb? i can not get it to work 01:08 < user890104> is it ported? 01:09 < Farthen> http://www.libusb.org/wiki/windows_backend 01:37 < fmibot> New commit by 3theseven (r89): Fix Nano2G flash bug and add boot-time application loader 01:37 < fmibot> r89 build result: Red for targets ipodnano4g 01:40 < fmibot> New commit by 3theseven (r90): Commit forgotten files 01:40 < fmibot> r90 build result: All green! 01:49 < fmibot> New commit by 3theseven (r91): Remove unused main.c file and add target-specific CFLAGS/LDFLAGS 01:49 < fmibot> r91 build result: All green! 01:56 -!- KnockMock [5f73b03b@gateway/web/freenode/ip.95.115.176.59] has joined #freemyipod 01:56 < KnockMock> blurb 01:56 -!- KnockMock [5f73b03b@gateway/web/freenode/ip.95.115.176.59] has quit [Client Quit] 01:56 < fmibot> r89 build result: Red for targets ipodnano4g 01:57 < fmibot> r89 build result: Red for targets ipodnano2g, ipodnano4g, ipodnano4g 01:58 < fmibot> r89 build result: Red for targets ipodnano2g, ipodnano4g 01:58 < Farthen> aaah, finally ;) 01:58 * TheSeven throws a cobblestone at fmibot 02:01 < Farthen> fmibot is immortal 02:09 < fmibot> r91 build result: All green! 02:09 < Farthen> ok, great 02:11 < user890104> hey guys, i suggested moving the source files into dirs such as src and include, what do you think about it? 02:32 < Farthen> why? everything is src 02:36 < fmibot> New commit by 3theseven (r92): Expose execimage() via USB 02:36 < fmibot> r92 build result: All green! 02:37 < TheSeven> some things certainly need to be cleaned up in the source, but I don't think splitting headers and C files is a very good idea 02:54 < user890104> could someone merge to trunk the patch for libembios.py that i provided 03:16 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 05:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 05:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod 08:34 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod 09:34 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod 09:51 < benedikt93> user890104, gonna fix libembios ;) 09:53 < fmibot> New commit by 3benedikt93 (r93): fix libembios.py typos (thx slck) 09:54 < fmibot> r93 build result: All green! 10:28 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Lämnar] 10:44 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has quit [Read error: Connection reset by peer] 10:44 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has joined #freemyipod 10:56 < fmibot> New commit by 3benedikt93 (r94): add execimage command to libembios.py/embios.py 10:56 < fmibot> r94 build result: All green! 11:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 11:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod 11:02 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 11:04 < Farthen> approaching r100... 11:16 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 11:16 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 11:17 < angelwolf71885> yah at this rate we will reach r100 before the end of the day haha 11:31 -!- benedikt93 is now known as benedik93|AFK 11:35 -!- perror [~fleury@aldebaran.labri.fr] has joined #freemyipod 11:45 -!- benedik93|AFK is now known as benedikt93 12:28 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 13:45 < TheSeven> anybody around do double check some flashing code before i try it? 13:45 < TheSeven> http://pastebin.com/VbgsnLpG 13:45 < TheSeven> to* 13:49 < TheSeven> this wiki page is becoming too big. firefox is lagging terribly when trying to edit it 13:53 < GaveUp> presumably not a bug since it's in there twice but how existly do those whiles break out if offset doesn't change value? (Yes I am THAT rusty) 13:55 < GaveUp> ah ok i see what you're doing 13:55 < GaveUp> feel free to smack my upside the head 13:55 < TheSeven> benedikt93: there's work! 13:55 < TheSeven> http://www.freemyipod.org/wiki/EmBIOS_Monitor_Protocol#22:_Read_raw_boot_flash 13:57 < GaveUp> well that wiki article has an issue ... 22 and 23 boot say read but 23 descriibes write 13:57 * TheSeven is always doing that. damn copy paste crap 13:58 < GaveUp> keep doing it .... makes it easier to blame my confusion on something other than just being stupid ;) 14:12 < fmibot> New commit by 3theseven (r95): Add support for accessing the boot flash on Nano2G 14:12 < fmibot> r95 build result: All green! 14:16 < fmibot> New commit by 3benedikt93 (r96): add commands 22 & 23 to libembios.py and embios.py 14:16 < fmibot> r96 build result: All green! 14:24 < TheSeven> benedikt93: I'm still wondering what to pass to writedevconsole direct ... (haven't looked at the source yet) 14:24 < TheSeven> oh and you're using decimal number parsing for the readrawbootflash command 14:25 < benedikt93> eg. writedevconsole direct 0x12345678 0x9abcdef0 ... 14:25 < TheSeven> what is that supposed to do? 14:25 < TheSeven> i would have rather expected a string argument 14:25 < benedikt93> write the integers 0x12345678 0x9abcdef0 to the console 14:26 < benedikt93> I could also implement it with a string arg 14:26 < benedikt93> I didn't know what consoles that are, so I thought it might be more useful to be able to write raw binary data 14:27 < TheSeven> things like the LCD 14:27 < benedikt93> ah, ok 14:28 < benedikt93> I'll add a string arg with the next commit 14:29 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has quit [Ping timeout: 248 seconds] 14:29 < benedikt93> "TheSeven> oh and you're using decimal number parsing for the readrawbootflash command": not again 14:29 < TheSeven> what's the transfer size boundary when it'll start using dma btw? 14:29 < benedikt93> had to change that over the whole file yesterday 14:29 < TheSeven> a quick glance at the code suggested 0x1f which is a bit small 14:30 * TheSeven would suggest > 2 * (command pipe packet size - 16) 14:30 < TheSeven> for everything smaller than that DMA will be slower than command pipe transfers 14:32 < benedikt93> it's not 1f, actually it always uses dma when size is larger than 0xf 14:33 * benedikt93 is going to implement an additional check for that 14:34 * TheSeven suggests just using up to (command pipe packet size - 17) bytes for the "alignment head" packet 14:34 < TheSeven> (and the same goes for the tail) 14:34 < TheSeven> if there is some data left to be transferred in between, use DMA if it's more than (command pipe packet size - 16) 14:35 < TheSeven> oh wait, two times that 14:35 < TheSeven> everything below that size won't be efficient using DMA 14:38 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has joined #freemyipod 14:38 < TheSeven> oh, this is getting complicated... 14:38 < TheSeven> user890104: slck, huh? 14:38 < user890104> yep, found out that the other nickname is taken by someone else 14:39 < user890104> so i'm stick to the wiki one 14:40 * TheSeven wonders if user890104: is 21.7 years old :P 14:40 < user890104> exactly :) 14:44 < TheSeven> hm, slck isn't in use currently and hasn't been used by its owner for more than a year 14:44 < TheSeven> however, he seems to have been around with another nickname associated to the same user some days ago 14:45 < TheSeven> you might want to go to #freenode and ask if that nickname registration could be dropped 14:45 < user890104> i got a message that it's registered by someone else and to enter a password 14:46 < user890104> okay, thanks 14:46 < TheSeven> it has been registered for more than two years, so you should have gotten that message all the time 14:46 < user890104> yes, but i didn't noticed it 14:49 < GaveUp> Last Quit Time: ... (6y 4m 20d 22:17:19 ago) ... how's that for stupid never expiring nicks! >:| 14:49 < benedikt93> after 60 days you can ask staff to "unregister" it 14:50 < TheSeven> if they agree to drop it (dunno what the policy is, IIRC unused for like half a year), register it yourself. type "/msg nickserv help register" for detailed instructions 14:50 < GaveUp> benedikt93: diff network 14:50 < GaveUp> + I'm lazy :P 14:54 < fmibot> New commit by 3benedikt93 (r97): tweak libembios.py and fix embios.py 14:54 < fmibot> r97 build result: All green! 14:54 < benedikt93> should now use dma only when really needed 15:20 < fmibot> New commit by 3theseven (r98): Make the location of the boot information table a bit more predictable 15:20 < fmibot> r98 build result: All green! 15:22 < TheSeven> hmm already 56KB binsize, 330KB ramsize on nano2g 15:34 < benedikt93> just a question: is it correct that 15:34 < benedikt93> MOV R2, R1,ASR#31 15:34 < benedikt93> ADD R2, R1, R2,LSR#30 15:34 < benedikt93> BIC R2, R2, #3 15:34 < benedikt93> would be the same as 15:34 < benedikt93> BIC R2, R1, #3 15:34 < benedikt93> ? 15:35 < TheSeven> no, this is something weird 15:36 < TheSeven> the upper one is R2 = R1 + (R1 & 0x80000000) + ((R1 & 0x80000000) >> 1) 15:37 < TheSeven> R2 = (R1 + (R1 & 0x80000000) + ((R1 & 0x80000000) >> 1)) & ~3 15:37 < TheSeven> oh wait, lsr not ls 15:37 < TheSeven> lsl* 15:37 < TheSeven> wtfh 15:38 < TheSeven> is this some kind of remainder function? 15:38 < GaveUp> wtfh ... unknown opcode 15:38 < benedikt93> I don't really know what it is exactly 15:38 < benedikt93> it's used when calculating an address 15:39 < TheSeven> if (r1 < 0) r2 = r1 & ~3; else r2 = (r1 + 3) & ~3; 15:39 < benedikt93> R1 seems to be some offset 15:39 < TheSeven> so it's rounding up to an 8 byte boundary if positive, and down if negative 15:40 < TheSeven> can you provide a bit more context where this is coming from? 15:42 < benedikt93> this is what I want to find out^^ it's after the header is loaded from norflash, in a subroutine which seems to be initializing the crypto or maybe even decrpt some stuff 15:43 < TheSeven> in the s5l8702 rom? which address? 15:43 < benedikt93> before that weird code, it checks if R1 is 4byte aligned 15:43 < benedikt93> 200021C8 15:44 < benedikt93> it's two subroutines down from exception_2c 15:45 < TheSeven> this is doing Weird Things(tm) 15:45 < TheSeven> interesting way to decrement the stack pointer ... 15:45 < benedikt93> which is called with R0 = address of header in ram and R1 = 2 from the firmware loading function 15:46 < TheSeven> judging from the loop frame, i'd say that R1 is the address of Something(tm) and R2 is its size 15:47 < benedikt93> r4 might be some length 15:48 < TheSeven> let's try to rewrite that in C 15:49 < TheSeven> int dosomething(int retval, void* something, size_t size) 15:49 < TheSeven> { 15:49 < TheSeven> void* endaddr = something + size; 15:50 < TheSeven> if (endaddr < something) return retval; 15:50 < TheSeven> int i; 15:50 < TheSeven> for (i = 0; something < endaddr; something++, i++) 15:51 < TheSeven> ... 15:51 < TheSeven> return retval; 15:51 < TheSeven> } 15:51 < TheSeven> that would be the outer part 15:51 < benedikt93> btw, r0 is for sure the address where the header is stored 15:52 < TheSeven> ok 15:52 < TheSeven> it's probably returning void 15:55 < TheSeven> and it's dealing with sha1 15:55 < benedikt93> why that? 15:56 < benedikt93> nvm, the address 0x38000000 16:03 < TheSeven> hm 16:04 < TheSeven> it looks a bit like some idiot used signed integers for something that should have been unsigned and the compiler was adding dozens of unneccessary precautions 16:07 < TheSeven> void dosomething(uint8_t* header, int addr, int size) 16:07 < TheSeven> { 16:07 < TheSeven> int endaddr = addr + size; 16:07 < TheSeven> if (endaddr < addr) return; 16:07 < TheSeven> int i; 16:07 < TheSeven> for (i = 0; addr < endaddr; addr++, i++) 16:07 < TheSeven> { 16:07 < TheSeven> uint32_t whatever = *(SHA1DATAIN + ((addr + (addr < 0 ? 3 : 0)) & ~3)); 16:07 < TheSeven> if ((addr & 3) == 0) 16:07 < TheSeven> *(SHA1DATAIN + (addr & ~3)) = (whatever & ~0xff) | header[i]; 16:07 < TheSeven> else if ((addr & 0x80000003) == 1) 16:07 < TheSeven> *(SHA1DATAIN + (addr & ~3)) = (whatever & ~0xff00) | (header[i] << 8); 16:07 < TheSeven> else if ((addr & 0x80000003) == 2) 16:07 < TheSeven> *(SHA1DATAIN + (addr & ~3)) = (whatever & ~0xff0000) | (header[i] << 16); 16:08 < TheSeven> hm, this is getting large 16:08 < TheSeven> http://pastebin.com/BucRuARV 16:10 < TheSeven> this whole thing basically copies R2 bytes at R0 into the SHA1 data input reg at offset R1 16:10 < TheSeven> I'd assume that R1 will always be 0 16:11 < TheSeven> basically this is an overcomplicated memcpy 16:12 < benedikt93> ok, thx 16:14 < TheSeven> actually it seems to have a bug regarding negative numbers :P 16:58 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Ping timeout: 248 seconds] 17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod 17:17 -!- perror [~fleury@aldebaran.labri.fr] has quit [Quit: Bye all !] 17:25 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod 18:24 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod 18:55 < TheSeven> benedikt93: 18:55 < benedikt93> yep 18:55 < TheSeven> D:\Daten\Projekte\iPod\fmi\apps\test>embios execimage 08000000 18:55 < TheSeven> Connected to emBIOS Debugger v0.0.1 (SVN revision: 98) on iPod Nano 2G, USB version 00.01 18:55 < TheSeven> Executing emBIOS executable image at 0x08000000...Traceback (most recent call last): 18:55 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 377, in 18:55 < TheSeven> parsecommand(dev, sys.argv) 18:55 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 358, in parsecommand 18:55 < TheSeven> dev.execimage(int(argv[2], 16)) 18:55 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\libembios.py", line 1021,in execimage 18:55 < TheSeven> self.handle.bulkWrite(self.__coutep, struct.pack(" )) 18:55 < TheSeven> NameError: global name 'threadid' is not defined 18:56 < TheSeven> copy&paste bug? 18:56 < benedikt93> exactly 18:56 < benedikt93> line 1021 should be self.handle.bulkWrite(self.__coutep, struct.pack(" execimage() return code: 0x02000200 looks very suspicious 18:59 < TheSeven> D:\Daten\Projekte\iPod\fmi\apps\test>embios getprocessinformation 0 1f0 18:59 < TheSeven> Connected to emBIOS Debugger v0.0.1 (SVN revision: 98) on iPod Nano 2G, USB version 00.01 18:59 < TheSeven> Retrieving process information...Traceback (most recent call last): 18:59 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 377, in 18:59 < TheSeven> parsecommand(dev, sys.argv) 18:59 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 330, in parsecommand 18:59 < TheSeven> dev.getprocinfo(int(argv[2], 16), int(argv[3], 16)) 18:59 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\libembios.py", line 773, in getprocinfo 18:59 < TheSeven> response = self.__getBulk(self.handle, self.__cinep, size + 0x10) 18:59 < TheSeven> AttributeError: embios instance has no attribute '_embios__getBulk' 19:00 < benedikt93> __getbulk instead of __getBulk 19:01 < benedikt93> to the above: suspicious in what sense? 19:02 < TheSeven> that it doesn't look like a valid return code but rather the response of a get transfer size request 19:02 < TheSeven> but that's probably a bug on my side 19:02 < TheSeven> oh, another crash: 19:02 < TheSeven> D:\Daten\Projekte\iPod\fmi\apps\test>embios getprocessinformation 0 1f0 19:02 < TheSeven> Connected to emBIOS Debugger v0.0.1 (SVN revision: 98) on iPod Nano 2G, USB version 00.01 19:02 < TheSeven> Retrieving process information...Traceback (most recent call last): 19:02 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 377, in 19:02 < TheSeven> parsecommand(dev, sys.argv) 19:02 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 330, in parsecommand 19:02 < TheSeven> dev.getprocinfo(int(argv[2], 16), int(argv[3], 16)) 19:02 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\libembios.py", line 777, in getprocinfo 19:02 < TheSeven> out[0] = struct.unpack(" IndexError: list assignment index out of range 19:03 < benedikt93> that [0] at the end seems to be too much 19:03 < TheSeven> nope 19:03 < TheSeven> rather the one after "out" 19:05 < TheSeven> this code is quite confusing 19:06 < benedikt93> I know 19:06 < benedikt93> seems that I have to fix like all usages of lists 19:07 < TheSeven> i don't quite get what the list was abused for in that place 19:07 < TheSeven> if it would get through that, it would end up in an endless loop later 19:08 < benedikt93> no, it'll break when the IndexError occurs 19:09 < TheSeven> ouch 19:10 < TheSeven> that while abused as an endless loop + independent constant condition check is *very* confusing then 19:10 < TheSeven> and also, using exceptions for regular control flow isn't really a best practice 19:10 < benedikt93> otherwise I would need a whole lot of additional checks if my pointer has reached the lists end 19:11 < TheSeven> also, the thread info seems to be missing the errno field 19:11 < benedikt93> this was because of the offset in the getproccessinfo 19:12 -!- Dreamxtreme [Archimedes@92.30.59.132] has quit [Quit: There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.] 19:12 < benedikt93> if that was threadwise it would have been easier 19:12 -!- Dreamxtreme [Dreamxtrem@92.30.59.132] has joined #freemyipod 19:13 < TheSeven> why not just lock the scheduler, download the whole struct (in multiple pieces, if needed), unlock the scheduler again, and then print it thread-wise? 19:14 < benedikt93> because there was the offset and size in http://www.freemyipod.org/wiki/EmBIOS_Monitor_Protocol#15:_Get_process_information i did it like this 19:14 < benedikt93> but when thinking of it again, I'll change it 19:15 < TheSeven> yes, the offset and size is needed to download it in parts if it exceeds the maximum command pipe packet size 19:19 -!- Dreamxtreme [Dreamxtrem@92.30.59.132] has quit [Read error: Connection reset by peer] 19:23 < cmwslw> i'm working on getting caught up on all the activity that happened over the past 24 hours 19:23 < cmwslw> so is an "emBIOS executable image" one that uses the emBIOS syscall api? 19:23 < TheSeven> yes 19:24 * TheSeven is still wondering where that weird usb response is coming from 19:29 < TheSeven> benedikt93: uh oh, libibugger is sending a wrong command id for execimage() 19:30 < TheSeven> libembios* 19:30 < benedikt93> " line 1021 should be self.handle.bulkWrite(self.__coutep, struct.pack(" 21 is correct 19:30 < TheSeven> i only noticed that you changed "threadid" 19:33 -!- Dreamxtreme [Dreamxtrem@92.30.96.53] has joined #freemyipod 19:33 < benedikt93> it was sending 18 before, so 0x02000200 was part of the undefined data which was left from __init__ 19:42 * TheSeven now wonders why his ipod enters an infinite recursion of panics 19:42 < TheSeven> "Unhandled SWI 00FEBEAF" 19:45 < TheSeven> hm, the stack munging pattern being "SWIGE 0xFEBEAF" could explain it 19:45 < TheSeven> but why is the PC running into a stack? 19:56 < TheSeven> *facepalm* 19:59 < TheSeven> overwriting the idle thread's code isn't really a good idea 20:00 < TheSeven> #include "embiosapp.h" 20:00 < TheSeven> void main(); 20:00 < TheSeven> EMBIOS_APP_HEADER("Test application", 0x4000, main, 127) 20:00 < TheSeven> void main() 20:00 < TheSeven> { 20:00 < TheSeven> embios_init(); 20:00 < TheSeven> panic(PANIC_KILLTHREAD, "test"); 20:00 < TheSeven> } 20:00 < TheSeven> nice way to write apps, huh? :D 20:04 < fmibot> New commit by 3theseven (r99): Make the syscall interface work, add simple hello world app 20:04 < fmibot> r99 build result: All green! 20:05 < TheSeven> who wants to try this fun out on his 4g? 20:10 * Dreamxtreme buys a 4G just for this very occation 20:10 * GaveUp will gladly try if someone is willing to donate a 4g :P 20:39 < fmibot> New commit by 3theseven (r100): Check the syscall table version before accepting it 20:39 < fmibot> r100 build result: All green! 20:53 < user890104> let's try it 20:55 < fmibot> New commit by 3benedikt93 (r101): fix libembios.py 20:55 < fmibot> r101 build result: All green! 20:57 < benedikt93> TheSeven, getprocinfo should now be fixed 20:58 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\embios.py", line 330, in parsecommand 20:58 < TheSeven> dev.getprocinfo(int(argv[2], 16), int(argv[3], 16)) 20:58 < TheSeven> TypeError: getprocinfo() takes at most 2 arguments (3 given) 20:58 < TheSeven> and it still has those weird offset/size arguments 20:59 < benedikt93> remove both args in embios.py 21:00 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\libembios.py", line 798, in getprocinfo 21:00 < TheSeven> out = (structversion, tablesize, procinfotolist(procinfo, structversion)) 21:00 < TheSeven> UnboundLocalError: local variable 'procinfotolist' referenced before assignment 21:02 < TheSeven> oh, that's a funny one 21:02 < user890104> data += struct.pack(" NameError: global name 'struct' is not defined 21:02 < user890104> what about this one 21:02 < TheSeven> that sounds like "import struct" is missing at the top 21:03 < benedikt93> there are two functions inside getprocinfo(libembios.py), move them to the beginning of getprocinfo 21:03 < benedikt93> yes it is missing 21:03 < TheSeven> why is getprocinfo a constructorless object? 21:04 < TheSeven> s/object/class/ 21:04 < TheSeven> why is it a class in the first place? 21:05 < benedikt93> it's a function that has two local functions 21:06 < TheSeven> those aren't normal functions if they have the "self" argument 21:07 < benedikt93> oh, didn't know that 21:07 < benedikt93> I'm really new to python, so 21:08 * TheSeven should probably just rewrite that whole thing instead of trying to fix it 21:08 < TheSeven> it never requests any data from the ipod 21:09 < TheSeven> and tells me that the table size is zero 21:11 < fmibot> New commit by 3benedikt93 (r102): fix some libembios.py/embios.py stuff 21:11 < fmibot> r102 build result: All green! 21:13 < benedikt93> fixed now all that and some other issue that was likely to cause a wrong tablesize output 21:13 < user890104> libembios.py", line 577, in writeusbcon 21:13 < user890104> size -= sendbytes 21:13 < user890104> TypeError: unsupported operand type(s) for -=: 'int' and 'tuple' 21:17 < user890104> the downloadint also needs some fix 21:18 < fmibot> New commit by 3benedikt93 (r103): fix some libembios.py stuff again 21:18 < fmibot> r103 build result: All green! 21:19 < user890104> self.__myprint("Downloading 0x%08x from 0x%08x..." % (data, offset), silent) 21:19 < user890104> data = self.read(offset, data, 0, 0) 21:19 < user890104> should be: 21:19 < user890104> self.__myprint("Downloading from 0x%08x..." % (offset), silent) 21:19 < user890104> data = self.read(offset, 1, 0, 0) 21:20 < user890104> copy/paste stuff :) 21:20 < fmibot> New commit by 3benedikt93 (r104): fix some libembios.py stuff once again 21:21 < fmibot> r104 build result: All green! 21:22 < user890104> benedikt93: you should have left the second param alone in self.read 21:23 < user890104> data = self.read(offset, 0, 0) 21:23 < user890104> TypeError: read() takes exactly 5 arguments (4 given) 21:23 < benedikt93> data = self.read(offset, 4, 0, 0) should do it 21:24 < user890104> oh, it's a 32-bit int 21:24 < user890104> didin't noticed it 21:26 < TheSeven> benedikt93: it's still reporting a 0-byte process information table without even sending a request for it 21:33 < benedikt93> then for some reason the check at 862 fails 21:33 < benedikt93> gonna look at this tommorow 21:33 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)] 22:07 < cmwslw> good I'm glad TheSeven added an example emBIOS app 22:20 < TheSeven> cmwslw: did you try it? i didn't test it on the 4g yet 22:21 < cmwslw> TheSeven: not yet but i will 22:21 < cmwslw> its pretty amazing how fast you work on this code 22:22 < TheSeven> you're always faster if you aren't doing things for the first time 22:32 < cmwslw> im so happy there isn't a 4g branch anymore 22:34 -!- Mr_Sensitive [~Dreamxtre@92.30.96.53] has joined #freemyipod 22:35 -!- Mr_Sensitive [~Dreamxtre@92.30.96.53] has quit [Read error: Connection reset by peer] 22:38 -!- Dreamxtreme [Dreamxtrem@92.30.96.53] has quit [Ping timeout: 248 seconds] 23:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection] 23:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod 23:22 < fmibot> New commit by 3cmwslw (r105): Fixed the same problems that r83 fixed for 4g_compat. 23:23 < fmibot> r105 build result: All green! 23:30 -!- DeLiri0us_ [~delirius@5ED6A40F.cable.ziggo.nl] has joined #freemyipod 23:32 < DeLiri0us_> Ohai! 23:32 < DeLiri0us_> I need some help 23:37 < cmwslw> what? 23:42 -!- DeLiri0us_ [~delirius@5ED6A40F.cable.ziggo.nl] has quit [Remote host closed the connection] 23:55 < TheSeven> cmwslw: what the hell is this supposed to tell me? http://www.freemyipod.org/wiki/File:8700_ball_layout.png 23:58 < cmwslw> its the ball layout of the chip described in the datasheet 23:59 < cmwslw> i made that a long time ago so it doesn't really matter anymore --- Log closed Thu Aug 12 00:03:49 2010