The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: The Unix Heritage Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Question about BSD disklabel history
Date: Sun, 31 Dec 2023 16:46:49 -0600	[thread overview]
Message-ID: <20231231224649.h45pogxycgkgs673@illithid> (raw)
In-Reply-To: <CAC20D2My_R8mmuV3kgApdW2WZOBBuHzmOpzKDxKx=ZaNgmmVZw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3439 bytes --]

At 2023-12-31T16:31:00-0500, Clem Cole wrote:
> Next (ney Apple) started with the Mach code base from CMU.  There was
> a push in the Valley in those days for something called OpenFirmware
> [Warner help here -- I think that it was forth based IIRC, and Sun may
> have had their hand in it also].

I'm not Warner but I owned and operated a few OpenFirmware based
machines.

> But the key is that it ran on 68K's.

I don't think that's the case.  OpenFirmware (OF) ran on SPARC and
PowerPC hardware, at least.  And since it was indeed Forth-based, in
principle it could have been ported practically anywhere (assuming
memory requirements for OF itself were met).

The m68k "Old World" PowerMacs used a different firmware entirely; I
assume boot ROM code descended from the original Macintosh (or even
Lisa, maybe).  The PowerPC "New World" PowerMacs, which immediately
departed from the beige color scheme, did come in with Apple's
acquisition of NeXT.  This may have been the last good thing that Steve
Jobs had a hand in.

On Sun SPARC machines you could get to an OF prompt at any time by
typing "Stop+A" (a.k.a. "L1+A"), using one of the funny left-hand side
function keys on a generation or two (Type 4??) Sun keyboards.  This was
a lot like the "programmer's switch" on some m68k Macs, which was wired
directly to an NMI that MacOS ("Classic") had a fixed vector for.

Open Firmware was an excellent idea; true peripheral portability was
achieved by having "option ROMs" on devices that needed them implemented
in Forth like OF itself.  A lot of flexibility here.  I don't know how
much of a performance price was paid--people did and do enjoy getting
into bootup-time races--but even if it were competitive, the PC side of
the industry would have stridently claimed it wasn't.

A lot of non-x86 Cisco kit in the 2000s (some PowerPC, and _maybe_ some
MIPS stuff too(?)) used some kind of cut-down descendant of OF called
OpenHackWare.  I'm not sure what its dimensions were; it may have mostly
been just the conventions and format that we now recognize as "device
tree" (DTS/DTB), which has perhaps been OpenFirmware's proudest legacy.
It beat the hell out of the PC BIOS alternative for device enumeration,
which always appeared to me to be pure binary chaos with no standard
apart from whatever Microsoft wanted for Windows.

By contrast, OpenFirmware was standardized in IEEE 1275.

> By the time the Intel Mac's BIOS had begun to be replaced in the
> WINTEL world by UEFI, Apple committed to using a flavor of it.

Originally EFI, without the "U".  I first saw these on first-generation
Itanium machines--huge, hot deskside HP boxes whose innards appeared to
use composite foam like that from aircraft wings for heat piping.  The
company I worked for was contracted to help achieve the Linux ia64 port.

I was immediately horrified by EFI's huge step backwards in concept and
implementation.  All this technical progress just to return to
unportable device driver ROMs and a C:\ prompt.  The hatred of the
Wintel duopoly toward elegance or cleanliness in any aspect of computing
cannot be overstated.

I'm weakly hopeful that the RISC-V community will rediscover
OpenFirmware.  It has to date had the good sense to avoid UEFI.  A wise
choice, as if they they hand Intel that much control over their
ecosystem, they will surrender all independence, and possibly the
architecture itself, at least in real silicon.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-12-31 22:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 17:30 [TUHS] " Grant Taylor via TUHS
2023-12-31 17:38 ` [TUHS] " arnold
2023-12-31 20:07   ` Warner Losh
2024-01-01  0:13     ` Bakul Shah
2023-12-31 20:27   ` Phil Budne
2023-12-31 21:02     ` Warner Losh
2024-01-01  0:26   ` Grant Taylor via TUHS
2024-01-01  2:22     ` Warner Losh
2024-01-01  3:24       ` Grant Taylor via TUHS
2023-12-31 21:31 ` Clem Cole
2023-12-31 22:07   ` Warner Losh
2024-01-01 16:00     ` Clem Cole
2024-01-02 18:49       ` Warner Losh
2024-01-02 19:30         ` Chet Ramey
2024-01-02 20:07           ` Clem Cole
2024-01-02 19:50         ` Dan Cross
2024-01-02 19:55           ` Jim Capp
2024-01-02 20:11             ` Dan Cross
2024-01-02 20:30           ` Dan Cross
2024-01-02 20:50             ` Clem Cole
2024-01-02 21:04               ` Dan Cross
2023-12-31 22:46   ` G. Branden Robinson [this message]
2023-12-31 23:06     ` Larry McVoy
2023-12-31 23:37       ` Al Kossow
2023-12-31 23:41       ` Alec Muffett
2024-01-02 20:48       ` Dan Cross
2024-01-02 21:17         ` John Cowan
2024-01-03  3:33         ` Theodore Ts'o
2024-01-03  3:57           ` Warner Losh
2024-01-03  4:03             ` Warner Losh
2024-01-03  4:30             ` Theodore Ts'o
2024-01-03  5:10               ` Warner Losh
2024-01-03 15:56                 ` Dan Cross
2024-01-03 16:37                   ` Theodore Ts'o
2024-01-03 16:41                     ` Dan Cross
2024-01-04  8:42                     ` arnold
2024-01-04 18:26                       ` Kevin Bowling
2024-01-03 14:39           ` Dan Cross
2023-12-31 23:08     ` Phil Budne
2023-12-31 23:37       ` G. Branden Robinson
2023-12-31 23:59         ` Warner Losh
2023-12-31 23:50     ` G. Branden Robinson
2024-01-01  0:09       ` Al Kossow
2023-12-31 21:55 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231231224649.h45pogxycgkgs673@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).