Sandisk C100 series

[shotofadds]

Marc,

On other Telechips devices, uploading a firmware file (.bin) using tcctool just runs that firmware from RAM, so nothing is flashed to the device. It should be safe to 'preview' firmware updates in this way.

I can't have a look at that service program right now, as .ru domains are blocked here (but I suspect it's the same FWDN program that has cropped up elsewhere).

[MarcGuay]

Howdy,

So I successfully uploaded v2.0.008A using tcctool and it ran fine, then I rebooted back into v2.0.007A.  I tried the same procedure using v1.0.005a and first it tried to connect in MTP mode (presumably the default setting), then upon unplugging I was presented with a firmware interface without strings.  All of the images displayed fine, but no words were present in the menus, etc.  I read about this on one of the many forums I scanned today, so they must have changed something between the v1 and v2 versions that doesn't gel well when you switch versions.  Anyway, this is probably unrelated to porting.

As for the FWDN program, shotofadds, I think you're right, it's the same program that's been around for a bit.  I'm going to see if it can be used to extract the Production Test Mode code from the player, though I have no idea even where to begin.  I've got some reading about memory to do.  Update:  The production test mode strings exist in the player.rom file so presumably the code lives there as well. 

Oh, and I also read that, at least with the v2 firmwares, they made it possible to perform a firmware upgrade simply by placing the "player.rom" file in the root directory in MSC mode and unplugging the unit, but have yet to try it myself because I want to see if I can preserve the 2.0.007A firmware I have on there first.  Update:  I found the string "UPDATE F/W?" in the .rom file and figured it was safe to try this update method, and indeed, placing a player.rom file in the root and rebooting is a method of loading code to the device.  Again, no idea how if this is relevent to porting.

As for the LCD, I've disassembled the firmware in the same fashion that tarsius had and can't really make heads or tails of it, but will skim through it and see if I can find anything. 

[shotofadds]

Oh, and I also read that, at least with the v2 firmwares, they made it possible to perform a firmware upgrade simply by placing the "player.rom" file in the root directory in MSC mode and unplugging the unit, but have yet to try it myself because I want to see if I can preserve the 2.0.007A firmware I have on there first.  Update:  I found the string "UPDATE F/W?" in the .rom file and figured it was safe to try this update method, and indeed, placing a player.rom file in the root and rebooting is a method of loading code to the device.  Again, no idea how if this is relevent to porting.

Ok, looks like you can upgrade the firmware in the same way as other Telechips players. On the D2 we use this to flash a patched version of the original firmware, which is used to dual-boot with the Rockbox bootloader. But, during initial development there's no need to flash anything and tcctool should be sufficient.

Given that most of the C100 hardware looks pretty much identical to the M200 (v1), the most important thing now is to identify the LCD model and try to write a driver for it. Good luck!

[MarcGuay]

This is the only marking I could find on the LCD in the scans.  I searched for every possible combination of letters & numbers it could be and came up empty, but maybe someone else has a clue.  It's on the bottom of the LCD in the "flipped away" scan in the wiki.

[B@SS]

If this help
On the front of screen
GPM580B0 0603
A-NB650218.50.N1 -1
Mark on the plastic thing around the screen
EV-BL-0130
65-04535

[MarcGuay]

Progress?

I've found the main functions relating to the Production Test Mode, as well as all of its glorious spelling mistakes.  When the LCD test is run, it displays fullscreen red, then green, then blue, etc, while waiting for a buttonpress inbetween.  I've modified what I believed to be the code for the colour red and sent the new player.rom file to the RAM using tcctool and it showed green instead, so my bumbling through the code isn't totally a wild goose chase.  But I've reached a bit of standstill due to lack of knowledge concerning ARM assembler language and am hoping that someone could point me in the right direction. 

Basically, what happens for each colour is this:

Code: [Select]

MOV     R0, #COLOUR
BL      disp_solid_colour_R0   ; I've name it this because it only seems to be run in these cases.
MOV     R0, #1
BL      lcd_subroutine2  ; This is a widely used subroutine that seems related to the LCD.

Where COLOUR is:

0xF800 = red
0x07E0 = green
0x001F = blue

Also, whenever strings are displayed on the LCD the follow command is used:

Code: [Select]

ADR     R2, StringName 

I suppose my main issue is that I don't really understand where R2 and R0 are located or pointing to.  I believe these are flexible variables that are constantly changing, so do I try and find the last known definition?  Word to the wise:  Teaching yourself is difficult, go to school.

[tarsius]

R0, R1, R2, ..., R15 are 32-bit registers within the processor.

Depending on your background with assembly languages, you might find it useful to refer directly to an ARM manual, like this one:

http://www.eecs.umich.edu/~panalyzer/pdfs/ARM_doc.pdf

or to a tutorial like this:

http://www.heyrick.co.uk/assembler/

Everything will come into focus after spending a bit of time working with it.

[MarcGuay]

Slow and steady wins the race?

The buttons are in GPIO-A (0x80000300).  When the 0x10000000 bit is NOT set, the menu button is pressed, and when the 0x01000000 bit is NOT set, the select button is pressed.  As for the LCD, it seems that all roads point towards address 0x203F2704 (which the TCC77X manual indicates as: "0x20000000 ~ 0x2FFFFFFF - Assigned to SDRAM initially"). 

And that's it for now.  Thanks for the links by the way, tarsius, the first one was particularly helpful in getting a grip on a few things.  I'm starting to realize how helpful a datasheet for the LCD controller would be in doing this.

[MarcGuay]

The TCC77X manual indicates that external IDE devices (which I presume includes the LCD) are assigned the 0x50000000 - 0x5FFFFFFF range, and taking a look at the working driver for the m200 & Logik DAX, these are indeed the addresses it uses.

Is it possible that in the c200 firmware 0x203F2704 (see previous post) has been reassigned at some point to the LCD controller or am I barking up the wrong tree?  The firmware contains no instances of data being moved to memory addresses in the 0x50000000 range at all.  Anyone have advice on where to look next?  Maybe trace back and see if 0x203F2704 has been re-defined?

[linuxstb]

Reading through my notes of my disassembly of the Logik DAX's firmware, it seems there was a "lcd init" type function that calculated the base address of the LCD controller (what I call LCD_BASE in the DAX/M200 driver in Rockbox) - i.e. 0x50000000.

This function took the value 0x5 in R1, and then did a "lsl #28" to shift it to 0x50000000, and then stored it in a memory location (in the DAX's firmware, it was 0x201969ac).

Looking through the C100's firmware, it seems to have a very similar function (entry point at 0x32074), and 0x203f2704 + 0x0c is the location that "LCD_BASE" is written to (at the end of that function).

The function at 0x32100 appears to be the "lcd_cmd" function - this is using the value stored at 0x203f2704 + 0x0c

0x322f4 appears to be performing the main LCD init - and it appears to be very similar to the C200's LCD init function - see firmware/target/arm/sandisk/sansa-c200/lcd-c200.c

This would make 0x38f3c some kind of delay function, but I don't understand it...

Hope that helps



EDIT: I've been investigating a little more, and have started writing the c100 LCD driver, which I'm attaching here.  This is based on the C200 driver, and all I've implemented so far is the lcd_device_init, lcd_send_command and lcd_send_data functions.  These are based on my disassembly of the C100's OF.  The delay function being called after most commands appears to be specifying the delay in 5ms ticks, so I've converted these to calls to the Rockbox sleep() function.

I haven't even tried to compile it though, and it could benefit from being double-checked against the OF.

The next step would be to implement the lcd_update_rect function to try and display things on the LCD.

[MarcGuay]

Alrighty, I've got "things" displaying on the LCD, but I can't figure out two of the GPIO inits, so it's basically a bunch of moving garbage.  The difficulty is in translating these lines of asm, which define GPIOD and GPIOD_FUNC, respectively:

Code: [Select]

ADD     R2, R0, #0x338          ; R2 = 0x80000338 = GPIOD_FUNC
LDR     R3, [R2]                      ; R3 = current val of GPIOD_FUNC
ORR     R3, R3, #2                 ; R3 = or
STR     R3, [R2]                      ;  Store R3 in GPIOD_FUNC

Code: [Select]

ADD     R1, R0, #0x330      ; R1 = GPIOD Data Register 
LDR     R3, [R1] ;                ; R3 = current val of GPIOD 
ORR     R3, R3, #0xC0        ; R3 = or
STR     R3, [R1]                   ;  Store R3 in GPIOD

The notes are just me trying to figure out what's going on.  Am I right to think that the second line is using the current value of GPIO_D as part of the calculation? 

This is what I have so far for the gpio_init function, it shares a lot with the LogikDAX:

Code: [Select]

    GPIOA_FUNC = 0;
    GPIOB_FUNC = 0x16A3;
    GPIOC_FUNC = 1;
    GPIOD_FUNC = 2; /* ? */
    GPIOE_FUNC = 0;
	
    GPIOA_DIR = 0xFFFF0E00;   /* 0 - 0xF200 */
    GPIOB_DIR = 0x6FFFF;
    GPIOC_DIR = 0x03FFFFFF; 
    GPIOD_DIR = 0x3F7;
    GPIOE_DIR = 0x9B;
    
    GPIOA = 0x1080;
    GPIOB = 0;
    GPIOC = 0;
    GPIOD = 0xc0; /* ? */				
    GPIOE = 0x9B;

[lowlight]

Code: [Select]

ADD     R2, R0, #0x338          ; R2 = 0x80000338 = GPIOD_FUNC
LDR     R3, [R2]                      ; R3 = current val of GPIOD_FUNC
ORR     R3, R3, #2                 ; R3 = or
STR     R3, [R2]                      ;  Store R3 in GPIOD_FUNC

Code: [Select]

ADD     R1, R0, #0x330      ; R1 = GPIOD Data Register 
LDR     R3, [R1] ;                ; R3 = current val of GPIOD 
ORR     R3, R3, #0xC0        ; R3 = or
STR     R3, [R1]                   ;  Store R3 in GPIOD

That's

GPIOD_FUNC |= 2

and

GPIOD |= 0xc0

[MarcGuay]

Thanks lowlight, makes perfect sense.  I guess the fact that this is the initialization of the GPIOs made me wonder what the current value could be besides zero...?  Unfortunately, the display outputs the same nonsense using these values.  Time to look over lcd_update_rect()...

[linuxstb]

Comparing your inits with the OF, I see one mistake - GPIOA should be set to 0x80, not 0x1080.  Everything else looks right though (with lowlight's changes).

Have you managed to work out which pin (if any) is the backlight control?

[MarcGuay]

Thanks for pointing out the error, I caught it myself shortly after posting, and recompiling provides the same results.

As for the backlight pin, I went hunting through the gpio_init bit-by-bit and came up with the following:

Setting GPIOB_FUNC to 0x14A3, 0x16A1 or 0x16A2 = No display, while 0x1683 = backlight on but nothing displayed.  I just realized that in order to get the build to compile I set the LCD_DEPTH to 1 in the c100 config file, figuring it would be fine for debugging purposes, but perhaps it's naive/stupid to think it wouldn't have a larger effect? 

Up:  I've got it compiling as a colour target with the same results, except now it's junk in brilliant 16-bit colour!