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. _______________________________________________ http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm http://www.arm.linux.org.uk/armlinux/mailinglists.php Please visit the above addresses for information on this list.
