2 Jan
2023
2 Jan
'23
3:26 a.m.
At 2023-01-01T21:29:17+0100, Paul Ruizendaal wrote:
As do C programmers. https://queue.acm.org/detail.cfm?id=3212479
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.
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. 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 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