Page MenuHomeFreeBSD

mmel (Michal Meloun)
User

Projects

User Details

User Since
Feb 3 2015, 4:54 AM (346 w, 1 d)

Recent Activity

Jul 28 2021

mmel committed R10:b07a6bd15a58: booti: Enable loading the kernel image to any address aligned to 2 MB (authored by mmel).
booti: Enable loading the kernel image to any address aligned to 2 MB
Jul 28 2021, 11:44 AM

Jul 23 2021

mmel accepted D31175: Support HWCAP/HWCAP2 for 32-bit ARM binaries..
Jul 23 2021, 8:27 PM

Jul 20 2021

mmel accepted D28803: arm/mv: Don't rely on firmware MSI mapping in ICU.

This looks perfect to me, many thanks.

Jul 20 2021, 7:29 PM

Jul 15 2021

mmel added inline comments to D31191: build: Rewrite arm_kernel_boothdr in Lua and add RISC-V support..
Jul 15 2021, 4:20 PM
mmel accepted D30474: arm64: Add per SoC family kernel config.
Jul 15 2021, 3:08 PM
mmel requested changes to D31191: build: Rewrite arm_kernel_boothdr in Lua and add RISC-V support..

In final commit, the original arm_kernel_boothdr.awk should be deleted. Otherwise look good to me

Jul 15 2021, 2:48 PM
mmel added a comment to D31175: Support HWCAP/HWCAP2 for 32-bit ARM binaries..

Otherwise looks good for me.,

Jul 15 2021, 8:06 AM

Jul 10 2021

mmel accepted D31030: pci_dw: Detect number of outbound regions automatically.

Tested on MACCHIATObin and HoneyComb LX2.

Jul 10 2021, 11:46 AM
mmel accepted D31029: pci_dw: Support modern "unroll" iATU mode.

Please, ignore my previous comment - I overlooked register name :(

Jul 10 2021, 11:46 AM
mmel accepted D31028: pci_dw: Support multiple memory windows.

Tested on MACCHIATObin and HoneyComb LX2 .

Jul 10 2021, 11:43 AM

Jul 8 2021

mmel accepted D31112: fan53555: attach to build and switch from syr827.
Jul 8 2021, 5:53 PM
mmel added a comment to D31103: syr827: add support for matching SYR828 as well (used by GPUs).

imho, only fan53555. And thanks for help.

Jul 8 2021, 1:13 PM
mmel added a comment to D31103: syr827: add support for matching SYR828 as well (used by GPUs).

If you can, do it yourself. My build environment is currently broken. I'm recovering from ZFS metadata corruption, plus ipfw (libalias) wants to divide by zero from time to time... :( Thanks.

Jul 8 2021, 12:44 PM
mmel committed R10:e88c3b1b02a6: intrng: remove now redundant shadow variable. (authored by mmel).
intrng: remove now redundant shadow variable.
Jul 8 2021, 6:59 AM
mmel committed R10:a49f208d94b8: intrng: Releasing interrupt source should clear interrupt table full state. (authored by mmel).
intrng: Releasing interrupt source should clear interrupt table full state.
Jul 8 2021, 6:45 AM
mmel added a comment to D31103: syr827: add support for matching SYR828 as well (used by GPUs).

We should switch to pmic/fan53555 driver which already supports it (along with other variants). I seem to have forgotten to do that. Can you test this, please?

Jul 8 2021, 6:06 AM

Jul 6 2021

mmel added a comment to D31030: pci_dw: Detect number of outbound regions automatically.

I need day or two to test this on my boards, but it looks OK for me.

Jul 6 2021, 6:52 AM
mmel added a comment to D31029: pci_dw: Support modern "unroll" iATU mode.

On correctly implemented systems, reading from an unimplemented device register will cause an exception (external asynchronous interrupt on arm64), on real systems it will return an arbitrary value.
Therefore, pci_dw_detect_atu_unroll() should only be called for modern core versions (which have the DW_IATU_VIEWPORT register implemented) - so we should check the core version first.
Otherwise looks good to me.

Jul 6 2021, 6:24 AM
mmel added a comment to D31069: rtld-elf/aarch64: Avoid checks for UND symbols when processing TPREL64.

For clarification, I meant this:

Jul 6 2021, 5:32 AM
mmel added a comment to D31069: rtld-elf/aarch64: Avoid checks for UND symbols when processing TPREL64.

However, the ELF definition also requires that the address of the undefined weak thread local symbol be translated to NULL. Additionally, I have seen code that relied on this. Unfortunately, because of aarch64's "unique" way of accessing TLS variables, I haven't found a way to implement this.
Wouldn't it be better to narrow down the cases where a message is printed, rather than allowing invalid and unreported behavior?

Jul 6 2021, 5:15 AM

Jun 24 2021

mmel committed R10:3eae4e106ac7: Fix error value returned by ofw_bus_gen_get_node(). (authored by mmel).
Fix error value returned by ofw_bus_gen_get_node().
Jun 24 2021, 10:06 AM

Jun 23 2021

mmel added a comment to D30761: ofw_bus_subr.c: Don't treat "0" as a valid OFW node.

nathan confirmed that ofw_bus_gen_get_node() should return -1 for non-ofw based device. i will commit fix asap (tomorrow).

Jun 23 2021, 3:34 PM
mmel added a comment to D30761: ofw_bus_subr.c: Don't treat "0" as a valid OFW node.

I'm working on this - but situation about return value becomes more clear now. Please see comment in ofw_if.m https://cgit.freebsd.org/src/tree/sys/dev/ofw/ofw_bus_if.m#n148 and andrew just pointed me to this commit https://cgit.freebsd.org/src/commit/?h=0d8d9edaaaca1

Jun 23 2021, 1:32 PM

Jun 19 2021

mmel accepted D30762: regulator: Add manpage this framework.

thx

Jun 19 2021, 8:38 AM
mmel accepted D30762: regulator: Add manpage this framework.

otherwise LGTM

Jun 19 2021, 8:22 AM

Jun 17 2021

mmel added a comment to D30761: ofw_bus_subr.c: Don't treat "0" as a valid OFW node.
In D30761#692573, @mmel wrote:

First, please don't take this as hating - I just think we've opened a Pandora's box full of mistakes... I've gotten caught up in the 0/-1 ambiguity for invalid phandle more than once, so I think it would be good to get that sorted out.

No worries, I agree that we should use only a single value to indicate a "NULL"/incorrent phandle.
Since it's a uint32_t I'd personally go with "0".

I understand but 0 is (probably only theoretically) valid pnode.

In D30761#692182, @mmel wrote:

Imho, this is just papering over real problem, it is obvious that ofw_bus_lookup_imap() should not be called for a device/bus that is not based on ofw.

ofw_bus_lookup_imap is called regardless of the ofw_pci patch.
pci_dw is a class 1 driver, which inherits devmethods from ofw_pcib. The latter implements pcib_route_interrupt using ofw_pcib_route_interrupt.
In other words ofw_bus_lookup_imap is called because the RC is ofw based.

Thats true, but something else is wrong in pcib_route_interrupt call-down hiearchy. This need slightly more time and deeper investigation...

I'm still trying to fully understand the real problem, but in the meantime I have a few questions:

  • Why ofw_bus_gen_get_node() returns a different value for the errored case than ofw_bus_default_get_node() ?

Frankly I have no idea. I haven't written any of those. I guess we wanted to differentiate between a case where there is no ofw support on the bus(-1) vs. where no node was found for a given device. (0)
Since phandle_t is an uint32_t type, assigning -1 to it is a bad idea imho.

After looking deeper into the dev/ofw source code, I noticed that the code only uses compare to -1 for error detection. So, I think ofw_bus_gen_get_node() is bad and should return -1 in case of error.

Well as mentioned above we should definitely return just one error value.
The problem is that changing the return value of ofw_bus_gen_get_node() could potentially break something else that relies on it returning 0.

That's true, but we have time to next release to fix all protentional problems.

Jun 17 2021, 6:38 PM
mmel added a comment to D30761: ofw_bus_subr.c: Don't treat "0" as a valid OFW node.

First, please don't take this as hating - I just think we've opened a Pandora's box full of mistakes... I've gotten caught up in the 0/-1 ambiguity for invalid phandle more than once, so I think it would be good to get that sorted out.

In D30761#692182, @mmel wrote:

Imho, this is just papering over real problem, it is obvious that ofw_bus_lookup_imap() should not be called for a device/bus that is not based on ofw.

ofw_bus_lookup_imap is called regardless of the ofw_pci patch.
pci_dw is a class 1 driver, which inherits devmethods from ofw_pcib. The latter implements pcib_route_interrupt using ofw_pcib_route_interrupt.
In other words ofw_bus_lookup_imap is called because the RC is ofw based.

Thats true, but something else is wrong in pcib_route_interrupt call-down hiearchy. This need slightly more time and deeper investigation...

Jun 17 2021, 2:25 PM

Jun 16 2021

mmel added a comment to D30761: ofw_bus_subr.c: Don't treat "0" as a valid OFW node.

Imho, this is just papering over real problem, it is obvious that ofw_bus_lookup_imap() should not be called for a device/bus that is not based on ofw.
I'm still trying to fully understand the real problem, but in the meantime I have a few questions:

  • Why ofw_bus_gen_get_node() returns a different value for the errored case than ofw_bus_default_get_node() ?
  • For all other buses (i2c, spi...) we have ofw and "native" variants -> why is PCI is special?
  • Why do we want to fake an enumerated pci bus (i.e. not ofw-based) as ofw-based?
  • Why do you think passing get_devinfo() to the parent is the correct default method, and why can it be used with all existing PCIE controllers?
  • How can ofw_pci work in case of more complex pcie topology (for example if the system has PCIe switches)?
Jun 16 2021, 1:38 PM

Jun 14 2021

mmel added a comment to D30181: Add ofw interface support to PCI.

yes, this commit is root cause .
Please see attached log:

Jun 14 2021, 1:09 PM
mmel added a comment to D30293: extres: regulator: Fix regulator_status for already enable regulators.

IMHO, this is wrong change. regulator_status() must report physical state of regulator - if given deice is powered or not. the mmc power sequencer should use similar technique as backlight. But seems like this kind of usage is common - so we can expand regulator framework with uncounted function -> something like regulator_on()/regulator_off()

Jun 14 2021, 12:22 PM
mmel added a comment to D30181: Add ofw interface support to PCI.

Unfortunately this broke (probably) all existing FDT enabled boards with enumerated (not FDT loaded) PCI(e) interfaces (in my case both mcbin and tegra). This driver probe() matches all PCI buses, and many things (driver, ofw code) depend on the fact that calling ofw_bus_get_node(dev) on a non-FDT installed device returns zero.

Jun 14 2021, 12:13 PM
mmel added a comment to D30387: Make the code consistent with the comments.

Sorry for long delay. Can you, please, also test "(IDMAC_MAX_SIZE * (IDMAC_DESC_SEGS - 1)) / MMC_SECTOR_SIZE"? Minus one should be sufficient and it passed all my tests.

Jun 14 2021, 11:42 AM

Mar 19 2021

mmel added inline comments to D29310: kern/intr: switch to allocating handles forward.
Mar 19 2021, 9:58 AM

Mar 18 2021

mmel requested changes to D29310: kern/intr: switch to allocating handles forward.
Mar 18 2021, 12:29 PM

Mar 7 2021

mmel committed R10:01c6d7918985: mvebu_gpio: Fix settings of gpio pin direction. (authored by mmel).
mvebu_gpio: Fix settings of gpio pin direction.
Mar 7 2021, 11:32 AM

Mar 4 2021

mmel committed R10:a5dce53b75d8: mvebu_gpio: Multiple fixes. (authored by mmel).
mvebu_gpio: Multiple fixes.
Mar 4 2021, 4:55 PM
mmel closed D29044: mvebu_gpio: fix gpio pin configuration update.
Mar 4 2021, 4:55 PM
mmel committed R10:f97f57b51855: simple_mfd: switch to controllable locking for syscon provider. (authored by mmel).
simple_mfd: switch to controllable locking for syscon provider.
Mar 4 2021, 3:18 PM

Mar 3 2021

mmel added a comment to D28911: mvebu_gpio: do not force data in value invertion during attach.

I don't think this change is necessary (it mitigates another bug). So I prefer to unconditionally initialize both registers in attach.

Mar 3 2021, 7:53 PM
mmel added a comment to D29044: mvebu_gpio: fix gpio pin configuration update.

write is expected (moreover these are WO ->thus not suitable for SYSCON_MODIFY operation).

Mar 3 2021, 7:40 PM
mmel added a comment to D29013: mvebu_gpio: fix interrupt cause register configuration.

I have initial part of this fixup. It should allow board to boot, at minimum. Unfortunately , the interrupt handling have still locking problem -> the solution needs change in syscon provided by simple_mfd driver -> so i need more time for this (one or two days).
But it would be nice if you can test this in your environment. It should fix hang-up issue in pcie driver.
What an ignominy...

Mar 3 2021, 6:02 PM

Mar 2 2021

mmel added a comment to D29013: mvebu_gpio: fix interrupt cause register configuration.

Noooo, Im stupid :( The root of the problem is trivial -> gpio_write() doesn't modify only the required bit, but the whole 32-bit register. HW init should use new gpio_modify() (implemented with SYSCON_MODIFY_4() not SYSCON_WRITE_4()). Big big sorry for troubles. I'll fix it tomorrow.

Mar 2 2021, 7:55 PM
mmel accepted D29013: mvebu_gpio: fix interrupt cause register configuration.

Oops. Thanks for fixing my bugs ...

Mar 2 2021, 7:24 PM

Mar 1 2021

mmel added a comment to D28803: arm/mv: Don't rely on firmware MSI mapping in ICU.

Thanks, perfect. Please let me know if you need help. I think that there will be more and more similar interrupt controllers/systems, so it's important to create a clean and flexible interface.

Mar 1 2021, 5:23 PM
mmel requested changes to D28803: arm/mv: Don't rely on firmware MSI mapping in ICU.

I'm sorry but I don't like this approach.
The PIC_MAP_INT function is designed to map external data of exact source to given irqsrc. It should not be misused to transfer any additional, platform specific data back to requester. Moreover if these external data (pure synthetic, without any relation to FDT) are passed as INTR_MAP_DATA_FDT to mapping layer.
Imho, we should convert gicp to standard MSI based interrupt controller. The communication between ICU and GICP should be splitted to normal MSI request and standard method for getting MSI mapping should be used (msi_map_msi()).
It's a little hard for me to express all the nuances so I can prepare skeleton for this solution, if you want.

Mar 1 2021, 4:38 PM
mmel accepted D28850: arm64: Fix spi_ranges_cnt in mv_ap806_gicp.

With above objection.

Mar 1 2021, 1:38 PM
mmel added a comment to D28911: mvebu_gpio: do not force data in value invertion during attach.

Can you please try the test again with https://cgit.FreeBSD.org/src/commit/?id=ce5a4083de2d79bc44d209c9e355a09ede47346c ? I hope that it fixed also this problem. Thanks.

Mar 1 2021, 1:24 PM
mmel committed R10:ce5a4083de2d: pci_dw_mv: Don't enable unhandled interrupts. (authored by mmel).
pci_dw_mv: Don't enable unhandled interrupts.
Mar 1 2021, 1:04 PM
mmel accepted D28938: AArch64: Don't set flush-subnormals-to-zero flag on startup.

My original idea was to do as much as possible for armv7. Primarily because it has been working on this platform for a long time. My bad is that I didn't remember that flush-to-zero mode was chosen because the little version of armv7 VFP may need software emulation for rounding to denormal values, so we chose the IEEE 754 incompatible mode.

Mar 1 2021, 12:13 PM

Feb 18 2021

mmel accepted D28775: cgem: improve usage of busdma(9) KPI.

Thanks.

Feb 18 2021, 5:26 PM

Feb 16 2021

mmel accepted D28579: arm64: Include NUMA locality info in the CPU topology.

Ahh, right, I forgot that Neoverse has (from this point of view) cache levels shifted – see slide 5 of https://www.slideshare.net/linaroorg/getting-the-most-out-of-dynamiq-enabling-support-of-dynamiq-sfo17104
So for purpose of OS optimization we can take real L1 + L2 caches as L1 in pre-neoverse meaning, real l3 in DynamIQ Shared Unit (DSU) block as L2 in pre-neoverse, and CMN as L3.
I think we can still handle all the cases using a two-level hierarchy, where NUMA domains as CG_SHARE_L3 groups and clusters as CG_SHARE_L2 groups will be exported. It should work on a server system, on a big.LITTLE (RK3399) and also on a medium SoC (LX2160A, which have 8 dual-core clusters). Do you think so?
I'm not sure if you want to implement this "extension", and I don't want to block you. The code in this review looks fine to me and doesn't block anything, so push it as needed.

Feb 16 2021, 1:47 PM

Feb 15 2021

mmel added a comment to D28579: arm64: Include NUMA locality info in the CPU topology.

I've spent some time digging up the ARM documentation, but unfortunately we don't seem to be able to determine the exact cache topology. But I think we can estimate it with a reasonable degree of accuracy. For rest, I assume that bit [24] bits is set (otherwise the affinity fields are shifted).

Feb 15 2021, 3:41 PM

Feb 13 2021

mmel added a comment to D28579: arm64: Include NUMA locality info in the CPU topology.

I agree with Andrew. We should use mpidr to build a cores topology. Nowadays it's easy, mpidr is stored in pcpu for all enumerated cores.
But there is another problem - cpuid should be taken as arbitrarily chosen value without any connection to cores topology - nobody can guarantee that cores are numbered sequentially within NUMA domain. Also assumption that NUMA domains are always symmetric (have same number of cores) looks too optimistic. Ampere, as well as LX2160, uses multicluster of dual cores with per cluster l2 cache - I think that L2 cache locality should also be included in initial implementation.
By that I mean that I offer help with implementation and testing on FDT based systems (unfortunately, ACPI is out of my scope and also setup).

Feb 13 2021, 1:04 PM
mmel committed R10:15e64578cb1e: dwmmc: Multiple busdma fixes. (authored by mmel).
dwmmc: Multiple busdma fixes.
Feb 13 2021, 12:30 PM
mmel committed R10:72d3aeb1b229: arm32: Align arguments of sync_icache() syscall to cacheline size. (authored by mmel).
arm32: Align arguments of sync_icache() syscall to cacheline size.
Feb 13 2021, 12:29 PM
mmel committed R10:f63b87ec3ecf: arm64: Initialize VFP control register. (authored by mmel).
arm64: Initialize VFP control register.
Feb 13 2021, 12:29 PM

Feb 11 2021

mmel committed R10:6930f97474e4: arm32: Align arguments of sync_icache() syscall to cacheline size. (authored by mmel).
arm32: Align arguments of sync_icache() syscall to cacheline size.
Feb 11 2021, 3:09 PM
mmel committed R10:e8dfdf40bed9: dwmmc: Multiple busdma fixes. (authored by mmel).
dwmmc: Multiple busdma fixes.
Feb 11 2021, 3:09 PM
mmel committed R10:214ef320018d: arm64: Initialize VFP control register. (authored by mmel).
arm64: Initialize VFP control register.
Feb 11 2021, 3:07 PM

Feb 9 2021

mmel committed R10:ec090f4a6765: arm32: Align arguments of sync_icache() syscall to cacheline size. (authored by mmel).
arm32: Align arguments of sync_icache() syscall to cacheline size.
Feb 9 2021, 12:13 PM

Feb 3 2021

mmel committed R10:8727c174b0fe: dwmmc: Multiple busdma fixes. (authored by mmel).
dwmmc: Multiple busdma fixes.
Feb 3 2021, 8:33 PM
mmel committed R10:65618fdda0f2: arm64: Initialize VFP control register. (authored by mmel).
arm64: Initialize VFP control register.
Feb 3 2021, 3:28 PM

Jan 27 2021

mmel accepted D28339: Remove redundantcy from the arm GIC softc.

LGTM

Jan 27 2021, 10:43 AM

Jan 21 2021

mmel added a comment to D28261: Return errors in bus_dmamap_load.

Kib, this error handling doesn't make sense to me, so I had to miss something important. Can you, please, explain me the context/reason for this strange kind of errors hiding? Moreover EBIG is also allowed in man page.

Jan 21 2021, 8:22 AM
mmel added a reviewer for D28261: Return errors in bus_dmamap_load: kib.
Jan 21 2021, 8:15 AM

Jan 19 2021

mmel committed R10:f635cef2a420: arm64 busdma: Fix loading of small bounced buffers. (authored by mmel).
arm64 busdma: Fix loading of small bounced buffers.
Jan 19 2021, 12:10 PM
mmel added a comment to D27529: Allow access to all accessible physical memory through /dev/mem.

Problem is that you cannot expect that (and moreover you cannot determine if) kernel can access memory describes by FDT reservation.
FDT reservation node is used for various purposes. It may be used as an advisory (i.e. for dma buffers location), as a shared memory (i.e. for framebuffer) or as hard exclusion area (i.e. for memory used in secure world) – thus inaccessible from kernel. Moreover, in last case, the implementation is allowed to generate (in rare cases) imprecise exception as result of attempt to access this protected (by trustzone hardware) memory
The FDT reservations are typically added dynamically by u-Boot or ATF -> see fdt_add_reserved_memory(). There is some chance that you can use “no-map” attribute to determine if the reservation may be accessible by kernel. For other cases you must be sure that memory is not mapped by kernel with different attributes than in u-boot or firmware -> this is architecturally undefined behavior which leads sooner or later to loss of coherency.
By all this, you cannot blindly take reserved memory as accessible by kernel and exportable by /dev/mem to userspace.
I can only recommend you try the opposite approach – explicitly map ACPI tables to kernel. I assume, that you can determine memory range where are these tables are and also than you can determine memory attributes if these are mapped by other party (ACPI).

Jan 19 2021, 9:40 AM

Jan 15 2021

mmel accepted D28156: Add missing no-ctfconvert to C generation rules.

LGTM. thanks.
It is a bit questionable whether ctfconvert should generate an error in this case (I don't think so), but calling it is clearly unnecessary in this case.

Jan 15 2021, 9:09 AM

Jan 14 2021

mmel added a comment to D27529: Allow access to all accessible physical memory through /dev/mem.

I afraid that this approach have problem on FDT based systems. FDT typically uses reserved memory regions also for secure portion of base memory (memory used by secure monitor or PSCI). And reserved memory is handled by using EXFLAG_NOALLOC -> https://cgit.freebsd.org/src/tree/sys/arm64/arm64/machdep.c#n1193
And of course this kind of memory cannot be accessed by /dev/mem.

Jan 14 2021, 9:21 AM

Jan 9 2021

mmel added a reviewer for D27218: arm: tune vmparam.h towards a little more modern: kib.

Unfortunately, side effect of this is large reduction of VA space available for mmap -> available range for (unfixed) mmap is only in the interval <start of data segment + MAXDSIZ, end of user VA space>.

Jan 9 2021, 8:02 PM

Jan 2 2021

mmel accepted D27897: arm: fix atomic_testand{set,clear}_64 for ops on high bits.

Ohh right, my next mistake. Seems I have not lucky day today :(
Thanks for fixing my stupid bugs.

Jan 2 2021, 8:50 PM
mmel added a comment to D27895: arm: atomic_testand{set,clear} didn't follow atomic(9) API.

I just committed fix for arm.
Thanks for cooperation.

Jan 2 2021, 7:58 PM
mmel committed R10:bd03acedb804: arm: Fix atomic_testand{set,clear}_32(). According to atomic (9), the bit… (authored by mmel).
arm: Fix atomic_testand{set,clear}_32(). According to atomic (9), the bit…
Jan 2 2021, 7:54 PM
mmel added a comment to D27886: arm64: fix mask in atomic_testand{set,clear}_64.
In D27886#623242, @mmel wrote:

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.

Are you saying 32-bit ARM is also broken? Those are a little weirder, I think it uses sys/sys/_atomic_subword.h.

Yes, it is also broken. ARM uses its own implementation, which does not do modulo for the bit position.
See https://cgit.freebsd.org/src/tree/sys/arm/include/atomic-v6.h#n862.
I will commit proper fix in next hour or so...

Jan 2 2021, 6:30 PM
mmel abandoned D27891: bitset: Fix BIT_TEST_SET_ATOMIC and BIT_TEST_CLR_ATOMIC..

Hmm, right. It would be better to read the manual before coding. My bad.

Jan 2 2021, 6:14 PM
mmel requested review of D27891: bitset: Fix BIT_TEST_SET_ATOMIC and BIT_TEST_CLR_ATOMIC..
Jan 2 2021, 12:06 PM
mmel accepted D27886: arm64: fix mask in atomic_testand{set,clear}_64.

Good catch. It never occurred to me that we could have a bug in atomics on two architectures at the same time, so I wasn't looking for a problem in my own garden :) I will try to fix arm by myself.
Tested on real HW, everything OK.

Jan 2 2021, 7:59 AM

Dec 30 2020

mmel committed R10:28482babd08a: arm64: Use new arm_kernel_boothdr script for generating booti images. (authored by mmel).
arm64: Use new arm_kernel_boothdr script for generating booti images.
Dec 30 2020, 12:58 PM
mmel committed R10:59f46e34cf64: sys/tools: Add a tool for generating arm and arm64 kernel images. (authored by mmel).
sys/tools: Add a tool for generating arm and arm64 kernel images.
Dec 30 2020, 12:25 PM
mmel committed R10:509a00620523: Tegra210: Connect to GENERIC kernel. (authored by mmel).
Tegra210: Connect to GENERIC kernel.
Dec 30 2020, 10:02 AM
mmel committed R10:30ae416898ef: Tegra210: Add lost-in-merge fixes: (authored by mmel).
Tegra210: Add lost-in-merge fixes:
Dec 30 2020, 10:02 AM

Dec 28 2020

mmel added inline comments to D26735: Improve loading of multipage aligned buffers..
Dec 28 2020, 2:03 PM
mmel committed R10:e90347891960: ARM64: Port FreeBSD to Nvidia Jetson TX1 and Nano. (authored by mmel).
ARM64: Port FreeBSD to Nvidia Jetson TX1 and Nano.
Dec 28 2020, 1:19 PM

Dec 27 2020

mmel committed R10:c8300031980e: EXTRES: Ignore index modifier flags for table based clock dividers. (authored by mmel).
EXTRES: Ignore index modifier flags for table based clock dividers.
Dec 27 2020, 4:49 PM
mmel accepted D27765: Use L2 blocks when in the identity map.

This is not entirely true, for every SoC we know where DRAM is located and its maximum size. Same is true for all MMIO peripherals.

Dec 27 2020, 3:58 PM
mmel added a comment to D27765: Use L2 blocks when in the identity map.

Tested with LINUX_BOOT_ABI, everything works fine.
But why did you also change the behavior for SOCDEV_PA/VA? Removal of the option to choose a SOCDEV_PA looks a like step backward to me. This breaks existing code (but covered by #if 0) for example in uart_dev_snps.c. At least this change should be mentioned in commit message, but I think that old way is better.

Dec 27 2020, 10:21 AM

Dec 26 2020

mmel committed R10:b9cbd68d1cbb: ARM: Enhance common Nvidia Tegra drivers by support for Tegra210 SoC. (authored by mmel).
ARM: Enhance common Nvidia Tegra drivers by support for Tegra210 SoC.
Dec 26 2020, 6:29 PM
mmel added a comment to D27765: Use L2 blocks when in the identity map.

Can you, please, rebase this to fresh tree?
Patch fails for me with:

git apply -p0  ../../git/D27765.diff
error: patch failed: sys/arm64/arm64/locore.S:497
error: sys/arm64/arm64/locore.S: patch does not app
Dec 26 2020, 12:01 PM
mmel committed R10:9211df29150d: MFC r366192: (authored by mmel).
MFC r366192:
Dec 26 2020, 7:53 AM

Dec 25 2020

mmel committed R10:aa76f0c39741: PMC: remove now orphaned PMC for INTEL XScale processors. (authored by mmel).
PMC: remove now orphaned PMC for INTEL XScale processors.
Dec 25 2020, 2:55 PM

Dec 17 2020

mmel committed rS368717: MFC r368167,r368187,r368203:.
MFC r368167,r368187,r368203:
Dec 17 2020, 1:17 PM
mmel committed rS368715: MFC r368364:.
MFC r368364:
Dec 17 2020, 12:58 PM

Dec 16 2020

mmel closed D27265: Use the standard method for localizing of MSI-X table bar..
Dec 16 2020, 2:39 PM
mmel committed rS368698: Use the standard method for localizing of MSI-X table bar..
Use the standard method for localizing of MSI-X table bar.
Dec 16 2020, 2:39 PM
mmel committed rS368697: Allocate right number of pages for the bounced buffers crossing the page..
Allocate right number of pages for the bounced buffers crossing the page.
Dec 16 2020, 2:37 PM

Dec 14 2020

mmel committed rS368635: Remove unused functions and variables in cpufunc.[ch]..
Remove unused functions and variables in cpufunc.[ch].
Dec 14 2020, 2:01 PM
mmel committed rS368634: Finish implementation of ARM PMU interrupts..
Finish implementation of ARM PMU interrupts.
Dec 14 2020, 1:10 PM
mmel committed rS368633: Verify (and fix) the context_id argument passed to the mpentry () by PSCI..
Verify (and fix) the context_id argument passed to the mpentry () by PSCI.
Dec 14 2020, 11:58 AM
mmel committed rS368631: MFC r368161:.
MFC r368161:
Dec 14 2020, 11:09 AM
mmel committed rS368630: MFC r367955:.
MFC r367955:
Dec 14 2020, 10:17 AM