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

[atomikpunk]

Ok, I'll try to look at buttons handling later today. I was looking for GPIOs but didn't see that in v1 it was on ADC.

For the LCD, I'm pretty sure I already found both of the write_command and write_data routines. I'll give it a deeper look later today. I also think that the v1 team already put up a basic lcd driver, so it probably only need some minor changes.

[linuxstb]

It would be useful to work out the GPIOs anyway - it will be much easier if we can find at least one button detectable that way.

It would also be nice to work out what GPIOs are used for output - hopefully the button light or other LEDs (I don't know what's on the m200v2) are controlled via GPIO.  This would be another nice way to get feedback from our test code.

P.S. The "v1 team" is just me...

[atomikpunk]

Well I looked at the OF tonight, analyzed a bit more on the lcd drawing routines... I can confirm that I found the lcd_write_command and lcd_write_data routines, and also found where they draw at particular pixels in (x,y). Nothing more to report as of now, but a little more understanding

But for the firmware "expansion" I'm still puzzled how we could do it. I'd say that just changing the size multiplier in the header would do, _for the firmware_. But it would break the OF because of absolute addresses in the libraries...

BTW, after review, it seems that the size multiplier in the header is only valid for the firmware section, that just happens to be the same size as "library blocks" on the FW I'm currently looking at... I still don't know how to deduce the library blocks size...

So I guess I'll take advice of my pillow for now


Edit: I thought about it in my shower this morning, I guess that simply expanding the firmware section in the OF could in fact do the trick, because the hardcoded addresses are for the use of library blocks, but we won't use them anyway while running rockbox, so who care about bad addresses in blocks that won't get executed!

I'm also wondering, maybe that the library blocks are in fact "files" created on a "system partition" that hold particular algorithms, like codecs, etc. I wonder if we could put some extra rockbox object files and load them the same way the OF do with library blocks. So I guess another thing to look at in the disassembly is how they dynamically load (if that's the way they do it) library blocks, where they take it from, where they load it to, etc. In brief, how the "dynamic" library handling is done.

So to resume, my research on the OF disassembly is concentrated on:
- firmware file format
- how to expand the firmware
- GPIOs
- buttons
- "dynamic" libraries

[atomikpunk]

Hi Daniel,

yes that would be very helpful if you could trace the buttons signals up to the processor. I work in electronics too so let me know if I can help you with that. If you don't mind checking for LEDs or stuff like that too, that'd be great.

[beambot]

Hello Forum,

@atomikpunk , linuxstb

nice work till know. You worked out a lot of information about our new 'toy'

@linuxstb

Is it possible to give us more information about the memory mapping of the AS3525 out of the manual e.g adress range of GPIO , ROM,  RAM , extRAM, Flash etc. Perhaps this information makes it easier to take a look to the OF.(I don't know what's your aggreement with austriamicrosystems about sharing this information)

thanks
Michael

[atomikpunk]

Hi Michael,

thanks for the cheers

About the memory mapping, Bagder will be the one who can answer this question since he's the one who worked out an arrangement with Austriamicrosystems. He will be able to release selected information based on his agreement.

If you are interested in helping understanding the OF, let me know and I will be able to share what I already found about it. And maybe we will be able to divide work and cooperate (via IRC/Wiki/Forums?).

[daniel_at]

Hi again,

Okay  so far I have just opened it and made some pictures of it. You can find it at flicker here:
http://flickr.com/photos/90053035@N00/sets/72157605072639496/

I have added notes to some of the pictures, but they dont show up in opera... but the bottom-note says there are comments in it.

For the switches: I just made some measurements - no deep insights so far. All switches seem to be connected to a resistor-network (with 2 R's for each switch), except the Pwr-switch. All switches (again except the Pwr) are connected to Digital (or Power-)GND on one side. The other side is connected to a pulled-up line to about 3V, which switches off (or goes high-Z) every 0.5ms for a very short period of time. But the intervall between the shutoffs is not _very_ periodical and depends on task running on the E200 (so it seems to be handled in an low-priority scheduled thread).

The pulled-Up line goes to about 0.3V if the display-background light is off (i.e. powersaving mode) EXCEPT for the "UP" (or play) Switch (not the wheel-up). Maybe this is somehow a "special" key which can be checked by GPIO.
But my guess is, that all keys trigger a GPIO and than the level is checked by the ADC (maybe therefore the "high-Z" spikes).

I cant even say, if there is only one common signal line for the switches which goes to the SoC (but it pretty seems so)

HTH a bit,
Daniel

But these assumptions are very rough guesses - i havent spent much time so far on it.
I also tried (just by random poke'in) to find one of the vias near the SoC which carrys the common signal for the swtches... but havent found one...

[Bagder]

For lots of info on the AS3525 like (default) memory addresses for various things, check the attached patch to tracker entry FS#8843:

http://www.rockbox.org/tracker/task/8843

It is supposedly based on the AS3525 Linux patch and does include lots of details otherwise only mentioned in the data sheet.

[atomikpunk]

Just for the records before I go to bed, I did some investigation and found some info about which memory ranges are in use. All my findings applies to the M200 series, but it should be pretty easy to translate it to other models. The range 0x49C60 to 0x4A060 seems to be used for stack, while the TTB is located at 0x44000 (up to 0x4BFFF). I found out where the TTB and TLBs are setup and I hope to better understand the memory usage, and eventually find out how libraries are loaded in memory and how they are used in the firmware.

[daniel_at]

@Bagder: You have some datasheets for the AS3525 - or?
Do these give some information about the/a JTAG interface to the SoC/or the integrated uC?

I wanted to try to find out if the on-board 8-pin connector is a JTAG-interface and if so, also get the  pin-assignment of it. So far i know:

1 - GND
2 - low-active reset (pull to GND to reset)
3 - high-Z, pulled up
4 - high-Z, pulled up
5 - high-Z, pulled up
6 - high-Z, pulled up
7 - high-Z, pulled up
8 - V+ (3.3V)
(Pin1 is a rectangular pad...others are oval)

This means that there is one line to much for JTAG, maybe one of them has to be pulled low to enable JTAG. Does the datasheet say something about it? And has the uC in Reset-mode? (I dont think so - or?)

I have added some pics: http://flickr.com/photos/90053035@N00/2496093231/in/set-72157605072639496/

If we get JTAG working and get r/w access to the flash, than testing would be a lot easier, bec. we could always unbrick it.

Daniel

[Bagder]

The data sheet really doesn't mention a lot about it other than like this...

[atomikpunk]

Hi Daniel,

please have a look a couple of post earlier, hth already did some investigation on JTAG. Maybe it will help you. From what I understand, the JTAG interface is in fact the ARM922T core JTAG interface. So, you can have a look at the (publicly available) ARM922T datasheet which is the arm core included in the AS3525.

I don't know much about JTAG but if you can connect to it and are able to read/write the rom/flash, as you said, it will be a lot easier and safer to work.

[daniel_at]

Hello,

please have a look a couple of post earlier, hth already did some investigation on JTAG.

Hm - have searched for JTAG prior, cant find a user hth here... i guess you mean my initial post - which ends with HTH, what means Hope That Helps

But anyway, thx to Bagder for looking that up in the datasheet. I have found in the ARM922 datasheet, that the nTRST should be pulled low while accessing the chip with JTAG - but i am not completely sure... maybe ill try to extend my JTAG-Programmer so that it trys all possible combinations of pinout-alignments and reset-state...

Daniel

[saratoga]

Hello,

please have a look a couple of post earlier, hth already did some investigation on JTAG.

Hm - have searched for JTAG prior, cant find a user hth here... i guess you mean my initial post - which ends with HTH, what means Hope That Helps

http://forums.rockbox.org/index.php?topic=14064.msg121222#msg121222

[daniel_at]

@saratoga: oh..sorry, somehow i managed to search through the wrong post. Sad that there is no option to show a complete thread on one page - or is there one?... Oh, just found - "print preview".  Nevermind

I have tried to connect the Sansa with the pinout from hth to my JTAG interface... couldn  not initiate the connection. I have tried different states of the System- and the Test-Reset lines.

Will try some other configurations later.

Daniel