This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#6524 - Sansa E2x0 emulator
Attached to Project:
Rockbox
Opened by Toni (ahellmann) - Wednesday, 10 January 2007, 22:43 GMT+2
Last edited by Alex Parker (BigBambi) - Sunday, 06 June 2010, 00:25 GMT+2
Opened by Toni (ahellmann) - Wednesday, 10 January 2007, 22:43 GMT+2
Last edited by Alex Parker (BigBambi) - Sunday, 06 June 2010, 00:25 GMT+2
|
DetailsHere is the source code to emulate Sansa firmware on a PC.
Until now I have done following components (rockbox used functionality only!): - emulate cpu - emulate ata (read only functionality) - emulate display - emulate memory - emulate keys - emulate timers - log the executed code to disassembler file (including rockbox.map infos) I can run the compiled rockbox.bin and play some games. :-) It is still very hackish, but works sufficiently to get an idea, what the original/rockbox firmware does (unknown address access, program flow, timings). Hopefully this also gives some hints, how the DAC can be controlled (not in the near future). Not supported yet: - thumb code - coprocessor - firq / audio Untested: - audio codecs Input files needed in the emulator executable directory: - partition.bin from the sansa - rockbox.map (for rockbox binary) - rockbox.bin (or of.bin from sansa) Output file: - disassembly.txt (logs the last n instructions in the instruction loop) I compiled under MSVC, so be aware to get some porting problems, if you use another compiler. Toni 
sansa-emulator.zip
(14.8 KiB)
|
This task depends upon
I used MSVC6.0 instead, which provides the complete package. Borland Turbo C V5.x would be
also ok. I have no experience with other IDEs. If you want to use a free compiler, why not
try to port this software to the VMware SDL compiler. You know, that you can compile
rockbox simulators? All necessary code is there (graphics, message loop, key input) waiting
to port this code. But I don't know, wether the VMware includes a reasonable debugger.
Anyway, since i don't have a Sansa to dump a partition from, would it be possible for you to post the partition.bin file you used? (Assuming you have a relatively small partition you use for this, and not a whole 4 or 8GB one).
Now at least the mp3-codec works as expected. Of cause you will get no sound.
- And I added the windows binary for playing around:
Perhaps the build of rockbox I'm using is incorrect? Can I combine any rockbox.bin/rockbox.map with your partition or do they need to be synced to specific cvs versions? (Basically, what do you actually read out of the partition file?) Also, is there a good way to edit the bin file?
was only for testing this specific codec.
Basically the mp3-codec is included in the 'partition bin'. No need for external linking.
To read the output, I hacked the data-stream at specific code addresses.
You can use any rockbox.bin with the attached partition.bin. You only have to pay attention
to a possible interface change in the codecs/plugins. This can happen at any time. On
the real target you will face the same problem: You cannot simply update 'rockbox.e200'
but you have to update the whole .rockbox directory. You will get a splash screen in
this situation.
The emulator reads all info from the partition.bin: mbr, config-sector, fat-table, files
It would probably be helpful for reverse engineering other portalplayer platforms.
Some major parts are still missing though: thumb code execution, dual core support, documentation to make it more
usefull for others. I am currently working on the first, because I think already the bootloader does a lot of
initialization (at least on the sansa).
When I have finished this, I will check again, wether I can reach the standard sansa menu display
(until now I only get the sansa startup screen, then the same code is executed over and over (waiting for
the cop to show up?).
I don't know exactly what is needed for a generic emulator. There is already the separation between general
code/memory and specialized registers/functionalities, which can widely vary between the different targets.
I can do more code cleanup, give input/output options. And to my understanding to run this emulator only
makes sence together with a decent debug environment. I don't intend to add memory screens, disassembler
screen, breakpoint support and other fancy stuff to the emulator.
- now executes thumb and arm code
- all registers mapped in a consistant way
- minor code cleanup
Now the emu runs the original bootloader (bl.bin) until switching to the firmware file.
With i2c capturing it should be possible to figure out, how to
- shutdown (if hold switch activation is known)
- battery status (I added a dump of the i2c traffic for this in the zip)
I'm having trouble getting this to run. My build freezes after the Sandisk logo. Could you unzip it and tell me what files I'm missing?
So far, all I've done is edit paths to point to the files in the zip (instead of global paths) and of course I added all the files I saw mentioned in the the source.
You can run the emulator with three input files:
1. bl.rom: 'hangs' at the try to switch to the firmware file)
2. of.bin: 'hangs' at the attempt to start the COP)
3. rockbox.bin: runs complete rockbox (as implemented for now)
So it is normal, that you don't get behind the startup screen, when running the bl.rom or the of.bin.
The next tasks for the emulator will be:
1. get a working flow from the bootloader into the firmware (not so hard)
2. add COP support (will be difficult)
I cannot get it to decode the Mp3 though. It just sits at zero percent (but doesn't freeze). The codec buffer has a few percent read in, and the PCM buffer is nearly full. Is this normal or do I need to change something?
gcc -o sansa_emu.exe *.c -lgdi32
However, I get these errors in the GetTicks function:
sansa.c: In function `GetTicks':
sansa.c:15: error: parse error before "__emit"
sansa.c:15:16: invalid suffix "Fh" on integer constant
sansa.c:16:16: invalid suffix "h" on integer constant
But it seems to work ok without that function (I don't see where it's used).
Eventually I want to integrate the cache data with the .map parser and have the emulator print out statistics instead of raw data. That should be fast enough to actually be useful. But that might take a while, so I'm tossing this out in case anyone wants to play with it until then. If you're interested in actually profiling something, I suggest modifying the logMiss() and logHit() functions in emulator.c to only log the address of the code you're interested in. Otherwise you'll have 300MB of bootloader logs to dig through :)
here is my first attempt to port it to sdl. It doesn't do anything right now
I have to figure out what all the calls to windows.h do
if anyone wants to look at it, or help me out if they can.
you will need the sdl-dev libs
Read me.txt has a short log of what I changed and why, along with many todos
For what its worth, I am slowly working on the memory profiler here and there. Finally got it to spit out function names instead of memory addresses.
I still plan to get the original code running.
To do so, I have to get the cop emulation running, which is tricky in several aspects.
So don't expect this step soon (if ever).
I succeeded in running the boot.rom together with rockbox bootloader and firmware, but
trying to run the original PP5022.mi4 fails in the descrambling code. There seems to be
a bug in the cpu emulation.
The logfile includes all register reading/writing from the sansa bootloader + sansa us-firmware.
The COP has been disabled for this purpose, according to my investigations there is no impact from the COP during startup.
The logfile shows:
- the startup bootloader sequence,
- the startup firmware sequence
- up to dma reading 10 x the mbr sector
I have removed following register addresses from the logfile (for size reduction pupose):
- USEC_TIMER
- CPU_CTL
- CPU_INT_STAT
- PROC_ID
Here is the complete log (with transition from bootloader to firmware).
The bl.rom I used here is 392.888Byte, probably 14.Jan.2007?
The OF.BIN is 5.419.520 Bytes
Unfortunately the interesting parts (the codecs) need correct COP support,
which is not yet implemented correctly.
I now mainly understand, how file dma is working in the sansa firmware.
Also some interrupts work well.
To make the emulator run the original sansa code, you now need a complete image of the flash.
To run rockbox firmware, you need to switch the CPU_INT_STAT definition. (see sansa.h).
Don't be surprised about the strange rockbox colours, this is because the display
is configured for the sansa firmware now. The latest rockbox firmware unfortunately
breaks the emulator. I have to investigate the reason.
about proper initialization of LCD to avoid "screen garbage" as described in
FS#6896?can someone tell me pls how can i run sansa emulator on pc (windows) step-by-step? Thanks
The binary kept crashing, so I removed the "dict.rock" related code from WinMain, rebuilt it with Cygwin and put a ROM image from my iPod as "of.bin". It did quite a bit of firmware initialization and then got stuck in a loop. I patched the firmware image to not do Broadcom initialization, and now it's stuck on some I2C stuff. I guess I should work on I2C emulation now. The main thing I want to do with it now is to find how the bootloader uses IDE0, because it's faster than Rockbox.