Rockbox Development > New Ports
Sandisk C100 series
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: ---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.
--- End code ---
Where COLOUR is:
0xF800 = red
0x07E0 = green
0x001F = blue
Also, whenever strings are displayed on the LCD the follow command is used:
--- Code: ---ADR R2, StringName
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version