[U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Paul Burton]

On 04/08/16 11:00, Michal Simek wrote:
> On 1.8.2016 14:51, Paul Burton wrote:
>> On 01/08/16 13:41, Michal Simek wrote:
>>> On 1.8.2016 14:09, Paul Burton wrote:
>>>> On 01/08/16 11:46, Michal Simek wrote:
>>>>> On 1.8.2016 12:06, Paul Burton wrote:
>>>>>> This series introduces initial support for the MIPS Boston, and FPGA
>>>>>> based development board & successor to the older Malta board. Further
>>>>>> peripheral work is needed but this introduces the basics.
>>>>>>
>>>>>> This can be tested in a currently out-of-tree QEMU port if desired,
>>>>>> which can be found in the boston branch of:
>>>>>>
>>>>>>   git://git.linux-mips.org/pub/scm/paul/qemu.git
>>>>>>
>>>>>> QEMU can be used to run U-Boot like this:
>>>>>>
>>>>>>   ./configure --target-list=mips64el-softmmu
>>>>>>   make
>>>>>>   ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
>>>>>>     -bios u-boot.bin -serial stdio
>>>>>
>>>>> I have tried it and nothing is coming up.
>>>>>
>>>>> Latest u-boot + your patches
>>>>> make boston64r2el_defconfig
>>>>>
>>>>> and your qemu on ubuntu 14.
>>>>>
>>>>> Can you recheck it?
>>>>>
>>>>> Thanks,
>>>>> Michal
>>>>
>>>> Hi Michal,
>>>>
>>>> This would be because U-Boot is being built for MIPS64r2 whilst QEMU is
>>>> emulating the MIPS64r6-implementing I6400, and MIPSr6 isn't entirely
>>>> backwards compatible with MIPSr2. If you reconfigure U-Boot to build for
>>>> MIPS64r6 then you should find that it runs correctly. I'll add mention
>>>> of that to the README file.
>>>
>>> sorry don't have any overview about mips at all.
>>> But last patch is adding 4 defconfigs 32r2 and 64r2 (big and little)
>>> endian.
>>>
>>> I do use
>>> .buildman-toolchains/gcc-4.9.0-nolibc/mips-linux/bin//mips-linux-gcc
>>>
>>> And getting this when I change it to mips64r6
>>> mips-linux-gcc: error: unrecognized argument in option '-march=mips64r6'
>>
>> Hi Michal,
>>
>> Ah, and that's why the defconfigs were changed to MIPSr2 in v3 of the
>> patchset. The Boston board can technically use CPUs implementing any
>> architecture revision, but is most commonly used with ones implementing
>> MIPSr6 hence the QEMU default. If it weren't for that buildman failure
>> with MIPSr6 it'd be the Boston defconfig default too.
>>
>>> Are there any toolchain at generic location which buildman can use?
>>
>> The toolchain I use is the codescape one available from imgtec.com:
>>
>>     http://codescape-mips-sdk.imgtec.com/components/toolchain/2015.06-05/
>>
>> The "IMG GNU Linux Toolchain" from that page will suffice. Anything with
>> gcc 5.x or newer should work too if you wanted to use crosstool-ng,
>> buildroot or similar to produce a toolchain.
>
> Ok. That toolchain work and qemu too.
>
> There is this compilation warning.
>
>   CC      common/autoboot.o
>   CC      common/board_f.o
>   CC      common/board_r.o
> common/autoboot.c: In function ‘process_fdt_options’:
> common/autoboot.c:281:27: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>    setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
>                            ^
> common/autoboot.c:286:27: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>    setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
>                            ^
> In file included from ././include/linux/kconfig.h:4:0,
>                  from <command-line>:0:
> common/board_f.c: In function ‘display_text_info’:
> include/generated/autoconf.h:94:30: warning: large integer implicitly
> truncated to unsigned type [-Woverflow]
>  #define CONFIG_SYS_TEXT_BASE 0xffffffff9fc00000
>                               ^
> common/board_f.c:158:14: note: in expansion of macro ‘CONFIG_SYS_TEXT_BASE’
>   text_base = CONFIG_SYS_TEXT_BASE;
>               ^

Hi Michal,

Interesting, I haven't been seeing this. Did you build for 32 bit by any 
chance? If so then I think you've somehow ended up with the 
CONFIG_SYS_TEXT_BASE appropriate for a 64 bit build. I'll doublecheck 
the defconfigs.

>   CC      cmd/itest.o
>   CC      cmd/load.o
>   CC      cmd/mem.o
>   LD      drivers/dfu/built-in.o
>   CC      common/board_info.o
>   LD      drivers/hwmon/built-in.o
>   CC      drivers/input/input.o
>   CC      common/bootm.o
>
>
> I personally prefer if you can integrate this to buildman and maybe you
> can use qemu defconfig. Description in Readme would be also helpful that
> everybody understands what to do.
>
> Toolchain at kernel.org which support this will be useful too.

I added a section to README.boston describing the situation with 
architecture revisions & toolchains in v5. Daniel mentioned he was going 
to look at supporting a newer toolchain in buildman.

Thanks,
     Paul