Re: [PULL 45/46] tests/functional/aspeed: Add test case for AST2700 A1

["Cédric Le Goater" <clg@redhat.com>]

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.
>>
>