Date: Wed, 08 May 2002 11:35:45 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: John Baldwin <jhb@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: *bsd on srm-less alpha's Message-ID: <3CD97001.89254E73@mindspring.com> References: <3CD8BADE.D7D0FC8C@mindspring.com> <XFMail.20020508081041.jhb@FreeBSD.org> <15577.7766.160517.751366@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote: > He's talking about using MILO, which, at least as of 2.1.13, uses the > OSF PALcode. What nobody knows is if the PALcode in milo is close > enough to the "real" OSF PALcode used by the SRM for it to be usable > by FreeBSD. It certainly seems close, as it has the text "SRM" and > "OSF" littered all over it. > > Now, I've heard various people talk about how we need certain VM > related PALcode functions that aren't avalable in the MILO palcode, > However, nobody has mentioned exactly which function this is, and I > think this might be an urban legend. I used to know this. I can describe it in general terms. Linux has abstracted its translation lookaside so that it can handle it in software for those processors, like MIPS, which require it. FreeBSD tries much harder to get the processor to do the work, and is less abstract. THis means that FreeBSD gets higher performance on platforms where hardware assitance is possible. The PAL code that MILO has in it is a demo version of the SRM PAL code that was given to the University of Arizona; the main difference was to permit the use of only 16M, instead of requiring 32M (my Alpha at the time had only 16M, as well). It has a couple of known bugs in areas that FreeBSD actively used (one is that a return value is not propagated for one of the functions used in paging). I don't know if this is still true of FreeBSD; it is for NetBSD; here's what NetBSD has to say: http://netbsd.org/Ports/alpha/faq.html#milo The Alpha port of Linux can boot on systems with NT firmware not because they can use the NT PALcode, but because MILO, the Alpha Linux loader, includes its own PALcode. (This of course means you need a different loader for each system type.) The MILO PALcode is: o Based on very old Digital Unix PALcode (from the DEC EBSDK). o Missing various features needed by NetBSD. o Known to have a number of serious bugs. o Worked-over to be built with a totally different toolchain than the PALcode in production SRM. Ross Harvey was on the verge of fixing some of the more obnoxious bugs in it once but managed to obtain the real SRM PALcode for the project on which he was working, so he didn't. It is probably more productive to spend time persuading DEC to release SRM for more platforms, or to release the unmodified source code to a current SRM, including the PALcode, than fix the MILO PALcode for NetBSD, particularly as Linux also uses SRM for more modern systems. FWIW, this same page has a discussion of the issues and documentation for the NT firmware (ARC BIOS): http://netbsd.org/Ports/alpha/faq.html#nt-firmware They say they don't like it because: o It's very geared to NT's kernel model o Memory management is essentially MIPS-like, and also limits the virtual address space to 32-bit (except for some virtual address extension hack used to get at the hardware in the kernel) o It's ... amazingly large and complex. The number of NT PALcode calls is simply mind boggling. The first one is a given. Not a valid complaint about it, really. The last one is not really an issue (I think; unless the functionality is spread all over many calls, so you can't just ignore them). Actually, I'm not sure if the 32 bit limitation is *any* address space, or only user address space... I think it means the KVA space is allowed to be larger, using the "hack". Chris Demetriou collected a lot of documentation necessary for the work (heck... necessary for all Alpha work, to date): ftp://ftp.netbsd.org/pub/NetBSD/misc/dec-docs/index.html But there doesn't appear to be a description of how to get the green or red books. > I do agree that getting this to work just isn't worth the time and effort. For you or me... but it would be an interesting way to learn about FreeBSD internals, without having to go through all the pain that would normally be associated with a completely new architecture. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD97001.89254E73>