On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycli...@andestech.com> wrote: > > Hi Alex, > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote: > > Hi Leo, > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycli...@andestech.com> wrote: > > > > > > Hi Alexandre, > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote: > > > > The following description is copied from the equivalent patch for the > > > > Linux Kernel proposed by Aurelien Jarno: > > > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i > > > > instruction has separated from the `I` extension, become two standalone > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction, > > > > this causes the following build failure: > > > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages: > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause' > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc' > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval' > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0' > > > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.gh...@canonical.com> > > > > --- > > > > arch/riscv/Makefile | 11 ++++++++++- > > > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > > > This patch seems to fail CI somehow. > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004) > > > > > > Could you take a look at it ? > > > > I have just tried on master (commit ab8903a24db1) and it failed for > > the same reason, so this is not related to this patch. Nevertheless, > > I'll try to bisect the problem :) > > > > Thanks, > > > > Alex > > > > Thanks for putting the effort into it! > > AFAIK, this patch does nothing related to the error message "undefined > reference to `__ashldi3'" from the failed CI. > > Nonetheless, I have tried a few times myself, > and found that CI could pass with ab8903a24db1 but cannot pass with this > patch on my side. > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines >
To me it is an issue with the toolchain: libgcc is missing those symbols. If I use an Ubuntu toolchain, it fails no matter which commit I am on (I tested as far as v2021.10). But if I use a toolchain from https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/, it works fine. What I don't understand is how you manage to have different build results with the same docker image: can you confirm that you use the same toolchains in the following builds? https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701 https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783 The only difference I see here is the gitlab-runner version (line 1). Thanks, Alex > Best regards, > Leo > > > > > > > Best regards, > > > Leo
