riscv_sim: Add command line arguments to enable or disable use of boot ROM. #199
Conversation
|
I think this could be very useful for normal usage, why is it not a run time option ? |
|
I could have made it a run time option but decided that whether you want it or not might depend on the emulator you are building more than on the particular invocation. This way means you don't have to specify a command line argument every time you run the emulator if you never want the boot ROM. I could make it a command line option but have a compilation option to change what the default is? I thought I'd better keep the default as using the boot ROM to maintain backwards compatibiltiy. |
|
What’s the purpose? In effect the boot ROM is just a software implementation of setting a specific reset state? |
|
I'm not sure but I suspect it was for compatibility with Spike. |
This comment has been minimized.
This comment has been minimized.
…t ROM. This adds command line arguments --boot-rom and --no-boot-rom to enable or disable the use of the boot ROM at the reset vector. The current behaviour (--boot-rom) initialises a small bit of memory at the reset vector to set up argument registers and then jump to the address specified by entry point of the ELF file. With --no-boot-rom the simulator just sets the initial PC to the entry point. For backwards compatibility the default is to use the boot-rom unless NO_BOOT_ROM is defined during compilation.
|
Any thoughts on this revised version with command line arguments? |
jrtc27
changed the title
|
I still don't understand why it's needed, given the only side-effect is what state a handful of GPRs reset in and that's entirely undefined by the ISA. And I guess also instret. I also really don't like having a configurable default, that's how you end up with confusion and things working on one machine but not another. |
|
I looked at this when I was working on the model configuration stuff (see
PR #175)
and have some thoughts. (Quick synopsis of the PR: to configure the
model, I
converted the command-line-switch method with a method that reads the
RISCV-Config
YAML files. The YAML files are used by the ACT group when configuring the
compatibility tests.
I'd like to be consistent between the Sail and ACT groups when it comes to
configuration. Also,
the number of command line switches is going to grow very, very large over
time. Consider
how one needs to configure the many WARL fields in the model.)
First, it was confusing to look at the log file and see code being
executed that wasn't in
the .elf file. It took a while to figure it out.
Second, this should not be a compile time setting; it needs to be
run-time (ie - a command
line switch). Customers may (will) have multiple cores, some with boot
ROMS, some without.
They don't want to manay multiple versions of the riscv_sim executable.
Third, if there is a boot ROM, then the code should be compiled and
loaded in a similar way
that the RAM is loaded. This method should be consistent for all code that
is pre-loaded into
the memory model(s).
Fourth, when working on the configuration stuff, I simply made the
starting address configurable
from the YAML file; I didn't bother with removing the bit of code that
creates the several instructions
that get put into ROM. This allowed the loaded code to be the only thing
that gets executed; the
ROM code is bypassed. I think that the ROM code initialization needs to
be removed.
Those are my thoughts at the moment.
Bill Mc.
…On Wed, Jan 11, 2023 at 3:40 AM Robert Norton ***@***.***> wrote:
Any thoughts on this revised version with command line arguments?
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXROLOG7OR7I6YM2UBBO3ULWRZ5Z7ANCNFSM6AAAAAATW4DHLM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Bill McSpadden
Formal Verification Engineer
RISC-V International
mobile: 503-807-9309
|
|
If you stop providing a baked-in boot ROM like you suggest and force the user to explicitly provide one then you're going to make it a total pain to use the model for running real software, which expects the de-facto entry state of a0 == hartid, a1 == dtb_addr. |
|
I'm not sure how the de-facto entry state became de-facto, or why.
It certainly isn't required by the RISC-V spec, and the architectural
compatibility tests don't depend on it - which is a primary use case of the
Sail model.
If it's important to run real software that depends on it, then, yes, a
model running real software has to provide those few instructions
themselves.
The extra work involved in doing that is tiny compared to the real software.
We should have nothing in the Sail model that requires initialization
outside of those that the spec requires or allows
(specifically, that latter would be CSR WARL fields in the PMP only, I
think).
I'd rather see the opposite: any use of gprs or CSRs that have not been
explicitly written or have spec'ed reset values signal an error
(where use means some operation that could cause differing states. This is
equivalent to implementing "X" states in other simulators
(I am NOT expecting this is be taken seriously!)
…On Wed, Jan 11, 2023 at 8:06 AM Jessica Clarke ***@***.***> wrote:
If you stop providing a baked-in boot ROM like you suggest and force the
user to explicitly provide one then you're going to make it a total pain to
use the model for running real software, which expects the de-facto entry
state of a0 == hartid, a1 == dtb_addr.
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVNF7SC6XE7FO2TTCLWR3K7RANCNFSM6AAAAAATW4DHLM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Because that's what Spike/Rocket/etc did in the early days and now BBL and OpenSBI assume that for their generic firmware builds. The harder you make it for users to run that kind of software the less likely it is people will take the Sail model seriously and will instead continue to use Spike. |
|
I think I'd rather file a bug against BBL and OpenSBI.
But I find it unlikely that real silicon will have that baked in, and if
they don't, then they have a boot ROM and they can simply provide that to
Sail as an image that gets loaded, as Bill suggested.
…On Wed, Jan 11, 2023 at 12:15 PM Jessica Clarke ***@***.***> wrote:
Because that's what Spike/Rocket/etc did in the early days and now BBL and
OpenSBI assume that for their generic firmware builds. The harder you make
it for users to run that kind of software the less likely it is people will
take the Sail model seriously and will instead continue to use Spike.
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJQM7NYEPIU5B7CQFQDWR4IGRANCNFSM6AAAAAATW4DHLM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
How then do you propose the right FDT be provided to firmware? Because it's the Sail model that knows what its configuration is, not firmware. |
|
There also may not be "real silicon"; for your use, you want Sail to be configured to match a specific DUT, but from a software development perspective you don't care about DUTs or boot ROMs, you just want to run the model, possibly with some extensions explicitly enabled or disabled, and test your software. |
|
a. That's the whole point of Unified Discovery (which isn't there yet).
b. if we build it into Sail, then you have the opposite problem when you
try to run it on real HW that has the FDT somewhere else.
(and if that's not a problem because everybody puts the FDT in the same
place, then it should be speced by RV)
c. If it's important to firmware, then there will be a boot image that
initializes those registers and runs right out of reset.
I fail to see why that is unworkable or onerous - that's what a real
bootROM would do, and there is no need to build that into SAIL.
A software development project will eventually need to run on real silicon,
and likely will have a boot ROM
(almost certainly much larger than the half dozen instructions we are
talking about here; the boot flow for high end processors is not a trivial
process).
If it requires that we come up with some default bootROM that gets run if
no other bootROM is specified, then we could provide default bootROM -
but not as part of, or built into Sail. It should be no different than one
provided by a manufacturer.
The mechanism of loading that image into Sail should be built in, though.
…On Wed, Jan 11, 2023 at 12:28 PM Jessica Clarke ***@***.***> wrote:
There also may not *be* real hardware; for *your* use, you want Sail to
be configured to match a specific DUT, but from a software development
perspective you don't care about DUTs or boot ROMs, you just want to run
the model, possibly with some extensions explicitly enabled or disabled,
and test your software.
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJQI5YMO3OWPEG3CTCTWR4JXZANCNFSM6AAAAAATW4DHLM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I don't understand this point. Software doesn't care where the FDT is in memory, it gets told that by the boot ROM.
The boot image that initialises those registers and runs right out of reset is what's there in the Sail model today.
But that boot ROM isn't appropriate for the Sail model, because, as you say, it's doing other microarchitecture-specific initialisation.
I don't see how you can provide something and have built-in loading of it yet not have it be part of the model. Where's it living if not here when its contents needs to be generated based on the user-provided arguments to the model? |
|
I suspect we are talking past each other a lot. We both have different
interpretation of how the Sail environment is or will be used.
We may even be agreeing with each other, but using the wrong terminology.
Part of this misundersatnding is our primary use case, which is comparing
what a DUT executes vs. what a Sail model that is configured identically
does.
We want the Sail model to match the architectural spec that mandates that
only a very small set or architectural state is guaranteed to have any
specific value.
The riscof framework does have the concept of hart configuration, which
include CSR reset values - encompassing part of what you are looking for.
HartD is one of those values.
It also has the concept of platform configuration (non-architectural
values), e.g.
- where the interrupt controller registers are located,
- where the base of DRAM is located
- what the reset vector is
These two are defined in a pair of YAML formatted files .
We don't have the concept of GPR reset values, on the other hand, and I
don't think we want to do that.
If a design will be reused some other SOC -you'd need to modify the core if
those register value would differ, and that's pretty ugly in an OOO machine
A small boot ROM could do that, though, and that's the approach we believe
should be taken
Bill and I agree we want to be able to load a bootROM that is provided to
the implementation, and start executing it at the reset vector.
So, the mechanism to load a boot image is needed - but contents of the boot
image should not be part of the Sail model; it comes externally.
We could have a boot image that is "standard"] or default - but, it's not
built in, it's loaded just like any other boot image, as an ELF formatted
bit of code.
We could have an entire directory full of different boot images for
different use cases, and our platform configuration YAML can point to the
one that gets loaded.
To me, that sounds like a very powerful, very versatile mechanism that
would handle virtually any use case.
So.. what is the downside?
…On Wed, Jan 11, 2023 at 12:46 PM Jessica Clarke ***@***.***> wrote:
b. if we build it into Sail, then you have the opposite problem when you
try to run it on real HW that has the FDT somewhere else.
(and if that's not a problem because everybody puts the FDT in the same
place, then it should be speced by RV)
I don't understand this point. Software doesn't care where the FDT is in
memory, it gets told that by the boot ROM.
c. If it's important to firmware, then there will be a boot image that
initializes those registers and runs right out of reset.
I fail to see why that is unworkable or onerous - that's what a real
bootROM would do, and there is no need to build that into SAIL.
The boot image that initialises those registers and runs right out of
reset is what's there in the Sail model today.
A software development project will eventually need to run on real silicon,
and likely will have a boot ROM
(almost certainly much larger than the half dozen instructions we are
talking about here; the boot flow for high end processors is not a trivial
process).
But that boot ROM isn't appropriate for the Sail model, because, as you
say, it's doing other microarchitecture-specific initialisation.
If it requires that we come up with some default bootROM that gets run if
no other bootROM is specified, then we could provide default bootROM -
but not as part of, or built into Sail. It should be no different than one
provided by a manufacturer.
The mechanism of loading that image into Sail should be built in, though.
I don't see how you can provide something and have built-in loading of it
yet not have it be part of the model. Where's it living if not here when
its contents needs to be generated based on the user-provided arguments to
the model?
—
Reply to this email directly, view it on GitHub
<#199 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJW3LZF5P3APU37PW53WR4LZZANCNFSM6AAAAAATW4DHLM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
ptomsich
added
tgmm-agenda
|
Proposed next steps from the discussion in the TGMM on May 30th:
From the discussion in the meeting, the consensus on what we might want (of course, this is just a sketch and not a detailed design and rationale as it may emerge after a thorough discussion) was:
@jrtc27 Let me know if this is a sensible approach from your perspective? |
riscv_sim: if NO_BOOT_ROM is defined then don't use a boot ROM at the reset vector, but set initial PC to elf_entry.
This provides a compilation option to avoid using the small hardcoded boot ROM at the reset vector and instead start execution directly from the the entry point specified by the ELF file.