Hailo-10H DDR regconfig needed for MT53E4G32D8GS 16GB LPDDR4 on AI HAT+ 2

General Discussion
, ,
1

I’m investigating DDR initialisation support after physically replacing the LPDDR4 RAM package on a Raspberry Pi AI HAT+ 2 / Hailo-10H board.

To be clear, I did not replace or modify the RAM on the Raspberry Pi 5 host. The RAM package was replaced on the AI HAT+ 2 itself.

Original board:

  • Raspberry Pi AI HAT+ 2
  • Hailo-10H
  • Boots as board-sku-6 / 8GiB

Replacement RAM package installed on the AI HAT+ 2:
Micron MT53E4G32D8GS-046 WT:C

Part details:

  • LPDDR4
  • 128Gb / 16GB package
  • 4G x32 organisation
  • x32 bus
  • 4266 MT/s
  • 200-ball package

Current behaviour:
After the RAM package replacement, the Hailo-10H still boots and is electrically stable. HailoRT detects the device, and Hailo GenAI workloads run successfully.

HailoRT evidence:
hailortcli scan detects:
Device: 0001:01:00.0

hailortcli fw-control identify reports:
Firmware Version: 5.1.1 (release,app)
Device Architecture: HAILO10H

The device is stable under Hailo GenAI workloads. I successfully ran Hailo-Ollama LLM HEF models and Qwen2-VL-2B-Instruct.hef VLM workloads. A 10-pass VLM burn-in across real images completed with:

  • throttled=0x0
  • no Hailo DMA / vDMA / PCIe / timeout / reset errors in dmesg
  • Hailo device remained alive afterward

However, the Hailo boot firmware still initialises the DDR as 8 GiB.

Boot/UART evidence:
[DDR] DDR #0 initialized successfully (8 GiB, 4266MT/s, BIST)
Machine model: Hailo - Hailo10 RPI 8GiB (board-sku-6)

I inspected the live signed DTB and the public hailo-ai/hailo-u-boot source.

Current live selector:
assembled_dram_pn = “MT53E2G32D4DE-046_regconfig_8GB”

Public hailo-u-boot source shows board-sku-6 uses:
arch/arm/dts/hailo10-board-sku-6.dts:
#include “hailo1x_ddr_MT53E2G32D4DE-046_regconfig_8GB_LP4.dtsi”

Available Hailo DDR regconfig files appear to cover only:

  • 1GB
  • 2GB
  • 4GB
  • 8GB

I could not find any Hailo DDR profile for:

  • MT53E4G32D8GS
  • MT53E4G32
  • 4G32D8
  • 128Gb
  • 16GB
  • 16GiB

I searched local Hailo firmware packages 5.1.1, 5.2.0, and 5.3.0, plus public hailo-ai/hailo-u-boot refs. Hailo 5.3.0 appears to select an 8GB_LP4 profile and changes the DDR PHY table, but still no 16GB profile is present.

Additional practical capacity test:
Qwen2-VL-2B-Instruct HEF loads successfully. Two VLM instances can be loaded, but three VLM instances fail with HAILO_TIMEOUT / buffer overflow / HAILO_CONNECTION_REFUSED. This is consistent with the Hailo firmware still operating under the 8GB DDR profile rather than exposing the full 16GB package.

Question:
Does Hailo-10H boot firmware support Micron MT53E4G32D8GS-046 WT:C when fitted to a Raspberry Pi AI HAT+ 2?

If yes, is there a Hailo-10H DDR regconfig / DTSI profile available for this part, equivalent to something like:

hailo1x_ddr_MT53E4G32D8GS-046_regconfig_16GB_LP4.dtsi

or another supported 16GB LPDDR4 profile?

If not publicly available, can Hailo confirm whether such a profile exists internally, or whether this 16GB package is unsupported by the current Hailo-10H boot firmware?

Thanks.

1 Like
2

Welcome to the Hailo Community!

At present, there are no DRAM devices larger than 8GB on the supported devices list.

Well done. Replacing the DDR memory on the AI HAT+ 2 is not something we typically expect users to do.

If this work is related to a commercial project, please feel free to send me a PM so we can discuss it in more detail.

3

Thanks for the confirmation.

That matches what I found from the public hailo-u-boot source and the local firmware packages. The HAT+ 2 boots and runs GenAI/VLM workloads with the MT53E4G32D8GS-046 package fitted, but the boot chain still selects the existing MT53E2G32D4DE-046 8GB DDR profile.

So it sounds like the missing piece is official Hailo DDR training/regconfig support for a >8GB LPDDR4 package, rather than an issue with HailoRT or the Linux driver.

At this stage im just experimenting rather than a commercial product, but I’d be interested to know whether Hailo has any roadmap or internal support for 16GB Hailo-10H DRAM configurations, or whether the limitation is expected to remain at 8GB for supported devices.

Thanks again

4

At the moment, supported Hailo-10H DRAM configurations are focused on up to 8GB, and we do not currently have plans we can share regarding 16GB support.

With current DRAM prices, larger memory configurations are difficult to justify commercially in many edge deployments. At the same time, smaller and more efficient LLMs continue to improve. Therefore, we are looking at expanding support for additional lower-capacity DDR devices rather than moving to larger configurations for now.

That said, we continue to evaluate requirements and feedback from our customers.

5

Makes sense.

During the Hailo-10H DDR initialisation path. When inspecting the extracted Hailo-10H DTB, I noticed these fields:

dram_auto_detect_en = <0x00>;
assembled_dram_pn = “MT53E2G32D4DE-046_regconfig_8GB”;

My understanding is that the current board-sku-6 firmware is therefore not attempting DRAM auto-detection, and is explicitly selecting the existing 8GB Micron DDR profile.

Could you clarify what dram_auto_detect_en does on Hailo-10H?

  • Does it only auto-select between known/supported DDR regconfig profiles already present in the firmware?
  • Or can it actually query/identify the fitted LPDDR4 device and derive the correct geometry/timings?
  • If enabled, would it have any chance of recognising a larger 128Gb / 16GB LPDDR4 package such as MT53E4G32D8GS-046, or would it still require a matching Hailo-generated DDR regconfig?
  • if testing a new DRAM configuration requires a modified Hailo-10H DTB/regconfig, is there an official developer or evaluation path for doing that while still passing the firmware security/signature checks?

Thanks again.

6

No.
We do have an Approved Component List document for developers designing their own hardware. As mentioned before, we currently focus on devices with up to 8 GB of RAM.

Since this would require work from our R&D team, it’s something we could discuss only within the scope of a commercial project.

I believe that is the case.

I am not sure that this is either possible or desirable. While it could be a useful feature in a modular system, embedded systems typically prioritize reliability. Automatically identifying a DDR device introduces an additional point of failure that could prevent the system from booting.