In <URL:news:local.netbsd.port-arm32> on Sun 12 Nov, Mike Pumford wrote:
> 
> 
> > > Right this has now been updated. Its the same kernel but the terminal type now
> > > defaults to vt100 . I did have to modify the vt100 termcap entry slightly. It
> > > appears that the RiscPC console does not emulate the vt100 alternate character
> > > set so I removed these entries from the termcap.
> > >
> > > Do these modification need to be worked into a PR?
> > 
> > 	Defintely. Thinking about it more it would be nice if the terminal
> > 	type could be set automatically based on whether ths shark's pc0
> > 	is found in dmesg. That way the ramdisk could be shared between
> > 	machines.
> > 	Would you be willing to look at that? (sample shark dmesg attached
> > 	:)
> > http://www.black-star.demon.co.uk/RPCINST.gz
> 
> Well I think I have something that works. I have uploaded new install kernels 
> for all arm32 machine types apart from A7000.
> The URLs are:
> http://www.black-star.demon.co.uk/RPCINST.gz
> http://www.black-star.demon.co.uk/CATSINST.gz
> http://www.black-star.demon.co.uk/SHARKINST.gz
> 
> The SHARKINST kernel should start sysinst with the terminal type set to pc3.
> The CATSINST and RPCINST kernels should start sysinst with the terminal type 
> set to vt100.
> 
> Any volunteers for testing?

The RPCINST kernel is now using vt100, but there are still a few minor
hickups with the screen updates. When setting the network, it does not
show anything when running the ping, and it does not always clear away
the old information. Maybe this is the way it should be?

It also looks as though the panic when the internal IDE interface is
probed and fails with the interrupt problem is gone. Still it keeps on
retrying and retrying, so it really is not too much better.

Another thing that happened with the previous kernel is that it ruined
my RISC OS part of the drive when I set it up in NetBSD. This is with a
Power-tec SCSI-2 card. The RISC OS part of the drive now gives me a
broken directory error when I try to access it.

Also, the calculated figures where all wrong, as they summed up to
almost twice the amount of MB on my 170 MB SCSI drive.

But, still, we are getting somewhere, and that is very good.

Kjetil B.
mailto:kjetil@thomassen.priv.no
http://www.thomassen.priv.no/