AM625: u-boot failed to initialize 8Gb of DDR4 with sysconfig configuration

Alexis, let me double check with the software team on the device tree changes.

In the meantime, can you try with:

Data Bus Width (per device) 8
Density (per device) (Gb) 16
Chip Selects / Ranks 2

Regards,

James

Hello James,

Here are the information return by u-boot with the configuration: 

Data Bus Width (per device) 8
Density (per device) (Gb) 16
Chip Selects / Ranks 2

=> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000080000000
-> size     = 0x0000000080000000
DRAM bank   = 0x0000000000000001
-> start    = 0x0000000880000000
-> size     = 0x0000000080000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x00000000fff03000
reloc off   = 0x000000007f703000
Build       = 64-bit
current eth = ethernet@8000000port@1
ethaddr     = 28:b5:e8:d4:64:6b
IP addr     = 10.0.0.5
fdt_blob    = 0x00000000fded0670
new_fdt     = 0x00000000fded0670
fdt_size    = 0x0000000000013700
multi_dtb_fit= 0x0000000000000000
lmb_dump_all:
 memory.cnt = 0x2 / max = 0x10
 memory[0]      [0x80000000-0xffffffff], 0x80000000 bytes flags: 0
 memory[1]      [0x880000000-0x8ffffffff], 0x80000000 bytes flags: 0
 reserved.cnt = 0x6 / max = 0x10
 reserved[0]    [0x9c700000-0x9c7fffff], 0x00100000 bytes flags: 0
 reserved[1]    [0x9c800000-0x9d9fffff], 0x01200000 bytes flags: 4
 reserved[2]    [0x9db00000-0x9e6fffff], 0x00c00000 bytes flags: 4
 reserved[3]    [0x9e780000-0x9fffffff], 0x01880000 bytes flags: 4
 reserved[4]    [0xfcec7000-0xffffffff], 0x03139000 bytes flags: 0
 reserved[5]    [0x880000000-0x8ffffffff], 0x80000000 bytes flags: 0
devicetree  = separate
serial addr = 0x0000000002800000
 width      = 0x0000000000000000
 shift      = 0x0000000000000002
 offset     = 0x0000000000000000
 clock      = 0x0000000002dc6c00
stack ptr   = 0x00000000fdecf9f8
ram_top ptr = 0x0000000100000000
malloc base = 0x00000000fdee4000
arch_number = 0x0000000000000000
TLB addr    = 0x00000000ffff0000
irq_sp      = 0x00000000fdecfff0
sp start    = 0x00000000fdecfff0
Early malloc usage: 3bc0 / 8000

I use the device tree file generated by the tool DDR sysconfig for the AM625.

There is no error accessing the no reserve memory in bank 0 and bank 1.

Regards,

Alexis.

Hi Alexis, so are you able to uniquely access the full 8GByte range?

Regards,

James

Hi James, I'm not sure to understand what you mean by "full 8GBytes range". I can only access 4GB of memory.

I mean 2GBytes on bank0 and 2GBytes on bank1, it is what I program in the memory section in the device tree for the test with the last configuration you asked me to test. If I'm right a density of 16Gbits with 2 ranks is for a total of 4GBytes of memory. Is it exact ?

So no I don't have access to the full range, only 4GB over 8GB.

Regards,

Alexis.

Hi Alexis,

we believe there is some limitation in the addressing in uboot.  We are still investigating this.

In the meantime, if you go back to:

Data Bus Width (per device) 8
Density (per device) (Gb) 32
Chip Selects / Ranks 2

are you able to boot into the kernel?  If so, can you try to access bank1 above 0x900000000?

Also, what version of SDK are you using?

Regards,

James

Hi James,

1 - Also, what version of SDK are you using?

I use SDK 10 with ti-u-boot version 10.00.07 and ti-kernel-linux version 10.00.07.

2 - are you able to boot into the kernel? 

Yes, but with 4Gb configured, I can't boot with 8Gb configured.

I will do the test again to capture kernel log.

3 - If so, can you try to access bank1 above 0x900000000?

I configure 8Gb with Databus width 8, Density 32 and rank2.

The access from u-boot to address  0x900000000 and higher leads to a reset of the board:

As I mentioned the u-boot memory mapping is: 

DRAM bank = 0x0000000000000000
-> start = 0x0000000080000000
-> size = 0x0000000080000000
DRAM bank = 0x0000000000000001
-> start = 0x0000000880000000
-> size = 0x0000000180000000

=> mw.b 0x900000000 55
"Synchronous Abort" handler, esr 0x96000045, far 0x900000000
elr: 000000008081daa4 lr : 000000008081da24 (reloc)
elr: 00000000fff20aa4 lr : 00000000fff20a24
x0 : 0000000000000000 x1 : 0000000900000000
x2 : 0000000000000001 x3 : 00000000fdf03df2
x4 : 0000000000000100 x5 : 0000000000000000
x6 : 00000000fffb00ad x7 : 0000000000000044
x8 : 0000000000000010 x9 : 0000000000000005
x10: 0000000000000006 x11: 000000000001869f
x12: 00000000ffffffff x13: 0000000100000000
x14: 00000000ffffffff x15: 00000000fdecf848
x16: 00000000fff209bc x17: 0000000000000000
x18: 00000000fdee3d70 x19: 0000000900000000
x20: 0000000000000001 x21: 0000000000000055
x22: 00000000fdefc650 x23: 0000000000000003
x24: 00000000fffea840 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000fdf03e10 x29: 00000000fdecfcf0

Code: 71000a9f 54000061 79000035 17fffff7 (39000035)
Resetting CPU ...

Regards,

Alexis

Hi Alexis,

we are able to reproduce this issue, and it is a limitation in u-boot as the higher addresses are not mapped. Since u-boot does not use more than 4GBytes, it was never mapped in earlier SDKs.  So when you try to write into those higher banks, it will crash

If you use SDK11, this issue is fixed, and you would be able to access the higher banks in u-boot using those commands.

However, if you are still using SDK10, you won't be able to access the higher banks in u-boot (ie, the aborts you are seeing is expected), but you should still be able to boot into the kernel using 8GB, and then you should be able to access the full 8GB range from the kernel prompt.

Please provide full boot log with 8GB configured.  Ensure DDR config uses:

Data Bus Width (per device) 8
Density (per device) (Gb) 32
Chip Selects / Ranks 2

Regards,

James

Hi James,

I tried to apply my patch from TiSDK10 to the u-boot version used by the TiSDK11, but some files are missing and memory is no more present in the device tree.

The use the information from the TiSDK11 to build u-boot from source: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_01_05_03/exports/docs/linux/Foundational_Components/U-Boot/BG-Build-K3.html#build-u-boot.

Could you give me which files must be modified to configure u-boot to use 8Gb of memory.

Regards,

Alexis.

Hi Alexis,

Since U-Boot v2025.01 which is used on SDK11.x, the devicetree files have been moved from <U-Boot>/arch/arm/dts/ directory to <U-Boot>/dts/upstream/src/arm64/ti/ to align with the devicetree files in kernel. But the U-Boot specific devicetree files (for example, DDR config) are still in the original directory.

If you still have problem in moving to SDK11 U-Boot, please provide your SDK10 U-Boot patch or list which files have been modified, I can show you which corresponding files to be modified in SDK11 U-Boot.

Hi Bin,

Thanks for your help.

Here are the file I modified in u-boot to configure for 4GB of DDR4, with 1 rank.

But I need to modify the memory configuration for 8GB of DDR4, let me know which file must be modified.

- I replace the DDR4 configuration by the sysconfig file with Bus width 8 bits, Density 32Gb and rank 2
The file is arch/arm/dts/k3-am62x-sk-ddr4-1600MTs.dtsi

- Then I modify memory node to have 2 banks of memory for 4GB, it must be change to 8GB.

diff --git a/arch/arm/dts/k3-am625-sk.dts b/arch/arm/dts/k3-am625-sk.dts
index 5ca722aec43..c8f9cd05fe7 100644
--- a/arch/arm/dts/k3-am625-sk.dts
+++ b/arch/arm/dts/k3-am625-sk.dts
@@ -24,8 +24,9 @@

        memory@80000000 {
                device_type = "memory";
-               /* 2G RAM */
-               reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+               /* 4G RAM */
+               reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+                       <0x00000008 0x80000000 0x00000000 0x80000000>;

        };

- Same thing that above.

diff --git a/arch/arm/dts/k3-am62x-sk-common.dtsi b/arch/arm/dts/k3-am62x-sk-common.dtsi
index 59ee4961650..fb5f85cda42 100644
--- a/arch/arm/dts/k3-am62x-sk-common.dtsi
+++ b/arch/arm/dts/k3-am62x-sk-common.dtsi
@@ -30,8 +30,9 @@
        memory@80000000 {
                bootph-pre-ram;
                device_type = "memory";
-               /* 2G RAM */
-               reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+               /* 4G RAM */
+               reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+                       <0x00000008 0x80000000 0x00000000 0x80000000>;
        };

- I disabled CONFIG_ARCH_FIXUP_FDT_MEMORY in u-boot to use the memory mapping define in the linux kernel device tree.

I don't know if it is still necessary, let me know if I have to remove this patch.

+++ b/configs/am62x_evm_a53_defconfig
@@ -35,6 +35,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000
 CONFIG_BOOTSTD_FULL=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_FDT_SIMPLEFB=y
+# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
 CONFIG_BOARD_LATE_INIT=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x80D00000

Regards,

Alexis.

Hi Alexis,

Alexis LOGNON said:

But I need to modify the memory configuration for 8GB of DDR4, let me know which file must be modified.

For SDK10.x, it will still be in the same file: arch/arm/dts/k3-am625-sk.dts.

Alexis LOGNON said:

+++ b/arch/arm/dts/k3-am625-sk.dts
@@ -24,8 +24,9 @@

        memory@80000000 {
                device_type = "memory";
-               /* 2G RAM */
-               reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+               /* 4G RAM */
+               reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+                       <0x00000008 0x80000000 0x00000000 0x80000000>;

In each line of the 'reg' property of memory@800000000 node, the first two numbers are the DDR address (64bit), the last two numbers are the DDR size (64bit). So change the last two numbers at following for 8 GB DDR.

<0x00000008 0x80000000 0x00000001 0x80000000>;

Alexis LOGNON said:

- Same thing that above.

diff --git a/arch/arm/dts/k3-am62x-sk-common.dtsi b/arch/arm/dts/k3-am62x-sk-common.dtsi

You don't need to modify the same in k3-am62x-sk-common.dtsi. This file is included in k3-am625-sk.dts, so the memory setting is overwritten by those in k3-am625-sk.dts.

FYI, the memory@80000000 node in k3-am62x-sk-common.dtsi has been removed in the latest devicetree code, since it is redundant.

Alexis LOGNON said:

- I disabled CONFIG_ARCH_FIXUP_FDT_MEMORY in u-boot to use the memory mapping define in the linux kernel device tree.

I don't know if it is still necessary, let me know if I have to remove this patch.

No, you shouldn't disable it. it would cause kernel boot to stop.

Bin Liu said:

For SDK10.x, it will still be in the same file: arch/arm/dts/k3-am625-sk.dts.

Forgot to mention, this file has been moved to <U-Boot>/dts/upstream/src/arm64/ti/ directory in SDK11.x U-Boot.

Hi Bin,

I look at the TI u-boot repo at tag 11.01.05: https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/dts?h=11.01.05.

There is no more the file k3-am625-sk.dts.

There is a file k3-am625-r5-sk.dts, do I need to path it also ?

By the way I modify the following files, to check that my modifications are applied.

I configure the 2 banks and reduced the first bank from 2GB to 1GB.

I can see that the modification of the first memory bank is done, but there is not the second bank.

 Here is the u-boot logs:

-Boot 2025.01-00531-g1ac7b41e843c (Oct 02 2025 - 17:18:59 +0200)

SoC:   AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 SK
DRAM:  1 GiB
Core:  83 devices, 32 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@8000000port@1

Hit any key to stop autoboot:  0 
=> bdinfo
boot_params = 0x0000000000000000
DRAM bank   = 0x0000000000000000
-> start    = 0x0000000080000000
-> size     = 0x0000000040000000
flashstart  = 0x0000000000000000
flashsize   = 0x0000000000000000
flashoffset = 0x0000000000000000
baudrate    = 115200 bps
relocaddr   = 0x00000000bfe9a000
reloc off   = 0x000000003f69a000

Could you confirm that the second bank is well managed by the SDK11 ?

Here are the patches.

diff --git a/arch/arm/dts/k3-am62-sk-common-u-boot.dtsi b/arch/arm/dts/k3-am62-sk-common-u-boot.dtsi
index b88c1fb6191..9b153eaf044 100644
--- a/arch/arm/dts/k3-am62-sk-common-u-boot.dtsi
+++ b/arch/arm/dts/k3-am62-sk-common-u-boot.dtsi
@@ -11,6 +11,14 @@
         tick-timer = &main_timer0;
     };
 
+        memory@80000000 {
+                device_type = "memory";
+                /* 8G RAM */
+                reg = <0x00000000 0x80000000 0x00000000 0x40000000>,
+                      <0x00000008 0x80000000 0x00000001 0x80000000>;
+                bootph-pre-ram;
+        };
+
     panel_lvds: panel-lvds {
         bootph-pre-ram;
         compatible = "simple-panel";
-- 
2.34.1

diff --git a/dts/upstream/src/arm64/ti/k3-am625-sk.dts b/dts/upstream/src/arm64/ti/k3-am625-sk.dts
index 6cd74660292..b5c51789eb5 100644
--- a/dts/upstream/src/arm64/ti/k3-am625-sk.dts
+++ b/dts/upstream/src/arm64/ti/k3-am625-sk.dts
@@ -28,8 +28,9 @@
        memory@80000000 {
                bootph-pre-ram;
                device_type = "memory";
-               /* 2G RAM */
-               reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+               /* 8G RAM */
+               reg = <0x00000000 0x80000000 0x00000000 0x40000000>,
+                     <0x00000008 0x80000000 0x00000001 0x80000000>;

        };

Regards,

Alexis.

Hello,

Without any response I made a diff between the u-boot configuration of the SDK10 and SDK11. I saw that one developer commit a change regarding the number of memory bank supported by the AM625. Could you clarify why such modification has been made ?

Could you also indicated the best way to validate the 8GB of memory under Linux, does I need to modify something to make the memory test tools memtest or stress-ng working ?

Regards,

Alexis.

Alexis, best way to validate 8GB in linux is to first perform a sanity check that you can *uniquely* write to the whole memory:

Use devmem2 tool from linux prompt to perform single writes of unique values across the memory (eg, at 0x80000000, 0xC0000000, 0x880000000, 0x900000000, 0x980000000, etc) . Then perform a readback of those same locations to ensure values are correct and were not overwritten due to aliasing.

The linux memtester tool will stress the interface, it is not necessary to test specific addresses.  But if you want linux to choose an address from a certain region, i believe you can modify the DT to reserve this memory region first, then you can run memtester on it.  Bin should be able to give more details on this.

Regards,

James

Hello James,

I have done some tests I reserved the area 880000000-9ffffffff as shown below: 

80080000-9c7fffff : System RAM
  82010000-830effff : Kernel code
  830f0000-8338ffff : reserved
  83390000-8357ffff : Kernel data
  87fff000-87ffffff : reserved
  8ffee000-8fffcfff : reserved
  9c700000-9c7fffff : reserved
9c800000-9e6fffff : reserved
9e700000-9e7fffff : System RAM
9e800000-9fffffff : reserved
a0000000-ffffffff : System RAM
  eb740000-f79fffff : reserved
  f7a6d000-f7b6dfff : reserved
  f7b6e000-f7bc5fff : reserved
  f7bc8000-f7bc8fff : reserved
  f7bc9000-f7bcbfff : reserved
  f7bcc000-f7bddfff : reserved
  f7bde000-ffffffff : reserved
500000000-5ffffffff : fc40000.spi spi@fc40000
880000000-9ffffffff : reserved

I compile devmem2 to access several address between 0x880000000 0x9FFFFFFFF, and the R/W access works.

So I clone the code and add a feature to write a range of address.

- For the range 0x880000000 for a size of 80000000 (2GB) there is no errors.

- For the range 0x900000000 for a size of 80000000 (2GB) the Linux kernel hang, if the first area 16 Mo.

I done several test with tisdk11 with the yocto build and the armbian trixie distribution.

The results are the same, the test shown that the kernel crash at differents offset.

By example:

0x900000000 + 0x2347d0

0x900000000 + 0x17c338

0x910000000 + 0x22a76d 

I also do a test stress for the CPU without any issue, and done the same test with only 1 cpu enable, but the issue is still there.

Could you help us to identify the issue ?

Do you think I can modify some parameter with the DDR sysconfig tools, to isolate the root cause of the probleme ?

Do you have any JTAG script that can help to test the DDR without Linux running ?

Regards,

Alexis.

Hi Alexis,

What is the output of the following command on your board right after boot into linux?

# dmesg | grep 'Memory:'

Hi Bin,

Here is the ouput of 'dmesg | grep 'Memory:'':

Memory: 1672660K/8388608K available (12992K kernel code, 1256K rwdata, 4668K rodata, 2752K init, 642K bss, 6576964K reserved, 131072K cma-reserved)

I add the output of:

- cat /proc/meminfo
MemTotal: 1814396 kB
MemFree: 1525008 kB
MemAvailable: 1562488 kB
Buffers: 1052 kB
Cached: 162932 kB
SwapCached: 0 kB
Active: 24328 kB
Inactive: 193904 kB
Active(anon): 780 kB
Inactive(anon): 62724 kB
Active(file): 23548 kB
Inactive(file): 131180 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 54248 kB
Mapped: 73888 kB
Shmem: 9256 kB
KReclaimable: 13568 kB
Slab: 32932 kB
SReclaimable: 13568 kB
SUnreclaim: 19364 kB
KernelStack: 2316 kB
PageTables: 2472 kB
SecPageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 907196 kB
Committed_AS: 315344 kB
VmallocTotal: 135288315904 kB
VmallocUsed: 11188 kB
VmallocChunk: 0 kB
Percpu: 1024 kB
HardwareCorrupted: 0 kB
AnonHugePages: 14336 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
CmaTotal: 131072 kB
CmaFree: 129584 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB

- cat /proc/iomem
000f4000-000f42ab : pinctrl-single
00104044-0010404b : 104044.phy phy@4044
00600000-006000ff : 600000.gpio gpio@600000
00601000-006010ff : 601000.gpio gpio@601000
00b00000-00b003ff : b00000.temperature-sensor temperature-sensor@b00000
00b01000-00b013ff : b00000.temperature-sensor temperature-sensor@b00000
01800000-0180ffff : GICD
01880000-0193ffff : GICR
02400000-024003ff : 2400000.timer timer@2400000
02410000-024103ff : 2410000.timer timer@2410000
02420000-024203ff : 2420000.timer timer@2420000
02430000-024303ff : 2430000.timer timer@2430000
02440000-024403ff : 2440000.timer timer@2440000
02450000-024503ff : 2450000.timer timer@2450000
02460000-024603ff : 2460000.timer timer@2460000
02470000-024703ff : 2470000.timer timer@2470000
02800000-0280001f : serial
04084000-04084087 : pinctrl-single
05000000-0502ffff : 5000000.m4fss
05040000-0504ffff : 5000000.m4fss
08000000-081fffff : 8000000.ethernet cpsw_nuss
0e000000-0e0000ff : e000000.watchdog watchdog@e000000
0e010000-0e0100ff : e010000.watchdog watchdog@e010000
0e020000-0e0200ff : e020000.watchdog watchdog@e020000
0e030000-0e0300ff : e030000.watchdog watchdog@e030000
0e0f0000-0e0f00ff : e0f0000.watchdog watchdog@e0f0000
0f900000-0f9007ff : f900000.dwc3-usb dwc3-usb@f900000
0f908000-0f9083ff : f900000.dwc3-usb dwc3-usb@f900000
0f910000-0f9107ff : f910000.dwc3-usb dwc3-usb@f910000
0f918000-0f9183ff : f910000.dwc3-usb dwc3-usb@f910000
0fa10000-0fa10fff : fa10000.mmc mmc@fa10000
0fa18000-0fa183ff : fa10000.mmc mmc@fa10000
0fc40000-0fc400ff : fc40000.spi spi@fc40000
20000000-200000ff : 20000000.i2c i2c@20000000
20010000-200100ff : 20010000.i2c i2c@20010000
20020000-200200ff : 20020000.i2c i2c@20020000
29000000-290001ff : 29000000.mailbox mailbox@29000000
2a000000-2a000fff : 2a000000.spinlock spinlock@2a000000
2b1f0000-2b1f00ff : 2b1f0000.rtc rtc@2b1f0000
30300000-30300fff : 30300000.crc crc@30300000
3100c100-3104ffff : 31000000.usb usb@31000000
31100000-31107fff : usb@31100000
31100000-31107fff : xhci-hcd.0.auto usb@31100000
3110c100-3114ffff : 31100000.usb usb@31100000
40900000-409011ff : 40900000.crypto crypto@40900000
43000014-43000017 : 43000014.chipid chipid@14
44043000-44043fdf : 44043000.system-controller debug_messages
48000000-480fffff : 48000000.interrupt-controller interrupt-controller@48000000
485c0000-485c00ff : 485c0000.dma-controller gcfg
485c0100-485c01ff : 485c0100.dma-controller gcfg
4a400000-4a47ffff : 4d000000.mailbox scfg
4a600000-4a67ffff : 4d000000.mailbox rt
4a800000-4a81ffff : 485c0000.dma-controller rchanrt
4a820000-4a83ffff : 485c0100.dma-controller rchanrt
4aa00000-4aa1ffff : 485c0000.dma-controller tchanrt
4aa40000-4aa5ffff : 485c0100.dma-controller tchanrt
4b800000-4b9fffff : 485c0000.dma-controller ringrt
4bc00000-4bcfffff : 485c0100.dma-controller ringrt
4c000000-4c01ffff : 485c0100.dma-controller bchanrt
4d000000-4d07ffff : 4d000000.mailbox target_data
70000000-7000ffff : 70000000.sram sram@70000000
78000000-78007fff : 78000000.r5f
78100000-78107fff : 78000000.r5f
80000000-8007ffff : reserved
80080000-9c7fffff : System RAM
82010000-8315ffff : Kernel code
83160000-8340ffff : reserved
83410000-835fffff : Kernel data
87fff000-87ffffff : reserved
8ffee000-8fffcfff : reserved
9c700000-9c7fffff : reserved
9c800000-9e6fffff : reserved
9e700000-9e7fffff : System RAM
9e800000-9fffffff : reserved
a0000000-ffffffff : System RAM
eb740000-f79fffff : reserved
f7a6d000-f7b6dfff : reserved
f7b6e000-f7bc5fff : reserved
f7bc8000-f7bc8fff : reserved
f7bc9000-f7bcbfff : reserved
f7bcc000-f7bddfff : reserved
f7bde000-ffffffff : reserved
500000000-5ffffffff : fc40000.spi spi@fc40000
880000000-9ffffffff : reserved

Regards,

Alexis.

Hi Alexis, sorry, some of your answers are unclear to me, can you clarify:

Alexis LOGNON said:

I compile devmem2 to access several address between 0x880000000 0x9FFFFFFFF, and the R/W access works.

Does this mean you tried several read/write across all of 0x880000000 thru 0x9FFFFFFFF successfully using devmem2?  Did you ensure that you can uniquely access this region of memory (ie, writing to 0x880000000 doesn't affect 0x900000000 or 0x980000000, for example)?

Alexis LOGNON said:

So I clone the code and add a feature to write a range of address.

- For the range 0x880000000 for a size of 80000000 (2GB) there is no errors.

- For the range 0x900000000 for a size of 80000000 (2GB) the Linux kernel hang, if the first area 16 Mo.

What do you mean by "if the first area 16 Mo."?  

Alexis LOGNON said:

I done several test with tisdk11 with the yocto build and the armbian trixie distribution.

The results are the same, the test shown that the kernel crash at differents offset.

By example:

0x900000000 + 0x2347d0

0x900000000 + 0x17c338

0x910000000 + 0x22a76d 

Can you explain this test, or better yet, post this log?  When you write the range of addresses, does it work for a while and then fail at one of those offsets?  Or were you able to write the whole block successfully and only failed at those 3 offsets?

Alexis LOGNON said:

I also do a test stress for the CPU without any issue

What stress test did you run?  This indicates that you have a robust DDR configuration

Alexis LOGNON said:

and done the same test with only 1 cpu enable, but the issue is still there.

I don't understand this.  Was the stress test that was successful run with multiple CPUs?

If i'm interpreting your answers correctly, it looks like you can successfully access all 8GB of memory, and you have run a stress test and passed.  So i'm not sure why you are still seeing hang issues.

Regards,

James