Rockbox Development > New Ports

Dell Digital Jukebox

<< < (6/7) > >>

zook:

--- Quote from: mcuelenaere on September 29, 2007, 06:59:06 PM ---For people who are too lazy to extract the _PIC themselves: http://www.verzend.be/v/2031877/JB3Upgrade_1_20_0_r_PIC.bin.html
--- End quote ---
I believe the ascii encoding is what the 010 editor calls Intel 32-bit Hex Code (see the Copy As menu).


--- Quote from: mcuelenaere on September 29, 2007, 06:59:06 PM ---@zook: I tried running it through IDA, but didn't came with something usefull. Which processor/architecture do you think it is running ? C55x ?

--- End quote ---
The TMS320DSC24 manual (http://www.archopen.org/tiki-download_file.php?fileId=6), which should be similar enough, states that the ARM core is booted first and that it's responsible of resetting the DSP core.
The ARM core is a Micro Controller Unit, so it would make sense that _PIC/EXT0 contains the ARM boot code.

LambdaCalculus:

--- Quote from: zook on September 30, 2007, 10:12:38 AM ---The ARM core is a Micro Controller Unit, so it would make sense that _PIC/EXT0 contains the ARM boot code.

--- End quote ---

I believe you're right, zook. Why would it be any other way?

zook:
It's been a busy week for me, so I haven't had all that much time to look at this.
However, I'm just one function short of having codified the CENC decoding.
The algorithm is a run length encoding variant. The first 32-bit word of the CENC block is the decoded size, then follows the sequences of encodings. The two most significant bit's of the first 8-bit word determines which type of encoding the sequence is. 0x80 and 0xC0 are repeated character block types (effectively memset's), with different length encodings. 0x00 and 0x40 is the type which I'm missing, I haven't traced it enough to describe it, but it's much more elaborate. My guess is that it's used to decode repeated patterns, but it goes hay-wire in the simulator so I can't say for sure.
Anyway, if any of this sounds familiar to anyone, then please chip in. I've had a feeling of deja vu since I first glanced at the code, but I still can't place where I've seen it before.

As an aside I've looked at the flash related code a bit and it seems like it provides these name mappings: TSIG, BOOT, CONF, TOC0, PFM1 and RESC. I was hoping to find code to decode/decrypt the BOOT block but so far I haven't found any. I'll need to fix the processor module though, there's too many important things missing currently.
I've also found the lowlevel functions which are used to erase or program the flash, so that should make an excellent starting point for working out how flash entries are processed during a firmware upgrade.
The flash functions in the Zen Micro firmware (the latest unprotected version) indentifies and accept 3 different types of SST flash chips. ID: 0xBF and 0x2780/0x2781/0x2782. I haven't cross-checked with the Dell DJ, but my guess is that it's the same. Why else would they accept different types?

mcuelenaere:
In segment003 of FRESC of DellDJ_1_20_03_rk.bin there are a lot of BE EF and FE EB; also some FF FF FF ..
These remind me of the minifs/cfs filesystem described on nomadness;
could this be a (mini-)implementation of this filesystem (e.g. for emergency purposes)?

I tried finding those docs where this is described, but can't find them anymore...
But in the HDD-dumps posted on epiZENter you can also find some BE EF and FE EB's (these are probably boundary markers).

zook:

--- Quote from: mcuelenaere on October 11, 2007, 04:13:56 PM ---In segment003 of FRESC of DellDJ_1_20_03_rk.bin there are a lot of BE EF and FE EB; also some FF FF FF ..
These remind me of the minifs/cfs filesystem described on nomadness;
could this be a (mini-)implementation of this filesystem (e.g. for emergency purposes)?

I tried finding those docs where this is described, but can't find them anymore...
But in the HDD-dumps posted on epiZENter you can also find some BE EF and FE EB's (these are probably boundary markers).

--- End quote ---
Ohh, FRESC does contain a filesystem implementation. I'm not sure the BE EF and FE EB blocks are referenced anywhere, though.
I've gathered a list of the most important functions that I've named in my disassembly:

--- Code: ---00849EB4 RescueModeMenu // Handles the rescue menu.
00849B60  ReloadFirmware
00849C38  FormatAll
00849DAC  CleanUp

0084BA08 Bootup // Is responsible of intializing everything.
0084D65C  System_Init
00800000   Chip_Init
00801A64    Lcd_Init // Device construction and registration.
00804084    Adc_Init // --||--
0080421C    Iic_Init // --||--
00802064    Rtc_Init // --||--
00804734    Mcu_Init // --||--
00809750   Flash_Init // --||--
00848480   Usb_Init // --||--
00808EB0  Ide_Init // --||--
0084D100  ReadJukeAndSplash // Loads the player software and the splash bitmap.
0084C130   cenc_decode // Decompresses the player software.

0084A5BC ProgressUpgrade // Handles the firmware archive, which is stored locally as upgrade.jrm.
0084C1AC  ParseCIFF // Parses the firmware archive, validates it and stores each entry according to their type.

00800164 Device_Register // Is used to register a device class instance.
008004AC Device_Open // Is used to access a device class instance.

00806804 Object_Init // Based on how these functions are used, I'm guessing that they're synchronization primitives. But I could be wrong.
00806854 Object_Lock
00806880 Object_Unlock

0080304C _fopen // Provides access to the filesystem.
00803610 _fread
00803BE5 _fwrite

--- End code ---

Im including the IDA plugin that I've been using, it's far from perfect but it's a step in the right direction: http://www.mediafire.com/?1mt2xznax33
Once again, the source is included along with a pre-compiled binary for IDA 5.0.
Once you've copied it to the plugins directory and loaded your FRESC file, you need activate the plugin by selecting Edit->Plugins->TMS320C55 processor extender.
It will extend the processor module to handle the two previously mentioned instructions, but it doesn't output the instruction text properly, so sometimes parts of or the whole instruction line is missing.
There's two more instructions which aren't handled at this point, because I haven't been able to find any documentation on them.
I plan to fix as many of the issues as I can once I've gotten the player software fully decoded.


Regarding the CENC encoding. I've gotten my code to the point where it produces the same output as the simulator in single case use. However, there's some logic or indexing error(s) in the code, which derails the decoding. So there's still some work left.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version