Page MenuHomeFreeBSD

mhorne (Mitchell Horne)
User

Projects

User Details

User Since
Mar 22 2019, 4:46 AM (61 w, 3 d)

Recent Activity

Fri, May 22

mhorne committed rS361402: Simplify the RISC-V kernel linker invocation.
Simplify the RISC-V kernel linker invocation
Fri, May 22, 6:55 PM
mhorne requested review of D24950: Remove remnant of arm's ELF trampoline.
Fri, May 22, 1:56 AM

Thu, May 21

mhorne added a comment to D24910: Add macros simplifying the fake preload setup.

That's a holdover from the a.out days. See D21099.

Thu, May 21, 6:52 PM
mhorne added inline comments to D24910: Add macros simplifying the fake preload setup.
Thu, May 21, 5:36 PM
mhorne updated the diff for D24910: Add macros simplifying the fake preload setup.

Remove KERNENTRY entirely. Call roundup in PRELOAD_PUSH_VALUE.

Thu, May 21, 5:16 PM
mhorne added inline comments to D24910: Add macros simplifying the fake preload setup.
Thu, May 21, 4:23 PM

Tue, May 19

mhorne updated the test plan for D24909: Simplify the RISC-V kernel linker invocation.
Tue, May 19, 2:58 PM
mhorne added a comment to D24912: Handle load from loader(8).

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.

Tue, May 19, 1:54 AM
mhorne updated the diff for D24912: Handle load from loader(8).

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

Tue, May 19, 1:23 AM
mhorne requested review of D24912: Handle load from loader(8).
Tue, May 19, 1:18 AM
mhorne requested review of D24910: Add macros simplifying the fake preload setup.
Tue, May 19, 1:08 AM

Fri, May 15

mhorne committed rS361086: MFC r360551-r360554.
MFC r360551-r360554
Fri, May 15, 8:01 PM

Mon, May 11

mhorne added a comment to D24660: sysutils/opensbi: update to v0.7.

@philip did you have a chance to test this yet? I hope to commit later this week. I will MFC the required changes for booting to stable/12 before I do.

Mon, May 11, 8:26 PM

Fri, May 8

mhorne committed rS360826: Sync relocation definitions.
Sync relocation definitions
Fri, May 8, 10:22 PM

Wed, May 6

mhorne committed rS360704: MFC r360519:.
MFC r360519:
Wed, May 6, 7:59 PM
mhorne committed rS360703: MFC r360082:.
MFC r360082:
Wed, May 6, 7:50 PM

Sat, May 2

mhorne added a comment to D24673: Make efirt module dependent on MK_EFI.

@imp, your commit message in rS331099 implies you had something like this in mind already. Are there any changes that ought to be made before this one that I might not be aware of?

Sat, May 2, 10:12 PM
mhorne requested review of D24673: Make efirt module dependent on MK_EFI.
Sat, May 2, 10:10 PM
mhorne added a comment to D24660: sysutils/opensbi: update to v0.7.

At first glance, this looks good.

I'll test this out on my HiFive board this afternoon (UTC+8).

Sat, May 2, 1:44 AM
mhorne accepted D24658: Set LG_VADDR to 48 on RISC-V..
Sat, May 2, 1:14 AM
mhorne added a comment to D24660: sysutils/opensbi: update to v0.7.

@lwhsu this update will likely affect CI, as the QEMU firmware file has been moved from /usr/local/share/opensbi/platform/qemu/virt/firmware/fw_jump.elf to /usr/local/share/opensbi/lp64/qemu/virt/firmware/fw_jump.elf. It looks like v0.8 will change this again, as the qemu/virt platform may be dropped in favor of a new generic platform. You might consider providing -bios default as an argument to QEMU instead, and this will use the version of OpenSBI shipped with QEMU.

Sat, May 2, 12:36 AM
mhorne requested review of D24660: sysutils/opensbi: update to v0.7.
Sat, May 2, 12:29 AM

Fri, May 1

mhorne committed rS360554: Use the HSM SBI extension to halt CPUs.
Use the HSM SBI extension to halt CPUs
Fri, May 1, 10:00 PM
mhorne committed rS360553: Use the HSM SBI extension to start APs.
Use the HSM SBI extension to start APs
Fri, May 1, 9:58 PM
mhorne closed D24497: Use the HSM SBI extension to start APs.
Fri, May 1, 9:58 PM
mhorne committed rS360552: Add support for HSM SBI extension.
Add support for HSM SBI extension
Fri, May 1, 9:56 PM
mhorne closed D24496: Add support for HSM SBI extension.
Fri, May 1, 9:56 PM
mhorne committed rS360551: Make mpentry independent of _start.
Make mpentry independent of _start
Fri, May 1, 9:52 PM
mhorne closed D24495: Make mpentry independent of _start.
Fri, May 1, 9:52 PM
mhorne requested review of D24646: Add RISC-V interpreter example to binmiscctl(8).
Fri, May 1, 2:59 AM
mhorne committed rS360519: Add RISC-V interpreter example.
Add RISC-V interpreter example
Fri, May 1, 1:31 AM
mhorne closed D24646: Add RISC-V interpreter example to binmiscctl(8).
Fri, May 1, 1:31 AM
mhorne added a comment to D24646: Add RISC-V interpreter example to binmiscctl(8).

LGTM (don't forget to bump .Dd); have you had a chance to test cross-builds with -user-static?

Fri, May 1, 1:15 AM
mhorne updated the test plan for D24646: Add RISC-V interpreter example to binmiscctl(8).
Fri, May 1, 1:01 AM

Thu, Apr 30

mhorne added inline comments to D24497: Use the HSM SBI extension to start APs.
Thu, Apr 30, 4:04 PM
mhorne updated the diff for D24497: Use the HSM SBI extension to start APs.

Use <= not <.

Thu, Apr 30, 3:24 PM
mhorne added a reviewer for D24497: Use the HSM SBI extension to start APs: markj.
Thu, Apr 30, 1:50 AM
mhorne updated the diff for D24497: Use the HSM SBI extension to start APs.

Update smp_after_idle_runnable to use mp_maxid. This way we can still free all
bootstacks even if the CPUs that came online have a sparse layout.

Thu, Apr 30, 1:50 AM

Apr 24 2020

mhorne added a comment to D24544: Retire the GENERICSF kernel config..

The following excerpt from kern.mk should also be cleaned up as part of this commit:

.if ${MACHINE_ARCH:Mriscv*sf}
CFLAGS+=        -march=rv64imac
.else
CFLAGS+=        -march=rv64imafdc
.endif
Apr 24 2020, 8:58 PM

Apr 21 2020

mhorne updated subscribers of D24304: Add 64-bit support to Cadence CGEM Ethernet driver..

@kp, @philip, @nick would it be possible to sanity test this on a sifive board?

Apr 21 2020, 5:23 PM
mhorne added a comment to D24499: Panic if any APs fail to be released.
In D24499#538963, @br wrote:

I think we should fix rS359280 instead, because absent of a secondary CPU was not an issue before.

It must have been an issue before, since cpu_init_fdt() updates all_cpus regardless of whether the AP started successfully.

Apr 21 2020, 5:07 PM

Apr 19 2020

mhorne updated subscribers of D24499: Panic if any APs fail to be released.
In D24499#538813, @br wrote:

What is the reason for a fatal page fault when some CPUs are not fired?
Normally it should start with a single CPU in that case.359280

Apr 19 2020, 8:14 PM
mhorne added a reviewer for D24499: Panic if any APs fail to be released: riscv.
Apr 19 2020, 2:29 AM
mhorne created D24499: Panic if any APs fail to be released.
Apr 19 2020, 2:29 AM
mhorne created D24498: Use the HSM SBI extension to halt CPUs.
Apr 19 2020, 2:29 AM
mhorne created D24497: Use the HSM SBI extension to start APs.
Apr 19 2020, 2:28 AM
mhorne created D24496: Add support for HSM SBI extension.
Apr 19 2020, 2:27 AM
mhorne created D24495: Make mpentry independent of _start.
Apr 19 2020, 2:13 AM
mhorne committed rS360085: RISC-V: provide the correct value for kernstart.
RISC-V: provide the correct value for kernstart
Apr 19 2020, 12:35 AM
mhorne closed D24156: RISC-V: provide the correct value for kernstart.
Apr 19 2020, 12:35 AM
mhorne committed rS360084: RISC-V: exclude reserved memory regions.
RISC-V: exclude reserved memory regions
Apr 19 2020, 12:33 AM
mhorne closed D24155: RISC-V: exclude reserved memory regions.
Apr 19 2020, 12:33 AM
mhorne committed rS360083: RISC-V: use physmem to manage physical memory.
RISC-V: use physmem to manage physical memory
Apr 19 2020, 12:18 AM
mhorne closed D24154: RISC-V: use physmem to manage physical memory.
Apr 19 2020, 12:18 AM
mhorne committed rS360082: Convert arm's physmem interface to MI code.
Convert arm's physmem interface to MI code
Apr 19 2020, 12:12 AM
mhorne closed D24153: Convert arm's physmem interface to MI code.
Apr 19 2020, 12:12 AM

Apr 18 2020

mhorne accepted D24483: Check the magic value in longjmp() before calling sigprocmask()..
Apr 18 2020, 5:03 PM

Apr 17 2020

mhorne added a comment to D24155: RISC-V: exclude reserved memory regions.

@nick if you see any other problems with this let me know. I plan on committing tonight or tomorrow, but can always follow-up if needed.

Apr 17 2020, 10:49 PM
mhorne updated the diff for D24155: RISC-V: exclude reserved memory regions.

Move logic above physmem_init_kernel_globals().

Apr 17 2020, 10:47 PM
mhorne updated the diff for D24155: RISC-V: exclude reserved memory regions.

Handle the case where a reserved memory region other than the SBI is specified.

Apr 17 2020, 9:29 PM
mhorne updated the diff for D24154: RISC-V: use physmem to manage physical memory.

Keep physmap globals in machdep.c.

Apr 17 2020, 9:27 PM

Apr 16 2020

mhorne added a comment to D24155: RISC-V: exclude reserved memory regions.
In D24155#537632, @nick wrote:

I think we can name reserved regions, looking for a reserved-memory child node for the bootloader may be a good idea. If someone already has reserved-memory but it's for a non-bootloader purpose I think this will break.

Apr 16 2020, 4:25 PM

Apr 11 2020

mhorne updated the test plan for D24156: RISC-V: provide the correct value for kernstart.
Apr 11 2020, 6:20 PM
mhorne added a comment to D24154: RISC-V: use physmem to manage physical memory.

Ping. Any opposition to this one? I would like to commit the set of patches soon.

Apr 11 2020, 6:00 PM

Apr 7 2020

mhorne committed rS359709: MFC r359289:.
MFC r359289:
Apr 7 2020, 6:42 PM

Apr 6 2020

mhorne committed rS359673: RISC-V: copy the DTB to early KVA.
RISC-V: copy the DTB to early KVA
Apr 6 2020, 10:49 PM
mhorne closed D24152: RISC-V: copy the DTB to early KVA.
Apr 6 2020, 10:49 PM

Apr 4 2020

mhorne updated the diff for D24154: RISC-V: use physmem to manage physical memory.

Rebase

Apr 4 2020, 10:11 PM
mhorne added inline comments to D24152: RISC-V: copy the DTB to early KVA.
Apr 4 2020, 10:02 PM
mhorne updated the diff for D24152: RISC-V: copy the DTB to early KVA.

Address markj's comments

Apr 4 2020, 9:58 PM

Mar 27 2020

mhorne updated the diff for D24154: RISC-V: use physmem to manage physical memory.

Rebase.

Mar 27 2020, 11:49 PM
mhorne added a comment to D24152: RISC-V: copy the DTB to early KVA.

The mapping of the DTB at MAX_KERNEL_ADDRESS - 4MB remains valid, doesn't it?

Yes, the mapping remains. Is there any reason we would need to invalidate it? pmap_bootstrap() sets virtual_end = VM_MAX_KERNEL_ADDRESS - L2_SIZE, so the virtual address is free to be re-mapped later.

Right, that looks like a preexisting bug. It is just unlikely that a running system will consume enough KVA to hit that problem, since many kernel allocations will go through the direct map on riscv.

EDIT: actually, thinking about it more, there's nothing currently stopping this virtual address from being re-mapped if KVA were to grow large enough... and that might cause problems because ofw_fdt.c holds onto the DTB pointer.

Hmm, I don't quite follow. Isn't OFW using the new mapping "created" by fake_preload_metadata()?

Mar 27 2020, 6:58 PM
mhorne updated the diff for D24152: RISC-V: copy the DTB to early KVA.

Invalidate the original DTB mapping in pmap_bootstrap().

Mar 27 2020, 6:56 PM
mhorne added a comment to D24154: RISC-V: use physmem to manage physical memory.
In D24154#532404, @kp wrote:

I've found this to fail to boot, because it didn't reserve memory for the DTB (supplied by BBL). I'm not entirely sure if that's a result of an issue with your patch, or if there's something wrong in our local tree.

How is the DTB memory supposed to be reserved?

The following fixes the immediate problem for me:

@@ -806,9 +808,11 @@ initriscv(struct riscv_bootparams *rvbp)
 #ifdef FDT
        try_load_dtb(kmdp, rvbp->dtbp_virt);
 #endif
+       /* Reserve memory for the DTB. */
+       physmem_exclude_region(rvbp->dtbp_phys, L2_SIZE, EXFLAG_NOALLOC);
Mar 27 2020, 5:42 PM

Mar 24 2020

mhorne closed D23838: Makefile.inc1: override MACHINE for native-xtools.
Mar 24 2020, 11:26 PM
mhorne committed rS359289: Makefile.inc1: override MACHINE for native-xtools.
Makefile.inc1: override MACHINE for native-xtools
Mar 24 2020, 11:26 PM
mhorne added a comment to D24152: RISC-V: copy the DTB to early KVA.

The mapping of the DTB at MAX_KERNEL_ADDRESS - 4MB remains valid, doesn't it?

Mar 24 2020, 8:31 PM
mhorne added inline comments to D24152: RISC-V: copy the DTB to early KVA.
Mar 24 2020, 5:07 PM
mhorne updated the diff for D24152: RISC-V: copy the DTB to early KVA.

Address comments.

Mar 24 2020, 5:05 PM
mhorne added a comment to D23838: Makefile.inc1: override MACHINE for native-xtools.

Ping. I've created a snippet P376 showing the build failure. As you can see the target triple is set correctly to amd64, but RISC-V CFLAGS are being picked up from bsd.cpu.mk.

Mar 24 2020, 3:24 PM
mhorne created P376 native-xtools build failure.
Mar 24 2020, 3:19 PM

Mar 23 2020

mhorne added a comment to rS359218: Fix ordering of machine includes.

Huh. I didn't know you could "audit" a commit on phabricator. Interesting!

Mar 23 2020, 12:25 AM

Mar 22 2020

mhorne created D24156: RISC-V: provide the correct value for kernstart.
Mar 22 2020, 6:40 PM
mhorne created D24155: RISC-V: exclude reserved memory regions.
Mar 22 2020, 6:39 PM
mhorne created D24154: RISC-V: use physmem to manage physical memory.
Mar 22 2020, 6:39 PM
mhorne created D24153: Convert arm's physmem interface to MI code.
Mar 22 2020, 6:36 PM
mhorne created D24152: RISC-V: copy the DTB to early KVA.
Mar 22 2020, 6:01 PM
mhorne committed rS359218: Fix ordering of machine includes.
Fix ordering of machine includes
Mar 22 2020, 5:59 PM

Mar 5 2020

mhorne added a comment to D23877: RISCV Platform Specific Code.
In D23877#525989, @nickisobrien_gmail.com wrote:

Okay, I'm not totally opposed to this interface, but I would like to better understand the motivation behind adopting it before we do so.
Does this solve a problem for some proprietary core? As I see it, this doesn't change anything for the FU540.

The arm directory is littered with these platform files, and this seems to be out of necessity due to the variety and inconsistency of standards that exists in its hardware. arm64 seems to have avoided the need for this interface so far, and I wonder if we can do the same. The Linux RISC-V world seems to be pushing hard for OpenSBI and keeping platform abstractions at the firmware level. We don't have to follow what Linux does, but I think we ought to be thoughtful in what we choose to do here. Thoughts?

It's definitely a fair point. Recent moves to OpenSBI has offloaded a lot of the platform specific code. Undoubtedly it's worth being thoughtful here as it will drive some of our RISC-V kernel architecture moving forward.

Mar 5 2020, 5:54 PM · riscv

Mar 2 2020

mhorne added a comment to D23877: RISCV Platform Specific Code.

Okay, I'm not totally opposed to this interface, but I would like to better understand the motivation behind adopting it before we do so.
Does this solve a problem for some proprietary core? As I see it, this doesn't change anything for the FU540.

Mar 2 2020, 9:00 PM · riscv

Feb 28 2020

mhorne added a reviewer for D23877: RISCV Platform Specific Code: br.

Hi Nick, thanks for taking the time to submit this. To start, could you please update your diffs with full context? (e.g. git show -U99999)

Feb 28 2020, 7:17 PM · riscv

Feb 27 2020

mhorne committed rP527307: sysutils/opensbi: update to version 0.6.
sysutils/opensbi: update to version 0.6
Feb 27 2020, 10:15 PM
mhorne closed D23820: sysutils/opensbi: update to version 0.6.
Feb 27 2020, 10:15 PM

Feb 26 2020

mhorne added inline comments to D23820: sysutils/opensbi: update to version 0.6.
Feb 26 2020, 4:57 AM

Feb 25 2020

mhorne added a comment to D23820: sysutils/opensbi: update to version 0.6.

Perhaps you want a ${${platform}_STRIP_ARGS} that has -K tohost -K fromhost for SPIKE?

Feb 25 2020, 7:59 PM
mhorne updated the diff for D23820: sysutils/opensbi: update to version 0.6.

Address review comments.

Feb 25 2020, 7:58 PM
mhorne updated the test plan for D23838: Makefile.inc1: override MACHINE for native-xtools.
Feb 25 2020, 7:34 PM
mhorne created D23838: Makefile.inc1: override MACHINE for native-xtools.
Feb 25 2020, 7:33 PM
mhorne added a comment to D23820: sysutils/opensbi: update to version 0.6.

I've just tested the spike binary, and the following warning was emitted:

warning: tohost and fromhost symbols not in ELF; can't communicate with target
Feb 25 2020, 5:30 PM
mhorne updated the diff for D23820: sysutils/opensbi: update to version 0.6.

Depend on riscv64-none-elf-binutils as well.

Feb 25 2020, 1:27 AM