Some drivers use INIT_BOARD_EXPORT, it is not necessary,
it is enough to use INIT_DEVICE_EXPORT for genearl drivers.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
See `components/drivers/include/drivers/watchdog.h`
maco definition of
RT_DEVICE_CTRL_WDT_GET_TIMEOUT
RT_DEVICE_CTRL_WDT_SET_TIMEOUT
RT_DEVICE_CTRL_WDT_GET_TIMELEFT
The wdt timeout time unit is defined as seconds in the API, but
the code incorrectly uses ms.
Correct this and comply with the API definition.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Reviewed-by: Yuanjie He <943313837@qq.com>
Reviewed-by: Shell <smokewood@qq.com>
Rewrote the spi driver.
Reuse the driver code from https://github.com/sophgo/cvi_alios_open,
which is Apache 2.0 licenced.
Signed-off-by: flyingcys <flyingcys@163.com>
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
```
./bsp/cvitek/drivers/drv_wdt.c: In function '_wdt_control':
warning: assignment to 'void *' from 'unsigned int' makes pointer
from integer without a cast [-Wint-conversion]
119 | wdt_device->parent.user_data = (rt_uint32_t)(*(rt_uint32_t *)arg);
| ^
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
122 | *(rt_uint32_t *)arg = (rt_uint32_t)wdt_device->parent.user_data;
| ^
```
Rootcasue: It's not portable to store integar in a pointer.
Solution: use global _wdt_dev to store the timeout value.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
The ADC controller needs to be calibrated during the initialization
phase, otherwise the measured voltage value will be inaccurate.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
In the new design, we require the user to manually enter the
PinName (as a string) in menuconfig instead of being given
menu items to select.
The original method will lead to too many menu item-related
macros being defined in the code, causing ifdef and other
codes scatter everywhere in the driver code, which is
inconvenient to maintain.
The new design adds a pinmux driver module to manage the
multiplexing of pins. This patch provides this driver module.
P.S., the reason why users are allowed to specify pinname
in a string instead of the pin number is mainly because
the technical manual provided by the SOC manufacturer
does not have numbers for some pins, only names.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Reviewed-by: Yuanjie He <943313837@qq.com>
Reviewed-by: Shell <smokewood@qq.com>
The contents of the SOC type part in the Kconfig configuration
are retained, and other parts related to I2C pin multiplexing
selection have been rolled back.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Reviewed-by: Yuanjie He <943313837@qq.com>
Reviewed-by: Shell <smokewood@qq.com>
* [bsp][hpmicro] add weak handle_trap implementation
- added weak handle_trap implementation
Signed-off-by: Fan YANG <fan.yang@hpmicro.com>
* [libcpu][risc-v][common] remove weak handle_trap function
- removed weak handle_trap function from trap_common.c
Signed-off-by: Fan YANG <fan.yang@hpmicro.com>
---------
Signed-off-by: Fan YANG <fan.yang@hpmicro.com>
The changes unify the tick.c implementations for all risc-v64
architectures, leveraging the CPUTIME feature. This refactoring was
necessary to streamline the codebase, and ensure consistent timer
handling across different platforms.
Changes:
- Updated `Kconfig` in `bsp/cvitek/cv18xx_risc-v` to fix formatting issues.
- Updated .config for BSPs to update `CPUTIME_TIMER_FREQ`
- Updated header of for API `riscv_cputime_init`
- Initialized riscv timer on `rt_hw_tick_init`
- Refactored `tick.c` and `tick.h` in `libcpu/risc-v/t-head/c906` and `libcpu/risc-v/virt64`:
- Replaced direct use of `rdtime` with `clock_cpu_gettime`.
- Removed redundant timer frequency definitions.
- Added static assertions to check the value of `CPUTIME_TIMER_FREQ`.
- Initialized `tick_cycles` based on `CPUTIME_TIMER_FREQ`.
- Integrated `ktime` support for tick initialization.
Signed-off-by: Shell <smokewood@qq.com>
Reviewed-on: https://github.com/RT-Thread/rt-thread/pull/9164
Reviewed-by: Chen Wang <unicorn_wang@outlook.com>
* [bsp/allwinner] feat: porting to RT_USING_DEVICE_OPS
This patch ports the codebase to use the RT_USING_DEVICE_OPS structure,
which is required by v5.1.0 Smart kernel, improves modularity and makes
it easier to manage device operations by consolidating them into a
single structure, enhancing maintainability and future scalability.
Changes:
- Added RT_USING_DEVICE_OPS conditionals to partition.c and drv_sdmmc.c.
- Defined rt_device_ops structures for partition and sdmmc drivers.
- Updated device initialization to use the ops structure if defined.
- Replaced direct function calls with rt_dev_control, rt_dev_read, and
rt_dev_write macros where applicable.
- Removed redundant us_delay function from os.c.
Signed-off-by: Shell <smokewood@qq.com>
* feat: update configuration
* feat: fixup compiler warning
---------
Signed-off-by: Shell <smokewood@qq.com>
* [libcpu] support for ARCH_REMAP_KERNEL
These changes introduce support for the ARCH_REMAP_KERNEL configuration,
which isolates kernel space in high virtual address regions. This feature
is necessary to enhance memory protection and management by segregating
user and kernel spaces more effectively.
Changes:
- Updated conditional macros to check for ARCH_REMAP_KERNEL instead of
ARCH_KERNEL_IN_HIGH_VA in board initialization files to reflect the new
configuration option.
- Modified qemu-virt64-riscv Kconfig and SConstruct files to include and
utilize ARCH_REMAP_KERNEL.
- Created a new linker script `link_smart.lds` for smart linking in qemu-virt64-riscv.
- Updated rtconfig.py to use a more flexible execution path setup.
- Enhanced user address space definitions in `lwp_arch.h` to support the
new virtual address mappings.
- Adjusted kernel memory initialization and mapping logic in `c906/mmu.c`
and `virt64/mmu.c` to account for high virtual address regions.
- Added Kconfig option to enable ARCH_REMAP_KERNEL for RISCV64 architectures.
- Enhanced memory setup functions to support new mapping scheme, including
updates to early page table setup and address relocation logic.
These modifications ensure that the system can utilize high memory
addresses for the kernel, improving memory isolation and system stability.
Signed-off-by: Shell <smokewood@qq.com>
* fixup: CI run failed
* bsp: default config without using smart
* fixup: static checks
* restore rt_hw_mmu_kernel_map_init for D1
---------
Signed-off-by: Shell <smokewood@qq.com>
- added new boards: hpm5300evk, hpm5301evklite and hpm6800evk
- upgaded hpm_sdk
- driver updates and bugfixes
- add hpmicro BSPs to CI
Signed-off-by: Fan YANG <fan.yang@hpmicro.com>
* bsp: cvitek: kconfig: add wdt for cv18xx_riscv
Add Watchdog timer in Kconfig.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* drv: cvitek: remove using macro from source file
Building of source file should be controlled by SConscript,
but not in source file itself.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp: cvitek: kconfig: add i2c for cv18xx_riscv
Add I2C in Kconfig for c906B.
Note, the IRQ# is different from that of c906L.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp: cvitek: kconfig: add rtc for cv18xx_riscv
Add RTC in Kconfig for c906B.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp: cvitek: fix channel issue for pwm driver
The original code confuses the concepts of controllers and channels.
Fixed it and do some code cleanup.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp:cvitek: add i2c pinmux config for cv18xx_riscv
Pinmux in driver code is controlled by SOC type, bcos driver
code should be general and support all pins defined by SoC.
Pinmux configuration in Kconfig is controlled by BOARD type,
bcos when we operate on board, it does not expose all chip-level
pin signals and we can only use part of them.
Following is I2C signals exported by duo family. Details see
https://milkv.io/docs/duo/overview.
Note: we have not added support for duo-S.
Duo
===
NAME I2C CV1800B/GPIO <PINNAME>__<FUNCNAME>
---- --- ------------ ---------------------
GP0 I2C0_SCL XGPIOA[28] IIC0_SCL__IIC0_SCL
GP1 I2C0_SDA XGPIOA[29] IIC0_SDA__IIC0_SDA
GP4 I2C1_SCL PWR_GPIO[19] SD1_D2__IIC1_SCL
GP9 I2C1_SCL PWR_GPIO[18] SD1_D3__IIC1_SCL
GP11 I2C1_SCL XGPIOC[10] PAD_MIPIRX0N__IIC1_SCL
GP5 I2C1_SDA PWR_GPIO[20] SD1_D1__IIC1_SDA
GP8 I2C1_SDA PWR_GPIO[21] SD1_D0__IIC1_SDA
GP10 I2C1_SDA XGPIOC[9] PAD_MIPIRX1P__IIC1_SDA
GP7 I2C3_SCL PWR_GPIO[22] SD1_CMD__IIC3_SCL
GP6 I2C3_SDA PWR_GPIO[23] SD1_CLK__IIC3_SDA
Duo 256m
========
NAME I2C CV1800B/GPIO <PINNAME>__<FUNCNAME>
---- --- ------------ ---------------------
GP4 I2C1_SCL PWR_GPIO[19] SD1_D2__IIC1_SCL
GP9 I2C1_SCL PWR_GPIO[18] SD1_D3__IIC1_SCL
GP5 I2C1_SDA PWR_GPIO[20] SD1_D1__IIC1_SDA
GP8 I2C1_SDA PWR_GPIO[21] SD1_D0__IIC1_SDA
GP11 I2C2_SCL XGPIOC[15] PAD_MIPI_TXP1__IIC2_SCL
GP10 I2C2_SDA XGPIOC[14] PAD_MIPI_TXM1__IIC2_SDA
GP7 I2C3_SCL PWR_GPIO[22] SD1_CMD__IIC3_SCL
GP6 I2C3_SDA PWR_GPIO[23] SD1_CLK__IIC3_SDA
Duo S
=====
NAME I2C CV1800B/GPIO <PINNAME>__<FUNCNAME>
---- --- ------------ ---------------------
J3-B18 I2C1_SCL XGPIOB[18] VIVO_D3__IIC1_SCL
J3-B12 I2C1_SCL XGPIOB[12] VIVO_D9__IIC1_SCL
J3-B11 I2C1_SDA XGPIOB[11] VIVO_D10__IIC1_SDA
J3-B13 I2C2_SCL XGPIOB[13] VIVO_D8__IIC2_SCL
J4-E1 I2C2_SCL PWR_GPIO[1] PWR_GPIO1__IIC2_SCL
J3-B14 I2C2_SDA XGPIOB[14] VIVO_D7__IIC2_SDA
J4-E2 I2C2_SDA PWR_GPIO[2] PWR_GPIO2__IIC2_SDA
J3-B20 I2C4_SCL XGPIOB[20] VIVO_D1__IIC4_SCL
J4-B1 I2C4_SCL XGPIOB[1] ADC3__IIC4_SCL
J3-B21 I2C4_SDA XGPIOB[21] VIVO_D0__IIC4_SDA
J4-B2 I2C4_SDA XGPIOB[2] ADC2__IIC4_SDA
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Signed-off-by: flyingcys <flyingcys@163.com>
* bsp:cvitek: remove using macro from source file for i2c
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp:cvitek: unify menu message text for i2c as other drivers
Other dirvers has no extra word "HW".
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* bsp:cvitek: add i2c pinmux config for c906_little
Porting what we have done in commit "bsp:cvitek: add i2c pinmux config
for cv18xx_riscv" to c906_little.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
---------
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
Signed-off-by: flyingcys <flyingcys@163.com>
Co-authored-by: flyingcys <flyingcys@163.com>