Bug 252891
| Summary: | risc-v : HiFive unleashed kernel entry panic: Memory access exception | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Klaus Küchemann <maciphone2> |
| Component: | riscv | Assignee: | Mitchell Horne <mhorne> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | br, emaste, maciphone2, mhorne |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | riscv | ||
| OS: | Any | ||
|
Description
Klaus Küchemann
2021-01-21 17:12:55 UTC
happens even with the original : https://github.com/Microsemi-SoC-IP/HiFive_U-Boot U-Boot 2018.09-g6f6e014 (Jan 20 2021 - 09:19:19 -0500) DRAM: 2 GiB MMC: In: serial Out: serial Err: serial Net: gmac0 RISC-V # setenv ipaddr xxxxx RISC-V # setenv serverip xxxxxxx RISC-V # bootp gmac0: PHY present at 0 gmac0: Starting autonegotiation... gmac0: Autonegotiation complete gmac0: link up, 1000Mbps full-duplex (lpa: 0x3c00) BOOTP broadcast 1 DHCP client bound to address xxxxxxxx (4 ms) Using gmac0 device TFTP from server xxxxxxx; our IP address is xxxxxxxx Filename 'boot/loader.efi'. Load address: 0x80000000 Loading: ################################################################# ################################ 1.4 MiB/s done Bytes transferred = 1415772 (159a5c hex) RISC-V # go 0x80000000 ## Starting application at 0x80000000 ... exception code: 2 , Illegal instruction , epc 80000002 , ra fffa3d72 exception code: 2 , Illegal instruction , epc 80000002 , ra fffa3d72 exception code: 2 , Illegal instruction , epc 80000002 , ra fffa3d72 exception code: 2 , Illegal instruction , epc 80000002 , ra fffa3d72 exception code: 2 , Illegal instruction , epc 80000002 , ra fffa3d72 ...endless loop... (In reply to Klaus Küchemann from comment #1) This second log in particular looks like a different issue, so I will focus on the original report for now. With some previous discussion, it is believed that this is caused by a hardware erratum in the fu540, which is vaguely described here: https://github.com/riscv/opensbi/issues/103 In particular, the issue is believed to be triggered by FreeBSD's construction of the direct map, which maps the PMP protected area with a 1GB page mapping, triggering the access exception even though the area is never actually accessed by the kernel. I've wanted to address this issue with the dmap for a while, but it will take a bit of time to finish the patch. kp@ has described the workaround he used for this issue last year, which is to disable the PMP protection of the SBI firmware area. I've once again tried to compile u-boot and OpenSBI with this workaround applied, in hopes that we can apply this solution for the time being. If you can, please attempt to boot with the following u-boot binaries flashed to the SD card: https://people.freebsd.org/~mhorne/tmp/u-boot-spl-test3.bin https://people.freebsd.org/~mhorne/tmp/u-boot-test3.itb (In reply to Mitchell Horne from comment #2) Really good job you are doing, thank you very much! https://dmesgd.nycbug.org/index.cgi?do=view&id=5888 (In reply to Klaus Küchemann from comment #3) You're welcome, I'm glad it worked this time. We'll keep the PR open, since it helps track the issue. I am prepping an update to the sysutils/opensbi port, and will make sure the workaround is included. I'll tag you in the review once it is posted. ^Triage: apparently fixed back in 2021. |
