Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
I continued analyzing the M200 4.1.08 firmware and understanding more stuff in it, though I'm far from complety understanding the whole firmware. Nonetheless, here we go for an update on my findings. ;D
For consistency, I will document every addresses in here relative to the file beginning except where otherwise noted.
Firmware file overview
The firmware file is divided in a bunch of blocks as we already know. In the M200 firmware, there seem to be 32 blocks:
Block IndexAddress in the fileDescription00x000000Firmware header10x000400Firmware2 to 180x400 + (Index * Block Multiplier)Library blocks190x21AC00Empty library block (filled with 0xFF)20 to 26Unregular, read belowResource blocks270x4D5400Empty resource block (filled with DEADBEEF)280x4D5600Unknown data block290x4D5800Unknown data block 2 (only contains 0xDF0 at 0x4D5800)300x4D5A00Unicode certificate data310x4D6800Empty ending block (filled with DEADBEEF)
Firmware Header Block (0)
Nothing newer than what is already known.
Boot Code Block (1)
I can confirm that this block actually contains a bootable code. So this code is loaded at address 0x0000000 in whatever ROM/FLASH/stuff that the AS3525 can boot. This code initialize some stuff like the AS3525 clock generation unit, etc. There is MUCH more to analyze in this block since this is where we'll find the most info about the V2 design (peripherals addresses, how to initialize the devices, etc.).
The following exception vector table (that contains jump instructions, which is standard for ARM vector tables) is present at 0x400:
AddressFunctionHandler summary0x400ResetMain code at 0x4B80x404Undefined instructionInfinite loop0x408Software InterruptInfinite loop0x40CPrefetch AbortInfinite loop0x410Data AbortInfinite loop0x414ReservedNOP0x418Interrupt RequestInterrupt handler at 0x84680x41CFast Interrupt RequestInterrupt handler at 0x8468
Library Blocks (2-18)
The 17 library blocks are tagged with the following "library names":
Block IndexLibrary Name2usb_functio3mp3_decoder4otg_functio5wav_codec6acp_decoder7aud_decoder8drm10_nonpk9drm10_pkcpt10drm10__Init11wma_decoder12wma_decInit13wma_decPlay14drm10_InitT15drm10_host_16wmaPDDRMini17wmaPDDRMper18sd_reload__
The following (improved) table describes the library blocks header (offsets are relative to each block base address):
OffsetValue(s)Description0x00Library nameOffset to the library name0x04Library base addressBase address of the library0x08Library end addressSeems to be the library end address, but seems to include extra space(?)0x0CBlock effective sizeSize of effective data in this block0x10Unknown valueStill unknown. Needed space for variables?0x14Exports countNumber of publicly exported functions0x18ExportsAn array of [export count] addresses which points to library functions
Resource Blocks (20-26)
These blocks are still mostly misunderstood, but they seems to contain various resources (localized strings, etc.). Resource blocks size is understood to be the next 0x200 bytes boundary after the block effective size. For example, a resource block with an effective size of 0x1234 would end 0x1400 bytes after the block beginning.
The resource blocks have the following header:
OffsetValue(s)Description0x00Block effective sizeSize of effective data in this block0x04Resource IDThe more plausible signification is a resource ID number0x08"HEADER"The "HEADER" ascii string
So that's about it for tonight, I hope it helps understanding the firmware file format. I'll try to continue understanding the file format... Or if more experienced developpers thinks I could help somewhere else, feel free to suggest!
Edit: Changed the "Boot block of the firmware" to "Firmware" as block 1 seems to be the whole firmware (without libraries)
Bagder:
I'm curious why you think that block 1 is "boot code". Why isn't it simply the entire firmware, apart from the lib stuff that is provided in the other blocks?
Also, given this description I figure a custom firmware could easily just be block 0 and block 1.
atomikpunk:
Lambda: Yes I did however I did not have time to ask for write permission yet. You are right, this kind of info is best stored on the wiki, though I think that maybe we should dedicate a separate page for the V2 firmware stuff if we don't want to monopolize the M200 page for the firmware ;D
Bagder: You are right, what I really meant to write was that block 1 is the block that is effectively run by the hardware on boot. Though I didn't analyze everything in there, it is reasonable to think that is much more than just a bootloader in this block. I also think that this block could hold the rockbox bootloader and this should do the trick. Probably that we will need to follow the firmware file format nonetheless, for example, on a first pass, only substitute block 0 and 1, then on a second pass completely the firmware file only to include required blocks.
Can someone reading the forums and with wiki admin access give me write access to the wiki? Else, I'll try to poke someone on IRC tonight...
Bagder:
Seeing that we don't have a recovery mode, we need to be very very careful when trying to insert code and run it on the v2 models, so yes we should make the Rockbox bootloader get inserted in the block 1 part, and based on some magic (like if we press a key, assuming we can easily read that without too much code) the code should proceed as normal and not run the Rockbox code. Thus we minimize the risk of bricking the device due to putting a bad image onto it.
This all of course requires that we now know how to generate a complete firmware upgrade file, so that we can insert a chunk of code in block 1 and generate a new file to upgrade to. Given the last updates of the firmware format, there's only that checksum in the header for block 1?
atomikpunk:
If you don't mind, I'll create a specific wiki page about the V2 firmware format here and link every v2 port pages to it. It will alleviate port pages from firmware details and still provide info to those interested... And since many Sansa devices use the same firmware format, I guess that a central page about it wouldn't hurt... What do you think?
Also based on Bagder idea, I guess that looking into the current firmware for button sensing would really help so I'll aim my analysis around that...
Calculus: thanks for the wiki access, I'll have a look at it tonight. :)
Bagder: I guess that should do it... There are still a couple of unknown fields in the firmware header, but they seem to always be the same so I guess we could use those without much damage...
I'm pretty new to the "firmware replacement scene" so I take any advices :) But since I really don't want to brick my device, I'd prefer if some other brave souls would try it before I do ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version