Re: [PATCH] dt-bindings: soc: Add new board description for MicroBlaze V

[Michal Simek]

On 11/9/23 09:36, Krzysztof Kozlowski wrote:
> On 08/11/2023 11:11, Michal Simek wrote:
> > > I meant that creating a binding for something which is not and will not
> > > be a product does not bring any benefits. Why do we even care to
> > > document it? Who requires it? I don't. I don't see DTS or driver, no
> > > need for compatible.
> > >
> > > That's why entire discussion starts with DTS (and/or driver).
> >
> > We have dt description for soft IPs like uartlite
> > Documentation/devicetree/bindings/serial/xlnx,opb-uartlite.yaml
> >
> > We have 16550 compatible IP with
> > Documentation/devicetree/bindings/serial/8250.yaml
> >
> > Simple ethernet core
> > Documentation/devicetree/bindings/net/xlnx,emaclite.yaml
> >
> > Axi ethernet
> > Documentation/devicetree/bindings/net/xlnx,axi-ethernet.yaml
> >
> > Adi clock generator
> > Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
> >
> > Adi fan control
> > Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yam
> >
> > Adi adcs
> > Documentation/devicetree/bindings/iio/adc/adi,axi-adc.yaml
> >
> > and much more.
> >
> > They are IPs from vendor catalogs. We can talk if it is a product (definitely
> > yes if you need to buy it for your design). But all of them fit to the same
> > category that you are composing your HW design with them.
> > All of them as standalone can't run. You will never create a product with just
> > uartlite IP. You need to add cpu, clocks, reset logic and others around to make
> > a product out of it.
> >
> > Our mental model is HW designer create new IP, we are writing driver for it,
> > customers can buy it (or get it for free) and use it.
> > They put it to their design, create custom board and sell it as a product.
> >
> > And in this particular case HW designed create risc-v compatible CPU.
> > I expect this should fine
> > https://lore.kernel.org/r/d442d916204d26f82c1c3a924a4cdfb117960e1b.1699270661.git.michal.simek@xxxxxxx
> >
> > And discussion what we are having is pretty much about how to share the view on
> > the system.
>
> That's different category. All of these are part of SoC. Here we talk
> about the SoC and I had impression that you added compatible for the SoC
> alone.
>
> > > > > I spoke to Palmer a bit about this, and what I think would make sense is
> > > > > if you had some sort of "reference design" bitstream that people could
> > > > > download and run on xyz AMD devkit. If that existed, then we could
> > > > > document that configuration etc. Otherwise you're in the same spot that
> > > > > a lot of IP vendor stuff is, where without there being something that
> > > > > qualifies as "real hardware" using the core, it doesn't make sense to
> > > > > try and create bindings etc. It's the same for the various people in
> > > > > the RISC-V community that created their own CPUs that they run on FPGAs.
> > > >
> > > > Aren't all ARM FVP models enabled by SW before soc vendors put them to a real
> > > > chip? Is there any real product available at that time?
> > >
> > > FVP also finished one. They do not claim they added compatible for a SoC
> > > or CPU. And that's my impression here.
> >
> > Are these real chips?
> >           compatible = "arm,foundation-aarch64", "arm,vexpress";
> >           compatible = "arm,fvp-base-revc", "arm,vexpress";
> >
> > FVP are Fixed Virtual Platforms. Pretty much emulators similar to QEMU.
>
> If your case is this one, then few parts of description should be
> rephrased in the bindings.

Let me comment this below.

> > > > I will try to find out if there is any official plan for releasing any reference
> > > > design against any evaluation board with commitment to supporting it.
> > > >
> > > > > > > Or I can define qemu one.
> > > > > > > "amd,qemu-mbv", "amd,mbv"
> > > > > >
> > > > > > QEMU is not hardware, so not.
> > > >
> > > > I am still trying to wrap my head around it. In qemu we are actually going to
> > > > create model for this configuration but based on what you are saying here we
> > > > shouldn't really have DT which describes it.
> > > > That's why we likely end up in situation that qemu create DT description self,
> > > > put it to memory and u-boot/kernel will consume it. The only difference is going
> > > > to be that DT will be used but won't be checked against dt-schema.
> > > > I personally prefer to have DT pass dt-schema checking and tell qemu guys, this
> > > > is what qemu should generate.
> > > > But if you think that this is wrong approach I will let them generate whatever
> > > > they want and will just check functionality. It means u-boot won't have DT,
> > > > Linux won't have DT and I am done.
> > >
> > >
> > > Sorry, I am confused now. Are we talking about real hardware or QEMU SW
> > > model? Your description clearly said:
> > > "AMD boards with MicroBlaze V SOC"
> > > so QEMU is not a board. Board has a physical form, a shape. Usually flat.
> >
> > Let me describe what we do for all our SOCs but Microblaze is the best example here.
> > Customers open design tools (right know Vivado) and design their system there.
> > Choose cpu and it's configuration like barrel shifter, divider, multiplicator,
> > size of caches. Then put there interrupt controller, timer, consoles, ethernet,
> > spi, i2c, etc. For all IPs you need to choose mmio base address and connect them
> > to any interrupt line you like.
> > You normally target a board, evaluation platforms or just standalone chips which
> > you use on your custom boards.
> > And build bitstream (configuration for FPGA) and also going over our device tree
> > generators which generate DT for describing the system.
> > Very old example is for example visible here
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/microblaze/boot/dts/system.dts?h=v6.6
> >
> > Another example is mb-v description mentioned in previous thread.
> >
> > The reason is simple with a lot of IPs in the design none will be able to get
> > description right in connection to addresses and especially interrupt numbers.
> >
> > It means at this stage you have bistream for your board and you have DTS
> > (without board specific information like i2c devices, ethernet phy, etc)
> >
> > For 10+ years our qemu is taking input as DTB and create qemu model based on it.
> > It means you say via DT I want this cpu core, this timer at 0x..., interrupt at
> > 0x..., uart at 0x..., etc. and qemu generates model for it. Pretty much the same
> > DT can be consumed by SW to run it on the model.
> >
> > We reached the state that you have qemu model which reflects your design choice
> > and at the same time you have hardware for your board.
> >
> > It means same DT describe qemu configuration and also hardware.
>
> So you can run it under QEMU. I misunderstood your proposal of adding
> qemu compatibles few emails before.
>
> But if the QEMU model and also the hardware is called "AMD MicroBlaze
> V", then how the heck is SoC called?

Let me talk about MicroBlaze which is the same category and available for 10+ years.
MicroBlaze is the name of CPU core.
And I think none has used any other term for SOC. Maybe just MicroBlaze based 
SOC. None is really creating any new name for it.
We use just xlnx,microblaze as compatible string for the whole DT.

compatible = "xlnx,microblaze";
model = "Xilinx MicroBlaze";

And then compatible string with version for cpu identification.
compatible = "xlnx,microblaze-10.0";


In connection to MicroBlaze V. It is cpu core name and if you want we can call 
it MicroBlaze V based SOC.

And the same DT is used for qemu model and also for hw designs running on 
different fpga boards in both cases.
I have no problem to define it as '"qemu,mbv"' or '"qemu,amd-mbv"' or 
'"qemu,mbv", "amd,mbv"' and fixed qemu model which just match it. And I am fine 
to ignore that it can also run it on fpga boards.

Thanks,
Michal