Rockbox Development > New Ports
Sandisk Clip Sport
wzdd:
Wodz, interesting about the mbrec. I'll have a look at what's going on. I can also definitely dump the usb transactions using VMWare, so I'll try to see how the adfu mode works (is there anything on this already?)
I updated the github code to remove the assembly language portion, so it now compiles on non-mips systems. But it's all (semi-)auto-decompiled and pretty horrible at the moment -- cleaning it up is the next step. Fortunately most of it is already implemented in rockbox's atj tools, so only the new stuff needs to be merged.
edit: sm - will do! Or at least try :)
wzdd:
Just a couple of updates ... it turns out that you can run arbitrary code from ADFU mode, which should make hacking this thing somewhat easier. I've pushed a demo to https://github.com/nfd/atj2127decrypt in the dfu directory, but you'll need an ADFUS.BIN file (available from that PD196_ATJ2127 repo) to initialise the hardware. (This probably isn't absolutely required, but the demo is pretty hacked-up and follows the standard ADFU flow, which is: upload ADFUS.BIN (raw mips32r2) which provides a basic OS for the rest, then upload some code to discover hardware information (nandhwsc.bin, also raw mips32r2), which then returns a block of data to the flashing tool -- I've managed to get nandhwsc to return different data to demonstrate that it's actually being run).
You can also issue a vendor-specific SCSI command to go from UDISK (standard block device) mode to ADFU mode, so the demo includes an example to do that as well (you should be able to reboot to UDISK mode from ADFU mode also, but this isn't working yet).
I also fixed mbrec decoding -- I was re-using some of the pd196 code for decrypting firmware blobs and didn't notice that it wouldn't work if the size of the target file was under 32k -- the mbrec now looks like mips32r2 code, so if there is scrambling it happens elsewhere -- wodz if you have some time to look at a decrypted firmware I'd be interested in your thoughts on this)
wodz:
I did a quick look at ADFUS.BIN file. It looks fairly similar to atj213x adfu handler. One thing I found unusuall is that mem mapped registers are accessed through KSEG2 which means that something must have setup MMU earlier. PD196_ATJ2127 register description seems to be accurate. I'll dig up which commands are supported and will report back.
edit: I compared usb core registers with what I know about atj213x usb core and both are the same (or at least very close). Porting hwstub to this platform should be trivial. One would need to write some header file with atj2127 registers addresses and tweak startup code. Interrupt controller (with obvious difference in interrupt source mapping), timer module, WDT are the same as in 213x as well.
edit2: here we go. in [] there are byte numbers as read from usb fifo
--- Code: ---adfu_cmd_handler()
read 32bit, check for 'USBC' 0x43425355 flag [0,1,2,3]
read 12 bytes, store only last [4,5,6,7,8,9,10,11,12,13,14,15]
check stored byte for CMD selector 0xB0, 0xCC or 0xCD
B0 - force reset by entering infinte loop which catches watchdog reset
CC - seems to be NOP
description of CD:
read byte, treate it as subcmd [16]
strip top bit and compare with available subcmds 0x21, 0x13, 0x20, 0x10, 0x22, 0x23, 0x60
bit7 serves as transfer direction indicator 1 - usb IN transfer, 0 - usb OUT transfer
0x20:
read 7 bytes, discard [17,18,19,20,21,22,23]
read 32bit, store in exec_address [24,25,26,27]
execute code from exec_address (jalr)
after exec return to adfus main()
0x21:
read 7 bytes, discard [17,18,19,20,21,22,23]
read 32bit, store as jump address [24, 25, 26, 27]
jalr to received address, the returned value in v0 is stored in cmd22_src_addr
replay with all zeros packet
0x22:
read 3 bytes, discard [17,18,19]
read 32bit, store as transfer len [20,21,22,23]
transfer (IN) memory content as pointed in cmd22_src_addr+4, len
reply with all zeros packet
0x23:
read 3 bytes, discard [17,18,19]
read 32bit, store as transfer len [20,21,22,23]
transfer (IN) memory content as pointed in cmd22_src_addr, len
reply with all zeros packet
0x13:
read 3 bytes, discard [17,18,19]
read 32bit, arg1 (address) [20,21,22,23]
read 32bit, arg0 (len) [24,25,26,27]
transfer 'len' bytes data in direction indicated in dir bit starting at 'address'
reply with all zeros packet
This two do some more fancy stuff. Basically they do some transfers interleaved with calls to 0xbfc1e400 with 4 arguments
where last is buffer address and first some sort of subcommand. At first glance this look like some crypt/scramble stuff with
some repetitive blocks of 0x20, 0x200 and 0x4000 bytes
0x10:
0x60:
--- End code ---
0xcd 0x13 is interesting as it looks like one can read arbitrary memory. It would be interesting to check if dumping memory starting at 0xbfc00000 is possible (ROM)
Cheers
wzdd:
Cool, glad it's similar! I was actually impressed by it -- HW companies aren't known for their software...
I've uploaded the Wireshark-readable packet captures from a DFU session here: http://nyloncactus.com/random/atj2127dfu.tar.gz
For command 0x23, it seems like it actually causes the device to dump memory to the host? What seems to happen is (examining the pcap):
- host writes a binary with command 0x13
- host executes the binary on the device with command 0x21
- host reads a block of memory from the device (length specified in packet)
- device replies with a block of data
This data is from a memory area which is written by the host-uploaded binary. It seems that the flash tool runs something which queries the NAND controller for the NAND ID and some other information, and writes a packet of length 0x9c beginning 'HW' which contains that ID and some other stuff. The host then decides what flash driver to upload based on what comes back. This seems quite nice to me.
wodz:
Thanks for pcap dumps. This seem to match my understanding of ADFUS.BIN disassm.
BTW. The sequence you described in your previous post is not accurate.
The interesting thing to explore is issuing cd93 cmd (cd 0x80|0x13 address len) to get ROM dumpstarting at 0bfc00000
I extracted payload from pcap file to trace this magic 0xbfc1e400 function. I'll report when find something.
edit: I did quick look at this 0xbfc1e400 function and it is rather complicated. What can be said for sure it is some nontrivial wrapper around ROM? functions starting at ~0xbfc20000. All this functions seems to use MIPS16 coding as calls are made through jalx instruction. atj2127 brief mentions about subset of libc provided in ROM. Referenced functions are:
0xbfc205b8, 0xbfc21470, 0xbfc21960, 0xbfc21b88, 0xbfc20740, 0xbfc21920, 0xbfc21308, 0xbfc204c4 and one data ref: 0xbfc24cd0 (with offsets 12, 14, 24)
Maybe you could pop up on IRC so we could have live discussion?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version