--- Log opened Sat Nov 19 00:02:09 2011
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
00:35 -!- bakkerthehacker [1834e870@gateway/web/freenode/ip.24.52.232.112] has joined #freemyipod
00:37 -!- bakkerthehacker [1834e870@gateway/web/freenode/ip.24.52.232.112] has quit [Client Quit]
01:19 < Poodlemastah> Probably not appropriate to say but, I love your work seven. 
03:50 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
03:50 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
05:08 -!- Keripo [~Keripo@eng383.wireless-resnet.upenn.edu] has joined #freemyipod
05:16 -!- Keripo [~Keripo@eng383.wireless-resnet.upenn.edu] has quit [Quit: Leaving.]
06:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
06:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
07:21 -!- n1s [~n1s@nl118-175-223.student.uu.se] has joined #freemyipod
07:21 -!- n1s [~n1s@nl118-175-223.student.uu.se] has quit [Changing host]
07:21 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
09:02 -!- Keripo [~Keripo@eng383.wireless-resnet.upenn.edu] has joined #freemyipod
10:10 -!- Keripo [~Keripo@eng383.wireless-resnet.upenn.edu] has quit [Quit: Leaving.]
10:21 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
11:08 < user890104> [7]: so the most recent exploit is using the same bug, but allow injectin up to 2kB payload?
11:10 < [7]> it allows injection of arbitrary size
11:10 < [7]> (well, RAM size is the limit)
11:12 < user890104> SRAM?
11:12 < [7]> no, DRAM
11:13 < [7]> it's basically the same vulnerability as in the bootrom (the verification code is the same, just the loader code around it is slightly different), just that it's in the second bootloader stage, so the payload (OSOS) is loaded to DRAM
11:16 < user890104> i see
11:17 < user890104> what does the image in the firmware partition contain? osos, aupd and rsrc as usual, or more entries?
11:17 < [7]> there's an additional "hash" entry, no idea what that is
11:18 < [7]> completely removing that didn't stop it from booting though
11:19 < [7]> and the location it points to is all-0xff
11:20  * user890104 restores his classic, capturing the usb traffic in the process
11:23  * [7] thinks he has a nano4g restore dump lying around, analyzing the differences might be interesting
11:25 < user890104> yeah, that's the point
11:25 < user890104> i can also restore my n3g and n4g
11:25 < user890104> (i'm only using the n2g to play music)
11:26  * [7] nowadays uses his phone to do that
11:59 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
12:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
12:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
12:22 < fmibot> New commit by theseven (r794): libipodcrypto: Patch entrypoint in s5l8702pwnage800 exploit
12:22 < fmibot> New commit by theseven (r795): ipodcrypt.py: Python 3 compatibility fix (once again, part of it was accidentally reverted)
12:23 < fmibot> r794 build result: emcore: All green!
12:23 < fmibot> r794 build result: umsboot: All green!
12:23 < fmibot> r795 build result: emcore: All green!
12:23 < fmibot> r795 build result: umsboot: All green!
12:24 < fmibot> New commit by theseven (r796): emCORE: Reset ATA core before enabling its interrupt
12:25 < fmibot> r796 build result: emcore: All green!
12:25 < fmibot> r796 build result: umsboot: All green!
12:26 < fmibot> New commit by theseven (r797): iPod Classic boot stub: Make this position independent to allow booting from the firmware partition
12:27 < fmibot> r797 build result: emcore: All green!
12:27 < fmibot> r797 build result: umsboot: All green!
12:29 < [7]> finally...
12:38 < Poodlemastah> user890104: usb 1-2: usbfs: interface 0 claimed by usb-storage while 'emcorefs' sets config #1
12:38 < Poodlemastah> While trying to mount emcoreFS
12:39 < user890104> usb-storage? you should be running emcore, not rockbox in order to use it
12:39 < Poodlemastah> I am..
12:39 < Poodlemastah> That's the strange thing.
12:39 < user890104> so either sitting in the menu, or in the console
12:39 < Poodlemastah> I'm in the console
12:39 < user890104> and lsusb shows ffff:e000 ?
12:39 < Poodlemastah> Yeah.
12:40 < user890104> can you compile it using make debug
12:40 < user890104> then run it using make testdebug
12:41 < Poodlemastah> Want me to pastebin output?
12:41 < user890104> yeah
12:41 < Poodlemastah> http://pastebin.com/3pu0RBi4
12:43 < user890104> ah, you hit the bug i fixed yesterday :)
12:43 < user890104> please update (svn up)
12:43 < user890104> then recompile and re-run
12:44 < Poodlemastah> It's up to date.
12:44 < Poodlemastah> Oh no, the device is running a slightly older emcore.
12:44 < Poodlemastah> Updating.
12:44 < user890104> the emcore version on the device shouldn't matter that much
12:45 < user890104> Endpoints: 0 at 0x02 1 at 0x81 2 at 0x04 3 at 0x83
12:45 < user890104> Getting device descriptor of USB device 11...
12:45 < user890104> this should *not* happen
12:45 < user890104> i mean in this order
12:46 < user890104> run "svnversion ." just in case
12:46 < Poodlemastah> 797
12:47 < user890104> ok then
12:47 < user890104> make clean
12:47 < user890104> make debug
12:47 < user890104> make testdebug
12:47 < Poodlemastah> Still the same.
12:48 < Poodlemastah> Had to make before make debug though.
12:48 < user890104> no, make debug is the same as make, but with an additional option
12:49 < user890104> what happens if you run the commands in the order i wrote them?
12:49 < Poodlemastah> make debug
12:49 < Poodlemastah> gcc -O2 -Wall -Wextra -Werror -D_FILE_OFFSET_BITS=64 -I/usr/include/libusb-1.0 -I/usr/include/fuse  -pthread -lusb-1.0 -lfuse -lrt -ldl   -DDEBUG -g -o build/emcorefs util.c usb.c emcore.c cache.c fuse.c emcorefs.c
12:49 < Poodlemastah> /usr/bin/ld: cannot open output file build/emcorefs: No such file or directory
12:49 < Poodlemastah> collect2: ld returned 1 exit status
12:49 < Poodlemastah> make: *** [debug] Error 1
12:50 < user890104> ah
12:50 < user890104> do make clean
12:50 < user890104> then mkdir build
12:50 < user890104> then make debug
12:50 -!- scorche [~scorche@rockbox/administrator/scorche] has quit [Ping timeout: 276 seconds]
12:50 < user890104> seems like make debug does not create the directory first
12:50 < Poodlemastah> That worked
12:52 < Poodlemastah> Seems my front usb/cardreader is shit. Tried a port routed directly to mobo and emcorefs worked.
12:52 < user890104> well, from the pastebin output it seems like it's trying to connect to the wrong device
12:53 -!- scorche [~scorche@rockbox/administrator/scorche] has joined #freemyipod
12:53 < user890104> can you leave at the same port when it didn't work, and unplug your cardreader?
12:55 < Poodlemastah> Wait, I was confused about my wiring, the port that didn't work was actually directly attached to motherboard.
12:55 < Poodlemastah> My bad.
12:55 < fmibot> New commit by user890104 (r798): emCOREFS: fix Makefile fail
12:56 < fmibot> r798 build result: emcore: All green!
12:56 < fmibot> r798 build result: umsboot: All green!
12:56 < user890104> the order in which libusb sees the ports matter
12:56 < Poodlemastah> Plugged it back into the exact same port and now it works..
12:56 < user890104> with the card reader unplugged?
12:56 < Poodlemastah> Nope.
12:57 < Poodlemastah> Exact same configuration as before.
12:57 < Poodlemastah> This shouldn't have happened.
12:58 < user890104> well, seems like your binary wasn't updated
12:58 < user890104> and you had some old pre-r790 version
12:59 < user890104> can you test the read/write speed?
12:59 < Poodlemastah> Checked lsusb and now my lsusb order is different. My iPod is now last in the list.
12:59 < Poodlemastah> ls: cannot open directory .: Input/output error
13:00 < user890104> can you pastebin the first like 100 lines from the output
13:00 < user890104> when it looks for the device
13:01 < Poodlemastah> Oh, I see why I got an input/output error
13:01 < Poodlemastah> Got a data abort at 0BF8880C
13:01 < Poodlemastah> FSR: 00000FD (domain 15, fault 13)
13:02 < Poodlemastah> Address: 00001005
13:09 < fmibot> New commit by user890104 (r799): emCOREFS, ipoddfu_c: stop looking for device if we already have found one, also proprely print a ssize_t value
13:09 < user890104> ok, update again
13:09 < fmibot> r799 build result: emcore: All green!
13:09 < fmibot> r799 build result: umsboot: All green!
13:09 < user890104> make clean && make debug && make testdebug
13:12 -!- bcoco85 [4de1cc7e@gateway/web/freenode/ip.77.225.204.126] has joined #freemyipod
13:13 < bcoco85> hi
13:13 < bcoco85> i see a lot of new versions
13:14 < bcoco85> keep on the good work
13:18 < bcoco85> i have been searching for relevant error messages without success
13:18 < bcoco85> all freezes freezed the display, so no message.
13:18 < Poodlemastah> 89, I'll just reboot, I can't seem to unmount it after a crash
13:20 < user890104> Poodlemastah: sudo umount or fusermount -u <tab>
13:21 < Poodlemastah> Yeah, It wouldn't unmount because of the ipod crash.
13:21 < user890104> the latter should auto-complete the path, if not enter it manually
13:21 < Poodlemastah> Rebooted though
13:21 < user890104> ah, you mean to reboot the ipod? yeah, that's the only solution after a crash
13:22 < Poodlemastah> No, the computer. It said it was busy with both umount and fusermount -u
13:22 < user890104> in these cases you can kill -9 the emcorefs process, then fusermount would manage to unmount it
13:23 < Poodlemastah> Same crash again on the ipod.
13:23 < bcoco85> i had rockbox.elf but im updating to latest avaliable rockbox build
13:23 < bcoco85> this file is outdated now¿?
13:23 < user890104> bcoco85: there have been some changes to rockobx recently, yes
13:24 < Poodlemastah> bcoco, is this a classic?
13:24 < user890104> i'm rebuilding my rockbox binaries, so i can post the results when they are ready
13:24 < bcoco85> classic2g
13:24 < Poodlemastah> Maybe you need the lcd patch?
13:24 < bcoco85> seems to be fixed
13:24 < user890104> Poodlemastah: it is included in rockbox as of now
13:24 < user890104> together with the usb fix
13:24 < bcoco85> just update like always (before the rgb666 update) and it works
13:25 < Poodlemastah> Ah, missed that.
13:26 < bcoco85> clickwheel crashed rockbox as usual
13:27 < user890104> bcoco85: as usual? can you explain what exactly do you do, and does it happen every time you do it?
13:27 < user890104> i also have a classic 2g
13:27 < bcoco85> while playback, if i change volume too fast, possibilities of crash are high
13:27 < user890104> the only way to lock it up so far was by replugging usb very quickly
13:27 < bcoco85> sometimes wheel is unresponsibe unless i pulse a button
13:28 < bcoco85> random freezes while playback
13:28 < bcoco85> if unlocked, screen lights up like when just touching
13:29 < bcoco85> -im not sure but- i noticed screen lighted up WHILE blocked sometimes
13:29 < user890104> [15:27:53] <bcoco85> sometimes wheel is unresponsibe unless i pulse a button << that is a known one
13:29 < bcoco85> its a list of behaviours. unluckily i dont have error messages, error logs, just behaviours. hope this list helps to see problems.
13:29 < [7]> and it's not a target-specific bug
13:29 < [7]> seems to happen on all rockbox devices from time to time, probably a race condition in the button handling code
13:30 < [7]> recently there have been several reports of lockups while doing something that talks with I2C
13:30 < user890104> bcoco85: can you send me te build where you have these issues, and tell me which emcore version you are using
13:30 < bcoco85> this happens in almost every rockbox build. im using emcore r769
13:31 < Poodlemastah> user890104: normal build of emcorefs crashes with a panic but the debug build seems to work fine.
13:31 < bcoco85> i begin to think that my classic2g is a bit damaged. it has a lot of accidental free-falls....
13:32 < bcoco85> bt, when mounted is very stable.
13:32 < bcoco85> 99% freezes are when playback
13:33 < bcoco85> some of that freezes replays a very small audio buffer. some keeps replaying a big (around half a second) audio buffer. seems like hardtechno music
13:34 < bcoco85> without a beat
13:34 < Poodlemastah> user890104: Getting ~1.3mb/s during write
13:34 < bcoco85> i have to tell people that i have a scratched cd simulator
13:36 < bcoco85> do you suggest me to update emcore to any specific version? or just keep r769?
13:36 < Poodlemastah> Went up to ~1.6mb/s
13:36 < user890104> Poodlemastah: with emcorefs? that's cool, i can only get ~150kb/s (but within a virtual machine)
13:37 < user890104> bcoco85: i don't think that a more recent revision would fix these crashes
13:37 < Poodlemastah> Yeah, using a steady 12% cpu.
13:39 < Poodlemastah> On a quad 4ghz proc.
13:39 < bcoco85> thanks
13:39 < user890104> Poodlemastah: can you pastebin a part of the debug log
13:39 < user890104> like 20-30 lines, preferably with opcode: WRITE in it
13:40 < user890104> it was doing the transfer in 4kb chunks for me, so that could be the reason for my slow speeds
13:40 < Poodlemastah> Its doing it in 4kb chunks here too
13:41 < Poodlemastah> http://pastebin.com/BFMQMj3J
13:41 < user890104> that's awful, i need to tell it to do it in large ones
13:42 < Poodlemastah> Any idea about the crash on normal builds?
13:42 < user890104> no, i also had it on mac os x
13:42 < bcoco85> thanks for all people. i appreciate the support
13:42 < user890104> haven't checked in ubuntu
13:43 < Poodlemastah> I'm using arch.
13:43 < user890104> x64?
13:43 < Poodlemastah> Yeah.
13:43 < user890104> my osx is x64 too, and my ubuntu is x86
13:43 < user890104> that might be the reason
13:43 < user890104> do you know how to work with gdb?
13:44 < Poodlemastah> Can't really say that I do. Sorry.
13:45 < user890104> well, make a regular build with make
13:45 < user890104> then first try: ./build/emcorefs -s -f <whatever mountpoint you want>
13:47 < Poodlemastah> No crash.
13:47 < user890104> ok then run it again without -f
13:47 < user890104> it would go in the background
13:48 < Poodlemastah> No crash.
13:49 < user890104> well...
13:49 < user890104> make test is the exact same command
13:50 < user890104> so, if you start over:
13:50 < user890104> fusermount -u ....
13:50 < user890104> make clean
13:50 < user890104> make
13:50 < user890104> make test
13:50 < user890104> does it crash?
13:51 < Poodlemastah> Nope.
13:51 < Poodlemastah> It only does it without -s
13:51 < user890104> ah, that's a known one
13:52 < user890104> i wrote about it in the README and the wiki
13:52 < user890104> -s disables multithreading
13:52 < user890104> which can't properly work with the current implementation of the filesystem api in emcore
13:52 < Poodlemastah> Terribly sorry for wasting your time. :(
13:53 < [7]> the filesystem api isn't the culprit here, it's the USB interface
13:53 < [7]> you would need something NCQ-like to allow for multiple in-flight accesses
13:54 < [7]> the current sequential interface can only handle a single in-flight request, so it doesn't make sense to try parallelizing things on the client side
13:54 < user890104> Poodlemastah: no problems, thanks for testing
13:55 < user890104> [7]: well, fuse wants to fetch multiple parts of the file at the same time to increase the speed
13:57 < [7]> how would that generally work on HDDs?
13:59 < Poodlemastah> Gah, more problems.
13:59 < Poodlemastah> http://pastebin.com/EmRbCnFn
14:00 < Poodlemastah> Mounted and trying to read a directory.
14:00 < Poodlemastah> On both debug and normal builds
14:01 < user890104> can you unmount emcorefs and remount it again?
14:01 < Poodlemastah> Same error.
14:01 < user890104> i/o error is used when emcore does not respond with success
14:02 < user890104> so could be busy with a previous operation
14:02 -!- Psirus [57b06799@gateway/web/freenode/ip.87.176.103.153] has joined #freemyipod
14:02 < user890104> try "python emcore.py reset" to reboot the ipod
14:02 < user890104> if it shows you "device busy", this is the problem
14:03 < [7]> if that happens, it means that some storage function on the ipod has locked up
14:03 < [7]> so there's either a bug or wrong parameters specified to something
14:04 < Psirus> hi, I'm on xubuntu and have a classic 6g, do you still need people for tests?
14:04 < Poodlemastah> Reset worked fine.
14:04 < user890104> Psirus: if it has emcore installed, you could try if emcorefs works for you
14:04 < Psirus> it has
14:04 < [7]> Poodlemastah: so reading the root directory during the second try worked again, but reading the subdirectory failed?
14:05 < user890104> Poodlemastah: you can make an even more verbose debug build by compiling it like that: CFLAGS="-DDEBUG_USB_PACKETS" make debug
14:06 < user890104> so we can see what requests are being sent/received
14:06 < user890104> Psirus: great, can you checkout the source of emcorefs and compile it?
14:07 < user890104> then turn on your ipod, select Console from the boot menu and connect it
14:07 < Psirus> i can try :)  i'll give you an update once i've done that
14:07 < user890104> ok, thanks
14:07 < Poodlemastah> Now it worked fine.
14:08 < user890104> Poodlemastah: a restart of the ipod would obviously fix that, the question is why did it happen
14:09 < user890104> the packet dump option should show any possible cause if it happens again
14:11 < Poodlemastah> Impressive, getting ~8.5mb/s on reads
14:12 < Poodlemastah> Found the cause user890104
14:14 -!- bcoco85 [4de1cc7e@gateway/web/freenode/ip.77.225.204.126] has quit [Quit: Page closed]
14:14 < user890104> Poodlemastah: what is it?
14:15 < Psirus> standard or debug build?
14:15 < Poodlemastah> Trying to remove a folder named "Graveyard - 2011- Hisingen Blues (FLAC)" in rootdir.
14:16 < [7]> Poodlemastah: does emcore.py rmdir work on that?
14:17 < liar> [7]: i just got one of the ipod nano 2gs where the display isn't supported but emcore is installed^^ (r674) is there an easy way to install iloader? (unfortunately dont know anything about emcore)
14:17 < Poodlemastah> [7]: It does not.
14:17 < [7]> python emcore.py runfirmware 0x08000000 <iloader_installer>
14:18 < [7]> how does it fail?
14:18 < Poodlemastah> struct.error: argument for 's' must be a bytes object
14:18 < [7]> liar: so we finally have one where we can check *why* that LCD doesn't work?
14:19 < Poodlemastah> Full output:
14:19 < Poodlemastah> http://pastebin.com/jRWW2QVR
14:19 < [7]> urrrgh
14:19 < [7]> that's python3 trouble again
14:21 < fmibot> New commit by user890104 (r800): emCOREFS: update the README file a bit
14:21 < liar> [7]: i hope so
14:21 < fmibot> r800 build result: emcore: All green!
14:21 < fmibot> r800 build result: umsboot: All green!
14:21 < Poodlemastah> [7]:With 2.7 it's:Removing directory Graveyard - 2011- Hisingen Blues (FLAC)...ERROR: 'dir_remove(dirname="Graveyard - 2011- Hisingen Blues (FLAC)") failed with RC=0xFFFFFFFF, errno=2'
14:23 < user890104> i noticed that emcorefs (and probably libemcore, too) don't support unicode filenames
14:23 < user890104> it could be that the filename has some dash or space that confuses it
14:24 < Poodlemastah> But I wrote that dir with emcorefs, shouldn't that have failed too?
14:24 < fmibot> New commit by theseven (r801): libemcore.py: Fix a couple more Python 3 incompatibilities
14:24 < fmibot> r801 build result: emcore: All green!
14:24 < user890104> i think that when creating the file, it gets question marks in place of the unknown chars
14:24 < liar> [7]: let me describe what i know so far: if i boot the ipod i get a whitescreen saying: emCORE v0.2.0 r674, once i press the center button rockbox starts. if i wait for a few seconds until the screen sleeps and wake it up again it gets initialized properly. the lcd is a ILI9320 (type: 2, rockbox: 0)
14:24 < fmibot> r801 build result: umsboot: All green!
14:24 < user890104> then the open call fails
14:25 < [7]> user890104: libemcore does support unicode file names, they need to be sent in UTF8 encoding
14:25 < user890104> Poodlemastah: try browsing the dir within rockbox, it should support these names
14:26 < user890104> [7]: i need to check what's FUSE sending to my app then
14:26 < Poodlemastah> I can browse it with both emcorefs and rockbox.
14:27 < Poodlemastah> I just can't remove it with either emcore.py or emcorefs
14:27 < Psirus> i get a lot of these: "undefined reference to `libusb_init'", but i have  libusb-1.0-0 and libusb-1.0-0-dev installed
14:27 < liar> [7]: can i use emcore.py from the current revision or should i revert to r674 to match the emcore version on the ipod?
14:28 < user890104> Poodlemastah: errno 2 is ENOENT, return code -1 means the same, so it fails when opening it
14:29 < user890104> Psirus: can you paste the whole output to pastebin.com?
14:29 < [7]> liar: the interface should be compatible
14:29 < [7]> some new apis might fail with "unsupported function" if the emcore version is too old, but if you just need things like runfirmware, any version should do
14:30 < Psirus> http://pastebin.com/pfkpnKem
14:32 < user890104> Psirus: that's strange
14:33 < Psirus> indeed
14:34 < user890104> can you check if you have libfuse-dev too?
14:34 < Psirus> i do
14:35 < [7]> possibly some lib dirs missing?
14:35 < [7]> try explicitly passing -L/usr/lib/i386-linux-gnu -L/usr/lib -L/lib in cflag
14:35 < [7]> CFLAGS*
14:37 < [7]> and possibly /usr/local/lib as well
14:37 < [7]> depending on where those libs are
14:38 < Poodlemastah> user890104: The actual error message is --------------------------------------------
14:38 < Poodlemastah> Sending 16 bytes...
14:38 < Poodlemastah> 31 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  
14:38 < Poodlemastah> Receiving 16 bytes...
14:38 < Poodlemastah> 01 00 00 00  5a 00 00 00  00 00 00 00  00 00 00 00  
14:38 < Poodlemastah> --------------------------------------------
14:38 < Poodlemastah>    unique: 1217, error: -90 (Message too long), outsize: 16
14:39 < user890104> Poodlemastah: can you pastebin some more around these lines?
14:39 < user890104> like 10 lines before and 10 lines after
14:39 < [7]> that's a file_size(null) call...
14:40 < user890104> ah, yes
14:40 < user890104> fuse shouldn't pass empty handles
14:40  * [7] wonders why this one doesn't even fail
14:40 < user890104> s/empty/null/
14:40 < [7]> oooops
14:40 < [7]> mixed up hex and decimal
14:41 < [7]> it's errno() returning 90
14:41 < [7]> so yeah, we'll need the packet above that
14:42 < [7]> anyway it's failing with ENOTEMPTY
14:42 < Poodlemastah> http://pastebin.com/AR2GjWXa
14:43 < [7]> so apparently whatever sent that rmdir() syscall didn't remove all directory entries before doing that
14:43 < [7]> so probably emcorefs didn't enumerate those directory entries properly
14:43 < user890104> it skips only . and ..
14:43 < user890104> the other ones should be returned
14:44 < [7]> user890104: a full log of all API calls emcorefs processes and all directory entries returned might help
14:45 < [7]> possibly also of the commands sent to and responses received from the ipod, with names and not just the raw packets
14:46 < [7]> Poodlemastah: does that directory contain any files/dirs?
14:46 < Poodlemastah> Yeah, some files
14:46 < user890104> Poodlemastah: can you recompile with -DDEBUG2 added to CFLAGS, then do "ls /__cache_dump"
14:46 < [7]> if yes, can you see them with python emcore.py ls "/Graveyard - 2011- Hisingen Blues (FLAC)"?
14:48 < Poodlemastah> No, I can't see them.
14:51 < [7]> so this seems to be an ipod-side problem after all
14:52 < [7]> does python emcore.py ls /GRAVEY~1 work?
14:52 < Psirus> http://pastebin.com/VMVi6Afc
14:53 < [7]> but libusb-1.0.a and libfuse.a are in one of those directories?
14:53 < Poodlemastah> Cant seem to find that dir
14:53 < Poodlemastah> ERROR: 'dir_open(dirname="/GRAVEY~1") failed with RC=0x00000000, errno=0'
14:55 < [7]> do the file names inside that directory contain any weird (non-ascii) characters?
14:55 < [7]> can you delete the directory from within rockbox?
14:58 < Psirus> apparently http://pastebin.com/P0Vu86K0
15:00 < Poodlemastah> [7]: It removed fine from rockbox, heres a pastebin with all files in the folder:
15:00 < Poodlemastah> http://pastebin.com/fy0DkWxC
15:03 < [7]> hm, i see no reason why emcore wouldn't be able to process these file names
15:06 < Poodlemastah> Uhm, python emcore.py ls / gives no output.
15:09 < Poodlemastah> python2.7 can ls both / and python emcore.py ls "/Graveyard - 2011- Hisingen Blues (FLAC)"
15:09 < Poodlemastah> With proper results
15:29 < user890104> Poodlemastah: what does python -V say?
15:32 < liar> [7]: the iloader installation worked fine and i think i've installed all the tools i need to build and execute emcore except embios (i suppose i need embios to execute emcore for testing purposes), i can't check that out from the svn server do you have a copy somewhere?
15:36 < user890104> liar: try checking out the whole tree somewhere else, then do "svn -r 672 up"
15:37 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
15:38 < Poodlemastah> user890104:Python 3.2.2
15:43 < user890104> Poodlemastah: Farthen or [7] could help you with python issues
15:43 < user890104> i know almost nothing of it (that's why i've rewritten libemcore in C)
15:57 < user890104> Psirus: which version of gcc/ld are you using? can you paste the output of pkg-config --cflags --libs fuse libusb-1.0
16:08 < liar> what should i expect to see if i run emcore.bin through embios?
16:09 < Psirus> gcc 4.6.1,  binutils 2.21.53, pkg-config output: -D_FILE_OFFSET_BITS=64 -I/usr/include/libusb-1.0 -I/usr/include/fuse  -pthread -lfuse -lrt -ldl -lusb-1.0
16:17 < user890104> liar: emCORE vX.X.X rXXX
16:17 < user890104> No usable boot options, waiting for USB commands
16:17 < user890104> or something like that
16:18 < liar> ok, all i see is "emCORE v0.2.2 r801"
16:18 < user890104> this is a nano2g, right?
16:19 < liar> yes
16:19  * user890104 pings [7]
16:20 < user890104> Psirus: haven't tried gcc 4.6.x so far, this might be the issue
16:20 < user890104> but it doesn't make sense, the libs are there, the path is included
16:21 < user890104> and the pkg-config output is fine
16:21 < Psirus> i dont want to cause more trouble than i'm useful
16:22 < user890104> well since the software is in early stage, any reports are useful in order to find/fix as much bugs as possible
16:22 < user890104> but your issue is a weird one
16:23 < user890104> i'm wondering if there's a way to run gcc with more verbose error output
16:24 < user890104> anyway, thank you for testing, we are now aware of the issue
16:25 < Psirus> alright
16:30 < liar> it seems to lockup in if (wakeup_wait(&(ib->storagewakeup), 100000) == THREAD_OK) break;
16:30 < liar> in initthread
16:31 < user890104> yeah, it mounts the flash/hdd on startup in order to look for /.boot/init.emcoreapp
16:32 < user890104> but it shouldn't fail
16:32 < liar> that file is missing on my ipod
16:33 < liar> should that be created during the emcore installation?
16:35 < liar> whats that app supposed to do?
16:37 < user890104> no, this is an optional one which is mostly used to launch rockbox instantly (fastboot)
16:37 < user890104> it doesn't exist on default installs, it must be copied manually
16:40 < [7]> liar: are you sure that it locks up there?
16:40 < [7]> my suspicion is that it's just the LCD that freezes
16:42 < fmibot> New commit by theseven (r802): libemcore.py: Revert accidentally committed change
16:42 < fmibot> r802 build result: emcore: All green!
16:42 < fmibot> r802 build result: umsboot: All green!
16:52 -!- Psirus [57b06799@gateway/web/freenode/ip.87.176.103.153] has quit [Quit: Page closed]
17:16 < liar> yeah i suppose it is the lcd
17:59 < liar> [7]: do you have an idea what i could try to find out whats going wrong with the lcd?
18:00  * [7] suspects something related to DMA
18:00 < [7]> hm, does running an emcore without any embedded app have lcd problems as well?
18:02 < liar> [7]: if emcore without any embedded app is equal to "runfirmware 0x08000000 embios.bin" then yes
18:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
18:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
18:02 < [7]> hmm, interesting, so it's not dithering or rgb666 related
18:03 < [7]> since the console is only doing plain DMA rgb565 like we've been doing it for ages
18:03 < [7]> you might even want to diff the lcd driver against the embios one then, ignoring all the new functions...
18:08 < liar> i think i won't have much luck with diff because it seems the embios nano2g lcd driver was pure assembler
18:09 < [7]> hm... not good
18:19 < user890104> [7]: this could be related to the problem with the dark dots at top left of the console
18:19 < user890104> which goes away as soon as i turn off dma
18:19 < [7]> possibly
18:20 < [7]> hm, you could try to add a 100ms or something delay between any dma and non-dma traffic
18:30 < liar> that does not seem to change anything for me
18:39 < [7]> want to rewrite the driver to not use dma at all?
18:43 < user890104> http://pastebin.com/YyNB0wbx
18:44 < user890104> (found in a skype log with [7])
18:44 < user890104> it fixes the pixels at top left
18:46 < [7]> liar: hm, can you try that as well?
18:51 < liar> hm weird
18:56 < liar> all i see now are some strange pixels in the first ~3 lines of the screen and "request"
19:08 < liar> just out of curiosity: is there a string containing request somewhere in the source? i couldn't find one
19:13 < user890104> liar: can you take a photo of the ipod's screen?
19:19 < liar> user890104: i dont have a camera, but i might be able to borrow one in the next hour
19:20 < user890104> ok great
19:21 < liar> also, there is no "request" in emcore.bin^^
19:21 < [7]> is it reproducible?
19:22 < [7]> might be just some arbitrary ram contents
19:27 < liar> i can reproduce it
19:28 < liar> i think i know where "request" is comming from. its from the embios screen
19:29 < liar> so far 3/6 times the weird screen, 2 times the embios screen, and once i got a whitescreen
19:29  * [7] facepalms
19:31 < [7]> seriously. why on earth would one swap these bytes in software if the hardware can do it by simply setting a bit in a control register!?
19:32 < [7]> why do I have to disassemble a 10MB OF blob to figure that out?
19:33 < [7]> why didn't they just do it the right way in diagmode / disk mode as well?
19:33 < [7]> i mean, they could have just used the OF's driver in disk mode as well!
19:34 < [7]> we'll definitely need to break compatibility with old ipod classic emcore/rockbox installations rather soon
19:36 < liar> user890104: http://imgur.com/qIFfb,ussO6#1
19:38 < liar> are these the same pixels as you had?
19:51 < user890104> liar: emcore works fine for me, my ipod isn't affected by the bug
19:52 < user890104> but there are like 2 or 3 pixels at top left
19:52 < user890104> which are blinking when doing usb operations for example
19:52 < user890104> with the fix i pasted, this is fixed
19:52 < [7]> hmm, maybe we're clocking this too aggressively?
19:52 < [7]> try setting LCD_PHTIME to 0x77
19:58 < liar> [7]: that did not change the behaviour
19:59 < [7]> this looks to me as if it's just skipping most of the pixels being transferred
20:02 < liar> ah damn... i forgot the line while (LCDSTATUS & 8);
20:02 < liar> now it is the same as before, just "emCORE v0.2.2 r802M" but nothing else
20:03 < liar> [7]: so it does not seem to be dma related?
20:04 < [7]> try commenting all the range setup accesses so that only the data bytes are ever transferred
20:04 < [7]> this should work somewhat because all the transfers will be full screen, the range will have already set up to be full screen by embios, and the lcd should wrap around at the end
20:06 < liar> that looks better
20:07 < liar> now it displays "No usable boot options, waiting for USB commands" too
20:19 < [7]> hm, so it's either plain wrong commands or something with the command to data transition
20:19 < [7]> what happens if you insert a sleep(100000); before and after those range setup commands?
20:21 < liar> [7]: the display freezes again
20:22 < [7]> i think now it's time to compare that part of the code with the embios one
20:23 < liar> there are some differences to the rockbox code as far as i can see
20:37 < liar> there are some differences to the rockbox code as far as i can see
20:38 < liar> woops
20:40 < liar> it seems that there is some confusion with endx <-> width, endy <-> height
20:50 < [7]> which in this case shouldn't matter because startx/starty are zero
20:50 < [7]> or do you mean that we're off by one?
20:51 < [7]> IIRC the LCDs will always want to know the inclusive endx/endy coordinates, not the height/width
21:07 < liar> hm no it seems to be right
21:08 < [7]> so the command bytes are correct?
21:10 < liar> i am not 100% sure but they match the embios code
21:11 < [7]> hm, so where does the embios code differ?
21:14 < liar> i couldn't find a difference
23:10 -!- Keripo [~Keripo@165.123.49.239] has joined #freemyipod
23:23 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Quit: hallowed are the ori!]
23:24 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Ex-Chat]
--- Log closed Sun Nov 20 00:02:13 2011