[06:02:30] *** Quits: steffengy (~quassel@p57B48547.dip0.t-ipconnect.de) (Disconnected by services) [06:02:30] *** Joins: steffengy1 (~quassel@p57B48D4E.dip0.t-ipconnect.de) [06:11:34] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:11:47] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:42:38] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [06:43:49] *** Joins: [Saint] (~saint@rockbox/staff/saint) [07:00:45] *** Joins: steffengy (~quassel@p57B496C6.dip0.t-ipconnect.de) [07:03:50] *** Quits: steffengy1 (~quassel@p57B48D4E.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) [10:08:39] *** Joins: slenselink__ (~STeeF@office.hostnetbv.nl) [10:09:03] *** slenselink__ is now known as STeeF [10:40:45] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [10:41:43] *** Joins: [Saint] (~saint@rockbox/staff/saint) [19:51:58] copper: what's the status of your ipod mod? looks like mine's hdd is getting more broken over time, so i'm thinking about replacing that drive with something more durable [19:52:27] user890104: aside frm the fact that I lost my patience and butchered the case? [19:52:31] It's working great. [19:52:39] with a 128 GB Lexar card [19:53:04] we've tested 4 different Lexars (different models and age and capacity), all of them work [19:53:36] sounds good [19:53:44] http://www.tarkan.info/store [19:53:46] my case is also broken a bit [19:54:02] http://www.lexar.com/products/lexar-professional-400x-sdxc-uhs-i-card [19:54:13] i wanted to replace the ipod with a 160gb one at our local apple reseller [19:54:14] it actually writes at 9/10 MB/s [19:54:25] but they refused to take it [19:54:48] because it was obvious that it has been opened [19:54:56] I copied over 90 gigs onto the card through Rockbox [19:55:16] Rockbox boots and loads super fast [19:55:26] what about emcore disk mode? [19:55:29] it would be tough to go back to an HDD iPod [19:55:41] I don't know what that is [19:56:09] which emcore revision are you using? [19:56:13] but frankly I'd rather not test stuff anymore [19:56:20] the website release from 2012 [19:56:29] ah [19:56:39] i see [19:56:39] formatted the card just fine [19:57:28] I'd rather not test stuff anymore, because there is no way in hell I'm going to open it up again if something goes wrong [19:58:06] at this point I'm just going to use it with its protective case always on, until it dies [19:58:17] it's got a fresh battery though [19:58:52] also, I think Tarkan has a new version of the SD/CF adapter [19:58:55] version 6 [19:58:58] I have version 5 [19:59:33] as far as I'm concerned, I have no problem recommending his adapter with Lexar cards [19:59:39] there are no known cases when an ipod classic needed to be opened because of software issues [19:59:53] user890104: what if the card fucks up [20:00:08] I managed to kill my last microsdxc card with Rockbox on the Fuze+ [20:00:23] had it replaced direct from SanDisk [20:00:59] ah, ok then [20:01:27] since I have no clue what happened, I'd rather err on the safe side [20:01:34] mine has a semi-dead hard drive, so i have nothing to lose :) [20:01:38] eh [20:01:52] maybe make a direct SD mod [20:02:11] how so? [20:02:13] which should be easy for emcore, but i'll need some help to port it for rockbox [20:02:19] unless it has a driver for that [20:02:32] what would a "direct SD mod" be? [20:02:35] well, the pins of that ZIF connector are connected to the CPU [20:02:45] SD cards have a copuple of pins (8-9) [20:03:03] so i can connect the data/clk/whatever pins to some of the HDD connector [20:03:07] you would solder some wires directly? [20:03:11] then write a SD driver [20:03:18] well, somehow yes [20:03:21] yikes! [20:03:31] i can get a SD to microSD adapter [20:03:33] I knew you guys were nuts and not to be trusted! [20:03:40] and solder the wires to it [20:03:48] then plug a microSD card :P [20:04:00] jesus [20:04:07] as TheSeven, it's technically doable [20:04:08] I don't even want to think about it [20:04:21] there just needs to be someone brave enough to do it [20:05:06] why would you do that though, when the adapter costs 30 bucks? [20:05:18] because i don't know what the adapter does [20:05:30] you'd rather solder wires? [20:05:32] when i write the sd driver, i'd be completely sure what's happening [20:05:41] because i talk directly to the card [20:05:49] I don't even [20:05:53] not to some blackbox which doesn't work with some cards [20:05:58] as you've seen already [20:06:08] I don't know what / who's to blame [20:06:17] emcore? the adapter? the cards? [20:06:46] thing is, TheSeven acknowledged that emCORE doesn't work with some SSDs either [20:06:55] with the exact same problem [20:07:09] so I find it a bit difficult to blame the adapter [20:07:10] if you think that soldering wires to an sd card is ugly, what do you think about this: http://wiki.openwrt.org/toh/tp-link/tl-wr741nd#wr740wr741.4.x.usb.mod [20:07:24] oh dear… [20:07:49] so, you see. soldering to an sd card is not *that* bad [20:08:02] let's just say this: I trust my fingers to type code, not to do… stuff like that [20:08:43] when my fingers fail me in ViM, I can fix it without any damage [20:09:40] (also because I never code anything potentially destructive) [20:09:42] if i break a $2 SD adapter i can just buy a new one [20:10:01] what about the soldering on the ZIF interface [20:10:13] ah no [20:10:26] you would solder the wires to a separate ZIF plug thing? [20:10:26] i'd get an adapter for this end [20:10:48] yes [20:10:58] that makes more sense [20:11:26] but on the sd card side, the pins are large enough [20:11:38] Apple should make devices with upgradable storage [20:11:50] except they've taken the opposite direction, soldering everything [20:12:07] their devices are gorgeous, but damn [20:12:11] uhm, no way. who's going to buy the new models then? [20:12:35] make the new models shinier? I don't know. [20:12:50] they still don't have a 128 GB iPod or even iPhone [20:12:57] flash based, I mean [20:13:07] only 128 GB iPads [20:13:47] it's sort of strange that they decided to develop ALAC from scratch instead of going with FLAC, and yet they're not doing anything with it yet [20:14:05] no ALAC on the iTunes Music Store, and their iPods and iPhones don't have enough storage for it [20:14:54] not even the Classic [20:15:02] I'm using lossyFLAC on mine [20:15:15] which takes about half the size of my FLAC collection [21:20:05] user890104: emcore's storage driver infrastructure is basically a clone of rockbox's [21:20:43] the backend driver is very similar, most changes are due to different handling of timers etc. in rockbox [21:24:24] so if you make this work with emcore, porting it to rockbox is absolutely trivial [21:25:11] tbh the hardware is the worst part of this [23:00:55] *** Joins: Bambi123 (545c5f92@gateway/web/freenode/ip.84.92.95.146) [23:01:08] hello [23:02:34] Quick question what is the simplest build environment I need to compile emCore? hoping to use Ubuntu or Centos as I run on a virtual machine, thanks. [23:03:06] what in particular do you want to compile / why? [23:03:10] only the kernel, or also apps? [23:03:28] Just want to compile kernel [23:03:42] Just investigating issues with BBT and solid state drives [23:04:09] Bambi123: ah, I guess you're the one who's selling these CF adapters then? [23:04:16] yep [23:04:48] for just the kernel, you only need an ARM toolchain [23:04:53] we typically use https://github.com/EliasOenal/TNT [23:05:23] I can tell you for sure that the BBT layer isn't what's causing the problems though, it's just the first thing that happens to access the disk [23:05:35] ok, will note that. [23:06:01] It is a very odd thing - as all the Lexar cards from 32Gb to 256Gb - 6months old to 4 years old work FINE. [23:06:03] (this has nothing to do with the card's internal wear leveling etc., it's just a layer on top of the block device that tries to fix bad sectors on old ipod hard disks) [23:06:17] it behaves a bit like LVM or something like that [23:06:26] as long as you don't actually write a BBT superblock to the disk, it won't do anything [23:06:44] (and it fails while checking if such a superblock exists, by reading sector 0 of the disk) [23:07:01] which, normally, is just a partition table, or in the BBT case a block with a special signature [23:07:13] That what is confusing me. I can see in the source BBT can soft fail [23:07:26] but we get a hard panic reading sector 0 [23:07:43] the lexar thing is what seems to suggest that the CF adapter has issues with the SD card... however there are reports that other cards work with the original firmware which is confusing [23:08:11] Original firmware (apple) works with 99% of the SD/SDXC cards used [23:08:31] do you have any information on how that adapter works internally? [23:08:35] I can only a couple of cards which do not, as they do not allow the MBR to be re-written [23:08:44] we've already tried all kinds of things to make it happy, such as increasing timeouts etc., without success [23:09:24] why would an SD card ever prevent the MBR from being overwritten? that doesn't make any sense to me... [23:09:37] (maybe for these wifi-enabled cards, but not for anything regular) [23:10:15] It is rare, like I said I have come across maybe a couple of cards which refused the MBR and Partition table writes [23:10:45] this might indeed make emcore installation fail... as the formatting code attempts to repartition the drive [23:11:52] It is one of them which really bugs me..... If the original firmware works why does it fail on Emcore. [23:12:13] I think this problem also seems to effect normal SSD drives as well [23:12:50] at least some of the SSD issues were timing issues [23:13:16] the first transfer on some SSDs seems to just take a while, increasing timeouts fixes it [23:13:44] this CF adapter is just not responding to a sector 0 read though, not even after tens of seconds [23:14:06] as far as I can tell it's also not signalling any error condition, just not sending data indefinitely [23:14:25] weird, and the original firmware does not attempt a similiar read? [23:14:38] it sure does [23:14:44] you can't mount the drive without doing that [23:14:54] this is totally weird [23:15:10] which brings us back to the $64000 question - why is it failing with emCore [23:16:35] Sorry my unix skills are not the greatest [23:16:51] that TNT link will recompile gcc to suit the arm processor [23:16:56] yes [23:17:01] and then I can svn the latest emCore source [23:17:07] it will install a custom gcc build in ~/toolchain [23:17:08] and build to target [23:17:11] yes [23:17:37] to build a full release you need a few more tools, but for the kernel just this toolchain is sufficient [23:17:38] anything to remember if I want the build to be very verbose and send data to the lcd [23:18:20] as long as you aren't in IRQ handler code, you can use the cprintf function to print to the LCD [23:18:34] (or to the USB debug console, which might be more useful for your purposes) [23:18:46] so I can send the value of variables etc using cprintf [23:18:53] yes [23:19:02] sorry USB debug? [23:19:20] you can basically send log output via USB [23:19:57] what do I need to run on the host pc? [23:20:28] you need the emcore debugger client (which you need to run your custom kernel anyway) [23:20:38] that's emcore/trunk/tools/emcore.py in our SVN [23:21:12] you can just run "emcore.py console" to display the log output, similar to adb logcat for android [23:21:59] ok, I only have physical windows machines, so will have to setup python on my machine. [23:23:07] that works on both windows and linux. setting up the drivers is much simpler on linux though (it just works out of the box) [23:24:19] reading some of the emCore source, I notice you have functions to deal with the CE-ATA and ATAPI interface of the classics [23:24:37] is there any possiblity the problem is introduced there? [23:24:44] very unlikely [23:25:23] you can probably just ignore the CEATA code [23:27:47] I think my first idea is to maybe read the full ata init sequence and identity raw data [23:28:06] and just compare with the Lexar and another card. [23:28:26] hm, I haven't looked into that into detail, but identify seems to still work with all cards [23:28:57] could be possible that the adapter is requesting a broken DMA mode or something, but I don't see why it would only do that with some cards... [23:29:27] is it possible the replied data by the non-lexar cards sends data which effect how the ATA function then proceed [23:29:45] maybe sector size or size, etc, etc [23:30:06] possible, but not really likely [23:30:14] probably worth ruling out though ;) [23:30:43] Yes, :) I have seen the weirdest of data of some cards - so yes it is something I need to confirm [23:32:01] I guess you have a card which fails to test? [23:33:31] I have 2 test cards here all work with the Apple firmware - Sandisk MicroSD 64Gb, Kingston 128Gb [23:33:41] But fail on EmCore [23:35:58] ok [23:36:03] I have spent many many hours when developing my adapters with storage scopes, recording the full ATA bus - and the SD adapter 100% works to ATAPI-6 standard [23:36:25] if you have such equipment that could be very useful in debugging this :) [23:36:28] timings and responses are to spec [23:36:55] so you developed these adapters yourself? [23:37:09] based on some existing bridge chip, or using some kind of microcontroller? [23:37:28] SD adapter is not my work - it is based on an existing bridge chipset [23:37:50] but needed work on the iPod compatibility [23:40:00] I think recording the ATA bus while booting up emCore on a working and non-working card would be very telling for fault finding [23:40:22] definitely [23:40:33] may help locate to problem area quicker than messing with code [23:41:25] yes, it will surely help pinpointing the problem, i.e. which side of the connection is behaving wrong and in what way [23:42:09] if you can do that, I'll happily assist with diagnosing (and hopefully fixing) the code side of things [23:42:54] great, time is a luxury - I was only hoping to setup a build env. but it looks like hardware diagnostics. [23:43:36] when I get some time, I will set it all up and record the ATA exchange. [23:44:20] My storage ability is limited - so will have to work on a solution to recording longer than I can at the moment [23:45:32] if that helps I can try to make a build that waits a few seconds before initiating the failing transfer so that you can trigger on the right thing [23:47:01] Yes that would be good, I would still have to create logic for the trigger pattern. [23:47:43] would it be possible maybe to wait x mS after the ATA reset pulse is sent? [23:47:53] That would be easier for me to account for [23:48:28] there will be some jitter on that [23:48:58] I can try to keep that down to a few hundred microseconds though [23:49:10] jitter is ok, my storage is limited to around 1 sec, and still be able to read the data being exchanged [23:49:45] I guess a second should be sufficient for capturing the whole handshake from reset through identify to the failing read [23:49:46] I can go out to 2secs record but I start to loose some info and the data exchange becomes garbled [23:51:14] the ata init is normally over within about 300 - 500mS [23:52:53] I can start my reading once the BSY signal is negated [23:55:01] the current code should assert RST briefly, then wait for about 300ms while setting up the host controller, then wait for nBSY for up to 10 seconds, then send the IDENTIFY command, then wait up to another 10 seconds for the response [23:55:20] then it will configure DMA, possibly sending up to 3 SET_FEATURE commands [23:55:55] and then immediately try to read sector 0 [23:58:23] I will look it up, but I think BSY clears a few ms after the RST [23:59:54] I can try to move the RST pulse towards the end of the host init sequence, that should shave off ~290ms