[PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Tom Rini]

Hey all,

This short series does two things.  For 3 machines we fix a bug of using
'?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
machines that have this issue today except for...) and on the 4th,
am335x-evm we add UBI support as well.  On the first three, these are
correct by inspection and on the fourth, I've written to and mounted
systemd-image from NAND on my EVM (it didn't work as I was using a custom
uImage that's not systemd-sane, and fixing that and confirming the config
used here works is on my list).

-- 
Tom

[PATCH 1/4] am37x-evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am37x-evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am37x-evm.conf b/conf/machine/am37x-evm.conf
index e4170f4..ddb54e8 100644
--- a/conf/machine/am37x-evm.conf
+++ b/conf/machine/am37x-evm.conf
@@ -16,7 +16,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH 2/4] ti814x.inc: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/include/ti814x.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/include/ti814x.inc b/conf/machine/include/ti814x.inc
index c53557f..475a212 100644
--- a/conf/machine/include/ti814x.inc
+++ b/conf/machine/include/ti814x.inc
@@ -20,7 +20,7 @@ UBOOT_LOADADDRESS = "0x80008000"
 EXTRA_IMAGEDEPENDS += "u-boot"
 
 # Ship all kernel modules
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lqn -e 128"
 SERIAL_CONSOLE = "115200 ttyO0"
 MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet"
-- 
1.7.0.4

[PATCH 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/omap3evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/omap3evm.conf b/conf/machine/omap3evm.conf
index 9cd04ed..16caf05 100644
--- a/conf/machine/omap3evm.conf
+++ b/conf/machine/omap3evm.conf
@@ -17,7 +17,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES

[Tom Rini]

We also change to using '+=' not '?=' with IMAGE_FSTYPES and add the
required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
line that sets us to use the PSP kernel tree and reference the TI wiki
for the source of our info.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am335x-evm.conf |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am335x-evm.conf b/conf/machine/am335x-evm.conf
index eedf072..624f386 100644
--- a/conf/machine/am335x-evm.conf
+++ b/conf/machine/am335x-evm.conf
@@ -12,11 +12,15 @@ GUI_MACHINE_CLASS = "smallscreen"
 
 require conf/machine/include/ti33x.inc
 
-IMAGE_FSTYPES ?= "tar.bz2"
+IMAGE_FSTYPES += "ubi tar.bz2"
 
 SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp"
+# UBI information, for more details see
+# http://processors.wiki.ti.com/index.php/UBIFS_Support
+MKUBIFS_ARGS = "-F -m 2048 -e 126976 -c 1580"
+UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512 -O 2048"
 
 PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
 
-- 
1.7.0.4

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Denys Dmytriyenko]

On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
> Hey all,
> 
> This short series does two things.  For 3 machines we fix a bug of using
> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
> machines that have this issue today except for...) and on the 4th,
> am335x-evm we add UBI support as well.  On the first three, these are
> correct by inspection and on the fourth, I've written to and mounted
> systemd-image from NAND on my EVM (it didn't work as I was using a custom
> uImage that's not systemd-sane, and fixing that and confirming the config
> used here works is on my list).

All,

Tom and I started talking on IRC and then decided to move the discussion back 
to the mailing list for others to participate.

So, basically, the proposal is to do this in our machine.conf files:

-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"

My response was that we shouldn't do that. The conf files that may set, append 
or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
to a sane tar.gz. From end-user perspective, they expect the setting in their 
local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
case. Of course, distro has the last word and potentially can alter it, but in 
most cases it shouldn't. That's how it works now and I believe it's the 
correct behaviour. Changing it to append additional values to what user wants 
is slightly heavy-handed, in my opinion. In other words, those are suggested 
image types, not enforced ones.

As Tom poined out, this is the same behaviour as currently used in OE-Core, 
where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".

The original issue in question may be coming from the way some setup scripts 
pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
something, that is not very suitable for the machines being used. This needs 
to be left unset and for the end-user to decide and set specifically, IMHO.

Comments, opinions?

-- 
Denys

Re: [PATCH 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES

[Koen Kooi]

Op 8 mrt. 2012, om 20:34 heeft Tom Rini het volgende geschreven:

> We also change to using '+=' not '?=' with IMAGE_FSTYPES and add the
> required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
> line that sets us to use the PSP kernel tree and reference the TI wiki
> for the source of our info.

The OE classic way of documenting is a lot better and doesn't rely on wiki pages but on the submitter actually checking the output of the commands. So please use the old style way of documenting the params.

regards,

Koen

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Koen Kooi]

Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:

> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
>> Hey all,
>> 
>> This short series does two things.  For 3 machines we fix a bug of using
>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
>> machines that have this issue today except for...) and on the 4th,
>> am335x-evm we add UBI support as well.  On the first three, these are
>> correct by inspection and on the fourth, I've written to and mounted
>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
>> uImage that's not systemd-sane, and fixing that and confirming the config
>> used here works is on my list).
> 
> All,
> 
> Tom and I started talking on IRC and then decided to move the discussion back 
> to the mailing list for others to participate.
> 
> So, basically, the proposal is to do this in our machine.conf files:
> 
> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> +IMAGE_FSTYPES += "jffs2 tar.bz2"
> 
> My response was that we shouldn't do that.

+= is the OE classic way of doing things and is IMNSHO the right thing.

> The conf files that may set, append 
> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
> to a sane tar.gz. From end-user perspective, they expect the setting in their 
> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
> case. Of course, distro has the last word and potentially can alter it, but in 
> most cases it shouldn't. That's how it works now and I believe it's the 
> correct behaviour. Changing it to append additional values to what user wants 
> is slightly heavy-handed, in my opinion. In other words, those are suggested 
> image types, not enforced ones.
> 
> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
> 
> The original issue in question may be coming from the way some setup scripts 
> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
> something, that is not very suitable for the machines being used. This needs 
> to be left unset and for the end-user to decide and set specifically, IMHO.
> 
> Comments, opinions?

See the discussion on OE-core a while back. There was a lot of handwaving done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf is the right way to do this. I think it's not intuitive because you have to remember that += and _append are expanded in different points during parsing, which requires either deep bitbake knowledge or minor braindamage.

regards,

Koen

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Denys Dmytriyenko]

On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
> 
> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
> >> Hey all,
> >> 
> >> This short series does two things.  For 3 machines we fix a bug of using
> >> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
> >> machines that have this issue today except for...) and on the 4th,
> >> am335x-evm we add UBI support as well.  On the first three, these are
> >> correct by inspection and on the fourth, I've written to and mounted
> >> systemd-image from NAND on my EVM (it didn't work as I was using a custom
> >> uImage that's not systemd-sane, and fixing that and confirming the config
> >> used here works is on my list).
> > 
> > All,
> > 
> > Tom and I started talking on IRC and then decided to move the discussion back 
> > to the mailing list for others to participate.
> > 
> > So, basically, the proposal is to do this in our machine.conf files:
> > 
> > -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> > +IMAGE_FSTYPES += "jffs2 tar.bz2"
> > 
> > My response was that we shouldn't do that.
> 
> += is the OE classic way of doing things and is IMNSHO the right thing.

Not convinced:

$ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
     30 =
      1 -
     44 ?=
     31 +=

BTW, dash in there is a fluke coming from here:
cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"

> > The conf files that may set, append 
> > or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
> > and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
> > to a sane tar.gz. From end-user perspective, they expect the setting in their 
> > local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
> > machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
> > case. Of course, distro has the last word and potentially can alter it, but in 
> > most cases it shouldn't. That's how it works now and I believe it's the 
> > correct behaviour. Changing it to append additional values to what user wants 
> > is slightly heavy-handed, in my opinion. In other words, those are suggested 
> > image types, not enforced ones.
> > 
> > As Tom poined out, this is the same behaviour as currently used in OE-Core, 
> > where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
> > 
> > The original issue in question may be coming from the way some setup scripts 
> > pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
> > something, that is not very suitable for the machines being used. This needs 
> > to be left unset and for the end-user to decide and set specifically, IMHO.
> > 
> > Comments, opinions?
> 
> See the discussion on OE-core a while back. There was a lot of handwaving 
> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
> is the right way to do this. I think it's not intuitive because you have to 
> remember that += and _append are expanded in different points during 
> parsing, which requires either deep bitbake knowledge or minor braindamage.

Link or it never happened :)

-- 
Denys

Re: [PATCH 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES

[Tom Rini]

On Fri, Mar 09, 2012 at 07:16:22AM +0100, Koen Kooi wrote:
> 
> Op 8 mrt. 2012, om 20:34 heeft Tom Rini het volgende geschreven:
> 
> > We also change to using '+=' not '?=' with IMAGE_FSTYPES and add the
> > required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
> > line that sets us to use the PSP kernel tree and reference the TI wiki
> > for the source of our info.
> 
> The OE classic way of documenting is a lot better and doesn't rely on
> wiki pages but on the submitter actually checking the output of the
> commands. So please use the old style way of documenting the params.

I disagree here.  The wiki page here has the calculations as to why the
erase size is 126976 whereas just doing ubiattach will only print out
the in-use value.  How about adding a line about verifying these with
ubiattach or dmesg ?

-- 
Tom

Re: [PATCH 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES

[Koen Kooi]

Op 9 mrt. 2012, om 16:54 heeft Tom Rini het volgende geschreven:

> On Fri, Mar 09, 2012 at 07:16:22AM +0100, Koen Kooi wrote:
>> 
>> Op 8 mrt. 2012, om 20:34 heeft Tom Rini het volgende geschreven:
>> 
>>> We also change to using '+=' not '?=' with IMAGE_FSTYPES and add the
>>> required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
>>> line that sets us to use the PSP kernel tree and reference the TI wiki
>>> for the source of our info.
>> 
>> The OE classic way of documenting is a lot better and doesn't rely on
>> wiki pages but on the submitter actually checking the output of the
>> commands. So please use the old style way of documenting the params.
> 
> I disagree here.  The wiki page here

It is still external documentation for things that people will get wrong

> has the calculations as to why the
> erase size is 126976 whereas just doing ubiattach will only print out
> the in-use value.  How about adding a line about verifying these with
> ubiattach or dmesg ?

That would be best. I should only need the machine.conf and the target board to figure out ubi params, not some random wiki

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Koen Kooi]

Op 9 mrt. 2012, om 16:01 heeft Denys Dmytriyenko het volgende geschreven:

> On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
>> 
>> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
>> 
>>> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
>>>> Hey all,
>>>> 
>>>> This short series does two things.  For 3 machines we fix a bug of using
>>>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
>>>> machines that have this issue today except for...) and on the 4th,
>>>> am335x-evm we add UBI support as well.  On the first three, these are
>>>> correct by inspection and on the fourth, I've written to and mounted
>>>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
>>>> uImage that's not systemd-sane, and fixing that and confirming the config
>>>> used here works is on my list).
>>> 
>>> All,
>>> 
>>> Tom and I started talking on IRC and then decided to move the discussion back 
>>> to the mailing list for others to participate.
>>> 
>>> So, basically, the proposal is to do this in our machine.conf files:
>>> 
>>> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
>>> +IMAGE_FSTYPES += "jffs2 tar.bz2"
>>> 
>>> My response was that we shouldn't do that.
>> 
>> += is the OE classic way of doing things and is IMNSHO the right thing.
> 
> Not convinced:
> 
> $ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
>     30 =
>      1 -
>     44 ?=
>     31 +=
> 
> BTW, dash in there is a fluke coming from here:
> cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"
> 
>>> The conf files that may set, append 
>>> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
>>> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
>>> to a sane tar.gz. From end-user perspective, they expect the setting in their 
>>> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
>>> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
>>> case. Of course, distro has the last word and potentially can alter it, but in 
>>> most cases it shouldn't. That's how it works now and I believe it's the 
>>> correct behaviour. Changing it to append additional values to what user wants 
>>> is slightly heavy-handed, in my opinion. In other words, those are suggested 
>>> image types, not enforced ones.
>>> 
>>> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
>>> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
>>> 
>>> The original issue in question may be coming from the way some setup scripts 
>>> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
>>> something, that is not very suitable for the machines being used. This needs 
>>> to be left unset and for the end-user to decide and set specifically, IMHO.
>>> 
>>> Comments, opinions?
>> 
>> See the discussion on OE-core a while back. There was a lot of handwaving 
>> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
>> is the right way to do this. I think it's not intuitive because you have to 
>> remember that += and _append are expanded in different points during 
>> parsing, which requires either deep bitbake knowledge or minor braindamage.
> 
> Link or it never happened :)

No link, but:

19:41 < Tartarus> But, where's the oe-core thread?
19:41 < koen> somewhere on OE-core
19:42 < koen> [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
19:42 < koen> july 2011

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Denys Dmytriyenko]

On Fri, Mar 09, 2012 at 07:43:40PM +0100, Koen Kooi wrote:
> 
> Op 9 mrt. 2012, om 16:01 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
> >> 
> >> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
> >> 
> >>> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
> >>>> Hey all,
> >>>> 
> >>>> This short series does two things.  For 3 machines we fix a bug of using
> >>>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
> >>>> machines that have this issue today except for...) and on the 4th,
> >>>> am335x-evm we add UBI support as well.  On the first three, these are
> >>>> correct by inspection and on the fourth, I've written to and mounted
> >>>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
> >>>> uImage that's not systemd-sane, and fixing that and confirming the config
> >>>> used here works is on my list).
> >>> 
> >>> All,
> >>> 
> >>> Tom and I started talking on IRC and then decided to move the discussion back 
> >>> to the mailing list for others to participate.
> >>> 
> >>> So, basically, the proposal is to do this in our machine.conf files:
> >>> 
> >>> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> >>> +IMAGE_FSTYPES += "jffs2 tar.bz2"
> >>> 
> >>> My response was that we shouldn't do that.
> >> 
> >> += is the OE classic way of doing things and is IMNSHO the right thing.
> > 
> > Not convinced:
> > 
> > $ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
> >     30 =
> >      1 -
> >     44 ?=
> >     31 +=
> > 
> > BTW, dash in there is a fluke coming from here:
> > cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"
> > 
> >>> The conf files that may set, append 
> >>> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
> >>> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
> >>> to a sane tar.gz. From end-user perspective, they expect the setting in their 
> >>> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
> >>> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
> >>> case. Of course, distro has the last word and potentially can alter it, but in 
> >>> most cases it shouldn't. That's how it works now and I believe it's the 
> >>> correct behaviour. Changing it to append additional values to what user wants 
> >>> is slightly heavy-handed, in my opinion. In other words, those are suggested 
> >>> image types, not enforced ones.
> >>> 
> >>> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
> >>> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
> >>> 
> >>> The original issue in question may be coming from the way some setup scripts 
> >>> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
> >>> something, that is not very suitable for the machines being used. This needs 
> >>> to be left unset and for the end-user to decide and set specifically, IMHO.
> >>> 
> >>> Comments, opinions?
> >> 
> >> See the discussion on OE-core a while back. There was a lot of handwaving 
> >> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
> >> is the right way to do this. I think it's not intuitive because you have to 
> >> remember that += and _append are expanded in different points during 
> >> parsing, which requires either deep bitbake knowledge or minor braindamage.
> > 
> > Link or it never happened :)
> 
> No link, but:
> 
> 19:41 < Tartarus> But, where's the oe-core thread?
> 19:41 < koen> somewhere on OE-core
> 19:42 < koen> [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
> 19:42 < koen> july 2011

Ok, here's the link:
http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061

It was discussed, there was no resolution, there were no changes.

Claiming that's how it's done in Classic OE (aka .dev) is not correct - as I 
showed above, 44 machines use ?=, 31 use += and 31 use =

OE-Core still uses ?=

Please give me the use case that this is meant to enable, which is not 
possible now.

-- 
Denys

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Koen Kooi]

Op 9 mrt. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:

> On Fri, Mar 09, 2012 at 07:43:40PM +0100, Koen Kooi wrote:
>> 
>> Op 9 mrt. 2012, om 16:01 heeft Denys Dmytriyenko het volgende geschreven:
>> 
>>> On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
>>>> 
>>>> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
>>>> 
>>>>> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
>>>>>> Hey all,
>>>>>> 
>>>>>> This short series does two things.  For 3 machines we fix a bug of using
>>>>>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
>>>>>> machines that have this issue today except for...) and on the 4th,
>>>>>> am335x-evm we add UBI support as well.  On the first three, these are
>>>>>> correct by inspection and on the fourth, I've written to and mounted
>>>>>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
>>>>>> uImage that's not systemd-sane, and fixing that and confirming the config
>>>>>> used here works is on my list).
>>>>> 
>>>>> All,
>>>>> 
>>>>> Tom and I started talking on IRC and then decided to move the discussion back 
>>>>> to the mailing list for others to participate.
>>>>> 
>>>>> So, basically, the proposal is to do this in our machine.conf files:
>>>>> 
>>>>> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
>>>>> +IMAGE_FSTYPES += "jffs2 tar.bz2"
>>>>> 
>>>>> My response was that we shouldn't do that.
>>>> 
>>>> += is the OE classic way of doing things and is IMNSHO the right thing.
>>> 
>>> Not convinced:
>>> 
>>> $ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
>>>    30 =
>>>     1 -
>>>    44 ?=
>>>    31 +=
>>> 
>>> BTW, dash in there is a fluke coming from here:
>>> cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"
>>> 
>>>>> The conf files that may set, append 
>>>>> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
>>>>> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
>>>>> to a sane tar.gz. From end-user perspective, they expect the setting in their 
>>>>> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
>>>>> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
>>>>> case. Of course, distro has the last word and potentially can alter it, but in 
>>>>> most cases it shouldn't. That's how it works now and I believe it's the 
>>>>> correct behaviour. Changing it to append additional values to what user wants 
>>>>> is slightly heavy-handed, in my opinion. In other words, those are suggested 
>>>>> image types, not enforced ones.
>>>>> 
>>>>> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
>>>>> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
>>>>> 
>>>>> The original issue in question may be coming from the way some setup scripts 
>>>>> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
>>>>> something, that is not very suitable for the machines being used. This needs 
>>>>> to be left unset and for the end-user to decide and set specifically, IMHO.
>>>>> 
>>>>> Comments, opinions?
>>>> 
>>>> See the discussion on OE-core a while back. There was a lot of handwaving 
>>>> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
>>>> is the right way to do this. I think it's not intuitive because you have to 
>>>> remember that += and _append are expanded in different points during 
>>>> parsing, which requires either deep bitbake knowledge or minor braindamage.
>>> 
>>> Link or it never happened :)
>> 
>> No link, but:
>> 
>> 19:41 < Tartarus> But, where's the oe-core thread?
>> 19:41 < koen> somewhere on OE-core
>> 19:42 < koen> [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
>> 19:42 < koen> july 2011
> 
> Ok, here's the link:
> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061
> 
> It was discussed, there was no resolution, there were no changes.
> 
> Claiming that's how it's done in Classic OE (aka .dev) is not correct - as I 
> showed above, 44 machines use ?=, 31 use += and 31 use =

And how many of those machines are broken/unmaintained/etc

> 
> OE-Core still uses ?=
> 
> Please give me the use case that this is meant to enable, which is not 
> possible now.

Setting a global, additional type in local.conf without needing deep knowledge of bitbake. People just don't understand why they need to do IMAGE_FSTYPES_append = foo instead of IMAGE_FSTYPES += or IMAGE_FSTYPE = "foo"

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Denys Dmytriyenko]

On Fri, Mar 09, 2012 at 08:19:48PM +0100, Koen Kooi wrote:
> 
> Op 9 mrt. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:
> 
> > On Fri, Mar 09, 2012 at 07:43:40PM +0100, Koen Kooi wrote:
> >> 
> >> Op 9 mrt. 2012, om 16:01 heeft Denys Dmytriyenko het volgende geschreven:
> >> 
> >>> On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
> >>>> 
> >>>> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
> >>>> 
> >>>>> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
> >>>>>> Hey all,
> >>>>>> 
> >>>>>> This short series does two things.  For 3 machines we fix a bug of using
> >>>>>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
> >>>>>> machines that have this issue today except for...) and on the 4th,
> >>>>>> am335x-evm we add UBI support as well.  On the first three, these are
> >>>>>> correct by inspection and on the fourth, I've written to and mounted
> >>>>>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
> >>>>>> uImage that's not systemd-sane, and fixing that and confirming the config
> >>>>>> used here works is on my list).
> >>>>> 
> >>>>> All,
> >>>>> 
> >>>>> Tom and I started talking on IRC and then decided to move the discussion back 
> >>>>> to the mailing list for others to participate.
> >>>>> 
> >>>>> So, basically, the proposal is to do this in our machine.conf files:
> >>>>> 
> >>>>> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> >>>>> +IMAGE_FSTYPES += "jffs2 tar.bz2"
> >>>>> 
> >>>>> My response was that we shouldn't do that.
> >>>> 
> >>>> += is the OE classic way of doing things and is IMNSHO the right thing.
> >>> 
> >>> Not convinced:
> >>> 
> >>> $ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
> >>>    30 =
> >>>     1 -
> >>>    44 ?=
> >>>    31 +=
> >>> 
> >>> BTW, dash in there is a fluke coming from here:
> >>> cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"
> >>> 
> >>>>> The conf files that may set, append 
> >>>>> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
> >>>>> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
> >>>>> to a sane tar.gz. From end-user perspective, they expect the setting in their 
> >>>>> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
> >>>>> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
> >>>>> case. Of course, distro has the last word and potentially can alter it, but in 
> >>>>> most cases it shouldn't. That's how it works now and I believe it's the 
> >>>>> correct behaviour. Changing it to append additional values to what user wants 
> >>>>> is slightly heavy-handed, in my opinion. In other words, those are suggested 
> >>>>> image types, not enforced ones.
> >>>>> 
> >>>>> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
> >>>>> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
> >>>>> 
> >>>>> The original issue in question may be coming from the way some setup scripts 
> >>>>> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
> >>>>> something, that is not very suitable for the machines being used. This needs 
> >>>>> to be left unset and for the end-user to decide and set specifically, IMHO.
> >>>>> 
> >>>>> Comments, opinions?
> >>>> 
> >>>> See the discussion on OE-core a while back. There was a lot of handwaving 
> >>>> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
> >>>> is the right way to do this. I think it's not intuitive because you have to 
> >>>> remember that += and _append are expanded in different points during 
> >>>> parsing, which requires either deep bitbake knowledge or minor braindamage.
> >>> 
> >>> Link or it never happened :)
> >> 
> >> No link, but:
> >> 
> >> 19:41 < Tartarus> But, where's the oe-core thread?
> >> 19:41 < koen> somewhere on OE-core
> >> 19:42 < koen> [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
> >> 19:42 < koen> july 2011
> > 
> > Ok, here's the link:
> > http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061
> > 
> > It was discussed, there was no resolution, there were no changes.
> > 
> > Claiming that's how it's done in Classic OE (aka .dev) is not correct - as I 
> > showed above, 44 machines use ?=, 31 use += and 31 use =
> 
> And how many of those machines are broken/unmaintained/etc

And how many were you responsible for changing to += in .dev? :)


> > OE-Core still uses ?=
> > 
> > Please give me the use case that this is meant to enable, which is not 
> > possible now.
> 
> Setting a global, additional type in local.conf without needing deep 
> knowledge of bitbake. People just don't understand why they need to do 
> IMAGE_FSTYPES_append = foo instead of IMAGE_FSTYPES += or IMAGE_FSTYPE = "foo"

Let's say a machine has IMAGE_FSTYPES ?= "jffs2 ubi".
And setting IMAGE_FSTYPES = "ubi tag.gz jffs2 ext3" in local.conf still works!

On the other hand, with the change to += I won't be able to set it to just 
"tar.gz" and NOT build everything that machine supports, i.e. jffs2, ubi etc.

I still believe the change breaks an existing valid use case w/o adding much 
value... But, I'm willing to be convinced otherwise, if people vote it that 
way. So, we need more opinions to weigh on the topic. :)

-- 
Denys

Re: [PATCH 0/4] IMAGE_FSTYPES fixes / improvements

[Tom Rini]

On Fri, Mar 09, 2012 at 02:36:31PM -0500, Denys Dmytriyenko wrote:
> On Fri, Mar 09, 2012 at 08:19:48PM +0100, Koen Kooi wrote:
> > 
> > Op 9 mrt. 2012, om 20:17 heeft Denys Dmytriyenko het volgende geschreven:
> > 
> > > On Fri, Mar 09, 2012 at 07:43:40PM +0100, Koen Kooi wrote:
> > >> 
> > >> Op 9 mrt. 2012, om 16:01 heeft Denys Dmytriyenko het volgende geschreven:
> > >> 
> > >>> On Fri, Mar 09, 2012 at 07:20:30AM +0100, Koen Kooi wrote:
> > >>>> 
> > >>>> Op 8 mrt. 2012, om 22:01 heeft Denys Dmytriyenko het volgende geschreven:
> > >>>> 
> > >>>>> On Thu, Mar 08, 2012 at 12:34:00PM -0700, Tom Rini wrote:
> > >>>>>> Hey all,
> > >>>>>> 
> > >>>>>> This short series does two things.  For 3 machines we fix a bug of using
> > >>>>>> '?=' rather than '+=' for setting IMAGE_FSTYPES (these are all of the
> > >>>>>> machines that have this issue today except for...) and on the 4th,
> > >>>>>> am335x-evm we add UBI support as well.  On the first three, these are
> > >>>>>> correct by inspection and on the fourth, I've written to and mounted
> > >>>>>> systemd-image from NAND on my EVM (it didn't work as I was using a custom
> > >>>>>> uImage that's not systemd-sane, and fixing that and confirming the config
> > >>>>>> used here works is on my list).
> > >>>>> 
> > >>>>> All,
> > >>>>> 
> > >>>>> Tom and I started talking on IRC and then decided to move the discussion back 
> > >>>>> to the mailing list for others to participate.
> > >>>>> 
> > >>>>> So, basically, the proposal is to do this in our machine.conf files:
> > >>>>> 
> > >>>>> -IMAGE_FSTYPES ?= "jffs2 tar.bz2"
> > >>>>> +IMAGE_FSTYPES += "jffs2 tar.bz2"
> > >>>>> 
> > >>>>> My response was that we shouldn't do that.
> > >>>> 
> > >>>> += is the OE classic way of doing things and is IMNSHO the right thing.
> > >>> 
> > >>> Not convinced:
> > >>> 
> > >>> $ grep IMAGE_FSTYPES openembedded/conf/machine/*|awk '{print $2}'|sort|uniq -c
> > >>>    30 =
> > >>>     1 -
> > >>>    44 ?=
> > >>>    31 +=
> > >>> 
> > >>> BTW, dash in there is a fluke coming from here:
> > >>> cm-x270.conf:#     - IMAGE_FSTYPES = "jffs2 tar cpio.gz"
> > >>> 
> > >>>>> The conf files that may set, append 
> > >>>>> or overwrite IMAGE_FSTYPES are parsed in the order of local.conf, machine.conf 
> > >>>>> and distro.conf. And if none of those set IMAGE_FSTYPES, bitbake.conf defaults 
> > >>>>> to a sane tar.gz. From end-user perspective, they expect the setting in their 
> > >>>>> local.conf to be obeyed. If they don't care and don't set IMAGE_FSTYPES, then 
> > >>>>> machine.conf will set it to supported values, i.e. jffs2 and tar.bz2 in our 
> > >>>>> case. Of course, distro has the last word and potentially can alter it, but in 
> > >>>>> most cases it shouldn't. That's how it works now and I believe it's the 
> > >>>>> correct behaviour. Changing it to append additional values to what user wants 
> > >>>>> is slightly heavy-handed, in my opinion. In other words, those are suggested 
> > >>>>> image types, not enforced ones.
> > >>>>> 
> > >>>>> As Tom poined out, this is the same behaviour as currently used in OE-Core, 
> > >>>>> where qemu machines all have IMAGE_FSTYPES ?= "tar.bz2 ext3".
> > >>>>> 
> > >>>>> The original issue in question may be coming from the way some setup scripts 
> > >>>>> pre-configure user settings in local.conf, defaulting IMAGE_FSTYPES to 
> > >>>>> something, that is not very suitable for the machines being used. This needs 
> > >>>>> to be left unset and for the end-user to decide and set specifically, IMHO.
> > >>>>> 
> > >>>>> Comments, opinions?
> > >>>> 
> > >>>> See the discussion on OE-core a while back. There was a lot of handwaving 
> > >>>> done and suggested that IMAGE_FSTYPES_append_$machine = " foo" in local.conf 
> > >>>> is the right way to do this. I think it's not intuitive because you have to 
> > >>>> remember that += and _append are expanded in different points during 
> > >>>> parsing, which requires either deep bitbake knowledge or minor braindamage.
> > >>> 
> > >>> Link or it never happened :)
> > >> 
> > >> No link, but:
> > >> 
> > >> 19:41 < Tartarus> But, where's the oe-core thread?
> > >> 19:41 < koen> somewhere on OE-core
> > >> 19:42 < koen> [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
> > >> 19:42 < koen> july 2011
> > > 
> > > Ok, here's the link:
> > > http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/2060/focus=2061
> > > 
> > > It was discussed, there was no resolution, there were no changes.
> > > 
> > > Claiming that's how it's done in Classic OE (aka .dev) is not correct - as I 
> > > showed above, 44 machines use ?=, 31 use += and 31 use =
> > 
> > And how many of those machines are broken/unmaintained/etc
> 
> And how many were you responsible for changing to += in .dev? :)
> 
> 
> > > OE-Core still uses ?=
> > > 
> > > Please give me the use case that this is meant to enable, which is not 
> > > possible now.
> > 
> > Setting a global, additional type in local.conf without needing deep 
> > knowledge of bitbake. People just don't understand why they need to do 
> > IMAGE_FSTYPES_append = foo instead of IMAGE_FSTYPES += or IMAGE_FSTYPE = "foo"
> 
> Let's say a machine has IMAGE_FSTYPES ?= "jffs2 ubi".
> And setting IMAGE_FSTYPES = "ubi tag.gz jffs2 ext3" in local.conf still works!
> 
> On the other hand, with the change to += I won't be able to set it to just 
> "tar.gz" and NOT build everything that machine supports, i.e. jffs2, ubi etc.
> 
> I still believe the change breaks an existing valid use case w/o adding much 
> value... But, I'm willing to be convinced otherwise, if people vote it that 
> way. So, we need more opinions to weigh on the topic. :)

So, this is a fundamental issue that needs (should) be consistent at the
highest level too.  I'll bring this up on oe-core and point out the
previous threads, current oe-core only behavior, etc.

-- 
Tom

[PATCH v2 1/4] am37x-evm.conf: Use '=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html
a machine conf file should use '=' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am37x-evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am37x-evm.conf b/conf/machine/am37x-evm.conf
index e4170f4..bc97930 100644
--- a/conf/machine/am37x-evm.conf
+++ b/conf/machine/am37x-evm.conf
@@ -16,7 +16,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES = "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v2 2/4] ti814x.inc: Use '=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html
a machine conf file should use '=' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/include/ti814x.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/include/ti814x.inc b/conf/machine/include/ti814x.inc
index c53557f..070ca75 100644
--- a/conf/machine/include/ti814x.inc
+++ b/conf/machine/include/ti814x.inc
@@ -20,7 +20,7 @@ UBOOT_LOADADDRESS = "0x80008000"
 EXTRA_IMAGEDEPENDS += "u-boot"
 
 # Ship all kernel modules
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES = "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lqn -e 128"
 SERIAL_CONSOLE = "115200 ttyO0"
 MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet"
-- 
1.7.0.4

[PATCH v2 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/omap3evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/omap3evm.conf b/conf/machine/omap3evm.conf
index 9cd04ed..c0936d2 100644
--- a/conf/machine/omap3evm.conf
+++ b/conf/machine/omap3evm.conf
@@ -17,7 +17,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES = "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v2 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES, use '=' in assignment

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html
a machine conf file should use '=' to set IMAGE_FSTYPES.  We also add
the required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
line that sets us to use the PSP kernel tree and reference the TI wiki
for the source of our info as well as dmesg / userland commands.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am335x-evm.conf |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am335x-evm.conf b/conf/machine/am335x-evm.conf
index eedf072..9111853 100644
--- a/conf/machine/am335x-evm.conf
+++ b/conf/machine/am335x-evm.conf
@@ -12,12 +12,33 @@ GUI_MACHINE_CLASS = "smallscreen"
 
 require conf/machine/include/ti33x.inc
 
-IMAGE_FSTYPES ?= "tar.bz2"
+IMAGE_FSTYPES = "ubi tar.bz2"
 
 SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp"
 
+# UBI information.  Note that this is board and kernel specific.  Changes
+# in your kernel port may require changes in these variables.  For more
+# details about this board please see
+# http://processors.wiki.ti.com/index.php/UBIFS_Support
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# From dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: logical eraseblock size:    126976 bytes
+# from ubiattach stdout:
+# UBI device number 0, total 1988 LEBs
+MKUBIFS_ARGS = "-F -m 2048 -e 126976 -c 1988"
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# from dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: physical eraseblock size:   131072 bytes (128 KiB)
+# UBI: sub-page size:              512
+# UBI: VID header offset:          2048 (aligned 2048)
+UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512 -O 2048"
+
 PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
 
 UBOOT_ARCH = "arm"
-- 
1.7.0.4

Re: [PATCH v2 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

On Fri, Mar 23, 2012 at 10:36:56AM -0700, Tom Rini wrote:

> Signed-off-by: Tom Rini <trini@ti.com>
> ---
>  conf/machine/omap3evm.conf |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Code is correct, commit message wasn't updated.  v3 or can someone just
fix before pushing?  Thanks!

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: [PATCH v2 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Denys Dmytriyenko]

On Fri, Mar 23, 2012 at 10:38:02AM -0700, Tom Rini wrote:
> On Fri, Mar 23, 2012 at 10:36:56AM -0700, Tom Rini wrote:
> 
> > Signed-off-by: Tom Rini <trini@ti.com>
> > ---
> >  conf/machine/omap3evm.conf |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> Code is correct, commit message wasn't updated.  v3 or can someone just
> fix before pushing?  Thanks!

I'm not sure the discussion at OE-Core is over... The way I read it, Richard 
would rather see MACHINE_IMAGES_FSTYPES implemented, instead of using 
overrides in local.conf.

-- 
Denys

Re: [PATCH v2 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 827 bytes --]

On Fri, Mar 23, 2012 at 01:51:46PM -0400, Denys Dmytriyenko wrote:
> On Fri, Mar 23, 2012 at 10:38:02AM -0700, Tom Rini wrote:
> > On Fri, Mar 23, 2012 at 10:36:56AM -0700, Tom Rini wrote:
> > 
> > > Signed-off-by: Tom Rini <trini@ti.com>
> > > ---
> > >  conf/machine/omap3evm.conf |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > Code is correct, commit message wasn't updated.  v3 or can someone just
> > fix before pushing?  Thanks!
> 
> I'm not sure the discussion at OE-Core is over... The way I read it, Richard 
> would rather see MACHINE_IMAGES_FSTYPES implemented, instead of using 
> overrides in local.conf.

Yes, this series assumes the direction for today is just to do as
documented (being so close to release) and tomorrow do something more
complicated.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

Re: [PATCH v2 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Denys Dmytriyenko]

On Fri, Mar 23, 2012 at 10:53:16AM -0700, Tom Rini wrote:
> On Fri, Mar 23, 2012 at 01:51:46PM -0400, Denys Dmytriyenko wrote:
> > On Fri, Mar 23, 2012 at 10:38:02AM -0700, Tom Rini wrote:
> > > On Fri, Mar 23, 2012 at 10:36:56AM -0700, Tom Rini wrote:
> > > 
> > > > Signed-off-by: Tom Rini <trini@ti.com>
> > > > ---
> > > >  conf/machine/omap3evm.conf |    2 +-
> > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > Code is correct, commit message wasn't updated.  v3 or can someone just
> > > fix before pushing?  Thanks!
> > 
> > I'm not sure the discussion at OE-Core is over... The way I read it, Richard 
> > would rather see MACHINE_IMAGES_FSTYPES implemented, instead of using 
> > overrides in local.conf.
> 
> Yes, this series assumes the direction for today is just to do as
> documented (being so close to release) and tomorrow do something more
> complicated.

Understood. Then I'll apply it after the one upstream gets pushed:

http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/17731

-- 
Denys

[PATCH v3 01/10] am37x-evm.conf: Use '=+' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am37x-evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am37x-evm.conf b/conf/machine/am37x-evm.conf
index e4170f4..3c6130a 100644
--- a/conf/machine/am37x-evm.conf
+++ b/conf/machine/am37x-evm.conf
@@ -16,7 +16,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES =+ "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v3 02/10] ti814x.inc: Use '=+' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/include/ti814x.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/include/ti814x.inc b/conf/machine/include/ti814x.inc
index c53557f..a7edb16 100644
--- a/conf/machine/include/ti814x.inc
+++ b/conf/machine/include/ti814x.inc
@@ -20,7 +20,7 @@ UBOOT_LOADADDRESS = "0x80008000"
 EXTRA_IMAGEDEPENDS += "u-boot"
 
 # Ship all kernel modules
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES =+ "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lqn -e 128"
 SERIAL_CONSOLE = "115200 ttyO0"
 MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet"
-- 
1.7.0.4

[PATCH v3 03/10] omap3evm.conf: Use '=+' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/omap3evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/omap3evm.conf b/conf/machine/omap3evm.conf
index 9cd04ed..6a74f11 100644
--- a/conf/machine/omap3evm.conf
+++ b/conf/machine/omap3evm.conf
@@ -17,7 +17,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES =+ "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v3 04/10] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES, use '=+' in assignment

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.  We also add
the required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
line that sets us to use the PSP kernel tree and reference the TI wiki
for the source of our info as well as dmesg / userland commands.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am335x-evm.conf |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am335x-evm.conf b/conf/machine/am335x-evm.conf
index eedf072..2e286a3 100644
--- a/conf/machine/am335x-evm.conf
+++ b/conf/machine/am335x-evm.conf
@@ -12,12 +12,33 @@ GUI_MACHINE_CLASS = "smallscreen"
 
 require conf/machine/include/ti33x.inc
 
-IMAGE_FSTYPES ?= "tar.bz2"
+IMAGE_FSTYPES =+ "ubi tar.bz2"
 
 SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp"
 
+# UBI information.  Note that this is board and kernel specific.  Changes
+# in your kernel port may require changes in these variables.  For more
+# details about this board please see
+# http://processors.wiki.ti.com/index.php/UBIFS_Support
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# From dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: logical eraseblock size:    126976 bytes
+# from ubiattach stdout:
+# UBI device number 0, total 1988 LEBs
+MKUBIFS_ARGS = "-F -m 2048 -e 126976 -c 1988"
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# from dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: physical eraseblock size:   131072 bytes (128 KiB)
+# UBI: sub-page size:              512
+# UBI: VID header offset:          2048 (aligned 2048)
+UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512 -O 2048"
+
 PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
 
 UBOOT_ARCH = "arm"
-- 
1.7.0.4

[PATCH v3 05/10] am3517-evm.conf: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am3517-evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am3517-evm.conf b/conf/machine/am3517-evm.conf
index b3efa9a..aa476a1 100644
--- a/conf/machine/am3517-evm.conf
+++ b/conf/machine/am3517-evm.conf
@@ -16,7 +16,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES += "ubi tar.bz2"
+IMAGE_FSTYPES =+ "ubi tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS2"
-- 
1.7.0.4

[PATCH v3 06/10] beagleboard.conf: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/beagleboard.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/beagleboard.conf b/conf/machine/beagleboard.conf
index 0043a70..d8bb1e2 100644
--- a/conf/machine/beagleboard.conf
+++ b/conf/machine/beagleboard.conf
@@ -19,7 +19,7 @@ EXTRA_IMAGEDEPENDS = "u-boot"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux"
 
-IMAGE_FSTYPES += "tar.bz2 ubi"
+IMAGE_FSTYPES =+ "tar.bz2 ubi"
 EXTRA_IMAGECMD_jffs2 = "-lnp "
 
 # Guesswork
-- 
1.7.0.4

[PATCH v3 07/10] ti816x.inC: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/include/ti816x.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/include/ti816x.inc b/conf/machine/include/ti816x.inc
index 2fe4006..01b560c 100644
--- a/conf/machine/include/ti816x.inc
+++ b/conf/machine/include/ti816x.inc
@@ -20,7 +20,7 @@ UBOOT_LOADADDRESS = "0x80008000"
 EXTRA_IMAGEDEPENDS += "u-boot"
 
 # Ship all kernel modules
-IMAGE_FSTYPES += "jffs2 tar.bz2"
+IMAGE_FSTYPES =+ "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lqn -e 128"
 SERIAL_CONSOLE = "115200 ttyO2"
 MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet"
-- 
1.7.0.4

[PATCH v3 08/10] beaglebone.conf: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/beaglebone.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
index 3803edf..e8a0627 100644
--- a/conf/machine/beaglebone.conf
+++ b/conf/machine/beaglebone.conf
@@ -15,7 +15,7 @@ EXTRA_IMAGEDEPENDS = "u-boot"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp"
 
-IMAGE_FSTYPES += "tar.bz2 "
+IMAGE_FSTYPES =+ "tar.bz2"
 
 # Guesswork
 SERIAL_CONSOLE = "115200 ttyO0"
-- 
1.7.0.4

[PATCH v3 09/10] omap3-touchbook.conf: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/omap3-touchbook.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/omap3-touchbook.conf b/conf/machine/omap3-touchbook.conf
index 95d93ac..edded08 100644
--- a/conf/machine/omap3-touchbook.conf
+++ b/conf/machine/omap3-touchbook.conf
@@ -19,7 +19,7 @@ require conf/machine/include/omap3.inc
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-omap-psp"
 
-IMAGE_FSTYPES += "tar.bz2"
+IMAGE_FSTYPES =+ "tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp "
 
 # Guesswork
-- 
1.7.0.4

[PATCH v3 10/10] pandaboard.conf: Use '=+' not '+=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '=+' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/pandaboard.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/pandaboard.conf b/conf/machine/pandaboard.conf
index 2c37b4f..22953af 100644
--- a/conf/machine/pandaboard.conf
+++ b/conf/machine/pandaboard.conf
@@ -8,7 +8,7 @@ UBOOT_MACHINE = "omap4_panda_config"
 
 GUI_MACHINE_CLASS = "bigscreen"
 
-IMAGE_FSTYPES += "tar.bz2"
+IMAGE_FSTYPES =+ "tar.bz2"
 
 SERIAL_CONSOLE = "115200 ttyO2"
 
-- 
1.7.0.4

[PATCH v4 1/4] am37x-evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '+=' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am37x-evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am37x-evm.conf b/conf/machine/am37x-evm.conf
index e4170f4..ddb54e8 100644
--- a/conf/machine/am37x-evm.conf
+++ b/conf/machine/am37x-evm.conf
@@ -16,7 +16,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v4 2/4] ti814x.inc: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '+=' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/include/ti814x.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/include/ti814x.inc b/conf/machine/include/ti814x.inc
index c53557f..475a212 100644
--- a/conf/machine/include/ti814x.inc
+++ b/conf/machine/include/ti814x.inc
@@ -20,7 +20,7 @@ UBOOT_LOADADDRESS = "0x80008000"
 EXTRA_IMAGEDEPENDS += "u-boot"
 
 # Ship all kernel modules
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lqn -e 128"
 SERIAL_CONSOLE = "115200 ttyO0"
 MACHINE_FEATURES = "kernel26 apm usbgadget usbhost vfat ext2 ethernet"
-- 
1.7.0.4

[PATCH v4 3/4] omap3evm.conf: Use '+=' not '?=' in IMAGE_FSTYPES

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '+=' to set IMAGE_FSTYPES.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/omap3evm.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/machine/omap3evm.conf b/conf/machine/omap3evm.conf
index 9cd04ed..16caf05 100644
--- a/conf/machine/omap3evm.conf
+++ b/conf/machine/omap3evm.conf
@@ -17,7 +17,7 @@ require conf/machine/include/omap3.inc
 
 # Ship all kernel modules
 
-IMAGE_FSTYPES ?= "jffs2 tar.bz2"
+IMAGE_FSTYPES += "jffs2 tar.bz2"
 EXTRA_IMAGECMD_jffs2 = "-lnp -e 0x20000 -s 2048"
 
 SERIAL_CONSOLE = "115200 ttyS0"
-- 
1.7.0.4

[PATCH v4 4/4] am335x-evm.conf: Add 'ubi' to IMAGE_FSTYPES, use '+=' in assignment

[Tom Rini]

As per
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/020053.html
a machine conf file should use '+=' to set IMAGE_FSTYPES.  We also add
the required MKUBIFS_ARGS / UBINIZE_ARGS.  These are placed next to the
line that sets us to use the PSP kernel tree and reference the TI wiki
for the source of our info as well as dmesg / userland commands.

Signed-off-by: Tom Rini <trini@ti.com>
---
 conf/machine/am335x-evm.conf |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/conf/machine/am335x-evm.conf b/conf/machine/am335x-evm.conf
index eedf072..e7ddd0b 100644
--- a/conf/machine/am335x-evm.conf
+++ b/conf/machine/am335x-evm.conf
@@ -12,12 +12,33 @@ GUI_MACHINE_CLASS = "smallscreen"
 
 require conf/machine/include/ti33x.inc
 
-IMAGE_FSTYPES ?= "tar.bz2"
+IMAGE_FSTYPES += "ubi tar.bz2"
 
 SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel = "linux-ti33x-psp"
 
+# UBI information.  Note that this is board and kernel specific.  Changes
+# in your kernel port may require changes in these variables.  For more
+# details about this board please see
+# http://processors.wiki.ti.com/index.php/UBIFS_Support
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# From dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: logical eraseblock size:    126976 bytes
+# from ubiattach stdout:
+# UBI device number 0, total 1988 LEBs
+MKUBIFS_ARGS = "-F -m 2048 -e 126976 -c 1988"
+
+# do ubiattach /dev/ubi_ctrl -m 7 -O 2048
+# from dmesg:
+# UBI: smallest flash I/O unit:    2048
+# UBI: physical eraseblock size:   131072 bytes (128 KiB)
+# UBI: sub-page size:              512
+# UBI: VID header offset:          2048 (aligned 2048)
+UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512 -O 2048"
+
 PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
 
 UBOOT_ARCH = "arm"
-- 
1.7.0.4