search

riscv-software-src / riscv-isa-sim

Spike, a RISC-V ISA Simulator
Other
2.43k stars 855 forks source link

How to print information without pk? #195

Open YohnWang opened 6 years ago

YohnWang commented 6 years ago

I want to transplant ucosii on spike,but how to print information without pk? I refered to the transplantation of freeRTOS (https://github.com/illustris/FreeRTOS-RISCV). It used 'tohost' to implement printf. But I don't know how it works.

noureddine-as commented 6 years ago

Hello,

Check https://github.com/riscv/riscv-tests/blob/master/benchmarks/common/syscalls.c it contains definition of some functions using the HTIF interface. You can then use that to build your baremetal applications.

My understanding is that tohost and fromhost are memories used for communication between the tethered RISC-V systems and the front end server riscv-fesvr.

Best Regards.

YohnWang commented 6 years ago

Your link is really helpful,thank you.

tohost and fromhost maybe work by symbols.

widlarizer commented 10 months ago

I have followed this advice and it worked for spike and qemu but it looks like a very bad idea. I encountered a bug when I adapted it for building with picolib instead of newlib. But I can't even say what the bug is, let alone fix it, when I don't know what the correct protocol usage is! So I have to replace HTIF instead with something present in spike. All I currently have is a workaround where I mark the syscall function __attribute__((noinline)) .

HTIF is a non-standard tool for Berkeley processors, so there's no documentation on it. It is going to disappear soon, as the RISC-V platform spec is released and the cores are updated to be self-hosting.

An alternative is clearly needed.

jerryz123 commented 10 months ago

That comment is out-of-date. There are no plans for removing HTIF (but there are also no plans for improving it).

An alternative is clearly needed.

I'm not really sure what you are trying to do.

widlarizer commented 10 months ago

I'm not really sure what you are trying to do.

As a dev for an embedded toolchain vendor, I would like to provide simple "hello world" support code to the customer that is guaranteed to be correct to be safe. Using pk isn't "simple" so we have code that lets newlib/picolib directly use HTIF for stdio. Currently, we use an HTIF implementation from lowRISC. This function is broken when it's inlined into a putchar function, it causes spike to print zero bytes. I am hotfixing it with __attribute__(noinline), but I can't find the source of the problem. I might find a compiler bug if I take another look at the assembly but I can't help but think that if there's no spec, then I don't know what conditions have to be met for HTIF to work, so there's no bug. This is a problem. For example, what if it works uninlined just by accident, and it gets miscompiled with a different LLVM version?

I looked into using UART instead. I could rewrite the support code using it instead of HTIF, but I would have to advise the toolchain user to edit and compile the device tree sources for spike, since UART is off by default. Therefore for now I have decided to stick with HTIF and the attribute-based hotfix.

widlarizer commented 10 months ago

I have found a more proper solution in riscv-coremark. The lowRISC code was missing a pair of __sync_synchronize(); barriers. The noinline attribute is no longer necessary

jerryz123 commented 10 months ago

You may also be interested in libgloss.

https://github.com/ucb-bar/libgloss-htif