Re: RFC: Renaming uboot-utils

Re: RFC: Renaming uboot-utils

[Andy Wilcox]

On Sat, 15 Dec 2007 14:14 "Leon Woestenberg" 
<leon.woestenberg@gmail.com> wrote:
> On Dec 14, 2007 9:16 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>> > Andy Wilcox schreef:
>>     
>>> > > Since uboot-utils builds a native binary (mkImage) it should really be
>>> > > called uboot-utils-native.
>>>       
>> >
>> > That part makes sense. FWIW, we already have a uboot-mkimage-native
>> > recipe in OE.
>> >
>>     
> Also, consider u-boot-utils instead of uboot-utils. The project is
> called u-boot and I thought I saw both namespaces appear in the u-boot
> dir?
> (If I'm too late, probably forget this).
>
> Also +1 from me.
>
>   
>>> > > My motivation is (a) I'd really like to build a few tools from uboot
>>> > > which are cross-compiled
>>>       
>> >
>> > And now you're talking about uboot-utils-cross, not uboot-utils-native
>> >
>>     
> Not necessarely.
>
> Anything *-cross is a tool that is built for, and runs on one platform
> and generates output for another.
>
> Andy said a few tools which *are* cross-compiled, so he I think he
> wants to cross-compile tools, which are deployed on the target and as
> such do not generate output for another target.

Leon is exactly right.  I meant I'd use the newly-freed u-boot-utils
to build a few programs for the target - in my case, I'm interested
in fw-setenv, which allows one command-line manipulation of the
u-boot environment area in flash.

Sorry for any confusion.

Re: RFC: Renaming uboot-utils

[Paul Sokolovsky]

Hello Andy,

Monday, December 17, 2007, 5:14:26 AM, you wrote:

> On Sat, 15 Dec 2007 14:14 "Leon Woestenberg" 
> <leon.woestenberg@gmail.com> wrote:
>> On Dec 14, 2007 9:16 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
>>> > Andy Wilcox schreef:
>>>     
>>>> > > Since uboot-utils builds a native binary (mkImage) it should really be
>>>> > > called uboot-utils-native.
>>>>       
>>> >
>>> > That part makes sense. FWIW, we already have a uboot-mkimage-native
>>> > recipe in OE.
>>> >
>>>     
>> Also, consider u-boot-utils instead of uboot-utils. The project is
>> called u-boot and I thought I saw both namespaces appear in the u-boot
>> dir?
>> (If I'm too late, probably forget this).
>>
>> Also +1 from me.
>>
>>   
>>>> > > My motivation is (a) I'd really like to build a few tools from uboot
>>>> > > which are cross-compiled
>>>>       
>>> >
>>> > And now you're talking about uboot-utils-cross, not uboot-utils-native
>>> >
>>>     
>> Not necessarely.
>>
>> Anything *-cross is a tool that is built for, and runs on one platform
>> and generates output for another.
>>
>> Andy said a few tools which *are* cross-compiled, so he I think he
>> wants to cross-compile tools, which are deployed on the target and as
>> such do not generate output for another target.

> Leon is exactly right.  I meant I'd use the newly-freed u-boot-utils
> to build a few programs for the target - in my case, I'm interested
> in fw-setenv, which allows one command-line manipulation of the
> u-boot environment area in flash.

> Sorry for any confusion.

  Yeah, all this discussion became rather confusing. To understand
what's it all about, a careful look at the commit was required, and
that uncovered few botched things:

--- packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0
+++ packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0

+DEPENDS_openprotium = "mtd-utils"

   Think again - does u-boot-utils require mtd-utils headers or tools
during compile-time? Moreover, is it required for openprotium only?

+SRC_URI_append_openprotium = " \
+        file://fw_env.c.patch;patch=1 \
+        file://tools-Makefile.patch;patch=1 \
+        file://env-Makefile.patch;patch=1 \
+        file://fw_env.config"

   What so special of these patches that they apply only to
openprotium?

+EXTRA_OEMAKE_openprotium = "CROSS_COMPILE=${TARGET_PREFIX}"

   Overrides above are worth privilege of doubt, but this one doesn't
need it: doing things like this in the OE mainline is rather incorrect
behavior to all other projects/users.

--- packages/tasks/task-base.bb 784db9539c99a3dfc0ce43cc4b61f9cd5eba3b27
+++ packages/tasks/task-base.bb 7a9b59f5510daa79b732e48d67445e1d5ebc4c81
 RDEPENDS_task-base-uboot = "\
-    uboot-utils"
+    u-boot-utils-native"

     More attention could have been spent here too - non-native
package *cannot* RDEPENDS on native, this is one of abort conditions
in insane.bbclass. Someone who added the original line thought that
uboot-utils is actually what its name suggests. When you'll be fixing
it, don't forget about this:

--- conf/distro/include/angstrom-2007-preferred-versions.inc    f3d89d1d37708d933d79f1a37dbef5925a80cf82
+++ conf/distro/include/angstrom-2007-preferred-versions.inc    2ee34e9004f488e328231f5a1f139e5225d0e2cf
-PREFERRED_VERSION_uboot-utils ?= "1.2.0"
+PREFERRED_VERSION_u-boot-utils-native ?= "1.2.0"



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFC: Renaming uboot-utils

[Paul Sokolovsky]

Hello Andy,

[cc'ed back to the list]

Monday, December 17, 2007, 4:24:21 PM, you wrote:

> Hi Paul, I appreciate the extra eyes.
>>
>>   Yeah, all this discussion became rather confusing. To understand
>> what's it all about, a careful look at the commit was required, and
>> that uncovered few botched things:
>>
>> --- packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0
>> +++ packages/uboot/u-boot-utils_1.2.0.bb        64396fa43c9fcef1ed1cd3ae82a49d140febbbd0
>>
>> +DEPENDS_openprotium = "mtd-utils"
>>
>>    Think again - does u-boot-utils require mtd-utils headers or tools
>> during compile-time? Moreover, is it required for openprotium only?
>>
>> +SRC_URI_append_openprotium = " \
>> +        file://fw_env.c.patch;patch=1 \
>> +        file://tools-Makefile.patch;patch=1 \
>> +        file://env-Makefile.patch;patch=1 \
>> +        file://fw_env.config"
>>
>>    What so special of these patches that they apply only to
>> openprotium?
>>
>>   
> Building fw_setenv does require mtd-utils at compile time to pick up 
> certain headers.

  Hm. Can't it be really built against just kernel headers? Pity, but
ok.

> OP is the only distro that currently needs u-boot-utils (for fw_setenv,
> a target
> utility).  I was trying to bend that out of the way: this package won't do
> anything if you aren't building OP.  But perhaps that was wrong - I should
> always built that utility, and you can use this package or not.  Is the
> latter
> way the right OE way?

  Yes, I'd say the right way for mainline OE is to use machine/distro
overrides very sparingly, in selected places only. OE provides
flexible overrides mechanism to address special needs a vendor may have
to build its product per its requirements, but such overrides better live
in vendor trees/overlays. For mainline OE, I'd say it's better to err
on generality, than create complex and non-maintainable overrides maze
(an example is OPIE which risked removal from OE due to this, and by
now has been almost completely cleared off from any
machine-specific hacks).

>> +EXTRA_OEMAKE_openprotium = "CROSS_COMPILE=${TARGET_PREFIX}"
>>
>>    Overrides above are worth privilege of doubt, but this one doesn't
>> need it: doing things like this in the OE mainline is rather incorrect
>> behavior to all other projects/users.
>>   
> Yeah, sorry - this is a remnant from the (broken) way the old package
> worked.  I should have caught that.
>> --- packages/tasks/task-base.bb 784db9539c99a3dfc0ce43cc4b61f9cd5eba3b27
>> +++ packages/tasks/task-base.bb 7a9b59f5510daa79b732e48d67445e1d5ebc4c81
>>  RDEPENDS_task-base-uboot = "\
>> -    uboot-utils"
>> +    u-boot-utils-native"
>>
>>      More attention could have been spent here too - non-native
>> package *cannot* RDEPENDS on native, this is one of abort conditions
>> in insane.bbclass. Someone who added the original line thought that
>> uboot-utils is actually what its name suggests. When you'll be fixing
>> it, don't forget about this:
>>   
> Perhaps the MACHINE|DISTRO_FEATURES uboot should just
> go away?  It was only needed to make the native mkimage program,
> which really should be a kernel DEPENDS anyway.  Sound
> reasonable?

  Let's hear Rod Whitby speak up, AFAIR, he added those features. But
as far as I understand, no, they should be there, and are the way to
add a particular bootloader support to *any* distro. Have a look at
apex and redboot support at the same place. So, if you say that your
machine has u-boot as bootloader, you'll get utils to manage it in the
image. Ditto for other bootloaders.

[]


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFC: Renaming uboot-utils

[Andy Wilcox]

Paul Sokolovsky wrote:
>
>> OP is the only distro that currently needs u-boot-utils (for fw_setenv,
>> a target
>> utility).  I was trying to bend that out of the way: this package won't do
>> anything if you aren't building OP.  But perhaps that was wrong - I should
>> always built that utility, and you can use this package or not.  Is the
>> latter
>> way the right OE way?
>>     
>
>   Yes, I'd say the right way for mainline OE is to use machine/distro
> overrides very sparingly, in selected places only. OE provides
> flexible overrides mechanism to address special needs a vendor may have
> to build its product per its requirements, but such overrides better live
> in vendor trees/overlays. For mainline OE, I'd say it's better to err
> on generality, than create complex and non-maintainable overrides maze
> (an example is OPIE which risked removal from OE due to this, and by
> now has been almost completely cleared off from any
> machine-specific hacks).
>
>   
Sounds reasonable.  I'll adjust that.
>
>> Perhaps the MACHINE|DISTRO_FEATURES uboot should just
>> go away?  It was only needed to make the native mkimage program,
>> which really should be a kernel DEPENDS anyway.  Sound
>> reasonable?
>>     
Let me answer my own question here.  It appears that
MACHINE|DISTRO_FEATURES was serving two purposes - one -
to actually make a u-boot.bin file for the target, and two - to
generate mkimage on the build host.   Given the former, it
should definitely not go away!

A few kernels will need to add the u-boot-utils-native dependency,
notably the linkstation.  I'll make these adjustments in the commit.

Regards,
Andy

Re: RFC: Renaming uboot-utils

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Wilcox schreef:

> A few kernels will need to add the u-boot-utils-native dependency,
> notably the linkstation.  I'll make these adjustments in the commit.

And witness the joys of using linux.inc: automagic dependency on mkimage
for machines that need it!

regards,

Koen

- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHZurFMkyGM64RGpERAtRaAJ4j2Q7fVMLaY7JbEazogWro3iYIZgCggkdD
aeY0fFxhJWIZN+J5cHXlRcE=
=Fsd1
-----END PGP SIGNATURE-----

Re: RFC: Renaming uboot-utils

[Paul Sokolovsky]

Hello Koen,

Monday, December 17, 2007, 11:31:49 PM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Andy Wilcox schreef:

>> A few kernels will need to add the u-boot-utils-native dependency,
>> notably the linkstation.  I'll make these adjustments in the commit.

> And witness the joys of using linux.inc: automagic dependency on mkimage
> for machines that need it!

  Actually, that magic is pretty dumb ;-) :

# Not every device needs mkimage to generate a kernel image, but lets make OE a bit more
# friendly and increase the "Just Works(TM) factor. Building uboot takes only a minute. 
DEPENDS += " u-boot-mkimage-openmoko-native "

P.S. As of now, u-boot, u-boot-utils-native,
u-boot-mkimage-openmoko-native all stage mkimage. Waste. Need to
cleanup.
  

> regards,

> Koen




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFC: Renaming uboot-utils

[Marcin Juszkiewicz]

Dnia poniedziałek, 17 grudnia 2007, Paul Sokolovsky napisał:
> Hello Koen,

> > And witness the joys of using linux.inc: automagic dependency on
> > mkimage for machines that need it!
>
>   Actually, that magic is pretty dumb ;-) :

Please refresh your metadata ;)

Koen merged my code from Poky which adds mkimage dependency ONLY for 
uImage devices.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

           time is what keeps things from happening all at once

Re: RFC: Renaming uboot-utils

[Rod Whitby]

Paul Sokolovsky wrote:
> Monday, December 17, 2007, 4:24:21 PM, you wrote:
>> Perhaps the MACHINE|DISTRO_FEATURES uboot should just
>> go away?  It was only needed to make the native mkimage program,
>> which really should be a kernel DEPENDS anyway.  Sound
>> reasonable?
> 
>   Let's hear Rod Whitby speak up, AFAIR, he added those features. But
> as far as I understand, no, they should be there, and are the way to
> add a particular bootloader support to *any* distro. Have a look at
> apex and redboot support at the same place. So, if you say that your
> machine has u-boot as bootloader, you'll get utils to manage it in the
> image. Ditto for other bootloaders.

Actually, I think NAiL added the uboot machine feature.  I only looked
at the uboot and redboot ones that were already there and added apex.


-- Rod

RFC: Renaming uboot-utils

[Andy Wilcox]

Since uboot-utils builds a native binary (mkImage) it should really be 
called
uboot-utils-native.

My motivation is (a) I'd really like to build a few tools from uboot
which are cross-compiled (notably, fw-setenv/printenv, which allow R/W
access to the u-boot configuration space), and (b) it's the "right"
thing to do (-;

The following files would be updated:

./conf/distro/foonas.conf
./conf/distro/include/angstrom-2007-preferred-versions.inc
./packages/linux/em-x270_2.6.23.bb
./packages/linux/linux-bd-neon-2.6_2.6.22.bb
./packages/linux/linux-gumstix_2.6.15.bb
./packages/linux/linux-omap.inc
./packages/linux/linux-storcenter_2.6.12.6.bb
./packages/linux/linux-turbostation_2.6.20.2.bb
./packages/tasks/task-base.bb

Any objection or comment?

Thanks!
Andy

Re: RFC: Renaming uboot-utils

[Philip Balister]

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

+1

Philip

Andy Wilcox wrote:
> Since uboot-utils builds a native binary (mkImage) it should really be 
> called
> uboot-utils-native.
> 
> My motivation is (a) I'd really like to build a few tools from uboot
> which are cross-compiled (notably, fw-setenv/printenv, which allow R/W
> access to the u-boot configuration space), and (b) it's the "right"
> thing to do (-;
> 
> The following files would be updated:
> 
> ./conf/distro/foonas.conf
> ./conf/distro/include/angstrom-2007-preferred-versions.inc
> ./packages/linux/em-x270_2.6.23.bb
> ./packages/linux/linux-bd-neon-2.6_2.6.22.bb
> ./packages/linux/linux-gumstix_2.6.15.bb
> ./packages/linux/linux-omap.inc
> ./packages/linux/linux-storcenter_2.6.12.6.bb
> ./packages/linux/linux-turbostation_2.6.20.2.bb
> ./packages/tasks/task-base.bb
> 
> Any objection or comment?
> 
> Thanks!
> Andy
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: RFC: Renaming uboot-utils

[Khem Raj]

yes it is a logical step. Go for it

Khem

On Dec 14, 2007 8:30 AM, Philip Balister <philip@balister.org> wrote:
> +1
>
> Philip
>
>
> Andy Wilcox wrote:
> > Since uboot-utils builds a native binary (mkImage) it should really be
> > called
> > uboot-utils-native.
> >
> > My motivation is (a) I'd really like to build a few tools from uboot
> > which are cross-compiled (notably, fw-setenv/printenv, which allow R/W
> > access to the u-boot configuration space), and (b) it's the "right"
> > thing to do (-;
> >
> > The following files would be updated:
> >
> > ./conf/distro/foonas.conf
> > ./conf/distro/include/angstrom-2007-preferred-versions.inc
> > ./packages/linux/em-x270_2.6.23.bb
> > ./packages/linux/linux-bd-neon-2.6_2.6.22.bb
> > ./packages/linux/linux-gumstix_2.6.15.bb
> > ./packages/linux/linux-omap.inc
> > ./packages/linux/linux-storcenter_2.6.12.6.bb
> > ./packages/linux/linux-turbostation_2.6.20.2.bb
> > ./packages/tasks/task-base.bb
> >
> > Any objection or comment?
> >
> > Thanks!
> > Andy
> >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>

Re: RFC: Renaming uboot-utils

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Wilcox schreef:
> Since uboot-utils builds a native binary (mkImage) it should really be 
> called
> uboot-utils-native.

That part makes sense. FWIW, we already have a uboot-mkimage-native
recipe in OE.

> My motivation is (a) I'd really like to build a few tools from uboot
> which are cross-compiled

And now you're talking about uboot-utils-cross, not uboot-utils-native

regards,

Koen

> (notably, fw-setenv/printenv, which allow R/W
> access to the u-boot configuration space), and (b) it's the "right"
> thing to do (-;
> 
> The following files would be updated:
> 
> ./conf/distro/foonas.conf
> ./conf/distro/include/angstrom-2007-preferred-versions.inc
> ./packages/linux/em-x270_2.6.23.bb
> ./packages/linux/linux-bd-neon-2.6_2.6.22.bb
> ./packages/linux/linux-gumstix_2.6.15.bb
> ./packages/linux/linux-omap.inc
> ./packages/linux/linux-storcenter_2.6.12.6.bb
> ./packages/linux/linux-turbostation_2.6.20.2.bb
> ./packages/tasks/task-base.bb
> 
> Any objection or comment?
> 
> Thanks!
> Andy
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHYuSWMkyGM64RGpERAs4YAJ40EIfK6AK1hfVn1jv/Lz85XSr0JgCfUXBS
6e2moAwqoeJBN0kqjXnPhX4=
=KWpO
-----END PGP SIGNATURE-----

Re: RFC: Renaming uboot-utils

[Leon Woestenberg]

Hello all,

On Dec 14, 2007 9:16 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> Andy Wilcox schreef:
> > Since uboot-utils builds a native binary (mkImage) it should really be
> > called uboot-utils-native.
>
> That part makes sense. FWIW, we already have a uboot-mkimage-native
> recipe in OE.
>
Also, consider u-boot-utils instead of uboot-utils. The project is
called u-boot and I thought I saw both namespaces appear in the u-boot
dir?
(If I'm too late, probably forget this).

Also +1 from me.

> > My motivation is (a) I'd really like to build a few tools from uboot
> > which are cross-compiled
>
> And now you're talking about uboot-utils-cross, not uboot-utils-native
>
Not necessarely.

Anything *-cross is a tool that is built for, and runs on one platform
and generates output for another.

Andy said a few tools which *are* cross-compiled, so he I think he
wants to cross-compile tools, which are deployed on the target and as
such do not generate output for another target.

u-boot-utils-cross would be a package that generates tools, of which
the output only can run on a target.

I think some of the tools in u-boot are cross tools, some are not, and
some are agnostic (the output from mkimage can be interpreted on any
host AFAIK).

Regards,

Leon.

Re: RFC: Renaming uboot-utils

[Paul Sokolovsky]

Hello Koen,

Friday, December 14, 2007, 10:16:22 PM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Andy Wilcox schreef:
>> Since uboot-utils builds a native binary (mkImage) it should really be 
>> called
>> uboot-utils-native.

> That part makes sense. FWIW, we already have a uboot-mkimage-native
> recipe in OE.

>> My motivation is (a) I'd really like to build a few tools from uboot
>> which are cross-compiled

> And now you're talking about uboot-utils-cross, not uboot-utils-native

  I had a look at mkimage source, it appears to generate
target-independent format (does htonl() and friends), so it at least
can stay uboot-utils-native as the actual commit made it.

  More interestingly is that both u-boot and u-boot-utils-native stage
mkimage, and that's all what u-boot-utils-native does actually, so we
have redundancy here.

> regards,

> Koen

[]


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com