Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
>
> 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@1010 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:
> >
> > {
> > dr_mode = "peripheral";
> > status = "okay";
> > };
>
> Thanks Aurelien for the explanation.
>
> The node usb@1010 (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@1010 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
> >
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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@1010 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:
{
dr_mode = "peripheral";
status = "okay";
};
Thanks Aurelien for the explanation.
The node usb@1010 (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
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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@1010 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:
{
dr_mode = "peripheral";
status = "okay";
};
This does not appear on the patches submitted on the Linux side for the MilkV
Mars.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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@1010 and usb@0 in the kernel device-tree. Best regards Heinrich Aurelien [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszh...@kernel.org/T/
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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 = < 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-jszh...@kernel.org/T/ > > >
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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
> ---
> v2:
> do not overwrite /soc/i2c@1205/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@1700");
> + phandle = fdt_get_phandle(fdt, offset);
> + offset = fdt_path_offset(fdt, "/soc/ethernet@1603");
> +
> + 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@1604"),
> +"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;
> + }
> + }
> +}
> +
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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 = < 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-jszh...@kernel.org/T/
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
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-jszh...@kernel.org/T/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
[PATCH v2 4/6] board: starfive: support Milk-V Mars board
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
---
v2:
do not overwrite /soc/i2c@1205/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
@@ -27,6 +27,26 @@ struct starfive_vf2_pro {
const char *value;
};
+static const struct starfive_vf2_pro milk_v_mars[] = {
+ {"/soc/ethernet@1603", "starfive,tx-use-rgmii-clk", NULL},
+ {"/soc/ethernet@1604", "starfive,tx-use-rgmii-clk", NULL},
+
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "motorcomm,tx-clk-adj-enabled", NULL},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "motorcomm,tx-clk-100-inverted", NULL},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "motorcomm,tx-clk-1000-inverted", NULL},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "motorcomm,rx-clk-drv-microamp", "3970"},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "motorcomm,rx-data-drv-microamp", "2910"},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "rx-internal-delay-ps", "1900"},
+ {"/soc/ethernet@1603/mdio/ethernet-phy@0",
+ "tx-internal-delay-ps", "1500"},
+};
+
static const struct starfive_vf2_pro starfive_vera[] = {
{"/soc/ethernet@1603/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@1700");
+ phandle = fdt_get_phandle(fdt, offset);
+ offset = fdt_path_offset(fdt, "/soc/ethernet@1603");
+
+ 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@1604"),
+ "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);
+
