dt-bindings: soc: Add new board description for MicroBlaze V

MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
It is hardware compatible with classic MicroBlaze processor. Processor can
be used with standard AMD/Xilinx IPs including interrupt controller and
timer.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml

On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> It is hardware compatible with classic MicroBlaze processor. Processor can
> be used with standard AMD/Xilinx IPs including interrupt controller and
> timer.
> 
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
> 
>  .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++

Bindings for SoCs (and by extension boards with them) usually go to in
$arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
different?

>  1 file changed, 26 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
> new file mode 100644
> index 000000000000..21adf28756fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD Platforms
> +
> +maintainers:
> +  - Michal Simek <michal.simek@amd.com>
> +
> +description: |
> +  AMD boards with MicroBlaze V SOC
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - description: AMD MicroBlaze V
> +        items:
> +          - const: amd,mbv

You don't actually list any boards here, but instead permit having only
the SoC compatible and no board one. The SoC compatible is also
incredibly generic. Personally I don't think this binding makes any
sense as it appears to exist as a catch all for anything using your
new cores in any combination.

Cheers,
Conor.

> +
> +additionalProperties: true
> +
> +...
> -- 
> 2.36.1
>

On 11/6/23 18:07, Conor Dooley wrote:
> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>> It is hardware compatible with classic MicroBlaze processor. Processor can
>> be used with standard AMD/Xilinx IPs including interrupt controller and
>> timer.
>>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>> ---
>>
>>   .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
> 
> Bindings for SoCs (and by extension boards with them) usually go to in
> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
> different?

I actually found it based on tracking renesas.yaml which describes one of risc-v 
board. No problem to move it under bindings/riscv/

> 
>>   1 file changed, 26 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>> new file mode 100644
>> index 000000000000..21adf28756fa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>> @@ -0,0 +1,26 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: AMD Platforms
>> +
>> +maintainers:
>> +  - Michal Simek <michal.simek@amd.com>
>> +
>> +description: |
>> +  AMD boards with MicroBlaze V SOC
>> +
>> +properties:
>> +  $nodename:
>> +    const: '/'
>> +  compatible:
>> +    oneOf:
>> +      - description: AMD MicroBlaze V
>> +        items:
>> +          - const: amd,mbv
> 
> You don't actually list any boards here, but instead permit having only
> the SoC compatible and no board one. The SoC compatible is also
> incredibly generic. Personally I don't think this binding makes any
> sense as it appears to exist as a catch all for anything using your
> new cores in any combination.

I think I need to define any string for compatibility because it is standard 
property. Because this is soft core it can be added to any board with AMD/Xilinx 
chip. I don't have really an option to list all boards.

I am happy to change it to something else but not sure to what.

Thanks,
Michal

On 07/11/2023 12:09, Michal Simek wrote:
> 
> 
> On 11/6/23 18:07, Conor Dooley wrote:
>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>> timer.
>>>
>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>> ---
>>>
>>>   .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>
>> Bindings for SoCs (and by extension boards with them) usually go to in
>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>> different?
> 
> I actually found it based on tracking renesas.yaml which describes one of risc-v 
> board. No problem to move it under bindings/riscv/
> 
>>
>>>   1 file changed, 26 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>> new file mode 100644
>>> index 000000000000..21adf28756fa
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>> @@ -0,0 +1,26 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: AMD Platforms
>>> +
>>> +maintainers:
>>> +  - Michal Simek <michal.simek@amd.com>
>>> +
>>> +description: |
>>> +  AMD boards with MicroBlaze V SOC
>>> +
>>> +properties:
>>> +  $nodename:
>>> +    const: '/'
>>> +  compatible:
>>> +    oneOf:
>>> +      - description: AMD MicroBlaze V
>>> +        items:
>>> +          - const: amd,mbv
>>
>> You don't actually list any boards here, but instead permit having only
>> the SoC compatible and no board one. The SoC compatible is also
>> incredibly generic. Personally I don't think this binding makes any
>> sense as it appears to exist as a catch all for anything using your
>> new cores in any combination.
> 
> I think I need to define any string for compatibility because it is standard 
> property. Because this is soft core it can be added to any board with AMD/Xilinx 
> chip. I don't have really an option to list all boards.

Why? Either there is a product with this soft-core or there is not. It
cannot be both.

> 
> I am happy to change it to something else but not sure to what.

Alone this compatible does not bring you anything.

Best regards,
Krzysztof

On 11/7/23 12:27, Krzysztof Kozlowski wrote:
> On 07/11/2023 12:09, Michal Simek wrote:
>>
>>
>> On 11/6/23 18:07, Conor Dooley wrote:
>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>>> timer.
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>> ---
>>>>
>>>>    .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>>
>>> Bindings for SoCs (and by extension boards with them) usually go to in
>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>>> different?
>>
>> I actually found it based on tracking renesas.yaml which describes one of risc-v
>> board. No problem to move it under bindings/riscv/
>>
>>>
>>>>    1 file changed, 26 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>> new file mode 100644
>>>> index 000000000000..21adf28756fa
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>> @@ -0,0 +1,26 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: AMD Platforms
>>>> +
>>>> +maintainers:
>>>> +  - Michal Simek <michal.simek@amd.com>
>>>> +
>>>> +description: |
>>>> +  AMD boards with MicroBlaze V SOC
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    const: '/'
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - description: AMD MicroBlaze V
>>>> +        items:
>>>> +          - const: amd,mbv
>>>
>>> You don't actually list any boards here, but instead permit having only
>>> the SoC compatible and no board one. The SoC compatible is also
>>> incredibly generic. Personally I don't think this binding makes any
>>> sense as it appears to exist as a catch all for anything using your
>>> new cores in any combination.
>>
>> I think I need to define any string for compatibility because it is standard
>> property. Because this is soft core it can be added to any board with AMD/Xilinx
>> chip. I don't have really an option to list all boards.
> 
> Why? Either there is a product with this soft-core or there is not. It
> cannot be both.

I am doing basic enablement. I am not making product. Product will be done by 
our customers using this core.
There will be thousands of different configurations done by customers which will 
have products with it. Also there could be hundreds configurations done on the 
same board.

Does it make sense to have board related compatible string like this if this 
evaluation board is used by a lot of customers?
"amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"

Or I can define qemu one.
"amd,qemu-mbv", "amd,mbv"

I think customers should be adding their compatible string in front of generic one.

Years ago I have done the same thing with Microblaze where compatible is defined 
as xlnx,microblaze only. When customer take this soft core, put IPs around and 
create a product they should extend it to be for example like this.
"xyz,my-product-1.0", "xlnx,microblaze";

And over all of years I have never seen any single customer to try to push dt 
description for any Microblaze based product.

>>
>> I am happy to change it to something else but not sure to what.
> 
> Alone this compatible does not bring you anything.

I don't agree with it. It is standard property and I have to define it somehow.
If not, I get an error.
.../xilinx-mbv32.dtb: /: 'compatible' is a required property

And it tells me that this risc-v compatible core runs on AMD fpga and it is 
compatible with it.

Thanks,
Michal

On 07/11/2023 13:09, Michal Simek wrote:
> 
> 
> On 11/7/23 12:27, Krzysztof Kozlowski wrote:
>> On 07/11/2023 12:09, Michal Simek wrote:
>>>
>>>
>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>>>> timer.
>>>>>
>>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>>> ---
>>>>>
>>>>>    .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>>>
>>>> Bindings for SoCs (and by extension boards with them) usually go to in
>>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>>>> different?
>>>
>>> I actually found it based on tracking renesas.yaml which describes one of risc-v
>>> board. No problem to move it under bindings/riscv/
>>>
>>>>
>>>>>    1 file changed, 26 insertions(+)
>>>>>    create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..21adf28756fa
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
>>>>> @@ -0,0 +1,26 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: AMD Platforms
>>>>> +
>>>>> +maintainers:
>>>>> +  - Michal Simek <michal.simek@amd.com>
>>>>> +
>>>>> +description: |
>>>>> +  AMD boards with MicroBlaze V SOC
>>>>> +
>>>>> +properties:
>>>>> +  $nodename:
>>>>> +    const: '/'
>>>>> +  compatible:
>>>>> +    oneOf:
>>>>> +      - description: AMD MicroBlaze V
>>>>> +        items:
>>>>> +          - const: amd,mbv
>>>>
>>>> You don't actually list any boards here, but instead permit having only
>>>> the SoC compatible and no board one. The SoC compatible is also
>>>> incredibly generic. Personally I don't think this binding makes any
>>>> sense as it appears to exist as a catch all for anything using your
>>>> new cores in any combination.
>>>
>>> I think I need to define any string for compatibility because it is standard
>>> property. Because this is soft core it can be added to any board with AMD/Xilinx
>>> chip. I don't have really an option to list all boards.
>>
>> Why? Either there is a product with this soft-core or there is not. It
>> cannot be both.
> 
> I am doing basic enablement. I am not making product. Product will be done by 
> our customers using this core.
> There will be thousands of different configurations done by customers which will 
> have products with it. Also there could be hundreds configurations done on the 
> same board.

If this is the same board, then why there is compatible for it?

> 
> Does it make sense to have board related compatible string like this if this 
> evaluation board is used by a lot of customers?
> "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"

I miss the point what is the hardware. Evaluation board is the hardware.
If someone changes it and makes a new product, it is a new product.

> 
> Or I can define qemu one.
> "amd,qemu-mbv", "amd,mbv"

QEMU is not hardware, so not.

> 
> I think customers should be adding their compatible string in front of generic one.

To what? To evaluation board? Why?

> 
> Years ago I have done the same thing with Microblaze where compatible is defined 
> as xlnx,microblaze only. 

Again, what is the use of such binding?

> When customer take this soft core, put IPs around and 
> create a product they should extend it to be for example like this.
> "xyz,my-product-1.0", "xlnx,microblaze";

So there is a product, not evaluation board.

> 
> And over all of years I have never seen any single customer to try to push dt 
> description for any Microblaze based product.
> 
>>>
>>> I am happy to change it to something else but not sure to what.
>>
>> Alone this compatible does not bring you anything.
> 
> I don't agree with it. It is standard property and I have to define it somehow.

The property is already defined, you do not have to define it. What you
define here is the value for compatible. Why do you need to define it
somehow? Who asks for that?

> If not, I get an error.
> .../xilinx-mbv32.dtb: /: 'compatible' is a required property

So you have a board? The patches must be linked to each other, e.g.
preferred way is to send them in one patchset.

> 
> And it tells me that this risc-v compatible core runs on AMD fpga and it is 
> compatible with it.


Best regards,
Krzysztof

On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
> 
> 
> On 11/6/23 18:07, Conor Dooley wrote:
> > On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> > > MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> > > It is hardware compatible with classic MicroBlaze processor. Processor can
> > > be used with standard AMD/Xilinx IPs including interrupt controller and
> > > timer.
> > > 
> > > Signed-off-by: Michal Simek <michal.simek@amd.com>
> > > ---
> > > 
> > >   .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
> > 
> > Bindings for SoCs (and by extension boards with them) usually go to in
> > $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
> > different?
> 
> I actually found it based on tracking renesas.yaml which describes one of
> risc-v board. No problem to move it under bindings/riscv/

That one is kinda a special case, as it contains arm/arm64/riscv.

+CC Palmer

On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
> On 07/11/2023 13:09, Michal Simek wrote:
> > On 11/7/23 12:27, Krzysztof Kozlowski wrote:
> >> On 07/11/2023 12:09, Michal Simek wrote:
> >>> On 11/6/23 18:07, Conor Dooley wrote:
> >>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:

> >>>>> +description: |
> >>>>> +  AMD boards with MicroBlaze V SOC
> >>>>> +
> >>>>> +properties:
> >>>>> +  $nodename:
> >>>>> +    const: '/'
> >>>>> +  compatible:
> >>>>> +    oneOf:
> >>>>> +      - description: AMD MicroBlaze V
> >>>>> +        items:
> >>>>> +          - const: amd,mbv
> >>>>
> >>>> You don't actually list any boards here, but instead permit having only
> >>>> the SoC compatible and no board one. The SoC compatible is also
> >>>> incredibly generic. Personally I don't think this binding makes any
> >>>> sense as it appears to exist as a catch all for anything using your
> >>>> new cores in any combination.
> >>>
> >>> I think I need to define any string for compatibility because it is standard
> >>> property. Because this is soft core it can be added to any board with AMD/Xilinx
> >>> chip. I don't have really an option to list all boards.
> >>
> >> Why? Either there is a product with this soft-core or there is not. It
> >> cannot be both.
> > 
> > I am doing basic enablement. I am not making product. Product will be done by 
> > our customers using this core.
> > There will be thousands of different configurations done by customers which will 
> > have products with it. Also there could be hundreds configurations done on the 
> > same board.
> 
> If this is the same board, then why there is compatible for it?
> 
> > 
> > Does it make sense to have board related compatible string like this if this 
> > evaluation board is used by a lot of customers?
> > "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
> 
> I miss the point what is the hardware. Evaluation board is the hardware.
> If someone changes it and makes a new product, it is a new product.

To me, this does actually make (some) sense.
The first compatible is "soc" + board + design.
The second is "soc" + board.
The final one is the "soc".

I say "soc" though, because it is not a single soc - it could be any
configuration of these soft AMD cores on an FPGA in any quality,
possibly set up heterogeneously too. I don't think trying to define a
generic compatible for it like this makes sense as the soc part does
not come close to identifying a specific device.

Until someone actually creates a product that ships with this, I don't
think it makes sense to try and define a binding.

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.

> > Or I can define qemu one.
> > "amd,qemu-mbv", "amd,mbv"
> 
> QEMU is not hardware, so not.
> 
> > 
> > I think customers should be adding their compatible string in front of generic one.
> 
> To what? To evaluation board? Why?
> 
> > 
> > Years ago I have done the same thing with Microblaze where compatible is defined 
> > as xlnx,microblaze only. 
> 
> Again, what is the use of such binding?
> 
> > When customer take this soft core, put IPs around and 
> > create a product they should extend it to be for example like this.
> > "xyz,my-product-1.0", "xlnx,microblaze";
> 
> So there is a product, not evaluation board.
> 
> > 
> > And over all of years I have never seen any single customer to try to push dt 
> > description for any Microblaze based product.
> > 
> >>>
> >>> I am happy to change it to something else but not sure to what.
> >>
> >> Alone this compatible does not bring you anything.
> > 
> > I don't agree with it. It is standard property and I have to define it somehow.
> 
> The property is already defined, you do not have to define it. What you
> define here is the value for compatible. Why do you need to define it
> somehow? Who asks for that?
> 
> > If not, I get an error.
> > .../xilinx-mbv32.dtb: /: 'compatible' is a required property
> 
> So you have a board? The patches must be linked to each other, e.g.
> preferred way is to send them in one patchset.

There were patches sent to U-Boot for an example configuration:
https://lore.kernel.org/u-boot/d488b7016e0d1b1324c64d8a8b2f033851aab6c6.1699271804.git.michal.simek@amd.com/

> > And it tells me that this risc-v compatible core runs on AMD fpga and it is 
> > compatible with it.

Basically, it provides no more specific information than the cpu node
does. From me, it's a NAK for a compatible like this that that permits
using it in isolation for any core configuration and combination.

Cheers,
Conor.

On 11/7/23 22:36, Conor Dooley wrote:
> +CC Palmer
> 
> On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
>> On 07/11/2023 13:09, Michal Simek wrote:
>>> On 11/7/23 12:27, Krzysztof Kozlowski wrote:
>>>> On 07/11/2023 12:09, Michal Simek wrote:
>>>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> 
>>>>>>> +description: |
>>>>>>> +  AMD boards with MicroBlaze V SOC
>>>>>>> +
>>>>>>> +properties:
>>>>>>> +  $nodename:
>>>>>>> +    const: '/'
>>>>>>> +  compatible:
>>>>>>> +    oneOf:
>>>>>>> +      - description: AMD MicroBlaze V
>>>>>>> +        items:
>>>>>>> +          - const: amd,mbv
>>>>>>
>>>>>> You don't actually list any boards here, but instead permit having only
>>>>>> the SoC compatible and no board one. The SoC compatible is also
>>>>>> incredibly generic. Personally I don't think this binding makes any
>>>>>> sense as it appears to exist as a catch all for anything using your
>>>>>> new cores in any combination.
>>>>>
>>>>> I think I need to define any string for compatibility because it is standard
>>>>> property. Because this is soft core it can be added to any board with AMD/Xilinx
>>>>> chip. I don't have really an option to list all boards.
>>>>
>>>> Why? Either there is a product with this soft-core or there is not. It
>>>> cannot be both.
>>>
>>> I am doing basic enablement. I am not making product. Product will be done by
>>> our customers using this core.
>>> There will be thousands of different configurations done by customers which will
>>> have products with it. Also there could be hundreds configurations done on the
>>> same board.
>>
>> If this is the same board, then why there is compatible for it?
>>
>>>
>>> Does it make sense to have board related compatible string like this if this
>>> evaluation board is used by a lot of customers?
>>> "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
>>
>> I miss the point what is the hardware. Evaluation board is the hardware.
>> If someone changes it and makes a new product, it is a new product.
> 
> To me, this does actually make (some) sense.
> The first compatible is "soc" + board + design.
> The second is "soc" + board.
> The final one is the "soc".
> 
> I say "soc" though, because it is not a single soc - it could be any
> configuration of these soft AMD cores on an FPGA in any quality,
> possibly set up heterogeneously too. I don't think trying to define a
> generic compatible for it like this makes sense as the soc part does
> not come close to identifying a specific device.

I am fine to skip it but it is required property which has to be defined somehow.

> 
> Until someone actually creates a product that ships with this, I don't
> think it makes sense to try and define a binding.

I disagree with this description. I am coming from FPGA world where it is too 
late to start to deal with dt binding when you have a product.
You are saying release the product and then start to deal with dt binding. When 
product is released there must be stable dt binding.

> 
> 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?

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.

>>
>>>
>>> I think customers should be adding their compatible string in front of generic one.
>>
>> To what? To evaluation board? Why?
>>
>>>
>>> Years ago I have done the same thing with Microblaze where compatible is defined
>>> as xlnx,microblaze only.
>>
>> Again, what is the use of such binding?
>>
>>> When customer take this soft core, put IPs around and
>>> create a product they should extend it to be for example like this.
>>> "xyz,my-product-1.0", "xlnx,microblaze";
>>
>> So there is a product, not evaluation board.
>>
>>>
>>> And over all of years I have never seen any single customer to try to push dt
>>> description for any Microblaze based product.
>>>
>>>>>
>>>>> I am happy to change it to something else but not sure to what.
>>>>
>>>> Alone this compatible does not bring you anything.
>>>
>>> I don't agree with it. It is standard property and I have to define it somehow.
>>
>> The property is already defined, you do not have to define it. What you
>> define here is the value for compatible. Why do you need to define it
>> somehow? Who asks for that?
>>
>>> If not, I get an error.
>>> .../xilinx-mbv32.dtb: /: 'compatible' is a required property
>>
>> So you have a board? The patches must be linked to each other, e.g.
>> preferred way is to send them in one patchset.
> 
> There were patches sent to U-Boot for an example configuration:
> https://lore.kernel.org/u-boot/d488b7016e0d1b1324c64d8a8b2f033851aab6c6.1699271804.git.michal.simek@amd.com/

thx.

> 
>>> And it tells me that this risc-v compatible core runs on AMD fpga and it is
>>> compatible with it.
> 
> Basically, it provides no more specific information than the cpu node
> does. From me, it's a NAK for a compatible like this that that permits
> using it in isolation for any core configuration and combination.

I hope you agree that if we ignore compatible string for the whole DT that DT 
describes HW is very reasonable way. It means you know what CPU is, what timer, 
console and intc are.
It clearly shows how MicroBlaze-V AMD design will be done for others who are 
interested on using it.
It also shows and explain what drivers needs to be enabled in defconfigs.

In connection to above u-boot. I can simply remove DT patch from that series (or 
move it to readme) and just say these IPs will be used that's why I am enabling 
them and point them to public announcement. And configure that DT will be passed 
via address in DDR and that's it.
But I simply think that DT is providing better view on the system.

We will of course extending our device tree generators to provide DT description 
directly from the tool as a starting point for customers.

Thanks,
Michal

On 08/11/2023 08:16, Michal Simek wrote:
> 
> 
> On 11/7/23 22:36, Conor Dooley wrote:
>> +CC Palmer
>>
>> On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
>>> On 07/11/2023 13:09, Michal Simek wrote:
>>>> On 11/7/23 12:27, Krzysztof Kozlowski wrote:
>>>>> On 07/11/2023 12:09, Michal Simek wrote:
>>>>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>
>>>>>>>> +description: |
>>>>>>>> +  AMD boards with MicroBlaze V SOC
>>>>>>>> +
>>>>>>>> +properties:
>>>>>>>> +  $nodename:
>>>>>>>> +    const: '/'
>>>>>>>> +  compatible:
>>>>>>>> +    oneOf:
>>>>>>>> +      - description: AMD MicroBlaze V
>>>>>>>> +        items:
>>>>>>>> +          - const: amd,mbv
>>>>>>>
>>>>>>> You don't actually list any boards here, but instead permit having only
>>>>>>> the SoC compatible and no board one. The SoC compatible is also
>>>>>>> incredibly generic. Personally I don't think this binding makes any
>>>>>>> sense as it appears to exist as a catch all for anything using your
>>>>>>> new cores in any combination.
>>>>>>
>>>>>> I think I need to define any string for compatibility because it is standard
>>>>>> property. Because this is soft core it can be added to any board with AMD/Xilinx
>>>>>> chip. I don't have really an option to list all boards.
>>>>>
>>>>> Why? Either there is a product with this soft-core or there is not. It
>>>>> cannot be both.
>>>>
>>>> I am doing basic enablement. I am not making product. Product will be done by
>>>> our customers using this core.
>>>> There will be thousands of different configurations done by customers which will
>>>> have products with it. Also there could be hundreds configurations done on the
>>>> same board.
>>>
>>> If this is the same board, then why there is compatible for it?
>>>
>>>>
>>>> Does it make sense to have board related compatible string like this if this
>>>> evaluation board is used by a lot of customers?
>>>> "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
>>>
>>> I miss the point what is the hardware. Evaluation board is the hardware.
>>> If someone changes it and makes a new product, it is a new product.
>>
>> To me, this does actually make (some) sense.
>> The first compatible is "soc" + board + design.
>> The second is "soc" + board.
>> The final one is the "soc".
>>
>> I say "soc" though, because it is not a single soc - it could be any
>> configuration of these soft AMD cores on an FPGA in any quality,
>> possibly set up heterogeneously too. I don't think trying to define a
>> generic compatible for it like this makes sense as the soc part does
>> not come close to identifying a specific device.
> 
> I am fine to skip it but it is required property which has to be defined somehow.
> 
>>
>> Until someone actually creates a product that ships with this, I don't
>> think it makes sense to try and define a binding.
> 
> I disagree with this description. I am coming from FPGA world where it is too 
> late to start to deal with dt binding when you have a product.
> You are saying release the product and then start to deal with dt binding. When 
> product is released there must be stable dt binding.

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).

> 
>>
>> 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.

> 
> 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.

> 
>>>
>>>>
>>>> I think customers should be adding their compatible string in front of generic one.
>>>
>>> To what? To evaluation board? Why?
>>>
>>>>
>>>> Years ago I have done the same thing with Microblaze where compatible is defined
>>>> as xlnx,microblaze only.
>>>
>>> Again, what is the use of such binding?
>>>
>>>> When customer take this soft core, put IPs around and
>>>> create a product they should extend it to be for example like this.
>>>> "xyz,my-product-1.0", "xlnx,microblaze";
>>>
>>> So there is a product, not evaluation board.
>>>
>>>>
>>>> And over all of years I have never seen any single customer to try to push dt
>>>> description for any Microblaze based product.
>>>>
>>>>>>
>>>>>> I am happy to change it to something else but not sure to what.
>>>>>
>>>>> Alone this compatible does not bring you anything.
>>>>
>>>> I don't agree with it. It is standard property and I have to define it somehow.
>>>
>>> The property is already defined, you do not have to define it. What you
>>> define here is the value for compatible. Why do you need to define it
>>> somehow? Who asks for that?
>>>
>>>> If not, I get an error.
>>>> .../xilinx-mbv32.dtb: /: 'compatible' is a required property
>>>
>>> So you have a board? The patches must be linked to each other, e.g.
>>> preferred way is to send them in one patchset.
>>
>> There were patches sent to U-Boot for an example configuration:
>> https://lore.kernel.org/u-boot/d488b7016e0d1b1324c64d8a8b2f033851aab6c6.1699271804.git.michal.simek@amd.com/
> 
> thx.
> 
>>
>>>> And it tells me that this risc-v compatible core runs on AMD fpga and it is
>>>> compatible with it.
>>
>> Basically, it provides no more specific information than the cpu node
>> does. From me, it's a NAK for a compatible like this that that permits
>> using it in isolation for any core configuration and combination.
> 
> I hope you agree that if we ignore compatible string for the whole DT that DT 
> describes HW is very reasonable way. It means you know what CPU is, what timer, 
> console and intc are.
> It clearly shows how MicroBlaze-V AMD design will be done for others who are 
> interested on using it.
> It also shows and explain what drivers needs to be enabled in defconfigs.
> 
> In connection to above u-boot. I can simply remove DT patch from that series (or 
> move it to readme) and just say these IPs will be used that's why I am enabling 
> them and point them to public announcement. And configure that DT will be passed 
> via address in DDR and that's it.
> But I simply think that DT is providing better view on the system.
> 
> We will of course extending our device tree generators to provide DT description 
> directly from the tool as a starting point for customers.
> 


You called the file:
"AMD boards with MicroBlaze V SOC", which means "AMD MicroBlaze V" is
the name of the SoC.

Now you create one compatible, not a list, for "AMD MicroBlaze V", so
only for the SoC. That's the discussion about. You cannot create a
final, real and working hardware with this SoC alone. To make it
working, you need to put it into some board. Now, for SW models,
probably you can... but then how do you run it? If under QEMU then show
me the QEMU machine file - I bet there are some specifics for this given
configuration. This means you have specific configuration, not a generic
SoC. And again we are at the same spot as with hardware - you could not
run the SW model without configuring it, thus you cannot run a "SoC".

Best regards,
Krzysztof

On 11/7/23 22:18, Conor Dooley wrote:
> On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
>>
>>
>> On 11/6/23 18:07, Conor Dooley wrote:
>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>>> timer.
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>> ---
>>>>
>>>>    .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>>
>>> Bindings for SoCs (and by extension boards with them) usually go to in
>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>>> different?
>>
>> I actually found it based on tracking renesas.yaml which describes one of
>> risc-v board. No problem to move it under bindings/riscv/
> 
> That one is kinda a special case, as it contains arm/arm64/riscv.

If they are kinda a special case then what are we?
All AMD/Xilinx platforms(ZynqMP/Versal/Versal NET) can have 
arm/arm64/riscv/microblaze cpus(riscv/microblaze as soft cores) in the same 
board (IIRC I have also seen xtensa soft core on our chips too).

Thanks,
Michal

On 11/8/23 09:11, Krzysztof Kozlowski wrote:
> On 08/11/2023 08:16, Michal Simek wrote:
>>
>>
>> On 11/7/23 22:36, Conor Dooley wrote:
>>> +CC Palmer
>>>
>>> On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/11/2023 13:09, Michal Simek wrote:
>>>>> On 11/7/23 12:27, Krzysztof Kozlowski wrote:
>>>>>> On 07/11/2023 12:09, Michal Simek wrote:
>>>>>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>>>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>
>>>>>>>>> +description: |
>>>>>>>>> +  AMD boards with MicroBlaze V SOC
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> +  $nodename:
>>>>>>>>> +    const: '/'
>>>>>>>>> +  compatible:
>>>>>>>>> +    oneOf:
>>>>>>>>> +      - description: AMD MicroBlaze V
>>>>>>>>> +        items:
>>>>>>>>> +          - const: amd,mbv
>>>>>>>>
>>>>>>>> You don't actually list any boards here, but instead permit having only
>>>>>>>> the SoC compatible and no board one. The SoC compatible is also
>>>>>>>> incredibly generic. Personally I don't think this binding makes any
>>>>>>>> sense as it appears to exist as a catch all for anything using your
>>>>>>>> new cores in any combination.
>>>>>>>
>>>>>>> I think I need to define any string for compatibility because it is standard
>>>>>>> property. Because this is soft core it can be added to any board with AMD/Xilinx
>>>>>>> chip. I don't have really an option to list all boards.
>>>>>>
>>>>>> Why? Either there is a product with this soft-core or there is not. It
>>>>>> cannot be both.
>>>>>
>>>>> I am doing basic enablement. I am not making product. Product will be done by
>>>>> our customers using this core.
>>>>> There will be thousands of different configurations done by customers which will
>>>>> have products with it. Also there could be hundreds configurations done on the
>>>>> same board.
>>>>
>>>> If this is the same board, then why there is compatible for it?
>>>>
>>>>>
>>>>> Does it make sense to have board related compatible string like this if this
>>>>> evaluation board is used by a lot of customers?
>>>>> "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
>>>>
>>>> I miss the point what is the hardware. Evaluation board is the hardware.
>>>> If someone changes it and makes a new product, it is a new product.
>>>
>>> To me, this does actually make (some) sense.
>>> The first compatible is "soc" + board + design.
>>> The second is "soc" + board.
>>> The final one is the "soc".
>>>
>>> I say "soc" though, because it is not a single soc - it could be any
>>> configuration of these soft AMD cores on an FPGA in any quality,
>>> possibly set up heterogeneously too. I don't think trying to define a
>>> generic compatible for it like this makes sense as the soc part does
>>> not come close to identifying a specific device.
>>
>> I am fine to skip it but it is required property which has to be defined somehow.
>>
>>>
>>> Until someone actually creates a product that ships with this, I don't
>>> think it makes sense to try and define a binding.
>>
>> I disagree with this description. I am coming from FPGA world where it is too
>> late to start to deal with dt binding when you have a product.
>> You are saying release the product and then start to deal with dt binding. When
>> product is released there must be stable dt binding.
> 
> 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@amd.com

And discussion what we are having is pretty much about how to share the view on 
the system.

>>
>>>
>>> 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.

> 
>>
>> 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.

>>>>
>>>>>
>>>>> I think customers should be adding their compatible string in front of generic one.
>>>>
>>>> To what? To evaluation board? Why?
>>>>
>>>>>
>>>>> Years ago I have done the same thing with Microblaze where compatible is defined
>>>>> as xlnx,microblaze only.
>>>>
>>>> Again, what is the use of such binding?
>>>>
>>>>> When customer take this soft core, put IPs around and
>>>>> create a product they should extend it to be for example like this.
>>>>> "xyz,my-product-1.0", "xlnx,microblaze";
>>>>
>>>> So there is a product, not evaluation board.
>>>>
>>>>>
>>>>> And over all of years I have never seen any single customer to try to push dt
>>>>> description for any Microblaze based product.
>>>>>
>>>>>>>
>>>>>>> I am happy to change it to something else but not sure to what.
>>>>>>
>>>>>> Alone this compatible does not bring you anything.
>>>>>
>>>>> I don't agree with it. It is standard property and I have to define it somehow.
>>>>
>>>> The property is already defined, you do not have to define it. What you
>>>> define here is the value for compatible. Why do you need to define it
>>>> somehow? Who asks for that?
>>>>
>>>>> If not, I get an error.
>>>>> .../xilinx-mbv32.dtb: /: 'compatible' is a required property
>>>>
>>>> So you have a board? The patches must be linked to each other, e.g.
>>>> preferred way is to send them in one patchset.
>>>
>>> There were patches sent to U-Boot for an example configuration:
>>> https://lore.kernel.org/u-boot/d488b7016e0d1b1324c64d8a8b2f033851aab6c6.1699271804.git.michal.simek@amd.com/
>>
>> thx.
>>
>>>
>>>>> And it tells me that this risc-v compatible core runs on AMD fpga and it is
>>>>> compatible with it.
>>>
>>> Basically, it provides no more specific information than the cpu node
>>> does. From me, it's a NAK for a compatible like this that that permits
>>> using it in isolation for any core configuration and combination.
>>
>> I hope you agree that if we ignore compatible string for the whole DT that DT
>> describes HW is very reasonable way. It means you know what CPU is, what timer,
>> console and intc are.
>> It clearly shows how MicroBlaze-V AMD design will be done for others who are
>> interested on using it.
>> It also shows and explain what drivers needs to be enabled in defconfigs.
>>
>> In connection to above u-boot. I can simply remove DT patch from that series (or
>> move it to readme) and just say these IPs will be used that's why I am enabling
>> them and point them to public announcement. And configure that DT will be passed
>> via address in DDR and that's it.
>> But I simply think that DT is providing better view on the system.
>>
>> We will of course extending our device tree generators to provide DT description
>> directly from the tool as a starting point for customers.
>>
> 
> 
> You called the file:
> "AMD boards with MicroBlaze V SOC", which means "AMD MicroBlaze V" is
> the name of the SoC.

It is official name for risc-v compatible core implementation for AMD/Xilinx 
FPGAs. Strictly speaking just name of cpu core.

SoC is cpu with other components around.

DT is describing one of the configuration with MicroBlaze V cpu core with 
related IP (timer, intc, serial) which together create SOC.

World boards is likely what should be fixed. Maybe design should be used instead.

> Now you create one compatible, not a list, for "AMD MicroBlaze V", so
> only for the SoC. That's the discussion about. You cannot create a
> final, real and working hardware with this SoC alone. To make it
> working, you need to put it into some board. 

I can agree with this description.

> Now, for SW models,
> probably you can... but then how do you run it? 

I can put this sw compatible design to thousands of boards but I can't say which 
one. As of today this SOC configuration/design is built and running on kcu105.
https://www.xilinx.com/products/boards-and-kits/kcu105.html

But in very easy way it can run on ac701
https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html

> If under QEMU then show
> me the QEMU machine file - I bet there are some specifics for this given
> configuration. This means you have specific configuration, not a generic
> SoC.

But I want to show it as reference only to see how that DTs will look like.

> And again we are at the same spot as with hardware - you could not
> run the SW model without configuring it, thus you cannot run a "SoC".

And in our case we use DT for SW model configuration too.

Thanks,
Michal

On Wed, Nov 08, 2023 at 11:06:53AM +0100, Michal Simek wrote:
> 
> 
> On 11/7/23 22:18, Conor Dooley wrote:
> > On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
> > > 
> > > 
> > > On 11/6/23 18:07, Conor Dooley wrote:
> > > > On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> > > > > MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> > > > > It is hardware compatible with classic MicroBlaze processor. Processor can
> > > > > be used with standard AMD/Xilinx IPs including interrupt controller and
> > > > > timer.
> > > > > 
> > > > > Signed-off-by: Michal Simek <michal.simek@amd.com>
> > > > > ---
> > > > > 
> > > > >    .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
> > > > 
> > > > Bindings for SoCs (and by extension boards with them) usually go to in
> > > > $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
> > > > different?
> > > 
> > > I actually found it based on tracking renesas.yaml which describes one of
> > > risc-v board. No problem to move it under bindings/riscv/
> > 
> > That one is kinda a special case, as it contains arm/arm64/riscv.
> 
> If they are kinda a special case then what are we?
> All AMD/Xilinx platforms(ZynqMP/Versal/Versal NET) can have
> arm/arm64/riscv/microblaze cpus(riscv/microblaze as soft cores) in the same
> board (IIRC I have also seen xtensa soft core on our chips too).

That would be an argument iff you had all of those in a single file, not
when you only have a single compatible for a riscv "soc" in it.

On 11/8/23 11:12, Conor Dooley wrote:
> On Wed, Nov 08, 2023 at 11:06:53AM +0100, Michal Simek wrote:
>>
>>
>> On 11/7/23 22:18, Conor Dooley wrote:
>>> On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
>>>>
>>>>
>>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>>>>> timer.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>>>> ---
>>>>>>
>>>>>>     .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>>>>
>>>>> Bindings for SoCs (and by extension boards with them) usually go to in
>>>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>>>>> different?
>>>>
>>>> I actually found it based on tracking renesas.yaml which describes one of
>>>> risc-v board. No problem to move it under bindings/riscv/
>>>
>>> That one is kinda a special case, as it contains arm/arm64/riscv.
>>
>> If they are kinda a special case then what are we?
>> All AMD/Xilinx platforms(ZynqMP/Versal/Versal NET) can have
>> arm/arm64/riscv/microblaze cpus(riscv/microblaze as soft cores) in the same
>> board (IIRC I have also seen xtensa soft core on our chips too).
> 
> That would be an argument iff you had all of those in a single file, not
> when you only have a single compatible for a riscv "soc" in it.

But DT (compare to System DT) is all the time describing system from cpu point 
of view. Or are they describing all that 3 different cpus via the same DT?

Thanks,
Michal

On Wed, Nov 08, 2023 at 11:24:20AM +0100, Michal Simek wrote:
> 
> 
> On 11/8/23 11:12, Conor Dooley wrote:
> > On Wed, Nov 08, 2023 at 11:06:53AM +0100, Michal Simek wrote:
> > > 
> > > 
> > > On 11/7/23 22:18, Conor Dooley wrote:
> > > > On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
> > > > > 
> > > > > 
> > > > > On 11/6/23 18:07, Conor Dooley wrote:
> > > > > > On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> > > > > > > MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> > > > > > > It is hardware compatible with classic MicroBlaze processor. Processor can
> > > > > > > be used with standard AMD/Xilinx IPs including interrupt controller and
> > > > > > > timer.
> > > > > > > 
> > > > > > > Signed-off-by: Michal Simek <michal.simek@amd.com>
> > > > > > > ---
> > > > > > > 
> > > > > > >     .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
> > > > > > 
> > > > > > Bindings for SoCs (and by extension boards with them) usually go to in
> > > > > > $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
> > > > > > different?
> > > > > 
> > > > > I actually found it based on tracking renesas.yaml which describes one of
> > > > > risc-v board. No problem to move it under bindings/riscv/
> > > > 
> > > > That one is kinda a special case, as it contains arm/arm64/riscv.
> > > 
> > > If they are kinda a special case then what are we?
> > > All AMD/Xilinx platforms(ZynqMP/Versal/Versal NET) can have
> > > arm/arm64/riscv/microblaze cpus(riscv/microblaze as soft cores) in the same
> > > board (IIRC I have also seen xtensa soft core on our chips too).
> > 
> > That would be an argument iff you had all of those in a single file, not
> > when you only have a single compatible for a riscv "soc" in it.
> 
> But DT (compare to System DT) is all the time describing system from cpu
> point of view. Or are they describing all that 3 different cpus via the same
> DT?

Please look at the contents of renesas.yaml & the commit that moved it
to its current location. I'm only talking about the binding, not any
users.

On 11/8/23 11:28, Conor Dooley wrote:
> On Wed, Nov 08, 2023 at 11:24:20AM +0100, Michal Simek wrote:
>>
>>
>> On 11/8/23 11:12, Conor Dooley wrote:
>>> On Wed, Nov 08, 2023 at 11:06:53AM +0100, Michal Simek wrote:
>>>>
>>>>
>>>> On 11/7/23 22:18, Conor Dooley wrote:
>>>>> On Tue, Nov 07, 2023 at 12:09:58PM +0100, Michal Simek wrote:
>>>>>>
>>>>>>
>>>>>> On 11/6/23 18:07, Conor Dooley wrote:
>>>>>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
>>>>>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
>>>>>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
>>>>>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
>>>>>>>> timer.
>>>>>>>>
>>>>>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>      .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
>>>>>>>
>>>>>>> Bindings for SoCs (and by extension boards with them) usually go to in
>>>>>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
>>>>>>> different?
>>>>>>
>>>>>> I actually found it based on tracking renesas.yaml which describes one of
>>>>>> risc-v board. No problem to move it under bindings/riscv/
>>>>>
>>>>> That one is kinda a special case, as it contains arm/arm64/riscv.
>>>>
>>>> If they are kinda a special case then what are we?
>>>> All AMD/Xilinx platforms(ZynqMP/Versal/Versal NET) can have
>>>> arm/arm64/riscv/microblaze cpus(riscv/microblaze as soft cores) in the same
>>>> board (IIRC I have also seen xtensa soft core on our chips too).
>>>
>>> That would be an argument iff you had all of those in a single file, not
>>> when you only have a single compatible for a riscv "soc" in it.
>>
>> But DT (compare to System DT) is all the time describing system from cpu
>> point of view. Or are they describing all that 3 different cpus via the same
>> DT?
> 
> Please look at the contents of renesas.yaml & the commit that moved it
> to its current location. I'm only talking about the binding, not any
> users.

Thanks for pointer.

"   renesas.yaml lists out all the Renesas SoC's and the platforms/EVK's which
     is either ARM32/ARM64. It would rather make sense if we move renesas.yaml
     to the soc/renesas folder instead. This is in preparation for adding a new
     SoC (RZ/Five) from Renesas which is based on RISC-V."

It sounds like boards with arm32 or arm64 or risc-v.

It means I should actually move 
Documentation/devicetree/bindings/arm/xilinx.yaml to new location.

In our case we have even systems where you have arm32 (r5 or r52) with arm64 
(a53 or a72 or a78) with soft cores (MicroBlaze and later MB-V) on the same board.

Every board which is listed in xilinx.yaml can have MicroBlazes in it.

Thanks,
Michal

On Tue, Nov 07, 2023 at 01:38:15PM +0100, Krzysztof Kozlowski wrote:
> On 07/11/2023 13:09, Michal Simek wrote:
> > 
> > 
> > On 11/7/23 12:27, Krzysztof Kozlowski wrote:
> >> On 07/11/2023 12:09, Michal Simek wrote:
> >>>
> >>>
> >>> On 11/6/23 18:07, Conor Dooley wrote:
> >>>> On Mon, Nov 06, 2023 at 12:53:40PM +0100, Michal Simek wrote:
> >>>>> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> >>>>> It is hardware compatible with classic MicroBlaze processor. Processor can
> >>>>> be used with standard AMD/Xilinx IPs including interrupt controller and
> >>>>> timer.
> >>>>>
> >>>>> Signed-off-by: Michal Simek <michal.simek@amd.com>
> >>>>> ---
> >>>>>
> >>>>>    .../devicetree/bindings/soc/amd/amd.yaml      | 26 +++++++++++++++++++
> >>>>
> >>>> Bindings for SoCs (and by extension boards with them) usually go to in
> >>>> $arch/$vendor.yaml not into soc/$vendor/$vendor.yaml. Why is this any
> >>>> different?
> >>>
> >>> I actually found it based on tracking renesas.yaml which describes one of risc-v
> >>> board. No problem to move it under bindings/riscv/
> >>>
> >>>>
> >>>>>    1 file changed, 26 insertions(+)
> >>>>>    create mode 100644 Documentation/devicetree/bindings/soc/amd/amd.yaml
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/soc/amd/amd.yaml b/Documentation/devicetree/bindings/soc/amd/amd.yaml
> >>>>> new file mode 100644
> >>>>> index 000000000000..21adf28756fa
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/soc/amd/amd.yaml
> >>>>> @@ -0,0 +1,26 @@
> >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>>> +%YAML 1.2
> >>>>> +---
> >>>>> +$id: http://devicetree.org/schemas/soc/amd/amd.yaml#
> >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>> +
> >>>>> +title: AMD Platforms
> >>>>> +
> >>>>> +maintainers:
> >>>>> +  - Michal Simek <michal.simek@amd.com>
> >>>>> +
> >>>>> +description: |
> >>>>> +  AMD boards with MicroBlaze V SOC
> >>>>> +
> >>>>> +properties:
> >>>>> +  $nodename:
> >>>>> +    const: '/'
> >>>>> +  compatible:
> >>>>> +    oneOf:
> >>>>> +      - description: AMD MicroBlaze V
> >>>>> +        items:
> >>>>> +          - const: amd,mbv
> >>>>
> >>>> You don't actually list any boards here, but instead permit having only
> >>>> the SoC compatible and no board one. The SoC compatible is also
> >>>> incredibly generic. Personally I don't think this binding makes any
> >>>> sense as it appears to exist as a catch all for anything using your
> >>>> new cores in any combination.
> >>>
> >>> I think I need to define any string for compatibility because it is standard
> >>> property. Because this is soft core it can be added to any board with AMD/Xilinx
> >>> chip. I don't have really an option to list all boards.
> >>
> >> Why? Either there is a product with this soft-core or there is not. It
> >> cannot be both.
> > 
> > I am doing basic enablement. I am not making product. Product will be done by 
> > our customers using this core.
> > There will be thousands of different configurations done by customers which will 
> > have products with it. Also there could be hundreds configurations done on the 
> > same board.
> 
> If this is the same board, then why there is compatible for it?
> 
> > 
> > Does it make sense to have board related compatible string like this if this 
> > evaluation board is used by a lot of customers?
> > "amd,kcu105-mbv-ABC-vXYZ", "amd,kcu105-mbv", "amd,mbv"
> 
> I miss the point what is the hardware. Evaluation board is the hardware.
> If someone changes it and makes a new product, it is a new product.
> 
> > 
> > Or I can define qemu one.
> > "amd,qemu-mbv", "amd,mbv"
> 
> QEMU is not hardware, so not.

But QEMU is an implementation with its own quirks and implementation 
details, and compatibles are tied to specific implementations. I'm fine 
with it and IIRC we already have some cases. I prefer saying 'qemu' here 
rather than just allowing a "generic" compatible alone because folks 
will tend to not think they can just reuse the qemu compatible when they 
will do that for a generic compatible. 

nit: qemu,mbv or something as 'qemu' is the vendor.

> 
> > 
> > I think customers should be adding their compatible string in front of generic one.
> 
> To what? To evaluation board? Why?
> 
> > 
> > Years ago I have done the same thing with Microblaze where compatible is defined 
> > as xlnx,microblaze only. 
> 
> Again, what is the use of such binding?
> 
> > When customer take this soft core, put IPs around and 
> > create a product they should extend it to be for example like this.
> > "xyz,my-product-1.0", "xlnx,microblaze";
> 
> So there is a product, not evaluation board.
> 
> > 
> > And over all of years I have never seen any single customer to try to push dt 
> > description for any Microblaze based product.

I think this FPGA stuff is all a bit special. I would ignore the 
customer product aspect because as Michal says here, we'll never see it. 
For upstream, just define something for what you are testing upstream 
with. 

Rob

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@amd.com
> 
> 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.

> 
>>
>>>
>>> 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?



Best regards,
Krzysztof

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@amd.com
>>
>> 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