hwmv2: convert SiFive and RISC-V QEMU boards

[fkokosinski]

Targets in question:

• hifive1
• hifive1_revb
• hifive_unleashed
• hifive_unmatched
• qemu_riscv32_xip
• sparkfun_red_v_things_plus

Converted to:

west build -p -b hifive1 samples/hello_world -t run
west build -p -b hifive1@B samples/hello_world -t run
west build -p -b hifive_unleashed samples/hello_world -t run
west build -p -b hifive_unmatched samples/hello_world -t run
west build -p -b sparkfun_red_v_things_plus samples/hello_world
west build -p -b qemu_riscv32/fe310/xip  samples/hello_world -t run

Edit:
I see that two targets also use SoCs from the FE300 SoC series: qemu_riscv32_xip and sparkfun_red_v_things_plus. I'll start porting them right away. Done.

[nordicjm]

Ha, just as I had finished porting hifive1 and revb!

[fkokosinski]

Hi @nordicjm, I've addressed you comments. PTAL :)

[nordicjm]

Minor nit.

[fkokosinski]

Hi @nordicjm, I've addressed your 2nd round of comments. PTAL

[nordicjm]

Looks good, thanks, should hear back about the privileged riscv part tomorrow

[gmarull]

update docs/maintainers as needed

[nordicjm]

Rebase needed

[nordicjm]

We are planning to have the value and name of this linked in future: #69317
But this raises an interesting issue @tejlmand because if just "e300" is used, that's so generic it's bound to have a name clash in future

[fkokosinski]

We could expand the e300 to be more verbose and include the SoC family name, i.e. sifive_freedom_e300 (with vendor) or freedom_e300 (without vendor).

[nordicjm]

It's a future thing, e300 is fine for now but yes in future might have to expand it

[tejlmand]

It's a future thing, e300 is fine for now but yes in future might have to expand it

I think current proposal is fine.
If we're later going to use those values internally, like we do the the CONFIG_SOC, then we should be generating those.
Just like we do for boards.

But there are a couple of reasons this is not done in first iteration of hwmv2, so let's not worry to much now.
But thanks for raising awareness on this @nordicjm 👍

[nordicjm]

qemu_virt_riscv32 and qemu_virt_riscv64 should probably become one board and use variant to specify which one is being built where no variant = 32-bit and variant "64" = 64-bit, thoughts @gmarull @aescolar ?

[fkokosinski]

I don't have a strong preference on this. But if we go ahead and convert them to a single board with variants, I suppose that qemu_virt_riscv32e should also be included in the process?

[tejlmand]

initial feeling is that it's the SoC which is either 32 bit or 64bit, and thus you select the SoC of the arch you want.
Thus the board indirectly select 32 / 64 bit based on the SoC it selects.

Not the board which should directly select 32 or 64 bit.

[fkokosinski]

Btw. our runners seem to be experiencing some problems:

The self-hosted runner: zephyr-runner-linux-x64-4xlarge-deployment-g2tcl-lwwnp lost communication with the server. Verify the machine is running and has a healthy network connection. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error.

I'll wait a bit before restarting the workflow to not flood the whole thing with more workload while it's not responding.

[fkokosinski]

OK, the CI now only reports one error that looks unrelated to this PR:

tests/subsys/mgmt/mcumgr/os_mgmt_info/mgmt.mcumgr.os.info.bt (nrf9160dk/nrf52840:tests/subsys/mgmt/mcumgr/os_mgmt_info/mgmt.mcumgr.os.info.bt) with error

Addressed

[nordicjm]

Also rebase will fix the test failure

[nordicjm]

Thanks for port!