[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 2/6] arm: socfpga: arria5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Dinh Nguyen]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Pavel Machek]

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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 3/6] arm: socfpga: de0-nano-soc: Enabling mtd partitioning layout

[Chin Liang See]

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
> 

[U-Boot] [PATCH 4/6] arm: socfpga: mcvevk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 4/6] arm: socfpga: mcvevk: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 5/6] arm: socfpga: sockit: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 5/6] arm: socfpga: sockit: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 6/6] arm: socfpga: socrates: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 6/6] arm: socfpga: socrates: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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 ?

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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.

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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).

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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),- at 1536k(UBI)

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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),
> - at 1536k(UBI)
> 
> This will create overlapping partitions "boot,root" and "UBI" .

Nice, let me give it a try.

Thanks
Chin Liang

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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),
> > - at 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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),
> > > - at 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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),
> > > > - at 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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 at 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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 at 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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.

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

(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),- at 1536k(UBI)
> 
> This will create overlapping partitions "boot,root" and "UBI" .

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

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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),- at 1536k
> > (UBI)
> > 
> > This will create overlapping partitions "boot,root" and "UBI" .
> 
> Just because you can does not mean that you should. This looks like a
> nasty trap for a user.

Please explain in detail why do you think so.

Best regards,
Marek Vasut

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

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),- at 1536k
> > > (UBI)
> > > 
> > > This will create overlapping partitions "boot,root" and "UBI" .
> > 
> > Just because you can does not mean that you should. This looks like a
> > nasty trap for a user.
> 
> 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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),- at 1
> > > > 536k (UBI)
> > > > 
> > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > 
> > > Just because you can does not mean that you should. This looks like a
> > > nasty trap for a user.
> > 
> > Please explain in detail why do you think so.
> 
> 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

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),- at 1
> > > > > 536k (UBI)
> > > > > 
> > > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > > 
> > > > Just because you can does not mean that you should. This looks like a
> > > > nasty trap for a user.
> > > 
> > > Please explain in detail why do you think so.
> > 
> > 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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)
> > > > > > ,- at 1 536k (UBI)
> > > > > > 
> > > > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > > > 
> > > > > Just because you can does not mean that you should. This looks like
> > > > > a nasty trap for a user.
> > > > 
> > > > Please explain in detail why do you think so.
> > > 
> > > 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Pavel Machek]

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)
> > > > > > > ,- at 1 536k (UBI)
> > > > > > > 
> > > > > > > This will create overlapping partitions "boot,root" and "UBI" .
> > > > > > 
> > > > > > Just because you can does not mean that you should. This looks like
> > > > > > a nasty trap for a user.
> > > > > 
> > > > > Please explain in detail why do you think so.
> > > > 
> > > > 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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Marek Vasut]

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) ,- at 1 536k (UBI)
> > > > > > > > 
> > > > > > > > This will create overlapping partitions "boot,root" and "UBI"
> > > > > > > > .
> > > > > > > 
> > > > > > > Just because you can does not mean that you should. This looks
> > > > > > > like a nasty trap for a user.
> > > > > > 
> > > > > > Please explain in detail why do you think so.
> > > > > 
> > > > > 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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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

[U-Boot] [PATCH 1/6] arm: socfpga: cyclone5-socdk: Enabling mtd partitioning layout

[Chin Liang See]

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