-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Add minimal support for Renesas EK-RZ/A3M #91031
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
base: main
Are you sure you want to change the base?
Add minimal support for Renesas EK-RZ/A3M #91031
Conversation
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
* R9A07G066M04GBG MPU | ||
* 1GHz, Arm Cortex®-A55 core w/NEON extension | ||
* Built-in 128MB DDR3L DRAM | ||
* 128KB SRAM w/ECC |
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.
Since I see that the SRAM defined on the board layer is 72 KB, is this information correct?
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, SRAM is 128KB, but the first 56KB is reserved for bootloader, so only 72KB is available for use.
sram: memory@1e000 { | ||
compatible ="zephyr,memory-region", "mmio-sram"; | ||
reg = <0x1e000 DT_SIZE_K(72)>; | ||
zephyr,memory-region = "SRAM"; | ||
}; |
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.
As I see in the HWM, this SRAM is in the SoC layer. Is there a specific reason for this node being placed here, or is my information incorrect?
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.
SRAM is 128KB, but the first 56KB is reserved for bootloader, so only 72KB is available for use. The start address depends on the bootloader, so it has been moved to board layer.
default 512 | ||
|
||
config SYS_CLOCK_HW_CYCLES_PER_SEC | ||
default 24000000 |
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.
Since the CPU frequency you defined is 1 GHz, this number doesn't match. Should we retrieve this value from the device tree instead of using a fixed 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.
as above, get this value from dts using dts functions
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.
Thanks. The generic timer is supplied by osc (24MHz). I added a node in dts and modify to get it. Please help me check again.
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.
&gpio { | ||
status = "okay"; | ||
}; |
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.
Since the board has this node enabled, there's no need to overlay it in test.
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 removed this node. Thanks
default 512 | ||
|
||
config SYS_CLOCK_HW_CYCLES_PER_SEC | ||
default 24000000 |
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.
as above, get this value from dts using dts functions
header: partition@0 { | ||
label = "header"; | ||
reg = <0x00000000 0x200>; | ||
read-only; | ||
}; |
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.
is this for mcuboot? If so, this is not correct. If it's something else then disregard
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.
No, it isn't. An existing bootloader (pre-built binary) requires the header in a specific format to load the Zephyr image.
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.
hmm is that without blobs? Boards in zephyr must be able to run samples without usage of binary blobs to be accepted - see https://docs.zephyrproject.org/latest/contribute/bin_blobs.html#limited-scope for details
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.
Could you please help me check the html doc? We document it to guide users how to prepare the board including the bootloader.
https://builds.zephyrproject.io/zephyr/pr/91031/docs/boards/renesas/rza3m_ek/doc/index.html#programming-and-debugging
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.
it's not about preparing, either those 2 samples work as-is without blobs or the board cannot be accepted into zephyr, if you need a binary blob IPL to run any application then the test cannot be passed under the without blobs requirement
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.
Hi @nordicjm, @nashif, @kartben,
As the document https://docs.zephyrproject.org/latest/contribute/guidelines.html#licensing, the other licenses are also accepted (BSD 3-clause included), not only Apache 2.0
Also in the manifest of other vendors, they also use BSD 3-clause.
Example: https://github.com/zephyrproject-rtos/hal_nordic/blob/master/drivers/nrf_802154/driver/src/nrf_802154.c
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 just reviewed the Zephyr policy regarding external source code integration:
https://docs.zephyrproject.org/latest/contribute/external.html#submission-and-review-process
As my understanding that https://github.com/renesas/hal_renesas has already been approved by the TSC.
Do I need to request TSC approval again for adding the IPL source code to hal_renesas
?
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.
Hi @nordicjm
Apologies if my earlier message came across too direct. I really appreciate the discussion and your support in helping us navigate this properly.
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.
@nordicjm Apache 2.0 requirement only applies to zephyr mainline, not modules. Modules when approved and created, document used license which needs to be compatible. Any new additions to the module/HAL under this license falls under the same approval. So, just because something else under that same approved license is being added to a module does not require TSC approval.
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.
Hey, this needs a rebase and force push to pick up the CI error workaround. |
f75181f
to
6f7fa44
Compare
6d8fae3
to
fc5f9a0
Compare
fc5f9a0
to
bff6cd0
Compare
@nhutnguyenkc CI is failing and this needs a rebase -- just a reminder that feature freeze is today :) |
Add support for Renesas RZ/A3M Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
Add devicetree to support for Renesas RZ/A3M Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
This adds minimal support for board RZ/A3M-EK Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
Add pinctrl support for Renesas RZ/A3M Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
Add GPIO driver support for RZ/A3M Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
Exclude EK-RZ/A3M board as the redefined CONFIG_SRAM_BASE_ADDRESS degrades the BUILD_OUTPUT_ADJUST_LMA option that will generate a bin file >10GB Signed-off-by: Nhut Nguyen <nhut.nguyen.kc@renesas.com>
b2cfb69
bff6cd0
to
b2cfb69
Compare
@kartben due to an issue, it has been moved to v4.3.0. I updated the milestone. |
|
Add minimal support for EK-RZ/A3M as following:
Need: zephyrproject-rtos/hal_renesas#110
Doc: https://builds.zephyrproject.io/zephyr/pr/91031/docs/boards/renesas/rza3m_ek/doc/index.html