Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
kugel.:
--- Quote from: RockRabbit on December 18, 2008, 04:55:23 PM ---Can you tell me where the experimental Rockbox code is? Or is it simply the latest version in trunk?
--- End quote ---
Yes, the SVN is developement and experimental at once. Only for release the code is branced.
--- Quote from: RockRabbit on December 18, 2008, 04:55:23 PM ---I might like to attempt this for the fun of it, even if my code is not used. However is there a proper way to do this, e.g. is there someone who is delegated to do this kind of thing?
--- End quote ---
Not that I know of. But just look at the source and the target tree system, and even the SVN history when other ports got their initial commit. It's quite easy.
--- Quote from: RockRabbit on December 18, 2008, 04:55:23 PM ---I have a copy of the current version of mkamsboot, and it looks fairly straightforward (peels of laughter sound from around the world) to add some c200 code to detect the USB cable. Presumably I could mod that and test it even without anything else rockboxy being on the player.
--- End quote ---
As far as I know, mkamsboot doesn't contain the dual boot. It's the dualboot.S files in there which contains the dual boot functionality. You need to edit that too to have proper dual boot. mkamsboot handles patching your OF with the dual boot and the compiled bootloader (see here why dual boot works independently of the bootloader).
--- Quote from: RockRabbit on December 18, 2008, 04:55:23 PM ---One last question - is it possible that the other buttons are hooked up to GPIOC and I simply stuffed up the code when I was looking for them? Or in other words, is there a possibility that some other setting is interacting with the port that stopped the other pins working?
--- End quote ---
It's possible. And it doesn't necessarily suprise me if there are buttons you didn't find. On the Fuze, I haven't found a single button using the method you used, even though there're at least 6 buttons directly attached to GPIO. You can actually feel lucky that you found so much.
--- Quote from: RockRabbit on December 18, 2008, 04:55:23 PM ---One even laster quesrion - Is it possible to dissassemble the OF (C200PA.BIN) using arm-elf-objdump?
--- End quote ---
Yes. You can use this command: arm-elf-objdump -D --target binary -marm C200PA.BIN --start-address=0x400 --stop-address=0x20000 -Mforce-thumb > disasm.txt
--start-address skips the firmware header which doesn't contain code.
--stop-address=0x20000 limits the disassembly to not go beyond that adress, so that you don't get the whole libraries(codecs,drm stufff etc) disassembled, but only the main firmware(the interesting part). Note that the output is thumb code, not ordinary arm code.
gabe565:
Kugel: OK, I was just wondering if you messed up or if the wiki was messed up! ;D
Until we know if the c200 uses a keyscan method like the Clip and m200, I'll just add the right button to the hardware mappings page as C6.
EDIT: Nevermind, Kugel covered everything I said except he worded it a little better...
RockRabbit:
Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?
gabe565:
I don't know of this happening in any Sansa devices before, but it is possible. I don't know how you would find them this way, do you?
kugel.:
--- Quote from: RockRabbit on December 18, 2008, 07:00:47 PM ---Is it likely that some of the buttons have been wired to output pins on the IO ports, such that the button must be "energised" by setting a particular pin to output before it will be able to signal the input pin? this way the buttons would be hidden and much more difficult to locate? Has this happened before?
--- End quote ---
That's surely possible. You're trying to read without anything being initialized by an OS. You're in a state between ROM and an actual bootloader of Software. It might be that e.g. the lcd needs to be initialized which itself then makes it indirectly possible to use other GPIOs and stuff.
And again, I didn't found any button for my Fuze with this method.
We actually have enough now for building a bootloader, so I wouldn't focus too much on this any more. Our bootloader will already have system initializations and hardware setup (kernel_init(), system_init()) that is already nicely implemented for the other AMS targets.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version