 Thank you, Kate. Thank you, Tim. And thanks to the Linux Foundation for putting on such a great event. Yeah, so as Kate mentioned, Google made the decision to switch our embedded controller implementation from the homegrown RTOS over to Zephyr about two and a half years ago. And today I want to talk a little bit like how what Google's journey has been with Zephyr and how we found like collaboration has worked within the Zephyr community. So what am I hoping you're going to take away from today's talk? I hope you might be inspired to start contributing to Zephyr, or maybe you're going to start collaborating in a new area to you. And then also, you know, myself and my team at Google, we're just trying to make some new friends. You know, so Google is a large company, but even at Google scale, we can't invent and implement everything ourselves. So by switching over to Zephyr, we were able to leverage a lot of the great features and capabilities that are in Zephyr today. Device stream in particular, this reduced a lot of the custom C code that we had to create for every Chromebook model. And we also adopted Zephyr's test framework. And for our embedded controller application, we increased our unit test coverage of our application from only 30% lines of code to over 90% lines of code. And, you know, the community has been great. They've been very eager and willing to collaborate on new features. So let me walk you through kind of the story of one of our very first contributions with Zephyr. So very early on, we added a new fuel gauge driver into the Zephyr source tree. And we incorporated this into the existing sensor framework, much like all the other fuel gauge drivers. However, about a year later, I got a direct message on Discord that asked, you know, why didn't Google promote a battery API that we already use on Chromebook today and that you could see in our open source RTOS? And the short answer was, you know, this first driver we added was really kind of testing the waters with Zephyr. We wanted to see how easy or hard this effort community is to actually work with. We obviously like what we found. We'd like the community. And that was a big part of our decision to switch over to Zephyr. And if you're wondering, you know, who was it that asked if we could add this new API? You were all introduced to Enos yesterday. He was kind of number one contributor into Zephyr. I think it's close to 5,000 commits into Zephyr. So I shared Enos's request internally and we started scoping out the work for how we might upstream our battery API into Zephyr. We started with a fairly small PR focused just on battery fuel gauge, got some good feedback about how to structure our APIs, make it look more like other Zephyr APIs. And we also got some other requests, like maybe we should also add a charging chip API or we should also have a thread that helps manage all the stuff together. So we realized it would be good to kind of step back and sketch out and show what might a full implementation look like that's going to have a battery in a system. So we created a request for Comet RFC up on GitHub and it includes this block diagram here that includes kind of all this future work that we could be doing. So a power supply system plus these two new APIs for a battery fuel gauge and a charger chip. But just as important as sketching out what the end goal is, we also defined what the minimum viable product or capacity for this API could be for this effort. This allowed us and the reviewers to kind of focus just on the fuel gauge API that you see down here in the lower left. And any features or requests that were kind of out of scope of that, we could defer and just avoid the feature creep. So how does the scaling actually work within Zephyr? So Google created this RFC and this PR and we iterated on these until they got merged. So then at that point we could then start extending our own implementation up in Zephyr. But because this MVP is now in tree, the gate is open for other collaborators to start contributing. So in parallel, Intel made their own changes to the battery fuel gauge API. Then we had an individual contributor from the Zephyr community not affiliated with any company that added yet another battery fuel gauge driver. In this case, they're fitting it into this brand new framework that we're creating. Cirrus Logic made their own contribution. They created an RFC and a PR for the charging chip API. Microsoft joined the party with their own changes to the battery fuel gauge API. And then here just last week, I think, made their own contribution with another battery fuel gauge driver. And I should note the companies of Cirrus Logic and Microsoft, and I think this represented their very first contribution into the Zephyr project. So this instance really demonstrates kind of the power in the scaling that you get out of Zephyr. And having more contributors, more companies contribute results in a more feature rich and more flexible implementation. And for this particular case, it was great to see the diversity that we had. We had multiple large companies, a medium company, a small company, plus an individual contributor, all making contributions. Another thing I want to touch upon, another area of collaboration that Google is working on, is around sensors. So sensors have been kind of part of the DNA for Zephyr for a long, long time. And there's over 140 drivers in the tree right now. But there's been some limitations. There's been some asks to make improvements here. And so this is just a few issues that I was able to find up on in the Zephyr project now that are open. And if you even look at the last issue listed here, this was opened all the way back in 2017 asking, you know, can we make the sensors more performant? And this was even opened by ANOS as well. So about a year ago, Google and Intel started a collaboration work to improve sensors. So, you know, here's a simplified view of sensors today. An application talks directly to the sensor driver API. And it just fetches sensor readings one by one. So recently, Yuval at Google made a couple key additions to this driver API. So the first was an asynchronous read mode, which simplifies how applications can talk to these sensors. And then he also added a streaming API that allows you to fetch samples from high bandwidth sensors. And this also added time stamping into sensor readings. And then both of these built upon the great real-time I.O. services that was authored by Tom at Intel. And then in parallel, Intel has been working on adding a new sensing subsystem. And this includes some great features of adding time stamps to all readings. You can create virtual sensors that build upon multiple physical sensors. And then there's arbitration and control over sampling rates. And the very first PR for the sensing subsystem merged just last week. And this all builds on the great all the great sensor drivers that are in tree now. And, you know, make sure you check out the virtual talk from Hebrew and Ken. That goes into a lot more detail. And I think that actually had a pretty successful virtual office hours yesterday on this topic as well. So some other things, Google's working to upstream. We're working on upstreaming some ACPI power sequencing. This is going to manage all the power states of an application processor. And it's going to support x86 and ARM. And this is another collaboration effort that we're working on with Intel. And for those in Zephyr, you're probably familiar with Fabio. He was one of the release managers for Zephyr 3.2. He's been hard at work at adding an input subsystem into Zephyr. And hopefully you were able to check out his talk yesterday. And then on USB power delivery, Google has added and landed both the sync only and source only modes of power delivery. And some Googlers, Diana and Sam, put together a great virtual talk that walk you through the entire process of adding USB power delivery to your Zephyr application. All right, so, you know, as I mentioned at the top, we've been doing this for about two and a half years working on Zephyr. And actually launching a Chromebook does take some time. But our partners, starting the beginning this year, actually are now shipping Chromebooks that are using Zephyr on the embedded controller. And this is just a sample of four devices that are on sale now that do include Zephyr as part of the implementation. And so where else is Google trying to use Zephyr? The first thing is Pigweed. Pigweed is a collection of open source libraries developed by a team at Google. And it really targets doing better and faster firmware development. And we're in the process of trying to get Pigweed adopted as an official Zephyr module so that Zephyr application developers can use Zephyr as a way to use it as a way to use it. And we know that Zephyr application developers can pick and choose the components that are going to work in their system. We have a couple virtual talks from Al and Yuval that talk about some of the integration you can do between Pigweed and Zephyr. And then a lot of Chromebooks also have a fingerprint sensor. We have recently started work to port our fingerprint firmware over to Zephyr as well. And this really helps future-proof our fingerprint design, making it a lot easier to switch to new space of supply chain problems. And we also have a couple hardware debug tools that are based off Zephyr. USB Type-C ports, reliable operation of those, is very critical to the user experience in Chromebooks. So we developed our own power delivery, USB power delivery analyzer, internally we call Twinkie. The latest version of this, Twinkie v2, is based off Zephyr and we're in the process of adding the board support files for Twinkie into the Zephyr tree. And then finally we have the chameleon board. This is an emulator for testing external displays with Chromebooks. And we do a lot of compatibility testing with this. Paul from Google had a great talk that goes into a lot of detail. That talk happened on Tuesday. But if you want to learn more about the chameleon be sure to just seek out and find Paul here at ZDS. And then we have, you know, I mentioned some of these before, but we had some other Googlers that were not able to travel to Prague. But be sure to look up, you know, Yuval, Al, Diana and Sam either up on GitHub or Discord if you have questions about their talks or maybe if you want to contribute. And in terms of in-person sessions, it's day three so the only session left that you can attend live is Aaron's talk on peripheral emulation, but I do encourage you to check that out. And then how to help. So, you know, where is Google trying to make some new friends? Sensors. You know, the work we've been doing here with Intel, it's going really well. But Intel and Google our use cases are really focused on laptops. So we'd like some other people from the community to start helping out here. I'm sure there's some other great use cases and applications that have some good ideas to make the sensors even better. And on the input subsystem, Fabio's kind of been a one-man show here. So if we could get some help, you know, maybe one thing is adding Z-Bus into this part of the implementation. And then finally for testing, you know, this is something that I think everybody in the project needs to help out on. Testing on real hardware is very expensive. And I don't have your hardware to test with, and you don't have mine. So introducing regressions can happen pretty easily. And, you know, within the embedded space, test is probably thought of as maybe a four-letter word. You know, let's get rid of that. And so, you know, I think a great goal, you know, a really big, hairy audacious goal for Zephyr would be that we would have emulators and tests for every single driver within Zephyr. So that's all I've got. Thank you very much and have a great day.