From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16165 invoked from network); 20 Apr 2023 18:58:01 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2023 18:58:01 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5BAA7412C2; Fri, 21 Apr 2023 04:57:53 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1682017073; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=xcbX0H7gm7sNJ4CWQiFq6TTiDBM7lmFC6CqTaTGXRn4=; b=upFOmbPVgN3Cz1JwZkyVw0cTQOTGv2LAakDpew+UKn/W3ci7FaTm/B1EirkRWuIsl8FPfY DaKaQmc51YhPspHC/uRhFEQ/CcDkXPlwzcLqAEwOQTpeE3A4OIqAg9c7Hbyzam1k4rzFqJ D570mBktNsdk1uy0ZSAUgjuSXyF2Le4= Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by minnie.tuhs.org (Postfix) with ESMTPS id 3A49E412B6 for ; Fri, 21 Apr 2023 04:57:42 +1000 (AEST) Date: Thu, 20 Apr 2023 18:57:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1682017059; x=1682276259; bh=xcbX0H7gm7sNJ4CWQiFq6TTiDBM7lmFC6CqTaTGXRn4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=evfIgeoQo5zZQ+ApbHXZOa6aM1qKrWbyJpi1eCkoM2iZ4fsNVRDSKBhT1Gh8UUEHF 9ZD3RBJlIPPfdBZm7PcTS6gdvPumgy7CCsIrGEJhsdthfSUM00a7mB3AdSfGecTRPz QjlnqA9+JV/8iH6SrovzevEA/1Ln5y76Wuz8Bh49vbwJyIe4E8zjgXD+BOUstYqSZI HhvnS/B66NIFFVsO1luRbJIGLne1xdg9AqWbhiXooVOoGDp8B7F9IWkAdzIsYFp8Wm DdjP89Tv1p9ZRDocRt10wIhUosrrh0r/UFq+caxAH3o9x29gaXCmzpV8AR2r9V+0CN ebZMuTeeuJuzw== To: Paul Ruizendaal Message-ID: <5A9q989Xqp3qAU5v84HciEjrFF9tcvviKQYlxhwTCbnDjEARnMx_BtNkzqXR_0Y0nAkzCdaSR6KGqWCQgwjUW_ydfz6iQSFKRvTnhGiqyc0=@protonmail.com> In-Reply-To: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> References: <2CB8870A-5FE5-4D02-ABF4-C8E520F8A2D1@planet.nl> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: ZRBX5PHGTX2OS23XG7YUPVY7EAXZMFPS X-Message-ID-Hash: ZRBX5PHGTX2OS23XG7YUPVY7EAXZMFPS X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "tuhs@tuhs.org" X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: UNIX "Machine Layer" Standards List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco The funny thing is what literally started all of this is I wanted to update= the firmware on my VisionFive, followed their instructions to a T, and it = bricked the firmware. I found that the embedded recovery ROM still worked, so then tried to follo= w their processes to reflash the bootloader/SBI stuff. That likewise faile= d, so I gave up on trusting any of their documentation/advice and just star= ted hacking on the thing with binaries sent over XMODEM on the serial line.= Their XMODEM-CRC implementation is broken so I even had to write my own v= ersion of sx (they had a XMODEM send, likewise doesn't work stock...got it = to work modified but then just wrote a simple stdio tool without all the cr= uft of their implementation.) Fast forward to today and the most I've put together for that is this: http= s://gitlab.com/segaloco/riscv-bits (src is "kernel" stuff, util is that XMO= DEM-CRC transfer thing I mentioned) I've got some process handling and VM stuff that hasn't gone up to the repo= yet, but it's hanging around because it's incomplete anyway. I then reali= zed with what I'd learned in the process I was poised to start hacking on o= ther SBCs at that level, so ordered the Pico, Ox64, and an Onion Omega2 (AR= M32, RV64, and MIPS32 respectively) and have slowly been building up develo= pment workflows for each (I'm eschewing vendor libraries and SDKs given my = experiences with the VisionFive...) The boot matter itself is proving the most annoying part, since literally e= ach one of those has a different mechanism to get an operational binary loa= ded up. VisionFive is an (broken) XMODEM-CRC transfer, Pico is a UF2 file = over USB, Ox64 is some custom Bouffalo Lab tool (although I think it's just= a wrapper on top of some standard XMODEM/Kermit/etc. type protocol), and t= hen the Omega2 I haven't even really explored raw boot yet, it's got OpenWR= T on it so I've just been hacking on the existing OS thus far, getting more= familiar with the board, my hunch is it's probably a UF2-ish thing since i= t's main UART is over USB like the Pico. RISC-V presents some complications given the privilege model, what with the= "master" mode vs the "supervisor" mode, as opposed to other chips where su= pervisor and master are essentially one in the same. Where I'm torn is if = I want to have OpenSBI in the mix just to go with what is ubiquitous in RIS= C-V land, or even try to handle that matter with my own code. That wouldn'= t necessarily have an analog on all the other platforms. Then there's hype= rvisor stuff, what with RISC-V having the extension and other chips having = something akin to this, but it not being universal. The simple answer is t= o just get everything, regardless of details into a "supervisor" state, ens= ure necessary interrupts are forwarded to this state if another, higher one= exists, and enter into this supervisor state with MMU/VM turned off. Then= theoretically each machine can start from here by setting up memory, then = device inits, then FS and other subsystem init, and finally process init. Anywho, I'm kinda at a standstill on this project right now while I work on= a few other things, namely a disassembly of Dragon Quest for the Famicom (= embedded console games are a lot like operating systems) and manual page di= ffing stuff, but I'm hoping to carve out some time this summer, maybe even = a little coding retreat from work for a few weeks, to hammer out a true pro= ject plan on paper so I can start working on more of this in earnest. I'm = not sure yet if I'll be headed down the "get UNIX going" or "get my kernel = going" route first when I get there, but either way, I'm sure we'll have pl= enty to talk about in the coming year. - Matt G. ------- Original Message ------- On Thursday, April 20th, 2023 at 8:57 AM, Paul Ruizendaal w= rote: > Hi Matt, >=20 > I=E2=80=99ve responded on list about the early unix development process a= s I understand it, but I want to avoid discussing things that are not direc= tly related to the history of Unix. Hence this PM as well. >=20 > > Where I'm trying to put this sort of knowledge into use is I'm starting= to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (AR= M32 and RISCV64 respectively) that is not only sufficient to start a V7-ish= kernel on each, but that are ultimately based on the same design, varying = literally only where the hardware strictly necessitates it, but similar eno= ugh that reading the two assembly files side by side yields essentially the= exact same discrete operations. >=20 >=20 > I have a similar interest, working with early Unix and modern RiscV hardw= are for a compare and contrast experience. >=20 > - My development targets are (i) an FPGA based RV32 SoC implementation, (= ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V. >=20 > - My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experim= ents around SysIII >=20 > Linux is for me a secondary target, just for comparison and to see if ide= as are =E2=80=9CLinux capable=E2=80=9D. I=E2=80=99m not overly interested i= n Arm at the moment. >=20 >=20 > My ideas are still evolving, but currently more or less along the below l= ines: >=20 > - Boot rom loads SPL, this is custom in each case and set by the SoC's de= signers. >=20 > - SPL initialises DRAM system and loads next stage. Unfortunately, this t= oo would seem to be quite system specific, but the BSP should provide the b= aseline for this. As BSP=E2=80=99s are often a mess, milage may vary. >=20 > - The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to p= rovide a standard abstraction layer that all of my software targets can wor= k with. This idea is used for the FPGA target and allows booting a Linux ke= rnel with just the generic Virtio device drivers (so far just disk and cons= ole). >=20 > - The last layer is the classical OS layer. If I get it right, each OS ca= n run on all h/w targets without customisation. >=20 > At the moment I=E2=80=99m playing with USB, and how that might layer into= the structure of V7, SysIII or 8th Edition -- and also the above. >=20 >=20 >=20 >=20 >=20 >