--- Log opened Sat Aug 14 00:08:12 2010 00:08 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #freemyipod 00:13 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has joined #freemyipod 00:30 < fmibot> New commit by 3theseven (r134): Make nandfsck actually realize that it succeeded, and make it's progress bar run a bit more fluently 00:30 < fmibot> r134 build result: All green! 00:30 < TheSeven> s/it's/its/ 01:22 -!- Mr_Sensitive [~Dreamxtre@92.30.26.237] has joined #freemyipod 01:24 -!- Dreamxtreme [~Dreamxtre@92.29.246.124] has quit [Ping timeout: 248 seconds] 02:10 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 02:45 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Ping timeout: 265 seconds] 02:50 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod 03:40 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 03:41 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 04:54 -!- cmwslw [~cmwslw@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Quit: Ex-Chat] 04:57 -!- Mr_Sensitive [~Dreamxtre@92.30.26.237] has quit [Read error: Connection reset by peer] 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 06:32 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 06:59 -!- Dreamxtreme [~Dreamxtre@92.30.56.120] has joined #freemyipod 08:10 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod 08:14 < fmibot> New commit by 3benedikt93 (r135): add libembios execfirmware command 08:14 < fmibot> r135 build result: All green! 08:16 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod 09:00 -!- benedikt93 is now known as benedikt93|AFK 09:11 < benedikt93|AFK> TheSeven, btw, did the workaround I pushed yesterday work? 09:12 < TheSeven> for getprocinfo? no 09:13 < TheSeven> it fails a bit less terribly though, just state UNKNOWN for all threads 09:14 < TheSeven> and it seems to also show processes with state = PROCESS_FREE 09:15 < TheSeven> and apparently the idle process isn't shown for some reason 09:15 < TheSeven> (it should be PID 0, but the first process shown seems to be the usb listener) 09:17 < TheSeven> hmm but judging from the garbage data i'm getting there, it might be an ipod-side problem 09:17 < TheSeven> this stuff looks like it's arm instructions 09:37 < TheSeven> ok, this was an ipod side bug 09:37 < TheSeven> however, all enums are still UNKNOWN and it's showing the free thread handles 09:38 < fmibot> New commit by 3theseven (r136): Fix getprocessinfo monitor command 09:38 < benedikt93|AFK> I fixed that free thred handle bug right now locally 09:38 < fmibot> r136 build result: All green! 09:40 -!- benedikt93|AFK is now known as benedikt93 09:46 < fmibot> New commit by 3benedikt93 (r137): fix libembios -> getprocinfo at least partially 09:46 < fmibot> r137 build result: All green! 09:47 < benedikt93> implemented free_thread check + updated the thread_type enum to string function to the latest thread.h 09:50 < TheSeven> it's locking up in an infinite loop now 09:50 < TheSeven> File "D:\daten\projekte\ipod\fmi\embios\trunk\tools\libembios.py", line 773, in procinfotolist 09:50 < TheSeven> if struct.unpack(" KeyboardInterrupt 09:51 < benedikt93> ah, forgot to increment the pointer and process_n there 09:52 < benedikt93> change line 773 to 09:52 < benedikt93> if struct.unpack(" ptr += 120 09:52 < benedikt93> process_n += 1 09:52 < benedikt93> continue 09:53 < benedikt93> ah, no, wrong again 09:53 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 09:54 < benedikt93> if struct.unpack(" ptr += 120 09:54 < benedikt93> process_n += 1 09:54 < benedikt93> continue 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 12:15 < angelwolf71885> i dont know if anyone has noticed but 2 days ago was the 1 year annivershry since this project has begun 12:16 < angelwolf71885> actuialy july 31 was the 1 year my bad 12:34 -!- Dreamxtreme [~Dreamxtre@92.30.56.120] has quit [Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.] 12:50 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Remote host closed the connection] 13:01 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 13:12 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has left #freemyipod 13:18 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 13:18 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has quit [Client Quit] 13:19 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 13:21 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has quit [Remote host closed the connection] 13:36 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 13:50 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod 13:51 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Lämnar] 14:24 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has quit [Ping timeout: 276 seconds] 14:46 -!- benedikt93 is now known as benedikt93|AFK 14:50 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 14:59 -!- benedikt93|AFK is now known as benedikt93 16:00 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 16:21 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has quit [Ping timeout: 240 seconds] 16:53 -!- MrShlee [~Default@114-30-105-184.ip.adam.com.au] has joined #freemyipod 16:53 -!- watto [~watto@188-221-185-113.zone12.bethere.co.uk] has joined #freemyipod 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:41 -!- MrShlee [~Default@114-30-105-184.ip.adam.com.au] has quit [Quit: Leaving] 18:04 -!- timccccc [~lisa@rab34-4-82-240-134-112.fbx.proxad.net] has joined #freemyipod 18:34 < fmibot> New commit by 3theseven (r138): iLoader as an emBIOS app 18:34 < fmibot> r138 build result: All green! 18:49 < TheSeven> benedikt93: actually *implementing* the execfirmware command and not only adding it to the usage info might be helpful :P 18:56 < fmibot> New commit by 3benedikt93 (r139): really add execfirmware 18:56 < fmibot> r139 build result: All green! 19:08 -!- Dreamxtreme [~Dreamxtre@92.30.17.70] has joined #freemyipod 19:14 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)] 20:24 -!- Mr_Sensitive [~Dreamxtre@92.30.197.137] has joined #freemyipod 20:26 -!- Dreamxtreme [~Dreamxtre@92.30.17.70] has quit [Ping timeout: 260 seconds] 20:48 < TheSeven> anyone with a 2g around? 21:26 < user890104> only a 4g here, loaded with ibugger waiting for some code to run on it 22:24 -!- cmwslw [~cmwslw@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod 22:26 * TheSeven wonders how to figure out why all apple code is refusing to boot on his ipod 22:44 < user890104> what is the execfirmware command for? booting (for example, apple's) firmware under embios or something else? 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:13 * TheSeven facepalms 23:14 < TheSeven> user890104: yes, it can boot the apple firmware, diskmode, diagmode, ibugger, or just another embios version 23:14 < user890104> i guess it is available only for 2g right now? 23:14 < user890104> because of the flash access 23:16 < fmibot> New commit by 3theseven (r140): Fix a bunch of bugs 23:16 < fmibot> r140 build result: All green! 23:16 < TheSeven> this command doesn't have anything to do with flash access 23:17 < TheSeven> you just specify a RAM address where the new firmware is loaded, no matter *how* it was loaded there (whether from flash or via usb or whatever) 23:17 < TheSeven> so we can already use this e.g. to update a running embios in-place 23:18 < user890104> so basicly to run something, it needs to be uploaded into the ram and then execute the execfirmware command? 23:18 < user890104> i'll give it a try 23:18 < TheSeven> yep 23:18 < TheSeven> just upload embios.bin to 0x08000000 and then run embios.py execfirmware 08000000 23:26 < TheSeven> hm, what next? 23:27 < TheSeven> who wants to write some apps? :P 23:30 < cmwslw> TheSeven: where do you normally upload apps? I tries using 0x09000000 and it said it needed 0x08000000 (i think) and when I did that it worked but it had a panic 23:31 < TheSeven> embios reserves the 0x09e00000-0x09ffffff and 0x22000000-0x2202ffff range for itself, all other memory may be used by apps or whatever 23:32 < TheSeven> however, apps need to be loaded at the address they're compiled for 23:32 < TheSeven> and of course you have to make sure that there are no collisions if multiple apps should be running side by side 23:33 < cmwslw> so apparently the hello world was compiled for 0x08000000. I'll have to look into the panic I got though. "hello world" was still printed 23:33 < TheSeven> the memory range used by an app can be configured in the memory section of its linker script (ls.x) 23:34 < TheSeven> well, it's printing that by means of calling panic(PANIC_KILLTHREAD, "hello world") or something 23:34 < TheSeven> back when i wrote it, this was the only api that existed :P 23:35 < cmwslw> oh that explains it. I thought it was a problem. But since panic hangs afterwards it would be impossible anyways 23:35 < TheSeven> not neccessarily 23:35 < TheSeven> there are three levels of panics: 23:36 < TheSeven> PANIC_KILLTHREAD will just terminate the thread that called it, which is useful if you detect something going wrong inside your app that doesn't affect system stability or other apps 23:37 < TheSeven> PANIC_KILLUSERTHREADS will kill all user threads, but keep the kernel and some system threads (for example the usb listener) alive, so that you can attach it to a debugger and have a look what's going on. 23:38 < TheSeven> this should be done if you can assume that it's safe to rely on the kernel still (mostly) working, but it wouldn't be safe to just continue execution of other threads, which might have been affected (for example by a stack overflow) 23:40 < TheSeven> and then there's PANIC_FATAL which is currently used in the kernel for very weird things (lowlevel I/O errors on the flash, running into severe trouble inside an interrupt handler, detection of kernel memory corruption, ...) 23:41 < cmwslw> im also confused about creating new threads. when coding it seems simple to make one, but making one through libibugger seems complicated 23:41 < TheSeven> this will immediately enter a safe context (critical section, interrupts disabled, system mode), print a message to the screen in a safe way that doesn't rely on interrupts or mutexes, and then lock up 23:42 < cmwslw> how do I know where and how big to make the stack? 23:42 < TheSeven> libibugger is basically wrapping the thread_create kernel api 23:42 < TheSeven> the arguments are mostly the same 23:42 < cmwslw> yea but in code all you have to do is make an array and pass a pointer to it 23:42 < TheSeven> yep 23:43 < TheSeven> well, if you do it through the debugger, you need to know where some free memory is and pass a pointer to that 23:43 < cmwslw> ok, and the size of the stack varies from app to app? 23:44 < TheSeven> that depends on how many local variables (and especially arrays) the functions called from that thread have, and what the maximum recursion/nesting level is 23:45 < TheSeven> 16KB should be sufficient for most things 23:45 < cmwslw> ok this clears up a lot. thanks 23:45 < TheSeven> ibugger is using a 4KB stack and i haven't seen more than 1.5-2K of it being actually used 23:46 < TheSeven> but if you're writing something more complex, it might need more 23:46 < user890104> have someone tested the console-related commands of libembios 23:46 < user890104> i'm getting some python errors 23:46 < TheSeven> you'd get a "*PANIC* Stack overflow (thread name)" in that case 23:47 < TheSeven> user890104: libembios is just broken 23:47 < TheSeven> Farthen is having a look into rewriting it 23:47 < TheSeven> (based on the new libusb this time) 23:47 < cmwslw> was it the old libusb that was causing the weird responses I was getting? 23:48 < TheSeven> with embios or ibugger? 23:48 < cmwslw> like downloadint was sometimes reading 12 bytes 23:48 < cmwslw> embios 23:48 < TheSeven> hm that's probably yet another libembios bug 23:49 < TheSeven> the old libusb is just causing all hell of trouble on windows, so we want to get rid of it 23:49 < cmwslw> yea well it was completely broken the first time i tried it. now i fixed it and its still semi-broken 23:49 < Farthen> the new one will be better, i hope :-P 23:49 < cmwslw> does the new version not use the same python syntax? 23:50 < Farthen> it will use the same commandline syntax except some commands 23:51 < TheSeven> cmwslw: once libembios is done, I might try to write a GDB stub wrapper for it, so that you could just single step though your code in (for example) ida :) 23:52 < cmwslw> that would be nice 23:54 < user890104> what's the difference between execimage and execfirmware 23:57 < TheSeven> execimage executes an embios app, while execfirmware executes a kernel/firmware 23:57 < TheSeven> from the technical side, embios apps have a header with some basic information, and are built to coexist with embios and other apps. they will be run in an embios thread 23:58 < TheSeven> execfirmware will shut down the kernel, flush and disable caches, disable interrupts, and jump into the code 23:59 < cmwslw> is there an embios command for decompressing and executing some UCL-compressed code? --- Log closed Sun Aug 15 00:00:54 2010