Date: Wed, 14 May 1997 20:24:42 -0400 (EDT) From: Andrew Gallatin <gallatin@CS.Duke.EDU> To: Warner Losh <imp@village.org> Cc: freebsd-alpha@freebsd.org Subject: Re: Alpha questions.. Message-ID: <199705150024.UAA01463@hurricane.cs.duke.edu> In-Reply-To: <E0wRjz7-0007TB-00@rover.village.org> References: <199705141522.LAA31644@hurricane.cs.duke.edu> <199705140110.VAA31030@hurricane.cs.duke.edu> <11626.863576303@time.cdrom.com> <E0wRjz7-0007TB-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh writes: > In message <199705141522.LAA31644@hurricane.cs.duke.edu> Andrew > Gallatin writes: > : It think there's a basic misconception here between 'console software' > : and PALcode. They are very closely related. Both are required for > : the operation of an alpha, but they serve very different roles. I'll > : try to explain the differences. > > You are correct. I had viewed the two as the same, with one providing > services to the OS. Like I said in a previous mail, ARC/mips is > different than ARC/alpha. Mips doesn't have PAL code at all, but does > have a number of interesting entry points that would be useful if they > could be called once the system had been booted into multi-user mode. > > : Anyway, I hope this helps. I'm *NOT* a linux fan & realize their boot > : process is a mess. I'm just attempting to understand it and am > : beginning to realize that there is a point to it. > > Yes. You do seem to understand it very well. You have given me what > I had hoped to have: Lots of pointers to books that I could afford buy > will buy anyway :-). And pointers to the Linux stuff (which I posted > one of to the alpha list). And a few things that will take quite a > while to read through. What I've read so far has been very good and > seems to be accurate (in that it doesn't contradict itself or other > things I've seen before). > > The boot process isn't at all clean, but I don't see too many ways to > make it cleaner, so more thought is needed on the matter. > > It looks like we may be able to leverage off of NetBSD's code here > since the boot stuff would likely just need to grok FAT, ufs and > isofs, whcih is what NetBSD's boot blocks already do. There may need > to be more glue on the loader than you'd need for the SRM code (since > you have to load the other PAL in), but abstracted out, Linux is just > doing a classic 2 level boot with some extra cruft tossed in. > Right. ;-) I think the quickest way to get bootstrapped might be to use the SRM console (being very careful NOT use any functions that cannot be provided by a future Milo-like FreeBSD console program). The SRM console is available for every machine I can think of with the exception of the XL series personal workstations. For most machines, the SRM console is freely available from ftp://ftp.digital.com/pub/DEC/Alpha/firmware. For EB* motherboards, one can order the "Alpha EBSDK and Firmware Update Kit" from Digital (current part number QR-21B02-03, cost $75). This kit includes a CD-ROM from which you can install the SRM console. This proposed reliance on the SRM console would only be a temporary measure until such time as custom FreeBSD console software could be written. The best time for that would seem to be only after FreeBSD was stable enough to be able to tell if the OS or the bootloader was at fault when debugging ;-) One thing to keep in mind is that if you're going to do something similar to what linux does with Milo: one needs to be certain that the the kernel bootstrap process is restriced to using only the functionality that can eventually be provided with FreeBSD console software. I have the feeling that Milo provides a much smaller set of I/O routines (eg, for the OS to use before its fully bootstrapped) than does the SRM console. I think one of the reasons that Milo has DEC's blessing is that Digital UNIX & OpenVMS must rely on functionality that the SRM console provides, but that Milo doesn't. Hence, DEC can use the SRM console a form of copy-protection for their cash-cows. Another rather important issue that needs to be hashed out is what sort of disk-layout to support. Are you going to be using NT/Linux style fdisk slices, or are you going to be using the entire disk like NetBSD & Digital UNIX do? Or both? (sorry if this has already been decided, I just joined the list yesterday & haven't been able to get an archive yet ;) Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705150024.UAA01463>