Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
notlistening:
Hi all,
edit - how annoying double posting :P
Right we have a RTOS of choice found here:
http://www.qnx.com/
I haved looked at this thread regarding booting for qnx, might have a gem or two in there.
http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc2151;jsessionid=16C813ABB6E40BA25830FA684D907695
Sneaky SanDisk
Was a little bored so I gave my e200 a twirl through a few tools. This is what i got.
--- Code: ---TestDisk 6.8, Data Recovery Utility, August 2007
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdd - 4075 MB / 3886 MiB - CHS 1019 126 62
Current partition structure:
Partition Start End Size in sectors
1 * Sys=72 99607 97 11 245730 44 51 1141509631
Bad relative sector.
2 * NetWare 3.11+ 21593 80 47 269421 14 42 1936028240
Bad relative sector.
3 * Sys=79 239360 18 30 487187 77 39 1936028192
Bad relative sector.
4 * Sys=0D 369390 104 25 369397 117 33 55499
Warning: Bad ending sector (CHS and LBA don't match)
Only one partition must be bootable
Next
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
--- End code ---
Interestingly with some digging I found the partition type codes as it thinks they are.
72 V7/x86 - Robert Nordier writes: V7/x86, a port of UNIX Version 7 to the PC, is available at www.nordier.com/v7x86.
0e FAT16 LBA 65 NetWare 3.11+ c6 sec. Huge-bad FAT16
78 QNX POSIX partition (secondary)
0D ? not sure but playing around with the tool some more it indicateds it might be JFS :P Don't shoot the messenger.
Bit more: This can up on further analysis
--- Code: ---The harddisk (4075 MB / 3886 MiB) seems too small! (< 4077 MB / 3889 MiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
D FAT32 0 0 1 1019 68 28 7964672 [##PORT#]
D FAT32 0 0 7 1019 68 34 7964672 [NO NAME]
--- End code ---
When working with the tools i got a lot of this:
--- Code: ---[50417.044276] printk: 375 messages suppressed.
[50417.044283] Buffer I/O error on device sdc7, logical block 786433
--- End code ---
edit - just a little more
--- Code: ---Warning: Incorrect number of heads/cylinder 255 (FAT) != 126 (HD)
Warning: Incorrect number of sectors per track 63 (FAT) != 62 (HD)
FAT32 0 0 1 1019 68 28 7964672 [##PORT#]
Warning: Incorrect number of heads/cylinder 255 (FAT) != 126 (HD)
Warning: Incorrect number of sectors per track 63 (FAT) != 62 (HD)
FAT32 0 0 7 1019 68 34 7964672 [NO NAME]
--- End code ---
I think it was when i specifically got photorec to work on the netware partition, also reset my usb hub and all the devices on it a few times.
During all of these test I found that my e200 went through stages of dieing firstly a few error, then more until it dropped off usb completely.
Hope this helps can shed some light on other models etc.
Tom
fragilematter:
I've modified 0x1FF and 0x3FF to 0xDD and it booted just fine. Then I modified 0x3FF to 0xAB, just for the sake of variety. Again, it starts up and plays with no problems. I guess the headers are checked only on firmware update :)
Now I'll move on to modifying mkamsboot.c so it places code after the OF. Oh, I almost forgot, the OF update file is 15MB in size, so the 0xDEADBEEF padding in the dump probably serves as reserved space, for a maximum of 32MB of firmware.
Edit: OK, scrap what I said earlyer about the reserved space. As I assumed initially, the OF isn't identical to the disk dump. The firmware update process probably moves things around.
The beginning of the dump has a (more or less) "correct" header structure, according to what we observed in the firmware update image.
But, in the dump we have 0xDEADBEEF padding from 0x1CEF400 to 0x1DFFBFB, and then the bytes 31 F9 7E 9D (at 0x1DFFBFC-0x1DFFBFF). These bytes are identical to the last four bytes of the update image, the only difference is that there they're at 0xEFFFFC-0xEFFFFF.
I'm thinking of using an algorithm similar to the one used in rsync to spot the portions common to the update image and the nand dump.
Also, to ease handling, I think it's safe to strip the dump to 31456252 Bytes, after this offset we have some 0 padding and then a FAT:
--- Code: ---0x1DFFC00-0x1DFFFFF 0 padding
0x1E00000 FAT start
0x1E00003 OEM name - MSWIN4.1
0x1E0000D Sectors/cluster - 64
0x1E0000E Reserved sector count - 32
0x1E00010 Number of file allocation tables - 2
0x1E00011 Max number of root directory entries - 0
0x1E00015 Media descriptor - 0xF8 : Hard disk. Single sided, 80 tracks per side, 9 sectors per track
0x1E00016 Sectors per fat - 242
0x1E00018 Sectors per track - 63
0x1E0001A Number of heads - 255
0x1E00026 Extended boot signature - 0x29
0x1E00036 FAT file system type - FAT16
0x1E001FE Boot sector signature - 0x55 0xAA
--- End code ---
Edit2: I've updated http://drop.io/sansahack with the stripped dump and also a delta file I made with rdiff against the update image e200pF.bin v3.01.16F.
So, to get the dump just run
--- Code: ---rdiff patch e200pF.bin OFtoDUMP.delta dump.bin
--- End code ---
atomikpunk:
Ok so to read the GPIO A pin 3 (which could be the hold button in my findings), you will need to use something like this test.S file:
--- Code: ---OrigEntry:
.word 0
/* Enable the GPIO module clock */
LDR R1, =CGU_PERI
LDR R2, [R1]
MOV R0, #0x10000
ORR R2, R2, R0
STR R2, [R1]
/* Be sure GPIOA port is set to all inputs*/
LDR R1, =GPIOA_REG
MOV R2, #0
STR R2, [R1, #0x400]
/* A little delay - not sure it is needed but it doesn't hurt */
loop:
NOP
ADDS R2, R2, #1
CMP R2, #100
BLT loop
/* Read GPIOA pin 3 */
LDRB R2, [R1, #0x20]
/* Check its state */
CMP R2, #0
MOV R0, #0x1
/* Delay only if bit is cleared (arbitrary) */
MOVEQ R0, #0x500000
loop2:
SUBS R0, R0, #1
BNE loop2
/* Jump back and resume! */
LDR PC, OrigEntry
.set CGU_PERI, 0xC80F0014
.set GPIOA_REG, 0xC80B0000
--- End code ---
So the test simply check the state of the GPIOA3 pin and wait or not depending on the state. Don't forget however that the OF itself does different things if the hold button is set or not at the moment the device is booted (display a lock or boot normally). Those who will test it should notice the (quite long, about 5s) delay.
Please review this code and try it on a unbrickable device (like the e200), I suggest that Daniel tries it first since he knows how to unbrick is player, or that he teach others how to do it.
Please post your results here!
fragilematter:
OK, the firmware update went OK. However, it seems the delay is tripped no matter what the state of the hold button is - i.e. about 6 seconds total boot time.
If you want to see for yourself have a look here http://video.google.com/videoplay?docid=1469507032638365055
Edit: weirdly, I get boot times of ~1second if I start the device by plugging the usb connected to a 5v power supply, both with hold on or off. Either GPIOA pin 3 becomes 0 or sansas boot differently when you plug in your cable (less likely)... I'll test this using the unconditional delay (the test.S from SVN).
atomikpunk:
Hmmm ok thanks for the test. In the video, first time is with hold and second is without?
I'll dive again in analysis then :'(
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version