OS booting on a riscv core (requirements)

1,528 views
Skip to first unread message

vithurson

unread,
Jul 30, 2018, 7:17:32 AM7/30/18
to RISC-V HW Dev
What is the minimum requirement of a risc v core implementation in order to be able to run the current risc -v port of the linux?
1) rv32 or rv 64?
2) what  are the extensions needed to be implemented.?
3) is memory management required to be implemented (TLBs and stuffs)
4) l1 instruction and l1 data cache needed to be coherent with each other or just flushing support  is enough?
any other requirement

thanks

Dr Jonathan Kimmitt

unread,
Jul 30, 2018, 7:27:33 AM7/30/18
to vithurson, RISC-V HW Dev

Certainly a 32-bit and 64-bit cores can run Linux. You need to take care of page table differences when you configure Linux.

Atomic instructions are a must, or a suitable emulation library. An atomic emulation library exists in Linux but

I'm not sure how mature it is. Floating point is not needed for the kernel but is highly desirable for user mode applications.

Compressed instructions are in theory optional, but if not present you will have to recompile the entire userland yourself, since

the G (general purpose) baseline assumes it. You need to have an MMU, and FLUSH.VM, though in theory no mmu operation is possible.

FENCE.I and friends is required to support cache flushing. FENCE.RW is needed in device drivers.

If you want to run pre-built debian or redhat riscv, you need to support IAMFDC in the hardware or IMC + emulation routines.
--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/2352b79e-a563-4522-b71e-630eb1439bf0%40groups.riscv.org.

vithurson

unread,
Jul 30, 2018, 7:47:40 AM7/30/18
to RISC-V HW Dev, nmk...@gmail.com
thanks,
are these emulation routines are to be implemented like this.
1) Interrupt the execution whenever we see a not implemented instruction and run the emulation routines to execute the instruction and return back?

Dr Jonathan Kimmitt

unread,
Jul 30, 2018, 7:52:49 AM7/30/18
to vithurson, RISC-V HW Dev

Your emulation routines should hook into the illegal instruction trap vector

You can see an example here:

https://github.com/riscv/riscv-pk/blob/3d921d3c76db3af7b9ae0b5df0f0790f26222246/machine/emulation.c

This version does not do atomics though.

Samuel Falvo II

unread,
Jul 30, 2018, 12:22:12 PM7/30/18
to Dr Jonathan Kimmitt, vithurson, RISC-V HW Dev
Are you sure G implies C? I've always seen reference to RV64GC as a
distinct thing from RV64G. Is this a recent change?
> https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/4934f44f-64b5-d670-881b-2d8c75ed218e%40cam.ac.uk.



--
Samuel A. Falvo II

Tommy Murphy

unread,
Jul 30, 2018, 12:28:48 PM7/30/18
to sam....@gmail.com, jr...@cam.ac.uk, vithurson, RISC-V HW Dev
G = IMAFD so does not include C



Dr Jonathan Kimmitt

unread,
Jul 30, 2018, 12:36:21 PM7/30/18
to Samuel Falvo II, vithurson, RISC-V HW Dev

Historically speaking G can exist without C, in fact all released versions of lowrisc just use G.

However this is a pain because the big Linux distributions have chosen C to be mandatory.

The Debian port uses RV64GC as the hardware baseline and the lp64d ABI (the default ABI for RV64G systems).

Making the C extension a part of the default hardware baseline for general-purpose binary Linux distributions has been agreed upon between Fedora porters, Debian porters and members of the RISC-V foundation. According to the chairman of the board of the RISC-V foundation, the foundation will provide "a profile for standard RISC-V Unix platforms that will include C as mandatory".

(according to wiki.debian.org)

Therefore, at lowrisc we have chosen to bring our default architecture to RV64GC for the next release, to fit in with the majority verdict.

This is an understandable emphasis since 32-bit only codes perform poorly on code density versus ARM thumb2, which is the market leader.

So if you are standing a design now, I would assume it would have to have C, otherwise any savings made in processor area in gate count
would soon be swallowed up by larger caches, etc. for the same performance.

Sathya Narayanan N

unread,
Jul 30, 2018, 1:21:21 PM7/30/18
to Dr Jonathan Kimmitt, Samuel Falvo II, vithurson, RISC-V HW Dev
Actually g implies including c in recent version s. I manually removed c and compiled imafd config for our riscv tapeout simulation s.
 is
needed in device drivers.

If you want to run pre-built debian or redhat riscv, you need to support
IAMFDC in the hardware or IMC + emulation routines.


On 30/07/18 12:17, vithurson wrote:

What is the minimum requirement of a risc v core implementation in order to
be able to run the current risc -v port of the linux?
1) rv32 or rv 64?
2) what  are the extensions needed to be implemented.?
3) is memory management required to be implemented (TLBs and stuffs)
4) l1 instruction and l1 data cache needed to be coherent with each other or
just flushing support  is enough?
any other requirement

thanks

--
You received this message because you are subscribed to the Google Groups
"RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to hw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at

.


--
You received this message because you are subscribed to the Google Groups
"RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to hw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.


--
 regards,
Sathya  

 

Samuel Falvo II

unread,
Jul 30, 2018, 1:29:12 PM7/30/18
to Sathya Narayanan N, Dr Jonathan Kimmitt, vithurson, RISC-V HW Dev
On Mon, Jul 30, 2018 at 10:21 AM, Sathya Narayanan N
<sath...@gmail.com> wrote:
> Actually g implies including c in recent version s.

The published user ISA specifications seems to disagree with you. If
this is intended to be the case, maybe a PR should be made against the
user ISA specifications. Otherwise, you're just going to create
confusion for the wider audience.

Tommy Murphy

unread,
Jul 30, 2018, 2:18:13 PM7/30/18
to sam....@gmail.com, sath...@gmail.com, Dr Jonathan Kimmitt, vithurson, RISC-V HW Dev
Correct, the latest specs explicitly state that G = IMAFD.
There is no ambiguity here.
If certain applications of the RISC-V (e.g. some or all Linux distros) require GC then that's a separate matter
But it doesn't change the fact that G = IMAFD and does not include C.



--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

Michael Clark

unread,
Jul 30, 2018, 5:33:29 PM7/30/18
to RISC-V HW Dev, sam....@gmail.com, sath...@gmail.com, Dr Jonathan Kimmitt, vithurson, Tommy Murphy
Answering the original question, here are the current minimum requirements for running Linux kernel.

Kernel

- Base ISA 2.2
- Priv ISA 1.10
- BBL does Mmuldiv and F+D emulation
- S indicates S-mode
- sv32, sv39 or sv48 MMU paging mode
- Current minimum: RV32IAS or RV64IAS

User-space / Glibc / musl-libc

- Possible to use IMAFD user-space under this scenario, with trap-and-emulate for M, F and D.
- trap-and-emulate is slower than libgcc support libraries if the hardware doesn’t support M, F and D.
- Possible to compile an RV32IA or RV64IA user-space using the GCC provided fill-in functions for muldiv and soft-float.
- Current minimum: RV32IA or RV64IA

FPU is not used by the kernel except for FSD/FLD in arch/riscv/include/asm/switch_to.h for floating point register file save/restore on context switch. The save/restore code is only called if mstatus.SD is set, so if there is no FPU then it will not be called.

AMOs are used in several places in the kernel. I believe spinlocks get compiled to nothing for a uniprocessor kernel config, however, there may be a bit of work to remove the requirement for atomics. AMOs theoretically could be removed for uniprocessor Linux relatively easily as earlier versions of the Linux port supported building without AMOs. It was decided to make A mandatory for the kernel. Userspace needs a compare and swap kernel syscall because it can be preempted (the kernel can disable interrupts in critical sections, so doesn’t need A on uniprocessor). The compare and swap syscall was removed when it was decided to make A mandatory. This is not to say there could be an out-of-tree fork. Glibc likely needs changes to allow building without A.

Hardware TLB and software page-walker would be an option, however there is no code to do this at present. The page walker would need to run in M-mode e.g. in bbl. I’m not sure if this is allowed by the current Privileged ISA, as there is no mcause value to indicate a TLB miss, and one would need to define an interface to fill the TLB.

Indeed it would be possible to support No-MMU Linux but this would require the FDPIC ABI [1] support to make shared libraries work. Although even that constraint can be relaxed [2]. FDPIC is static PIE with some extension to separate code and data, as while code is shared by multiple executables running the same code, each executable running the same binary needs its own copy of the data section. I believe FDPIC uses FAT function pointers similarly to the PowerPC TOC pointer. This is because the GOT cannot be known relative to text. i.e. the ABI removes the assumption that text and data relative addresses are known. Indeed this is even a good idea on systems with MMUs as it would allow ASLR to have different entropy for code and data, preventing a leaked data pointer from revealing the location of text (for location of ROP gadgets based on static analysis).

I think over time, it would be worthwhile to:

- Implement static PIE support. RISC-V currently does not support static PIE and it would be relatively easy to add and allows ASLR for static executables
- Define an FDPIC ABI for No-MMU Linux. This would not be a trivial undertaking. My opinion is that separate ASLR entropy for code and data would even be useful for systems with MMUs.

kr...@berkeley.edu

unread,
Jul 30, 2018, 6:52:30 PM7/30/18
to Dr Jonathan Kimmitt, Samuel Falvo II, vithurson, RISC-V HW Dev

>>>>> On Mon, 30 Jul 2018 17:36:19 +0100, Dr Jonathan Kimmitt <jr...@cam.ac.uk> said:

| Historically speaking G can exist without C, in fact all released versions of
| lowrisc just use G.

Just to make clear, G=IMAFD and does not include C. Nothing has ever
changed here.

Linux source code should be able to be ported to work with just RV32I,
though A is effectively necessary with more than one hart (can use
interrupt disable to provide atomic sections for one hart).

| However this is a pain because the big Linux distributions have chosen C to be
| mandatory.

| The Debian port uses RV64GC as the hardware baseline and the lp64d ABI (the
| default ABI for RV64G systems).

| Making the C extension a part of the default hardware baseline for
| general-purpose binary Linux distributions has been agreed upon between Fedora
| porters, Debian porters and members of the RISC-V foundation. According to the
| chairman of the board of the RISC-V foundation, the foundation will provide "a
| profile for standard RISC-V Unix platforms that will include C as mandatory".
| (according to wiki.debian.org)

While RISC-V ISA design can support many different Linux variants, at
this point in RISC-V project, we had to concentrate community efforts
on a single distribution that would have the most impact. Most
commercial RISC-V design-ins today are in embedded space, where code
size and core area/power matters, even for Linux distros, hence agreement
that RV64GC made sense as the ISA version to be supported in Linux.

| Therefore, at lowrisc we have chosen to bring our default architecture to
| RV64GC for the next release, to fit in with the majority verdict.

Great news! The underlying open-source Rocket Chip code base has had
C support for a while.

| This is an understandable emphasis since 32-bit only codes perform poorly on
| code density versus ARM thumb2, which is the market leader.

For app processors, 64-bit is becoming a more common requirement, and
here RV64GC has a significant code-size advantage over other 64-bit
ISAs.

| So if you are standing a design now, I would assume it would have to have C,
| otherwise any savings made in processor area in gate count
| would soon be swallowed up by larger caches, etc. for the same
| performance.

Exactly - at least for everything below medium-issue superscalar
designs. There is an argument for sticking with pure fixed-width
instruction size for very wide superscalar designs. Of course, RISC-V
supports that option, and nothing prevents anyone building/maintaining
an RV64G version of a Linux distro. But in terms of maximizing RISC-V
impact with current ecosystem resources, it made sense to recommend
RV64GC as the standard ISA for Linux community to support.

Krste
| 8797c32a-3a5c-cf8e-e9d1-b2fa76ce2e56%40cam.ac.uk.

Palmer Dabbelt

unread,
Jul 30, 2018, 7:42:51 PM7/30/18
to nmk...@gmail.com, hw-...@groups.riscv.org
On Mon, 30 Jul 2018 04:17:32 PDT (-0700), nmk...@gmail.com wrote:
> What is the minimum requirement of a risc v core implementation in order to
> be able to run the current risc -v port of the linux?
> 1) rv32 or rv 64?

Both rv32i and rv64i are supported, but rv64i is more likely to work.
rv64i-based systems are also supported in the upstream glibc, which makes life
a bit easier as you'll probably want a glibc-based userspace if you're
interesting in booting Linux.

> 2) what are the extensions needed to be implemented.?

rv64imafdc (aka rv64gc) is your best bet, as then you can use an unmodified
Debian or Fedora userspace and run lots of interesting programs with no extra
work or your end.

Our glibc port supports rv64ima, rv64imac, rv64imafd, and rv64imafdc but you'll
have to build all of userspace around it yourself -- with something like
OpenEmbedded this isn't that big of a deal, though.

If you want to use an rv32i-based system then you'll need to grab some glibc
patches as it's not upstream yet. As far as I know nobody has built or tested
a significant userspace for rv32i-based systems so you'll probably run into a
handful of issues, and since there are some possible ABI issues in 32-bit land
we might need to break userspace at some point -- which is still legal for
rv32i-based systems because glibc isn't upstream yet.

Linux, glibc, and the rest of userspace should work without the M extension but
since nobody tries this you'll probably run into a bunch of issues. I'd expect
the vast majority of these to be minor, but they'll still be headaches.

We used to support systems without the A extension, but the interface we had
wasn't well designed so we currently mandate the A extension in Linux and
glibc. We could change this, but it would require a bit of work to do right --
also, note that this is only sensible for single-hart systems, you'll need the
A extension if you want to run Linux on multiple harts. You're probably better
off just implementing A, as it's easy on single-hart systems and necessary on
multi-hart systems.

Support for rv32e-based systems is non-existent in the vast majority of the
Linux ecosystem, and while there's nothing fundamental that would prevent this
from working it's not something we've seen any interest in.

> 3) is memory management required to be implemented (TLBs and stuffs)

We don't currently have a port of Linux to MMU-free RISC-V systems, and doing
so would be a significant amount of work. While there has been some interest
there hasn't been nearly enough to get the project started, so you much better
off implementing virtual memory.

> 4) l1 instruction and l1 data cache needed to be coherent with each other
> or just flushing support is enough?

The memory model related restrictions are listed in the notes for the UNIX
platform spec, which restrict some parts of the memory model that have not been
formally specified yet. For example, there are constraints on I/O ordering as
well as some constraints on the allowable values that can be fetched. Existing
implementations are fairly aggressive about taking advantage of this weakness
in the memory model, so I wouldn't anticipate any problems if your design does
as well.

While we nominally support every order that has been specified by the RISC-V
memory model, existing implementations are not particularly aggressive in
taking advantage of many aspect of the weak memory model so you might run into
bugs if you do something exotic. These would all be software bugs, of course,
but they may be hard to track down.

> any other requirement

You need a reasonable memory capacity: 8MiB is probably a bad idea and 16MiB
will be uncomfortable -- of course you'll need a whole lot more if you want to
run a lot of user space stuff.

You'll also need some devices if you want to do anything interesting. While we
support the vast majority of devices in Linux, our bootloader story isn't
nearly as good so your best bet will be to pick devices based on your
bootloader. This should improve as we get better bootloader support, but that
is a big chunk of work.

vithurson

unread,
Jul 31, 2018, 6:59:05 AM7/31/18
to RISC-V HW Dev, nmk...@gmail.com
thanks all
I have another question regarding this in the process of booting the os , where will be the hardware specific information such as stdout fifo address (for printf) configured?

Michael Clark

unread,
Jul 31, 2018, 7:51:39 AM7/31/18
to vithurson, RISC-V HW Dev
Currently BBL provided an SBI console API to the kernel, however, once the kernel has drivers for the output devices then it will likely end up that we use the “chosen” node in device-tree.

chosen { stdout-path = "uart@0x10300000"; };

Linux supports this already assuming the device-tree is correct and there is a driver for the output device.

Of course SBI is useful for bring-up when you don’t have a full fledged driver in the kernel, so it might remain. It’s definitely useful to have getchar/putchar in a pre-boot execution environment.

BBL currently finds a device that it recognises in the device-tree and uses that for the SBI console. It could be modified to use chosen, or you can use an alternative boot loader. Linux will use either SBI or chosen depending on how it is configured. Ideally SBI is just registered as an earlyprintk device and Linux will pick it up if there is no chosen node. I’m not exactly sure what happens if chosen is implemented. The chosen device should be picked up as the earlyprintk device if it’s driver supports earlyprintk.

I believe there is earlyprintk support in several of the openfirmware aware UART drivers. There certainly is for the NS16550A. It’s likely not that hard to add earltprintk support to a custom UART driver.
--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

Dr Jonathan Kimmitt

unread,
Jul 31, 2018, 12:14:18 PM7/31/18
to vithurson, RISC-V HW Dev
This kind of information together with the kind of UART present will normally be kept in the device tree blob which is appended to the boot loader or read from rom for fixed platforms. You can also fix the addresses using platform drivers in Linux if you have a fixed platform. DTB files are compiled from DTS files using device tree compiler (dtc). The same Linux image may run on many different systems using different dtb files.

Sent from my iPhone
--

Sathya Narayanan N

unread,
Aug 1, 2018, 12:40:22 AM8/1/18
to Dr Jonathan Kimmitt, vithurson, RISC-V HW Dev
I would like to second Jonathan, having a DTB model is the best way to go ahead.
I used this model to try out SEL4 (a secure os) on RISCV FPGA. 

You can have a look at below link. We have successfully booted linux on Inbuilt RISCV based FPGA/ASIC
https://bitbucket.org/casl/shakti-linux 



To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/EE4D7338-59A3-4C97-8BA8-52C128B7FA11%40cam.ac.uk.



--
 regards,
Sathya  

 

dongle wingle

unread,
Aug 26, 2018, 4:16:26 AM8/26/18
to Sathya Narayanan N, Dr Jonathan Kimmitt, RISC-V HW Dev
I need further understanding on memory management.

do page table entries are created in run time by operating system and/or precompiled image consists of PTEs?
in which stage the satp register is configured with a for the first time? by the boot loader or operating system?

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/EE4D7338-59A3-4C97-8BA8-52C128B7FA11%40cam.ac.uk.



--
 regards,
Sathya  

 

Dr Jonathan Kimmitt

unread,
Aug 26, 2018, 4:28:17 AM8/26/18
to dongle wingle, Sathya Narayanan N, RISC-V HW Dev

On our lowrisc system (which I believe is representative) the first stage boot loader runs in machine mode, hence PTEs are ignored.

This calls Berkeley Boot Loader (BBL) as a chain loader which also runs in machine mode.

This can then call any payload in supervisor mode but usually this is Linux,

which sets up its own SATP and PTEs very early on in an architecture dependent subroutine.

In virtual memory, the Linux kernel itself will be mapped to the end of memory.

Of course you are free to create PTEs in the boot loader but usually this is treated as romable code and traditionally

is as small and simple as possible to maximise flexibility.

vithurson

unread,
Aug 26, 2018, 6:25:36 AM8/26/18
to RISC-V HW Dev, nmk...@gmail.com, sath...@gmail.com
PMP configurations are done by bbl ?
how about pma s?

Andrew Waterman

unread,
Aug 26, 2018, 2:29:00 PM8/26/18
to vithurson, RISC-V HW Dev, sath...@gmail.com
On Sun, Aug 26, 2018 at 3:25 AM vithurson <nmk...@gmail.com> wrote:
PMP configurations are done by bbl ?
how about pma s?

These systems have read-only PMAs, so no configuration is needed.

vithurson

unread,
Sep 4, 2018, 3:20:14 PM9/4/18
to RISC-V HW Dev, nmk...@gmail.com, sath...@gmail.com
moving forward , in the atomic instructions after a lr is executed to a memory location by the user space application ,the reservation should be done for the virtual addresses or physical address of that address?
if there is a context switching, reservation bit should be cleared by the hardware? or by the os (if so how os takes care of that)?

Andrew Waterman

unread,
Sep 4, 2018, 3:37:22 PM9/4/18
to vithurson, RISC-V HW Dev, Sathya Narayanan N
On Tue, Sep 4, 2018 at 12:20 PM, vithurson <nmk...@gmail.com> wrote:
moving forward , in the atomic instructions after a lr is executed to a memory location by the user space application ,the reservation should be done for the virtual addresses or physical address of that address?

The reservation is logically on physical memory.

It is nevertheless possible to implement the reservation using virtual addresses, but you need to fail the SC when the LR and SC are to two different homonyms (e.g. if the page got remapped under your feet).


if there is a context switching, reservation bit should be cleared by the hardware? or by the os (if so how os takes care of that)?

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

dongle wingle

unread,
Sep 9, 2018, 1:11:06 PM9/9/18
to Andrew Waterman, RISC-V HW Dev, Sathya Narayanan N
thanks. :)
In a single core implementation, for lr/sc implementation is it okay to 
1. have a single XLEN bit register and valid bit which will be  set by a LR's load address
2. SC match that address and return success / failure and then clears the valid bit?


Rishi Khan

unread,
Sep 9, 2018, 1:13:44 PM9/9/18
to dongle wingle, Andrew Waterman, RISC-V HW Dev, Sathya Narayanan N
I don't think so, because I can have two LR before an SC. Like this:
LR A
LR B
SC B ...
SC A ...

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAAYNYsLC%3DT6imVPj4TkqaXftPEB16o0q%2BX6PpqTx43KEBZtqKg%40mail.gmail.com.

dongle wingle

unread,
Sep 9, 2018, 2:32:41 PM9/9/18
to Rishi Khan, Andrew Waterman, RISC-V HW Dev, Sathya Narayanan N
"An SC must fail if there is another SC (to any address) between the LR and the SC in programorder."
So will the second sc ever succeed?

Paul Miranda

unread,
Sep 9, 2018, 3:37:21 PM9/9/18
to RISC-V HW Dev, rish...@gmail.com, and...@sifive.com, sath...@gmail.com
I believe it's meant to read "to any address in the reserved range"... Of course, if your implementation only has one reservation address, then it really is to any address and a livelock is possible if the order of execution never changes.

Rishi Khan

unread,
Sep 9, 2018, 4:36:43 PM9/9/18
to Paul Miranda, RISC-V HW Dev, and...@sifive.com, sath...@gmail.com
Actually, the manual does say that you can't have an LR or SC  in between an LR/SC pair for portable code. So, although my arch accepts it, another compliant arch may disallow such a double locking.

Currently the main use I have for LR/SC is decrement if non-zero (i.e a semaphore). This looks like this:

If (value >0) return value-1;
Else return -1;

With the type of value as int32_t or int64_t.

 I'd be curious to see if others have the same general required instruction sequence and if it makes sense to make that an AMO instruction.

dongle wingle

unread,
Sep 9, 2018, 7:44:23 PM9/9/18
to Rishi Khan, Paul Miranda, RISC-V HW Dev, and...@sifive.com, sath...@gmail.com
hi Rishi,
the manual also says A store-conditional instruction to a scratch word of memory should be used during a preemptive context switch to forcibly yield any existing load reservation.

How you are taking care of this?

Rishi Khan

unread,
Sep 10, 2018, 3:28:56 PM9/10/18
to dongle wingle, Paul Miranda, RISC-V HW Dev, and...@sifive.com, sath...@gmail.com
I am not … in our arch we do not have preemption. However, it seems pretty clear that:
1) the case for recursive LR/SC is tenuous at best
2) it makes for non-portable code
3) things like preemption would need to be dealt with.

It seems that RISC-V is designed to not allow recursive LR/SC pairs, so I’ll retract my previous statement and say that it’s probably a bad idea.

With that said, I think dongle wingle’s approach would work:
In a single core implementation, for lr/sc implementation is it okay to 
1. have a single XLEN bit register and valid bit which will be  set by a LR's load address
2. SC match that address and return success / failure and then clears the valid bit?

However, in the multi-core case, one would also need to consider unsetting the valid bit if another core wrote to the LR address range. That would suggest storing the bit closer to the data and further from the core.
Reply all
Reply to author
Forward
0 new messages