Kicking Off Atlas Lite on a Second Chipset Platform

Good afternoon, everyone. Thanks for coming in on a Sunday. I'll be quick with the introductions, because I want most of our time for the schedule discussion. I'm Mark from Program Management, and I've just been assigned as the software program manager for Atlas Lite. It's my first program on the system software side, so please be patient with me when I ask basic questions.

Welcome, Mark. Basic questions are usually the ones that catch real problems. I'm Chris, Kernel and BSP. I'll be the kernel lead for Atlas Lite, on top of my Orion Lite work.

Dongwook Kang, also Kernel and BSP. I just finished the Pulse Watch launch, so I'm free to focus on Atlas Lite bring-up from next week.

Harin Jeon, Platform Framework. I'll lead the framework work for Atlas Lite. Most of my team is currently on Atlas, so I'm especially interested in how we share code between the two programs.

Nina Cho, SQE. I'll be the quality lead. I was on the Nova Tab launch until last week, so I've had a very recent reminder of how things go wrong at the end of a program.

Let me give the background. Atlas Lite is the mid-range companion to Atlas. The business wants it to share the Atlas software experience, same Android version and same major features, but on Qorvix's new mid-range chipset, the Q7, to hit a lower price point. The target market launch is June 4th, 2027, about three months after Atlas.

And that's the core challenge right there. Atlas is on Arvenna. Atlas Lite is on Qorvix. So the kernel and BSP work is almost entirely separate, even though the user sees the same software. Two chipset vendors means two BSPs, two sets of drivers, and two sets of vendor bugs.

That's exactly the kind of thing I need to understand. Are there any advantages to using Qorvix again, given that Orion and Orion Lite are also on Qorvix?

Definitely. We know the Qorvix team, their release process, and their tools. Many of our Orion drivers for displays, sensors, and charging can be reused with modest changes. And the Q7 is a cost-reduced version of the chipset family Orion uses, so a lot of the hardware blocks are familiar. The risk is lower than starting with a brand-new vendor.

One important difference, though. Orion is on kernel 6.1, but Atlas Lite has to launch on 6.12, because it's a new device on the new Android release. So we can reuse Orion's driver logic, but not Orion's kernel. That's where the GKI work Sora presented on Friday becomes directly relevant.

Let's talk about how the code is organized. Harin, do we create a separate branch for Atlas Lite, or do both products live on one branch?

My strong preference is one common branch for the framework, with device-specific configuration layered on top. We tried separate branches for Orion and Orion Lite, and we spent months porting fixes back and forth. Half of the field issues on Orion Lite last year were bugs we had already fixed on Orion but never ported.

From the quality side, I fully agree. One branch means one set of fixes. But it also means that a change made for Atlas can break Atlas Lite, and vice versa. If we go that way, we need automated testing on both devices for every change, from the very beginning.

For the kernel, the situation is a little different. With GKI, the core kernel is shared anyway. Our vendor modules will be different for each chipset, but common logic, like our thermal framework or charging policies, should live in shared modules that both devices use. I'd want a clear rule: if code isn't chipset-specific, it goes into a shared module.

That sounds sensible. Are there any downsides I should be aware of?

The main downside is timing. Atlas is three months ahead of us. If Atlas is in code freeze while we're still adding features, a shared branch can create tension, because they won't want any risky changes. We'll need a clear policy for how Atlas Lite features are merged during Atlas's stabilization period, probably behind feature flags that are turned off for Atlas.

Let's talk about the hardware itself. What's different about Atlas Lite that affects software?

The biggest one is memory. Atlas has twelve gigabytes of RAM. Atlas Lite will ship with six gigabytes in most markets, and four in a few price-sensitive ones. The Atlas software was designed with a lot of headroom. On a four-gigabyte device, some features, like on-device AI or keeping many apps in the background, will behave very differently.

That's my biggest concern too. Some of the new Atlas features assume they can keep a large model in memory. On four gigabytes, they'll either have to be disabled or redesigned. I'd like the product team to tell us early which features are mandatory on Atlas Lite, so we don't spend months optimizing something that gets cut anyway.

I'll make that my first action item. I'll ask product management for a feature list with three categories: must have, nice to have, and Atlas only, by the end of August.

And please ask them to decide on the four-gigabyte variant early as well. Testing two memory configurations doubles a lot of our performance and stability work. If the four-gigabyte version is only for two small markets, I'd want to know whether it's worth that cost.

Now the schedule. Here's my draft, working backward from June 4th. Release candidate on April 30th. Code freeze on April 9th. Feature complete on February 26th. First boot on Q7 hardware on October 26th. And development starts when Qorvix delivers the first Q7 BSP, which they've said will be September 28th. Please tear it apart.

First boot four weeks after the BSP drop is reasonable for a chipset family we know. But I'd push for starting before September 28th. Qorvix has an evaluation board for the Q7 that's available now. If we get two of them in early September, we can start porting our shared drivers to 6.12 a month earlier, and first boot on real hardware becomes much less risky.

That sounds like a good investment. Is there any reason not to?

Only staffing. Dongwook is free from next week, but the other two kernel engineers for Atlas Lite are on Orion Lite until the September release. So early work would be Dongwook alone, which is fine for porting, but he shouldn't be expected to solve everything by himself.

My concern is later in the schedule. Atlas code freeze is January 22nd, and its final stability campaign runs into February. Atlas Lite feature complete is February 26th. That means SQE is running the Atlas final campaign and the Atlas Lite pre-feature-complete testing at the same time. We don't have enough test devices or people for both.

What would you suggest?

Two options. Either we move Atlas Lite feature complete to mid-March, after the Atlas campaign ends, which compresses our own stabilization window. Or we start Atlas Lite stability testing much earlier, in December, while it's still lightweight, and accept that we'll find bugs later than ideal. I lean toward the second option, but only if the shared branch works as Harin described, so fixes found on Atlas automatically benefit Atlas Lite.

That's a strong argument for the shared branch. On a shared branch, the Atlas final stability campaign is effectively testing a big part of Atlas Lite's code as well. We'd only need to focus Atlas Lite testing on the device-specific parts and the memory configuration.

Let me list the risks I've heard so far, and you tell me what I've missed. The Qorvix Q7 BSP date. Memory constraints on the four-gigabyte variant. Staffing until the Orion Lite September release. SQE capacity overlapping with Atlas. And merge policy during Atlas's code freeze.

Add one more: Qorvix's own GKI readiness. Their Orion drivers were written for the old non-GKI model. They told us the Q7 BSP will be GKI-compliant from the first drop, but that's a big change for them, and I'd want to see the first drop before I believe it.

Related to that: if the first Q7 drop isn't GKI-compliant, we'll have to do a lot of the conversion work ourselves, which would push first boot out by several weeks. I'd suggest we ask Qorvix to share their symbol list requests with us early, so we can see how much non-standard access their drivers need.

Good. I'll add both to the risk register, with Chris as the owner for the Qorvix GKI risk.

Let me ask a basic question about staffing. How big does the Atlas Lite team need to be, and where are those people coming from? I've been told the headcount is fixed, so I need to understand what we can realistically do with it.

For kernel and BSP, the plan is six engineers at full strength: Dongwook plus two from Orion Lite after the September release, and three from Orion after its maintenance load drops in October. That's enough, but only because so much of the Qorvix knowledge already exists within those teams. If we had to hire from outside, it would take months to get people up to speed.

On the framework side, it's trickier. Most of the expertise on the new Atlas features is with the Atlas team, and they won't be free until after Atlas launches in March. So for Atlas Lite, we'll mostly be integrating features that someone else designed, and we'll need their help whenever something behaves differently on low memory.

How do we make sure that help is actually available when we need it? Everyone on Atlas will be under pressure in January and February.

I'd suggest naming a 'feature buddy' on the Atlas team for each major feature, someone who agrees to spend a few hours a week answering our questions. It needs to be formally agreed with their managers, otherwise it'll be the first thing to disappear when Atlas gets busy.

We could do the same on the kernel side, in the other direction. I learned a lot about Qorvix power management on Pulse Watch, and the Atlas kernel team will hit similar problems on Arvenna. Sharing what we learn across both chipsets should help everyone.

I like that a lot. I'll talk to the Atlas program manager this week and propose the buddy system formally, so it's part of both programs' plans rather than an informal favor.

Before we finish, I'd like to propose one quality principle for Atlas Lite. On Nova Tab, the thermal regression slipped through because our long-duration tests only ran on release candidates. For Atlas Lite, I want sustained performance and memory pressure tests running weekly from first boot, not just at the end. Mid-range devices live and die by how they perform after an hour of use, not in a three-minute benchmark.

I'd support that, especially for memory. On low-memory devices, the problems usually show up as apps restarting in the background, which users find extremely annoying but which never appears as a crash in our dashboards.

Then let's make it a program requirement, with its own line in the weekly status report. Nina, could you define the tests and the pass criteria?

Yes. I'll include an app restart metric: how many of the last ten used apps are still in memory after thirty minutes of mixed use. That's the number users actually feel.

Let me summarize the decisions. One common framework branch with Atlas, with device configuration on top and feature flags during Atlas's freeze. Shared kernel modules for anything that isn't chipset-specific. Early development on Q7 evaluation boards from early September, with the official start on September 28th. First boot October 26th, feature complete February 26th, code freeze April 9th, release candidate April 30th, launch June 4th. Atlas Lite stability testing starts in December. Any objections?

No objection from kernel.

Action items. Dongwook: request two Q7 evaluation boards from Qorvix this week. Chris: get written confirmation of the Q7 BSP date and their GKI readiness, including their symbol list requests. Harin: draft the shared branch and feature flag policy, and review it with the Atlas framework leads. Nina: define the weekly sustained performance and memory tests. And I'll get the feature list from product management by August 31st.

I'll set up the review with the Atlas leads for next Thursday. If they have concerns, better to hear them now than in January.

Thank you all. For a first meeting, I feel like I learned more in an hour than in a week of reading documents. Our next checkpoint is Sunday, August 30th, at 3 p.m. Korea time, here. By then, we should have the evaluation boards ordered, the feature list, and the branch policy draft.

Sounds good. And Mark, keep asking the basic questions. They're useful.

I'll take you up on that. And I'll send out the minutes tonight with the draft milestones, the risk register, and the action items, so anyone who wasn't here today can catch up before Monday. See you all in two weeks.

Thanks, Mark. Please include the four-gigabyte question in the minutes too, so product management sees it as an open decision.