Subject: Re: HEADS UP : New bootloader for RISC OS based machines commited
To: Chris Gilbert <chris@paradox.demon.co.uk>
From: Reinoud Zandijk <imago@kabel065011.kabel.utwente.nl>
List: port-arm32
Date: 02/18/2001 14:00:00
Hi Chris,
On Sun, 18 Feb 2001, Chris Gilbert wrote:
> On Sunday 18 February 2001 1:26 am, Reinoud Zandijk wrote:
> > The new bootloader features a new clean startup mechanism that isnt RISC
> > OS version specific anymore as well as a much cleaner and more
> > maintainable. It also features a clean and rock steady loader mechanism
> > that puts the kernel in the correct place before calling it. This means
> > the end of the relocation of a running kernel as the old bootloader
> > demanded.
>
> That reminds me, any reason you did it in BASIC? Looking over the existing
> bootloader it's all in standalone C, only the gui config stuff needs desklib.
> The reason I ask is that I've looked over the BASIC program and can't follow
> half of it as I'm very rusty at BASIC these days.
The reason for this is simple since it doesnt need compiling (and i dont
have a `C' compiler for RiscOS) but there is no reason why it can't be
written in `C' ... its just that it can be tweaked under RiscOS without
depending on a complete compilation environment / library. It also
eliminated the `chicken and the egg' problem for me.
> > The newest version of the bootloader is allways available at :
> > ftp://ftp.netbsd.org/pub/NetBSD/arch/arm32/bootloader.arc
>
> shouldn't that be:
> ftp://ftp.netbsd.org/pub/NetBSD/arch/arm32/riscos/
I stand a 100% corrected .... sorry for that .. i gave the wrong URL.
> > Next to the MemFix module needed for Castle Kinetic card machines.
>
> To do what with it? We need it, without it we don't work. (Castle even
> updated their FAQ to include the solution for how to get netbsd working!)
Well I thought that was evident but i'll include it in next version...
sorry about that too :)
> > P.S. sorry for the reddish colour as yet :( .. switching VT's will solve
> > it but will propably be solved when wscons is included.
>
> Who's fault is the red colour, the bootloader? or the kernel making an
> assumption that the bootloader has done something with the palette?
Yep I think the later... allthough i cant find any colour/VIDC stuff in
the old bootloader ... maybe i've overlooked something but i couldn't find
it.
Cheers,
Reinoud