android
Go Back   abi>>forums > MP3 Players By Brand > SanDisk Sansa > Sansa View > Sansa View Hacks

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 04-02-2011, 10:32 AM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default I've successfully got e200tool identing my bricked View. Please help me finish it!

Code:
Falcon@VirtualXP ~/e200tool
# ./e200tool.exe init
e200tool v0.2.3-viewmod (c) by MrH 2006, 2007
Searching for device 0781:0720 ... found!
Setting configuration 1...
Success!
Attempting to claim interface 0...
Success! Using interface 0.
Initializing USB stub (4780 bytes) ... done!
... And then the View drops off the USB bus but does nothing more. I think we're on to something though... something probably quite big.

I've had a bricked View sitting in a change drawer for over a year now. I used to have some issues with power management and hanging, that no amount of reformatting/resetting would fix... so I decided to try completely erasing the drive using a hex editor, so it'll completely re-initialize itself from scratch. Before doing so, though, I backed the entire physical address space up to a flat file, in case I messed something up. Yep. It bricked it. Apparently the boot ROM is accessible in user-space, so clearing the partitionable area also destroyed its boot ROM. HOWEVER, it's still sitting right there in that backup file, if I could just find a way to push it back to flash!

I'm so close to getting this thing unbricked. And if I can get this unbricked, I'll contribute the backup image, the modified e200tool code, and any other information to help unbrick any other Views out there.

I spent this morning fighting with libusb's dirt-poor documentation (pretty much none whatsoever - the reference pages basically saying "to use this function, use this function."). I finally got it to stop giving me "Invalid argument" on usb_claim_interface, by calling usb_set_configuration to "1" first - not "0" as I had originally suspected. It wasn't until I found "testlibusb-win" that I was finally able to uncover the parameters I needed to feed libusb's functions... /facepalm

But I finally got it working, at least to the point of uploading goofed-up USB loader code to the device. That prompts me to wonder: could I upload the initial bytes of the saved ROM image instead? Maybe get that "16MB_FORMAT" drive to appear, and I could upload the rest from there? I think we're really on the right track here, and thought it was worth sharing.

(I think the most impressive thing is, besides holding on to my bricked View knowing I'd find a fix some day, is that I'm a PHP coder, not a C++ coder - man, this stuff is complicated! )

Last edited by FalconFour; 04-02-2011 at 10:41 AM.
Reply With Quote

Advertisement [Remove Advertisement]

  #2  
Old 04-02-2011, 12:42 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,608
Default

e200tool uploads a program to PP based CPUs over USB and then communicates with that program by issuing it commands. The program is present in "arm_code.c". If you want to run code on a different CPU then the PP5024 (used in the e200v1), then you'll need to update arm_code.c for whatever CPU the View uses. Otherwise its just going to crash as soon as e200tool runs since it won't be able to run the PP5024 program.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #3  
Old 04-02-2011, 01:16 PM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Thanks for the reply! Almost had the View figured for a lost cause for lack of activity in View topics, first ray of light I've had so far

Yeah, I figured that's how it works, by uploading a program and running it to interface with the PC-side application. My first attempt was to upload the bootloader code itself and hope it a) fits, and b) runs long enough to expose 16MB-FORMAT to the PC. No such luck, it craps out at ~69kb. I added a functionality to the e200tool that allows me to "init" a certain segment of the stub code, which I had replaced with the bootloader as a test... so I could do "e200tool init 0x400" to send only 1024 bytes. Any less than 69kb and it will finish, but nothing happens (doesn't drop USB, nothing). Now that's the curiosity.

I think the compiled loader/interface stub for e200tool is actually running on the View, as evidenced by being able to upload non-executable code and having the View hang, instead of resetting & dropping the USB bus connection. Part of the stub execution is to reset the USB bus under a different VID/PID, and I think it's getting hung up on, perhaps, initializing the wrong buffer or address space for USB usage... that may be where it's getting screwed.

There is one huge void on the internet during my searches, and that's any sign of e200tool development discussion. That would be *very* useful to know, just how e200tool came to be, how these paths were discovered and how I could re-discover them on the View. I'm no c++ dev, but I'm really dedicated to finding a way to fix this thing, not to benefit myself, but to fill that void on the internet of "awh, bricked your View? Send it to SanDisk and cross your fingers!"

edit: I think as a basic "building block" step, I first need to figure out how to compile the original arm_code.c file such that it produces the same "black box"-style result of dropping the USB connection... *then* what I'd do is play with avoiding re-initializing the USB, perhaps see if I can make it repeatedly belch "testtesttesttest..." over the USB line, and listen for that within e200tool. If that works, I can start dumping more diag info, build little blocks of the e200tool's ARM code back up, and eventually find the place it's hanging at
edit: Kind of a crapshoot, but I just tried duplicating backup Flash image to a physical-appearing mounted VHD file -> Acronis Disk Director -> resize 8gb data partition to 1gb -> move 40mb hidden partition to end of 1gb partition (same as it would be otherwise) - now the drive has 7gb of free space -> raw-copy the VHD to a 4gb MicroSD card -> try booting from SD card in case it'll fall back to alternative bootable media. No dice... same manufacturer mode.

Last edited by FalconFour; 04-02-2011 at 01:31 PM.
Reply With Quote

  #4  
Old 04-02-2011, 03:04 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,608
Default

Quote:
Originally Posted by FalconFour View Post
I think the compiled loader/interface stub for e200tool is actually running on the View, as evidenced by being able to upload non-executable code and having the View hang, instead of resetting & dropping the USB bus connection. Part of the stub execution is to reset the USB bus under a different VID/PID, and I think it's getting hung up on, perhaps, initializing the wrong buffer or address space for USB usage... that may be where it's getting screwed.
Its running, but since most if not all of the addresses are probably different on the View, its not going to be able to actually do anything.

Quote:
Originally Posted by FalconFour View Post
There is one huge void on the internet during my searches, and that's any sign of e200tool development discussion. That would be *very* useful to know, just how e200tool came to be, how these paths were discovered and how I could re-discover them on the View.
Whoever wrote e200tool appears to have reverse engineered it from the Sandisk firmware binary in private. He then anonymously posted the code.

Quote:
Originally Posted by FalconFour View Post
I'm no c++ dev,
Good news, its not written in c++

Quote:
Originally Posted by FalconFour View Post
edit: I think as a basic "building block" step, I first need to figure out how to compile the original arm_code.c file such that it produces the same "black box"-style result of dropping the USB connection...
arm_code.c has the instructions at the top of the file. You just need arm-elf-gcc installed, which comes with the rockbox dev tools.
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #5  
Old 04-02-2011, 03:20 PM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Quote:
Originally Posted by saratoga View Post
Its running, but since most if not all of the addresses are probably different on the View, its not going to be able to actually do anything.

Whoever wrote e200tool appears to have reverse engineered it from the Sandisk firmware binary in private. He then anonymously posted the code.
Explains a lot. Craaap. OK, may be tiems for som hackans.

Quote:
Originally Posted by saratoga View Post
Good news, its not written in c++

arm_code.c has the instructions at the top of the file. You just need arm-elf-gcc installed, which comes with the rockbox dev tools.
haha... well, that sure doesn't look good on my resume Just straight "C" then, I take it. And I'll go poke around for the rockbox dev tools... that definitely sounds like a good place to start! I really think if I can get this thing to compile and load at all, I can probably get it to do something useful... and now that I know e200tool is kinda "open source behind closed doors" in a sense, I can probably stop googling the heck out of every permutation of "how manufacturer mode works" I think up, too!

edit: Well, a little bit of progress... I modified e200rpatcher to take the place of e200tool and add one much-needed bit of functionality: read from a file, send to device. "e200rpatcher my_compiled_app.bin" will send that file to the device via the manufacturer-mode system. And so far, that manufacturer-mode thing consists basically of this: "how many bytes to expect" (in one USB write request), then loop through the data to be sent, 64 bytes at a time. Any less and it hangs the device for some reason (so I guess it's accepting the data!). Huge PITA was having to write-in the debug functionality to figure out where it was hanging, by sending 63 bytes instead of 64. /facepalm

Last edited by FalconFour; 04-02-2011 at 07:18 PM.
Reply With Quote

  #6  
Old 04-03-2011, 03:13 AM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Might just change this thread title to "I've successfully unbricked the world's first fully erased Sansa View"... I'm confirming it right now, but I'm RUNNING e200tool ON MY SANSA VIEW right now! "Write", "Run", everything... and you WILL NOT BELIEVE how simple the solution was... it was an issue of memory addressing - in fact, the program ONLY loads when using the wrong CPU type (arm7tdmi for e200, instead of ARM1176JZ-S in the View).

After it loads, though, the program performs completely flawlessly with... well, I don't even recall making any modifications! The lazy can just re-import the generated hex code into e200tool, edit the launch address to 0x10F00000 instead of 0x10600000 (thanks), and run "e200tool recover bootLoader.rom", while the power switch is on Hold and holding down the Home button (so it doesn't try to access the Flash firmware, which doesn't exist).

I'll post more details soon, but I just lit up the apartment with shining "GLEE!" after seeing the screen turn on again for the first time in over a year, showing the Sansa logo and some debug text for recovery-mode. But yep... I think this is it!

edit: ... if I could just find a way to write to the Flash chip... I've got all the ability to run all the code I care to run, but I just can't find a way to write to the Flash so I can get it working again... sheeit. Sadly, e2tplus doesn't play as nice with the View as e200tool itself does... commenting-out the "ata_init()" in the main function allows it to start, but I spent about 2 hours debugging compiler issues... if -lgcc is used, I get a critical error about not finding "crt0.o" (as always - even though nothing on the entire hard drive even references crt0.o). If not, the program can't do division. Makes no sense. :/

Last edited by FalconFour; 04-03-2011 at 07:51 AM.
Reply With Quote

  #7  
Old 04-03-2011, 12:03 PM
saratoga saratoga is offline
Rockbox Developer / Moderator
 
Join Date: Apr 2007
Posts: 3,608
Default

Quote:
Originally Posted by FalconFour View Post
edit: ... if I could just find a way to write to the Flash chip... I've got all the ability to run all the code I care to run, but I just can't find a way to write to the Flash so I can get it working again... sheeit. Sadly, e2tplus doesn't play as nice with the View as e200tool itself does...
None of these tools are going to be able to write to the flash because no one has ever reverse engineered how the flash memory works on the View. Even on the e200 e200tool didn't write to the flash (iirc when the tool was written that hadn't been figured out yet), instead it just loaded the entire firmware image into DRAM and then rebooted into recovery mode. Then you used recovery mode to install a new firmware. Thats probably the only way you're going to get this to work.

Quote:
Originally Posted by FalconFour View Post
commenting-out the "ata_init()" in the main function allows it to start, but I spent about 2 hours debugging compiler issues... if -lgcc is used, I get a critical error about not finding "crt0.o" (as always - even though nothing on the entire hard drive even references crt0.o). If not, the program can't do division. Makes no sense. :/
crt0.o is part of the c runtime. Are you sure you've actually setup the devtools correctly? Can you compile rockbox? Given the age of the e200tool code, you may also want to try the older arm compiler when prompted (the non-eabi one) if the current one doesn't work (arm-eabi-elf-gcc).
__________________
Interested in Google's Summer of Code ? PM me.
Reply With Quote

  #8  
Old 04-04-2011, 01:08 AM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Fun fun. Yeah, having a fun time trying to get the e2tplus stub to work properly on the View... pretty much worked fine "stock" with the original e200tool, but e2tplus just gags to death on it. Out of the box, it turns on the LCD to a scrambled image (since it didn't even intend to turn the LCD on), and hangs. If I disable (comment out) writing to GPIOD during sd_card_mux(), it seems to work better. The program runs, as I found a way to blink the button LEDs thanks to that GSoC wiki page, and I modified the led_on() code to utilize it to show me the error conditions it was trying to report. Now when I run it, it's constantly blinking and restarting whenever USB is plugged in. Working on cleaning up the code and removing the unnecessary "device identification" strings, but I kinda think I have a better bet with a different option.

The big issue we've got is that sansa.fmt has no effect when placed on the 16MB-FORMAT RAM drive. It ignores the file and just reboots. But the code is still there in the loader to re-initialize the Flash, I just need to find a way to trigger it! I know what I'd need to do: take a "jump" command for something like, say, where it prints on the screen that it's in USB 2.0 MSD mode... and change that jump to point to the "initialize Flash" routine instead. Then it would just immediately start erasing when I run it, and we'd be done!

Unfortunately, the disassemblers I've found so far (rockbox's "arm_disass", "disarm", and "ARMu") are really not up to the task. They jumble up string data with the code data, become offset and start showing gibberish instructions, and don't allow me to emulate a memory map for debugging (so I could hit "run" and watch what it's doing to the memory area)... I'm still crunching away at it, though.

I spent a few hours "bit-banging" the NAND startup routine from the e2tplus code, and found a bit of a curiosity: it was playing totally "dumb". All the registers would return to 0 with no result, but the fact that they would be semi-persistent is certainly curious. For example, I could write an instruction to a register and then immediately read it back, it would still be there. But a few writes later it would disappear, although there is still nothing in the result and status registers. Not sure if it's because I'm entering commands too slowly, though... or maybe the disconnect-and-reconnect of USB. Still, may be making progress here...
Reply With Quote

  #9  
Old 04-04-2011, 01:27 AM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Hey, something I'm actually curious about, though...

What's up with people saying "OMG, DON'T FORMAT YOUR 16MB-FORMAT PARTITION!!"...? The 16MB-FORMAT partition is a purely virtual, RAM-based device, which is the entire problem I'm having right now... it frustrates me to no end every time I see someone rambling in bold print about using Windows' format utility on the 16MB-FORMAT drive. If it were actually tied to Flash, I'd be done with this by now

Is the 16MB-FORMAT drive actually physical on some e200 models? Or is that just a huge, endlessly perpetuated misconception? :P

edit: Progress... I've got e2tplus up and running with the Flash code and ata_init() running on startup. After adding a lot of debugging light-flashing functions (on return errors - which aren't reported anywhere! wtf), I found that it's getting hung up on the one thing I suspected all along: the Flash controller just isn't responding to anything. So it times out during the initial wake-up command, but never passes that info along to anyone... man, I spent hours debugging this thing. Mostly debugging just to get it to launch without endlessly re-launching itself - took quite a bit of work to find that the "if ((UOG_ENDPTSTAT & mask) == 0)" check was what was causing it to crap itself. I just commented that out, and so far it's been totally flawless.

So I think, knowing that the Flash controller isn't even responding to program control, it might be best to try tinkering with the bootloader... I got a new disassembler set up, but the code is still a mess, almost like it's half encrypted or something. None of the strings or data have any references, and most of the subroutines are orphaned with no incoming references. Very little information in there. But I mean, what I'm trying to do is so simple (it's already part of the code!), it's just a matter of finding that function, and tracking down what part will trigger it :/ I'm just afraid that function is part of the scrambled data in the boot loader. I know about 3/4 of the file is composed of that obscenely large splash graphic/animation, but I still only have patchy parts of the file that could actually be decoded... the rest is what would appear to be code data, but isn't being decoded. :/

edit: Here's what I'm referring to by "it's already part of the code"...
Code:
ROM:10F07E34 aErasing_Please DCB "Erasing. Please wait...",0
ROM:10F07E4C aEraseCompleted DCB "Erase Completed.",0
ROM:10F07E5D                 DCB    0
ROM:10F07E5E                 DCB    0
ROM:10F07E5F                 DCB    0
ROM:10F07E60 aEraseFailed_   DCB "Erase Failed.",0
... It's just that there are zero references to any of these strings in the code... this entire area of memory, it acts like it doesn't even exist. I've tried searching for a similar offset, or anything in the 0x10F07000 area... nothing. I can't tell where it's calling the data from. If I could find that, I could find the routine it's calling and trace it backwards (like where it would compare the 16MB-FORMAT files to "FIRMWARE", "FONT", etc - and no, it doesn't even seem to check for extensions!). Then I could find what trigger it uses for the erase function

edit: Ooohh... shiny toy! OK, so check this out. Apparently the contents of RAM are not erased when the bootloader (loaded via e200tool) reboots the device after USB is unplugged. You can imagine what that means. Yep... I'm running a memory dump now! And so far, at 0x10F00000, I still see the boot loader, even after I rebooted. Maybe I can find some additional "unpacked" code in here that would give us some clue... not holding out *much* hope for that, but it'd a good thing to have...

Last edited by FalconFour; 04-04-2011 at 07:13 AM.
Reply With Quote

  #10  
Old 04-05-2011, 06:30 PM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

It's official!

I have successfully recovered my Sansa View from a "Tango Digital Media Platform" blue ring of death bricking!


I'll be writing-up and posting a full tutorial and code/tools package (for Windows, since I don't use Linux, but I imagine it'll compile just as well on Linux), within the next few hours

Some preliminary notes: recovery can ONLY be performed with v01.01 (maybe 01.00 but never tested it), or v01.02 firmwares. v01.03 changed the way the bootloader recovery works and it no longer seems to properly write to Flash. In fact, I don't even think v01.03's recovery mode works at all. Also, the way to get the bootloader to reinitialize Flash is to set the Hold lock like going into recovery mode, then hold the UP part of the wheel (play, up, part nearest to the screen) INSTEAD of holding "Home", while loading the boot loader (powering on or using e200tool - which I'll likely "fork" as "viewtool" - in the recovery function). That creates the Flash structures needed to hold the firmware. The missing piece.
Reply With Quote

  #11  
Old 04-06-2011, 05:53 PM
FalconFour's Avatar
FalconFour FalconFour is offline
Junior Member
 
Join Date: Jan 2010
Posts: 26
Default

Now running natively in Windows 7 x64, libusb driver and all...
Code:
C:\Users\Falcon\Desktop\viewtool>viewtool.exe recover 1.3.02a/bootLoader.rom
viewtool v0.2.3-alpha by FalconFour based on e200tool by MrH
Writing '1.3.02a/bootLoader.rom' to address 0x10f00000
Searching for Sansa View ... found!
Setting configuration 1... Success!
Claim interface 0... Success! Using interface 0.
Found Sansa View in Manufacturing Mode. Let's get you outta those wet clothes...
Initializing USB stub (5248 bytes) ... Running bulk write, bytes:
0x1440 ...Now booting View into viewtool loader!
10 found!
Setting configuration 1... Success!
Claim interface 0... Success! Using interface 0.
Write at 0x10f638b8
Write done!
Running from address 0x10f00000
Searching for Sansa View ... found!
Setting configuration 1... Success!
Claim interface 0... Success! Using interface 0.
Execution started!

C:\Users\Falcon\Desktop\viewtool>
And I'm'a make a "one stop solution" batch file outta this too...
Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



All times are GMT -5. The time now is 06:33 PM.