From: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Link: https://lore.kernel.org/qemu-devel/20250307035945.3698802-29-jamin_lin@aspeedtech.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
---
tests/functional/test_aarch64_aspeed.py | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tests/functional/test_aarch64_aspeed.py b/tests/functional/test_aarch64_aspeed.py
index 8df6a97a2852..c25c96627823 100755
--- a/tests/functional/test_aarch64_aspeed.py
+++ b/tests/functional/test_aarch64_aspeed.py
@@ -31,6 +31,10 @@ def do_test_aarch64_aspeed_sdk_start(self, image):
'https://github.com/AspeedTech-BMC/openbmc/releases/download/v09.05/ast2700-a0-default-obmc.tar.gz',
'cfbbd1cce72f2a3b73b9080c41eecdadebb7077fba4f7806d72ac99f3e84b74a')
+ ASSET_SDK_V905_AST2700A1 = Asset(
+ 'https://github.com/AspeedTech-BMC/openbmc/releases/download/v09.05/ast2700-default-obmc.tar.gz',
+ 'c1f4496aec06743c812a6e9a1a18d032f34d62f3ddb6956e924fef62aa2046a5')
+
def start_ast2700_test(self, name):
num_cpu = 4
uboot_size = os.path.getsize(self.scratch_file(name,
@@ -95,6 +99,12 @@ def test_aarch64_ast2700_evb_sdk_v09_05(self):
self.archive_extract(self.ASSET_SDK_V905_AST2700)
self.start_ast2700_test('ast2700-a0-default')
+ def test_aarch64_ast2700a1_evb_sdk_v09_05(self):
+ self.set_machine('ast2700a1-evb')
+
+ self.archive_extract(self.ASSET_SDK_V905_AST2700A1)
+ self.start_ast2700_test('ast2700-default')
+
if __name__ == '__main__':
QemuSystemTest.main()
--
2.48.1
Jamin,
On 3/9/25 14:51, Cédric Le Goater wrote:
> From: Jamin Lin <jamin_lin@aspeedtech.com>
>
> Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
> Link: https://lore.kernel.org/qemu-devel/20250307035945.3698802-29-jamin_lin@aspeedtech.com
> Signed-off-by: Cédric Le Goater <clg@redhat.com>
> ---
> tests/functional/test_aarch64_aspeed.py | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tests/functional/test_aarch64_aspeed.py b/tests/functional/test_aarch64_aspeed.py
> index 8df6a97a2852..c25c96627823 100755
> --- a/tests/functional/test_aarch64_aspeed.py
> +++ b/tests/functional/test_aarch64_aspeed.py
> @@ -31,6 +31,10 @@ def do_test_aarch64_aspeed_sdk_start(self, image):
> 'https://github.com/AspeedTech-BMC/openbmc/releases/download/v09.05/ast2700-a0-default-obmc.tar.gz',
> 'cfbbd1cce72f2a3b73b9080c41eecdadebb7077fba4f7806d72ac99f3e84b74a')
>
> + ASSET_SDK_V905_AST2700A1 = Asset(
> + 'https://github.com/AspeedTech-BMC/openbmc/releases/download/v09.05/ast2700-default-obmc.tar.gz',
> + 'c1f4496aec06743c812a6e9a1a18d032f34d62f3ddb6956e924fef62aa2046a5')
> +
> def start_ast2700_test(self, name):
> num_cpu = 4
> uboot_size = os.path.getsize(self.scratch_file(name,
> @@ -95,6 +99,12 @@ def test_aarch64_ast2700_evb_sdk_v09_05(self):
> self.archive_extract(self.ASSET_SDK_V905_AST2700)
> self.start_ast2700_test('ast2700-a0-default')
>
> + def test_aarch64_ast2700a1_evb_sdk_v09_05(self):
> + self.set_machine('ast2700a1-evb')
> +
> + self.archive_extract(self.ASSET_SDK_V905_AST2700A1)
> + self.start_ast2700_test('ast2700-default')
> +
>
> if __name__ == '__main__':
> QemuSystemTest.main()
On a BE host, if I run an ast2700a0-evb machine :
$ qemu-system-aarch64 -machine ast2700a0-evb ...
...
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A0
Model: AST2700 EVB
DRAM: 8 GiB (effective 0 Bytes)
QEMU hangs.
If the RAM size is defined to 8g
$ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ...
...
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A0
Model: AST2700 EVB
DRAM: 8 GiB
aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
Core: 125 devices, 27 uclasses, devicetree: separate
machine boots.
Whereas, with an ast2700a1-evb machine :
$ qemu-system-aarch64 -machine ast2700a1-evb ...
...
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A1
Model: AST2700 EVB
DRAM: 1 GiB
aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
Core: 125 devices, 27 uclasses, devicetree: separate
machine boots.
$ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ...
...
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A1
Model: AST2700 EVB
DRAM: 8 GiB
aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp. version(0)
Core: 125 devices, 27 uclasses, devicetree: separate
machine boots.
I Wonder if you could analyze this issue to check if it is related
to one of our QEMU model.
Thanks,
C.
Hi Cédric
>
> On a BE host, if I run an ast2700a0-evb machine :
>
> $ qemu-system-aarch64 -machine ast2700a0-evb ...
> ...
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A0
> Model: AST2700 EVB
> DRAM: 8 GiB (effective 0 Bytes)
>
> QEMU hangs.
>
> If the RAM size is defined to 8g
>
> $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ...
> ...
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A0
> Model: AST2700 EVB
> DRAM: 8 GiB
> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> version(0)
> Core: 125 devices, 27 uclasses, devicetree: separate
>
> machine boots.
>
> Whereas, with an ast2700a1-evb machine :
>
> $ qemu-system-aarch64 -machine ast2700a1-evb ...
> ...
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A1
> Model: AST2700 EVB
> DRAM: 1 GiB
> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> version(0)
> Core: 125 devices, 27 uclasses, devicetree: separate
>
> machine boots.
>
> $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ...
> ...
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A1
> Model: AST2700 EVB
> DRAM: 8 GiB
> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> version(0)
> Core: 125 devices, 27 uclasses, devicetree: separate
>
> machine boots.
>
>
> I Wonder if you could analyze this issue to check if it is related to one of our
> QEMU model.
>
>
Sorry, I only have a little-endian host machine (x86_64).
Is it possible to run a big-endian(POWER PC) QEMU host environment on this machine, so that I can then run the AST2700 QEMU target inside it to analyze this issue?
If you agree, could you please help me insert the following lines into the function that detects the DRAM size on the AST2700?
https://github.com/qemu/qemu/blob/master/hw/arm/aspeed_ast27x0.c#L332
https://github.com/qemu/qemu/commit/7436db1063bbfecc2e498a7d795613b33312d665
````
static void aspeed_ram_capacity_write(void *opaque, hwaddr addr, uint64_t data,
unsigned int size)
{
AspeedSoCState *s = ASPEED_SOC(opaque);
ram_addr_t ram_size;
MemTxResult result;
uint32_t read_back[4] = {0};
ram_size = object_property_get_uint(OBJECT(&s->sdmc), "ram-size",
&error_abort);
assert(ram_size > 0);
printf("jamin size %d\n", size);
printf("addr=%" PRIx64 " (addr ram_size)=%" PRIx64 "\n", addr, (addr % ram_size));
/*
* Emulate ddr capacity hardware behavior.
* If writes the data to the address which is beyond the ram size,
* it would write the data to the "address % ram_size".
*/
result = address_space_write(&s->dram_as, addr % ram_size,
MEMTXATTRS_UNSPECIFIED, &data, size);
if (result != MEMTX_OK) {
qemu_log_mask(LOG_GUEST_ERROR,
"%s: DRAM write failed, addr:0x%" HWADDR_PRIx
", data :0x%" PRIx64 "\n",
__func__, addr % ram_size, data);
}
address_space_read(&s->dram_as, addr % ram_size,
MEMTXATTRS_UNSPECIFIED, read_back,
size);
for(int i=0; i<4; i++) {
printf("jamin read_back[%d]=%x\n", i, read_back[i]);
}
}
````
Also, could you please provide me with the following log?
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A0
Model: AST2700 EVB
DRAM: jamin size 4
addr=c0000000 (addr ram_size)=0
jamin read_back[0]=eadbeef4
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
jamin size 4
addr=40000000 (addr ram_size)=0
jamin read_back[0]=adbeef43
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
jamin size 4
addr=0 (addr ram_size)=0
jamin read_back[0]=dbeef432
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
1 GiB
It's quite strange, because you mentioned that the A1 version works, but the A0 version doesn't.
It seems detect the DRAM size failed in this loop,
https://github.com/AspeedTech-BMC/u-boot/blob/aspeed-master-v2023.10/drivers/ram/aspeed/sdram_ast2700.c#L1173
struct ddr_capacity ram_size[] = {
{0x10000000, {208, 256}}, // 256MB
{0x20000000, {208, 416}}, // 512MB
{0x40000000, {208, 560}}, // 1GB
{0x80000000, {472, 880}}, // 2GB
{0x100000000, {656, 880}}, // 4GB
{0x200000000, {880, 880}}, // 8GB
};
u32 test_pattern = 0xdeadbeef
for (sz = SDRAM_SIZE_8GB - 1; sz > SDRAM_SIZE_256MB; sz--) {
test_pattern = (test_pattern << 4) + sz;
writel(test_pattern, (void *)CFG_SYS_SDRAM_BASE + ram_size[sz].size);
if (readl((void *)CFG_SYS_SDRAM_BASE) != test_pattern)
break;
}
Please help to dump this register.
=> md 12c00010
12c00010: 00000028 00000000 00000000 00000000 (...............
0x28-->
0010 1000
Bit0 : 0 DDR4 SDRAM
Bit:1 : 0 Reserved
Bit:4:2 : 010 --> 1GB
Thanks-Jamin
> Thanks,
>
> C.
On 5/16/25 04:59, Jamin Lin wrote:
> Hi Cédric
>
>>
>> On a BE host, if I run an ast2700a0-evb machine :
>>
>> $ qemu-system-aarch64 -machine ast2700a0-evb ...
>> ...
>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>
>> SOC: AST2700-A0
>> Model: AST2700 EVB
>> DRAM: 8 GiB (effective 0 Bytes)
>>
>> QEMU hangs.
>>
>> If the RAM size is defined to 8g
>>
>> $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ...
>> ...
>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>
>> SOC: AST2700-A0
>> Model: AST2700 EVB
>> DRAM: 8 GiB
>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>> version(0)
>> Core: 125 devices, 27 uclasses, devicetree: separate
>>
>> machine boots.
>>
>> Whereas, with an ast2700a1-evb machine :
>>
>> $ qemu-system-aarch64 -machine ast2700a1-evb ...
>> ...
>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>
>> SOC: AST2700-A1
>> Model: AST2700 EVB
>> DRAM: 1 GiB
>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>> version(0)
>> Core: 125 devices, 27 uclasses, devicetree: separate
>>
>> machine boots.
>>
>> $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ...
>> ...
>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>
>> SOC: AST2700-A1
>> Model: AST2700 EVB
>> DRAM: 8 GiB
>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>> version(0)
>> Core: 125 devices, 27 uclasses, devicetree: separate
>>
>> machine boots.
>>
>>
>> I Wonder if you could analyze this issue to check if it is related to one of our
>> QEMU model.
>>
>>
>
> Sorry, I only have a little-endian host machine (x86_64).
> Is it possible to run a big-endian(POWER PC) QEMU host environment on this machine, so that I can then run the AST2700 QEMU target inside it to analyze this issue?
You can but unless you have access to a POWER hypervisor, this will be
very slow because of the 2 levels of emulations.
> If you agree, could you please help me insert the following lines into the function that detects the DRAM size on the AST2700?
> https://github.com/qemu/qemu/blob/master/hw/arm/aspeed_ast27x0.c#L332
> https://github.com/qemu/qemu/commit/7436db1063bbfecc2e498a7d795613b33312d665
> ````
> static void aspeed_ram_capacity_write(void *opaque, hwaddr addr, uint64_t data,
> unsigned int size)
> {
> AspeedSoCState *s = ASPEED_SOC(opaque);
> ram_addr_t ram_size;
> MemTxResult result;
> uint32_t read_back[4] = {0};
> ram_size = object_property_get_uint(OBJECT(&s->sdmc), "ram-size",
> &error_abort);
>
> assert(ram_size > 0);
> printf("jamin size %d\n", size);
> printf("addr=%" PRIx64 " (addr ram_size)=%" PRIx64 "\n", addr, (addr % ram_size));
> /*
> * Emulate ddr capacity hardware behavior.
> * If writes the data to the address which is beyond the ram size,
> * it would write the data to the "address % ram_size".
> */
> result = address_space_write(&s->dram_as, addr % ram_size,
> MEMTXATTRS_UNSPECIFIED, &data, size);
> if (result != MEMTX_OK) {
> qemu_log_mask(LOG_GUEST_ERROR,
> "%s: DRAM write failed, addr:0x%" HWADDR_PRIx
> ", data :0x%" PRIx64 "\n",
> __func__, addr % ram_size, data);
> }
>
> address_space_read(&s->dram_as, addr % ram_size,
> MEMTXATTRS_UNSPECIFIED, read_back,
> size);
>
> for(int i=0; i<4; i++) {
> printf("jamin read_back[%d]=%x\n", i, read_back[i]);
> }
> }
> ````
> Also, could you please provide me with the following log?
>
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A0
> Model: AST2700 EVB
> DRAM: jamin size 4
> addr=c0000000 (addr ram_size)=0
> jamin read_back[0]=eadbeef4
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> jamin size 4
> addr=40000000 (addr ram_size)=0
> jamin read_back[0]=adbeef43
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> jamin size 4
> addr=0 (addr ram_size)=0
> jamin read_back[0]=dbeef432
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> 1 GiB
U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
SOC: AST2700-A0
Model: AST2700 EVB
DRAM: aspeed_sdmc_read reg @0x4 data: 0x28
aspeed_sdmc_read reg @0x4 data: 0x28
aspeed_sdmc_write reg @0x4 data: 0x34
jamin size 4
addr=c0000000 (addr ram_size)=0
jamin read_back[0]=0 <-- this is wrong
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
aspeed_sdmc_read reg @0x4 data: 0x3c
aspeed_sdmc_write reg @0x4 data: 0x34
aspeed_sdmc_read reg @0xc data: 0x0
aspeed_sdmc_write reg @0xc data: 0x1b8
aspeed_sdmc_read reg @0x40 data: 0x0
jamin size 4
addr=1bdea1f70 (addr ram_size)=3dea1f70
jamin read_back[0]=0
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
jamin size 4
addr=1bdea1f74 (addr ram_size)=3dea1f74
jamin read_back[0]=0
jamin read_back[1]=0
jamin read_back[2]=0
jamin read_back[3]=0
jamin size 4
>
> It's quite strange, because you mentioned that the A1 version works, but the A0 version doesn't.
> It seems detect the DRAM size failed in this loop,
> https://github.com/AspeedTech-BMC/u-boot/blob/aspeed-master-v2023.10/drivers/ram/aspeed/sdram_ast2700.c#L1173
> struct ddr_capacity ram_size[] = {
> {0x10000000, {208, 256}}, // 256MB
> {0x20000000, {208, 416}}, // 512MB
> {0x40000000, {208, 560}}, // 1GB
> {0x80000000, {472, 880}}, // 2GB
> {0x100000000, {656, 880}}, // 4GB
> {0x200000000, {880, 880}}, // 8GB
> };
> u32 test_pattern = 0xdeadbeef
>
> for (sz = SDRAM_SIZE_8GB - 1; sz > SDRAM_SIZE_256MB; sz--) {
> test_pattern = (test_pattern << 4) + sz;
> writel(test_pattern, (void *)CFG_SYS_SDRAM_BASE + ram_size[sz].size);
>
> if (readl((void *)CFG_SYS_SDRAM_BASE) != test_pattern)
> break;
> }
>
> Please help to dump this register.
> => md 12c00010
> 12c00010: 00000028 00000000 00000000 00000000 (...............
I can't do that because the u-boot prompt is never reached. From QEMU:
(qemu) x/10x 0x12c00010
0000000012c00010: 0x0000003c 0x00000000 0x00000000 0x00000000
0000000012c00020: 0x00000000 0x00000000 0x00000000 0x00000000
0000000012c00030: 0x000001b8 0x00000000
Hope it helps
C.
Hi Cédric
> Subject: Re: [PULL 45/46] tests/functional/aspeed: Add test case for AST2700
> A1
>
> On 5/16/25 04:59, Jamin Lin wrote:
> > Hi Cédric
> >
> >>
> >> On a BE host, if I run an ast2700a0-evb machine :
> >>
> >> $ qemu-system-aarch64 -machine ast2700a0-evb ...
> >> ...
> >> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
> >>
> >> SOC: AST2700-A0
> >> Model: AST2700 EVB
> >> DRAM: 8 GiB (effective 0 Bytes)
> >>
> >> QEMU hangs.
> >>
> >> If the RAM size is defined to 8g
> >>
> >> $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ...
> >> ...
> >> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
> >>
> >> SOC: AST2700-A0
> >> Model: AST2700 EVB
> >> DRAM: 8 GiB
> >> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> >> version(0)
> >> Core: 125 devices, 27 uclasses, devicetree: separate
> >>
> >> machine boots.
> >>
> >> Whereas, with an ast2700a1-evb machine :
> >>
> >> $ qemu-system-aarch64 -machine ast2700a1-evb ...
> >> ...
> >> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
> >>
> >> SOC: AST2700-A1
> >> Model: AST2700 EVB
> >> DRAM: 1 GiB
> >> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> >> version(0)
> >> Core: 125 devices, 27 uclasses, devicetree: separate
> >>
> >> machine boots.
> >>
> >> $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ...
> >> ...
> >> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
> >>
> >> SOC: AST2700-A1
> >> Model: AST2700 EVB
> >> DRAM: 8 GiB
> >> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
> >> version(0)
> >> Core: 125 devices, 27 uclasses, devicetree: separate
> >>
> >> machine boots.
> >>
> >>
> >> I Wonder if you could analyze this issue to check if it is related to
> >> one of our QEMU model.
> >>
> >>
> >
> > Sorry, I only have a little-endian host machine (x86_64).
> > Is it possible to run a big-endian(POWER PC) QEMU host environment on this
> machine, so that I can then run the AST2700 QEMU target inside it to analyze
> this issue?
>
> You can but unless you have access to a POWER hypervisor, this will be very
> slow because of the 2 levels of emulations.
>
> > If you agree, could you please help me insert the following lines into the
> function that detects the DRAM size on the AST2700?
> >
> https://github.com/qemu/qemu/blob/master/hw/arm/aspeed_ast27x0.c#L332
> >
> https://github.com/qemu/qemu/commit/7436db1063bbfecc2e498a7d795613b
> 333
> > 12d665
> > ````
> > static void aspeed_ram_capacity_write(void *opaque, hwaddr addr, uint64_t
> data,
> > unsigned int
> size) {
> > AspeedSoCState *s = ASPEED_SOC(opaque);
> > ram_addr_t ram_size;
> > MemTxResult result;
> > uint32_t read_back[4] = {0};
> > ram_size = object_property_get_uint(OBJECT(&s->sdmc), "ram-size",
> > &error_abort);
> >
> > assert(ram_size > 0);
> > printf("jamin size %d\n", size);
> > printf("addr=%" PRIx64 " (addr ram_size)=%" PRIx64 "\n", addr, (addr
> % ram_size));
> > /*
> > * Emulate ddr capacity hardware behavior.
> > * If writes the data to the address which is beyond the ram size,
> > * it would write the data to the "address % ram_size".
> > */
> > result = address_space_write(&s->dram_as, addr % ram_size,
> > MEMTXATTRS_UNSPECIFIED,
> &data, size);
> > if (result != MEMTX_OK) {
> > qemu_log_mask(LOG_GUEST_ERROR,
> > "%s: DRAM write failed, addr:0x%"
> HWADDR_PRIx
> > ", data :0x%" PRIx64 "\n",
> > __func__, addr % ram_size, data);
> > }
> >
> > address_space_read(&s->dram_as, addr % ram_size,
> > MEMTXATTRS_UNSPECIFIED, read_back,
> > size);
> >
> > for(int i=0; i<4; i++) {
> > printf("jamin read_back[%d]=%x\n", i, read_back[i]);
> > }
> > }
> > ````
> > Also, could you please provide me with the following log?
> >
> > U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
> >
> > SOC: AST2700-A0
> > Model: AST2700 EVB
> > DRAM: jamin size 4
> > addr=c0000000 (addr ram_size)=0
> > jamin read_back[0]=eadbeef4
> > jamin read_back[1]=0
> > jamin read_back[2]=0
> > jamin read_back[3]=0
> > jamin size 4
> > addr=40000000 (addr ram_size)=0
> > jamin read_back[0]=adbeef43
> > jamin read_back[1]=0
> > jamin read_back[2]=0
> > jamin read_back[3]=0
> > jamin size 4
> > addr=0 (addr ram_size)=0
> > jamin read_back[0]=dbeef432
> > jamin read_back[1]=0
> > jamin read_back[2]=0
> > jamin read_back[3]=0
> > 1 GiB
>
>
>
> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>
> SOC: AST2700-A0
> Model: AST2700 EVB
> DRAM: aspeed_sdmc_read reg @0x4 data: 0x28 aspeed_sdmc_read reg
> @0x4 data: 0x28 aspeed_sdmc_write reg @0x4 data: 0x34 jamin size 4
> addr=c0000000 (addr ram_size)=0
> jamin read_back[0]=0 <-- this is wrong
It seems that the "data" is in the CPU 's native endianness.
I'm currently looking for a big-endian environment to test the changes I made, and will update you once I have results.
uint32_t val = cpu_to_le32((uint32_t)data);
address_space_write(&s->dram_as, addr % ram_size,
MEMTXATTRS_UNSPECIFIED, &val, 4);
Thanks-Jamin
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> aspeed_sdmc_read reg @0x4 data: 0x3c
> aspeed_sdmc_write reg @0x4 data: 0x34
> aspeed_sdmc_read reg @0xc data: 0x0
> aspeed_sdmc_write reg @0xc data: 0x1b8
> aspeed_sdmc_read reg @0x40 data: 0x0
> jamin size 4
> addr=1bdea1f70 (addr ram_size)=3dea1f70
> jamin read_back[0]=0
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> jamin size 4
> addr=1bdea1f74 (addr ram_size)=3dea1f74
> jamin read_back[0]=0
> jamin read_back[1]=0
> jamin read_back[2]=0
> jamin read_back[3]=0
> jamin size 4
>
>
> >
> > It's quite strange, because you mentioned that the A1 version works, but the
> A0 version doesn't.
> > It seems detect the DRAM size failed in this loop,
> >
> https://github.com/AspeedTech-BMC/u-boot/blob/aspeed-master-v2023.10/d
> > rivers/ram/aspeed/sdram_ast2700.c#L1173
> > struct ddr_capacity ram_size[] = {
> > {0x10000000, {208, 256}}, // 256MB
> > {0x20000000, {208, 416}}, // 512MB
> > {0x40000000, {208, 560}}, // 1GB
> > {0x80000000, {472, 880}}, // 2GB
> > {0x100000000, {656, 880}}, // 4GB
> > {0x200000000, {880, 880}}, // 8GB
> > };
> > u32 test_pattern = 0xdeadbeef
> >
> > for (sz = SDRAM_SIZE_8GB - 1; sz > SDRAM_SIZE_256MB; sz--) {
> > test_pattern = (test_pattern << 4) + sz;
> > writel(test_pattern, (void *)CFG_SYS_SDRAM_BASE +
> > ram_size[sz].size);
> >
> > if (readl((void *)CFG_SYS_SDRAM_BASE) != test_pattern)
> > break;
> > }
> >
> > Please help to dump this register.
> > => md 12c00010
> > 12c00010: 00000028 00000000 00000000 00000000 (...............
>
> I can't do that because the u-boot prompt is never reached. From QEMU:
>
> (qemu) x/10x 0x12c00010
> 0000000012c00010: 0x0000003c 0x00000000 0x00000000 0x00000000
> 0000000012c00020: 0x00000000 0x00000000 0x00000000 0x00000000
> 0000000012c00030: 0x000001b8 0x00000000
>
> Hope it helps
>
> C.
>
Hello Jamin
On 5/19/25 03:52, Jamin Lin wrote:
> Hi Cédric
>
>> Subject: Re: [PULL 45/46] tests/functional/aspeed: Add test case for AST2700
>> A1
>>
>> On 5/16/25 04:59, Jamin Lin wrote:
>>> Hi Cédric
>>>
>>>>
>>>> On a BE host, if I run an ast2700a0-evb machine :
>>>>
>>>> $ qemu-system-aarch64 -machine ast2700a0-evb ...
>>>> ...
>>>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>>>
>>>> SOC: AST2700-A0
>>>> Model: AST2700 EVB
>>>> DRAM: 8 GiB (effective 0 Bytes)
>>>>
>>>> QEMU hangs.
>>>>
>>>> If the RAM size is defined to 8g
>>>>
>>>> $ qemu-system-aarch64 -machine ast2700a0-evb -m 8g ...
>>>> ...
>>>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>>>
>>>> SOC: AST2700-A0
>>>> Model: AST2700 EVB
>>>> DRAM: 8 GiB
>>>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>>>> version(0)
>>>> Core: 125 devices, 27 uclasses, devicetree: separate
>>>>
>>>> machine boots.
>>>>
>>>> Whereas, with an ast2700a1-evb machine :
>>>>
>>>> $ qemu-system-aarch64 -machine ast2700a1-evb ...
>>>> ...
>>>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>>>
>>>> SOC: AST2700-A1
>>>> Model: AST2700 EVB
>>>> DRAM: 1 GiB
>>>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>>>> version(0)
>>>> Core: 125 devices, 27 uclasses, devicetree: separate
>>>>
>>>> machine boots.
>>>>
>>>> $ qemu-system-aarch64 -machine ast2700a1-evb -m 8g ...
>>>> ...
>>>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>>>
>>>> SOC: AST2700-A1
>>>> Model: AST2700 EVB
>>>> DRAM: 8 GiB
>>>> aspeed_dp dp@12c0a000: aspeed_dp_probe(): Failed to access dp.
>>>> version(0)
>>>> Core: 125 devices, 27 uclasses, devicetree: separate
>>>>
>>>> machine boots.
>>>>
>>>>
>>>> I Wonder if you could analyze this issue to check if it is related to
>>>> one of our QEMU model.
>>>>
>>>>
>>>
>>> Sorry, I only have a little-endian host machine (x86_64).
>>> Is it possible to run a big-endian(POWER PC) QEMU host environment on this
>> machine, so that I can then run the AST2700 QEMU target inside it to analyze
>> this issue?
>>
>> You can but unless you have access to a POWER hypervisor, this will be very
>> slow because of the 2 levels of emulations.
>>
>>> If you agree, could you please help me insert the following lines into the
>> function that detects the DRAM size on the AST2700?
>>>
>> https://github.com/qemu/qemu/blob/master/hw/arm/aspeed_ast27x0.c#L332
>>>
>> https://github.com/qemu/qemu/commit/7436db1063bbfecc2e498a7d795613b
>> 333
>>> 12d665
>>> ````
>>> static void aspeed_ram_capacity_write(void *opaque, hwaddr addr, uint64_t
>> data,
>>> unsigned int
>> size) {
>>> AspeedSoCState *s = ASPEED_SOC(opaque);
>>> ram_addr_t ram_size;
>>> MemTxResult result;
>>> uint32_t read_back[4] = {0};
>>> ram_size = object_property_get_uint(OBJECT(&s->sdmc), "ram-size",
>>> &error_abort);
>>>
>>> assert(ram_size > 0);
>>> printf("jamin size %d\n", size);
>>> printf("addr=%" PRIx64 " (addr ram_size)=%" PRIx64 "\n", addr, (addr
>> % ram_size));
>>> /*
>>> * Emulate ddr capacity hardware behavior.
>>> * If writes the data to the address which is beyond the ram size,
>>> * it would write the data to the "address % ram_size".
>>> */
>>> result = address_space_write(&s->dram_as, addr % ram_size,
>>> MEMTXATTRS_UNSPECIFIED,
>> &data, size);
>>> if (result != MEMTX_OK) {
>>> qemu_log_mask(LOG_GUEST_ERROR,
>>> "%s: DRAM write failed, addr:0x%"
>> HWADDR_PRIx
>>> ", data :0x%" PRIx64 "\n",
>>> __func__, addr % ram_size, data);
>>> }
>>>
>>> address_space_read(&s->dram_as, addr % ram_size,
>>> MEMTXATTRS_UNSPECIFIED, read_back,
>>> size);
>>>
>>> for(int i=0; i<4; i++) {
>>> printf("jamin read_back[%d]=%x\n", i, read_back[i]);
>>> }
>>> }
>>> ````
>>> Also, could you please provide me with the following log?
>>>
>>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>>
>>> SOC: AST2700-A0
>>> Model: AST2700 EVB
>>> DRAM: jamin size 4
>>> addr=c0000000 (addr ram_size)=0
>>> jamin read_back[0]=eadbeef4
>>> jamin read_back[1]=0
>>> jamin read_back[2]=0
>>> jamin read_back[3]=0
>>> jamin size 4
>>> addr=40000000 (addr ram_size)=0
>>> jamin read_back[0]=adbeef43
>>> jamin read_back[1]=0
>>> jamin read_back[2]=0
>>> jamin read_back[3]=0
>>> jamin size 4
>>> addr=0 (addr ram_size)=0
>>> jamin read_back[0]=dbeef432
>>> jamin read_back[1]=0
>>> jamin read_back[2]=0
>>> jamin read_back[3]=0
>>> 1 GiB
>>
>>
>>
>> U-Boot 2023.10-v00.05.06 (Mar 26 2025 - 05:59:26 +0000)
>>
>> SOC: AST2700-A0
>> Model: AST2700 EVB
>> DRAM: aspeed_sdmc_read reg @0x4 data: 0x28 aspeed_sdmc_read reg
>> @0x4 data: 0x28 aspeed_sdmc_write reg @0x4 data: 0x34 jamin size 4
>> addr=c0000000 (addr ram_size)=0
>> jamin read_back[0]=0 <-- this is wrong
>
>
> It seems that the "data" is in the CPU 's native endianness.
> I'm currently looking for a big-endian environment to test the changes I made, and will update you once I have results.
>
> uint32_t val = cpu_to_le32((uint32_t)data);
> address_space_write(&s->dram_as, addr % ram_size,
> MEMTXATTRS_UNSPECIFIED, &val, 4);
FYI, I opened
https://gitlab.com/qemu-project/qemu/-/issues/2973
Thanks,
C.
>
>> jamin read_back[1]=0
>> jamin read_back[2]=0
>> jamin read_back[3]=0
>> aspeed_sdmc_read reg @0x4 data: 0x3c
>> aspeed_sdmc_write reg @0x4 data: 0x34
>> aspeed_sdmc_read reg @0xc data: 0x0
>> aspeed_sdmc_write reg @0xc data: 0x1b8
>> aspeed_sdmc_read reg @0x40 data: 0x0
>> jamin size 4
>> addr=1bdea1f70 (addr ram_size)=3dea1f70
>> jamin read_back[0]=0
>> jamin read_back[1]=0
>> jamin read_back[2]=0
>> jamin read_back[3]=0
>> jamin size 4
>> addr=1bdea1f74 (addr ram_size)=3dea1f74
>> jamin read_back[0]=0
>> jamin read_back[1]=0
>> jamin read_back[2]=0
>> jamin read_back[3]=0
>> jamin size 4
>>
>>
>>>
>>> It's quite strange, because you mentioned that the A1 version works, but the
>> A0 version doesn't.
>>> It seems detect the DRAM size failed in this loop,
>>>
>> https://github.com/AspeedTech-BMC/u-boot/blob/aspeed-master-v2023.10/d
>>> rivers/ram/aspeed/sdram_ast2700.c#L1173
>>> struct ddr_capacity ram_size[] = {
>>> {0x10000000, {208, 256}}, // 256MB
>>> {0x20000000, {208, 416}}, // 512MB
>>> {0x40000000, {208, 560}}, // 1GB
>>> {0x80000000, {472, 880}}, // 2GB
>>> {0x100000000, {656, 880}}, // 4GB
>>> {0x200000000, {880, 880}}, // 8GB
>>> };
>>> u32 test_pattern = 0xdeadbeef
>>>
>>> for (sz = SDRAM_SIZE_8GB - 1; sz > SDRAM_SIZE_256MB; sz--) {
>>> test_pattern = (test_pattern << 4) + sz;
>>> writel(test_pattern, (void *)CFG_SYS_SDRAM_BASE +
>>> ram_size[sz].size);
>>>
>>> if (readl((void *)CFG_SYS_SDRAM_BASE) != test_pattern)
>>> break;
>>> }
>>>
>>> Please help to dump this register.
>>> => md 12c00010
>>> 12c00010: 00000028 00000000 00000000 00000000 (...............
>>
>> I can't do that because the u-boot prompt is never reached. From QEMU:
>>
>> (qemu) x/10x 0x12c00010
>> 0000000012c00010: 0x0000003c 0x00000000 0x00000000 0x00000000
>> 0000000012c00020: 0x00000000 0x00000000 0x00000000 0x00000000
>> 0000000012c00030: 0x000001b8 0x00000000
>>
>> Hope it helps
>>
>> C.
>>
>
© 2016 - 2026 Red Hat, Inc.