--- Log opened Mon Apr 25 00:00:29 2011
00:00 < TheSeven> want to try bisecting what's failing?
00:00 < kleemajo> TheSeven: the reset vectors are all pointing to 0x22000000 addresses... is that intentional?
00:01 < TheSeven> you mean that 0x0 is mapped to 0x22000000? yes, i'm expecting that
00:02 < kleemajo> TheSeven: do you copy the interrupt vector to 0x0?
00:03 < kleemajo> I'm loading the code at 0x09000000 and running it
00:03 < TheSeven> no, i'm expecting the MMU to handle that
00:03 < TheSeven> (i'm setting up the vectors at 0x22000000)
00:04 < TheSeven> where are the page tables btw? maybe i'm corrupting them?
00:04 < TheSeven> or is the mmu disabled?
00:04 < TheSeven> does the MIU map 0x0 to 0x22000000?
00:04 < kleemajo> TheSeven: yes on the MIU
00:05 < kleemajo> the way I'm loading it...
00:05 < TheSeven> ok, that's good
00:05 < TheSeven> have time to try bisecting it?
00:06 < kleemajo> TheSeven: depends on if the grocery store is open or not :P
00:07 < TheSeven> if yes, can you please try http://files.freemyipod.org/tmp/emcore-try002.bin ?
00:07 < TheSeven> this file should reboot the ipod after doing some basic setup to check if we manage to get through that at least
00:09 < kleemajo> TheSeven: ah, the store is open until 11, I'm good for a while. Let's do this.
00:10 < TheSeven> btw, what time zone are you living in?
00:10 < TheSeven> i'm in utc+2, so it's 2am here :)
00:10 < TheSeven> but i'll be happy to stay up for another two hours or so
00:10 < kleemajo> I'm in vancouver, so pst. gmt-7 or something
00:11 < kleemajo> TheSeven: that didn't reboot the device
00:12 < TheSeven> ok, let's try harder: try003 is up
00:12 < TheSeven> this tries to reboot as the very first thing, to check whether the reboot code itself works
00:13 < kleemajo> TheSeven: nope
00:13 < TheSeven> do you have working reset code?
00:13 < TheSeven> argh, bugger
00:13 < TheSeven> looking at the file in ida tells me that something didn't get rebuilt for some reason
00:15 < kleemajo> TheSeven: to reboot, we write 0x100000 into 0x3C800000
00:15 < TheSeven> that's what i'm doing as well
00:19 < kleemajo> TheSeven: I'm looking at your source code right now. What all did you need to change for the ipt2g?
00:19 < TheSeven> damn, it's using the crt0.S from iponano4g, apparently I missed something when creating the port
00:19 < TheSeven> once i've sorted that out, I can send you a patch
00:20 < kleemajo> TheSeven: sounds good
00:20 -!- timccc1 [~timccc@112.166.15.141] has joined #freemyipod
00:20 -!- timccc [~timccc@112.166.15.141] has quit [Read error: Connection reset by peer]
00:22 < TheSeven> aha, i overlooked it in the linker script
00:22 < TheSeven> try004 is up
00:23 < kleemajo> TheSeven: it rebooted
00:23 < TheSeven> http://files.freemyipod.org/tmp/emcore-try004.patch is the source
00:24 < TheSeven> try005 is up
00:24 < TheSeven> (which is try002 with that linker problem fixed)
00:25 < kleemajo> TheSeven: it rebooted
00:25 < TheSeven> try006 is up (reboot just before passing control to the C code)
00:29 < kleemajo> sorry, didn't notice your message
00:29 < kleemajo> it rebooted
00:29 < TheSeven> kleemajo: try007 is up, reboots just before enabling multitasking
00:30 < kleemajo> TheSeven: rebooted
00:31 < TheSeven> kleemajo: try008 (reboot after enabling interrupts, but still from the idle thread context)
00:31 < TheSeven> if IRQs are the culprit, this one should hang
00:32 < kleemajo> TheSeven: rebooted
00:32 < TheSeven> yay! \o/
00:32 < kleemajo> maybe that linker fix was all it needed...
00:32 < TheSeven> no, as it only prevented my debugging code from being effective
00:33 < kleemajo> TheSeven: What toolchain do you guys use?
00:33 < TheSeven> i don't quite know, I've stolen it from rockbox :)
00:33 < TheSeven> some arm-elf-eabi one
00:34 < kleemajo> TheSeven: so just grab the one from rockbox and it should work?
00:34 < TheSeven> yep
00:34 < TheSeven> kleemajo: try009 (reboot from init thread, after first context switch, which should not yet rely on timers)
00:35 < kleemajo> TheSeven: rebooted
00:35 < TheSeven> http://svn.rockbox.org/viewvc.cgi/trunk/tools/rockboxdev.sh
00:35 < TheSeven> run that as root, choose "e", and it will install the toolchain to /usr/local/arm-elf-eabi-<whatever>
00:35 < kleemajo> TheSeven: thanks
00:35 < TheSeven> it will automatically apply all the neccessary patches
00:37 < TheSeven> kleemajo: try010  (reboot just before terminating the init thread, let's try a bigger stap)
00:37 < TheSeven> step*
00:37 < TheSeven> if this one still reboots, we actually don't have a lockup but some USB problem
00:38 < kleemajo> TheSeven: rebooted....
00:38 < TheSeven> ah, nice
00:39 < TheSeven> kleemajo: try011 (binary same as the first try, just to check)
00:40 < TheSeven> shouldn't reboot, but respond to usb
00:41 < kleemajo> TheSeven: doesn't respond, but doesn't respond to usb either
00:41 < TheSeven> try12 is up (should reboot on usb bus reset)
00:42 < kleemajo> TheSeven: doesn't reboot
00:42 < TheSeven> hm, now what's that? irqs? clock gates?
00:43 < kleemajo> TheSeven: nothing shows up in Wireshark at all...
00:43 < kleemajo> clock gates would make sense
00:44 < TheSeven> try013 (enables all clock gates on boot)
00:45 < kleemajo> TheSeven: same thing
00:45 < kleemajo> TheSeven: How are you doing the clock gates?
00:46 < TheSeven> zeroing 0x3c5000xx
00:46 < TheSeven> xx being 28, 2c, ...
00:47 < TheSeven> which IRQ does the OTG have on the ipt2g?
00:47 < kleemajo> TheSeven: clock gates are at 48, 4c, 58, 68 and 6c on the ipt2g
00:47 < TheSeven> er, i meant those
00:47 < kleemajo> ;)
00:48 < TheSeven> #define CLOCKGATE_USB_1 2
00:48 < TheSeven> #define CLOCKGATE_USB_2 35
00:48 < TheSeven> #define IRQ_USB_FUNC 19
00:48 < TheSeven> does that match?
00:49 < kleemajo> TheSeven: we do clockgates differently than you, but the irq matches
00:49 < kleemajo> TheSeven: I need to fix openiboot's clockgates
00:49 < TheSeven> how do you do those?
00:50 < kleemajo> TheSeven: a table of the bits to switch in each register, with the clock gate values being the offset in the table
00:50 < kleemajo> TheSeven: the table is copied from iboot
00:51 < kleemajo> TheSeven: https://github.com/kleemajo/openiBoot/blob/master/openiboot/plat-s5l8720/clock.c
00:51 < kleemajo> TheSeven: look for ClockGateTable
00:51 < kleemajo> TheSeven: otg is 0x18 and phy is 0x19
00:52 < kleemajo> TheSeven: it should work fine if you turn them all on though
00:52 < TheSeven> seems to be consistent with my gate numbers
00:52 < TheSeven> CLOCKGATE_USB_1 is apparently the OTG, and 2 is the PHY
00:52 < TheSeven> nice to know
00:52 < kleemajo> TheSeven: how exactly did you do clockgates?
00:52 < TheSeven> the main difference now is that the working friver uses polling instead of interrupts
00:53 < TheSeven> REG &= ~(1 << gatenum)
00:53 < TheSeven> wrapping to the next reg every 32 gates of course
00:53 < TheSeven> #define PWRCON(i)    (*((uint32_t volatile*)(0x3C500000 + ((i) == 4 ? 0x6C : ((i) == 3 ? 0x68 : ((i) == 2 ? 0x58 : ((i) == 1 ? 0x4C : 0x48)))))))
00:54 < kleemajo> TheSeven: makes sense, there were a few that set 10 different bits though which confused me...
00:54 < kleemajo> TheSeven: I need to look into that more
00:54 < TheSeven>     if (enable) PWRCON(gate >> 5) &= ~(1 << (gate & 0x1f));
00:54 < TheSeven>     else PWRCON(gate >> 5) |= 1 << (gate & 0x1f);
00:55 < kleemajo> TheSeven: ah, toolchain finally finished compiling
00:56 < TheSeven> wow, that was fast
00:56 < TheSeven> i've seen that take two hours on some machines :)
00:56 < TheSeven> try014 is up, reboots on any USB irq, and unmasks all USB irq sources to somehow produce one
00:57 < kleemajo> TheSeven: same as before
00:58 < TheSeven> ok
00:58 < kleemajo> TheSeven: if you want to debug, you can write to the framebuffer. It's already set up at 0xfc00000
00:58 < TheSeven> oh, nice
00:58 < TheSeven> try015: reboot on any enabled IRQ
00:59 < TheSeven> the timer should trigger that one
00:59 < TheSeven> what's the frame buffer resolution and pixel format?
00:59 < kleemajo> RGB888
00:59 < TheSeven> nice :)
00:59 < kleemajo> 320 by 480
00:59 < TheSeven> 24 or 32bit mapped?
00:59 < kleemajo> or vice versa
01:00 < TheSeven> so address+=3 means move one pixel on the 320pixel axis?
01:01 < kleemajo> TheSeven: I'm just checking, give me a sec
01:04 < kleemajo> TheSeven: so it's 32 bits per pixel
01:04 < kleemajo> TheSeven: wraps at 320
01:05 < TheSeven> so XRGB?
01:05 < TheSeven> that's not so nice...
01:05 < TheSeven> which byte is the unused one?
01:06 < kleemajo> looks like XRGB
01:06 < kleemajo> the msb is unused
01:07 < TheSeven> when being read as little endian 32bit ints?
01:07 < kleemajo> yes
01:07 < TheSeven> so actually the last byte
01:07 < kleemajo> wait
01:07 < kleemajo> yes
01:07 < kleemajo> haha
01:07 < kleemajo> sorry, I'm not super familiar with this framebuffer stuff.
01:08 < TheSeven> so byte-wise it's probably B G R X...
01:08 < kleemajo> probably
01:08 < kleemajo> I'll test it
01:09  * TheSeven has only dealt with RGB565 displays so far, so this one might need some changes
01:11 < kleemajo> mw 0xfc00000 0xff0000 -> first pixel red
01:11 < kleemajo> mw 0xfc00004 0x00ff00 -> second pixel green
01:11 < kleemajo> mw 0xfc00008 0x0000ff -> third pixel blue
01:11 < kleemajo> where mw writes 32 bits to the specifies address
01:12 < kleemajo> so BGRX
01:13 < kleemajo> and it does wrap at 320 as expected (so each line starts at an address that is a multiple of 0x500)
01:18 < kleemajo> ok, figure out your build system :)
01:18 < kleemajo> TheSeven: can you send me a patch of the version without any reboots?
01:37 < TheSeven> kleemajo: try016 is up, which has a completely untested framebuffer driver
01:38 < TheSeven> http://files.freemyipod.org/tmp/emcore-try016.patch
01:40 < TheSeven> just run "make ipodtouch2g" in emcore/trunk and you should get a file called build/ipodtouch2g/emcore.bin
01:40 < kleemajo> TheSeven: it put a string of white dots down the left side of the lcd
01:41 < TheSeven> so the whole left column is white? or only every n-th pixel?
01:41 < kleemajo> every 2nd pixel, but it skips blocks occasionally
01:41 < TheSeven> oh, caught it already
01:42 < TheSeven> try017 :)
01:43 < kleemajo> haha, it kind of worked
01:44 < TheSeven> what does it look like? :)
01:44 < kleemajo> I can read the text
01:45 < kleemajo> although it only put pixels every 3 lines or something
01:45 < kleemajo> and used black for text, white for background
01:45 < TheSeven> the "empty" lines are black or white?
01:45 < kleemajo> black
01:46 < TheSeven> is the text stretched to three times its height, or are those lines just missing?
01:46 < kleemajo> the text is stretched
01:46 < kleemajo> I'd take a picture, but my webcam just broke yesterday
01:48 < TheSeven> found it
01:48 < TheSeven> try018 - should be fixed
01:49 < TheSeven> and it was actually every fourth line :)
01:49 < kleemajo> makes sense
01:50 < kleemajo> it works... black text on white
01:50 < kleemajo> nice
01:50 < TheSeven> \o/
01:50 < TheSeven> so the question is now why USB doesn't work...
01:50 < kleemajo> The output is:
01:50 < kleemajo> emCORE v0.2.2 r708:709M
01:51 < kleemajo> No usable boot options, waiting for USB commands
01:51 < TheSeven> perfect :)
01:51 < TheSeven> did you ever test try015 btw?
01:51 < TheSeven> did it reboot?
01:51 < TheSeven> thi
01:51 < TheSeven> this seems to have been lost in the framebuffer discussion
01:52 < kleemajo> TheSeven: can't remember
01:52 < TheSeven> can you try again?
01:52 < TheSeven> i'd expect it to reboot
01:52 < TheSeven> if yes, i'd assume that the kernel is fully up and running, and it's just that USB IRQs get stuck somewhere
01:52 < kleemajo> yup, reboots
01:54 < fmibot> New commit by theseven (r710): emCORE: New target: iPod Touch 2G
The kernel works, LCD works, but USB is broken. Apart from that, it's about on par with the iPod Nano 4G port
01:55 < kleemajo> nice
01:55 < fmibot> r710 build result: emcore: All green!
01:55 < TheSeven> haha, that was the fastest-ever new port :)
01:55 < kleemajo> TheSeven: I'll take a look at it and see if I can get usb working
01:55 < TheSeven> binaries should now be available at http://builds.freemyipod.org/
01:56 < TheSeven> some more notes:
01:56 < TheSeven> - the working code i sent you earlier doesn't use IRQs at all
01:56 < TheSeven> (everything is done by polling)
01:57 < kleemajo> TheSeven: is that some setting in the code?
01:57 < TheSeven> no, that code was written to be as trivial as possible :)
01:57 < TheSeven> - to print data to the lcd, you can use cprintf(1, "formatstring: %d", arguments);
01:58 < kleemajo> cool
01:59 < TheSeven> those prints are normally atomic, so prints from multiple threads will synchronize to each other. if you're inside an IRQ handler or critical section, use csprintf instead, which will immediately write to the LCD, as synchronization primitives aren't available in that context
01:59 < TheSeven> so this one might end up printing in the middle of some other output, but is safe to use from everywhere
02:00 < TheSeven> 1 is the console bitmask, 1 being the lcd, 2 the usb console (should work as soon as usb works), 4 the uart (not implemented on that target)
02:01 < TheSeven> if you want to periodically output some registers or whatever else, insert an endless loop in init.c, between lines 247 and 248
02:01 < TheSeven> you can use sleep() there, which has nanosecond resolution
02:02 -!- [Saint] [~st.lasciv@203.184.19.113] has quit [Disconnected by services]
02:02 -!- S_a_i_n_t [~st.lasciv@203.184.19.113] has joined #freemyipod
02:03 < kleemajo> TheSeven: looks good
02:03 < TheSeven> feel free to ask me if any questions arise :)
02:03 < kleemajo> TheSeven: your code is nice... openiBoot is quite messy in comparison
02:03 < TheSeven> i'm not sure about that
02:03 < TheSeven> openiboot is certainly documented way better, but at some places probably not as flexible as emcore
02:04 < TheSeven> i designed this to support multiple, completely different devices from the beginning
02:04 < TheSeven> and as i'm basically the only kernel developer, i know the code rather well :)
02:04 < kleemajo> TheSeven: Ya, openiBoot was only designed to support one device. ricky26 is working on fixing that, but it's still a work in progress
02:05 < TheSeven> feel free to look at emcore/trunk/Makefile
02:05 < TheSeven> this now uses some rather sophisticated constructs, which can save a lot of work :)
02:06 < TheSeven> i basically cherrypicked all the good things I could find from the rockbox code, and then improved the rest
02:06 < kleemajo> :)
02:09 < TheSeven> kleemajo: as a first experiment you might want to add a loop that prints GINTSTS every second to the LCD, to check whether the USB IRQs even reach that level
02:09 < TheSeven> you'll need to include "usb/synopsysotg.h" in init.c, and add the following loop at init.c:248
02:10 < TheSeven> while (1) { cprintf(1, "GINTSTS: 0x%08X\n", GINTSTS); sleep(1000000); }
02:11 < TheSeven> already tried building it?
02:12 < kleemajo> yup, was playing around with some stuff already
02:12 < kleemajo> looks like sleep is broken...
02:12 < kleemajo> I'll try to figure it out
02:12 < TheSeven> very short sleeps as well? (try 100 or something)
02:13 < TheSeven> kleemajo: might point towards some more general IRQ problem than just USB
02:14 < TheSeven> however, there are at least *some* irqs triggering
02:14 < kleemajo> yup, short sleeps are broken too
02:14 < TheSeven> so it isn't just some massively-off frequency
02:15 < TheSeven> kleemajo: does udelay instead of sleep work?
02:15 < TheSeven> if yes, the usec timer is ticking, but timer irqs aren't firing
02:16 < TheSeven> we're using TIMERB to wake up after a sleep, so that one might deserve a closer look
02:16 < kleemajo> udelay looks broken too
02:17 < kleemajo> probably some timer setup stuff
02:17 < TheSeven> try a delay-less loop printing USEC_TIMER
02:17 < TheSeven> (which is 0x3c700080 divided by 10)
02:17 < TheSeven> does the value move at all?
02:18 < kleemajo> nope, stuck at 13822715
02:18 < kleemajo> You know your code very well, I'm impressed
02:18 < TheSeven> well, after all, it's *my* code
02:18 < kleemajo> you have never taken more than 3 seconds to propose a solution
02:19 < kleemajo> I haven't even had time to think of anything :)
02:19 < TheSeven> i've written the kernel from scratch, and i've ported it to several targets, facing all kinds of problems
02:19 < kleemajo> haha
02:19 < TheSeven> ok, try including "ipodnano4g/s5l8720.h", and setting PWRCON(0) to PWRCON(4) to zero before entering that timer printing loop
02:20 < TheSeven> if it still isn't moving, it's at least not a clock gate that's the culprit
02:20 < kleemajo> I'm guessing it has something to do with a function in openiboot called "timer_init_rtc" with a comment that says "do some voodoo"
02:20 < TheSeven> hm, actually, looking at the code, i realize that crt0.S already enables all clock gates in the first two regs, where the most important one seem to be
02:21 < TheSeven> i've seen very low level code rely on that timer, so i'd expect it to be set up already
02:22 < TheSeven> however, i remember seeing some voodoo regarding that as well
02:22 < TheSeven> some ROMs however set up a different timer with 1usec interval
02:23 < TheSeven> can you check whether *((uint32_t*)0x3c7000b4) moves?
02:23 < TheSeven> that's one that i've seen being used instead of that voodoo one
02:24 < TheSeven> kleemajo: if it does, grab the last two sections from target/ipodnano3g/crt0.S and copy-paste them into the ipt2g crt0.S
02:24 < kleemajo> nah, it's stuck too
02:24 < TheSeven> damn
02:25 < TheSeven> well, try copy-pasting the oib voodoo code in front of the printing loop?
02:26 < TheSeven> this is some of the timer voodoo from an 8702 bootloader:
02:26 < TheSeven> 	mov	r4, #0x440
02:26 < TheSeven> 	str	r4, [r1,#0xa0]
02:26 < TheSeven> 	mov	r4, #0xb
02:26 < TheSeven> 	str	r4, [r1,#0xb0]
02:26 < TheSeven> 	mvn	r4, r2
02:26 < TheSeven> 	str	r4, [r1,#0xa8]
02:26 < TheSeven> 	str	r3, [r1,#0xa4]
02:26 < TheSeven> r1 being 0x3c700000 and r3 being 0x3
02:27 < TheSeven> and r2 being zero
02:27 < TheSeven> so, if you want to try that, this would be:
02:27 < TheSeven> *((uint32_t*)0x3c7000a0) = 0x440;
02:27 < TheSeven> *((uint32_t*)0x3c7000b0) = 0xb;
02:28 < TheSeven> *((uint32_t*)0x3c7000a8) = 0xffffffff;
02:28 < TheSeven> *((uint32_t*)0x3c7000a4) = 0x3;
02:28 < TheSeven> kleemajo: try putting that in front of the printing loop
02:28 < kleemajo> ah, got it working with some voodoo from openiboot
02:28 < kleemajo>     *((uint32_t*)0x3c700088) = 0xA;
02:28 < kleemajo>     *((uint32_t*)0x3c700090) = 0xffffffff;
02:28 < kleemajo>     *((uint32_t*)0x3c70008c) = 0xffffffff;
02:28 < kleemajo>     *((uint32_t*)0x3c700098) = 0xffffffff;
02:28 < kleemajo>     *((uint32_t*)0x3c700094) = 0xffffffff;
02:28 < kleemajo>     *((uint32_t*)0x3c700088) = 0x18010;
02:29 < TheSeven> ah, yeah, mine was actually the voodo for the b4 timer :)
02:29 < kleemajo> voodoo is amazing
02:29 < TheSeven> that 0x18010 value also looks very known to me
02:29 < TheSeven> i bet that's in some of my hwinit code as well
02:29 < kleemajo> Bus 001 Device 049: ID ffff:e000
02:30 < kleemajo> usb works
02:30 < TheSeven> that's what I expected :)
02:30 < TheSeven> it got stuck in the udelay in the init code...
02:30 < kleemajo> nice
02:30 < TheSeven> so i'd suggest copying target/ipodnano4g/timer.c to the ipt2g directory, changing the corresponding line in SOURCES, and moving the voodoo to timer_init()
02:31 < TheSeven> to get accurate timing you'll have to patch some more values in that file anyway
02:31 < kleemajo> yeah, it looks a bit off
02:31 < TheSeven> in which direction? too slow or too fast?
02:32 < kleemajo> what's it supposed to be counting in?
02:32 < TheSeven> USEC_TIMER? in microseconds
02:32 < kleemajo> that would make sense...
02:32 < TheSeven> so the 3rd hex digit should change every second
02:32 < TheSeven> but sleeps may nevertheless be inaccurate because the wakeup being scheduled are probably off
02:33 < TheSeven> emcore uses a tickless kernel
02:33 < kleemajo> 3rd hex digit?
02:34 < TheSeven> 0xxxXxxxxx < rthe highlighted digit should increment by one every second if it's accurate
02:34 < TheSeven> that digit corresponds to 1048576, which is close enough to 1M
02:35 < TheSeven> 0x..X.... < readability...
02:35 < TheSeven> the*
02:35 < TheSeven> argh, now I missed a dot at the end...
02:35 < kleemajo> about 2 secs for each switch, so its slow
02:35 < TheSeven> interesting...
02:35 < TheSeven> but should work for now
02:35 < TheSeven> want to try out the USB interface?
02:36 < kleemajo> sure
02:36 < kleemajo> what tools?
02:36 < TheSeven> libusb, python 2.6/2.7, pyusb >=1.0.0a0
02:36 < TheSeven> usually only the last one will need to be installed
02:37 < TheSeven> http://downloads.sourceforge.net/project/pyusb/PyUSB 1.0/1.0.0-alpha-1/pyusb-1.0.0-a1.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fpyusb%2Ffiles%2FPyUSB%25201.0%2F1.0.0-alpha-1%2F&ts=1303674758&use_mirror=puzzle
02:37 < kleemajo> == python-usb in ubuntu repos?
02:37 < TheSeven> untar, run "sudo python setup.py install" in the directory
02:37 < TheSeven> no, python-usb ist too old
02:37 < TheSeven> that's v0.4.2
02:38 < TheSeven> then i'd suggest adding the following alias:
02:38 < TheSeven> alias emcore="python /path/to/emcore/trunk/tools/emcore.py"
02:39 < TheSeven> if you want to be able to use this as non-root, you'll have to do the following things as well:
02:39 < TheSeven> add yourself to some group that gets libusb access, (or pick some existing group to abuse for that purpose)
02:40 < TheSeven> sudo apt-get install acl
02:40 < TheSeven> create a file called /etc/udev/rules.d/50-libusb.rules (you may change the name if you want)
02:40 < TheSeven> content: SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", RUN+="/bin/setfacl -m g:usb:rw $env{DEVNAME}"
02:40 < TheSeven> the "usb" in g:usb:rw is the group access will be granted to
02:41 < kleemajo> haha, just running as root seems easier
02:41 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
02:41 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
02:42 < [7]> well, not if you want to use this as part of a build process one day, like i need to
02:43 < [7]> but if you want to run it as root, i'd suggest adding the sudo to the alias
02:43 < [7]> then run for example the following:
02:43 < [7]> emcore writedevconsole 1 "Hello, World!"
02:45 < kleemajo> it worked!
02:45 < [7]> run just "emcore" to get a list of commands
02:45 < [7]> not all will be available with the set of drivers currently implemented
02:45 < kleemajo> I did already... there are a lot!
02:45 < [7]> but things like emcore run, emcore getprocinfo, emcore uploadfile and emcore downloadfile will be very useful
02:46 < [7]> oh, and emcore execfirmware
02:46 < [7]> you can use that to run firmware from e.g. 0x08000000, but not from 0x22000000
02:47 < [7]> emcore has relocated itself to 0x0fXXXXXX and 0x220XXXXX
02:47 < kleemajo> ok
02:48 < [7]> kleemajo: i've asked the server admin to give you commit access to the svn, so that you can upload your fixes tomorrow, when he's awake again (he's utc+2 as well)
02:49 < [7]> and as I said, feel free to play around, ask questions and cherrypick whatever code you like
02:50 < kleemajo> [7]: I have to say that I am very impressed with emcore... it took what 3 hours to get usb + lcd working...
02:50 < kleemajo> you are crazy
02:50 < [7]> well, LCD was damn easy as it's just memory mapped
02:50 < [7]> the other LCDs i've implemented have taken me days
02:51 < kleemajo> well technically it needs to be set up, but it already is
02:51 < [7]> USB was basically for free as we knew that the driver was compatible before even starting
02:51 < [7]> if you want to test usb stability, go ahead and upload/download/compare huge chunks of memory
02:51 < kleemajo> [7]: that's exactly what I was planning on doing
02:51 < [7]> use odd sizes and alignments so that it will have to mix direct dma with indirect transfers
02:52 < kleemajo> [7]: the oib usb code breaks after doing more than 1 transfer
02:52 < esto> guys you are amazing
02:52 < esto> its impressive to see the port in less than 1 day 
02:56 < [7]> yeah, actually three and a half hours after I had the crazy idea to try this :P
02:57 < kleemajo> [7]: this will definitely help both projects... need more people with 2g touch devices though
02:59 < [7]> this has proven once again that 2am to 5am is the most productive time of the day :)
03:00 < [7]> kleemajo: one of the advantages of emcore is that you can run apps, which are built separately from the kernel, and if they didn't crash badly, you can even update them without rebooting
03:01 < [7]> combined with the ability to implement drivers in userspace for testing, this can save quite a lot of work
03:01 < kleemajo> [7]: It definitely looks good
03:01 < kleemajo> [7]: I think that I'll have to get emcore up to date with openiboot
03:02 < kleemajo> [7]: shouldn't be too hard since everything is implemented in openiboot already
03:02 < kleemajo> [7]: also, usb transfers are working perfectly
03:02 < [7]> it's ideal for poking at the hardware in a controlled environment, allowing to test one component after the other of a driver being implemented
03:03 < kleemajo> cool
03:03 < [7]> this reduces the test cycle time in many cases to like 10 seconds, where other solutions would need several minutes and complicated procedures, during which you've already forgotten what you originally wanted to do
03:04 < [7]> you can reset most things without a reboot by just running emcore execfirmware on itself :)
03:04 < [7]> now go ahead, compare the USB drivers, and spot the bug :)
03:05 < kleemajo> Haha, sounds good
03:06 < kleemajo> Anyways, I need to go get groceries
03:06 < [7]> and I need to fall asleep :)
03:06 < kleemajo> haha
03:07 < [7]> that was a really nice hacking night
03:07 < kleemajo> definitely
03:07 < kleemajo> I have exams next week until thursday so I probably won't get much done, but I'd love to work on emcore after that
03:07 < [7]> reminds me of the day when I broke the ipod nano 2g's nor encryption during a similarly productive night :)(
03:09 < kleemajo> nice
03:13 -!- kleemajo is now known as kleemajo|idle
03:47 -!- kyle6513 [~kyle6513@CPE-121-208-218-78.mjcz2.cha.bigpond.net.au] has joined #freemyipod
04:57 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Ping timeout: 258 seconds]
05:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
05:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
05:11 -!- kyle6513 [~kyle6513@CPE-121-208-218-78.mjcz2.cha.bigpond.net.au] has quit [Quit: Leaving]
05:34 < timccc1> !
06:03 -!- Keripo1 [~Keripo@dhcp0101.kin.resnet.group.upenn.edu] has quit [Ping timeout: 260 seconds]
06:08 -!- Keripo [~Keripo@165.123.49.251] has joined #freemyipod
07:31 -!- timccc1 [~timccc@112.166.15.141] has quit [Ping timeout: 260 seconds]
07:38 -!- timccc [~timccc@112.166.15.141] has joined #freemyipod
07:56 -!- Keripo [~Keripo@165.123.49.251] has quit [Quit: Leaving.]
08:33 -!- kyle6513 [~kyle6513@CPE-121-208-218-78.mjcz2.cha.bigpond.net.au] has joined #freemyipod
09:38 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
09:46 -!- soap is now known as soP_
09:46 -!- soP_ is now known as soap_
10:33 -!- S_a_i_n_t [~st.lasciv@203.184.19.113] has quit [Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...]
10:52  * [7] just identified a dozen FTL and PMU interface GUIDs: http://www.freemyipod.org/wiki/GUID_table
10:53 < [7]> (nano4g)
11:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
11:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
11:06 < user890104> [7]: if there are any drivers from openiboot that can be useful in emcore, i can try porting them
11:06 < user890104> unless... well ... they're written in assembly :)
11:06 < [7]> no, oib's drivers aren't
11:07 < [7]> however it's probably better to let someone who has an 8720-based device do it
11:07 < [7]> which would be kleemajo, Farthen and me
11:08 < [7]> and cmwslw in case he ever turns up again
11:08  * user890104 has a 8720-based device, too (nano4g)
11:08 < [7]> ah? didn't know that :)
11:08 < kyle6513> hm
11:08 < [7]> thought you were nano2g-only :P
11:08 < kyle6513> I have a nano4g if you'll need it.
11:08 < user890104> nope, nano2g, nano3g, nano4g and ipod4g
11:11 < user890104> and i'm looking for a classic, second hand or something because new ones are ... a bit expensive
11:12 < user890104> (new classic 3g is about 236 EUR in Bulgaria)
11:15  * [7] added some more GUIDs, the FTL's interface should be complete now
11:15 < teuf> user890104: second hand 80GB classic seems to be around 100€ here
11:18 < user890104> i have found a second hand 120gb one for 60 EUR, but someone bought it before me
11:18 < user890104> i think it was classic 1g or classic 2g
11:20 < teuf> 120GB is 2G
11:20 < teuf> 1G is 80GB/thick 160GB
11:20 < user890104> ah, thanks
11:27 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
11:57 < benedikt93> [7], you can often find more details on the GUIDs by grep'in first value of them in the UDK
12:01 < benedikt93> they often relate to the so-called "protocols"
12:02 < benedikt93> http://feishare.com/edk2doxygen/index.html <--- is also interesting for understanding EFI
12:03 < benedikt93> UDK --> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
12:07 < [7]> benedikt93: yes, these are all protocol guids
12:07 < [7]> but i would have expected most of the interesting ones to be proprietary apple protocols
12:09 < [7]> feel free to add links to the source files to the table for that ones that turn up in UEFI :)
12:13 < [7]> benedikt93: this is also very helpful: http://pastie.org/1831128
12:35 < [7]> aha, the accelerometer is a LIS302DL
12:35 < [7]> http://www.st.com/stonline/books/pdf/docs/12726.pdf
13:17 < benedikt93> whoaa, so we do support iOS dvices now?^^
13:27 < user890104> it seems so
13:28 < [7]> this is just an early kernel port, with no intention to release it to end users
13:28 < [7]> this is openiboot's domain
13:28 < [7]> it's mainly intended to be helpful for developers, and to share drivers with openiboot
13:35 < user890104> i'm wondering why apple used 87xx one in the 2g touch, the rest are all 89xx
13:47 -!- iSiDoRoS [4fa79476@gateway/web/freenode/ip.79.167.148.118] has joined #freemyipod
13:48 -!- iSiDoRoS [4fa79476@gateway/web/freenode/ip.79.167.148.118] has quit [Client Quit]
13:51 -!- timccc [~timccc@112.166.15.141] has quit [Ping timeout: 252 seconds]
13:52 -!- timccc [~timccc@112.166.15.141] has joined #freemyipod
14:16 -!- Keripo [~Keripo@eng441.wireless-resnet.upenn.edu] has joined #freemyipod
14:50 -!- Keripo [~Keripo@eng441.wireless-resnet.upenn.edu] has quit [Quit: Leaving.]
16:22 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Quit: hallowed are the ori!]
16:41 -!- kleemajo|idle [~kleemajo@host176-169.resnet.ubc.ca] has quit [Quit: Leaving]
16:47 -!- n1s [~quassel@rockbox/developer/n1s] has joined #freemyipod
16:54 -!- Keripo [~Keripo@eng441.wireless-resnet.upenn.edu] has joined #freemyipod
17:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
17:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
17:23 -!- kleemajo [~kleemajo@128.189.169.176] has joined #freemyipod
17:30 -!- kyle6513 [~kyle6513@CPE-121-208-218-78.mjcz2.cha.bigpond.net.au] has quit [Quit: Leaving]
18:04 < user890104> http://www.everymac.com/ultimate-mac-lookup/?search_keywords=a1288
18:05 < user890104> so the 3g ipod touch use the same cpu as the 2g ones?
18:05 < kleemajo> only the 8gb version
18:06 < user890104> ok, thanks
18:06 < kleemajo> the 16gb and 32 gb have a S5L8922
18:40 -!- bcoco85 [~co@77.225.204.126] has quit [Ping timeout: 260 seconds]
18:41 -!- bcoco85 [~co@77.225.204.126] has joined #freemyipod
19:18 -!- Keripo [~Keripo@eng441.wireless-resnet.upenn.edu] has quit [Quit: Leaving.]
19:21 -!- Keripo [~Keripo@eng441.wireless-resnet.upenn.edu] has joined #freemyipod
19:28 -!- bcoco85 [~co@77.225.204.126] has quit [Ping timeout: 250 seconds]
21:07 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Read the fucking binary.]
22:19 -!- Kebianizao [~kvirc@224.69.22.95.dynamic.jazztel.es] has joined #freemyipod
22:41 -!- n1s [~quassel@rockbox/developer/n1s] has quit [Remote host closed the connection]
23:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
23:03 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
23:05 -!- [Saint] [~st.lasciv@203.184.19.113] has joined #freemyipod
23:09 -!- Kebianizao [~kvirc@224.69.22.95.dynamic.jazztel.es] has quit [Quit: Estaba usando KVIrc KVIrc Equilibrium 4.1.1, revision: 5639, sources date: 20110306, built on: 2011-04-12 20:52:16 UTC 5639 http://www.kvirc.net/]
--- Log closed Tue Apr 26 00:56:18 2011