[meta-freescale] [meta-fsl-arm PATCH 4/4] mxs-base.inc: Add default settings for UBI filesystem generation

[Eric Bénard]

Hi Otavio,

Le Wed, 18 Sep 2013 10:43:41 -0300,
Otavio Salvador <otavio at ossystems.com.br> a écrit :

> On Wed, Sep 18, 2013 at 10:33 AM, Eric Bénard <eric at eukrea.com> wrote:
> > Le Wed, 18 Sep 2013 09:58:47 -0300,
> > Daiane Angolini <daiane.list at gmail.com> a écrit :
> >> On Wed, Sep 18, 2013 at 9:32 AM, Eric Bénard <eric at eukrea.com> wrote:
> >> > Le Wed, 18 Sep 2013 09:23:22 -0300,
> >> > Otavio Salvador <otavio at ossystems.com.br> a écrit :
> >> >> I had this for loooooong time in my queue and I recall to try it, but
> >> >> not lately. I will also extend the commit log and move it to mx28evk
> >> >> board.
> >> >>
> >> > no these values are wrong as they come from an i.MX35 tutorial so that
> >> > won't work on an i.MX28EVK (moreover this board hasn't any NAND
> >> > populated by default so the values will depend on the NAND flash the
> >> > user puts in the socket - here I tested with 2k and 4k flashes).
> >> >
> >> > So if you can't test it please don't add default values.
> >>
> >> If not use default values, what do you suggest?
> >>
> > you need a default value for a pair of CPU/NAND flash.
> >
> > In the present case the values in the log come from
> > https://community.freescale.com/docs/DOC-1579 which is an i.MX35 and
> > not a MXS (and is not embedding the same nand flash controller and as
> > stated on the page : "Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0")
> > so I'm quite sure the i.MX35 values won't work.
> >
> > Moreover "-s 512" is wrong vs the webpage content, other values are
> 
> I agreed in the wrong value and I will fix it.
> 
> > not in sync with the patch's log and surprisingly for our i.MX35 boards
> > I have :
> > MKUBIFS_ARGS = "-m 2048 -e 129024 -c 2030"
> > UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512"
> > which are exactly the values Otavio wants to put in mxs-base.inc (so I
> > assume he took them from our cpuimx35 board's conf file but copied the
> 
> No, I didn't copy them from your layer.
> 
you're right that can also come from imx31pdk.conf but anyway the
real problem is that doesn't come from a MXS board.

> > community's log values and both don't match as I assume iMX35 PDK's log
> > comes from the LTIB generated kernel when we are using mainline and so
> > a different NAND driver).
> >
> > Last but not least I have tested some 2k and 4k NAND flashs on i.MX28
> > with UBI files generated using OE-Core and for example for 2k I have :
> > MKUBIFS_ARGS = "-m 2048 -e 126976 -c 1900"
> > UBINIZE_ARGS = "-m 2048 -p 128KiB -s 2048"
> > which corresponds to the values reported by the (3.10.x) kernel running
> > on the boards (and other i.MX28 boards embedding NAND are using the same
> > values for the key parameters of these variables - Denx's m28 for
> > example as you can see in their manual :
> > http://www.denx.de/wiki/publish/DULG/DULG-m28evk.pdf )
> 
> I will check the NAND I have here and see if it works with this values or not.
> 
to be sure you need to get the values from your NAND on your board and
not to copy from other boards which may have different NAND flash.
This way you can put a proper log message with log coming from your
board and not from somewhere else.

How to match the values was properly explained in old OE's machines for
example beagleboard.conf :
http://cgit.openembedded.org/openembedded/tree/conf/machine/beagleboard.conf#n28

> >> Even if we can test it (I think I have access to one NAND to attach on imx28)
> >> it will be only *one* NAND
> >>
> > True. As i.MX28 EVK comes without a NAND I think it's better to not
> > allow generating UBI rootfs for this board with random values and let
> > user who need UBI add the right values vs the flash they are really
> > using (same for all the other EVK as now Freescale ship empty sockets
> > by default).
> 
> I disagree here. We need to be able to test it and then we ought to
> provide default values for it. We ought to have the part number in the
> comment about the params and make clear it needs adjustments if using
> other part number.
> 
Then start by doing a real test it on a board and then you can cook
the right patch ;-)

Eric