Sandisk Sansa View

[midgey]

Just to add to that, I recently bought a View and can confirm that the OF will take our firmware and the bootloader will indeed attempt to load it. I compiled the e200 bootloader and resigned it with the dummy key then encrypted it with the View key. After the Sansa logo, the LCD will go white then purple and fade to black. This suggests that nothing is controller the LCD and our code is running.

I'll poke around with the bootloader and disassemble it over the next week. No promises because I know very little about disassembling and other projects have priority.

[zman977]

ok ill see what i can help out with. This will be a little of a learning experience for me so...

hey by the way i wonder how close the fuse is with the view? ive read that a few people tryed the e200 boot loader just to try it on the view and could get some where with it and i wonder if the v2 and fuse have any thing similar with the view. if the devs have a boot loader out yet for the fuse that is.

edit**
never mind they dont lol it was a thought though

[saratoga]

hey by the way i wonder how close the fuse is with the view?

Theres basically nothing in common except the DAC.  The View is based on an updated PP chip,  the Fuze an AMS chip.   

if the devs have a boot loader out yet for the fuse that is.

edit**
never mind they dont lol it was a thought though

There is a bootloader out there for the Fuze, but since the Fuze has essentially nothing in common, you might as well expect an Ipod or Cowan bootloader to work.

[obo]

I recently got a "broken" View from ebay, which just needed recovery.  I've added documentation to the wiki describing the hidden partition layout - there are a few differences from the e200.  The firmware section starts with the magic "CPUI" followed by 0x60000 instead of "PPMI" followed by 0x20000.  If enough progress is made, Sansapatcher will need changing to cope with this (plus a little re-arrangement to allow for a third type of mi4 Sansa).

I'm struggling trying to run custom code on the View (a modified e200 bootloader)

I can modify an existing firmware file (editing plain.bin in this case):

Code: [Select]

mv firmware.mi4 firmware.orig.mi4
./mi4code decrypt -s firmware.orig.mi4 plain.bin
./mi4code build plain.bin plain.mi4
./mi4code encrypt plain.mi4 plain.enc.mi4 view
./mi4code sign plain.enc.mi4 firmware.mi4
but doing something similar with bootloader.bin:

Code: [Select]

./mi4code build bootloader.bin bootloader.plain.mi4
./mi4code encrypt bootloader.plain.mi4 bootloader.enc.mi4 view
./mi4code sign bootloader.enc.mi4 firmware.mi4
fails, the recovery screen displays "Bad File copied" as it loads the files from the 16Mb RAM disc.  Does anyone have any ideas what I am missing?

[j8048188]

was the new checksum calculated correctly and inserted into the file?

[crackmonkey421]

You may need to sign before you encrypt instead of after; that's what I do, but it may work your way too.  Maybe the "offs_id" needs set when you build.  The firmware.mi4 for v1e200 rockbox gets accepted, so it must be similar to what you would do on an v1e200 to build an mi4 from a bin.  I'll try some things when I get home.

Edit:
When you modified the original firmware.mi4, did you change the file size?  Just wondering.  I looked into it a little more and the commands look correct from what I've read.  I'll try it to write and compile some custom code from scratch and build it in the same way.

[Chronon]

I trimmed some off-topic posts.  Please read the sticky and post in this thread only if you're contributing to the effort to port Rockbox to the Sansa View.

[obo]

You may need to sign before you encrypt instead of after; that's what I do, but it may work your way too.  Maybe the "offs_id" needs set when you build.  The firmware.mi4 for v1e200 rockbox gets accepted, so it must be similar to what you would do on an v1e200 to build an mi4 from a bin.  I'll try some things when I get home.

Edit:
When you modified the original firmware.mi4, did you change the file size?  Just wondering.  I looked into it a little more and the commands look correct from what I've read.  I'll try it to write and compile some custom code from scratch and build it in the same way.

With the OF:
the order in which I sign and encrypt doesn't seem to matter, both worked.  Stripping the OF (mi4code decrypt -s), and building it again results in a larger file, but it still loads.

was the new checksum calculated correctly and inserted into the file?

There is a checksum, but I'm not sure if it's correct or not (since it's a CRC with a custom initial polynomial.. I've haven't yet checked this).  But since the modified OF worked, I'd have to presume that the MI4 header is being setup in a way that the device accepts...

Edit:  The OF uses 01030100 at 0x4 (default mi4code build option), and 0xEC at 0x2E4 (the default build offs_id).

[crackmonkey421]

Yea, everything you've done looks correct as far as I've read.  I got "Invalid Image" after it restarts with a very small block of custom code.  I'm not sure what's causing this either.  I would think someone with v1e200 experience (maybe even v1c200) might know because the v1e200 rockbox firmware is accepted and ran, so the v1e200 probably has similar issues that were accounted for in the rockbox firmware.  One thought is to chop up the OF to figure out what parts are required to get it accepted and ran.  Another idea is to take a closer look at the e200's mi4 source code to get ideas or even to build from.

[obo]

Well, it works if I copy the file over in MSC rather than recovery mode - I guess the checks are stricter at that point, and required a patched bootloader?

The modified bootloader I used fails to write anything, so I guess the SD interface is different or at another location.  I've found a few registers in the disassembly, but have yet to identify what any might be.

IRAM seems to be at 0x40000000 (normal PP), and I think it's 128K.
I2S init is at 0x70000000 (normal PP)
Other ones to look at are 0xc5000000, 0x7fc00000 and 0x80000000, but I'm sure there are more!  This is proving to be quite a learning curve.

[zman977]

The modified bootloader I used fails to write anything, so I guess the SD interface is different or at another location.

So we need to find the location of the SD interface? Which would be a good place to look; the bootloader.rom or the firmware.mi4?

[saratoga]

The modified bootloader I used fails to write anything, so I guess the SD interface is different or at another location.

So we need to find the location of the SD interface? Which would be a good place to look; the bootloader.rom or the firmware.mi4?

It has to be in both, but the bootloader is a much smaller file.

[Y-brik]

My original post seems to have been deleted, so I'll keep it short and sweet. I have a busted View (Screen cracked). All the boards work fine, I will gladly mail it out to whoever needs a backup in case of a bricked View

[obo]

For my GSoC work I've been looking at both the bootloader and the main firmware (I've been using version 01.01.06a, available at http://daniel.haxx.se/sansa/view.html).  I'm finding a lot of references to registers which match those for the PP502x series, specifically:

Mailboxes (MBX_BASE)
Interrupts (CPU_INT_ & CPU_HI_INT_)
Timers (TIMER1_ & USEC_TIMER)
Processor Control (CPU_CTL)
Cache Control (CACHE_CTL)
GPIOs (up to at least GPIOI)

What I am not finding are any references to the registers for MMC/SD or either of the two LCD base/bridges, which has me a little worried that these might be completely different on this target.

Any advice, guidance or even confirmation of what I've found so far would be greatly appreciated!

[yelped]

Well, about the SD Interface I don't know, but since the LCD is a different size and resolution, I would expect it to be different.