On Wed, Jan 13, 2016 at 6:35 PM, Marek Vasut <ma...@denx.de> wrote: > On Wednesday, January 13, 2016 at 06:56:36 PM, Otavio Salvador wrote: >> On Wed, Jan 13, 2016 at 3:42 PM, Marek Vasut <ma...@denx.de> wrote: >> > On Wednesday, January 13, 2016 at 06:16:01 PM, Otavio Salvador wrote: >> >> On Wed, Jan 13, 2016 at 3:09 PM, Marek Vasut <ma...@denx.de> wrote: >> >> > On Wednesday, January 13, 2016 at 05:40:20 PM, Otavio Salvador wrote: >> >> >> On Wed, Jan 13, 2016 at 2:30 PM, Marek Vasut <ma...@denx.de> wrote: >> >> >> > On Wednesday, January 13, 2016 at 04:55:56 PM, Otavio Salvador wrote: >> >> >> >> On Wed, Jan 13, 2016 at 1:53 PM, Marek Vasut <ma...@denx.de> wrote: >> >> >> >> > On Wednesday, January 13, 2016 at 04:39:53 PM, Otavio Salvador > wrote: >> >> >> >> >> On Wed, Jan 13, 2016 at 12:34 PM, Marek Vasut <ma...@denx.de> > wrote: >> >> >> >> >> > On Wednesday, January 13, 2016 at 01:04:31 PM, Otavio >> >> >> >> >> > Salvador >> > >> > wrote: >> >> >> >> >> >> On Wed, Jan 13, 2016 at 1:36 AM, Marek Vasut <ma...@denx.de> >> > >> > wrote: >> >> >> >> >> >> > Upgrade U-Boot to latest version and drop upstreamed >> >> >> >> >> >> > patches. >> >> >> >> >> >> > >> >> >> >> >> >> > Repair configuration of U-Boot during build. It is no >> >> >> >> >> >> > longer possible to run "make foomachine" in U-Boot. >> >> >> >> >> >> > Instead, it is necessary to do "make foomachine_defconfig >> >> >> >> >> >> > ; make". Fix this in u-boot.inc and u-boot-fw-utils*.bb . >> >> >> >> >> >> >> >> >> >> >> >> Please drop this config suffix, from u-boot.inc. The config >> >> >> >> >> >> value should be used as is and the respective BSP ought to >> >> >> >> >> >> be fixed to change _config to _defconfig. >> >> >> >> >> > >> >> >> >> >> > If I don't have the _defconfig there AND I define >> >> >> >> >> > UBOOT_MACHINE in my machine file, it will call "make >> >> >> >> >> > machine", which no longer works. >> >> >> >> >> >> >> >> >> >> I know and the right fix is to use the right value to >> >> >> >> >> UBOOT_MACHINE as we do for KERNEL_DEVICETREE. >> >> >> >> > >> >> >> >> > So what is the right value ? UBOOT_MACHINE := "foo_defconfig" ? >> >> >> >> > This does not sound right at all. >> >> >> >> > >> >> >> >> > And what is the right value of UBOOT_CONFIG then ? >> >> >> >> >> >> >> >> foo_defconfig. >> >> >> >> >> >> >> >> This is what we pass for make to configure the board and should be >> >> >> >> the given value. >> >> >> > >> >> >> > OK, that makes sense. You didn't answer my question about >> >> >> > UBOOT_MACHINE though. Any thoughts on that ? >> >> >> >> >> >> If using UBOOT_MACHINE = "foo_defconfig" will work just fine. >> >> > >> >> > This makes no sense at all, does it ? How can UBOOT_MACHINE contain >> >> > _defconfig ? This sounds like a crude hack, not a systematic solution. >> >> >> >> I think it makes more sense than it adding _defconfig suffix behind >> >> the scenes... >> > >> > The machine is just that, the name of the machine. For machine foo, the >> > UBOOT_MACHINE should be foo , not foo_defconfig . The _defconfig should >> > be added by the recipe, but certainly not by the user, since that would >> > be a dirty hack and confusing as hell. The "foo_defconfig" string would >> > only be sensible for UBOOT_CONFIG variable, but no way for UBOOT_MACHINE. >> >> UBOOT_CONFIG is different on this context; it is more like PACKAGECONFIG. >> >> You can see, for example: >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/conf/machine/im >> x6qsabresd.conf#n14 >> >> So I understand it is a little confusing but it is indeed how it has been >> done. > > Just because some variable is misused in some metalayer doesn't make it right, > does it ?
I am not OE-Core maintainer but I think we ought to push for simple things and making behind the scenes suffix appending to generate a value goes on the opposite direction, from my point of view. Also this u-boot.inc change will make impossible for people to use OLD versions of U-Boot without duplicating it and hacking it. A bad side effect. >From me, this is Nack! -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
