diff mbox series

[RFC,3/5] board: starfive: support Milk-V Mars board

Message ID 20240303130122.29983-4-heinrich.schuchardt@canonical.com
State RFC
Delegated to: Andes
Headers show
Series riscv: add support for Milk-V Mars board | expand

Commit Message

Heinrich Schuchardt March 3, 2024, 1:01 p.m. UTC
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>
---
 board/starfive/visionfive2/spl.c | 101 +++++++++++++++++++++++++++----
 1 file changed, 89 insertions(+), 12 deletions(-)

Comments

E Shattow March 7, 2024, 11:03 p.m. UTC | #1
On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt <
heinrich.schuchardt@canonical.com> wrote:
...

> * The EEPROM is atmel,24c02 according to the vendor U-Boot.
>
...

The same vendor (Milk-V) U-Boot change is present on their branch for Mars
CM Lite (which despite the naming has more in common with Pine64 Star64
than Mars); However on visual inspection the silkscreen markings are for
24c04. See: [Photo flatbed scans of Mars CM Lite 4GB rev 1.01](
https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1872478605).
Can this be determined at runtime, or I must trust that this is not a
wrongly marked chip?
E Shattow March 8, 2024, 2:06 a.m. UTC | #2
P.S. Found the longer description at
https://github.com/milkv-mars/mars-buildroot-sdk/commit/d381610c92827de01b25843786012351b3f35519
as follows: "if configured as 24c04, its address will occupy 0x51,
conflicting with the RTC chip pcf85063 on the IO-Board. Refer to:
Documentation/misc-devices/eeprom.rst". What does that even mean, it is for
Raspberry Pi Compute IO carrier only?

On Thu, Mar 7, 2024 at 3:03 PM E Shattow <lucent@gmail.com> wrote:

>
> On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt <
> heinrich.schuchardt@canonical.com> wrote:
> ...
>
>> * The EEPROM is atmel,24c02 according to the vendor U-Boot.
>>
> ...
>
> The same vendor (Milk-V) U-Boot change is present on their branch for Mars
> CM Lite (which despite the naming has more in common with Pine64 Star64
> than Mars); However on visual inspection the silkscreen markings are for
> 24c04. See: [Photo flatbed scans of Mars CM Lite 4GB rev 1.01](
> https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1872478605).
> Can this be determined at runtime, or I must trust that this is not a
> wrongly marked chip?
>
Heinrich Schuchardt March 8, 2024, 3:20 a.m. UTC | #3
On 3/8/24 03:06, E Shattow wrote:
> P.S. Found the longer description at 
> https://github.com/milkv-mars/mars-buildroot-sdk/commit/d381610c92827de01b25843786012351b3f35519 <https://github.com/milkv-mars/mars-buildroot-sdk/commit/d381610c92827de01b25843786012351b3f35519> as follows: "if configured as 24c04, its address will occupy 0x51, conflicting with the RTC chip pcf85063 on the IO-Board. Refer to: Documentation/misc-devices/eeprom.rst". What does that even mean, it is for Raspberry Pi Compute IO carrier only?

According to
https://ww1.microchip.com/downloads/en/devicedoc/doc0180.pdf
the chips differ in how their address lines are used. Either they select 
a chip or a memory address.

The chip is at reg 0x50. So it could be that if you read the upper 
memory of atmel,24c04 it would use reg 0x51.

https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf says the 
CM4IO board has an RTC at address 0x51.

Together with the commit message this really sounds like the smaller 
chip size is faked due to incompatibility.

As you mentioned to have access to a CM module I would like to know what 
its serial number looks like to understand what if it can be used to 
detect if we are running U-Boot on full board or a CM module.

For my Milk-V board I have:

MARS-V11-2340-D008E000-xxxxxxxx

Best regards

Heinrich
Heinrich Schuchardt March 8, 2024, 3:38 a.m. UTC | #4
On 3/8/24 04:20, Heinrich Schuchardt wrote:
> On 3/8/24 03:06, E Shattow wrote:
>> P.S. Found the longer description at 
>> https://github.com/milkv-mars/mars-buildroot-sdk/commit/d381610c92827de01b25843786012351b3f35519 <https://github.com/milkv-mars/mars-buildroot-sdk/commit/d381610c92827de01b25843786012351b3f35519> as follows: "if configured as 24c04, its address will occupy 0x51, conflicting with the RTC chip pcf85063 on the IO-Board. Refer to: Documentation/misc-devices/eeprom.rst". What does that even mean, it is for Raspberry Pi Compute IO carrier only?
> 
> According to
> https://ww1.microchip.com/downloads/en/devicedoc/doc0180.pdf
> the chips differ in how their address lines are used. Either they select 
> a chip or a memory address.
> 
> The chip is at reg 0x50. So it could be that if you read the upper 
> memory of atmel,24c04 it would use reg 0x51.
> 
> https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf says the 
> CM4IO board has an RTC at address 0x51.
> 
> Together with the commit message this really sounds like the smaller 
> chip size is faked due to incompatibility.

Running i2cdetect on my Mars Milk-V board shows that a device is 
responding to address 0x51:

$ sudo i2cdetect 5
I will probe file /dev/i2c-5.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- UU --
40:
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:

> 
> As you mentioned to have access to a CM module I would like to know what 
> its serial number looks like to understand what if it can be used to 
> detect if we are running U-Boot on full board or a CM module.
> 
> For my Milk-V board I have:
> 
> MARS-V11-2340-D008E000-xxxxxxxx
> 
> Best regards
> 
> Heinrich
> 
> 
> 
> 
> 
> 
>
Heinrich Schuchardt March 8, 2024, 9:08 a.m. UTC | #5
On 08.03.24 00:03, E Shattow wrote:
> 
> On Sun, Mar 3, 2024 at 5:02 AM Heinrich Schuchardt 
> <heinrich.schuchardt@canonical.com 
> <mailto:heinrich.schuchardt@canonical.com>> wrote:
> ...
> 
>     * The EEPROM is atmel,24c02 according to the vendor U-Boot.
> 
> ...
> 
> The same vendor (Milk-V) U-Boot change is present on their branch for 
> Mars CM Lite (which despite the naming has more in common with Pine64 
> Star64 than Mars); However on visual inspection the silkscreen markings 
> are for 24c04. See: [Photo flatbed scans of Mars CM Lite 4GB rev 
> 1.01](https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1872478605 <https://github.com/geerlingguy/sbc-reviews/issues/22#issuecomment-1872478605>). Can this be determined at runtime, or I must trust that this is not a wrongly marked chip?


On the Milk-V Mars there is a chip marked "24C04F 21626P" like on the 
photo on the CM module from the thread above. This should be the EEPROM.

In some datasheets F is appended to mark the voltage range.

So this atmel,24c02 change seems really only be relevant if you have a 
CM module on a baseboard with an RTC at 0x51.

Best regards

Heinrich
diff mbox series

Patch

diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index 1b49945d11b..c62624a2eb5 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,51 @@  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");
+	fdt_setprop_string(fdt, fdt_path_offset(fdt, "/soc/i2c@12050000/eeprom@50"),
+			   "compatible", "atmel,24c02");
+
+	/* 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 +232,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);
 }