barebox: Add recipe for this new bootloader
PATCH 1/1 barebox: Add recipe for this new bootloader
* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repository
--- recipes/barebox/barebox.inc | 49 ++++++++++++++++++++++++++++++++++++ recipes/barebox/barebox_2009.12.bb | 15 +++++++++++ recipes/barebox/barebox_git.bb | 10 +++++++ 3 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 recipes/barebox/barebox.inc create mode 100644 recipes/barebox/barebox_2009.12.bb create mode 100644 recipes/barebox/barebox_git.bb
recipes/barebox/barebox.inc new file +49 -0
@@ -0,0 +1,49 @@ +DESCRIPTION = "Barebox - a bootloader that inherits the best of U-Boot and the Linux kernel" +HOMEPAGE = "http://www.barebox.org/" +SECTION = "bootloaders" +PRIORITY = "optional" +LICENSE = "GPL" +PROVIDES = "virtual/bootloader" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +inherit kernel-arch + +EXTRA_OEMAKE = "CROSS_COMPILE=${TARGET_PREFIX}" + +BAREBOX_MACHINE ?= "${MACHINE}_defconfig" +BAREBOX_BINARY ?= "barebox.bin" +BAREBOX_IMAGE ?= "barebox-${MACHINE}-${PV}-${PR}.bin" +BAREBOX_SYMLINK ?= "barebox-${MACHINE}.bin" + +INSANE_SKIP_${PN} = True + +do_configure_prepend() { + cp ${WORKDIR}/defconfig ${S}/.config + oe_runmake oldconfig +} + +do_compile () { + unset LDFLAGS + unset CFLAGS + unset CPPFLAGS + oe_runmake all +} + +do_deploy () { + install -d ${DEPLOY_DIR_IMAGE} + install ${S}/${BAREBOX_BINARY} ${DEPLOY_DIR_IMAGE}/${BAREBOX_IMAGE} + package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${BAREBOX_IMAGE} + + cd ${DEPLOY_DIR_IMAGE} + rm -f ${BAREBOX_SYMLINK} + ln -sf ${BAREBOX_IMAGE} ${BAREBOX_SYMLINK} + package_stagefile_shell ${DEPLOY_DIR_IMAGE}/${BAREBOX_SYMLINK} +} +do_deploy[dirs] = "${S}" +addtask deploy before do_build after do_compile + +do_stage() { + install -d ${STAGING_BINDIR_NATIVE} + install -m 755 scripts/mkimage ${STAGING_BINDIR_NATIVE}/ +}
recipes/barebox/barebox_2009.12.bb new file +15 -0
@@ -0,0 +1,15 @@ +require barebox.inc + +PR = "r0" + +DEFAULT_PREFERENCE = "-1" + +BAREBOX_REVISION ?= "0" + +S = "${WORKDIR}/barebox-${PV}.${BAREBOX_REVISION}" + +SRC_URI = "http://barebox.org/download/barebox-${PV}.${BAREBOX_REVISION}.tar.bz2;name=barebox-${PV}.${BAREBOX_REVISION} \ + file://defconfig" + +SRC_URI[barebox-2009.12.0.md5sum] = "d1aefe17cfd72affec766617b42dfb78" +SRC_URI[barebox-2009.12.0.sha256sum] = "0ccd59898289652f4bebd8282737a771729d84886195221c781df08f81a837ef"
recipes/barebox/barebox_git.bb new file +10 -0
@@ -0,0 +1,10 @@ +require barebox.inc + +PR = "r0" + +FILESPATHPKG =. "barebox-git:" + +SRC_URI = "git://git.pengutronix.de/git/barebox.git;protocol=git \ + file://defconfig" + +S = "${WORKDIR}/git"
Signature · 1 line
1.6.0.4
Hi,
Quoted 4 lines · Eric Benard
* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repository
Please review carefully this recipe as this is my first public recipe so I may have misunderstood some variable's usage.
It's based on u-boot & linux recipes.
inherit kernel-arch is here in order to get the ARCH variable set
I'll send patches for a machine using barebox in a few days/weeks.
One question : is there a clean way to handle several config files for the bootloader (or for the kernel) for one machine (example : mymachine_with_128M_ram, mymachine_with_256M_ran) in order to compile several binaries which can be used depending on the hardware configuration used by the customer ?
Thanks,
Eric
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 14 lines · Eric Benard
* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repositorySigned-off-by Eric Benard <[email protected]>+++ b/recipes/barebox/barebox_2009.12.bb
(quoted diff) +2
-0@@ -0,0 +1,15 @@ +PR = "r0" +++ b/recipes/barebox/barebox_git.bb
Review
Quoted 2 lines
(quoted diff) +1
-0@@ -0,0 +1,10 @@ +PR = "r0"
Please don't set variables to the current default value, but leave them out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still pokes needlessly at PACKAGES).
Setting PR is relatively minor, but lets stay consistent :)
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFLU3rkMkyGM64RGpERAozFAKCreMUUurwnuzOIWPSqx7ZEUTeNVACeNxUF vSV+pweWy2F1wabuldokuIw=
=TFC8
-----END PGP SIGNATURE-----
Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:
Quoted 19 lines · Eric Benard
Quoted 1 line
* barebox is "a bootloader that inherits the best of U-Boot and the
Linux kernel"
Quoted 13 lines
* add recipe for v2009.12.0 (last stable)
* add recipe for git repositorySigned-off-by Eric Benard <[email protected]>+++ b/recipes/barebox/barebox_2009.12.bb
(quoted diff) +2
-0@@ -0,0 +1,15 @@ +PR = "r0" +++ b/recipes/barebox/barebox_git.bbReview
Quoted 2 lines
(quoted diff) +1
-0@@ -0,0 +1,10 @@ +PR = "r0"
Quoted 8 lines
Please don't set variables to the current default value, but leave them
out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still
pokes needlessly at PACKAGES).Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
Thanks,
Paul
[1] http://docs.openembedded.org/usermanual/html/recipes_versioning.html
PATCH 1/1 usermanual : update note about PR
quoting Koen Kooi : Please don't set variables to the current default value, but leave them out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still pokes needlessly at PACKAGES).
--- docs/usermanual/chapters/recipes.xml | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
docs/usermanual/chapters/recipes.xml +3 -3
@@ -323,9 +323,9 @@ mv fixed.recipe.bb myrecipe.bb</screen></para> then the default value of "r0" is used.</para> <para><note> - <para>It is good practice to always define PR in your recipes, even - for the <emphasis>"r0"</emphasis> release, so that when editing the - recipe it is clear that the PR number needs to be updated.</para> + <para>As PR is set to "r0" as a default, it must not be defined at the + creation of the recipe. When editing the recipe for the first time, the + PR variable must be defined to "r1".</para> <para>You should always increment PR when modifying a recipe. Sometimes this can be avoided if the change will have no effect on the
Signature · 1 line
1.6.3.3
Re: [PATCH] usermanual : update note about PR
2010/1/17 Eric Benard <[email protected]>:
Quoted 25 lines
quoting Koen Kooi : Please don't set variables to the current default value, but leave them out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still pokes needlessly at PACKAGES).
Signed-off-by Eric Benard <[email protected]>---
docs/usermanual/chapters/recipes.xml | 6 +++---1 files changed, 3 insertions(+), 3 deletions(-)docs/usermanual/chapters/recipes.xml +0
-0@@ -323,9 +323,9 @@ mv fixed.recipe.bb myrecipe.bb</screen></para>then the default value of "r0" is used.</para>
<para><note>
- <para>It is good practice to always define PR in your recipes, even
- for the <emphasis>"r0"</emphasis> release, so that when editing the
- recipe it is clear that the PR number needs to be updated.</para>
+ <para>As PR is set to "r0" as a default, it must not be defined at the
+ creation of the recipe. When editing the recipe for the first time, the
+ PR variable must be defined to "r1".</para>
Quoted 4 lines
<para>You should always increment PR when modifying a recipe. Sometimes this can be avoided if the change will have no effect on the --
1.6.3.3
Personally (having forgotten to bump PR once or twice), I'm in favour of keeping the recommendation of setting PR = "r0" as good practice in a recipe.
Apart from the good practice, it also might help a little bit to give PR a standard location.
Frans.
Re: [PATCH] usermanual : update note about PR
Quoted 5 lines · Frans Meulenbroeks
Personally (having forgotten to bump PR once or twice), I'm in favour of keeping the recommendation of setting PR = "r0" as good practice in a recipe.
Apart from the good practice, it also might help a little bit to give PR a standard location.
yes this looks like a sane pratice.
Eric
Re: [PATCH] usermanual : update note about PR
In reply to Frans MeulenbroeksQuoted 2 lines · Frans Meulenbroeks
Apart from the good practice, it also might help a little bit to give PR a standard location.
PR does have a standard location as defined in the StyleGuide, although of course it may not be observed in all recipes.
Re: [PATCH] usermanual : update note about PR
In reply to Eric BenardQuoted 1 line · Eric Benard
quoting Koen Kooi : Please don't set variables to the current default
NACK. This is Koen's position. See my previous mail that there are differing views.
2010/1/17 Paul Menzel <[email protected]>:
Quoted 27 lines
Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:
Quoted 26 lines · Eric Benard
Quoted 1 line
* barebox is "a bootloader that inherits the best of U-Boot and the
Linux kernel"
Quoted 13 lines
* add recipe for v2009.12.0 (last stable)
* add recipe for git repositorySigned-off-by Eric Benard <[email protected]>+++ b/recipes/barebox/barebox_2009.12.bb
(quoted diff) +2
-0@@ -0,0 +1,15 @@ +PR = "r0" +++ b/recipes/barebox/barebox_git.bbReview
Quoted 2 lines
(quoted diff) +1
-0@@ -0,0 +1,10 @@ +PR = "r0"Please don't set variables to the current default value, but leave them
out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still
pokes needlessly at PACKAGES).
Quoted 8 lines
Quoted 1 line
Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
Personally I'm in favour of the above good practice. I suggest to keep PR = "r0" in recipes
Frans
Quoted 13 lines · Frans Meulenbroeks
2010/1/17 Paul Menzel <[email protected]>:
Quoted 12 lines
Am Sonntag, den 17.01.2010, 22:02 +0100 schrieb Koen Kooi:
Quoted 8 lines
Please don't set variables to the current default value, but leave them
out. We had tons of problems with vars getting copy/paste where the default changed and we had to manually fix those (e.g. efl.bbclass still
pokes needlessly at PACKAGES).Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
Quoted 8 lines
Quoted 4 lines
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
Personally I'm in favour of the above good practice. I suggest to keep PR = "r0" in recipes
Frans
+1 on this. The PR is such a common variable to set, and as Koen
observes setting it to zero is relatively minor. I feel that its presence in a recipe may help avoid the "forgot to bump PR" problems.
-Mike (mwester)
Quoted 7 lines · Paul Menzel
Quoted 1 line
Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
I think it's safe to say that there are two factions with regard to PR being set to r0. And as you can see, both have their arguments in favor. Even though it may sound like it, Koen's position is not the only one. And I guess, neither one is official.
Quoted 5 lines · Rolf Leggewie
Quoted 4 lines · Paul Menzel
Quoted 1 line
Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
Quoted 8 lines
Quoted 3 lines
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
I think it's safe to say that there are two factions with regard to PR being set to r0. And as you can see, both have their arguments in favor. Even though it may sound like it, Koen's position is not the only one. And I guess, neither one is official.
Yes, I think that's an accurate summary of the situation. I think the only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
p.
Quoted 10 lines · Phil Blundell
Quoted 9 lines · Rolf Leggewie
Quoted 7 lines · Paul Menzel
Quoted 1 line
Setting PR is relatively minor, but lets stay consistent :)
Could someone please change this in the manual please [1].
»It is good practice to always define PR in your recipes, even for the "r0" release, so that when editing the recipe it is clear that the PR number needs to be updated.«
Quoted 8 lines
Quoted 4 lines
I think it's safe to say that there are two factions with regard to PR being set to r0. And as you can see, both have their arguments in favor. Even though it may sound like it, Koen's position is not the only one. And I guess, neither one is official.
Yes, I think that's an accurate summary of the situation. I think the only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
That would seem sensible if only to lay this matter to rest once and for all! It would also be good to test the TSC processes...
Cheers,
Richard
include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)
Quoted 1 line · Richard Purdie
On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
[...]
Quoted 5 lines
Quoted 2 lines
only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
That would seem sensible if only to lay this matter to rest once and for all! It would also be good to test the TSC processes...
I would think this is too minor for the TSC to bother. But if you want to take it on, why should I object? It does take up bandwidth on this list from time to time, so much is true. Personally, I don't think the best option would be to rule in favor of one or the other faction, because that's what it would be seen for. I don't think the TSC can really win and resolve this issue.
*If* the TSC decides to vote on this, may I propose to have it decide that people are free to include PR as r0 or not as they see fit, perpetuating current practice. I think that is about the only sensible solution we can find here. If anything were to be made definitive, it should be that devs - when speaking "officially" or something that could be perceived as such - ought to make sure to stress this is a matter of (their) personal preference.
Please don't let the TSC turn into some bureaucratic monster that regulates everything. When in doubt, feel free to not rule at all.
Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)
Quoted 9 lines · Rolf Leggewie
Quoted 1 line · Richard Purdie
On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
[...]
Quoted 5 lines
Quoted 2 lines
only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
That would seem sensible if only to lay this matter to rest once and for all! It would also be good to test the TSC processes...
Quoted 6 lines
I would think this is too minor for the TSC to bother. But if you want to take it on, why should I object? It does take up bandwidth on this list from time to time, so much is true. Personally, I don't think the best option would be to rule in favor of one or the other faction, because that's what it would be seen for. I don't think the TSC can really win and resolve this issue.
I'm not entirely sure what point you are making about it being undesirable for the TSC to "rule in favour of one or the other faction". One of the primary roles of the TSC is to resolve or adjudicate disputes between developers and, since such disputes are often binary issues by their nature, it seems likely that in a lot of cases this is going to boil down to having the TSC accept the viewpoint of one party and reject the viewpoint of the other. It would certainly be a shame for the TSC to shy away from making a decision just because it might be seen to agree with one group and disagree with another.
A large part of the reason for having the TSC in the first place was to establish a group of people who were empowered (and, indeed, obliged) to make decisions, and I think this is a fairly good example of a situation where simply having a decision of some kind is more important than the detail of what exactly that decision is.
This particular issue is clearly somewhat trivial and, whichever viewpoint prevails, the impact in the real world is going to be fairly small. But it has cropped up on this list several times now and it seems equally clear that, so long as it remains unresolved, it will continue to waste everybody's time and contributors will continue to be baffled as to what exactly they should put in their patches in order to get them applied.
p.
Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)
2010/1/21 Phil Blundell <[email protected]>:
Quoted 17 lines · Rolf Leggewie
Quoted 9 lines
Quoted 1 line · Richard Purdie
On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
[...]
Quoted 5 lines
Quoted 2 lines
only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
That would seem sensible if only to lay this matter to rest once and for all! It would also be good to test the TSC processes...
Quoted 6 lines
I would think this is too minor for the TSC to bother. But if you want to take it on, why should I object? It does take up bandwidth on this list from time to time, so much is true. Personally, I don't think the best option would be to rule in favor of one or the other faction, because that's what it would be seen for. I don't think the TSC can really win and resolve this issue.
Quoted 9 lines
I'm not entirely sure what point you are making about it being undesirable for the TSC to "rule in favour of one or the other faction". One of the primary roles of the TSC is to resolve or adjudicate disputes between developers and, since such disputes are often binary issues by their nature, it seems likely that in a lot of cases this is going to boil down to having the TSC accept the viewpoint of one party and reject the viewpoint of the other. It would certainly be a shame for the TSC to shy away from making a decision just because it might be seen to agree with one group and disagree with another.
Actually the # of options for TSC are somewhat bigger.
A decision could be that X is the required way of working and !X is not ok However, it can also be weakened into making X is the preferred way and !X less desirable (without forbidding it)
And there is still the option to leave X as a personal preference to the developer.
For PR, guess my suggestion would be to have PR="r0" as preferred and not having PR as less desirabe.
But if you make a change bumping PR (or adding PR="r1", if no PR exists) is required.
Frans
Quoted 24 lines
A large part of the reason for having the TSC in the first place was to establish a group of people who were empowered (and, indeed, obliged) to make decisions, and I think this is a fairly good example of a situation where simply having a decision of some kind is more important than the detail of what exactly that decision is.
This particular issue is clearly somewhat trivial and, whichever viewpoint prevails, the impact in the real world is going to be fairly small. But it has cropped up on this list several times now and it seems equally clear that, so long as it remains unresolved, it will continue to waste everybody's time and contributors will continue to be baffled as to what exactly they should put in their patches in order to get them applied.
p.
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: include default PR or not (was: [PATCH] barebox: Add recipe for this new bootloader)
Quoted 35 lines · Frans Meulenbroeks
2010/1/21 Phil Blundell <[email protected]>:
Quoted 17 lines · Rolf Leggewie
Quoted 9 lines
Quoted 1 line · Richard Purdie
On Mon, 2010-01-18 at 13:10 +0000, Phil Blundell wrote:
[...]
Quoted 5 lines
Quoted 2 lines
only way we will get a definitive answer would be to have the TSC hand down a judgement on the matter.
That would seem sensible if only to lay this matter to rest once and for all! It would also be good to test the TSC processes...
Quoted 6 lines
I would think this is too minor for the TSC to bother. But if you want to take it on, why should I object? It does take up bandwidth on this list from time to time, so much is true. Personally, I don't think the best option would be to rule in favor of one or the other faction, because that's what it would be seen for. I don't think the TSC can really win and resolve this issue.
Quoted 9 lines
I'm not entirely sure what point you are making about it being undesirable for the TSC to "rule in favour of one or the other faction". One of the primary roles of the TSC is to resolve or adjudicate disputes between developers and, since such disputes are often binary issues by their nature, it seems likely that in a lot of cases this is going to boil down to having the TSC accept the viewpoint of one party and reject the viewpoint of the other. It would certainly be a shame for the TSC to shy away from making a decision just because it might be seen to agree with one group and disagree with another.
Actually the # of options for TSC are somewhat bigger.
A decision could be that X is the required way of working and !X is not ok However, it can also be weakened into making X is the preferred way and !X less desirable (without forbidding it)
And there is still the option to leave X as a personal preference to the developer.
Quoted 4 lines
For PR, guess my suggestion would be to have PR="r0" as preferred and not having PR as less desirabe.
But if you make a change bumping PR (or adding PR="r1", if no PR exists) is required.
IMO Letting PR=r0 is better because it does help people in remembering to bump PR when they make the first change after r0
afterall 0 is also a number so it does convey some information in the recipe.
Quoted 32 lines
Frans
Quoted 15 lines
A large part of the reason for having the TSC in the first place was to establish a group of people who were empowered (and, indeed, obliged) to make decisions, and I think this is a fairly good example of a situation where simply having a decision of some kind is more important than the detail of what exactly that decision is.
This particular issue is clearly somewhat trivial and, whichever viewpoint prevails, the impact in the real world is going to be fairly small. But it has cropped up on this list several times now and it seems equally clear that, so long as it remains unresolved, it will continue to waste everybody's time and contributors will continue to be baffled as to what exactly they should put in their patches in order to get them applied.
Quoted 9 lines
p.
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: include default PR or not
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 3 lines · Khem Raj
IMO Letting PR=r0 is better because it does help people in remembering to bump PR when they make the first change after r0
afterall 0 is also a number so it does convey some information in the recipe.
My experience is that people forget to bump PR regardless of PR = rX being present in the recipe and/or includes, that line of thinking is moot. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFLXB7qMkyGM64RGpERAh9dAKCOEMCbtp+JMVdjqmpIJeAwO0sxuQCfXUbN 6ggZc7oVtJXYhraPeNIwSIw=
=/Bkw
-----END PGP SIGNATURE-----
Re: include default PR or not
In reply to Phil BlundellQuoted 2 lines · Phil Blundell
I'm not entirely sure what point you are making about it being undesirable for the TSC to "rule in favour of one or the other faction".
I'm not advocating for the TSC to take a soft stance for fear of confrontation. But why have a rule about something that isn't really so important? If we follow down the path of letting the TSC decide even over silly things like PR, I'm afraid two things will happen. One is the TSC will become overloaded and two OE will become a bureaucratic, no-fun hell. Not sure that would be an improvement.
Hi,
Quoted 4 lines · Eric Benard
* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repository
appart from the comment from Koen I didn't receive any comment concerning this recipes. Does this mean they are OK and can be pushed upstream by someone with commit access ?
Thanks,
Eric
Quoted 11 lines · Eric Bénard
Hi,
Quoted 4 lines · Eric Benard
* barebox is "a bootloader that inherits the best of U-Boot and the Linux kernel"
* add recipe for v2009.12.0 (last stable)
* add recipe for git repositoryappart from the comment from Koen I didn't receive any comment concerning this recipes.
Does this mean they are OK and can be pushed upstream by someone with commit access ?
thanks. I applied the patch
Quoted 8 lines
Thanks,
Eric_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel