Looks good, thanks for finishing this. Will you handle the removal of the static power8 definitions as well?

In D31253#703905, @jrtc27 wrote:

For example:

panic: pmap_l2_to_l3: PA out of range, PA: 0x0
cpuid = 1
time = 1625512247
KDB: stack backtrace:
db_trace_self() at db_trace_self
db_trace_self_wrapper() at db_trace_self_wrapper+0x38
kdb_backtrace() at kdb_backtrace+0x2c
vpanic() at vpanic+0x148
panic() at panic+0x2a
pmap_remove_write() at pmap_remove_write+0x56a
vm_object_page_collect_flush() at vm_object_page_collect_flush+0xf8
vm_object_page_clean() at vm_object_page_clean+0x144
vinactivef() at vinactivef+0x90
vput_final() at vput_final+0x2ea
vput() at vput+0x32
vn_close1() at vn_close1+0x13c
vn_closefile() at vn_closefile+0x44
_fdrop() at _fdrop+0x18
closef() at closef+0x1b8
closefp_impl() at closefp_impl+0x78
closefp() at closefp+0x52
kern_close() at kern_close+0x134
sys_close() at sys_close+0xe
do_trap_user() at do_trap_user+0x208
cpu_exception_handler_user() at cpu_exception_handler_user+0x72
--- exception 8, tval = 0x6
KDB: enter: panic

In D31021#703930, @jrtc27 wrote:

In D31021#703923, @mhorne wrote:

The odd naming for tlkclk was discussed in D23406. Assuming the clk framework can accept two clocks with the same name, I think we are better off with this rename.

Our in-tree copy of the device tree should long have lost the old fixed clock node. For what it's worth, the Linux kernel also just names the PRCI's clock tlclk on both boards, but I don't know if they have the same global namespace issue. Our clk framework does just have a big global linked-list of clocks and so names need to be unique. But I'd be tempted to just say "don't use those ancient device trees for the FU540".

The odd naming for tlkclk was discussed in D23406. Assuming the clk framework can accept two clocks with the same name, I think we are better off with this rename.

Any remaining concerns with this change?

Looks straightforward to me, with a couple of questions. I have never written a gpio driver myself, so maybe @manu or @mmel can give it a quick look.

In D31208#702538, @jrtc27 wrote:

This will eventually need to be a dynamic property based on the page table format in use. Would it not be better to just make pmap_fault verify that the address is suitably sign-extended and return 0 if not?

In D31209#702537, @jrtc27 wrote:

This bug is also repeated in support.S for all the fu/su/casu functions

In D31193#702034, @asomers wrote:

@mhorne I'm not a doc committer. Are you, and can I consider this change as approved by you?

Thanks!

In D30297#700016, @ehem_freebsd_m5p.com wrote:

I would compare the triplet of get_physaddr_bits()/get_physaddr_count()/get_physaddr_max() to the triplets of PAGE_SHIFT/PAGE_SIZE/PAGE_MASK in sys/arm64/include/param.h. Since my present requirement is to have one of these three, I'm willing to simplify, but I see them coming back in the future. Simply need to type something...

Looks good. One final nitpick, but I won't block based on that alone.

Very nice to see this change already, I was hoping someone would pick this up for PPC.

In D30256#699185, @jrtc27 wrote:

Hm, never mind, I guess Spike doesn't end up with a ttyu0, only rcons?

Address jilles' comments.

FYI I am planning a larger import of perf event definitions from Linux, but there is no reason this can't go ahead. I will commit this shortly if nobody beats me to it.

Thanks for this one.

Any further comments? I plan to commit within the next day or two if not.

@imp do you care to commit this or shall I?

Thanks, this fell off my radar.

Rebase on top of D30602; set pm_has_raw_event field. Fix 'branches' typo.

Provide an MD field, pm_has_raw_event, to inform when the event code is raw.

I have not messed around with loading a new DTB from loader myself, but I have thought a bit about this problem of maintaining boot-hartid before. I guess you did something like load -t dtb /path/to/dtb?

In D30280#680286, @ehem_freebsd_m5p.com wrote:

There is actually a trade-off between two issues here. Is it valuable for rman_reserve_resource_bound() to handle the case of being given a count of 0? Is it valuable for rman_reserve_resource_bound() to handle the situation of count == 0? Both are a bit funky and a bit valuable to handle.

Having rstart=0 and rend=~0 is actually likely to hint at issues underneath. Along this line looking at sys/arm64/arm64/nexus.c, I'm pretty sure what it is doing isn't plausible. Perhaps handling count=0 has some value and this should be abandoned. The issues in sys/arm64/arm64/nexus.c are going to need to be fixed.

Thank you both for the review. I was rushing a bit with the previous revision, and it shows. I've tested the success case for installing and stripping a file beginning with '-'. I'll look into adding a test for this case to install_test.sh.

Use asprintf() to allocate _from_name.

This seems ready to go, but perhaps D29873 should become the child revision? I.e. cleanup first, addition second.

In D29310#688060, @ehem_freebsd_m5p.com wrote:

Any comments on what is currently present?

The approach of always allocating lowest first seems boring, but it is boring since it is quite effective and addresses the need perfectly. Does mean some test cases are harder to reach, but every approach is going to make some cases harder to test and other cases easier.

Handle from_name beginning with '-'.

In D30614#687694, @arichardson wrote:

Surprised I haven't seen this, pretty sure I've built with XSTRIPBIN=llvm-strip before.

To state the problem as I understand it: ofwbus fails to reserve or report its resource usage back to nexus, violating an assumption of newbus. This is of no consequence when all devices allocate resources through ofwbus, but becomes an issue when a child of nexus needs to allocate an unused resource region (this will be the case for Xen's PV bus on arm64).

In D30602#687492, @andrew wrote:

Is there a way to tell if a raw event or event code has been asked for on the syscall boundary? In current architecture the event space is 16bit so we can tell the difference, however we shouldn't assume this will never change.