Sandisk Sansa e200 v2

[rasher]

I think it's safe to assume that all e200v2s are 0781:7422 and 0781:7423. No further tests needed.

[broschb]

I just got a v2 e250, and would really like to get rockbox going on it.  I hope this is the correct thread to post, I have not done any low level programming, but would be willing to learn, I have done quite a bit of java, c++.  I want to know if anyone can recommend the best way for me to get started and contribute working on/assisting this port.

[Bagder]

I want to know if anyone can recommend the best way for me to get started and contribute working on/assisting this port.

http://www.rockbox.org/wiki/NewPort is the standard way. Of course you should also read up on everything we know about the e200v2 so far.

[brickhouse]

So is the  recovery mode still the main issue left with getting code on one of these? I talked with a Sansa support person and asked if the e200v2 had a recovery mode and he said no. So the next logical question I asked is what can I do if I get it in a messed up mode and he explained that I would need to slide the hold switch over and press one of the other buttons(It was a bad connection so I didn't get the last step) to put it in MSC mode and then try updating the firmware. I konw on another post people have gotten these into MSC mode so I didn't ask to have him repeat it. So is the solution to this more so in the update software that is needed to check for updates from sansa and also used to update the e200v2 ?

[newflesh]

First of all, I don't know actually anything about embedded system, so please excuse me if end up looking like a caveman trying to figure out a car using his club... anyway, since I'm interested in getting an e200 with RockBox I've geeked out a bit on the available info.

I looked at charts of the chips, and noticed the new one has an on-chip ROM, while the old one lacks this. Then I wanted to figure out what that ROM could do, and in the SDK document linked in the other Sansa V2 thread I found this:

Boot loader
The integrated Bootloader which is located in the on-chip ROM
supports direct boot from
• NandFlash
• IDE
• serial NorFlash
• SPI master
The boot loader also supports initial firmware programming and
field firmware update by connecting the device via USB
interface. By using a two stage Bootloader concept for the USB
boot loading mode, programming of the firmware code to all kind
of non-volatile memories is supported.

(http://www.streamunlimited.com/downloads/AS352x_SDK6_sw_pb.pdf page 2-6)

So, if we assume that the ROM-code can handle MSC transfers independently of the firmware, and that it has a function to look for the firmware files in the flash, wouldn't that indicate that there's a pretty safe way to unbrick the device if you can make files it accepts?

In any case, kudos to everyone working on RockBox, and unless I manage to track down an e200v1 I'll be ready to risk trying some stuff if there's any code ready if I get a v2 (which most likely is the case, since it seems to be the best player in my price range)

[saratoga]

So, if we assume that the ROM-code can handle MSC transfers independently of the firmware, and that it has a function to look for the firmware files in the flash, wouldn't that indicate that there's a pretty safe way to unbrick the device if you can make files it accepts?

But how do you get into that mode?  If you write a bootloader with the correct header, the ROM is going to think the firmware is ok and then switch control over to it.  If your firmware then doesn't work properly, how will you get back to the ROM's USB mode?  

[newflesh]

Maybe there's some key combo that instructs the embedded code to run the install/update feature? Maybe starting with the MSC command does that... it sounds possible with brickhouse's support response.

Is there a bootloader in the firmware bins available? Could it be possible Sandisk decided to only use the bootloader on the ROM, and that the installer checks root for a bin before loading the installed firmware?

[pgs]

But how do you get into that mode?  If you write a bootloader with the correct header, the ROM is going to think the firmware is ok and then switch control over to it.  If your firmware then doesn't work properly, how will you get back to the ROM's USB mode?  

I could imagine that, if they did it properly, it could work, from boot ROM, like this:

reset:
start:

if(standalone) run_firmware
else /* following occurs in msc mode */
  while(msc_mode) do_msc_stuff
  /* out of MSC mode, i.e. USB detach */
  if(new_firmware) update_firmware
  udpate_db /*maybe in else clause? or maybe update_db.run_firmware */
  reset
 
Since this would be in the internal ROM, it will always work.
If the firmware fails, it could be possible to attach the thing to a PC, start in MSC mode, and replace the firmware.
Of course, _if_ they did this way.

The update db thing is a bit unclear, running it in boot ROM makes no sense, on the other hand, somewhere it should go...

Topic change, maybe someone could be interested.

About the "hidden directories", instead of changing the attribute on the device, one option could be to "modify" some FAT "drivers" in order to see the attribute  0x18 as a dir.
There is a quite easy possibility, so use some FAT, fuse based, filesystem, under Linux.
So, I installed "libfat", from: http://sourceforge.net/projects/libfat/ and added the above attribute as directory.
This is pretty straightforward, just edit bits/libfat.h (in the source tree) with:

--- libfat.h.org        2007-05-22 10:04:49.000000000 +0200
+++ libfat.h    2008-03-15 15:03:43.000000000 +0100
@@ -244,10 +244,11 @@
 #define ATTR_SYSTEM 0x4
 #define ATTR_VOLUME_ID 0x8
 #define ATTR_DIRECTORY 0x10
+#define ATTR_HIDDEN_DIRECTORY 0x18
 #define ATTR_ARCHIVE 0x20
 #define ATTR_LONG_NAME ( ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID )
 
-#define ATTR_ISDIR(D)  ( ( (D) & ATTR_DIRECTORY ) ==  ATTR_DIRECTORY )
+#define ATTR_ISDIR(D)  ( ( ( (D) & ATTR_DIRECTORY ) ==  ATTR_DIRECTORY ) || ( ( ( (D) & ATTR_HIDDEN_DIRECTORY ) ==  ATTR_HIDDEN_DIRECTORY ) ) )
 
 /* values used by libfat. not correlated with fat file system values */

Configure, compile and mount (read-only), the hidden directory will be visible.

Hope this help.

pgs

[saratoga]

I could imagine that, if they did it properly, it could work, from boot ROM, like this:

reset:
start:

if(standalone) run_firmware
else /* following occurs in msc mode */
 Â while(msc_mode) do_msc_stuff
 Â /* out of MSC mode, i.e. USB detach */
 Â if(new_firmware) update_firmware
 Â udpate_db /*maybe in else clause? or maybe update_db.run_firmware */
 Â reset
 
Since this would be in the internal ROM, it will always work.

Yes but if the firmware you flash does not work, none of that will matter since the system will crash as soon as it boots.  This is why you need a way to recover from bad flashes.

[pgs]

Yes but if the firmware you flash does not work, none of that will matter since the system will crash as soon as it boots.  This is why you need a way to recover from bad flashes.

There is one assumption that maybe was not clear: the MSC mode is in the ROM (Read Only Memory), not in the flash (or it is in the boot loader of the flash, which can be protected).

So, as soon as the device is attached to a PC, it goes in MSC (if enabled) and this will always work, no matter what firmware it has.

This is similar to the (not so new) BIOS recovery feature of PCs, where, even in case of bad flashing, there is a part of the BIOS untouched, which can boot and reprogram the flash by its own.

If the flashing is gone bad, the device will be anyway able to go in MSC and reprogram the flash, since this mode is non-modifiable.

In other words, the very first boot manager is in ROM and it always has the chance to start the firmware or go into MSC mode, no matter how bad is the firmware, and later re-flash or re-start the firmware.

They _could_ have implemented this way, hopefully they did.

pgs

[saratoga]

Yes but if the firmware you flash does not work, none of that will matter since the system will crash as soon as it boots.  This is why you need a way to recover from bad flashes.

There is one assumption that maybe was not clear: the MSC mode is in the ROM (Read Only Memory), not in the flash (or it is in the boot loader of the flash, which can be protected).

So, as soon as the device is attached to a PC, it goes in MSC (if enabled) and this will always work, no matter what firmware it has.

This is similar to the (not so new) BIOS recovery feature of PCs, where, even in case of bad flashing, there is a part of the BIOS untouched, which can boot and reprogram the flash by its own.

If the flashing is gone bad, the device will be anyway able to go in MSC and reprogram the flash, since this mode is non-modifiable.

In other words, the very first boot manager is in ROM and it always has the chance to start the firmware or go into MSC mode, no matter how bad is the firmware, and later re-flash or re-start the firmware.

They _could_ have implemented this way, hopefully they did.

pgs

Has anyone reported being able to get into UMS mode without booting the device?  I don't recall anyone saying so, which is why I tend to think its not possible to do that on the V2 (at least without some sort of hardware modding or unknown recovery mode).

[pgs]

Has anyone reported being able to get into UMS mode without booting the device?  I don't recall anyone saying so, which is why I tend to think its not possible to do that on the V2 (at least without some sort of hardware modding or unknown recovery mode).

It _could_ be that MSC mode, or UMS mode, is always active _without_ booting the firmware.

How do you know if it is the firmware in flash running or the one in ROM?
You can't, so "booting" does not mean the firmware in flash is running, it just means the device is executing some starting code, but we do not know where this code is coming from.

This is the same as saying: how can you go in recovery mode without booting the firmware?
You can, since you do not boot the firmware, recovery mode happens before, same goes here.
When a key combination is pressed, who is reading the keys? If the firmware does not work, the machine did not boot, how could be the CPU reads the keypad? The CPU executes ROM code, that is it.

It _could_ be that the recovery mode _is_ the MSC mode.
I mean by this, _active_ MSC mode, i.e. MSC mode while connected to a PC. Like any simple mp3 player does.

How can I explain it more clearly?

Let me try again...

The ARM has a ROM, with some boot code. This is the code executed at power up (or reset), this goes in the booting phase. That is, the device always boots. This code is _not_ flashable. This code handle the MSC mode, _before_ the firmware starts.

_If_ they implemented this way, the MSC mode will always be available, it will be always possible to copy a new firmware to the device and, consequently, to update it.

Note that, when in MSC mode, connected to a PC, you cannot play songs or do anything with the device, like the firmware is not active...

Anyway, this are just hypothesis, without a test, there is not much to say more...
This means that, until someone bricks a device and recovers (or not) by MSC, we will never know for sure.

Any volunteers here? :-)

pgs

[fed]

Have you tried to ask Sansa if your hypothesis is correct?

[pgs]

Have you tried to ask Sansa if your hypothesis is correct?

Well, actually I was deriving the hypothesis from the comments of people asking the "recovery" question to Sandisk.

It seems the answer was always: "do this and that and you'll be in MSC mode", so I came to the conclusion that the device, connected to a PC, in MSC mode, _is_ in recovery mode.

Anyway, I sent an email to the Sandisk support, time ago, with a similar question and I'm still waiting the answer, so...

pgs

[eXomaniac]

As is also own a Sansa 280 v2 and want to see Rockbox on it, i would like to know what exactly should be tested / done now to get this port forwards.

Is there any safe way to test this recovery mode ?

One thing i know ( dont know if this actually was told) is that to upgrade the firmware you have to plugin the sansa to you pc so it loads in MSC mode and then the firmware is being upgraded. After this you plug out, and after reboot you see that the player himself is updating and ready for use.

Perhaps it helps to know... as i dont know much about this, for me it sounds logically to use this as a recovery mode / firmware mode.

I want to help, tell me how