Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (19/386) > >>

atomikpunk:
Hi peeps,

just a little update to show what I'm looking at.

I can now confirm that the "libraries" are effectively dynamically loaded as I suspected. And the code clearly shows the values we also find in the libraries header (load address, variables address, library size, variables size, etc.). This also explains why multiple libraries loading addresses overlap. I can easily be understood because most of the overlapping libraries provides the functionality which can't overlap. For example, the wav codec library is loaded at the same address as the acp decoder library.

I also think that I found the routine where the libraries are loaded but I still can't understand it. This is my next step because it may help understanding the library loading process and eventually evaluate if it is possible to expand the firmware file and how to do it.

From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code... And since we wouldn't have the OF in backup neither... So maybe the next big question is: is it possible to grow an image file bigger than 0x500000 and still be accepted by the firmware loader?

That's about it for the last couple of days.

Any news from JTAG or other findings?

Bagder:

--- Quote from: atomikpunk on May 21, 2008, 12:39:07 AM ---From what I understand, if we would like to "bypass" the OF, we could simply use the whole firmware file as we wanted, not bothering with the libraries and all that stuff. I don't know how we could get back to the OF however as we don't know where is the firmware upgrade code...

--- End quote ---

Right. We want (or need) dual-boot ability so we should only insert enough code in there to be able to load Rockbox from the NAND and start it. IMHO.

atomikpunk:
Hi,

could someone probe the xpc pins 0 to 3 while unpowered? On the 224 pins BGA package, those are E5, C4, F4 and A3 respectively. They should be tied up to GND or VCC. This could help understanding the booting mode. xpc0 tells about internal or external memory (GND is external, VCC is internal bootloader). xpc[3:1] is for internal bootloader mode.

Also, if xpc0 is tied pulled high (internal bootloader), it would be interesting to probe xpa0 (pin D5) and see if it is connected to a button. If that is the case, then maybe there is a "firmware update" mode accessible...

daniel_at:

--- Quote from: atomikpunk on May 21, 2008, 10:19:09 PM ---could someone probe the xpc pins 0 to 3 while unpowered?

--- End quote ---

Hm - that would only be possible on a defect device, or at least it would be defect afterwards... Its not possible to measure (reliable) any of the pins from the BGA. There are some vias which might conntact any of those pins, but you can only make rough guesses based on their position.

So if anyone has already bricked any of the devices stated in the Subject, he/she may connact me to and maybe it will be possible to make some experiments...

Daniel

atomikpunk:
Hmmm I'm not sure why you say the device would be broken afterward. It's only unpowered probing, no? Like you find the ground, place a probe there, then probe the lines I listed and check if there is a pull-up or pull-down, then do it again with vcc?

Just for the record, I think I found a routine where there is GPIOA input reading on at least 4 pins of it. It is done in a quite strange manner however so I'm still trying to understand it. I'll keep you informed.

Navigation

[0] Message Index

[#] Next page

[*] Previous page