Linux 5.0 on HiFive Unleashed [solved]

(Wladimir van der Laan) #1

I’ve been trying to compile a new kernel for Fedora RISC-V for a while, every time without success. In my most recent try

Then I do make and it produces a bbl.u540 that I install to the correctly labeled GPT partition of a SD card.

I get this, then nothing at all, no error messages through the serial out

SiFive FSBL:       2018-03-20
HiFive-U serial #: 0000xxxx
bbl loader
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrrrr    vvvvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrrrrr      vvvvvvvvvvvvvvvvvvvvvv
rrrrrrrrrrrrr       vvvvvvvvvvvvvvvvvvvvvv
rr                vvvvvvvvvvvvvvvvvvvvvv
rr            vvvvvvvvvvvvvvvvvvvvvvvv      rr
rrrr      vvvvvvvvvvvvvvvvvvvvvvvvvv      rrrr
rrrrrr      vvvvvvvvvvvvvvvvvvvvvv      rrrrrr
rrrrrrrr      vvvvvvvvvvvvvvvvvv      rrrrrrrr
rrrrrrrrrr      vvvvvvvvvvvvvv      rrrrrrrrrr
rrrrrrrrrrrr      vvvvvvvvvv      rrrrrrrrrrrr
rrrrrrrrrrrrrr      vvvvvv      rrrrrrrrrrrrrr
rrrrrrrrrrrrrrrr      vv      rrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrr          rrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrr      rrrrrrrrrrrrrrrrrrrr
rrrrrrrrrrrrrrrrrrrrrr  rrrrrrrrrrrrrrrrrrrrrr


I have no idea how to even start debugging this :confused:

# grep SIFIVE .config
# grep RISCV .config
  • Is the serial device name in the command line console=ttySI0 still correct? (could this explain no output?)
    edit: okay, this could be it, we might need ttySIF0:
drivers/tty/serial/sifive.c:#define SIFIVE_TTY_PREFIX                   "ttySIF"

No, unfortunately that didn’t help.

(Wladimir van der Laan) #2

Is it a boot loader issue? Does it need u-boot instead of bbl perhaps? (just found this)

Edit: or, what is opensbi? I realize I have no clue how this all fits together.

Edit: YESS after simply changing the branch to v5.1-rc1_unleashed (hadn’t noticed that it existed), I get kernel output !

[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 5.1.0-rc1-00010-ge3827dbacb90 (root@medusa.local) (gcc version 9.0.1 20190320 (Red Hat 9.0.1-0.11) (GCC)) #8 SMP Fri Mar 29 14:12:06 UTC 2019
[   16.407127] systemd[1]: System time before build time, advancing clock.
[   16.426215] systemd[1]: systemd v241-2.gita09c170.0.riscv64.fc30 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[   16.449523] systemd[1]: Detected architecture riscv64.

Welcome to Fedora 31 (Rawhide)!

[   16.463061] systemd[1]: Set hostname to <medusa.local>.
../machine/mtrap.c:21: machine mode: unhandlable trap 4 @ 0x000000008000387a
                                                                            Power off

It even gets as far as booting from nbd0, right after setting the hostname it dies in a mtrap (huh - CAUSE_MISALIGNED_LOAD 0x4) but so happy to have output now.

(Wladimir van der Laan) #3

apparently I get a misaligned load trap … in the misaligned_load_trap handler :cry: (so it’s different from the one described here Linux does not boot after a massive code addition to the bbl)

0000000080003870 <misaligned_load_trap>:
    80003870:   000a07b7                lui     a5,0xa0
    80003874:   458d                    li      a1,3
    80003876:   3007a6f3                csrrs   a3,mstatus,a5
    8000387a:   00066703                lwu     a4,0(a2)
    8000387e:   30069073                csrw    mstatus,a3
    80003882:   00377813                andi    a6,a4,3
    80003886:   8eaa                    mv      t4,a0
    80003888:   1141                    addi    sp,sp,-16
    8000388a:   8536                    mv      a0,a3
    8000388c:   4f11                    li      t5,4
    8000388e:   00b80363                beq     a6,a1,80003894 <misaligned_load_trap+0x24>
    80003892:   4f09                    li      t5,2

Edit: okay, this issue was funny. Apparently the compiler is generating RISCV-C but not defining __riscv_compressed, resulting in the trap handler getting unexpected input (the other __riscv_* are defined though?!? edit: this has been reported, is a known issue in gcc mainline [1]). After defining that manually and recompiling riscv-pk it works and boots !

medusa:~# uname -r


(Troy Benjegerdes) #4

So if that ‘just works’, then I need to update freedom-u-sdk and figure out how to support two kernel targets. Any thoughts on the best way to build that without creating a bunch of checked-out bloat?

Although if you want to come bleed with us a mainline-able U-boot might be working from soonish

(Wladimir van der Laan) #5

Not really, at the moment I definitely have a lot of checked-out bloat here :slight_smile: At least wanted to document my steps so it might help people running into some of the same issues.

I don’t think submodule would work for the use-case. I suppose the script would have to explicitly add remote, fetch, and check out the kernel branch that is going to be built. At least the git history is shared for large part.

I intend to!