[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 at 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