Reverse engineering Clip Zip

[Inipp]

Hi all,

I'm interested in the process that you guys went through when reverse engineering the sansa zip (and sansa ams in general).
I found out a lot already thanks to your wonderful wiki and good documented source code but still some things are unknown to me.

How did you find out...

• that an as3525(v2) is being used inside the sandisk SoC?
• the pin out of the sandisk SoC?
• how to communicate with the peripherals(LCD, SD, Flash, RAM)? Bus pirate, OF reversing, datasheets?
• were the firmware resides and how it can be accessed through usb (as in Wiki/SansaAMSUnbrick).
  

Don't be afraid to get technical. I got some background in electronics, reversing and microcontrollers.

~Inipp

[saratoga]

that an as3525(v2) is being used inside the sandisk SoC?

The player had a different arm CPU then the original clip, and more internal memory, so it had to be a new SOC.

the pin out of the sandisk SoC?

I don't think we know the pinout.

how to communicate with the peripherals(LCD, SD, Flash, RAM)? Bus pirate, OF reversing, datasheets?

They're generally pretty similar to AMSv1, but the differences were mostly reverse engineered or located in datasheets.

were the firmware resides and how it can be accessed through usb (as in Wiki/SansaAMSUnbrick).

Someone experimented with a bricked player and realized that it would expose the internal memory when in that state.

[Inipp]

saratoga thanks for your reply.

The player had a different arm CPU then the original clip, and more internal memory, so it had to be a new SOC.

Let me rephrase my question: How did someone figure out that the first generation Sansa AMS(e200v2, c200v2, m200 v2 or Clip) had an as3525.

I don't think we know the pinout.

You do need the pinout, or at least partially, don't you? The MMC/SD interface is already integrated in the as3525 but there's no LCD module inside the as3525. Thus no data register you can just write to.

Someone experimented with a bricked player and realized that it would expose the internal memory when in that state.

There are quite some pins that can be shorted with each other. I assume that there had been some educated guess whether or not something like that would even be possible.

[saratoga]

Let me rephrase my question: How did someone figure out that the first generation Sansa AMS(e200v2, c200v2, m200 v2 or Clip) had an as3525.

The firmware files from Sandisk have the string "as3525" in the header. 

You do need the pinout, or at least partially, don't you? The MMC/SD interface is already integrated in the as3525 but there's no LCD module inside the as3525. Thus no data register you can just write to.

The display controller was reverse engineered from the firmware.  Its necessary to know what registers are written to, if thats what you mean.

There are quite some pins that can be shorted with each other. I assume that there had been some educated guess whether or not something like that would even be possible.

The idea is to prevent the chip from working, so you have a few choices as to which pin is used.  I never tried, but I suspect a lot of the pins will result in the memory not working when shorted. 

Anyway, it sounds like you're more interested in the process of figuring this stuff out then the specifics.  Have you read the AMS development thread in the New Ports forum?  This stuff is probably nearly all in there.   

[Inipp]

Thank you, I was hoping for such an answer.

Yea, I'm really more interested in the process than the specifics. But I do own a clip zip and I like the figure out/know how my devices work.

I have read the clip zip development thread and I have been skimming through the sansa ams thread.
It contains a lot of useful information but it's mostly: "I figured out x,y,z" and not How they figured it out.

[saratoga]

Not the zip thread, this stuff was figured out years before then. Check out the original sans a ams thread.