--- Log opened Tue Sep 07 00:05:48 2010
00:05 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #freemyipod
01:10 -!- Dreamxtreme [~Dreamxtre@92.30.60.81] has quit [Quit: Going!]
01:11 -!- Dreamxtreme [~Dreamxtre@92.30.60.81] has joined #freemyipod
01:20 < mulenmar> TheSeven: Just tested installer-nano2g.ipodx, it works just fine again.
01:26 < mulenmar> TheSeven: Also I can verify that, after an intentional dirty shutdown, after the FTL check, iLoader doesn't load the OFW on touching the wheel. ^_^
01:26 * mulenmar applauds
01:28 < mulenmar> TheSeven: Oddly, I can't reproduce the backlight problem anymore either now.
01:30 -!- Dreamxtreme [~Dreamxtre@92.30.60.81] has quit [Ping timeout: 276 seconds]
01:31 -!- Dreamxtreme [~Dreamxtre@92.30.83.33] has joined #freemyipod
02:17 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Ping timeout: 264 seconds]
02:21 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
03:22 -!- MrShlee [~Default@182-239-156-197.ip.adam.com.au] has joined #freemyipod
03:43 -!- funman [~fun@122.143.66-86.rev.gaoland.net] has joined #freemyipod
03:43 -!- funman [~fun@122.143.66-86.rev.gaoland.net] has quit [Changing host]
03:43 -!- funman [~fun@rockbox/developer/funman] has joined #freemyipod
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:12 -!- funman [~fun@rockbox/developer/funman] has quit [Quit: free(random());]
06:33 -!- MrShlee [~Default@182-239-156-197.ip.adam.com.au] has quit [Quit: Leaving]
06:51 < fmibot> New commit by 3theseven (r205): Release iLoader v0.2.2, installer v0.2.1, emBIOS v0.1.1 and emBIOS Loader (nano2g) v0.1.1
06:52 < fmibot> r205 build result: All green!
07:03 < TheSeven> ok, r205 is available on the web site now
07:39 < mulenmar> Okay, uberissue here. Can't enter disk mode from emBIOS, which I need to do to restore with iTunes.
07:39 < mulenmar> I get a "*PANIC* Failed to unmount flash: 1"
07:40 < mulenmar> This is after I tried updating Rockbox while Rockbox was running (which I had a bad feeling about anyway).
07:40 < mulenmar> When I disconnected, Rockbox offered to reboot itself. Something about ROLO (Rockbox Loader) came up, and it tried to reboot.
07:41 < mulenmar> Now I can't load iLoader. I tried entering Disk Mode to rerun ipodpatcher or restore with iTunes, but I get the panic.
07:41 < mulenmar> I'm stumped as to what I can do now.
07:42 < TheSeven> "updating Rockbox while Rockbox was running" should work perfectly, and always did for me
07:43 -!- funman [~fun@rockbox/developer/funman] has joined #freemyipod
07:43 < TheSeven> this actually looks like your ftl is broken, which should be fixed by running disk mode, which you can't run because of that :P
07:44 < TheSeven> you'll probably have to fire up disk mode via usb now
07:44 < TheSeven> which means you'll need to make your libusb work :)
07:44 * TheSeven has to run now
07:44 < TheSeven> I'll be back in about half an hour
07:44 < mulenmar> *sigh* I'll see what I can do from Arch Linux. >_>
07:52 < mulenmar> Actually, I can't even shut my Nano2G off now. v_v
08:11 < TheSeven> hm, poweroff from the iloader recovery menu should work
08:13 < mulenmar> "Could not load iLoader theme. It was probably deleted. Please choose an option below:" menu? Okay, trying the Power off option.
08:14 < mulenmar> *PANIC* Failed to unmount flash: 1" o_o
08:15 < TheSeven> ah, right
08:15 < TheSeven> it tries to unmount the ftl before shutting down
08:15 * TheSeven wonders why the unmount actually fails
08:16 < mulenmar> Well, Rockbox tried to do something with RoLo before rebooting, so it probably screwed something up.
08:16 < TheSeven> btw, if you want to power it off no matter what it does, reset it, and immediately when the backlight turns off, switch on the hold switch
08:16 < TheSeven> this will power it down by hardware means
08:17 < TheSeven> did the new rockbox version boot just fine after rolo'ing, or did it lock up, or what did it do?
08:17 < mulenmar> I can't even load iLoader, let alone get to Rockbox. <8~(
08:18 < TheSeven> rolo was supposed to boot directly into the new rockbox version without really rebooting the device
08:18 < TheSeven> so i wonder what it actually did
08:21 < TheSeven> did it lock up on a screen saying "ROLO\nExecuting..." or something similar?
08:27 < fmibot> New commit by 3theseven (r206): Make ftl_sync return success if the FTL wasn't even mounted and release emBIOS 0.1.2
08:27 < fmibot> r206 build result: All green!
08:29 -!- mulenmar [~mulenmar@74-132-43-158.dhcp.insightbb.com] has quit [Quit: Leaving]
08:32 < TheSeven> r206 released
08:38 -!- mulenmar [~mulenmar@74-132-43-158.dhcp.insightbb.com] has joined #freemyipod
08:39 < TheSeven> re
08:39 * TheSeven just released emBIOS 0.1.2, which should hopefully not behave as badly in this situation
08:41 < TheSeven> two more questions: is embios complaining about FTL trouble on boot?
08:41 < TheSeven> and how exactly did rolo behave?
08:42 < mulenmar> Unfortunately I didn't note how the Rolo configuration behaved. But emBIOS didn't complain about FTL trouble, just about iLoader.
08:42 < mulenmar> Then it paniced.
08:42 < TheSeven> hm, it *is* probably complaining, you're just not quick enough to see that before iloader comes up
08:43 < TheSeven> do you remember if rockbox locked up after trying to rolo the new build, or did it boot that successfully and the trouble just began when rebooting the next time?
08:43 < mulenmar> Doesn't say anything about FTL.
08:44 < mulenmar> It didn't boot the new build and I reset it. I don't remember if it locked up or told me to reset.
08:44 < TheSeven> it won't ever tell you to reset, so it probably locked up, for whatever reason
08:44 < TheSeven> if you choose "quit iloader", what does the console say?
08:45 < mulenmar> Just the emBIOS version, a blank line, and "iLoader terminated on user's behalf" as usual.
08:45 < TheSeven> damn
08:46 < TheSeven> so it's going down the really evil code path
08:46 * TheSeven wonders what the hell rockbox could have corrupted to make it fail to even mount the VFL
08:47 < TheSeven> any luck with pyusb?
08:47 < mulenmar> I gave up on that in Ubuntu.
08:47 < mulenmar> I'm installing Arch Linux on another laptop. That only has USB 1.1, but that shouldn't be an issue for this I'm sure.
08:48 < TheSeven> so you say you managed to install the latest pyusb and libusb, and libembios still complained about not being able to import usb.core?
08:49 < mulenmar> Yes.
08:49 < TheSeven> do you still have the old pyusb version installed? if yes, you might want to try removing that (probably the python-usb package)
08:50 < mulenmar> No, I tried removing that. Didn't matter.
08:52 < TheSeven> what's lying around in /usr/lib/python2.6/site-packages/usb?
08:52 < TheSeven> (or whatever python version you're using)
08:54 < mulenmar> That can't be right -- no site-packages directory there.
08:54 < TheSeven> hm, where did it install itself?
08:54 < TheSeven> maybe in /usr/local for some reason?
08:55 < funman> python2.somethingelse?
08:56 < mulenmar> /usr/local/lib/python2.6, looks like.
08:56 < mulenmar> Nothing listed there. I really hope I didn't screw something up, else I'll feel stupid.
08:57 < mulenmar> Meh, I was going to get rid of Ubuntu anyway.
08:58 * TheSeven suggests to run the pyusb installation again and have a look at what it actually installs
09:01 < mulenmar> That just puts a few lines of "running " various things, "Removing /usr/local/lib/python2.6/dist-packages/pyusb-0.4.2.egg-info", then "Writing /usr/local/lib/python2.6/dist-packages/pyusb-0.4.2.egg-info"
09:09 < TheSeven> well that points to where it thinks it installed itself
09:09 < TheSeven> try prepending /usr/local/lib/python2.6/dist-packages to the PYTHONPATH environment variable
09:13 < mulenmar> I'm beginning to think I messed up in the process of following the wiki. I just deleted the svn tree and I'm checking out again, starting over.
09:17 < mulenmar> Okay, and NOW it builds. *sigh*
09:18 < mulenmar> Now what?
09:21 < TheSeven> grab http://builds.freemyipod.org/embios/target/ipodnano2g/embios-ipodnano2g-r206.bin
09:21 < TheSeven> embios.py uploadfile 08000000 embios-ipodnano2g-r206.bin && embios.py execfirmware 08000000
09:24 -!- funman [~fun@rockbox/developer/funman] has quit [Quit: free(random());]
09:25 < mulenmar> Um, stupid question: where is embios.py after I  build emBIOS?
09:26 < TheSeven> embios/trunk/tools
09:26 < mulenmar> Okay. I need to be root, right?
09:32 < mulenmar> Again with the usb.core not found issue. *sigh* This will go better on Arch Linux, I'm sure. Trying to make this work on Ubuntu is a waste of time.
09:44 * TheSeven suspects the PYTHONPATH variable didn't survive the user switch
10:21 < user890104> Farthen: i came up with another idea for the nano 4g: you can load the exploit, then upload embios, upload the 1.0.4 FW, then delete the exploit and the ipod will continue to run 1.0.4, until the battery falls empty, or until you reset it (to test something for example) so even if you don't have a pc around, you won't be stuck with the ibugger loading screen
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:58 -!- mulenmar [~mulenmar@74-132-43-158.dhcp.insightbb.com] has quit [Ping timeout: 258 seconds]
12:05 -!- user890104 [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has quit [Ping timeout: 272 seconds]
12:19 -!- mulenmar [~mulenmar@74-132-43-158.dhcp.insightbb.com] has joined #freemyipod
12:53 -!- mulenmar [~mulenmar@74-132-43-158.dhcp.insightbb.com] has quit [Quit: Leaving]
12:54 -!- funman [~fun@rockbox/developer/funman] has joined #freemyipod
12:54 -!- mulenmar [~mulenmar_@74-132-43-158.dhcp.insightbb.com] has joined #freemyipod
13:01 < mulenmar> TheSeven: Alright, I've got the Arch Linux laptop setup. What were the required versions of libusb and pyusb again? libusb 0.1.12 is installed by default, but there's a PKGBUILD for libusb-beta 1.0.0 if I need that.
13:02 < TheSeven> in theory it should work with both
13:02 < TheSeven> the important thing is the pyusb version
13:02 < TheSeven> just grab the latest pyusb, that should work
13:02 < TheSeven> on linux, slightly older versions might work as well, on windows they won't
13:03 < mulenmar> There is a pyusb 0.4.3 and a pyusb 1.0.0_a0 (the latter of which I just installed)
13:05 < TheSeven> sounds good
13:11 < mulenmar> Okay, emBIOS directions in the wiki followed as far as they go. What was the command again? "python embios.py" something?
13:14 -!- user890104 [Venci@Venci-Notebook-WLAN.ipv6.6bez10.info] has joined #freemyipod
13:15 < TheSeven> 11:22] <TheSeven> grab http://builds.freemyipod.org/embios/target/ipodnano2g/embios-ipodnano2g-r206.bin
13:15 < TheSeven> [11:22] <TheSeven> embios.py uploadfile 08000000 embios-ipodnano2g-r206.bin && embios.py execfirmware 08000000
13:16 < mulenmar> Thanks!
13:18 < mulenmar> Do I have to do anything special with the iPod (beyond connecting it to the laptop)?
13:19 < mulenmar> Before running the command, I mean.
13:20 < mulenmar> Just go to "Quit iLoader", right?
13:20 < TheSeven> doesn't matter
13:26 < mulenmar> usb.core.USBError: could not set config 1: Connection timed out
13:27 < mulenmar> Ah, that was with the "Quit iLoader", didn't do that if I just left it at the "Could not load iLoader theme" menu.
13:27 < TheSeven> hm, shouldn't make a difference
13:27 < TheSeven> did you manage to upload the new build?
13:29 < mulenmar> No. The first half of the command runs just fine, then the *PANIC* Failed to unmount flash: 1 error pops up.
13:29 < mulenmar> emBIOS hold switch recovery mode time?
13:30 < TheSeven> haha, nasty kind of bug.
13:31 < mulenmar> The recovery mode, once I managed to time it right, doesn't help.
13:31 < mulenmar> Error: No emBIOS device found.
13:31 < TheSeven> you'll need to use embiosldr.py for that one
13:31 < TheSeven> just embiosldr.py run embios-ipodnano2g-r206.bin
13:32 < TheSeven> you could try just reflashing the bugger in place
13:32 < TheSeven> grab http://builds.freemyipod.org/embios/target/ipodnano2g/embios-ipodnano2g-r206.ucl in place
13:32 < TheSeven> instead*
13:32 * TheSeven wonders why he's typing crap today
13:33 < mulenmar> And I flash that with ipodpatch -a?
13:33 < TheSeven> nope
13:34 < mulenmar> Because there is no embiosldr.py that locate can find, and I just ran updatedb
13:34 < TheSeven> hmm, /me might have forgotten to add that to svn
13:35 < TheSeven> embios.py uploadfile 08000000 embios-ipodnano2g-r206.ucl && embios writebootflash a000 08000000 c000
13:35 < TheSeven> embios.py*
13:35 < TheSeven> once that completes, just reset it
13:38 < mulenmar> After it says "Writing boot flash memory . . . if this was not what you intended blah blah" it has "ERROR: problem with USB connection" -- but it DOESN'T panic
13:38 < mulenmar> Well, it doesn't SAY it panics
13:39 < mulenmar> Scrollwheel stops responding though.
13:39 < mulenmar> So I assume it really is panicing.
13:39 < TheSeven> hm it might have just ran into a USB timeout, flashing takes rather long (up to 5 seconds)
13:39 < TheSeven> just reset it and see what happens
13:40 < TheSeven> either it boots the new one, or it is stuck in the recovery loader now
13:40 < mulenmar> It's still at the "Could not load iLoader theme" menu.
13:40 < mulenmar> Still panics if I try to enter disk mode.
13:41 < TheSeven> so it apparently flashed nothing at all
13:41 < mulenmar> Nope.
13:42 < mulenmar> Tried running the second part of your command again, same result -- so obviously the FIRST half finished.
13:42 < fmibot> New commit by 3theseven (r207): Add embiosldr.py to svn
13:42 < fmibot> r207 build result: All green!
13:43 * mulenmar updates his svn tree
13:44 * TheSeven suggests to directly run diskmode (diskflsh-nano2g.bin) through embiosldr.py
13:45 < TheSeven> hmm, no, that probably won't work
13:45 < TheSeven> embiosldr.py run embios-ipodnano2g-r206.bin && embios.py upload 08000000 diskflsh-nano2g.bin && embios execfirmware 08000000
13:45 < TheSeven> that should finally get you from the recovery mode to disk mode
13:46 < mulenmar> Exception: Could not find specified device (generation = 0)
13:46 < mulenmar> I am of course running these as root and prepending them with "python"
13:48 < mulenmar> Should I try the earlier embios.py command, but replace it with diskflsh-nano2g.bin? And/Or with a different address?
13:50 < TheSeven> you're in recovery mode? (the hold switch thing?)
13:50 < TheSeven> regarding the timing: reset it and as soon as it shuts off, flick the hold switch with the other hand
13:50 < TheSeven> it will probably stay off
13:50 < mulenmar> Oh. No, I'll get back in there.
13:51 < TheSeven> then, briefly switch the hold switch off and on again (for like a quarter of a second)
13:51 < TheSeven> if it stays off, keep the hold switch off a bit longer
13:51 < TheSeven> you'll find the sweet spot rather quick :)
13:53 < mulenmar> Ugh. FINALLY got it again.
13:53 < mulenmar> usb.core.USBError: Connection timed out
13:54 < TheSeven> hmm
13:54 < TheSeven> you should probably split that command and run its parts individually
13:54 < mulenmar> This laptop is USB 1.1, would that make a difference?
13:54 < TheSeven> especially the first and second part will need a bit of delay in between
13:54 < TheSeven> it shouldn't
13:54 < mulenmar> I tried that, it had the timeout in the FIRST command
13:55 < mulenmar> This is getting worrysome.
13:55 < TheSeven> yeah, it's really not nice when the tools don't work...
13:56 * mulenmar tries nice -n -16 without success
13:57 < TheSeven> that shouldn't make a difference
13:57 < TheSeven> actually USB1 *might* be the cause
13:58 < mulenmar> Well that's not good. I'll have to swap the hard drive out into the other laptop.
13:59 < TheSeven> there might be a software woraround
13:59 < TheSeven> workaround*
13:59 < mulenmar> Increase the timeout length in the script?
14:00 < TheSeven> libembiosldr.py, line 45/46: replace 528 by 48
14:04 < TheSeven> embiosldr is still using buggy old ibugger code, that isn't 100% compliant to the usb specs
14:05 < TheSeven> reducing the transfer size should circumvent its bugs
14:05 < mulenmar> Well, that gets it past the first part of the command.
14:05 < mulenmar> Then I get a "ERROR: no such command"
14:05 < TheSeven> s/upload/uploadfile/
14:06 * TheSeven is still quite used to the old syntax
14:06 < mulenmar> Ah, it should be uploadfile
14:09 * Farthen can always change the syntax...
14:09 < mulenmar> Heh, looks like a few other places need the timeout extended to work with USB1.1, I can't just tell it to reset or poweroff.
14:10 < TheSeven> those also get timeouts?
14:10 < mulenmar> Yeah
14:10 < TheSeven> the usb speed shouldn't be much of a problem here
14:11 < mulenmar> But on reset, the panics STILL happen.
14:11 < TheSeven> timeouts are usually caused by the device doing a task that takes more than half a second before it responds, or more likely the device not responding at all
14:11 < TheSeven> the flash unmounting panic?
14:11 < TheSeven> with r206?
14:12 < mulenmar> Yes, and those files you told me to download.
14:13 < TheSeven> hm, what the hell is happening then?
14:13 * mulenmar tries the embios-ipodnano2g.bin file
14:13 < TheSeven> - the ftl apparently *can* be mounted
14:13 < TheSeven> - but it *can't* be read from or synced
14:13 < TheSeven> - nothing should have been written since boot, yet it can't be synced
14:13 < TheSeven> syncing should just return success if nothing was written or the ftl wasn't even mounted
14:14 * mulenmar realizes he misread
14:14 < TheSeven> that's not consistent
14:15 < mulenmar> I have no clue what's going on either.
14:16 < TheSeven> hmm, I'd really like to know how unmounting can still fail
14:17 < TheSeven> let me compile a debug build
14:21 -!- MrShlee [~Default@182-239-156-197.ip.adam.com.au] has joined #freemyipod
14:22 < TheSeven> http://files.freemyipod.org/embios-debug.bin
14:22 -!- MrShlee [~Default@182-239-156-197.ip.adam.com.au] has quit [Client Quit]
14:22 < TheSeven> after booting that through recovery mode, iloader should start up
14:22 < TheSeven> don't touch anything, just run embios.py console
14:22 < TheSeven> it should spit out a bunch of debug messages
14:25 < mulenmar> And I get that on the iPod with "embiosldr.py run . . . . . . " right?
14:25 < TheSeven> yep
14:27 < mulenmar> init.c:189: Initializing storage drivers...
14:27 < mulenmar> target/ipodnano2g/ftl.c:2552: FTL: No DEVICEINFO found!
14:28 < mulenmar> init.c:191: Initializing storage subsystem...
14:28 < mulenmar> init.c:193: Reading partition tables...
14:28 < mulenmar> disk.c:88: Bad boot sector signature
14:28 < mulenmar> init.c:195: Mounting partitions...
14:28 < mulenmar> disk.c:88: Bad boot sector signature
14:28 < mulenmar> init.c:201: Finished initialisation sequence
14:29 < mulenmar> file.c:73: open("/iLoader/boot.embiosapp",0)
14:29 < mulenmar> fat.c:1692: fat_open(0), entry 0
14:29 < mulenmar> fat.c:2201: fat_readwrite(file:0,count:0x1,buf:9FC5150,read)
14:29 < mulenmar> fat.c:2203: fat_readwrite: sec=0 numsec=0 eof=0
14:30 < mulenmar> fat.c:705: cache_fat_sector() - Could not read sector 0 (error -1)
14:30 < mulenmar> fat.c:945: read_fat_entry() - Could not cache sector 0
14:30 < mulenmar> fat.c:2152: transfer(s=0, c=1, read)
14:30 < mulenmar> fat.c:2176: transfer() - Couldn't read sector 0 (error code -1)
14:30 < TheSeven> hmm you should probably pastebin such things
14:30 < mulenmar> Oh, sorry.
14:31 < TheSeven> and "No DEVICEINFO found" looks really, really bad
14:31 < mulenmar> That's almost all of it though, and I suspect the fault lies early on.
14:32 < TheSeven> and execfirmware *still* results in a panic with that build?
14:32 < mulenmar> Whoa, what the heck -- somehow I got into disk mode while I was trying to reset!
14:32 < mulenmar> I can't mount it though.
14:33 < TheSeven> disk mode might sometimes take quite a bunch of seconds to boot if the the flash is borked
14:33 < mulenmar> No /dev/sd** file for it.
14:33 < TheSeven> unplug/replug it
14:33 < mulenmar> Dang it -- it rebooted.
14:33 < TheSeven> disk mode doesn't soft disconnect properly to trigger re-enumeration
14:33 < TheSeven> this will probably have fixed it though
14:34 < TheSeven> just booting disk mode once is usually sufficient
14:34 < mulenmar> Nope, still get the panics.
14:34 < mulenmar> It rebooted when I disconnected.
14:35 < TheSeven> hmm this is getting weird
14:35 < TheSeven> hm, it could mean that the flash isn't even powered up
14:36 * TheSeven would try the brute force way now
14:36 < mulenmar> A soldering iron?
14:36 < TheSeven> do you have a copy of norflash.bak around somewhere?
14:37 < TheSeven> if yes, i'd just flash the apple bootloader
14:37 < mulenmar> Afraid I don't. Except ON the iPod.
14:37 < TheSeven> try getting into disk mode again
14:37 < mulenmar> I know the firmware file downloaded from iTunes is on my other computer.
14:38 < TheSeven> unplug as soon as you've ran the execfirmware command
14:38 < mulenmar> And I have no idea how I managed to get to disk mode!
14:38 < TheSeven> reconnect about a second later
14:39 < mulenmar> That didn't do anything.
14:40 < TheSeven> did it panic?
14:40 < mulenmar> No. And I tried selecting the disk mode option afterwards, and the screen went black, but with the backlight on, then rebooted.
14:40 < TheSeven> hm, so at least the panic seems to be gone
14:41 < mulenmar> During the reboot, the FTL damaged thing came up briefly, then I was back at the "Could not load iLoader theme" menu
14:41 < TheSeven> oh, that's a good sign
14:41 < mulenmar> Upon trying to access disk mode, same panic after an error message
14:41 < TheSeven> that means that at least the VFL is functional again
14:42 < mulenmar> Invalid block type FF while reading vPage 875264
14:42 < mulenmar> FTL recovery failed. Use disk mode to recover
14:42 < TheSeven> hm. not that good.
14:44 < TheSeven> and if you now try to enter disk mode (using the debug build)?
14:44 < mulenmar> By the unplug-plug thing? That didn't do anything before. *tries again*
14:45 < TheSeven> upload the debug build through embiosldr.py
14:45 < TheSeven> iloader should come up and complain
14:45 < TheSeven> unplug it, select disk mode, and re-plug it as soon as you've selected disk mode
14:46 < mulenmar> iLoader, no. Complaints, yes. Multiple panics.
14:46 < TheSeven> multiple panics?
14:46 < TheSeven> what kind of panics?
14:46 < mulenmar> *PANIC* nand_read_page: Misaligned spare buffer at E0003003 (bank 0, page 570465048)
14:46 < mulenmar> *PANIC* (unreadable)
14:46 < TheSeven> urgh
14:46 < mulenmar> *PANIC* Hit reset vector!
14:47 < mulenmar> *PANIC* Hit reset vector! Hit reset vector!
14:47 < TheSeven> ok, that looks like a combination of memory corruption and execution bouncing around in a bunch of places where it really shouldn't be
14:47 < mulenmar> I didn't even get a chance to unplug it.
14:48 < TheSeven> is the kernel still alive after that?
14:48 < TheSeven> (can you reach it through embios.py?)
14:48 < mulenmar> I just reset it. 8~/ Let me try to duplicate.
14:49 < TheSeven> what happens if you try to embiosldr.py run diskflsh-nano2g.bin directly?
14:50 < mulenmar> (And no, I can't reach the kernel)
14:50 < mulenmar> I'll find out.
14:51 < mulenmar> "ERROR: No emBIOS device found!" in recovery mode.
14:51 < TheSeven> embiosldr.py, not embios.py
14:53 < mulenmar> Connected to emBIOS Loader Recovery Mode on iPod Nano 2G, USB version 1
14:53 < mulenmar> Uploading diskflsh-nano2g.bin to 0x 8000000....... done
14:54 < mulenmar> Passing control to code at 0x 8000000... done
14:54 < mulenmar> It's at the same screen.
14:54 < mulenmar> "Connect via USB"
14:54 < TheSeven> hmm
14:55 < TheSeven> so apparently the system information struct didn't survive from a previous embios boot
14:55 * TheSeven wonders why
14:56 * mulenmar hopes we don't have to resort to writebootflash, as that sounds risky
14:56 < TheSeven> it's not as risky as the warning might suggest
14:56 < mulenmar> What about runfirmware?
14:56 < TheSeven> runfirmware is basically uploadfile + execfirmware
14:57 < mulenmar> Ah.
14:57 * TheSeven digs in his tool collection
14:57 < mulenmar> I'm AFK for the next five minutes.
14:58 < TheSeven> try "embiosldr.py run"ning http://files.freemyipod.org/resetftl.bin
14:58 < TheSeven> that will hopefully wipe away whatever is left of the FTL/VFL
14:59 < TheSeven> this should avoid that embios bootup crash and hopefully allow us to reinitialize everything cleanly using disk mode
15:07 < mulenmar> Exception: Unaligned data write!
15:07 < TheSeven> pad that file to a 4 byte alignment
15:08 < mulenmar> I don't know how to do that.
15:08 < TheSeven> (append 2 garbage bytes)
15:09 < TheSeven> ok, I uploaded a new file that should weork
15:09 < TheSeven> work*
15:10 < mulenmar> That seemed to work.
15:13 < mulenmar> Now to see if I can access disk mode.
15:13 < mulenmar> Nope.
15:14 < mulenmar> Still panics.
15:16 < TheSeven> which panic this time?
15:17 < mulenmar> The old, single one.
15:17 < TheSeven> the cannot unmount flash one?
15:18 < TheSeven> what does the debug log say?
15:18 < mulenmar> Debug log after panic? I'll find out.
15:18 < TheSeven> or even before the panic
15:19 < TheSeven> the most interesting part is what it did while trying to mount
15:19 < TheSeven> but it should still be possible to dump the log after the panic
15:19 < mulenmar> Well, as I expected, I can't get a console after the panic.
15:19 < mulenmar> "Well duh!"
15:19 < TheSeven> try unplugging/replugging and running embios.py console again
15:20 * TheSeven wonders what kind of panic this is
15:21 < TheSeven> hm, it's a fatal one, for no apparent reason
15:21 < mulenmar> Unplugged, plugged, ran "python embios.py console", now it's just sitting there.
15:21 < mulenmar> Ah, "ERROR: No emBIOS device found!"
15:22 < fmibot> New commit by 3theseven (r208): Reduce severity of ftl_sync panic to KILLUSERTHREADS.
15:22 < funman> REPLACE BIOS AND CONTINUE Y/N
15:22 < fmibot> r208 build result: All green!
15:24 * TheSeven just updated http://files.freemyipod.org/embios-debug.bin
15:26 * mulenmar uploads and runs embios-debug
15:29 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
15:31 < mulenmar> Well, I've got the embios-debug running.
15:31 < mulenmar> Now it's back at the "Could not find iLoader theme" screen again.
15:33 < mulenmar> From the console, long list of FTL: VFL: Reading page 865535-875264 messages.
15:33 < mulenmar> And the "invalid block type FF while reading vPage 8752654" of course.
15:35 < mulenmar> Whole  thing at http://pastebin.com/kpZw4SmZ
15:37 < TheSeven> mulenmar: and this thing does panic with "can't unmount ..." when trying to run disk mode?
15:38 < mulenmar> It goes to a black screen, then reboots.
15:38 < mulenmar> Black screen + bright backlight, that is.
15:39 < TheSeven> via execfirmware or iloader?
15:39 < mulenmar> Well I don't get any debug info from "python embios.py console", so I assume it's what's left of iLoader.
15:40 < fmibot> New commit by 3theseven (r209): Revert accidentally committed debug flags from previous commit
15:40 < fmibot> r209 build result: All green!
15:40 < fmibot> New commit by 3theseven (r210): Make sure the ftl_initialized variable is initialized to false
15:41 < fmibot> r210 build result: All green!
15:41 * TheSeven updated embios-debug.bin once again
15:42 < TheSeven> the "can't unmount" panic should be gone forever now
15:43 < TheSeven> and i meant what you did to get that black screen + reboot
15:44 < mulenmar> Oh. I got the black screen with the embios-debug.bin, and it rebooted to what's on the iPod.
15:45 < TheSeven> how did you try to launch disk mode?
15:45 < mulenmar> Didn't get much of a chance. 8~/
15:45 < TheSeven> by uploading the file and running execfirmware, or by choosing the option from the iloader menu?
15:45 < TheSeven> ah
15:45 < TheSeven> embios crashed while booting?
15:46 < TheSeven> how does the new file behave?
15:46 < mulenmar> As for this new embios-debug.bin: *PANIC* nand_read_page: Misaligned spare buffer at 0A00000A (bank 0, page 506107)
15:47 < TheSeven> dammit, it's hitting a buffer overflow somewhere because of currupted (and not properly checked) flash data
15:47 * TheSeven wonders how you managed to break the FTL in the first place
15:48 < mulenmar> Well it KEPT saying in the debug logs that FTL recover failed because of "Invalid block type FF while reading vPage 875264"
15:48 < mulenmar> *recovery
15:49 * TheSeven would like to just wipe that flash
15:51 * mulenmar would go OfficeSpace on it if he had another Nano2g to help with testing with
15:52 * TheSeven thinks he knows why resetftl failed
15:57 < mulenmar> So how do we fix it?
15:57 < mulenmar> Change it to reset type FF blocks to something empty?
15:58 < TheSeven> run a fixed version of resetftl
15:59 < TheSeven> http://files.freemyipod.org/resetftl.bin
15:59 < TheSeven> should work now
16:02 < mulenmar> It ran, and actually said "Wiping flash." Then rebooted. Trying for disk mode now . . .
16:02 < mulenmar> . . . and *PANIC*
16:02 < TheSeven> which panic?
16:03 < mulenmar> Failed to unmount flash: 1
16:03 < mulenmar> The "invalid block type" error is still there too.
16:04 < TheSeven> this is really weird
16:04 < TheSeven> resetftl failing, ftl_sync failing even though it just *can't* when looking at the code
16:06 < mulenmar> After resetftl runs and the Nano reboots, the "FTL damaged" scan runs too, oddly enough.
16:07 < mulenmar> And the "invalid block type" is still there.
16:07 < mulenmar> Could try forcibly changing that block as a workaround?
16:07 < TheSeven> actually i'd like to forcibly change all blocks
16:08 < mulenmar> Is that safe? (*really doesn't know*)
16:09 * mulenmar hopes you don't mean with a hammer
16:12 < TheSeven> well, it's not much less force than a hammer...
16:12 < TheSeven> but it should force it to fail cleanly and recover instead of crashing
16:13 < TheSeven> i've updated resetftl.bin again
16:13 < TheSeven> this time it should report if anything went wrong
16:14 < TheSeven> ...and updated once again to retry blocks if they fail...
16:14 -!- user890104_ [~Venci@212.233.135.74] has joined #freemyipod
16:14 < mulenmar> Well, it didn't say anything about anything going wrong
16:14 < mulenmar> Okay, so I should download it again?
16:14 < TheSeven> when did you last download it?
16:15 -!- user890104 [Venci@Venci-Notebook-WLAN.ipv6.6bez10.info] has quit [Disconnected by services]
16:15 < TheSeven> after [18:13] <TheSeven> i've updated resetftl.bin again?
16:15 -!- user890104_ is now known as user890104
16:15 < TheSeven> if yes, you don't need to re-download it, as it didn't detect errors anyway
16:16 < mulenmar> I downloaded after you said "i've updated resetftl.bin again", then saw you say ". . . and updated once again . . ."
16:16 < TheSeven> and that one didn't report any problems?
16:17 < mulenmar> NO
16:17 < mulenmar> Oops, sorry hit the Caps Lock by mistake
16:17 < mulenmar> No, it didn't say anything.
16:20 < mulenmar> Still did no good. Tried it again, it says "Wiping flash" but doesn't do anything at all.
16:20 < TheSeven> how long does it take?
16:20 < mulenmar> Before, a second or two.
16:21 < mulenmar> Now, it's just doing nothing. No progress bar movement or even starting. (same resetftl.bin)
16:21 < TheSeven> aha...
16:23 < TheSeven> ok, can you re-download it again?
16:23 < TheSeven> it really shouldn't stall without saying anything now
16:25 < mulenmar> Took about 10 seconds. Then it rebooted, ran an FTL check, and came to the menu.
16:25 < mulenmar> Trying for disk mode again.
16:25 < TheSeven> damn
16:25 < mulenmar> Nope, same "Failed to unmount flash" panic.
16:25 < TheSeven> now *this* is weird
16:26 < TheSeven> i'd really like to have a memory dump of that state
16:26 < TheSeven> can you do the following?
16:27 < TheSeven> embios.py downloadfile 22000000 2c000 sram.bin
16:27 < TheSeven> embios.py downloadfile 09f80000 80000 sdram.bin
16:27 < TheSeven> and zip up and send me those files?
16:27 < mulenmar> From the panic screen? Nope. Times out.
16:29 < TheSeven> what's the md5sum of the embios-debug.bin you're using?
16:29 < TheSeven> should be bb3cdfbbd130157fbb1b83108ac43ba8
16:29 < mulenmar> bb3cdfbbd130157fbb1b83108ac43ba8  embios-debug.bin
16:30 < TheSeven> hmm
16:30 < mulenmar> Wait, you mean boot the embios-debug.bin, get the panic, then try to downloadfile?
16:30 < TheSeven> yes
16:35 < mulenmar> I hit the multi-PANIC starting with "nand_read_page: Misaligned spare buffer at 0A00000A (bank 0, page 506364) if I try to load embios-debug.bin with embios.py
16:36 < mulenmar> With embiosldr.py run, it loads but reboots if I try to open disk mode.
16:38 < TheSeven> try a second time
16:39 < TheSeven> if disk mode finds something to clean up, it will just reboot
16:40 < mulenmar> Tried it, it rebooted again. FTL cleanup.
16:40 * mulenmar tries a third time
16:44 < mulenmar> Still reboots. I tried sending it right back into recovery mode and loading the debug again, but it doesn't respond to controls.
16:44 < mulenmar> But I can dump
16:45 < TheSeven> but the panic has finally gone?
16:48 < mulenmar> No, it's just locked up at the "Can not find iLoader theme" screen.
16:48 < TheSeven> ok
16:48 < mulenmar> Also, I have no idea how to send files over IRC.
16:49 -!- funman [~fun@rockbox/developer/funman] has quit [Quit: free(random() + malloc(random()));]
16:49 * mulenmar looks it up
16:50 < TheSeven> so how is it behaving now?
16:51 < TheSeven> if embios works as expected, i don't need the memory dump
16:51 < TheSeven> and sending files over irc rarely works at all, better use a file hosting site
16:51 < mulenmar> It's just at the "Can not find iLoader theme" screen, and does not respond to input.
16:51 < TheSeven> hmm, but you did turn the hold switch off, did you? :P
16:52 < mulenmar> *facepalm*
16:52 < mulenmar> Yes. >_>
16:54 < mulenmar> So I guess those dumps would be worthless? Or would you still be able to use whatever part is about the condition of the FTL and such?
16:57 < TheSeven> not much
16:57 < TheSeven> i had hoped to be able to debug the panic that way
16:57 < mulenmar> Well, it just reboots if I try to make it panic through the disk mode entry.
16:59 < TheSeven> so the ftl is apparently in a shape that's bad enough for disk mode to fail
16:59 < TheSeven> we really need to wipe that thing, but how?
16:59 < TheSeven> why for heaven's sake does resetftl fail?
16:59 < mulenmar> Whoa, power off works from embios-debug.bin.
16:59 < mulenmar> Not that that helps much.
16:59 < TheSeven> as expected.
17:00 < TheSeven> you could even boot the apple firmware now :)
17:00 < mulenmar> It just sends up a panic with what's on the iPod.
17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection]
17:00 < mulenmar> Even now.
17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod
17:00 < TheSeven> yes, the flashed version is of course the known-broken one
17:00 < mulenmar> No way to load embios-debug and connect to iTunes to restore, is there?
17:01 < TheSeven> it would be, if disk mode wouldn't be failing
17:01 < TheSeven> and the latest resetftl didn't get stuck?
17:02 < mulenmar> No.
17:02 < TheSeven> and took like 2 seconds again?
17:02 < mulenmar> 10.
17:02 < TheSeven> no message below the status bar?
17:02 < mulenmar> Don't remember, I'll do it again.
17:03 < mulenmar> No, nothning.
17:03 < mulenmar> -nothning +nothing
17:04 < TheSeven> does the debug log still complain about that 0xff-typed vpage?
17:04 < mulenmar> And it runs the FTL check again when it reboots.
17:04 < TheSeven> or is it back to "no DEVICEINFOSIGN"?
17:06 < mulenmar> Still complains about Invalid block type FF.
17:06 < mulenmar> Same dump as I put up at http://pastebin.com/kpZw4SmZ earlier.
17:07 < TheSeven> hm, usually it was sufficient to erase bank 0 block 0 page 0 to make it wipe everything
17:08 < mulenmar> This is hardly a "usual" problem, though.
17:09 < mulenmar> This is more like "installing Windows 98SE, the updates, 98SE2ME, and 98lite in the wrong order"-type problem.
17:13 -!- benedikt93 [~benedikt9@pD9E27250.dip.t-dialin.net] has joined #freemyipod
17:13 -!- benedikt93 [~benedikt9@pD9E27250.dip.t-dialin.net] has quit [Changing host]
17:13 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
17:17 * TheSeven comes back with a hammer
17:17 < TheSeven> try http://files.freemyipod.org/embios-wipe.bin
17:18 < TheSeven> it will start spitting out thousands of lines on the LCD
17:18 < TheSeven> it should also get printed to the usb console, so you can grab it
17:18 < mulenmar> embios.py run embios-wipe.bin?
17:18 < TheSeven> embiosldr.py
17:19 < mulenmar> Yeah, that's what I meant to put. #oops
17:19 < TheSeven> it's an embios build that will wipe the flash if ftl recovery is needed but fails
17:20 < TheSeven> if there are any non-zero status codes (the last number on each line), please let me know
17:20 * TheSeven will be back in 20 minutes
17:23 < mulenmar> It sent absolutely nothing to the LCD
17:24 < mulenmar> And the console only said "The FTL seems to be damaged. Forcing check. Scanning flash . . . Invalid block type FF while reading vPage 875264. FTL recovery failed. Use disk mode to recover."
17:59 < TheSeven> mulenmar: please re-download the file
17:59 < TheSeven> it should do more now :)
18:04 < mulenmar> Oh, it did plenty more, and all the status codes I caugth were zero, but the panic STILL happens if I try to use disk mode.
18:07 < TheSeven> there shouldn't *ever* be a panic with that build!
18:08 < mulenmar> The panic was afterward, when I tried to access disk mode -- I'll try it again.
18:09 < mulenmar> Disk mode from embios-wipe: Reboot
18:09 < TheSeven> how long did the wiping take?
18:09 < mulenmar> About 20-30 seconds, I guess. I did it twice, second time dumping console to a text file. All status zero
18:13 < mulenmar> *sigh* Is it possible to create a program to just completely replace the screwed-up emBIOS instead of trying to fix what's there?
18:15 < TheSeven> embios isn't the culprit here
18:15 < TheSeven> the FTL is what went bad
18:15 < TheSeven> and apparently we don't even manage to wipe that away
18:18 < mulenmar> Ah. Whatever happened, the Rockbox code for "Ooh, I've been updated while I was hooked up. Do you want me to blah blah blah" caused it.
18:19 < mulenmar> Something about RoLo. Since there wasn't a RoLo installed, but iLoader, something got screwed up.
18:20 < TheSeven> RoLo is a mechanism to do in-place updates of rockbox
18:20 < TheSeven> it has nothing to do with the bootloader at all
18:20 < mulenmar> Something should probably be done about that too, so it refuses to do anything if iLoader is detected, in case we can't figure out how to fix it.
18:21 < TheSeven> as i said, this isn't related to iloader at all
18:21 < TheSeven> i have no idea why rolo crashed, but that happens from time to time, probably because of a icache issue
18:23 < mulenmar> So we're really in a better position to fix this since iLoader is on there, with emBIOS's debugging capabilities? Cool.
18:24 < TheSeven> exactly.
18:24 < TheSeven> i'm wondering what would happen if the apple bootloader would be flashed now
18:28 < mulenmar> Well how do I extract that, since I can't do it from iTunes?
18:29 < TheSeven> not even itunes can do it
18:30 < mulenmar> That's what I said -- how do I extract and install it since I can't do it from iTunes?
18:31 < TheSeven> the problem is that the uninstaller won't work without a working FTL
18:32 < mulenmar> Is there a way to change how that one, individual block is marked? To make it valid, even if empty?
18:32 < mulenmar> ie mark it empty
18:34 < TheSeven> yes - by erasing it
18:35 < TheSeven> exactly what we're doing all the time
18:35 < TheSeven> and i have no idea why it doesn't work
18:35 < mulenmar> It's somehow resisting the cha--- wait, maybe this is SSD degration that was exposed by the FTL screwup
18:36 < mulenmar> And that one block is broken?
18:36 < TheSeven> it's not a single broken block
18:36 < TheSeven> it's a hundred blocks that have valid contents even though they have been erased, until it even reaches that point
18:38 * mulenmar is out of ideas 8~(
18:38 * TheSeven too
18:39 < mulenmar> So basically it's partially bricked.
18:39 < TheSeven> you could try to boot the apple bootloader
18:39 < TheSeven> but that's going to be a bit tricky
18:41 < mulenmar> But you said we have to fix the FTL to make that work. And we can't do that.
18:41 < mulenmar> So far.
18:46 < TheSeven> if we just boot it, it *might* fix it by itself
18:47 < mulenmar> And if it doesn't . . . we no longer have emBIOS's debugging capabilities.
18:48 < mulenmar> Although I don't see any alternatives that don't cost ~US$45. . . .
18:48 < TheSeven> we can just boot it without permanently flashing it
18:48 < TheSeven> after a reset it will be gone again
18:49 < mulenmar> Alright. I'll try to track down the file iTunes downloaded for it so we can extract stuff.
18:52 < TheSeven> that file won't help us at all
18:53 < mulenmar> Oh? I thought that contained the bootloader too.
18:53 < TheSeven> yes, packaged into an encrypted installer
18:53 < mulenmar> *sigh*
18:54 < mulenmar> Next time, I'm getting an iRiver or something.
18:54 < mulenmar> Or making my own.
18:54 < mulenmar> This is ridiculous.
18:54 < TheSeven> the main problem is that we need to run the bootloader from the sram
18:56 < mulenmar> I've got that sram.bin dump from earlier. Would it be in that, or do you mean we need to force the bootloader into the sram somehow?
18:59 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Lämnar]
19:08 < TheSeven> http://files.freemyipod.org/loader.bin
19:09 < TheSeven> embios.py uploadfile 08000000 loader.bin && embios.py execfirmware 08000000
19:12 < mulenmar> *PANIC* Failed to unmount flash: 1
19:13 * mulenmar tries embiosldr.py
19:13 * TheSeven is getting annoyed by mulenmar always using the known-broken embios version to test things
19:14 < TheSeven> you'll *always* have to use one of the new ones I supplied, or you'll *always* get those panics
19:14 < TheSeven> but embiosldr might work, too
19:15 < mulenmar> I *did* use the newer version, TheSeven.
19:15 < TheSeven> the new version *can't* panic that way
19:17 < mulenmar> If I did that from recovery mode, I got an error of "Problem with USB connection." Repeatedly.
19:17 < mulenmar> ANYWAY, the screen says "Unified iBugger Loader, etc etc
19:18 < TheSeven> hm, it worked through embiosldr for me
19:18 * mulenmar isn't so stupid as to try the known-broken thing repeatedly hoping for the same result as the first resort until he's been awake for 30 hours or more.
19:18 < mulenmar> embiosldr worked here too.
19:21 < mulenmar> It says "USB init... ok". What now?
19:23 < TheSeven> http://files.freemyipod.org/ibugger.zip
19:23 < TheSeven> extract that, and run the following:
19:26 < TheSeven> ibugger.py upload 22000000 norboot.8701 && ibugger.py execute 22000800
19:28 < mulenmar> "usb.core.USBError: Connection timed out" again
19:29 < TheSeven> at which step?
19:29 < mulenmar> First.
19:29 < TheSeven> disconnect/reconnect in case you haven't done that yet after launching ibugger
19:32 < mulenmar> No difference.
19:33 < TheSeven> try resetting and starting over
19:33 < TheSeven> oh, wait, this is that usb1 laptop, right?
19:34 < TheSeven> you'll have to apply the same fix to libembios.py
19:34 < TheSeven> (s/528/48/)
19:38 < mulenmar> To libembios.py? There's no 528 in that entire file. 8~/
19:39 * mulenmar looks in libibugger.py too, just in case . . .
19:40 < TheSeven> add the following after line 49 ("self.type = self.type + 1"):
19:40 < TheSeven> self.maxin = self.maxout = 48
19:40 < TheSeven> with the same indention
19:46 < mulenmar> Okay, that gets it to upload. But the second part doesn't work.
19:47 < mulenmar> "execute" requires a stack, or something, so it's not recognized.
19:47 -!- chawsum [~chi1@h12n1fls304o1039.telia.com] has joined #freemyipod
19:47 < TheSeven> oh yeah
19:47 < TheSeven> ibugger.py execute 22000800 2202c000
19:48 < mulenmar> Black apple on a white background? And then goes to the "Could not load iLoader theme".
19:48 < mulenmar> Should the uninstall work now?
19:49 < TheSeven> is there still ftl trouble?
19:49 < TheSeven> does disk mode work?
19:52 < chawsum> hey, is it possible to run ipodlinux on nano 2g, or only rockbox?
19:52 < TheSeven> no, ipodlinux has not been ported to the 2g nano
19:53 < chawsum> okay
19:53 < chawsum> no biggie, rockbox is running fine :)
19:54 < mulenmar> Well, TheSeven,  the apple disappears and that "Could not load iLoader theme" menu loads. The version number shows it to be the emBIOS on the iPod. Going to disk mode results in our lovely "Failed to unmount flash" panic.
19:55 < mulenmar> Nothing showed up about FTL scan, so I assume it didn't see any trouble.
19:55 < TheSeven> so it didn't help at all
19:55 < mulenmar> Nope.
19:55 < mulenmar> Soldering iron -> DFU mode?
19:55 < TheSeven> that won't help either
19:56 < mulenmar> So we're out of options?
19:57 < TheSeven> we need to figure out what's wrong with that flash
20:02 * TheSeven will have another try at making it erase the flash
20:06 < mulenmar> Well considering I just found out that my grandfather has cancer, I'll be away from keybard for about twenty minutes or so. I'll still be here to test, though.
20:11 < TheSeven> mulenmar: i've updated embios-wipe.bin again
20:12 < TheSeven> it will be a lot more verbose now and check for success by reading the blocks back after erasing
20:15 < mulenmar> It says "128 dirty in 0:0 (110) and is looping at trying to wipe 0:0
20:19 < TheSeven> ok, reset it
20:22 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
20:24 < mulenmar> Reset it. Doesn't seem to have done anything, I still get the panic. *force-feeds the hardware a chill pill*
20:26 < TheSeven> yes, i just wanted to stop that endless loop that might wear out the flash, even though I doubt it's doing anything at all
20:27 < TheSeven> i've updated the file again, this time even more verbose
20:32 -!- chawsum [~chi1@h12n1fls304o1039.telia.com] has left #freemyipod
20:32 < mulenmar> This time it didn't start looping unitl 154:0, after going through 0:0 - 153:0 checking. It might be actually checking/fixing everything, and just not updating the number after it reaches a dirty block.
20:37 < mulenmar> Or not. I reset it again and it's still at 154:0
20:37 < mulenmar> "Wiping 154:0. . . 0
20:37 < mulenmar> 64 (0, 6144) dirty in 154:0 (100)
20:38 < TheSeven> aaaha
20:39 < TheSeven> mulenmar: updated once again
20:40 < mulenmar> Hmm, reason it was 154:0 again might have been that between the 0:0 loop and the 154:0 I didn't send it into recovery mode, so it did the FTL check -- and I *did* and the FTL check didn't happen between the 154:0 loops.
20:40 < mulenmar> Downloading.
20:41 -!- ChanServ changed the topic of #freemyipod to: www.freemyipod.org project development channel. Please use #freemyipod-support for support questions or #freemyipod-chatter for everything that's entirely off-topic.
20:43 < mulenmar> Or maybe not. "Wiping 154:0... 0
20:43 < mulenmar> 64 (1048576, 26624) dirty in 154:0 (100)
20:44 < TheSeven> that just *can't* be right
20:44 < TheSeven> oh, wait, it's bits, not bytes
20:45 < mulenmar> So it's checking bit by bit?
20:45 < TheSeven> yes
20:45 < TheSeven> and >90% of the bits are failing in that block
20:45 < mulenmar> So this is going to take a while. >_>
20:45 < TheSeven> what flash size is that one?
20:45 * mulenmar has visions of Scandisk checking a 6.4GB FAT32 partition and taking 3 hours
20:46 < mulenmar> Mine is only 2GB
20:46 < mulenmar> Usually a curse, but in this case not so much.
20:46 < TheSeven> do you know your nand chip id?
20:47 < TheSeven> (as shown in the rockbox debug menu)
20:47 < mulenmar> No, sorry. 8~(
20:47 < TheSeven> you do :)
20:47 < mulenmar> If this works, I'm writing down ALL the hardware info that menu provides, though.
20:48 < TheSeven> at least you posted them some time ago, just found them in the logs
20:48 < TheSeven> [11:11] <mulenmar> NAND: banks 2 bank 0 id 2585D3AD bank 1 id: 2585D3AD
20:48 < mulenmar> OH!
20:48 < mulenmar> Stupid human memory.
20:48 < TheSeven> let me look up what kind of geometry that chip has
20:49 < TheSeven> hm, 2 banks, 4096 blocks per bank, 128 pages per block, 2048+64 bytes per page
20:50 < TheSeven> this time it might actually be stuck on a bad block
20:52 < mulenmar> So the FTL's list of bad blocks is messed up?
20:52 < TheSeven> the whole ftl is fubar'd
20:52 < mulenmar> It IS in a different part of 154:0 than it was before, if I'm reading the number and guessing right.
20:53 < mulenmar> Will this, hopefully, rebuild the FTL properly?
20:53 < TheSeven> i hope so
20:53 < mulenmar> At least it isn't an 8GB. 8~J
20:53 * TheSeven just uploaded yet another one
20:53 < TheSeven> this time it will skip blocks after trying to erase them 10 times without success
20:56 < TheSeven> watch for "<whatever> bad blocks so far" lines
20:56 < mulenmar> Uh-oh, I'm not liking this. 47 bad blocks so far.
20:57 < mulenmar> How many bytes are in each block?
20:58 < TheSeven> which block is it currently scanning?
20:58 < mulenmar> 255:1
20:58 < mulenmar> This is not good, is it?
20:58 < TheSeven> each block is 256K, but the FTL will always mark 512K chunks as bad
20:59 < TheSeven> well, it might still be a driver bug, but let's wait for more result
20:59 < TheSeven> the 255:1 actually means that it has done 255 of the 512K blocks, and 47 of the 256K blocks are bad
21:01 < TheSeven> what is it currently reporting?
21:02 < mulenmar> 306:1 201 bad blocks so far
21:02 < mulenmar> It think it's marked every single block bad since 154:0. . . 
21:02 < TheSeven> no, that would be twice as many
21:03 < mulenmar> This is definitely going to take a while. I'm going to make something to eat.
21:04 * TheSeven might add another improvement: reset the bank if an error occurs
21:06 < TheSeven> ok, as soon as you're back, note the current/bad block numbers, reset it, re-download the file, and re-run it
21:07 < TheSeven> let's see if it gets any better
21:10 < mulenmar> 432:1 452 bad blocks so far
21:10 < TheSeven> what are the numbers in front of it?
21:11 < mulenmar> Sorry, I already reset it. 8~/
21:12 < mulenmar> Apparantly it found a few bad blocks in the ~154 range, and most around ~250 on
21:13 < TheSeven> does the new one behave any better?
21:13 < mulenmar> Same, as far as I can see.
21:14 < mulenmar> Wipe 235:0, increase number of bad blocks by one. Wipe 235:1, increase by one. Repeat forever.
21:14 < TheSeven> damn
21:14 < TheSeven> what are the numbers in front of it?
21:15 < mulenmar> They fluctuate up and down very quickly. From log,  (1061363, 33196)
21:17 < mulenmar> Wiping 289:1... 0
21:17 < mulenmar> 166 bad blocks so far
21:17 < mulenmar> 128 (1090718, 33381) dirty in 289:1 (000)
21:19 < mulenmar> Wiping 319:1... 0
21:19 < mulenmar> 226 bad blocks so far
21:19 < mulenmar> 128 (1056478, 33048) dirty in 319:1 (000)
21:19 < mulenmar> I don't see a pattern to the numbers in parerntheses.
21:20 < TheSeven> hmm
21:20 < TheSeven> this looks more and more like erasing is just not working at all
21:20 < mulenmar> Other than that they slowly go up, then will suddenly drop a bit, and slowly creep back up, that is.
21:21 < TheSeven> those numbers are plausible for ordinary data
21:21 < mulenmar> Well is works from 0:0 to 154:0, and briefly thereafter.
21:21 < TheSeven> and the first part of the flash where it seemed to work is the spare area, where most of the blocks are probably erased anyway
21:21 < mulenmar> s/is/it
21:24 < TheSeven> this is all very confusing
21:25 < mulenmar> Wiping 402:0... 0
21:25 < mulenmar> 391 bad blocks so far
21:25 < mulenmar> 128 (1098756, 33102) dirty in 402:0 (000)
21:25 < TheSeven> perfectly valid block
21:25 < TheSeven> (000) = not even an ecc error inside
21:25 < mulenmar> Yeah, tell me about it.
21:26 < TheSeven> now how on earth can erasing fail while reading works?
21:26 < mulenmar> They're all like that.
21:26 < mulenmar> And how can software screw hardware up this badly?!
21:27 < TheSeven> it might just be some unknown write protect pin that's set to a wrong value or whatever
21:27 < TheSeven> that would explain the whole lot
21:27 < TheSeven> and it could have been triggered by the rolo'ed build doing nonsense because of cache inconsistency
21:28 < TheSeven> you might want to try powering it down and letting it sit for >10 seconds before powering it on again
21:29 < TheSeven> but that's all poking in the dark
21:29 < mulenmar> Or even taking the battery out?
21:30 < TheSeven> i wouldn't open it up unless it's absolutely neccessary
21:30 < TheSeven> those things are just too easy to break
21:30 < TheSeven> and the battery is soldered to the board
21:31 < mulenmar> So I turned it off, let it sit, and powered it on. Still no disk mode, but I wasn't expecting it.
21:32 < TheSeven> executing it which way?
21:32 < mulenmar> Should I resume the seemingly pointless check?
21:32 < TheSeven> you can just try running it again
21:32 < TheSeven> you'll notice within a few seconds if the behavior changed significantly
21:37 < mulenmar> Well there is a slight difference with embios-debug
21:37 < mulenmar> Instead of rebooting on "Enter disk mode", the backlight dims and it locks up.
21:37 < mulenmar> So . . . I guess we're having SOME effect.
21:37 < TheSeven> let it sit like this for a while
21:38 < TheSeven> however, it should usually react within like 10 seconds
21:38 * TheSeven has another idea what could be related
21:38 < mulenmar> The menu is still visible, the backlight's just dimmed. And no response.
21:40 < TheSeven> hmm
21:40 * TheSeven starts to recognize a pattern
21:40 < TheSeven> somebody had a similar issue like a week ago, which magically fixed itself
21:41 < TheSeven> first, the backlight was behaving weird after booting to the apple firmware
21:41 < TheSeven> then the backlight started working properly again, but instead disk mode started to lock up
21:41 < TheSeven> after a few tries it magically worked again
21:41 < TheSeven> you're basically experiencing the same thing, just way slower
21:42 < mulenmar> I had a similar problem with the backlight -- boot OFW, reset, backlight still off, boot Rockbox, backlight normal again even after reset.
21:42 < mulenmar> It was "magically" fixed with the last iLoader update I put on here.
21:43 < mulenmar> Still no change on the Nano.
21:48 < Dreamxtreme> i fixed it
21:48 < Dreamxtreme> you forgot a $ on line 394
21:49 < TheSeven> Dreamxtreme: context?
21:49 < Dreamxtreme> sorry joke 
21:49 < Dreamxtreme> :D
21:51 * mulenmar hands Dreamxtreme a large bowl full of badly-microwaved saurkraut sprayed with skunk stink and a side of anchovies, along with a dirty glare.
21:51 < mulenmar> We've been working on this for the entire day without luck. >_>
21:51 < Dreamxtreme> sorry just got in 
21:51 < Dreamxtreme> i best go watch tv 
21:51 * Dreamxtreme hides
21:52 < TheSeven> mulenmar: try replacing embios.py with this one: http://files.freemyipod.org/embios.py
21:52 < TheSeven> and then running the following command
21:52 < TheSeven> embios.py i2cread 0 e6 0 ff
21:52 < TheSeven> and pastebin the result
21:53 < TheSeven> this will dump the state of the power management chip
21:53 < TheSeven> i have a feeling that the cause might be hiding in that area
21:55 -!- dakiato [~quassel@mail.lcarsys.net] has quit [Ping timeout: 245 seconds]
21:56 < mulenmar> http://pastebin.com/FjG57i7k
22:04 < TheSeven> sorry, no important differences found (when comparing to mine)
22:04 < TheSeven> just things like backlight brightness and current date/time
22:04 < TheSeven> and a byte of nvram
22:04 < mulenmar> The clock memory?
22:05 < mulenmar> (Remembered something from Linux kernel configuration, probably wrong)
22:05 < TheSeven> yep
22:05 < mulenmar> So, what now? Do I just go back to running the "disk check"?
22:05 < TheSeven> i don't know what it's used for, but it can't affect hardware
22:05 < TheSeven> well, our "disk check" has proven that we're unable to erase anything
22:06 < TheSeven> the question is why
22:06 * mulenmar sighs at the "Invalid block type FF while reading vPage 875264" error.
22:07 < mulenmar> Write protection of some sort.
22:08 < TheSeven> either that, or just failure on our side of things
22:08 < TheSeven> but what the hell would cause that to appear suddenly...
22:10 < mulenmar> Something in the RoLo.
22:11 < mulenmar> Or timed hardware failure built in by Apple? X~P
22:11 < TheSeven> there must be some kind of state difference between our devices
22:11 < TheSeven> and it must be some kind of persistent state that survives reset/powerdown
22:12 < TheSeven> the only place i know of where such a thing exists is the pmu, which we've just checked
22:13 < TheSeven> we must be missing something...
22:14 < mulenmar> We could ask in #rockbox-community.
22:14 < TheSeven> i doubt they can help with this
22:15 < mulenmar> Unless that byte of nvram does more than you think is possible. 8~\ #has_no_other_ideas
22:16 < mulenmar> Spurious address jump from a bug from unexpected setup set something unknown that wasn't supposed to be changed?
22:16 * mulenmar is grasping at quantum filaments at this point
22:17 < TheSeven> that's what I'm suspecting
22:17 < TheSeven> (the only way how rolo could have triggered this)
22:17 < mulenmar> Is the nvram even changable via a accident?
22:18 < TheSeven> yes, but only via rather complex code
22:18 < TheSeven> but i'm 100% sure that nobody is reading it up to the point where it fails, so that really can't be the issue
22:19 < TheSeven> are you prepared for going even deeper?
22:19 < TheSeven> my next attempt would be wiping the boot flash to force it into the bootrom dfu mode
22:20 < TheSeven> first of all, make a backup of what's currently in it:
22:20 < TheSeven> embios.py downloadfile 24000000 00100000 bootflash-backup.bin
22:21 < TheSeven> once you've done that, just run embios.py writebootflash 8000 08000000 1000
22:21 < TheSeven> then reset it. it will seem to power off, but should still respond to usb commands
22:22 < TheSeven> from that point on, ipoddfu.py will be the only script that will work
22:24 < TheSeven> once you're in that situation, run ipoddfu.py norboot-orig.dfu
22:24 < TheSeven> ipoddfu.py is in /tools/ipoddfu
22:24 < TheSeven> at that point, a black-on-white apple logo should come up. pray for it to show a "use itunes to restore screen", and *not* just reset again
22:25 < TheSeven> this way, no non-apple code will be running on the ipod at all
22:25 < mulenmar> "ERROR: Problem with USB connection".
22:25 < TheSeven> which script?
22:26 < mulenmar> That's embios.py.
22:26 < TheSeven> the writebootflash command failing?
22:26 < mulenmar> Yes.
22:26 < TheSeven> now that's ugly.
22:26 < mulenmar> With the embios-debug.bin loaded, for good measure.
22:27 < mulenmar> Same without it.
22:27 < TheSeven> and if you reset it, it still boots embios?
22:27 < mulenmar> Yes.
22:27 < mulenmar> Want me to try iBugger?
22:27 < TheSeven> that won't help either
22:27 < mulenmar> Didn't think so.
22:27 < mulenmar> 8~(
22:28 < mulenmar> So even the boot flash is write-protected somehow.
22:28 < TheSeven> it's weird that it just times out
22:28 < mulenmar> This is even with the USB 1.1 edits, too.
22:28 < TheSeven> this time you might really want to try increasing the timeout
22:29 < mulenmar> Where/to?
22:29 < TheSeven> libembios.py, line 475, in milliseconds
22:29 < TheSeven> choose 3000 or something
22:29 < TheSeven> however, even if it times out, it should complete the write, so i doubt it will help
22:30 < mulenmar> The increased time came before the "If this was not what you intended press Ctrl-C NOW.........." message and the error.
22:31 < mulenmar> So, I assume the write comes after the warned and before the error?
22:32 < TheSeven> it should
22:32 < Farthen> yep
22:32 < TheSeven> let's get even more aggressive
22:32 < mulenmar> Also the controls don't respond. So it's panicing or something.
22:32 < TheSeven> http://files.freemyipod.org/embiosldr-corrupter.bin
22:32 < TheSeven> run that through embiosldr
22:33 < TheSeven> or, alternatively, through embios-debug.bin using embios.py uploadfile 08000000 embiosldr-corrupter.bin && embios.py execfirmware 08000000
22:34 < TheSeven> it will lock up if you run that, wait for a few seconds and reset it
22:34 < TheSeven> it will hopefully *not* boot embios any more
22:34 < mulenmar> Nope . . . just a black screen and dark backlight.
22:34 < mulenmar> Progress?
22:35 < TheSeven> it doesn't come up any more?
22:35 < TheSeven> what does lsusb show?
22:36 < mulenmar> Bus 001 Device 079: ID 05ac:1220 Apple, Inc. 
22:36 < mulenmar> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
22:36 < TheSeven> ok, that's bootrom dfu mode
22:36 < mulenmar> I smell good news -- DFU!
22:36 < TheSeven> [00:24] <TheSeven> once you're in that situation, run ipoddfu.py norboot-orig.dfu
22:36 < TheSeven> [00:24] <TheSeven> ipoddfu.py is in /tools/ipoddfu
22:36 < TheSeven> [00:25] <TheSeven> at that point, a black-on-white apple logo should come up. pray for it to show a "use itunes to restore screen", and *not* just reset again
22:36 < mulenmar> Got it.
22:36 < TheSeven> what is it doing?
22:39 < mulenmar> Connected to S5L8701 Bootrom DFU mode, USB version 1
22:39 < mulenmar> Upload: .................................................................. done
22:39 < mulenmar> Black apple on white background.
22:39 < mulenmar> Now nothing.
22:40 < TheSeven> run the ipoddfu command again
22:40 < mulenmar> Black battery-charging icon on white background.
22:41 < TheSeven> ok, it's getting better :)
22:41 < TheSeven> once that goes away, try it a third time
22:41 < TheSeven> (that battery icon means that basically anything went wrong :) )
22:43 < TheSeven> any news?
22:43 < mulenmar> Well that took a while.
22:43 < TheSeven> if it's stuck at that battery screen, just reset it
22:43 < mulenmar> Trying the third time.
22:44 < TheSeven> usually it shuts off itself within a few seconds if that happens though
22:44 < mulenmar> Here it goes again with the black apple.
22:44 < TheSeven> if "use itunes to restore" or a picture of a dock connector comes up, we're set for the next stage :)
22:45 < mulenmar> Nothing yet, just the poisoned Apple.
22:45 < mulenmar> And it faded away again to DFU.
22:45 < TheSeven> dammit
22:45 < mulenmar> CLEAR!
22:45 < TheSeven> retry once again
22:45 < mulenmar> Seriously, this feels like shocking it back to life. X~P
22:45 < mulenmar> Battery again.
22:46 < TheSeven> apparently there's some kind of way for it to store things, if it behaves differently
22:46 < mulenmar> Maybe we've been trying to fix it for so long it needs to charge?
22:46 < TheSeven> i doubt that
22:46 < TheSeven> it has been on usb for most of the time
22:47 < mulenmar> Still showing the battery.
22:48 < mulenmar> Faded away. Trying *again*. Clear! X~P
22:48 < mulenmar> Black apple.
22:49 < TheSeven> if it still doesn't work, check if it behaves differently if you hold play+right while executing the ipoddfu command until the apple goes away
22:49 < mulenmar> Do the ipodfu scripts need to be editied for USB1.1 as well?
22:50 < TheSeven> if they would, the apple bootloader wouldn't have even started
22:51 < mulenmar> Yeah, didn't think so.
22:51 < TheSeven> does play+right change anything?
22:51 < mulenmar> No difference I can see.
22:52 < TheSeven> so it still goes to the battery screen?
22:52 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Ping timeout: 258 seconds]
22:52 < mulenmar> Yes.
22:52 < TheSeven> just as a side note: this means the device would be bricked if the apple bootloader was flashed
22:53 < TheSeven> i didn't yet know that this is even possible
22:53 < mulenmar> So, it's officially hopeless?
22:53 < TheSeven> well, as I said, we've had something similar before, where it fixed itself within a few tries
22:54 < TheSeven> http://files.freemyipod.org/embiosldr-ipodnano2g.dfu
22:54 < mulenmar> Huh, I can rerun the flash even with the battery icon showing...
22:54 < TheSeven> try running that file through ipoddfu.py
22:54 < TheSeven> embios should boot again
22:55 < mulenmar> Hello again, emBIOS.
22:58 < TheSeven> you could try running embios-wipe.bin again, but i doubt it will work any better than before
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:01 < mulenmar> Weird -- now it won't reset, but it still shows up in lsusb
23:06 < mulenmar> Reflashed the dfu . . . wonder why it didn't stick after the panic from my last deseparte try for disk mode.
23:16 < TheSeven> reset it, turn on the hold switch, run the ipoddfu command (with embiosldr)
23:16 < TheSeven> re-download embios-wipe.bin and embiosldr.py run that
23:16 < TheSeven> it should try writing to a page now
23:18 < TheSeven> mulenmar: what's the last message it prints?
23:18 < TheSeven> (before the usual "restore failed" thing)
23:21 < mulenmar> Maybe I'm just tired, but how do I run ipodffu with embiosldr? I thought they're unrelated tools?
23:21 < TheSeven> i mean "ipoddfu.py embiosldr-ipodnano2g.dfu"
23:21 < mulenmar> Gotcha.
23:24 < mulenmar> Well, I can't run embiosldr.py without rebooting into recovery mode, and I can't reboot now without going into DFU mode.
23:26 * mulenmar flashes DFU with hold switch on, to make it boot into recovery mode.
23:27 * mulenmar realized he missed one of your steps, at least consciously
23:28 < mulenmar> embios-wipe.bin doesn't do anything, emBIOS just remains at its menu. 8~(
23:28 < TheSeven> ipoddfu.py doesn't flash anything
23:28 < TheSeven> it will just run the file passed to it from ram
23:32 < TheSeven> mulenmar: it should say something during bootup
23:32 < TheSeven> quit iloader to see the console
23:35 < mulenmar> emBIOS v0.1.2 r206:208
23:35 < mulenmar> The FTL seems to be damaged.
23:35 < mulenmar> Forcing check.
23:36 < mulenmar> Scanning flash...Invalid block type FF while reading vPage 875264
23:36 < mulenmar> Writing...Write failed. FTL recovery failed. Use disk mode to recover.
23:36 < mulenmar> iLoader terminated on user's behalf.
23:36 < TheSeven> dammit
23:37 < TheSeven> try re-running it
23:37 < TheSeven> if it produces the same result, we're definitely fighting against some kind of write protection
23:37 < mulenmar> Ok. Btw, 0x2585d3ad may be Hynix HY27UV08AG5M.
23:39 < mulenmar> Re-running just the dfu part, then quitting iLoader brings up the same-old "broken" emBIOS as always.
23:39 < mulenmar> D'oh! I'm doing that wrong, so duh.
23:40 < TheSeven> where did you get that part number from?
23:40 < mulenmar> mympxplayer.org/export.php?t=12337
23:41 < mulenmar> FIrst search result in Scroogle. Don't know if it's true, but it's a lead.
23:46 < TheSeven> [01:37] <TheSeven> try re-running it
23:46 < TheSeven> [01:38] <TheSeven> if it produces the same result, we're definitely fighting against some kind of write protection
23:46 < TheSeven> did you try that?
23:48 < mulenmar> Yes, same result.
23:49 < TheSeven> damn
23:49 < TheSeven> let's get a GPIO dump
23:49 < TheSeven> please run the following:
23:49 < TheSeven> embios.py downloadfile 3cf00000 200 gpio.bin
23:50 < TheSeven> and send me the result
23:52 < mulenmar> http://rapidshare.com/files/417737507/gpio.bin
23:53 < mulenmar> MD5: 36A19C9DA1399180902A50A889B412AE , if you want it
23:55 < TheSeven> port modes match exactly with mine
23:55 < TheSeven> let's compare port data
23:56 < TheSeven> there *are* data mismatches!
--- Log closed Wed Sep 08 00:00:28 2010