[U-Boot] [RFC PATCH] ARM: Activate hypervisor mode for TI am5726 (OMAP5/dra7)
Hi, I was wondering if I could have any input on the patch below activating hypervisor mode on TI OMAP5-based SoC. The patch essentially uses the on-chip ROM code API to enable hypervisor mode on the primary A15 core and goes in tandem with a Linux kernel patch recently accepted into omap-for-v3.19/fixes that checks hypervisor mode on the primary A15 core and sets it accordingly on additional cores being activated. I am aware that there is some development going on for ARM's PSCI that amongst other things is supposed to deal with hypervisor activation in a more generic fashion and I am wondering if there is any preference on how to properly activate hypervisor mode for the TI SoCs mentioned above. Thanks, Frank --- u-boot patch: Enable hypervisor mode for AM5726 --- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index 86c0e42..696da4b 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -19,7 +19,20 @@ ENTRY(save_boot_params) ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS str r0, [r1] +/* + * Turn on hypervisor mode on CPU#0 + */ +#ifdef CONFIG_DRA7XX_HYPERVISOR_ON + mov r0, lr @ This is a great place to switch into hyp mode + @ only the r0 was needed from _start and is now + @ free; all other general purpose registers were + @ already free. + ldr r12, =0x102 @ Set PL310 control register - value in R0 + .word 0xe1600070 @ SMC #0 - hand assembled because -march=armv5 + @ call ROM Code API to set control register +#else bx lr +#endif /* CONFIG_DRA7XX_HYPERVISOR_ON */ ENDPROC(save_boot_params) ENTRY(set_pl310_ctrl_reg) --- Link to the corresponding Linux kernel patch: http://linux-kernel.2935.n7.nabble.com/PATCH-ARM-omap5-dra7xx-Enable-booting-secondary-CPU-in-HYP-mode-td1009407.html#a1014616 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] Read mmc device memory capacity from EXT_CSD if memory is addressed by sector
Hi Pantos, hi Tom,
I sent this a couple of months ago to the mailing list, never really received a
response. We are testing 2014.04-rc3 right now and the issue is still there.
Would you still consider bringing this fix in for the upcoming release?
This is for an eMMC chip with an initial memory size 2GB whose memory size
drops below 2GB when turning enhanced (pseudo-SLC) mode on for the user
partition. u-boot would then fail memory size detection and assume memory size
if zero. You'd see error messages like:
MMC: block number 0x1 exceeds max(0x0)
MMC: block number 0x800 exceeds max(0x0)
MMC: block number 0x900 exceeds max(0x0)
Thanks,
Frank
On 05/02/14 03:00 PM, Frank Bormann wrote:
Hello Everyone,
I believe, there is a bug in the mmc driver code pertaining to how u-boot
detects memory size of an mmc device. However, I am not 100% sure, my solution
conforms to the JEDEC standard. So I am putting it up for discussion.
Previously, sector count indicated by mmc devices in the EXT_CSD
would only be used in u-boot if the size indicated is greater than
2 GB. This seems to be incorrect. I am working with a 4 GB Micron
eMMC device that after partition configuration and setting the
user data area to enhanced mode has a remaining capacity of less
than 2 GB for the user data area. JESD84-B50 explicitly states in
6.2.4 that for these devices SEC_CNT from the EXT_CSD is still
valid even if the memory size for that device has dropped below
2 GB by the partition configuration applied. The access mode bits
from the OCR register seem to provide a better way to decide
whether to use the CSD-based C_SIZE C_MULT or the EXT_CSD-based
SEC_CNT information when determining the device's capacity.
In particular, this fixes a bug where u-boot SPL would assign 0 to
mmc-block_dev.lba later on in the mmc_startup() function and
subsequently fail to load u-boot from that mmc due to the original
C_SIZE C_MULT code assigning a 4 TB size to mmc-capacity, that
incorrect capacity never being overwritten by the SEC_CNT capacity
calculation (due to its size being less than 2 GB) and then finally
lldiv(mmc-capacity, mmc-read_bl_len) exceeding the 32-bit result
data type of mmc-block_dev.lba.
Signed-off-by: Frank Bormann fborm...@yahoo.com
---
drivers/mmc/mmc.c | 10 +-
include/mmc.h |1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c6a1c23..c5d1efc 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -935,19 +935,19 @@ static int mmc_startup(struct mmc *mmc)
if (!IS_SD(mmc) (mmc-version = MMC_VERSION_4)) {
/* check ext_csd version and capacity */
err = mmc_send_ext_csd(mmc, ext_csd);
- if (!err (ext_csd[EXT_CSD_REV] = 2)) {
+ if (!err (ext_csd[EXT_CSD_REV] = 2)
+ (mmc-ocr OCR_ACCESS_MODE) == OCR_ACCESS_BY_SECTOR) {
/*
* According to the JEDEC Standard, the value of
-* ext_csd's capacity is valid if the value is more
-* than 2GB
+* ext_csd's capacity is valid if the device addresses
+* its memory by sector
*/
capacity = ext_csd[EXT_CSD_SEC_CNT] 0
| ext_csd[EXT_CSD_SEC_CNT + 1] 8
| ext_csd[EXT_CSD_SEC_CNT + 2] 16
| ext_csd[EXT_CSD_SEC_CNT + 3] 24;
capacity *= MMC_MAX_BLOCK_LEN;
- if ((capacity 20) 2 * 1024)
- mmc-capacity_user = capacity;
+ mmc-capacity_user = capacity;
}
switch (ext_csd[EXT_CSD_REV]) {
diff --git a/include/mmc.h b/include/mmc.h
index e1060b9..816b580 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -104,6 +104,7 @@
#define OCR_HCS0x4000
#define OCR_VOLTAGE_MASK 0x007FFF80
#define OCR_ACCESS_MODE0x6000
+#define OCR_ACCESS_BY_SECTOR (1 30)
#define SECURE_ERASE 0x8000
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/1] Read mmc device memory capacity from EXT_CSD if memory is addressed by sector
Hello Everyone,
I believe, there is a bug in the mmc driver code pertaining to how u-boot
detects memory size of an mmc device. However, I am not 100% sure, my solution
conforms to the JEDEC standard. So I am putting it up for discussion.
Previously, sector count indicated by mmc devices in the EXT_CSD
would only be used in u-boot if the size indicated is greater than
2 GB. This seems to be incorrect. I am working with a 4 GB Micron
eMMC device that after partition configuration and setting the
user data area to enhanced mode has a remaining capacity of less
than 2 GB for the user data area. JESD84-B50 explicitly states in
6.2.4 that for these devices SEC_CNT from the EXT_CSD is still
valid even if the memory size for that device has dropped below
2 GB by the partition configuration applied. The access mode bits
from the OCR register seem to provide a better way to decide
whether to use the CSD-based C_SIZE C_MULT or the EXT_CSD-based
SEC_CNT information when determining the device's capacity.
In particular, this fixes a bug where u-boot SPL would assign 0 to
mmc-block_dev.lba later on in the mmc_startup() function and
subsequently fail to load u-boot from that mmc due to the original
C_SIZE C_MULT code assigning a 4 TB size to mmc-capacity, that
incorrect capacity never being overwritten by the SEC_CNT capacity
calculation (due to its size being less than 2 GB) and then finally
lldiv(mmc-capacity, mmc-read_bl_len) exceeding the 32-bit result
data type of mmc-block_dev.lba.
Signed-off-by: Frank Bormann fborm...@yahoo.com
---
drivers/mmc/mmc.c | 10 +-
include/mmc.h |1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c6a1c23..c5d1efc 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -935,19 +935,19 @@ static int mmc_startup(struct mmc *mmc)
if (!IS_SD(mmc) (mmc-version = MMC_VERSION_4)) {
/* check ext_csd version and capacity */
err = mmc_send_ext_csd(mmc, ext_csd);
- if (!err (ext_csd[EXT_CSD_REV] = 2)) {
+ if (!err (ext_csd[EXT_CSD_REV] = 2)
+ (mmc-ocr OCR_ACCESS_MODE) == OCR_ACCESS_BY_SECTOR) {
/*
* According to the JEDEC Standard, the value of
-* ext_csd's capacity is valid if the value is more
-* than 2GB
+* ext_csd's capacity is valid if the device addresses
+* its memory by sector
*/
capacity = ext_csd[EXT_CSD_SEC_CNT] 0
| ext_csd[EXT_CSD_SEC_CNT + 1] 8
| ext_csd[EXT_CSD_SEC_CNT + 2] 16
| ext_csd[EXT_CSD_SEC_CNT + 3] 24;
capacity *= MMC_MAX_BLOCK_LEN;
- if ((capacity 20) 2 * 1024)
- mmc-capacity_user = capacity;
+ mmc-capacity_user = capacity;
}
switch (ext_csd[EXT_CSD_REV]) {
diff --git a/include/mmc.h b/include/mmc.h
index e1060b9..816b580 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -104,6 +104,7 @@
#define OCR_HCS0x4000
#define OCR_VOLTAGE_MASK 0x007FFF80
#define OCR_ACCESS_MODE0x6000
+#define OCR_ACCESS_BY_SECTOR (1 30)
#define SECURE_ERASE 0x8000
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] File system API: Read file size without reading file contents
Hi All, I would like to read a configuration file from an ext4 disk partition in u-boot and parse its contents. In order to malloc a buffer of sufficient size to read the entire file contents, I would need to know the file size before actually reading it. As far as I understand, the current struct fstype_info API does not allow me to do that (other than parsing the ls output). While the read function does in fact return the file size, it does so only after the file was already read into memory. Lower level functions for ext4 such as ext4fs_open() do however provide this information before reading the file contents. Unless there is something that I have missed, how would you feel about me adding a .size function to the struct fstype_info API to expose this information on the top-level API? Thanks, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
