boards: peregrine: Introduce sam4l_wm400_cape

[nandojve]

The sam4l_wm400_cape is a beagle-bone cape integrated with a SAM4L SoC and RF233 IEEE 802.15.4 radio. This board has been used to validate SAM4L and write many drivers including TWIM, USB device stack and ESP-01 WiFi module. The board was developed in partnership with Universidade do Estado de Santa Catarina USFC to be used as gateway, mainly on IEEE 802.15.4 experiments developed by the Departamento de Engenharia de Automação e Sistemas EAS.

depends on #83475

[nandojve]

Hi @kartben ,

Is not possible to attach schematic pdf files on docs folder ?

 -:79: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#79: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400-BeagleBoneBlackShield.pdf

-:83: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#83: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400L.pdf

[kartben]

Hi @kartben ,

Is not possible to attach schematic pdf files on docs folder ?

 -:79: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#79: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400-BeagleBoneBlackShield.pdf

-:83: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#83: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400L.pdf

I guess you should chmod u-x these files. But in any case I don't think we want to clutter git repo with PDF files and make everyone's git operations (clone, etc) slower and slower over time.
Can't you add an external link?

[nandojve]

Hi @kartben ,
Is not possible to attach schematic pdf files on docs folder ?

 -:79: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#79: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400-BeagleBoneBlackShield.pdf

-:83: ERROR:EXECUTE_PERMISSIONS: do not set execute permissions for source files
#83: FILE: boards/peregrine/sam4l_wm400_cape/doc/WM-400L.pdf

I guess you should chmod u-x these files. But in any case I don't think we want to clutter git repo with PDF files and make everyone's git operations (clone, etc) slower and slower over time. Can't you add an external link?

I'll drop for the moment. It can be added later.

[nordicjm]

we don't do this for other boards with random newlines, why do we need this here?

[nandojve]

Because makes it more readable.

[nordicjm]

Marking as unresolved because I did not mark this as resolved and see this as an issue

[nandojve]

I would like you to stop to say it is an issue. If it is an issue you should point out at least one time were it is documented.

BTW, I don't see any inconsistency. This is from current devicetree spec v0.4.

I assume that if it is on the documentation example is correct.
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4 pg42

[nordicjm]

Needs fixing as per comments

[nandojve]

Hi @nordicjm ,

I appreciate if you could re visit this PR.

[mbolivar]

As discussed on Discord, there doesn't seem to be a good argument against 'paragraphs' in devicetree properties for readability. @nordicjm can you please clarify your position when you get a chance? Ideally on Discord if that's OK with you since that's where we have the bulk of the conversation going IMO

[nandojve]

Hi @nordicjm ,

Please, recheck.

Besides I don't agreed with your review I made the changes you asked on last PR.
The below are the devicetree rules and there is no rule that prevents paragraph. The second entry says that we should follow the spec and I already show a picture from v0.4 that have a paragraph.

• Indent with tabs.
• Follow the Devicetree specification conventions and rules.
  
• Use dashes (-) as word separators for node and property names.
• Use underscores (_) as word separators in node labels.
• Leave a single space on each side of the equal sign (=) in property definitions.
• Don’t insert empty lines before a dedenting };.
• Insert a single empty line to separate nodes at the same hierarchy level.

I already made far more then necessary to have this board in, including a new watchdog driver and fix on watchdog tests just because you don't approve a config on a board to disabled it with the argument that something is wrong at SoC level without look the history of this driver, which still have the issue open.

Now, I need this board in tree to migrate the USB driver and I hope I can get it. If I can not get your approval after this change I understand that this is a personal attack and need to escalate to solve the issue.

[nordicjm]

I already made far more then necessary to have this board in, including a new watchdog driver and fix on watchdog tests just because you don't approve a config on a board to disabled it with the argument that something is wrong at SoC level without look the history of this driver, which still have the issue open.

Watchdog shouldn't even be enabled by default so the original setup of that is wrong https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#general-recommendations

Now, I need this board in tree to migrate the USB driver and I hope I can get it. If I can not get your approval after this change I understand that this is a personal attack and need to escalate to solve the issue.

You've made this same nonsense claim multiple times now and I'm getting tired of reading it @kartben as per zephyr guidelines please intervene.

As per original message:

the issue is consistency, you are not following existing styles in boards and making your own
just to point out this guideline pr which you approved stating to follow what exists in the tree already https://github.com/zephyrproject-rtos/zephyr/pull/83117/files#diff-d84ff1b1f7f14c50055618e1e0f6a0986cae639ab168881fc493de64ebd76971R544
#83117 (comment)

Out of 886 board dts files in zephyr, the following have spaces in aliases:

boards/mediatek/mt8196/mt8196_adsp.dts line 107
boards/microchip/mec1501modular_assy6885/mec1501modular_assy6885.dts line 25
boards/mxchip/az3166_iotdevkit/az3166_iotdevkit.dts line 19
boards/mxchip/az3166_iotdevkit/az3166_iotdevkit.dts line 23
boards/others/serpente/serpente.dts line 30

4 out of 886 = 0.4%

The C specification has lots of things zephyr doesn't allow, just because something can be used doesn't mean it should be used

[decsny]

@nordicjm @nandojve I added the dev review label, since this argument does not seem to want to resolve, if you can still not resolve it by next thursday then please show up to that meeting
@MaureenHelm

[nandojve]

I already made far more then necessary to have this board in, including a new watchdog driver and fix on watchdog tests just because you don't approve a config on a board to disabled it with the argument that something is wrong at SoC level without look the history of this driver, which still have the issue open.

Watchdog shouldn't even be enabled by default so the original setup of that is wrong https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#general-recommendations

You are implying things without know the problem, or just ignoring. I already point out to you the #23282, which stills open.
The driver that I made helped inclusive to find that the disable call was not in the basic api tests. Just shows how the watchdog is a complicated feature. The way you are reviewing is to give priority to style instead of the whole situation. This only shows that you prefer fulfill your needs then project needs.

Now, I need this board in tree to migrate the USB driver and I hope I can get it. If I can not get your approval after this change I understand that this is a personal attack and need to escalate to solve the issue.

You've made this same nonsense claim multiple times now and I'm getting tired of reading it @kartben as per zephyr guidelines please intervene.

As per original message:

the issue is consistency, you are not following existing styles in boards and making your own

This is not true. There are many boards that have paragraph on properties.
You are using 1 node (aliases) to create an illusion that there are no consistency.

just to point out this guideline pr which you approved stating to follow what exists in the tree already https://github.com/zephyrproject-rtos/zephyr/pull/83117/files#diff-d84ff1b1f7f14c50055618e1e0f6a0986cae639ab168881fc493de64ebd76971R544

How this PR is not in sync with this board https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/atmel/sam/sam4l_ek/sam4l_ek.dts ?

#83117 (comment)
Out of 886 board dts files in zephyr, the following have spaces in aliases:
boards/mediatek/mt8196/mt8196_adsp.dts line 107
boards/microchip/mec1501modular_assy6885/mec1501modular_assy6885.dts line 25
boards/mxchip/az3166_iotdevkit/az3166_iotdevkit.dts line 19
boards/mxchip/az3166_iotdevkit/az3166_iotdevkit.dts line 23
boards/others/serpente/serpente.dts line 30
4 out of 886 = 0.4%
The C specification has lots of things zephyr doesn't allow, just because something can be used doesn't mean it should be used

The aliases node was adjusted on the last push to fulfill your personal vision. You are using the aliases node to try exploit a rule about paragraphs that do not exists and people do not agreed.

The prove you are using this as an excuse, this is you inside dts folder complaining about paragraph.
Originally posted by @nordicjm in #84173 (comment)

The above link is a draft PR and you jump on it just to point out the same thing, your personal wishes. I took the time to check dts folder and the below is the list of vendors that have been using paragraph, may not be the full list:
ADI
Ambiq
Atmel
Broadcom
Espressif
FVP
Infineon
Intel
Microchip
Nordic
Nuvoton
Openisa
NXP
QEMU
Raspberrypi
Renesas
Rockchip
Sensry
SiFive
Silabs
ST
TI
WCH
Xilinx
Xtensa

Here is the point were the "rule of paragraph" was made

seemingly we need something to prevent random newline spacing in the same parts i.e. https://github.com/zephyrproject-rtos/zephyr/pull/83310/files#diff-a188c48a9493b631f516e6672a23b4792710f6c3e7375e7b4956957a9c22d3edR18

I hope you reconsider your position in this matter and stop to push things that people do not agreed.

[nordicjm]

I already made far more then necessary to have this board in, including a new watchdog driver and fix on watchdog tests just because you don't approve a config on a board to disabled it with the argument that something is wrong at SoC level without look the history of this driver, which still have the issue open.

Watchdog shouldn't even be enabled by default so the original setup of that is wrong https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html#general-recommendations

You are implying things without know the problem, or just ignoring. I already point out to you the #23282, which stills open. The driver that I made helped inclusive to find that the disable call was not in the basic api tests. Just shows how the watchdog is a complicated feature. The way you are reviewing is to give priority to style instead of the whole situation. This only shows that you prefer fulfill your needs then project needs.

Then I'm not really sure why you are placing blame on me for needing to add a driver that is required for the hardware to function

Now, I need this board in tree to migrate the USB driver and I hope I can get it. If I can not get your approval after this change I understand that this is a personal attack and need to escalate to solve the issue.

You've made this same nonsense claim multiple times now and I'm getting tired of reading it @kartben as per zephyr guidelines please intervene.
As per original message:

the issue is consistency, you are not following existing styles in boards and making your own

This is not true. There are many boards that have paragraph on properties. You are using 1 node (aliases) to create an illusion that there are no consistency.

There is no rule on it so I will drop the point, but conversely by having this you are saying that the following is completely acceptable:

	rf2xx@0 {
		compatible = "atmel,rf2xx";

		reg = <0x0>;

		spi-max-frequency = <6000000>;

		irq-gpios = <&gpioa 20 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;

		reset-gpios = <&gpioa 10 GPIO_ACTIVE_LOW>;

		slptr-gpios = <&gpioa 9 GPIO_ACTIVE_HIGH>;

		status = "okay";
	};

The point in consistency is to stop things like that.

The prove you are using this as an excuse, this is you inside dts folder complaining about paragraph. Originally posted by @nordicjm in #84173 (comment)

The above link is a draft PR and you jump on it just to point out the same thing, your personal wishes.

It's a board/soc PR, PRs get reviewed. I don't get notified on board PRs being opened nor being marked from draft -> ready so they get reviewed as and when I see them and given that it's a continuation of a previous one which had major issues with the commit structure, it was worth checking.

I hope you reconsider your position in this matter and stop to push things that people do not agreed.

Given it's not an explicit rule and the from input of others on the topic, I will no longer check this in PRs but I expect a PR to be raised in future as indicated above and see no-one raise any issues on the lines. I apologise for this and length of time it's gone on for.