* Synchronize the code of the rt mart branch to the master branch.
* TTY device
* Add lwP code from rt-smart
* Add vnode in DFS, but DFS will be re-write for rt-smart
* There are three libcpu for rt-smart:
* arm/cortex-a, arm/aarch64
* riscv64
Co-authored-by: Rbb666 <zhangbingru@rt-thread.com>
Co-authored-by: zhkag <zhkag@foxmail.com>
Try a few times before switching to other data widths.
The original strategy (simply wait for 20ms ) failed on STM32H743 with an MTFC4GACAJCN-4M (4GB EMMC) when switching data width.
(unless the debugging info is enabled, which add more delays)
With this EMMC, the fixed delay was set to 50ms for it to be able to work.
Instead of a fixed delay, I think we better change to trying a few more times with smaller delays.
Currently RTT mmc stack only support Highspeed mode or
blow, which means the max speed should be 52MHz according
to JEDEC spec. Two problems show here:
(1) max_data_rate = (unsigned int)-1. The value of unsigned int
depends on compilers/arch. Moreover, it makes no sense to assume
cpu addressing width with IP clock rate limit.
(1)hs_max_data_rate was set to 200MHz.
So what should BSP drivers do if 52MHz < max_data_rate < 200MHz?
Either it blindly sets a spec-violated clock rate to drive a Highspeed
card, or just adjust the clock rate internally. Both cases are
really bad for practice.
If the card claims to support Highspeed, we set the clock to not
to exceed 52MHz. Otherwise it should be set according to
card->max_data_rate parsed by ext_csd. This patch fixes it as-is,
and also simplify the code a lot.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
It makes no sense to try bus width if not supported by drivers or BSP,
since we know it must be failed. It saves a lot for booting in time
critical environment.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
修改“mmc_parse_ext_csd”函数,防止容量计算过程溢出。
Modify the "mmc_parse_ext_csd" function to prevent the capacity
calculation process from overflowing.
Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com>