All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Linus Walleij" <linusw@kernel.org>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 3/3] ARM: dts: broadcom: Use CFE CPU bring-up on the XG6846B
Date: Wed, 21 Oct 2026 15:29:27 +0000	[thread overview]
Message-ID: <sashiko-outbox-180435@kernel.org> (raw)
In-Reply-To: <20261021-genexis-xg6846-smp-v7-3-rc1-v3-3-7c871f1755db@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ARM: dts: broadcom: xg6846b partial no-map removal breaks lowmem setup
--

commit 83c5177a7db3728e4dd180472b439b349fdb5f65
Author: Linus Walleij <linusw@kernel.org>

ARM: dts: broadcom: Use CFE CPU bring-up on the XG6846B

This commit disables the inherited PSCI node on the Genexis XG6846B and
configures the CPUs to use the Broadcom BCA CFE SMP bring-up method. It
also removes the no-map property from the secondary-boot@0 reserved-memory
node so the reservation does not fail when overlapping the initial page
tables.

> diff --git a/arch/arm/boot/dts/broadcom/bcm6846-genexis-xg6846b.dts b/arch/arm/boot/dts/broadcom/bcm6846-genexis-xg6846b.dts
> index a3616fb7b3a8d..45d4df5231109 100644
> --- a/arch/arm/boot/dts/broadcom/bcm6846-genexis-xg6846b.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm6846-genexis-xg6846b.dts
> @@ -34,7 +34,7 @@ reserved-memory {
>  		ranges;
>  
>  		secondary-boot@0 {
> -			no-map;
> +			/* Includes the kernel's initial page tables. */
>  			reg = <0x00000000 0x00008000>;
>  		};
>  		pmc3-firmware@8000 {

[Severity: High]
Could removing no-map from secondary-boot@0 while leaving no-map on the
immediately adjacent pmc3-firmware@8000 node cause a boot regression in
adjust_lowmem_bounds(), prepare_page_table(), and map_lowmem()?

In arch/arm/boot/dts/broadcom/bcm6846-genexis-xg6846b.dts, reserved-memory
now has a mapped 32 KiB region followed by a 1 MiB no-map region:

		secondary-boot@0 {
			/* Includes the kernel's initial page tables. */
			reg = <0x00000000 0x00008000>;
		};
		pmc3-firmware@8000 {
			no-map;
			reg = <0x00008000 0x00100000>;
		};

On multi_v7_defconfig (which enables CONFIG_ARCH_BCMBCA=y alongside
CONFIG_ARCH_MESON=y), arch/arm/Makefile sets TEXT_OFFSET to 0x00208000,
placing swapper_pg_dir at physical [0x00204000, 0x00208000) and
KERNEL_START (_stext) at 0x00208000.

During setup_arch() -> arm_memblock_init() ->
early_init_fdt_scan_reserved_mem(), secondary-boot@0 is reserved via
memblock_reserve(0x0, 0x8000) and remains mapped in memblock.memory, while
pmc3-firmware@8000 does not overlap the kernel at 0x00208000 and is marked
MEMBLOCK_NOMAP via memblock_mark_nomap(0x8000, 0x100000). This splits
memblock.memory into:

  regions[0] = [0x00000000, 0x00008000) (MEMBLOCK_NONE)
  regions[1] = [0x00008000, 0x00108000) (MEMBLOCK_NOMAP)
  regions[2] = [0x00108000, 0x10000000) (MEMBLOCK_NONE)

In arch/arm/mm/mmu.c:adjust_lowmem_bounds(), the first loop checks whether
block_start of the first usable range [0x0, 0x8000) is aligned to PMD_SIZE
(which succeeds because 0x0 is aligned) and breaks without aligning
regions[2] (0x00108000). The second loop then checks block_end on
[0x0, 0x8000):

	for_each_mem_range(i, &block_start, &block_end) {
		if (block_start < vmalloc_limit) {
			if (block_end > lowmem_limit)
				lowmem_limit = min_t(u64,
							 vmalloc_limit,
							 block_end);

			if (!memblock_limit) {
				if (!IS_ALIGNED(block_start, PMD_SIZE))
					memblock_limit = block_start;
				else if (!IS_ALIGNED(block_end, PMD_SIZE))
					memblock_limit = lowmem_limit;
			}

		}
	}

Because block_end is 0x8000 (!IS_ALIGNED(block_end, PMD_SIZE)),
memblock_limit is set to 0x8000, which round_down(memblock_limit, PMD_SIZE)
rounds down to 0, calling memblock_set_current_limit(0).

Next, in paging_init() -> prepare_page_table(), end is computed from
memblock.memory.regions[0] as 0x8000:

	end = memblock.memory.regions[0].base + memblock.memory.regions[0].size;
	if (end >= arm_lowmem_limit)
		end = arm_lowmem_limit;

	for (addr = __phys_to_virt(end);
	     addr < VMALLOC_START; addr += PMD_SIZE)
		pmd_clear(pmd_off_k(addr));

This clears all kernel PMDs from __phys_to_virt(0x8000) up to
VMALLOC_START, unmapping the running kernel at 0xc0208000. Immediately
afterward in paging_init() -> map_lowmem(), processing regions[0]
([0x0, 0x8000)) with kernel_sec_start == 0 == start and end (0x8000) <
kernel_sec_end hits Case 1:

			if (kernel_sec_start == start)
				start = kernel_sec_end;
			if (kernel_sec_end == end)
				end = kernel_sec_start;
		...
		map.pfn = __phys_to_pfn(start);
		map.virtual = __phys_to_virt(start);
		map.length = end - start;
		map.type = MT_MEMORY_RW;
		create_mapping(&map);

which sets start = kernel_sec_end while end remains 0x8000, underflowing
map.length = end - start while memblock.current_limit is 0.

Conversely, on configs where TEXT_OFFSET == 0x00008000 (such as
bcm6846_defconfig), KERNEL_START is at physical 0x00008000 and is already
reserved by arm_memblock_init() before early_init_fdt_scan_reserved_mem()
runs, so pmc3-firmware@8000 with no-map overlaps the kernel image and fails
in early_init_dt_reserve_memory() with -EBUSY (which is the only reason
memblock.memory is not split at 0x8000 on bcm6846_defconfig).

Should no-map also be removed from pmc3-firmware@8000, or how is
pmc3-firmware@8000 intended to coexist with the kernel image at physical
0x00008000 and 32-bit ARM's PMD_SIZE lowmem alignment requirements?

[ ... ]

>
>base-commit: 6356fd3dd29d8b5620507a0ce037c644e052b5dd
>-- 
>2.51.2
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021-genexis-xg6846-smp-v7-3-rc1-v3-0-7c871f1755db@kernel.org?part=3

  reply	other threads:[~2026-10-21 15:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 15:09 [PATCH v3 0/3] ARM: bcm: Enable CFE SMP on BCMBCA Linus Walleij
2026-10-21 15:09 ` [PATCH v3 1/3] dt-bindings: arm: cpus: Add brcm,bca-smp enable method Linus Walleij
2026-10-22 14:15   ` Rob Herring
2026-10-24  4:20     ` William Zhang
2026-10-21 15:09 ` [PATCH v3 2/3] ARM: bcm: Add CFE SMP support for BCMBCA Linus Walleij
2026-10-24  4:15   ` William Zhang
2026-10-21 15:09 ` [PATCH v3 3/3] ARM: dts: broadcom: Use CFE CPU bring-up on the XG6846B Linus Walleij
2026-10-21 15:29   ` sashiko-bot [this message]
2026-10-24 19:44     ` Linus Walleij
2026-10-24  4:16   ` William Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-180435@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linusw@kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.