On Saturday 03 February 2001  3:14 pm, Reinoud Zandijk wrote:
> Hi Chris,
>
> On Sat, 3 Feb 2001, Chris Gilbert wrote:
> > Now that we know that the new bootloader works on the kinetic, do you
> > have a list of other machines it works on? (note that for the kinetic you
> > need the latest version from:
> > ftp://130.89.65.13/pub/
>
> Yep ... that's correct... I'm currenly thinking of maybe moving the kernel
> up in the SDRAM when on a Kinetic, but i've got to have a look since that
> can give additional problems; maybe i need to ``invent'' a DRAM report for
> it. The current code allways assumes its in the lowest DRAM block so that
> has to be messed around with... Still very happy we've got it working at
> last at the Kinetic .... now still the screencolor and the wierd debug
> kernel stuff....

That could be done by the kernel, and may actually require to be done by the 
kernel if castle provide info on how to unlock the 4MB readonly segment of 
the kinetic.

> My TODO list is now :
>
>   - make the bootloader a bit more user friendly ? ideas ?

Hmmm, is it possible to cheat and reuse the existing bootloader frontend in 
some way?

>   - fixing that strange red text colour on booting

Hmm, is this because the kernel assumes the palete has been setup by the 
booter in some way?

>   - changing the bootconfig structure to give a more acurate status of the
>     machine including support for more DRAM/SDRAM/VRAM blocks

Shouldn't be too hard a lot of the code already checks the number of 
dram/vram blocks, however we've got hard coded sizes for the arrays.

>   - not very important but still : fixing that strange slow printing
>     before page swapping L1/L2 pages when running debugged kernels...
>     Might give a clue/hint to a hidden bug somewhere.

Could just be an oddity of our console driver.  For along time it's been 
talked about that we should switch to wscons, perhaps you should leave the 
cons alone until we've done the page swap?

> > I'm wondering if the best way to tackle having the 2 different
> > bootloaders is to have a new kernel option that uses the code that you've
> > got over the existing code.  That way we can move away from the old
> > version, and if it breaks for the new one you can move back.  Probably
> > call the new option NEWBOOT, or perhaps we should make it the default,
> > and make people put in an option OLDBOOT ?
>
> Hmm... well as long as there is noone reporting a boot-failure it could be
> safe to switch over to the new one for the ARM[6,7,SA] Acorn derivatives
> ..... however i would like more ppl to test it first....

Well it works, but the vidc seems to go horribly wrong when booting, eg the 
awful noise and the mouse pointer going to pot, thinking about it it could be 
the way that I've got the VM arranged on my code.  I suppose that any changes 
to the VM layout need to be reflected back to the bootloader.  Much as the 
old bootloader had it's quirks, pretty much the first thing it did was sort 
out it's Page tables so that things were in the right place.

> Status so far for all ARM[6,7,SA] Acorn derivative's :
>   machine		once	support	confirmed/comment
>   -----------------------------------------------------------------
>   A7000(+)		YES	X	Please test again
>   RSt. R7500(+)		???	??	Isn't this a A7000 ?
>   ARM6 RiscPC		???	X	Should run (where is it!)
>   ARM7 RiscPC		YES	X	YES, developpers machine
>   SA RiscPC		YES	X	YES (see next)
>   SA Kinetic RiscPC	YES	X	YES
>   NC's			YES	X	Port busy but should work
>   RSt. Networx (HD)		??	Unknown

Also Netstation etc

>   MicD. Omega,			??	Unknown
>   MicD. Mico	  		??	Unknown
>
> RiscPC's tested with and without 2Mb VRAM ... would also like some results
> with RiscPC's with 1Mb VRAM or no VRAM ...

Yes I've only got 1MB VRAM, would be nice to have 2 so that demos can be in a 
few more colours :)

> So i would like ppl with all different kinds of machines to test the new
> bootloader (needs the new rpc_machdep.c at minimum) and report the results
> / problems ?

well it's all booted, but the console seems slower, is red, and when the 
switch from bootloader to kernel happens it makes a rather nasty noise and 
mangles the pointer (kind of seems like it's crashed, but hadn't ;)

Cheers,
Chris