Hai CPU trong một SoC nói chuyện với nhau thế nào? Mailbox, Mutex và Shared RAM

Trả lời nhanh

• Trên các SoC dị thể (heterogeneous SoC), Cortex-A chạy Linux và Cortex-M chạy RTOS nằm chung một chip, chung một không gian địa chỉ vật lý — và chúng giao tiếp với nhau qua đúng 3 cơ chế phần cứng: Mailbox, Mutex và Shared RAM, mỗi thứ làm một việc rất khác nhau.
• Mailbox chỉ "báo có hàng": bên gửi ghi 1 word vào thanh ghi DATA, set bit STATUS, phần cứng bắn ngắt doorbell (doorbell IRQ) sang CPU kia để đánh thức nó. Dữ liệu thật không đi qua Mailbox — nó nằm ở Shared RAM. Đây chính là cơ chế "kick" quen thuộc trong virtio.
• Mutex là khóa phần cứng kiểu test-and-set để phân xử ai được đụng vào tài nguyên chung: đọc bit ra 0 nghĩa là được cấp khóa (lock granted), ra 1 nghĩa là bên kia đang giữ.
• Shared RAM là nơi dữ liệu thật nằm: chứa payload và các vrings (vòng đệm của virtqueue). Cả hai CPU đều truy cập trực tiếp bằng load/store qua Interconnect, vì cùng nhìn thấy một physical address space.
• Một lệnh từ Linux xuống Cortex-M đi qua 7 bước: xin lock → ghi payload vào Shared RAM → nhả lock → ghi Mailbox → doorbell IRQ → Cortex-M đọc payload → xử lý và điều khiển ngoại vi (CAN, GPIO) qua MMIO.

Giao tiếp liên bộ xử lý (IPC) trong SoC dị thể là gì?

Giao tiếp liên bộ xử lý (Inter-Processor Communication — IPC) là tập hợp các cơ chế phần cứng và phần mềm giúp nhiều nhân xử lý trên cùng một chip phối hợp làm việc mà không xung đột dữ liệu. Trong SoC dị thể, các nhân khác hẳn nhau về kiến trúc và hệ điều hành — ví dụ nhân hiệu năng cao Cortex-A chạy Linux đảm nhiệm giao diện, mạng và ứng dụng; nhân thời gian thực Cortex-M chạy RTOS đảm nhiệm điều khiển ngoại vi, cảm biến và các tác vụ cần phản hồi tức thì. Vì hai bên không dùng chung được các cơ chế đồng bộ phần mềm thông thường (như spinlock giữa hai kiến trúc khác nhau), SoC phải cung cấp cơ chế đồng bộ và thông báo ở mức phần cứng.

Vì sao hai CPU chung một chip vẫn cần cơ chế giao tiếp riêng?

Câu hỏi cốt lõi là: hai CPU phải nói chuyện với nhau bằng cách nào mà không "giẫm chân nhau". Chúng dùng chung bộ nhớ và ngoại vi, nên nếu cả hai cùng ghi vào một vùng dữ liệu mà không có phân xử, dữ liệu sẽ hỏng. Ngược lại, nếu một bên ghi xong dữ liệu mà bên kia không hề biết để mà đọc, dữ liệu cũng vô ích.

Nhìn vào sơ đồ của bài gốc, SoC được chia thành 4 tầng từ trên xuống: Processors (hai CPU), Mailbox/Mutex, Interconnect, và Memory/I/O. Ngoài hai CPU, chỉ có đúng 3 thứ tham gia vào việc giao tiếp: Mailbox để thông báo, Mutex để phân quyền, và Shared RAM để chứa dữ liệu. Ba vấn đề — "ai được đụng vào dữ liệu", "dữ liệu nằm ở đâu" và "làm sao biết có dữ liệu mới" — được tách bạch thành ba cơ chế riêng.

Mailbox hoạt động như thế nào?

Mailbox là kênh thông báo nhỏ nhất có thể. Bên gửi ghi 1 word vào thanh ghi DATA và set bit STATUS. Phần cứng lập tức bắn một doorbell IRQ sang CPU kia. Bên nhận thức dậy, đọc DATA — xong. Chỉ vậy thôi.

Điểm mấu chốt cần nhớ: Mailbox chỉ chuyển được một word nhỏ (ví dụ một chỉ số buffer), không phải dữ liệu lớn. Nó chỉ nói "có hàng rồi, ra lấy đi" — còn "hàng" thật nằm ở Shared RAM. Ai từng làm việc với virtio sẽ nhận ra ngay: đây chính là cái "kick" mà guest dùng để báo cho host biết virtqueue vừa có thêm buffer.

Một chi tiết nữa: Mailbox thường chỉ đi một chiều. Muốn Cortex-M trả lời lại Cortex-A thì chiều ngược lại cần một Mailbox khác.

Mutex phần cứng khác gì khóa phần mềm?

Mutex giải quyết một bài toán khác hẳn Mailbox: ai được phép đụng vào tài nguyên chung tại một thời điểm. Mỗi CPU gửi yêu cầu khóa (lock request) theo kiểu test-and-set: nếu bit đọc về bằng 0 thì lock granted — CPU đó được vào; nếu bằng 1 thì bên kia đang giữ, phải chờ.

Mutex này được làm bằng phần cứng là có lý do. Hai nhân Cortex-A và Cortex-M khác kiến trúc, chạy hai hệ điều hành khác nhau (Linux và RTOS), nên spinlock phần mềm thông thường không dùng chung được một cách tin cậy. Đưa phép test-and-set xuống phần cứng khiến việc tranh khóa trở nên nguyên tử (atomic) và công bằng cho cả hai bên, bất kể mỗi bên chạy hệ điều hành gì.

Shared RAM và Interconnect đóng vai trò gì?

Hai đường dọc ở mép trái và phải của sơ đồ (nhãn "bus access: load, store") là đường CPU truy cập bộ nhớ và ngoại vi bình thường. Chúng đi từ hai CPU xuyên qua tầng Mailbox/Mutex xuống thẳng Interconnect — không đi qua Mailbox hay Mutex. Vì hai CPU dùng chung một physical address space, cả hai đều thấy cùng một Shared RAM.

Interconnect là bus trung tâm, phân phối mọi truy cập của hai CPU tới 4 đích:

• Shared RAM: truy cập load/store, chứa payload thật và các vrings — vòng đệm của virtqueue trong virtio.
• UART: qua MMIO, truyền các byte nối tiếp.
• CAN: qua MMIO, truyền các frame CAN.
• GPIO: qua MMIO, đọc/ghi mức logic của chân.

MMIO (Memory-Mapped I/O) nghĩa là CPU điều khiển ngoại vi bằng cách đọc/ghi vào địa chỉ của nó, y như đọc/ghi RAM — không cần lệnh vào/ra riêng biệt.

Cơ chế	Việc nó làm	Dữ liệu đi qua	Điểm cần nhớ
Mailbox	Thông báo "có hàng" và đánh thức CPU kia bằng doorbell IRQ	1 word nhỏ (ví dụ chỉ số buffer) trong thanh ghi DATA	Thường một chiều; chính là cơ chế "kick" của virtio
Mutex	Phân xử quyền dùng tài nguyên chung bằng test-and-set phần cứng	1 bit trạng thái: 0 = được cấp khóa, 1 = đang bị giữ	Cần phần cứng vì hai nhân khác kiến trúc/OS không dùng chung spinlock được
Shared RAM	Chứa dữ liệu thật để hai bên cùng đọc/ghi	Payload và vrings (virtqueue)	Cả hai CPU cùng thấy vì chung physical address space

Một lần Linux gửi lệnh cho Cortex-M diễn ra theo thứ tự nào?

Ghép cả ba cơ chế lại, một lần Cortex-A (Linux) gửi lệnh cho Cortex-M (RTOS) diễn ra đúng 7 bước:

1. Cortex-A xin lock ở Mutex và nhận được granted.
2. Cortex-A ghi payload vào Shared RAM qua Interconnect.
3. Cortex-A nhả lock.
4. Cortex-A ghi vào thanh ghi DATA của Mailbox một word nhỏ (ví dụ chỉ số buffer) và set bit STATUS.
5. Mailbox bắn doorbell IRQ sang Cortex-M.
6. Cortex-M thức dậy, đọc DATA, rồi đọc payload từ Shared RAM.
7. Nếu cần phản hồi, Cortex-M làm ngược lại — và vì Mailbox thường chỉ một chiều nên chiều ngược lại dùng một Mailbox khác.

Sau khi nhận lệnh, Cortex-M xử lý yêu cầu bằng cách điều khiển ngoại vi qua MMIO: ví dụ gửi một frame ra bus CAN hoặc đổi mức logic của một chân GPIO. Nhìn tổng thể, đây chính là nền tảng phần cứng mà các framework giao tiếp liên nhân như RPMsg và OpenAMP xây lên trên: Shared RAM giữ vai trò của các virtqueue, Mailbox giữ vai trò thông báo "kick", còn Mutex bảo vệ các cấu trúc dữ liệu dùng chung trong lúc hai bên cùng truy cập.

Câu hỏi thường gặp

Mailbox có truyền được dữ liệu lớn không? Không. Mailbox chỉ chuyển 1 word nhỏ như một chỉ số buffer. Dữ liệu lớn luôn nằm ở Shared RAM; Mailbox chỉ đóng vai trò thông báo "có hàng ở Shared RAM, ra lấy đi".

Vì sao không dùng spinlock phần mềm giữa Cortex-A và Cortex-M? Vì hai nhân khác kiến trúc và chạy hai hệ điều hành khác nhau (Linux và RTOS), spinlock phần mềm thông thường không dùng chung được một cách tin cậy. Mutex phần cứng thực hiện phép test-and-set một cách nguyên tử, độc lập với phần mềm của từng bên.

MMIO là gì? MMIO (Memory-Mapped I/O) là cách CPU điều khiển ngoại vi bằng cách đọc/ghi vào các địa chỉ bộ nhớ được ánh xạ cho ngoại vi đó, y như đọc/ghi RAM. Trong SoC này, UART, CAN và GPIO đều được truy cập qua MMIO thông qua Interconnect.

Doorbell IRQ là gì? Là ngắt phần cứng mà Mailbox phát ra để "gõ cửa" đánh thức CPU bên kia ngay khi có thông báo mới, thay vì bắt CPU đó phải liên tục kiểm tra (polling) xem có dữ liệu chưa — nhờ vậy bên nhận có thể ngủ và chỉ thức dậy khi thật sự có việc.

Hai CPU có cần cùng hệ điều hành để giao tiếp qua cơ chế này không? Không. Toàn bộ cơ chế Mailbox, Mutex và Shared RAM nằm ở phần cứng, nên một bên chạy Linux và một bên chạy RTOS vẫn giao tiếp được — đây chính là tình huống phổ biến nhất trên các SoC dị thể.

---

Nguồn tham khảo: bài viết "Hai CPU nói chuyện với nhau như thế nào?" của tác giả Devlinux trong nhóm Cộng đồng lập trình Nhúng & Vi Mạch (devlinux.vn) trên Facebook, đăng ngày 08/11/2026. Sơ đồ minh họa là hình của bài gốc.