Page MenuHomeFreeBSD

mmel (Michal Meloun)
User

Projects

User Details

User Since
Feb 3 2015, 4:54 AM (249 w, 6 d)

Recent Activity

Sat, Nov 16

mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Hi Mmel,

In D22255#489923, @mmel wrote:

Hi Mmel,
Please find my comments inline.

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:
• Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).

In locore.S L1 block page table entry is built on 1GiB aligned physical load addr of kernel. However this is irrespective of using loader or U-Boot to boot the FreeBSD kernel.

• U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets.

Yes.
As part of this patch linux_load_initrd() will do build_l1_block_pagetable() to map initrd start address aligned to 1GiB PA=VA.
(By default, initrd_addr_r will be relocated to highmem by booti in U-Boot code (do_bootm_linux->boot_prep_linux->boot_reloc_ramdisk->boot_ramdisk_high)).
locore.S maps 1GiB algined kernel_addr_r PA=VA. I assumed that fdt_addr_r ( a couple of KiB’s in size) can also be within this 1GiB aligned addr. However, fdt_addr_r can be mapped similar to initrd start addr (in linux_load_initrd()).

Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..)

Sure.

It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

Sure. My understanding is that patch handles this. Physical load address of,
kernel is mapped into KVA starting at KERNBASE in locore.S
dtb blob is mapped into KVA starting at [ KERNBASE+(kernel size) ] in machdep_boot.c
initrd is mapped into KVA starting at [ KERNBASE+(kernel size) + (dtb size) ] in machdep_boot.c

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).

[1]
locore.S does maps kernel physical load addr into KVA starting at [ KERNBASE ] to [ KERNBASE + (kernel size)] using build_l2_block_pagetable. KVA is in L2 table which has 512, 2MiB entries. 1GiB L1 table entry is linked to this L2 table.
The following comments from create_pagetables: in locore.S,

  • It relys on:
  • We were loaded to an address that is on a 2MiB boundary
  • All the memory must not cross a 1GiB boundaty
  • x28 contains the physical address we were loaded from *

I am mapping dtb and initrd image into L2 table following the end of kernel. Therefore I created build_l2_block_pagetable() in machdep_boot.c
In fact if this not done dtb or initrd cannot be added into KVA. Due to above comments, I added a print in machdep_boot.c if kernel+dtb+initrd will exceed 1GiB.

This is not exact description. You allocates and maps new memory (by using lastaddr) for fdt and initrd blobs. Then you *copy* these blobs to new location. See lines 122 and 127 for fdt, and lines 270, 273 and 275 for initrd.

Basically, I am creating 2MiB KVA L2 table entries to move the fdt and initrd blobs from PA to KVA.

As you can see, you have mapped both source and destination address for initrd blob memmove(), but only destination address was mapped for fdt blob memmove() (point me to right place if I’m wrong, please).

Sorry I did not understand this clearly. inirtd size (in counts of 2MiB) is calculated using initrd-end - inird-start. For dtb the size is available in its header.

Problem is not about initrd but fdt blob
at line 127 we do
memmove((void *)lastaddr, dtb_ptr, dtb_size);
destination memory is mapped at line 122 by
build_l2_block_pagetable(lastaddr, dtb_size, abp
but where is mapped source memory (pointed by dtb_ptr in memmove())????

Sat, Nov 16, 1:57 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Hi Mmel,
Please find my comments inline.

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:
• Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).

In locore.S L1 block page table entry is built on 1GiB aligned physical load addr of kernel. However this is irrespective of using loader or U-Boot to boot the FreeBSD kernel.

• U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets.

Yes.
As part of this patch linux_load_initrd() will do build_l1_block_pagetable() to map initrd start address aligned to 1GiB PA=VA.
(By default, initrd_addr_r will be relocated to highmem by booti in U-Boot code (do_bootm_linux->boot_prep_linux->boot_reloc_ramdisk->boot_ramdisk_high)).
locore.S maps 1GiB algined kernel_addr_r PA=VA. I assumed that fdt_addr_r ( a couple of KiB’s in size) can also be within this 1GiB aligned addr. However, fdt_addr_r can be mapped similar to initrd start addr (in linux_load_initrd()).

Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..)

Sure.

It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

Sure. My understanding is that patch handles this. Physical load address of,
kernel is mapped into KVA starting at KERNBASE in locore.S
dtb blob is mapped into KVA starting at [ KERNBASE+(kernel size) ] in machdep_boot.c
initrd is mapped into KVA starting at [ KERNBASE+(kernel size) + (dtb size) ] in machdep_boot.c

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).

[1]
locore.S does maps kernel physical load addr into KVA starting at [ KERNBASE ] to [ KERNBASE + (kernel size)] using build_l2_block_pagetable. KVA is in L2 table which has 512, 2MiB entries. 1GiB L1 table entry is linked to this L2 table.
The following comments from create_pagetables: in locore.S,

  • It relys on:
  • We were loaded to an address that is on a 2MiB boundary
  • All the memory must not cross a 1GiB boundaty
  • x28 contains the physical address we were loaded from *

I am mapping dtb and initrd image into L2 table following the end of kernel. Therefore I created build_l2_block_pagetable() in machdep_boot.c
In fact if this not done dtb or initrd cannot be added into KVA. Due to above comments, I added a print in machdep_boot.c if kernel+dtb+initrd will exceed 1GiB.

This is not exact description. You allocates and maps new memory (by using lastaddr) for fdt and initrd blobs. Then you *copy* these blobs to new location. See lines 122 and 127 for fdt, and lines 270, 273 and 275 for initrd. As you can see, you have mapped both source and destination address for initrd blob memmove(), but only destination address was mapped for fdt blob memmove() (point me to right place if I’m wrong, please).

Sat, Nov 16, 10:22 AM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

After more detailed analysis, I think that there are more problems.
Let me explain situation. Givens are:

  1. Actual locore.S mappings of kernel expects that physical memory is aligned to 1GB boundary. This implies that we don’t support boards with lower that 1 GB memory (I don’t see other real limitation caused by this fact).
  2. U-Boot booti command expect that kernel, fdt, and initrd blobs are loaded at ${kernel_addr_r}, ${fdt_addr_r} and ${initrd_addr_r} offsets. Real value of these variables is driven by u-boot and we cannot expect nothing about this value. (order, gaps, etc..) It’s possible that kernel want to load kernel at begining of memory and initrd blob at end. We must support this, it's generic part of ‘distro_boot’ u-booot protocol/framework. And support of distro_boot is one of major goals for having booti supported, imo.

This give me some conclusions:
Because of 1) optimal mapping granularity is 1GB, more fine grained granularity is nothing than waste of TLB entries and build_l2_block_pagetable() is useless. (at least I don’t see single advantage of using fine grained mappings, while disadvantage is clear - more TLB pressure ).
Because of 2) – all 3 booti blobs must be taken separately. I don’t see single reason for postponing mapping of FDT to C code. Original locoer.S works and build_l2_block_pagetable() is unusable. Using lastaddr for reservation of memory used by initrd is clearly nonsense. Initrd blob should be reserved by using (probably) arm_physmem_exclude_regions() and map it later , when pmap is fully bootstrapped.

Sat, Nov 16, 3:52 AM · arm64

Fri, Nov 15

mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

please, use original locore.S from D13861 I'ts tested on many boards and it works :).

Fri, Nov 15, 3:18 PM · arm64
mmel added inline comments to D22255: Boot arm64 kernel using booti command from U-boot. .
Fri, Nov 15, 12:13 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

Moreover this doesn't boot on RockPro64, where original code from D13861 works without problems. jhibbits, please revert this, this code needs definitely more love. (Please, be sure that I'm first who wants booti support in kernel, but broken support is worse that no support)

Fri, Nov 15, 12:05 PM · arm64
mmel added a comment to D22255: Boot arm64 kernel using booti command from U-boot. .

I'm sorry for delayed review, but I am overloaded with my current work on Rockchip ports.
But in any case, if you want to reuse someone else's patch, it would be better to include the original author directly as the reviewer.

Fri, Nov 15, 9:17 AM · arm64

Fri, Nov 8

mmel added inline comments to D22281: Cleanup Rockchip clocks implementation..
Fri, Nov 8, 6:11 PM
mmel created D22283: Tidy up Rockchip composite clock..
Fri, Nov 8, 5:18 PM
mmel created D22282: Enhance Rockchip clocks implementation..
Fri, Nov 8, 5:17 PM
mmel created D22281: Cleanup Rockchip clocks implementation..
Fri, Nov 8, 5:14 PM

Wed, Nov 6

mmel accepted D22260: regulator: Add regulator_check_voltage function.

LGTM

Wed, Nov 6, 2:49 PM

Wed, Oct 23

mmel accepted D22106: regulator: Add a regnode_set_constraint function.

LGTM

Wed, Oct 23, 9:51 AM
mmel accepted D22106: regulator: Add a regnode_set_constraint function.

rest is OK for me.

Wed, Oct 23, 9:24 AM
mmel added a comment to D22106: regulator: Add a regnode_set_constraint function.

The code itself looks OK for me. But I have problem with using its usage as default regulator init method, because:

  • it cannot be used by regulators with its own init
  • it expect that regulator is accessible early, at registration time. I'm not sure if this is possible in all cases (like I2C and interrupts ..)
Wed, Oct 23, 8:14 AM

Oct 4 2019

mmel added a comment to D21703: o Unify all <machine>/resource.h, unhide PCI_RES_BUS, add CLK and PWR..

Can you, please, give me your motivation for adding new resource types when it’s clear that these resources cannot be handled by resman/newbus without extreme API breakage?
For OFW/FDT world, major issues are:

    • given resource (request, allocated) cannot be described by single integer, and infrastructure must take it fully opaque (there is nothing like ‘resource start’, ‘resource end’ and interval enumerator)
  • hierarchy for other resources(clk, regulator, reset, phy, ...) is not bus related and can have circular dependencies – so it cannot be represented by tree, but by graph. This result to fact that bus enumerator cannot prepare resource list for its child devices. This is something which break basic design expectation of newbus.
  • circular resource dependencies (between types – frequent, within single resource type – no that frequent but exist mainly for clocks) also means, that we relay need staggered device_attach(), there is no way to do this by automatic ordering of devices attach, driven by resource availability.

Another current newbus or bus_space limitation is that we should have (general, globalized) memory attributes and be should pass it do all memory mapping function. On arm or arm64, PCI config space should be mapped with different attribute (strongly ordered) that pci (or other devices) mmio register space (posted writes are allowed). Actual behavior (all devices are mapped as strongly ordered) have measurable performance impact.
Don’t take me badly, I’m still newbus fan, I only don’t see reliable way how we can extend it without fatal/significant API breakage.

Oct 4 2019, 8:14 AM

Mar 19 2019

mmel committed rS345299: PSCI: Don't take missing implementation of psci get_version() as fatal..
PSCI: Don't take missing implementation of psci get_version() as fatal.
Mar 19 2019, 3:42 PM
mmel committed rS345297: Improve cpufreq_dt..
Improve cpufreq_dt.
Mar 19 2019, 2:35 PM
mmel committed rS345296: Use named field's initializer when constructing <foo>_platform structure..
Use named field's initializer when constructing <foo>_platform structure.
Mar 19 2019, 2:33 PM
mmel committed rS345295: extres: Unify error codes for <foo>_get_by_ofw_property() methods..
extres: Unify error codes for <foo>_get_by_ofw_property() methods.
Mar 19 2019, 2:31 PM

Feb 15 2019

mmel accepted D19206: stand: dev_net: correct net_open's interpretation of params.

Yep, thanks.

Feb 15 2019, 3:40 PM
mmel accepted D19196: Per discussions on arch@ and elsewhere, retire drm module / drives..
Feb 15 2019, 6:46 AM

Feb 11 2019

mmel accepted D19139: Make taskqgroup_attach{,_cpu}(9) work across architectures.

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)

Feb 11 2019, 5:15 PM

Feb 10 2019

mmel committed rS343965: Fix bug introduced by r343962..
Fix bug introduced by r343962.
Feb 10 2019, 6:28 PM
mmel committed rS343963: Don't allocate same clock twice...
Don't allocate same clock twice..
Feb 10 2019, 2:30 PM
mmel committed rS343962: Properly handle alignment requests bigger that page size..
Properly handle alignment requests bigger that page size.
Feb 10 2019, 2:25 PM

Feb 6 2019

mmel committed rS343828: Adapt FreeBSD specific DT stub for Jetson TK1 board to be consistent with.
Adapt FreeBSD specific DT stub for Jetson TK1 board to be consistent with
Feb 6 2019, 6:04 AM

Jan 27 2019

mmel committed rS343498: Properly define and declare phynode_topo_lock,.
Properly define and declare phynode_topo_lock,
Jan 27 2019, 3:50 PM

Jan 7 2019

mmel committed rS342847: MFC r342113:.
MFC r342113:
Jan 7 2019, 11:03 AM

Dec 15 2018

mmel committed rS342113: Improve R_AARCH64_TLSDESC relocation..
Improve R_AARCH64_TLSDESC relocation.
Dec 15 2018, 10:39 AM
mmel closed D18417: Improve R_AARCH64_TLSDESC relocation..
Dec 15 2018, 10:39 AM
mmel committed rS342112: Fix mismerge caused by r342111..
Fix mismerge caused by r342111.
Dec 15 2018, 9:14 AM
mmel committed rS342111: MFC r341738:.
MFC r341738:
Dec 15 2018, 6:35 AM
mmel committed rS342110: MFC r341738:.
MFC r341738:
Dec 15 2018, 6:25 AM

Dec 14 2018

mmel committed rS342078: MFC r341679:.
MFC r341679:
Dec 14 2018, 10:46 AM
mmel committed rS342077: MFC r341679:.
MFC r341679:
Dec 14 2018, 10:30 AM
mmel committed rS342075: MFC r341511,r341512,r341513:.
MFC r341511,r341512,r341513:
Dec 14 2018, 10:25 AM
mmel committed rS342074: MFC r341511,r341512,r341513:.
MFC r341511,r341512,r341513:
Dec 14 2018, 10:20 AM

Dec 9 2018

mmel added a comment to D17137: arm64: Add HWCAP support.

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.

Dec 9 2018, 12:30 PM
mmel committed rS341760: MFC r341393:.
MFC r341393:
Dec 9 2018, 6:48 AM

Dec 8 2018

mmel updated the diff for D18417: Improve R_AARCH64_TLSDESC relocation..
Dec 8 2018, 3:20 PM
mmel committed rS341738: Implement R_AARCH64_TLS_DTPMOD64 and A_AARCH64_TLS_DTPREL64 relocations..
Implement R_AARCH64_TLS_DTPMOD64 and A_AARCH64_TLS_DTPREL64 relocations.
Dec 8 2018, 2:58 PM

Dec 7 2018

mmel committed rS341679: Fix cut&paste typo in atomic_fetchadd_64()..
Fix cut&paste typo in atomic_fetchadd_64().
Dec 7 2018, 11:13 AM

Dec 5 2018

mmel committed rS341513: Tidy up arm64 reloc_jmpslots() implementation..
Tidy up arm64 reloc_jmpslots() implementation.
Dec 5 2018, 10:32 AM
mmel committed rS341512: Implement arm64 version of __tls_get_addr()..
Implement arm64 version of __tls_get_addr().
Dec 5 2018, 10:25 AM
mmel committed rS341511: Fix style(9)..
Fix style(9).
Dec 5 2018, 10:25 AM
mmel added a comment to D14409: Sandbox head(1) with fileargs..

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

Dec 5 2018, 5:06 AM

Dec 4 2018

mmel added a comment to D14409: Sandbox head(1) with fileargs..

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

Dec 4 2018, 2:43 PM
mmel added a comment to D14409: Sandbox head(1) with fileargs..

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)

Dec 4 2018, 2:04 PM

Dec 3 2018

mmel created D18417: Improve R_AARCH64_TLSDESC relocation..
Dec 3 2018, 10:26 AM

Dec 2 2018

mmel added a comment to D17367: Eliminate pointless calls to vm_fault_prefault().

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.

Dec 2 2018, 3:59 PM
mmel added a comment to D17367: Eliminate pointless calls to vm_fault_prefault().

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).

Dec 2 2018, 1:57 PM
mmel committed rS341394: MFC r338317:.
MFC r338317:
Dec 2 2018, 7:45 AM
mmel committed rS341393: Return computed real memory size, not a value from similarly named.
Return computed real memory size, not a value from similarly named
Dec 2 2018, 7:41 AM

Nov 15 2018

mmel added inline comments to D17978: regulator_fixed: Do not disable fixed regulator at probe.
Nov 15 2018, 6:19 AM

Nov 3 2018

mmel added a member for arm64: mmel.
Nov 3 2018, 8:58 AM

Oct 30 2018

mmel added a comment to D17750: extres/phy: Add phy_set_mode method.

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.

Oct 30 2018, 8:52 AM · arm64, ARM

Aug 25 2018

mmel committed rS338317: Fix wrong offset calculation for R_ARM_TLS_TPOFF32 relocations..
Fix wrong offset calculation for R_ARM_TLS_TPOFF32 relocations.
Aug 25 2018, 4:54 PM

Aug 22 2018

mmel added a comment to D16510: Rework rtld's TLS Variant I implementation to match r326794.

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 22 2018, 10:40 AM

Aug 13 2018

mmel committed rS337705: MFC r335249:.
MFC r335249:
Aug 13 2018, 8:48 AM
mmel committed rS337704: Add USB ID for rebranded RTL8153 found on NVIDIA Jetson TX1 board..
Add USB ID for rebranded RTL8153 found on NVIDIA Jetson TX1 board.
Aug 13 2018, 7:28 AM

Aug 8 2018

mmel added a comment to D16555: Add support for pmap_enter(..., psind == 1) to armv6's pmap.
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 :)

Aug 8 2018, 7:31 AM
mmel accepted D16555: Add support for pmap_enter(..., psind == 1) to armv6's pmap.

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 8 2018, 6:35 AM

Aug 1 2018

mmel accepted D16517: snd_hda: Enable bus_dmamap_sync operations, both new and uncommented.

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.

Aug 1 2018, 8:40 AM

Jul 29 2018

mmel accepted D16443: Prepare for adding psind == 1 support to armv6's pmap_enter().

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

Jul 29 2018, 9:51 AM

Jun 16 2018

mmel updated the diff for D13861: Add support for booting FreeBSD kernel directly from U_Boot using booti command..

Rebased to current, renamed UBOOT_BOOT_API to LINUX_BOOT_API

Jun 16 2018, 9:32 AM

Mar 9 2018

mmel accepted D14541: Make Raspberry Pi RNG compatible with upstream DTBs.
Mar 9 2018, 5:18 AM

Mar 2 2018

mmel accepted D14541: Make Raspberry Pi RNG compatible with upstream DTBs.

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

Mar 2 2018, 11:35 AM

Feb 10 2018

mmel added a comment to D14299: sysutils/rpi-firware Include dtb and overlays.

+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.

Feb 10 2018, 5:07 PM

Jan 19 2018

mmel updated the diff for D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7..
  • print actual mitigation variant if bootversode
  • slightly restructure code to make additional vendors or CPUs addition easier
Jan 19 2018, 5:07 PM

Jan 18 2018

mmel added inline comments to D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7..
Jan 18 2018, 2:47 PM
mmel updated the diff for D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7..

Addressed all objections.

Jan 18 2018, 2:18 PM

Jan 17 2018

mmel added inline comments to D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7..
Jan 17 2018, 7:00 AM

Jan 16 2018

mmel retitled D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7. from Implement BP hardening as mitigation for Spectre Version 2 attacks on ARMv7 platforms. to Implement mitigation for Spectre Version 2 attacks on ARMv7..
Jan 16 2018, 7:51 AM
mmel created D13931: Implement mitigation for Spectre Version 2 attacks on ARMv7..
Jan 16 2018, 6:16 AM

Jan 12 2018

mmel updated the diff for D13863: Simplify and cleanup startup code for secondary cores..
Jan 12 2018, 8:42 AM
mmel added a comment to D13861: Add support for booting FreeBSD kernel directly from U_Boot using booti command..

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.

Jan 12 2018, 8:01 AM
mmel added a comment to D13864: Add workaround for broken PSCI implementation..

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

Jan 12 2018, 7:14 AM
mmel added a comment to D13863: Simplify and cleanup startup code for secondary cores..

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 12 2018, 7:09 AM

Jan 11 2018

mmel added a comment to D13861: Add support for booting FreeBSD kernel directly from U_Boot using booti command..

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...)
Jan 11 2018, 4:12 PM
mmel created D13864: Add workaround for broken PSCI implementation..
Jan 11 2018, 3:46 PM
mmel created D13863: Simplify and cleanup startup code for secondary cores..
Jan 11 2018, 3:44 PM
mmel created D13861: Add support for booting FreeBSD kernel directly from U_Boot using booti command..
Jan 11 2018, 2:57 PM

Dec 26 2017

mmel added a comment to D13619: axp209: move driver to sys/dev/pmic.

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 26 2017, 12:04 PM

Dec 23 2017

mmel accepted D13521: syscon: Introduce kobj and split out fdt bits.

Perfect, thanks.

Dec 23 2017, 9:20 AM

Dec 21 2017

mmel added a comment to D13521: syscon: Introduce kobj and split out fdt bits.

Everything else looks OK for me.

Dec 21 2017, 4:30 AM
mmel added a comment to D13536: Set the address of translation table for thread0..

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 21 2017, 4:07 AM

Dec 19 2017

mmel added a comment to D13536: Set the address of translation table for thread0..

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); .

Dec 19 2017, 3:41 PM
mmel accepted D8720: Add ACPI support to the GICv2 and GICv3 drivers..

No objection from arm or intrng side.

Dec 19 2017, 3:04 PM
mmel added a comment to D13536: Set the address of translation table for thread0..

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

Dec 19 2017, 2:58 PM

Dec 12 2017

mmel added inline comments to D13455: u-boot-tools: Add new ports u-boot-tools.
Dec 12 2017, 4:54 AM
mmel accepted D13455: u-boot-tools: Add new ports u-boot-tools.

Thanks !!!

Dec 12 2017, 4:51 AM

Dec 8 2017

mmel added a comment to D13378: Rework alignment handling in __libc_allocate_tls() for Variant I of TLS layout..

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

Dec 8 2017, 10:04 AM

Dec 5 2017

mmel created D13378: Rework alignment handling in __libc_allocate_tls() for Variant I of TLS layout..
Dec 5 2017, 4:46 PM

Nov 29 2017

mmel added a comment to D13152: math/R: Fix build on armv6 and armv7 (RE: Bug 223476).

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/

Nov 29 2017, 1:22 PM

Nov 25 2017

mmel added a comment to D13134: [mips32/tls] change TCB size from 8 to 16 to be aligned with r324938 & r325364.

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 25 2017, 8:58 AM

Nov 20 2017

mmel added a comment to D13134: [mips32/tls] change TCB size from 8 to 16 to be aligned with r324938 & r325364.

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 20 2017, 3:19 PM

Nov 19 2017

mmel accepted D13152: math/R: Fix build on armv6 and armv7 (RE: Bug 223476).

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

Nov 19 2017, 7:52 AM

Nov 3 2017

mmel added a comment to D12816: Fix qt5 builds on some arm architectures.

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

Nov 3 2017, 6:20 AM
mmel added inline comments to D12907: Add alignment support to __libc_allocate_tls()..
Nov 3 2017, 6:06 AM