--- Log opened Tue Aug 10 00:01:40 2010
00:01 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #freemyipod
00:01 < angelwolf71885> i bet because you can basicly just upload drivers from older ipods right?
00:01 < angelwolf71885> because ibugger forced you to write the drivers right?
00:02 < cmwslw> no the drivers still have to be written, it's just a lot more of an organized coding environment
00:03 < angelwolf71885> oh i see
00:03 < angelwolf71885> well as i read it on the site emBISOS alows easy porting of older drivers
00:03 < angelwolf71885> and intigrashion of all drivers
00:04 < angelwolf71885> so i took that to mean just upload already writen drivers from older ipods xD
00:05 < cmwslw> no every ipod has its own set of drivers, just the tools that use emBIOS can be generation-independent for the most part
00:05 < angelwolf71885> oh i see lol
00:06 < angelwolf71885> dose emBIOS live on the utility flash? the one where emergiancey disk mode lives?
00:06 < cmwslw> it doesn't live anywhere right now, we just upload it using iBugger
00:07 < angelwolf71885> oh i see lol
00:07 < angelwolf71885> well what made ibugger such a mess? lack of easy API's?
00:09 < cmwslw> we had two different versions of ibugger for the 2g and 4g
00:09 < cmwslw> both duplicated a lot of code driver-wise
00:09 < cmwslw> plus we also had drivers written in iloader
00:10 < angelwolf71885> but them both being diffrent made codeing a pain because of diffrent api's and such correct?
00:10 < angelwolf71885> wow thats alot of code dupes
00:11 < angelwolf71885> but wasnt ibugger just for development and everthing was gunna be implimented into iloader?
00:11 < angelwolf71885> or was ibugger the one loading iloader?
00:12 < cmwslw> ibugger was just a development tool and a way to get code to run
00:12 < angelwolf71885> ok lol
00:13 < TheSeven> well, iloader was duplicating code of ibugger, which was then duplicated by the installer, uninstaller and nandfsck, and the ibugger loader code was also duplicated into ibugger core, and all of these were duplicated for every ipod generation
00:13 < angelwolf71885> well its great things are being unifyed :D and from the screen shot on the site looks to be much more informative
00:14 < cmwslw> yea the console is awesome for debugging
00:14 < angelwolf71885> holly hell thats one cluster cluck TheSeven
00:15 < TheSeven> not that we had an ibugger console for ages :)
00:16 < cmwslw> thats true but i had no idea how to use it. and there's just something special about it being on the ipods screen
00:16 < TheSeven> yep :)
00:17 < TheSeven> the ibugger console was just another syscall interface that ended up in a console window on the pc
00:17 < angelwolf71885> yah its kinda psicological seeing it on the ipod screen telling you yah code is actuialy running on the ipod
00:18 < TheSeven> now that data partition access seems to be working on the 2g, i'm wondering what to do next...
00:19 < TheSeven> there are still a bunch of todos before we can start writing embios applications
00:19 < TheSeven> - write the actual syscall interface
00:19 < TheSeven> - clean up platform dependent things a bit, there are quite some hardwired pieces in usb.c and init.c
00:20 < angelwolf71885> do you have power controll in embios? or is that more for higer OS like rockbox?
00:20 < TheSeven> - decide on a way how to tell embios which application should be launched on boot
00:20 < cmwslw> i think i saw a place in the platform-independent section that included s5l8701.h
00:20 < TheSeven> - write a tool to accomplish that
00:20 < TheSeven> - hunt for bugs in the fat32 driver
00:21 < TheSeven> - try to get the nano4g branch integrated again
00:21 < cmwslw> +1 for that
00:21 < angelwolf71885> thats one full plate
00:22 < TheSeven> angelwolf71885: what kind of power control? like clock gating/scaling, undervolting, power saving? or power management in terms of switching the unit on and off and reading the battery?
00:22 < TheSeven> cmwslw: that doesn't belong there, whereever it is
00:22 < TheSeven> what's blocking the 4g right now?
00:23 < TheSeven> multitasking, usb and flash access
00:23 < angelwolf71885> well the first one would be clock controll and commands for telling the ipod to switch off
00:23 < cmwslw> well maybe it was from a revision a long time ago
00:23 < TheSeven> flash access can probably be ignored for now, we can still upload apps via usb
00:24 < TheSeven> multitasking is a matter of making the timer and interrupts work, which shouldn't be too hard
00:24 < angelwolf71885> well can ibugger spit out a DIR of the flash?
00:24 < angelwolf71885> i mean embios
00:24 < TheSeven> in theory, yes, on the 2g
00:24 < TheSeven> usb can probably be cherrypicked from the 2g with some minor changes
00:25 < TheSeven> cmw: which one first?
00:26 < angelwolf71885> because when i think flash access i think write ability.. but read ability is something diffrent to me lol
00:26 < TheSeven> cmwslw*
00:26 < TheSeven> angelwolf71885: embios for nano2g has a full fat32 read/write access driver for the data flash
00:26 < cmwslw> id say get the timer working then multitasking
00:27 < cmwslw> then if we have multitasking we can pretty much copy/paste the usb code
00:27 < cmwslw> after tweaking some base addresses
00:27 < TheSeven> usb should work without multitasking
00:27 < angelwolf71885> i ment for the 4g lol.. can it even see the flash? or dose it only see the ram?
00:27 < TheSeven> the latter
00:28 < TheSeven> we don't really have a clue about the 4g hardware/drivers yet :)
00:28 < angelwolf71885> ah ok lol
00:28 < angelwolf71885> yah the 4g is flying blind right now lol
00:28 < cmwslw> you already said it could, but i just couldn't understand the purpose of endpoints and the wakeup functions
00:29 < angelwolf71885> ide say multi tasking so then you can acess multiable pices of HW on the 4g at once
00:30 < angelwolf71885> atleast if i understood where everythings at on that so far
00:30 < TheSeven> ok, so the first step would be making the 4g timer tick
00:31 < angelwolf71885> thats sounds like a plain
00:31 < TheSeven> we'll need to setup a timer to generate an interrupt every SYSTEM_TICK microseconds
00:31 < TheSeven> as a first step, i would just read the timer counter and print it to the lcd to see if it is changing at all
00:32 < TheSeven> once that's done, we need to get interrupts going
00:32 < TheSeven> there shouldn't be much more than that for multitasking
00:32 < angelwolf71885> sounds prety simple and strate forward
00:33 < cmwslw> once you do this for a while you realize thats almost never the case
00:35 < angelwolf71885> yah i certnialy understand that.. it make look simple on payper but in pratice it can be a royial pain
00:35 < angelwolf71885> paper*
00:35 < TheSeven> Connected to emBIOS UNKNOWN (      47) v73.78.50 (SVN revision: 16842752) on UNKNOWN (      48), USB version 00.01Powering device off... done
00:35 < TheSeven> looks like libembios is a *bit* broken right now
00:36 < TheSeven> well, this is indeed *relatively* straightforward compared to other areas, like reading/writing files on the data flash
00:38 < angelwolf71885> yah i never knew writeing to media required a driver untill a few years ago lol
00:39 < TheSeven> cmwslw: what, roughly, is the current base revision of the branch?
00:39 < cmwslw> you mean what I started from or what i've updated to from trunk?
00:40 < TheSeven> angelwolf71885: not only a driver. also an FTL, in this case, which complicates things a lot. It took me months to get write access running without corrupting everything within a few writes
00:40 < angelwolf71885> wow.. that just makes me appreshate the work you have done that much more :)
00:41 < cmwslw> i started from r13 but have merged in applicable changes up to r19
00:41 < cmwslw> pretty much everything after that was incompatible
00:41 < angelwolf71885> was it because of apples propritary mods to the HW? or just a funky qwark of flash media?
00:43 < angelwolf71885> or is FTL also required for HDD's?
00:43 < TheSeven> google would have told you that it's an acronym for "Flash Translation Layer"
00:46 < angelwolf71885> lol i feel dumb for that
00:47 < angelwolf71885> just googled FTL and the first thing to pop up is wikipedia artical for  faster then light xD
00:51 < angelwolf71885> holly hell FTL is a pain its the wear leveling driver..
00:52 < angelwolf71885> well in simple terms.. its ware leveling.. it just makes the flash disk look like a fat disk.. but includes ware leveling
00:55 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]]
00:58 < fmibot> New commit by 3cmwslw (r75): The accel return value should be 8 bits not 32.
00:58 < fmibot> r75 build result: All green!
00:58 < cmwslw> fmibot: i love you!
00:58 < Farthen> yay! it works!
00:59 < Farthen> (actually not really, there seems to be a bug with the error stuff)
00:59 < fmibot> New commit by 3cmwslw (r76): Moved demo code to main.c.
00:59 < fmibot> r76 build result: All green!
01:00 < cmwslw> this is really cool
01:01 < Farthen> silly bash script syntax. now it should work
01:02 < cmwslw> does it test the build of branches too or just trunk?
01:03 < Farthen> only trunk
01:03 < Farthen> it does only build trunk
01:03 < cmwslw> ok
01:03 < Farthen> but a new commit on a branch will also trigger the message
01:04 < Farthen> i'm wondering why it doesn't display the pretty mIRC colors
01:06 < cmwslw> for mine the new commit by cmwslw is highlighted red
01:06 < Farthen> yeah, sure because it's you who is highlighted
01:06 < cmwslw> it normally does that when cmwslw is mentioned but normally it does the whole line
01:06 < slck> because of the channel's +c mode
01:06 < Farthen> thanks
01:06 < slck> :)
01:09 < slck> cmwslw: what's the "while (1) { }" for at the end of demo() ?
01:09 * Farthen kindly asks TheSeven to set the mlock to -c
01:09 < cmwslw> slck: i found out that main() is inside a while(1) {} itself
01:09 < cmwslw> the demo hangs so its not repeated
01:12 < Farthen> great
01:13 < cmwslw> 2 test
01:13 < cmwslw> sweet
01:26 < slck> would it be a good idea to split the embios code into dirs such as include and src
01:26 < slck> i've seen it as a good coding practice
01:42 < fmibot> New commit by 3theseven (r77): Try to bring the nano4g branch up to speed again
01:42 < fmibot> r77 build result: Red for targets ipodnano4g
01:56 * Farthen goes to sleep and leaves the irc bot alone now ;)
02:07 < fmibot> New commit by 3theseven (r78): Make the tick timer tick on the 4g
02:07 < fmibot> r78 build result: Red for target ipodnano4g
02:50 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Ping timeout: 240 seconds]
02:54 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
02:55 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod
02:56 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Client Quit]
04:28 < cmwslw> for some reason the ATTRIBUTE_PRINTF is not working (thats why it failed for fmibot and me)
04:28 < cmwslw> it worked with the old gcc_extensions but not now that its been moved to _ansi.h
04:31 -!- cmwslw [~cmwslw@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Quit: Ex-Chat]
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
05:41 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod
05:43 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has quit [Client Quit]
07:58 -!- perror [~fleury@aldebaran.labri.fr] has joined #freemyipod
08:32 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
10:01 < benedikt93> hi
10:06 < benedikt93> TheSeven, did this happen with my latest version of libembios?
10:06 < benedikt93> <TheSeven> Connected to emBIOS UNKNOWN (      47) v73.78.50 (SVN revision: 16842752) on UNKNOWN (      48), USB version 00.01Powering device off... done
10:07 < TheSeven> after i fixed a bunch of bugs to even make it parse, yes
10:10 < fmibot> New commit by 3benedikt93 (r79): fix libembios.py bugs
10:11 < fmibot> r79 build result: Red for target ipodnano4g
10:11 < benedikt93> TheSeven, could you try it with the new version again as I can't test it myself?
10:12 < benedikt93> r67 should have fixed most of the bugs already
10:17 < teuf> is there any NOR test that would be useful to do on a classic ?
10:19 < TheSeven> in case you manage to make that code work, you could try dumping and decrypting your nor flash
10:19 < TheSeven> we don't have a classic 3g image yet
10:19 < teuf> hmm /me is a bit worried by the "in case you manage to make that code work" part :)
10:20 < TheSeven> i haven't dealt with the code myself, just passed it around
10:20 < TheSeven> serpilliere is the one who wrote it :)
10:20 < teuf> ah ok
10:20 < TheSeven> benedikt93
10:20 < TheSeven> D:\Daten\Projekte\embios>tools\embios poweroff 0
10:20 < TheSeven> Traceback (most recent call last):
10:20 < TheSeven>   File "D:\Daten\Projekte\embios\tools\embios.py", line 166, in <module>
10:20 < TheSeven>     dev = libembios.embios()
10:20 < TheSeven>   File "D:\Daten\Projekte\embios\tools\libembios.py", line 62, in __init__
10:20 < TheSeven>     self.svnrev, self.major, self.minor, self.patch, self.type, self.devtype = i
10:20 < TheSeven> [1:6]
10:20 < TheSeven> ValueError: need more than 5 values to unpack
10:21 -!- watto [~watto@193.203.81.165] has joined #freemyipod
10:22 -!- watto [~watto@193.203.81.165] has left #freemyipod
10:23 -!- watto [~watto@193.203.81.165] has joined #freemyipod
10:28 < benedikt93> ah, it should be i[1:7] in line 62
10:39 < TheSeven> which is probably equivalent to just i[1:]
10:40 < benedikt93> yep
10:49 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
10:55 < TheSeven> btw with that fixed I'm still getting
10:55 < TheSeven> Connected to emBIOS UNKNOWN (0x00000047) v73.78.50 (SVN revision: 16842752) on U
10:55 < TheSeven> NKNOWN (0x00000048), USB version 00.01
10:59 < benedikt93> just briefly looked at usb.c, does that really match the protocoll?
10:59 -!- benedikt93 is now known as benedik93|AFK
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:00 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Remote host closed the connection]
11:01 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
11:06 -!- benedik93|AFK is now known as benedikt93
11:09 < benedikt93> TheSeven, shouldn't it be
11:09 < benedikt93> dbgsendbuf[1] = VERSION_SVN_INT;
11:09 < benedikt93> dbgsendbuf[2] = VERSION_MAJOR | (VERSION_MINOR << 8) | (VERSION_PATCH << 16) | (1 << 24);
11:09 < benedikt93> dbgsendbuf[3] = PLATFORM_ID;
11:09 < benedikt93> ?
11:11 < TheSeven> hm
11:11 < TheSeven> probably yes
11:30 < benedikt93> so, change the protocol specs to fit usb.c or the other way around?
11:42 < TheSeven> i fixed it locally in usb.c
11:43 < benedikt93> did libembios then output what it's supposed to?
11:58 < TheSeven> i haven't checked that yet
12:10 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
13:49 -!- benedikt93 [~benedikt9@pD951FC43.dip.t-dialin.net] has joined #freemyipod
13:49 -!- benedikt93 [~benedikt9@pD951FC43.dip.t-dialin.net] has quit [Changing host]
13:49 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
14:29 < TheSeven> weird...
14:30 < TheSeven> the usec timer seems to be sitting behind a different clock gate than the normal timers
14:32 < TheSeven> timer IRQ is 99% sure IRQ8 on VIC0
15:29 -!- cmwslw [~cmwslw@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod
15:51 -!- Dreamxtreme [~Dreamxtre@92.30.22.218] has joined #freemyipod
15:59 < fmibot> New commit by 3theseven (r80): Yay! Preemptive multitasking on Nano 4G!
15:59 < fmibot> r80 build result: Red for target ipodnano4g
15:59 < TheSeven> the LCD/drawing code doesn't seem to be thread safe though :)
16:00 < TheSeven> cmwslw: Expect funny LCD contents when testing this :P
16:00 < cmwslw> TheSeven: do you have any idea why the ATTRIBUTE PRINTF is not working?
16:00 < TheSeven> hmm no, maybe some __GNUC__ or something not defined in your environment
16:01 < cmwslw> let me see
16:12 < fmibot> New commit by 3theseven (r81): Backport thread-safe console code from Nano 2G
16:12 < fmibot> r81 build result: Red for target ipodnano4g
16:12 < TheSeven> heh, I bet I can type faster than my 4G can show characters on the screen :P
16:13 < Dreamxtreme> heh
16:13 < Dreamxtreme> bit slow
16:14 < TheSeven> just sell that as the "typewriter effect" :D
16:14 < Dreamxtreme> :D
16:15 < cmwslw> TheSeven: Thats why i made the noblit console functions
16:16 < cmwslw> it prints instantaneous if you do that
16:16 < TheSeven> as soon as we have LCD DMA, the blitting will be done asynchronously
16:16 < cmwslw> ok. anyways i don't know why you are still including gcc_extensions.h in panic.h
16:17 < cmwslw> but the thing is, even when I replace it with _ansi.h it still fails
16:17 < TheSeven> this might rather be an explanation why it worked for me
16:18 < cmwslw> do you have an old copy lying around?
16:20 < cmwslw> the _ansi.h works by defining _ATTRIBUTE rather than just using __attribute__
16:20 < TheSeven> no, it apparently doesn't even need that header on my system for whatever reason
16:22 < TheSeven> it seems to be defined in something included from global.h on my system
16:25 < cmwslw> it seems my entire _ansi.h is not processed thats why
16:25 < cmwslw> apparently the include guard is already defined
16:33 < TheSeven> any idea why?
16:33 < TheSeven> if changing it helps, i'd go for ___ANSI_H__. the old one was inconsistent anyways
16:37 -!- Dreamxtreme [~Dreamxtre@92.30.22.218] has quit [Read error: Connection reset by peer]
16:46 -!- Dreamxtreme [~Dreamxtre@92.30.177.68] has joined #freemyipod
16:50 < fmibot> New commit by 3benedikt93 (r82): libembios.py + embios.py now feature complete !
16:50 < fmibot> r82 build result: Red for target ipodnano4g
17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection]
17:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #freemyipod
17:02 < cmwslw> TheSeven: maybe its including another version of _ansi.h included with the compiler
17:02 < TheSeven> i am *not* passing -I/usr/include anymore...
17:02 < cmwslw> and yea changing it helps, but it gets hung up again with the same problem at stdio.h
17:03 < cmwslw> let me make sure no other files in embios use that include guard by mistake
17:04 < cmwslw> nope
17:05 < slck> it compiles fine for me without -I/usr/include 
17:06 < TheSeven> cmwslw: which toolchain are you using?
17:07 < cmwslw> rockbox one
17:08 < cmwslw> i tried arm-elf-eabi and arm-none-eabi and they both have the same problem
17:09 < cmwslw> and it seems farthen is having the same problem with fmibot
17:10 < cmwslw> slck: what os and toolchain do you use?
17:11 < slck> ubuntu 10.04 i386
17:11 < slck> and the rockbox one
17:11 < slck> i added to my .bash_login:
17:12 < slck> export PATH="${PATH}:/home/venci/rbdev/bin:/home/venci/bin" CROSS="arm-elf-eabi-"
17:12 -!- slck_ [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has joined #freemyipod
17:12 -!- slck [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has quit [Read error: Connection reset by peer]
17:12 -!- slck_ is now known as slck
17:13 < slck> and i compile it using only "make <target>"
17:15 -!- benedikt93 is now known as benedik93|AFK
17:18 < Farthen> cmwslw: you mean the -I stuff
17:18 < Farthen> ?
17:22 < cmwslw> i mean fmibot has been failing since gcc_extensions were removed
17:28 < Farthen> fmibot?
17:28 < Farthen> that's the irc bot
17:28 < Farthen> you mean the build script?
17:28 < cmwslw> i use it as a synonym for the build script
17:31 < TheSeven> cmwslw: huh? it seems to be succeeding
17:31 < TheSeven> the nano2g build works absolutely fine
17:32 < cmwslw> maybe fmibot reported it wrong
17:33 < cmwslw> well apparently its only me with this problem then
17:33 < Farthen> where? it only says that it fails for nano4g
17:34 < cmwslw> well i thought your build script was failing because of my problem, but i just found out it only compiles trunk
17:35 < Farthen> yep
17:35 < cmwslw> i thought it said it failed for the 4g_compat branch
17:36 < Farthen> i don't see the need for it compiling branches as they are nothing that anyone wants to use. they are basically for testing
17:37 < cmwslw> can you compile the 4g_compat branch yourself?
17:43 * TheSeven thinks an efi guid database in the wiki or somewhere would be helpful
17:43 < TheSeven> just a mapping what a guid stands for and where to find more information
17:49 < benedik93|AFK> TheSeven, btw, anything new from serpilliere?
--- Log opened Tue Aug 10 17:49:40 2010
17:49 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #freemyipod
17:50 -!- perror [~fleury@aldebaran.labri.fr] has quit [Quit: Bye all !]
17:56 < Dreamxtreme> serpilliere working on the Classics  ?
18:05 < benedik93|AFK> Dreamxtreme, nano 3g, I myself do so, too
18:06 < Dreamxtreme> O ok 
18:06 < cmwslw> Ok well i don't know why this didn't work before, but i must have had other changes at the same time
18:06 < cmwslw> all I had to do was simply change the include guard
18:06 < Dreamxtreme> ive got a classc 1G sitting here and waiting lol 
18:07 < cmwslw> this still doesn't explain why it worked for everyone else though
18:08 < benedik93|AFK> the classics are very similiar to the nano 3g
18:08 < Dreamxtreme> so you would say that once the 3G is cracked the classics are coming very soon after?
18:18 < teuf> I'd say that all models except the nano5g are cracked, so we must have different definitions for this word ;)
18:24 < Dreamxtreme> i mean like fully ready for rockbox
18:24 < Dreamxtreme> =D
18:27 < TheSeven> http://www.freemyipod.org/wiki/GUID_Table
18:27 < TheSeven> feel free to complete this
18:27 * Dreamxtreme has a butchers
18:30 -!- benedik93|AFK is now known as benedikt93
18:33 < benedikt93> "<benedik93|AFK> TheSeven, btw, anything new from serpilliere?"
18:33 < TheSeven> not that i know of
18:34 < TheSeven> he's probably still on vacation
18:39 * Dreamxtreme enters noob mode with a couple of questions
18:40 < Dreamxtreme> so what do i need program wise to give you the GUID info 
18:40 < Dreamxtreme> and also will it break my ipod as im still using it as my only player
18:41 * Dreamxtreme now exits noob mode
18:45 < benedikt93> you would need to dump, decrypt, and analyse the code in the NOR flash
18:46 < benedikt93> no, it won't brick your ipod, you can (almost) always restore it via dfu mode
18:46 < benedikt93> you need a dissassembler, an arm toolchain, TheSeven's ipodtools
18:47 < TheSeven> you need, most importantly, a lot of knowledge about ARM processors and EFI
18:47 < Dreamxtreme> ah shame 
18:48 < Dreamxtreme> i dont really have time to read up on all that stuff
18:53 < Dreamxtreme> plus i use it too often to do that
18:53 < Dreamxtreme> wish you could just plug it in and read stuff off it 
18:53 < cmwslw> you can
18:54 < cmwslw> we haven't opened up an ipod since we used jtag on the 2g
18:54 < Farthen> we haven't opened up any ipod except the 2g i think
18:55 < Farthen> well, the broken classic one time
18:55 < Farthen> but that one was... broken
18:55 < Dreamxtreme> i mean so i can still use it when i disconnect it 
18:55 < Dreamxtreme> with the orginal apple firmware on it 
18:55 < cmwslw> so should i just remove references to gcc_extensions.h in a commit?
18:56 < Dreamxtreme> .......for now until rockbox goes on it that is 
18:56 < cmwslw> i'm wondering why they are still there. I'm also thinking about changing the _ansi.h include guard but don't know if this will mess things up for others
18:56 < cmwslw> it shouldn't though
19:01 < TheSeven> [20:55] <cmwslw> so should i just remove references to gcc_extensions.h in a commit? << yes
19:01 < TheSeven> and change the include guard to ___ANSI_H__
19:02 < fmibot> New commit by 3cmwslw (r83): Fixed the _ansi.h include guard and removed references to gcc_extensions.h.
19:02 < fmibot> r83 build result: Red for target ipodnano4g
19:03 < TheSeven> Dreamxtreme: I'm using Rockbox on my 2G, whether I want to test embios or boot rockbox can be chosen from a boot menu, and on the 4G, switching between the apple firmware and ibugger is a matter of copying/removing a file in disk mode
19:03 < TheSeven> so that's not really holding anyone back
19:04 < cmwslw> TheSeven: why do you put test code in init.c rather than main.c
19:04 < TheSeven> because main.c isn't even used right now in trunk
19:08 * TheSeven wants an S5L8720 datasheet
19:09 < cmwslw> did the 8700 one help much?
19:09 < Dreamxtreme> ah o k
19:09 < TheSeven> for the 2g, yes
19:09 * Dreamxtreme waits for rockbox to be unstable on the classic 1G then
19:09 < TheSeven> the 4g has quite a lot of differences, so i always don't quite know whether to trust it or not
19:10 < cmwslw> what are you working on now? usb?
19:14 < TheSeven> i'm having a look at the bootloader's lcd driver
19:15 < TheSeven> if you want to, you can try doing usb yourself
19:15 < TheSeven> it should be a matter of replacing the base adresses and the phy clock register value
19:15 < TheSeven> (and calling the appropriate init functions)
19:16 < cmwslw> ok I can start  but i have plans today and tomorrow so i might not get much time in
19:36 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Read error: Connection reset by peer]
19:36 < TheSeven> hm then i'll probably do it
19:36 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
19:37 * TheSeven got bored digging through efi code
19:58 < n1s> TheSeven: any progress on that?
19:58 < TheSeven> not much
19:58 * TheSeven has just been digging into the lcd driver a bit
19:59 < TheSeven> this is split into two efi modules: Lcd and DisplayPlatform
19:59 < n1s> ok
19:59 < TheSeven> DisplayPlatform registers two protocols to the same function table, and registers an event listener for the registration of the LCD protocol
20:00 < TheSeven> the LCD module then registers that protocol, and triggers the callback, which will then look up the LCD protocol and call various functions in it, which i haven't identified yet
20:00 < n1s> oh, yeah a little bit over complicated for a dap firmware :)
20:00 < TheSeven> however, both modules are talking directly to the hardware, so i can see no reason to split this thing in the first place
20:01 < TheSeven> for a *bootloader* of a dap firmware :)
20:14 * TheSeven is a bit puzzled
20:14 < TheSeven> the usb core just doesn't trigger any ints
20:16 < benedikt93> likely to be the reason why you can't use your ipod when connected to a pc
20:16 < benedikt93> and it just showing that "synchronising"
20:24 < TheSeven> benedikt93: huh?
20:25 < benedikt93> you can't just browse your music then...whatever, just use the functionality provided over usb(diskmode, whatever)
20:26 < TheSeven> that's normal
20:27 * TheSeven still doesn't get what the problem is
20:29 < TheSeven> this is just incredible...
20:29 < TheSeven> VIC0INTENABLE = 0x80000 works
20:29 < TheSeven> VICINTENABLE(irq >> 5) = 1 << (irq & 0x1f) doesn't, with irq being 19
20:30 < TheSeven> #define VICINTENABLE(v)       (*((volatile uint32_t*)(0x38E00010 + 0x1000 * v)))
20:30 < TheSeven> #define VIC0INTENABLE         (*((volatile uint32_t*)(0x38E00010)))
20:30 < TheSeven> what the hell?
20:33 < TheSeven> VIC0INTENABLE = 1 << (irq & 0x1f) works
20:33 < TheSeven> so there's something wrong with the macro. but what?
20:35 * benedikt93 bangs his head on the table
20:36 * TheSeven is confused
20:45 -!- Dreamxtreme [~Dreamxtre@92.30.177.68] has quit [Read error: Connection reset by peer]
20:59 * GaveUp is GaveUp ... nice to meet you ;)
21:12 * benedikt93 finally dumped the whole norflash of his iN3G
21:14 < TheSeven> can anyone have a look what the IRQ number(s) of the I2C controllers on the 4G are?
21:15 < benedikt93> hmm, there are some strings like diagflsh applflsh chrgflsh lbatflsh a t the end with maybe some adresses around them
21:18 < benedikt93> seems to be some filesys
21:20 -!- Dreamxtreme [~Dreamxtre@92.30.117.12] has joined #freemyipod
21:33 < fmibot> New commit by 3theseven (r84): Abandon 4g_compat branch
21:34 < fmibot> r84 build result: Red for target ipodnano4g
21:34 -!- angelwolf71885 [chatzilla@cpe-173-168-248-236.tampabay.res.rr.com] has joined #freemyipod
21:36 < angelwolf71885> hey TheSeven how are things today? i saw you delited the 4G_branch of the emBIOS build tracker thing
21:36 < fmibot> New commit by 3theseven (r85): Merge 4g_compat branch. I2C on Nano4G is known broken and the Nano4G LCD console is dog slow. The rest seems to be working fine.
21:36 < fmibot> r85 build result: All green!
21:37 < angelwolf71885> wow nice. :D
21:37 < TheSeven> cmwslw: don't forget to change your working base before making any changes :)
21:39 < fmibot> New commit by 3benedikt93 (r86): fix embios.py
21:39 < fmibot> r86 build result: All green!
21:39 < TheSeven> Farthen: the build performance of your server is really incredible...
21:40 < Farthen> sure ;)
21:46 < benedikt93> fwiw, the last two builds arent in the list at build.freemyipod.org
21:47 < slck> i was just looking at this one, the php script would need a fix
21:48 < Farthen> yeah
21:48 < slck> and it's coming in some minutes
21:48 < Farthen> hmm, i made some changes. can you create a diff from your version? i should be able to manually apply them
21:48 < slck> Farthen: could you zip the whole dir again please
21:48 < slck> including index.php
21:49 < Farthen> the archive is very big now...
21:49 < slck> and i'll post a modified version of it
21:49 < Farthen> nah, just tell me the line, i will find it myself ;)
21:49 < slck> ok just a sec
21:52 < slck> insert this one before line 45:
21:52 < slck> 		$errors[$project][$rev] = array();
21:52 < slck> it should read:
21:52 < slck>         $rev = substr($filename, 1);
21:52 < slck>         $failed_targets = file($curr_file);
21:52 < slck> 		$errors[$project][$rev] = array();
21:52 < Farthen> ok, thanks
21:53 < Farthen> works now, thanks
21:53 < slck> i have forgotten to initialize the array :)
21:54 < slck> is usb working on nano4g now?
21:54 < slck> i mean is it accessible with the debugger
22:00 < TheSeven> yes
22:01 < slck> 0xFFFF 0xE000 - is that it?
22:01 < TheSeven> yep
22:02 < slck> good job :)
22:09 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
22:10 < slck> i'm having some weird error after installing driver for embios - the ibugger doesn't work now
22:11 < slck> ImportError: DLL load failed: %1 is not a valid Win32 application.
22:11 < TheSeven> hm, 64bit python?
22:12 < slck> i got both 32 bit and 64 bit
22:12 < slck> and i don't know which driver did my windows just installed 
22:12 < slck> i guess it's the 64-bit
22:13 < slck> i'm using your ibugger.inf file with some lines added for embios
22:13 < slck> and libusb-win 1.2
22:13 < TheSeven> hm
22:13 < TheSeven> try using the 64bit python explicitly if your os is 64bit
22:14 < TheSeven> the 32bit python probably can't work with the 64bit driver
22:15 < slck> thanks
22:16 < slck> Connected to emBIOS Debugger v0.0.1 (SVN revision: 86) on iPod Nano 4G, USB version 1
22:16 < Dreamxtreme> WOOHOO!
22:18 * TheSeven wonders what benedisk93's writedevconsole command is doing
22:23 -!- Mr_Sensitive [~Dreamxtre@92.30.68.232] has joined #freemyipod
22:23 -!- Mr_Sensitive [~Dreamxtre@92.30.68.232] has quit [Read error: Connection reset by peer]
22:26 -!- Dreamxtreme [~Dreamxtre@92.30.117.12] has quit [Ping timeout: 276 seconds]
22:26 < slck> damn windows, needs a logoff to refresh my PATH env. variable...
22:27 -!- slck [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has quit []
22:32 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Ping timeout: 258 seconds]
22:32 * TheSeven wonders how to figure out the i2c irq number
22:38 -!- Dreamxtreme [Archimedes@92.30.59.132] has joined #freemyipod
22:40 -!- slck [Venci@Venci-Notebook-LAN.ipv6.6bez10.info] has joined #freemyipod
22:55 < slck> i found some typos in libembios.py
22:55 < slck> http://pastie.org/1084918
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:02 < fmibot> New commit by 3theseven (r87): Fix Nano4G I2C (with polling for now) and do some cleanup
23:02 < fmibot> r87 build result: Red for target ipodnano2g
23:03 < TheSeven> cmwslw: you can play with your accelerometer again :)
23:08 < slck> TheSeven: on nano 4g, the poweroff function resets the device instead of shutting down
23:08 < TheSeven> yes
23:08 < TheSeven> we don't know how to shut it down yet
23:09 < slck> oh ok, i thought it's a bug
23:10 < fmibot> New commit by 3theseven (r88): Fix red
23:11 < fmibot> r88 build result: All green!
23:11 < TheSeven> well, it *is* a bug.
23:11 < TheSeven> also, I have the impression that you can't power off the 4g while it's on usb power
23:15 < slck> i've found another libembios issue, which i don't know how to fix
23:15 < slck> when resetting, it doesn't print the "done!" message
23:29 < slck> another typo at libembios.py:355, __getBulk should be __getbulk
23:37 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Lämnar]
23:55 -!- slck is now known as user890104
--- Log closed Wed Aug 11 00:07:23 2010