This is a discussion on Rockbox Project (M6) within the Rockbox forums, part of the Community Development category; rockbox is more and more interesting thank you all for your work i hope your open source will be a ...
I'm not sure which FM tuner chip is in the musiccard 'cause I didn't start to check the firmware code of M3 yet. But on the photo of M6SL, the tuner chip is remarked, and the address of TEA5760 should be 0x40, so maybe some tricky things are there......
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?
I currently don't have access to a Windows machine, so unfortunately I'm unable to verify it for you. Can someone with a Windows machine please verify this?
Also, how did Rika! modify the string? What I did to change SETTIGS.DAT to SETTINGS.DAT was:
1. find SETTIGS.DAT\0\0
2. replace GS.DAT\0 with NGS.DAT
I made sure that the file length did not change in the process.
Oh, and I forgot to tell you one thing: The string that I changed was inside the Rar-compressed portion of the M3/M6 firmware. I decompressed it, changed the string, compressed it (using rar.exe v2.80), reassembled the firmware (header, rar-file, tail), then uploaded it into the device.
Please note that we _have_ to use rar.exe older than version 3, because the compression scheme is quite different and the samsung chip (I assume decompression is done by the chip) only knows how to decompress rar v2 files. If you use a rar v3 file, then upon next boot, the firmware image couldn't be read and you have to use the DFU tool again...
I currently don't have access to a Windows machine, so unfortunately I'm unable to verify it for you. Can someone with a Windows machine please verify this?
Would you like to take a look at DFU-Util? It needs some work so we can upload multiple files with a pause between. I was able to get it to compile in FreeBSD, but since I don't have my player yet I didn't look into it anymore.
Also, how did Rika! modify the string? What I did to change SETTIGS.DAT to SETTINGS.DAT was:
1. find SETTIGS.DAT\0\0
2. replace GS.DAT\0 with NGS.DAT
I made sure that the file length did not change in the process.
I asked him just to change a character in "Divide by zero" with a hex editor.
Would you like to take a look at DFU-Util? It needs some work so we can upload multiple files with a pause between. I was able to get it to compile in FreeBSD, but since I don't have my player yet I didn't look into it anymore.
I've tried it before, but it could not download a firmware into my M3. Is there anything special that must be done before we can use this utility? Anyway, I'll take a look at it again.
Originally Posted by markun
I asked him just to change a character in "Divide by zero" with a hex editor.
Well, maybe _that_ firmware has a checksum somewhere then... I don't know. Maybe it's because that firmware is not rar-compressed... here's my understanding of the Meizu firmwares:
1. On the M3 and M6 TP/SP players, the firmware image consists of a header, a rar-compressed payload and a tail. On the M6 SL, the firmware image consists of a header, an uncompressed payload and a tail.
2. The M3 and M6 TP/SP has a 1 MB NOR flash on the Samsung chip. To fit the firmware into this 1 MB flash, it needs to be compressed. The M6 SL doesn't have this NOR flash.
3. When we upgrade the firmware on the M3 and M6 TP/SP, the header is stripped off (or copied somewhere maybe), the tail is seeked (the tail basically signals the end of the file), and then the rar-compressed file is copied in its compressed form (i.e. not decompressed).
4. Upon reboot, the bootloader notices a new firmware, and if the player needs to be formatted, it's formatted. Otherwise, new firmware or not, upon every reboot, the bootloader reads the rar-compressed firmware in the NOR flash, lets the chip decompress it, and writes it to memory (that's why it's called SDRAM_image.bin). After that the bootloader jumps to an address in the memory area and the firmware takes control.
5. When we upgrade the firmware on the M6 SL, the difference is that there is no NOR flash on the chip, and that the firmware is stored on the NAND flash, so it doesn't need to be compressed. Upon reboot, the firmware is loaded directly onto memory.
6. The header itself does not have a checksum. This is because we can modify the rar file and still have a working firmware.
My description of the boot process are just guesses... I haven't actually debugged the code (see my previous comment about objdump segfaulting when trying to disassemble the ebn file). But I think they are quite logical. At least maybe everyone already knows that for a fact, but it's just that I'm too n00b and didn't know it
markun: Why you want to change the SST39VF800.dfu? the dfu file is not any kind of firmware, it's like a dll, just a group of functions stay in the SRAM to erase/read/write the flash, it's transfered there and called remotely by the DFU Tool. Samsung's implementation of DFU is not strictly following the USB-DFU standard, there's no suffix part with CRC verification but just the "A5 A5 A5 A5 5A 5A 5A 5A".
Originally Posted by wpyh
3. When we upgrade the firmware on the M3 and M6 TP/SP, the header is stripped off (or copied somewhere maybe), the tail is seeked (the tail basically signals the end of the file), and then the rar-compressed file is copied in its compressed form (i.e. not decompressed).
4. Upon reboot, the bootloader notices a new firmware, and if the player needs to be formatted, it's formatted. Otherwise, new firmware or not, upon every reboot, the bootloader reads the rar-compressed firmware in the NOR flash, lets the chip decompress it, and writes it to memory (that's why it's called SDRAM_image.bin). After that the bootloader jumps to an address in the memory area and the firmware takes control.
The header is never stripped off, it's the 2nd stage boot code! When power on, it will be run in first to load the firmware into SDRAM and jump there.
On a M3/M6SP/M6TP, the header is just the init code following with a decompress function which will extract the RAR part at offset 0x2000 to the ram area at address 0x08000000, it's finished by software, not by the chip. That means, if we don't care about speed, we can skip the header and just write the plain image without compression and let the code run in the rom.
The formatting process is not a part of the bootloader but right inside the firmware, it doesn't touch the firmware area, just clear, rebuild and upgrade the file system on the NAND chip.
On a M6SL, The bootrom will copy the "header" at the first 32768 bytes of the NAND chips into the SRAM and excute it, the "header" includes the NAND flash library functions(block read, data verify and ECC error recovery...), it's more complicated than the case of NOR boot so it's much longer,
markun: Why you want to change the SST39VF800.dfu?
Since the first .dfu file (for example the SST39VF800.dfu) gets loaded into SRAM and then executed, I thought we might replace it with our initial test code. That way we don't have to wait till out test code is flashed and then reboot. Once we have a real rockbox bootloader we want to write it to flash of course (and use the normal SST39VF800.dfu or updateNAND_BE_070831.dfu)
Do you think there is a problem with this strategy?
EDIT:
just a group of functions stay in the SRAM to erase/read/write the flash, it's transfered there and called remotely by the DFU Tool.
Rereading what you wrote again. I always assumed the the flash code was self contained and was just excuted from the beginning of SRAM, but you mean the DFU tool somehow signals the player to jump to each of the routines from the jumptable (before the DFUC marker) at the right time to run the various routines? In that case maybe we should just flash our code.
... or maybe we can just let all entries the jumptable jump to our test routine
markun: Yes, the .dfu file is just a piece of the code, the feature of DFU mode is inside the build-in boot rom, it will chat with the DFU Tools on PC side thru' the USB pipeline, and then parse the command, accept the data blocks, call the NOR/NAND flash functions to burn the firmware, return the error codes. Until total reset, the device is not in your control.
The GPIO usage of M3 is
----------------------------
Buttons
P1.4 Play
P1.0 Menu
P3.3 <>
QT1106
P0.0 CS
P0.1 SCLK
P1.6 MOSI
P0.3 MISO
LTC3455
P5.7 CHRG
P1.3 PWRON
EEPROM?
P3.2 SDA
P3.4 SCL
The LCD driver is connect to the function pin and control by the APB LCD I/F at address 0x3C100000. the audio codec and the FM tuner is link with the native I2C bus at address 0x34 and 0x60-0x68.
What do you mean by this? Does 1 device uses 9 different i2c addresses?
0x60 sounds again like it's the TEA5767 and not the TEA5760UK as it's written on the chip..
btw, the TEA5760UK datasheet is a bit unclear to me, since you see the 8-bit address 0010 0000 where there should have been a 7-bit address. Do you have a different datasheet?
APB = Advanced Peripheral Bus (SFRS 0x3C000000 - 0x3FFFFFFF)
Function pin = Most pins are multiplexed. Each pin of P1 can be configured as GPI(0) GPO(1), Function pin(2) and not used(3). On the other ports, the pin can be selected from more than one functions(2/3/4/5...) besides GPIO in/out(0/1).
The main address is 0x60, but 0x62, 0x64, 0x66, 0x68 are also accessed somewhere in the firmware. It confuse me too. More research is needed.
markun: Why you want to change the SST39VF800.dfu? the dfu file is not any kind of firmware, it's like a dll, just a group of functions stay in the SRAM to erase/read/write the flash, it's transfered there and called remotely by the DFU Tool. Samsung's implementation of DFU is not strictly following the USB-DFU standard, there's no suffix part with CRC verification but just the "A5 A5 A5 A5 5A 5A 5A 5A".
Well, why did it fail, then? This is weird...
Originally Posted by kgb2008
The header is never stripped off, it's the 2nd stage boot code! When power on, it will be run in first to load the firmware into SDRAM and jump there.
On a M3/M6SP/M6TP, the header is just the init code following with a decompress function which will extract the RAR part at offset 0x2000 to the ram area at address 0x08000000, it's finished by software, not by the chip. That means, if we don't care about speed, we can skip the header and just write the plain image without compression and let the code run in the rom.
Oh, I see now how it works.. but can a rar decompressor fit into <8k bytes of code? It seems too small to be true. But if this is true, then we can change the rar decompressor into a bzip2 decompressor :D
What tools are you using to examine the firmware? objdump segfaulted right away, so right now I can't disassemble it.
Originally Posted by kgb2008
The formatting process is not a part of the bootloader but right inside the firmware, it doesn't touch the firmware area, just clear, rebuild and upgrade the file system on the NAND chip.
On a M6SL, The bootrom will copy the "header" at the first 32768 bytes of the NAND chips into the SRAM and excute it, the "header" includes the NAND flash library functions(block read, data verify and ECC error recovery...), it's more complicated than the case of NOR boot so it's much longer,
Well, in theory we can also store the firmware inside the NAND for the M3 and M6 TP/SP, can't we?
markun: I've made a mistake, the chip at i2c address 0x22 is the FM tuner TEA5760UK, the 0x60-0x68 may be some kind of GPIO extender......
Good, then I didn't make the TEA5760UK rockbox driver for nothing Could you check the I2C address of the FM tuner in the M6SL again to be sure it's not the TEA5760UK as well?
Both the M3 and M6SL will check the FM tuner chip at address 0x22 to ensure MANID == 0x202B and CHIPID == 0x5760, so they are all use TEA5760UK. Don't know why the device address is not the "0010 0000 R/W" as the datasheet states, this misleaded me for several days.
An external low current RTC helps to shut down the MCU entirely to save power, and the Philips audio codec is the selling point for marketing consideration and keep away from the noise issue of PCB layout.
Could you check the I2C address of the FM tuner in the M6SL again to be sure it's not the TEA5760UK as well?
Linear Mode
