Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
I found something very interesting tonight about the OS run by the sansa. It seems like it uses Segger's EmbOS. I found at least one evidence of this in the signature of the tasks creation routine. They are particularly recognizable and they are perfect match with the homologous routines in EmbOS. However, I still don't know the compiler used as EmbOS supports multiple compiler environments...
I hope it'll make analysis much easier by having routines documentation at hand...
I'll try to update the wiki when I can so others will be able to keep up to date with findings (and possibly contribute). Until then, good night ;D
embrion:
You rock :) I can't wait to switch my Nano to Sansa Fuze :D
Austrian hardware + German OS. Makes sense :)
My findings:
1. As AS3525 is ARM9 than according to http://www.segger.com/emboscpus.html , You got 6 possibilities. At least KEIL got very nice simulator, so we could test a more or less simple code (check memory jumps and stuff might be useful I think but I might be wrong because I did embedded only once in my life at school)
2. Those trials on Segger's site are only add ons for compilers but got included 2 very nice docs about ARM7/9 usage with embOS. I believe there shoul be trials of those compilers on manufacturers sites. At least Keil's uVision got trial version.
3. KEIL is very popular so I'd check it in the first place + 1 got some god feelings about it.
4. http://www.segger.com/jlink.html (a lot of text + some screenshots = might help with flash memo layout and/or jtag pins and/or anything else)
5. I googled some guy's resume:
--- Quote ---Worked on basic radio functionality for a prototype of the latest XM radio using ARM assembly, C, C++ running under Segger's embOS RTOS. The CPU is an Arm922t core as part of a System-On-Chip built by Austria Microsystems (AS3525)
--- End quote ---
atomikpunk:
Haha thanks for the great words.
Yes I downloaded trials of the embOS and the package includes a very nice doc, at least providing most (if not all) of the API with signatures, description, etc. Very valuable :)
What I would suggest for finding out the compiler used is to compare C runtime and C library output from the various compilers with the one present in the firmware. I already found out what seems to be the strncmp function in the firmware so if someone could provide with the assembly output of the various compilers, we could compare with the firmware and see which one it is...
Anyone willing to look at the firmware, feel free to contact me via private message so we can get in touch on jabber/msn/icq.
Edit: After looking a little more into it, it seems more and more possible that EmbOS version 3.32 (or earlier) was used. I'm coming to this conclusion from the structure members that moved between versions and the one that truly match the M200 4.1.8A firmware looks like EmbOS 3.32.
Edit 2: (Damn anti-double-post) After looking at the GPIO ports usage in the firmware, it seems to me that the buttons reading is done in a keypad-like manner using port A. A[3:0] seems to be used as inputs while A[7:4] seems to be used as outputs. The routine at 0x32B4 (in the M200 4.1.8A firmware) seems to be the scanning routine, checking all column/rows combination and thus giving out a 16-bit mask of the "keypad". This would also explain why Daniel said that there are switches connected to resistor "networks".
That being said, I guess that it would be interesting to: 1) be sure that this button reading method is used on all V2 sansas, and if not, what is the button reading method for other models, and 2) identify which buttons are connected to this "keypad" and which one is where. Once we are able to recognize buttons, it will be possible to create dual-boot images :)
embrion:
Good thinking :)
If there will be any problems with identifying which button is which, than You could always set official firmware to boot as default without key combination, Rockbox as alternative when button press and hold + use hit and miss method for finding correct key code by trying different codes in boot loader and pressing always the same physical key :) It's a lot safer approach as long as boot loader won't brake possibility to boot official firmware :)
atomikpunk:
Well good and bad news this morning.
The good: I was able to run linuxstb's sleep code on my M200.
The bad: There is a place in the code where the GPIO pin A3 is used as an input and it looked like a button to me. So instead of trying to implement the scanning routine for the "keypad" buttons, I thought it would be easier and safer to try to look at one GPIO directly. So I coded a very simple routine that:
1. Enable the GPIO hardware
2. Made port A an input (since all pins are input, except in the keypad scanning routine where A[7:4] are made outputs temporarily, then back to inputs)
3. Read pin A3
4.a. If the pin read 0, then wait for 0x500000 units (which correspond to ~5s in linuxstb's code)
4.b. If the pin read 1, then don't wait
5. jump to the original firmware reset handler
I don't know why, but my M200 is bricked now. I looked and looked at my code, then loaded it in the disassembler to be sure that it was ok, also looked at my automatically-generated routine graph to be even more certain that nothing was wrong, but still there is something that I missed... :'(
It's shocking but on the other side, I knew it was risky to try so I learned from my mistake... But the problem now is I don't see much interest in pursuing my work on this since I don't have a player anymore and I don't think I'll be getting another in the near future... But nonetheless I think I'll continue reading (and posting) on this forum, at least for a while, who knows what can happen (JTAG anyone? ;D)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version