Skip to content

K
Kernel Liteos M

OpenHarmony / Kernel Liteos M
大约 1 年 前同步成功

通知 20
Star 28
Fork 1
K
Kernel Liteos M

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 17 1月, 2022 4 次提交
  3. 13 1月, 2022 3 次提交
  5. 12 1月, 2022 4 次提交
  7. 11 1月, 2022 4 次提交
  9. 10 1月, 2022 2 次提交
  11. 08 1月, 2022 2 次提交
    • O
      !528 修复内核gn模板编译依赖的问题 · 4a120d75
      由 openharmony_ci 提交于 
      Merge pull request !528 from SimonLi/master
      4a120d75
    • S
      build: 修复内核gn编译依赖的问题 · 11215e11
      由 SimonLi 提交于 
      背景：
1. //kernel/liteos_m/BUILD.gn通过excutable生成config.gni文件到
out目录下
2. //kernel/liteos_m/liteos.gni定义内核模板，依赖out目录下的config.gni
意味着使用内核模板的模块（例如device/board、device/soc）需要依赖
kernel/liteos_m/BUILD.gn先加载，有这个顺序依赖约束。

解决方案：
将生成config.gni部分移到liteos.gni模块定义处，解决这个约束。
Signed-off-by: NSimonLi <likailong@huawei.com>
      11215e11
  13. 07 1月, 2022 2 次提交
  15. 06 1月, 2022 4 次提交
  17. 05 1月, 2022 2 次提交
  19. 04 1月, 2022 3 次提交
  21. 31 12月, 2021 5 次提交
    • O
      !521 fix: 修复newlib缺省PTHREAD_KEYS_MAX 问题 · 9ebad7d2
      由 openharmony_ci 提交于 
      Merge pull request !521 from zhushengle/key
      9ebad7d2
    • Z
      fix: 修复newlib缺省PTHREAD_KEYS_MAX 问题 · 65f04bf0
      由 zhushengle 提交于 
      Close #I4OX47
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I4c6b07a77dca5eb5b24f462e639ff173f06d5da0
      65f04bf0
    • O
      !520 pm codex告警清零 · 1af38709
      由 openharmony_ci 提交于 
      Merge pull request !520 from zhushengle/codex
      1af38709
    • Z
      fix: pm codex告警清零 · 96663805
      由 zhushengle 提交于 
      Close #I4OWPE
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I07f6db919062090b917ce991198f769032365472
      96663805
    • Z
      feat: 内核提供tick timer框架，支持多架构多平台通用化 · f635450d
      由 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
      f635450d
  23. 30 12月, 2021 2 次提交
  25. 29 12月, 2021 1 次提交
  27. 28 12月, 2021 2 次提交