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

Michal Simek michal.simek at xilinx.com
Thu Aug 4 12:00:06 CEST 2016


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;
              ^
  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.

Thanks,
Michal




More information about the U-Boot mailing list