Re: Booting on RiscPC

●To: Mike Pumford <mpumford%mudcovered.org.uk@localhost> ●Subject: Re: Booting on RiscPC ●From: Stephen Borrill <netbsd%precedence.co.uk@localhost> ●Date: Fri, 28 Feb 2025 12:19:26 +0000 (GMT)

On Mon, 1 Apr 2019, Mike Pumford wrote:

On 28/03/2019 09:43, Stephen Borrill wrote:

On Wed, 27 Mar 2019, Mike Pumford wrote:

It may take a few days as I'm going to be away from the hardware but I'll have a look into the driver and see if I can see any way for that keyboard failure to happen. Is the behaviour consistent? does the same key always give the same pair of characters?


Yes, always consistent.

I did find a couple of possible start of day quirks where we could potentially take an interrupt before the code was really ready. I've also added code that drains the keyboard input before we attach (the pckbc code does this and it seems reasonable given that the code is taking over control from another OS). Not sure if this will help you out or if we need to do more things to ensure the keyboard controller is in a sane state when we take over from RISC OS.

For the moment, I have swapped out the HP keyboard for a V7 one and that works fine.

NetBSD 8 is the latest version that boots on RiscPC as far as I can see because of the toolchain updates as discussed in this thread:

https://mail-index.netbsd.org/port-acorn32/2019/03/29/msg000088.html

The 8.3 INSTALL kernel occassionally panicked when pressing keys and I worked out that this actually down to it trying to beep (so a spkr/vidcaudio problem), but I managed to do an install. I have a Simtec RapIDE card and it detects the (spinning) drive attached to that as wd0, but does not detect the driver attached to the onboard IDE (as that has RISCOS on, this had the nice side-effect of me not breaking RISCOS!).


The 8.3 GENERIC kernel panics around here:
pioc0: SMC FDC37C665GT peripheral controller rev 2
wdc0 at pioc0 offset 0x1f0-0x1f7 irq 9
atabus0 at wdc0 channel 0

I compiled up my own GENERIC kernel from the head of netbsd-8 and that booted fine. The panic on beep has gone away too. dmesg here:

https://dmesgd.nycbug.org/index.cgi?do=view&id=8258

Some binaries, notably syslogd and ssh-keygen, are core-dumping on

Illegal instruction. I think this has the side effect of stopping me logging in at the console multi-user. I can rsh to it, but rlogin and telnet just close the connection.

I don't know how feasible it is to get a modern toolchain to spit out code that will work on an ARM6/7 or StrongARM especially with the RiscPC's hardware issues with ldrh/strh.


--
Stephen

●References: ●Re: Booting on RiscPC ●From: Mike Pumford ●Re: Booting on RiscPC ●From: Stephen Borrill ●Re: Booting on RiscPC ●From: Mike Pumford ●Re: Booting on RiscPC ●From: Mike Pumford ●Re: Booting on RiscPC ●From: Mike Pumford ●Re: Booting on RiscPC ●From: Stephen Borrill ●Re: Booting on RiscPC ●From: Mike Pumford ●Re: Booting on RiscPC ●From: Stephen Borrill ●Re: Booting on RiscPC ●From: Mike Pumford

●Prev by Date: Re: Booting on RiscPC ●Previous by Thread: Re: Booting on RiscPC ●Next by Thread: GCC 7 problems ●Indexes: ● reverse Date ● reverse Thread ● Old Index Home | Main Index | Thread Index | Old Index