- User Since
- Feb 3 2015, 4:54 AM (154 w, 22 h)
Fri, Jan 12
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.
Thu, Jan 11
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...)
Tue, Dec 26
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.
Sat, Dec 23
Thu, Dec 21
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.
Tue, Dec 19
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
Mar 13 2017
It seems that this breaks lam (and thus portsnap) on systems without capsicum. Many tier2 systems are affected by this.
root@tegra124:/usr/ports # portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Sat Jan 28 07:27:13 UTC 2017 to Mon Mar 13 16:02:31 UTC 2017.
Fetching 5 metadata patches.lam: unable to limit rights on: -: Function not implemented
Applying metadata patches... done.
Fetching 5 metadata files... lam: unable to limit rights on: -: Function not implemented
/usr/sbin/portsnap: cannot open a5dec4addaeb7dfd733a5eb227f3cdbb7f1f4ab2bd63426d5fd6e5d4e5be2277.gz: No such file or directory
metadata is corrupt.
Mar 8 2017
platform_late_init() is only transitional hack, full platform model needs FDT_PLATFORM_DEF() macro.
Ahh, I see now, Marvell subtree is not fully converted to platform model :) . But trust me, conversion its not that hard and makes your life much easier.
Also, there is global effort to make single generic kernel for all supported armv6 boards, and #ifdef SoC only technique is in direct direct contradiction with this goal.
See allwinner subtree, mainly aw_machdep.c. This platform supports numerous board with single kernel in 'right' way, without #ifdef hell.
Mar 7 2017
In D9864#204948, @zbb wrote:
In general, I don't insist on adding this change to all Cortex-A9 CPUs and I acknowledge your arguments.
Another platform-dependent method is OK for us. We need something that will be executed on both primary and secondary CPUs. It would be best if this stays in a common place for both primary and secondary CPUs (such as cpu_setup() is common for CPU0 and CPUx).
What do you think?
I'm sorry about my platform_mp_start_ap() mistake.
I understand that cpuinfo_get_actlr_modifier() looks like most direct (and most easier) way how to make this. But again, this setting must be platform dependent.
Assume that you have 2 different boards (with different bootloaders) but with exactly same CPU. One board start OS in secure world, one in non-secure. . Then, write to ACTRL is OK for first one, but may cause exception on second.
Mar 4 2017
Yep, fully agree. From my point of view, platform_late_init() (for BP) is best place for performance tweaks. At this point, printf() works and cpuinfo is initialized, so you can check proper CPU revision, print some warning about potentially dangerous action, etc...
For AP, you can use standard platform_mp_start_ap(), but many ACTRL bits are shared between CPU's. So, typically, it's sufficient to set up only BP.
Mar 2 2017
See Erratum 571620, 719331, 719332, 751473 and probably more others.
Feb 23 2017
By my opinion, kernel should call dtrace_trap_func () only in unresolvable kernel trap case, as alternative to panic.
Something like: oups, dtrace probe causes panic, recovery me.
In my example a malformed script results in a memory access to 0x02. The resulting translation fault brings the system down. This should not happen.
Yes, due to missing FAULT_TRAN_L: case in dtrace_trap().
Can you be, please, little more specific for
"abort_handler - didn't call the dtrace_trap() function early enough to handle faults caused by DTrace " ?
Feb 17 2017
Export symbols within FBSD_1.5 namespace.