[OE-core] [PATCH] u-boot: add machine name to spl image name

[Koen Kooi]

Op 11 apr. 2012, om 13:36 heeft Richard Purdie het volgende geschreven:

> On Tue, 2012-04-10 at 15:56 +0200, Koen Kooi wrote:
>> Op 10 apr. 2012, om 15:41 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Fri, 2012-04-06 at 06:29 -0700, Koen Kooi wrote:
>>>> 
>>>> Op 5 apr. 2012 om 20:18 heeft Saul Wold <sgw at linux.intel.com> het volgende geschreven:
>>>> 
>>>>> On 04/05/2012 04:48 AM, Stefan Herbrechtsmeier wrote:
>>>>>> Signed-off-by: Stefan Herbrechtsmeier<stefan at herbrechtsmeier.net>
>>>>>> ---
>>>>>> meta/recipes-bsp/u-boot/u-boot.inc        |    2 +-
>>>>>> meta/recipes-bsp/u-boot/u-boot_2011.03.bb |    2 +-
>>>>>> meta/recipes-bsp/u-boot/u-boot_2011.06.bb |    2 +-
>>>>>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>>>>> 
>>>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
>>>>>> index 700d5d3..0445c34 100644
>>>>>> --- a/meta/recipes-bsp/u-boot/u-boot.inc
>>>>>> +++ b/meta/recipes-bsp/u-boot/u-boot.inc
>>>>>> @@ -32,7 +32,7 @@ UBOOT_MAKE_TARGET ?= "all"
>>>>>> # deploy directory.  For those versions they can set the following variables
>>>>>> # to allow packaging the SPL.
>>>>>> SPL_BINARY ?= ""
>>>>>> -SPL_IMAGE ?= "${SPL_BINARY}-${PV}-${PR}"
>>>>>> +SPL_IMAGE ?= "${SPL_BINARY}-${MACHINE}-${PV}-${PR}"
>>>>>> SPL_SYMLINK ?= "${SPL_BINARY}-${MACHINE}"
>>>>>> 
>>>>>> do_compile () {
>>>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot_2011.03.bb b/meta/recipes-bsp/u-boot/u-boot_2011.03.bb
>>>>>> index 1ebdbea..e99bc2c 100644
>>>>>> --- a/meta/recipes-bsp/u-boot/u-boot_2011.03.bb
>>>>>> +++ b/meta/recipes-bsp/u-boot/u-boot_2011.03.bb
>>>>>> @@ -17,7 +17,7 @@ FILESDIR = "${@os.path.dirname(d.getVar('FILE',1))}/u-boot-git/${MACHINE}"
>>>>>> SRCREV = "19b54a701811220221fc4d5089a2bb18892018ca"
>>>>>> 
>>>>>> PV = "v2011.03+git${SRCPV}"
>>>>>> -PR = "r5"
>>>>>> +PR = "r6"
>>>>>> 
>>>>>> SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
>>>>>> 
>>>>>> diff --git a/meta/recipes-bsp/u-boot/u-boot_2011.06.bb b/meta/recipes-bsp/u-boot/u-boot_2011.06.bb
>>>>>> index 8ebdbff..680401f 100644
>>>>>> --- a/meta/recipes-bsp/u-boot/u-boot_2011.06.bb
>>>>>> +++ b/meta/recipes-bsp/u-boot/u-boot_2011.06.bb
>>>>>> @@ -17,7 +17,7 @@ FILESDIR = "${@os.path.dirname(d.getVar('FILE',1))}/u-boot-git/${MACHINE}"
>>>>>> SRCREV = "b1af6f532e0d348b153d5c148369229d24af361a"
>>>>>> 
>>>>>> PV = "v2011.06+git${SRCPV}"
>>>>>> -PR = "r0"
>>>>>> +PR = "r1"
>>>>>> 
>>>>>> SRC_URI = "git://git.denx.de/u-boot.git;branch=master;protocol=git"
>>>>>> 
>>>>> 
>>>>> Merged into OE-Core
>>>> 
>>>> wait a minute, why was this merged?
>>> 
>>> In retrospect it shouldn't.
>> 
>> Can we back it out? It breaks a ton of buildscripts. SPL_SYMLINK already has the machine.
>> 
>>> It was presented to me as part of a series
>>> and I wasn't careful enough about sifting through the commits, likely
>>> the jetlag wasn't helping. I'll aim to try harder, people can help by
>>> pointing out patches they don't think should be going into the release
>>> at this point...
>> 
>> I read Sauls mail at the airport at 6:30 in the morning, which means
>> that if I skipped sleeping I would have had a 16 hour window to
>> object. For a bootloader patch that's not enough. Especially when the
>> people who care about bootloaders are on spring break or attending
>> collab.
> 
> I don't expect people to wait for Saul's emails and then review patches
> already on the mailing list.

I don't expect that either, my point was that the window between the patch being posted and saul sending the "applied" email was 16 hours, half of it during PST sleepy time. That is waaaaay too short for a bootloader patch to get reviewed. Opening my mail at 6:30 I read the patch for the first time and thought "hmmm, this isn't right" and noticed Saul had already applied it. That will teach me for not checking my oe-core email for a day :)

> Regardless, I'm rather torn in this case. Stefan's usecase is a valid
> one and I don't see why we have to change the layout of DEPLOY_DIR
> because of this one issue. I know of people doing some interesting
> things with layouts and I don't really want to impose policy on that
> which the change you propose does.

Adding MACHINE to DEPLOY_DIR_IMAGE allows you to get rid of post processing scripts to rename foo-MACHINE to foo before consuming it, since you can now symlink safely to foo without stepping on other machines.

> Having the symlink contain MACHINE
> but not the name is rather odd.
> 
> I also agree its late in the cycle for something which breaks build
> scripts however :(.
> 
> So I'm probably in favour of reverting from 1.2 but adding straight away
> for 1.3 although I don't like letting 1.2 out with this issue present
> really.

Sounds good to me.

regards,

Koen