Modify ot_earlgrey to specifically target the Earlgrey 1.0.0 release instead of Earlgrey 2.5.2-RC0

[AlexJones0]

Depends on #159.

This PR contains changes to the OpenTitan QEMU Earlgrey model to specifically target the Earlgrey 1.0.0 release. The intention is then to stop using the existing ot-earlgrey_1.0.0-9.2.0 branch of the QEMU fork. Specifically:

• Update documentation and versioning names referring to EarlGrey 2.5.2-RC0 to instead point to EarlGrey 1.0.0
• Effectively drop support for the "moving/current" Earlgrey target. ot_earlgrey is changed to explicitly support 1.0.0, and moving Earlgrey (i.e. Earlgrey OpenTitan master) is no longer explicitly supported. This change is made both to reduce maintenance burden and due to the limited value of emulation.
• The definitions of the spi_host, clkmgr, entropy_src, pwrmgr and rstmgr are updated on the Earlgrey machine to match the behaviour of these IPs in the earlgrey_1.0.0 release.
• Some hard-coded keys/nonces and TAP ID code definitions are updated.

See the commit messages for more details. Note for review: commit 43a7858 which separates the definitions just duplicate the files and rename with top-specific extensions. Any behavioural changes are then introduced in subsequent commits, to ease the review process.

One open question - this PR introduces a fair bit of duplication. The spi_host and entropy_src definitions are duplicated for small diffs in the register definitions which cannot be trivially handled via a runtime property.

• Splitting the entropy_src makes a fair bit of sense: the register removal shifts the offsets of ~50 registers, and we likely expect it to change more in the moving Darjeeling target in the future.
• Splitting the spi_host is a bit more contentious, as the change comprises just fields in a single register. I'm curious about whether there is potential for a better solution here that I'm missing that can still conform to upstream QEMU standards and avoid the need for conditional compilation.

[jwnrt]

Looks good from my end.

[jwnrt]

Doesn't cfggen extract keys like these from the system verilog for the LC_CTRL and OTP_CTRL? Maybe we can do the same here in the future. Fine for now.

[loiclefort]

Those keys are already extracted by cfggen but the machines still contain default values (that can be overridden by the runtime config file).
Maybe we can remove all keys/nonces/seeds/secrets from the machines source code and provide default config files instead?

[AlexJones0]

Removing the keys from the sources and providing a default config file definitely sounds like a better option, but I'd prefer to leave that to a separate PR to keep this PR more simple and self-contained.

[loiclefort]

Splitting the spi_host is a bit more contentious, as the change comprises just fields in a single register. I'm curious about whether there is potential for a better solution here that I'm missing that can still conform to upstream QEMU standards and avoid the need for conditional compilation

Maybe something like this?

REG32(COMMAND, 0x20u)
    FIELD(COMMAND, CSAAT, 0u, 1u)
    FIELD(COMMAND, SPEED, 1u, 2u)
    FIELD(COMMAND, DIRECTION, 3u, 2u)
    FIELD(COMMAND, LEN, 5u, 20u)
    FIELD(COMMAND, EG100_LEN, 0u, 9u)
    FIELD(COMMAND, EG100_CSAAT, 9u, 1u)
    FIELD(COMMAND, EG100_SPEED, 10u, 2u)
    FIELD(COMMAND, EG100_DIRECTION, 12u, 2u)

and then add a version property and replace all FIELD32_EX(command, COMMAND, XXX) by helper functions like this:

if (s->version == OT_SPIHOST_VERSION_EG_1_0_0) {
    return FIELD32_EX(command, COMMAND, EG100_XXX);
} else {
    return FIELD32_EX(command, COMMAND, XXX);
}

It's not pretty but maybe less maintenance work than a complete fork of the source file.

(alternatively, you could just add some code in ot_spi_host_io_read/ot_spi_host_io_write to swap the fields on the fly then s->version is OT_SPIHOST_VERSION_EG_1_0_0)

[AlexJones0]

Maybe something like this?

That makes sense. I agree that it's not pretty but I also think for a small difference like this it is worth it to reduce maintenance work, whereas I will probably just keep the entropy source split due to potential future changes.

I'll work on that change now and push it to this PR.

[AlexJones0]

@loiclefort I've tried to make the change you suggested. Here is an initial look at what this change would require.

Because the COMMAND register is used in a lot of different places I'm not that sure if this is that much more maintainable. How does it look to you? If you let me know which of the two approaches you think will be better long-term (or if you have any alternative ideas for me to test out) I can change the PR.

[loiclefort]

Because the COMMAND register is used in a lot of different places I'm not that sure if this is that much more maintainable. How does it look to you?

Indeed that's a lot of changes...

What about my other suggestion? We can keep all internal state in "DJ/master" register encoding and convert on-the-fly to EG 1.0.0 encoding in ot_spi_host_io_read/ot_spi_host_io_write when s->version is OT_SPIHOST_VERSION_EG_1_0_0.
For example for the write part:

static uint32_t ot_spi_host_convert_from_eg100_command(OtSPIHostState *s, uint32_t eg_cmd)
{
    uint32_t csaat = FIELD_EX32(eg_cmd, COMMAND, EG_1_0_0_CSAAT);
    uint32_t speed = FIELD_EX32(eg_cmd, COMMAND, EG_1_0_0_SPEED);
    uint32_t direction = FIELD_EX32(eg_cmd, COMMAND, EG_1_0_0_DIRECTION);
    uint32_t len = FIELD_EX32(eg_cmd, COMMAND, EG_1_0_0_LEN);

    uint32_t command = 0;
    command = FIELD_DP32(command, COMMAND, CSAAT, csaat);
    command = FIELD_DP32(command, COMMAND, SPEED, speed);
    command = FIELD_DP32(command, COMMAND, DIRECTION, direction);
    command = FIELD_DP32(command, COMMAND, LEN, len);
    return command;
}

static void ot_spi_host_io_write(void *opaque, hwaddr addr, uint64_t val64,
                                 unsigned int size)
{
 (...)
    case R_COMMAND: {
        if (s->version == OT_SPI_HOST_VERSION_EG_1_0_0) {
            val32 = ot_spi_host_convert_from_eg100_command(s, val32);
        }

        val32 &= R_COMMAND_MASK;
(...)

and the opposite for ot_spi_host_io_read.

[AlexJones0]

What about my other suggestion?

That's a great idea, thanks. I've incorporated that now, and pushed the changes to this PR (you can see the changes here). I think it works out a lot cleaner and the additional conversion for Earlgrey 1.0.0 backwards compatibility seems reasonable.

Actually, the lack of ability to read the command register and the nature of the change (widening the length field, which should be decreasing in nature) should mean that the snippet you provided (with versioning added on top) is sufficient. I'm running some tests right now to check for any regressions, but I definitely think this is preferable over splitting the files for now.

edit: I didn't find any issues with this approach running tests on earlgrey_1.0.0.