Docsite content: update Supported Platforms page

[june-andronick]

Update the https://docs.sel4.systems/Hardware/ page to make sure it's consistent, up to date, and with an easy high-level take-away for a wider audience.

• add an exec summary at the very top: x86, ARM, RISC-V; maybe also saying whether it's 32 and 64 bits; maybe be clear about the situation for MCS / multicore; maybe linked from seL4 main website?
• add link to the "verified configurations" page
• make things consistent across the page / other pages
  • IOMMU vs SMMU vs System MMU
  • the RISC-V table header should be bold and grey
  • "in progress" vs "pending" for the verification status
  • ARM HYP vs ARM Hyp
  • "status" in the table should be "verification status" to be clearer
• for verification status: do we ignore SysInit? BV?
• what is the "pending" Ariane RISC-V?

[lsf37]

• IOMMU vs SMMU vs System MMU

We should make SMMU/System MMU consistent, but IOMMU is the name for the x86 mechanism, and SMMU is the name for the Arm mechanism, so those should stay separate, i.e. the table header for Arm should become SMMU, but the one for x86 should stay IOMMU, I think.

• "status" in the table should be "verification status" to be clearer

Could be too long for the table header, at least I remember playing around with that and not changing it.

• for verification status: do we ignore SysInit? BV?

Yes, I think that's too much detail for this table. We should think a bit more about how to represent the verification status here, because that is going to get more complex as more verified platforms are being added with various differing feature sets.

• what is the "pending" Ariane RISC-V?

We should remove that. It was going to be the eventual verification target for RISC-V MCS. Ariane is the ETH implementation of RISC-V and the chip HC was going to use (or still is, unclear to me). There is an Ariane config for seL4, but no physical board that the foundation has.

[june-andronick]

This made some progress. Still on my list to do (most in discussion w @lsf37):

• find a way to indicate which ones are tested, which boards have simulators (maybe which seL4 release)
• add the generic simulators
• decide if we present the unmaintained in a separate table
• instructions on what to do if the board you want is not in the list (see Docsite content: hardware: instructions if board not in the list #316)
• small improvements (incl ones raised by @Ivan-Velickovic)

[june-andronick]

Also needed:

• make the page more visible (probably after the information architecture restructure)
• think about how to make sure it stays maintained

[Indanz]

Comparing the machine queue systems with the webpage, I notice the following differences:

• mq has a star64 | riscv | riscv64 | StarFive JH7110 | SiFive U74-MC, which is not on the website.
• The website has Microchip PolarFire Icicle Kit, but that's not in the list of mq systems.
• tqma is missing from the website (I can make a PR for that one).
• xavier_1 | arm | armv8-a | Xavier NX | Nvidia Carmel is missing from the website.
• The website mentions rocketchip twice, it's the same RISC-V CPU on different FPGAs.

I think it's worth making it clearer when some platforms are softcores implemented on an FPGA.

[Ivan-Velickovic]

mq has a star64 | riscv | riscv64 | StarFive JH7110 | SiFive U74-MC, which is not on the website.

There's a PR for it seL4/docs#181 but it shouldn't be merged until seL4/seL4_tools#174 and seL4/util_libs#167 are merged.

• xavier_1 | arm | armv8-a | Xavier NX | Nvidia Carmel is missing from the website.

It's not supported by seL4 currently.

[june-andronick]

Thanks @Indanz and @Ivan-Velickovic. I've been comparing (1) the hardware listed on https://docs.sel4.systems/Hardware/ and (2) hardware listed on https://github.com/seL4/ci-actions/blob/master/seL4-platforms/platforms.yml (which I thought would be equivalent to the machine queue, but I'm missing some of the ones mentioned by @Indanz). The aim (discussed with @lsf37) is to find a way to generate another column in the table in (1) to tag boards that are not under CI/test (plus fix any discrepancies between (1) and (2)).

• 2 are listed in (1) as unmaintained and appear w no_hw_build in (2): Arndale and Inforce

  • We should maybe list unmaintained boards in a separate table, or really highlight in some way that they are unmaintained . Yes?

• 6 are listed in (1) as maintained but absent from (2):

  • maintained by Foundation: ARM TK1-SOM; RISC-V Rocketchip (no Virt)
  • maintained by DW: ARM Ultra96v2 Evaluation Kit; RISC-V Microchip; RISC-V Rocketchip (w Virt)
  • maintained by HC: RISC-V Ariane
  • For the Foundation ones: why aren't they in (2)? is it equivalent to being listed in (2) as disabled (see below) and should therefore be tagged as not under CI/test?
  • For the others, should we also just tag them as not under CI/test?

• 8 are listed in (1) but disabled in (2):

  • maintained by capgemini: ARM Avnet MaaXBoard
  • maintained by Foundation: ARM HiKey, ARM OdroidX, ARM OdroidXU, ARM
    Raspberry Pi 3-b, ARM Raspberry Pi 4B, ARM Zynq-7000 ZC706 Ev Kit
  • For the Foundation ones: should we just tag them as not under CI/test?
  • For the capgemini one: why does it appear under (2)? should we also just tag them as not under CI/test?

• 5 are not listed in (1) but appear in (2) (as disabled) without simulation_binary tag:

  • ARM: QUARTZ64, TQMA8XQP1GB, WANDQ (imx6), ALLWINNER20, IMX7SABRE
  • I understand that TQMA is meant to be added. What about the others? Should they be added to (1) too, and flagged as not under CI/test?

• 5-6 have the simulation_binary tag on:

  • appear in (1) (and (2)): ARM Sable Lite, RISC-V Spike (SPIKE32 and SPIKE64)
  • appear only in (2): ARM ARMVIRT (qemu), RISCVVIRT64 (qemu), RISCVVIRT32 (qemu)
  • Should we add all 3 above to the list in (1) as simulators?

• @Indanz additionally mentions Star64 and xavier_1 which I don't see in (2).

  • Why aren't these in (2)? Any other differences between (2) and mq?

[june-andronick]

@Indanz @lsf37 @Ivan-Velickovic Can you please let me know about my questions in bold above? Thanks :)

[Ivan-Velickovic]

We should maybe list unmaintained boards in a separate table, or really highlight in some way that they are unmaintained . Yes?

Yes, I think a separate unmaintained list would be better.

For the Foundation ones: why aren't they in (2)? is it equivalent to being listed in (2) as disabled (see below) and should therefore be tagged as not under CI/test?

Not being listed in the platforms.yml is equivalent to being listed in platforms.yml and having the no_hw_build option being true. So yes, they should be tagged as not tested in CI.

For the others, should we also just tag them as not under CI/test?

Yes

I understand that TQMA is meant to be added. What about the others? Should they be added to (1) too, and flagged as not under CI/test?

To my knowledge we do not own any of the other boards and so they cannot be placed under (2).

Should we add all 3 above to the list in (1) as simulators?

Yes.

Why aren't these in (2)? Any other differences between (2) and mq?

Star64 has PRs that need to be merged first before we can put it in (2). xavier_1 is not supported at all by seL4 and so should not be in (1) or (2).

Hope this helps.

[Ivan-Velickovic]

(regarding the xavier_1, what I meant is that TS bought the platform and put it in machine queue but we never finished porting it to seL4 and so that's why there's no support in seL4 for it but it's in machine queue)

[june-andronick]

Many thanks @Ivan-Velickovic , that is very helpful.

• I have separated the unmaintained platforms: hardware: separate the unmaintained platforms docs#223
• I will work on a "no in CI" tag
• for the simulators: **how should I add them? manually adding lines or creating a new page under the 'hardware' folder with the info in the headers so it could be extracted?

[Ivan-Velickovic]

how should I add them? manually adding lines or creating a new page under the 'hardware' folder with the info in the headers so it could be extracted?

I think the 'hardware' folder should instead be called platforms probably and we should probably have a page for each simulator. While the simulators might be more self-explanatory than hardware platforms, I think it's still worth it to have a dedicated page for each perhaps including things such as:

• An outline of the default configuration that we use for the simulators.
• Links to the relevant documentation (e.g https://www.qemu.org/docs/master/system/riscv/virt.html for RISC-V).
• Instructions for running sel4test just like all the other platforms.