> ...usually, if one can reflash the device, one should generally be able to dump any MTD partition contents, too...
The Google fastboot protocol allows you to flash, but not to dump. The reason nvflash on your Tegra tablet is different is because those devices are capable of booting into an NVIDIA-specific bootloader that offers the extended functionality to dump the flash contents. On most Android devices, you need to boot the device first and use root access to dump the flash partitions (and in fact on some Android devices even root doesn't have access to dump the flash partitions, so you also need a kernel exploit to modify the driver).
The realistic alternative, and which is totally possible, is to just build your own semi-compatible kernel. With normal adb access you can easily see what kind of hardware it is running, and you can try to guess and check (and pray you don't fry) your way to a compatible set of kernel drivers to access the flash partition; you really need just enough to get flash working with a custom initrd that does nothing but mounts the /system partition and makes the modifications you need; but honestly: "ain't nobody got time for that" ;P.
No. It requires a kind of screwdriver that I don't have with me (and which wasn't in the set that I bought in my initial attempts to cut apart a pair of prescription glasses to work with it), and for all I know it will strip the threads on the way out ;P. If nothing else (Further, I would pretty much just be able to say "uhh... it looks like some kind of digital computer... possibly one involving silicon?" ;P.)
The Google fastboot protocol allows you to flash, but not to dump. The reason nvflash on your Tegra tablet is different is because those devices are capable of booting into an NVIDIA-specific bootloader that offers the extended functionality to dump the flash contents. On most Android devices, you need to boot the device first and use root access to dump the flash partitions (and in fact on some Android devices even root doesn't have access to dump the flash partitions, so you also need a kernel exploit to modify the driver).
The realistic alternative, and which is totally possible, is to just build your own semi-compatible kernel. With normal adb access you can easily see what kind of hardware it is running, and you can try to guess and check (and pray you don't fry) your way to a compatible set of kernel drivers to access the flash partition; you really need just enough to get flash working with a custom initrd that does nothing but mounts the /system partition and makes the modifications you need; but honestly: "ain't nobody got time for that" ;P.