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!

(Rakesh) #6

hello all,

i have downloaded the latest fedora disk image from this link
following the same procedure here find that they mentione -sda.raw file but in the link provided -sda1.raw image which is EXT4 file system , i copied the same raw image to first partition in sd card using dd command and in the second partition copied the bbl+kernel+initramfs images but still the u540 board is not booting up, struck in the middle any suggestion how to boot up with fedora-riscv raw image

(Jim Wilson) #7

New threads for new problems please. It is confusing to add something that is unrelated to the original question. The kernel you are using will boot on qemu but not on the HiFive Unleashed, as it is missing drivers required for the hardware. We are still in the process of upstreaming the necessary drivers to the linux kernel sources. Meanwhile, you can build something that will boot on the hardware by using, and then optionally replace the debian rootfs with a fedora rootfs. You will have to edit the u-boot config file to disable initramfs to boot the debian/fedora rootfs instead of initramfs.

(Wladimir van der Laan) #8

It doesn’t seem that I have permission to edit or delete this: but please close/delete this topic; the instructions here don’t work with newer kernels and might confuse people.

Use OpenSBI wrapping u-boot to boot kernels.

(Jim Wilson) #9

I don’t know of any way to close discussions other than to mark them as spam, and this isn’t spam. Posting a note that the info it obsolete should be good enough and you already did that.