Skip to contentSkip to conversation

ARM: dts: phyBOARD-WEGA-AM335x updates

PATCH New Teresa Remmet 5 participants 17 messages Jan 5, 2017 – Jan 6, 2017

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover ARM: dts: phyBOARD-WEGA-AM335x updates

Set of small patches to update the device tree of the phyCORE-AM335x SOM and phyBOARD-WEGA-AM335x.

Teresa Remmet (6):
ARM: dts: am335x-phycore-som: Update NAND partition table
ARM: dts: am335x-phycore-som: Update compatible string for spi nor
ARM: dts: am335x-phycore-som: Add i2c temp sensor
ARM: dts: am335x-wega: Set USB0 mode to otg
ARM: dts: am335x-phycore-som: Update ethernet phy node
ARM: dts: am335x-wega: Update ethernet phy node

 arch/arm/boot/dts/am335x-phycore-som.dtsi | 30 +++++++++++++++++++-----------
 arch/arm/boot/dts/am335x-wega.dtsi        |  9 +++++++--
 2 files changed, 26 insertions(+), 13 deletions(-)
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)
arch/arm/boot/dts/am335x-phycore-som.dtsi +7 -9
index 75e24ad..ef3fe5a 100644
@@ -222,21 +222,19 @@
 			label = "barebox";
 			reg = <0x80000 0x80000>;
 		};
+
 		partition at 5 {
-			label = "bareboxenv";
-			reg = <0x100000 0x40000>;
+			label = "barebox_backup";
+			reg = <0x100000 0x80000>;
 		};
+
 		partition at 6 {
-			label = "oftree";
-			reg = <0x140000 0x40000>;
+			label = "bareboxenv";
+			reg = <0x180000 0x40000>;
 		};
 		partition at 7 {
-			label = "kernel";
-			reg = <0x180000 0x800000>;
-		};
-		partition at 8 {
 			label = "root";
-			reg = <0x980000 0x0>;
+			reg = <0x1C0000 0x0>;
 		};
 	};
 };
Signature · 1 line
1.9.1
#2 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 3 lines · Teresa Remmet

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Regards,

Tony

#3 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 9 lines · Tony Lindgren
Quoted 3 lines · Teresa Remmet

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

The rest of the series looks fine to me so applying it into omap-for-v4.11/dt.

Cheers,

Tony

#4 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 6 lines · Tony Lindgren
Quoted 5 lines · Tony Lindgren
Quoted 3 lines · Teresa Remmet

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

Quoted 7 lines
Quoted 4 lines

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I don't have much context for this thread, and no I don't plan to solve your problems for you. But I can provide tips!

Quoted 3 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree. And it's just dumb once that gets codified in the kernel source tree.

The best solution would be to try to migrate away from static device tree representations of partition info entirely. UBI volumes are best where possible. If not, then some other kind of on-flash data structures (along the lines of a GPT) with a corresponding MTD partition parser is an OK alternative. Unfortunately, there isn't any good standard format for this on MTD, so it's typically all custom -- and so people use the easiest approach: device tree. And it's even more difficult with NAND, which has reliability problems, especially with static data (e.g., read disturb).

Anyway, the parser solution is helpful only if one can properly fix the "flag day" first. And it requires a little bit more work to be generally useful; I posted some work for this over a year ago, but bikeshedding brought it down.

Quoted 2 lines

The rest of the series looks fine to me so applying it into omap-for-v4.11/dt.

Brian

#5 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Hello Brian,

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 23 lines · Tony Lindgren
Quoted 8 lines · Tony Lindgren
Quoted 6 lines · Teresa Remmet
Quoted 4 lines

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

Quoted 6 lines
Quoted 4 lines

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!

Quoted 4 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

Quoted 7 lines

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup,? if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

I will send patches for this.

Regards,
Teresa

Quoted 32 lines

The best solution would be to try to migrate away from static device tree representations of partition info entirely. UBI volumes are best where possible. If not, then some other kind of on-flash data structures
(along the lines of a GPT) with a corresponding MTD partition parser is
an OK alternative. Unfortunately, there isn't any good standard format
for this on MTD, so it's typically all custom -- and so people use the
easiest approach: device tree. And it's even more difficult with NAND,
which has reliability problems, especially with static data (e.g., read
disturb).

Anyway, the parser solution is helpful only if one can properly fix the
"flag day" first. And it requires a little bit more work to be generally
useful; I posted some work for this over a year ago, but bikeshedding brought it down.

Quoted 3 lines

The rest of the series looks fine to me so applying it into omap-for-v4.11/dt.

Brian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#6 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 34 lines · Teresa Remmet

Hello Brian,

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 23 lines · Tony Lindgren
Quoted 8 lines · Tony Lindgren
Quoted 6 lines · Teresa Remmet
Quoted 4 lines

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

Quoted 6 lines
Quoted 4 lines

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!

Quoted 4 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

Quoted 7 lines

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

Quoted 7 lines

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup,? if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

I will send patches for this.

OK thanks! Also thank you Brian for your comments.

Regards,

Tony

#7 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 41 lines · Tony Lindgren
Quoted 40 lines · Teresa Remmet

Hello Brian,

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 23 lines · Tony Lindgren
Quoted 8 lines · Tony Lindgren
Quoted 6 lines · Teresa Remmet
Quoted 4 lines

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

Quoted 6 lines
Quoted 4 lines

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!

Quoted 4 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

Quoted 7 lines

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup, if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

Quoted 4 lines
Quoted 1 line

I will send patches for this.

OK thanks! Also thank you Brian for your comments.

Tony - I tested leaving the partition info as-is with the updates from the bootloader and it works. Would you prefer that I match Brian and remove the partition table completely, or should I just leave my board alone?

I am good either way.

Quoted 3 lines

Regards,

Tony

adam

#8 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 47 lines · Adam Ford
Quoted 41 lines · Tony Lindgren
Quoted 40 lines · Teresa Remmet

Hello Brian,

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 23 lines · Tony Lindgren
Quoted 8 lines · Tony Lindgren
Quoted 6 lines · Teresa Remmet
Quoted 4 lines

To improve NAND safety we updated the partition layout. Added barebox backup partition and removed kernel and oftree partition. They are kept in ubi now.

Quoted 6 lines
Quoted 4 lines

What about the users with earlier partition tables?

Please read about "flag day" changes, typically they are not acceptable.

Adding Brian and Adam to Cc. Can you guys come up with some solution on this?

I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!

Quoted 4 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

Quoted 7 lines

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup, if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

Quoted 4 lines
Quoted 1 line

I will send patches for this.

OK thanks! Also thank you Brian for your comments.

Quoted 6 lines

Tony - I tested leaving the partition info as-is with the updates from the bootloader and it works. Would you prefer that I match Brian and remove the partition table completely, or should I just leave my board alone?

I am good either way.

OK. How about let's remove the partitions from kernel for v4.11 as clean-up then for cases where the bootloader might change them?

Regards,

Tony

#9 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Adam Ford
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Teresa Remmet

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 11 lines · Tony Lindgren
Quoted 3 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup, if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

Ah, well if these are essentially just a backup, then why do they need changed at all? To be more precise about my "dumb" statement: it seems unwise to assume that all systems using a particular board will have the same partition layout. So *relying* on the in-kernel DTS(I) files to have a universal partition layout would likely cause problems.

I don't have much problem with keeping a sample layout there as a backup, if you find it useful. But it seems like it will be hard to argue that you can ever change it in the future.

Anyway, the ofpart mechanism is there, and it's fine to use it, but it's up to you to understand the implications and manage the backwards compatibility problems :)

Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
Quoted 1 line

I will send patches for this.

OK thanks! Also thank you Brian for your comments.

Tony - I tested leaving the partition info as-is with the updates from the bootloader and it works. Would you prefer that I match Brian and remove the partition table completely, or should I just leave my board alone?

Quoted 4 lines
Quoted 1 line

I am good either way.

OK. How about let's remove the partitions from kernel for v4.11 as clean-up then for cases where the bootloader might change them?

I don't have much stake in this but...if there were any systems using the backup layout (i.e., the in-kernel partition layout), wouldn't that break them? Is there a problem with just leaving them alone?

Brian

#10 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

Quoted 47 lines · Brian Norris
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Adam Ford
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Teresa Remmet

Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:

Quoted 11 lines · Tony Lindgren
Quoted 3 lines

I'm suggesting we leave the kernel nodes empty and let u-boot populate them, so maybe you guys can discuss this on the related lists.

That's an option. I've worked with platforms that did something like this, and that's really one of the only ways you can handle putting partition information in the device tree. You're really hamstringing yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

In our case the bootloader does pass the partition table to the kernel. So it gets overwritten anyway. This was just more for backup, if someone uses a different bootloader. But I'm fine with removing the nand partition table completely from the kernel device tree. Same with the SPI nor partition table.

Ah, well if these are essentially just a backup, then why do they need changed at all? To be more precise about my "dumb" statement: it seems unwise to assume that all systems using a particular board will have the same partition layout. So *relying* on the in-kernel DTS(I) files to have a universal partition layout would likely cause problems.

I don't have much problem with keeping a sample layout there as a backup, if you find it useful. But it seems like it will be hard to argue that you can ever change it in the future.

Anyway, the ofpart mechanism is there, and it's fine to use it, but it's up to you to understand the implications and manage the backwards compatibility problems :)

Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
Quoted 1 line

I will send patches for this.

OK thanks! Also thank you Brian for your comments.

Tony - I tested leaving the partition info as-is with the updates from the bootloader and it works. Would you prefer that I match Brian and remove the partition table completely, or should I just leave my board alone?

Quoted 8 lines
Quoted 4 lines
Quoted 1 line

I am good either way.

OK. How about let's remove the partitions from kernel for v4.11 as clean-up then for cases where the bootloader might change them?

I don't have much stake in this but...if there were any systems using the backup layout (i.e., the in-kernel partition layout), wouldn't that break them? Is there a problem with just leaving them alone?

Yeah I guess it depends on the device and it's bootloader versions.

Regards,

Tony

#11 lore raw

PATCH 1/6 ARM: dts: am335x-phycore-som: Update NAND partition table

In reply to Brian Norris

On Thu, Jan 05, 2017 at 09:56:20AM -0800, Brian Norris wrote:
[snip]

Quoted 9 lines

The best solution would be to try to migrate away from static device tree representations of partition info entirely. UBI volumes are best where possible. If not, then some other kind of on-flash data structures (along the lines of a GPT) with a corresponding MTD partition parser is an OK alternative. Unfortunately, there isn't any good standard format for this on MTD, so it's typically all custom -- and so people use the easiest approach: device tree. And it's even more difficult with NAND, which has reliability problems, especially with static data (e.g., read disturb).

Just as a side note, there is some work in this area:
https://www.mail-archive.com/u-boot at lists.denx.de/msg232759.html

Quoted 4 lines

Anyway, the parser solution is helpful only if one can properly fix the "flag day" first. And it requires a little bit more work to be generally useful; I posted some work for this over a year ago, but bikeshedding brought it down.

Best regards,
ladis

#12 lore raw

PATCH 2/6 ARM: dts: am335x-phycore-som: Update compatible string for spi nor

In reply to Teresa Remmet

As we may have different SPI NOR flashes with 8MB populated on phyCORE-AM335x SOM, set the "jedec,spi-nor" SPI Flash compatible string.

---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/am335x-phycore-som.dtsi +1 -1
index ef3fe5a..8060ce5 100644
@@ -339,7 +339,7 @@
 	status = "okay";
 
 	serial_flash: m25p80 at 0 {
-		compatible = "m25p80";
+		compatible = "jedec,spi-nor";
 		spi-max-frequency = <48000000>;
 		reg = <0x0>;
 		m25p,fast-read;
Signature · 1 line
1.9.1
#13 lore raw

PATCH 3/6 ARM: dts: am335x-phycore-som: Add i2c temp sensor

In reply to Teresa Remmet

Include the i2c temperature sensor which is optionaly mounted on the phyCORE-AM335x-R2 module.

---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/boot/dts/am335x-phycore-som.dtsi +6 -0
index 8060ce5..08d1134 100644
@@ -120,6 +120,12 @@
 		reg = <0x2d>;
 	};
 
+	i2c_tmp102: temp at 4b {
+		compatible = "ti,tmp102";
+		reg = <0x4b>;
+		status = "disabled";
+	};
+
 	i2c_eeprom: eeprom at 52 {
 		compatible = "atmel,24c32";
 		pagesize = <32>;
Signature · 1 line
1.9.1
#14 lore raw

PATCH 4/6 ARM: dts: am335x-wega: Set USB0 mode to otg

In reply to Teresa Remmet

Set USB0 to otg mode (default) and not fix to peripheral. As it can be used in host mode also.

---
 arch/arm/boot/dts/am335x-wega.dtsi | 1 -
 1 file changed, 1 deletion(-)
arch/arm/boot/dts/am335x-wega.dtsi +0 -1
index 02c6736..e97fd6d 100644
@@ -206,7 +206,6 @@
 };
 
 &usb0 {
-	dr_mode = "peripheral";
 	status = "okay";
 };
 
Signature · 1 line
1.9.1
#15 lore raw

PATCH 5/6 ARM: dts: am335x-phycore-som: Update ethernet phy node

In reply to Teresa Remmet

Update ethernet phy0 node to use phy-handle now.

---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
arch/arm/boot/dts/am335x-phycore-som.dtsi +5 -1
index 08d1134..de91275 100644
@@ -78,7 +78,7 @@
 };
 
 &cpsw_emac0 {
-	phy_id = <&davinci_mdio>, <0>;
+	phy-handle = <&phy0>;
 	phy-mode = "rmii";
 	dual_emac_res_vlan = <1>;
 };
@@ -87,6 +87,10 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&mdio_pins>;
 	status = "okay";
+
+	phy0: ethernet-phy at 0 {
+		reg = <0>;
+	};
 };
 
 &mac {
Signature · 1 line
1.9.1
#16 lore raw

PATCH 6/6 ARM: dts: am335x-wega: Update ethernet phy node

In reply to Teresa Remmet

Update ethernet phy1 node to use phy-handle now.

---
 arch/arm/boot/dts/am335x-wega.dtsi | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
arch/arm/boot/dts/am335x-wega.dtsi +7 -1
index e97fd6d..8ce5417 100644
@@ -119,11 +119,17 @@
 };
 
 &cpsw_emac1 {
-	phy_id = <&davinci_mdio>, <1>;
+	phy-handle = <&phy1>;
 	phy-mode = "mii";
 	dual_emac_res_vlan = <2>;
 };
 
+&davinci_mdio {
+	phy1: ethernet-phy at 1 {
+		reg = <1>;
+	};
+};
+
 &mac {
 	slaves = <2>;
 	pinctrl-names = "default";
Signature · 1 line
1.9.1