-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Arduino UNO R4 #60760
Conversation
There's a HAL already for SmartBond devices (https://github.com/zephyrproject-rtos/hal_renesas) and code for both that and R-Car. @andrzej-kaczmarek @blauret @aaillet @lorc any idea if there's interest to have official support for RA family? |
My team is mostly interested in CortexA cores and virtualization, so I'm afraid no one from my side can help with this. |
It's great initiative. Just a few comments:
My team is focused on the Smartbond devices. I'll try to reach out in the organization to see if someone can help. That said, it's en of July and it's summer holidays it could take some time. |
27041f5
to
00560d7
Compare
Thank you for responses.
I misunderstood the need for Renesas-specific software for debugging.
At a glance, RA package contains no FSP sources. FSP sources are in the separated repository framework-renesas-fsp.
Thanks a lot.
Have a nice holidays! |
Hi, I'm afraid that as people from other teams, I'm mainly focusing on my part, Cortex-R support for R-Car SoCs. From my point of view, Smartbond code and HAL will not fit RA series as Smartbond is coming from a brand that Renesas bought. As this series was already existing before it's brand acquirement, I think it's not using Renesas IPs. On the other hand, it may be possible to reuse R-CAR code if same IPs are used. Concerning interest from Renesas to officially support Zephyr on RA/RZ this series, I'll ask my internal contact if plans are existing ! |
3cba69b
to
1971b88
Compare
Thank you for response.
I got it. The smartbond HAL provide with Apache2 license.
From this viewpoint, using BSP may not be suitable if making a standard driver between series.
Thanks a lot! |
property-allowlist: | ||
- bias-disable | ||
- bias-pull-up | ||
- drive-open-drain | ||
- input-enable | ||
- drive-strength |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are these handled? I can't see them being referenced in pinctrl_soc.h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they're not used, they shouldn't be allowed yet, this will create confusion to the users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I got it.
I removed it.
To avoid complicating the initial code for supporting the SoC, I have implemented only the bare minimum for now. Signed-off-by: TOKITA Hiroshi <[email protected]>
11b4b57
to
389a7dd
Compare
include: | ||
- name: pincfg-node.yaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should be removed entirely, none of the props are used right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a little misunderstanding. I deleted it additionally.
Thank you for pointing it out.
389a7dd
to
891ac1d
Compare
static int ra_icu_init(const struct device *dev) | ||
{ | ||
ARG_UNUSED(dev); | ||
|
||
return 0; | ||
} | ||
|
||
DEVICE_DT_INST_DEFINE(0, ra_icu_init, NULL, NULL, NULL, PRE_KERNEL_1, CONFIG_INTC_INIT_PRIORITY, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just pass NULL to the init function, it;s now optional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed as so.
reg = <0x40040020 0x20>; | ||
gpio-controller; | ||
#gpio-cells = <2>; | ||
port-no = <1>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this property needed? this is not hw description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is an index of gpio.
The index can be calculated from the address.
I replaced it with the calculated value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the RA series, all GPIO ports use continuous addresses. Even if there is a dropout in the middle, the port number will not change, so calculation is possible.
CM4-based SoC uses 0x40040000 to 0x40040160 for ioport0 .. ioportb.
In the case of CM33-based SoC, it also uses 0x40080000 to 0x40080160.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In past situations, we've always restricted DT to the hardware description itself (port-no is needed here because of how software works, not because it describes hw uniquely).
drivers/gpio/gpio_ra.c
Outdated
static int gpio_ra_init(const struct device *dev) | ||
{ | ||
return 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
To avoid complicating the initial code for supporting the SoC, I have implemented only the bare minimum for now. Signed-off-by: TOKITA Hiroshi <[email protected]>
891ac1d
to
722751a
Compare
Add initial support for Renesas RA GPIO. To avoid complicating the initial code for supporting the SoC, I have implemented only the bare minimum for now. Signed-off-by: TOKITA Hiroshi <[email protected]>
Adding initial support for Renesas RA UART. To avoid complicating initial code for supporting the SoC, I have implemented only the bare minimum for now. Signed-off-by: TOKITA Hiroshi <[email protected]>
Add support for the Arduino UNO R4 Minima. This board is the newest version of Arduino that uses Renesas RA4M1 SoC. This commit provides only limited support to simplify the initial support patch. Signed-off-by: TOKITA Hiroshi <[email protected]>
Renesas RA always uses interrupt handlers dynamically. But this test requires static vector tables. So, it needs to exclude platforms that use Renesas RA. Signed-off-by: TOKITA Hiroshi <[email protected]>
722751a
to
9c4de38
Compare
What's keeping Zephyr from supporting Arduino Uno R3? Not enough RAM? |
ZephyrRTOS intends 32bit/64bit MPUs. I think it may difficult to port 16bit/8bit. |
Adds support for Arduino UNO R4.
I have verified that hello_world, blinky, and button sample work with this PR.
We can flash and debug with the cmsis-dap adapter and pyOCD.
But not supporting flash program with dfu-util, because Arduino IDE use not standard version of dfu-util.
To avoid complicating initial code for supporting the SoC,
I have implemented only the bare minimum for now.
We can't use FSP that the BSP Renesas provides is not an OSS license (It doesn't allow execution outside of Renesas SoCs).I write this PR entirely from scratch, so it is not dependent on FSP.But it is good to use FSP for reliability reasons if we can use it.This PR is still remain some TODOs.Because it still needs to complete implementing some functions (clock_control, pinctrl, etc.), mark them as TODO,depending on it.This PR changes R-Car UART driver to support RA UART.But I don't have R-Car board, so I can't test it.If Renesas plans to support Zephyr officially, I would prefer to follow that policy. (But that doesn't mean we can't proceed without it.)