I am under the impression, mistaken as it may be, that this is a platform specific definition, just as the reset vector is.
I am charged with defining it for our implementations, as it turns out.
The two obvious options are that every HART starts executing at reset (and they can find out their own ID and diverge), or that only HART#0 starts, and it is responsible for kickstarting the others.
This slightly begs the questions of
- how does it even know there are other HARTs, how many, and what their HART IDs are? Obvious choices:
baked into the boot ROM
baked into the config string
- even if it knows, how does it start them running? Obvious choices:
the others reset into a WFI state, so an IPI wakes them
There is a magic MMIO locations that starts them running
(not that IPIs are also writes to a platform defined MMIO locations
- where do they all start running? Obvious choices:
reset vector
some other fixed location
configurable by HART 0
at the SW interrupt vector location (in the case of WFI and IPI)
All of these will work; which is best depends on the application and specific platform features, of course.
When you ask about stopping a HART - do you mean how a HART can stop itself, or how some other HART can cause it to suddenly stop? A HART can stop itself with a WFI.
Reaching and and stopping it externally would be a custom platform feature (possibly as simple as an IPI to a handler that performs a WFI, or a drastic as an MMIO write that causes it clock to stop or something).
Defining how to work out if a HART is free to execute code: are you asking how you know which HARTs are implemented, or how a master process can figure out which HARTs that it knows about are available to assign to a task?
The former is discussed above, and the latter sounds like a standard OS feature,
At 12:52 PM +0200 11/12/17, Liviu Ionescu wrote:
>--
>You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
>To post to this group, send email to isa...@groups.riscv.org.
>Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
2) What are the interrupt enable flags defined to be coming out of reset? and does an implementation need a mechanism to change the interrupt enable flags and trap vector of a remote hart?
3). How do we reset a particular remote hart? Some implementations may define a PRCI (Power, Reset, Clock, Interrupt) MMIO region to allow a given hart to be reset. Should this be standardized? I believe it should be.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
>> To post to this group, send email to isa...@groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/B3AA8382-2464-4221-B44F-11C79D72859A%40livius.net.
>
>
> --
> **************************************************
> * Allen Baum tel. (908)BIT-BAUM *
> * 248-2286 *
> **************************************************
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/p0624084ad62e5e7d0174%40%5B192.168.1.50%5D.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/7FCF6BDF-33A5-488B-831B-6D0C551A040B%40mac.com.
On 13 Nov 2017, at 00:40, Michael Clark <michae...@mac.com> wrote:1) What is the upper limit on the time bound between the first and last harts executing the reset vector. This should be (implementation/specification) defined? A time limit is required to find out all harts that are present, as they might come out of reset at different times.
2) What are the interrupt enable flags defined to be coming out of reset? and does an implementation need a mechanism to change the interrupt enable flags and trap vector of a remote hart?
3). How do we reset a particular remote hart? Some implementations may define a PRCI (Power, Reset, Clock, Interrupt) MMIO region to allow a given hart to be reset. Should this be standardized? I believe it should be.
according to the actual specs, it looks like every hart starts executing at reset.
the reset address is device specific, and it is not required for the addresses to be different, so for a smp device I would expect all harts to start the same code and one of them (probably hart 0) to take the lead, all the other enter in a form of sleep.
>> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
>> To post to this group, send email to isa...@groups.riscv.org.
>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/B3AA8382-2464-4221-B44F-11C79D72859A%40livius.net.
>
>
> --
> **************************************************
> * Allen Baum tel. (908)BIT-BAUM *
> * 248-2286 *
> **************************************************
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/p0624084ad62e5e7d0174%40%5B192.168.1.50%5D.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/7FCF6BDF-33A5-488B-831B-6D0C551A040B%40mac.com.
I'm pretty much agreeing with Andrew here:The configuration should be determined by reading the config string ( at an implementation defined address).You can't set a timeout because some HARTs maybe be powered off or clock disabled (which contradicts Liviu's assertion that"according to the actual specs, it looks like every hart starts executing at reset."I think the spec says that only HART ID0 is required to run at reset:"In certain cases, we must ensure exactly one hart runs some code (e.g., at reset), and so require one hart to have a known hart ID of zero."The spec says only that, at reset:priv_mode <-- Mmstatus.MIE <-- 0mstatus.MPRV <-- 0PC <-- (implementation defined value)mcause <-- (0 or implementation defined values indicating type of resetand all other state is undefined (though I think the wording should be "not specified", as "undefined" has a pretty specific meaning when you're taping out a chip).I actually don't like the idea for all HARTs to start executing all at the same time, primarily because that will cause possibly unpleasant current inrush.True story: the Apple Newton had an issue that, when the battery was low, waking it up would cause enough current inrush to drop the supply voltage, which signalled a low-voltage battery condition that would put it to sleep - at which point voltage recovered and it would try to wake up again.... until it totally drained the battery and couldn't.The software fix was to start it in slow clock mode and gradually ramp it up.Having multiple HARTs multiplies that issue.Better to either stagger wakeup, or just leave them powered off/unclocked, or both.Putting my RAS hat on - if you only wake up one HART - how do you select which one to wake? If it is always HART zero, you now have a single point of failure- especially since HART 0 is required to exist.There are solutions, but it seems to me that HART ids should not be fixed in HW if you want to avoid that problem. Since The HART ID CSR is in a read_only region, I would infer that some backdoor access is required to change it with HW sequencer support.
At 2:58 PM -0800 11/12/17, Andrew Waterman wrote:
On 13 Nov 2017, at 02:08, Allen J. Baum <allen...@esperantotech.com> wrote:I'm pretty much agreeing with Andrew here:The configuration should be determined by reading the config string ( at an implementation defined address).
You can't set a timeout because some HARTs maybe be powered off or clock disabled (which contradicts Liviu's assertion that"according to the actual specs, it looks like every hart starts executing at reset."I think the spec says that only HART ID0 is required to run at reset:"In certain cases, we must ensure exactly one hart runs some code (e.g., at reset), and so require one hart to have a known hart ID of zero."The spec says only that, at reset:priv_mode <-- Mmstatus.MIE <-- 0mstatus.MPRV <-- 0PC <-- (implementation defined value)mcause <-- (0 or implementation defined values indicating type of resetand all other state is undefined (though I think the wording should be "not specified", as "undefined" has a pretty specific meaning when you're taping out a chip).
I actually don't like the idea for all HARTs to start executing all at the same time, primarily because that will cause possibly unpleasant current inrush.
... it seems to me that HART ids should not be fixed in HW if you want to avoid that problem.
Hart 0 starts at reset, but how do you start other harts executing, stop them, work out if you have a hart free to execute code on, etc.? I can't find where this is documented.Thanks in advance :-)
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/58c862c4-99f0-4ed5-890e-91b12cdd602f%40groups.riscv.org.
regards,
Liviu
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/2FA586F5-E9FE-497A-B15C-60C69CFE53EB%40livius.net.
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CC5F2F6A-BFF6-41A3-9E21-C9056699A678%40esperantotech.com.
mstatus.MIE is 0 out of reset; the rest is unspecified.
(question about IPI: your slides say:
- One hart can write to different hart's MSIP register
- Mechanism for inter-hart interrupts.
But MSIP is a bit in the MIP CSR - are you saying that from an MMIO point of view,
-there is a address corresponding to just that bit, as opposed to writing the entire CSR?
- Or would an AMOOR to the MIP MMIO view what is expected
- Or is it simply completely implementation dependent?
At 2:58 PM -0800 11/12/17, Andrew Waterman wrote:
mstatus.MIE is 0 out of reset; the rest is unspecified.
What I would like to do is have a core come out of a full reset in WFI state, and have some other core wake it up with an IPI(question about IPI: your slides say:- One hart can write to different hart's MSIP register- Mechanism for inter-hart interrupts.But MSIP is a bit in the MIP CSR - are you saying that from an MMIO point of view,-there is a address corresponding to just that bit, as opposed to writing the entire CSR?- Or would an AMOOR to the MIP MMIO view what is expected- Or is it simply completely implementation dependent?
- is there anything in the spec that prohibits waking up from reset in a WFI state?
- if is woken up, what is the next instruction it should execute?Reset vector? Reset vector+4 (since execution will resume at pc + 4, and the PC is initialized to the reset vector)?
- MIE is clear at reset. But WFI wakeup ignores xIE, ignores xDELEG, and only pays attention to xSIP/xTIP/xEIP iff the corresponding xSIE/xTIE/xEIE bits are set- or at least that is how I am interpreting the spec.This implies that MSIE most also be set to one in the WFI core at reset.I believe setting the initial state of MSIE=1 is legal to implement (i.e. not prohibited, left up to implementation)