SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[atomikpunk]

Hi peeps,

just a little update to show what I'm looking at.

I can now confirm that the "libraries" are effectively dynamically loaded as I suspected. And the code clearly shows the values we also find in the libraries header (load address, variables address, library size, variables size, etc.). This also explains why multiple libraries loading addresses overlap. I can easily be understood because most of the overlapping libraries provides the functionality which can't overlap. For example, the wav codec library is loaded at the same address as the acp decoder library.

I also think that I found the routine where the libraries are loaded but I still can't understand it. This is my next step because it may help understanding the library loading process and eventually evaluate if it is possible to expand the firmware file and how to do it.

From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code... And since we wouldn't have the OF in backup neither... So maybe the next big question is: is it possible to grow an image file bigger than 0x500000 and still be accepted by the firmware loader?

That's about it for the last couple of days.

Any news from JTAG or other findings?

[Bagder]

From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code...

Right. We want (or need) dual-boot ability so we should only insert enough code in there to be able to load Rockbox from the NAND and start it. IMHO.

[atomikpunk]

Hi,

could someone probe the xpc pins 0 to 3 while unpowered? On the 224 pins BGA package, those are E5, C4, F4 and A3 respectively. They should be tied up to GND or VCC. This could help understanding the booting mode. xpc0 tells about internal or external memory (GND is external, VCC is internal bootloader). xpc[3:1] is for internal bootloader mode.

Also, if xpc0 is tied pulled high (internal bootloader), it would be interesting to probe xpa0 (pin D5) and see if it is connected to a button. If that is the case, then maybe there is a "firmware update" mode accessible...

[daniel_at]

could someone probe the xpc pins 0 to 3 while unpowered?

Hm - that would only be possible on a defect device, or at least it would be defect afterwards... Its not possible to measure (reliable) any of the pins from the BGA. There are some vias which might conntact any of those pins, but you can only make rough guesses based on their position.

So if anyone has already bricked any of the devices stated in the Subject, he/she may connact me to and maybe it will be possible to make some experiments...

Daniel

[atomikpunk]

Hmmm I'm not sure why you say the device would be broken afterward. It's only unpowered probing, no? Like you find the ground, place a probe there, then probe the lines I listed and check if there is a pull-up or pull-down, then do it again with vcc?

Just for the record, I think I found a routine where there is GPIOA input reading on at least 4 pins of it. It is done in a quite strange manner however so I'm still trying to understand it. I'll keep you informed.

[daniel_at]

Because a BGA hides all its pins beneath the package: http://flickr.com/photos/90053035@N00/2494642819/in/set-72157605072639496/

So you have to desolder the chip (which only works if you heat up the whole PCB so that the solder melts, which in turn destroys the device) and than make some measurements. But you can only check connection to GND/VCC or other "well known" nets.

The board from my e200 has a lot of vias under the chip - which may contact some of the pins - but you cant say sure which via goes to which pin - only make rough guesses based on the location of the via.

[saratoga]

You can get to maybe a dozen or two of the bga pins out of 224, so testing isn't exactly easy, and a lot of them are boring pins (JTAG).

[linuxstb]

atomikpunk.

Firstly, I think it would be useful if you could share some of your disassembly findings.  It would also seem to make sense for everyone working on disassembling V2 firmwares to use the same version.

Whilst I'm sure replacing (for example) the mp3 codec with our own code could work, it's far from ideal. 

Firstly, it will make development much slower (you'll need to start the original firmware, and play an mp3 file in order for our code to be run.

Secondly, we're running our own code within the environment of the OF - we don't know what other threads may be running at the time (or how the OF multi-tasks), so we would need to make sure we don't corrupt anything currently in use by the OF.

Thirdly, in some ways it's a disadvantage to be running within the initialised environment of the OF - it means we don't know that our code will run reliably when we move to replacing the OF firmware completely.

But having said that, it's also an advantage to be able to read the hardware registers after they've been initialised by the OF - so we can ensure Rockbox does things at least as well.

So in conclusion, trying to run code by replacing a library function would be useful, but I think we still need to find a way to extend my current method of inserting code to work with larger bootloaders.

[atomikpunk]

Hi linuxstb,

I have no problem working on the same firmware version. ATM, I'm on the M200 v.4.1.8a but I wouldn't mind too much changing to another one. However, keep in mind that much of my work up to now would be "lost" in the sense that I would need to re-analyze most of the routines. If you guys don't mind looking at this firmware version (M200 v.4.1.8a), I'd be glad to share my findings. In fact, most of what I've found wasn't published exactly because I think it wouldn't be useful for others not looking at the same firmware version as I do.

Concerning the library replacement, I also think it is not the ideal solution. However, a big plus is that we could separate the job: one team beginning to work on missing drivers and the other team keep looking at the OF. And the biggest gain would be to have a lot more space to put custom code in because library blocks are much smaller than their "reserved" space (much smaller than for example 0x1E000 bytes size of a library block on the M200).

But you're right, we don't know if, and if so, how the kernel do multitasking and there is risk there. However, as far as we don't try to play a file of the particular format, I'm pretty sure there won't be any problem. And still, we could re-flash the device with the OF.

I too think that's a temporary solution helping us to develop while we also try to understand the firmware and figure out how we will be able to put rockbox in...


Edit: for those of you interested, I put up some more disassembly details on the SansaV2Firmware wiki page. For the moment it only contains an overview of both the reset and irq vectors, buts also some pointers in the code where I think the library blocks are loaded. Those with the appropriate tools may look there and see if they can provide more info about it. I already have some more details but bed is calling me for the moment, so I'll update when I'll have some time... Have fun until then

[beambot]

Today I also tried to connect my clip to a jtag with the pinout given by hth and it didn't work (to solder the wires wasn't funny  ). Means the jtag pinout of the clip isn't the same as for the e200, the pinout is wrong or there is another' switch' to enable the jtag port. I tried some cable combination with my breadboard without success. I will take another look to it tomorrow...

Michael

 

[saratoga]

I quickly double checked the posted JTAG pinout against the pins in the datasheet using a scan of the clip's board (you can actually see the JTAG traces go from the CPU to the header) and they looked right to me.  Though you're welcome to double check me:

(First row is A, First column is 1)

C2 jtag_trst_n  JTAG reset not
A1 jtag_tms  JTAG mode select
B2 jtag_tck  JTAG clock
B1 jtag_tdi  JTAG data input
D3 jtag_tdo  JTAG data output

[beambot]

Sorry to ask again, but I would like to be sure !!!

Early in this thread some one  posted a picture of the clip's board :
If I take JTAG nSRST (Header Pin7) as a reference because this is the only one which works  and take a look to the AS3525A Package Ball out I found it named M2. If I count backwards looking at the picture my proc pin candidates which are going to the jtag header are A1 A2 B1 B2 C3 (TMS,XPC7,TDI,TCK,TRST_N). So for my point of view not all neccessary JTAG pins are present at the 'header'. But it makes no sence to put only a few of the JTAG pins to the header, so I guess something is wrong with my counting. Give me a tip . Perhaps I'm not able to count 

Michael

[daniel_at]

@beambot: try to look at the surrounding of the jtag-interface, if you find a unsolderd resistor or anything else, that can be bridged while facturing and then removed.

I found something like that within my E200v2 - but i have not tried to bridge it so far.
Picture: http://flickr.com/photos/90053035@N00/2494642819/in/set-72157605072639496/

bye, Daniel

[atomikpunk]

Hi,

I've just put up some more findings on the library loading routines on the wiki. Please have a look here. As a summary, I am now pretty sure that library blocks are loaded in RAM directly by code in the firmware. I also noted that the library blocks size seems to be hardcoded in the firmware and would be 0x1E000 as expected.

If you feel like looking at the firmware, feel free to contact me via PMs and/or look at the wiki and try to expand knowledge in the area of the library loading routines. Or maybe have a look around the loading of the sd_reload, usb_function and otg_function libraries to try to find recovery procedures or stuff that trigs usb modes.

I hope we get to find a recovery procedure soon because there are a lot of things I'd like to test

[embrion]

Quiet risky method of recovery in case somthing goes wrong with bootloader but luckly it's one-or-two-times-in-device-life operation so no big deal.
However, in early developing stage, jtag would be usefull for debricking while developing the bootloader. It's perfect interface but as far as I know, we need some dedicated software to control it ( unless it works with hyperterminal and got "load FW image from TFTP server" option )