On 10/22/24 03:38, Jamin Lin wrote:
Hi Cedric,
Subject: Re: [SPAM] [PATCH v1 09/16] test/qtest/aspeed_smc-test: Introduce a
new TestData to test different BMC SOCs
On 10/18/24 07:31, Jamin Lin wrote:
Currently, these test cases are only used for testing fmc_cs0 for AST2400.
To test others BMC SOCs, introduces a new TestData structure.
Users can set the spi base address, flash base address, jedesc id and
so on for different BMC SOCs and flash model testing.
Introduce new helper functions to make the test case more readable.
Set spi base address 0x1E620000, flash_base address 0x20000000 and
jedec id 0x20ba19 for fmc_cs0 with n25q256a flash for AST2400 SMC
model testing.
To pass the TestData into the test case, replace qtest_add_func with
qtest_add_data_func.
Signed-off-by: Jamin Lin <jamin_...@aspeedtech.com>
---
tests/qtest/aspeed_smc-test.c | 546 +++++++++++++++++++---------------
1 file changed, 299 insertions(+), 247 deletions(-)
- fd = g_file_open_tmp("qtest.m25p80.XXXXXX", &tmp_path, NULL);
+ fd = g_file_open_tmp("qtest.m25p80.n25q256a.XXXXXX",
+ &data->tmp_path, NULL);
Why did you change the name ?
The default flash size of fmc_cs0 are difference between ASPEED SOCs.
For example: AST2400 default flash size of fmc_cs0 is 32MB but
AST1030 default flash size of fmc_cs0 is 1MB.
Besides, the testcases support to test jedec_id of flash.
We set the different default flash model of fmc_cs0 for all ASPEED SOCs
Ex:
n25q256a jedec_id is 0x20ba19.
w25q80bl jedec_id is 0xef4014.
That was why I added the name of flash model in the filename of testing image.
So, users easily know the testcases testing which flash model.
By the way, I set the different filename of testing image for AST1030, AST2500,
AST2600 and AST2700.
AST2500: "qtest.m25p80.mx25l25635e.XXXXXX"
AST2600: "qtest.m25p80.mx66u51235f.XXXXXX"
AST1030: “qtest.m25p80.w25q80bl.XXXXXX"
AST2700: “"qtest.m25p80.w25q01jvq.XXXXXX"”
I am okay to set the filename of testing image back to "qtest.m25p80.XXXXXX"
for AST2400.
No. Keep it as it is. I was wondering if this was some kind of work around.
LGTM,
Reviewed-by: Cédric Le Goater <c...@redhat.com>
Thanks,
C.
