lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250808083916.959079-1-yangzh0906@thundersoft.com>
Date: Fri,  8 Aug 2025 16:39:16 +0800
From: Albert Yang <yangzh0906@...ndersoft.com>
To: arnd@...db.de
Cc: adrian.hunter@...el.com,
	gordon.ge@....ai,
	linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org,
	ulf.hansson@...aro.org,
	yangzh0906@...ndersoft.com
Subject: Re: [PATCH v2 5/8] mmc: sdhci: add Black Sesame Technologies BST C1200 controller driver

Hi Arnd,

Thank you for your detailed review and technical guidance on the dma-ranges
configuration and hardware address mapping solutions.

On Fri, Jul 11, 2025, at 08:55, Arnd Bergmann wrote:

>A more sensible setup would be to have the DMA access
>routed to the memory controller. Since memory on your
>system appears to start at 0x8.00000000, that would look
>like
>
>        dma-ranges = <0x0 0x0  0x08 0x00000000  0x1 0x00000000>;
>
>which means that a DMA to the first 4GB of the bus
>address space gets routed outside of the bus into the
>first 4GB of physical memory. Obviously you cannot just
>change the dts to pretend this is the correct mapping, you
>have to also program the bus controller to use it.
>
>The datasheet for the chip should tell you specifically
>what type of bus this is (AXI, AHB, OPB or something else),
>and what registers are used to program this mapping. It
>is possible that this cannot be reprogrammed, but more likely
>there is a hidden register that is made available to the boot
>loader but is not intended to be reconfigured by the OS.

After investigating the approaches you suggested, I need to clarify the
hardware constraints we face:

The BST C1200 SoC has fundamental hardware limitations:
- System RAM starts at 0x8.00000000 (above 32-bit addressable range)
- The eMMC controller's DMA engine is limited to 32-bit addressing
- The SMMU does not function for address translation in this path due to
  hardware design flaws
- These limitations were finalized during silicon design and cannot be
  modified in software

Regarding your suggestion about programming the bus controller mapping,
we have thoroughly reviewed the BST C1200 datasheet and confirmed:
- No accessible registers exist to reprogram the address mapping
- The 32-bit DMA limitation is a hard constraint of the controller IP

Given these silicon-level constraints, the current bounce buffer approach
represents the only viable solution to provide eMMC functionality on this
platform.

We understand this is not an ideal architectural solution and appreciate
your patience in reviewing this hardware-constrained implementation. I want
to assure you that these design limitations have been addressed in our
subsequent chip generations.

We would appreciate your consideration of this approach given the documented
hardware constraints. Thank you again for your time and expertise in
reviewing this patch.

Best regards,
Albert Yang

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ