Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
daniel_at:
Because a BGA hides all its pins beneath the package: http://flickr.com/photos/90053035@N00/2494642819/in/set-72157605072639496/
So you have to desolder the chip (which only works if you heat up the whole PCB so that the solder melts, which in turn destroys the device) and than make some measurements. But you can only check connection to GND/VCC or other "well known" nets.
The board from my e200 has a lot of vias under the chip - which may contact some of the pins - but you cant say sure which via goes to which pin - only make rough guesses based on the location of the via.
saratoga:
You can get to maybe a dozen or two of the bga pins out of 224, so testing isn't exactly easy, and a lot of them are boring pins (JTAG).
linuxstb:
atomikpunk.
Firstly, I think it would be useful if you could share some of your disassembly findings. It would also seem to make sense for everyone working on disassembling V2 firmwares to use the same version.
Whilst I'm sure replacing (for example) the mp3 codec with our own code could work, it's far from ideal.
Firstly, it will make development much slower (you'll need to start the original firmware, and play an mp3 file in order for our code to be run.
Secondly, we're running our own code within the environment of the OF - we don't know what other threads may be running at the time (or how the OF multi-tasks), so we would need to make sure we don't corrupt anything currently in use by the OF.
Thirdly, in some ways it's a disadvantage to be running within the initialised environment of the OF - it means we don't know that our code will run reliably when we move to replacing the OF firmware completely.
But having said that, it's also an advantage to be able to read the hardware registers after they've been initialised by the OF - so we can ensure Rockbox does things at least as well.
So in conclusion, trying to run code by replacing a library function would be useful, but I think we still need to find a way to extend my current method of inserting code to work with larger bootloaders.
atomikpunk:
Hi linuxstb,
I have no problem working on the same firmware version. ATM, I'm on the M200 v.4.1.8a but I wouldn't mind too much changing to another one. However, keep in mind that much of my work up to now would be "lost" in the sense that I would need to re-analyze most of the routines. If you guys don't mind looking at this firmware version (M200 v.4.1.8a), I'd be glad to share my findings. In fact, most of what I've found wasn't published exactly because I think it wouldn't be useful for others not looking at the same firmware version as I do.
Concerning the library replacement, I also think it is not the ideal solution. However, a big plus is that we could separate the job: one team beginning to work on missing drivers and the other team keep looking at the OF. And the biggest gain would be to have a lot more space to put custom code in because library blocks are much smaller than their "reserved" space (much smaller than for example 0x1E000 bytes size of a library block on the M200).
But you're right, we don't know if, and if so, how the kernel do multitasking and there is risk there. However, as far as we don't try to play a file of the particular format, I'm pretty sure there won't be any problem. And still, we could re-flash the device with the OF.
I too think that's a temporary solution helping us to develop while we also try to understand the firmware and figure out how we will be able to put rockbox in...
Edit: for those of you interested, I put up some more disassembly details on the SansaV2Firmware wiki page. For the moment it only contains an overview of both the reset and irq vectors, buts also some pointers in the code where I think the library blocks are loaded. Those with the appropriate tools may look there and see if they can provide more info about it. I already have some more details but bed is calling me for the moment, so I'll update when I'll have some time... Have fun until then :)
beambot:
Today I also tried to connect my clip to a jtag with the pinout given by hth and it didn't work (to solder the wires wasn't funny ;D). Means the jtag pinout of the clip isn't the same as for the e200, the pinout is wrong or there is another' switch' to enable the jtag port. I tried some cable combination with my breadboard without success. I will take another look to it tomorrow...
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version