[TUHS] Porting the SysIII kernel: boot, config & device drivers

[Rob Pike]

Seems like a good time to pull out the "wheel of reincarnation" paper.

http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-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 at 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=36myc8wQhLo
> >
> > What an interesting keynote! At first he makes the case that OS
> > research is dead (not unlike Rob’s 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=3212479
>
> > > 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’ve 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 ‘-S’ 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’s. Luckily,
> > 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 (“init_DRAM”) that takes 24 (poorly documented) words of 32 bits
> > to define the desired configuration (with options to specify “default”
> > or “auto”).
> >
> > 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’s (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." — 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’s 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 “revenue bomb” 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 ’81-’83
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20230102/c47f7363/attachment.htm>