- 20 1月, 2022 1 次提交
-
-
由 JerryH 提交于
内核支持信号功能,支持注册、屏蔽、等待及触发等操作。 close #I4R72Q Signed-off-by: NJerryH <huangjieliang@huawei.com> Change-Id: I26fb11a03d1899c6f7e665f0798824c578d592a6
-
- 18 1月, 2022 1 次提交
-
-
由 JerryH 提交于
支持pipe管道驱动,支持poll多文件描述符检测接口。 Signed-off-by: NJerryH <huangjieliang@huawei.com> Change-Id: Ida1f29709affbc91a26b8518e4a77b8e5469be19
-
- 31 12月, 2021 1 次提交
-
-
由 zhushengle 提交于
背景: 当前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: Nzhushengle <zhushengle@huawei.com> Change-Id: I83ad0bdf303904f0e73f808b57b60183619fddcd
-
- 25 12月, 2021 1 次提交
-
-
由 LiteOS2021 提交于
命名规范:修改少量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: NLiteOS2021 <dinglu@huawei.com>
-
- 13 12月, 2021 1 次提交
-
-
由 kenneth 提交于
低内存资源回收特性,支持维护可杀低重要任务,当高内存任务申请不到足够内存时,临时释放低重要性的任务来释放内存来满足高内存任务正常运行; 当高内存任务退出运行时,自动恢复被杀的低重要性任务。设计文档归档位置 https://gitee.com/rtos_yuan/lmk/tree/design/ BREAKING CHANGE: 增加低内存资源回收注册相关接口LOS_LmkOpsNodeRegister、LOS_LmkOpsNodeUnregister和内存资源释放和任务恢复接口LOS_LmkTasksKill和LOS_LmkTasksRestore. close #I4ID0M Signed-off-by: Nkenneth <zhushangyuan@huawei.com>
-
- 30 11月, 2021 1 次提交
-
-
由 zhangfanfan2 提交于
close: #I4IGGY Signed-off-by: Nzff <zhangfanfan2@huawei.com>
-
- 27 11月, 2021 1 次提交
-
-
由 LiteOS2021 提交于
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: NLiteOS2021 <dinglu@huawei.com> Change-Id: Ia356a003088b9df37df667ea8ba91c80f5a41967
-
- 05 11月, 2021 1 次提交
-
-
由 Caoruihong 提交于
Kconfig usages are the same with liteos_a Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I9aacbb69da88d5427cced89d1a49cb1041afa998
-
- 14 10月, 2021 1 次提交
-
-
由 LiteOS2021 提交于
close #I4DPR7 Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
-
- 11 10月, 2021 1 次提交
-
-
由 kenneth 提交于
修复It_los_mem.h中没有定义LOS_DLNK_NODE_HEAD_SIZE、MIN_DLNK_POOL_SIZE,编译告警等问题。 close #I4DAOU Signed-off-by: Nkenneth <zhushangyuan@huawei.com>
-
- 28 9月, 2021 1 次提交
-
-
由 zhushengle 提交于
1.修复risc-v backtrace无法输出的问题 异常时未将fp传入,且backtrace校验不足,容易导致再次异常 2.优化task 输出信息格式 3.shell中task命令代码重复 4.OSBackTraceInit 拼写有误 Close #I4BPHX:riscv32_virt 异常时无法输出backtrace信息 Signed-off-by: Nzhushengle <zhushengle@huawei.com> Change-Id: I141d5e7808fc967d846f425422f5dcf2ac01d1d1
-
- 10 8月, 2021 1 次提交
-
-
由 Haryslee 提交于
1.【需求描述】 动态库开发部分: gcc的sample code。 提供生成暴露接口生成机制,并允许产品新增需要暴露的接口。 提供可以判断库允许资源大小的能力,并提供相关工具辅助开发者确定开发的库要求的资源是否可以满足。 动态库运行部分: 提供elf load的api,可以加载指定路径下的库,并完成符号重映射等运行准备。 提供elf 暴露符号调用的api,用于调用库的api。 elf加载&链接异常时,有明确错误记录,返回明确错误类型。 提供elf 卸载的api。 2.【方案描述】 (1) 通过灌段的形式记录需要导出符号的地址信息,用于暴露内核对外的接口,在加载链接器中通过查询 对应的符号信息获取符号地址。 (2) 加载链接时,解析共享库并将共享库中可加载段通过文件系统读入内存中,并对共享库中未定义的、 需要重定位的符号进行重定位。需要调用符号时,根据符号名通过哈希表即可查询共享库提供的对应符号 的地址。 BREAKING CHANGE: 新增4个对外接口,声明在los_dynlink.h文件中,分别为: (1) LOS_DynlinkInit: 动态加载模块初始化。 (2) LOS_SoLoad: 加载指定路径的共享库。 (3) LOS_FindSym: 根据共享库句柄查找指定符号。 (4) LOS_SoUnload: 卸载共享库。 close #I418HJ Signed-off-by: NHaryslee <lihao189@huawei.com> Change-Id: I7669b7ef20096294f9d1094c85ac6602fefad354
-
- 30 7月, 2021 1 次提交
-
-
由 LiteOS2021 提交于
1.【需求描述】 L0 支持Trace,提供两种工作模式:在线模式、离线缓存模式, 用于按时间线追踪系统事件,如任务切换、中断、ipc等。 2.【方案描述】 (1).在内核模块预置静态代码桩 (2).触发桩后,收集系统上下文信息 (3).离线模式则写入内存,用户可通过dump导出; (4).在线模式通过pipeline对接IDE进行可视化解析和展示; BREAKING CHANGE: 1.新增一系列trace的对外API,位于los_trace.h中. LOS_TRACE_EASY简易插桩 LOS_TRACE标准插桩 LOS_TraceInit配置Trace缓冲区的地址和大小 LOS_TraceStart开启事件记录 LOS_TraceStop停止事件记录 LOS_TraceRecordDump输出Trace缓冲区数据 LOS_TraceRecordGet获取Trace缓冲区的首地址 LOS_TraceReset清除Trace缓冲区中的事件 LOS_TraceEventMaskSet设置事件掩码,仅记录某些模块的事件 LOS_TraceHwiFilterHookReg注册过滤特定中断号事件的钩子函数 Close #I41Y9Y Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
-
- 21 7月, 2021 1 次提交
-
-
由 zhushengle 提交于
解决系统未初始化完成前无timer可用的问题。 Close #I410F0 Signed-off-by: Nzhushengle <zhushengle@huawei.com> Change-Id: I3799b9b0ff03cb1dfe80a97816a484df28ae49fd
-
- 13 7月, 2021 1 次提交
-
-
由 arvinzzz 提交于
1. 删除残留无用的trace代码 2. 调整los_error.h中失效的错误类型定义 3. 整理los_config.h中的特性控制宏 close: #I3ZMB4 Signed-off-by: Narvinzzz <zhaotianyu9@huawei.com> Change-Id: I9f03c486b54ae66308f0dac1aa003dd2a5ef5b84
-
- 22 6月, 2021 1 次提交
-
-
由 zhushengle 提交于
1.【需求描述】 L0 支持低功耗投票框架, 使内核与应用、驱动分离开,通过注册及投票机制控制系统的低功耗模式, 减低系统功耗,提升设备电池寿命。 2.【方案描述】 (1).提供注册机制,使驱动与内核分离 (2).提供投票机制,判断系统运行模式 (3).记录持锁设备,便于回溯 进入:系统运行进入idle任务时判断当前的功耗模式,如果上层应用未对当前功耗模式(deep和shutdown) 持锁,则系统准备进入当前模式,首先所有设备依次进入当前模式,如果有设备进入当前模式失败,则恢复 已进入当前模式的所有设备,并且功耗模式变为normal模式;设备依次进入当前功耗模式后cpu再进入当前 功耗模式。 恢复:功耗模式为deep时,需要恢复逻辑,时系统恢复运行。当有中断出发时,系统会退出低功耗模式, 恢复顺序为:首先cpu先恢复,然后设备依次恢复。 BREAKING CHANGE: 1.原调度中基于tick timer的低功耗扩展和当前的pm模块合并,删除原对外接口LOS_SchedSleepInit, 变为pm模块统一提供的LOS_PmRegistered接口. 2.原来在arch los_timer.h下提供的低功耗模式为枚举LOS_SysSleepEnum,其中OS_SYS_NORMAL_SLEEP 和OS_SYS_DEEP_SLEEP不符合对外定义,统一修改为LOS_SYS_NORMAL_SLEEP和LOS_SYS_DEEP_SLEEP, 并移至los_pm.h中. 3.VOID HalEnterSleep(LOS_SysSleepEnum sleep) 变更为UINT32 HalEnterSleep(VOID). Close #I3UDNV Signed-off-by: Nzhushengle <zhushengle@huawei.com> Change-Id: Id5382c42c8055ba7850895a3f575130a73e38a65
-
- 16 6月, 2021 1 次提交
-
-
由 zhushy_ 提交于
change function name LOS_BackTraceInit and involve it in los_init.c when macro is not set to 0 close https://gitee.com/openharmony/kernel_liteos_m/issues/I3SYQQSigned-off-by: kenneth <459864689@qq.com>
-
- 19 4月, 2021 1 次提交
-
-
由 Caoruihong 提交于
Change-Id: Ie25b83a42d3ca35c3a6d624ef01f425a85957d7f
-
- 13 4月, 2021 1 次提交
-
-
由 星e雨 提交于
Description:liteos_m scheduling optimization and low power design. Sig:kernel Feature or Bugfix:Feature Binary Source:No Change-Id: If913b673c9b69039b51ca416be0a77ebccf2773b
-
- 01 4月, 2021 1 次提交
-
-
由 arvinzzz 提交于
Change-Id: I45c37c3c92e74e676818e713fa46b3a9fe970e68
-
- 11 3月, 2021 1 次提交
-
-
由 mamingshuai 提交于
-
- 30 1月, 2021 1 次提交
-
-
由 huangjieliang 提交于
Reviewed-by: likailong
-
- 20 1月, 2021 1 次提交
-
-
由 星e雨 提交于
-
- 16 12月, 2020 1 次提交
-
-
由 Caoruihong 提交于
Reviewed-by: likailong
-
- 02 12月, 2020 1 次提交
-
-
由 likailong 提交于
Reviewed-by: wangmihu, zhushengle
-
- 13 11月, 2020 1 次提交
-
-
由 l00278955 提交于
Reviewed-by: liulei, shenwei Change-Id: I7baba352c02b78aefc81fc5eca000d840d3b2fe3
-
- 08 9月, 2020 1 次提交
-
-
由 wenjun 提交于
-