| Message ID | 20240321181149.177356-5-heinrich.schuchardt@canonical.com |
|---|---|
| State | Superseded, archived |
| Delegated to: | Andes |
| Headers | show |
| Series | riscv: add support for Milk-V Mars board | expand |
On 2024-03-21 19:11, Heinrich Schuchardt wrote: > The differences between the Milk-V Mars board and the VisionFive 2 board > are small enough that we can support both using the same U-Boot build. > > * The model and compatible property are taken from proposed Linux patches. > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > * The second Ethernet port is not available. From the device tree that have been submitted to the kernel [1] it seems another difference is that there is a CD gpio for mmc1. From the schematics, it also seems that the usb0 port is not in peripheral mode, but in host mode. That said on the submitted kernel device tree it seems simply disabled. Aurelien [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszhang@kernel.org/T/
On 24.03.24 16:00, Aurelien Jarno wrote: > On 2024-03-21 19:11, Heinrich Schuchardt wrote: >> The differences between the Milk-V Mars board and the VisionFive 2 board >> are small enough that we can support both using the same U-Boot build. >> >> * The model and compatible property are taken from proposed Linux patches. >> * The EEPROM is atmel,24c02 according to the vendor U-Boot. >> * The second Ethernet port is not available. > > From the device tree that have been submitted to the kernel [1] it seems > another difference is that there is a CD gpio for mmc1. Yes, the Mars board has cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; while the VisionFive 2 has broken-cd; We could add the cd-gpios to the VF2 dts and then set broken-cd in spl_fdt_fixup_*(). What I would really like to understand from the reviewers is if the approach with patching the device-tree is what we are targeting for. Or should we try to keep the device-trees in sync with Linux, package all JH7110 device-trees into the FIT image and in SPL choose the device-tree from the fit image and only patch the memory size. The device-tree for the Milk-V CM module differs a lot in GPIO routing. I am not sure that patching the VF2 device-tree is future proof. Best regards Heinrich > > From the schematics, it also seems that the usb0 port is not in > peripheral mode, but in host mode. That said on the submitted kernel > device tree it seems simply disabled. > > Aurelien > > [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszhang@kernel.org/T/ >
Hi Heinrich, On Thu, Mar 21, 2024 at 07:11:47PM +0100, Heinrich Schuchardt wrote: > The differences between the Milk-V Mars board and the VisionFive 2 board > are small enough that we can support both using the same U-Boot build. > > * The model and compatible property are taken from proposed Linux patches. > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > * The second Ethernet port is not available. > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> > --- > v2: > do not overwrite /soc/i2c@12050000/eeprom@50/compatible > > --- > board/starfive/visionfive2/spl.c | 99 ++++++++++++++++++++++++++++---- > 1 file changed, 87 insertions(+), 12 deletions(-) > > diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c > index 1b49945d11b..e0e33cb37ba 100644 > --- a/board/starfive/visionfive2/spl.c > +++ b/board/starfive/visionfive2/spl.c > @@ -67,6 +87,49 @@ static const struct starfive_vf2_pro starfive_verb[] = { > "tx-internal-delay-ps", "0"}, > }; > > +void spl_fdt_fixup_mars(void *fdt) > +{ > + static const char compat[] = "milkv,mars\0starfive,jh7110"; > + u32 phandle; > + u8 i; > + int offset; > + int ret; > + > + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat)); > + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", > + "Milk-V Mars"); > + > + /* gmac0 */ > + offset = fdt_path_offset(fdt, "/soc/clock-controller@17000000"); > + phandle = fdt_get_phandle(fdt, offset); > + offset = fdt_path_offset(fdt, "/soc/ethernet@16030000"); > + > + fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle); > + fdt_appendprop_u32(fdt, offset, "assigned-clocks", JH7110_AONCLK_GMAC0_TX); > + fdt_setprop_u32(fdt, offset, "assigned-clock-parents", phandle); > + fdt_appendprop_u32(fdt, offset, "assigned-clock-parents", > + JH7110_AONCLK_GMAC0_RMII_RTX); > + > + /* gmac1 */ > + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/soc/ethernet@16040000"), > + "status", "disabled"); > + > + for (i = 0; i < ARRAY_SIZE(milk_v_mars); i++) { > + offset = fdt_path_offset(fdt, milk_v_mars[i].path); > + > + if (starfive_verb[i].value) Should this be milk_v_mars[i].value ? > + ret = fdt_setprop_u32(fdt, offset, milk_v_mars[i].name, > + dectoul(milk_v_mars[i].value, NULL)); > + else > + ret = fdt_setprop_empty(fdt, offset, milk_v_mars[i].name); > + > + if (ret) { > + pr_err("%s set prop %s fail.\n", __func__, milk_v_mars[i].name); > + break; > + } > + } > +} > +
Hi Heinrich, On Wed, Mar 27, 2024 at 12:03:01PM +0100, Heinrich Schuchardt wrote: > [EXTERNAL MAIL] > > On 24.03.24 16:00, Aurelien Jarno wrote: > > On 2024-03-21 19:11, Heinrich Schuchardt wrote: > > > The differences between the Milk-V Mars board and the VisionFive 2 board > > > are small enough that we can support both using the same U-Boot build. > > > > > > * The model and compatible property are taken from proposed Linux patches. > > > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > > > * The second Ethernet port is not available. > > > > From the device tree that have been submitted to the kernel [1] it seems > > another difference is that there is a CD gpio for mmc1. > > Yes, the Mars board has > > cd-gpios = <&sysgpio 41 GPIO_ACTIVE_LOW>; > > while the VisionFive 2 has > > broken-cd; > > We could add the cd-gpios to the VF2 dts and then set broken-cd in > spl_fdt_fixup_*(). > > What I would really like to understand from the reviewers is if the > approach with patching the device-tree is what we are targeting for. > > Or should we try to keep the device-trees in sync with Linux, package > all JH7110 device-trees into the FIT image and in SPL choose the > device-tree from the fit image and only patch the memory size. > > The device-tree for the Milk-V CM module differs a lot in GPIO routing. > I am not sure that patching the VF2 device-tree is future proof. I think we could patch the VF2 device-tree currently with this few differeces, and create a new device tree for Milk-V Mars CM module if patching the VF2 device tree is too much of an effort. Does this sound reasonable ? Do you have any preference over which scheme we should use ? Best regards, Leo > > Best regards > > Heinrich > > > > > > From the schematics, it also seems that the usb0 port is not in > > peripheral mode, but in host mode. That said on the submitted kernel > > device tree it seems simply disabled. > > > > Aurelien > > > > [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszhang@kernel.org/T/ > > >
On 24.03.24 16:00, Aurelien Jarno wrote: > On 2024-03-21 19:11, Heinrich Schuchardt wrote: >> The differences between the Milk-V Mars board and the VisionFive 2 board >> are small enough that we can support both using the same U-Boot build. >> >> * The model and compatible property are taken from proposed Linux patches. >> * The EEPROM is atmel,24c02 according to the vendor U-Boot. >> * The second Ethernet port is not available. > > From the device tree that have been submitted to the kernel [1] it seems > another difference is that there is a CD gpio for mmc1. Thank you for reviewing. On all of Milk-V Mars, VisionFive 2 1.2B, and 1.3A I see GPIO 41 level changing when removing or inserting an SD card using U-Boot command 'gpio status -a'. So this seems not to be Milk-V specific. Could you, please, check. > > From the schematics, it also seems that the usb0 port is not in > peripheral mode, but in host mode. That said on the submitted kernel > device tree it seems simply disabled. All three blue-colored USB 3.0 ports are able to read an SD-card in U-Boot. The black port provides 5V but I could not make it work. On the schema I found: USB20: Do not support OTG mode and AVSS_USB0-AVSS_USB2 attached to ground. Could you, please, specify which node in the device-tree you want to disable. I cannot see anything disabled for usb@10100000 and usb@0 in the kernel device-tree. Best regards Heinrich > > Aurelien > > [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszhang@kernel.org/T/ >
On 2024-03-28 17:01, Heinrich Schuchardt wrote: > On 24.03.24 16:00, Aurelien Jarno wrote: > > On 2024-03-21 19:11, Heinrich Schuchardt wrote: > > > The differences between the Milk-V Mars board and the VisionFive 2 board > > > are small enough that we can support both using the same U-Boot build. > > > > > > * The model and compatible property are taken from proposed Linux patches. > > > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > > > * The second Ethernet port is not available. > > > > From the device tree that have been submitted to the kernel [1] it seems > > another difference is that there is a CD gpio for mmc1. > > Thank you for reviewing. > > On all of Milk-V Mars, VisionFive 2 1.2B, and 1.3A I see GPIO 41 level > changing when removing or inserting an SD card using U-Boot command 'gpio > status -a'. So this seems not to be Milk-V specific. > > Could you, please, check. This already have been answered by others, thanks. > > From the schematics, it also seems that the usb0 port is not in > > peripheral mode, but in host mode. That said on the submitted kernel > > device tree it seems simply disabled. > > All three blue-colored USB 3.0 ports are able to read an SD-card in U-Boot. > > The black port provides 5V but I could not make it work. > > On the schema I found: > > USB20: Do not support OTG mode and AVSS_USB0-AVSS_USB2 attached to ground. > > Could you, please, specify which node in the device-tree you want to > disable. I cannot see anything disabled for usb@10100000 and usb@0 in the > kernel device-tree. Disclaimer, I have no such board, but I remember people on IRC trying to use the device tree from the VF2 on a Milk-V Mars and getting an error with the USB being in a wrong mode. The difference I have noticed is not a node but the dr_mode property: &usb0 { dr_mode = "peripheral"; status = "okay"; }; This does not appear on the patches submitted on the Linux side for the MilkV Mars. Aurelien
On 4/1/24 17:28, Aurelien Jarno wrote: > On 2024-03-28 17:01, Heinrich Schuchardt wrote: >> On 24.03.24 16:00, Aurelien Jarno wrote: >>> On 2024-03-21 19:11, Heinrich Schuchardt wrote: >>>> The differences between the Milk-V Mars board and the VisionFive 2 board >>>> are small enough that we can support both using the same U-Boot build. >>>> >>>> * The model and compatible property are taken from proposed Linux patches. >>>> * The EEPROM is atmel,24c02 according to the vendor U-Boot. >>>> * The second Ethernet port is not available. >>> >>> From the device tree that have been submitted to the kernel [1] it seems >>> another difference is that there is a CD gpio for mmc1. >> >> Thank you for reviewing. >> >> On all of Milk-V Mars, VisionFive 2 1.2B, and 1.3A I see GPIO 41 level >> changing when removing or inserting an SD card using U-Boot command 'gpio >> status -a'. So this seems not to be Milk-V specific. >> >> Could you, please, check. > > This already have been answered by others, thanks. > >>> From the schematics, it also seems that the usb0 port is not in >>> peripheral mode, but in host mode. That said on the submitted kernel >>> device tree it seems simply disabled. >> >> All three blue-colored USB 3.0 ports are able to read an SD-card in U-Boot. >> >> The black port provides 5V but I could not make it work. >> >> On the schema I found: >> >> USB20: Do not support OTG mode and AVSS_USB0-AVSS_USB2 attached to ground. >> >> Could you, please, specify which node in the device-tree you want to >> disable. I cannot see anything disabled for usb@10100000 and usb@0 in the >> kernel device-tree. > > Disclaimer, I have no such board, but I remember people on IRC trying to > use the device tree from the VF2 on a Milk-V Mars and getting an error > with the USB being in a wrong mode. > > The difference I have noticed is not a node but the dr_mode property: > > &usb0 { > dr_mode = "peripheral"; > status = "okay"; > }; Thanks Aurelien for the explanation. The node usb@10100000 (aka usb0) does not exist in the U-Boot VisionFive2 device-tree, yet. There isn't any dr_mode property either. We will have to consider this node once we merge the Linux device-tree. Best regards Heinrich > > This does not appear on the patches submitted on the Linux side for the MilkV > Mars. > > Aurelien >
> > On 4/1/24 17:28, Aurelien Jarno wrote: > > On 2024-03-28 17:01, Heinrich Schuchardt wrote: > >> On 24.03.24 16:00, Aurelien Jarno wrote: > >>> On 2024-03-21 19:11, Heinrich Schuchardt wrote: > >>>> The differences between the Milk-V Mars board and the VisionFive 2 > >>>> board are small enough that we can support both using the same U-Boot > build. > >>>> > >>>> * The model and compatible property are taken from proposed Linux > patches. > >>>> * The EEPROM is atmel,24c02 according to the vendor U-Boot. > >>>> * The second Ethernet port is not available. > >>> > >>> From the device tree that have been submitted to the kernel [1] it > >>> seems another difference is that there is a CD gpio for mmc1. > >> > >> Thank you for reviewing. > >> > >> On all of Milk-V Mars, VisionFive 2 1.2B, and 1.3A I see GPIO 41 > >> level changing when removing or inserting an SD card using U-Boot > >> command 'gpio status -a'. So this seems not to be Milk-V specific. > >> > >> Could you, please, check. > > > > This already have been answered by others, thanks. > > > >>> From the schematics, it also seems that the usb0 port is not in > >>> peripheral mode, but in host mode. That said on the submitted kernel > >>> device tree it seems simply disabled. > >> > >> All three blue-colored USB 3.0 ports are able to read an SD-card in U-Boot. > >> > >> The black port provides 5V but I could not make it work. > >> > >> On the schema I found: > >> > >> USB20: Do not support OTG mode and AVSS_USB0-AVSS_USB2 attached to > ground. > >> > >> Could you, please, specify which node in the device-tree you want to > >> disable. I cannot see anything disabled for usb@10100000 and usb@0 in > >> the kernel device-tree. > > > > Disclaimer, I have no such board, but I remember people on IRC trying > > to use the device tree from the VF2 on a Milk-V Mars and getting an > > error with the USB being in a wrong mode. > > > > The difference I have noticed is not a node but the dr_mode property: > > > > &usb0 { > > dr_mode = "peripheral"; > > status = "okay"; > > }; > > Thanks Aurelien for the explanation. > > The node usb@10100000 (aka usb0) does not exist in the U-Boot > VisionFive2 device-tree, yet. There isn't any dr_mode property either. > > We will have to consider this node once we merge the Linux device-tree. > > Best regards > > Heinrich > usb@10100000 is cadence usb controller. In VF2, dr mode is usb peripheral and seldom used in u-boot. So the cadence usb wrapper codes not in uboot upstream. I don't know the dr mode in milkv 7110 board. But if it its dr mode is host, I think I need develop cadence usb wrapper code upstream. Minda > > > > This does not appear on the patches submitted on the Linux side for > > the MilkV Mars. > > > > Aurelien > >
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c index 1b49945d11b..e0e33cb37ba 100644 --- a/board/starfive/visionfive2/spl.c +++ b/board/starfive/visionfive2/spl.c @@ -27,6 +27,26 @@ struct starfive_vf2_pro { const char *value; }; +static const struct starfive_vf2_pro milk_v_mars[] = { + {"/soc/ethernet@16030000", "starfive,tx-use-rgmii-clk", NULL}, + {"/soc/ethernet@16040000", "starfive,tx-use-rgmii-clk", NULL}, + + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "motorcomm,tx-clk-adj-enabled", NULL}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "motorcomm,tx-clk-100-inverted", NULL}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "motorcomm,tx-clk-1000-inverted", NULL}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "motorcomm,rx-clk-drv-microamp", "3970"}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "motorcomm,rx-data-drv-microamp", "2910"}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "rx-internal-delay-ps", "1900"}, + {"/soc/ethernet@16030000/mdio/ethernet-phy@0", + "tx-internal-delay-ps", "1500"}, +}; + static const struct starfive_vf2_pro starfive_vera[] = { {"/soc/ethernet@16030000/mdio/ethernet-phy@0", "rx-internal-delay-ps", "1900"}, @@ -67,6 +87,49 @@ static const struct starfive_vf2_pro starfive_verb[] = { "tx-internal-delay-ps", "0"}, }; +void spl_fdt_fixup_mars(void *fdt) +{ + static const char compat[] = "milkv,mars\0starfive,jh7110"; + u32 phandle; + u8 i; + int offset; + int ret; + + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat, sizeof(compat)); + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", + "Milk-V Mars"); + + /* gmac0 */ + offset = fdt_path_offset(fdt, "/soc/clock-controller@17000000"); + phandle = fdt_get_phandle(fdt, offset); + offset = fdt_path_offset(fdt, "/soc/ethernet@16030000"); + + fdt_setprop_u32(fdt, offset, "assigned-clocks", phandle); + fdt_appendprop_u32(fdt, offset, "assigned-clocks", JH7110_AONCLK_GMAC0_TX); + fdt_setprop_u32(fdt, offset, "assigned-clock-parents", phandle); + fdt_appendprop_u32(fdt, offset, "assigned-clock-parents", + JH7110_AONCLK_GMAC0_RMII_RTX); + + /* gmac1 */ + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/soc/ethernet@16040000"), + "status", "disabled"); + + for (i = 0; i < ARRAY_SIZE(milk_v_mars); i++) { + offset = fdt_path_offset(fdt, milk_v_mars[i].path); + + if (starfive_verb[i].value) + ret = fdt_setprop_u32(fdt, offset, milk_v_mars[i].name, + dectoul(milk_v_mars[i].value, NULL)); + else + ret = fdt_setprop_empty(fdt, offset, milk_v_mars[i].name); + + if (ret) { + pr_err("%s set prop %s fail.\n", __func__, milk_v_mars[i].name); + break; + } + } +} + void spl_fdt_fixup_version_a(void *fdt) { static const char compat[] = "starfive,visionfive-2-v1.2a\0starfive,jh7110"; @@ -167,22 +230,34 @@ void spl_fdt_fixup_version_b(void *fdt) void spl_perform_fixups(struct spl_image_info *spl_image) { u8 version; + const char *product_id; - version = get_pcb_revision_from_eeprom(); - switch (version) { - case 'a': - case 'A': - spl_fdt_fixup_version_a(spl_image->fdt_addr); - break; - - case 'b': - case 'B': - default: - spl_fdt_fixup_version_b(spl_image->fdt_addr); + product_id = get_product_id_from_eeprom(); + if (!product_id) { + pr_err("Can't read EEPROM\n"); + return; + } + 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(); + switch (version) { + case 'a': + case 'A': + spl_fdt_fixup_version_a(spl_image->fdt_addr); + break; + + case 'b': + case 'B': + default: + spl_fdt_fixup_version_b(spl_image->fdt_addr); break; + }; + } else { + pr_err("Unknown product %s\n", product_id); }; - /* Update the memory size which read form eeprom or DT */ + /* Update the memory size which read from eeprom or DT */ fdt_fixup_memory(spl_image->fdt_addr, 0x40000000, gd->ram_size); }
The differences between the Milk-V Mars board and the VisionFive 2 board are small enough that we can support both using the same U-Boot build. * The model and compatible property are taken from proposed Linux patches. * The EEPROM is atmel,24c02 according to the vendor U-Boot. * The second Ethernet port is not available. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> --- v2: do not overwrite /soc/i2c@12050000/eeprom@50/compatible --- board/starfive/visionfive2/spl.c | 99 ++++++++++++++++++++++++++++---- 1 file changed, 87 insertions(+), 12 deletions(-)