arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +1 -0

@@ -86,4 +86,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */

Quoted 21 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +0 -0

@@ -86,4 +86,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 

include/configs/socfpga_de0_nano_soc.h line 99

Quoted 11 lines

include/configs/socfpga_de0_nano_soc.h +11 -0

+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		\
+				"16m(rootfs),"		\
+				"-(UBI)\0"
+#endif

Does Atlas have a dedicated QSPI NOR ?

Quoted 24 lines · Marek Vasut

Quoted 23 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +0 -0

@@ -86,4 +86,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 

Quoted 13 lines

include/configs/socfpga_de0_nano_soc.h line 99

Quoted 11 lines

include/configs/socfpga_de0_nano_soc.h +11 -0

+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		\
+				"16m(rootfs),"		\
+				"-(UBI)\0"
+#endif

Does Atlas have a dedicated QSPI NOR ?

No, it does not.

Quoted 43 lines · Dinh Nguyen

Quoted 41 lines · Marek Vasut

Quoted 35 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +8 -0

@@ -86,4 +86,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		

\

include/configs/socfpga_de0_nano_soc.h +1 -0

+				"16m(rootfs),"		

\

include/configs/socfpga_de0_nano_soc.h line 99

Quoted 2 lines

include/configs/socfpga_de0_nano_soc.h +2 -0

+				"-(UBI)\0"
+#endif

Does Atlas have a dedicated QSPI NOR ?

Quoted 1 line

No, it does not.

Do you now understand why I have every single mainline SoCFPGA board in my
collection and why I am eagerly waiting for my first Arria 10 project ? :)

Best regards,
Marek Vasut

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

include/configs/socfpga_de0_nano_soc.h +3 -0

index 16e146c..c42175d 100644
@@ -86,4 +86,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\

Quoted 36 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +12 -0

@@ -86,4 +86,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		\
+				"16m(rootfs),"		\
+				"-(UBI)\0"
+#endif
+

Quoted 1 line

#endif /* __CONFIG_TERASIC_DE0_H__ */

Ok, three copies of the same table. Should it go to socfpga common? You could at least do

MTDPARTS_DEFAULT_SOCDK

and then use

#define MTDPARTS_DEFAULT MTDPARTS_DEFAULT_SOCDK

in the socfpga_de0_nano_soc.h, so we don't have 3 copies of the same table.

Quoted 45 lines · Pavel Machek

Quoted 37 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644

include/configs/socfpga_de0_nano_soc.h +12 -0

@@ -86,4 +86,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		\
+				"16m(rootfs),"		\
+				"-(UBI)\0"
+#endif
+

Quoted 1 line

#endif /* __CONFIG_TERASIC_DE0_H__ */

Ok, three copies of the same table. Should it go to socfpga common? You could at least do

MTDPARTS_DEFAULT_SOCDK

Quoted 7 lines

and then use

#define MTDPARTS_DEFAULT MTDPARTS_DEFAULT_SOCDK

in the socfpga_de0_nano_soc.h, so we don't have 3 copies of the same
table.

I'd rather suggest to do something like

#ifndef MTDPARTS_DEFAULT
#define ...
#endif

in socfpga_common.h . Even better would obviously be if we could just scrap
this altogether and parse the MTD layout from OF. I dunno if we can do that
nowadays, but that'd be great.

Best regards,
Marek Vasut

Quoted 25 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

include/configs/socfpga_de0_nano_soc.h +3 -0

index 16e146c..c42175d 100644
@@ -86,4 +86,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)
+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\

include/configs/socfpga_de0_nano_soc.h line 101

Quoted 10 lines

include/configs/socfpga_de0_nano_soc.h +9 -0

+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\
+				"256k(boot),"		\
+				"16m(kernel),"		\
+				"16m(rootfs),"		\
+				"-(UBI)\0"
+#endif
+
 #endif	/* __CONFIG_TERASIC_DE0_H__ */

Ok, three copies of the same table. Should it go to socfpga common? You could at least do

MTDPARTS_DEFAULT_SOCDK

and then use

#define MTDPARTS_DEFAULT MTDPARTS_DEFAULT_SOCDK

in the socfpga_de0_nano_soc.h, so we don't have 3 copies of the same table.

Pavel

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_mcvevk.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_mcvevk.h index d051eec..a176a21 100644

include/configs/socfpga_mcvevk.h +2 -0

@@ -134,4 +134,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_sockit.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_sockit.h index 5bcee05..a516e5d 100644

include/configs/socfpga_sockit.h +1 -0

@@ -91,4 +91,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_socrates.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_socrates.h index 16a2a86..7b48afa 100644

include/configs/socfpga_socrates.h +1 -0

@@ -92,4 +92,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 
+/* mtd partitioning for serial NOR flash */

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644

include/configs/socfpga_cyclone5_socdk.h +3 -1

+				"-(UBI)\0"
+#endif
+
 #endif	/* __CONFIG_SOCFPGA_CYCLONE5_H__ */
--

1.9.2.468.g3f0c02a

Quoted 22 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---
 include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644

include/configs/socfpga_cyclone5_socdk.h +0 -0

@@ -96,4 +96,16 @@
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 

include/configs/socfpga_cyclone5_socdk.h line 100

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +2 -0

+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)

Is this the default Altera layout ?

include/configs/socfpga_cyclone5_socdk.h line 104

Quoted 5 lines

include/configs/socfpga_cyclone5_socdk.h +4 -0

+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\

What happens if the DT grows over 64k ?

include/configs/socfpga_cyclone5_socdk.h line 105

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"256k(boot),"		\

256k is not enough for U-Boot (considering this is U-Boot).

include/configs/socfpga_cyclone5_socdk.h line 107

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +2 -0

+				"16m(kernel),"		\
+				"16m(rootfs),"		\

Why don't you put kernel and rootfs onto the UBI volume instead ?

Quoted 7 lines

include/configs/socfpga_cyclone5_socdk.h +3 -1

+				"-(UBI)\0"
+#endif
+
 #endif	/* __CONFIG_SOCFPGA_CYCLONE5_H__ */
--

1.9.2.468.g3f0c02a

Best regards,
Marek Vasut

Quoted 25 lines · Marek Vasut

Quoted 24 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644

include/configs/socfpga_cyclone5_socdk.h +0 -0

@@ -96,4 +96,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h line 100

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +2 -0

+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)

Is this the default Altera layout ?

Yah but believe it need to be updated

Quoted 6 lines

include/configs/socfpga_cyclone5_socdk.h line 104

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h +4 -0

+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\

What happens if the DT grows over 64k ?

Hmmm rethinking of this, I will make Linux dtb, U-Boot and kernel as part of one big UBI partition called boot.

Quoted 3 lines

include/configs/socfpga_cyclone5_socdk.h line 105

Quoted 1 line

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"256k(boot),"		\

256k is not enough for U-Boot (considering this is U-Boot).

Will create boot region to avoid worrying the size issue

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h line 107

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +2 -0

+				"16m(kernel),"		\
+				"16m(rootfs),"		\

Why don't you put kernel and rootfs onto the UBI volume instead ?

Yup, kernel will go into boot partition. It will be separated from rootfs as user might choose nfs.

Quoted 28 lines · Chin Liang See

Quoted 27 lines · Marek Vasut

Quoted 25 lines · Chin Liang See

Enabling mtd partitioning layout which indicate partition for various boot partition

Signed-off-by Chin Liang See <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Dinh Nguyen <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Stefan Roese <[email protected]>

---

 include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(quoted diff) +0 -0

b/include/configs/socfpga_cyclone5_socdk.h index
67bb35f..e4a1657
100644

include/configs/socfpga_cyclone5_socdk.h +0 -0

@@ -96,4 +96,16 @@
 
 /* The rest of the configuration is shared */
 #include <configs/socfpga_common.h>
 

Quoted 6 lines

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h line 100

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +2 -0

+/* mtd partitioning for serial NOR flash */
+#if defined(CONFIG_CMD_UBI) || defined(CONFIG_CMD_SF)

Is this the default Altera layout ?

Yah but believe it need to be updated

So you're not worried about compatibility I presume ?

Quoted 11 lines

Quoted 7 lines

include/configs/socfpga_cyclone5_socdk.h line 104

Quoted 5 lines

include/configs/socfpga_cyclone5_socdk.h +4 -0

+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\

What happens if the DT grows over 64k ?

Hmmm rethinking of this, I will make Linux dtb, U-Boot and kernel as
part of one big UBI partition called boot.

I am using this sort of layout on SoCkit internally:

        "mtdparts=ff705000.spi:"                \
                "1m(u-boot),"                   \
                "64k(env1),"                    \
                "64k(env2),"                    \
                "-(UBI)\0"

I have two environment blocks to implement redundant env, which is useful
when deploying the system. It makes the system slightly more resilient
against problems of aging flash.

Quoted 14 lines

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h line 105

Quoted 2 lines

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"256k(boot),"		\

256k is not enough for U-Boot (considering this is U-Boot).

Will create boot region to avoid worrying the size issue

Quoted 6 lines

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"16m(kernel),"		

\

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"16m(rootfs),"		

\

Why don't you put kernel and rootfs onto the UBI volume instead ?

Quoted 2 lines

Yup, kernel will go into boot partition. It will be separated from rootfs as user might choose nfs.

Can you share the final layout before you roll out patches ?

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

Is this the default Altera layout ?

Yah but believe it need to be updated

So you're not worried about compatibility I presume ?

I still need to care of compatiblity. Some of them will break due to size increase. But through the use of partition name and environment, user will be abstracted from this.

Quoted 14 lines

Quoted 10 lines

Quoted 6 lines

include/configs/socfpga_cyclone5_socdk.h line 104

Quoted 4 lines

include/configs/socfpga_cyclone5_socdk.h +4 -0

+#define MTDPARTS_DEFAULT	"mtdparts=ff705000.spi:"\
+				"256k(spl),"		\
+				"64k(env),"		\
+				"64k(dtb),"		\

What happens if the DT grows over 64k ?

Hmmm rethinking of this, I will make Linux dtb, U-Boot and kernel as
part of one big UBI partition called boot.

I am using this sort of layout on SoCkit internally:

        "mtdparts=ff705000.spi:"                \

Quoted 4 lines

                "1m(u-boot),"                   \
                "64k(env1),"                    \
                "64k(env2),"                    \
                "-(UBI)\0"

Hmmm I didn't see the area for SPL. Wonder is it part of u-boot partition?

Quoted 5 lines

I have two environment blocks to implement redundant env, which is useful
when deploying the system. It makes the system slightly more resilient
against problems of aging flash.

Nice thought, will increase the environment partition to 256kB to cater this.

Quoted 13 lines

Quoted 13 lines

Quoted 3 lines

include/configs/socfpga_cyclone5_socdk.h line 105

Quoted 1 line

include/configs/socfpga_cyclone5_socdk.h +1 -0

+				"256k(boot),"		\

256k is not enough for U-Boot (considering this is U-Boot).

Will create boot region to avoid worrying the size issue

Quoted 6 lines

Quoted 4 lines

(quoted diff) +1 -0

+				"16m(kernel),"

\

(quoted diff) +1 -0

+				"16m(rootfs),"

\

Why don't you put kernel and rootfs onto the UBI volume instead ?

Quoted 4 lines

Quoted 2 lines

Yup, kernel will go into boot partition. It will be separated from rootfs as user might choose nfs.

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

The new one would like this
256k(spl)

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

The environment will be used to determine the image offset for mentioned boot images from boot partition.

Thanks
Chin Liang

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:

Quoted 12 lines

Quoted 1 line

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 4 lines

256k(env)
15872k(boot)
16m(rootfs)

Quoted 2 lines

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two UBI volumes ?

Quoted 6 lines

The environment will be used to determine the image offset for mentioned boot images from boot partition.

Thanks
Chin Liang

Quoted 1 line · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:

[...]

Quoted 22 lines

Quoted 12 lines

Quoted 1 line

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 4 lines

256k(env)
15872k(boot)
16m(rootfs)

Quoted 5 lines

Quoted 2 lines

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two UBI volumes ?

For backward compatibility, it can be raw if user want to stick with old way.

Quoted 34 lines · Chin Liang See

Quoted 2 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:

[...]

Quoted 28 lines

Quoted 12 lines

Quoted 1 line

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 6 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two UBI
volumes ?

Quoted 3 lines

For backward compatibility, it can be raw if user want to stick with
old way.

If you're breaking the partitioning layout anyway, you don't have to care about the "old way", right ?

Best regards,
Marek Vasut

Quoted 40 lines · Marek Vasut

Quoted 38 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See

wrote:

[...]

Quoted 22 lines

Quoted 12 lines

Quoted 1 line

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 4 lines

256k(env)
15872k(boot)
16m(rootfs)

Quoted 6 lines

Quoted 2 lines

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two UBI
volumes ?

For backward compatibility, it can be raw if user want to stick with
old way.

Quoted 2 lines

If you're breaking the partitioning layout anyway, you don't have to care about the "old way", right ?

Actually this partition can be used as raw partition if user don't want to store zimage and dtb as raw binary.

But the rootfs partition still can be presented to Linux as ubifs.

Quoted 45 lines · Chin Liang See

Quoted 44 lines · Marek Vasut

Quoted 41 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See

wrote:

[...]

Quoted 23 lines

Quoted 13 lines

Quoted 2 lines

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 4 lines

256k(env)
15872k(boot)
16m(rootfs)

Quoted 8 lines

Quoted 3 lines

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two
UBI
volumes ?

For backward compatibility, it can be raw if user want to stick with
old way.

Quoted 7 lines

Quoted 3 lines

If you're breaking the partitioning layout anyway, you don't have to
care about the "old way", right ?

Actually this partition can be used as raw partition if user don't want
to store zimage and dtb as raw binary.

You should never store raw zImage/dtb in a flash on a production system.
This is real bad and can result in a corruption in the future when the
system is in the field for a long time. I'd suggest to just use two UBI
volumes, one for fitImage and the other for rootfs.

Quoted 1 line

But the rootfs partition still can be presented to Linux as ubifs.

That's for sure :)

Best regards,
Marek Vasut

Quoted 55 lines · Marek Vasut

Quoted 46 lines · Chin Liang See

Quoted 45 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See

Quoted 41 lines · wrote:

Quoted 3 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See

wrote:

[...]

Quoted 23 lines

Quoted 13 lines

Quoted 2 lines

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 4 lines

256k(env)
15872k(boot)
16m(rootfs)

Quoted 8 lines

Quoted 3 lines

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two
UBI
volumes ?

For backward compatibility, it can be raw if user want to stick with
old way.

Quoted 7 lines

Quoted 3 lines

If you're breaking the partitioning layout anyway, you don't have to
care about the "old way", right ?

Actually this partition can be used as raw partition if user don't want
to store zimage and dtb as raw binary.

Quoted 7 lines

You should never store raw zImage/dtb in a flash on a production system.
This is real bad and can result in a corruption in the future when the
system is in the field for a long time. I'd suggest to just use two UBI
volumes, one for fitImage and the other for rootfs.

Yup, we are trying to move the raw away by having UBI enabled. I presume when you refer 2 UBI volumes, I presume its still single UBI partition?

Quoted 74 lines · Chin Liang See

Quoted 72 lines · Marek Vasut

Quoted 56 lines · Chin Liang See

Quoted 50 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See

Quoted 42 lines · wrote:

Quoted 4 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See

wrote:

[...]

Quoted 29 lines

Quoted 14 lines

Quoted 2 lines

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the
rationale.

Quoted 7 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Quoted 5 lines

Is that an UBIFS partition ? If so, why don't you just use
two
UBI
volumes ?

Quoted 4 lines

For backward compatibility, it can be raw if user want to stick
with
old way.

Quoted 4 lines

If you're breaking the partitioning layout anyway, you don't have
to
care about the "old way", right ?

Quoted 4 lines

Actually this partition can be used as raw partition if user don't
want
to store zimage and dtb as raw binary.

You should never store raw zImage/dtb in a flash on a production system.
This is real bad and can result in a corruption in the future when
the
system is in the field for a long time. I'd suggest to just use two
UBI
volumes, one for fitImage and the other for rootfs.

Quoted 4 lines

Yup, we are trying to move the raw away by having UBI enabled. I presume when you refer 2 UBI volumes, I presume its still single UBI
partition?

Yeah, one UBI partition with two UBI volumes -- boot and root.

Quoted 81 lines · Marek Vasut

Quoted 79 lines · Chin Liang See

Quoted 64 lines · Marek Vasut

On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See

Quoted 56 lines · wrote:

Quoted 50 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See

Quoted 42 lines · wrote:

Quoted 4 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See

wrote:

[...]

Quoted 29 lines

Quoted 14 lines

Quoted 2 lines

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the
rationale.

Quoted 7 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Quoted 5 lines

Is that an UBIFS partition ? If so, why don't you just use
two
UBI
volumes ?

Quoted 4 lines

For backward compatibility, it can be raw if user want to stick
with
old way.

Quoted 4 lines

If you're breaking the partitioning layout anyway, you don't have
to
care about the "old way", right ?

Quoted 4 lines

Actually this partition can be used as raw partition if user don't
want
to store zimage and dtb as raw binary.

Quoted 9 lines

You should never store raw zImage/dtb in a flash on a production system.
This is real bad and can result in a corruption in the future when
the
system is in the field for a long time. I'd suggest to just use two
UBI
volumes, one for fitImage and the other for rootfs.

Yup, we are trying to move the raw away by having UBI enabled. I presume when you refer 2 UBI volumes, I presume its still single UBI
partition?

Quoted 1 line

Yeah, one UBI partition with two UBI volumes -- boot and root.

Ok I grasp you correctly. In this case, I would suggest to opt for 2 partitions instead of 2 volumes. User can just use sf erase rootfs instead of checking for volume offset. I suspect the ubi part will take longer time if we are having one partition only. I shall send out the new revision if this works for you :)

Quoted 97 lines · Chin Liang See

Quoted 87 lines · Marek Vasut

Quoted 85 lines · Chin Liang See

Quoted 83 lines · Marek Vasut

On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See

Quoted 63 lines · wrote:

Quoted 56 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See

Quoted 46 lines · wrote:

Quoted 5 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang
See

wrote:

[...]

Quoted 31 lines

Quoted 15 lines

Quoted 3 lines

Can you share the final layout before you roll
out
patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for
the
rationale.

Quoted 7 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Quoted 6 lines

Is that an UBIFS partition ? If so, why don't you
just
use
two
UBI
volumes ?

Quoted 5 lines

For backward compatibility, it can be raw if user want to
stick
with
old way.

Quoted 5 lines

If you're breaking the partitioning layout anyway, you don't
have
to
care about the "old way", right ?

Quoted 5 lines

Actually this partition can be used as raw partition if user
don't
want
to store zimage and dtb as raw binary.

You should never store raw zImage/dtb in a flash on a production
system.
This is real bad and can result in a corruption in the future when
the
system is in the field for a long time. I'd suggest to just use
two
UBI
volumes, one for fitImage and the other for rootfs.

Quoted 8 lines

Quoted 6 lines

Yup, we are trying to move the raw away by having UBI enabled. I
presume when you refer 2 UBI volumes, I presume its still single
UBI
partition?

Yeah, one UBI partition with two UBI volumes -- boot and root.

Quoted 8 lines

Ok I grasp you correctly. In this case, I would suggest to opt for 2
partitions instead of 2 volumes. User can just use sf erase rootfs instead of checking for volume offset. I suspect the ubi part will take
longer time if we are having one partition only. I shall send out the
new revision if this works for you :)

Oh, I see what you're concerned about. On the other hand, you are not supposed
to erase UBI partition, since that'd nuke the UBI erase counters and UBI would
loose track of how many times each block was erased, which helps with wear
leveling.

If you're adamant about two UBI partitions , you can try the trick where you can
create overlapping mtd partitions, that way you'd have both options available.
(it is actually a legal construction, you can check the kernel MTD docs).

Quoted 116 lines · Marek Vasut

Quoted 98 lines · Chin Liang See

Quoted 88 lines · Marek Vasut

On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

Quoted 85 lines · wrote:

Quoted 83 lines · Marek Vasut

On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See

Quoted 63 lines · wrote:

Quoted 56 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See

Quoted 46 lines · wrote:

Quoted 5 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang
See

wrote:

[...]

Quoted 31 lines

Quoted 15 lines

Quoted 3 lines

Can you share the final layout before you roll
out
patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for
the
rationale.

Quoted 7 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition.
It contains the linux dtb, u-boot and linux images.

Quoted 6 lines

Is that an UBIFS partition ? If so, why don't you
just
use
two
UBI
volumes ?

Quoted 5 lines

For backward compatibility, it can be raw if user want to
stick
with
old way.

Quoted 5 lines

If you're breaking the partitioning layout anyway, you don't
have
to
care about the "old way", right ?

Quoted 5 lines

Actually this partition can be used as raw partition if user
don't
want
to store zimage and dtb as raw binary.

You should never store raw zImage/dtb in a flash on a production
system.
This is real bad and can result in a corruption in the future when
the
system is in the field for a long time. I'd suggest to just use
two
UBI
volumes, one for fitImage and the other for rootfs.

Quoted 8 lines

Quoted 6 lines

Yup, we are trying to move the raw away by having UBI enabled. I
presume when you refer 2 UBI volumes, I presume its still single
UBI
partition?

Yeah, one UBI partition with two UBI volumes -- boot and root.

Quoted 8 lines

Ok I grasp you correctly. In this case, I would suggest to opt for 2
partitions instead of 2 volumes. User can just use sf erase rootfs instead of checking for volume offset. I suspect the ubi part will take
longer time if we are having one partition only. I shall send out the
new revision if this works for you :)

Oh, I see what you're concerned about. On the other hand, you are not supposed
to erase UBI partition, since that'd nuke the UBI erase counters and UBI would
loose track of how many times each block was erased, which helps with wear
leveling.

Quoted 6 lines

If you're adamant about two UBI partitions , you can try the trick where you can
create overlapping mtd partitions, that way you'd have both options available.
(it is actually a legal construction, you can check the kernel MTD docs).

After grabbing a coffee

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Quoted 150 lines · Chin Liang See

Quoted 148 lines · Marek Vasut

Quoted 113 lines · Chin Liang See

Quoted 109 lines · Marek Vasut

On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

Quoted 98 lines · wrote:

Quoted 83 lines · Marek Vasut

On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See

Quoted 73 lines · wrote:

Quoted 65 lines · Marek Vasut

On Sunday, December 13, 2015 at 12:59:48 AM, Chin
Liang
See

Quoted 53 lines · wrote:

Quoted 6 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM,
Chin
Liang
See

wrote:

[...]

Quoted 36 lines

Quoted 17 lines

Quoted 4 lines

Can you share the final layout before you
roll
out
patches ?

Sure, plan to do so but need to away from desk
just
now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see
above
for
the
rationale.

Quoted 9 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or
raw
partition.
It contains the linux dtb, u-boot and linux
images.

Quoted 6 lines

Is that an UBIFS partition ? If so, why don't you
just
use
two
UBI
volumes ?

Quoted 6 lines

For backward compatibility, it can be raw if user
want
to
stick
with
old way.

Quoted 6 lines

If you're breaking the partitioning layout anyway, you
don't
have
to
care about the "old way", right ?

Quoted 5 lines

Actually this partition can be used as raw partition if user
don't
want
to store zimage and dtb as raw binary.

Quoted 13 lines

You should never store raw zImage/dtb in a flash on a production
system.
This is real bad and can result in a corruption in the future
when
the
system is in the field for a long time. I'd suggest to just
use
two
UBI
volumes, one for fitImage and the other for rootfs.

Quoted 7 lines

Yup, we are trying to move the raw away by having UBI enabled.
I
presume when you refer 2 UBI volumes, I presume its still single
UBI
partition?

Quoted 2 lines

Yeah, one UBI partition with two UBI volumes -- boot and root.

Quoted 12 lines

Ok I grasp you correctly. In this case, I would suggest to opt for
2
partitions instead of 2 volumes. User can just use sf erase rootfs
instead of checking for volume offset. I suspect the ubi part will
take
longer time if we are having one partition only. I shall send out
the
new revision if this works for you :)

Oh, I see what you're concerned about. On the other hand, you are not
supposed
to erase UBI partition, since that'd nuke the UBI erase counters and
UBI would
loose track of how many times each block was erased, which helps with
wear
leveling.

If you're adamant about two UBI partitions , you can try the trick
where you can
create overlapping mtd partitions, that way you'd have both options
available.
(it is actually a legal construction, you can check the kernel MTD
docs).

Quoted 1 line

After grabbing a coffee

That's a good idea, though I think I will make do with a green tea (??).

Quoted 12 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for
UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

Quoted 7 lines

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),
- at 1536k(UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Quoted 4 lines

Quoted 1 line

After grabbing a coffee

That's a good idea, though I think I will make do with a green tea (??).

Yeah, beside green tea, genmaicha (???) is one of my top choice too. :)

Quoted 21 lines

Quoted 11 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for
UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

Quoted 7 lines

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

Quoted 4 lines

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),
- at 1536k(UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Nice, let me give it a try.

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:

Quoted 26 lines

Quoted 26 lines

Quoted 12 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another
for
UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

Quoted 7 lines

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

mtdparts=1m(u -boot),256k(env1),256k(env2),14848k(boot),112m(root),
- at 1536k(UBI)

Quoted 3 lines

Quoted 1 line

This will create overlapping partitions "boot,root" and "UBI" .

Nice, let me give it a try.

Make sure to test it in Linux too ;-)

Best regards,
Marek Vasut

Quoted 1 line · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:

[...]

Quoted 30 lines

Quoted 29 lines

Quoted 22 lines

Quoted 12 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another
for
UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

Quoted 7 lines

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

Quoted 5 lines

mtdparts=1m(u -boot),256k(env1),256k(env2),14848k(boot),112m(root),
- at 1536k(UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Nice, let me give it a try.

Quoted 1 line

Make sure to test it in Linux too ;-)

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I already applied the patch for cache ARMV7. I will take a look into ubi code as I suspect its due to eraseblock size issue.

Quoted 3 lines · Chin Liang See

Quoted 2 lines · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:

Quoted 7 lines

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I already applied the patch for cache ARMV7. I will take a look into ubi
code as I suspect its due to eraseblock size issue.

Keep looking, good luck.

The armv7 cache issue is more serious than I thought, I am starting to suspect
there is some problem with the L3 interconnect, but I cannot put my finger on
it yet.

Best regards,
Marek Vasut

Quoted 5 lines · Marek Vasut

Quoted 4 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See

wrote:

[...]

Quoted 8 lines

Quoted 6 lines

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I already applied the patch for cache ARMV7. I will take a look into ubi
code as I suspect its due to eraseblock size issue.

Keep looking, good luck.

Yup, will compare the UBI code with the Linux one.

Quoted 5 lines

The armv7 cache issue is more serious than I thought, I am starting to suspect
there is some problem with the L3 interconnect, but I cannot put my finger on
it yet.

Hmmm... I can try to help.

FYI, I was trying to understand how the code error in cache-cp15 will cause the misbehave. One thing I am suspecting it might due to mismatch of cache policy for the memory that store the page table and translation page walk mechanism. But with your fix, it should be good as they are matching now.

Quoted 18 lines · Chin Liang See

Quoted 6 lines · Marek Vasut

Quoted 4 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See

wrote:

[...]

Quoted 9 lines

Quoted 8 lines

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I
already applied the patch for cache ARMV7. I will take a look into
ubi
code as I suspect its due to eraseblock size issue.

Quoted 4 lines

Quoted 1 line

Keep looking, good luck.

Yup, will compare the UBI code with the Linux one.

Quoted 10 lines

Quoted 7 lines

The armv7 cache issue is more serious than I thought, I am starting
to suspect
there is some problem with the L3 interconnect, but I cannot put my
finger on
it yet.

Hmmm... I can try to help.

Quoted 8 lines

FYI, I was trying to understand how the code error in cache-cp15 will
cause the misbehave. One thing I am suspecting it might due to mismatch
of cache policy for the memory that store the page table and translation page walk mechanism. But with your fix, it should be good
as they are matching now.

I would suggest to move this to the thread below the CPU_V7 patch.

btw. the L2 cache is not enabled on SoCFPGA at all :-( I have a patch to fix
it, but this doesn't help us.

I suspect there might be some synchronisation
or timing issue with accesses through the L3 interconnect, which would point
to NIC301 misconfiguration, but that's purely hypothetical.Do you have some
hardware-level or RTL-level/simulation tool to debug such issues at Altera ?

Best regards,
Marek Vasut

Quoted 20 lines · Marek Vasut

Quoted 19 lines · Chin Liang See

Quoted 7 lines · Marek Vasut

On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See

Quoted 4 lines · wrote:

Quoted 3 lines · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See

wrote:

[...]

Quoted 9 lines

Quoted 8 lines

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I
already applied the patch for cache ARMV7. I will take a look into
ubi
code as I suspect its due to eraseblock size issue.

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Keep looking, good luck.

Yup, will compare the UBI code with the Linux one.

Yeah, I managed to get ubiufsmount work in U-Boot now. Need to disable the 4K_SECTORS when enabling UBI at NOR flash.

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

The armv7 cache issue is more serious than I thought, I am starting
to suspect
there is some problem with the L3 interconnect, but I cannot put my
finger on
it yet.

Hmmm... I can try to help.

FYI, I was trying to understand how the code error in cache-cp15 will
cause the misbehave. One thing I am suspecting it might due to mismatch
of cache policy for the memory that store the page table and translation page walk mechanism. But with your fix, it should be good
as they are matching now.

Quoted 1 line

I would suggest to move this to the thread below the CPU_V7 patch.

Would you able to include me to the thread? Thanks in advance!

Quoted 3 lines

btw. the L2 cache is not enabled on SoCFPGA at all :-( I have a patch to fix
it, but this doesn't help us.

Hmmm... I saw the PL310 is defined. I might want to look further.

Quoted 7 lines

I suspect there might be some synchronisation
or timing issue with accesses through the L3 interconnect, which would point
to NIC301 misconfiguration, but that's purely hypothetical.Do you have some
hardware-level or RTL-level/simulation tool to debug such issues at Altera ?

I hardly use simulation except for in house pre-silicon validation. But I use DS-5 a lot to troubleshoot an issue (by probing various registers including cp15).

Thanks
Chin Liang

Quoted 2 lines

Best regards,
Marek Vasut

Quoted 26 lines · Chin Liang See

Quoted 25 lines · Marek Vasut

Quoted 23 lines · Chin Liang See

Quoted 8 lines · Marek Vasut

On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See

Quoted 5 lines · wrote:

Quoted 4 lines · Marek Vasut

On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See

wrote:

[...]

Quoted 11 lines

Quoted 9 lines

Yeah, I can successfully mounted with ubifs :)

Just that I still have the issue with U-Boot ubifsmount although I
already applied the patch for cache ARMV7. I will take a look
into
ubi
code as I suspect its due to eraseblock size issue.

Keep looking, good luck.

Quoted 5 lines

Quoted 1 line

Quoted 1 line

Yup, will compare the UBI code with the Linux one.

Yeah, I managed to get ubiufsmount work in U-Boot now. Need to disable
the 4K_SECTORS when enabling UBI at NOR flash.

In that case, look at commit 0a02655481834a4ebdf457e43c24729ffd7daf37

Quoted 23 lines

Quoted 23 lines

Quoted 22 lines

Quoted 9 lines

The armv7 cache issue is more serious than I thought, I am starting
to suspect
there is some problem with the L3 interconnect, but I cannot put
my
finger on
it yet.

Hmmm... I can try to help.

FYI, I was trying to understand how the code error in cache -cp15
will
cause the misbehave. One thing I am suspecting it might due to mismatch
of cache policy for the memory that store the page table and translation page walk mechanism. But with your fix, it should be
good
as they are matching now.

Quoted 4 lines

Quoted 2 lines

I would suggest to move this to the thread below the CPU_V7 patch.

Would you able to include me to the thread? Thanks in advance!

https://www.mail-archive.com/u-boot at lists.denx.de/msg195327.html

Quoted 6 lines

Quoted 4 lines

btw. the L2 cache is not enabled on SoCFPGA at all :-( I have a patch
to fix
it, but this doesn't help us.

Hmmm... I saw the PL310 is defined. I might want to look further.

I will send that patch out shortly, but I think there is something else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Are you able to replicate my USB issue with mainline on socfpga ? What
happens if you run usb reset with a USB stick plugged in? What compiler
version do you use ?

Quoted 10 lines

Quoted 9 lines

I suspect there might be some synchronisation
or timing issue with accesses through the L3 interconnect, which would point
to NIC301 misconfiguration, but that's purely hypothetical.Do you have some
hardware-level or RTL-level/simulation tool to debug such issues at
Altera ?

Quoted 11 lines

I hardly use simulation except for in house pre-silicon validation. But
I use DS-5 a lot to troubleshoot an issue (by probing various registers
including cp15).

Thanks
Chin Liang

Quoted 2 lines

Best regards,
Marek Vasut

Best regards,
Marek Vasut

Quoted 5 lines

Quoted 3 lines

Yeah, I managed to get ubiufsmount work in U-Boot now. Need to disable
the 4K_SECTORS when enabling UBI at NOR flash.

In that case, look at commit 0a02655481834a4ebdf457e43c24729ffd7daf37

Yup, I was defining that macro. Surprising that nobody is defining that. Also nice to know you are the one creating this patch.

Quoted 11 lines

I will send that patch out shortly, but I think there is something else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Are you able to replicate my USB issue with mainline on socfpga ? What
happens if you run usb reset with a USB stick plugged in? What compiler
version do you use ?

I tried that few weeks back and it works for me. FYI, I am using the mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe I can try again with your toolchain.

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:

Quoted 13 lines

Quoted 12 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Are you able to replicate my USB issue with mainline on socfpga ? What
happens if you run usb reset with a USB stick plugged in? What compiler
version do you use ?

Quoted 5 lines

I tried that few weeks back and it works for me. FYI, I am using the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe I can
try again with your toolchain.

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2. Which gcc version is in the mentor toolchain?

Can you try it again with u-boot/master ? I'd be interested in your results.
Can you share the entire output of the U-Boot and run 'dcache' command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer USB 2.0 sticks
now too.

Best regards,
Marek Vasut

Quoted 1 line · Marek Vasut

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:

[..]

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Are you able to replicate my USB issue with mainline on socfpga ? What
happens if you run usb reset with a USB stick plugged in? What compiler
version do you use ?

Quoted 8 lines

Quoted 5 lines

I tried that few weeks back and it works for me. FYI, I am using the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe I can
try again with your toolchain.

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2. Which gcc version is in the mentor toolchain?

Mine is Sourcery CodeBench Lite 2015.05-11 (gcc 4.9.2 also)

Quoted 7 lines

Can you try it again with u-boot/master ? I'd be interested in your results.
Can you share the entire output of the U-Boot and run 'dcache' command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer USB 2.0 sticks
now too.

I can do that but git clone will take some time

Quoted 44 lines · Chin Liang See

Quoted 2 lines · Marek Vasut

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:

[..]

Quoted 23 lines

Quoted 15 lines

Quoted 7 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Quoted 7 lines

Are you able to replicate my USB issue with mainline on socfpga ?
What
happens if you run usb reset with a USB stick plugged in? What
compiler
version do you use ?

Quoted 7 lines

I tried that few weeks back and it works for me. FYI, I am using
the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe I
can
try again with your toolchain.

Quoted 3 lines

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2.
Which gcc version is in the mentor toolchain?

Mine is Sourcery CodeBench Lite 2015.05-11 (gcc 4.9.2 also)

Quoted 9 lines

Can you try it again with u-boot/master ? I'd be interested in your
results.
Can you share the entire output of the U-Boot and run 'dcache' command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer USB
2.0 sticks
now too.

Quoted 1 line

I can do that but git clone will take some time

You can use git fetch in your current repo.

I started wondering how you're testing the CV SoCDK, since I discovered just
this morning that it doesn't even boot (I already sent patches to fix that).

Best regards,
Marek Vasut

Quoted 50 lines · Marek Vasut

Quoted 45 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See

wrote:

[..]

Quoted 23 lines

Quoted 15 lines

Quoted 7 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Quoted 7 lines

Are you able to replicate my USB issue with mainline on socfpga ?
What
happens if you run usb reset with a USB stick plugged in? What
compiler
version do you use ?

Quoted 7 lines

I tried that few weeks back and it works for me. FYI, I am using
the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe I
can
try again with your toolchain.

Quoted 3 lines

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2.
Which gcc version is in the mentor toolchain?

Mine is Sourcery CodeBench Lite 2015.05-11 (gcc 4.9.2 also)

Quoted 9 lines

Can you try it again with u-boot/master ? I'd be interested in your
results.
Can you share the entire output of the U-Boot and run 'dcache' command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer USB
2.0 sticks
now too.

Quoted 1 line

I can do that but git clone will take some time

You can use git fetch in your current repo.

Quoted 4 lines

I started wondering how you're testing the CV SoCDK, since I discovered just
this morning that it doesn't even boot (I already sent patches to fix that).

I presume you are referring to SPL? FYI, I am still using the SPL from SOCEDS while using latest U-Boot from mainstream. That's why I didn't the issue noticed by Shengjiang and you.

But will make the switch soon once done with few in progress patches for U-Boot.

Quoted 63 lines · Chin Liang See

Quoted 54 lines · Marek Vasut

Quoted 50 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See

wrote:

[..]

Quoted 25 lines

Quoted 16 lines

Quoted 8 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Quoted 7 lines

Are you able to replicate my USB issue with mainline on socfpga ?
What
happens if you run usb reset with a USB stick plugged in? What
compiler
version do you use ?

Quoted 8 lines

I tried that few weeks back and it works for me. FYI, I am using
the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe
I
can
try again with your toolchain.

Quoted 3 lines

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2.
Which gcc version is in the mentor toolchain?

Mine is Sourcery CodeBench Lite 2015.05-11 (gcc 4.9.2 also)

Quoted 4 lines

Can you try it again with u-boot/master ? I'd be interested in
your
results.

Quoted 8 lines

Can you share the entire output of the U-Boot and run 'dcache'
command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer
USB
2.0 sticks
now too.

Quoted 1 line

I can do that but git clone will take some time

Quoted 7 lines

You can use git fetch in your current repo.

I started wondering how you're testing the CV SoCDK, since I discovered just
this morning that it doesn't even boot (I already sent patches to fix
that).

Quoted 5 lines

I presume you are referring to SPL? FYI, I am still using the SPL from
SOCEDS while using latest U-Boot from mainstream. That's why I didn't
the issue noticed by Shengjiang and you.

Well, at least you're honest ... but *sigh*, it'd be nice if you tested
mainline only, really.

Quoted 4 lines

But will make the switch soon once done with few in progress patches
for U-Boot.

I will collect the remaining patches today and see how socdk fares.

Best regards,
Marek Vasut

Quoted 71 lines · Marek Vasut

Quoted 69 lines · Chin Liang See

Quoted 55 lines · Marek Vasut

On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See

Quoted 50 lines · wrote:

Quoted 3 lines · Marek Vasut

On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See

wrote:

[..]

Quoted 25 lines

Quoted 16 lines

Quoted 8 lines

I will send that patch out shortly, but I think there is something
else
going on. I am starting to suspect something with the L3 interconnect.
Maybe some R/W reordering or something like that in NIC301 .

Quoted 7 lines

Are you able to replicate my USB issue with mainline on socfpga ?
What
happens if you run usb reset with a USB stick plugged in? What
compiler
version do you use ?

Quoted 8 lines

I tried that few weeks back and it works for me. FYI, I am using
the
mentor toolchain "arm-altera-eabi" that come with SOCEDS. Maybe
I
can
try again with your toolchain.

Quoted 3 lines

I am using the unreleased ELDK 5.8 (gcc 4.9.2) and debian gcc 5.2.
Which gcc version is in the mentor toolchain?

Mine is Sourcery CodeBench Lite 2015.05-11 (gcc 4.9.2 also)

Quoted 4 lines

Can you try it again with u-boot/master ? I'd be interested in
your
results.

Quoted 8 lines

Can you share the entire output of the U-Boot and run 'dcache'
command before
doing 'usb reset' ? I am seeing this issue with Sandisk Cruzer
USB
2.0 sticks
now too.

Quoted 1 line

I can do that but git clone will take some time

Quoted 7 lines

You can use git fetch in your current repo.

I started wondering how you're testing the CV SoCDK, since I discovered just
this morning that it doesn't even boot (I already sent patches to fix
that).

I presume you are referring to SPL? FYI, I am still using the SPL from
SOCEDS while using latest U-Boot from mainstream. That's why I didn't
the issue noticed by Shengjiang and you.

Quoted 3 lines

Well, at least you're honest ... but *sigh*, it'd be nice if you tested
mainline only, really.

Yah, after all the build error issue, I believe I would need to make the switch. Let me take a look so I can check the SPL health. I will fetch and try it out.

Quoted 5 lines

Quoted 3 lines

But will make the switch soon once done with few in progress patches
for U-Boot.

I will collect the remaining patches today and see how socdk fares.

Let me know if you notice any failure while I will do the test my side later.

Quoted 4 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

Quoted 1 line · Chin Liang See

On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

I presume you are referring to SPL? FYI, I am still using the SPL
from
SOCEDS while using latest U-Boot from mainstream. That's why I didn't
the issue noticed by Shengjiang and you.

Well, at least you're honest ... but *sigh*, it'd be nice if you tested
mainline only, really.

Quoted 5 lines

Yah, after all the build error issue, I believe I would need to make
the switch. Let me take a look so I can check the SPL health. I will
fetch and try it out.

Please check USB host, I suspect it is broken. I don't have the cable handy now, so I cannot check.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

But will make the switch soon once done with few in progress patches
for U-Boot.

Quoted 6 lines

Quoted 2 lines

I will collect the remaining patches today and see how socdk fares.

Let me know if you notice any failure while I will do the test my side
later.

Looks like with u-boot-socfpga/master, all is good.

Quoted 3 lines

I presume you are referring to SPL? FYI, I am still using the SPL from SOCEDS while using latest U-Boot from mainstream. That's why I didn't the issue noticed by Shengjiang and you.

Well, at least you're honest ... but *sigh*, it'd be nice if you tested mainline only, really.

Hi!

Quoted 6 lines

Quoted 5 lines

I presume you are referring to SPL? FYI, I am still using the SPL from
SOCEDS while using latest U-Boot from mainstream. That's why I didn't
the issue noticed by Shengjiang and you.

Quoted 3 lines

Well, at least you're honest ... but *sigh*, it'd be nice if you tested
mainline only, really.

Actually... If there are enough resources, it would be good to keep testing both. There's world beyond mainline Marek does not want to see
;-).

Pavel

Quoted 12 lines · Pavel Machek

Hi!

Quoted 9 lines

Quoted 5 lines

I presume you are referring to SPL? FYI, I am still using the SPL from
SOCEDS while using latest U-Boot from mainstream. That's why I didn't
the issue noticed by Shengjiang and you.

Well, at least you're honest ... but *sigh*, it'd be nice if you tested
mainline only, really.

Quoted 4 lines

Actually... If there are enough resources, it would be good to keep testing both. There's world beyond mainline Marek does not want to see
;-).

haha :) I just made the switch and noticed some issues. I2C patch is the first and more to go.

Quoted 23 lines · Chin Liang See

Quoted 21 lines · Pavel Machek

Hi!

Quoted 8 lines

Quoted 7 lines

I presume you are referring to SPL? FYI, I am still using the SPL
from
SOCEDS while using latest U-Boot from mainstream. That's why I
didn't
the issue noticed by Shengjiang and you.

Quoted 4 lines

Well, at least you're honest ... but *sigh*, it'd be nice if you
tested
mainline only, really.

Actually... If there are enough resources, it would be good to keep
testing both. There's world beyond mainline Marek does not want to
see
;-).

Quoted 3 lines

haha :) I just made the switch and noticed some issues. I2C patch is
the first and more to go.

Is there more ?

Best regards,
Marek Vasut

Quoted 28 lines · Marek Vasut

Quoted 26 lines · Chin Liang See

Quoted 15 lines · Pavel Machek

Hi!

Quoted 8 lines

Quoted 7 lines

I presume you are referring to SPL? FYI, I am still using the SPL
from
SOCEDS while using latest U-Boot from mainstream. That's why I
didn't
the issue noticed by Shengjiang and you.

Quoted 4 lines

Well, at least you're honest ... but *sigh*, it'd be nice if you
tested
mainline only, really.

Quoted 6 lines

Actually... If there are enough resources, it would be good to keep
testing both. There's world beyond mainline Marek does not want to
see
;-).

haha :) I just made the switch and noticed some issues. I2C patch is
the first and more to go.

Quoted 1 line

Is there more ?

For Cyclone V socdk pin mux, they are in good shape where i2c should be the last needed. I need to do the same for Arria V socdk as I am trying to find the board.

I am still testing against other. One thing I bump yesterday is the FAT support doesn't work in SPL. That would need some tricks that I did for SOCEDS U-Boot :)

Quoted 4 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

Quoted 1 line · Chin Liang See

On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:

Quoted 5 lines

For Cyclone V socdk pin mux, they are in good shape where i2c should be
the last needed. I need to do the same for Arria V socdk as I am trying
to find the board.

It's in my office, but I am at home now :-/ I _think_ I reloaded the AV
SoCDK pinmux, so the basic functionality should at least be there.

Quoted 6 lines

I am still testing against other. One thing I bump yesterday is the FAT
support doesn't work in SPL. That would need some tricks that I did for
SOCEDS U-Boot :)

I think this might be because FAT is too ... well ... fat.

It consumes too
much stack I think.

Best regards,
Marek Vasut

Quoted 6 lines · Marek Vasut

Quoted 5 lines · Chin Liang See

Quoted 4 lines · Marek Vasut

On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See

Quoted 1 line · wrote:

On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:

[..]

Quoted 6 lines

Quoted 5 lines

For Cyclone V socdk pin mux, they are in good shape where i2c should be
the last needed. I need to do the same for Arria V socdk as I am trying
to find the board.

Quoted 3 lines

It's in my office, but I am at home now :-/ I _think_ I reloaded the AV
SoCDK pinmux, so the basic functionality should at least be there.

Yah, I just tested master against arria5_socdk and they are doing good

:) For record, this include testing sdmmc, sf, i2c, usb and ethernet.

Quoted 7 lines

Quoted 5 lines

I am still testing against other. One thing I bump yesterday is the FAT
support doesn't work in SPL. That would need some tricks that I did for
SOCEDS U-Boot :)

I think this might be because FAT is too ... well ... fat.

Hmmm... let me create some slimming pill for that :)

Quoted 2 lines

It consumes too
much stack I think.

Yah, it took lot of space in stack and especially malloc. As FAT access only happen after SDRAM access, we can relocate the stack and malloc to SDRAM after SDRAM workng. FYI, I did that for 2013.01.01 and it works well :) Will try it out

Quoted 24 lines · Chin Liang See

Quoted 8 lines · Marek Vasut

Quoted 6 lines · Chin Liang See

Quoted 5 lines · Marek Vasut

On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See

Quoted 1 line · wrote:

On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:

[..]

Quoted 12 lines

Quoted 6 lines

For Cyclone V socdk pin mux, they are in good shape where i2c should be
the last needed. I need to do the same for Arria V socdk as I am
trying
to find the board.

It's in my office, but I am at home now :-/ I _think_ I reloaded the
AV
SoCDK pinmux, so the basic functionality should at least be there.

Quoted 5 lines

Yah, I just tested master against arria5_socdk and they are doing good

:) For record, this include testing sdmmc, sf, i2c, usb and ethernet.

Excellent, what about QSPI ?

Quoted 29 lines · Marek Vasut

Quoted 28 lines · Chin Liang See

Quoted 9 lines · Marek Vasut

On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See

Quoted 6 lines · wrote:

Quoted 5 lines · Marek Vasut

On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See

Quoted 1 line · wrote:

On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:

[..]

Quoted 7 lines

Quoted 6 lines

For Cyclone V socdk pin mux, they are in good shape where i2c should be
the last needed. I need to do the same for Arria V socdk as I am
trying
to find the board.

Quoted 5 lines

It's in my office, but I am at home now :-/ I _think_ I reloaded the
AV
SoCDK pinmux, so the basic functionality should at least be there.

Yah, I just tested master against arria5_socdk and they are doing good

Quoted 5 lines

Quoted 3 lines

:) For record, this include testing sdmmc, sf, i2c, usb and

ethernet.

Excellent, what about QSPI ?

QSPI is good as tested with sf command.

Hi!

Quoted 4 lines

Quoted 3 lines

I presume you are referring to SPL? FYI, I am still using the SPL from SOCEDS while using latest U-Boot from mainstream. That's why I didn't the issue noticed by Shengjiang and you.

Quoted 2 lines

Well, at least you're honest ... but *sigh*, it'd be nice if you tested mainline only, really.

Actually... If there are enough resources, it would be good to keep testing both. There's world beyond mainline Marek does not want to see ;-).

Quoted 6 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

Quoted 2 lines · Chin Liang See

Quoted 1 line · Marek Vasut

On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

After grabbing a coffee

That's a good idea, though I think I will make do with a green tea (??).

Quoted 15 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

Quoted 2 lines

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),- at 1536k(UBI)

This will create overlapping partitions "boot,root" and "UBI" .

(Please, trim your emails when replying)

Quoted 30 lines · Marek Vasut

Quoted 6 lines · Chin Liang See

Quoted 3 lines · Marek Vasut

Quoted 2 lines · Chin Liang See

Quoted 1 line · Marek Vasut

On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See

After grabbing a coffee

That's a good idea, though I think I will make do with a green tea (??).

Quoted 10 lines

and rethinking, we can have 2 MTD_PARTITION
where one for backward compatiblity (supporting raw) while another for UBI.

MTDPARTS_RAW
256k(spl),
256k(env),
15872k(boot),
-(rootfs)

Quoted 7 lines

MTDPARTS_UBI
256k(spl),
256k(env),
-(UBI)

We should make UBI as default then. If user care about backward compatiblity, they shall use the MTDPARTS_RAW then.

Try this:

Quoted 4 lines

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),- at 1536k (UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Quoted 7 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 5 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),- at 1536k (UBI)

Quoted 4 lines

Quoted 1 line

This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Please explain in detail why do you think so.

Quoted 10 lines · Marek Vasut

Quoted 9 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 6 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),- at 1 536k (UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Quoted 4 lines

Quoted 2 lines

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Please explain in detail why do you think so.

Please make a 200 page study of human psychology explaining that noone would ever be confused by two overlapping partitions :-).

Quoted 14 lines · Pavel Machek

Quoted 13 lines · Marek Vasut

Quoted 11 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 6 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),- at 1 536k (UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Quoted 4 lines

Quoted 1 line

Please explain in detail why do you think so.

Please make a 200 page study of human psychology explaining that noone would ever be confused by two overlapping partitions :-).

Add a comment explaining the situation and reasoning behind that, problem solved.

Quoted 17 lines · Marek Vasut

Quoted 16 lines · Pavel Machek

Quoted 14 lines · Marek Vasut

Quoted 11 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 6 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root) ,- at 1 536k (UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Please explain in detail why do you think so.

Quoted 5 lines

Quoted 2 lines

Please make a 200 page study of human psychology explaining that noone would ever be confused by two overlapping partitions :-).

Add a comment explaining the situation and reasoning behind that, problem solved.

We do partitions so that people don't overwrite data by mistake. Having overlapping partitions kind of defeats the purpose.

Just because trap is documented does not mean that it is not nasty. 199.95 pages to go.

Quoted 21 lines · Pavel Machek

Quoted 20 lines · Marek Vasut

Quoted 18 lines · Pavel Machek

Quoted 8 lines · Marek Vasut

Quoted 7 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 5 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root) ,- at 1 536k (UBI)

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

This will create overlapping partitions "boot,root" and "UBI" .

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Please explain in detail why do you think so.

Please make a 200 page study of human psychology explaining that noone would ever be confused by two overlapping partitions :-).

Quoted 5 lines

Quoted 2 lines

Add a comment explaining the situation and reasoning behind that, problem solved.

We do partitions so that people don't overwrite data by mistake. Having overlapping partitions kind of defeats the purpose.

I'd expect that in case you are fiddling with MTD on a bootloader level, you have at least a vague idea of what you are doing.

Quoted 2 lines

Just because trap is documented does not mean that it is not nasty. 199.95 pages to go.

Do you have a better idea how to satisfy both sets of people, ones which want kernel on a separate partition and ones which want to use single UBI volume then ?

Quoted 26 lines · Marek Vasut

Quoted 25 lines · Pavel Machek

Quoted 23 lines · Marek Vasut

Quoted 12 lines · Pavel Machek

Quoted 11 lines · Marek Vasut

Quoted 10 lines · Pavel Machek

(Please, trim your emails when replying)

Quoted 7 lines

Try this:

mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(r oot) ,- at 1 536k (UBI)

This will create overlapping partitions "boot,root" and "UBI" .

Quoted 7 lines

Quoted 4 lines

Quoted 2 lines

Just because you can does not mean that you should. This looks like a nasty trap for a user.

Please explain in detail why do you think so.

Please make a 200 page study of human psychology explaining that noone would ever be confused by two overlapping partitions :-).

Add a comment explaining the situation and reasoning behind that, problem solved.

Quoted 5 lines

Quoted 2 lines

We do partitions so that people don't overwrite data by mistake. Having overlapping partitions kind of defeats the purpose.

I'd expect that in case you are fiddling with MTD on a bootloader level, you have at least a vague idea of what you are doing.

Yes, but people should not have to expect we prepare traps for them.

Quoted 6 lines

Quoted 2 lines

Just because trap is documented does not mean that it is not nasty. 199.95 pages to go.

Do you have a better idea how to satisfy both sets of people, ones which want kernel on a separate partition and ones which want to use single UBI volume then ?

If you expect people to read a comments explaining a situation, you can easily add an explanation and (commented out) alternative configutation that can be used.

Quoted 2 lines · Pavel Machek

Quoted 1 line · Marek Vasut

On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:

I sense the overlapping partitions are a matter of taste here.

Quoted 9 lines

Quoted 8 lines

Quoted 2 lines

Just because trap is documented does not mean that it is not nasty. 199.95 pages to go.

Do you have a better idea how to satisfy both sets of people, ones which
want kernel on a separate partition and ones which want to use single
UBI volume then ?

Quoted 3 lines

If you expect people to read a comments explaining a situation, you can easily add an explanation and (commented out) alternative configutation that can be used.

I do not want to maintain multiple configurations, especially is there is
known working alternative which covers all the usecases.

Best regards,
Marek Vasut

Quoted 34 lines · Chin Liang See

Quoted 2 lines · Marek Vasut

On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:

[...]

Quoted 28 lines

Quoted 12 lines

Quoted 1 line

Can you share the final layout before you roll out patches ?

Sure, plan to do so but need to away from desk just now.

Here is the old layout
256k(spl)
64k(env)
64k(dtb)
256k(boot)
16m(kernel)
16m(rootfs)

Quoted 2 lines

The new one would like this
256k(spl)

I'd say you should just call this u-boot, see above for the rationale.

Quoted 6 lines

256k(env)
15872k(boot)
16m(rootfs)

The boot partition can be used as ubi part or raw partition. It contains the linux dtb, u-boot and linux images.

Is that an UBIFS partition ? If so, why don't you just use two UBI
volumes ?

Quoted 3 lines

For backward compatibility, it can be raw if user want to stick with
old way.

If you're breaking the partitioning layout anyway, you don't have to care about the "old way", right ?

Best regards,
Marek Vasut