-
Notifications
You must be signed in to change notification settings - Fork 7.3k
dts: wch: Enable using whole flash with CH32V208 And reorganize soc folder for future deduplication #87345
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?
dts: wch: Enable using whole flash with CH32V208 And reorganize soc folder for future deduplication #87345
Conversation
1d88336
to
d4880f1
Compare
d4880f1
to
cbb1ae2
Compare
cc @kholia (need to open a issue to add you to the collaborators) |
@fkokosinski @miggazElquez I added the reorganization commit, please check and advise |
9b716f6
to
734dc55
Compare
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 looks good to me, I have rebased my code for the 303 on top of this and everything works.
modules/hal_wch/CMakeLists.txt
Outdated
@@ -1,3 +1,3 @@ | |||
if(CONFIG_SOC_CH32V003 OR CONFIG_SOC_SERIES_QINGKE_V4C) | |||
if(CONFIG_SOC_CH32V003 OR CONFIG_SOC_SERIES_QINGKE_V4) |
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.
Wouldn't it be better to put just CONFIG_SOC_FAMILY_CH32V
? I don't see why a ch32v soc wouldn't use the HAL.
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.
Done
4fbd942
to
19ee357
Compare
@nzmichaelh As you are the assignee this can't be merged without your approval. |
ee20e07
19ee357
to
ee20e07
Compare
@nzmichaelh please take a look. |
ee20e07
to
015859c
Compare
Rebased on main due to CI fail. |
drivers/timer/Kconfig.wch_ch32v00x
Outdated
@@ -3,6 +3,6 @@ | |||
|
|||
config CH32V00X_SYSTICK | |||
bool "CH32V00X systick timer" | |||
depends on SOC_CH32V003 || SOC_SERIES_QINGKE_V4C | |||
depends on SOC_CH32V003 || SOC_SERIES_QINGKE_V4 |
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 action required: I agree with the direction here, as the systick is part of the QingKe CPU
@@ -1,7 +1,7 @@ | |||
# Copyright (c) 2025 MASSDRIVER EI (massdriver.space) |
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.
TL;DR: I think we should rename this to ch32v20x_30x as microarchitecture != series, but doing this in a follow up PR is fine.
Long story: I've been thinking about the same thing at https://github.com/nzmichaelh/zephyr/tree/ch32v006
The issue is that QingKe VXY isn't really a series as per https://docs.zephyrproject.org/latest/hardware/porting/soc_porting.html The CH32V003 has a QingKe V2A, certain GPIO features, and AFIO mapping; while the CH32V006 and others in that series have a QingKe V2C and different GPIO, AFIO.
This is a coincidence, and as GPIO/AFIO configuration is not a feature of the microarchitecture, I don't think we should use the microarchitecture as the series.
I'd prefer keeping the directory as-is at the moment and revisiting in the future. Your choice though.
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 only for sorting, there is no implication of having actual series behind it (at least for me): the support for Socs like CH592 was mentioned in the original discussion about this, and in the end, things are still set on soc/actual serie(ch32v30x, ch32v203, ch32v208, etc) level (and do note ch32v203 cant be shared with ch32v208 for example! the WCH 'series' dont actually mean much).
@@ -18,12 +18,15 @@ GTEXT(__initialize) | |||
|
|||
SECTION_FUNC(vectors, ivt) | |||
.option norvc | |||
/* Jump to 0x08000008, into the main flash zone where j __start is */ | |||
lui x5, 0x8000 | |||
jr 0x8(x5) |
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 doesn't the j __start
work? Is the linker file 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.
no, it jumps where the j start is, at 0x08000008. The actual issue it is needed with is because the aliased zone contains only the zero-wait flash zone, and when linking for running at 0x08000000, there is also the issue of the offset jumps and generally offset vs absolute adresses which wont always be correct.
In practice, to use non-zero wait flash or run at 0x08000000 instead of at 0x0 in the aliased copy, you need this or it will crash at some point in the code (due to the aforementioned issues).
@VynDragon can you rebase please? |
Enables using the whole flash on CH32V208 Signed-off-by: Camille BAUD <[email protected]>
Reorganization for deduplication Signed-off-by: Camille BAUD <[email protected]>
015859c
to
a0682e9
Compare
Done, rebased on main, hopefully I didnt mess it up. |
Enables using the whole flash on CH32V208
This needs #87141This fixes it differently.and #85395