Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: RE: mkamsboot considered harmful

RE: mkamsboot considered harmful

From: Mark Ganson <mwganson_at_hotmail.com>
Date: Thu, 4 Jun 2009 14:52:45 +0000

> Date: Thu, 4 Jun 2009 14:05:52 +0200
> From: rafael.carre_at_gmail.com
> To: rockbox-dev_at_cool.haxx.se
> Subject: mkamsboot considered harmful
>
> -----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 acc
epted, 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.
>
> - --
> Rafal Carr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkonuKAACgkQYWCeGMCv8Q/8dwCeOruXoYZfKen5eICllbkP8rq5
> YGAAniqX0f44vCPTNqtpVHbsBi40EcYT
> =+zfp
> -----END PGP SIGNATURE-----

For what it's worth, there's not much danger of any new OF releases for the e200v2. According to moderators at the official Sandisk forum there won't be any more OF updates for that discontinued series. The Clips and Fuzes will likely get more updates, though.
--Mark
_________________________________________________________________
Lauren found her dream laptop. Find the PC thats right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290
Received on 2009-06-04


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa