From: Daniel Stenberg <daniel_at_rockbox.org>
Date: Tue, 9 May 2006 09:36:27 +0200 (CEST)

On Mon, 8 May 2006, RaeNye wrote:

> Cowon's OF might rely on what the preloader has done, and RB bootloader
> thrashes everything. Thus, I must decide ASAP which firmware to load.

The iriver versions don't do it like this and they still work fine. The
conclusion it MUST be done like this is a bit drastic IMHO.

> As I said before, I suspect the problem originates from i2c-generic using
> global variables before initialized by RB-bootloader. Having a more
> efficient PCF50606 driver is important (I nagged about it before) but
> irrelevant to the progress of the dual-bootloader. After PCF50606 driver is
> re-implmented (possibly by yours truly), it makes perfect sense to adjust
> the dual-bootloader to use it, but it is not a prerequisite IMHO.

We can re-iterate this many laps, but so far extremely little Rockbox code
depend on anything in any original firmware. This (depending on the cowon
firmware code) would probably be the biggest dependency we have and given what
we've seen in the past: it is very likely to bite us one way or another in the
future. I don't see you adding any new reasons for your standpoint and I think
I've emptied all my arguments. So, I'm still against it.

If the i2c-generic is so bad (it has been publicly admitted numerous times
that it was written primarily "to work" not to be the fastest - and thus it
has lots of room for improvements) it cannot be used, I would consider that a
bug and we should fix it.

Also, the efficiancy is hardly a factor in the bootloader.

But again, as I said in the bug tracker entry, if we really cannot fix our
drivers to work in this bootloader I am willing to allow this (in my view)
hackish approach just to get something working added. We can always fix things
more later on.

> I intend to add an additive dword-sizes checksum over the preloader's code.
> I cannot signal it's not working with either leds, the lcd or any hardware
> (since that would require PCF50606 funcs...)

I suggested a led flash since that was the only feedback I got on the dual
boot patch that didn't work! ;-)

> but I can fallback to booting RB.

... and it sounds like a much better fallback than what I suggested.

> OSS is all about choice, hence I don't intend to tell users anything like
> "The dual-bootloader will only boot RB by default because I'm a RB dev" as
> much as grub won't tell you "I ain't booting your Windows by default". Even
> if the official version supports only RB-first, it is easy to reverse the
> order (as people in iaudiophile.net's forum have already done).

In my view, Open source is primarily about choice because people have the
source and can do whatever they want. It doesn't mean we have to add every
imaginable feature ever asked-for as an available option.

I don't feel particularly strongly on this topic, I just think its a waste of
time to add functionality to bootloaders to reverse the default boot order.
People who really feel they need it can always just make it do that anyway.

And we certainly aren't grub.

> Finally, you always run fsck, which calls the needed worker (e.g.,
> fsck.ext2). If your system has ReiserFS, you'll have fsck.reiser; if not,
> you won't need it or even have it compiled. The very same should be done
> with mkboot.

I could certainly agree to a system like that, even if it feels a bit like
overkill to me (with only iriver and iaudio around). But I haven't seen you do
that and that's why I was advocating a way to make a generic mkboot for
multiple targets.

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/

Received on 2006-05-09