Date: Sat, 13 Dec 1997 00:02:15 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jasone@canonware.com Cc: jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: Beginning SPARC port Message-ID: <199712130002.RAA17704@usr04.primenet.com> In-Reply-To: <Pine.LNX.3.95.971211075254.19030U-100000@paladio> from "Jason Evans" at Dec 12, 97 03:51:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Compiler issues... gcc already supports the target platform. Standard > gcc supports SPARC, and Cygnus has a patch to support the Ultra (V8+). > What are the issues you refer to? Since FreeBSD is supported in the > release version of gcc, don't you guys just copy it into your tree and > call it good? Since the Ultra compiler won't be self-hosted until well > after the kernel is up and running, why is this important as a first step? There are GAS hacks for weak symbol support in an a.out environment, and there are binutils hacks for BSD shared library technology, which is not identical to SunOS 4.x shared library technology (BSD shared libraries have a single file instead of needing seperate files for linker stubs and data vs. library text, as in SunOs 4.x). Because of this, FreeBSD currently uses a very old version of binutils that has been hacked up. Specifically, FreeBSD has its own "ld" and "ld.so". The general feeling seems to be that we need to go to ELF. This sort of implies that the FreeBSD SPARC port should discard the FreeBSD a.out format entirely, and use an actively maintained toolchain so that you won't have to duplicate the local hacks for SPARC. > Even linker/loader issues seem like a longer term goal, because the kernel > itelf is bootstrapped (unless there's shared code there - I haven't looked > yet). It seems to me that the first major steps are: > > 1) Get the kernel to boot (and more or less work). You can do this with only a console (serial port or real console) driver. To do this requires using DEVFS and MFS. This lets you load an image with whatever loader technology, and bring the kernel up without a local media file system. Without using DEVFS, you will need a net driver for NFS, or a local media driver for a local media file system (probably FFS). Part of getting the kernel working is in doing a lot of hardware specific things. These need to be abstracted (this is my opinion) to make ports easier. I think these should be encapsulated via a C interface, so that for a new port, you can write a C stub that provides the hardware specific information as hardcoded values for the porting hardware you are using. Memory size, etc.. All the things you would get from PPCBug, M68kBug, OpenBoot, PC BIOS, etc.. I would be happy to help with this code. Another part of getting the kernel working is to convert all of the assembly code over. I think a lot of this code could be written to have C equivalents, and interfaces that expect assembly should be changed if the same functionality can be achieved, however more slowly, with C code. I would be very happy to work on this as well; it won't even require that people buy a SPARC machine to contribute to this process. The biggest challenge I think you will face in this phase is in getting the VM running, and then keeping it in sync (this is where I had problems in a PPC port I've since shelved). You will need to get a commitment from John Dyson on working with you on this, either to act as an information source and to get notification of changes, or to "freeze" the VM for everything but bug fixes for the duration of the porting process (this is what finally made me shelve the PPC port -- I was running PPCBug firmware, so I couldn't even leverage the NetBSD code). > 2) Probe hardware devices. > 3) Create minimal number of device drivers for a minimal complete system. > 4) Move to self hosting. All logical steps. #'s 2 & 3 are doozies. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712130002.RAA17704>