notes on riscpc install
This afternoon I installed woody from scratch on a RiscPC. All in all I
think it was a relatively successful enterprise, though there were a few
sticky areas. Maybe these notes will be helpful if anybody is
interested in documenting the process or fixing the problems.
I used the 3.0.22 boot-floppies images from the archive, and installed
over the network. The standard kernel crashed fairly frequently during
the install; I replaced it with one built from 2.2.20-rmk3 sources and
didn't have any further trouble on that score. I'm not sure yet what
was going on there.
After rebooting the system at the end of the first stage install, you
have to manually arrange to launch the kernel with the right "root="
argument in order to start the second stage (and of course for all
subsequent boots). This is a bit more technical than it probably ought
to be, but probably unavoidable.
Update-menus segfaulted during base-config. When I started trying to
debug that problem, it went away. I'm not sure if this was just some
random effect, or a symptom of further kernel problems, or something
more sinister.
Strace doesn't appear to behave properly. It just displays the first
"execve" line, and then nothing further (though the inferior runs to
completion as normal). An identical strace binary seems to work OK on
one of my other machines, so perhaps this is a kernel problem of some
kind.
Then I started trying to make X work.
Firstly, the X server refuses to start because of iopl issues. I filed
#141357. The workaround in the meantime is:
# ln -s 03000000,2 /etc/arm_systype
Secondly, /dev/sunmouse was not created and I had to do it manually. I
filed #141391.
Thirdly, I was getting "FBIOPUT_VSCREENINFO: Invalid argument" errors.
This seemed to be caused by my choice of 24bpp as my colour depth.
Changing to 16bpp allowed the X server to start without error but the
screen was completely blank. 8bpp appeared to work OK.
As an aside, selecting 16bpp at the text console with "fbset -bpp 16"
seemed to be fine apart from the cursor, which disappeared at first and
then changed to purple. Selecting 24bpp in this way gave the same error
as I was getting with X.
I don't know whether these are kernel, X or configuration problems, so I
haven't yet filed any bugs. (My kernel configuration has all of the
CONFIG_FBCON_CFB.. options set to "y".)
Fourthly, once I managed to get the server started, the keyboard was all
screwed up. This is presumably an effect of the infamous
Archimedes-style scancodes that the kernel uses here. Using "-kb" is a
partial workaround, but something better is clearly required. I filed
#141392.
That's it for now.
p.
--
To UNSUBSCRIBE, email to debian-arm-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: