-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

You probably know that in mkamsboot we maintain a list of tested OF and
their md5sum, to prevent accidentally bricking, if our algorithm goes
bad with some new OF.

If the OF is unknown, mkamsboot would only print a warning.

In r21073 I changed that error out and prevent patching an untested OF.

Then in r21118 I accidentally removed that error, and reverted to the
previous behaviour : only printing a warning and patching the OF anyway.


Now I have a doubt about what we should do:

If we prevent patching an untested OF, any firmware released after the
rbutilqt release would not be accepted, and the user would have to
download an older firmware, after rbutilqt informed him that its OF
version is unknown.
The Sansa forums usually only give the last OF for download, though
that must be possible to find older OFs with some search.

If we permit patching any OF, tested or not, we add a little risk of
bricking those players which can't be unbricked, but what is the risk
exactly?

- - The algorithm has been tested many times on all the models and on
  all OF versions known.
- - When patching an OF the 2 variables are the OF version and the
  bootloader content, and we didn't (and can't) test all possible
  bootloaders.
- - When running rockbox, there is also a little risk of bricking : if
  the code goes mad and overwrites the first sectors of internal
  storage which hold the OF. The storage code "jumps" over this area,
  but in case of memory corruption we can imagine the check is changed
  and rendered ineffective.


It is possible to brick the iriver H100 models (according to the
flyspray task which asked for testing bootloaders for 3.0 release), and
the code that patches H100 OF also use a builtin list of tested OF; and
will refuse to patch an untested OF.



So I wonder : is the disadvantage of refusing to patch recently
released OFs worth the advantage of using only tested OFs ?

Right now I tend to think that no, we should accept just any OF.

- --
Rafaël Carré
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkonuKAACgkQYWCeGMCv8Q/8dwCeOruXoYZfKen5eICllbkP8rq5
YGAAniqX0f44vCPTNqtpVHbsBi40EcYT
=+zfp
-----END PGP SIGNATURE-----
Received on 2009-06-04