2023-06-EOSS-Oniro-Zephyr.pdf

《2023-06-EOSS-Oniro-Zephyr.pdf》由會員分享，可在線閱讀，更多相關《2023-06-EOSS-Oniro-Zephyr.pdf（23頁珍藏版）》請在三個皮匠報告上搜索。

1、#EMBEDDEDOSSUMMITHow Eclipse Oniro Uses Zephyr Lessons Learned Stefan Schmidt,Principal Solution Architect,Huawei OSTCEOSS 2023Agenda3Oniro OverviewOpenHarmony Overview5 Use cases and Lessons LearnedFuture Roadmap DiscussionScope4Where Zephyr is used in Eclipse Oniro and howThe perspective will be a

2、s a user and consumer of Zephyr Needs for integration,stability and maintenanceAlso new features and bug fixesOniro Overview5The Eclipse Oniro project is centered around the Oniro Working Group at the Eclipse Foundation https:/oniroproject.org“Oniro is an Eclipse Foundation project focused on the de

3、velopment of a distributed open source operating system platform that enables interoperability of consumer devices,regardless of brand,make,or model.The platform is designed to be compatible with a broad range of embedded operating system environments,including OpenHarmony,an open source operating s

4、ystem specified and hosted by the OpenAtom Foundation.”Oniro Overview6The promise to support devices big and small does mean it supports different kernels,Linux as well as RTOS systems.Linux build with YoctoZephyr:meta-zephyrLiteOS:meta-liteosmOniro 2.0 end of last year as horizontal platform2023 fo

5、cus on vertical solution:OpenHarmonyOpenHarmony Overview7Hosted and developed at the OpenAtom Foundation Open Source foundation of HarmonyOSApache 2.0 licensedMini,small and standardsystemsLinux and Lite OS274 certified productsfrom 108 manufacturersChinese marketExpanding marketsOpenHarmony Overvie

6、w8Three different sytem typesMini(Cortex-M,=128 KiB,RTOS)systemSmall(Cortex-A,=1 MiB,RTOS or Linux)systemStandard(Cortex-A,=128 MiB,Linux)system Linux and LiteOSDSoftBus,distributed scheduler and data managementKernel Abstraction Layer(KAL)Hardware Driver Foundation(HDF)9Use Cases&Lessons Learned Us

7、e Case 1:meta-zephyr10Use of meta-zephyr to build with bitbake through Yocto/OEEnsure unified developer workflow for buildingProblems:Layer was mixing machine support,distro policies and more in oneOnly a handfull of machines supported in comparison to what Zephyr actually supportsSolution:Split met

8、a-zepyhr into meta-zephyr-bsp and meta-zephyr-core layers$bitbake generate-zephyr-machines Automatically generate machines from west boards with some Cmake hacks Machines need to be manually verified,tested and added to CI afterwardsUse Case 1:meta-zephyr11Using Zephyr through meta-zephyr has impose

9、d limits in available machinesFor us the extra steps to unify our developer flow was worth the workSplitting the layers,generating machines,adding application and sample recipes68 patches upstreamed into meta-zephyr Use Case 2:Connectivity and Graphics 12Hardware support for Arduino Nano 33 BLE,Nitr

10、ogen 96 and othersSubsystems used besides core:OpenThread,CoAP and LVGLProblems:Version mismatches in OpenThread spinnel protocol(with Linux host)LVGL version to old to work as intended for us(LVGL used in Linux as well as Zephyr)Solution:Switching to a newer Zephyr version solved some OpenThread pr

11、oblemsLVGL version bump and further revamp in upstream LVGL moduleUse Case 2:Connectivity and Graphics 13LVGL subsystem update resulted in revamp upstreamSmaller fixes where needed(persistend storage in partion table)Matching protocol versions for OpenThread needed to be coordinated for updatesThe c

12、ore functionality and bringup worked smoothly for us20 patches upstreamed into ZephyrUse Case 3:Zephyr and Linux Code Sharing 14Shared code base between Linux and ZephyrEDDIE project runs on top of bothC+code base,using CoAP,JSON and OpenThreadClearly not a Zephyr problem,but a niche use caseProblem

13、s:Linux and Zephyr offer different APIs for CoAP(libcoap vs native)OpenThread configuration interfaceSolution:Duplicated code,abstrated where possibleUse Case 3:Zephyr and Linux Code Sharing15Is this a common request?Do others split projects between Linux and Zephyr from the start?Full abstraction l

14、ayer out of scope for Zephyr projectUse Case 4:Blueprints(doorlock&CATS)16Blueprints involving sensors,actors,wireless and graphicsKeypad,OpenThread,CoAP,LVGL and graphical assetsProblems:Demo hardware bringup timeSRAM(256 KB)and flash(1 MB)size limitations for featuresetSolution:Selecting the right

15、 hardware components was easy due to wide range of driver supportSwitched early prototype from Zephyr to LinuxUse Case 4:Blueprints(doorlock&CATS)17Doorlock still using ZephyrMotor driver,keypad,OpenThread,CoAP,application logicContext Aware TouchScreen switched from Zephyr to LinuxGraphical applica

16、tion with different pages and graphical assetsRunning out of flash spaceEven without OpenThread subsystemUse Case 5:IP Compliance18Our IP compliance process goes beyond SBOM generationManual audits on source for build artifactsSeveral issues spotted in our Zephyr target builds Problems:Binaries with

17、 unclear licence situation(NXP,espressif HALs)Proprietary font in LVGL moduleUnclear license(proprietary as well as open source)statement(mcuboot,nios2f)Solution:IP audit team prepared list of potential issuesFurther analysed in the project and raised as upstream Zephyr ticketsUse Case 5:IP Complian

18、ce19Resolved:https:/ module)Still open(or stale closed):https:/ Roadmap Current Focus and Roadmap212023 focus on enhancing OpenHarmony as verticial solutionApplication frameworks and ecosystem(e.g.ReactNative,Flutter)IDE ToolingSystem profiling and optimizationRust in security critical areas(e.g.web

19、 engine)OpenHarmony on Zephyr?22External Zephyr module to glue both systems togetherOpenHarmony already has RTOS support(LiteOS)Could extend platform supportPorting effort around KAL and HDFDepends on interest of partner,customers and the Oniro working group Interested in feedbackONIRO PROJECTThank you!Join us oniroproject.org31