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@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 >