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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8769 invoked from network); 1 Jan 2023 21:32:31 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 1 Jan 2023 21:32:31 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C785642456; Mon, 2 Jan 2023 07:32:25 +1000 (AEST) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by minnie.tuhs.org (Postfix) with ESMTPS id 1059641C68 for ; Mon, 2 Jan 2023 07:32:22 +1000 (AEST) Received: by mail-ua1-f41.google.com with SMTP id z3so5848048uao.9 for ; Sun, 01 Jan 2023 13:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Jy9i8yYNArD4d0nWRZi7Tm4lyq3HlBsKzjcalD0yFFs=; b=jo4ucFy5qWrS8EuvbDSOX9v4SxbJjHt3XhvtyTBZZa31JJacY57wpDfbuSkjJQ10XM fDz4e/0hRUmJGlseKROt9HxZXaaLg1yIY4d0SQwCex1253h3yxNsuqKhx2FO1gVAABDD EQlJoe6Q/9xeL6sJlov7+BaujMISYHpJVcIOs+Z94Az71SZwwVEVUyutu3OCXc+HBw9O tRnOdjJ/ZXvydzkySIVGpmacFaMGrb3id+Wi1S/FPcG5Ia6aw9St36Rih+DfywMNQd2X yciBd6e2gT7ExzfGDs6UybP5Uv01h/vD7ClnDw5NFc6x0TAxa7wuVCbzJgLJlp/6I9m4 rQrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Jy9i8yYNArD4d0nWRZi7Tm4lyq3HlBsKzjcalD0yFFs=; b=CG7MYs4ZNJWGf4duSZeqwXB4BSAaFhg9JyfM80SDDvX5oTHjlBRdbqYBp9J/kmjxHs 2UOpdcothtZVV3w0fqhfOY+9c13ktHwULWg/1LFJTJw4oUXsrgobkPCp9sZ5dqxlHsFH 8d5falUN3LPheXyvsjyPqW84UcieBDmFdF4wdni1v4wFgqaXDqPFMw4OK+dwfVwNq0RP 0mqaOrd/QHA/G3DhK06h7R1guETNgdMfhhT1NeI7xbAcZ5sKwotJJ5Kgeq22YWf2fD1v TryPA6YlSeZKPmpq1WJ7Oi7uYWnC4hk9f8z/MCchjwHfUk5TeGYEEhIpaVjdUjd+5PJX byXA== X-Gm-Message-State: AFqh2kokcNXB6XZwsWEfRqZSv+Q3llau+ZgmCiKLaAarlJxtJpMMnQPf RmuMeGPwyXaJmx9eduED88gfDtAHSPVhuu/753c= X-Google-Smtp-Source: AMrXdXt9paQqlLWXkv027cJ6uNKOI9y53+TLBJPp5A/ikRQYERG9a1DHGYL650V9HI4a2X5E4tdDNwK8QBZgVr+dU70= X-Received: by 2002:ab0:3488:0:b0:419:2a92:7be7 with SMTP id c8-20020ab03488000000b004192a927be7mr3424911uar.76.1672608680891; Sun, 01 Jan 2023 13:31:20 -0800 (PST) MIME-Version: 1.0 References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101212609.yjg2poiggil7pwat@illithid> In-Reply-To: <20230101212609.yjg2poiggil7pwat@illithid> From: Rob Pike Date: Mon, 2 Jan 2023 08:31:10 +1100 Message-ID: To: "G. Branden Robinson" Content-Type: multipart/alternative; boundary="00000000000045db3505f13a8e72" Message-ID-Hash: 7VWLB3CMKE3WMEZFSDGLKJOWIMZ3G2EU X-Message-ID-Hash: 7VWLB3CMKE3WMEZFSDGLKJOWIMZ3G2EU X-MailFrom: robpike@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; 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: Porting the SysIII kernel: boot, config & device drivers List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000045db3505f13a8e72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Seems like a good time to pull out the "wheel of reincarnation" paper. http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-disp= lay-processors.pdf I think about it a lot when I ponder the state of graphics these days. The wheel does seem finally to have rusted in place, although I'm not sure I'd choose this exact angle of rotation. -rob On Mon, Jan 2, 2023 at 8:27 AM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > At 2023-01-01T21:29:17+0100, Paul Ruizendaal wrote: > > > Mothy Roscoe gave a really interesting keynote at OSDI'21: > > > https://www.youtube.com/watch?v=3D36myc8wQhLo > > > > What an interesting keynote! At first he makes the case that OS > > research is dead (not unlike Rob=E2=80=99s similar observation 20 years > > before). > > > > However, he goes on to point out a specific challenge that he > > feels is in dire need of research and innovation. In short his case is > > that a modern SoC is nothing like a VAX, but Linux still treats all > > hardware like a VAX. > > As do C programmers. https://queue.acm.org/detail.cfm?id=3D3212479 > > > > That makes figuring out where the host OS image is and getting it > > > loaded into memory a real pain in the booty; not to mention on > > > modern systems where you=E2=80=99ve got to do memory training as part= of > > > initializing DRAM controllers and the like. > > > > That was my immediate pain point in doing the D1 SoC port. > > Unfortunately, the manufacturer only released the DRAM init code as > > compiler =E2=80=98-S=E2=80=99 output and the 1,400 page datasheet does = not discuss its > > registers. Maybe this is a-typical, as I heard in the above keynote > > that NXP provides 8,000 page datasheets with their SoC=E2=80=99s. Lucki= ly, > > similar code for ARM chips from this manufacturer was available as C > > source and I could reverse engineer the assembler file back to about > > 1,800 lines of C. See > > https://gitlab.com/pnru/xv6-d1/-/blob/master/boot0/sdram.c > > I don't think it's atypical. I was pretty annoyed trying to use the > data sheet to program a simple timer chip on the ODROID-C2; the sheet > was simply erroneous about the address of one of the registers you > needed to poke to set up a repeating timer. When I spoke to people more > experienced with banging on modern devices, I was mostly met with > resignation and rolled shoulders. I grew up in the hobbyist era; these > days it is _only_ OS nerds who program these devices, and these OS nerds > don't generally handle procurement themselves. Instead, purchasing > managers do, and those people don't have to face the pain. > > Data sheets are only as good as they need to be to move the product, > which means they don't need to be good at all, since the people who pay > for them look only at the advertised feature list and the price. > > > It does all the expected things (set voltage, switch on the main > > clock, set up the PLL, calculate delays in terms of clocks, train for > > the line delays, probe address multiplexing, etc.) by accessing a > > multitude of registers that appear directly connected to the > > controller fabric. Yet, at the same time it has only a single entry > > point (=E2=80=9Cinit_DRAM=E2=80=9D) that takes 24 (poorly documented) w= ords of 32 bits > > to define the desired configuration (with options to specify =E2=80=9Cd= efault=E2=80=9D > > or =E2=80=9Cauto=E2=80=9D). > > > > Why does the main processor need to run this code? Why is there not a > > small RV32E CPU inside this controller that runs the 1,800 lines and > > exposes just the 24 words as registers to the main CPU? Are the square > > mils really that expensive? Or is this the reason that many SoC=E2=80= =99s (but > > not the D1) have a small side CPU to do this for all devices? > > I can't speak to the economic arguments but it seems wasteful to me to > have an auxiliary CPU that is--or _should_--be used only to bring up the > board. The other problem I have is more ominous. > > "Ah, BMC. Now every computer comes with an extra full-fledged computer! > The main computer is for your use, and the other computer is for the use > of the attacker." =E2=80=94 Russ Allbery > > But the real problem is with the software these auxiliary processors > run. My first encounter with auxiliary processors was with the TRS-80 > Model 16 line in the early 1980s, which was also available as an upgrade > option from the Model II. The II ran a Zilog Z80. The Model 16 upgrade > added a 68000 board which became the main CPU, and the Z80 was relegated > to I/O management. This turned out to work really well. I gather that > big IBM iron was doing this sort of thing decades earlier. That at > least is an honorable and useful application of the additional core, > instead of smuggling your keystrokes and network packets out to > interested intelligence agencies and harvesters for targeted > advertising. > > [...] > > One of the things on my mind was that SoC boards change quite quickly: > > the D1 was last year=E2=80=99s hit with hobbyists, next year it will be > > something else. Not nice if one has to redo 3,500-10,000 lines of code > > for each board. Although I am not a fan of Forth, I can see that it is > > useful when the controller IP blocks of a SoC (or the PCI cards of > > discrete systems) expose some form of re-targetable program needed to > > boot it up. The manufacturer BSP code is just not plug & play. > > Yes. I too think Forth is a little weird but I appreciate its > power/memory footprint ratio. I really admire OpenFirmware and was > intensely disappointed when the RISC-V community didn't take the > opportunity to resurrect it. Forth code seems a lot more auditable to > me than machine language blobs. > > > Maybe the correct solution for my archeology is to just use the > > simpler FPGA SoC as a target. > > Maybe it's the correct solution for anyone who cares about a verified > boot process, too. No one who sells silicon seems to. > > > For a long time I have wondered why early Xenix did not make the jump > > to a product that was split between a BIOS and a BDOS part, so that > > they could sell BDOS-part updates to the total installed base. The > > BDOS part could even be in some kind of p-code. Considering that they > > heavily invested in their =E2=80=9Crevenue bomb=E2=80=9D C-compiler at = the time, this > > type of thinking was close to their hart > > You _really have_ been writing for RISC-V lately... ;-) > > > (the Amsterdam Compiler Kit was a similar idea). I am talking =E2=80=99= 81-=E2=80=9983 > > here, thereafter it is clear that their economic interest was to focus > > on DOS. > > > > There are 3 possibilities: > > 1. It did not make technical sense > > 2. It did not make economic sense > > 3. It did make sense, but it simply did not happen > > > > So, yes, I was conflating a lot of different thoughts into a single > > solution, without first thinking clearly about the question. > > Someone is bound to suggest that p-code was, or still is, detrimental to > boot times. But cores are so much faster than memory buses, and JIT > compilers so far advanced over what was available in the 1980s, that I > wonder if that is simply a myth today for any implementation that didn't > go out of its way to be slow. > > > For sure, that is undisputed. But could it have been even more > > successful? Maybe the main reason for "no BIOS attempt" was purely > > economic: for the companies having to port to each and every machine > > created customer lock-in, and for the professionals it created an > > industry of well paying porting & maintenance jobs. The customers were > > willing to pay for it. Why kill the golden goose? > > Never compete on margins when you can extract monopoly rents, leverage > asymmetric information, impose negative externalities, and defraud your > customer or the public generally. Everybody who stops learning > economics after their first micro class is a sheep waiting your shears. > > Regards, > Branden > --00000000000045db3505f13a8e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems like a good time to pull out the "wheel of reincarnati= on" paper.

http://cva.stanford.edu/cla= sses/cs99s/papers/myer-sutherland-design-of-display-processors.pdf
<= /div>
I think about it a lot when I ponder the state of graphics these days. The= wheel does seem finally to have rusted in place, although I'm not sure= I'd choose this exact angle of rotation.

-rob


On Mon, Jan 2, = 2023 at 8:27 AM G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
At 2023-01-01T21:29:17+0100, Paul = Ruizendaal wrote:
> > Mothy Roscoe gave a really interesting keynote at OSDI'21: > > https://www.youtube.com/watch?v=3D36myc8wQhLo=
>
> What an interesting keynote! At first he makes the case that OS
> research is dead (not unlike Rob=E2=80=99s similar observation 20 year= s
> before).
>
> However, he goes on to point out a specific challenge that he
> feels is in dire need of research and innovation. In short his case is=
> that a modern SoC is nothing like a VAX, but Linux still treats all > hardware like a VAX.

As do C programmers.=C2=A0 https://queue.acm.org/deta= il.cfm?id=3D3212479

> > That makes figuring out where the host OS image is and getting it=
> > loaded into memory a real pain in the booty; not to mention on > > modern systems where you=E2=80=99ve got to do memory training as = part of
> > initializing DRAM controllers and the like.
>
> That was my immediate pain point in doing the D1 SoC port.
> Unfortunately, the manufacturer only released the DRAM init code as > compiler =E2=80=98-S=E2=80=99 output and the 1,400 page datasheet does= not discuss its
> registers. Maybe this is a-typical, as I heard in the above keynote > that NXP provides 8,000 page datasheets with their SoC=E2=80=99s. Luck= ily,
> similar code for ARM chips from this manufacturer was available as C > source and I could reverse engineer the assembler file back to about > 1,800 lines of C. See
> https://gitlab.com/pnru/xv6-d1/-/blob= /master/boot0/sdram.c

I don't think it's atypical.=C2=A0 I was pretty annoyed trying to u= se the
data sheet to program a simple timer chip on the ODROID-C2; the sheet
was simply erroneous about the address of one of the registers you
needed to poke to set up a repeating timer.=C2=A0 When I spoke to people mo= re
experienced with banging on modern devices, I was mostly met with
resignation and rolled shoulders.=C2=A0 I grew up in the hobbyist era; thes= e
days it is _only_ OS nerds who program these devices, and these OS nerds don't generally handle procurement themselves.=C2=A0 Instead, purchasin= g
managers do, and those people don't have to face the pain.

Data sheets are only as good as they need to be to move the product,
which means they don't need to be good at all, since the people who pay=
for them look only at the advertised feature list and the price.

> It does all the expected things (set voltage, switch on the main
> clock, set up the PLL, calculate delays in terms of clocks, train for<= br> > the line delays, probe address multiplexing, etc.) by accessing a
> multitude of registers that appear directly connected to the
> controller fabric. Yet, at the same time it has only a single entry > point (=E2=80=9Cinit_DRAM=E2=80=9D) that takes 24 (poorly documented) = words of 32 bits
> to define the desired configuration (with options to specify =E2=80=9C= default=E2=80=9D
> or =E2=80=9Cauto=E2=80=9D).
>
> Why does the main processor need to run this code? Why is there not a<= br> > small RV32E CPU inside this controller that runs the 1,800 lines and > exposes just the 24 words as registers to the main CPU? Are the square=
> mils really that expensive? Or is this the reason that many SoC=E2=80= =99s (but
> not the D1) have a small side CPU to do this for all devices?

I can't speak to the economic arguments but it seems wasteful to me to<= br> have an auxiliary CPU that is--or _should_--be used only to bring up the board.=C2=A0 The other problem I have is more ominous.

"Ah, BMC.=C2=A0 Now every computer comes with an extra full-fledged co= mputer!
The main computer is for your use, and the other computer is for the use of the attacker." =E2=80=94 Russ Allbery

But the real problem is with the software these auxiliary processors
run.=C2=A0 My first encounter with auxiliary processors was with the TRS-80=
Model 16 line in the early 1980s, which was also available as an upgrade option from the Model II.=C2=A0 The II ran a Zilog Z80.=C2=A0 The Model 16 = upgrade
added a 68000 board which became the main CPU, and the Z80 was relegated to I/O management.=C2=A0 This turned out to work really well.=C2=A0 I gathe= r that
big IBM iron was doing this sort of thing decades earlier.=C2=A0 That at least is an honorable and useful application of the additional core,
instead of smuggling your keystrokes and network packets out to
interested intelligence agencies and harvesters for targeted
advertising.

[...]
> One of the things on my mind was that SoC boards change quite quickly:=
> the D1 was last year=E2=80=99s hit with hobbyists, next year it will b= e
> something else. Not nice if one has to redo 3,500-10,000 lines of code=
> for each board. Although I am not a fan of Forth, I can see that it is=
> useful when the controller IP blocks of a SoC (or the PCI cards of
> discrete systems) expose some form of re-targetable program needed to<= br> > boot it up. The manufacturer BSP code is just not plug & play.

Yes.=C2=A0 I too think Forth is a little weird but I appreciate its
power/memory footprint ratio.=C2=A0 I really admire OpenFirmware and was intensely disappointed when the RISC-V community didn't take the
opportunity to resurrect it.=C2=A0 Forth code seems a lot more auditable to=
me than machine language blobs.

> Maybe the correct solution for my archeology is to just use the
> simpler FPGA SoC as a target.

Maybe it's the correct solution for anyone who cares about a verified boot process, too.=C2=A0 No one who sells silicon seems to.

> For a long time I have wondered why early Xenix did not make the jump<= br> > to a product that was split between a BIOS and a BDOS part, so that > they could sell BDOS-part updates to the total installed base. The
> BDOS part could even be in some kind of p-code. Considering that they<= br> > heavily invested in their =E2=80=9Crevenue bomb=E2=80=9D C-compiler at= the time, this
> type of thinking was close to their hart

You _really have_ been writing for RISC-V lately... ;-)

> (the Amsterdam Compiler Kit was a similar idea). I am talking =E2=80= =9981-=E2=80=9983
> here, thereafter it is clear that their economic interest was to focus=
> on DOS.
>
> There are 3 possibilities:
> 1. It did not make technical sense
> 2. It did not make economic sense
> 3. It did make sense, but it simply did not happen
>
> So, yes, I was conflating a lot of different thoughts into a single > solution, without first thinking clearly about the question.

Someone is bound to suggest that p-code was, or still is, detrimental to boot times.=C2=A0 But cores are so much faster than memory buses, and JIT compilers so far advanced over what was available in the 1980s, that I
wonder if that is simply a myth today for any implementation that didn'= t
go out of its way to be slow.

> For sure, that is undisputed. But could it have been even more
> successful? Maybe the main reason for "no BIOS attempt" was = purely
> economic: for the companies having to port to each and every machine > created customer lock-in, and for the professionals it created an
> industry of well paying porting & maintenance jobs. The customers = were
> willing to pay for it. Why kill the golden goose?

Never compete on margins when you can extract monopoly rents, leverage
asymmetric information, impose negative externalities, and defraud your
customer or the public generally.=C2=A0 Everybody who stops learning
economics after their first micro class is a sheep waiting your shears.

Regards,
Branden
--00000000000045db3505f13a8e72--