[PATCH 0/4] board: starfive: add Milk-V Mars CM support
With this series the Milk-V Mars CM board can be booted.
NVMe, SD-card, Ethernet, UART are working but not USB.
The first series Milk-V Mars CM Lite board (the version without eMMC) uses incorrect series numbers indicating eMMC presence. For these CONFIG_STARFIVE_NO_EMMC=y must be set to indicate that eMMC is not present.
Thanks to E. Shattow for all the helpful discussions. He figured out what needed to be patched in the device-tree.
Heinrich Schuchardt (4): board: starfive: function to read eMMC size board: add support for MARS CM SD doc: Milk-V Mars CM and Milk-V Mars CM Lite configs: visionfive2: enable SPL_YMODEM_SUPPORT
arch/riscv/include/asm/arch-jh7110/eeprom.h | 7 + board/starfive/visionfive2/Kconfig | 9 ++ board/starfive/visionfive2/spl.c | 27 +++- .../visionfive2/starfive_visionfive2.c | 11 +- .../visionfive2/visionfive2-i2c-eeprom.c | 18 +++ configs/starfive_visionfive2_defconfig | 1 + doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars_cm.rst | 125 ++++++++++++++++++ 8 files changed, 197 insertions(+), 2 deletions(-) create mode 100644 doc/board/starfive/milk-v_mars_cm.rst
The EEPROM provides information about the size of the EEPROM. Provide a new function get_mmc_size_from_eeprom() to read it.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- arch/riscv/include/asm/arch-jh7110/eeprom.h | 7 +++++++ board/starfive/visionfive2/Kconfig | 9 +++++++++ .../visionfive2/visionfive2-i2c-eeprom.c | 18 ++++++++++++++++++ 3 files changed, 34 insertions(+)
diff --git a/arch/riscv/include/asm/arch-jh7110/eeprom.h b/arch/riscv/include/asm/arch-jh7110/eeprom.h index 62d184aeb57..17395d4269e 100644 --- a/arch/riscv/include/asm/arch-jh7110/eeprom.h +++ b/arch/riscv/include/asm/arch-jh7110/eeprom.h @@ -12,6 +12,13 @@ u8 get_pcb_revision_from_eeprom(void); u32 get_ddr_size_from_eeprom(void);
+/** + * get_mmc_size_from_eeprom() - read MMC size form EEPROM + * + * @return: size in GiB or 0 on error. + */ +u32 get_mmc_size_from_eeprom(void); + /** * get_product_id_from_eeprom - get product ID string * diff --git a/board/starfive/visionfive2/Kconfig b/board/starfive/visionfive2/Kconfig index 2186a939646..d7e8a7a7d78 100644 --- a/board/starfive/visionfive2/Kconfig +++ b/board/starfive/visionfive2/Kconfig @@ -50,4 +50,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply PHY_LIB imply PHY_MSCC
+config STARFIVE_NO_EMMC + bool "Report eMMC size as zero" + help + The serial number string in the EEPROM is meant to report the + size of onboard eMMC. Unfortunately some Milk-V Mars CM Lite + modules without eMMC show a non-zero size here. + + Set to 'Y' if you have a Mars CM Lite module. + endif diff --git a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c index ddef7d61235..cd3d8bd51a6 100644 --- a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c +++ b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c @@ -548,6 +548,24 @@ u32 get_ddr_size_from_eeprom(void) return hextoul(&pbuf.eeprom.atom1.data.pstr[14], NULL); }
+u32 get_mmc_size_from_eeprom(void) +{ + u32 size; + + if (IS_ENABLED(CONFIG_STARFIVE_NO_EMMC)) + return 0; + + if (read_eeprom()) + return 0; + + size = dectoul(&pbuf.eeprom.atom1.data.pstr[19], NULL); + + if (pbuf.eeprom.atom1.data.pstr[21] == 'T') + size <<= 10; + + return size; +} + U_BOOT_LONGHELP(mac, "\n" " - display EEPROM content\n"
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
The EEPROM provides information about the size of the EEPROM.
"The EEPROM provides information about the size of the eMMC."
Provide a new function get_mmc_size_from_eeprom() to read it.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
arch/riscv/include/asm/arch-jh7110/eeprom.h | 7 +++++++ board/starfive/visionfive2/Kconfig | 9 +++++++++ .../visionfive2/visionfive2-i2c-eeprom.c | 18 ++++++++++++++++++ 3 files changed, 34 insertions(+)
diff --git a/arch/riscv/include/asm/arch-jh7110/eeprom.h b/arch/riscv/include/asm/arch-jh7110/eeprom.h index 62d184aeb57..17395d4269e 100644 --- a/arch/riscv/include/asm/arch-jh7110/eeprom.h +++ b/arch/riscv/include/asm/arch-jh7110/eeprom.h @@ -12,6 +12,13 @@ u8 get_pcb_revision_from_eeprom(void); u32 get_ddr_size_from_eeprom(void);
+/**
- get_mmc_size_from_eeprom() - read MMC size form EEPROM
- @return: size in GiB or 0 on error.
- */
+u32 get_mmc_size_from_eeprom(void);
/**
- get_product_id_from_eeprom - get product ID string
diff --git a/board/starfive/visionfive2/Kconfig b/board/starfive/visionfive2/Kconfig index 2186a939646..d7e8a7a7d78 100644 --- a/board/starfive/visionfive2/Kconfig +++ b/board/starfive/visionfive2/Kconfig @@ -50,4 +50,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply PHY_LIB imply PHY_MSCC
+config STARFIVE_NO_EMMC
bool "Report eMMC size as zero"helpThe serial number string in the EEPROM is meant to report thesize of onboard eMMC. Unfortunately some Milk-V Mars CM Litemodules without eMMC show a non-zero size here.Set to 'Y' if you have a Mars CM Lite module.endif diff --git a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c index ddef7d61235..cd3d8bd51a6 100644 --- a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c +++ b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c @@ -548,6 +548,24 @@ u32 get_ddr_size_from_eeprom(void) return hextoul(&pbuf.eeprom.atom1.data.pstr[14], NULL); }
+u32 get_mmc_size_from_eeprom(void) +{
u32 size;if (IS_ENABLED(CONFIG_STARFIVE_NO_EMMC))return 0;if (read_eeprom())return 0;size = dectoul(&pbuf.eeprom.atom1.data.pstr[19], NULL);if (pbuf.eeprom.atom1.data.pstr[21] == 'T')size <<= 10;return size;+}
U_BOOT_LONGHELP(mac, "\n" " - display EEPROM content\n" -- 2.43.0
Fixed-position parsing on a data format of ordered variable length hyphen-delimited fields. Notable is that some Pine64 Star64 and Milk-V Mars CM Lite boards shipped with uninitialized or wrong EEPROM data; further the EEPROM Write Protect can be trivially disabled and arbitrary data written i.e. with a paperclip then `mac` command. Could this code be generalized to split fields on hyphen character better expressing the expected data format or is that unwanted complexity and code size?
On 4/16/24 06:09, E Shattow wrote:
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
The EEPROM provides information about the size of the EEPROM.
"The EEPROM provides information about the size of the eMMC."
Thanks for catching this.
Provide a new function get_mmc_size_from_eeprom() to read it.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
arch/riscv/include/asm/arch-jh7110/eeprom.h | 7 +++++++ board/starfive/visionfive2/Kconfig | 9 +++++++++ .../visionfive2/visionfive2-i2c-eeprom.c | 18 ++++++++++++++++++ 3 files changed, 34 insertions(+)
diff --git a/arch/riscv/include/asm/arch-jh7110/eeprom.h b/arch/riscv/include/asm/arch-jh7110/eeprom.h index 62d184aeb57..17395d4269e 100644 --- a/arch/riscv/include/asm/arch-jh7110/eeprom.h +++ b/arch/riscv/include/asm/arch-jh7110/eeprom.h @@ -12,6 +12,13 @@ u8 get_pcb_revision_from_eeprom(void); u32 get_ddr_size_from_eeprom(void);
+/**
- get_mmc_size_from_eeprom() - read MMC size form EEPROM
- @return: size in GiB or 0 on error.
- */
+u32 get_mmc_size_from_eeprom(void);
- /**
- get_product_id_from_eeprom - get product ID string
diff --git a/board/starfive/visionfive2/Kconfig b/board/starfive/visionfive2/Kconfig index 2186a939646..d7e8a7a7d78 100644 --- a/board/starfive/visionfive2/Kconfig +++ b/board/starfive/visionfive2/Kconfig @@ -50,4 +50,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply PHY_LIB imply PHY_MSCC
+config STARFIVE_NO_EMMC
bool "Report eMMC size as zero"helpThe serial number string in the EEPROM is meant to report thesize of onboard eMMC. Unfortunately some Milk-V Mars CM Litemodules without eMMC show a non-zero size here.Set to 'Y' if you have a Mars CM Lite module.- endif
diff --git a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c index ddef7d61235..cd3d8bd51a6 100644 --- a/board/starfive/visionfive2/visionfive2-i2c-eeprom.c +++ b/board/starfive/visionfive2/visionfive2-i2c-eeprom.c @@ -548,6 +548,24 @@ u32 get_ddr_size_from_eeprom(void) return hextoul(&pbuf.eeprom.atom1.data.pstr[14], NULL); }
+u32 get_mmc_size_from_eeprom(void) +{
u32 size;if (IS_ENABLED(CONFIG_STARFIVE_NO_EMMC))return 0;if (read_eeprom())return 0;size = dectoul(&pbuf.eeprom.atom1.data.pstr[19], NULL);if (pbuf.eeprom.atom1.data.pstr[21] == 'T')size <<= 10;return size;+}
- U_BOOT_LONGHELP(mac, "\n" " - display EEPROM content\n"
-- 2.43.0
Fixed-position parsing on a data format of ordered variable length hyphen-delimited fields. Notable is that some Pine64 Star64 and Milk-V Mars CM Lite boards shipped with uninitialized or wrong EEPROM data; further the EEPROM Write Protect can be trivially disabled and arbitrary data written i.e. with a paperclip then `mac` command. Could this code be generalized to split fields on hyphen character better expressing the expected data format or is that unwanted complexity and code size?
The boards that I have seen up to now are consistent in the string layout of the boards that I have received up to now:
VisionFive 2 1.2B VF7110A1-2239-D004E000-xxxxxxxx VisionFive 2 1.3B VF7110B1-2253-D004E000-xxxxxxxx VisionFive 2 1.3B VF7110B1-2253-D008E000-xxxxxxxx Pine64 Pinetab V VF7110B1-2230-D008E000-xxxxxxxx Pine64 Star64 v1 STAR64V1-2310-D008E000-xxxxxxxx Milk-V Mars MARS-V11-2340-D008E000-xxxxxxxx Milk-V Mars CM Lite MARC-V10-2340-D002E016-xxxxxxxx
The example of the Pinetab V and of the first batch of the Milk V CM Lite shows that the trustworthiness of the EEPROM data is limited.
As you mentioned such deviations can be fixed by rewriting the EEPROM. I don't think that this is problematic for the parsing of the string. It might be an issue for warranty claims.
Retrieving the RAM size already relies on positional data. The eMMC size is just a sub-field of what is read in get_ddr_size_from_eeprom().
Changes would have to start there if wanted by the StarFive maintainer.
Best regards
Heinrich
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{ + const char *compat; + const char *model; + + spl_fdt_fixup_mars(fdt); + + if (!get_mmc_size_from_eeprom()) { + int offset; + + model = "Milk-V Mars CM SDCard"; + compat = "milkv,mars-cm-sdcard\0starfive,jh7110"; + + offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest"); + fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016); + } else { + model = "Milk-V Mars CM eMMC"; + compat = "milkv,mars-cm-emmc\0starfive,jh7110"; + } + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat)); + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model); +} + void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; } - if (!strncmp(product_id, "MARS", 4)) { + if (!strncmp(product_id, "MARC", 4)) { + spl_fdt_fixup_marc(spl_image->fdt_addr); + } else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom(); diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \ + "starfive/jh7110-milkv-mars-cm-sdcard.dtb" +#define FDTFILE_MILK_V_MARC_MMC \ + "starfive/jh7110-milkv-mars-cm-emmc.dtb" #define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; } - if (!strncmp(product_id, "MARS", 4)) { + if (!strncmp(product_id, "MARC", 4)) { + if (get_mmc_size_from_eeprom()) + fdtfile = FDTFILE_MILK_V_MARC_MMC; + else + fdtfile = FDTFILE_MILK_V_MARC_SD; + } else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";compat = "milkv,mars-cm-sdcard\0starfive,jh7110";offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);
Note this is:
- pinmux = <GPIOMUX(62, GPOUT_SYS_SDIO0_RST, + pinmux = <GPIOMUX(22, GPOUT_SYS_SDIO0_RST,
As in the vendor code repo for Mars CM Lite branch:
https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e29...
But the GPIOMUX macro here (for code readability) would bring in another header to include. Add a comment of what the magic number is for.
Does anyone have a better explanation of why this is needed than the vendor "u-boot: configure sdio0 as mars-cm sdcard version" commit message?
} else {model = "Milk-V Mars CM eMMC";compat = "milkv,mars-cm-emmc\0starfive,jh7110";}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);+}
void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb"+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb"#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite" and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
[1]: https://milkv.io/docs/mars/compute-module/introduction#design-philosophy
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
- const char *compat;
- const char *model;
- spl_fdt_fixup_mars(fdt);
- if (!get_mmc_size_from_eeprom()) {
int offset;model = "Milk-V Mars CM SDCard";
"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";
"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);- } else {
model = "Milk-V Mars CM eMMC";
"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";
"milkv,mars-cm\0starfive,jh7110"
- }
- fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));
- fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);
+}
void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
- if (!strncmp(product_id, "MARS", 4)) {
- if (!strncmp(product_id, "MARC", 4)) {
spl_fdt_fixup_marc(spl_image->fdt_addr);- } else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
- "starfive/jh7110-milkv-mars-cm-sdcard.dtb"
"starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
- "starfive/jh7110-milkv-mars-cm-emmc.dtb"
"starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
- if (!strncmp(product_id, "MARS", 4)) {
- if (!strncmp(product_id, "MARC", 4)) {
if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;- } else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();
-- 2.43.0
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing emil.renner.berthing@canonical.com wrote:
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite" and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
Are there any actual differences that need representation in the dtb file for downstream OS different from Milk-V Mars to Milk-V Mars CM (or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for SDCard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea06598995db99ddb... but it does not seem necessary in mainline Linux, SD Card is working without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as mars-cm sdcard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e29...
Then also there is some mention about PMIC and renamed i2c reference, already obsolete. That's all, is there more to it? Possibly a dtb for Mars is enough to also be used on Mars CM and Mars Lite?
-E
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);} else {model = "Milk-V Mars CM eMMC";"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";"milkv,mars-cm\0starfive,jh7110"
}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);+}
void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb""starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb""starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
On 30.04.24 00:46, E Shattow wrote:
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing emil.renner.berthing@canonical.com wrote:
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite" and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
Are there any actual differences that need representation in the dtb file for downstream OS different from Milk-V Mars to Milk-V Mars CM (or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for SDCard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea06598995db99ddb... but it does not seem necessary in mainline Linux, SD Card is working without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as mars-cm sdcard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e29...
This is what is patched in fdt_fixup_marc().
Then also there is some mention about PMIC and renamed i2c reference, already obsolete. That's all, is there more to it? Possibly a dtb for Mars is enough to also be used on Mars CM and Mars Lite?
Looking at the schematics the biggest difference between the Mars and the Mars CM (Lite) is on the USB side. The Mars board has USB 3.0 via a PCIe lane and a VIA VL805/806 while the Mars CM has USB directly via the SoC.
To add USB support for the Mars CM we will need an adapted device-tree.
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);} else {model = "Milk-V Mars CM eMMC";"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";"milkv,mars-cm\0starfive,jh7110"
}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);+}
- void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110";
@@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb""starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb""starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
On Tue, Apr 30, 2024 at 12:18 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 30.04.24 00:46, E Shattow wrote:
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing emil.renner.berthing@canonical.com wrote:
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite" and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
Are there any actual differences that need representation in the dtb file for downstream OS different from Milk-V Mars to Milk-V Mars CM (or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for SDCard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea06598995db99ddb... but it does not seem necessary in mainline Linux, SD Card is working without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as mars-cm sdcard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e29...
This is what is patched in fdt_fixup_marc().
That's the Mars fixup with a conditional for the s/GPIO62/GPIO22/ of CM Lite; which Linux seems not to mind either way so long as this was done at the U-Boot phase, it is functional for eMMC/SD mmc access with unmodified visionfive2 1.3b dtb (GPIO62 pinmux) from Linux.
It is not clear to me why in vendor U-Boot this is s/GPIO62/GPIO22/ but in vendor Linux kernel this is s/GPIO62/GPIO24/ ? It seems not needed (in Linux).
Then also there is some mention about PMIC and renamed i2c reference, already obsolete. That's all, is there more to it? Possibly a dtb for Mars is enough to also be used on Mars CM and Mars Lite?
Looking at the schematics the biggest difference between the Mars and the Mars CM (Lite) is on the USB side. The Mars board has USB 3.0 via a PCIe lane and a VIA VL805/806 while the Mars CM has USB directly via the SoC.
To add USB support for the Mars CM we will need an adapted device-tree.
Mars also needs this direct-to-SoC USB support, as its USB ports are a mix of VL805 and directly via the SoC. This can be the same for Mars and Mars CM/Lite.
See this photo from https://milkv.io/docs/mars/getting-started/bootloader what highlights this direct SoC USB port of Milk-V Mars: https://milkv.io/assets/images/mars-usb-port-a-b48fe1ff1003539d42bf5e1dde172...
The over-current errata https://doc-en.rvspace.org/VisionFive2/DG_USB/JH7110_SDK/usb_overcurrent_deb... suggests "please modify the above settings during the U-Boot phase".
-E
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);} else {model = "Milk-V Mars CM eMMC";"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";"milkv,mars-cm\0starfive,jh7110"
}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);+}
- void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110";
@@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb""starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb""starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
On 30.04.24 11:59, E Shattow wrote:
On Tue, Apr 30, 2024 at 12:18 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 30.04.24 00:46, E Shattow wrote:
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing emil.renner.berthing@canonical.com wrote:
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite" and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
Are there any actual differences that need representation in the dtb file for downstream OS different from Milk-V Mars to Milk-V Mars CM (or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for SDCard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea06598995db99ddb... but it does not seem necessary in mainline Linux, SD Card is working without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as mars-cm sdcard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e29...
This is what is patched in fdt_fixup_marc().
That's the Mars fixup with a conditional for the s/GPIO62/GPIO22/ of CM Lite; which Linux seems not to mind either way so long as this was done at the U-Boot phase, it is functional for eMMC/SD mmc access with unmodified visionfive2 1.3b dtb (GPIO62 pinmux) from Linux.
It is not clear to me why in vendor U-Boot this is s/GPIO62/GPIO22/ but in vendor Linux kernel this is s/GPIO62/GPIO24/ ? It seems not needed (in Linux).
According to the schematics GPIO22 is connected to SD_PWR_ON on the the low speed connector both on the Mars CM and the Mars CM Lite. GPIO62 is connected to SDMMC_RST_N on the eMMC. Both the SD-card and the eMMC are connected to SDI0. This is why only one of them can be usable.
GPIO024 is used for the MIPI camera interface.
I guess unless you reset the SD-card or eMMC GPIO062 and GPI022 are not used and this is why Linux is working in both configurations.
Then also there is some mention about PMIC and renamed i2c reference, already obsolete. That's all, is there more to it? Possibly a dtb for Mars is enough to also be used on Mars CM and Mars Lite?
Looking at the schematics the biggest difference between the Mars and the Mars CM (Lite) is on the USB side. The Mars board has USB 3.0 via a PCIe lane and a VIA VL805/806 while the Mars CM has USB directly via the SoC.
To add USB support for the Mars CM we will need an adapted device-tree.
Mars also needs this direct-to-SoC USB support, as its USB ports are a mix of VL805 and directly via the SoC. This can be the same for Mars and Mars CM/Lite.
The schematics say:
"One USB Controller only, supports either USB 2.0 or USB 3.0."
This sounds to me like you cannot have both in functional state.
Maybe Minda or Hal know more?
Best regards
Heinrich
See this photo from https://milkv.io/docs/mars/getting-started/bootloader what highlights this direct SoC USB port of Milk-V Mars: https://milkv.io/assets/images/mars-usb-port-a-b48fe1ff1003539d42bf5e1dde172...
The over-current errata https://doc-en.rvspace.org/VisionFive2/DG_USB/JH7110_SDK/usb_overcurrent_deb... suggests "please modify the above settings during the U-Boot phase".
-E
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27 ++++++++++++++++++- .../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) +{
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt, "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);} else {model = "Milk-V Mars CM eMMC";"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";"milkv,mars-cm\0starfive,jh7110"
}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat));fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);+}
- void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110";
@@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info *spl_image) pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();diff --git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR 0x2030000 #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb""starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb""starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
On 30.04.24 11:59, E Shattow wrote:
On Tue, Apr 30, 2024 at 12:18 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 30.04.24 00:46, E Shattow wrote:
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing emil.renner.berthing@canonical.com wrote:
Heinrich Schuchardt wrote:
We already support the VisionFive 2 and the Milk-V Mars board by patching the VisionFive 2 device tree. With this patch the same is done for the Milk-V Mars CM.
Hi Heinrich.
Thanks for the patch. As far as I can tell the Milk-V documentation[1] is pretty consistent in calling the version without eMMC
"Milk-V Mars CM Lite"
and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model, compatible and filenames suggested below.
sophy
Are there any actual differences that need representation in the dtb file for downstream OS different from Milk-V Mars to Milk-V Mars CM (or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for SDCard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea0659899 5db99ddbbbb252ee439c42b9c1a9 but it does not seem necessary in mainline Linux, SD Card is working without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as mars-cm sdcard version" https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f7 2ecf1e2947dfeb2c66e5035fce90
This is what is patched in fdt_fixup_marc().
That's the Mars fixup with a conditional for the s/GPIO62/GPIO22/ of CM Lite; which Linux seems not to mind either way so long as this was done at the U-Boot phase, it is functional for eMMC/SD mmc access with unmodified visionfive2 1.3b dtb (GPIO62 pinmux) from Linux.
It is not clear to me why in vendor U-Boot this is s/GPIO62/GPIO22/ but in vendor Linux kernel this is s/GPIO62/GPIO24/ ? It seems not needed (in Linux).
According to the schematics GPIO22 is connected to SD_PWR_ON on the the low speed connector both on the Mars CM and the Mars CM Lite. GPIO62 is connected to SDMMC_RST_N on the eMMC. Both the SD-card and the eMMC are connected to SDI0. This is why only one of them can be usable.
GPIO024 is used for the MIPI camera interface.
I guess unless you reset the SD-card or eMMC GPIO062 and GPI022 are not used and this is why Linux is working in both configurations.
Then also there is some mention about PMIC and renamed i2c reference, already obsolete. That's all, is there more to it? Possibly a dtb for Mars is enough to also be used on Mars CM and Mars Lite?
Looking at the schematics the biggest difference between the Mars and the Mars CM (Lite) is on the USB side. The Mars board has USB 3.0 via a PCIe lane and a VIA VL805/806 while the Mars CM has USB directly via the SoC.
To add USB support for the Mars CM we will need an adapted device-tree.
Mars also needs this direct-to-SoC USB support, as its USB ports are a mix of VL805 and directly via the SoC. This can be the same for Mars and Mars CM/Lite.
The schematics say:
"One USB Controller only, supports either USB 2.0 or USB 3.0."
This sounds to me like you cannot have both in functional state.
Maybe Minda or Hal know more?
Best regards
Heinrich
usb 3.0 PHY and PCIe0 using the same PHY. (2 PCIe + USB 2.0 or 1PCIe + USB 3.0/2.0) Now I have upstreamed the usb controller driver.
See this photo from https://milkv.io/docs/mars/getting-started/bootloader what highlights this direct SoC USB port of Milk-V Mars: https://milkv.io/assets/images/mars-usb-port-a-b48fe1ff1003539d42bf5e1 dde1725a3.jpg
The over-current errata https://doc-en.rvspace.org/VisionFive2/DG_USB/JH7110_SDK/usb_overcurre nt_debug.html suggests "please modify the above settings during the U-Boot phase".
-E
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt
heinrich.schuchardt@canonical.com
board/starfive/visionfive2/spl.c | 27
++++++++++++++++++-
.../visionfive2/starfive_visionfive2.c | 11 +++++++- 2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 45848db6d8b..bb0f28d7aad 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt) } }
+void spl_fdt_fixup_marc(void *fdt) {
const char *compat;const char *model;spl_fdt_fixup_mars(fdt);if (!get_mmc_size_from_eeprom()) {int offset;model = "Milk-V Mars CM SDCard";"Milk-V Mars CM Lite"
compat = "milkv,mars-cm-sdcard\0starfive,jh7110";"milkv,mars-cm-lite\0starfive,jh7110"
offset = fdt_path_offset(fdt,"/soc/pinctrl/mmc0-pins/mmc0-pins-rest");
fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);} else {model = "Milk-V Mars CM eMMC";"Milk-V Mars CM"
compat = "milkv,mars-cm-emmc\0starfive,jh7110";"milkv,mars-cm\0starfive,jh7110"
}fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,sizeof(compat));
fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model",+model); }
- void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] =
"starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info
*spl_image)
pr_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {spl_fdt_fixup_marc(spl_image->fdt_addr);} else if (!strncmp(product_id, "MARS", 4)) { spl_fdt_fixup_mars(spl_image->fdt_addr); } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom(); diff--git a/board/starfive/visionfive2/starfive_visionfive2.c b/board/starfive/visionfive2/starfive_visionfive2.c index a86bca533b2..be6ca85b030 100644 --- a/board/starfive/visionfive2/starfive_visionfive2.c +++ b/board/starfive/visionfive2/starfive_visionfive2.c @@ -17,6 +17,10 @@ DECLARE_GLOBAL_DATA_PTR; #define JH7110_L2_PREFETCHER_BASE_ADDR
0x2030000
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000 +#define FDTFILE_MILK_V_MARC_SD \
"starfive/jh7110-milkv-mars-cm-sdcard.dtb""starfive/jh7110-milkv-mars-cm-lite.dtb"
+#define FDTFILE_MILK_V_MARC_MMC \
"starfive/jh7110-milkv-mars-cm-emmc.dtb""starfive/jh7110-milkv-mars-cm.dtb"
#define FDTFILE_MILK_V_MARS \ "starfive/jh7110-milkv-mars.dtb" #define FDTFILE_VISIONFIVE2_1_2A \ @@ -61,7 +65,12 @@ static void set_fdtfile(void) log_err("Can't read EEPROM\n"); return; }
if (!strncmp(product_id, "MARS", 4)) {
if (!strncmp(product_id, "MARC", 4)) {if (get_mmc_size_from_eeprom())fdtfile = FDTFILE_MILK_V_MARC_MMC;elsefdtfile = FDTFILE_MILK_V_MARC_SD;} else if (!strncmp(product_id, "MARS", 4)) { fdtfile = FDTFILE_MILK_V_MARS; } else if (!strncmp(product_id, "VF7110", 6)) { version = get_pcb_revision_from_eeprom();-- 2.43.0
Provide a man-page describing the usage of U-Boot on the Milk-V Mars CM and Milk-V Mars CM Lite boards.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars_cm.rst | 125 ++++++++++++++++++++++++++ 2 files changed, 126 insertions(+) create mode 100644 doc/board/starfive/milk-v_mars_cm.rst
diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst index 2762bf74c11..afa85ad2540 100644 --- a/doc/board/starfive/index.rst +++ b/doc/board/starfive/index.rst @@ -7,4 +7,5 @@ StarFive :maxdepth: 1
milk-v_mars.rst + milk-v_mars_cm.rst visionfive2 diff --git a/doc/board/starfive/milk-v_mars_cm.rst b/doc/board/starfive/milk-v_mars_cm.rst new file mode 100644 index 00000000000..4cd6034281c --- /dev/null +++ b/doc/board/starfive/milk-v_mars_cm.rst @@ -0,0 +1,125 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Milk-V Mars CM +============== + +U-Boot for the Milk-V Mars CM uses the same U-Boot binaries as the VisionFive 2 +board. In U-Boot SPL the actual board is detected and the device-tree patched +accordingly. + +The Milk-V Mars CM Lite comes without eMMC it needs a different pin muxing. +The size of the eMMC shows up in the serial number shown by the *mac* command, +e.g. MARC-V10-2340-D002E016-00000304. The number after the E is the MMC size +in GB. U-Boot takes a value of E000 as an indicator for the Lite version. +Unfortunately the vendor has not set this value correctly on some Lite boards. +Please, use CONFIG_STARFIVE_NO_EMMC=y to indicate a Milk-V Mars CM Lite in this +case. Otherwise you will not be able to read from eMMC + +Building +~~~~~~~~ + +1. Add the RISC-V toolchain to your PATH. +2. Setup ARCH & cross compilation environment variable: + +.. code-block:: none + + export CROSS_COMPILE=<riscv64 toolchain prefix> + +The M-mode software OpenSBI provides the supervisor binary interface (SBI) and +is responsible for the switch to S-Mode. It is a prerequisite to build U-Boot. +Support for the JH7110 was introduced in OpenSBI 1.2. It is recommended to use +a current release. + +.. code-block:: console + + git clone https://github.com/riscv/opensbi.git + cd opensbi + make PLATFORM=generic FW_TEXT_START=0x40000000 FW_OPTIONS=0 + +Now build the U-Boot SPL and U-Boot proper. + +.. code-block:: console + + cd <U-Boot-dir> + make starfive_visionfive2_defconfig + make OPENSBI=$(opensbi_dir)/build/platform/generic/firmware/fw_dynamic.bin + +This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out) as well +as the FIT image (u-boot.itb) with OpenSBI and U-Boot. + +Device-tree selection +~~~~~~~~~~~~~~~~~~~~~ + +Depending on the board version U-Boot sets variable $fdtfile to either +starfive/jh7110-milkv-mars-cm-emmc.dtb (for the generic version or +starfive/jh7110-milkv-mars-cm-sdcard.dtb (for the Lite version). + +To overrule this selection the variable can be set manually and saved in the +environment + +:: + + setenv fdtfile my_device-tree.dtb + env save + +or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to +provide a default value. + +Boot source selection +~~~~~~~~~~~~~~~~~~~~~ + +The low speed connector nRPIBOOT line is used to switch the boot source. + +* If nRPIBOOT is connected to ground, the board boots from UART. +* If nRPIBOOT is not connected, the board boots from SPI flash. + +Flashing a new U-Boot version +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +U-Boot SPL is provided as file spl/u-boot-spl.bin.normal.out. Main U-Boot is +in file u-boot.itb. + +Assuming your new U-Boot version is on partition 1 of an SD-card you could +install to the SPI flash with: + +:: + + sf probe + load mmc 1:1 $kernel_addr_r u-boot-spl.bin.normal.out + sf update $kernel_addr_r 0 $filesize + load mmc 1:1 $kernel_addr_r u-boot.itb + sf update $kernel_addr_r 0x100000 $filesize + +After updating U-Boot you may want to reboot and reset the environment to the +default. + +:: + + env default -f -a + env save + +Booting from UART +~~~~~~~~~~~~~~~~~ + +For booting via UART U-Boot must be built with CONFIG_SPL_YMODEM_SUPPORT=y. + +Upload u-boot-spl.bin.normal.out via XMODEM. Then upload u-boot.itb via +YMODEM. + +The XMODEM implementation in the boot ROM is not fully specification compliant. +It sends too many NAKs in a row. Some tolerant terminal implementations exist. +Or use a dedicated recovery tool e.g. +https://github.com/xypron/JH71xx-tools/tree/VisionFive2: + +.. code-block:: bash + + # send U-Boot SPL via XMODEM + vf2-recover -D /dev/ttyUSB0 -r u-boot-spl.bin.normal.out + # connect to board to transfer main U-Boot via YMODEM + picocom --send-cmd 'sz -b -vv' --baud 115200 /dev/ttyUSB0 + # In Picocom use <CTRL+A>,<CTRL+S> to send u-boot.itb + +Booting from SPI flash +~~~~~~~~~~~~~~~~~~~~~~ + +Once you power up, you should see the U-Boot prompt on the serial console.
On Mon, Apr 15, 2024 at 4:50 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
Provide a man-page describing the usage of U-Boot on the Milk-V Mars CM and Milk-V Mars CM Lite boards.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
doc/board/starfive/index.rst | 1 + doc/board/starfive/milk-v_mars_cm.rst | 125 ++++++++++++++++++++++++++ 2 files changed, 126 insertions(+) create mode 100644 doc/board/starfive/milk-v_mars_cm.rst
diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst index 2762bf74c11..afa85ad2540 100644 --- a/doc/board/starfive/index.rst +++ b/doc/board/starfive/index.rst @@ -7,4 +7,5 @@ StarFive :maxdepth: 1
milk-v_mars.rst
- milk-v_mars_cm.rst visionfive2
diff --git a/doc/board/starfive/milk-v_mars_cm.rst b/doc/board/starfive/milk-v_mars_cm.rst new file mode 100644 index 00000000000..4cd6034281c --- /dev/null +++ b/doc/board/starfive/milk-v_mars_cm.rst @@ -0,0 +1,125 @@ +.. SPDX-License-Identifier: GPL-2.0+
+Milk-V Mars CM +==============
+U-Boot for the Milk-V Mars CM uses the same U-Boot binaries as the VisionFive 2 +board. In U-Boot SPL the actual board is detected and the device-tree patched +accordingly.
+The Milk-V Mars CM Lite comes without eMMC it needs a different pin muxing.
JH7110 Technical Reference Manual does list some sdio related mux function with this GPIO62/GPIO22 substitution. I did not hear back yet from Milk-V developer support per my request for clarifying why this is needed and relevant schematics. I want this explained more clearly in documentation the purpose for this different pin muxing or why it is needed in the U-Boot phase of the boot process for specifically Milk-V Mars CM Lite (SD Card non-eMMC version). Previously I thought it was something about the power regulator not having a complete device driver in U-Boot but I don't know. Is it a bodge or is it intentional for easier manufacture?
+The size of the eMMC shows up in the serial number shown by the *mac* command, +e.g. MARC-V10-2340-D002E016-00000304. The number after the E is the MMC size
The number may have 'T' suffix making this description wrong. Describing as unit-less "size." is enough, so delete "in GB."
+in GB. U-Boot takes a value of E000 as an indicator for the Lite version.
None of the Lite versions have eMMC so that can be inferred without naming the specific product. Maybe in future there is some other need for this config option so keep it generic.
Suggest "U-Boot takes a value of E000 as an indicator for not having an eMMC."
+Unfortunately the vendor has not set this value correctly on some Lite boards.
Milk-V developer support acknowledged 14th Apr 2024 my e-mail inquiry about wrong EEPROM data, but did not comment (yet) on instructions for a fix for boards that have wrong EEPROM data.
As for documentation we should have something that describes how to confirm the data is correct and if it is not then what can be done, in the case of fixing the EEPROM data and not.
Suggest to add: "In default operation EEPROM Write Protect is enabled, and may be disabled connecting the "GND" and "EN" test pads on top of the module."
and an example of `mac product_id` also `mac write_eeprom` commands. You can do this with a steady hand and a paperclip, as the pads are accessible near the board edge even with the heatsink in place. Lest we be blamed for bad decisions users make with a paperclip though, I don't know if you want to include this information. I think it was easy to do and future production runs should have the correct EEPROM data value for eMMC so it would make sense to want to update this.
+Please, use CONFIG_STARFIVE_NO_EMMC=y to indicate a Milk-V Mars CM Lite in this +case. Otherwise you will not be able to read from eMMC
Suggest: "Please, use CONFIG_STARFIVE_NO_EMMC=y when EEPROM data indicates eMMC is present on Milk-V Mars CM Lite. Otherwise you will not be able to read from SD Card."
+Building +~~~~~~~~
+1. Add the RISC-V toolchain to your PATH. +2. Setup ARCH & cross compilation environment variable:
+.. code-block:: none
- export CROSS_COMPILE=<riscv64 toolchain prefix>
+The M-mode software OpenSBI provides the supervisor binary interface (SBI) and +is responsible for the switch to S-Mode. It is a prerequisite to build U-Boot. +Support for the JH7110 was introduced in OpenSBI 1.2. It is recommended to use +a current release.
+.. code-block:: console
git clone https://github.com/riscv/opensbi.gitcd opensbimake PLATFORM=generic FW_TEXT_START=0x40000000 FW_OPTIONS=0
Is it needed to pass FW_OPTIONS ?
FW_TEXT_START is deprecated in opensbi commit d4d2582e (8th Apr 2024). Keep for compatibility but noted here in review.
+Now build the U-Boot SPL and U-Boot proper.
+.. code-block:: console
cd <U-Boot-dir>make starfive_visionfive2_defconfigmake OPENSBI=$(opensbi_dir)/build/platform/generic/firmware/fw_dynamic.bin+This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out) as well +as the FIT image (u-boot.itb) with OpenSBI and U-Boot.
+Device-tree selection +~~~~~~~~~~~~~~~~~~~~~
+Depending on the board version U-Boot sets variable $fdtfile to either +starfive/jh7110-milkv-mars-cm-emmc.dtb (for the generic version or +starfive/jh7110-milkv-mars-cm-sdcard.dtb (for the Lite version).
+To overrule this selection the variable can be set manually and saved in the +environment
+::
- setenv fdtfile my_device-tree.dtb
- env save
+or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to +provide a default value.
+Boot source selection +~~~~~~~~~~~~~~~~~~~~~
+The low speed connector nRPIBOOT line is used to switch the boot source.
+* If nRPIBOOT is connected to ground, the board boots from UART. +* If nRPIBOOT is not connected, the board boots from SPI flash.
+Flashing a new U-Boot version +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+U-Boot SPL is provided as file spl/u-boot-spl.bin.normal.out. Main U-Boot is +in file u-boot.itb.
+Assuming your new U-Boot version is on partition 1 of an SD-card you could +install to the SPI flash with:
+::
- sf probe
- load mmc 1:1 $kernel_addr_r u-boot-spl.bin.normal.out
- sf update $kernel_addr_r 0 $filesize
- load mmc 1:1 $kernel_addr_r u-boot.itb
In my testing of Mars CM Lite the SD-Card appears as mmc 0:1 and not mmc 1:1. If you had eMMC that would be mmc 1:1, I guess, but I don't have the Mars CM with eMMC version here to confirm. That description could be changed to refer to eMMC, and/or example reflecting SD Card. How is this on the Mars, is there both SD and eMMC?
- sf update $kernel_addr_r 0x100000 $filesize
I have been using $loadaddr for memory address with spi flash procedure as less typing and easier to remember than $kernel_addr_r ; Is there a reason or U-Boot convention for one or the other?
+After updating U-Boot you may want to reboot and reset the environment to the +default.
+::
- env default -f -a
- env save
+Booting from UART +~~~~~~~~~~~~~~~~~
+For booting via UART U-Boot must be built with CONFIG_SPL_YMODEM_SUPPORT=y.
Prefix the following to reference the earlier explanation: "With nRPIBOOT set for UART boot, power the board and upload..."
+Upload u-boot-spl.bin.normal.out via XMODEM. Then upload u-boot.itb via +YMODEM.
+The XMODEM implementation in the boot ROM is not fully specification compliant. +It sends too many NAKs in a row. Some tolerant terminal implementations exist. +Or use a dedicated recovery tool e.g. +https://github.com/xypron/JH71xx-tools/tree/VisionFive2:
+.. code-block:: bash
- # send U-Boot SPL via XMODEM
- vf2-recover -D /dev/ttyUSB0 -r u-boot-spl.bin.normal.out
- # connect to board to transfer main U-Boot via YMODEM
- picocom --send-cmd 'sz -b -vv' --baud 115200 /dev/ttyUSB0
- # In Picocom use <CTRL+A>,<CTRL+S> to send u-boot.itb
Comment: I've been using 'tio' serial tool that has its own XMODEM and YMODEM implementation not depending on 'sz'. Would like to see this as an additional mention for an all-in-one tool if you can confirm that it does not hit the JH7110 XMODEM implementation bug - I'm not sure, but I have had success with it so I think it's okay. 'tio' is widely available in Linux distros so that may be more convenient for users, unless it does hit that bug and I haven't noticed it, I just tried a lot of tools until finding that this seems to work for me.
+Booting from SPI flash +~~~~~~~~~~~~~~~~~~~~~~
+Once you power up, you should see the U-Boot prompt on the serial console.
2.43.0
We can use U-Boot for recovering JH7110 based boards via UART if CONFIG_SPL_YMODEM_SUPPORT=y.
* Send u-boot-spl.normal.out via XMODEM. * Send u-boot.itb via YMODEM.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index fa80d489f5e..e2d83c62b28 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_PROMPT="StarFive # " CONFIG_CMD_EEPROM=y CONFIG_SYS_EEPROM_SIZE=512
Successful in use w/ 'tio' serial tool and Adafruit CP2102N Friend adapter on Mars CM Lite board in DFRobot mini router carrier.
While SPL and u-boot.itb payload are sourced via UART the environment variables are from the environment variable storage as-is. This makes sense in the use case for development but may have side-effects in the case of U-Boot as a JH7110 recovery tool. There is now 'env default -f -a' which does not purge non-default variables and retains the non-default variables when migrating from vendor firmware. Consider to also build for U-Boot the commands that can aid in cleaning the stored environment variable state CONFIG_CMD_ERASEENV=y and in-memory state CONFIG_CMD_NVEDIT_LOAD=y. With these it can be done easily with: 'env erase; env load; env save'.
On Mon, Apr 15, 2024 at 4:51 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
We can use U-Boot for recovering JH7110 based boards via UART if CONFIG_SPL_YMODEM_SUPPORT=y.
- Send u-boot-spl.normal.out via XMODEM.
- Send u-boot.itb via YMODEM.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index fa80d489f5e..e2d83c62b28 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_PROMPT="StarFive # " CONFIG_CMD_EEPROM=y CONFIG_SYS_EEPROM_SIZE=512 -- 2.43.0
Tested-by: E Shattow lucent@gmail.com
On 17.04.24 03:41, E Shattow wrote:
Successful in use w/ 'tio' serial tool and Adafruit CP2102N Friend adapter on Mars CM Lite board in DFRobot mini router carrier.
While SPL and u-boot.itb payload are sourced via UART the environment variables are from the environment variable storage as-is. This makes sense in the use case for development but may have side-effects in the case of U-Boot as a JH7110 recovery tool. There is now 'env default -f -a' which does not purge non-default variables and retains the non-default variables when migrating from vendor firmware. Consider to also build for U-Boot the commands that can aid in cleaning the stored environment variable state CONFIG_CMD_ERASEENV=y and in-memory state CONFIG_CMD_NVEDIT_LOAD=y. With these it can be done easily with: 'env erase; env load; env save'.
Thank you for testing.
After erasing there is no need to save the environment. If there is no environment on flash, the default will be loaded anyway:
*** Warning - bad CRC, using default environment
Instead of 'env erase' you could use 'sf erase 0xf0000 0x1000' which is already available. As adding CONFIG_CMD_ERASEENV=y is not necessary in the scope of this patch series I would prefer leaving it to future discussion.
Best regards
Heinrich
On Mon, Apr 15, 2024 at 4:51 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
We can use U-Boot for recovering JH7110 based boards via UART if CONFIG_SPL_YMODEM_SUPPORT=y.
- Send u-boot-spl.normal.out via XMODEM.
- Send u-boot.itb via YMODEM.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index fa80d489f5e..e2d83c62b28 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -62,6 +62,7 @@ CONFIG_SPL_I2C=y CONFIG_SPL_DM_SPI_FLASH=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_SPI_LOAD=y +CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_SYS_PROMPT="StarFive # " CONFIG_CMD_EEPROM=y CONFIG_SYS_EEPROM_SIZE=512 -- 2.43.0
Tested-by: E Shattow lucent@gmail.com
On Wed, Apr 17, 2024 at 1:22 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 17.04.24 03:41, E Shattow wrote:
Successful in use w/ 'tio' serial tool and Adafruit CP2102N Friend adapter on Mars CM Lite board in DFRobot mini router carrier.
While SPL and u-boot.itb payload are sourced via UART the environment variables are from the environment variable storage as-is. This makes sense in the use case for development but may have side-effects in the case of U-Boot as a JH7110 recovery tool. There is now 'env default -f -a' which does not purge non-default variables and retains the non-default variables when migrating from vendor firmware. Consider to also build for U-Boot the commands that can aid in cleaning the stored environment variable state CONFIG_CMD_ERASEENV=y and in-memory state CONFIG_CMD_NVEDIT_LOAD=y. With these it can be done easily with: 'env erase; env load; env save'.
Thank you for testing.
After erasing there is no need to save the environment. If there is no environment on flash, the default will be loaded anyway:
*** Warning - bad CRC, using default environment
Instead of 'env erase' you could use 'sf erase 0xf0000 0x1000' which is already available. As adding CONFIG_CMD_ERASEENV=y is not necessary in the scope of this patch series I would prefer leaving it to future discussion.
Best regards
Heinrich
The 'env erase; env load; env save' can be done at the same session just before recovery write to provide a sanitized environment with the defaults of the present U-Boot payload loaded via UART, so is not the same as 'sf erase ...' waiting for a reboot (5 minutes more to transfer via UART at 115200 baud) and needing to interrupt the boot to further 'env save'. Having 'env load' allows to allow that reboot step in-between. Point taken though, it's helpful for recovery but not required. -E
P.S. mis-spoke should have written "Having 'env load' allows to skip that reboot step in-between
On Wed, Apr 17, 2024 at 12:28 PM E Shattow lucent@gmail.com wrote:
On Wed, Apr 17, 2024 at 1:22 AM Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 17.04.24 03:41, E Shattow wrote:
Successful in use w/ 'tio' serial tool and Adafruit CP2102N Friend adapter on Mars CM Lite board in DFRobot mini router carrier.
While SPL and u-boot.itb payload are sourced via UART the environment variables are from the environment variable storage as-is. This makes sense in the use case for development but may have side-effects in the case of U-Boot as a JH7110 recovery tool. There is now 'env default -f -a' which does not purge non-default variables and retains the non-default variables when migrating from vendor firmware. Consider to also build for U-Boot the commands that can aid in cleaning the stored environment variable state CONFIG_CMD_ERASEENV=y and in-memory state CONFIG_CMD_NVEDIT_LOAD=y. With these it can be done easily with: 'env erase; env load; env save'.
Thank you for testing.
After erasing there is no need to save the environment. If there is no environment on flash, the default will be loaded anyway:
*** Warning - bad CRC, using default environment
Instead of 'env erase' you could use 'sf erase 0xf0000 0x1000' which is already available. As adding CONFIG_CMD_ERASEENV=y is not necessary in the scope of this patch series I would prefer leaving it to future discussion.
Best regards
Heinrich
The 'env erase; env load; env save' can be done at the same session just before recovery write to provide a sanitized environment with the defaults of the present U-Boot payload loaded via UART, so is not the same as 'sf erase ...' waiting for a reboot (5 minutes more to transfer via UART at 115200 baud) and needing to interrupt the boot to further 'env save'. Having 'env load' allows to allow that reboot step in-between. Point taken though, it's helpful for recovery but not required. -E
participants (4)
-
E Shattow -
Emil Renner Berthing -
Heinrich Schuchardt -
Minda Chen