zhushengle
f635450d7c
feat: 内核提供tick timer框架,支持多架构多平台通用化
...
背景:
当前Arch下tick timer的实现依赖于弱函数机制,三方适配时出错及限制较大,且tick
timer作为内核必须模块,未模块化,当前散落在tick和调度等模块中,且当前存在arch依赖
内核,内核也依赖arch的情况,为了解决上述问题,将tick timer模块化,通过提供tick
timer框架实现内核依赖Arch而Arch不依赖内核,并且可以减少对外暴漏的接口,使得三方
适配时更加明确需要实现的接口。
方案描述:
1.tick timer结构
在kernel_liteos_m/arch/include/los_timer.h,中定义结构:
typedef struct {
UINT32 freq;
INT32 irqNum;
UINT32 (*init)(HWI_PROC_FUNC tickHandler);
UINT64 (*getCycle)(UINT32 *period);
VOID (*reload)(UINT64 time);
VOID (*lock)(VOID);
VOID (*unlock)(VOID);
HWI_PROC_FUNC tickHandler;
} ArchTickTimer;
并声明对外获取tick timer的接口:
ArchTickTimer *ArchSysTickTimerGet(VOID)
define LOS_SysTickTimerGet ArchSysTickTimerGet
2.在每个架构下提供默认的tick timer操作:
STATIC ArchTickTimer g_archTickTimer = {
.freq = xxx, 必填
.irqNum = xxx, 必填
.init = xxx, 必填
.getCycle = xxx, 必填
.reload = xxx, 必填
.lock = xxx, 必填
.unlock = xxx, 必填
.tickHandler = NULL, 可选
}
并实现:ArchTickTimer *ArchSysTickTimerGet(VOID) 接口
3.内核los_tick.c中提供对外(其它模块)和公共的tick timer初始化操作函数,
如果用户不想启用系统默认的tick timer,则需要在 "内核初始化之前" 调用接口:
LOS_TickTimerRegister(const ArchTickTimer *timer, const HWI_PROC_FUNC tickHandler)
将用户自己的tick timer或中断处理函数 注册进去。
用户也可以注册自己的中断处理函数(用户不提供,默认使用系统提供的)。
BREAKING CHANGE:
原来版本中每个架构下提供的tick timer相关操作函数为弱函数:
WEAK UINT32 HalTickStart(OS_TICK_HANDLER handler);
WEAK VOID HalSysTickReload(UINT64 nextResponseTime);
WEAK UINT64 HalGetTickCycle(UINT32 *period);
WEAK VOID HalTickLock(VOID);
WEAK VOID HalTickUnlock(VOID);
用户如果需要启用自己的tick timer需要自己实现相关接口(强属性),在 "内核初始化之前" 通过调用:
LOS_TickTimerRegister 接口替换系统默认提供的tick timer相关接口。
无论用户提供的tick timer 还是系统默认提供的,均在内核初始化时启动。
Close #I4N7XV:arch 重构
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I83ad0bdf303904f0e73f808b57b60183619fddcd
2021-12-31 10:50:33 +08:00
LiteOS2021
04bf3a682f
feat: synchronizing arch api
...
命名规范:修改少量Arch接口,命名规范化调整:
1.修改arch/include下接口声明,所有arch对外提供调用函数均以ArchXX命名
2.提取多个架构均有实现的公共函数声明至arch/include对应头文件中以供外部调用,并修改命名格式为ArchXX
3.修改OS_HWI_WITH_ARG为LOSCFG_PLATFORM_HWI_WITH_ARG并移至los_config.h中
4.typedef VOID (*OS_TICK_HANDLER)(VOID);暂时移至arch/include/los_timer.h中
5.实现atomic原子操作相关接口,位于arch/include/los_atomic.h,arm架构部分与汇编指令相关原子操作接口使用ARCH_ARM宏进行控制是否编译
BREAKING CHANGE: 1.修改arch/include下接口,以ArchXX命名函数
2.提取公共函数声明:ArchAtomicXchg32bits、ArchAtomicDecRet、ArchAtomicCmpXchg32bits
3.新增部分原子操作c内联实现
Close #I4N7XV
Signed-off-by: LiteOS2021 <dinglu@huawei.com>
2021-12-25 18:36:09 +08:00
ou-yangkan
c082d77f55
fix:Fix spelling errors
...
Signed-off-by: ou-yangkan <519689417@qq.com>
2021-12-20 09:35:58 +08:00
openharmony_ci
d03b490d3d
!462 OsMuxInit函数中增加对owner成员的初始化
...
Merge pull request !462 from fangye945a/master
2021-12-15 02:34:24 +00:00
openharmony_ci
939414ea9a
!456 fix: tick中断处理时,无挂起任务时应更新当前运行任务的时间片, 并触发一次调度
...
Merge pull request !456 from zhushengle/tick
2021-12-15 01:57:10 +00:00
fangye
d1f7b8e465
OsMuxInit函数中增加对owner成员的初始化
...
Signed-off-by: fangye <fangye@talkweb.com.cn>
2021-12-14 22:45:29 +08:00
suzongyao
eff6b5533c
fix: 解决kernel目录下一些函数入参过剩导致编译错误的问题
...
Signed-off-by: suzongyao <suzongyao@talkweb.com.cn>
2021-12-13 17:15:26 -08:00
kenneth
ab886d848a
feat: 低内存资源回收low memory killer
...
低内存资源回收特性,支持维护可杀低重要任务,当高内存任务申请不到足够内存时,临时释放低重要性的任务来释放内存来满足高内存任务正常运行;
当高内存任务退出运行时,自动恢复被杀的低重要性任务。设计文档归档位置 https://gitee.com/rtos_yuan/lmk/tree/design/
BREAKING CHANGE: 增加低内存资源回收注册相关接口LOS_LmkOpsNodeRegister、LOS_LmkOpsNodeUnregister和内存资源释放和任务恢复接口LOS_LmkTasksKill和LOS_LmkTasksRestore.
close #I4ID0M
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-12-13 12:07:33 +08:00
zhushengle
ea12d40caf
fix: tick中断处理时,无挂起任务时应更新当前运行任务的时间片, 并触发一次调度
...
Close #I4LRZG
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I4472fb50c775b832688aa7a555498901a80e2999
2021-12-13 11:37:50 +08:00
openharmony_ci
4a95944fc5
!446 支持删除已经超时但还在队列中未执行的软件定时器
...
Merge pull request !446 from JerryH/swtmr
2021-12-09 03:10:36 +00:00
JerryH
ecce17ea48
fix: 解决定时器超时但还在队列中无法删除的问题
...
利用每次创建时,软件定时器timerId都是唯一的(0~0xffffffff循环),在超时写队列时,同时记录软件定时器id,删除的时候更新软件定时器id,那么在处理软件定时器前,
通过队列中记录的id获取软件定时器控制块,如果控制块的id不等于记录的id,那么说明该软件定时器被删除过,将不执行对应回调函数,表现为删除该定时器。
BREAKING CHANGE: SwtmrHandlerItem结构体新增swtmrID字段,用于标识超时队列中软件定时器id
Close #I4LFVD
Signed-off-by: JerryH <huangjieliang@huawei.com>
Change-Id: I716176f177c4bc07adb348936d5568fbadcbebe7
2021-12-08 15:27:49 +08:00
zhushengle
d7c0059dc4
fix: 调度中将pm相关的部分用LOSCFG_KERNEL_PM包含
...
Close #I4L00F
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I0dbe0954dcb881c0079677c215aceb099d6d1b94
2021-12-06 19:12:55 +08:00
zhangfanfan2
f51d675fee
fix: LOS_Panic接口中增加需要增加LOS_BackTrace(),方便定位主动异常位置
...
close: #I4IGGY
Signed-off-by: zff <zhangfanfan2@huawei.com>
2021-11-30 07:24:29 +00:00
openharmony_ci
d0d51b4a29
!393 feat: 支持Lms轻量级地址消毒
...
Merge pull request !393 from LiteOS/lms
2021-11-29 14:22:21 +00:00
zhushengle
91903a3716
fix: 修正部分编码风格问题
...
Close #I4K8M7
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: If34d5c632cbb06f639434d8c35fb226a0253f4a7
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-11-29 14:22:39 +08:00
LiteOS2021
7b838e8a7b
feat: 支持Lms
...
1.【需求描述】:
支持内核态堆内存非法访问检测,包括:越界访问、double free、释放后使用;支持libc常用高频函数内存检测;支持安全函数内存检测;读写检测可配可裁剪。
2.【方案描述】:
(1).影子内存映射与标记
(2).编译器使能-fsanitize=kernel-address 自动插桩检测点
(3).实时校验影子内存的合法性;
(4).错误访问打印回溯栈
BREAKING CHANGE: 新增支持API:
LOS_LmsCheckPoolAdd使能检测指定内存池
LOS_LmsCheckPoolDel不检测指定内存池
LOS_LmsAddrProtect为指定内存段上锁,不允许访问
LOS_LmsAddrDisableProtect去能指定内存段的访问保护
Close #I4HYBG
Signed-off-by: LiteOS2021 <dinglu@huawei.com>
Change-Id: Ia356a003088b9df37df667ea8ba91c80f5a41967
2021-11-27 11:31:12 +08:00
zhushengle
cc8a794229
feat: 调度、任务及pm解耦
...
pm中冻结线程的操作,融合至OsSchedSuspend和OsSchedResume,
使得调度模块提供对应完整的方法给任务模块,做到之间的相互解耦,
方便其它调度算法的融入。
Close #I4JTN6
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ifde7077166a2fe67e7246fa68f777844640d67db
2021-11-25 16:54:02 +08:00
Caoruihong
7e673430dc
feat(build): support Kconfig
...
Kconfig usages are the same with liteos_a
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I9aacbb69da88d5427cced89d1a49cb1041afa998
2021-11-05 12:18:04 +08:00
zff
c886629e27
fix:系统pend类接口未对软件定时器任务进行限制,容易引发软件定时器任务非正常挂起,
...
出现响应不及时的问题
close: #I44CI9
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I6aa612f3c34eef274eaa0c98efed0a3c4736de6e
2021-10-18 16:35:51 +08:00
openharmony_ci
c68b67a4e3
!351 fix: 调用LOS_TaskDetach操作已退出的joinable的任务时,未正确回收该任务
...
Merge pull request !351 from zhushengle/detach
2021-10-15 07:40:54 +00:00
zhushengle
49c93b37c5
fix: 调用LOS_TaskDetach操作已退出的joinable的任务时,未正确回收该任务
...
Close #I4DZL7
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Iac88818317c07807d0636712025f2c75b3b1f766
2021-10-15 10:56:02 +08:00
LiteOS2021
afbc9a593b
fix: 优化trace buffer初始化,删除swtmr 桩中的无效参数
...
close #I4DPR7
Signed-off-by: LiteOS2021 <dinglu@huawei.com>
2021-10-14 09:48:49 +08:00
kenneth
f7d26b8e12
fix: gcc编译testsuite编译问题修复
...
修复It_los_mem.h中没有定义LOS_DLNK_NODE_HEAD_SIZE、MIN_DLNK_POOL_SIZE,编译告警等问题。
close #I4DAOU
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-10-11 14:30:51 +08:00
openharmony_ci
892d6981e7
!336 fix: 删除OsMemboxExcInfoGetSub内存调测方法中多余的赋值语句
...
Merge pull request !336 from kenneth/membox
2021-10-08 02:39:05 +00:00
openharmony_ci
3eb4679f13
!324 【fix】hook层LOS_HOOK_TYPE_SEM_PEND的runningTask入参可能为空
...
Merge pull request !324 from Zhaotianyu/0926hook_fix
2021-10-08 01:06:22 +00:00
kenneth
94db0fe7a3
fix: 删除OsMemboxExcInfoGetSub内存调测方法中多余的赋值语句。
...
OsMemboxExcInfoGetSub内存调测方法中存在对memExcInfo->size多次赋值,size含义不清晰,删除多余的赋值语句。
close #I4CFNX
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-09-29 14:51:14 +08:00
openharmony_ci
91bd0c2e2b
!331 fix: OS_TASK_STACK_PROTECT_SIZE undeclared error
...
Merge pull request !331 from kenneth/mpu
2021-09-29 02:50:25 +00:00
zhushengle
0fb49d4422
fix: 修复risc-v异常时,异常信息混乱且backtrace无法输出的问题
...
1.修复risc-v backtrace无法输出的问题
异常时未将fp传入,且backtrace校验不足,容易导致再次异常
2.优化task 输出信息格式
3.shell中task命令代码重复
4.OSBackTraceInit 拼写有误
Close #I4BPHX:riscv32_virt 异常时无法输出backtrace信息
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I141d5e7808fc967d846f425422f5dcf2ac01d1d1
2021-09-28 11:39:42 +08:00
kenneth
56e234b300
fix: fix OS_TASK_STACK_PROTECT_SIZE undeclared error
...
当开启LOSCFG_EXC_HARDWARE_STACK_PROTECTION宏时,增加定义OS_TASK_STACK_PROTECT_SIZE宏
close #I4C5RW
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-09-28 10:27:52 +08:00
arvinzzz
3fd22ac2b0
fix: 修复hook层LOS_HOOK_TYPE_SEM_PEND的runningTask入参可能为空
...
在校验完semPend之后,就获取好runningTask并且与semPend关联
close: #I4BU4P
Signed-off-by: arvinzzz <zhaotianyu9@huawei.com>
Change-Id: Ib56a1a1db8e4471d9e2adb0b7c3d8b17b1f87b8d
2021-09-27 09:48:02 +08:00
openharmony_ci
4061deaae8
!311 feat: 支持posix 和 cmsis join能力
...
Merge pull request !311 from zhushengle/join
2021-09-24 00:30:44 +00:00
zhushengle
ecfdf7ff9b
feat: 支持posix 和 cmsis join能力
...
支持API:
LOS_TaskJoin
LOS_TaskDeatch
pthread_join
pthread_deatch
osThreadJoin
osThreadDetach
Close #I44V26
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ib61e69c280eef2e4b3b79d9bba7bbd5a300c7fe4
2021-09-23 18:54:14 +08:00
openharmony_ci
25441ec1b5
!314 fix: risc-v 低功耗下存在功能问题
...
Merge pull request !314 from zhushengle/list
2021-09-18 06:14:40 +00:00
zhushengle
9f185b5b52
fix: pm模块解冻线程时存在删除空链表且时间片频繁唤醒系统
...
1.如果冻结线程状态为delay,则此时pendlist为NULL,解冻时不需要delete
2.低功耗时关闭时间片,减少时间片频繁唤醒系统
3.risc-v 中64位相加存在溢出
Close #I4AKUS
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Icb9e8f7df8488635f9660d3932b06fa6f57e6133
2021-09-18 11:42:08 +08:00
openharmony_ci
03bbc750ce
!305 fix: 修复OsQueueMailFree提早释放内存的问题
...
Merge pull request !305 from hpline/master
2021-09-17 09:33:45 +00:00
wangchen
6ffd55dcd0
fix: shell模块task命令踩内存问题修改
...
【背景】task命令获取内存时传入的参数过大,可能引起踩内存问题。
【修改方案】
1,对task命令中获取内存信息时的入参进行调整,避免引起内存问题
【影响】
对现有的产品编译不会有影响。
re #I4A70V
Signed-off-by: wangchen <253227059@qq.com>
2021-09-16 15:56:38 +08:00
lurix
902efbcea9
chore: update the comment.
...
Signed-off-by: lurix <lurix@foxmail.com>
2021-09-15 12:57:40 +00:00
zhushengle
9b5739ab11
feat: 低功耗支持冻结线程等需求
...
1.支持低功耗时冻结线程
2.支持延时锁
3.低功耗与idle分离
4.支持对接电源管组件的低功耗接口
LOS_PmReadLock --- 常阻塞,低功耗线程阻塞于该接口,当系统无任何模块持锁时会唤醒低功耗线程, 触发低功耗流程
LOS_PmSuspend --- 进入低功耗流程
Close #I49FJF
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I009255cfa1852b109dd8bfaf9c779e976660d621
2021-09-14 19:55:26 +08:00
lurix
9c3a6901f1
chore: 解决代码风格导致的编译报错
...
Signed-off-by: lurix <lurix@foxmail.com>
2021-09-14 02:04:02 +00:00
lurix
ec88d16289
fix: 修复OsQueueMailFree提早释放内存的问题
...
Signed-off-by: lurix <lurix@foxmail.com>
2021-09-13 10:04:25 +00:00
zhushengle
c6600d9ddd
fix: 优化低功耗流程
...
1.normal和其它模式分离,流程分层化,使得结构较为清晰
2.tick timer处理实现优化为注册对应机制则默认支持,不注册则不执行,简化使用逻辑
3.添加 pm测试用例
Close #I46VXK
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I7810ce0ca12dce96972399adf88e8319bb487905
2021-09-09 11:46:23 +08:00
zhushengle
3798091d87
fix: 内核模块编译增加-Werror编译选项,且清除内核编译告警
...
Close #I46E6S
Change-Id: If1362c02a0a344da881a9bf90e41f0a43ba33609
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-09-06 16:16:43 +08:00
openharmony_ci
459cabf7de
!286 按任务统计已经alloc的内存大小
...
Merge pull request !286 from lnlan/taskinfo
2021-09-01 01:48:21 +00:00
lnlan
475db62db1
feat: los_memory.c代码重复率处理
...
【背景】
los_memory.c中有4处遍历内存节点的操作,重复率较高
【修改方案】
1.提取一个遍历内存节点的函数,入参可传入处理函数来应对不同处理场景
【影响】
对现有的产品编译不会有影响。
re #I44WNU
Signed-off-by: lanleinan <lanleinan@163.com>
Change-Id: Iafd25be39e76ee29e4fb27e5ef65f1888cc23f02
2021-08-31 02:30:30 +00:00
xiaofan
61cbf83f5d
fix:修复software timer线程
...
readsize在第一次循环后可能未被正确赋值的问题
Signed-off-by: xiaofan <xiaofan@iscas.ac.cn>
2021-08-28 16:23:37 +08:00
lnlan
53117f9f47
feat: 按任务统计已经alloc的内存大小
...
【背景】
m核需补充shell命令,按任务统计已经alloc的内存大小
【修改方案】
1.新增在task命令中,在打印task
info前遍历所有内存节点,统计各任务所占用的内存节
点大小,在打印时将其打出。
2.内存节点中,taskid所占位数随系统最大任务数调整
【影响】
对现有的产品编译不会有影响。
re #I44WNU
Signed-off-by: lanleinan <lanleinan@163.com>
Change-Id: I080b5dd056966784c0752408f9e320ca0e97c7f7
2021-08-28 06:14:34 +00:00
wangchen
5a9d53b644
fix: M核告警消除
...
【背景】定期M核代码消除。
【修改方案】
1,根据工具扫描结果,对代码告警进行更改
【影响】
对现有的产品编译不会有影响。
re #I46LHG
Signed-off-by: wangchen <253227059@qq.com>
2021-08-20 18:44:33 +08:00
openharmony_ci
4e11ded476
!267 fix: 删除延时节点后,存在时间无法有效刷新的场景
...
Merge pull request !267 from zhushengle/sched
2021-08-19 00:39:21 +00:00
openharmony_ci
97c4a5813f
!249 堆内存算法支持多段非连续性内存区域
...
Merge pull request !249 from kenneth/multiple_mem
2021-08-17 07:43:18 +00:00
kenneth
0facb0c017
feat: support non-continuous memory regions
...
The multiple non-continuous memory regions are supported when the macro
LOSCFG_MEM_MUL_REGIONS is enabled. The array of the type LOS_MEM_REGION should be defined,
and each array element defines the start address and the length for each memory regions, \
begining from the lower address to the higher memory address.
close #I43XOP
Signed-off-by: kenneth <zhushangyuan@huawei.com>
2021-08-17 09:07:04 +08:00