- User Since
- Feb 3 2015, 4:54 AM (193 w, 3 d)
Aug 25 2018
Aug 22 2018
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.
Aug 13 2018
Aug 8 2018
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.
Aug 1 2018
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.
Jul 29 2018
Applied, booted new kernel and make buildworld passed without problem.
Thanks for your ARM effort.
Jun 16 2018
Rebased to current, renamed UBOOT_BOOT_API to LINUX_BOOT_API
Mar 9 2018
Mar 2 2018
Tested also on RPi-B (armv6) without problem.
Please, also remove rng related lines from sys/dts/arm/rpi.dts stubs.
Feb 10 2018
+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.
Jan 19 2018
- print actual mitigation variant if bootversode
- slightly restructure code to make additional vendors or CPUs addition easier
Jan 18 2018
Addressed all objections.
Jan 17 2018
Jan 16 2018
Jan 12 2018
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.
Jan 11 2018
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...)
Dec 26 2017
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.
Dec 23 2017
Dec 21 2017
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.
Dec 19 2017
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. 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).
Dec 12 2017
Dec 8 2017
thanks. I will incorporate all your comments into final commit.
Dec 5 2017
Nov 29 2017
Sorry for delay. We don't support arm for FreeBSD 10 and arm packages are built only for FreeBSD11 and higher.
Nov 25 2017
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.
Nov 20 2017
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)?
Nov 19 2017
I can confirm that R cad be built on native ARMv7 system with this.
Nov 3 2017
Seems that exp-run passed without problems. Can you, please, commit this ?
Nov 2 2017
- malloc_aligned() modified to rtld version
- added alignment fix also for Variant I
- check malloc() return values
- use custom version of assert()
Oct 30 2017
Oct 20 2017
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
Oct 18 2017
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 ).
Oct 17 2017
Sep 10 2017
Sep 9 2017
Sep 8 2017
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.
Sep 6 2017
Aug 11 2017
Aug 4 2017
Jun 28 2017
Jun 21 2017
Jun 18 2017
Jun 17 2017
Oups, my bad, sorry.
We cannot use standard way for tunable sysctl initialization here. SYSINIT machinery is executed far after cpuinfo_init() so boot CPU doesn't get right quirks.
Anyway, I submitted fix for this in r320054.
So again, sorry for troubles...
I'm fine with rest.
Jun 15 2017
I'm fine with both solutions, with preference to "arm,io-coherent". Using standardized, documented way is always better :)
I do not think this patch was accepted in mainline Linux -> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363953.html
When a PL310 cache is used in a system that provides hardware
coherency, the entire outer cache operations are useless, and can be
This is significantly incorrect/misleading/false sentence. All these outer cache operations are necessary for standard mapping operations, irrespective of coherency status.
Please, reword this part in commit.
Jun 14 2017
Too late but still...
What exactly is "cpu_class" and why we need at all? I understand why it's useful for ARMv4, but it's near useless for ARMv7 (there is too much variants)
Yep, exactly, I agree.
Jun 13 2017
Hmm, allow me a short summary:
- This patch simply cannot work. On boot core, the platform_cpu_init() is called before platform is recognized. On secondary cores, platform_cpu_init() is called before given core enters to coherency domain, so each single memory write (outside of stack) causes disaster..
- I don't see any way how we can do any platform specific operation before reinit_mmu() is called.
- The goal can be reached by different, much more consistent way.
May 28 2017
May 22 2017
The one should really save all edited files before updating review :(
- fix style(9) for copyright blocks
- pair RETURNV() with ENTERV()
May 17 2017
Oups, the 'lib/msun/src/math.h.orig' will not be included in the final commit, of course.
May 15 2017
Nothing strong, but I would probably prefer a new method for late init on secondary cores, instead of reusing of platform_late_init() - something like platform_mp_late_init.
Code sharing between BP / AP will be very rare, i think.
May 14 2017
I would prefer to move this code to platform_late_init().
The only drawback is that you must use cp15_actlr_set() + cp15_actlr_get() for boot CPU...
I think that this patch is not longer needed?
Both issues (device memory class remap, ACTRL modification) can be processed in platform_late_init().
Otherwise, I'm fine with this.
May 9 2017
Committed as r318021. Sorry for huge delay...
Apr 16 2017
Thanks for clarification, I see it now.
Apr 11 2017
Apr 2 2017
Can you be, please, little more verbose? I'm unable to detect where exactly the problem is.
Yep, I agree. Thanks for clarification.
Apr 1 2017
Armada38x have Marvell specific (or modified) PL310 ? If not then all errata fixes (but two at line 274 and 295) are checked online. Why do you want to disable them? Do you have measured impact caused by these tests?
Please tell me, do you really think that hellish "#ifdef SOC_xxx" style used in Marvell subdirectory is the right one?
For me, using "#ifdef SOC_xxx" is unacceptable in common code, and is deprecated in vendor subdirs.
Mar 29 2017
Alternatively, we can use global variable for unknown xref value , initialized at early system startup.
- in current code takes 0 (or NULL) xref as unknown xref not as error indicator.
- we cannot expect that all "information sources" *FDT/ACPI/HINTS" can share same value for unknown xref natively
- natural value for unknown xref is 0 for FDT , NULL for HINTS
- if you want change value of unknown xref correctly, then you must also remap FDT no such property to INTRNG unknown xref for all FDT users
- the "#define XREF_INVALID (-1)" is nonsense, it's hidden "#define XREF_INVALID ACPI_INVALID_HANDLE" as these values are coupled