[U-Boot] [PATCH 1/6] 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 clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -96,4 +96,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 + #endif /* __CONFIG_SOCFPGA_CYCLONE5_H__ */ -- 1.9.2.468.g3f0c02a
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_arria5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_arria5_socdk.h b/include/configs/socfpga_arria5_socdk.h index ebb6ed5..d9f07d8 100644 --- a/include/configs/socfpga_arria5_socdk.h +++ b/include/configs/socfpga_arria5_socdk.h @@ -96,4 +96,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 + #endif /* __CONFIG_SOCFPGA_ARRIA5_H__ */ -- 1.9.2.468.g3f0c02a
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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 + #endif /* __CONFIG_TERASIC_DE0_H__ */ -- 1.9.2.468.g3f0c02a
On Friday, December 11, 2015 at 10:15:50 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
Does Atlas have a dedicated QSPI NOR ?
Best regards, Marek Vasut
On 12/11/2015 08:21 AM, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:50 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
Does Atlas have a dedicated QSPI NOR ?
No, it does not.
Dinh
On Friday, December 11, 2015 at 04:43:19 PM, Dinh Nguyen wrote:
On 12/11/2015 08:21 AM, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:50 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
Does Atlas have a dedicated QSPI NOR ?
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
On Fri, 2015-12-11 at 18:36 +0100, Marek Vasut wrote:
On Friday, December 11, 2015 at 04:43:19 PM, Dinh Nguyen wrote:
On 12/11/2015 08:21 AM, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:50 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
Does Atlas have a dedicated QSPI NOR ?
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 ? :)
We can always arrange a board for you. Let me work out the arrangement then.
Thanks Chin Liang
Best regards, Marek Vasut
On Fri 2015-12-11 17:15:50, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
#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
On Saturday, December 12, 2015 at 10:10:00 PM, Pavel Machek wrote:
On Fri 2015-12-11 17:15:50, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
#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.
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
On Sat, 2015-12-12 at 22:45 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 10:10:00 PM, Pavel Machek wrote:
On Fri 2015-12-11 17:15:50, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
#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.
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.
Yah this sound good. Let me do that by having them definied into socfpga_common.h
Thanks Chin Liang
Best regards, Marek Vasut
On Sat, 2015-12-12 at 22:10 +0100, Pavel Machek wrote:
On Fri 2015-12-11 17:15:50, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_de0_nano_soc.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index 16e146c..c42175d 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -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
#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.
Yup, let me do that by putting them into socfpga_common.h
Thanks Chin Liang
Pavel
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_mcvevk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_mcvevk.h b/include/configs/socfpga_mcvevk.h index d051eec..a176a21 100644 --- a/include/configs/socfpga_mcvevk.h +++ b/include/configs/socfpga_mcvevk.h @@ -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) +#define MTDPARTS_DEFAULT "mtdparts=ff705000.spi:"\ + "256k(spl)," \ + "64k(env)," \ + "64k(dtb)," \ + "256k(boot)," \ + "16m(kernel)," \ + "16m(rootfs)," \ + "-(UBI)\0" +#endif + #endif /* __CONFIG_DENX_MCVEVK_H__ */ -- 1.9.2.468.g3f0c02a
On Friday, December 11, 2015 at 10:15:51 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_mcvevk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_mcvevk.h b/include/configs/socfpga_mcvevk.h index d051eec..a176a21 100644 --- a/include/configs/socfpga_mcvevk.h +++ b/include/configs/socfpga_mcvevk.h @@ -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) +#define MTDPARTS_DEFAULT "mtdparts=ff705000.spi:"\
"256k(spl)," \"64k(env)," \"64k(dtb)," \"256k(boot)," \"16m(kernel)," \"16m(rootfs)," \"-(UBI)\0"+#endif
MCVEVK has no QSPI NOR, so NAK.
Best regards, Marek Vasut
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_sockit.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h index 5bcee05..a516e5d 100644 --- a/include/configs/socfpga_sockit.h +++ b/include/configs/socfpga_sockit.h @@ -91,4 +91,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 + #endif /* __CONFIG_TERASIC_SOCKIT_H__ */ -- 1.9.2.468.g3f0c02a
On Friday, December 11, 2015 at 10:15:52 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_sockit.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h index 5bcee05..a516e5d 100644 --- a/include/configs/socfpga_sockit.h +++ b/include/configs/socfpga_sockit.h @@ -91,4 +91,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
Same question about the layout as on the CV-SoCDK applies here.
Best regards, Marek Vasut
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de --- include/configs/socfpga_socrates.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h index 16a2a86..7b48afa 100644 --- a/include/configs/socfpga_socrates.h +++ b/include/configs/socfpga_socrates.h @@ -92,4 +92,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 + #endif /* __CONFIG_SOCFPGA_SOCRATES_H__ */ -- 1.9.2.468.g3f0c02a
On Friday, December 11, 2015 at 10:15:53 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_socrates.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h index 16a2a86..7b48afa 100644 --- a/include/configs/socfpga_socrates.h +++ b/include/configs/socfpga_socrates.h @@ -92,4 +92,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
DTTO
Best regards, Marek Vasut
On Friday, December 11, 2015 at 10:15:48 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -96,4 +96,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)
Is this the default Altera layout ?
+#define MTDPARTS_DEFAULT "mtdparts=ff705000.spi:"\
"256k(spl)," \"64k(env)," \"64k(dtb)," \
What happens if the DT grows over 64k ?
"256k(boot)," \
256k is not enough for U-Boot (considering this is U-Boot).
"16m(kernel)," \"16m(rootfs)," \
Why don't you put kernel and rootfs onto the UBI volume instead ?
"-(UBI)\0"+#endif
#endif /* __CONFIG_SOCFPGA_CYCLONE5_H__ */
1.9.2.468.g3f0c02a
Best regards, Marek Vasut
On Fri, 2015-12-11 at 15:21 +0100, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:48 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -96,4 +96,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)
Is this the default Altera layout ?
Yah but believe it need to be updated
+#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.
"256k(boot)," \256k is not enough for U-Boot (considering this is U-Boot).
Will create boot region to avoid worrying the size issue
"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.
Thanks Chin Liang
"-(UBI)\0"+#endif
#endif /* __CONFIG_SOCFPGA_CYCLONE5_H__ */
1.9.2.468.g3f0c02a
Best regards, Marek Vasut
On Saturday, December 12, 2015 at 12:59:02 AM, Chin Liang See wrote:
On Fri, 2015-12-11 at 15:21 +0100, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:48 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -96,4 +96,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)
Is this the default Altera layout ?
Yah but believe it need to be updated
So you're not worried about compatibility I presume ?
+#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.
"256k(boot)," \256k is not enough for U-Boot (considering this is U-Boot).
Will create boot region to avoid worrying the size issue
"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.
Can you share the final layout before you roll out patches ?
On Sat, 2015-12-12 at 04:20 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 12:59:02 AM, Chin Liang See wrote:
On Fri, 2015-12-11 at 15:21 +0100, Marek Vasut wrote:
On Friday, December 11, 2015 at 10:15:48 AM, Chin Liang See wrote:
Enabling mtd partitioning layout which indicate partition for various boot partition
Signed-off-by: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Dinh Nguyen dinh.linux@gmail.com Cc: Pavel Machek pavel@denx.de Cc: Marek Vasut marex@denx.de Cc: Stefan Roese sr@denx.de
include/configs/socfpga_cyclone5_socdk.h | 12 ++++++++++++ 1 file changed, 12 insertions(+)
diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 67bb35f..e4a1657 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -96,4 +96,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)
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.
+#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"
Hmmm I didn't see the area for SPL. Wonder is it part of u-boot partition?
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.
"256k(boot)," \256k is not enough for U-Boot (considering this is U-Boot).
Will create boot region to avoid worrying the size issue
"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.
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: [...]
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.
OK
+#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"Hmmm I didn't see the area for SPL. Wonder is it part of u-boot partition?
Yes, the u-boot-with-spl-dtb.sfp (which contains 4 copies of SPL and U-Boot image) goes into the 'u-boot' partition.
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.
I am using env1 and env2, see above. That should be enough.
"256k(boot)," \256k is not enough for U-Boot (considering this is U-Boot).
Will create boot region to avoid worrying the size issue
"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.
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
The environment will be used to determine the image offset for mentioned boot images from boot partition.
Thanks Chin Liang
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:
[...]
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
For backward compatibility, it can be raw if user want to stick with old way.
Thanks Chin Liang
The environment will be used to determine the image offset for mentioned boot images from boot partition.
Thanks Chin Liang
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:
[...]
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
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
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:
[...]
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
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 ?
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.
Thanks Chin Liang
Best regards, Marek Vasut
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See
wrote:
[...]
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
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 ?
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.
But the rootfs partition still can be presented to Linux as ubifs.
That's for sure :)
Best regards, Marek Vasut
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See
wrote:
[...]
> 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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
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 ?
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.
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?
Thanks Chin Liang
But the rootfs partition still can be presented to Linux as ubifs.
That's for sure :)
Best regards, Marek Vasut
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See
wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See
wrote:
[...]
> > 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)
I'd say you should just call this u-boot, see above for the rationale.
> 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 ?
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 ?
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.
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.
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See
wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote: > On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang > See
> wrote: [...]
> > > 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) > > I'd say you should just call this u-boot, see above for > the > rationale. > > > 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 ?
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 ?
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.
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.
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 :)
Thanks Chin Liang
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See
wrote: > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote: > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang > > See > > > wrote: > [...] > > > > > 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) > > > > I'd say you should just call this u-boot, see above for > > the > > rationale. > > > > > 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 ? > > 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 ?
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.
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.
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).
On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
wrote:
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote: > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang > See > > wrote: > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote: > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin > > > Liang > > > See > > > > > wrote: > > [...] > > > > > > > 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) > > > > > > I'd say you should just call this u-boot, see above > > > for > > > the > > > rationale. > > > > > > > 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 ? > > > > 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 ?
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.
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.
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).
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.
Thanks Chin Liang
On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See
wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang See
wrote: > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote: > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang > > See > > > > wrote: > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote: > > > > On Saturday, December 12, 2015 at 07:30:46 AM, Chin > > > > Liang > > > > See > > > > > > > wrote: > > > [...] > > > > > > > > > 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) > > > > > > > > I'd say you should just call this u-boot, see above > > > > for > > > > the > > > > rationale. > > > > > > > > > 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 ? > > > > > > 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 ? > > 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.
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.
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).
After grabbing a coffee
That's a good idea, though I think I will make do with a green tea (抹茶).
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.
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@1536k(UBI)
This will create overlapping partitions "boot,root" and "UBI" .
On Mon, 2015-12-14 at 01:58 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 02:03:02 PM, Chin Liang See
wrote:
On Sun, 2015-12-13 at 04:14 +0100, Marek Vasut wrote: > On Sunday, December 13, 2015 at 01:49:06 AM, Chin Liang > See > > wrote: > > On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote: > > > On Sunday, December 13, 2015 at 12:59:48 AM, Chin > > > Liang > > > See > > > > > > wrote: > > > > On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut > > > > wrote: > > > > > On Saturday, December 12, 2015 at 07:30:46 AM, > > > > > Chin > > > > > Liang > > > > > See > > > > > > > > > wrote: > > > > [...] > > > > > > > > > > > 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) > > > > > > > > > > I'd say you should just call this u-boot, see > > > > > above > > > > > for > > > > > the > > > > > rationale. > > > > > > > > > > > 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 ? > > > > > > > > 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 ? > > > > 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.
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.
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).
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. :)
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.
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root), -@1536k(UBI)
This will create overlapping partitions "boot,root" and "UBI" .
Nice, let me give it a try.
Thanks Chin Liang
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:
[..]
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. :)
The one with baked rice in it, right ? I love that as well :)
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.
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root), -@1536k(UBI)
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
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:
[...]
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.
Try this:
mtdparts=1m(u -boot),256k(env1),256k(env2),14848k(boot),112m(root), -@1536k(UBI)
This will create overlapping partitions "boot,root" and "UBI" .
Nice, let me give it a try.
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.
Thanks Chin Liang
Best regards, Marek Vasut
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:
[...]
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.
Try this:
mtdparts=1m(u -boot),256k(env1),256k(env2),14848k(boot),112m(root), -@1536k(UBI)
This will create overlapping partitions "boot,root" and "UBI" .
Nice, let me give it a try.
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.
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
On Tue, 2015-12-15 at 01:32 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See wrote:
[...]
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.
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.
Thanks Chin Liang
Best regards, Marek Vasut
On Tuesday, December 15, 2015 at 02:09:42 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 01:32 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See
wrote:
[...]
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.
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.
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
On Tue, 2015-12-15 at 02:15 +0100, Marek Vasut wrote:
On Tuesday, December 15, 2015 at 02:09:42 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 01:32 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See
wrote:
[...]
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.
Yeah, I managed to get ubiufsmount work in U-Boot now. Need to disable the 4K_SECTORS when enabling UBI at NOR flash.
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.
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!
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 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
Best regards, Marek Vasut
On Tuesday, December 15, 2015 at 11:09:59 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 02:15 +0100, Marek Vasut wrote:
On Tuesday, December 15, 2015 at 02:09:42 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 01:32 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See
wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang See
wrote:
[...]
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.
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
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.
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@lists.denx.de/msg195327.html
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 ?
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
Best regards, Marek Vasut
Best regards, Marek Vasut
On Tue, 2015-12-15 at 19:16 +0100, Marek Vasut wrote:
On Tuesday, December 15, 2015 at 11:09:59 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 02:15 +0100, Marek Vasut wrote:
On Tuesday, December 15, 2015 at 02:09:42 AM, Chin Liang See wrote:
On Tue, 2015-12-15 at 01:32 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 04:22:57 PM, Chin Liang See
wrote:
On Mon, 2015-12-14 at 02:25 +0100, Marek Vasut wrote: > On Monday, December 14, 2015 at 02:22:32 AM, Chin Liang > See
> wrote:
[...]
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.
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.
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.
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@lists.denx.de/msg195327.html
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 ?
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.
Thanks Chin Liang
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
Best regards, Marek Vasut
Best regards, Marek Vasut
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote: [...]
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.
I guess because most people don't use UBI on NOR yet.
[...]
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.
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
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:
[..]
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.
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)
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
Thanks Chin Liang
Best regards, Marek Vasut
On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See wrote:
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:
[..]
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.
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)
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
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
On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See wrote:
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See wrote:
[..]
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.
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)
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
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.
But will make the switch soon once done with few in progress patches for U-Boot.
Thanks Chin Liang
Best regards, Marek Vasut
On Tuesday, December 22, 2015 at 05:00:42 PM, Chin Liang See wrote:
On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See wrote:
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See
wrote:
[..]
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.
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)
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
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.
Well, at least you're honest ... but *sigh*, it'd be nice if you tested mainline only, really.
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
On Tue, 2015-12-22 at 21:10 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 05:00:42 PM, Chin Liang See wrote:
On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See wrote:
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See
wrote:
[..]
> 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.
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)
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
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.
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.
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.
Thanks Chin Liang
Best regards, Marek Vasut
On Wednesday, December 23, 2015 at 01:24:00 AM, Chin Liang See wrote:
On Tue, 2015-12-22 at 21:10 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 05:00:42 PM, Chin Liang See wrote:
On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 04:49:54 PM, Chin Liang See
wrote:
On Fri, 2015-12-18 at 14:10 +0100, Marek Vasut wrote:
On Friday, December 18, 2015 at 10:39:12 AM, Chin Liang See
wrote:
[..]
> > 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.
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)
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
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.
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.
Please check USB host, I suspect it is broken. I don't have the cable handy now, so I cannot check.
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.
Looks like with u-boot-socfpga/master, all is good.
On Wed, 2015-12-23 at 01:48 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 01:24:00 AM, Chin Liang See wrote:
On Tue, 2015-12-22 at 21:10 +0100, Marek Vasut wrote:
On Tuesday, December 22, 2015 at 05:00:42 PM, Chin Liang See wrote:
On Tue, 2015-12-22 at 16:53 +0100, Marek Vasut wrote:
[..]
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.
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.
Sure, let me try it out now.
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.
Looks like with u-boot-socfpga/master, all is good.
Nice
Thanks Chin Liang
Hi!
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.
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
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
Hi!
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.
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.
Thanks Chin Liang
Pavel
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
Hi!
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.
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.
Is there more ?
Best regards, Marek Vasut
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
Hi!
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.
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.
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 :)
Thanks Chin Liang
Best regards, Marek Vasut
On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
Hi!
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.
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.
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.
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.
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
On Thu, 2015-12-24 at 02:30 +0100, Marek Vasut wrote:
On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
[..]
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.
Yah, I just tested master against arria5_socdk and they are doing good :) For record, this include testing sdmmc, sf, i2c, usb and ethernet.
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 :)
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
Thanks Chin Liang
Best regards, Marek Vasut
On Monday, December 28, 2015 at 09:51:44 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 02:30 +0100, Marek Vasut wrote:
On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See
wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
[..]
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.
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 ?
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 :)
Well, have fun checking this stuff. I think this has to do with BSS usage.
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
The stack and malloc area are already placed into DRAM when running board_init_r() in SPL. I suspect your FAT issues might be elsewhere.
Best regards, Marek Vasut
On Mon, 2015-12-28 at 13:39 +0100, Marek Vasut wrote:
On Monday, December 28, 2015 at 09:51:44 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 02:30 +0100, Marek Vasut wrote:
On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See
wrote:
On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
[..]
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.
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 ?
QSPI is good as tested with sf command.
Thanks Chin Liang
On Tuesday, December 29, 2015 at 10:06:06 PM, Chin Liang See wrote:
On Mon, 2015-12-28 at 13:39 +0100, Marek Vasut wrote:
On Monday, December 28, 2015 at 09:51:44 AM, Chin Liang See wrote:
On Thu, 2015-12-24 at 02:30 +0100, Marek Vasut wrote:
On Thursday, December 24, 2015 at 12:36:45 AM, Chin Liang See
wrote:
On Thu, 2015-12-24 at 00:16 +0100, Marek Vasut wrote:
On Wednesday, December 23, 2015 at 11:57:49 PM, Chin Liang See
wrote: > On Wed, 2015-12-23 at 20:02 +0100, Pavel Machek wrote:
[..]
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.
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 ?
QSPI is good as tested with sf command.
Cool, thanks!
Best regards, Marek Vasut
On Wednesday, December 23, 2015 at 08:02:11 PM, Pavel Machek wrote:
Hi!
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.
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 ;-).
It is not and never was supported to mix U-Boot and U-Boot-SPL versions.
Best regards, Marek Vasut
(Please, trim your emails when replying)
On Mon 2015-12-14 01:58:04, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
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 (抹茶).
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.
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@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.
Pavel
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
On Mon 2015-12-14 01:58:04, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:43:58 AM, Chin Liang See wrote:
On Mon, 2015-12-14 at 01:22 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:11:27 AM, Chin Liang See wrote:
On Sun, 2015-12-13 at 16:42 +0100, Marek Vasut wrote:
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 (抹茶).
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.
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@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.
Please explain in detail why do you think so.
Best regards, Marek Vasut
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@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.
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 :-).
Pavel
On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@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.
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.
Best regards, Marek Vasut
On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root),-@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.
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.
Pavel
On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
Try this:
mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root) ,-@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.
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.
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.
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 ?
Best regards, Marek Vasut
On Mon 2015-12-14 13:20:28, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote:
(Please, trim your emails when replying)
> Try this: > > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(root) > ,-@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.
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.
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.
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. Pavel
On Monday, December 14, 2015 at 01:53:53 PM, Pavel Machek wrote:
On Mon 2015-12-14 13:20:28, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:31:32, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:26:39 PM, Pavel Machek wrote:
On Mon 2015-12-14 12:09:08, Marek Vasut wrote:
On Monday, December 14, 2015 at 08:54:38 AM, Pavel Machek wrote: > (Please, trim your emails when replying) > > > Try this: > > > > mtdparts=1m(u-boot),256k(env1),256k(env2),14848k(boot),112m(r > > oot) ,-@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.
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.
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.
I sense the overlapping partitions are a matter of taste here.
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.
I do not want to maintain multiple configurations, especially is there is known working alternative which covers all the usecases.
Best regards, Marek Vasut
On Mon, 2015-12-14 at 14:34 +0100, Marek Vasut wrote:
On Monday, December 14, 2015 at 01:53:53 PM, Pavel Machek wrote:
On Mon 2015-12-14 13:20:28, Marek Vasut wrote:
On Monday, December 14, 2015 at 12:51:16 PM, Pavel Machek wrote:
[..]
I sense the overlapping partitions are a matter of taste here.
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.
I do not want to maintain multiple configurations, especially is there is known working alternative which covers all the usecases.
I believe the boot command will abstract these different use cases. We will have different command for qspiload_raw and qspiload which is the default that utilize ubifsload.
Thanks Chin Liang
Best regards, Marek Vasut
On Sun, 2015-12-13 at 01:01 +0100, Marek Vasut wrote:
On Sunday, December 13, 2015 at 12:59:48 AM, Chin Liang See wrote:
On Sat, 2015-12-12 at 16:36 +0100, Marek Vasut wrote:
On Saturday, December 12, 2015 at 07:30:46 AM, Chin Liang See wrote:
[...]
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)
I'd say you should just call this u-boot, see above for the rationale.
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 ?
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 ?
Actually this partition can be used as raw partition if user want to store zimage and dtb as raw binary. But the rootfs partition still can be presented to Linux as ubifs.
Thanks Chin Liang
Best regards, Marek Vasut
participants (4)
-
Chin Liang See -
Dinh Nguyen -
Marek Vasut -
Pavel Machek