Rockbox Project (M6)

I think it's wonderful too of course I'll try to get some rockbox/meizu stuff done this weekend.

btw, the shipping of my meizu got delayed and they told me it will probably be impossible to get an M6SP so instead it would be the SL. I don't really mind. It would be nice though to have several devs with different models.

PS. Someone called for me on IRC yesterday night when I wasn't at home. Was it you by any chance, kgb2008?

kgb2008: How did you find out that the LCD driver IC are/might be the S6D0129/S6D0139?

i'm sorry to hear you will not be getting a sp-model, since most of us have that version. Will you still be able to develop rockbox for both versions??

yes the majority of us have sp. but if markun will bye sl it dosent turn the things dramaticlly, does it? as i understand as rockbox supports and audio chip which is in sl and which is in sp one module of rockbox will work and on sp and on tp and on sl! isnt is so?

I don't think that will be a big problem. Most of the code will be shared between the two versions of the M6.

oh ok, i really hope so, becouse it would be a shame if rockbox was only available for the SL series.

markun: The S6D0129 is the most popular single chip QVGA LCD driver of Samsung TFT panel in these years, in the case of Toshiba, it will be JBT6K71.

Just look for the pattern of bit-bangled SPI subrountines, locate the one would be called at the moment of LCD start-up, we can get the initializing command series, and know that the gamma setting register is from R30 to R39 and the display control register is at R07. it's quite difference to the other SEC LCD drivers, but match with the S6D0129/139.

The Toshiba screen in the Giabeat uses a NEC uPD161704 I believe, so maybe it could be that one as well. Would you be able to tell from looking at the M6T firmware?

Markun: I can't tell you which LCD driver chip is employed inside M6T, 'cause i don't have any spec or reference code about toshiba's QVGA LCM. The register initial code of the LCD driver on M6SP/SL/TP is something like below, you may check if it's familiar.

M6SP,M6SL
------------------------
LCD_SetReg(7,0);
LCD_SetReg(0x13,0);
LCD_SetReg(0x11,0x3304);
LCD_SetReg(0x14,0x1300);
LCD_SetReg(0x10,0x1A20);
LCD_SetReg(0x13,0x40);
LCD_SetReg(0x13,0x60);
LCD_SetReg(0x13,0x70);
LCD_SetReg(0x01,0x127);
LCD_SetReg(0x02,0x700);
LCD_SetReg(0x03,0x1030);
LCD_SetReg(0x08,0x208);
LCD_SetReg(0x0B,0x620);
LCD_SetReg(0x0C,0x110);
LCD_SetReg(0x30,0x120);
LCD_SetReg(0x31,0x117);
LCD_SetReg(0x32,0);
LCD_SetReg(0x33,0x305);
LCD_SetReg(0x34,0x717);
LCD_SetReg(0x35,0x124);
LCD_SetReg(0x36,0x706);
LCD_SetReg(0x37,0x503);
LCD_SetReg(0x38,0x1F03);
LCD_SetReg(0x39,9);
LCD_SetReg(0x40,0);
LCD_SetReg(0x41,0);
LCD_SetReg(0x42,0x13F);
LCD_SetReg(0x43,0);
LCD_SetReg(0x44,0x13F);
LCD_SetReg(0x45,0);
LCD_SetReg(0x46,0xEF00);
LCD_SetReg(0x47,0x13F);
LCD_SetReg(0x48,0);
LCD_SetReg(7,0x15);
LCD_SetReg(7,0x17);
LCD_SetReg(0x20,0);
LCD_SetReg(0x21,0);
LCD_SetReg(0x22,0);

M6TP
------------------------------
LCD_SetReg(0x03,1);
LCD_SetReg(0x3A,1);
LCD_SetReg(0x32,2);
LCD_SetReg(0x33,0);
LCD_SetReg(0x37,0);
LCD_SetReg(0x77,0xFFF);
LCD_SetReg(0x72,1);
LCD_SetReg(0x1C,0x1A5C);
LCD_SetReg(0x52,0x21);
LCD_SetReg(0x53,0x11);
LCD_SetReg(0x24,0x61);
LCD_SetReg(0x25,0x61);
LCD_SetReg(0x26,0);
LCD_SetReg(0x27,0);
LCD_SetReg(0x61,26);
LCD_SetReg(0x62,8);
LCD_SetReg(0x63,0x15);
LCD_SetReg(0x64,0x16);
LCD_SetReg(0x65,0xC);
LCD_SetReg(0x66,0x24);
LCD_SetReg(0x4D,0x205);
LCD_SetReg(0x4E,1);
LCD_SetReg(0x4F,0x104);
LCD_SetReg(0x2E,0x32);
LCD_SetReg(0x3E,0x88);
LCD_SetReg(0x70,0x20);
LCD_SetReg(0x29,0);
LCD_SetReg(0x2A,0);
LCD_SetReg(0x28,0xEF);
LCD_SetReg(0x2C,0x13F);
LCD_SetReg(8,0);
LCD_SetReg(9,0xEF);
LCD_SetReg(0x0A,0);
LCD_SetReg(0x0B,0x13F);
LCD_SetReg(1,0);
LCD_SetReg(5,4);
LCD_SetReg(6,0);
LCD_SetReg(7,0);
LCD_SetReg(2,0x46);
LCD_SetReg(0x3C,0);
LCD_SetReg(0x3D,0x13F);
LCD_SetReg(0x18,0x1F6A);
LCD_SetReg(0x1A,0xAA);
LCD_SetReg(0x1B,0x28);
LCD_SetReg(0x1C,0x1A5C);
LCD_SetReg(0x1D,0x65);
LCD_SetReg(0x1F,0x38);
LCD_SetReg(0x20,0x80);
LCD_SetReg(0x18,0x1F6B);
LCD_SetReg(0x1E,0x21);
LCD_SetReg(0x3B,1);
LCD_SetReg(0,8);

I didn't know that the M3 was so similar to the M6. It has some components of the SP and some of the SL. I read that it has the same screen as the nano 2nd gen, but I couldn't find out which one that is. I think I've found the LCD init code. Do you recognize which driver it is?

LCD_SetReg(0x11, 0x3001);
LCD_SetReg(0x14, 0xB318);
LCD_SetReg(0x10, 0x1A80);
LCD_SetReg(0x13, 0x40);
LCD_SetReg(0x13, 0x60);
LCD_SetReg(0x13, 0x70);
LCD_SetReg(1, 0x110);
LCD_SetReg(2, 0);
LCD_SetReg(3, 0x1030);
LCD_SetReg(7, 4);
LCD_SetReg(8, 0x202);
LCD_SetReg(0xB, 0x2004);
LCD_SetReg(0xC, 0);
LCD_SetReg(0x30, 0);
LCD_SetReg(0x31, 3);
LCD_SetReg(0x32, 2);
LCD_SetReg(0x33, 0x400);
LCD_SetReg(0x34, 0x506);
LCD_SetReg(0x35, 0);
LCD_SetReg(0x36, 0x707);
LCD_SetReg(0x37, 0x300);
LCD_SetReg(0x38, 8);
LCD_SetReg(0x39, 0x1F00);
LCD_SetReg(0x44, 0xAF00);
LCD_SetReg(0x45, 0x8300);
LCD_SetReg(9, 9);
LCD_SetReg(7, 0x16);
LCD_SetReg(7, 0x17);
LCD_SetReg(0x21, 0);

EDIT: I see now that it has some similarities with the S6D0129/39...
EDIT: I looked at the datasheets of the SD6D0110 and 114, but both have less than 0x46 registers.

S6D0123, I guess.

A new forum has been created specifically for the Meizu Rockbox project on Meizu Me.

Hopefully, this will make it easier for you guys allowing for separate topics on specific issues rather than gathering everything in a now 14 page thread.

Good luck guys! A lot of people will appreciate your work.

thanks. here is a link for rockbox development tree of froums (all messages are saved) Rockbox - Meizu Me

Added some code to compile the rockbox simulator for the Meizu M6. Because we already have a 320x240 target (ipod video) there is not much work for the interface to do (only the button mappings), but it gives you a feeling of what it will be like:



kgb2008: are you planning to try and run some test code on your player? btw, all ARM based rockbox targets are little-endian. Do you think we should switch the M6 to little-endian mode too or change the rockbox code?

Tango icons nice

Markun: I'm sorry that I have none of the Miniplayer models myself, I wonder if i can borrow anyone from my friend for testing purpose, but i believe there're some guys here like to try the new build on their gadget. All i've done is just for fun and hope it can smooth your development somehow.

Since rockbox won't reference to any piece of the Blues SDK libraries, I think you may feel free to choose the byte order as little-endian.

You're doing an amazing job, so thank you again for that I still haven't heard received any news about my player.

Yesterday I looked at the DFU specs and it contains some info on a 'suffix' to add to the DFU file, but non of Samsung's .dfu files seem to contain it.

I wonder what the CUFD marker is all about after interrupt vectors. It is contained in every .dfu and .ebn file as far as I can see.
Could it be some kind of byte-order-marker? Just wishful thinking I guess

Did you find some kind of checksum in the firmware files? An easy way to test this would be to modify a character in one of the debug strings in the .dfu file and see if we can still do a firmware upgrade with the dfu tools.

No, there is no checksum in firmware files.

Proof: I modified both my M3 and M6 firmwares to store its settings in SETTINGS.DAT instead of the (typo) SETTIGS.DAT, and the firmware updates and runs just fine. As expected, after the change settings are stored in SETTINGS.DAT.

wpyh: That's very good news!

I asked "Rika!" to do a similar test, but by modifying SST39VF800.dfu. He told me that DFU tools didn't want to continue after changing one of the strings. Could you verify it for me? Could you also test if making a change in the CUFD marker has any effect?

Due to the totally change of the BOM list and PCB layout, the GPIO pins usage on M6SL is quite different to SP/TP.

1) ADC0 is no longer in use to fetch the scan code of the buttons. The Lock switch, the Menu, Play, RW and FF buttons are map to the GPIO pins P1.2, P1.0, P1.4, P3.3 and P4.7.

2) The I2C address of FM tuner is 0x60, seems M6SL employed a TEA5767/5768 instead of TEA5760, it's bind to the native I2C bus of S5L8700 with the audio codec WM8987 which have an I2C address of 0x34.

3) There're still two pins bit-bangling with a chip at the I2C address 0x22, looks like an EEPROM. (P3.2 SDA, P3.4 SCL)

4) Several pins are talking with the touch slider and the LCD driver in soft SPI, as following,

QT1106 (P0.0 CS, P0.1 SCLK, P1.6 MOSI, P0.3 MISO)

LCD Driver(P7.1 CS, P4.2 SCLK, P4.3 MOSI, P1.1 MISO)

5) At lease two pins connect with the LTC3455 (P5.7 CHRG, P1.3 PWRON) to check if the cell in charging and turn off the system.

markun: "CUFD" is the reverse of "DFUC" (DFU compatiable?), it's a magic word, not a checksum, the offical DFU tools will check this for safety. Unless you finish your own burning tool, just keep this 4 bytes at the right place. BTW, I don't think the Samsung DFU tools does any matters with the DFU protocal :-)

Originally Posted by kgb2008

Due to the totally change of the BOM list and PCB layout, the GPIO pins usage on M6SL is quite different to SP/TP.

1) ADC0 is no longer been use to fetch the scan code of buttons, the Lock switch and the Menu, Play, RW, FF buttons are map to the GPIO pins P1.2, P1.0, P1.4, P3.3 and P4.7.

2) The I2C address of FM tuner is 0x60, seems M6SL employed a TEA5767/5768 instead of TEA5760, it's bind to the native I2C bus of S5L8700 with the audio codec WM8987 which have an I2C address of 0x34.

3) There're still two pins bit-bangling with a chip at the I2C address 0x22, look like an EEPROM. (P3.2 SDA, P3.4 SCL)

4) Several pins are talking with the touch slider and the LCD driver in soft SPI, as following,

QT1106 (P0.0 CS, P0.1 SCLK, P1.6 MOSI, P0.3 MISO)

LCD Driver(P7.1 CS, P4.2 SCLK, P4.3 MOSI, P1.1 MISO)

5) At lease two pins connect with the LTC3455 (P5.7 CHRG, P1.3 PWRON) to check if the cell in charging and turn off the system.

Thanks! I'll update the wiki when I have the time. It's strange that the FM chip wasn't the TEA5760 after all because the chips in the M6SL and the M3 both have TEA5760UK written on them:

÷È×å×·×&#217 ; MEIZU ÷È×å - רҵ MP3 PLAYER
÷È×å×·×&#217 ; MEIZU ÷È×å - רҵ MP3 PLAYER

markun: "CUFD" is the reverse of "DFUC" (DFU compatiable?), it's not a checksum, but the offical DFU tools will check this for safety only, unless you finish your own burning tool, just keep this 4 bytes at the right place.

Yes, or "DFU code" or something. I didn't want to imply that the DFUC marker was related to a checksum, just wondered if there was any since the DFU tool didn't want to update anymore after chaning one string.

EDIT: ok, updated the wiki. Let me know if I made any mistakes. Yesterday I adapted the TEA5767 driver in rockbox for the TEA5760UK. I guess it was for nothing, but it was easy and didn't take a lot of time