boards: dts: soc: bflb: misc fixes

[kartben]

Use folders named "bflb" as it's the official vendor prefix.

Fixes BL604E not properly being listed under Bouffalo vnedor in board catalog (https://docs.zephyrproject.org/latest/boards/index.html#name=BL604E)

Also add .. zephyr:board-supported-runners:: to the BL604E doc to automatically document supported runners.

[nandojve]

Nak on this.

You should not depends on vendor list defined for devicetree bindings to proper display the boards information. The information of the vendor can be extracted from the already defined field.

zephyr/boards/bouffalolab/bl60x/bl604e_iot_dvk/board.yml

Line 4 in bf104d4

vendor: bflb

[kartben]

Nak on this.

You should not depends on vendor list defined for devicetree bindings to proper display the boards information. The information of the vendor can be extracted from the already defined field.

zephyr/boards/bouffalolab/bl60x/bl604e_iot_dvk/board.yml

Line 4 in bf104d4

vendor: bflb

Sure, I can fix this (it turns out that many boards actually have wrong vendor in the board.yml, so it was simply easier to rely on folder name as this one is always right).

This doesn't change the fact that "bouffalolab" would be the only vendor in-tree not using the vendor prefix for its folder names which I am sure you will admit is probably not ideal?

[kartben]

You should not depends on vendor list defined for devicetree bindings to proper display the boards information.

See #89024.
But folder names should be fixed nevertheless.

[VynDragon]

Makes sense to me.

[nandojve]

This doesn't change the fact that "bouffalolab" would be the only vendor in-tree not using the vendor prefix for its folder names which I am sure you will admit is probably not ideal?

IMHO this should not be an excuse to change the folder name. Right now the tool seems to relying on the folder name which I believe it is not be the best way. On my perspective, the new hardware model introduced freedom to allow us to have different folder structures, define metadata (both SoC and Board) and expand. The metadata binds the folder structure defined by the vendor and that should be the ideal source of information. This way we can have freedom on the folder structure names to make it easy to ready and organize the content.

So, if we enforce people to use the metadata and fill any the missing fields the tools can collect the correct information in the right way from the right place. We can share the code that collect the info and use that as standard instead "force" naming and avoid multiple source of truth.

[kartben]

This doesn't change the fact that "bouffalolab" would be the only vendor in-tree not using the vendor prefix for its folder names which I am sure you will admit is probably not ideal?

IMHO this should not be an excuse to change the folder name. Right now the tool seems to relying on the folder name which I believe it is not be the best way. On my perspective, the new hardware model introduced freedom to allow us to have different folder structures, define metadata (both SoC and Board) and expand. The metadata binds the folder structure defined by the vendor and that should be the ideal source of information. This way we can have freedom on the folder structure names to make it easy to ready and organize the content.

So, if we enforce people to use the metadata and fill any the missing fields the tools can collect the correct information in the right way from the right place. We can share the code that collect the info and use that as standard instead "force" naming and avoid multiple source of truth.

Yeah, but it's just the way boards and socs must be organized, sorry.

If you really want, I can drop the change to dts/riscv/bouffalolab since that one is not actually a requirement as far as I can tell.

This way we can have freedom on the folder structure names to make it easy to ready and organize the content.

BTW this is exactly the point - there are some areas where complete freedom is not desirable, and there is an expectation from folks that they will find boards and socs in a "predictable" location in the main Zephyr tree.

[nandojve]

Yeah, but it's just the way boards and socs [must be organized].

I see, thank you for pointing out.
Go ahead and keep same folders for dts.

Note: Not sure if it is necessary change this line too

zephyr/soc/bouffalolab/soc.yml

Line 2 in b469fc1

- name: bouffalolab_bflb

[kartben]

Yeah, but it's just the way boards and socs [must be organized].

I see, thank you for pointing out. Go ahead and keep same folders for dts.

Note: Not sure if it is necessary change this line too

zephyr/soc/bouffalolab/soc.yml

Line 2 in b469fc1

- name: bouffalolab_bflb

Yeah good point.
Maybe @nordicjm can comment here but my recommendation would be to actually just remove the family name altogether. AFAIK it's not mandatory to have a family (check e.g. all socs with "<no family>" in the board catalog), and in this case would be better than making up a name for something that doesn't really correspond to anything in the vendor catalog (as opposed to, say, Atmel SAM0 family)

[nordicjm]

Yeah, but it's just the way boards and socs [must be organized].

I see, thank you for pointing out. Go ahead and keep same folders for dts.
Note: Not sure if it is necessary change this line too

zephyr/soc/bouffalolab/soc.yml

Line 2 in b469fc1

- name: bouffalolab_bflb

Yeah good point. Maybe @nordicjm can comment here but my recommendation would be to actually just remove the family name altogether. AFAIK it's not mandatory to have a family (check e.g. all socs with "" in the board catalog), and in this case would be better than making up a name for something that doesn't really correspond to anything in the vendor catalog (as opposed to, say, Atmel SAM0 family)

Family name is completely optional, it can go, or be renamed

[VynDragon]

Ah so if it can go i'd like to take this opportunity to recommend making it either go back (? maybe not, different code trees) to SOC_FAMILY_BFLB instead of SOC_FAMILY_BOUFFALOLAB_BFLB, or consider that BL60x is the family (bl602 family in bflb terms) and the socs are really bl602 and bl604, matched to footprints. I am not sure what the best way would be though.

[kartben]

@nandojve do you want me to add the dropping of the family name to this PR?

EDIT: posted at the same time as @VynDragon, woops. I'm fine with SOC_FAMILY_BFLB, but having no family and just working at the "series" level would be fine too IMO (e.g CMakeLists.txt for the hal would test for SOC_SERIES_BL60X instead of SOC_FAMILY_BOUFFALOLAB_BFLB, etc.). Will let @nandojve make the call :)

[VynDragon]

@nandojve do you want me to add the dropping of the family name to this PR?

EDIT: posted at the same time as @VynDragon, woops. I'm fine with SOC_FAMILY_BFLB, but having no family and just working at the "series" level would be fine too IMO (e.g CMakeLists.txt for the hal would test for SOC_SERIES_BL60X instead of SOC_FAMILY_BOUFFALOLAB_BFLB, etc.). Will let @nandojve make the call :)

All the rest of the code is based on SOC_SERIES_BLxxx checks anyway

[nandojve]

Hi @kartben,

Thank you for asking. I would like to have the SOC_FAMILY_BFLB.