Subject: Re: WSCons testing....
To: None <port-arm32@netbsd.org>
From: Andy Wingate <xyzzy@ox.compsoc.net>
List: port-arm32
Date: 03/20/2001 21:57:10
In message <Pine.NEB.4.30.0103181818270.28847-100000@rangerover.kasbah>
          Reinoud Zandijk <imago@kabel065011.kabel.utwente.nl> wrote:

> I've uploaded a few new test kernels with WSCONS for the RiscPC. Please
> only check the newest kernel version and in 256, 32K or 16M colours only
> for now ... and please report the following when having trouble :
> 	- kernel date
> 	- bootloader (old, new, version)
> 	- how much VRAM you have
> 	- resolution that gave trouble + number of colours
> 	- nature of the problem
> 	- if in multi-user : your wscons.conf file

I've tried out all the test kernels on the two Risc PCs here and the
wscons stuff seems to be getting better every time, although I do have
a few issues. The 20010318_wscons kernel seems to work as well as the
20010317 ordinary one although the display is rather slower. I've been
using what seems to be the latest BtNetBSD - 2001/02/19 14:09:03 (or
20010219b)

I have experienced 2 out of 10-20 boots where the display has been
garbled. I'm not sure what caused it at all but I got what appeared
white smudged lines in the top half of the screen over the black
square in the green border. All over times it displayed correctly.

My main problem is the fact that the kernels appear to be compiled
without the RapIDE32 support so I can't access my partitions. I am
eventually asked to choose root to be a floppy or memory disk.

One thing that does annoy me is that the new bootloader appears to
attempt to access all filesystems just as the kernel is starting. This
causes problems if I have ZipFS running but no disc in the drive and
may have issues with FastSpool+ (or at least I appear to get bizarre
errors with it running before running the bootloader). My dad's SCSI
Syquest EZFlyer has to be turned on and have its disc mounted to
enable his machine to load a kernel successfully (and avoid the "SCSI
disc not ready at line ...") error. Although that machine doesn't have
any discs set up for NetBSD it should allow some testing of the
bootloader and new kernels, at least during the initial stages of
bootstrapping. Both machines have Rev. J StrongARMs but there should
be a 610 and a 710 card around somewhere.

With this machine and its RapIDE32 disc, I altered fastboot to fit my
config and then tried the bootloader and kernels. I get up to pioc0:
very quickly (which was "instant" using the old bootloader) and then
it hangs for a while until "wdc0 at pioc0..." appears and then a very
long time later I am informed about my expansion cards (RapIDE32) and
network card (etherh). 

The kernel from the February snapshot that Chris rolled out works fine
(using the old bootloader) and certainly gets through the
bootstrapping faster. There is a delay after the pioc0 line but it is
nowhere near as long as with the other kernel and I get a delay at
each expansion card but it isn't anywhere near as long as the delays
within the new kernels (including the two non-wscons (St
Patrick's Day and 20th Feb ones).

> Offcource it can only run in modes defined in the AKF85 mode definition
> file but rather keep it to more sensible values for now (i.e. 640x480,
> 800x600, 1024x768, 1280x1024 and derivatives) and not below 256 colours...
> these are currently not supported as yet... i'll work on these first.

What do you meany by "it can only run in modes defined in the AKF85
mode definition file"? I thought the bootloader used whatever MDF you
have loaded, although the display does seem shifted to the left
slightly compared to the old bootloader or ordinary RISC OS. I boot
using "X1152 Y864 C256 F69."

> Thanks a lot in advance... having this information is really nessisary if
> i'm gonna solve it :)) for at the moment everything runs smooth here ...

Out of interest, would it be worth adding "symtab" to the default
command-line in fastboot? Especially as the symbol table is in all the
kernels I've tried.
-- 
Andy Wingate <URL:http://www.ox.compsoc.net/~xyzzy/>
GnuPG fingerprint: 8A11 9F2B 198B 7815 0EAB  5E37 4D23 2931 C642 BF8A
No user servicable parts inside.