> On Sun, Feb 26, 2012 at 12:29 PM, Frank Gevaerts <frank_at_gevaerts.be> wrote:
> > The way I understand it (which could be wrong) is that the dualboot code
> > (i.e. the bit that decides which bit gets to boot) is *not* in the
> > bootloader as in the files that are downloaded, but in bits of code
> > that's embedded at build time into rbutil and/or mkamsboot. This has
>
> I haven't followed the amsv2 bootloader / mkamsboot functionality.
> However, if this is true it's a bad thing because it embeds a
> dependency into Rockbox Utility. This means that depending on the
> version of Rockbox Utility used the bootloader (or rather dualboot
> code, but from a users point of view this doesn't make a difference)
> will behave differently, and this shouldn't happen. While there might
> be reasons for embedding the dualboot code into mkamsboot there should
> be a different approach for Rockbox Utility -- it won't be hard to
> download dualboot binary code from the server instead of having a
> binary blob in Rockbox Utility. Of course other ideas are always
> welcome.
>

I think the underlying problem is that people expect USB to work and we don't make it clear to them that it does not work yet on all targets. I think the best solution to this problem would be to display a warning whenever a user installs a build that does not have USB support that reminds them of that and links to the manual's dual boot section. I don't see that it really matters if the user has to manually turn off the player and then plug in USB, or if they have to manually turn off the player, hold left, and then insert USB. If we've informed the user about the limitations of the build they're installing, the end result will be the same. If we haven't, we're still depending on them to either figure it out themselves.

If you dislike how mkamsboot works and want to change ti, thats fine, but I don't see that changing it will solve the underlying issue, nor help users of future ports lacking USB support.

Mike
Received on 2012-02-26