00:42 *** S_a_i_n_t has quit IRC (Ping timeout: 255 seconds)
00:44 *** S_a_i_n_t has joined #freemyipod
01:59 *** Jiss has quit IRC (Quit: Quit)
03:09 *** TheSeven has quit IRC (Ping timeout: 240 seconds)
03:13 *** TheSeven has joined #freemyipod
05:00 Session Start: Tue Nov 02 05:00:21 2010
05:00 Session Ident: #freemyipod
05:00 *** clustur has joined #freemyipod
06:16 *** n1s has joined #freemyipod
06:46 *** n1s has quit IRC (Quit: Lämnar)
08:25 *** perror has joined #freemyipod
09:41 *** Jiss has joined #freemyipod
09:54 *** perror has quit IRC (Quit: Bye all !)
09:54 *** perror has joined #freemyipod
10:06 *** cac2s has joined #freemyipod
10:15 * TheSeven just booted rockbox through umsboot :)
10:15 < TheSeven> well, it froze at some point, but at least it showed its logo
10:16 < user890104> TheSeven: on which device?
10:16 < TheSeven> nano2g
10:17 < user890104> nice
10:18 < TheSeven> 168772 of 180224 bytes of sram used
10:18 < TheSeven> that was tight :)
10:18 < TheSeven> a whopping 11kB of free RAM
10:19 *** liar has quit IRC (Ping timeout: 255 seconds)
10:19 < TheSeven> executable size: 14192 bytes (8496 bytes when compressed)
10:20 < TheSeven> i've seen UCL do better...
10:20 < TheSeven> so that's another 3 flash pages
10:22 < TheSeven> fits perfectly
10:26 *** liar has joined #freemyipod
11:00 Session Start: Tue Nov 02 11:00:16 2010
11:00 Session Ident: #freemyipod
11:00 *** clustur has joined #freemyipod
11:01 < fmibot> New commit by 3theseven (r239): libipoddfu: Fix device detection
11:01 < fmibot> r239 build result: All green!
11:02 < fmibot> New commit by 3theseven (r240): emBIOS: Shut down USB controller before powering off or executing firmware image (disk mode fix part 1/2)
11:02 < fmibot> r240 build result: All green!
11:03 < fmibot> New commit by 3theseven (r241): iLoader themes: Wait 200 milliseconds before executing disk mode (disk mode fix part 2/2)
11:03 < fmibot> r241 build result: All green!
11:07 < fmibot> New commit by 3theseven (r242): UMSboot: Fork from emBIOS trunk
11:07 < fmibot> r242 build result: All green!
11:11 < fmibot> New commit by 3theseven (r243): UMSboot: Initial commit
11:11 < fmibot> r243 build result: All green!
11:13 < fmibot> New commit by 3theseven (r244): UMSboot: Remove leftover folder
11:13 < fmibot> r244 build result: All green!
11:26 < TheSeven> who wants to test it?
11:47 < S_a_i_n_t> what's UMSboot?
11:48 < TheSeven> S_a_i_n_t: a tool that should hopefully finally ease recovering borked ipods
11:48 < S_a_i_n_t> Ah.
11:48 < S_a_i_n_t> Mice
11:48 < S_a_i_n_t> *nice
11:48 < TheSeven> haha :)
11:48 < TheSeven> it will provide access to a pre-formatted ramdisk via the usb mass storage protocol
11:48 < TheSeven> you just copy a *.ubi file to it, unplug it, and the file will be executed
11:49 < TheSeven> no more need for python, libusb etc.
11:49 < TheSeven> (besides for the really fubar'd ones of course)
11:51 < TheSeven> now we need try getting rid of all possible embios bootup panics
11:51 *** cac2s has left 
11:52 *** cac2s has joined #freemyipod
12:00 < TheSeven> the ubi file will be moved to 0x08000000 and executed from there, the ramdisk file system will be shrunken to the minimum possible size, moved to the end of RAM, and a pointer to the beginning of the ramdisk will be stored in the last word of sram (0x2202bffc)
12:01 < TheSeven> you shouldn't reformat the partition or create folders on it or it will explode :)
12:12 * TheSeven wonders how to get rid of the various possible FTL panics
12:14 * S_a_i_n_t boggles at "you shouldn't reformat the partition or create folders on it or it will explode :)"
12:14 < S_a_i_n_t> errr....huh?
12:14 < S_a_i_n_t> ;D
12:15 < TheSeven> well, it's relying on some assumptions...
12:23 *** Jiss has quit IRC (Quit: Quit)
12:28 *** cac2s has left 
12:29 *** cac2s has joined #freemyipod
12:38 *** cac2s has quit IRC (Ping timeout: 245 seconds)
12:40 *** cac2s has joined #freemyipod
12:42 *** fmibot has quit IRC (Ping timeout: 276 seconds)
12:43 *** fmibot has joined #freemyipod
12:43 *** ChanServ sets mode: +o fmibot
13:20 *** n1s has joined #freemyipod
13:20 *** n1s has quit IRC (Changing host)
13:20 *** n1s has joined #freemyipod
13:42 *** cac2s has left 
14:20 < user890104> TheSeven: how do i test this one?
14:20 < user890104> i got my music/data backed up, so i don't mind wiping it
14:21 < TheSeven> no need to wipe anything
14:21 < TheSeven> just svn up, compile an installer (don't forget to re-run make flashfiles) and run that
14:21 < TheSeven> you should have a "umsboot" option in the fallback menu
14:22 < TheSeven> if you boot that, you'll see a 32MB ramdisk
14:22 < TheSeven> copy e.g. an embios.bin or rockbox.bin to that, rename it to *.ubi and unplug
14:23 < user890104> just a moment to launch my ubuntu VM which takes care of building installers
14:31 < user890104> [LD] build/ipodnano2g/umsboot.elf
14:31 < user890104> arm-elf-eabi-ld: build/ipodnano2g/umsboot.elf: section .ramdisk vma 0x8000000 overlaps previous sections
14:31 < user890104> [OC] build/ipodnano2g/umsboot.elf
14:32 < user890104> is this safe?
14:32 < user890104> i mean is it expected
14:33 < TheSeven> yes
14:33 < TheSeven> i still have to find a way to suppress that warning
14:33 < TheSeven> that the initcode section is re-used as ramdisk space later is intentional :)
14:35 < user890104> do i need to repartition it now or ot uses the nor flash, not the firmware partition?
14:37 < user890104> i still don't fully understand the whole stuff
14:37 < TheSeven> repartitioning has some advantages and disadvantages. it's not required, but i generally recommend as long as you don't want to use itunes.
14:41 < user890104> 0xffff 0x5562 is that the ramdisk?
14:44 < TheSeven> yes
14:47 < user890104> got an ibugger running, but after usb init ... ok it seems to have frozen
14:51 * TheSeven doesn't trust ibugger too much
14:51 < TheSeven> probably it's relying on something that doesn't hold true when booting through umsboot
14:51 < TheSeven> as long as it boots embios fine, i'm happy :)
14:53 < user890104> the embios binary itself, or the embiossed iloader installer?
14:55 < TheSeven> they should both work
14:56 < user890104> rearranging files seems to corrupt the display buffer
14:56 < TheSeven> how did you manage to trigger that?
14:57 < user890104> oh, i uploaded a bad file
14:57 < TheSeven> such things shouldn't happen nevertheless
14:57 < TheSeven> what exactly did you do?
14:58 < user890104> i extracted osos.fw from the OF, but forgot that it's encrypted and put it straight away, renamed
14:58 < user890104> it doesn't check the image, does it?
15:00 < TheSeven> no
15:00 < user890104> the installer seems to run fine
15:00 < TheSeven> it just picks it based on the file name extension
15:00 < TheSeven> nevertheless i can't see how this could possibly lead to lcd buffer corruption
15:04 < user890104> after "booting", the screen got really screwed up, the upper half was totally random and the lower was almost filled with black dots, and some small remains of the console message
15:06 < TheSeven> interesting
15:06 < TheSeven> but this definitely happened after it printed "booting"?
15:06 < TheSeven> then it seems like the encrypted file actually made up valid code writing to the lcd... that's funny.
15:07 < user890104> the booting line was visible, so i guess it actually started running the code
15:09 < TheSeven> i need to know if that corruption might have happened while it was swapping blocks to defragment the file
15:09 < user890104> the first one did
15:09 < TheSeven> if the booting line was perfectly fine but everything else was garbled, that point to such an issue
15:09 < TheSeven> if the booting line is also affected, it probably happened after booting the image
15:10 < user890104> i think it was blurred, too
15:10 < user890104> will try it again
15:11 < user890104> embios runs fine, too
15:15 < user890104> so, this time i uploaded the unencrypted apple f/w, and something simmilar happened
15:16 < user890104> loading ... still fine, right after loading the screen buffer got shifted left by like 5-6 px and lightly corrupted with black dots, then the arranging message appears
15:17 < user890104> after arranging just before booting message, the corruption got more colorful - literally
15:17 < TheSeven> that's pretty certainly evidence of a nasty bug in the filesystem code
15:18 < user890104> then the booting message appears, and then freezes
15:18 < user890104> could you reproduce it on your device
15:18 < user890104> i was using the appleos.bin backup from iloader instalation
15:19 < TheSeven> let me try
15:19 < TheSeven> it will probably just happen with any file that's bigger than a few kilobytes
15:20 < user890104> what does the rearranging actually do?
15:20 < TheSeven> basically defragmenting and shrinking the ramdisk
15:21 < TheSeven> hm, i'm also seeing some corrupted pixels with a 3.5MB mp3 file renamed to ubi
15:21 < TheSeven> it's also taking way too long
15:21 < user890104> yes, that too
17:00 Session Start: Tue Nov 02 17:00:19 2010
17:00 Session Ident: #freemyipod
17:00 *** clustur has joined #freemyipod
17:30 *** n1s has quit IRC (Quit: Lämnar)
18:14 < fmibot> New commit by 3theseven (r245): UMSboot: Add missing SVN ignore property for build folder
18:14 < fmibot> r245 build result: All green!
18:15 < fmibot> New commit by 3theseven (r246): UMSboot: Fix problems that occurred when more than 2MB of the file system were used
18:15 < fmibot> r246 build result: All green!
18:21 < TheSeven> user890104: this seems to have fixed most of the problem, but not all
18:21 < TheSeven> even with this version i managed to get a few pixels of lcd corruption once
18:22 < TheSeven> judging from debug output i have the impression that something might be wrong with the RAM
18:23 < TheSeven> can you test stuffing the ramdisk with some crap and placing a single known-good ubi file somewhere in between?
18:23 < TheSeven> make sure that the ubi file isn't copied unless at least some megabytes of space are used
18:23 < TheSeven> if you want to stress test it even more, delete some files again and copy other ones, to cause fragmentation
18:23 < TheSeven> do you still manage to make it fail somehow?
18:52 < user890104> let's see
19:14 < user890104> this time the loading was sooo fast
19:14 < user890104> then some rearranging
19:14 < user890104> and after booting i guess it crashed and restarted
19:14 < user890104> i used an appleos.bin
19:14 < user890104> and store a 23 MB pdf before that to fill up the space
19:16 < user890104> there's a limit of 25 files per folder according to my windows 7
19:17 *** perror has quit IRC (Quit: Bye all !)
19:20 < user890104> now the limit changed to 16
19:21 < user890104> every time i delete something and create a new file, the limit changes to a lower number
19:28 < TheSeven> not really
19:28 < TheSeven> the limit is dependent on the file name length
19:28 < TheSeven> there are 63 directory entries
19:28 < TheSeven> everything that's more than 8.3 format and not all-lowercase will eat multiple of them
19:32 < TheSeven> i've found a file system image that makes it lock up during the rearranging stage...
19:37 < user890104> oh, that explains it, i'm copying the files over and over and windows adds ...copy (1) copy (2) at the end of the name
19:37 < user890104> so after filling up with junk, it booted successfully embios
19:37 < user890104> let's try the encrypted file
19:38 < TheSeven> mine is getting stuck in a fat entry cycle :/
19:40 < user890104> no corruption now
19:40 < user890104> and of course nothing boots since it's encrypted
19:40 < user890104> i'm gonna try the unencrypted & uncapped OF
19:43 < user890104> i think rearranging got stuck
19:44 < user890104> can i get some kind of debug what's rearranging on the ipod's console
19:46 < user890104> for example print something from within the loops
19:50 < TheSeven>     char buf[30];
19:50 < TheSeven>     snprintf(buf, sizeof(buf), "%d => %d\n", src, dest);
19:50 < TheSeven>     lcdconsole_puts(buf, 0, 0xffff);
19:51 < TheSeven> putting that at the beginning of the swap function in umsboot/main.c should provide some hints
19:56 < user890104> main.c: In function ‘swap’:
19:56 < user890104> main.c:110: warning: incompatible implicit declaration of built-in function ‘snprintf’
19:56 < user890104> what's missing, string.h?
19:58 < TheSeven> doesn't matter
19:58 < TheSeven> should work nevertheless
19:58 < TheSeven> and IIRC that would be stdio.h
20:04 < user890104> booting corrupted 2 or 3 of the pixels, and it didn't actually boot
20:04 < user890104> (appleos.bin renamed to .ubi)
20:04 < user890104> is it actually possible to boot it that way?
20:04 < TheSeven> i don't know for sure
20:35 < TheSeven> urgh.
20:35 < TheSeven> long file names.
20:45 < fmibot> New commit by 3theseven (r247): UMSboot: Fix issues with long file names
20:45 < fmibot> r247 build result: All green!
20:46 < fmibot> New commit by 3theseven (r248): libc: Optimize for performance instead of code size. Uses ~600 bytes more but is several times faster.
20:46 < fmibot> r248 build result: All green!
20:50 < user890104> TheSeven could you please explain the structure of the directory entries at the end of nano 2g's nor flash, i've found them but don't know which bytes hold the address and the length of each image
20:51 < TheSeven> hm they're documented at the ipodlinux wiki, but that's down :/
20:52 < TheSeven> judging from some of my code, the address is at filename+0xc and the size at filename+0x10
20:53 < TheSeven> the size is apparently not including the header, so you'll need to add 512
20:54 < TheSeven> btw, trying to boot the of through umsboot just locks up on mine
20:58 < user890104> locks up after "booting..." ?
20:58 < TheSeven> yes
21:04 < user890104> same for me
21:12 *** n1s has joined #freemyipod
21:12 *** n1s has quit IRC (Changing host)
21:12 *** n1s has joined #freemyipod
21:17 < user890104> TheSeven is the norflash.bak encrypted?
21:17 < TheSeven> the file itself isn't, but the images contained in it are
21:17 *** Jiss has joined #freemyipod
21:18 < user890104> so how do i decrypt them? i remeber ibugger has an decryptnor command
21:18 < user890104> remember*
21:18 < TheSeven> ipodcrypt.py nano2g-decryptdfu should work
21:18 < TheSeven> at least for the norboot.8701 part of it
21:19 < TheSeven> i don'
21:19 < TheSeven> i don't remember how the other ones are encrypted
21:19 < TheSeven> could be also decryptdfu or possibly decryptfw
21:20 < TheSeven> you'll probably have to change it to use the uid key instead of gid
21:20 < TheSeven> what are you planning to do btw?
21:22 < user890104> i'm trying to extract and decrypt the disk mode image and run it with runfirmware or umsboot
21:23 < TheSeven> it should be easier to grab it from the bootflash after iloader has been installed
21:23 < TheSeven> that's just compressed, not encrypted
21:23 < user890104> so i've managed to extract 4 images (2 of them being the apple logo i guess), diskflsh and diagflsh
21:23 < TheSeven> ucl2e10singleblkunpack should do the trick
21:23 < user890104> yes, but i like doing thigns the hard way to learn how the others did them
21:24 < TheSeven> i did that ages ago and don't even know if it's possible using only released tools
21:25 < user890104> i tried to run ibugger and use that decryptnor command, but it doesn't run from within embios' runfirmware
21:25 < TheSeven> hm... ibugger loader or core?
21:25 < user890104> i guess i'll go back to the time when we used the notes expoit combines with an ibugger loader
21:25 < user890104> a loader
21:25 < TheSeven> that should work in theory
21:26 < user890104> actually, yes but it freezes
21:26 < user890104> usb init ... ok, then freeze
21:26 < TheSeven> depending on the version you might need to load it to a different address though
21:26 < TheSeven> 0x09000000 should work for every version
21:26 < user890104> i missed that, tried 08000000
21:26 < TheSeven> some earlier ones had a usb transfer buffer at 0x08000000
21:27 < TheSeven> that was fixed later on, but i don't know which one you're currently dealing with
21:27 < user890104> i think it's the latest
21:27 < user890104> snapshot-201003100612
21:28 < TheSeven> hm
21:28 < TheSeven> it also fails for me through umsboot
21:28 < TheSeven> but it works through embios
21:29 < TheSeven> oh
21:29 < TheSeven> it doesn't any more
21:29 < user890104> Running firmware at 0x9000000. Bye.ERROR: Problem with USB connection.
21:29 < user890104> and then it's not detected
21:30 < TheSeven> this was probably broken by r240
21:30 < TheSeven> apparently ibugger relies on the usb controller already being powered up
21:31 < user890104> so disk mode powers it up?
21:31 < TheSeven> yes
21:31 < TheSeven> if you want to boot ibugger, use embios loader recovery mode
21:31 < TheSeven> and then embiosldr.py run .../loader.bin
21:33 < user890104> yep, booted now
21:37 < user890104> do i need the 512-byte headers when sending file to be decrypted or i could just strip them when extracting?
21:37 < TheSeven> no idea
21:37 < TheSeven> you won't need it, but the tool might want to strip the header itself
21:39 < user890104> decryptnor seems to be the right way
22:56 < fmibot> New commit by 3theseven (r249): emBIOS: Handle FTL problems more gracefully on iPod Nano 2G
22:56 < fmibot> r249 build result: All green!
23:00 Session Start: Tue Nov 02 23:00:20 2010
23:00 Session Ident: #freemyipod
23:00 *** clustur has joined #freemyipod
23:13 < fmibot> New commit by 3theseven (r250): Release emBIOS v0.1.4
23:13 < fmibot> r250 build result: All green!
23:20 *** soap has joined #freemyipod
23:20 < TheSeven> release completed.
23:20 < TheSeven> let's write some news
23:25 < TheSeven> the r220 installer has been downloaded a whopping 188 times total, the updater 32 times
23:26 < TheSeven> er, i mean 208/35 times
23:28 < TheSeven> most of the visitors came through the wiki, but quite a bunch of them came from http://psx-scene.com/forums/f6/psgroove-ported-rockbox-ipods-66820/index96.html