Linux kernel 2.6 on Risc 600 machine
ivelegacy (2674) 139 posts |
hi thank you in advance (1) in case i can emerge a brand new one, i am used to use catalyst to generate stages1-4 with all the profiles i need. I am used to use Qemu/Arm as virtualizer in order to cook them, as i do not trust cross-compiling, i trust native compiling, so i put a genuine arm machine inside Qemu. |
Raik (463) 2030 posts |
Not sure, maybe it helps. I know this place for RiscPC ArmLinux. |
ivelegacy (2674) 139 posts |
yes please, let me know. |
Raik (463) 2030 posts |
Better, send a mail via my contacform at http://riscos.openpandora.org and I will send it forward to the maintainer of the disc. |
Theo Markettos (89) 919 posts |
Debian etch includes a 2.6.18 kernel: It may well be feasible to build a later one (2.6.x) – I don’t think anyone has tried. |
ivelegacy (2674) 139 posts |
i have found this url, which seems interesting because i can see kernel sources (and patches) i can’t find any boot loader, i mean all the links are broken. Does anyone has a kernel loader for RiscOS ? |
Raik (463) 2030 posts |
I use RedHad in the past. There is not a real bootloader. I remember Linux install was a little fiddly. |
Theo Markettos (89) 919 posts |
Here’s an old version of the tools: The latest version of the loader can be found here: |
Ken Foster (416) 2 posts |
http://mirror.inode.at/data/slackwarearm/armedslack-11.0/ for the RPC Slackware port. I do remember compiling a Gentoo kernel and rootfs for the RPC a few years ago. IIRC, I used distcc and three qemu-system-arm instances (each on a separate core) with -j3 in MAKEOPTS where possible (I did try a qemu chroot, but had little success using that method). This allowed the configure scripts to run on the host machine (and therefore much faster). I believe the latest kernel I ran was 2.6.22 (or possibly 2.6.23). |
ivelegacy (2674) 139 posts |
@Ken Foster how pretty is the support of linux for RiscPC ? |
Ken Foster (416) 2 posts |
I think I just used vanilla-sources (honestly can’t remember now, though). From what I remember, it ran pretty slow and as a result I never got much further than a basic shell environment TBH (didn’t try X or anything). I do remember the I2C support was broken in the last few kernels I built, which meant no RTC support. Other than that, hardware support was pretty good – the kernel was fine with all the various NIC podules I threw at it and even supported my PowerTec SCSI card). |
Andrew Wickham (2067) 18 posts |
Just found this thread after playing with kernel compilation on my RiscPC over the last 2-3 weeks, with a view to changing the 2.6.18-6 Debian kernel in two ways: 2.6.26 compiled and booted but with an error relating to tmpfs, so / is read-only – and the device naming scheme has switched to “sda” in place of “hda”, which is not a problem if I can use UUID in fstab, but without tmpfs the relevant bits of /dev/disk do not get set up. So I thought I’d try re-compliing with the legacy ATA support rather than libata. But not yet managed to get a kernel out since a “vanilla” 2.6.26 (i.e. based on an unmodified “make rpc_defconfig” version of .config). Perhaps a better route would be to generate an initrd file to load from RISCOS, as one does for installation. There’s no RiscPC-specific version of the kernel sources for 2.6.26 in etch, so 2.6.18-6 is the latest supported by packages. But the “arch/arm/mach-rpc” code is still there in much more recent sources (good luck with compiling 4.2!) The 2.6.19 kernel from slackware-arm fails to boot (blank screen after the linloader text) but that may be a matter of (i) it needs GRUB or (ii) mixing a slackware-arm kernel with a Debian installation. With the working 2.6.18-6 kernel (and “etch” packages, upgraded from a 2.2 installation via 3.0), command line is fine (if slow) and XFCE4 starts – but only in 640×480 despite 2MB VRAM and what looks like a sensible xorg.conf. Ken – would you mind sharing any kernels you made (if still available)? |
David Feugey (2125) 2687 posts |
Very interesting. I know it’s off topic, but I’m curious about ARM3 support… |
Theo Markettos (89) 919 posts |
initrd is probably the way to go – most modern Linux distros use that. It also makes for much easier handling of drivers, because they can all be modules in the initrd rather than having to bake them in. That would require modifying linloader, but I don’t think it would be that complex: get linloader to allocate another chunk of contiguous physical memory as it does for the kernel, and dump the initrd in there. It then needs an ATAG to supply the initrd address to the kernel. |
Andrew Wickham (2067) 18 posts |
Theo, thank you for the guidance. linloader can cope with loading an initrd file accessible under ADFS (as used for the installation), so I presume at least some of necessary functionality is there already. If I can generate one, copy it out of the ext2 partition and refer to it in the parameters passed to linloader that might do the trick straight off if I’m lucky! Need to sort out cross-compling on something faster. At least I am getting output again – it seems that while no zImage appears after “make bzImage”, “make modules_install install” puts a new kernel into /boot with the corresponding system.map. But one cycle of config/make takes all day! David – there is still the “acorn26” port in NetBSD, but on the Linux side as far as I know Debian and Slackware has never targeted anything before RiscPC. There is a kernel for A5000 on Russell King’s ARMLinux site but that is 2.0.36, and while there is a root disk image the lack of a “supplemental” disk probably makes installation “interesting” – see ARMLinux Archimedes is still on the machine list so maybe I’ll try compliing for the A540 (once I’ve set up the cross-compiler!) |
David Feugey (2125) 2687 posts |
Thanks for the link. Of course, it’s ‘only for fun’, but it could be more than this. ArchiEmu works at more than 80 MHz on modern hardware. Future ARM3 hypervisor could be much faster. So to get Linux is not such a stupid idea. I mean, no more stupid than to get DosBox an DOS :) |
Theo Markettos (89) 919 posts |
ARM2/3 are also interesting because they’re out of patent. So you can clone them without fear of ARM’s lawyers – there’s an ARM2 on FPGA around. If they are able to run Linux they then become a lot more useful, though the 64 MB address limit is a pain. (MEMC also applies other limits, but you don’t have to use MEMC in a virtualised/FPGA system) |
David Feugey (2125) 2687 posts |
Exact. You even not have to virtualise any components (except ARM), so it could be possible to have a paravirtualized version of Linux for another ARM3 system (FPGA, ArchiEmu, or the forthcoming 80% native speed ARM3 VM from Jon Habbott :) ). |