--- Log opened Mon Nov 28 00:02:26 2011
01:09 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Quit: hallowed are the ori!]
03:27 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
03:27 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod-support
10:20 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod-support
11:21 < Poodlemastah> Is there any way to read the serial(back of ipod or software) from emcore or rockbox?
11:41 < user890104> Poodlemastah: the serial number?
11:44 < TheSeven> this information isn't displayed anywhere in the user interface, but the software could easily access it
11:47 < user890104> TheSeven: i can complete and commit my serial number patch for emcore
11:47 < user890104> which file should i put get_serial_number in?
11:47 < TheSeven> it's stored at [0x2202BF1C]+0x18, which is usually 0x2202BE08
11:48 < TheSeven> user890104: I'd like a more flexible interface for that, which supports both device model/sn and CPUID, in a target-independent way
11:48 < user890104> on nano 2g, i'm reading it from 0x2202bdf0 + 0x18
11:48 < TheSeven> possibly also the HDD/NAND SN if available
11:49 < TheSeven> yes, that's where it is currently, but the correct way to access it would be to get the pointer from 0x2202bf1c and add 0x18 to that
11:49 < TheSeven> that would work with apple's bootloader as well, which places this information in a different location
11:50 < TheSeven> the main reason to expose that information would be to keep track of multiple devices on a USB bus and allow to select between them in emcore.py
11:50 < TheSeven> but this needs to be done right :)
11:50 < user890104> TheSeven: i added a "serialnumber" option to emcore getinfo, so it should be fine on the pc side. the point is to implement it more flexible on the device side, that's why i'm asking which file it should belong to
11:51 < user890104> sysinfo.c?
11:51 < TheSeven> well, that "serialnumber" option should be able to deal with board model, board sn, soc model, soc sn, hdd model, hdd sn, ...
11:51 < TheSeven> and allow for different string lengths on different targets
11:53 < TheSeven> and ideally get all this information with a single USB call for performance reasons
11:53 < TheSeven> i'm thinking about a pointer map followed by dynamically sized strings or something similar
11:54 < TheSeven> this will probably need an internal version number as well to allow to add more fields in the future
11:55 < user890104> so it would be more like "sysinfo" than "serialnumber"? :)
11:55 < TheSeven> so we'll need to carefully design an interface for that and figure out how to talk to this chipid thing
11:55 < TheSeven> yes
11:55 < TheSeven> hwinfo
11:55 < TheSeven> hm, board revision number would also be interesting
11:56 < TheSeven> not that we have found any differences between the revisions so far, but who knows...
11:57 < TheSeven> Poodlemastah: so what exactly do you want? check if the board SN matches the one lasered on the case?
12:24 -!- ShapeShifter499 [~ShapeShif@c-98-244-33-205.hsd1.ca.comcast.net] has joined #freemyipod-support
15:17 < Poodlemastah> Well, the lasered one is unreadable due to scratching. Would be good to have for possible warranty. No worries though.
15:23 < user890104> Poodlemastah: first, emcore.py downloadint 0x2202BF1C
15:23 < user890104> note the number, then
15:23 < user890104> emcore.py hexdump $[<the above number> + 0x18] 11
15:25 < user890104> ah, doesn't seem to work on classics
15:25 < Poodlemastah> Was just going to say. :)
15:32  * user890104 is wondering where in the NOR flash did TheSeven hide SysCfg
15:38 < user890104> it is memory-mapped on nano2g, but on the classics you need to read it in a different way
15:45 < user890104> Poodlemastah: http://pastebin.com/t8UMecnd
15:50 < Poodlemastah> Worked beautifully. Thanks 89. :)
16:12 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod-support
16:55 < TheSeven> user890104: not me, apple :)
16:55 < TheSeven> and the syscfg is in the first flash sector on the classics
16:55 < user890104> TheSeven: i forgot that it's not memory-mapped, i was looking at the sram dump for it :)
16:56 < user890104> or not actually the sram
16:56 < TheSeven> well, that has nothing to do with each other
16:56 < user890104> more likely the address where it is on nano2g
16:56 < TheSeven> 0x2202BF1C is the SysI pointer
16:56 < TheSeven> that points to a struct that's filled by the bootloader using the data on the NOR flash
16:56 < TheSeven> we haven't implemented that on the classic yet because we only need it for dualboot
16:57 < user890104> ah, i see
16:57 < user890104> that's why i didn't find it where i expected to see it
18:02 -!- mic_ [588619c8@gateway/web/freenode/ip.88.134.25.200] has joined #freemyipod-support
18:03 < mic_> has anyone tried r817 with latest rock box on classic
18:04 < user890104> mic_: depends on what you mean by "lastest"
18:04 < user890104> trunk is not stable at the moment (if it builds at all)
18:04 < user890104> with the 3.10 RC it seems to be working for me
18:05 < mic_> nightly build from today?
18:05 < mic_> or a recent build
18:07 < mic_> new to bin, ucl files how do i put them on ipod...do i need a compiler?
18:07 < mic_> was that a dumb question?
18:08 < mic_> havent  programmed c for last 15years
18:09 < mic_> only used .ubi and .emcore
18:10 < mic_> and .dfu
18:12 < mic_> so put all latest builds in directory  called r817, emcore-ipodclassic-r817.bin, umsboot-ipodclassic-r817.bin, emcore-installer-ipodclassic-r817.ubi,emcore-ipodclassic-r817.ucl  and umsboot-ipodclassic-r817.ucl
18:13 < mic_> what next?
18:13 < mic_> surely not just renaming the ending?
18:14 < user890104> well
18:14 < user890104> in order to update you need only the installer .ubi file
18:14 < user890104> go to Tools -> Run UMSboot
18:15 < user890104> then copy the file in the empty disk drive that appears
18:15 < user890104> eject/unmount depeniding on your OS, and it will update
18:15 < user890104> it's that simple :)
18:16 < user890104> so basicly emcore-installer-ipodclassic-r817.ubi
18:17 < mic_> thanks
18:19 < mic_> what work is being done to improve battery life...does the cpu need a variable voltage?
18:19 < user890104> there's a bug in r817: if you enter the Tools menu and select some option, the action would be carried out when you select "Return to main menu" and not right after selecting it
18:19 < mic_> ok
18:19 < user890104> the cpu is running at high power all the time, because boosting is not yet implemented
18:19 < user890104> but there's something else that affects the battery life
18:20 < user890104> and we still don't know what is it
18:21 < mic_> does emcore just sit upon a simple hard drive..or is there apple hardware encrytion?
18:21 < mic_> or is apple stuff completely removed;-)
18:24 < mic_> why are there 4 partitions?
18:29 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
18:34 -!- ShapeShifter499 [~ShapeShif@c-98-244-33-205.hsd1.ca.comcast.net] has quit [Quit: Leaving]
18:44 < user890104> mic_: the apple's stuff is completely removed, that's why dual booting is not possible at the moment
18:44 < user890104> the whole hdd is superfloppy-formatted
18:44 < user890104> and emcore is not on the hdd actually
18:45 < user890104> it's in the utility flash
18:45 < user890104> so completely wiping the hdd won't remove emcore
18:45 < user890104> but a restore with itunes from DFU mode will
18:48 < mic_> which is the most important issue to solve at the moment?
18:49 < mic_> is emcore to stay in flash utility ?
18:53 < user890104> you mean in order to allow dualbooting the original firmware?
18:57 < mic_> no apple is out of my life...in fact it was only there for 1 day bad experience...slow arduous no controö
18:58 < mic_> emcore r817 is hanging on classic does that mean a failed update or does one just have to wait
19:00 < mic_> menu selected back to r 708
19:01 < user890104> well, someone reported that it does not work with certain ipods because of a recent change
19:01 < user890104> it works on mine though
19:01 < user890104> you should wait for the next official release
19:01 < user890104> which is to happen after the rockbox one (in less than a week IIUC)
19:01 < mic_> :-))))
19:07 < TheSeven> user890104: I'm not sure if we can manage that
19:07 < TheSeven> there's still a lot of work to be done in the boot menu... and i'd really like to include that in the next release
19:08  * TheSeven is tired of people failing to install fastboot correctly
19:08 < user890104> TheSeven: i mean that the *rockbox* release is going to be in a week
19:08 < TheSeven> yeah, but ours will probably not be really close after that
19:09 < TheSeven> we might need another couple of weeks... currently I don't have much time to deal with that stuff... might find some time on wednesday
19:11 < user890104> ah, i see
19:12 < user890104> i can port the classics bootmenu changes to nano2g if that would help
19:12 < user890104> but there's a bug at the moment, so we should fix that first
19:12 < TheSeven> I think my next step will be to add another interface (on top of the generic chooser) to libui
19:13 < user890104> another interface in terms of what?
19:13 < TheSeven> which will be a more simple list interface, which can be used as a dropdown for the default boot option menus
19:14 < TheSeven> I'm basically trying to make bootoptionchooser.c a bit more generic and move it to libui
19:14 < TheSeven> after that, I'll implement a generic spinner control, which will allow to set the timeouts
19:15 < TheSeven> possibly add another "settinglist" interface to libui which handles the control flow of entering the individual setting choosers
19:15 < TheSeven> and use all of that in the boot menu
19:17 < TheSeven> once that's done we can start porting that to the nano2g
19:17 < user890104> ah, ok
19:17 < TheSeven> oh, and we should really track down that memory corruption bug
19:17 < TheSeven> I'm fairly certain that this might actually be a bug in TLSF
19:18 < TheSeven> whether the corruption happens or not seems to be related to the location of some memory allocations
19:19 < TheSeven> http://pastie.org/2905488 is a failing case where everything is still intact when the boot menu terminates, but things seem to get corrupted during the deallocation of the thread handle
19:19 < TheSeven> hm, this discussion should probably move to #freemyipod
19:35 -!- mic_ [588619c8@gateway/web/freenode/ip.88.134.25.200] has quit [Quit: Page closed]
20:00 -!- fuzzix [~fuzzix@cl-380.dub-01.ie.sixxs.net] has left #freemyipod-support
21:31 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Read error: Connection timed out]
23:36 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod-support
--- Log closed Tue Nov 29 00:02:29 2011