Booting Ubuntu23.04 Error

When booting the ubuntu23.04,the following error has occurred。

200bff8 belongs to the clint。in OpenSBI,bff8 is CLINT_TIME_VAL_OFF

So, how do I modify the code and inform os not to handle this address?

Interesting @eden Here is some discussion of kernel panics.

The 0xBFF8 offset is the mamory-mapped address for the internal 64-bit MTIME counter, most likely used for systick or other O/S scheduling purposes.

Maybe there’s some Ubuntu comfiguration flag or option to disable the use of systick?

No it doesn’t. The error very clearly says “virtual address”, not “physical address”.

Is it caused by the rtc driver?

1 Like

Probably either EDK2 is buggy or the version of the Linux kernel in 23.04 doesn’t handle EFI run-time services properly on RISC-V, whether that’s Linux not correctly calling SetVirtualAddressMap or EDK2 not correctly handling it. Either way, SiFive’s officially-supported firmware is U-Boot, not EDK2, and this looks like a generic issue that is not specific to the HiFive Unmatched, so you should go talk to EDK2 and/or RISC-V Linux kernel developers in their respective forums / on their mailing lists / etc., not here.

@eden maybe not so much as the “rtc driver” but rather the driver or other piece of the Linux kernel which handles MTIME, perhaps for its systick or other O/S purposes.

RTC is an external peripheral and part of the Always ON (AON) power and clock domain, not the Mostly OFF (MOFF) area. Due to the nuances and complexities of AON, it’s not likely to overlook anything in there.

MTIME is an integral part of the CPU core, in its MOFF area, yet is one of the only MOFF blocks which is memory-mapped to a physical address (0x200 bff8) for its access. Thus, I might imagine an innocent typo in the kernel which overlooked this rare special case.

None of this is relevant. I explained the issue in my comment.

I’m willing to bet Platform/SiFive/U7SeriesPkg/Universal/Dxe/TimerDxe is just totally broken after ExitBootServices. It’s probably assuming M-mode has given it free reign over the CLINT and it can just poke physical addresses, but it’s running in S-mode (always I hope) and so once ExitBootServices is called, SetVirtualAddressMap is called and calls into EFI Runtime Services are made it ends up trying to access the CLINT and totally falls over because it can’t do that any more. It should be making SBI calls down into M-mode firmware for timer accesses. Or if it really needs to then it can ask the OS to map it somewhere and update its pointers during SetVirtualAddressMap.

TL;DR: Your random build of a WIP EDK2 for the HiFive Unmatched is just broken. It is not written by anyone at SiFive, so don’t expect them to offer support for it here. Go talk to them. And in future please very clearly state in your posts that you are using EDK2 not U-Boot. Because if you do not specify it, people will assume you are using the official firmware from SiFive, which is U-Boot, and thus will get extremely confused when they see a backtrace like yours.

I searched the data and said that risc-v has no pmmu, so the physical addresses and the internal virtual addresses are mapped one by one.

So, I wrote the following in the dts:
clint: clint@2000000 {
compatible = “riscv,clint0”;
interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
&cpu1_intc 3 &cpu1_intc 7
&cpu2_intc 3 &cpu2_intc 7
&cpu3_intc 3 &cpu3_intc 7
&cpu4_intc 3 &cpu4_intc 7>;
reg = <0x0 0x2000000 0x0 0x10000>;

However, the same mistake still occurred.So, what else needs to write to map the mtime ???

  1. RISC-V has a sort-of MMU for physical addresses, the PMP, but it’s solely for protection, not translation
  2. A physical MMU would translate “CPU physical” to “SoC physical” addresses or some similar thing; it has nothing to do with virtual addresses
  3. RISC-V has a normal MMU for translating virtual to physical addresses, an extremely vital part of modern computing hardware for most processor applications, so virtual and physical addresses are absolutely not “mapped one by one”

I really do not want to have to repeat myself here. I’ve told you exactly what the problem is and explained it. Your inability to take information on board is getting a bit tiresome.

Why would that do anything at all of use? It’s clear you have no idea how any of this works at all, so please either educate yourself with the copious amount of online resources or report the issue to wherever you got that version of EDK2 from. This is not the place for those reports as I’ve already told you, nor is this the place for teaching you the basics of computer architecture and operating systems.

I have reported this issue to ubuntu。However, several days have passed, and no one replied to me 。Our project has therefore been stalled ,so, I have to find a way to solve it,but, I’m a newcomer on the risc-v, so I don’t know what to do 。I don’t mind jessica clarke’s comments. In fact, she helped me lot and I am very grateful to her :100:

This error occurs when I boot the ubuntu with uefi edk2,But I have tested uboot ,this problem doesn’t happen with the uboot。So, I don’t know how uboot deals with MTIME :sob:

It’s not Ubuntu’s bug, there is no bug there in the Linux kernel, it’s an issue with your firmware that you went and found and put on your board; the EDK2 you have is just broken and cannot possibly work, because one of the services it provides to the running operating system is not implemented correctly. Please listen to what I’m telling you.

And Jessica is normally a female name…

Oh Sorry Jessica ,I have corrected my comment

Is it a service for the memory mapping?

No. That is handled exclusively by the OS. I’m assuming it’s the RTC service.

There are indeed runtime services like SetTime / GetTime in EDK2。

However on the unmatched motherboard, rtc is integrated on da9063. So I may need to write da9063 driver. This is difficult for me since I have never used da9063 . Is there reference code or related datasheet?

Yes, Get/SetTime are being implemented with the CLINT, which is fine, but it needs to be implemented in a way that doesn’t crash.

So, I need to refer to the openbsbi?

That or have the CLINT driver properly create and manage a memory mapping for the CLINT. You can use something like PL031RealTimeClockLib for reference, noting how mPL031RtcBase is managed (see LibRtcVirtualNotifyEvent in particular for translating the address after the OS takes over memory management and calls SetVirtualAddressMap).