Rockbox Project (M6)

markun · 03-06-2008

rockbox does have a video player:

PluginMpegplayer < Main < TWiki

and for me porting rockbox is not about fixing any bugs in the original firmware, but about having fun

I didn't have high hopes about finding S5L8700 datasheet. We'll just have to read the disassembled firmwares and test our ideas by writing code and trying it on the player.

vcf · 03-06-2008

markun! you are absoloutlty right( about the fun and the data sheet)

BobbyQ · 03-06-2008

by the way, the rockbox mpeg video plugin is (yet) far inferior to the Meizu FW. So I would also classify the whole rockbox on M6 things as an educational/fun project, not a full FW replacement. But gapless playback would be really cool .. I want dual-boot ! :-)

markun · 03-07-2008

I started a new wiki page about the information I'm gathering from looking at the disassembled files. Feel free to help out by adding new info or correcting mistakes I made.

MeizuReverseEngineering < Main < TWiki

vcf · 03-08-2008

so here we need some people with asm laguage knoladge. is here anybodt who knows it?

Kane Draco · 03-08-2008

Wow. Awesome. I'll be watching this thread for updates. I'd love to put Rockbox on my M6, and it will probably be available in the time when its safe to modify mine without hurting the warranty, or later.

kgb2008 · 03-09-2008

The firmware is developed in C/C++ language and based on the uc/OS II 2.77 kernel, we can easily get the entry point of every tasks by comparing with the ucOS2 source code...

Another tips, there's a build-in ascii font at the end part of the firmware, we can track the reference and find out how to display strings on the LCD.

wpyh · 03-09-2008

kgb2008: I don't see any ASCII font at the end of the firmware; where is it located?

By the way, I've looked at M6SL firmware: it's not compressed with RAR, and the header is different.

For M6 SP/TP, there is a 8192 byte header, followed by a RAR file (old version of rar, < 3.0), followed by a tail. For M6SL, there is a 32768 byte header, followed by the firmware image itself (SDRAM_image.bin), followed by a tail.

The tail is just a terminator (0xa5a5a5a5 0x5a5a5a5a).

kgb2008 · 03-09-2008

The LCD controller special register group is located at 0x39200000, there's a rountine to map some of the SDRAM areas as frame buffers.

wpyh: Find the pattern of "00 00 00 01 00 02 00 03 .... 00 7E 00 7F" near the end of SDRAM_image.bin, it's the beginning of ASCII font data block, around 8576 bytes.

In the case of M6SL, the firmware is locate in the cheaper NAND flash, the header(Module 0) must deal with ECC data verification & recovery, so it's larger than which in M6 SP/TP.

wpyh · 03-09-2008

OK, I saw it. Thanks. The format is similar to the usual font format: 128 entries for the table (16-bit BE), then width table of 128 entries (8-bit), then the data (16x16 font).

By 0x39200000, you mean memory address, right? I haven't looked into the asm disassemble yet. By the way, is there a way to compile it back into SDRAM_image.bin? If there is, we can make modifications and recompile, and see what changes, thus learning the code in the process.

wpyh · 03-09-2008

Yeah, and another thing here: in the disassembled SDRAM_image, there are some garbled characters, like this one on line 14643:

sub_800A314 ; CODE XREF: sub_8006F28+6D0p

What locale do I need to view it under?

Rika! · 03-09-2008

procedure at 0x8000B68 seems to be a printf() or something similar, maybe it used for debugging purposes

kgb2008 · 03-09-2008

Originally Posted by Rika!

procedure at 0x8000B68 seems to be a printf() or something similar, maybe it used for debugging purposes

I think it's just an uart_puts() like function for error output while the entry code (something like init.s) is running, but it's no use to us since we cannot access the UART/JTAG interface outside the box, we must find out the way how to output strings to LCD directly. Find the string "Formatting......", "Please Wait......", you will find that it's reference to a function that can write a string on the screen at specified X,Y position. We should check how to initialize the LCD registers, and if we must sync out the frame buffer to the vram. After these things, we can try to run a Helloworld on M6 :-)

nice2know_u · 03-09-2008

I don't envy you guys, this looks like an awful lot of work to me.

But I really hope you succeed, and soon we can run rockbox on our M6 :P

Rika! · 03-09-2008

kgb, where u got info about kernel version? oO

vcf · 03-09-2008

Originally Posted by kgb2008

I think it's just an uart_puts() like function for error output while the entry code (something like init.s) is running, but it's no use to us since we cannot access the UART/JTAG interface outside the box, we must find out the way how to output strings to LCD directly. Find the string "Formatting......", "Please Wait......", you will find that it's reference to a function that can write a string on the screen at specified X,Y position. We should check how to initialize the LCD registers, and if we must sync out the frame buffer to the vram. After these things, we can try to run a Helloworld on M6 :-)

yes its right. btw where u got info about kernel version?

kgb2008 · 03-09-2008

Originally Posted by Rika!

kgb, where u got info about kernel version? oO

Translate:

LDR R0,=0x115
RET

as:

INT16U OSVersion (void)
{
return (OS_VERSION);
}

----------------------------
0x115 == 277

P.S. 0x3CC00000 is the UART register block, by tracking this you will figure out those wellknown guys - uart_gets(), uart_puts(), ...., sprintf(), printf(), scanf(), and other functions in arm c runtime library.

markun · 03-09-2008

kgb2008: thanks man, I added the registeres to the page. Are you planning on creating an account for the rockbox wiki or will you keep posting your info here?

mbarry · 03-10-2008

So...much...technical termanology:eek:...

wpyh · 03-10-2008

Hi, I'm just a noob, and I tried using objdump to disassemble the firmware but failed.

I started by compiling binutils-2.17.50.0.14 with "./configure --target=arm-elf --disable-shared --enable-static", then cd to binutils and "./objdump -D -b binary -m arm9 -EB /tmp/header" (that header is the header I extracted from the firmware image).

Here is the output:

/tmp/header: file format binary

Disassembly of section .data:

00000000 <.data>:
Segmentation fault

Why did it segfault? Any pointers, please.