[02:13:46] *** Quits: cyb3rkn19ht (~cyb3rkn19@c-67-172-198-4.hsd1.va.comcast.net) (Remote host closed the connection) [02:14:28] *** Joins: cyb3rkn19ht (~cyb3rkn19@c-67-172-198-4.hsd1.va.comcast.net) [06:56:08] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:56:18] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [11:28:06] *** Joins: Xaero252 (43a0122d@gateway/web/freenode/ip.67.160.18.45) [11:28:15] Anybody active on the channel? [11:30:40] At any rate, I have a serious in depth query regarding iPod Classic emcore - I have attempted to install a solid state disk into my iPod classic, the stock firmware and emcore fail to boot, however diagnostic mode reveals that the SSD is indeed powered on and detected; Further investigation suggests (for the emcore side of the house at least) that BBT may be the culprit for the device not booting; immediately upon loading [11:31:16] <[7]> how exactly does emcore fail? [11:31:38] "ATA: Error %08X while reading BBT (sector %d, count %d)\n" [11:32:09] <[7]> hm, that basically means that the first attempt to read a sector failed [11:33:28] Indeed; Is BBT utilized for both spinning platter and Nand memory? My understanding that it was a NAND function... Though I see in the source, that the function that throws that does indeed attempt to read sectors. [11:33:29] <[7]> what is the error code? [11:34:05] <[7]> this is a software bad block remapping layer on top of whatever the hardware does, intended to deal with some half-broken hard disk drives [11:34:42] <[7]> unless you have a special BBT data structure in the first sectors of the drive it will just realize that no software BBT is set up and pass through requests 1:1 [11:34:57] The exact error code is 80000003 [11:35:54] I see; could it be that since this is a NAND based SSD that the SSD's controller is writing to the first sectors of the drive? [11:37:14] Interestingly this occurs with two seperate SSD's on both a 6g and 7g iPod motherboard; which *should* be the case since the code remains unchanged. Also interesting to note is that neither drive appears to provide SMART information, though they both support ATA Secure-Erase. [11:40:12] <[7]> I've never seen an SSD not support SMART, so that might actually indicate that the diagmore firmware can't quite access it either [11:40:27] <[7]> from what it looks like this error code means that in ata_rw_chunk the call to ata_wait_for_start_of_transfer times out [11:40:46] <[7]> however the IDENTIFY command seems to work [11:41:10] <[7]> I've got reports of similar issues in the past, it seems like some SSDs need a bit of time after powering up before being fully accessible [11:41:38] <[7]> two things might be worth trying: [11:41:47] I'm all ears :D [11:41:51] <[7]> 1. increasing the timeout value of that call (the 500000 argument) [11:42:08] <[7]> 2. if that didn't help, adding 1-2 seconds of delay after powering up the drive [11:42:34] <[7]> that 500000 means half a second btw [11:43:21] I see; Could the delay be approximated by how long the drive takes to respond when plugged in via zif->usb adapter to my *nix rig? [11:43:44] <[7]> possibly, but some of that might also be caused by the adapter [11:43:50] <[7]> so that would be an upper bound at least [11:44:46] Indeed. Something peculiar happened once with this drive as well, the Error was thrown but emCore still started, however any attempt to read/write from the drive from there caused a panic. [11:46:14] <[7]> that is by design [11:46:37] <[7]> the bbt error is non-fatal, it will just enter passthrough mode like if there is no bbt in the sector [11:47:00] <[7]> subsequently it will fail to mount the data partition [11:47:13] <[7]> so any attempt to access that will throw various errors [11:47:29] <[7]> it really shouldn't panic though [11:47:38] Excellent, is there any toolchain wiki page available? [11:48:10] <[7]> we use the rockbox arm eabi toolchain, which is built by rockboxdev.sh [11:48:32] <[7]> http://git.rockbox.org/?p=rockbox.git;a=blob_plain;f=tools/rockboxdev.sh;hb=refs/heads/master [11:49:06] Excellent! I love easy to work with projects [11:50:45] which specific architecture is the classic? [11:50:52] <[7]> don't worry, things will get much more tricky if you need to compile emcore apps (such as the installer or boot menu) [11:51:04] <[7]> arm926e IIRC [11:52:37] Interesting. I'm hoping these SSD's can indeed work. Theres no logical reason they shouldn't 3.3v 1.8" Zif Drives... they've been reported working with 5.5g and lower iPods. [11:53:17] <[7]> there have been lots of reports of similar behavior like you're observing as well [11:53:35] <[7]> the classic has a different ATA driver which might be more picky [11:54:01] <[7]> and some people have reported ssd accessibility delays of several (up to 10) seconds [11:54:17] Seems logical and similar to what I've seen [11:54:53] These drives take about 5+ seconds to start talking with my desktop via usb, some of that is adapter overhead... but I'd have a hard time believing all of it is. [11:57:05] been a while since I worked with a toolchain that was this easy to configure lol. then again my last device choices for development were a little archaic by design (PS2, PSP) [12:01:35] <[7]> have fun with elf2emcoreapp :P [12:06:05] <[7]> I have to leave now, feel free to contact me later if you run into further trouble [12:08:50] kk thanks for the assist [12:55:01] Okay, so I've built the modified emcore.bin, now the question becomes, how to install it properly? [13:04:03] Also, not sure what the big deal was with elf2emcoreapp; just needed to give it proper libs lol [13:25:37] supposedly I should be able to use emcoreldr.py to load this thing, I've updated my libusb to the latest, and am running python3 but it regurgitates nothing but errors. [13:36:53] *** Quits: Xaero252 (43a0122d@gateway/web/freenode/ip.67.160.18.45) (Quit: Page closed) [13:37:45] *** Joins: Xaero252 (43a0122d@gateway/web/freenode/ip.67.160.18.45) [14:01:28] [13:03:58] Also, not sure what the big deal was with elf2emcoreapp; just needed to give it proper libs lol<< after doing the same thing, it compiled fine but didn't produce working binaries when run later [14:02:03] about replacing emocre.bin, the only way i can think of, is rebuilding a complete installer image, and reflashing it [14:02:16] so you need to build apps/installer-ipodclassic [14:06:24] Crud, every time I try to build that it complains about svn versions for versions.h [14:08:39] well, we made the build system with subversion <= 1.6 in mind [14:08:48] "make: *** No rule to make target `.svn/entries', needed by `build/version.h'. Stop." [14:09:01] just make an empty file, it should do it [14:09:18] Yes, the SVN code in the makefile worked fine for emcore itself though, don't see why the same code wouldn't work in a differrent directories [14:09:45] i.e. mkdir .svn && touch ./svn/entries? [14:09:53] exactly [14:10:08] kk [14:10:10] we should switch to $(svnversion)-based approach at some point [14:11:06] svn: E070014: Can't read file '/home/xaero/testing/emcore/apps/installer-ipodclassic/.svn/entries': End of file found [14:11:13] this is going to be irritating, I can already tell [14:12:45] Also, just to note, the makefile has REVISION := $(shell svnversion .) already. so I'm not sure why its not working... [14:13:25] and running svnversion outside of the makefile returns 868, which is accurate [14:19:58] making progress... [14:22:18] Exception AttributeError: "'NoneType' object has no attribute 'libusb_exit'" in > ignored [14:22:19] I have pyusb 1.0.0a3 [14:22:26] which makefile uses svnversion? i should have missed that [14:22:59] uhm... how did you get to that error msg? [14:23:18] Most of them use svnversion in the first place (deciding REVISION and REVISION_INT); later on for the version.h file they don't use svnversion though [14:24:32] the only target for installer_ipodclassic is all, so make all -> umsboot -> success -> "[GENPWN] build/bootstrap.bin -> traceback with that error at the base of it. [14:24:56] and I see why now; usb.core.USBError: [Errno 13] Access denied (insufficient permissions) pyusb needs root [14:26:36] much more progress now... [14:29:12] had to hardcode the version number in usb.c for the ipodclassic emcore this time around, strange. [14:30:22] BFD: build/boot.elf(.text): relocation 15 has invalid symbol index 30 should these worry me at all? probably about 12-15 messages [14:34:20] eff, new python version is going to be the death of me for this [14:34:36] "TypeError: Type str doesn't support the buffer API" [14:40:39] cheated, mv python->python.bak ln -s python2 -> python [14:42:43] not going to build rockbox.ucl i just touch'd it, should be fine, right? [14:43:45] And now, I believe I have reached the final dead-end [14:44:05] "Assertion failure in make_mapping_symbol at ../../binutils-2.20.1/gas/config/tc-arm.c line 2485." [14:44:30] Or not; since binutils 2.20.1 isn't even there [14:45:46] nope cause thats just a false reference T_T [14:52:03] What GCC was emcore built using, current GCC doesn't like the old mapping symbols. [14:53:18] nvm found it has to be less than 4.5 I'm at 4.7 [14:54:36] luckily arch is friendly enough to play well with multiple version [14:57:24] emcorefs also fails to compile on recent gcc versions [14:57:40] how far back should I roll? [14:59:16] you don't need this one for compiling the installer, it's an extra tool [14:59:49] and i really don't know which gcc version is supported by emcore, haven't had such issues so far [15:00:49] Its kind of the price I pay for using a build-your own rolling release distro ;) [15:01:45] I just really hope that somehow increasing the delay before attempting to access the ATA device allows one of these two SSD's to work. [15:25:11] I may have to setup a legacy linux install just to get this to compile rofl [15:25:18] old gcc versions aren't playing nice atm [15:31:24] *** Quits: Xaero252 (43a0122d@gateway/web/freenode/ip.67.160.18.45) (Quit: Page closed) [15:34:14] *** Joins: xaero252 (43a0122d@gateway/web/freenode/ip.67.160.18.45) [19:00:04] xaero252: i can make a patched build for you, if you like [21:21:08] *** Quits: cyb3rkn19ht (~cyb3rkn19@c-67-172-198-4.hsd1.va.comcast.net) (Remote host closed the connection) [21:22:04] *** Joins: cyb3rkn19ht (~cyb3rkn19@c-67-172-198-4.hsd1.va.comcast.net)