[U-Boot] Build problem with crownbay

[Bin Meng]

Hi Simon,

On Mon, Dec 15, 2014 at 12:27 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin.
>
> On 14 December 2014 at 20:01, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Dec 15, 2014 at 8:23 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 14 December 2014 at 08:44, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 14 December 2014 at 08:09, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Dec 14, 2014 at 1:35 PM, Simon Glass <sjg at chromium.org> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> I see the following problem when trying to build crownbay:
>>>>>>
>>>>>> ./tools/buildman/buildman crownbay -se
>>>>>> boards.cfg is up to date. Nothing to do.
>>>>>> Summary of current source for 1 boards (1 thread, 32 jobs per thread)
>>>>>>        x86: +   crownbay
>>>>>> +{standard input}: Assembler messages:
>>>>>> +{standard input}:136: Error: can't open M0220661105.inc for reading:
>>>>>> No such file or directory
>>>>>> +make[3]: *** [arch/x86/cpu/queensbay/tnc_car.o] Error 1
>>>>>> +make[2]: *** [arch/x86/cpu/queensbay] Error 2
>>>>>> +make[1]: *** [arch/x86/cpu] Error 2
>>>>>> +make: *** [sub-make] Error 2
>>>>>>
>>>>>> Can you please take a look?
>>>>>>
>>>>>> I have pushed the test code to u-boot-x86/testing.
>>>>>
>>>>> I am not familiar with the buildman. I switched to the
>>>>> u-boot-x86/testing branch and did the same command as you:
>>>>>
>>>>> $ ./tools/buildman/buildman crownbay -se
>>>>> WARNING: no status info for 'beagle_x15'
>>>>> WARNING: no maintainers for 'beagle_x15'
>>>>> WARNING: no status info for 'stv0991'
>>>>> WARNING: no maintainers for 'stv0991'
>>>>> WARNING: no status info for 'socfpga_socrates'
>>>>> WARNING: no maintainers for 'socfpga_socrates'
>>>>> Summary of current source for 1 boards (1 thread, 24 jobs per thread)
>>>>> (no errors to report)
>>>>
>>>> In order to build (rather than summarise results) take off the -se.
>>>>
>>>>>
>>>>> My ~/.buildman is as follows:
>>>>>
>>>>> $ cat ~/.buildman
>>>>> [toolchain]
>>>>> root: /
>>>>>
>>>>> [toolchain-alias]
>>>>> x86: i386
>>>>>
>>>>> [make-flags]
>>>>>
>>>>> I did a u-boot.rom build for crownbay from the u-boot root directory
>>>>> and it builds fine.
>>>>>
>>>>> Based on the error message you gave, it looks like buildman is trying
>>>>> to cd into the 'arch/x86/cpu/queensbay/' directory and build it from
>>>>> there? What exact command build is using? The error message is related
>>>>> to tnc_car.S line#126
>>>>>
>>>>> 125 ucode_start:
>>>>> 126         .include "arch/x86/cpu/queensbay/M0220661105.inc"
>>>>> 127 ucode_size = ( . - ucode_start)
>>>>>
>>>>> So if the build is started from 'arch/x86/cpu/queensbay directory',
>>>>> the build will fail. But if started from u-boot root directory, there
>>>>> will be no problem.
>>>>
>>>> Well buildman just uses the normal build system. If you need to
>>>> include files then they will have to go either in the same directory
>>>> or in the include/asm/arch directory.
>>>>
>>>> Are you using a cross-compiler? Are you using an in-tree build? How do
>>>> you build it>
>>>>
>>>> I'm going to apply what I can from this series but we need to figure
>>>> this one out.
>>>
>>> I had a bit of a look. The root cause is having to include an assembly
>>> language include in a format I'm not really that keen on anyway. So I
>>> have sent a series that should avoid needing that. Please take a look.
>>
>> Yes, I will have a look.
>
> I found an endianness problem as I mentioned on the other patch. But
> I'm hoping you can get it to work without too much trouble.

Yep, I noticed that. Is the endianness fix applied on the
u-boot-x86/testing branch? Right now I just did a build of the
crownbay from the testing branch, but unfortunately the generated
u-boot.rom does not boot on Crown Bay. I am trying to figure out why.

> I'd quite like to apply the patches that we currently have. The build
> error currently prevents me going about halfway, but I suppose if we
> can figure out how to avoid the microcode assembler include, we may be
> able to fiddle the patch order and apply things that way.

I think with your ifdtool patch series the issue of the microcode
assembler include goes away, so we should be fine.

Regards,
Bin