This is a huge stack- why do we need this much, and why only for the RT1060 EVKC? Do we enable SDIO on this platform, and is that ballooning the stack size required?

Emphasis on huge...

I tried with 10240/20480, which does not work, maybe this can be small, but as my test SD card is 4G(it is very hard to find a smaller one nowadays), this could be challenging. and 40K stack is not a big deal for mimxrt1060C, though.

I think it is worth investigating why the stack is overflowing here- do you have a backtrace for this that might highlight the issue?

sure, Let me enable the trace and check, will feedback soon

@danieldegrasse @dleach02 , Thanks a lot for checking, I find I make a mistake in change the stack size, I need rebuild not just flash, so now the main_stack size can be reduce to 2048 for my 4G card. and according to the trace log, the issue is here:

test_stetup - > sd_init -> sd_common_init, and there is a retry in this see below code snipple, the sd_common_init is repeatly called for card to get idle. this may cause the stack overflow. maybe we can recommend to refine the code here.

static int sd_common_init(struct sd_card *card)
{
	int ret;

	/* Perform voltage check using SD CMD8 */
	ret = sd_retry(sd_send_interface_condition, card, CONFIG_SD_RETRY_COUNT);
	if (ret == -ETIMEDOUT) {
		LOG_INF("Card does not support CMD8, assuming legacy card");
		return sd_idle(card);
	} else if (ret) {
		LOG_ERR("Card error on CMD 8");
		return ret;
	}
	if (card->host_props.is_spi &&
		IS_ENABLED(CONFIG_SDHC_SUPPORTS_SPI_MODE)) {
		/* Enable CRC for spi commands using CMD59 */
		ret = sd_enable_crc(card);
	}
	return ret;
}

Ok, 2048 is fine- I've seen this before on some platforms. The stack usage for the SDMMC framework is unfortunately just kind of high :/

given that rev C is the default, I'm not sure we have to explicitly call it out here because twister will generate an alias list of [mimxrt1060_evk/mimxrt1062/qspi, mimxrt1060_evk@C/mimxrt1062/qspi]

@dleach02, I would prefer to have a clear one, as I have multiply boards, which would be very confuse to configure them in board farm

fair enough. I actually wasn't sure how best to do this as there are a bunch of testcase/sample yaml files that I touched.

CI will tracking these, to make sure all items within test plan, will be maintained.

did this test case work with rt1060 before adding revC?

No, such case is filter out before. and then marked as no run, but actually it is stack overflow, which twister set this to not runnable