| 00:04:34 | [7] | well, IDA isn't really designed for debugging roms :) |
| 00:13:15 | wodz | Hmm, that makes me think about stepping through rk27xx nand bootloader running in hacked skyeye :-) |
| 00:14:27 | wodz | I need to digg up my notes about this |
| 00:17:31 | | Join tripper [0] (~SKITTLES@scalise.dreamhost.com) |
| 00:17:45 | tripper | is amayer on much |
| 00:18:00 | tripper | one of his themes is breaking and I wanted to ask him about it |
| 00:23:31 | *** | Saving seen data "./dancer.seen" |
| 00:31:36 | | Quit wodz (Quit: Leaving) |
| 00:32:57 | | Quit rdn (Remote host closed the connection) |
| 00:42:08 | [7] | pamaury: damn, it always ends up crashing into the data abort handler somehow if I single step the USB IRQ handler |
| 00:43:56 | pamaury | I think I'm slowly trying to understand how all this works |
| 00:44:04 | pamaury | s/trying/managing |
| 00:44:18 | [7] | pamaury: look like you're quicker than me then... |
| 00:44:44 | [7] | could you make use of remote access to a GDB'ed clip+? |
| 00:45:03 | pamaury | I have found more or less how the descriptors are generated, I think this will help me to figure out many things |
| 00:45:12 | pamaury | currently not |
| 00:48:00 | | Join sciopat [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
| 00:48:37 | pamaury | I suspect everything is done with classes. For example the mass storage would be something like usb_add_interface(new ums_recover_intf_t()) |
| 00:48:37 | pamaury | I'll send you the ida back at some point, so you can have a look if you can |
| 00:49:18 | [7] | pamaury: would a RAM dump of the running state be of any use? |
| 00:50:06 | | Quit sciopath (Ping timeout: 246 seconds) |
| 00:50:18 | pamaury | currently no, I haven't found the addresses of useful stuff. It's incredible how much bookeeping this thing done instead of actually *doing* things |
| 00:50:53 | [7] | absolutely |
| 00:51:20 | [7] | pamaury: where's IRAM/DRAM on this one? |
| 00:51:24 | [7] | (address and size) |
| 00:52:07 | pamaury | iram is at 0x81000000 |
| 00:52:53 | pamaury | dram at 0x30000000 |
| 00:53:06 | [7] | dram is 4MB? how much is IRAM? |
| 00:54:12 | pamaury | I think on clip+ there 1MB of IRAM |
| 00:54:19 | [7] | woah |
| 00:54:37 | pamaury | and on the older versions, 320KB |
| 00:55:07 | pamaury | ./configure says clip+ has 8MB of dram |
| 00:55:54 | [7] | ok that's gonna take a while to dump |
| 00:56:03 | [7] | I'll try to correlate it with the mass storage drive contents |
| 00:56:24 | | Quit sciopat (Ping timeout: 246 seconds) |
| 01:00 |
| 01:00:44 | [7] | 0x30000000 through 0x30800000 is all zeroes :/ |
| 01:01:11 | | Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
| 01:01:19 | pamaury | I haven't find any reference to the DRAM currently |
| 01:01:43 | [7] | so that 4MB drive might after all be flash? |
| 01:01:55 | [7] | wait... 4MB is exactly the size of an eMMC boot area, right? |
| 01:02:12 | [7] | writing was noticably slower than reading |
| 01:04:45 | pamaury | interesting |
| 01:06:15 | pamaury | I have no idea how this thing boots and which part we flash when we write the rockbox bootloader |
| 01:06:37 | [7] | who has a clue about that? bertrik? |
| 01:07:27 | pamaury | funman |
| 01:07:44 | bertrik | [7]: the rockbox bootloader is written in the main (big) flash |
| 01:08:14 | [7] | so I guess we have a way to get at the boot area contents from a working one's eMMC somehow? |
| 01:08:42 | bertrik | the firmware uses the first 0x10000 blocks or so |
| 01:09:19 | pamaury | bertrik: of the user area ? or of the boot area ? does it have a boot area ? |
| 01:09:41 | [7] | hm..... no, the contents of the 4MB drive do NOT stick across a reboot... |
| 01:10:31 | bertrik | pamaury: I don't know if there's a user or boot area, I though there was just one flat internal flash memory, of which the first 32 MB or so is reserved for the OF |
| 01:10:53 | [7] | hm, the data on the drive doesn't read back properly AT ALL |
| 01:11:00 | bertrik | I seem to remember that the reserved area is about twice the size of a firmware upgrade image, perhaps an active firmware and a spare |
| 01:11:05 | | Quit sciopath (Ping timeout: 246 seconds) |
| 01:11:35 | bertrik | in our sd driver for AMS, we always skip the first 32 MB |
| 01:11:41 | pamaury | bertrik: do you know if the dram needs some init of some kind ? |
| 01:12:11 | bertrik | I don't know, but generally I guess so |
| 01:12:43 | bertrik | we do some magic write IIRC in the rockbox initcode too |
| 01:13:05 | bertrik | which is interpreted by the SDRAM controller |
| 01:13:07 | [7] | ok, so that drive is completely fake |
| 01:13:20 | [7] | if I write it and read it back I just get thousands of copies of the last written sector |
| 01:13:37 | | Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
| 01:13:40 | | Join sakax [0] (~sakax@d8D862C77.access.telenet.be) |
| 01:14:24 | bertrik | [7]: oh, I thought it was consistent at least in between reboots |
| 01:14:36 | bertrik | or maybe that was linux caching? |
| 01:14:54 | pamaury | haha, I *might* be wrong but apparently the ums interface might expose two vendor specific commands |
| 01:14:58 | pamaury | (control type) |
| 01:15:00 | [7] | straight write and read back with dd returns duplicated last sector data |
| 01:15:07 | [7] | without even disconnecting in between |
| 01:15:42 | [7] | interesting... which ones? |
| 01:15:52 | pamaury | 0xfe and 0xff |
| 01:16:00 | pamaury | that's just a wild at this point |
| 01:16:05 | [7] | that looks like standard USB mass storage stuff |
| 01:16:07 | bertrik | aren't those the microsoft extensions to UMS? |
| 01:16:10 | [7] | get max lun and mass storage reset |
| 01:16:14 | bertrik | oh |
| 01:17:01 | [7] | technically those aren't vendor specific ones but standard ones, addressed at the mass storage interface instead of the device |
| 01:17:04 | pamaury | and I didn't remember these were 0xff and 0xfe control transfers, so that's good :) |
| 01:17:23 | [7] | so you've already located the place where these things are hooked? |
| 01:19:11 | pamaury | more or less, you won't believe me... |
| 01:19:42 | * | [7] tends to believe absolutely everything given what kind of mess this is |
| 01:20:57 | pamaury | currently I have only located the hooks for controls, apparently each "config" (could be device or interface) has a list of "handlers", each "handler" specify the command it handles and the function to call |
| 01:21:19 | saratoga | [7]: the 4MB drive is completely fake |
| 01:21:20 | [7] | kinda reminds me of that IRQ hook list |
| 01:21:52 | saratoga | theres another mode where you get a full 32 MB drive that corresponds to the NAND first 32 MB blocks |
| 01:22:30 | pamaury | [7]: I can give you the adresses but these are mostly useless, control transfers aren't useful |
| 01:22:34 | saratoga | no one knows what the purpose of the 4MB drive is, but usually it means the device is broken somehow |
| 01:22:37 | pamaury | we need to locate the bulk ones |
| 01:22:52 | saratoga | the 32MB one will mount if you short out the NAND pins during power up, once you unshort them it is writeable |
| 01:23:35 | | Quit sciopath (Ping timeout: 276 seconds) |
| 01:23:56 | [7] | saratoga: hm, this is a NAND or eMMC device? I'm puzzled. |
| 01:24:08 | saratoga | its actually a NAND connected to a sandisk made SD controller |
| 01:24:13 | saratoga | software wise it looks like SD |
| 01:24:36 | [7] | so you actually mean the first 32MB of that SD card? |
| 01:24:36 | bertrik | "many clips died to bring us this information" |
| 01:24:38 | saratoga | we actually use the same driver for both the internal and external SD cards |
| 01:24:58 | saratoga | yeah its the first 32 MB worth of blocks on the internal SD |
| 01:25:08 | pamaury | oh, so the ams chips does the FTL ? |
| 01:25:12 | bertrik | yes |
| 01:25:19 | saratoga | i think its a sandisk chip |
| 01:25:23 | pamaury | lol, that's interesting |
| 01:25:42 | pamaury | this chip is really amazing, everything you would expect is just not true here |
| 01:25:43 | bertrik | that made things so much easier with AMS |
| 01:26:07 | | Quit zu_ (Read error: Operation timed out) |
| 01:26:12 | [7] | saratoga: in case you didn't follow the discussion, I've JTAGed a donated dead clip and we're now looking into what that 4MB drive actually is and if it allows non-jtag recovery of some kind |
| 01:26:25 | saratoga | my theory about the 4MB drive is that when Sandisk customized the AS3525, parts of the original ROM were left in place but not necessarily working, hence when the device is bricked you can end up in the original ROM and get that 4MB drive (or the working 32 MB drive) |
| 01:26:48 | saratoga | [7]: just caught up, I saw the JTAG, but thought you were looking at the internal ROM on the device? |
| 01:27:10 | [7] | we're disassembling the internal ROM to figure out what that 4MB thing is |
| 01:27:13 | pamaury | there is only one ROM on that thing, right ? |
| 01:28:01 | saratoga | yeah, its built into the AMS chip |
| 01:28:04 | saratoga | 128KB IIRC |
| 01:28:17 | [7] | yes |
| 01:28:22 | pamaury | yes that's it |
| 01:28:36 | [7] | saratoga: so you say you can't reach this 4MB drive state by just overwriting the first 32MB? |
| 01:29:26 | saratoga | [7]: i think you end up with the 4MB state if the internal memory is corrupted badly enough |
| 01:29:34 | [7] | ok |
| 01:29:43 | saratoga | the 32MB state seems to happen if the NAND itself fails to talk to the controller during boot |
| 01:29:57 | saratoga | so i think a software problem means the 4MB one, and a hardware problem the 32 MB |
| 01:30:03 | saratoga | at least thats what people in the forums report |
| 01:30:04 | | Join zu [0] (~zu@ks387228.kimsufi.com) |
| 01:30:08 | [7] | I wonder if I should try booting the OF on this dead one |
| 01:30:10 | bertrik | saratoga: or perhaps if some checksum fails |
| 01:30:13 | [7] | just to see if it works |
| 01:30:30 | saratoga | people have bricked their players flashing a bad firmware and got the 4MB ROM, then shorted the NAND chip and got the 32MB, then copied over a good firmware and recovered a working player |
| 01:30:39 | saratoga | yes a checksum would make sense |
| 01:31:06 | saratoga | "4MB ROM" => "4MB disk" (no idea if its actually a ROM or even anything at all) |
| 01:31:12 | saratoga | anyway, have to step out for a minute |
| 01:31:18 | saratoga | will check back |
| 01:40:19 | | Quit Raptors (Ping timeout: 248 seconds) |
| 01:42:35 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
| 01:47:08 | | Quit Raptors (Ping timeout: 246 seconds) |
| 01:48:18 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
| 02:00 |
| 02:02:56 | | Quit bertrik (Ping timeout: 256 seconds) |
| 02:05:49 | [7] | hm, the instructions on http://www.rockbox.org/wiki/SansaAMSJTAG fail |
| 02:06:12 | [7] | one reason for that is that they expect code to be execuring from RAM, however in my case ROM is still mapped to address 0 |
| 02:08:30 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130729175331]) |
| 02:09:48 | pamaury | [7]: there is a register to change the memory map iirc |
| 02:09:58 | [7] | yes but that didn't help either |
| 02:09:59 | funman | what are you guys doing? |
| 02:10:07 | [7] | i.e. remapping worked, but it didn't boot regardless |
| 02:10:20 | [7] | funman: trying to figure out what's the matter with that AMS 4MB mode |
| 02:10:42 | funman | i could never make any sense of it |
| 02:10:42 | [7] | I have JTAG'ed a 4MB mode clip+ that someone donated |
| 02:10:55 | [7] | so we can finally have a peek into the inside of it :) |
| 02:11:07 | funman | nice :) |
| 02:11:34 | funman | did you find SDRAM init code? |
| 02:11:57 | funman | firmware/target/arm/memory-init.S |
| 02:12:10 | [7] | it looks like the bootrom doesn't use SDRAM, which was kinda to be expected |
| 02:12:16 | [7] | sdram address space reads as all zeros |
| 02:12:18 | funman | indeed |
| 02:12:28 | funman | OF is loaded in SRAM |
| 02:13:10 | funman | firmware/target/arm/as3525/memory-init.S |
| 02:14:14 | pamaury | I'm disassembling the bootrom currently |
| 02:15:23 | [7] | funman: how much IRAM does the clip+ have? |
| 02:15:30 | funman | [7]: what is mapped at 0? |
| 02:15:32 | funman | 1MB |
| 02:15:42 | [7] | I get a data abort trying to read from 0x81039000 |
| 02:16:17 | [7] | funman: rom is mapped to 0 in that state, but it executes from 0x80000000 |
| 02:16:30 | funman | oh |
| 02:17:10 | funman | [7]: try 0xc1039000 |
| 02:17:12 | [7] | hm, interesting... tried a second time, didn't get a data abort |
| 02:17:40 | funman | in as3525v2.h : #define IRAM_SIZE 0x100000 |
| 02:17:59 | | Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) |
| 02:18:15 | funman | the bootrom remaps IRAM at 0x0 |
| 02:18:53 | funman | hmm maybe not on clip+, |
| 02:19:19 | [7] | I wouldn't expect the rom to differ within an SoC series |
| 02:19:34 | [7] | maybe it remaps it before executing the firmware, but not before entering this recovery mode |
| 02:20:38 | [7] | pamaury: the pattern that I get when reading from the mass storage drive appeas in IRAM at 0xec6c0 |
| 02:20:42 | pamaury | The bootrom I have set remap bit |
| 02:20:53 | pamaury | it the clip+ one |
| 02:21:08 | | Quit froggyman (Ping timeout: 245 seconds) |
| 02:21:50 | funman | clip+ OF starts with iram at 0x0 |
| 02:22:10 | [7] | 0xc8100008 reads 0x00000002 in the state I captured it in (i.e. sitting in that while(true); loop) |
| 02:22:35 | funman | it's read only |
| 02:22:52 | [7] | nah, bit 1 is read only, not bit 0 |
| 02:22:57 | funman | Default : GPIOC(0) |
| 02:23:06 | funman | ah yes |
| 02:23:32 | *** | Saving seen data "./dancer.seen" |
| 02:23:36 | funman | can you upload rb bootloader to IRAM and set bit 0 ? |
| 02:23:52 | [7] | if you have a binary for me, sure |
| 02:24:43 | [7] | rockbox boots with CPSR=0x600000D3 (supervisor mode, IRQ/FIQ disabled) I assume? |
| 02:24:50 | [7] | and caches disabled |
| 02:25:20 | funman | iirc yes |
| 02:26:19 | | Join froggyman [0] (~froggyman@unaffiliated/froggyman) |
| 02:27:18 | [7] | funman: so where can I get a bootloader binary that should work? |
| 02:27:28 | funman | sure |
| 02:27:32 | funman | uploading |
| 02:29:40 | funman | [7]: http://37.187.19.138/~fun/bootloader.bin |
| 02:30:18 | [7] | ATA error -2 :) |
| 02:30:27 | funman | hmm |
| 02:30:32 | funman | not bad |
| 02:31:00 | funman | storage_init returns -2 |
| 02:32:02 | funman | this means the 'card' (internal storage) timeouts when reading OCR |
| 02:32:24 | funman | maybe we could make a bootloader that loads from SD slot |
| 02:32:50 | funman | firmware/target/arm/as3525/sd-as3525v2.c +511 |
| 02:33:00 | [7] | I've now halted it in the state where it displays the ata error so that we can look at regs |
| 02:33:16 | funman | not sure if regs would help |
| 02:33:35 | funman | IMO you should play with SD commands |
| 02:33:54 | funman | bootloader.bin is created when building clip+ bootloader btw, no special command |
| 02:33:55 | [7] | well access to SD controller regs is playing with SD commands :) |
| 02:34:05 | funman | but controller looks ok |
| 02:34:31 | funman | we don't get errors when sending commands |
| 02:34:46 | funman | it's rather that the storage doesn't respond to our commands |
| 02:35:12 | funman | let me try something |
| 02:39:35 | funman | http://pastie.org/8213549 |
| 02:39:58 | [7] | so I guess that needs a microsd card? |
| 02:40:09 | funman | yes |
| 02:40:30 | [7] | hm, can you build a binary from that? I don't even have the RB toolchain set up right now |
| 02:40:38 | funman | http://pastie.org/8213551 actually builds |
| 02:41:00 | funman | http://37.187.19.138/~fun/bootloader.bin |
| 02:41:13 | funman | just put any usd card and see if the boot progresses further |
| 02:41:46 | funman | my patch might be horribly wrong |
| 02:43:39 | funman | it might have been enough to force GPIOB_PIN(5) to 0 in send_cmd |
| 02:43:45 | | Quit wipt (Ping timeout: 260 seconds) |
| 02:43:53 | [7] | file not found => bootloader USB mode :) |
| 02:43:58 | funman | woot! |
| 02:44:04 | funman | does it mount? |
| 02:44:36 | [7] | well it attached to USB at least |
| 02:44:47 | [7] | it probably has a 32MB offset now, so it doesn't find any partitions |
| 02:44:56 | funman | nah there should be no offset |
| 02:45:13 | funman | /* skip SanDisk OF */ |
| 02:45:13 | funman | if (drive == INTERNAL_AS3525) |
| 02:45:13 | funman | start += AMS_OF_SIZE; |
| 02:45:27 | funman | but i force drive to SD_SLOT_AS3525 |
| 02:45:34 | funman | xxd /dec/sdc|head ? |
| 02:45:53 | [7] | hm it says no media present |
| 02:45:55 | funman | might be worth to dd some data and then check with a real card reader |
| 02:45:57 | funman | damn |
| 02:47:08 | | Quit yosafbridge (Ping timeout: 256 seconds) |
| 02:47:20 | [7] | I'm wondering if the USB mode picks the right card |
| 02:47:30 | funman | http://pastie.org/8213561 : http://37.187.19.138/~fun/bootloader.bin |
| 02:48:52 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
| 02:48:58 | | Quit advcomp2019__ (Ping timeout: 268 seconds) |
| 02:49:04 | funman | http://pastie.org/8213564 : http://37.187.19.138/~fun/bootloader.bin |
| 02:49:40 | [7] | the first one is ata error 2 again |
| 02:50:14 | [7] | the second one again |
| 02:51:14 | funman | hmm which ams_variant do you have? |
| 02:51:30 | [7] | clip+, whatever that is |
| 02:51:40 | funman | there are 2 variants |
| 02:51:48 | [7] | how do I tell? |
| 02:52:05 | funman | GPIOB_DIR &= ~(1<<5); |
| 02:52:05 | funman | amsv2_variant = !!GPIOB_PIN(5); |
| 02:52:39 | [7] | hm... addresses? ;) |
| 02:52:54 | funman | firmware/export/as3525.h |
| 02:53:19 | funman | http://pastie.org/8213568 : http://37.187.19.138/~fun/bootloader.bin |
| 02:53:37 | funman | #define GPIOB_DIR (*(volatile unsigned char*)(GPIOB_BASE+0x400)) |
| 02:53:43 | funman | #define GPIOB_DATA (*(volatile unsigned char*)(GPIOB_BASE+(0xff<<2))) |
| 02:53:49 | funman | #define GPIOB_BASE 0xC80C0000 |
| 02:55:27 | [7] | amsv2_variant is zero then |
| 02:55:35 | [7] | 0xc80c0400: 00000045 |
| 02:55:35 | [7] | 0xc80c03fc: 000000c4 |
| 02:55:35 | [7] | 0xc80c0080: 00000000 |
| 02:55:47 | funman | last binary should work better then |
| 02:56:17 | [7] | yes, it mounted :) |
| 02:56:33 | funman | \o/ |
| 02:56:51 | funman | now the same patch should be applied to main rockbox but revised a bit to disable internal storage |
| 02:57:41 | pamaury | what does this patch do ? |
| 02:57:53 | [7] | I just tried, it successfully boots the main binary from the microsd card |
| 02:57:56 | funman | send commands to uSD controller |
| 02:58:11 | funman | [7]: hmm can you browse? |
| 02:58:21 | [7] | no, it dies with ata error -2 again |
| 02:58:28 | funman | oh of course |
| 02:58:38 | funman | let me build main binary with that same patch |
| 02:58:53 | pamaury | hum, but does the main binary knows how to talk to the uSB already ? |
| 02:58:58 | [7] | anyway, looks like we're dealing with a screwed up FTL here |
| 02:59:08 | funman | pamaury: sure |
| 02:59:12 | funman | uSD slots always worked |
| 02:59:20 | [7] | I wonder how that controller chip behaves if the nand isn't accessible, it probably recreates all internal structures as it becomes accessible again? |
| 02:59:30 | pamaury | ah ok, |
| 02:59:32 | funman | http://37.187.19.138/~fun/rockbox.zip |
| 03:00 |
| 03:00:01 | pamaury | maybe the controller has some magic commands |
| 03:00:50 | funman | http://pastie.org/8213583 : http://37.187.19.138/~fun/rockbox.zip |
| 03:04:34 | [7] | OK, I can browse files now |
| 03:04:39 | [7] | quite interesting |
| 03:04:48 | funman | play some mp3!!! |
| 03:04:49 | [7] | this is mounted as both internal and external storage now :) |
| 03:04:54 | funman | :) |
| 03:05:07 | funman | my patch might need some work |
| 03:05:12 | funman | did you take first or 2nd version ? |
| 03:05:19 | [7] | the second one, didn't try the first |
| 03:05:29 | funman | i thought that one would only mount once |
| 03:05:55 | [7] | well the file browser displays .rockbox and <microSD1> containin another .rockbox |
| 03:06:06 | [7] | could possibly be just aliased and not actually mounted twice of course |
| 03:06:38 | [7] | anyway, we know who's the culprit on this particular device. now how do we fix it? :) |
| 03:07:05 | funman | 0 clue |
| 03:07:21 | funman | you could try to solder some wires directly to the NAND |
| 03:07:52 | [7] | I'm less concerned about this particular device than about finding a general, real solution for this kind of problem |
| 03:08:15 | [7] | which would mean 2 things: a way to boot through that 4MB drive, and a way to tell that SD controller chip to reinitialize the NAND |
| 03:08:43 | [7] | could possibly that this one is just bricked even worse than some others... IIRC it failed to respond to the "unbrick pin" trick |
| 03:08:45 | funman | i'd guess NAND is just broken at that point |
| 03:08:47 | pamaury | I can do the first one, but for the second it's unlikely the bootrom help in any way |
| 03:09:16 | [7] | I should probably double check if I can unbrick this one the other way |
| 03:13:03 | funman | can you put a breakpoint in JTAG when the bootrom initializes the internal storage? |
| 03:13:33 | [7] | I can, if you tell me where that is :) |
| 03:13:45 | funman | if you send me your boot rom i will |
| 03:13:54 | [7] | I could also try setting up a memory access breakpoint |
| 03:14:14 | funman | gtg.. good luck with this |
| 03:15:13 | [7] | funman: http://theseven.bounceme.net/~theseven/tmp/bootrom.bin |
| 03:15:20 | [7] | that's the rom from that particular device |
| 03:15:56 | [7] | funman: http://theseven.bounceme.net/~theseven/tmp/bootrom.idb is the ida database |
| 03:16:12 | [7] | but pamaury has already worked on improving that, so you might be more interested in his one |
| 03:16:33 | funman | "Please use newer version of IDA" |
| 03:16:54 | [7] | that's an ida 5.5 database |
| 03:17:01 | [7] | my ida was complaining that it's too old :) |
| 03:17:06 | funman | i use 5.2 |
| 03:17:14 | * | [7] uses 6.1 these days |
| 03:23:25 | pamaury | [7]: this is looking good, I now have a much more solid understanding of that thing |
| 03:41:06 | | Join Scr0mple [0] (~Simon@161.43.73.67) |
| 03:41:32 | [7] | now what kind of awards should we give that bootrom? |
| 03:42:58 | pamaury | there are so many we couldn't count them |
| 03:43:02 | funman | [7]: 0x80012C40 sets MCI_CTRL |= INT_ENABLE and MCI_PWREN = 1<<1 |
| 03:43:30 | | Quit Scromple (Ping timeout: 260 seconds) |
| 03:43:34 | funman | 0x12ca4 : writes MCI_CTRL 0x12ca8 : writes MCI_PWREN |
| 03:44:11 | funman | the code is not identical to my disassembly of clipv2 OF though |
| 03:45:04 | * | funman gone |
| 03:45:22 | * | [7] as well |
| 03:47:48 | * | pamaury too will go to bed |
| 03:57:58 | | Quit Marex (Ping timeout: 260 seconds) |
| 03:57:58 | | Quit uwe_mobile (Ping timeout: 260 seconds) |
| 03:58:14 | pamaury | [7]: funman: I found all the scsi requests of the bootrom. As far as I can tell it has the same one as our stack + verify 10 and format unit (might be useful). And it is possible that it has an additional 3 vendor specific commands at 0xD0, 0xD1 and 0xD2 (still unsure, need more disassembly) |
| 03:58:26 | | Join uwe_mobile [0] (~uwe@static.88-198-8-117.clients.your-server.de) |
| 03:58:30 | | Join Marex [0] (~Marex@195.140.253.167) |
| 04:00 |
| 04:01:48 | | Join ungali [0] (~yaaic@184.64.50.234) |
| 04:05:50 | saratoga | very neat |
| 04:09:02 | | Quit pamaury (Ping timeout: 240 seconds) |
| 04:09:23 | | Quit olspookishmagus (Quit: All for nothing) |
| 04:15:51 | | Quit amiconn (Disconnected by services) |
| 04:15:52 | | Quit pixelma (Disconnected by services) |
| 04:15:52 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:15:52 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:15:54 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:15:57 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:23:34 | *** | Saving seen data "./dancer.seen" |
| 04:56:21 | | Join Strife89 [0] (~Strife89@adsl-98-80-218-76.mcn.bellsouth.net) |
| 05:00 |
| 05:00:19 | | Nick plop is now known as gurgle (~0x56@sillytitties.com) |
| 05:00:29 | | Nick gurgle is now known as fizz (~0x56@sillytitties.com) |
| 05:00:38 | | Nick fizz is now known as BOOM (~0x56@sillytitties.com) |
| 05:00:43 | | Nick BOOM is now known as x56 (~0x56@sillytitties.com) |
| 05:00:43 | DBUG | Enqueued KICK x56 |
| 05:03:57 | | Quit Strife89 (Ping timeout: 276 seconds) |
| 05:16:52 | | Join Strife89 [0] (~Strife89@adsl-98-80-223-207.mcn.bellsouth.net) |
| 05:37:37 | | Quit [7] (Disconnected by services) |
| 05:37:46 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:00 |
| 06:00:51 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 06:00:51 | * | [Saint] applauds the work done here last night |
| 06:01:10 | [Saint] | You awesome bastards. |
| 06:01:22 | [Saint] | The scrollback was a highly interesting read. |
| 06:15:03 | saratoga | the AS3525 datasheet does mention a USB firmware update mode if the main storage can't be read |
| 06:16:13 | [Saint] | so, if I read correctly - assuming the hardware is good, we can now breath some life back into these bricked devices? |
| 06:16:22 | saratoga | no idea |
| 06:16:36 | saratoga | perhaps that is the USB people see when the NAND is shorted |
| 06:17:35 | [Saint] | well, from what I read, that magnificent bastard managed to get a Clip booting from the sdcard from the "4MB" state. |
| 06:17:54 | saratoga | yeah but with JTAG |
| 06:18:01 | saratoga | so unless you're going to do a lot of difficult soldering |
| 06:18:11 | saratoga | a better solution would be nice |
| 06:19:15 | * | [Saint] often forgets that Johnny Normal will flinch at hand soldering JTAg and almost certainly don't have a wiggler lying around. |
| 06:22:36 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 06:23:37 | *** | Saving seen data "./dancer.seen" |
| 06:37:36 | | Quit ungali (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org) |
| 07:00 |
| 07:05:25 | [Saint] | I just tried out http://forums.rockbox.org/index.php/topic,43307.msg220177.html#msg220177 |
| 07:05:40 | | Quit sakax (Quit: Leaving) |
| 07:06:07 | [Saint] | and there is indeed a rather audible click/thump |
| 07:14:27 | | Quit saratoga (Quit: Page closed) |
| 07:29:15 | | Join sciopath [0] (~sciop@yer91-2-82-237-54-159.fbx.proxad.net) |
| 07:30:33 | copper | I can't solder |
| 07:31:00 | copper | I don't understand how I'm supposed to make a teeny tiny soldering job with a big fat iron… thingy |
| 07:31:15 | copper | eh, soldering iron |
| 07:31:32 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 07:31:46 | copper | I flunked the soldering class at school |
| 07:44:36 | | Join saratoga [0] (123e1c0a@gateway/web/freenode/ip.18.62.28.10) |
| 07:45:44 | saratoga | copper: use a sharp soldering iron, use flux, heat the parts you want to solder, then touch the solder to the fluxed surface, it'll be sucked up and coat the flux. |
| 07:47:19 | [Saint] | for the really fine stuff, I use a heat torch. |
| 07:49:32 | copper | also, unless you have a big house in the 'burbs or whatever, I suspect most people living in appartments don't have a soldering iron with a workspace for doing that sort of thing |
| 07:49:58 | [Saint] | uhhhh. |
| 07:50:52 | saratoga | well i have an entire laboratory for this kind of thing but it only takes a square foot or two of table space to solder |
| 07:51:23 | copper | Are you an electrical engineer? |
| 07:51:29 | saratoga | yeah |
| 07:51:32 | copper | figures |
| 07:51:40 | copper | :) |
| 07:51:47 | [Saint] | I often solder at my desk, I just shift the laptop off. |
| 07:52:08 | [Saint] | it requires only as much space as whatever you're working on, really. |
| 07:58:48 | | Quit saratoga (Ping timeout: 250 seconds) |
| 08:00 |
| 08:07:43 | | Join WeDOS [0] (~vieras@a91-152-141-222.elisa-laajakaista.fi) |
| 08:07:44 | WeDOS | hiya! |
| 08:08:38 | WeDOS | anyone alive? |
| 08:09:04 | WeDOS | i was wondering can i put my iPod Classic 160GB into diagnostics mode somehow? i'm using freemyipod to boot Rockbox. |
| 08:09:16 | WeDOS | i have bad blocks on the harddisk :/ |
| 08:09:27 | WeDOS | http://www.methodshop.com/gadgets/ipodsupport/diagnosticmode/index.shtml |
| 08:09:42 | WeDOS | i was wondering about something like that... after freemyipod i can't use "normal" firmware. |
| 08:09:59 | WeDOS | but can i use Linux or Windows to format the drive and do read/write test to map the bad blocks? |
| 08:10:07 | [Saint] | No, you can not. |
| 08:10:15 | [Saint] | re: diagmode. |
| 08:10:31 | [Saint] | You can certainly use a host OS to do so, though. |
| 08:11:01 | WeDOS | ok |
| 08:11:14 | WeDOS | Linux has atleast command called bad blocks |
| 08:11:27 | WeDOS | is it possible (easy?) to exchange iPod Classic HD? |
| 08:11:38 | WeDOS | i just love the hardware with Rockbox |
| 08:11:42 | [Saint] | Possible? Yes. Easy? No. |
| 08:12:12 | [Saint] | It is rather non-trivial to disassemble the Classics. |
| 08:12:13 | WeDOS | i wonder what Apple seller would say if i would return it to repairs? |
| 08:12:36 | WeDOS | what do you mean? |
| 08:12:38 | [Saint] | This is the 6G "fat" one, yes? |
| 08:12:43 | WeDOS | yeah |
| 08:13:16 | [Saint] | Yeah, those are known to crap their discs out I believe. |
| 08:13:19 | WeDOS | i was also wondering that if i'll buy a new MP3 player are there any recommendations for durable MP3 player i can use Rockbox with? |
| 08:13:30 | WeDOS | [Saint]: i've also understood so... |
| 08:13:43 | [Saint] | Regarding what I mean, it isn't particularly easy to disassemble the Classic series. |
| 08:13:48 | WeDOS | ok... |
| 08:14:02 | WeDOS | i wonder what new drives cost and what kinda drives they are? |
| 08:14:09 | [Saint] | The older (non-Nano/Touch) iPods are very easy to service. |
| 08:14:12 | WeDOS | maybe i just better buy a new player |
| 08:14:15 | [Saint] | The Classics, not so much. |
| 08:14:20 | [Saint] | But its still possible. |
| 08:14:28 | WeDOS | [Saint]: everything is possible :) |
| 08:14:36 | [Saint] | ifixit has very nice teardown instructions. |
| 08:14:47 | WeDOS | any recommendations for a new MP3 player? |
| 08:15:06 | [Saint] | Depends on your requirements. |
| 08:15:12 | WeDOS | largeish HD |
| 08:15:17 | [Saint] | I happen to think the player you have is one of the best on offer. |
| 08:15:24 | WeDOS | 32GB would probably be enough |
| 08:15:27 | [Saint] | I also have several. |
| 08:15:32 | [Saint] | They're great. |
| 08:16:11 | [Saint] | If 32GB is enough, you might want to look at the Clip+/Clip Zip or possible Fuse+ |
| 08:16:25 | [Saint] | *possibly |
| 08:16:46 | [Saint] | But, personally, I'd rather keep the Classic. :) |
| 08:16:57 | [Saint] | Put an mSATA SSD in there. :) |
| 08:18:38 | [Saint] | I have one with a 64GB SSD, and the (rather large at 850mAh) battery in the "fat" Classic lasts forever. |
| 08:19:04 | [Saint] | I'd like to put a larger disc in, but, cost. |
| 08:19:43 | [Saint] | (even though I could get at least double the capacity now for what I payed for it then...) |
| 08:21:30 | WeDOS | how much is 64GB SSD disc about? |
| 08:21:44 | WeDOS | largeish HD |
| 08:22:04 | WeDOS | dunno if Clip+/Clip Zip or Fuse are available in Finland |
| 08:23:13 | copper | [Saint]: why did you assume he has the "fat" iPod? |
| 08:23:14 | [Saint] | I payed around $300NZD at the time, a long while ago, they're less than half that now. |
| 08:23:28 | copper | the fat one is the older one |
| 08:23:30 | [Saint] | copper: 160Gb and disc trouble. :) |
| 08:23:39 | *** | Saving seen data "./dancer.seen" |
| 08:23:42 | copper | I have 160GB and it's the thin one |
| 08:24:09 | [Saint] | 160GB+disc issues==fat Classic is a pretty good guess. |
| 08:24:18 | copper | okay |
| 08:28:37 | WeDOS | ok.. |
| 08:28:51 | WeDOS | but how do i reformat the player with badblock mapping enabled? |
| 08:28:57 | WeDOS | mkfs.vfat on linux? |
| 08:29:00 | copper | WeDOS: I'm very happy with my Fuze+ and a fast 64GB microsdxc card |
| 08:29:09 | WeDOS | there's also program called badblocks |
| 08:29:51 | copper | WeDOS: mkfs.vat -l: "Read the bad blocks list from filename" |
| 08:30:14 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 08:30:28 | copper | and I guess "badblocks -o filename" |
| 08:35:19 | WeDOS | ok |
| 08:36:35 | [Saint] | latter before the former. |
| 08:39:34 | | Quit WeDOS (Ping timeout: 245 seconds) |
| 08:39:52 | | Join WeDOS [0] (~vieras@a91-152-141-222.elisa-laajakaista.fi) |
| 08:48:11 | WeDOS | [Saint]: so i should just run Rockbox and map the badblocks? |
| 08:48:20 | WeDOS | and mount it normally or in some DFU mode or sumthing? |
| 08:48:56 | [Saint] | DFU mode won't help here, no. |
| 08:49:43 | WeDOS | ok |
| 08:49:49 | WeDOS | so just normal Rockbox mode |
| 08:49:59 | WeDOS | iPod is seen in Linux as mass storage |
| 08:50:11 | WeDOS | i'll check if mkfs.vfat has badblock scan ability |
| 08:50:27 | WeDOS | not that familiar with little weirder commandline options |
| 08:52:43 | WeDOS | https://wiki.archlinux.org/index.php/Badblocks |
| 08:52:44 | WeDOS | has some info |
| 08:53:04 | [Saint] | badblocks -b block_size -o output_file /path/to/device && mkfs.vfat -l output_file_from_badblocks /path/to/device |
| 08:53:09 | [Saint] | should suffice. |
| 08:54:15 | [Saint] | though I believe you can do "mkfs.vfat -c" to do essentially the same thing. |
| 08:54:15 | WeDOS | For comfortably passing badblocks error output to the filesystem it has to be written to a file. |
| 08:54:18 | WeDOS | # badblocks -wsv -o /root/<badblocks.txt> /dev/<device> |
| 08:56:19 | [Saint] | you do NOT want -w |
| 08:56:30 | [Saint] | ...unless you don;t care about the data on the device. |
| 08:56:52 | | Join DexterLB [0] (~dex@79.100.5.0) |
| 08:56:55 | [Saint] | I'm assuming you don't, but, in case you need to backup - do that first. |
| 08:57:26 | WeDOS | i've done it already |
| 08:58:15 | [Saint] | that's cool. -w isn't safe if you want to keep data, just checking. :) |
| 08:58:32 | [Saint] | -n is used in that instance. |
| 08:59:05 | WeDOS | ok |
| 08:59:19 | WeDOS | how about i should target it directly to /dev/sdb |
| 09:00 |
| 09:01:54 | WeDOS | ofcourse :) |
| 09:01:55 | WeDOS | well |
| 09:01:58 | WeDOS | it's running now |
| 09:02:03 | WeDOS | i guess it'll take a LONG time |
| 09:03:08 | [Saint] | it will, yes. |
| 09:04:20 | | Join LinusN [0] (linus@giant.haxx.se) |
| 09:05:17 | WeDOS | ok |
| 09:05:19 | WeDOS | 1% done |
| 09:05:24 | WeDOS | 3min 49sec gone |
| 09:05:47 | WeDOS | so under 400minutes |
| 09:05:52 | WeDOS | hopefully :) |
| 09:06:17 | [Saint] | it doesn't quite work that way. Some blocks will require multiple passes. |
| 09:16:30 | WeDOS | already 4,46% and 14min |
| 09:16:32 | WeDOS | approx |
| 09:16:43 | WeDOS | i really like this player though |
| 09:16:53 | | Quit DexterLB (Quit: So long and thanks for all the fish) |
| 09:16:54 | WeDOS | so i should probably get someone to replace the drive with SSD |
| 09:18:24 | WeDOS | why there isn't bad block mapping built in for Rockbox? |
| 09:18:29 | WeDOS | like format with -c |
| 09:19:06 | | Join Guest97565 [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 09:20:43 | [Saint] | because a host is much better suited for this. |
| 09:22:03 | [Saint] | There's nothing against anyone making a disc scan plugin, but there's no desire to have this functionality in-core. |
| 09:22:53 | [Saint] | http://www.rockbox.org/wiki/DoItRight |
| 09:24:01 | | Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) |
| 09:24:08 | | Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) |
| 09:27:17 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 09:33:01 | | Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) |
| 09:35:18 | WeDOS | mkfs.vfat -l badblocks.txt /dev/sdb |
| 09:35:25 | WeDOS | should do the filesystem after the check |
| 09:52:06 | | Quit froggyman (Ping timeout: 264 seconds) |
| 09:53:26 | | Join froggyman [0] (~froggyman@c58-107-240-32.mirnd3.nsw.optusnet.com.au) |
| 09:53:31 | | Quit froggyman (Changing host) |
| 09:53:31 | | Join froggyman [0] (~froggyman@unaffiliated/froggyman) |
| 09:55:14 | | Join wodz [0] (~wodz@89-75-41-78.dynamic.chello.pl) |
| 09:58:26 | wodz | pamaury: (log) in hwstub whats the usage of usb_drv_configure_endpoint()? I thought the stub uses ctrl transfers only but it tries to setup bulk and interrupt endpoints |
| 10:00 |
| 10:02:26 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 10:11:15 | | Quit AlexP (Ping timeout: 264 seconds) |
| 10:21:05 | wodz | pamaury: (log) I cannot make rk27xx enumerate with hwstub. I get device descriptor read/64, error -110 in dmesg. Any hints? |
| 10:23:43 | *** | Saving seen data "./dancer.seen" |
| 10:33:47 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 10:49:41 | | Quit wodz (Quit: Leaving) |
| 10:50:04 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 10:55:49 | | Quit WeDOS (Ping timeout: 240 seconds) |
| 10:56:26 | | Join WeDOS [0] (~vieras@a91-152-141-222.elisa-laajakaista.fi) |
| 11:00 |
| 11:13:59 | * | bertrik is reading the backlog regarding last nights experiments with the AMS 4MB "bricked" mode |
| 11:14:22 | [Saint] | very interesting indeed. |
| 11:21:15 | | Quit [Saint] (Remote host closed the connection) |
| 11:22:21 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 11:36:52 | TheSeven | copper: I used a $10 12V 7W mini soldering iron for this |
| 11:38:12 | TheSeven | hm, ipod classic diagmode is another thing we should take care of |
| 11:38:44 | TheSeven | and a read/write test won't behave well on broken ipod drives |
| 11:39:07 | TheSeven | there's a reason I've wrote hddscan2, and it's mainly buggy firmware |
| 11:39:43 | | Quit WeDOS (Ping timeout: 246 seconds) |
| 11:42:00 | TheSeven | and i think rockbox locks up on the classic when it hits a bad block? |
| 11:42:03 | mortalis | wodz: pamaury: HID doesn't have any an influence for me. Sometimes transfer fails right after connect, and I'm not able to run tests. Few times transfer of 1G was successful, but usually it's not. |
| 12:00 |
| 12:03:49 | | Quit thegeek_ (Ping timeout: 264 seconds) |
| 12:11:19 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 12:21:37 | | Join Dexter_LB [0] (~dex@79.100.5.0) |
| 12:22:02 | | Quit Dexter_LB (Client Quit) |
| 12:22:13 | | Join DexterLB [0] (~dex@79.100.5.0) |
| 12:23:46 | *** | Saving seen data "./dancer.seen" |
| 12:34:32 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 12:36:50 | | Quit [Saint] (Remote host closed the connection) |
| 12:37:57 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 12:38:29 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 12:38:53 | pamaury | wodz: usb_drv_configure_endpoints is probably a leftover from rockbox |
| 12:39:25 | pamaury | TheSeven: I found all the callbacks for scsi transfers in the bootrom |
| 12:39:39 | pamaury | maybe the format_unit could help |
| 12:39:55 | TheSeven | did you find the REAL callbacks or just these wrappers of wrappers of wrappers? |
| 12:41:02 | TheSeven | there's this weird function at 80C8 which seems to somehow defer a SCSI command, but I haven't figured out where this actually ends up yet |
| 12:41:32 | pamaury | Don't know yet, we'll see |
| 12:42:50 | pamaury | did you last my last comment after you left ? |
| 12:42:53 | pamaury | *see |
| 12:43:01 | TheSeven | I have a feeling that 9734 might be the one who picks up these deferred commands, but it does so many indirect calls that I couldn't really figure out |
| 12:43:40 | TheSeven | yes, I saw that |
| 12:43:52 | TheSeven | I'm wondering why these handlers are being registered in a different place though |
| 12:44:43 | pamaury | oh, the callback stack of the read_10 handler only has 4 functions I don't know about ^^ could be worse |
| 12:44:53 | funman | TheSeven: btw could you write data on the usb interface of this 4MB mode, and try to find where it landed in RAM? |
| 12:44:57 | pamaury | I have no idea what are the parameters though |
| 12:44:57 | funman | or IRAM |
| 12:45:10 | TheSeven | hm, they're registered not too far apart actually... |
| 12:46:56 | pamaury | TheSeven: you can have a look, at 0x8000B290 that's the READ(10) handler |
| 12:48:37 | wodz | pamaury: what about descriptor read/64, error -110, where to start looking? |
| 12:49:13 | TheSeven | wodz: I'm spotting some data that I wrote at 0x810ec8be |
| 12:49:34 | pamaury | wodz: broken control transfer, could be anything. I should really have a go with the usb analyser |
| 12:49:34 | TheSeven | er, 0x810ec8c0 |
| 12:49:44 | wodz | TheSeven: this is not message for me most probably |
| 12:50:14 | TheSeven | 0x810ec6c0-0x810ecbbf actually |
| 12:50:24 | TheSeven | er, funman: ^ |
| 12:51:25 | TheSeven | wodz: your message typically means "device didn't respond at all to the very first request, kept sending NAK for several seconds" |
| 12:51:48 | TheSeven | so it might actually mean that your USB stack didn't receive the request in the first place |
| 12:52:28 | wodz | ok, gonna setup backligh so I will have minimal feedback |
| 12:52:48 | TheSeven | pamaury: that function is just such a "defer this scsi command" thing |
| 12:53:17 | TheSeven | pamaury: all of those call 80c8 somewhere with the command number, which writes it at offset 0x10 in some structure |
| 12:54:16 | TheSeven | they also load another handler address and store it at offset 0 in that structure/object |
| 12:54:48 | TheSeven | there's a handler for each command, but they're 100% identical, duplicated code |
| 12:55:11 | TheSeven | they all call 9734 and then possibly free up some object |
| 12:55:28 | TheSeven | and I haven't managed to track down what 9734 does yet |
| 12:56:09 | * | TheSeven wonders how pamaury keeps analyzing this weird code so quickly |
| 12:57:34 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 12:59:00 | pamaury | I think I need to analyse more of the usb core driver, currently I haven't figured out where the transfer functions are |
| 12:59:17 | pamaury | I *only* have the generic usb part |
| 12:59:42 | | Quit fs-bluebot (Ping timeout: 245 seconds) |
| 12:59:48 | TheSeven | the functions which check the CBW signature and write the CSW signature are easy to locate |
| 13:00 |
| 13:00:43 | | Quit bluebrother^ (Ping timeout: 260 seconds) |
| 13:00:59 | | Join fs-bluebot [0] (~fs-bluebo@g224239255.adsl.alicedsl.de) |
| 13:02:09 | TheSeven | pamaury: I'm fairly certain that the call at F752 ends up sending a bulk packet. but I have no idea how you manage to track those calls :) |
| 13:02:42 | pamaury | TheSeven: out of curiosity could you try to reformat your unit using the sg_* tools (ie send FORMAT_UNIT) ? |
| 13:02:54 | pamaury | sg_format <dev> I think |
| 13:03:39 | TheSeven | not yet |
| 13:03:43 | TheSeven | let me try |
| 13:05:54 | TheSeven | hm, sg_format sends an inquiry first that the device doesn't understand |
| 13:06:22 | TheSeven | "mode_page 1 not supported?" |
| 13:06:30 | pamaury | damn, can you send a raw SCSI command ? |
| 13:06:35 | TheSeven | probably |
| 13:08:12 | bertrik | so, the 4MB mode allows access to IRAM, right? To be useful as a debug mode, you also need something like "run from address X", could it be that the unidentified 0xD0/D1/D2 commands do that? |
| 13:08:40 | pamaury | sg_raw <dev> 0x4 x 0 0 y |
| 13:08:47 | TheSeven | sudo sg_raw /dev/sdc 04 00 00 00 00 00 gets me a "SCSI status: Good" immediately |
| 13:09:23 | TheSeven | bertrik: so far we haven't identified a way to access a significant portion of IRAM through it. what we spotted looks more like a transfer buffer |
| 13:09:44 | pamaury | good, at least one command which format ! |
| 13:10:01 | pamaury | now can you retry to read the internal storage with rockbox ? |
| 13:12:04 | TheSeven | still ata error -2 |
| 13:14:05 | | Join maruk [0] (~papier@titanium.v6.sdv.fr) |
| 13:14:15 | pamaury | believe or not but I'm beginning to like this bootrom; I mean it's crazy to program it this way, for a rom, but it's elegant and consistent, you can see the pattern of the programmer |
| 13:19:10 | TheSeven | well, IF you can spot one... |
| 13:19:46 | TheSeven | how do you figure out which of those dozens of object pointers being passed around refer to the same thing? |
| 13:21:42 | pamaury | method ^^ I create tons of structures and type each one I spot a new and I slowly give meaning to them. The trick is to identify the constructors |
| 13:24:37 | TheSeven | but how can you track WHICH one of those structs will be passed into a function as the "this" (r0) argument? |
| 13:25:40 | pamaury | for a random function you can, you need to track everything from the constructors, that's the only way |
| 13:25:44 | pamaury | *you can't |
| 13:26:35 | TheSeven | so you have to follow the full control flow between the constructor and the function that the object is passed into. which can get even more funny if that object is stored into another object in between. |
| 13:27:09 | | Quit Strife89 (Ping timeout: 246 seconds) |
| 13:27:22 | pamaury | yes exactly, and this using constructors are called in other constructors, you end up with the big hierarchy of objects lying in each other |
| 13:27:34 | pamaury | *since |
| 13:27:50 | * | TheSeven guesses that pamaury has actually written C++ code before :) |
| 13:27:53 | pamaury | it gets more difficult when you have inheritance |
| 13:29:58 | | Quit bzed (Remote host closed the connection) |
| 13:30:12 | pamaury | You know i've disassembled all the weird models of microsoft like COM which make C++ look like it's super easy at times ^^ |
| 13:30:22 | | Join bzed [0] (~bzed@devel.recluse.de) |
| 13:36:51 | funman | TheSeven: 5 * 256bytes buffer? |
| 13:39:07 | pamaury | ah, nightmarish code: intf_desc->config_desc->dev_desc->obj->string_manager->do() |
| 13:40:42 | funman | polymorph boot rom? :) |
| 13:40:52 | funman | code doesn't need to be encrypted to be undecipherable! |
| 14:00 |
| 14:05:49 | | Join thegeek [0] (~thegeek@60.36.34.95.customer.cdi.no) |
| 14:23:50 | *** | Saving seen data "./dancer.seen" |
| 14:35:10 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 15:00 |
| 15:40:52 | | Quit Zarggg (Quit: Zarggg) |
| 15:53:41 | TheSeven | pamaury: I've tried to track down where it parses the scsi requests |
| 15:54:07 | TheSeven | there is this function which is registered as a handler to the various commands which stores the command number somewhere |
| 15:54:28 | TheSeven | that number is read back only in two code locations |
| 15:54:49 | TheSeven | both just use it to determine the size of the command, and don't use the command value themselves |
| 15:54:58 | TheSeven | so I must be missing something somewhere |
| 15:57:04 | | Quit shamus (Read error: Connection reset by peer) |
| 15:57:26 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
| 15:58:05 | | Quit Guest97565 (Ping timeout: 264 seconds) |
| 15:59:45 | funman | are there no calls/access to IRAM? |
| 16:00 |
| 16:02:22 | | Join Guest97565 [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 16:04:46 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
| 16:06:36 | pamaury | TheSeven: can't help you, currently I'm lost in the high level objects of the usb driver |
| 16:10:29 | amayer | tripper: ping |
| 16:23:53 | *** | Saving seen data "./dancer.seen" |
| 16:37:54 | | Quit [Saint] (Read error: Connection reset by peer) |
| 16:39:01 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 16:49:21 | TheSeven | pamaury: that function which registers all of those scsi handlers, could it be that this one is being run for every single request, timer IRQ or something else? |
| 16:49:41 | TheSeven | my debugger says they're re-registered dozens of times per second |
| 16:50:46 | pamaury | I cannot currently, the suggest this is cached |
| 16:50:57 | pamaury | *cannot tell *the code |
| 16:56:36 | TheSeven | pamaury: can you send me your current IDB? |
| 16:57:43 | pamaury | yes |
| 16:58:17 | pamaury | I fear it won't be terribly using at this point |
| 16:58:48 | pamaury | TheSeven: https://www.dropbox.com/s/d94hfsoqtymy5fh/clipplus_internalrom.idb |
| 16:58:58 | TheSeven | we really need an open source IDA + collabREate :) |
| 16:59:12 | pamaury | yes, definitely |
| 16:59:38 | pamaury | but writing ida from scrath...well that's a massive task |
| 17:00 |
| 17:04:06 | TheSeven | I wonder what happened to the EDA project |
| 17:04:54 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:05:43 | wodz | what I would really like to see is a mix of ida and emulator |
| 17:06:13 | wodz | its f*** frustrating to track all regs changes by hand |
| 17:06:33 | TheSeven | well IDA + JTAG kinda solves this :) |
| 17:06:42 | wodz | yep |
| 17:07:08 | wodz | rk270x doesn't have JTAG port (or at least that is what doc says) |
| 17:09:19 | TheSeven | hm, last commit on EDA was 4 years ago |
| 17:11:21 | pamaury | the way I see it, you would have to start something, fail to learn what is necessary and restart, probably in loop |
| 17:11:51 | pamaury | building a generic disassembler core is not trivial, depending on where you want to put the logic |
| 17:17:59 | | Part LinusN |
| 17:42:03 | | Quit petur (Quit: Nettalk6 - www.ntalk.de) |
| 17:57:48 | | Quit Scr0mple (Read error: Connection reset by peer) |
| 17:57:55 | | Join Scromple_ [0] (~Simon@161.43.73.67) |
| 18:00 |
| 18:04:27 | | Quit Zagor (Quit: Clint excited) |
| 18:16:21 | | Quit nosa-j (Ping timeout: 256 seconds) |
| 18:19:48 | | Join nosa-j [0] (~m00k@184.76.254.130) |
| 18:23:55 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 18:23:57 | *** | Saving seen data "./dancer.seen" |
| 18:29:06 | | Part maruk |
| 18:33:13 | | Quit gevaerts (Ping timeout: 264 seconds) |
| 18:35:01 | | Quit nosa-j (Ping timeout: 240 seconds) |
| 18:36:19 | | Join nosa-j [0] (~m00k@184.76.254.130) |
| 18:41:29 | | Quit Rower (Quit: Hmmm...) |
| 18:42:06 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 18:43:17 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
| 18:44:45 | TheSeven | damn |
| 18:45:20 | TheSeven | after soldering a jumper to these unbricking pins the jtag interface refuses to work :/ |
| 18:45:28 | TheSeven | I should really have glued that down |
| 18:46:19 | TheSeven | can't spot anything by visual inspection... |
| 18:52:08 | | Quit mortalis (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) |
| 18:54:03 | pamaury | TheSeven: I'm getting closer, I have all classes except one from the way down to endpoint descriptor to the irq handler |
| 18:55:18 | pamaury | time for a break |
| 18:57:20 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 18:59:04 | pamaury | TheSeven: can you recall me which stm32 usb core matches this one and has the doc in the datasheet |
| 18:59:16 | TheSeven | all of the biger ones |
| 18:59:23 | TheSeven | stm32f2/stm32f4 series |
| 18:59:29 | wodz | stm32f2/f4 |
| 18:59:38 | TheSeven | I think even some f1 ones |
| 18:59:43 | TheSeven | but only some :) |
| 19:00 |
| 19:01:21 | pamaury | thanks |
| 19:01:49 | pamaury | oh they have two of them |
| 19:08:02 | * | TheSeven fixed the jtag |
| 19:10:05 | TheSeven | FYI: shorting the nand pins results in ata error -2 as well |
| 19:10:25 | TheSeven | ...and still a 4MB drive |
| 19:10:45 | TheSeven | so either these pins aren't connected properly, or we have a different problem here |
| 19:10:46 | bertrik | TheSeven: you load the bootloader over jtag? |
| 19:10:54 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
| 19:10:54 | | Quit n1s (Changing host) |
| 19:10:54 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 19:11:24 | TheSeven | yes |
| 19:14:20 | TheSeven | the pins that I short (as indicated on the SansaAMSUnbrick page) read 2.7V if non-shorted, and have a short current of about 50µA |
| 19:14:46 | TheSeven | hm wait, this will probably need a full power cycle and not just a jtag reset |
| 19:15:56 | TheSeven | hm nope, behaves the same way |
| 19:16:00 | TheSeven | no response to that jumper at all |
| 19:16:07 | | Quit wodz (Quit: Leaving) |
| 19:16:15 | | Join saratoga [0] (123e1c0a@gateway/web/freenode/ip.18.62.28.10) |
| 19:16:55 | saratoga | you're trying to branch into that 32 MB disk code? |
| 19:18:51 | TheSeven | well I'm trying to figure out what's up with the sd controller in the first place |
| 19:19:46 | pamaury | TheSeven: I'm confused by your register map in your repo, it seems that there is a shift in the device registers |
| 19:19:59 | pamaury | dinep1msk is after deachmsk |
| 19:20:06 | pamaury | but in the doc there is a gap :-/ |
| 19:21:30 | TheSeven | hm |
| 19:23:15 | saratoga | FWIW, the datasheet has a flow chart for entering USB prom mode, it depends on a GPIO, so if sandisk didn't change i guess the check for the gpio pin state might still be there |
| 19:23:36 | TheSeven | pamaury: my code seems to match the stm32 doc |
| 19:24:14 | TheSeven | deachmsk is 0x83c, dinep1msk is 0x840 |
| 19:24:49 | TheSeven | (in the document they're called OTG_HS_DEACHINTMSK and OTG_HS_DIEPEACHMSK1) |
| 19:25:06 | pamaury | TheSeven: in the STM32F205xx datasheet, OTG_HS_DIEPEACHMSK1 0x844 |
| 19:25:31 | TheSeven | that regs.h file is in fact a parsed and recreated version of a header from the stm32 demo code, so I guess it's right |
| 19:25:47 | | Quit saratoga (Quit: Page closed) |
| 19:25:53 | TheSeven | funny |
| 19:26:00 | TheSeven | so I guess one of the datasheets is off |
| 19:27:02 | TheSeven | and the OTG_FS core doesn't list those regs at all |
| 19:27:33 | pamaury | hum, same error in STM32F4 datasheet, probably the same synopsys doc though |
| 19:30:45 | TheSeven | hm... does someone know what that "nand unbrick" jumper is actually connected to? |
| 19:30:58 | TheSeven | it shows a constant voltage for me |
| 19:33:01 | TheSeven | nothing but the initial ramp up during powerup, nothing during rockbox boot, ... |
| 19:33:11 | TheSeven | toasted sd controller? |
| 19:34:15 | TheSeven | the sd controller is inside the soc, right? |
| 19:34:19 | pamaury | yes |
| 19:38:13 | | Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) |
| 19:38:45 | bertrik | TheSeven: the as3525 datasheet does also mention some kind of boot selection pins |
| 19:39:25 | pamaury | TheSeven: actually you are right, the descriptors might be created on every irq |
| 19:39:42 | bertrik | among them is pin B4 I think, I'll look it up |
| 19:42:36 | TheSeven | hm, the read enable pin of the flash toggles during boot |
| 19:42:51 | bertrik | from the datasheet "The update button is located between xpa[4] and xpa[0]." where xpa is the same as GPIO port A |
| 19:43:23 | bertrik | but that is from the as3525 datasheet or "AMSv1", while the clip+ is an "AMSv2" |
| 19:45:55 | TheSeven | bertrik: so you think that this jumper actually tells the soc to boot something else? |
| 19:46:04 | TheSeven | I thought it just shorted some nand pins? |
| 19:46:27 | bertrik | I'm not sure |
| 19:46:55 | bertrik | someone documented on our wiki that GPIO B4 is the "unbrick pad" |
| 19:46:59 | bertrik | for the clip+ |
| 19:49:21 | bertrik | MichaelChicoine did it in revision 73 of http://www.rockbox.org/wiki/SansaAMSHardwareMappings |
| 19:51:37 | | Join nkf [0] (djao@efnet.math.uwaterloo.ca) |
| 19:52:15 | | Quit Galois (Disconnected by services) |
| 19:52:16 | | Nick nkf is now known as Galois (djao@efnet.math.uwaterloo.ca) |
| 19:52:52 | | Join wodz [0] (~wodz@89-75-41-78.dynamic.chello.pl) |
| 19:55:38 | TheSeven | hm... no way of soldering directly to the flash chip, that won't work |
| 19:58:01 | wodz | TheSeven: TSSOP54 package? With 0.5mm pitch it is possible to solder very fine kynar wire. I did it once. |
| 19:58:28 | TheSeven | not with my tools |
| 19:58:36 | TheSeven | I didn't get solder to stick to the flash pins *at all* |
| 19:58:50 | wodz | use more aggressive flux then |
| 19:59:12 | TheSeven | then it'll short out all over the place |
| 19:59:34 | TheSeven | no way to get that done with my tools, I'd rather leave that thing undamaged |
| 19:59:58 | wodz | safer for sure |
| 20:00 |
| 20:04:25 | wodz | TheSeven: Are you running IDA in wine, in vm or natively on windows? |
| 20:04:37 | TheSeven | vm |
| 20:05:14 | TheSeven | oh noes, a JTAG pin broke loose again :/ |
| 20:06:32 | TheSeven | gpioa = 0x20, gpiob = 0xc4 |
| 20:09:52 | TheSeven | wtf, ever had the screen show upside down on a clip+? |
| 20:10:19 | pamaury | lol ^^ |
| 20:10:31 | pamaury | there might be a setting for that |
| 20:10:44 | TheSeven | guess I just broke the ribbon cable :/ |
| 20:11:00 | | Quit GodEater (Quit: Coyote finally caught me) |
| 20:11:08 | wodz | TheSeven: |
| 20:11:11 | wodz | err |
| 20:11:55 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 20:12:44 | TheSeven | indeed, that recovery pin toggles GPIO B4 |
| 20:13:48 | pamaury | haha, reverse enginerring can be cool some times: |
| 20:13:49 | pamaury | int __cdecl usb_truc__ctor(usb_truc_t *this, usb_thing_t *thing, void **otg_base_ptr, usb_obj_t *obj) |
| 20:14:37 | | Quit GodEater (Changing host) |
| 20:14:37 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 20:14:46 | | Quit nosa-j (Read error: No route to host) |
| 20:16:32 | bertrik | TheSeven: great to have that confirmed |
| 20:17:06 | pamaury | can someone explain what is about this pin ? |
| 20:17:12 | * | pamaury has not followed the whole discussion |
| 20:17:47 | * | pamaury is running out of names: truc, thing, obj. What's next ? machin ! |
| 20:17:53 | TheSeven | pamaury: that's what the "unbrick" pin on the PCB seems to be connected to |
| 20:18:25 | | Join saratoga [0] (123e1c0a@gateway/web/freenode/ip.18.62.28.10) |
| 20:19:01 | TheSeven | are there *any* success reports of that pin fixing a 4mb drive clip+? |
| 20:19:02 | saratoga | does the ROM obfuscate its GPIO reads? |
| 20:19:02 | pamaury | so it just switches the boot mode ? |
| 20:19:23 | pamaury | no, there are a few reads in the ROM for the GPIO |
| 20:19:31 | saratoga | TheSeven: AFAIK people have never fixed a clip in the 4MB mode without getting it into 32MB mode, but the latter has been done |
| 20:19:34 | TheSeven | for that particular pin? |
| 20:19:43 | pamaury | GPIO B4 ? let me see |
| 20:19:46 | TheSeven | saratoga: and that was done by means of this pin? |
| 20:20:07 | saratoga | let me check |
| 20:20:18 | pamaury | apparently not, it reads GPIO B5 |
| 20:21:07 | pamaury | and GPIO C[2:1] if I read correctly |
| 20:21:14 | TheSeven | B5 is 0 for me |
| 20:21:30 | TheSeven | C2 and C1 are zero as well |
| 20:23:12 | tripper | amayer: I got the theme to work |
| 20:23:22 | tripper | turns out I had to upgrade to the latest testing build |
| 20:24:00 | *** | Saving seen data "./dancer.seen" |
| 20:24:01 | amayer | tripper: oh you had a problem with the progress bar? |
| 20:24:33 | amayer | I updated how they worked because before they were implemented weird. |
| 20:25:15 | saratoga | this log is long, but someone starts out with a 4MB disk and eventually gets a 32 MB one if I understand correctly: http://www.rockbox.org/irc/log-20111024 |
| 20:27:50 | tripper | amayer: no, the WPS would load fine but the SBS wouldn't load at all |
| 20:28:00 | tripper | then I upgraded to the latest rockbox image and everything was fine |
| 20:28:02 | saratoga | from what people have said in the channel over the years, usually a dead firmware gives you a 4MB partition, shorting that pin gives you a 32 MB or, depending on the player, a 1GB on that is the entire first SD bank |
| 20:28:05 | tripper | ┐('～`；)┌ |
| 20:28:19 | saratoga | that 1GB may be AMSv1 though, not sure |
| 20:29:51 | | Quit GodEater (Quit: Coyote finally caught me) |
| 20:30:00 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 20:30:02 | saratoga | hmm no the logs here indicate that someone got a 1GB disk on a clipv2 which is amsv2: http://www.rockbox.org/wiki/SansaClipV2UnbrickingTutorial |
| 20:30:11 | amayer | tripper: which theme are you talking about? |
| 20:30:36 | | Join GodEater_ [0] (~GodEater@rockbox/staff/GodEater) |
| 20:31:36 | | Quit GodEater (Disconnected by services) |
| 20:31:43 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 20:32:03 | TheSeven | that log suggests that bertrik has already unbricked a clip+? was that ever in a 4MB state? |
| 20:32:25 | tripper | amayer: the hazard twins |
| 20:32:30 | saratoga | i think funman unbricked one as well |
| 20:32:48 | tripper | oh and also I've been working on a modification of hazard light with antialiased fonts and more track information like bitrate and samplerate |
| 20:32:54 | tripper | it looks pretty great |
| 20:33:37 | | Quit GodEater (Disconnected by services) |
| 20:33:44 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 20:33:58 | saratoga | funman said: "If the reported drive is 4MB then you should attempt the unbrick procedure again until you see the correct size, it's very difficult to have the correct drive come at the first attempt, for me it always required between 3 and 10 attempts until it worked." |
| 20:34:13 | | Quit GodEater_ (Client Quit) |
| 20:34:34 | | Join GodEater_ [0] (~GodEater@rockbox/staff/GodEater) |
| 20:34:36 | | Quit GodEater_ (Client Quit) |
| 20:38:12 | | Quit GodEater (Changing host) |
| 20:38:12 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 20:42:30 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
| 20:42:33 | TheSeven | from that IRC log we learn three things: |
| 20:42:33 | TheSeven | - the clipv2 identifies as "m200plus" as well |
| 20:42:33 | TheSeven | - it might come up as a gigabyte drive, which works as well |
| 20:42:33 | DBUG | Enqueued KICK TheSeven |
| 20:42:33 | TheSeven | - shorting nand pins might actually put it into 4MB mode |
| 20:44:43 | copper | That definitely qualifies as "hacking". |
| 20:46:18 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 20:46:23 | | Quit GodEater (Quit: Coyote finally caught me) |
| 20:46:33 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 20:47:49 | TheSeven | what's the matter with that amsv2_variant thing btw? |
| 20:48:42 | amayer | tripper: thats awesome! let me know when they are finished. I would love to see them |
| 20:49:16 | pamaury | TheSeven: ever heard of a register 0xa0003c0a in this synopsys otg ? |
| 20:49:35 | TheSeven | so base + 3c0a? |
| 20:50:41 | tripper | So is there development work being done on the rockbox utility and bootloader to support the Classic? |
| 20:51:00 | | Quit Zarggg (Read error: Connection reset by peer) |
| 20:51:11 | tripper | emCORE bootloading works absolutely fine but the rockbox port itself is so advanced that it would be a shame to discourage people by listing it as "unusable" |
| 20:53:02 | TheSeven | pamaury: that's somewhere in TX FIFO 2 access area |
| 20:53:39 | | Quit GodEater (Changing host) |
| 20:53:39 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 20:54:06 | TheSeven | tripper: show me a way to install through something other than DFU, and I'll take a look |
| 20:54:11 | pamaury | TheSeven: no base address is 0xc6000000 :-/ |
| 20:54:20 | TheSeven | huh? |
| 20:54:41 | TheSeven | how is 0xa0003c0a related to synopsysotg then? |
| 20:56:26 | pamaury | it builds one structure per usb register used and there is this one among them |
| 20:57:57 | tripper | TheSeven: would it be bad if the rockbox utility asked the user to enter DFU mode? |
| 20:58:07 | tripper | it could give target-specific instructions |
| 20:59:10 | TheSeven | the whole driver mess behind dfu on windows is the problem |
| 21:00 |
| 21:00:38 | | Quit GodEater (Quit: Coyote finally caught me) |
| 21:00:47 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 21:07:18 | pamaury | TheSeven: I have located where the bootrom inits its "registers". It builds one small structure per register with its address and there is this one in the middle , very strange |
| 21:18:08 | | Quit ender` (Ping timeout: 264 seconds) |
| 21:23:21 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 21:30:49 | pamaury | TheSeven: what is at otg_base + 0x928 ? |
| 21:31:31 | pamaury | ah no forget about that |
| 21:32:35 | | Quit saratoga (Ping timeout: 250 seconds) |
| 21:33:20 | TheSeven | that's some endpoint reg |
| 21:50:48 | pamaury | TheSeven: what is the content of GHWCFG1 ? |
| 21:51:22 | TheSeven | on the clip+? |
| 21:52:03 | pamaury | no the meaning sorry |
| 21:53:26 | TheSeven | it contains some information about the synthesis parameters, such as available fifo size, available endpoints, ... |
| 21:53:57 | pamaury | ah no wait, arg I'm messing with offsets, there are too many of them |
| 21:54:36 | pamaury | hwcfg4 |
| 21:56:14 | | Quit Rower (Quit: Hmmm...) |
| 21:58:11 | pamaury | numdevmodinend, what's that ? number of in endpoints ? |
| 21:59:43 | tripper | amayer: the most ridiculous part is I'm developing them using entirely the rockbox text editor |
| 21:59:46 | tripper | (´・ω・ˋ) |
| 22:00 |
| 22:00:21 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 22:00:21 | * | pamaury spots someone using the rockbox text editor and is shocked |
| 22:07:34 | | Quit __jae__ (Quit: leaving) |
| 22:13:12 | TheSeven | pamaury: yes, that's a bitmap of present endpoints IIRC |
| 22:13:47 | | Join Strife89 [0] (~Strife89@adsl-068-213-037-174.sip.mcn.bellsouth.net) |
| 22:15:30 | amayer | tripper: that is rediculous! |
| 22:16:41 | | Join __jae__ [0] (~jae@dedicated.jaerhard.com) |
| 22:16:48 | | Quit wodz (Read error: Connection reset by peer) |
| 22:17:43 | pamaury | TheSeven: funman: bertrik: what is at 0x10000000 on amsv2 ? |
| 22:18:07 | TheSeven | no idea |
| 22:18:44 | pamaury | datasheet says "External Memory IF" |
| 22:18:52 | pamaury | (Ext Flash or Ext ROM) |
| 22:22:30 | | Join wodz [0] (~wodz@89-75-41-78.dynamic.chello.pl) |
| 22:24:03 | *** | Saving seen data "./dancer.seen" |
| 22:24:11 | TheSeven | pamaury: FYI, these SCSI handler functions are called from C8F6 |
| 22:24:26 | tripper | imagine bundling a c compiler with rockbox |
| 22:27:12 | wodz | tripper: what for? |
| 22:28:31 | tripper | for laughs |
| 22:28:54 | tripper | the lua interpreter is already there though for writing short little programs in the rockbox text editor if you're up to such torture |
| 22:31:46 | wodz | tripper: there is also my unfinished port of ficl forth kernel on gerrit |
| 22:32:51 | | Quit y4n (Quit: We're fucking 3LN!) |
| 22:33:46 | | Quit kevku (Ping timeout: 260 seconds) |
| 22:41:27 | TheSeven | CDE0 is probably the function that takes care of actually *processing* scsi commands |
| 22:58:13 | | Quit amayer (Quit: Leaving) |
| 23:00 |
| 23:03:18 | | Quit freqmod (Read error: Operation timed out) |
| 23:05:32 | | Quit n1s (Quit: Ex-Chat) |
| 23:06:00 | | Join freqmod [0] (~quassel@cm-84.215.142.108.getinternet.no) |
| 23:07:05 | | Quit Guest97565 (Ping timeout: 264 seconds) |
| 23:17:26 | | Join nosa-j [0] (~m00k@184.76.254.130) |
| 23:22:09 | pamaury | the reversing of the bootrom is now getting hardcore |
| 23:27:50 | | Join Topy44 [0] (~Topy44@93.190.93.215) |
| 23:30:53 | TheSeven | pamaury: I'm tempted to bet that we could have squeezed the same functionality into an 8KB ROM :) |
| 23:31:32 | pamaury | I think so too |
| 23:31:54 | pamaury | interestingly, your "scsi processing" function at CDE0 uses the same "buffer builder" as the descriptor functions |
| 23:32:02 | pamaury | I don't have its complete layout though |
| 23:32:15 | pamaury | I think this bootrom also has a notion of thread |
| 23:32:45 | TheSeven | looks like that function doesn't really process it but instead just copies it into yet another buffer |
| 23:33:02 | TheSeven | yes, it must be multitasked |
| 23:33:38 | TheSeven | this stuff isn't running in IRQ mode, and you know there is this idle loop |
| 23:33:40 | pamaury | I must say I'm kind of lost in the high level structures, there are list and vectors but I don't know of *what* |
| 23:34:15 | pamaury | and I still haven't found the actual usb driver ! |
| 23:34:20 | TheSeven | the "main loop" of the thread that calls the scsi processing stuff seems to be sub_800108f4 |
| 23:34:57 | | Quit Topy44 (Quit: ZNC - http://znc.in) |
| 23:35:26 | pamaury | could be |
| 23:35:30 | pamaury | or could not be ^^ |
| 23:35:51 | TheSeven | well that's a noreturn function that this whole scsi mess returns to |
| 23:36:14 | TheSeven | I've also found some stuff that looks like mutexes |
| 23:36:15 | pamaury | actually this function is in the virtual table of some high level object |
| 23:36:18 | pamaury | make sense |
| 23:36:29 | pamaury | do you have the addresses of these "mutexes" ? |
| 23:36:42 | TheSeven | so it might actually be that the scsi commands are enqueued somewhere and then processed by another thread |
| 23:38:00 | pamaury | I'm trying to understand how the threading works, it uses objects *of course* |
| 23:38:17 | pamaury | I may have found the thread ctor |
| 23:38:21 | TheSeven | some mutex-ish stuff is at 4db8 |
| 23:38:24 | TheSeven | (and its xrefs) |
| 23:39:20 | pamaury | arf, this is a bit too arm-technical for me, do you know what it does exactly ? |
| 23:40:08 | TheSeven | the ORR 0x80 one at the top locks out IRQs and the BICEQ 0x80 one at the bottom reenables them |
| 23:41:30 | TheSeven | and 0b98 switches to supervisor mode (and a different stack) and back to system mode, that looks like some kind of syscall interface wrapper |
| 23:41:42 | funman | saratoga: iirc unbrick works exactly the same for amsv1 and amsv |
| 23:41:43 | funman | saratoga: iirc unbrick works exactly the same for amsv1 and amsv2 |
| 23:41:46 | pamaury | I hope we won't duplicate too much work |
| 23:42:06 | TheSeven | 4408 is executed in supervisor mode |
| 23:42:18 | pamaury | I have noticed that the "thread" seem to be in system mode |
| 23:42:24 | TheSeven | yes, that makes sense |
| 23:42:35 | TheSeven | "system" mode is essentially privileged usermode |
| 23:42:36 | pamaury | this is insane in a bootrom :-X |
| 23:43:14 | | Join Topy44 [0] (~Topy44@93.190.93.215) |
| 23:43:19 | TheSeven | I guess they took some RTOS kernel which they had the USB and mass storage drivers for anyway and plugged it all together |
| 23:44:34 | funman | TheSeven: ams variant is not very interesting, it's just that they handle a few things (like uSD controller selection) differently between the 2 variants |
| 23:44:36 | pamaury | yeah, the architecture is nice actually, just not for a bootrom |
| 23:46:26 | funman | TheSeven: pamaury: http://37.187.19.138/~fun/fw-clipv2.7z : my clipv2 (OF) disassembly |
| 23:46:39 | funman | there might be some identical functions already reversed in it |
| 23:46:39 | pamaury | funman: is that OF or bootrom ? |
| 23:46:53 | funman | pamaury: as is said, OF |
| 23:47:33 | funman | i spent 30 mins on clip+ bootrom yesterday and SD code didn't look identical |
| 23:47:52 | funman | i was disappointed because for AMSv1, bootrom and OF were mostly identical |
| 23:48:22 | funman | well, feel free to use it or not :) |
| 23:48:50 | funman | please disregard the curse words in comments ^_^ |
| 23:49:05 | funman | "@ fuck" means the function and its subfunctions are not "interesting" iirc |
| 23:50:30 | pamaury | damn, that the point where I realise the threading functions are connected to the "wtf" functions I was stuck on |
| 23:55:46 | TheSeven | 95% sure the same RTOS base! |
| 23:56:46 | pamaury | did you reverse anything about thread/mutex/queue/usb ? |
| 23:57:42 | TheSeven | if that was directed to me, I didn't find much interesting stuff yet |
| 23:57:54 | TheSeven | but that OF IDB looks somewhat promising |
icon identifies that the person is a core developer (has commit access).