From owner-freebsd-sparc Tue Nov 17 15:07:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05462 for freebsd-sparc-outgoing; Tue, 17 Nov 1998 15:07:59 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from atdot.dotat.org (atdot.dotat.org [203.23.150.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05451 for ; Tue, 17 Nov 1998 15:07:54 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.8.8/8.7) id JAA00931; Wed, 18 Nov 1998 09:36:42 +1030 (CST) From: Mark Newton Message-Id: <199811172306.JAA00931@atdot.dotat.org> Subject: Re: Porting process (Again) To: paipai@tin.it (Paolo Di Francesco) Date: Wed, 18 Nov 1998 09:36:42 +1030 (CST) Cc: freebsd-sparc@FreeBSD.ORG In-Reply-To: <19981117191824.ELKO23830.fep03-svc@winworkstation> from "Paolo Di Francesco" at Nov 17, 98 08:19:59 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Paolo Di Francesco wrote: > Step #1) Read docs about the booting process, and do experiments on it. > This means we need to write some asm code and do some unusefull things, > such as to print on the screen "Hello world". I can do it on i386 using > a floppy. This mean I can boot ANYTHING from the floppy. (Well, I loaded > an image directly from the boot sector). The same thing will happen > under Sparc. > This will improve the asm skill... NetBSD's /sys/arch/sparc/stand probably has everything you need. Indeed, "borrowing" their bootblocks and standalone code verbatim might be possible. > Step #2) Choose a version to start from. (Maybe 3.0?) Absolutely: 3.0-CURRENT. You don't want the port to be obselete before it even starts. > Step #3) Isolate the asm (i386) code from the FreeBSD kernel code. This > mean : > Step #3.1) Isolate the asm directory and then the asm source files. Many > of the directories have no asm code, so we need concentrate on the dirs > which HAVE asm code. Then, in these dirs many files have no asm code. > And so on. So a document with a tree like [ yada yada ] /sys/i386/i386 should be the only relevent directory which asm code in it (there is also some in /sys/i386/isa, /sys/i386/boot and /sys/i386/linux, yes, but you aren't going to have a SPARC box with an ISA bus or i386 bootblocks, are you?). Some (most?) of the asm code in /sys/i386/i386 is only assembly language for speed, and could just as easily be written in C (indeed, some of it used to be C, from memory: bcopy routines spring immediately to mind). There's also a small amount of assembly-that-could-be-C in /usr/src/lib/libc/i386, but you aren't worried about userland yet anyway, right? Oh, I guess you'll want to port the system call stub routine -- Grab NetBSD's. > Step #3.2) Understand priority. What we need NOW to boot... For example > we do not need "low priority" files which are not usefull for the first > kernel version. Probably the easiest config for initial testing is something which includes the basic kernel, a PROM console device driver (no framebuffers or anything) and a PROM polled ethernet driver. With that config you can use an NFS root filesystem, so you won't have to write/debug any SCSI device drivers to get things up and running (if you use interfaces to the PROM devices you won't have to write any hardware-knowledgable device drivers at all. If you're polling ethernet/console you won't even need to care if your embryonic interrupt system is slightly broken). > Step #4) configure the base kernel and compile it under i386. Natch. Port the toolchain to run on NetBSD/sparc (or NetBSD/sparc64) and develop there. Cross compilation on an i386 isn't necessarily a win. > Step #n-1) Write the device dependent code. Controller, network cards, misc > cards, and so on. Probably start with a hardware-knowledgable ethernet driver to replace the (high-overhead) PROM driver, then do SCSI, then take it from there. On the uSPARC a lot of the PCI drivers have already been written for you; You'd just need PCI glue code. The new bus abstraction being worked on for FreeBSD-current might help a lot here too. - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1958-3414 ------------- Fax: +61-8-83034403 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message