Yep, thanks.

That's simply perfect, many thanks.
I tested this on arm64, all work like charm. (But I'm able to do only limited test, my iflib based driver is still far far away from working state)

Imho, aggregated reading of ID registers is not a best solution.
Personally, I think that we should implement aggregated view by using HWCAPS (As we must do this in any case, upcoming COMPAT32 simply expects this).
But we should return actual/real values of ID registers. This allow us to write program which iterates over clusters and selects best cores for given workload.
I mainly talking about SHA or SVE extensions here.

bingo! I'm on r341345. And yes, r341347 fixed it.
Thanks and sorry for noise.

Ahh, right, I overlooked this, sorry. So I taking back WITHOUT_CAPSICUM case.

How this can works on kernels build without 'options CAPABILITIES'? Note that CAPABILITIES option is
not included in kernel option for small embedded boards (arm, mips...)?
We should change CAPSICUM to mandatory or implement fallback here (as we already do in rest of tree)

Only kernel was changed during bisecting, nothing else. And all kernels was cross-compiled by
same toolchain. Kernel before r339819 works, r339819 hangs, and fresh current with r339819
reverted also works. Also, during bisecting, any kernel after r339819 hangs.
So I thing that r339819 is culprit.

Unfortunately, this patch destabilized arm kernel.
The bad thing is that my Tegra does not panic, just hangs hard and I can’t even enter the JTAG debugger [1].
Moreover, this issue is very rare, I can do finish full buildkernel in most cases. The only known testcase is full
build of qt5-webengine (~16k of C++ files, +10 hours of compilation time).

Manu,
can you, please, subclass phy to USB specialized variant (say phyusb or usbphy)? You can use clk (clkdiv, clkmux ...) as template. We should implement lots of USB OTG related function here. VBUS voltage and over-current detection, ID pin status change interrupt, OTG state machine and I thing that should use proper layering from beginning.
If you too busy for this, I can implement (empty) subclass in next 2-3 days.

Firstly, I want to say that this patch is OK. It only slightly changed memory layout for TLS segment (because it uses malloc_aligned()) which exposed unrelated bug in ARM TLS relocation.

In D16555#353199, @alc wrote:

Which linker is being used?

Can you please email me the output of "procstat -av"?

Output mailed directly.
And about linker - it's hard to say :)

Tested on Jetson TK1 (cortex-A15) without single problem.
From preliminary collected statistic it looks like pmap_enter(..., psind == 1) is used ~60 times per buildworld.
Unfortunately, the same statistic also told me that is pmap_enter_object() doesn't not create single 1MB mappings, even for shared libraries.
I'm pretty sure that this worked before - but this regression is not related to this patch.

The commit message is a bit misleading. This patch ensures DMA coherency only for control structures but audio data buffers are not covered by required bus_dmamap_sync() operations. (We simply don't have right sync operation for syncing in progress DMA buffers - something like make buffer range snapshot before CPU read and make buffer range snapshot after CPU write).
Can you, please, elaborate this fact in commit message.

Applied, booted new kernel and make buildworld passed without problem.
LGTM.
Thanks for your ARM effort.

Rebased to current, renamed UBOOT_BOOT_API to LINUX_BOOT_API

Tested also on RPi-B (armv6) without problem.
Please, also remove rng related lines from sys/dts/arm/rpi[2].dts stubs.

+100 for overlays.
But I'm not sure if it's right time to publish base .dtb files in this way. We cannot use it for now (because interrupts for uart and spi are routed throw "bcm2835-aux") and it's unclear if binding headers (dts/include/dt-bindings/*) are same (or compatible) as linux mainstream ones.

• print actual mitigation variant if bootversode
• slightly restructure code to make additional vendors or CPUs addition easier

Addressed all objections.

In D13861#290576, @andrew wrote:

You didn't describe any reason it wouldn't work. Rather than the kernel as the first argument to booti, it would be the second, after either passing it through mkimage, or loading it as a raw file with a size.

mkimage, imho, is not supported(or not preferred - it have bundled load address inside) on arm64, but this is not important yet.

I agree but, unfortunately, yes. The context_id is used for selecting right stack. See line 270 in new file.

Boot CPU have always cpuid 0 so yes, it boots (i hope). I have disordered cpus nodes in my DTS and all looks OK.

Yep, I known. But my actual situation with Jetson TX1 board is more complicated.

• the TX1 firmware can only load U-Boot for eMMC.
• shipped U-Boot doesn't support EFI
• on OS start, U-Boot modifies DTB (it excludes memory used by secure monitor and PSCI,, it modifies the pinmux table so that it matches the current setting), it stored trained settings for DDR4 controller for various memory frequencies...)

imho, we should put platform specialized drivers to dev subtree only if given driver can be reused on multiple platforms. I personally vote for not moving it.

Perfect, thanks.

Everything else looks OK for me.

Nice, this looks OK for me
But,it seems that there are some related problems:

• the PCB for proc0/thread0 is allocated on top of stack, from dirty memory, but not all fields are not initialized - this is probably a root cause why this bug is not visible on all boards.
• we leaks initial low memory mappings in kernel_pmap. This can results to double mappings with different attributes which is undefined behavior. Imho, we should clear all mappings in low memory region.

yes, but the fix looks incorrect for me.
I think that we can have same problem with secondary cores(idle threads). Imho, cpu_startup() is more appropriate place for this and we should derive TTBR0 value from kernel_pmap[1]. See arm version of cpu_startup() and call to pmap_set_pcb_pagedir(kernel_pmap, pcb); .

No objection from arm or intrng side.

I can confirm same issue on Cortex-A72. Loading zero to TTBR0_EL1 causes immediate exception (in sched_switch+0x3a0).

Thanks !!!

Kib,
thanks. I will incorporate all your comments into final commit.

Sorry for delay. We don't support arm for FreeBSD 10 and arm packages are built only for FreeBSD11 and higher.
See http://pkg.freebsd.org/

Generally speaking, I think that implementing more and more knowledge about TLS ABI into kernel is direct way to hell and it simply leads to hard to solve compatibility issues.
The ideal kernel should take TP pointer as opaque value, without any attempt to interpret it.

with full respect, I don’t think that this is right way. Moreover, I think that you papering over real problem there.
With this patch, what’s happen if someone requests any higher alignment (that actual 16) for TLS data? Or, can patched kernel run the old init (pre r324938)?

I can confirm that R cad be built on native ARMv7 system with this.

Seems that exp-run passed without problems. Can you, please, commit this ?

• malloc_aligned() modified to rtld version
• added alignment fix also for Variant I
• check malloc() return values
• use custom version of assert()

In D12743#264414, @kib wrote:

Does it make sense to include machine/elf.h from auxv.h ? Why not make it a user duty ?

Imho yes, AT_ values are defined in machine/elf.h so user should include it in (almost) all cases.

Would be nice to provide some kind of man page.

I will ask Ian for man page, this kind of job is significantly out of my skill (even in my native language). My bad I known.

Split out libc changes

Drop getauxval(), make _elf_aux_info() public.

My exp-run for selected ports just ended and It found unexpected problem.
Some ports detect getauxval() presence and if is present then expect that all (linux specific) AT_ flags are defined and implemented (e.g. security/p11-kit ).

Can be this MFCed to stable? In other words, do we support in place upgrade from 10 (soft FP ABI) to 11 (hard FP ABI)?
From my point of view, this is OK for FBSD 12.