Re: MIPS test results

Re: MIPS test results

[Kevin Hilman]

[ switching to the kernelci mailing list ]

Paul Burton <paul.burton@mips.com> writes:

[...]

>> In fact, while we're doing builds for MIPS, none of us are that familiar
>> with it, so we still had some basic questions on how to boot the
>> hardware, and which kernel images we should be using to boot the boards.
>
> I'm happy to help with that :)
>
>> For example, we're building all the upstream defconfigs for MIPS, and
>> you can see those here:
>> https://storage.kernelci.org/mainline/master/v4.20-rc4-98-g60b548237fed/mips/
>> 
>> Our build scripts are currently setup to save/upload the vmlinux.bin.z
>> file from the build, but we noticed that only some of the defconfigs
>> genrate the .z images.  e.g. nlm_xlp_defconfig genreates the .z, whereas
>> ath25_defconfig does not.
>> 
>> It looks like all the kernel builds generate a vmlinux.bin
>> (uncompressed) though, but until we have hardware that is using those
>> images, we decided not to upload the uncompressed images due to storage
>> space.
>> 
>> Once we have a better idea of how to actually boot the hardware we have,
>> with which kernel images, it might help us figure out what kernel images
>> we should be saving and uploading so any labs with MIPS hardware could
>> use them.
>
> One niggle we'll have is the plethora of boot options that various MIPS
> boards make use of... Gradually we're pushing towards a standard boot
> protocol & a single kernel image (in U-Boot's FIT/.itb format) but we're
> starting from a place very far away from that.
>
> If you could let me know which boards you have I can probably help you
> boot them - I was involved in all the MIPS boards Imagination produced &
> am familiar with a bunch of our customer's boards.

The board we have is a MIPS Creator C120, so let's start with what we
need to get that one working.

Kevin

Re: MIPS test results

[Paul Burton]

Hi Kevin,

On Mon, Dec 03, 2018 at 09:36:01AM -0800, Kevin Hilman wrote:
> >> Our build scripts are currently setup to save/upload the vmlinux.bin.z
> >> file from the build, but we noticed that only some of the defconfigs
> >> genrate the .z images.  e.g. nlm_xlp_defconfig genreates the .z, whereas
> >> ath25_defconfig does not.
> >> 
> >> It looks like all the kernel builds generate a vmlinux.bin
> >> (uncompressed) though, but until we have hardware that is using those
> >> images, we decided not to upload the uncompressed images due to storage
> >> space.
> >> 
> >> Once we have a better idea of how to actually boot the hardware we have,
> >> with which kernel images, it might help us figure out what kernel images
> >> we should be saving and uploading so any labs with MIPS hardware could
> >> use them.
> >
> > One niggle we'll have is the plethora of boot options that various MIPS
> > boards make use of... Gradually we're pushing towards a standard boot
> > protocol & a single kernel image (in U-Boot's FIT/.itb format) but we're
> > starting from a place very far away from that.
> >
> > If you could let me know which boards you have I can probably help you
> > boot them - I was involved in all the MIPS boards Imagination produced &
> > am familiar with a bunch of our customer's boards.
> 
> The board we have is a MIPS Creator C120, so let's start with what we
> need to get that one working.

Apologies for the slow response - busy week..!

For the Ci20 there are 2 main options:

  1) Use a U-Boot uImage.

     The Ci20 ships with the U-Boot bootloader by default, and expects
     to load kernels packages in the legacy U-Boot uImage format. When
     you build the kernel, if you have the U-Boot mkimage tool in your
     $PATH, you should get a arch/mips/boot/uImage.gz file. You then
     load this into DDR using U-Boot, for example using the tftp
     command, and run the bootm command to boot the kernel.

     Of note is that Ezequiel Garcia, CC'd, is currently working on
     upstreaming Ci20 support in U-Boot.

  2) Use my ci20-usb-boot tool [1].

     Alternatively you could use my ci20-usb-boot tool to bypass U-Boot
     entirely. It boots a kernel ELF (ie. either vmlinux or vmlinuz) on
     a Ci20 connected to a host machine via USB. This relies upon the
     board/SoC powering up in USB boot mode, and how to do that depends
     on the revision of the board. The later ones should show the
     correct jumper settings on the PCB silkscreen though. I find the
     easiest way to do this is to configure the board to boot from SD
     card but have no SD card present, which causes the boot ROM to fall
     back to USB boot mode.

     Once you can see the USB device on the host (ID a108:4780) and have
     read/write permissions for it in /dev, it should be as easy as:

     $ ci20-usb-boot vmlinux

     The tool has a --serial option to select between boards if you have
     more than one connected to a host, and it can optionally wait for
     the board to appear if you have a race condition between powering
     it on & running the tool.

     One limitation of this method is that it doesn't currently allow
     you to specify a kernel command line, though that shouldn't be
     difficult to implement.

Thanks,
    Paul

[1] https://github.com/paulburton/ci20-tools

Re: MIPS test results

[Kevin Hilman]

Paul Burton <paul.burton@mips.com> writes:

[...]

> For the Ci20 there are 2 main options:
>
>   1) Use a U-Boot uImage.
>
>      The Ci20 ships with the U-Boot bootloader by default, and expects
>      to load kernels packages in the legacy U-Boot uImage format. When
>      you build the kernel, if you have the U-Boot mkimage tool in your
>      $PATH, you should get a arch/mips/boot/uImage.gz file. You then
>      load this into DDR using U-Boot, for example using the tftp
>      command, and run the bootm command to boot the kernel.
>
>      Of note is that Ezequiel Garcia, CC'd, is currently working on
>      upstreaming Ci20 support in U-Boot.

u-boot is the preferred option, and I just tried it on my Ci20, but it
seems the u-boot on this board doesn't find the network, so I can't
DHCP/TFTP (log below[1]).

If I just let the kernel boot that is flashed on the board, it boots up
an OpenWRT image and is able to DHCP and get an IP address, so I know
the network interface is working.

Maybe Ezequiel has a newer version of u-boot with working network
support I could try?  If so, please also send instructions for how to
(re)flash u-boot, (or maybe boot a new u-boot from the SD card?)

Kevin

[1]
U-Boot SPL 2015.07-rc2 (Jul 14 2016 - 12:16:30)


U-Boot 2015.07-rc2 (Jul 14 2016 - 12:16:30 +0000)

MIPS(interAptiv): IMG Pistachio 546MHz.
Model: IMG Marduk
DRAM:  256 MiB
NAND:  512 MiB
MMC:   Synopsys Mobile storage: 0
SF: Detected W25Q16CL with page size 256 Bytes, erase size 4 KiB, total 2 MiB
*** Warning - bad CRC, using default environment

In:    uart@18101500
Out:   uart@18101500
Err:   uart@18101500
Net:   No valid Mac-addr found from dtb

Error: ethernet@18140000 address not set.
No ethernet found.
Hit any key to stop autoboot:  0 
pistachio # dhcp
mdio_register: non unique device name 'ethernet@18140000'
ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000

Error: ethernet@18140000 address not set.
mdio_register: non unique device name 'ethernet@18140000'
ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000

Error: ethernet@18140000 address not set.
mdio_register: non unique device name 'ethernet@18140000'
ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000

Error: ethernet@18140000 address not set.
mdio_register: non unique device name 'ethernet@18140000'
ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000

Error: ethernet@18140000 address not set.
No ethernet found.
mdio_register: non unique device name 'ethernet@18140000'
ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000

Error: ethernet@18140000 address not set.
pistachio # 

Re: MIPS test results

[Ezequiel Garcia]

On Thursday, December 13, 2018 21:51 -03, Kevin Hilman <khilman@baylibre.com> wrote:

> Paul Burton <paul.burton@mips.com> writes:
>
> [...]
>
> > For the Ci20 there are 2 main options:
> >
> >   1) Use a U-Boot uImage.
> >
> >      The Ci20 ships with the U-Boot bootloader by default, and expects
> >      to load kernels packages in the legacy U-Boot uImage format. When
> >      you build the kernel, if you have the U-Boot mkimage tool in your
> >      $PATH, you should get a arch/mips/boot/uImage.gz file. You then
> >      load this into DDR using U-Boot, for example using the tftp
> >      command, and run the bootm command to boot the kernel.
> >
> >      Of note is that Ezequiel Garcia, CC'd, is currently working on
> >      upstreaming Ci20 support in U-Boot.
>
> u-boot is the preferred option, and I just tried it on my Ci20, but it
> seems the u-boot on this board doesn't find the network, so I can't
> DHCP/TFTP (log below[1]).
>
> If I just let the kernel boot that is flashed on the board, it boots up
> an OpenWRT image and is able to DHCP and get an IP address, so I know
> the network interface is working.
>
> Maybe Ezequiel has a newer version of u-boot with working network
> support I could try?  If so, please also send instructions for how to
> (re)flash u-boot, (or maybe boot a new u-boot from the SD card?)
>

Hey Kevin,

Yes, I have. I will push a branch for you and let you know,
so you can test with some recent U-Boot.

However... this log you have here is not from the CI20 board,
which is JZ4780 SoC, but from some development board
with a Pistachio SoC!

I thought those were dead, but it seems there are
some Pistachio boards around ?


Ezequiel

> Kevin
>
> [1]
> U-Boot SPL 2015.07-rc2 (Jul 14 2016 - 12:16:30)
>
>
> U-Boot 2015.07-rc2 (Jul 14 2016 - 12:16:30 +0000)
>
> MIPS(interAptiv): IMG Pistachio 546MHz.
> Model: IMG Marduk
> DRAM:  256 MiB
> NAND:  512 MiB
> MMC:   Synopsys Mobile storage: 0
> SF: Detected W25Q16CL with page size 256 Bytes, erase size 4 KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> In:    uart@18101500
> Out:   uart@18101500
> Err:   uart@18101500
> Net:   No valid Mac-addr found from dtb
>
> Error: ethernet@18140000 address not set.
> No ethernet found.
> Hit any key to stop autoboot:  0
> pistachio # dhcp
> mdio_register: non unique device name 'ethernet@18140000'
> ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000
>
> Error: ethernet@18140000 address not set.
> mdio_register: non unique device name 'ethernet@18140000'
> ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000
>
> Error: ethernet@18140000 address not set.
> mdio_register: non unique device name 'ethernet@18140000'
> ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000
>
> Error: ethernet@18140000 address not set.
> mdio_register: non unique device name 'ethernet@18140000'
> ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000
>
> Error: ethernet@18140000 address not set.
> No ethernet found.
> mdio_register: non unique device name 'ethernet@18140000'
> ethernet@18140000:0 is connected to ethernet@18140000.  Reconnecting to ethernet@18140000
>
> Error: ethernet@18140000 address not set.
> pistachio #

Re: MIPS test results

[Kevin Hilman]

"Ezequiel Garcia" <ezequiel.garcia@collabora.com> writes:

> On Thursday, December 13, 2018 21:51 -03, Kevin Hilman <khilman@baylibre.com> wrote: 
>  
>> Paul Burton <paul.burton@mips.com> writes:
>> 
>> [...]
>> 
>> > For the Ci20 there are 2 main options:
>> >
>> >   1) Use a U-Boot uImage.
>> >
>> >      The Ci20 ships with the U-Boot bootloader by default, and expects
>> >      to load kernels packages in the legacy U-Boot uImage format. When
>> >      you build the kernel, if you have the U-Boot mkimage tool in your
>> >      $PATH, you should get a arch/mips/boot/uImage.gz file. You then
>> >      load this into DDR using U-Boot, for example using the tftp
>> >      command, and run the bootm command to boot the kernel.
>> >
>> >      Of note is that Ezequiel Garcia, CC'd, is currently working on
>> >      upstreaming Ci20 support in U-Boot.
>> 
>> u-boot is the preferred option, and I just tried it on my Ci20, but it
>> seems the u-boot on this board doesn't find the network, so I can't
>> DHCP/TFTP (log below[1]).
>> 
>> If I just let the kernel boot that is flashed on the board, it boots up
>> an OpenWRT image and is able to DHCP and get an IP address, so I know
>> the network interface is working.
>> 
>> Maybe Ezequiel has a newer version of u-boot with working network
>> support I could try?  If so, please also send instructions for how to
>> (re)flash u-boot, (or maybe boot a new u-boot from the SD card?)
>> 
>
> Yes, I have. I will push a branch for you and let you know,
> so you can test with some recent U-Boot.

Cool, thanks.

> However... this log you have here is not from the CI20 board,
> which is JZ4780 SoC, but from some development board
> with a Pistachio SoC!

The board I have is labeled Creator Ci40, and grep'ing in the MIPS DT
files, led me to pistachio_marduk.dts.

> I thought those were dead, but it seems there are some Pistachio
> boards around ?

This was given to me by Imagination a couple years ago, but I never had
the time to get it into kernelCI, and then the interest from Imagination
"went away." ;)

If nobody cares about this particular board, I don't really want to
waste any time on it either.  But, if there are other boards that people
actually care about we should integrate into kernelCI, and that someone
wants to donate, I'd prefer to setup those.

Kevin

Re: MIPS test results

[Ezequiel Garcia]

On Fri, 2018-12-14 at 09:03 -0800, Kevin Hilman wrote:
> "Ezequiel Garcia" <ezequiel.garcia@collabora.com> writes:
> 
> > On Thursday, December 13, 2018 21:51 -03, Kevin Hilman <khilman@baylibre.com> wrote: 
> >  
> > > Paul Burton <paul.burton@mips.com> writes:
> > > 
> > > [...]
> > > 
> > > > For the Ci20 there are 2 main options:
> > > > 
> > > >   1) Use a U-Boot uImage.
> > > > 
> > > >      The Ci20 ships with the U-Boot bootloader by default, and expects
> > > >      to load kernels packages in the legacy U-Boot uImage format. When
> > > >      you build the kernel, if you have the U-Boot mkimage tool in your
> > > >      $PATH, you should get a arch/mips/boot/uImage.gz file. You then
> > > >      load this into DDR using U-Boot, for example using the tftp
> > > >      command, and run the bootm command to boot the kernel.
> > > > 
> > > >      Of note is that Ezequiel Garcia, CC'd, is currently working on
> > > >      upstreaming Ci20 support in U-Boot.
> > > 
> > > u-boot is the preferred option, and I just tried it on my Ci20, but it
> > > seems the u-boot on this board doesn't find the network, so I can't
> > > DHCP/TFTP (log below[1]).
> > > 
> > > If I just let the kernel boot that is flashed on the board, it boots up
> > > an OpenWRT image and is able to DHCP and get an IP address, so I know
> > > the network interface is working.
> > > 
> > > Maybe Ezequiel has a newer version of u-boot with working network
> > > support I could try?  If so, please also send instructions for how to
> > > (re)flash u-boot, (or maybe boot a new u-boot from the SD card?)
> > > 
> > 
> > Yes, I have. I will push a branch for you and let you know,
> > so you can test with some recent U-Boot.
> 
> Cool, thanks.
> 
> > However... this log you have here is not from the CI20 board,
> > which is JZ4780 SoC, but from some development board
> > with a Pistachio SoC!
> 
> The board I have is labeled Creator Ci40, and grep'ing in the MIPS DT
> files, led me to pistachio_marduk.dts.
> 

I'm only working on CI20, which AFAIK is a completely different SoC.

> > I thought those were dead, but it seems there are some Pistachio
> > boards around ?
> 
> This was given to me by Imagination a couple years ago, but I never had
> the time to get it into kernelCI, and then the interest from Imagination
> "went away." ;)
> If nobody cares about this particular board, I don't really want to
> waste any time on it either.  But, if there are other boards that people
> actually care about we should integrate into kernelCI, and that someone
> wants to donate, I'd prefer to setup those.
> 

Hm, I don't know how interesting CI40 is. I'm under the impression CI20
is more widespread, and was more distributed, but Paul should know
better than me about this.

Regards,
Eze

Re: MIPS test results

[Paul Burton]

Hi Kevin,

On Fri, Dec 14, 2018 at 09:03:43AM -0800, Kevin Hilman wrote:
> > However... this log you have here is not from the CI20 board,
> > which is JZ4780 SoC, but from some development board
> > with a Pistachio SoC!
> 
> The board I have is labeled Creator Ci40, and grep'ing in the MIPS DT
> files, led me to pistachio_marduk.dts.

Right - pistachio is the codename for the cXT200 SoC, and marduk is the
codename for the Ci40 board.

> > I thought those were dead, but it seems there are some Pistachio
> > boards around ?
> 
> This was given to me by Imagination a couple years ago, but I never had
> the time to get it into kernelCI, and then the interest from Imagination
> "went away." ;)
> 
> If nobody cares about this particular board, I don't really want to
> waste any time on it either.  But, if there are other boards that people
> actually care about we should integrate into kernelCI, and that someone
> wants to donate, I'd prefer to setup those.

I don't especially care about the Ci40 board per se, but I do care about
the interAptiv CPU it uses & which still has active customers. So far as
I'm aware the Ci40 is the only dev board available to the public
containing interAptiv cores, so that leaves me caring about tests on
Ci40 :)

In terms of updating its U-Boot, I notice the creatordev.io site that
documented it is no longer online... But its source is available here:

  https://github.com/CreatorDev/u-boot

You can build it yourself as README.md describes, or I've placed a
prebuilt binary here:

  https://0x83.org/tmp/u-boot-pistachio_marduk-2015.10-v1.0.5-00001-gc1b568e7ea-dirty.img

It says -dirty in the filename but I believe this is just because the
.gitignore rules don't ignore some of the files generated by the
build... I promise I didn't sneak anything malicious in here :)

For reference I built it using the Codescape 2018.09-02 toolchain from
here:

  https://codescape.mips.com/components/toolchain/2018.09-02/downloads.html

To flash the new U-Boot image on the board, we'll need to load it into
RAM using the existing U-Boot. Since ethernet isn't working for you one
option would be to use a micro SD card & U-Boot's fatload or ext4load
commands.

Then say you loaded the new U-Boot image at 0xe000000 the following
shows an example of writing it into flash:

pistachio # sf probe
SF: Detected W25Q16CL with page size 256 Bytes, erase size 4 KiB, total 2 MiB
pistachio # sf erase 0 180000
SF: 1572864 bytes @ 0x0 Erased: OK
pistachio # sf write e000000 0 180000
device 0 offset 0x0, size 0x180000
SF: 1572864 bytes @ 0x0 Written: OK

Presuming that goes well, reset the board & check the U-Boot version &
build date - it should be the new build.

If you're interested in getting a Ci20 I'll see what I can do - I'm sure
we must have some spares in the office :)

Thanks,
    Paul

Re: MIPS test results

[Kevin Hilman]

Paul Burton <paul.burton@mips.com> writes:

> Hi Kevin,
>
> On Fri, Dec 14, 2018 at 09:03:43AM -0800, Kevin Hilman wrote:
>> > However... this log you have here is not from the CI20 board,
>> > which is JZ4780 SoC, but from some development board
>> > with a Pistachio SoC!
>> 
>> The board I have is labeled Creator Ci40, and grep'ing in the MIPS DT
>> files, led me to pistachio_marduk.dts.
>
> Right - pistachio is the codename for the cXT200 SoC, and marduk is the
> codename for the Ci40 board.
>
>> > I thought those were dead, but it seems there are some Pistachio
>> > boards around ?
>> 
>> This was given to me by Imagination a couple years ago, but I never had
>> the time to get it into kernelCI, and then the interest from Imagination
>> "went away." ;)
>> 
>> If nobody cares about this particular board, I don't really want to
>> waste any time on it either.  But, if there are other boards that people
>> actually care about we should integrate into kernelCI, and that someone
>> wants to donate, I'd prefer to setup those.
>
> I don't especially care about the Ci40 board per se, but I do care about
> the interAptiv CPU it uses & which still has active customers. So far as
> I'm aware the Ci40 is the only dev board available to the public
> containing interAptiv cores, so that leaves me caring about tests on
> Ci40 :)
>
> In terms of updating its U-Boot, I notice the creatordev.io site that
> documented it is no longer online... But its source is available here:
>
>   https://github.com/CreatorDev/u-boot
>
> You can build it yourself as README.md describes, or I've placed a
> prebuilt binary here:
>
>   https://0x83.org/tmp/u-boot-pistachio_marduk-2015.10-v1.0.5-00001-gc1b568e7ea-dirty.img
>
> It says -dirty in the filename but I believe this is just because the
> .gitignore rules don't ignore some of the files generated by the
> build... I promise I didn't sneak anything malicious in here :)
>
> For reference I built it using the Codescape 2018.09-02 toolchain from
> here:
>
>   https://codescape.mips.com/components/toolchain/2018.09-02/downloads.html

I tried building, but my MIPS complier from debian (gcc version 6.3.0
20170516 (Debian 6.3.0-18)) wouldn't build it, and I got the same errors
from the version of the compiler you link above.

Is anyone working on more recent MIPS compilers?  For all the other
arches we're building with gcc-7 or gcc-8.

Anyways, I tried with you u-boot image, and that can DHCP so I'm on to
the next step.

I was then able to build mainline (pistachio_defconfig) and boot
mainline using the debian ramdisk and rootfs (mipsel) we build for
kernelCI!

In the process I found a couple things to fix in how we build/install
kernels for MIPS, so I've submitted some fixes for kernelCI infra.  Once
those are merged, we'll start getting regular builds and boots on my
Ci40 with kernelCI.

If you have other boards that might be interesting, I'd be happy to add
them as well.

Thanks for all the help getting this bootstrapped,

Kevin

Re: MIPS test results

[Guenter Roeck]

On Fri, Dec 14, 2018 at 5:28 PM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Paul Burton <paul.burton@mips.com> writes:
>
> > Hi Kevin,
> >
> > On Fri, Dec 14, 2018 at 09:03:43AM -0800, Kevin Hilman wrote:
> >> > However... this log you have here is not from the CI20 board,
> >> > which is JZ4780 SoC, but from some development board
> >> > with a Pistachio SoC!
> >>
> >> The board I have is labeled Creator Ci40, and grep'ing in the MIPS DT
> >> files, led me to pistachio_marduk.dts.
> >
> > Right - pistachio is the codename for the cXT200 SoC, and marduk is the
> > codename for the Ci40 board.
> >
> >> > I thought those were dead, but it seems there are some Pistachio
> >> > boards around ?
> >>
> >> This was given to me by Imagination a couple years ago, but I never had
> >> the time to get it into kernelCI, and then the interest from Imagination
> >> "went away." ;)
> >>
> >> If nobody cares about this particular board, I don't really want to
> >> waste any time on it either.  But, if there are other boards that people
> >> actually care about we should integrate into kernelCI, and that someone
> >> wants to donate, I'd prefer to setup those.
> >
> > I don't especially care about the Ci40 board per se, but I do care about
> > the interAptiv CPU it uses & which still has active customers. So far as
> > I'm aware the Ci40 is the only dev board available to the public
> > containing interAptiv cores, so that leaves me caring about tests on
> > Ci40 :)
> >
> > In terms of updating its U-Boot, I notice the creatordev.io site that
> > documented it is no longer online... But its source is available here:
> >
> >   https://github.com/CreatorDev/u-boot
> >
> > You can build it yourself as README.md describes, or I've placed a
> > prebuilt binary here:
> >
> >   https://0x83.org/tmp/u-boot-pistachio_marduk-2015.10-v1.0.5-00001-gc1b568e7ea-dirty.img
> >
> > It says -dirty in the filename but I believe this is just because the
> > .gitignore rules don't ignore some of the files generated by the
> > build... I promise I didn't sneak anything malicious in here :)
> >
> > For reference I built it using the Codescape 2018.09-02 toolchain from
> > here:
> >
> >   https://codescape.mips.com/components/toolchain/2018.09-02/downloads.html
>
> I tried building, but my MIPS complier from debian (gcc version 6.3.0
> 20170516 (Debian 6.3.0-18)) wouldn't build it, and I got the same errors
> from the version of the compiler you link above.
>
> Is anyone working on more recent MIPS compilers?  For all the other
> arches we're building with gcc-7 or gcc-8.
>
I use gcc 7.3.0 from kernel.org when building v4.4 and later, and
gcc-4,.9.4 for older kernels.

To build the root file system, I used gcc-5.4.0 built with buildroot.

Guenter

> Anyways, I tried with you u-boot image, and that can DHCP so I'm on to
> the next step.
>
> I was then able to build mainline (pistachio_defconfig) and boot
> mainline using the debian ramdisk and rootfs (mipsel) we build for
> kernelCI!
>
> In the process I found a couple things to fix in how we build/install
> kernels for MIPS, so I've submitted some fixes for kernelCI infra.  Once
> those are merged, we'll start getting regular builds and boots on my
> Ci40 with kernelCI.
>
> If you have other boards that might be interesting, I'd be happy to add
> them as well.
>
> Thanks for all the help getting this bootstrapped,
>
> Kevin
>
> 
>

Re: MIPS test results

[Paul Burton]

Hi Kevin,

On Fri, Dec 14, 2018 at 05:28:48PM -0800, Kevin Hilman wrote:
> > In terms of updating its U-Boot, I notice the creatordev.io site that
> > documented it is no longer online... But its source is available here:
> >
> >   https://github.com/CreatorDev/u-boot
> >
> > You can build it yourself as README.md describes, or I've placed a
> > prebuilt binary here:
> >
> >   https://0x83.org/tmp/u-boot-pistachio_marduk-2015.10-v1.0.5-00001-gc1b568e7ea-dirty.img
> >
> > It says -dirty in the filename but I believe this is just because the
> > .gitignore rules don't ignore some of the files generated by the
> > build... I promise I didn't sneak anything malicious in here :)
> >
> > For reference I built it using the Codescape 2018.09-02 toolchain from
> > here:
> >
> >   https://codescape.mips.com/components/toolchain/2018.09-02/downloads.html
> 
> I tried building, but my MIPS complier from debian (gcc version 6.3.0
> 20170516 (Debian 6.3.0-18)) wouldn't build it, and I got the same errors
> from the version of the compiler you link above.
> 
> Is anyone working on more recent MIPS compilers?  For all the other
> arches we're building with gcc-7 or gcc-8.

During development I typically build the kernel with Arnd's gcc 8.1.0
toolchain from here:

  https://mirrors.edge.kernel.org/pub/tools/crosstool/

I also have automated builds using the Codescape 2018.09-02 toolchain I
linked above, based on gcc 6.3.0.

I suspect the Ci40 U-Boot probably hasn't been built with newer
toolchains. I did see issues building on my arch linux laptop where the
libfdt code seemed to be pulling in system headers, so ended up building
on a CentOS 6 machine - I wonder if that could be the build issue you
saw? U-Boot has seen fixes for this, the Ci40 port is just too old to
contain them. Otherwise I'm confused as to why the Codescape toolchain
built it fine for me but not for you.

> Anyways, I tried with you u-boot image, and that can DHCP so I'm on to
> the next step.
> 
> I was then able to build mainline (pistachio_defconfig) and boot
> mainline using the debian ramdisk and rootfs (mipsel) we build for
> kernelCI!
> 
> In the process I found a couple things to fix in how we build/install
> kernels for MIPS, so I've submitted some fixes for kernelCI infra.  Once
> those are merged, we'll start getting regular builds and boots on my
> Ci40 with kernelCI.

That's fantastic news :)

> If you have other boards that might be interesting, I'd be happy to add
> them as well.

I'll see where we stand on Ci20's & mail you privately.

> Thanks for all the help getting this bootstrapped,

Not at all - thank you for putting in the time & effort to get this up &
running :)

Thanks,
    Paul