Re: AMSv2 USB
Am 27.02.2012 11:30, schrieb Torne Wuff: I absolutely agree; while *our* definition of unstable includes "is missing USB support", the consistent surprise users demonstrate when they find out is evidence enough that that definition is not obvious :) That's not quite right. We allow targets that lack USB in the stable category. This is why we're having this discussion. The bootloader behavior was changed for stable targets as a result of enabling USB in current builds. Best regards.
Re: AMSv2 USB
On 26 February 2012 22:53, Mike Giacomelli wrote: > 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. I absolutely agree; while *our* definition of unstable includes "is missing USB support", the consistent surprise users demonstrate when they find out is evidence enough that that definition is not obvious :) If it looks like it works (i.e. it boots and plays music and so on) then people will expect USB to work because that's a core feature of the device to a user. -- Torne Wuff to...@wolfpuppy.org.uk
RE: AMSv2 USB
> On Sun, Feb 26, 2012 at 12:29 PM, Frank Gevaerts 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
Re: AMSv2 USB
On Sun, Feb 26, 2012 at 12:29 PM, Frank Gevaerts 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. We had installation dependencies hardcoded in Rockbox Utility in the past (Rockbox release version) and it was a bad thing (since it required us to make a new release of Rockbox Utility on each new Rockbox release). We should really avoid adding such dependencies, and it looks like mkimxboot is doing something similar (though I have no idea if this involves dualboot decision). - Dominik
Re: AMSv2 USB
Am 26.02.2012 01:03, schrieb Frank Gevaerts: Since USB was enabled on trunk to evaluate how well USB works, without knowing if it will even be enabled in the next release, I must say I fail to understand why mkamsboot got changed. I agree (in hindsight, I too haven't thought of this issue when the change was made) that bootloader shouldn't have been changed until we know USB is reliable enough. That is, when it's included in a stable release. Best regards.
Re: AMSv2 USB
On 26/02/12 11:29, Frank Gevaerts wrote: On Sun, Feb 26, 2012 at 11:21:07AM +, Alex Parker wrote: If USB is not to be enabled on 3.11, then we revert the bootloader change. Rockbox Utility should be installing bootloaders that work with the current release. If people are using current builds then they can also install an alternate bootloader manually if they so desire. We do releases for a reason, and they should come first. 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 the big advantage of making bootloader experimentation more or less safe (i.e. you can't even touch the bit that lets you boot the OF to recover), but it does make this particular situation a bit more complicated than we'd like it to be. Hmmm, OK. While that makes it a bit more difficult for people wanting to install reverse operating bootloaders I don't think it changes the basic premise - if 3.11 doesn't have USB enabled then the change in mkamsboot/rbutil gets reverted and a new release of mkamsboot/rbutil is done at the same time. Alex
Re: AMSv2 USB
On Sun, Feb 26, 2012 at 11:21:07AM +, Alex Parker wrote: > If USB is not to be enabled on 3.11, then we revert the bootloader > change. Rockbox Utility should be installing bootloaders that work > with the current release. If people are using current builds then > they can also install an alternate bootloader manually if they so > desire. We do releases for a reason, and they should come first. 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 the big advantage of making bootloader experimentation more or less safe (i.e. you can't even touch the bit that lets you boot the OF to recover), but it does make this particular situation a bit more complicated than we'd like it to be. Frank > > Alex > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: AMSv2 USB
On 26/02/12 11:12, Frank Gevaerts wrote: On Sat, Feb 25, 2012 at 07:30:07PM -0700, Mike Giacomelli wrote: I guess it'll get fixed when 3.11 comes out. Will it? Is USB stable enough to be enabled in a stable release? I haven't seen any discussion about that yet. I sincerely hope that the answer won't be "It will be enabled because rolling back the mkamsboot change is too much work"... Frank I think it is a fairly simple answer. If (on its own merits) USB is stable enough on AMSv2 then OK, we go ahead with 3.11. If USB is not to be enabled on 3.11, then we revert the bootloader change. Rockbox Utility should be installing bootloaders that work with the current release. If people are using current builds then they can also install an alternate bootloader manually if they so desire. We do releases for a reason, and they should come first. Alex
Re: AMSv2 USB
On Sat, Feb 25, 2012 at 07:30:07PM -0700, Mike Giacomelli wrote: > I guess it'll get fixed when 3.11 comes out. Will it? Is USB stable enough to be enabled in a stable release? I haven't seen any discussion about that yet. I sincerely hope that the answer won't be "It will be enabled because rolling back the mkamsboot change is too much work"... Frank -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: AMSv2 USB
On Sat, Feb 25, 2012 at 07:30:07PM -0700, Mike Giacomelli wrote: > I think the problem is that we did a release of rbutil that finally > started installing the new bootloader but that defaults to installing > the old release. Rockbox Utility installs the *current* release. Frank -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
RE: AMSv2 USB
> Since USB was enabled on trunk to evaluate how well USB works, without > knowing if it will even be enabled in the next release, I must say I > fail to understand why mkamsboot got changed. I think the problem is that we did a release of rbutil that finally started installing the new bootloader but that defaults to installing the old release. > This really needs to get fixed somehow. I guess it'll get fixed when 3.11 comes out. > Can people who need to make similar changes in the future *please* try > to remember that we have a stable release that needs to work, and figure > out a decent migration plan first? I think to make this happen would have required releasing an official bootloader to go with each release. Otherwise either release users or current build users will get the wrong bootloader. We don't currently do that. I guess another option would be to have rbutil show an alert if someone's installing a build without USB support. We seem to have this problem quite a lot.
