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
