Weekly Vendor Sync on the First Arvenna Drop and a Slipping Power Driver

Good afternoon from Seoul, and good morning to Stockholm. Welcome to the weekly vendor sync. Today is a milestone in itself: it's the official start of Atlas development. Rachel from Platform Framework is joining us today, because one of the topics affects her team directly. Let's start with the review of BSP 0.5, then the development branch, and then the outlook for 1.0.

Good morning, everyone. Before we start, I want to say thank you for the clear feedback in the first two weeks. It's made our internal planning much easier.

Hi, everyone. Rachel from Framework. I'm here mainly to understand when the camera and audio pieces will land, since my team's September plan depends on them.

Daniel, how did BSP 0.5 go?

Overall, it's a solid first drop, and it arrived on time on the fourteenth, which I want to acknowledge. As agreed, we used it only for hardware validation on the evaluation boards. Display, storage, and USB all came up on the first day. The kernel console and Android shell work as described in the release notes. And the known issues list was accurate, which saved us a lot of time.

That's good to hear. We put a lot of effort into the release notes after the feedback on Orion.

It shows. There is one significant hardware validation issue, though. Memory training passes at the lower speed setting on all six boards, but at the full speed of 6400, it fails on two of the six. When it fails, the board doesn't boot at all. We've swapped the memory parts and the problem stays with the boards, not the parts.

That's useful, and I haven't heard of it from other customers. Could you send us the training logs from the bootloader for both failing boards? Our memory team can tell a lot from the per-lane results. It could be a board-level signal integrity issue, or it could be a training parameter that's too tight for some boards.

I'll send them today. I'd also like to know whether the same failure could happen on our proto hardware, which arrives next week. If the training margins are tight on your evaluation board, they could be even tighter on our layout.

Good point. I'll ask our memory team to prioritize this, because a proto board that can't run memory at full speed would block your first boot milestone. I'll come back with an initial assessment by Wednesday.

Next, the 6.12 development branch. Sora, how's it going?

Access came through on August 11th, one day later than planned, which is fine. The branch boots on the evaluation board most of the time, and two of our engineers have been porting our display and charging drivers against it. Our main problem is that suspend and resume don't work at all. The board goes into suspend, but it never wakes up. That blocks any battery or standby testing.

That's a known issue on the development branch, and it's actually connected to the 1.0 discussion. Our power management controller driver for 6.12 is still being reworked. The current version on the branch doesn't correctly restore the controller's state after resume, so the wake-up interrupt never reaches the CPU.

We also used the hot fix channel for the first time last week. We filed three blockers, and two came back with fixes within two working days, which is exactly what we agreed. The third is the suspend issue, which I understand is the bigger topic.

Let me be direct about it, since we agreed to give at least a week's warning. The power management rework is behind. Our current estimate is that the full 1.0 drop, including the reworked power driver, would ship on September 18th instead of September 11th. That's one week, which I know is exactly five working days, the threshold for your escalation trigger.

Thank you for raising it now rather than on September 10th. That's exactly the behavior I asked for. Before we decide anything, let's understand the impact. Daniel, Rachel, what does a one-week slip of 1.0 mean for each of you?

For kernel, our next milestone is the home screen on proto hardware by September 21st. That needs display, touch, storage, and a stable kernel on 6.12, but it doesn't strictly need suspend and resume. So, technically, we could reach the home screen without the reworked power driver, as long as we keep the device awake.

For framework, the problem is different. What I need from 1.0 is the camera and audio hardware abstraction layers. If those slip a week along with the power driver, my team loses a week of camera integration, and camera is the biggest feature on Atlas. I'm much more worried about camera and audio than about suspend.

So the two teams need different things from 1.0, and only one of those things is late. Priya, are camera and audio on track for September 11th?

Yes. Camera and audio are in final testing, and they're independent of the power driver rework. If we had the option, we could ship them on the eleventh as planned.

Then let's create that option. Split 1.0 into two drops: 1.0 on September 11th with the move to 6.12, camera, and audio, but with the current power driver and suspend as a known issue. Then 1.0.1 on September 18th with only the reworked power driver. Rachel gets camera on time, we get our home screen milestone, and suspend follows a week later.

That's feasible from a release perspective. My only concern is testing cost on our side. Each drop goes through four days of regression testing. Two drops in one week means our test team runs back to back. It's doable, but I want to be honest that it stretches them.

Could 1.0.1 be a smaller test cycle? If it only changes the power driver, a full four-day regression seems like overkill. A targeted run on power, thermal, and suspend tests might be enough, and we'd do our own broader testing when it lands.

That's a reasonable proposal. I'd still want to run our boot and stability smoke tests, because the power driver touches early boot. But that's one day, not four.

Then the question for me is the escalation trigger. Formally, the full 1.0 is late by five working days. But if we split the drop, nothing that blocks a milestone is late. I'd propose we don't trigger a formal replan, but I'll document the split and the reasoning in the risk register. Marco, does that work for you?

It does, and I appreciate the flexibility. I'd ask one thing in return: if 1.0.1 slips past the eighteenth, we treat that as a formal escalation without debate. I'd rather have a clear line than a negotiation every time.

Agreed. That's fair to both sides.

One condition from kernel's side. Please make sure 1.0 doesn't include a half-finished version of the new power driver. I'd much rather have the old, known driver with suspend broken than a partially reworked one with new, unknown behavior. Mixing the two would make every power bug we see in September ambiguous.

Understood. 1.0 will contain exactly the same power driver as the current development branch, and the release notes will say so explicitly. All of the rework lands together in 1.0.1.

Let's look ahead to the proto hardware. Daniel, what's your plan for the first week once the boards arrive on the twenty-fourth?

Day one is power-on and bootloader. If memory training passes at full speed, we move straight to the kernel console with the 0.5 BSP, since that's the most stable kernel we have. In parallel, we try the 6.12 development branch. Our goal is a kernel console on 6.12 by September 7th, as planned, but having 0.5 as a fallback means we can validate the hardware even if 6.12 has problems.

One suggestion: if you hit memory training problems on the proto boards, try the lower speed setting first to confirm everything else works, and send us the logs immediately. We can often provide adjusted training parameters within a day or two.

And on my side, the extra evaluation boards from Sora's request arrived on Friday, so my team now has six. That's enough to start camera integration as soon as 1.0 lands on September 11th, without waiting for proto hardware.

Good. For what it's worth, I'd recommend your team installs the development branch on two of those boards now, so you can start compiling the framework against the new kernel headers. That way, when 1.0 arrives, the only new thing is the camera stack itself.

Since development officially starts today, I'd like to agree on how our two companies work together day to day during bring-up. A weekly sync is fine for planning, but when a board doesn't boot at eleven at night in Seoul, nobody wants to wait until Monday. What's the fastest way for Daniel's team to reach the right person at Arvenna?

For bring-up, we usually set up a shared chat channel with our core engineers on it, in addition to the ticket portal. The rule is that anything blocking a board goes into the channel immediately with a short summary, and then gets a ticket for tracking. Our engineers in Stockholm start their day when it's mid-afternoon in Seoul, so there's a few hours of overlap every day.

That works well for us. The overlap is mostly our afternoon and their morning. What I'd ask is that we hand over clearly at the end of each Seoul day: a short note in the channel saying what's blocked, what we've tried, and which logs are attached. That way, Priya's team can work on it during their day, and we get answers when we come in the next morning.

I like that follow-the-sun approach. It's how we worked with another customer in Taipei, and it effectively gave us almost two working days per calendar day during critical weeks. The key is the quality of the handover note. If it's vague, we lose a whole cycle asking questions.

I can write a short template for the handover note: board identifier, build number, symptom, steps already tried, and links to logs. It sounds bureaucratic, but it saves a lot of back and forth.

Could framework engineers join that channel too, once we start camera integration? Camera issues often turn out to be in the hardware abstraction layer, and it would be faster to ask Arvenna directly than to route everything through kernel.

Of course. I'd suggest a separate thread for camera and audio, so the kernel discussions don't get buried. I'll add our camera and audio engineers to the channel before 1.0 lands.

Perfect. Then the weekly sync stays for planning and decisions, and the channel is for day-to-day unblocking. Sora's template becomes the standard for handovers.

One more question while I'm here. Kevin from Google sent the partner timeline, which says the last developer preview is in October and the final release in early December. Does Arvenna's 1.1 drop on October 9th target the developer preview, or the version before it?

It targets the last developer preview, assuming Google publishes it in early October as usual. If Google is late, we'd ship 1.1 against the previous preview and follow up with an update. We've had to do that before, and it's manageable.

Good. I'll add that dependency to the plan. Kevin offered to join these calls when there's a platform topic, so I'll invite him in early October.

Let me summarize. BSP 1.0 is split. 1.0 ships on September 11th with kernel 6.12, camera, and audio, and suspend as a known issue. 1.0.1 ships on September 18th with the reworked power driver, with a one-day smoke test on Arvenna's side. No formal replan, but if 1.0.1 slips past the eighteenth, that's an automatic escalation. Actions: Sora sends the memory training logs today. Marco returns an initial memory assessment by Wednesday. Priya updates the drop plan and known issues on the portal. Rachel's team sets up the development branch on two evaluation boards. And I update the risk register.

Understood. I'll have the updated plan on the portal by tomorrow morning, your time.

And I'll share our first-week proto plan with Priya, so her team knows what we'll be testing and can be ready for questions.

Thank you, everyone. This is a good example of how early warning turns a potential slip into a manageable plan. Our next sync is Monday, August 24th, at 4 p.m. Korea time, which is the day the proto boards arrive, so it might be an exciting one.

Let's hope it's exciting in a good way. Thanks, Hyejin. I'll make sure our memory engineer is in the channel on the twenty-fourth, just in case the proto boards behave like the two evaluation boards did. If they do, we'll want to look at the training logs while your team is still in the lab.

Thanks, everyone. I'm glad I joined; this changed my September plan for the better.