Re: [PATCH v4 09/13] hw/riscv: Add Tenstorrent Atlantis machine

[Nicholas Piggin <npiggin@gmail.com>]

On Tue, May 05, 2026 at 02:34:50PM +1000, Alistair Francis wrote:
> On Tue, May 5, 2026 at 11:04 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > On Thu, Apr 30, 2026 at 09:57:34AM +1000, Alistair Francis wrote:
> > > On Sat, Apr 25, 2026 at 11:20 PM Joel Stanley <joel@jms.id.au> wrote:
> > > >
> > > > The Tenstorrent Atlantis platform is a collaboration between Tenstorrent
> > > > and CoreLab Technology. It is based on the Atlantis SoC, which includes
> > > > the Ascalon-X CPU and other IP from Tenstorrent and CoreLab Technology.
> > >
> > > Can you provide a link to documentation
> >
> > Also not presently.
> 
> Hmmm... That's a bit annoying. Can we get some?

That's the plan but I don't have a date I can give you for it, sorry.

[...]

> > > > +static void create_fdt_cpus(TTAtlantisState *s, uint32_t *intc_phandles)
> > >
> > > So generally we only create a device tree for virtual boards, that is
> > > boards that don't really exist and are just QEMU constructs.
> > >
> > > You said that this is based on the "Atlantis SoC" so I assume it's
> > > real hardware. In the real hardware do you expect the device tree to
> > > be provided by the ROM? Usually for boards users supply the device
> > > tree as part of the boot flow (via u-boot or something similar). In
> > > which case should QEMU actually generate this or can users just supply
> > > their own?
> > >
> > > Basically the question is, if you are trying to model the hardware, is
> > > generating the device tree here correct?
> > >
> > > Obviously the advantage of doing it here is then the device tree
> > > describes what QEMU supports, which is great. But that can be harder
> > > to manage when the hardware doesn't do that, as then you have
> > > divergence.
> >
> > We went around this same discussion internally and yeah it's a valid
> > question, we could have explained this a bit better.
> >
> > In the real (unreleased) hardware and the DT will be loaded from ROM.
> 
> Really? That usually doesn't go well

Well not ROM but flash loaded by early firmware. The plan is to have an
"M mode" dtb loaded for opensbi and then later stages supply their own
dtb.

The opensbi dtb won't go away from the tt-atlantis model, whether its
generated or we change it to use a dtb for the purpose of QEMU. I guess
if the next stage does not have its own dtb it can use one supplied by
opensbi.

Does that sound right? I don't know if I have the details exactly right.

> > I think we should do that when the model and firmware and dt is more
> > complete. At the moment it has been easier for development to use QEMU
> > generated fdt.
> >
> > Is that acceptable to do that now and switch to a fdt ROM later...
> 
> Obviously guest software can decide to use whatever it wants. But what
> we don't want to do is break users. So removing the generated FDT
> (which is the equivalent of ROM FDT on hardware) will cause breakages.
> So we don't want to do that if we can avoid it. Also generating the
> FDT is overhead for us, so we only want to if the guest software will
> actually use it. Does that make sense?
> 
> Adding the device tree later is fine though, as guests don't have to use it.
> 
> >
> > [...]
> >
> > > > +static void finalize_fdt(TTAtlantisState *s)
> > > > +{
> > > > +    uint32_t aplic_s_phandle = next_phandle();
> > > > +    uint32_t imsic_s_phandle = next_phandle();
> > > > +    void *fdt = MACHINE(s)->fdt;
> > > > +
> > > > +    create_fdt_cpu(s, s->memmap, aplic_s_phandle, imsic_s_phandle);
> > > > +
> > > > +    /*
> > > > +     * We want to do this, but the Linux aplic driver was broken before v6.16
> > > > +     *
> > > > +     * qemu_fdt_setprop_cell(MACHINE(s)->fdt, "/soc", "interrupt-parent",
> > > > +     *                       aplic_s_phandle);
> > > > +     */
> > >
> > > And now we are stuck with hacks like this, which we really don't want
> > > to be dealing with. Maybe it's best to leave the device tree to the
> > > kernel.
> >
> > ... Despite issues like this?
> 
> If the kernel generates a device tree for it to use then we don't have
> mismatched problems (like this one). Generating the DT in QEMU for
> real boards proves to be a challenge and this is exactly why. Now we
> have to choose between pre or post 6.16 support (I assume 6.16+ works
> without this, but you get the point).

Yeah I see do see why we'd want a Linux one, and we are currently
upstreaming dts for Linux. At the moment we don't have it so using
the firmware stage one fills the gap.

It is a little bit hacky maybe but I guess I'm not seeing where a
compatibility problem comes in versus other systems with their own
firmware DTB (that I assume a next-stage could similarly use and be
exposed to these issues if it did not supply its own).

Thanks,
Nick