Ta biết rằng Linux chạy ở khắp nơi từ siêu máy tính, máy chủ, máy để bàn (máy xách tay), điện thoại (android)…cho đến các thiết bị gia dụng, gia đình. Khi sử dụng máy tính cá nhân, server ta dễ dàng “sờ” thấy được các thành phần của Linux như các tiến trình, shell..etc. Hầu hết các bản phân phối phổ biến làm hết những thứ liên quan đến phần cứng, nhân hệ điều hành, driver cho ta rồi. Ta thường chỉ quan tâm đến ứng dụng chạy trên đó thôi. ...
Bài này sẽ dịch lại Slide thảo luận giữa 2 diễn giả là Alexandre Belloni, Thomas Petazzoni từ Free Electrons tại Embedded Linux Conference 2016. So sánh giữa Buildroot và OpenEmbedded/Yocto Project 1. Điểm chung Đều là build-system cho Embedded Linux. Mục tiêu là có thể customize, build hoàn chỉnh một Embedded Linux System. Bao gồm: filesystem, toolchain, kernel, bootloaders Đều được build từ source Sử dụng cross-compilation Rất actively trong cả dự án đang maintained và phát triển. Được sử dụng rộng dãi trong công nghiệp. Tài liệu tốt, nhiều khóa đào tạo. Sử dụng Free Software (phần mềm tự do) 2. Khác nhau 2.1 Về tư tưởng chung Buildroot: Tập trung mạnh vào sự đơn giản Dễ sử dụng dễ hiểu và mở rộng Các trường hợp đặc biệt sẽ được thực hiện qua extension scripts. Sử dụng được ác công nghệ, ngôn ngữ đang tồn tại hiện nay: kconfig, make Minimallist : phương trâm càng nhỏ càng tốt Không phụ thuộc vào mục đích sử dụng Cộng đồng mở, nhưng có vendor hoặc tổ chức nào quản lý Yocto Hỗ trợ nhiều kiến trúc phổ biến OpenEmbedded: Chỉ hỗ trợ qemu Yocto Project : Thêm những nền tảng máy khác Chỉ cung cấp core recipes, sử dụng layer để mở rộng và thêm gói cũng như nền tảng phần cứng. Việc custom chỉ xảy ra ở các layer riêng biệt Hệ thống build đa năng: cố gắng linh hoạt nhất có thể để handle hầu hết các trường hợp sử dụng. Cộng đồng mở, nhưng vẫn được quản lý bởi Yocto Project Advisory Board, vốn được tạo bởi các công ty tài trợ OpenEmbedded là một dự án cộng đồng độc lập 2.2. Về output Buildroot Ouput chính là một root filesystem image Cũng có thể kèm toolchain, kernel image, bootloader đi kèm. Hỗ trợ nhiều định dạng: ext2/3/4, ubifs, iso9660, etc. Không có gói binary, không có hệ thống quản lý gói Nhiều người gọi là firmware generator Không thể update qua các gói Cần update toàn bộ hệ thống, như Android. Không nên tin tưởng việc update 1 phần. Yocto Project: Tạo bản phân phố, đầu ra là một loại các package. Hệ thống quản lý là tùy chọn cho hệ thống đích Có thể cài đặt, update chỉ 1 phần của hệ thống Cũng có thể sinh *root filesystem images thông qua cài đặt các tool tạo image. Hỗ trợ: ext2/3/4, ubifs, iso9660, etc…cũng có cả VM Images, vmdk, vdi qcow2 Cuối cùng, có thể tạo ra 1 disk image Cũng có thể sinh một SDK kèm theo image, cho phép app developer compile, test ứng dụng của họ mà không cần tích hợp chúng trong quá trình build. Nhưng SDK phải được đồng bộ với thay đổi của image. 2.3. Cấu hình (Configuration) Buildroot: Sử dụng lại kconfig từ Linux kernel Giao diện đơn giản thông qua {menu,x,b,g} config Toàn bộ configuration được lưu trong 1 file duy nhất .config/defconf Định nghĩa toàn bộ các khía cảnh của hệ thống: kiến trúc, kernel version/config, bootloader, user-space packages, etc. make menuconfig, make -> đơn giản Build cùng một hệ thống cho nhiều máy khác nhau: sẽ hoàn toàn riêng biệt Cần 1 tool để sinh defconfig từ nhiều fragements Có thể làm được những không quá dễ Quá trình build hoàn toàn tách biệt cho mỗi máy Yocto Project: Quá trình configuration được chia ra làm nhiều phần: Distribution configuration: cấu hình gói general, toolchain, chọn libc. Machine configuration: định nghĩa architecture, đặc tính machine, BSP. Image recipe: Quy định package nào sẽ được cài dặt trên hệ thống đích Local configuration: bản phân phối với máy build luôn, có bao nhiêu thread có thể sử dụng khi compiling, có hay không xóa bỏ code sau khi build. Cần biêt về nhiều lớp khác nhau mới có thể sử dụng chúng. Cho phép build cùng 1 image cho nhiều máy hoặc nhiều distribution hoặc nhiều ảnh cho 1 máy 2.4. Layers (Lớp) Buildroot: Không có khái niệm này Tất cả package được maintained từ các kho chính thức Cho phép chất lượng rất tốt nhờ được review bởi experts Sử dụng *BR2_EXTERNAL Cho phép lưu trữ định nghĩa package, cấu hình và các thông tin khác. Chỉ có 1 BR2_EXTERNAL Sử dụng cho các package custom hoặc proprietary package Chỉ có thể add, không cho phép override. Yocto Project: Cơ chế layer cho phép sửa/thêm package mới hoặc tạo ảnh mới Xóa bỏ sự ngăn cách giữa core build system, BSP và các chỉnh sửa Scales được, bên thứ 3 có thể cung cấp layer với BSPs của họ hoặc một tập recipes để handle những ứng dụng đặc trưng Sử dụng layer cùng nhau phải đảm bảo tính tương thích và dùng chung OE branch base. Cần để ý chất lượng layer, việc review vẫn chưa có tính hệ thống OpenEmbedded Metadata Index đưa ra danh sách các layer, recipe, máy hiện mà framework này hỗ trợ tại http://layers.openemdedded.org/layerindex Có cơ chế override cho phép điều chỉnh recipe dựa trên máy hoặc distro. 2.5. Về toolchain Tự build toolchain, dựa trên gcc, lựa chọn được thư viện C Libraries (glibc, uClibc, musl) Sử dụng các toolchain build sẵn từ bên ngoài: Có vẻ bên Buildroot thì dễ dàng hơn vì nó có sẵn bên trong Chỉ thực sự support tốt với những layer từ các vendor trong Yocto Project Buildroot: không có trong slide Yocto Project : không có trong slide 2.6 Về mức độ phức tạp Buildroot: ...
Trong loại bài dịch trước đây nói về USB, tôi có nhắc một chút đến việc load đúng driver thì phía Host làm thế nào? Như ta đã biết, khi một thiết bị USB được cắm vào máy (Host), phía Host sẽ thực hiện một loạt thao tác từ xác định nguồn (bus, hay self), lấy thông tin tốc độ, các thông tin về descriptor (thiết bị, giao diện, các Endpoint). Cuối cùng để sử dụng các tính năng chính mà thiết bị cung cấp, thì hệ điều hành phía Host, dù là Windows, hay Linux, hay MacOS sẽ phải load driver tương ứng với thiết bị. ...
Như ta đã làm trong bài trước, sau khi thực hiện việc setup các biến môi trường bằng lệnh source, ta thực hiện build tạo image có có tên là rpi-basic-image thông qua lệnh: $bitbake rpi-basic-image Thực ra còn 2 image khác ta có thể build đó là rpi-hwup-image rpi-test-image. Ta có thể thấy 2 file bb cho 2 image ở thư mục meta-raspberrypi/recipes-core/images/. rpi-hwup-image : là image nhỏ nhất (có dịp sẽ thử) rpi-basic-image: là image ta vấn dùng đến bây giờ. rpi-test-image : là image dùng cho việc test. (có dịp sẽ thử) ...
Để tiếp tục customize bản OS được build trong bài trước. Hôm nay ta sẽ thực hiện một nhiệm nhỏ. Đó là thiết lập một IP cho bản build. Tức là ta sẽ thiết lập 1 IP mặc định được gán cho Raspberry PI khi nó được khởi động bằng bản build của chúng ta. Như thường lệ ta cần thiết lập các biến môi trường trước khi định thực hiện bất cứ thay đổi nào trên bản build. ...
Ta đã nói đến việc build một bản phân phối Linux cho Raspberry PI ở bài Tạo một bản phân phối Linux cho Raspberry PI bằng Yocto Project. Một trong những giao thức truy cập file phổ biến nhất hiên nay là SMB, vốn ban đầu được hỗ trợ trên các máy Windows, dùng cho giao thức chia sẻ file trong mạng nội bộ. Trên Linux, để tạo một server như thế, người ta dùng Samba (cái tên cũng na ná nhỉ). ...
Ban đầu, dự định sẽ tạo một NAS server theo link tham khảo bên dưới. Nhưng thấy ta nên tách riêng phần tạo bản phân phối Linux thành 1 bài riêng, rồi viết các nội dung liên quan đến customize thành các bài khác sẽ dễ hiểu hơn. Hơn nữa, phần tạo bản build basic sẽ cần được thảo luận kĩ hơn do có thể phát sinh nhiều vấn đề. Mà nếu không giải quyết được các vấn đề đó thì nội dung các bài khác sẽ không thể thực hiện được. Do vậy, bài này sẽ tập trung vào tạo bản basic rpi-basic-image thôi. ...
Poky là một hệ distro linux ở dạng tham chiếu của Yocto Project. OpenEmbedded là một phần trong đó. Nào thế đủ rồi, ta đi vào phần chính. 1. Về Yocto project và ứng dụng cho Rasberry PI Lần trước, tôi có viết một hứng về việc tạo ra một ảnh cho Raspberry dựa trên Raspbian (chụp lại ảnh của một hệ thống đang chạy). Với kết quả lúc trước, thì vấn đề là nó không thực sự nhỏ hơn, khi giải nén ra nó vẫn chiếm khoảng 414MB. ...
Bitbake là một công cụ cốt lõi của Yocto Project. Nó bao gồm 1 bộ thông dịch các script được viết trong các file recipe (công thức tạo phần mềm), và thực hiện các lệnh trong đó. Nó mô tả lại và tự động hóa qúa trình người ta đưa một phần mềm vào một distro. Về việc đưa một phần mềm vào distro, ta có thể thấy nó bao gồm vài step chính. Từ việc tải source code (ở đây là tải source code chứ không phải các gói đã được build sẵn đâu nhé, nó gần giống với ArchLinux, Gentoo và hoàn toàn khác với Ubuntu) , thực hiện các bản patch (sửa source hoặc kịch bản build đề phù hợp mục đích sử dụng), biên dịch, cuối cùng là tích hợp vào distro (kèm theo các thông số cấu hình). ...