Re: Re: hh.org bootldr almost working!

Hi Guys!

Am Mittwoch, 21. Januar 2004 15:32 schrieb Sven Lankes:
> On Wed, Jan 21, 2004 at 03:16:25PM +0100, Schweizer Walter wrote:
> > bootloader. The original should do, because
[..]
> The new bootloader would make development much easier
> (esp. Kernel development).
Erm? What could be easier than tftp-downloading the kernel from network to ram 
and running it directly from there without flashing a single bit? Which 
additional features are really provided that are not an ease to have it done 
on the desktop machine connected? Nothing really againt a new bootloader, but 
I can't see any real advantages or disadvantages. OK, Arnold is quite a bit 
buggy in some cases, but theese bugs are known and easy to prevent. Breaking 
compatiblity to the "old" simpad series though does not seem appropriate to 
me, because flashing a bootloader is alsways a bit more dangerous, at least 
compared to simple os images. Additionally most users won't event be able to 
reverse such changes on failure, because noone has a jtag programmer 
available. Ok ok, I do, 2-4 ther guys too, but how many others do? 
Furthermore I'm just a bit concerned that many users won't even try to 
install linux anymore, because the procedure of understanding how the old 
bootloader flashing works, chaning the bootloader, understanding the new one, 
booting a few times, flashing the new os and perhaps reversing all that 
afterwards is much more complicated than just leechin' an image and the 
downloader, running the whole thing and it works. Not talkin' 'bout that 
users won't like doin' things that they don't understand and I don't want to 
expect that from _any_ hobby user. 
Even though a bootloader with nice splash screen would be nifty, even if we 
just send the device to suspend state :-)

> The reason Alex started to port the hh.org-Loaders was not that
> he wasn't able to flash jffs2-images.
Oh, yeah, the problem could have been easily fixed without any modifications, 
if we provided an additional "first-time"-image only containing $FFs 
preceeded with a boot header. This could be automatically generated with the 
expected size and address when an os image is generated. Such an eraser image 
would'nt even make the archives noticeably larger. :-)

Nothing againt bootldr, but a cost-benefit-analysis let's me tend to keep 
using arnold.



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn