| 00:05:02 | | Join Provel [0] (~Provel@75-132-32-77.dhcp.stls.mo.charter.com) |
| 00:13:30 | | Quit yosafbridge (Ping timeout: 240 seconds) |
| 00:15:22 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140616143923]) |
| 00:21:53 | | Join yosafbridge [0] (~yosafbrid@192.241.198.49) |
| 00:31:22 | | Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) |
| 00:37:32 | | Quit Guest70275 (Ping timeout: 240 seconds) |
| 00:38:01 | *** | Saving seen data "./dancer.seen" |
| 00:56:16 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 00:59:02 | | Quit bluebrother^ (Ping timeout: 240 seconds) |
| 00:59:16 | | Quit fs-bluebot (Ping timeout: 272 seconds) |
| 01:00 |
| 01:01:30 | | Join fs-bluebot [0] (~fs-bluebo@f053154187.adsl.alicedsl.de) |
| 01:03:34 | | Quit ZincAlloy (Quit: Leaving.) |
| 01:24:41 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 01:40:20 | | Join JdGordon [0] (~JdGordon@203.111.191.138) |
| 01:40:27 | | Quit JdGordon (Changing host) |
| 01:40:27 | | Join JdGordon [0] (~JdGordon@rockbox/developer/JdGordon) |
| 01:56:40 | | Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) |
| 02:00 |
| 02:09:48 | | Quit zoktar (Read error: Connection reset by peer) |
| 02:12:13 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
| 02:35:20 | | Join Misanthropos_ [0] (~Misanthro@frnk-5f746e1b.pool.mediaWays.net) |
| 02:36:46 | | Quit Misanthropos_ (Client Quit) |
| 02:38:02 | *** | Saving seen data "./dancer.seen" |
| 02:41:51 | | Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
| 03:00 |
| 03:00:02 | | Quit AlexP (Remote host closed the connection) |
| 03:52:22 | | Join us`0gb [0] (~0gb.us@c-71-237-219-28.hsd1.or.comcast.net) |
| 04:00 |
| 04:08:35 | | Join ygrek [0] (~user@108.59.6.97) |
| 04:18:17 | | Quit amiconn (Disconnected by services) |
| 04:18:17 | | Quit pixelma (Disconnected by services) |
| 04:18:17 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:18:17 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:18:17 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:18:17 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:38:04 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:06:37 | | Join steffengy [0] (~quassel@p57B49EC8.dip0.t-ipconnect.de) |
| 05:07:33 | | Quit TheSeven (Ping timeout: 272 seconds) |
| 05:09:06 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 05:09:33 | | Quit steffengy1 (Ping timeout: 240 seconds) |
| 06:00 |
| 06:10:15 | [Saint] | Regarding exFAT vs FAT32 in modern Android handsets, isn't the FS compatibility argument pretty much dead these days? |
| 06:11:50 | [Saint] | I mean, I use F2FS for my external storage (and internal, actually), and MTP makes it completely irrelevant that the host may or may not support it. |
| 06:33:05 | | Join pretty_function [0] (~sigBART@123.252.214.60) |
| 06:33:28 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 06:38:08 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:13:06 | | Quit pamaury (Ping timeout: 245 seconds) |
| 07:53:38 | | Quit pretty_function (Remote host closed the connection) |
| 07:54:10 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 08:00 |
| 08:00:25 | | Quit ygrek (Ping timeout: 264 seconds) |
| 08:00:39 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 08:13:40 | | Quit user890104 (Ping timeout: 244 seconds) |
| 08:15:55 | | Join pretty_function [0] (~sigBART@123.252.214.60) |
| 08:16:27 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 08:18:09 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 08:22:07 | | Join kugel [0] (~kugel@avm-guido.avm.de) |
| 08:22:07 | | Quit kugel (Changing host) |
| 08:22:07 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 08:22:39 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:35:25 | | Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) |
| 08:38:09 | *** | Saving seen data "./dancer.seen" |
| 08:41:10 | | Join ygrek [0] (~user@108.59.6.97) |
| 08:41:19 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:44:30 | | Quit pretty_function (Remote host closed the connection) |
| 08:53:41 | | Join Sparkie [0] (~Sparkie@121-74-147-249.telstraclear.net) |
| 08:54:00 | | Nick Sparkie is now known as Guest51238 (~Sparkie@121-74-147-249.telstraclear.net) |
| 08:57:04 | | Part Guest51238 |
| 09:00 |
| 09:01:11 | | Join ygrek_ [0] (~user@108.59.6.97) |
| 09:03:56 | | Quit ygrek (Ping timeout: 245 seconds) |
| 09:04:37 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 09:26:01 | | Quit us`0gb (Quit: http://0gb.us/) |
| 09:32:27 | | Join pystar89 [0] (~pystar89@ip-176-199-76-43.unitymediagroup.de) |
| 09:34:10 | [Saint] | I've been looking at https://android.googlesource.com/platform/frameworks/av/+/android-4.4.4_r1/media/libstagefright/codecs/mp3dec/src/ |
| 09:34:31 | [Saint] | saratoga_: have you seen this? Is it useful to us? |
| 09:35:17 | [Saint] | whoops: https://android.googlesource.com/platform/frameworks/av/+/android-4.4.4_r1/media/libstagefright/codecs/mp3dec/src/asm/ |
| 09:36:29 | [Saint] | Well...shit. That's somewhat creepy. |
| 09:36:47 | * | [Saint] just found the backlog where saratoga found the exact same thing |
| 09:41:25 | | Join Sparkie_ [0] (~Sparkie@121-74-147-249.telstraclear.net) |
| 09:42:45 | Sparkie_ | I installed rockbox on my 7th gen ipod classic and my battery life is appalling when i have the screen on, 1% every 5 seconds, but it stayed on playing music on shuffle with no display for around 15 hours over night and today. How do i fix the battery life? |
| 09:43:32 | | Quit JdGordon (Remote host closed the connection) |
| 09:45:25 | [Saint] | The battery indicator is based on voltage, so, its likely your battery is just fucked. |
| 09:45:52 | Sparkie_ | should i wipe rockbox and put apple back on and ask for replacement? |
| 09:46:34 | [Saint] | Hahaha. Good luck with that. Its a decade old. |
| 09:46:41 | [Saint] | If not more. |
| 09:48:16 | Sparkie_ | oh no i bought it two days ago |
| 09:48:47 | kugel | the ipod 7th gen is not a decade old |
| 09:49:46 | kugel | and apple still sells it |
| 09:50:07 | kugel | Sparkie_: if it's that new the battery is probably fine |
| 09:50:39 | kugel | perhaps the calibration data is just inaccurate |
| 09:50:54 | [Saint] | I don't see how it could be anything other than the battery. |
| 09:51:05 | [Saint] | Its possible to configure it poorly, but, not *that* poorly. |
| 09:51:11 | kugel | did you try if the "1% every 5 seconds" continues until the battery is completely empty? |
| 09:51:53 | [Saint] | And, yes, the calibration data is bullcrap, but I haven't ever seen the battery on any of my Classics plummet at a rate anywhere close to 1% every 5 seconds. |
| 09:52:03 | Sparkie_ | the battery stays on 84% for a while and then at 0% for about 15 minutes with the screen on |
| 09:52:43 | Sparkie_ | im thinking it could be to do with the calibration because when it charges it goes really fast then really slow |
| 09:52:53 | Sparkie_ | and stays on %'s for a decent amoutn of time |
| 09:52:58 | [Saint] | Even if I configure my Classic as badly as I possibly can, I can't get the batery to drop that fast. |
| 09:53:02 | Sparkie_ | oh and it fluctuates |
| 09:53:10 | [Saint] | I set the LCD to always on, and the HDD spindown time to 10 minutes. |
| 09:53:16 | | Join edhelas [0] (~edhelas@2001:981:e7ba:1:863a:4bff:fe85:8a3c) |
| 09:53:18 | [Saint] | And its still not dropping anywhere near that rate, |
| 09:54:08 | [Saint] | Even other things I can think of that add to it like maxing out all the EQ bands, and enabled accessory power supply don't come close to making the batteyr drop as fast as OP claims his does. |
| 09:54:19 | [Saint] | And my batteries are very well used. |
| 09:54:59 | kugel | Sparkie_: i think you should check if it's bad with the OF too |
| 09:55:22 | [Saint] | Hmmmmm...what theme are you using? |
| 09:55:32 | Sparkie_ | flying spaghetti monster |
| 09:55:40 | [Saint] | Its highly possible the author fucked up the display. |
| 09:56:03 | [Saint] | Improbable, but, certainly possible. |
| 09:57:07 | Sparkie_ | ok i will restore back to apple firmware through i tunes |
| 09:57:40 | kugel | Sparkie_: i don't think the battery is bad at this point, but better be sure by checking with the OF |
| 09:58:19 | Sparkie_ | ok yes thank you very much |
| 09:58:26 | [Saint] | Hmmm, nope, the theme is displaying battery in a sane way. |
| 09:59:08 | [Saint] | Odd indeed. |
| 09:59:43 | Sparkie_ | hold on guys, my ipod seems to be charging fine now |
| 09:59:51 | Sparkie_ | at a proper rate i mean |
| 09:59:56 | Sparkie_ | maybe it calibrated by itself |
| 10:00 |
| 10:00:01 | [Saint] | Nope. |
| 10:00:06 | [Saint] | Doesn;t work that way. |
| 10:00:18 | Sparkie_ | yer yer i know bu ti have no idea what is happening |
| 10:00:37 | kugel | Sparkie_: I also think you need a few more charge cycles to reliably tell that the battery runs empty fast. could be that it wasn't fully charged |
| 10:01:23 | Sparkie_ | yer sure thank you and i will do |
| 10:01:55 | Sparkie_ | my battery is charging at a seems to be normal rate now instead of some stupid % per 2 seconds |
| 10:02:37 | [Saint] | Wait. |
| 10:02:43 | [Saint] | Do you mean *discharging*? |
| 10:02:49 | Sparkie_ | no no chargin now |
| 10:03:04 | [Saint] | Ok. Well, that's new information. |
| 10:03:52 | [Saint] | Are we positive about the "loses 1% every 5s" statement? |
| 10:04:02 | Sparkie_ | it was before |
| 10:04:12 | [Saint] | Simple math seems to suggest that you'd be getting 8 minutes of battery at that rate. |
| 10:04:19 | [Saint] | I'm willing to believe that wasn't the case. |
| 10:04:54 | Sparkie_ | when the screen was on. when it wasn't 80% to 30% shuffling music through earphones for about 15 hours straight |
| 10:05:25 | Sparkie_ | saint, it was doing that for a while and then slowing down every now and again and stayed on 0% for about 15 minutes |
| 10:06:45 | [Saint] | How long is "for a while"? Even if it did it for a period of 30s, that's 6% battery lost. |
| 10:06:58 | [Saint] | Is it possible at all that the perception of time was warped? |
| 10:07:46 | Sparkie_ | Oh my god dude. I am saying that before, the battery was decreasing fast. But sometimes it would decrease slower |
| 10:08:41 | | Quit ygrek_ (Ping timeout: 255 seconds) |
| 10:09:31 | Sparkie_ | It charged super fast aswell. |
| 10:10:44 | [Saint] | The impression you gave, was that whenever the screen was on the battery would reliably discharge at a rate of ~1% ever ~5s, I'm just trying to ascertain how close to reality that is. Because as noted, at that rate, you've only got 8 minutes of battery with the screen on. |
| 10:11:26 | Sparkie_ | yes ok . It was doing that for times, but not all the time |
| 10:11:37 | Sparkie_ | that's why i said it fluctuates |
| 10:11:42 | Sparkie_ | it's puzzling me too |
| 10:13:41 | [Saint] | It definitely puzzles me. I attempted to configure my iPod in the worst possible way and I can't get anywhere near that kind of discharge rate. |
| 10:13:47 | [Saint] | Something odd is going on. |
| 10:14:11 | Sparkie_ | i orignally thought it was a battery that could hold very little charge but i think it must be something else. |
| 10:14:24 | Sparkie_ | also do you happen to know how many miiliamphours 7th gen ipods hold |
| 10:14:56 | [Saint] | 600, IIRC. |
| 10:15:12 | Sparkie_ | ok i think it said 500 on battery stats |
| 10:15:15 | Sparkie_ | on rockbox |
| 10:15:38 | [Saint] | That setting isn't related to any battery level displayed to the user at any time. |
| 10:15:48 | [Saint] | That setting is only related to the estimated runtime. |
| 10:15:54 | [Saint] | Which is hilariously inaccurate anyway. |
| 10:16:32 | [Saint] | So, errr, what I'm saying is, changing it will have absolutely no effect. |
| 10:16:39 | Sparkie_ | ok yep |
| 10:17:04 | Sparkie_ | my ipod charging seems allright now. It might have just taken some cahrge/discharge cycles as kugel said |
| 10:19:01 | TheSeven | another thing on my todo list... |
| 10:19:13 | Sparkie_ | yes? |
| 10:19:24 | TheSeven | finally figure out where apple is hiding that current sensor so that we can get more accurate battery readings |
| 10:20:09 | | Join JdGordon [0] (~JdGordon@pa49-183-201-219.pa.vic.optusnet.com.au) |
| 10:20:18 | Sparkie_ | Oh cool. theseven are you part of dev team? |
| 10:20:26 | TheSeven | yes |
| 10:20:36 | TheSeven | I'm the ipod nano 2g & ipod classic port maintainer |
| 10:20:50 | Sparkie_ | oh my that's really cool |
| 10:21:02 | Sparkie_ | ty for the rockbox :0 |
| 10:22:09 | TheSeven | Sparkie_: I'd *guess* that the battery runtime will be fine, just the meter is probably a bit off |
| 10:22:43 | TheSeven | so if it works for several hours while pretending that the battery would be empty, I just wouldn't worry about that at this time |
| 10:23:05 | TheSeven | if it's very new, it might also be that the battery just hasn't been run in properly yet |
| 10:23:30 | TheSeven | especially if it has (somewhat likely) been sitting in a warehouse for years before being sold |
| 10:23:50 | Sparkie_ | yer I guess. I'll keep rockbox on for like another week or so then change back to apple and if still hasnt fixed i will take back in 30 day warranty babyyyy |
| 10:23:57 | Sparkie_ | yer that's true |
| 10:24:44 | TheSeven | another thing is that the battery won't even try to charge before it's (actually, even if the meter says otherwise) below 80% or so |
| 10:25:11 | TheSeven | however plugging it in (and thus removing the load on the battery) will make the meter fluctuate quite a bit even in that area |
| 10:25:42 | Sparkie_ | Ok, it just went from 100% to 95% in abuit 10 seconds |
| 10:25:48 | Sparkie_ | 93 |
| 10:25:50 | Sparkie_ | 92 |
| 10:25:55 | Sparkie_ | 91 |
| 10:26:06 | TheSeven | what does the voltage reading in the battery debug screen say? |
| 10:26:13 | TheSeven | (system => debug => battery) |
| 10:27:04 | TheSeven | the percent gauge is nowhere near accurate, it has >10% tolerance in a lot of situations, especially shortly after changing the power source |
| 10:27:18 | TheSeven | it will vastly overestimate the battery state while charging, and slightly underestimate it while discharging |
| 10:27:25 | Sparkie_ | view battery? |
| 10:27:29 | TheSeven | yes |
| 10:27:40 | Sparkie_ | 4.030V |
| 10:27:46 | TheSeven | so if you're just playing with the 80-100% range, this kind of behavior is just normal at this point |
| 10:28:09 | Sparkie_ | it's 3.977V atm |
| 10:28:27 | TheSeven | ok, it should actually start charging at that point if you plug it in |
| 10:28:59 | TheSeven | however the meter will likely just jump straight to 100% if you do so, even though fully charging it from that point would take an hour or so |
| 10:29:24 | Sparkie_ | ok it is jumping all over tha place on the view battery |
| 10:29:27 | TheSeven | this is something that's somewhat likely to get fixed during the next weeks, as I'm currently trying to clean out the last few remaining quirks of the ipod classic port |
| 10:29:36 | Sparkie_ | oh cool |
| 10:30:06 | TheSeven | Sparkie_: I'd expect it to jump to about 4.15-4.20V if you plug it in, and back to about 4.00V if you unplug it |
| 10:30:15 | Sparkie_ | where will that be available from? |
| 10:30:38 | Sparkie_ | yer you are right |
| 10:30:45 | Sparkie_ | i meant the voltage is jumping |
| 10:30:52 | TheSeven | ok, you're just seeing the normal battery meter confusion then ;) |
| 10:31:21 | Sparkie_ | pwr status is discharging when it is plugged in? |
| 10:31:22 | TheSeven | you can't properly tell the exact state of charge from just the voltage, but without access to the current sensor it can't do much better |
| 10:31:57 | TheSeven | yes, that's also just not implemented yet. it will always say discharging. |
| 10:32:08 | TheSeven | another thing that I already have a fix for, that just didn't go into the official builds yet |
| 10:32:15 | Sparkie_ | oh ok. so are you saying my problem is pretty normal but will most likley be fixed next patch? |
| 10:32:23 | TheSeven | yes |
| 10:32:31 | Sparkie_ | oh coool dude thanks for that |
| 10:33:13 | TheSeven | I'd expect this kind of things to be fixed in the development builds in about 1-2 months |
| 10:33:30 | Sparkie_ | how long should i keep it charging after 100%? |
| 10:33:39 | TheSeven | and once we've reached that point there will very likely also be a new emCORE release which embeds these newer builds |
| 10:34:06 | TheSeven | Sparkie_: about an hour should be sufficient to get it close to actual 100%, however it's safe to just keep it plugged in overnight ;) |
| 10:34:32 | Sparkie_ | ok yer i might do that |
| 10:35:32 | TheSeven | also note that if the voltage was above ~4.00-4.05V while plugging in, it won't start charging (you'll see that the voltage goes back up to about 4.1V, but not close to 4.2V) |
| 10:37:40 | Sparkie_ | ok so, one last time, the reason my batteyr was discharging fast and then slow may have been because it wasn't fully charged and therefore not at the given percentage? |
| 10:38:12 | *** | Saving seen data "./dancer.seen" |
| 10:41:15 | Sparkie_ | is that right? |
| 10:41:21 | | Join pretty_function [0] (~sigBART@123.252.214.60) |
| 10:47:26 | Sparkie_ | theseven? |
| 11:00 |
| 11:01:24 | | Join ygrek_ [0] (~user@108.59.6.97) |
| 11:04:07 | TheSeven | Sparkie_: techincally not 100% correct, but the behavior is similar, yes |
| 11:04:40 | Sparkie_ | ok cool. so what do you think i should do from here? |
| 11:04:46 | TheSeven | actually the battery meter is slightly underestimating the state of charge while discharging, and massively overestimating it while charging (but only if it actually charges) |
| 11:05:08 | Sparkie_ | ok and the bettery meter is trying to coirrect itself hence the fast discharge? |
| 11:05:18 | TheSeven | the meter will "jump" (not instantly, but during a few minutes) between those different estimates |
| 11:05:57 | TheSeven | once we have current sensor readings, the meter can actually calculate how big these over/underestimations are and correct them |
| 11:06:42 | * | kugel wonders why other targets can get largely-reliable battery readouts without current sensor |
| 11:07:28 | TheSeven | because they aren't dealing with 300+ mA discharge current spikes I guess ;) |
| 11:07:42 | TheSeven | or just because nobody cared about the meter accuracy |
| 11:08:25 | TheSeven | but even on nano2g adding the current sensor to compensate for the battery's internal resistance vastly improved the readings |
| 11:08:52 | TheSeven | especially during charging, as you just can't tell the battery state from just the voltage if it's charging in the CV phase |
| 11:09:45 | TheSeven | this one is probably just as "largely reliable" as the others ;) |
| 11:10:53 | * | TheSeven spotted some code in disk mode yesterday that measures the USB D+/D- lines and thus must be dealing with the mux in front of the ADC that is also responsible for battery current measurements |
| 11:13:02 | TheSeven | (this would also enable us to properly detect USB charging spec compliant chargers btw) |
| 11:21:36 | Sparkie_ | where will i find the rockbox update if it come sout next month? |
| 11:22:31 | copper | where do you usually "find" it? |
| 11:22:38 | TheSeven | http://build.rockbox.org/ will always point to the newest development builds |
| 11:22:56 | TheSeven | and if we consider the latest changes somewhat complete and stable, we'll release them on freemyipod.org |
| 11:25:31 | Sparkie_ | where would be the ipod classic 7th gen one be though |
| 11:26:12 | TheSeven | hm, looks like the link is missing indeed |
| 11:26:29 | TheSeven | http://build.rockbox.org/data/rockbox-ipod6g.zip |
| 11:26:46 | Sparkie_ | oh ok ty |
| 11:26:54 | Sparkie_ | and this is the latest one with the battery issue/ |
| 11:26:56 | Sparkie_ | ? |
| 11:27:12 | copper | there's a battery issue? |
| 11:28:08 | TheSeven | this is the most recent development build, which doesn't have any battery meter and charging state detection improvements yet |
| 11:28:23 | TheSeven | I guess these will go in there within the next month though |
| 11:28:49 | Sparkie_ | ok yer i had this on before but i changed to the one from rockbox utility after the battery issue |
| 11:29:54 | TheSeven | the rockbox utility will do nothing else, it will just download that file ;) |
| 11:30:29 | Sparkie_ | hmm ok. looking at the graph on view battery on my ipod, the gradient at which the battery is decreasing is really steep |
| 11:31:33 | Sparkie_ | even after charging for over anhour after 100% is this normal? |
| 11:33:16 | Sparkie_ | oh wait that's voltage my bad |
| 11:35:55 | Sparkie_ | anywaays im of ty for the help. I'll look forward to seeing new rockbox. goodbye |
| 11:41:23 | | Quit Sparkie_ (Ping timeout: 255 seconds) |
| 12:00 |
| 12:10:37 | | Quit JdGordon (Ping timeout: 272 seconds) |
| 12:15:30 | | Quit mc2739 (Read error: Connection reset by peer) |
| 12:16:04 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 12:16:38 | | Join user890104 [0] (Venci@unaffiliated/user890104) |
| 12:31:42 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 12:38:15 | *** | Saving seen data "./dancer.seen" |
| 12:44:11 | | Quit pretty_function (Remote host closed the connection) |
| 13:00 |
| 13:04:23 | | Join JdGordon [0] (~JdGordon@pa49-183-201-219.pa.vic.optusnet.com.au) |
| 13:04:27 | | Quit JdGordon (Remote host closed the connection) |
| 13:15:27 | | Join wodz [0] (~wodz@89-75-149-112.dynamic.chello.pl) |
| 13:17:07 | wodz | what is the difference between target_id in configure and MODEL_NUMBER define in target specific config file? |
| 13:20:47 | | Quit bcobco () |
| 13:29:35 | wodz | hmm, we have duplicates in MODEL_NUMBER - hm60x, clip zip 79; xfi2, hm801 82; xfi3, ma9 83; ma9c, yp-z5 84; zenv, ihifi760 92; android, nokian8xx, nokian900, pandora, yp-r0, sdlapp 100 |
| 13:29:43 | wodz | I guess this is not good |
| 13:29:50 | mortalis | wodz: IIRC MODEL_NUMBER used in bootloader to check compatibility of bootloader and main binary, and target_id is the same thing but for voicefiles |
| 13:31:54 | wodz | so we shouldn't have duplicates in MODEL_NUMBER |
| 13:32:06 | wodz | it doesn't make much sense for app builds also |
| 13:34:21 | | Join bcobco [0] (~bcobco@77.225.204.119) |
| 13:35:29 | wodz | target_id is exported as TARGET_ID |
| 13:39:10 | mortalis | changing MODEL_NUMBER might be a prblem for some targets, as it will require to release new bootloaders |
| 13:39:36 | wodz | yes |
| 13:42:53 | wodz | I wonder why there are two distinct numbers while vast majority of targets have this unique |
| 13:46:41 | | Join ZincAlloy [0] (~Adium@pD9EEAFDC.dip0.t-ipconnect.de) |
| 14:00 |
| 14:07:41 | | Quit bcobco (Remote host closed the connection) |
| 14:08:06 | | Join bcobco [0] (~bcobco@77.225.204.119) |
| 14:10:54 | pamaury | wodz: modelnum is for the bootloader and target_id for apps |
| 14:11:16 | wodz | what you mean apps? |
| 14:11:42 | pamaury | codecs, plugins, voicefiles |
| 14:11:52 | pamaury | I think each codec and plugin has the target id in the header |
| 14:12:19 | wodz | ok, but why it needs to be different then MODEL_NUMBER? |
| 14:12:36 | wodz | why two separate numbers |
| 14:13:17 | | Join Rower [0] (~husvagn@h176n2-aeg-a11.ias.bredband.telia.com) |
| 14:13:25 | pamaury | no good reason I think |
| 14:14:22 | wodz | pamaury: btw. I looked at cp3 OF and there is gpio toggling in codec related functions. I tried this but without luck. I need to study more gpio setup :/ |
| 14:15:02 | pamaury | ok, so there might be power/hp gates controlled by gpio ? |
| 14:15:28 | wodz | could be |
| 14:16:14 | pamaury | also the model_num is in two places: configure and target config file |
| 14:16:32 | pamaury | because some targets don't use it except for rolo |
| 14:17:28 | pamaury | also the scramble tool doesn't always make use of the model_num values, like for RKW I think |
| 14:19:34 | | Quit Rower (Ping timeout: 240 seconds) |
| 14:20:26 | | Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) |
| 14:25:08 | kugel | pamaury: i pushed the 24bit driver |
| 14:25:39 | wodz | pamaury: in configure there is target_id in target config file there is MODEL_NUMBER |
| 14:30:33 | | Quit ygrek_ (Ping timeout: 240 seconds) |
| 14:32:17 | | Quit copper (Ping timeout: 240 seconds) |
| 14:32:35 | wodz | TheSeven: http://pastie.org/9316335 (HEAD + g#843 + g#844) with rockbox official compiler |
| 14:32:38 | fs-bluebot | Gerrit review #843 at http://gerrit.rockbox.org/r/843 : Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann |
| 14:32:38 | fs-bluebot | Gerrit review #844 at http://gerrit.rockbox.org/r/844 : usb-designware: New USB driver for Synopsys DesignWare USB OTG core. by Michael Sparmann |
| 14:33:08 | wodz | + bunch of 'function declaration isn’t a prototype' which I fixed locally |
| 14:37:37 | | Join Sparkie_ [0] (~Sparkie@121-74-147-249.telstraclear.net) |
| 14:38:19 | *** | Saving seen data "./dancer.seen" |
| 14:42:17 | | Quit Sparkie_ (Ping timeout: 255 seconds) |
| 14:49:26 | pamaury | wodz: but the modelnum is duplicated in configure when given to scramble as an argument |
| 14:49:45 | pamaury | kugel: yeah I saw, I modified the zen to use it, it works fine |
| 14:49:54 | pamaury | I'll push it soon |
| 14:50:17 | wodz | pamaury: I don't understand |
| 14:50:54 | pamaury | in configure, there are lines like "$rootdir/tools/scramble -rkw -modelnum=92" |
| 14:51:31 | pamaury | and also in tools/scramble.c, the modelnum are written for each target, that's many places to keep in sync, pretty bad |
| 14:53:12 | wodz | :/ |
| 14:54:25 | | Quit cmhobbs (Ping timeout: 264 seconds) |
| 14:54:57 | pamaury | the simplest approach would be to change the target_id, I *think* it won't cause any problem |
| 14:56:42 | | Join copper [0] (~copper@unaffiliated/copper) |
| 14:57:49 | | Quit bcobco (Remote host closed the connection) |
| 14:58:13 | | Join bcobco [0] (~bcobco@77.225.204.119) |
| 14:58:57 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 15:00 |
| 15:44:41 | | Quit petur (Quit: *plop*) |
| 16:00 |
| 16:01:56 | | Quit krabador (Quit: Sto andando via) |
| 16:07:13 | | Join ygrek_ [0] (~user@108.59.6.97) |
| 16:24:56 | | Quit kugel (Quit: Lost terminal) |
| 16:38:23 | *** | Saving seen data "./dancer.seen" |
| 16:44:56 | | Join kugel [0] (~kugel@46.114.24.96) |
| 16:44:57 | | Quit kugel (Changing host) |
| 16:44:57 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 16:48:50 | | Quit bcobco () |
| 16:53:16 | | Join bcobco [0] (~bcobco@77.225.204.119) |
| 17:00 |
| 17:00:00 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:03:39 | | Quit edhelas (Ping timeout: 260 seconds) |
| 17:04:36 | | Quit kugel (Read error: Connection reset by peer) |
| 17:10:00 | | Quit bcobco () |
| 17:12:34 | | Quit mortalis (Ping timeout: 240 seconds) |
| 17:13:46 | | Join kugel2 [0] (~kugel@46.115.1.147) |
| 17:17:32 | | Quit GodEater (Ping timeout: 255 seconds) |
| 17:18:34 | | Join GodEater [0] (~whoknows@90.194.223.13) |
| 17:18:34 | | Quit GodEater (Changing host) |
| 17:18:34 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 17:19:28 | | Join bcobco [0] (~bcobco@77.225.204.119) |
| 17:23:50 | TheSeven | wodz: hm, weird errors... |
| 17:24:43 | wodz | TheSeven: I made it compile but didn't have time to test |
| 17:38:35 | | Quit mc2739 (Ping timeout: 240 seconds) |
| 17:39:47 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 17:51:09 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 17:51:46 | | Quit petur (Quit: *plop*) |
| 17:58:43 | | Join edhelas [0] (~edhelas@77-173-104-232.ip.telfort.nl) |
| 18:00 |
| 18:04:48 | TheSeven | copper: which way does that adapter get inserted into the ipod? |
| 18:04:48 | TheSeven | with the CF card towards the front or the back? |
| 18:05:18 | copper | haha |
| 18:06:04 | copper | erm |
| 18:06:12 | copper | I'm trying to figure out a way to explain it |
| 18:06:27 | copper | but basically the ZIF interface should give you a clue |
| 18:06:35 | copper | it's not perfectly in the middle |
| 18:06:58 | copper | http://outpost.fr/tmp/qrM.jpg/ |
| 18:07:09 | copper | that side should go against the back |
| 18:07:17 | copper | the back case* |
| 18:07:43 | copper | you won't be able to plug in the ZIF ribbon if you install the adapter the wrong way |
| 18:09:01 | copper | in other words, the adapter should be facing you like in the picture, with the front side of the ipod (with the display) against the table |
| 18:09:19 | copper | dunno if that's clear enough :P |
| 18:10:02 | copper | the top left end of the adapter will make it fit snuggly in the front case |
| 18:10:38 | copper | it's designed to fit the case so it doesn't move around |
| 18:11:06 | copper | you're supposed to remove the two blue bottom "bumpers" |
| 18:11:09 | TheSeven | ok, so unlike the HDD, the adapter gets plugged with the contacts of the ZIF ribbon cable facing towards the top of the connector? |
| 18:11:49 | copper | not sure what you mean, but yes, it's installed differently from the HDD |
| 18:12:04 | copper | you'll know it when it fits |
| 18:12:44 | copper | I took pictures but I was stupid and deleted them |
| 18:13:11 | TheSeven | ok, that little piece of metal that holds it in its position makes it more clear |
| 18:14:38 | copper | I don't suppose you're going to close the ipod anyway? |
| 18:15:10 | TheSeven | yeah, just didn't want to insert it the wrong way round, as the ZIF connector might have pins on both sides |
| 18:15:25 | TheSeven | and it's kinda convenient that the battery is accessible on the top side |
| 18:15:29 | copper | like I said, it's conveniently off-center |
| 18:16:13 | copper | 16:15:26 UTC <TheSeven> and it's kinda convenient that the battery is accessible on the top side |
| 18:16:16 | copper | what do you mean? |
| 18:16:28 | TheSeven | er, damn |
| 18:16:32 | TheSeven | what did I type |
| 18:16:35 | copper | the battery should be glued to the back case, not the front case |
| 18:16:36 | TheSeven | I meant the CF card |
| 18:16:44 | copper | ah |
| 18:16:47 | TheSeven | was just plugging the battery while typing that :P |
| 18:16:59 | TheSeven | hm, surprise |
| 18:17:02 | copper | yes, so you can insert an SD card without removing the adapter |
| 18:17:12 | TheSeven | I just tried to plug a microdrive into it just out of curiosity, and it doesn't work (ata error 5) |
| 18:17:44 | copper | it wouldn't be any fun if it worked! |
| 18:18:17 | TheSeven | hm, interesting |
| 18:18:27 | TheSeven | with just the adapter without a card, I don't even get an error |
| 18:18:28 | [Saint] | Seems a bit of a unnt gesture to get east access to the card without renovi the adapter considering how you have to get to the adapter in the first place. |
| 18:18:30 | TheSeven | it pretends to work |
| 18:19:09 | copper | too many typos! |
| 18:19:10 | [Saint] | s/unnt/cute/ no idea what autocomplete did there. |
| 18:19:21 | [Saint] | *easy |
| 18:19:44 | [Saint] | *removing |
| 18:19:55 | * | TheSeven needs to remove that empty battery detection code again |
| 18:20:36 | TheSeven | too inconvenient to actually connect the battery! :P |
| 18:22:13 | copper | I can't remember, did you determine if it was the ZIF adapter, or the CF adapter, that used up too much current? |
| 18:22:28 | TheSeven | the ZIF adapter is completely passive |
| 18:22:32 | TheSeven | that's just a connector adapter |
| 18:22:43 | copper | hmmm |
| 18:22:52 | copper | have you tried a CF card? |
| 18:22:56 | copper | without the CF adapter |
| 18:23:12 | TheSeven | that's one of the things that I'll experiment with |
| 18:23:22 | copper | for a while I couldn't decide if I should buy a CF card instead of an SD card |
| 18:23:44 | copper | but the CF cards are a lot more expensive, even when used |
| 18:23:47 | copper | (second hand) |
| 18:25:00 | copper | and I figured that I didn't need the extra performance, since I would only access it over USB anyway |
| 18:26:26 | [Saint] | If you're not doing bulk transfers often, the extra performance is rather wasted. |
| 18:26:52 | [Saint] | Roxkbox would certainly never make use of it at all during playback. |
| 18:27:32 | [Saint] | Its rather surprising how slow "fast enough for lossless realtime" actually is. |
| 18:33:51 | copper | indeed |
| 18:38:26 | *** | Saving seen data "./dancer.seen" |
| 18:50:32 | TheSeven | nothing connected: ata error 4, microdrive connected: ata error c, tarkan adapter without card: no error |
| 18:51:24 | TheSeven | tarkan adapter with weird card: no error |
| 18:52:02 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:52:03 | | Quit bertrik (Changing host) |
| 18:52:03 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:53:10 | [Saint] | "weird card"? |
| 18:54:13 | TheSeven | some old minisd thing that works in basically no device |
| 18:54:32 | TheSeven | reading sector 0 on that succeeds, but returns what looks like an ATA identify response |
| 18:54:39 | TheSeven | "Rev 1.4 FC-1307 SD to CF Adapter V1.4" |
| 18:54:57 | copper | ugh |
| 18:55:06 | copper | I never suspected so much could go wrong with that thing |
| 18:55:16 | copper | I thought, it's just an adapter |
| 18:56:37 | TheSeven | storage init error 0 with tarkan adapter + some old noname 256MB card. that worked in the card reader, we have something here! |
| 18:58:42 | TheSeven | 256MB CF card: no init error, raw access seems to work, but filesystem accesses don't. maybe just too small? |
| 18:59:30 | TheSeven | yeah, probably too small for valid FAT32 with 4K sectors |
| 19:00 |
| 19:05:02 | copper | that's downright ancient! |
| 19:14:34 | [Saint] | I have a 6MB SD card somewhere |
| 19:14:58 | [Saint] | (Yep...6MB) |
| 19:16:05 | * | TheSeven has a 16MB card somewhere :P |
| 19:22:06 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 19:23:17 | | Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) |
| 19:25:46 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 19:26:58 | | Quit APLU (Ping timeout: 272 seconds) |
| 19:31:24 | | Quit pamaury (Ping timeout: 272 seconds) |
| 19:31:32 | TheSeven | tarkan adapter + 256MB noname card: works after sorting out some FS issues |
| 19:32:20 | TheSeven | note: it seems like the emcore installer messes things up if there's already a FAT filesystem on the card and it's not an initial installation |
| 19:32:49 | TheSeven | you need to manually tell it to reformat the data partition in that case, or it will fail to mount |
| 19:34:39 | | Join model [0] (~model@cscluster.minotstateu.edu) |
| 19:37:35 | | Quit bertrik (Ping timeout: 240 seconds) |
| 19:38:03 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 19:40:21 | | Join RiD [0] (RiD@bl22-9-15.dsl.telepac.pt) |
| 19:42:48 | | Quit Rower (Ping timeout: 272 seconds) |
| 19:43:56 | | Quit jhMikeS (Ping timeout: 245 seconds) |
| 20:00 |
| 20:21:39 | | Quit y4n (Disconnected by services) |
| 20:21:43 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 20:26:21 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 20:32:05 | | Quit ygrek_ (Ping timeout: 240 seconds) |
| 20:38:20 | * | TheSeven spots some rather idiotic bugs that might have wasted several days of his time |
| 20:38:29 | *** | Saving seen data "./dancer.seen" |
| 20:40:59 | TheSeven | ok, microdrive compatibility fixed |
| 20:41:54 | TheSeven | copper: how did you manage to get hold of tarkan? |
| 20:43:57 | wodz | TheSeven: http://pastie.org/9317501 <- this is my 'fix' for official rb gcc version. The problem is the driver doesn't work on my n2g (with and without g#842) |
| 20:43:59 | fs-bluebot | Gerrit review #842 at http://gerrit.rockbox.org/r/842 : Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann |
| 20:44:38 | TheSeven | wodz: but with the cache coherency patch? |
| 20:44:40 | TheSeven | how does it fail? |
| 20:44:52 | wodz | TheSeven: yes with coherency fix |
| 20:46:35 | wodz | TheSeven: http://pastie.org/9317513 (with HID turned off and g#842 applied) |
| 20:46:37 | fs-bluebot | Gerrit review #842 at http://gerrit.rockbox.org/r/842 : Revert "Change control handling to start expecting host packets before sending data... by Michael Sparmann |
| 20:47:42 | TheSeven | ok, so it survives enumeration... |
| 20:48:04 | copper | TheSeven: tarkan@tarkan.info |
| 20:48:20 | wodz | TheSeven: not always it seems |
| 20:48:37 | TheSeven | the behavior suggests that there are STALLs |
| 20:49:12 | TheSeven | which could be a sign of cache trouble |
| 20:49:28 | wodz | TheSeven: the other time I got http://pastie.org/9317524 |
| 20:50:02 | TheSeven | yep, that's EP0 stalls |
| 20:50:13 | TheSeven | typical behavior that I was observing *without* the cache coherency fix |
| 20:50:45 | wodz | TheSeven: could you give me build with your gcc so I could test if this my n2g or gcc + fix + whatever |
| 20:51:15 | wodz | TheSeven: 'Fix cache coherency on ARM940T (and other ARMv4T cores).' is definitely applied |
| 20:51:25 | TheSeven | sure |
| 20:51:37 | TheSeven | theseven.homenet.org/~theseven/tmp/rockbox-ipodnano2g-usbfixtest.zip">http://theseven.homenet.org/~theseven/tmp/rockbox-ipodnano2g-usbfixtest.zip |
| 20:59:47 | | Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) |
| 20:59:57 | wodz | TheSeven: your build enumerates correctly but drive doesn't pop up |
| 21:00 |
| 21:00:01 | wodz | no error in dmesg |
| 21:00:17 | wodz | ah, and device hard freezes |
| 21:00:39 | wodz | and then there are errors |
| 21:01:16 | wodz | TheSeven: http://pastie.org/9317573 |
| 21:01:45 | [Saint] | Yep. Same here. |
| 21:02:04 | [Saint] | Enumerates, never mounts, hard freeze. |
| 21:02:32 | wodz | TheSeven: the same on w7 and linux |
| 21:02:59 | [Saint] | (I used the supplied build too...cos, honestly, fuck sorting out getting the patch set to compile with the Rb toolset. |
| 21:03:43 | [Saint] | But the backlog suggests wodz got a lot further than I did in battling compile errors. |
| 21:03:51 | [Saint] | And, to no avail it seems. |
| 21:05:06 | TheSeven | hm, I'll have to have another look after my replacement LCD arrives |
| 21:07:39 | [Saint] | Wheeee! |
| 21:07:39 | wodz | TheSeven: sorry to disappoint you :/ |
| 21:07:52 | [Saint] | It mounted! |
| 21:07:59 | TheSeven | wodz: better catch that sooner than later |
| 21:08:10 | [Saint] | Buuuuuut, this time the host froze. :) |
| 21:09:37 | wodz | TheSeven: can usb_dw_get_max_transfer_size() be called agains ep0 ? If so this is plain wrong. |
| 21:09:59 | TheSeven | no, that function is completely counter-intuitive |
| 21:10:16 | TheSeven | it returns the number of packets that can be sent at once on a bulk endpoint |
| 21:10:21 | TheSeven | not the number of bytes |
| 21:10:25 | wodz | oh |
| 21:11:03 | TheSeven | well, not quite sure what it's supposed to do in rockbox, but that's what it's doing, and it seems to work on the classic ;) |
| 21:12:34 | wodz | TheSeven: anyway http://pastie.org/9317612 makes it compile cleanly with rb gcc and I think should be correct |
| 21:12:57 | TheSeven | yeah, as kugel said we should get rid of those bitfields regardless |
| 21:13:01 | TheSeven | or at least the hw-related ones |
| 21:13:23 | TheSeven | thanks for pinpointing the cause of that error though :) |
| 21:14:27 | wodz | TheSeven: yeah, I am all for this but this is a lot of work to debitfildize the driver |
| 21:18:21 | TheSeven | copper: seems like I can reproduce your behavior with a 32GB sandisk extreme SDHC card |
| 21:18:41 | TheSeven | that's the only card that I have that exhibits this problem though |
| 21:19:30 | gevaerts | Is it the only one that claims to be extreme? |
| 21:19:40 | gevaerts | You can only expect such cards to be outliers :) |
| 21:22:22 | wodz | gevaerts: Could you comment maybe my question why there are two different numbers describing target in our build system? (I mean MODEL_NUMBER in target's config .h file and target_id in configure) |
| 21:22:38 | gevaerts | wodz: I have no idea |
| 21:22:44 | copper | TheSeven: do you mean that, you have other sandisk cards that work? |
| 21:23:10 | copper | or rather: what cards did you test, that do work? |
| 21:23:11 | TheSeven | no, it's the only sandisk card that I have |
| 21:23:16 | TheSeven | from what I can tell the CF adapter's firmware is locking up somehow |
| 21:23:30 | TheSeven | it doesn't recover until a power cycle even if I swap the card |
| 21:23:30 | wodz | gevaerts: Who may I ask about this? |
| 21:23:41 | gevaerts | wodz: someone who was around before me :) |
| 21:23:47 | gevaerts | Zagor, maybe? |
| 21:23:50 | TheSeven | not sure if it's supposed to handle swapping cards during operation though |
| 21:23:58 | gevaerts | Possibly amiconn? |
| 21:25:09 | wodz | amiconn is rather inactive and hard to catch |
| 21:31:15 | * | TheSeven wonders how it can be possible that we lock up that adapter with only some SD cards, but it still works fine with the very same card in a card reader |
| 21:32:38 | copper | what works fine |
| 21:32:42 | copper | the CF adapter? |
| 21:32:45 | TheSeven | yes |
| 21:32:55 | TheSeven | if I put it into a CF card reader, it works just fine with the sandisk card |
| 21:33:00 | TheSeven | like it did for you with the original firmware |
| 21:33:09 | TheSeven | but emcore somehow locks it up |
| 21:33:19 | TheSeven | but only with the sandisk card. hm... |
| 21:33:19 | copper | there's still the tarkan adapter between the two |
| 21:33:33 | TheSeven | that adapter isn't more than a few pieces of wire |
| 21:33:34 | copper | you didn't answer my question: what cards work for you? |
| 21:33:47 | TheSeven | some old 256MB noname crap |
| 21:34:18 | TheSeven | the 2GB minisd card doesn't work in a card reader either and behaves differently (as if no card was plugged in at all) in emcore |
| 21:34:39 | wodz | wait isn't tarkan cf<->sd thing? If so there must be mcu inside (or cpld/fpga) |
| 21:35:02 | copper | it's zif → cf → sd |
| 21:35:04 | TheSeven | wodz: it's a passive ZIF => CF adapter + active CF => SD adapter |
| 21:35:19 | TheSeven | and the CF => SD card works in a card reader with the very same card that fails in the classic |
| 21:35:33 | wodz | oh, thats weird |
| 21:36:21 | copper | that fails with emcore* |
| 21:36:32 | | Quit bcobco () |
| 21:37:12 | TheSeven | it must be some compatibility thing that involves *both* sides of the adapter |
| 21:37:14 | copper | also note that the first thing I did, was to format the entire sd card as FAT32, labeled "iPodClassic", then I put the card into the adpater |
| 21:37:51 | TheSeven | copper: the working lexar card had roughly the same capacity as the failing sandisk one, both way above 32GB, right? |
| 21:38:08 | TheSeven | disabling DMA doesn't help at all |
| 21:38:16 | copper | http://outpost.fr/tmp/DCi.jpg/ |
| 21:38:20 | copper | those are the cards I tried |
| 21:38:24 | copper | top row: fails |
| 21:38:27 | copper | bottom row: works |
| 21:38:43 | TheSeven | the top center one is the one that I'm experimenting with right now |
| 21:38:51 | copper | the final 128 GB Lexar card (which worked) isn't on the picture |
| 21:39:57 | TheSeven | so we can rule out any capacity / sdhc / sdxc based thing as well |
| 21:43:29 | wodz | TheSeven: Do you have any documentation/reveng which sdio signals map to which ata lines? |
| 21:43:52 | copper | http://www.tarkan.info/20121226/tutorials/ipod-and-sdhc-sdxc-cards |
| 21:44:00 | TheSeven | wodz: no, I'd have to probe that |
| 21:44:29 | TheSeven | hm or actually I can't probe it, because I don't have a CE-ATA ipod |
| 21:45:04 | TheSeven | [Saint]: do you have the required tools to figure out where the pins inside the CE-ATA ZIF cable end up? |
| 21:52:56 | | Quit RiD (Ping timeout: 255 seconds) |
| 21:55:05 | | Quit y4n (Quit: PÆNTS ØLF!) |
| 21:56:08 | | Join RiD [0] (~RiD@2.83.169.151) |
| 21:57:16 | | Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) |
| 21:57:39 | | Quit Misanthropos (Read error: Connection timed out) |
| 21:58:03 | | Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) |
| 22:00 |
| 22:02:06 | TheSeven | interesting... I can trigger the very same behavior by unplugging and replugging an otherwise working card on the fly |
| 22:02:51 | TheSeven | another side note: the adapter doesn't seem to support LBA48 |
| 22:03:41 | TheSeven | so 128GB is the maximum card size that it can possibly support |
| 22:04:27 | | Quit ender` (Quit: #define sizeof(x) ((rand() % 100 == 42) ? sizeof(x)-1 : sizeof(x))) |
| 22:10:39 | | Join wo [0] (594b9570@gateway/web/freenode/ip.89.75.149.112) |
| 22:13:15 | wo | TheSeven: As it seems that ipod side is the same in thick and thin I'd be more interested to see where sdio signals are mapped on 40pin connector |
| 22:13:32 | | Quit Misanthropos (Ping timeout: 272 seconds) |
| 22:13:45 | TheSeven | wo: yes, but I only have access to one half of that mapping |
| 22:13:53 | TheSeven | i.e. I don't know where which SDIO signal is on the ipod side |
| 22:15:08 | wo | TheSeven: why do you need to know this? You need to know where it ends up on 40pin 'hdd' flex' side |
| 22:15:23 | TheSeven | yeah, but I can only track ipod => 40pin here |
| 22:15:31 | TheSeven | but what I actually need to do is track ceata => 40pin |
| 22:15:50 | TheSeven | the only way how I can do this is tracking ceata => ipod => 40pin |
| 22:16:10 | wo | can't you drive sdio and look with scope on 40pin? |
| 22:16:54 | TheSeven | possibly, if I had a scope that's fast enough. it's also a bit hard to tell produce any signal at all on the data pins as long as nothing responds on the CMD pin |
| 22:16:58 | | Join Misanthropos [0] (~Misanthro@frnk-5f741134.pool.mediaWays.net) |
| 22:17:08 | TheSeven | tell it to produce* |
| 22:18:20 | wo | ok, so the only way is to compare mapping of thick and thin flex cable |
| 22:18:29 | TheSeven | yes |
| 22:18:40 | TheSeven | I can figure out the mapping of the thick one, and where the CEATA identify pin is |
| 22:18:44 | TheSeven | er, thin one |
| 22:18:51 | TheSeven | I need [Saint] for the thick one |
| 22:18:55 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 22:23:40 | | Quit Misanthropos (Ping timeout: 272 seconds) |
| 22:25:45 | | Join RiDD [0] (Ghost@2.83.169.151) |
| 22:29:49 | | Quit RiD (Ping timeout: 255 seconds) |
| 22:30:10 | | Nick RiDD is now known as RiD (Ghost@2.83.169.151) |
| 22:31:46 | | Quit model (Read error: Connection reset by peer) |
| 22:34:22 | | Join Gallomimia [0] (~gallomimi@S0106c8fb26452633.ca.shawcable.net) |
| 22:37:55 | | Quit rela (Read error: Connection reset by peer) |
| 22:38:33 | *** | Saving seen data "./dancer.seen" |
| 22:56:12 | | Quit wo (Quit: Page closed) |
| 22:56:14 | | Quit TheSeven (Ping timeout: 252 seconds) |
| 22:57:56 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 23:00 |
| 23:03:12 | | Quit amayer (Quit: Leaving) |
| 23:10:24 | TheSeven | hm, sometimes I'm getting it to hand badly enough to not even allow access to the registers anymore |
| 23:14:15 | TheSeven | s/hand/hang/ |
| 23:15:52 | | Quit wodz (Quit: Leaving) |
| 23:29:30 | | Quit nyanpasu (Ping timeout: 240 seconds) |
| 23:39:35 | | Quit pamaury (Ping timeout: 240 seconds) |
| 23:44:35 | | Quit TheSeven (Disconnected by services) |
| 23:44:52 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 23:49:51 | | Quit GodEater (Ping timeout: 244 seconds) |
| 23:53:12 | kugel | hm the build client fetches all remotes between each build |
| 23:53:21 | kugel | why that? |
| 23:54:40 | [7] | hm, as in checks for new versions of them? |
| 23:55:22 | | Join GodEater [0] (~whoknows@90.194.223.13) |
| 23:55:22 | | Quit GodEater (Changing host) |
| 23:55:22 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 23:55:51 | kugel | yes. i don't know if it would also actually check out new commits that happen in the meantime though |
| 23:56:22 | kugel | i have 4 remotes, and fetching them takes a significant amount of time if the internet connection is congested due to build uploads |
| 23:57:25 | [7] | hm right, between each build is nonsense, I was thinking at the beginning of each round, which seemed to make sense |
| 23:57:53 | | Join Basstard` [0] (~sturgeon@host-95-195-128-64.mobileonline.telia.com) |
icon identifies that the person is a core developer (has commit access).