Page MenuHomeFreeBSD

Handle load from loader(8)
Needs ReviewPublic

Authored by mhorne on Tue, May 19, 1:18 AM.

Details

Reviewers
br
markj
jrtc27
Group Reviewers
riscv
Summary

In locore, we must detect and handle different arguments passed by
loader(8) compared to what we have when booting directly via SBI
firmware. Currently we receive the hart ID in a0 and a pointer to the
device tree blob in a1. loader(8) provides only a pointer to its
metadata.

The only tricky part to this is that the hart ID of the boot hart is
expected to have been stored in the device tree by a previous booting
stage. This is performed by u-boot v2020.07 and onwards, but without
this we must fail to boot as there is no way for a hart to obtain its
own ID while executing in supervisor mode.

Fix-up initriscv() to parse the loader's metadata, continuing to use
fake_preload_metadata() in the direct boot case.

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 31173
Build 28836: arc lint + arc unit

Event Timeline

mhorne requested review of this revision.Tue, May 19, 1:18 AM
mhorne created this revision.
mhorne updated this revision to Diff 71977.Tue, May 19, 1:23 AM

Remove a duplicated section of code from a mis-merge.

There is no guarantee that mhartid does not collide with the kernel's VA space. Unlikely, yes (especially since the spec encourages reducing the magnitude of the largest mhartid), but completely permitted. The only restriction on mhartid is this:

Hart IDs might not necessarily be numbered contiguously in a multiprocessor system, but at least one hart must have a hart ID of zero.

Why can we not make loader conform to the standard RISC-V boot interface, putting mhartid in a0 and the dtb address in a1? It can shove the address of modulep somewhere in the mangled FDT. I really don't like the idea of guessing whether an integer is an address or not. Alternatively, we could provide a different entry point for loader, if it really needs the current interface.

mhorne added a comment.EditedTue, May 19, 1:54 AM

There is no guarantee that mhartid does not collide with the kernel's VA space. Unlikely, yes (especially since the spec encourages reducing the magnitude of the largest mhartid), but completely permitted. The only restriction on mhartid is this:

Hart IDs might not necessarily be numbered contiguously in a multiprocessor system, but at least one hart must have a hart ID of zero.

Why can we not make loader conform to the standard RISC-V boot interface, putting mhartid in a0 and the dtb address in a1? It can shove the address of modulep somewhere in the mangled FDT. I really don't like the idea of guessing whether an integer is an address or not. Alternatively, we could provide a different entry point for loader, if it really needs the current interface.

Providing modulep as the first and only argument seems to be standardized across the various loader(8) implementations, although there may be an example that differs. However, u-boot does not provide the boot hart ID as an argument to EFI payloads (nor, as I discovered, simple payloads invoked with the "go" command). The solution of stuffing the ID in the device tree and reading it later is what Linux plans on using for its EFI implementation.

Admittedly I don't love the check against the address either. I can see about providing an alternate entry point, but a hart id > 0xffffffc000000000 is an edge-case I'm not all that worried about.

https://lists.denx.de/pipermail/u-boot/2020-February/401563.html suggests Linux is going the way of an alternate entry point, FWIW.

nick added a subscriber: nick.Wed, May 20, 6:57 AM