[Buildroot] What's up with the kernel names? (Again)

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

    I thought it was seattled sometime last year that kernel names
would not include timestamps or any think that breaks u-boot from
loading the kernel.

    I just had atngw100-linux-2.6.27.13-20090203.gz for a kernel name.
It's already bad enough that rootfs has stupid timestamps, we don't
really need kernel binaries too. If I wanted to preserve binaries, I
would copy them over before building again. Whenever I type make, I
expect things to be overwritten.
    As I develop a system, I don't want to find out that I'm out of
disk space because it has every single failed attempt in binaries
folder. I also don't want to touch u-boot in anyway, don't care if
there are autoscripts or not. Ideally it would be named uImage like
the kernel folks intended.

    Peter, could we hear your opinion on this? At least let's make
this optional and never bother with it again.


Kind Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

 Thiago> Hi,
 Thiago>     I thought it was seattled sometime last year that kernel names
 Thiago> would not include timestamps or any think that breaks u-boot from
 Thiago> loading the kernel.

I thought so as well.

 Thiago>     I just had atngw100-linux-2.6.27.13-20090203.gz for a kernel name.
 Thiago> It's already bad enough that rootfs has stupid timestamps, we don't
 Thiago> really need kernel binaries too. If I wanted to preserve binaries, I
 Thiago> would copy them over before building again. Whenever I type make, I
 Thiago> expect things to be overwritten.
 Thiago>     As I develop a system, I don't want to find out that I'm out of
 Thiago> disk space because it has every single failed attempt in binaries
 Thiago> folder. I also don't want to touch u-boot in anyway, don't care if
 Thiago> there are autoscripts or not. Ideally it would be named uImage like
 Thiago> the kernel folks intended.

 Thiago>     Peter, could we hear your opinion on this? At least let's make
 Thiago> this optional and never bother with it again.

I agree. I'll look closer into it.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

 Thiago> Hi,
 Thiago>     I thought it was seattled sometime last year that kernel names
 Thiago> would not include timestamps or any think that breaks u-boot from
 Thiago> loading the kernel.

 Thiago>     I just had atngw100-linux-2.6.27.13-20090203.gz for a kernel name.
 Thiago> It's already bad enough that rootfs has stupid timestamps, we don't
 Thiago> really need kernel binaries too. If I wanted to preserve binaries, I
 Thiago> would copy them over before building again. Whenever I type make, I
 Thiago> expect things to be overwritten.

The rootfs timestamp is because your defconfig sets the
BR2_ROOTFS_SUFFIX to a nonstandard value.

I had a look at target/linux/Makefile.in.advanced and see that it
uses:

LINUX26_KERNEL:=$(BINARIES_DIR)/$(BOARD_NAME)-linux-$(LINUX26_VERSION)-$(DATE)$(KERNEL_EXT)

whereas the normal (!advanced) Linux config uses:

LINUX26_KERNEL:=$(BINARIES_DIR)/linux-kernel-$(LINUX26_VERSION)-$(KERNEL_ARCH)

To me the sane thing would just be for the files to be named whatever
the kernel names them (uImage/zImage/bzImage/..), but even if we don't
do that we should atleast make the 2 Linux types use the same style.

We can add BR2_KERNEL_PREFIX/SUFFIX (defaulting to "") if people
really to do something special.

Ulf, what do you say?

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

> To me the sane thing would just be for the files to be named whatever
> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
> do that we should atleast make the 2 Linux types use the same style.
>

Unless someone oposes, I will commit the patch below tomorrow night.
It will use the rootfs suffix if one is specified for the kernel, but
if none is supplied, we get default kernel names. Then you can get
both rootfs and kernel with your board names, dates, etc. And both
rootfs and kernel names will always match.

It would be even better if /boot in the rootfs had a soft link to the
long kernel name if it's suffixed with something.

Index: target/linux/Makefile.in.advanced
===================================================================
--- target/linux/Makefile.in.advanced   (revision 25243)
+++ target/linux/Makefile.in.advanced   (working copy)
@@ -138,7 +138,6 @@
 ifeq ($(LINUX26_BINLOC),)
 LINUX26_BINLOC:=$(LINUX26_FORMAT)
 endif
-KERNEL_EXT:=
 endif

 # --------------
@@ -149,7 +148,6 @@
 ifeq ($(LINUX26_BINLOC),)
 LINUX26_BINLOC:=arch/$(KERNEL_ARCH)/boot/$(LINUX26_FORMAT)
 endif
-KERNEL_EXT:=.gz
 endif

 # --------------
@@ -158,7 +156,6 @@
 ifeq ($(LINUX26_BINLOC),)
 LINUX26_BINLOC:=arch/$(KERNEL_ARCH)/boot/$(LINUX26_FORMAT)
 endif
-KERNEL_EXT:=.z
 endif

 # --------------
@@ -167,14 +164,13 @@
 ifeq ($(LINUX26_BINLOC),)
 LINUX26_BINLOC:=arch/$(KERNEL_ARCH)/boot/bzImage
 endif
-KERNEL_EXT:=.bz
 endif

 ROOTFS_STRIPPED_SUFFIX=$(strip $(subst ",,$(ROOTFS_SUFFIX)))
 #"))
 # -----------------------------------------------------------------------------
 # File name for the Linux kernel binary
-LINUX26_KERNEL_NAME:=$(BOARD_NAME)-linux-$(LINUX26_VERSION)$(ROOTFS_STRIPPED_SUFFIX)$(KERNEL_EXT)
+LINUX26_KERNEL_NAME:=$(LINUX26_FORMAT)$(ROOTFS_STRIPPED_SUFFIX)


 ifeq ($(BOARD_NAME),)
@@ -182,7 +178,7 @@
 endif

 ifndef LINUX26_KERNEL
-LINUX26_KERNEL:=$(BINARIES_DIR)/$(BOARD_NAME)-linux-$(LINUX26_VERSION)-$(DATE)$(KERNEL_EXT)
+LINUX26_KERNEL:=$(BINARIES_DIR)/$(LINUX26_KERNEL_NAME)
 endif

 # for packages that need it

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

 Thiago> Hi,
 >> To me the sane thing would just be for the files to be named whatever
 >> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
 >> do that we should atleast make the 2 Linux types use the same style.
 >> 

 Thiago> Unless someone oposes, I will commit the patch below tomorrow night.

Please do it today, I'm planning on cutting the release tomorrow
(Friday) at noon.

 Thiago> It will use the rootfs suffix if one is specified for the kernel, but
 Thiago> if none is supplied, we get default kernel names. Then you can get
 Thiago> both rootfs and kernel with your board names, dates, etc. And both
 Thiago> rootfs and kernel names will always match.

Seems good, but don't forget the non-advanced version as well. We
should imho use the same naming convention for both kernel builds.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

tor 2009-02-05 klockan 14:23 +0100 skrev Peter Korsgaard:
> >>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> 
>  Thiago> Hi,
>  >> To me the sane thing would just be for the files to be named whatever
>  >> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
>  >> do that we should atleast make the 2 Linux types use the same style.
>  >> 
> 
>  Thiago> Unless someone oposes, I will commit the patch below tomorrow night.
> 
> Please do it today, I'm planning on cutting the release tomorrow
> (Friday) at noon.
> 
>  Thiago> It will use the rootfs suffix if one is specified for the kernel, but
>  Thiago> if none is supplied, we get default kernel names. Then you can get
>  Thiago> both rootfs and kernel with your board names, dates, etc. And both
>  Thiago> rootfs and kernel names will always match.
> 


And you have no clue about the kernel version.
And you have to modify the suffix for every project.
Much better to just create the link to uImage etc.

Then you have both.
BR


> Seems good, but don't forget the non-advanced version as well. We
> should imho use the same naming convention for both kernel builds.
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

On Thu, Feb 5, 2009 at 6:37 PM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
>>  Thiago> It will use the rootfs suffix if one is specified for the kernel, but
>>  Thiago> if none is supplied, we get default kernel names. Then you can get
>>  Thiago> both rootfs and kernel with your board names, dates, etc. And both
>>  Thiago> rootfs and kernel names will always match.
>>
>
>
> And you have no clue about the kernel version.
> And you have to modify the suffix for every project.
> Much better to just create the link to uImage etc.
>
> Then you have both.

But if you use the rootfs suffix, not only you have both, but you also
can disable it.
Following your argument, I might just as well want to have rootfs in
/tftpboot, and if the names match (same suffix) then I know which
kernel is inside each rootfs image.

The $(DATE) seams to be default to rootfs suffix already, all you have
to do is change it per project to include the project or board name.
You have to touch your projects at some point to change things anyway,
otherwise they would always build the same thing, so that's not a very
good argument against.

You can have the same functionality as before, but with added flexibility.

I'm just trying to test it out before commiting. Since I can't build
my usual platform, avr32, I'm giving arm a try.

Kind Regards,
   Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

fre 2009-02-06 klockan 00:28 -0200 skrev Thiago A. Corr?a:
> On Thu, Feb 5, 2009 at 6:37 PM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> >>  Thiago> It will use the rootfs suffix if one is specified for the kernel, but
> >>  Thiago> if none is supplied, we get default kernel names. Then you can get
> >>  Thiago> both rootfs and kernel with your board names, dates, etc. And both
> >>  Thiago> rootfs and kernel names will always match.
> >>
> >
> >
> > And you have no clue about the kernel version.
> > And you have to modify the suffix for every project.
> > Much better to just create the link to uImage etc.
> >
> > Then you have both.
> 
> But if you use the rootfs suffix, not only you have both, but you also
> can disable it.
> Following your argument, I might just as well want to have rootfs in
> /tftpboot, and if the names match (same suffix) then I know which
> kernel is inside each rootfs image.
> 

?The AT91 uboot patches and autoscripts rely on this very exact naming,
so if you commit your patch, you break the at91 support.

If you add KERNEL_VERSION to the root fs name
you do things automatically, if you dont
then everything is manually, and you have
a risk of mismatch between name and actual version.
I would not mind that the rootfs contains
kernel version, but it will break the at91 u-boot
autoscripts which means that it should avoided
at this point, and introduced in a future buildroot.


To avoid bugs due to people forgetting to update onfig the kernel name
needs to depend BOTH on PROJECT and LINUX_VERSION.

> The $(DATE) seams to be default to rootfs suffix already, all you have
> to do is change it per project to include the project or board name.

I think your major problem is that the DATE changes.
I think it is fair to allow DATE to be in the rootfs suffix.

but I still think your needs are best accomodated by 

ln -s $(LINUX_KERNEL_NAME) uImage

Then You do not have to change your u-boot configuration
and  You do not break the at91 build.


> You have to touch your projects at some point to change things anyway,
> otherwise they would always build the same thing, so that's not a very
> good argument against.
> 
> You can have the same functionality as before, but with added flexibility.
> 
> I'm just trying to test it out before commiting. Since I can't build
> my usual platform, avr32, I'm giving arm a try.
> 
BR



> Kind Regards,
>    Thiago A. Correa
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> ?The AT91 uboot patches and autoscripts rely on this very exact naming,
 Ulf> so if you commit your patch, you break the at91 support.

So they are broken for people using the simple linux build already?

 Ulf> If you add KERNEL_VERSION to the root fs name you do things
 Ulf> automatically, if you dont then everything is manually, and you
 Ulf> have a risk of mismatch between name and actual version.  I
 Ulf> would not mind that the rootfs contains kernel version, but it
 Ulf> will break the at91 u-boot autoscripts which means that it
 Ulf> should avoided at this point, and introduced in a future
 Ulf> buildroot.

 Ulf> To avoid bugs due to people forgetting to update onfig the kernel name
 Ulf> needs to depend BOTH on PROJECT and LINUX_VERSION.

Then set prefix/suffix.

 >> The $(DATE) seams to be default to rootfs suffix already, all you have
 >> to do is change it per project to include the project or board name.

 Ulf> I think your major problem is that the DATE changes.
 Ulf> I think it is fair to allow DATE to be in the rootfs suffix.

Sure, setting prefix/suffix to $(DATE) should work - But it shouldn't
be default.

 Ulf> but I still think your needs are best accomodated by 

 Ulf> ln -s $(LINUX_KERNEL_NAME) uImage

No, lets not add any more clutter to binaries/

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> ?The AT91 uboot patches and autoscripts rely on this very exact 
naming,
 Ulf> so if you commit your patch, you break the at91 support.

So they are broken for people using the simple linux build already?

==> The previous default was to use the advanced build, if my memory
        does not fail me.

        If you use a simple build then you do not get any help from the 
autoscript.

 Ulf> If you add KERNEL_VERSION to the root fs name you do things
 Ulf> automatically, if you dont then everything is manually, and you
 Ulf> have a risk of mismatch between name and actual version.  I
 Ulf> would not mind that the rootfs contains kernel version, but it
 Ulf> will break the at91 u-boot autoscripts which means that it
 Ulf> should avoided at this point, and introduced in a future
 Ulf> buildroot.

 Ulf> To avoid bugs due to people forgetting to update onfig the kernel name
 Ulf> needs to depend BOTH on PROJECT and LINUX_VERSION.

Then set prefix/suffix.

==> How can setting prefix/suffix retroactively help people that has 
forgotten
        to set prefix/suffix?

 >> The $(DATE) seams to be default to rootfs suffix already, all you have
 >> to do is change it per project to include the project or board name.

 Ulf> I think your major problem is that the DATE changes.
 Ulf> I think it is fair to allow DATE to be in the rootfs suffix.

Sure, setting prefix/suffix to $(DATE) should work - But it shouldn't
be default.

 Ulf> but I still think your needs are best accomodated by

 Ulf> ln -s $(LINUX_KERNEL_NAME) uImage

No, lets not add any more clutter to binaries/

==> If you do not like that solution, then letting people that
       want uImage , build the simple linux would work for me.
       But your opinion seems to be that you want to do things
       in a certain way, and you want to ensure that noone
       can do it in a different way, regardless if their use case
       is different from yours.
-- 
Bye, Peter Korsgaard


Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Ulf> So they are broken for people using the simple linux build already?

 Ulf> ==> The previous default was to use the advanced build, if my memory
 Ulf>        does not fail me.

For certain atmel boards, yes.

 Ulf> No, lets not add any more clutter to binaries/

 Ulf> ==> If you do not like that solution, then letting people that
 Ulf>       want uImage , build the simple linux would work for me.
 Ulf>       But your opinion seems to be that you want to do things
 Ulf>       in a certain way, and you want to ensure that noone
 Ulf>       can do it in a different way, regardless if their use case
 Ulf>       is different from yours.

Sigh, we are talking about making the name configurable, instead of
the current hardcoded settings. I don't see where that takes away any
functionality from your use cases? It's the current setup that forces
certain ways of doing stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

 Thiago> You can have the same functionality as before, but with added
 Thiago> flexibility.

Agreed.

 Thiago> I'm just trying to test it out before commiting. Since I can't build
 Thiago> my usual platform, avr32, I'm giving arm a try.

What's broken for avr32?

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

----- Original Message ----- 
From: "Peter Korsgaard" <jacmet@uclibc.org>
To: "Thiago A. Corr?a" <thiago.correa@gmail.com>
Cc: <ulf.samuelsson@atmel.com>; "Peter Korsgaard" <jacmet@uclibc.org>; 
<buildroot@uclibc.org>
Sent: Friday, February 06, 2009 9:45 AM
Subject: Re: [Buildroot] What's up with the kernel names? (Again)


>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

 Thiago> You can have the same functionality as before, but with added
 Thiago> flexibility.

Agreed.

 Thiago> I'm just trying to test it out before commiting. Since I can't 
build
 Thiago> my usual platform, avr32, I'm giving arm a try.

What's broken for avr32?

=> www.at91.com and its associated ftp server is down.
     They managed to get the web server running yesterday,
     and I hope the ftp server will be up running soon.


Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 Thiago> It will use the rootfs suffix if one is specified for the kernel, but
 Thiago> if none is supplied, we get default kernel names. Then you can get
 Thiago> both rootfs and kernel with your board names, dates, etc. And both
 Thiago> rootfs and kernel names will always match.

 Ulf> And you have no clue about the kernel version.

Why would you want to know? We don't provide that kind of info for the
other files either (which is good as the file names don't change then)
Just run mkimage -l and/or boot it if you want to check.

 Ulf> And you have to modify the suffix for every project.
 Ulf> Much better to just create the link to uImage etc.

Yes, as it's a per-project decission. I don't believe this is a big
effort, most people only work on 1-2 projects.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

ons 2009-02-04 klockan 13:29 +0100 skrev Peter Korsgaard:
> >>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:
> 
>  Thiago> Hi,
>  Thiago>     I thought it was seattled sometime last year that kernel names
>  Thiago> would not include timestamps or any think that breaks u-boot from
>  Thiago> loading the kernel.
> 
>  Thiago>     I just had atngw100-linux-2.6.27.13-20090203.gz for a kernel name.
>  Thiago> It's already bad enough that rootfs has stupid timestamps, we don't
>  Thiago> really need kernel binaries too. If I wanted to preserve binaries, I
>  Thiago> would copy them over before building again. Whenever I type make, I
>  Thiago> expect things to be overwritten.
> 
> The rootfs timestamp is because your defconfig sets the
> BR2_ROOTFS_SUFFIX to a nonstandard value.
> 
> I had a look at target/linux/Makefile.in.advanced and see that it
> uses:
> 
> LINUX26_KERNEL:=$(BINARIES_DIR)/$(BOARD_NAME)-linux-$(LINUX26_VERSION)-$(DATE)$(KERNEL_EXT)
> 
> whereas the normal (!advanced) Linux config uses:
> 
> LINUX26_KERNEL:=$(BINARIES_DIR)/linux-kernel-$(LINUX26_VERSION)-$(KERNEL_ARCH)
> 
> To me the sane thing would just be for the files to be named whatever
> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
> do that we should atleast make the 2 Linux types use the same style.

> 
> We can add BR2_KERNEL_PREFIX/SUFFIX (defaulting to "") if people
> really to do something special.
> 
> Ulf, what do you say?
> 

I think that we should have a symbolic link to xImage as we do for
u-boot.bin for those that do not like the more complex filenames.
Then there is no need for a 

The purpose of having a more complex file name is to
be able to see which kernel you have and it configuration.
Also to be able to copy multiple kernels for multiple chips to a single
directory - Typically /tftpboot.

uImage really does not give you *any* information on the contents.

When testing several configurations for the same kernel,
adding some kind of revision information is important.
THat is why the date is there, a little simplistic, but
it works for me.


> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

 >> To me the sane thing would just be for the files to be named whatever
 >> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
 >> do that we should atleast make the 2 Linux types use the same style.

 >> We can add BR2_KERNEL_PREFIX/SUFFIX (defaulting to "") if people
 >> really to do something special.
 >> 
 >> Ulf, what do you say?
 >> 

 Ulf> I think that we should have a symbolic link to xImage as we do for
 Ulf> u-boot.bin for those that do not like the more complex filenames.
 Ulf> Then there is no need for a 

I think the suggestion to either use the rootfs suffix/prefix or
introduce a kernel version of them makes more sense than adding more
clutter with symlinks (and the potential problems they give)

 Ulf> uImage really does not give you *any* information on the contents.

Similar to rootfs.powerpc.squashfs doesn't tell you much about what
files you have in there. When people see uImage or u-boot.bin, it's
completely clear what type of image format it is, as that's what they
are used to from compiling the kernel/u-boot/whatever by hand.

 Ulf> When testing several configurations for the same kernel,
 Ulf> adding some kind of revision information is important.
 Ulf> THat is why the date is there, a little simplistic, but
 Ulf> it works for me.

That's the point I guess - It's a pretty random decission that
obviously doesn't work for others.

This unstable kernel name doesn't work very well with scripts - E.G. I
have an updatelinux script in U-Boot which downloads a fixed filename
from tftp and writes it to flash.

But sure, we can support *_SUFFIX set to $(DATE) for the people who
wants something like that.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

----- Original Message ----- 
From: "Peter Korsgaard" <jacmet@uclibc.org>
To: <ulf.samuelsson@atmel.com>
Cc: "Peter Korsgaard" <jacmet@uclibc.org>; "Thiago A.Corr?a" 
<thiago.correa@gmail.com>; <buildroot@uclibc.org>
Sent: Friday, February 06, 2009 9:41 AM
Subject: Re: [Buildroot] What's up with the kernel names? (Again)


>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> >> To me the sane thing would just be for the files to be named whatever
> >> the kernel names them (uImage/zImage/bzImage/..), but even if we don't
> >> do that we should atleast make the 2 Linux types use the same style.
>
> >> We can add BR2_KERNEL_PREFIX/SUFFIX (defaulting to "") if people
> >> really to do something special.
> >>
> >> Ulf, what do you say?
> >>
>
> Ulf> I think that we should have a symbolic link to xImage as we do for
> Ulf> u-boot.bin for those that do not like the more complex filenames.
> Ulf> Then there is no need for a
>
> I think the suggestion to either use the rootfs suffix/prefix or
> introduce a kernel version of them makes more sense than adding more
> clutter with symlinks (and the potential problems they give)
>
> Ulf> uImage really does not give you *any* information on the contents.
>
> Similar to rootfs.powerpc.squashfs doesn't tell you much about what
> files you have in there.

> When people see uImage or u-boot.bin, it's
> completely clear what type of image format it is, as that's what they
> are used to from compiling the kernel/u-boot/whatever by hand.
>

Yes, but again, when you work on multiple boards, it is a useless name
If you look at commercial linux support (aty least Timesys), they do not 
distribute
files called "uImage", their naming is similar to the current.

If symlinks are no good, and I dont understand why, then a duplicate would 
work for me.

> Ulf> When testing several configurations for the same kernel,
> Ulf> adding some kind of revision information is important.
> Ulf> THat is why the date is there, a little simplistic, but
> Ulf> it works for me.
>
> That's the point I guess - It's a pretty random decission that
> obviously doesn't work for others.
>
> This unstable kernel name doesn't work very well with scripts - E.G. I
> have an updatelinux script in U-Boot which downloads a fixed filename
> from tftp and writes it to flash.
>
> But sure, we can support *_SUFFIX set to $(DATE) for the people who
> wants something like that.
>
> -- 
> Bye, Peter Korsgaard
>

Can we agree on
$(PROJECT)-linux-$(LINUX_VERSION)$(<XXX>_SUFFIX).$(<XXX>_EXT)

and leave $(DATE) in SUFFIX?

This is a stable name, and also gives the information I require.


Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> Yes, but again, when you work on multiple boards, it is a useless name
 Ulf> If you look at commercial linux support (aty least Timesys), they do
 Ulf> not distribute
 Ulf> files called "uImage", their naming is similar to the current.

Ok, but whatever timesys does shouldn't be the deciding factor for
what we do in BR, especially when there's objections from the
developers (here and on irc).

 Ulf> If symlinks are no good, and I dont understand why, then a duplicate
 Ulf> would work for me.

That would be silly, just set prefix/suffix to what you want.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

On Fri, Feb 6, 2009 at 6:56 AM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> Can we agree on
> $(PROJECT)-linux-$(LINUX_VERSION)$(<XXX>_SUFFIX).$(<XXX>_EXT)
>
> and leave $(DATE) in SUFFIX?
>
> This is a stable name, and also gives the information I require.
>

What's wrong with ROOTFS_SUFFIX = -$(PROJECT)-$(LINUX_VERSION)$(DATE) ?

You will get everything you had before, albeit in a different order
(uImage-myprojec-2.6.28-20080106)

I work on different projects all the time, most of the time more than
2, and I don't see how that information is usefull at all. All I
really need to preserve is a copy of buildroot and dl folder. On the
other hand, the support ppl just need to preserve the firmware image
(rootfs in this case). Binaries are of no use to a developer, we need
is to be able to reproduce builds.

Whenever I need to update something in a product, it usually goes in a
full system update. The kernel is no speciall case for updates, it's
just one of the many stuff in rootfs.

On the other hand, during developent, you will often need to repeat
the build with the same configuration over and over. Specially if you,
like me, needs to add your own custom programs in there. It doesn't
make any sense then having several binaries of all your previous
failled attempts.

But please, again notice, that we are not forcing our way on others.
It's still possible to get all that info into the generated files if
you want. Plus, if you have many different projects, you know which
kernel belongs to each rootfs, since the suffix matches.


Ulf> If you add KERNEL_VERSION to the root fs name you do things
Ulf> automatically, if you dont then everything is manually, and you
Ulf> have a risk of mismatch between name and actual version.  I
Ulf> would not mind that the rootfs contains kernel version, but it
Ulf> will break the at91 u-boot autoscripts which means that it
Ulf> should avoided at this point, and introduced in a future
Ulf> buildroot.

I suspect that the autoscript generation uses the same variable as the
kernel build. Otherwise it's impossible to predict your current naming
scheme. If so, it wouldn't break anything, as the variable is
preserved, just it's contents changed slightly.

Kind Regards,
   Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

On Fri, Feb 6, 2009 at 12:31 PM, Thiago A. Corr?a
<thiago.correa@gmail.com> wrote:
> Ulf> If you add KERNEL_VERSION to the root fs name you do things
> Ulf> automatically, if you dont then everything is manually, and you
> Ulf> have a risk of mismatch between name and actual version.  I
> Ulf> would not mind that the rootfs contains kernel version, but it
> Ulf> will break the at91 u-boot autoscripts which means that it
> Ulf> should avoided at this point, and introduced in a future
> Ulf> buildroot.
>
> I suspect that the autoscript generation uses the same variable as the
> kernel build. Otherwise it's impossible to predict your current naming
> scheme. If so, it wouldn't break anything, as the variable is
> preserved, just it's contents changed slightly.

From target/u-boot/Makefile.in:
        echo setenv linux $(LINUX26_KERNEL_NAME).gz >> $(U_BOOT_AUTOSCRIPT)

So, it should be ok.

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

fre 2009-02-06 klockan 12:31 -0200 skrev Thiago A. Corr?a:
> On Fri, Feb 6, 2009 at 6:56 AM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> > Can we agree on
> > $(PROJECT)-linux-$(LINUX_VERSION)$(<XXX>_SUFFIX).$(<XXX>_EXT)
> >
> > and leave $(DATE) in SUFFIX?
> >
> > This is a stable name, and also gives the information I require.
> >
> 
> What's wrong with ROOTFS_SUFFIX = -$(PROJECT)-$(LINUX_VERSION)$(DATE) ?
> 
> You will get everything you had before, albeit in a different order
> (uImage-myprojec-2.6.28-20080106)
> 

Which breaks the U-Boot autoscripts.

It also makes it harder to get an overview if you list
a directory and files pertaining to a single board are spread out all
over when you sort in alphabetical order.

If I do ls, I'd like to have the files together.

> I work on different projects all the time, most of the time more than
> 2, and I don't see how that information is usefull at all. All I
> really need to preserve is a copy of buildroot and dl folder. On the
> other hand, the support ppl just need to preserve the firmware image
> (rootfs in this case). Binaries are of no use to a developer, we need
> is to be able to reproduce builds.
> 

A lot of people just want to upload prebuilt binaries 
in the initial evaluation phase of a new MCU.
Later they want to develop stuff.

When you build 10 boards and keep the binaries in /tftpboot
you want to know what they are.


> Whenever I need to update something in a product, it usually goes in a
> full system update. The kernel is no speciall case for updates, it's
> just one of the many stuff in rootfs.
> 
> On the other hand, during developent, you will often need to repeat
> the build with the same configuration over and over. Specially if you,
> like me, needs to add your own custom programs in there. It doesn't
> make any sense then having several binaries of all your previous
> failled attempts.
> 
> But please, again notice, that we are not forcing our way on others.
> It's still possible to get all that info into the generated files if
> you want. Plus, if you have many different projects, you know which
> kernel belongs to each rootfs, since the suffix matches.

I need it in this specific order.
I also would like to avoid unneccesary problems
due to someone forgetting to update strings.

You need to have a single filename which does not change.

I have proposed something that can be static.

> 
> Ulf> If you add KERNEL_VERSION to the root fs name you do things
> Ulf> automatically, if you dont then everything is manually, and you
> Ulf> have a risk of mismatch between name and actual version.  I
> Ulf> would not mind that the rootfs contains kernel version, but it
> Ulf> will break the at91 u-boot autoscripts which means that it
> Ulf> should avoided at this point, and introduced in a future
> Ulf> buildroot.
> 
> I suspect that the autoscript generation uses the same variable as the
> kernel build. Otherwise it's impossible to predict your current naming
> scheme. If so, it wouldn't break anything, as the variable is
> preserved, just it's contents changed slightly.

If you want to do changes, then you need to test and verify that it
works.
And I repeat, I want all files related to a specific project
to be sorted together.



> Kind Regards,
>    Thiago A. Correa
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> You will get everything you had before, albeit in a different order
 >> (uImage-myprojec-2.6.28-20080106)
 >> 

 Ulf> Which breaks the U-Boot autoscripts.

Why? It looks like it uses LINUX26_KERNEL_NAME.

 Ulf> I need it in this specific order.
 Ulf> I also would like to avoid unneccesary problems
 Ulf> due to someone forgetting to update strings.

Then set the appropriate _SUFFIX / _PREFIX variables.

 Ulf> And I repeat, I want all files related to a specific project
 Ulf> to be sorted together.

Then put them in /tftpboot/<project>/.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

m?n 2009-02-09 klockan 20:34 +0100 skrev Peter Korsgaard:
> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
>  >> You will get everything you had before, albeit in a different order
>  >> (uImage-myprojec-2.6.28-20080106)
>  >> 
> 
>  Ulf> Which breaks the U-Boot autoscripts.

> Why? It looks like it uses LINUX26_KERNEL_NAME.
> 

They work with the patches to u-boot which assumes
that the name look like they used to.
If the new naming remains, who is going to fix the u-boot patches?


>  Ulf> I need it in this specific order.
>  Ulf> I also would like to avoid unneccesary problems
>  Ulf> due to someone forgetting to update strings.
> 
> Then set the appropriate _SUFFIX / _PREFIX variables.
> 

AGAIN: How can you RETROACTIVELY set _SUFFIX/_PREFIX
if you forgot to set _SUFFIX/_PREFIX and thus
overwrote another project.

It is high maintenance and error prone to do it this way.


>  Ulf> And I repeat, I want all files related to a specific project
>  Ulf> to be sorted together.
> 
> Then put them in /tftpboot/<project>/.
> 

Which again means fixing u-boot patches.
Who is going to do that
You suggested previously that the person breaking the build
needs to fix it.
Does that still apply?

BR
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

On Mon, Feb 9, 2009 at 8:52 PM, Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> m?n 2009-02-09 klockan 20:34 +0100 skrev Peter Korsgaard:
>> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>>
>> Hi,
>>
>>  >> You will get everything you had before, albeit in a different order
>>  >> (uImage-myprojec-2.6.28-20080106)
>>  >>
>>
>>  Ulf> Which breaks the U-Boot autoscripts.
>
>> Why? It looks like it uses LINUX26_KERNEL_NAME.
>>
>
> They work with the patches to u-boot which assumes
> that the name look like they used to.
> If the new naming remains, who is going to fix the u-boot patches?
>

I don't see anywhere where the kernel name is referenced in u-boot
except for the generation of the script, which I fixed. Looks like
Peter is also unable to guess what you are talking about. Perhaps you
might care to enlighten us.

>>  Ulf> I need it in this specific order.
>>  Ulf> I also would like to avoid unneccesary problems
>>  Ulf> due to someone forgetting to update strings.
>>
>> Then set the appropriate _SUFFIX / _PREFIX variables.
>>
>
> AGAIN: How can you RETROACTIVELY set _SUFFIX/_PREFIX
> if you forgot to set _SUFFIX/_PREFIX and thus
> overwrote another project.

Are you serious? It's irresponsible not to use version control for
work related development. If someone forgets to set it and they really
want to, they would detect it the first time they built and tested the
system.
Also, after said test, they would imediatly notice that if they want
to keep the binary, they should save it. That's the same for every
tool that generates binaries, from compilers, to CADs, even text
editors.

> It is high maintenance and error prone to do it this way.
>

You are probably only looking at this with the eyes of a chip
manufaturer. Atmel makes boards, we, customers from Atmel, we build
projects or products. We have boards that are used in countless
products, whose only difference is their firmwares or daughter boards.
It's not a BOARDNAME variable that will keep things from being
overwritten or completely mixed up to the point that it's impossible
to tell what is the contents of the rootfs.


>>  Ulf> And I repeat, I want all files related to a specific project
>>  Ulf> to be sorted together.
>>
>> Then put them in /tftpboot/<project>/.
>>
>
> Which again means fixing u-boot patches.
> Who is going to do that
> You suggested previously that the person breaking the build
> needs to fix it.
> Does that still apply?
>

As I said, it looks just ok to me. If you explain what seems to be the
problem I could take a look and see if I'm able to do it.
This policy won't work for long: If I don't have the skills to fix it,
no amount of complains is going to help unless explained. You can't
expect everyone on a project to have the same skills, not only unreal,
but also hurts the project as it drives away contributions. Helping
and explaining is much better than complaining.

I did my best not to break things. The build isn't broken on any of
the tests I've made, and I even got a u-boot.bin, therefore things
can't be horribly broken.

Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

On Mon, Feb 9, 2009 at 8:52 PM, Ulf Samuelsson <ulf.samuelsson@atmel.com> 
wrote:
> m?n 2009-02-09 klockan 20:34 +0100 skrev Peter Korsgaard:
>> >>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>>
>> Hi,
>>
>>  >> You will get everything you had before, albeit in a different order
>>  >> (uImage-myprojec-2.6.28-20080106)
>>  >>
>>
>>  Ulf> Which breaks the U-Boot autoscripts.
>
>> Why? It looks like it uses LINUX26_KERNEL_NAME.
>>
>
> They work with the patches to u-boot which assumes
> that the name look like they used to.
> If the new naming remains, who is going to fix the u-boot patches?
>

I don't see anywhere where the kernel name is referenced in u-boot
except for the generation of the script, which I fixed. Looks like
Peter is also unable to guess what you are talking about. Perhaps you
might care to enlighten us.


==> Look at the u.-boot patches in device/Atmel/arch-arm/

Best Regards
Ulf Samuelsson


>>  Ulf> I need it in this specific order.
>>  Ulf> I also would like to avoid unneccesary problems
>>  Ulf> due to someone forgetting to update strings.
>>
>> Then set the appropriate _SUFFIX / _PREFIX variables.
>>
>
> AGAIN: How can you RETROACTIVELY set _SUFFIX/_PREFIX
> if you forgot to set _SUFFIX/_PREFIX and thus
> overwrote another project.

Are you serious? It's irresponsible not to use version control for
work related development. If someone forgets to set it and they really
want to, they would detect it the first time they built and tested the
system.

==> And that is time wasted.

Also, after said test, they would imediatly notice that if they want
to keep the binary, they should save it. That's the same for every
tool that generates binaries, from compilers, to CADs, even text
editors.

> It is high maintenance and error prone to do it this way.
>

You are probably only looking at this with the eyes of a chip
manufaturer. Atmel makes boards, we, customers from Atmel, we build
projects or products. We have boards that are used in countless
products, whose only difference is their firmwares or daughter boards.
It's not a BOARDNAME variable that will keep things from being
overwritten or completely mixed up to the point that it's impossible
to tell what is the contents of the rootfs.



>>  Ulf> And I repeat, I want all files related to a specific project
>>  Ulf> to be sorted together.
>>
>> Then put them in /tftpboot/<project>/.
>>
>
> Which again means fixing u-boot patches.
> Who is going to do that
> You suggested previously that the person breaking the build
> needs to fix it.
> Does that still apply?
>

As I said, it looks just ok to me. If you explain what seems to be the
problem I could take a look and see if I'm able to do it.

==> The u-boot patches allows you to use the long filenames without
        having to update the complete filename all the time.

This policy won't work for long: If I don't have the skills to fix it,
no amount of complains is going to help unless explained. You can't
expect everyone on a project to have the same skills, not only unreal,
but also hurts the project as it drives away contributions. Helping
and explaining is much better than complaining.

==> I designed the advanced linux configuration to tightly fit together with 
u-boot
        to mimize the hassle of getting the board up and running.
        You can always build the classic linux configuration 
target/linux/Makefile.in",
        so unless you are prepared to go the whole way, why meddle?
        Peter has said on other occasions: "fix the problem you created, or 
revert the patch".

I did my best not to break things. The build isn't broken on any of
the tests I've made, and I even got a u-boot.bin, therefore things
can't be horribly broken.

==> You have to build for an AT91; and download to the target,
        create the default environment,
        and then download the kernel/rootfs over ethernet
        as well as booting linux to do a full test.
        When you update anything, like kernel version and recompute
        the filenames, you will discover it is broken
        Read the code and you will see it.

Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> I don't see anywhere where the kernel name is referenced in u-boot
 Ulf> except for the generation of the script, which I fixed. Looks like
 Ulf> Peter is also unable to guess what you are talking about. Perhaps you
 Ulf> might care to enlighten us.

 Ulf> ==> Look at the u.-boot patches in device/Atmel/arch-arm/

Ulf, see again why hiding that kind of "magic" under target/device is
bad? If things break for specific platforms because they have feature
patches hidden away under target/device then I think it's pretty
unrealistic for other developers to fix it.

 Ulf> ==> I designed the advanced linux configuration to tightly fit
 Ulf> together with u-boot
 Ulf>        to mimize the hassle of getting the board up and running.
 Ulf>        You can always build the classic linux configuration
 Ulf> target/linux/Makefile.in",
 Ulf>        so unless you are prepared to go the whole way, why meddle?

So maybe the problems we're seing is in that design? I don't use the
linux-advanced stuff, but my feeling is that there's too much "magic"
going around here, and that things are too specialized.

But that's a discussion for another day.

 Ulf>        Peter has said on other occasions: "fix the problem you
 Ulf> created, or revert the patch".

And I agree with that, but it's ofcourse not black/white. What I mean
is that if you make changes, then you need to work with the other
developers to help fix up stuff and/or change it so stuff doesn't
break.

In other words, try to think bigger than just your specific platform.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Hi,
>
> Ulf> I don't see anywhere where the kernel name is referenced in u-boot
> Ulf> except for the generation of the script, which I fixed. Looks like
> Ulf> Peter is also unable to guess what you are talking about. Perhaps you
> Ulf> might care to enlighten us.
>
> Ulf> ==> Look at the u.-boot patches in device/Atmel/arch-arm/
>
> Ulf, see again why hiding that kind of "magic" under target/device is
> bad? If things break for specific platforms because they have feature
> patches hidden away under target/device then I think it's pretty
> unrealistic for other developers to fix it.
>
> Ulf> ==> I designed the advanced linux configuration to tightly fit
> Ulf> together with u-boot
> Ulf>        to mimize the hassle of getting the board up and running.
> Ulf>        You can always build the classic linux configuration
> Ulf> target/linux/Makefile.in",
> Ulf>        so unless you are prepared to go the whole way, why meddle?
>
> So maybe the problems we're seing is in that design? I don't use the
> linux-advanced stuff, but my feeling is that there's too much "magic"
> going around here, and that things are too specialized.
>

The advanced kernel build allows you to build any kernel since 2.6.22.
It allows you to take any patch from kernel.org and apply.
It allows you to take patches for a group of parts, I.E AT91 or AVR32
and it allows you to make a board specific patch.
It also allows you to take any patch you desire and apply on top.

It does not get to be more general purpose than that..

Anyone can, if they want to, add similar patchsets for other chips.
The fact that this has not happened, does not make this "specialized".

I do not see why, if  Thiagos only problem is that the build is not called 
uImage,
he cannot use the "simple kernel build"
As I see it, he wants to use 95% what I have written and then destroy the 
final stage.
I think that sucks.


> But that's a discussion for another day.
>
>

Best Regards
Ulf Samuelsson 

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Why? It looks like it uses LINUX26_KERNEL_NAME.
 >> 

 Ulf> They work with the patches to u-boot which assumes
 Ulf> that the name look like they used to.
 Ulf> If the new naming remains, who is going to fix the u-boot patches?

See, that's the problem about adding feature patches to BR. Don't
expect other developers to spend time on fixing those things up.

 Ulf> AGAIN: How can you RETROACTIVELY set _SUFFIX/_PREFIX
 Ulf> if you forgot to set _SUFFIX/_PREFIX and thus
 Ulf> overwrote another project.

Another project would have another BR2_PROJECT setting, and hence use
another directory, right? That was the idea behind the project thing,
wasn't it?

 Ulf> Which again means fixing u-boot patches.
 Ulf> Who is going to do that
 Ulf> You suggested previously that the person breaking the build
 Ulf> needs to fix it.
 Ulf> Does that still apply?

For bugfixes yes, but for feature patches for some kind of hardware
the developer might not have access to - No.

Sure, we should try to make sure everything still works, but we also
HAVE to make it easy to do so - That means among others that the
various platforms should behave similary.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

> 
> Hi,
> 
> >> Why? It looks like it uses LINUX26_KERNEL_NAME.
> >> 
> 
> Ulf> They work with the patches to u-boot which assumes
> Ulf> that the name look like they used to.
> Ulf> If the new naming remains, who is going to fix the u-boot patches?
> 
> See, that's the problem about adding feature patches to BR. Don't
> expect other developers to spend time on fixing those things up.

I think you want people to discuss things before committing.
Yet, this patch was committed before an agreement was made.
THAT is the problem.
The patch should not have been committed by Thiago, unless 
he is prepared to go the full way.

> Ulf> AGAIN: How can you RETROACTIVELY set _SUFFIX/_PREFIX
> Ulf> if you forgot to set _SUFFIX/_PREFIX and thus
> Ulf> overwrote another project.
> 
> Another project would have another BR2_PROJECT setting, and hence use
> another directory, right? That was the idea behind the project thing,
> wasn't it?

Yes and No
Not if you publish the resulting binaries on an ftp mirror
and not if you have a common /tftpboot directory.

Then missing out on fixing _SUFFIC/_PREFIX means 
additional work, something which was not needed
with the previous implementation.

> 
> Ulf> Which again means fixing u-boot patches.
> Ulf> Who is going to do that
> Ulf> You suggested previously that the person breaking the build
> Ulf> needs to fix it.
> Ulf> Does that still apply?
> 
> For bugfixes yes, but for feature patches for some kind of hardware
> the developer might not have access to - No.
> 
> Sure, we should try to make sure everything still works, but we also
> HAVE to make it easy to do so - That means among others that the
> various platforms should behave similary.
> 

Each platform in u-boot behaves differently anyway.
You define the functionality of u-boot in the board header file.

> -- 
> Bye, Peter Korsgaard
>


Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> See, that's the problem about adding feature patches to BR. Don't
 >> expect other developers to spend time on fixing those things up.

 Ulf> I think you want people to discuss things before committing.

Sure.

 Ulf> Yet, this patch was committed before an agreement was made.
 Ulf> THAT is the problem.

That's part of the problem. I mentioned some of the other issues in my
earlier mail. The reason for the change was the hardcoded (and imho
odd) naming convention. I explicitly asked Thiago to commit soon so we
could get it in the release. It's ofcourse unfortunate that FOSDEM got
in between and that you have special at91 specific magic in the tree
which got broken.

 >> Sure, we should try to make sure everything still works, but we also
 >> HAVE to make it easy to do so - That means among others that the
 >> various platforms should behave similary.
 >> 

 Ulf> Each platform in u-boot behaves differently anyway.
 Ulf> You define the functionality of u-boot in the board header file.

Sure, that's why the only sane default is to use the filenames the
upstream projects use as that's what people expect.

This doesn't mean that we shouldn't provide a setting (like the
suffix/prefix thing) to use other names if people want that, but it
shouldn't be default.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Hi,
> 
> >> See, that's the problem about adding feature patches to BR. Don't
> >> expect other developers to spend time on fixing those things up.
> 
> Ulf> I think you want people to discuss things before committing.
> 
> Sure.
> 
> Ulf> Yet, this patch was committed before an agreement was made.
> Ulf> THAT is the problem.
> 
> That's part of the problem. I mentioned some of the other issues in my
> earlier mail. The reason for the change was the hardcoded (and imho
> odd) naming convention. I explicitly asked Thiago to commit soon so we
> could get it in the release. It's ofcourse unfortunate that FOSDEM got
> in between and that you have special at91 specific magic in the tree
> which got broken.
> 
> >> Sure, we should try to make sure everything still works, but we also
> >> HAVE to make it easy to do so - That means among others that the
> >> various platforms should behave similary.
> >> 
> 
> Ulf> Each platform in u-boot behaves differently anyway.
> Ulf> You define the functionality of u-boot in the board header file.
> 
> Sure, that's why the only sane default is to use the filenames the
> upstream projects use as that's what people expect.
> 
> This doesn't mean that we shouldn't provide a setting (like the
> suffix/prefix thing) to use other names if people want that, but it
> shouldn't be default.


The default IS to use the filenames the upstream projects use.
You get that by selecting the standard build.
When you select an "advanced" configuration, you should
expect things to be a little different, don't you agree?

There is a setting to generate the u-boot autoscript.
If you use that, you really want the stuff to be compatible
with the u-boot patches.
I am OK with using that to set the default filename to 
the previous "complex" file name, and let the
normal #Image possibly with PREFIX/SUFFIX
be the default otherwise.

The patches for U-boot are generic and coould be applied
for any architecture.

The problem I am trying to solve is with newbies calling in 
wanting help with the configuration of u-boot.
That can be done with a short email instead of 30-60
minutes conversation, with this fully working.


> 
> -- 
> Bye, Peter Korsgaard
>



Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

On Tue, Feb 10, 2009 at 11:50 AM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
>> >> Sure, we should try to make sure everything still works, but we also
>> >> HAVE to make it easy to do so - That means among others that the
>> >> various platforms should behave similary.
>> >>
>> Ulf> Each platform in u-boot behaves differently anyway.
>> Ulf> You define the functionality of u-boot in the board header file.
>>
>> Sure, that's why the only sane default is to use the filenames the
>> upstream projects use as that's what people expect.
>>
>> This doesn't mean that we shouldn't provide a setting (like the
>> suffix/prefix thing) to use other names if people want that, but it
>> shouldn't be default.
>
>
> The default IS to use the filenames the upstream projects use.
> You get that by selecting the standard build.
> When you select an "advanced" configuration, you should
> expect things to be a little different, don't you agree?

First of all, that's not fair when you have said earlier that some
platforms (namely avr32) are just unable to build with the "standard"
option, and therefore, there is no choice.
Second of all, I expect to have more choices in advanced, not less.
Third of all, your At91 customers will have the exact same problem had
they choosen the standard build because they also don't want the
forced odd name.

> There is a setting to generate the u-boot autoscript.
> If you use that, you really want the stuff to be compatible
> with the u-boot patches.
> I am OK with using that to set the default filename to the previous
> "complex" file name, and let the
> normal #Image possibly with PREFIX/SUFFIX
> be the default otherwise.
>
> The patches for U-boot are generic and coould be applied
> for any architecture.
>
> The problem I am trying to solve is with newbies calling in wanting help
> with the configuration of u-boot.
> That can be done with a short email instead of 30-60
> minutes conversation, with this fully working.
>

I found this on the patches:
+       setenv("linux",
MK_STR(BOARD_NAME)"-linux-"MK_STR(KERNEL_VERSION)"-"MK_STR(DATE)".gz");

That was broken to begin with. It has an hardcoded filename extension,
while the previous "naming convention" allowed for other different
extensions. The proper way of doing that would be:

+       setenv("linux",         MK_STR(KERNEL_LINUX26_NAME));

even without my changes! Only then it would be set to the kernel name,
whatever it might be. After that just echo that make variable to the
header where you previously defined the other macros.
Now, if we change the patch like above, at least this part, would work
even with standard build since I've made those variables have the same
name in both standard and advanced build.

While still on the subject, why haven't the patches been submitted
upstream? Last time you said that the At91 had given up because u-boot
devs were unavailable. Then, after that, avr32 team were able to get
their patches upstream. Why haven't At91 tried again?

We probably wouldn't be having this conversation had patches been
submited upstream, because they would not accept that and it would
have been fixed then.

I think I can edit the patch manually and have it build, but I can't
download it to a target, unless you want to ship a board and
programming tool to Brazil (with taxes to be collected from sender,
otherwise I will just refuse the package).

Kind Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

    Ulf, here. Check the attached patch, this should fix the u-boot
commands you have added as patches. I'm still building, but the code
looks ok, so I don't think there will be problems.
    I think the os command is quite useless, as it says "select the
kernel version" but there doesn't seam to be any choices at all, but
anyway, if you want to keep it, it's fixed too. If you want, you can
apply the patch and commit, I won't commit this directly myself.

Kind Regards,
   Thiago A. Correa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.patch
Type: application/octet-stream
Size: 2400 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20090210/93471ca4/attachment-0001.obj>

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

No you have totally misunderstood.
U-Boot will, with my patch use an initial default, but you can
update the linux kernel version and then automatically generate the 
kernel name for tftp download without recompiling u-boot.

That is why you have the os command.

A better implementation would automatically
recompute the linux kernel name when any
part of it is changed.

Best Regards
Ulf Samuelsson



> Hi,
> 
>    Ulf, here. Check the attached patch, this should fix the u-boot
> commands you have added as patches. I'm still building, but the code
> looks ok, so I don't think there will be problems.
>    I think the os command is quite useless, as it says "select the
> kernel version" but there doesn't seam to be any choices at all, but
> anyway, if you want to keep it, it's fixed too. If you want, you can
> apply the patch and commit, I won't commit this directly myself.
> 
> Kind Regards,
>   Thiago A. Correa
>

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

On Tue, Feb 10, 2009 at 3:42 PM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
> No you have totally misunderstood.
> U-Boot will, with my patch use an initial default, but you can
> update the linux kernel version and then automatically generate the kernel
> name for tftp download without recompiling u-boot.
>
> That is why you have the os command.
>
> A better implementation would automatically
> recompute the linux kernel name when any
> part of it is changed.
>

But you never update kernel-date env variable. That way it can't guess
what to concatenate in there, or it will always generate the same
name.

One possible way could be:
+int do_os (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+       char kname[512];
+       char *curname;
+       char *kdate;
+       int datepos;
+       curname = getenv("linux");
+       kdate = getenv("kernel-date");
+       datepos = strstr(curname, kdate);
+       if (datepos) {
+               //Replace the hardcoded date
+               curname[datepos] = 0;
+               sprintf(kname, "%s%s%s", curname, date??, curname +
datepos + strlen(kdate));
+       } else {
+               strcpy(kname, "uImage");
+       }
+       setenv("linux", kname);
+       return 0;
+}

This searches the kernel-date inside the name, therefore it can be
anywhere, and updates it. But as you can see from date??? I have no
idea where the new value comes from.
If it comes from some script or program, it could be modified so that
it stores the older date in kernel-olddate variable, then you searcho
for it and replace with the new date:

+int do_os (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+       char kname[512];
+       char *curname;
+       char *kdate;
+       int datepos;
+       curname = getenv("linux");
+       kdate = getenv("kernel-olddate");
+       datepos = strstr(curname, kdate);
+       if (datepos) {
+               //Replace the hardcoded date
+               curname[datepos] = 0;
+               sprintf(kname, "%s%s%s", curname,
getenv("kernel-date"), curname + datepos + strlen(kdate));
+       } else {
+               strcpy(kname, "uImage");
+       }
+       setenv("linux", kname);
+       return 0;
+}


Regards,
   Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

tis 2009-02-10 klockan 16:48 -0200 skrev Thiago A. Corr?a:
> Hi,
> 
> On Tue, Feb 10, 2009 at 3:42 PM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
> > No you have totally misunderstood.
> > U-Boot will, with my patch use an initial default, but you can
> > update the linux kernel version and then automatically generate the kernel
> > name for tftp download without recompiling u-boot.
> >
> > That is why you have the os command.
> >
> > A better implementation would automatically
> > recompute the linux kernel name when any
> > part of it is changed.
> >
> 
> But you never update kernel-date env variable. That way it can't guess
> what to concatenate in there, or it will always generate the same
> name.


The user can do thinks like:

setenv kernel-date 20090123 ; os
setenv kernel-version 2.6.28.1; os

to tell u-boot that a new version is to be used.



--------------------------

Just for fun, I checked my OpenSuSE /boot directory

Guess what I found:

"vmlinuz" which happens to be a LINK to

??vmlinuz-$(KERNEL_VERSION)-$(REV)-$PROJECT)
?
There was also a:
vmlinux-$(KERNEL_VERSION)-$(REV)-$PROJECT).gz file

Looks like the guys doing OpenSuSE are as "odd" as I am.

Would be interesting to know how the /boot directory
in Fedora, Ubuntu etc look like.

BR
Ulf Samuelsson



> 
> One possible way could be:
> +int do_os (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> +{
> +       char kname[512];
> +       char *curname;
> +       char *kdate;
> +       int datepos;
> +       curname = getenv("linux");
> +       kdate = getenv("kernel-date");
> +       datepos = strstr(curname, kdate);
> +       if (datepos) {
> +               //Replace the hardcoded date
> +               curname[datepos] = 0;
> +               sprintf(kname, "%s%s%s", curname, date??, curname +
> datepos + strlen(kdate));
> +       } else {
> +               strcpy(kname, "uImage");
> +       }
> +       setenv("linux", kname);
> +       return 0;
> +}
> 
> This searches the kernel-date inside the name, therefore it can be
> anywhere, and updates it. But as you can see from date??? I have no
> idea where the new value comes from.
> If it comes from some script or program, it could be modified so that
> it stores the older date in kernel-olddate variable, then you searcho
> for it and replace with the new date:
> 
> +int do_os (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
> +{
> +       char kname[512];
> +       char *curname;
> +       char *kdate;
> +       int datepos;
> +       curname = getenv("linux");
> +       kdate = getenv("kernel-olddate");
> +       datepos = strstr(curname, kdate);
> +       if (datepos) {
> +               //Replace the hardcoded date
> +               curname[datepos] = 0;
> +               sprintf(kname, "%s%s%s", curname,
> getenv("kernel-date"), curname + datepos + strlen(kdate));
> +       } else {
> +               strcpy(kname, "uImage");
> +       }
> +       setenv("linux", kname);
> +       return 0;
> +}
> 
> 
> Regards,
>    Thiago A. Correa
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Ulf> Just for fun, I checked my OpenSuSE /boot directory

 Ulf> Guess what I found:

 Ulf> "vmlinuz" which happens to be a LINK to

 Ulf> ??vmlinuz-$(KERNEL_VERSION)-$(REV)-$PROJECT)
 Ulf> ?
 Ulf> There was also a:
 Ulf> vmlinux-$(KERNEL_VERSION)-$(REV)-$PROJECT).gz file

 Ulf> Looks like the guys doing OpenSuSE are as "odd" as I am.

And guess what the kernel outputs? A simple arch/x86/boot/bzImage, as
platform/distribution specific naming convention doesn't belong in the
mainline kernel.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

>
> Hi,
>
> Ulf> Just for fun, I checked my OpenSuSE /boot directory
>
> Ulf> Guess what I found:
>
> Ulf> "vmlinuz" which happens to be a LINK to
>
> Ulf> ??vmlinuz-$(KERNEL_VERSION)-$(REV)-$PROJECT)
> Ulf> ?
> Ulf> There was also a:
> Ulf> vmlinux-$(KERNEL_VERSION)-$(REV)-$PROJECT).gz file
>
> Ulf> Looks like the guys doing OpenSuSE are as "odd" as I am.
>
> And guess what the kernel outputs? A simple arch/x86/boot/bzImage, as
> platform/distribution specific naming convention doesn't belong in the
> mainline kernel.
>

No but it belongs in the distribution created by buildroot.
Try making a remote upgrade when the old kernel and the new kernel has the 
same name.

Your argument smells of
"we have always done it in a certain way, and therefore we should always do 
it in the same way".
There are some reasons why you may want to have a simple name,
and all these reasons are covered by generating a symlink.

It is a good idea to make things as simple as possible, you are trying to 
make things simpler than that.

Best Regards
Ulf Samuelsson

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

On Thu, Feb 12, 2009 at 3:16 PM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
>
>>
>> Hi,
>>
>> Ulf> Just for fun, I checked my OpenSuSE /boot directory
>>
>> Ulf> Guess what I found:
>>
>> Ulf> "vmlinuz" which happens to be a LINK to
>>
>> Ulf> ??vmlinuz-$(KERNEL_VERSION)-$(REV)-$PROJECT)
>> Ulf> ?
>> Ulf> There was also a:
>> Ulf> vmlinux-$(KERNEL_VERSION)-$(REV)-$PROJECT).gz file
>>
>> Ulf> Looks like the guys doing OpenSuSE are as "odd" as I am.
>>
>> And guess what the kernel outputs? A simple arch/x86/boot/bzImage, as
>> platform/distribution specific naming convention doesn't belong in the
>> mainline kernel.
>>
>
> No but it belongs in the distribution created by buildroot.
> Try making a remote upgrade when the old kernel and the new kernel has the
> same name.

Hardly any embedded device contains just a linux system without any
custom software made by the manufacturer of the product, which is
usually closed source.

Had the upgrade been motivated by changes in that closed source part,
the kernel would probably be the same.

Also, even if the kernel names had unpredictable entrophy in it, the
upgrade program has to handle it, removing the old binary, otherwise
you would fill up all the flash space.

> Your argument smells of
> "we have always done it in a certain way, and therefore we should always do
> it in the same way".
> There are some reasons why you may want to have a simple name,
> and all these reasons are covered by generating a symlink.

Actually, it looks like you are trying to come up with any sort of
argument against. Last one you could think of was that the ls *had* to
list files in a specific order. But even that could be done with
addition of a prefix. Now, 5 days later you come up with upgrading
problems.
The current solution does allow you to do the exact same thing, while
still giving the flexibility of opting not to use it at all. We are
not limiting your options, but rather giving more, why can't we just
let this thread go?

Even the u-boot patches could be made to work: Either look for a date
by strstr, or, adopt a template for the command to work, and set that
into the suffix. Same as before, except that instead of
linux-version-date, it would be uImage-version-date.

Then you could set the at91*_defconfig to that default, instead of
setting it into Config.in or makefiles.
It would be best implemented as the first solution, but the second one
is easiest.

> It is a good idea to make things as simple as possible, you are trying to
> make things simpler than that.
>

Hard coded prefix, suffix and extension plus symlink is much closer to
overcomplicated than current solution is to over simplification.

Kind Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Thiago" == Thiago A Corr?a <thiago.correa@gmail.com> writes:

Hi,

 Thiago> The current solution does allow you to do the exact same
 Thiago> thing, while still giving the flexibility of opting not to
 Thiago> use it at all. We are not limiting your options, but rather
 Thiago> giving more, why can't we just let this thread go?

I agree, I'm also getting tired of it. The new setup is more flexible
than before and still nice and clean.

 >> It is a good idea to make things as simple as possible, you are
 >> trying to make things simpler than that.

 Thiago> Hard coded prefix, suffix and extension plus symlink is much
 Thiago> closer to overcomplicated than current solution is to over
 Thiago> simplification.

Agreed.

-- 
Bye, Peter Korsgaard

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

Subject: Re: [Buildroot] What's up with the kernel names? (Again)


> Hi,
> 
> On Tue, Feb 10, 2009 at 11:50 AM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
>>> >> Sure, we should try to make sure everything still works, but we also
>>> >> HAVE to make it easy to do so - That means among others that the
>>> >> various platforms should behave similary.
>>> >>
>>> Ulf> Each platform in u-boot behaves differently anyway.
>>> Ulf> You define the functionality of u-boot in the board header file.
>>>
>>> Sure, that's why the only sane default is to use the filenames the
>>> upstream projects use as that's what people expect.
>>>
>>> This doesn't mean that we shouldn't provide a setting (like the
>>> suffix/prefix thing) to use other names if people want that, but it
>>> shouldn't be default.
>>
>>
>> The default IS to use the filenames the upstream projects use.
>> You get that by selecting the standard build.
>> When you select an "advanced" configuration, you should
>> expect things to be a little different, don't you agree?
> 
> First of all, that's not fair when you have said earlier that some
> platforms (namely avr32) are just unable to build with the "standard"
> option, and therefore, there is no choice.
> Second of all, I expect to have more choices in advanced, not less.
> Third of all, your At91 customers will have the exact same problem had
> they choosen the standard build because they also don't want the
> forced odd name.
> 
>> There is a setting to generate the u-boot autoscript.
>> If you use that, you really want the stuff to be compatible
>> with the u-boot patches.
>> I am OK with using that to set the default filename to the previous
>> "complex" file name, and let the
>> normal #Image possibly with PREFIX/SUFFIX
>> be the default otherwise.
>>
>> The patches for U-boot are generic and coould be applied
>> for any architecture.
>>
>> The problem I am trying to solve is with newbies calling in wanting help
>> with the configuration of u-boot.
>> That can be done with a short email instead of 30-60
>> minutes conversation, with this fully working.
>>
> 
> I found this on the patches:
> +       setenv("linux",
> MK_STR(BOARD_NAME)"-linux-"MK_STR(KERNEL_VERSION)"-"MK_STR(DATE)".gz");
> 
> That was broken to begin with. It has an hardcoded filename extension,
> while the previous "naming convention" allowed for other different
> extensions. The proper way of doing that would be:
> 
> +       setenv("linux",         MK_STR(KERNEL_LINUX26_NAME));
> 
> even without my changes! Only then it would be set to the kernel name,
> whatever it might be. After that just echo that make variable to the
> header where you previously defined the other macros.
> Now, if we change the patch like above, at least this part, would work
> even with standard build since I've made those variables have the same
> name in both standard and advanced build.
> 
> While still on the subject, why haven't the patches been submitted
> upstream? Last time you said that the At91 had given up because u-boot
> devs were unavailable. Then, after that, avr32 team were able to get
> their patches upstream. Why haven't At91 tried again?
> 
> We probably wouldn't be having this conversation had patches been
> submited upstream, because they would not accept that and it would
> have been fixed then.
> 
> I think I can edit the patch manually and have it build, but I can't
> download it to a target, unless you want to ship a board and
> programming tool to Brazil (with taxes to be collected from sender,
> otherwise I will just refuse the package).
> 
> Kind Regards,
>    Thiago A. Correa
>

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

Subject: Re: [Buildroot] What's up with the kernel names? (Again)


> Hi,
>
> On Tue, Feb 10, 2009 at 11:50 AM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
>>> >> Sure, we should try to make sure everything still works, but we also
>>> >> HAVE to make it easy to do so - That means among others that the
>>> >> various platforms should behave similary.
>>> >>
>>> Ulf> Each platform in u-boot behaves differently anyway.
>>> Ulf> You define the functionality of u-boot in the board header file.
>>>
>>> Sure, that's why the only sane default is to use the filenames the
>>> upstream projects use as that's what people expect.
>>>
>>> This doesn't mean that we shouldn't provide a setting (like the
>>> suffix/prefix thing) to use other names if people want that, but it
>>> shouldn't be default.
>>
>>
>> The default IS to use the filenames the upstream projects use.
>> You get that by selecting the standard build.
>> When you select an "advanced" configuration, you should
>> expect things to be a little different, don't you agree?
>
> First of all, that's not fair when you have said earlier that some
> platforms (namely avr32) are just unable to build with the "standard"
> option, and therefore, there is no choice.

You can build, but you do not get the latest patches.

> Second of all, I expect to have more choices in advanced, not less.
> Third of all, your At91 customers will have the exact same problem had
> they choosen the standard build because they also don't want the
> forced odd name.

That is an assumption you make.
I regularily discuss pro's and con's with buildroot with end customers.
There are a number of things brought up, but, so far, never the linux file 
name.

The key requirement for newbies is to load a kernel/rootfs to the target
with minimum effort. The current "cleanups" to "sane" defaults is clearly
making life harder for newbies.

This category does NOT want to change a lot of options from (in)sane 
defaults.
They want (at the most) to do

$ make userconfig                ; setup user specific defaults.
$ make <board>_config       ; setup board
$ make                                 ; build board
$ make install                        ; program target with resulting files.

and then connect to the target with a terminal and see linux boot.
*I* want it to be easy, or they will phone me and ask for help,
which means I can handle less projects.

We are far from this point, but with the u-boot patches I can easily
support people over the phone without worrying about
having the odd environment variable misspelled or so.

---------------
Once they have passed a certain point and are confident with buildroot
then the requirements change.

The main complaint of buildroot is lack of stability.
People do not want to upgrade and retest just because someone feels
that this is a good idea, they want 100% control over when upgrades happen.
At the same time they would like to work in a project which is maintained.

With buildroot you are forced to continuosly upgrade or you lose support
and it is getting worse.

There is complaints that there is no support for proprietary functions.
If you want to add your company logo at boot, this is certainly
not something that should  be in the trunk, but still people
want this to be easy to include in the build.



>
>> There is a setting to generate the u-boot autoscript.
>> If you use that, you really want the stuff to be compatible
>> with the u-boot patches.
>> I am OK with using that to set the default filename to the previous
>> "complex" file name, and let the
>> normal #Image possibly with PREFIX/SUFFIX
>> be the default otherwise.
>>
>> The patches for U-boot are generic and coould be applied
>> for any architecture.
>>
>> The problem I am trying to solve is with newbies calling in wanting help
>> with the configuration of u-boot.
>> That can be done with a short email instead of 30-60
>> minutes conversation, with this fully working.
>>
>
> I found this on the patches:
> +       setenv("linux",
> MK_STR(BOARD_NAME)"-linux-"MK_STR(KERNEL_VERSION)"-"MK_STR(DATE)".gz");
>
> That was broken to begin with. >

Considering that ?ou only AFAIK want to  build uImage's for U-Boot,
this is a minor restriction.

> It has an hardcoded filename extension,
> while the previous "naming convention" allowed for other different
> extensions. The proper way of doing that would be:
>
> +       setenv("linux",         MK_STR(KERNEL_LINUX26_NAME));
>

No, because the whole idea of the patches is that you can modify the
different parts of the filename afterwards.

If the kernel name is:

at91sam9260ek-linux-2.6.28-20081001.gz

then
"setenv kernel_version 2.6.28.1 ; os"

will change the kernel name to

at91sam9260ek-linux-2.6.28.1-20081001.gz

Your patch will FIX the kernel name to whatever was the name at u-boot 
build.

> even without my changes! Only then it would be set to the kernel name,
> whatever it might be. After that just echo that make variable to the
> header where you previously defined the other macros.
> Now, if we change the patch like above, at least this part, would work
> even with standard build since I've made those variables have the same
> name in both standard and advanced build.

As you see from above - NO.

>
> While still on the subject, why haven't the patches been submitted
> upstream? Last time you said that the At91 had given up because u-boot
> devs were unavailable. Then, after that, avr32 team were able to get
> their patches upstream. Why haven't At91 tried again?

You can send a mail to the at91 team and ask.

>
> We probably wouldn't be having this conversation had patches been
> submited upstream, because they would not accept that and it would
> have been fixed then.
>
> I think I can edit the patch manually and have it build, but I can't
> download it to a target, unless you want to ship a board and
> programming tool to Brazil (with taxes to be collected from sender,
> otherwise I will just refuse the package).

I can test any binary, but if it looks like the one you send, then that is 
broken.

>
> Kind Regards,
>    Thiago A. Correa
>

[Buildroot] What's up with the kernel names? (Again)

[Thiago A. Corrêa]

Hi,

   I think I finally understand your use case. But I still think you
are getting the requirement backward.

On Tue, Feb 10, 2009 at 4:50 PM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
>> Second of all, I expect to have more choices in advanced, not less.
>> Third of all, your At91 customers will have the exact same problem had
>> they choosen the standard build because they also don't want the
>> forced odd name.
>
> That is an assumption you make.
> I regularily discuss pro's and con's with buildroot with end customers.
> There are a number of things brought up, but, so far, never the linux file
> name.

Well, we buy quite a lot from Atmel, so you can count me as a first. :)

> The key requirement for newbies is to load a kernel/rootfs to the target
> with minimum effort. The current "cleanups" to "sane" defaults is clearly
> making life harder for newbies.

Agreed, and if the kernel is named uImage, there is no need for
setenv's or special undocumented commands.

> This category does NOT want to change a lot of options from (in)sane
> defaults.
> They want (at the most) to do
>
> $ make userconfig                ; setup user specific defaults.
> $ make <board>_config       ; setup board
> $ make                                 ; build board
> $ make install                        ; program target with resulting files.

If it was avr32, make install could simply invoke avr32program and
upload the rootfs to the target. Being uImage a static name, uboot
would never need to be touched, they could simply wait for the board
to load. Sure it's slow, but it's also easy.
AT91 might have something similar, I don't know. I evaluated Atmel's
ARMs once, but that J-Link programmer simply never worked. Might have
been a bad board, since it was in another customer before, I don't
know.

> and then connect to the target with a terminal and see linux boot.
> *I* want it to be easy, or they will phone me and ask for help,
> which means I can handle less projects.

Same here, but with a different reason. I'm on the other end of the
problem, I'm a software developer.
Whenever I need to test my code on the board, I want names not to
change. I know the previous build was flawed, or in the case of the
kernel, most likely is just the same binary. I need to rerun buildroot
when I change my code, so it links with all the system libs, but the
side effect is that I get a new kernel every day, except that they are
exactly the same binary that was just relinked because it's name
changed from yesterday.

> We are far from this point, but with the u-boot patches I can easily
> support people over the phone without worrying about
> having the odd environment variable misspelled or so.

Just don't create odd environment variables, then it can never be mispelled.

> ---------------
> Once they have passed a certain point and are confident with buildroot
> then the requirements change.
>
> The main complaint of buildroot is lack of stability.
> People do not want to upgrade and retest just because someone feels
> that this is a good idea, they want 100% control over when upgrades happen.
> At the same time they would like to work in a project which is maintained.
>
> With buildroot you are forced to continuosly upgrade or you lose support
> and it is getting worse.

That's what Peter is trying to fix. And I hope this goes well, because
I would like to see buildroot being stable. I remember that when I
started using buildroot, the toolchain was broken every 100 or so
revisions, and it was almost impossible to work. Try explaining that
to your management.

> There is complaints that there is no support for proprietary functions.
> If you want to add your company logo at boot, this is certainly
> not something that should  be in the trunk, but still people
> want this to be easy to include in the build.
>

That's the case of the silent u-boot build support, that I have added
a while back. We didn't want the console spilling out information as
we needed to use that U(S)ART for other purposes. It's not nice when
your custommer turns on your device and it sends to a printer several
pages of boot messages.

> No, because the whole idea of the patches is that you can modify the
> different parts of the filename afterwards.
>
> If the kernel name is:
>
> at91sam9260ek-linux-2.6.28-20081001.gz
>
> then
> "setenv kernel_version 2.6.28.1 ; os"
>
> will change the kernel name to
>
> at91sam9260ek-linux-2.6.28.1-20081001.gz
>
> Your patch will FIX the kernel name to whatever was the name at u-boot
> build.

Yeah, that's what I thought when I saw a file named factory defaults.
You could either have ppl build with a suffix that is predetermined such as:
at91sam9260ek-2.6.28-20081001 and get uImage-at91sam9260ek-2.6.28-20081001

And hardcode that do u-boot (as software developer, I find it horrible)

Or, you could drop all that complication and use uImage, or if you
really want that approach, make it better and introduce a command to
ask for kernel version, then generates it using strstr to find the
older entry, and therefore, it's able to cope with different naming
schemes, whatever the customer throws at it.

>>
>> While still on the subject, why haven't the patches been submitted
>> upstream? Last time you said that the At91 had given up because u-boot
>> devs were unavailable. Then, after that, avr32 team were able to get
>> their patches upstream. Why haven't At91 tried again?
>
> You can send a mail to the at91 team and ask.

Does support.atmel.no makes any difference? I had a ticket there
asking for the avr32 patches to be submited to FSF over a year ago,
and we all know how that turned out so far.


Kind Regards,
    Thiago A. Correa

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

Subject: Re: [Buildroot] What's up with the kernel names? (Again)


> Hi,
>
> On Tue, Feb 10, 2009 at 11:50 AM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
>>> >> Sure, we should try to make sure everything still works, but we also
>>> >> HAVE to make it easy to do so - That means among others that the
>>> >> various platforms should behave similary.
>>> >>
>>> Ulf> Each platform in u-boot behaves differently anyway.
>>> Ulf> You define the functionality of u-boot in the board header file.
>>>
>>> Sure, that's why the only sane default is to use the filenames the
>>> upstream projects use as that's what people expect.
>>>
>>> This doesn't mean that we shouldn't provide a setting (like the
>>> suffix/prefix thing) to use other names if people want that, but it
>>> shouldn't be default.
>>
>>
>> The default IS to use the filenames the upstream projects use.
>> You get that by selecting the standard build.
>> When you select an "advanced" configuration, you should
>> expect things to be a little different, don't you agree?
>
> First of all, that's not fair when you have said earlier that some
> platforms (namely avr32) are just unable to build with the "standard"
> option, and therefore, there is no choice.

You can build, but you do not get the latest patches.

> Second of all, I expect to have more choices in advanced, not less.
> Third of all, your At91 customers will have the exact same problem had
> they choosen the standard build because they also don't want the
> forced odd name.

That is an assumption you make.
I regularily discuss pro's and con's with buildroot with end customers.
There are a number of things brought up, but, so far, never the linux file 
name.
I can understand that you would like to have a filename which does not 
change.
"odd" is something relative, as I pointed out, *professional* companies
do NOT use simple names as "uImage" for embedded control.
The default for embedded linux distributions is a complex name
which includes architecture and linux version.
You are simply forced to do that, if you want to maintain
a large number of kernels.
The "simple" name is in this context insane.

The *key* requirement for newbies is to load a kernel/rootfs to the target
with minimum effort. The current "cleanups" to "sane" defaults is clearly
making life harder for newbies.

This category does NOT want to change a lot of options from (in)sane 
defaults.
They want (at the most) to do

$ make userconfig                ; setup user specific defaults.
$ make <board>_config       ; setup board
$ make                                 ; build board
$ make install                        ; program target with resulting files.

and then connect to the target with a terminal and see linux boot.
*I* want it to be easy, or they will phone me and ask for help,
which means I can handle less projects.

We are far from this point, but with the u-boot patches I can easily
support people over the phone without worrying about
having the odd environment variable misspelled or so.

---------------
Once they have passed a certain point and are confident with buildroot
then the requirements change.

The main complaint of buildroot is lack of stability.
People do not want to upgrade and retest just because someone feels
that this is a good idea, they want 100% control over when upgrades happen.
At the same time they would like to work in a project which is maintained.

With buildroot you are forced to continuosly upgrade or you lose support
and it is getting worse.

There is complaints that there is no support for proprietary functions.
If you want to add your company logo at boot, this is certainly
not something that should  be in the trunk, but still people
want this to be easy to include in the build.



>
>> There is a setting to generate the u-boot autoscript.
>> If you use that, you really want the stuff to be compatible
>> with the u-boot patches.
>> I am OK with using that to set the default filename to the previous
>> "complex" file name, and let the
>> normal #Image possibly with PREFIX/SUFFIX
>> be the default otherwise.
>>
>> The patches for U-boot are generic and coould be applied
>> for any architecture.
>>
>> The problem I am trying to solve is with newbies calling in wanting help
>> with the configuration of u-boot.
>> That can be done with a short email instead of 30-60
>> minutes conversation, with this fully working.
>>
>
> I found this on the patches:
> +       setenv("linux",
> MK_STR(BOARD_NAME)"-linux-"MK_STR(KERNEL_VERSION)"-"MK_STR(DATE)".gz");
>
> That was broken to begin with. >

Considering that ?ou only AFAIK want to  build uImage's for U-Boot,
this is a minor restriction.

> It has an hardcoded filename extension,
> while the previous "naming convention" allowed for other different
> extensions. The proper way of doing that would be:
>
> +       setenv("linux",         MK_STR(KERNEL_LINUX26_NAME));
>

No, because the whole idea of the patches is that you can modify the
different parts of the filename afterwards.

If the kernel name is:

at91sam9260ek-linux-2.6.28-20081001.gz

then
"setenv kernel_version 2.6.28.1 ; os"

will change the kernel name to

at91sam9260ek-linux-2.6.28.1-20081001.gz

Your patch will FIX the kernel name to whatever was the name at u-boot 
build.

> even without my changes! Only then it would be set to the kernel name,
> whatever it might be. After that just echo that make variable to the
> header where you previously defined the other macros.
> Now, if we change the patch like above, at least this part, would work
> even with standard build since I've made those variables have the same
> name in both standard and advanced build.

As you see from above - NO.

>
> While still on the subject, why haven't the patches been submitted
> upstream? Last time you said that the At91 had given up because u-boot
> devs were unavailable. Then, after that, avr32 team were able to get
> their patches upstream. Why haven't At91 tried again?

You can send a mail to the at91 team and ask.

>
> We probably wouldn't be having this conversation had patches been
> submited upstream, because they would not accept that and it would
> have been fixed then.
>
> I think I can edit the patch manually and have it build, but I can't
> download it to a target, unless you want to ship a board and
> programming tool to Brazil (with taxes to be collected from sender,
> otherwise I will just refuse the package).

I can test any binary, but if it looks like the one you send, then that is 
broken.

>
> Kind Regards,
>    Thiago A. Correa
>

[Buildroot] What's up with the kernel names? (Again)

[Ulf Samuelsson]

Subject: Re: [Buildroot] What's up with the kernel names? (Again)


> Hi,
>
> On Tue, Feb 10, 2009 at 11:50 AM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
>>> >> Sure, we should try to make sure everything still works, but we also
>>> >> HAVE to make it easy to do so - That means among others that the
>>> >> various platforms should behave similary.
>>> >>
>>> Ulf> Each platform in u-boot behaves differently anyway.
>>> Ulf> You define the functionality of u-boot in the board header file.
>>>
>>> Sure, that's why the only sane default is to use the filenames the
>>> upstream projects use as that's what people expect.
>>>
>>> This doesn't mean that we shouldn't provide a setting (like the
>>> suffix/prefix thing) to use other names if people want that, but it
>>> shouldn't be default.
>>
>>
>> The default IS to use the filenames the upstream projects use.
>> You get that by selecting the standard build.
>> When you select an "advanced" configuration, you should
>> expect things to be a little different, don't you agree?
>
> First of all, that's not fair when you have said earlier that some
> platforms (namely avr32) are just unable to build with the "standard"
> option, and therefore, there is no choice.

You can build, but you do not get the latest patches.

> Second of all, I expect to have more choices in advanced, not less.
> Third of all, your At91 customers will have the exact same problem had
> they choosen the standard build because they also don't want the
> forced odd name.

That is an assumption you make.
I regularily discuss pro's and con's with buildroot with end customers.
There are a number of things brought up, but, so far, never the linux file 
name.
I can understand that you would like to have a filename which does not 
change.
"odd" is something relative, as I pointed out, *professional* companies
do NOT use simple names as "uImage" for embedded control.
The default for embedded linux distributions is a complex name
which includes architecture and linux version.
You are simply forced to do that, if you want to maintain
a large number of kernels.
The "simple" name is in this context insane.
And again, it would be easy to add an option for a choice.
You happen to give no choice for people which do not
want to have uImage as part of the name.
uImage is a name for the initiated, not for the newbie
who expect to have a "linux".

The *key* requirement for newbies is to load a kernel/rootfs to the target
with minimum effort. The current "cleanups" to "sane" defaults is clearly
making life harder for newbies.

This category does NOT want to change a lot of options from (in)sane 
defaults.
They want (at the most) to do

$ make userconfig                ; setup user specific defaults.
$ make <board>_config       ; setup board
$ make                                 ; build board
$ make install                        ; program target with resulting files.

and then connect to the target with a terminal and see linux boot.
*I* want it to be easy, or they will phone me and ask for help,
which means I can handle less projects.

We are far from this point, but with the u-boot patches I can easily
support people over the phone without worrying about
having the odd environment variable misspelled or so.

---------------
Once they have passed a certain point and are confident with buildroot
then the requirements change.

The main complaint of buildroot is lack of stability.
People do not want to upgrade and retest just because someone feels
that this is a good idea, they want 100% control over when upgrades happen.
At the same time they would like to work in a project which is maintained.

With buildroot you are forced to continuosly upgrade or you lose support
and it is getting worse.

There is complaints that there is no support for proprietary functions.
If you want to add your company logo at boot, this is certainly
not something that should  be in the trunk, but still people
want this to be easy to include in the build.



>
>> There is a setting to generate the u-boot autoscript.
>> If you use that, you really want the stuff to be compatible
>> with the u-boot patches.
>> I am OK with using that to set the default filename to the previous
>> "complex" file name, and let the
>> normal #Image possibly with PREFIX/SUFFIX
>> be the default otherwise.
>>
>> The patches for U-boot are generic and coould be applied
>> for any architecture.
>>
>> The problem I am trying to solve is with newbies calling in wanting help
>> with the configuration of u-boot.
>> That can be done with a short email instead of 30-60
>> minutes conversation, with this fully working.
>>
>
> I found this on the patches:
> +       setenv("linux",
> MK_STR(BOARD_NAME)"-linux-"MK_STR(KERNEL_VERSION)"-"MK_STR(DATE)".gz");
>
> That was broken to begin with. >

Considering that ?ou only AFAIK want to  build uImage's for U-Boot,
this is a minor restriction.

> It has an hardcoded filename extension,
> while the previous "naming convention" allowed for other different
> extensions. The proper way of doing that would be:
>
> +       setenv("linux",         MK_STR(KERNEL_LINUX26_NAME));
>

No, because the whole idea of the patches is that you can modify the
different parts of the filename afterwards.

If the kernel name is:

at91sam9260ek-linux-2.6.28-20081001.gz

then
"setenv kernel_version 2.6.28.1 ; os"

will change the kernel name to

at91sam9260ek-linux-2.6.28.1-20081001.gz

Your patch will FIX the kernel name to whatever was the name at u-boot 
build.

> even without my changes! Only then it would be set to the kernel name,
> whatever it might be. After that just echo that make variable to the
> header where you previously defined the other macros.
> Now, if we change the patch like above, at least this part, would work
> even with standard build since I've made those variables have the same
> name in both standard and advanced build.

As you see from above - NO.

>
> While still on the subject, why haven't the patches been submitted
> upstream? Last time you said that the At91 had given up because u-boot
> devs were unavailable. Then, after that, avr32 team were able to get
> their patches upstream. Why haven't At91 tried again?

You can send a mail to the at91 team and ask.

>
> We probably wouldn't be having this conversation had patches been
> submited upstream, because they would not accept that and it would
> have been fixed then.
>
> I think I can edit the patch manually and have it build, but I can't
> download it to a target, unless you want to ship a board and
> programming tool to Brazil (with taxes to be collected from sender,
> otherwise I will just refuse the package).

I can test any binary, but if it looks like the one you send, then that is 
broken.

>
> Kind Regards,
>    Thiago A. Correa
>

[Buildroot] What's up with the kernel names? (Again)

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Second of all, I expect to have more choices in advanced, not less.
 >> Third of all, your At91 customers will have the exact same problem had
 >> they choosen the standard build because they also don't want the
 >> forced odd name.

 Ulf> That is an assumption you make.

Which is probably fairly easy to make given the 'advanced' in the
name. Are you saying it shoule be Makefile.ulf instead? ;)

 Ulf> I regularily discuss pro's and con's with buildroot with end customers.

Atmel customers are not necessarily a representative group for
buildroot users.

 Ulf> There are a number of things brought up, but, so far, never the linux
 Ulf> file name.
 Ulf> I can understand that you would like to have a filename which does not
 Ulf> change.
 Ulf> "odd" is something relative, as I pointed out, *professional* companies
 Ulf> do NOT use simple names as "uImage" for embedded control.

So mainline Linux / U-Boot / whatever isn't *professional*?

 Ulf> The "simple" name is in this context insane.
 Ulf> And again, it would be easy to add an option for a choice.

Which is what Thiago's commit added.

 Ulf> You happen to give no choice for people which do not
 Ulf> want to have uImage as part of the name.
 Ulf> uImage is a name for the initiated, not for the newbie
 Ulf> who expect to have a "linux".

Then add linux to _PREFIX for those configs. The previous linux-*.gz
doesn't tell me anything about the format, and in fact it was extra
confusing with that .gz even though it isn't a gzip file.

 Ulf> The *key* requirement for newbies is to load a kernel/rootfs to
 Ulf> the target with minimum effort. The current "cleanups" to "sane"
 Ulf> defaults is clearly making life harder for newbies.

That I don't follow. A constant name by default should if nothing else
make it simpler.

 Ulf> They want (at the most) to do

 Ulf> $ make userconfig                ; setup user specific defaults.
 Ulf> $ make <board>_config       ; setup board
 Ulf> $ make                                 ; build board
 Ulf> $ make install                        ; program target with resulting files.

And where is that broken with Thiago's commit?

 Ulf> The main complaint of buildroot is lack of stability.  People do
 Ulf> not want to upgrade and retest just because someone feels that
 Ulf> this is a good idea, they want 100% control over when upgrades
 Ulf> happen.  At the same time they would like to work in a project
 Ulf> which is maintained.

Maintained, uptodate and stability is hard to combine, but you are
welcome to maintain a stable tree based of the buildroot releases if
you want to.

 Ulf> With buildroot you are forced to continuosly upgrade or you lose
 Ulf> support and it is getting worse.

Worse? Just because people haven't been idling the last few weeks like
they used to do? If that's what you want, just stick to a release.

 Ulf> There is complaints that there is no support for proprietary
 Ulf> functions.

functions?

 Ulf> If you want to add your company logo at boot, this is certainly
 Ulf> not something that should  be in the trunk, but still people
 Ulf> want this to be easy to include in the build.

I don't see any problems with having some kind of bootsplash package
in BR. U-Boot afaik also has some bmp support, so I don't see the
problem.

 >> That was broken to begin with. >

 Ulf> Considering that ?ou only AFAIK want to  build uImage's for U-Boot,
 Ulf> this is a minor restriction.

Doesn't make it any less broken, especially now that we have the
prefix/suffix stuff.

 >> While still on the subject, why haven't the patches been submitted
 >> upstream? Last time you said that the At91 had given up because u-boot
 >> devs were unavailable. Then, after that, avr32 team were able to get
 >> their patches upstream. Why haven't At91 tried again?

 Ulf> You can send a mail to the at91 team and ask.

Ulf, that's not constructive - Please behave.

-- 
Bye, Peter Korsgaard