Do yêu cầu bắt buộc nên gần đây phải làm việc với VIM. Thực ra vẫn dùng máy tính Windows để chạy các ứng dụng SSH Client, SCP, rồi thì Excel. Tuy nhiên, các thao tác chủ yếu với source, text file, là trên command. Mà trên command của Unix, hay Linux. Dù có trả qua bao nhiêu năm nữa, thì có vẻ chỉ có 2 trường phái là VIM và Emacs thôi. Nhiều người thích Emacs, cũng nhiều người thích VIM. ...

Chuyển sang dùng Vi Vi - Editor khá nhiều tuổi, có lẽ còn nhiều tuổi hơn của mình. Là editor phổ biến nhất trên hệ thống dòng lệnh Linux, Unix hoặc tương tự. Có Linux, bạn gần như sẽ có thể dùng Vi. Mà Linux thì có ở rất rất nhiều nơi. Có phải vì nó mặc định nên nó phổ biến??? Mình từng nghĩ vậy hoặc nghĩ chắc nó nhẹ nên người ta cài sẵn nó thôi chứ chức năng hoặc độ tiện dụng chắc tệ lắm. Vì thực ra, ở trường mình từng dùng 1, 2 lần thôi. Vì khi mới bắt đầu biết đến Linux, thì nó cũng có giao diện đồ họa khá tiện rồi. Thầy giáo lại là một emacs-fan nữa nên ít khi phải dùng Vi. Vi thường xuất hiện trong những câu chuyện chém gió về những pro chưa từng gặp, những hacker kiệt xuất, etc…Nào là pro toàn dùng Vim thôi, hay bọn hacker chắc dùng Vim kinh lắm… Đến gần đây, khi càng ngày càng muốn theo Embedded Linux, mình vẫn chưa sử dụng Vi bao giờ vì đơn giản, mọi thứ mình đang dùng (Notepadplusplus, Eclipse) khá ổn. Thế nhưng, từ giờ chắc phải suy nghĩ về việc học sử dụng nghiêm túc em Vim này. Nó đến từ việc mình bị bắt phải dùng khi bắt đầu việc mới. Thực ra mình cũng không ngại đâu, sẽ nhớ được thôi. Bí quá thì copy ra ngoài notepad++ rồi lại copy vào.:))) Nhưng không, mình đã lầm, Vim có nhiều thứ hơn mình nghĩ. Mới đang ở giai đoạn bắt đầu sử dụng Vim như là editor chính, cả công việc lẫn ở nhà. Nên cứ note tạm mấy cái mình thấy hữu ích và có thể xem đi xem lại thôi. ...

Có một vài lệnh hữu dụng được cộng đồng sử dụng board NXP chia sẻ, mình sẽ note ở đây cho dễ tìm vậy. Link tại đây. Lệnh Bitbake **Miêu tả ** bitbake _Nấu ra 1 “ảnh” (Image) _(Thêm tham số _-k đ_ể cho phép chạy đến hết kẻ cả có lỗi thực thi) bitbake -c Thực hiện 1 task của package nào đó. Tên các task mặc định thường có``: _fetch,_ unpack, patch, configure, compile, install, package, package_write, and build. ...

Tham khảo Sách : AT&T Assembly Language, Richard Blum 1. Ngôn ngữ Assembly là gì? Ở mức thấp nhất, Process chỉ hiểu instruction code Instruction Code là các mã nhị phân chứa các thành phần: Instruction prefix, Opcode, ModR/M, SIB, Displacement, Data Element. Người ta hoàn toàn có thể viết chương trình bằng instruction code, nhưng nó sẽ cực kì khó nhọc, bởi ta chỉ thấy không gì khác ngoài các byte nối tiếp nhau. Việc sử dụng các ngôn ngữ bậc cao giúp việc viết chương trình dễ dàng hơn rất nhiều, vì trình biên dịch hoặc thông dịch đảm nhiệm việc chuyển mã ngôn ngữ bậc cao trực tiếp hoặc gián tiếp sang instruction code để chạy. Tuy nhiên, việc sinh instruction code của trình biên dịch/thông dịch không phải luôn luôn hiệu quả. Khi muốn động vào các kết quả được sinh ra từ trình biên dich/thông dịch ở trên, ta không khó có thể sử trực tiếp trên instruction code, một dạng dễ nhớ của các instruction code này được sinh ra để phục vụ việc này. Đó chính là Assembly Language. Vì gần như được chuyển sang instruction code của Processor nên Assemble Code gần như được gắn với Processor nào đó. Dù các lệnh của hầu hết bộ xử lý là tương tự nhau nhưng quy tắc gợi nhớ các mã Assembly dù chỉ khác nhau một chút thôi cũng khiến việc viết code cross-processor gần như là không thể rồi. Ta nói Assembly Language là nói đến 1 ngôn ngữ, nhưng thực chất mỗi Processor có 1 Assembly Language riêng của nó. Bởi vậy, để để lập trình với Assembly cho 1 Processor nào đó, ta cũng cần Assembler tương ứng cho Processor đó. 2. Intel ASM và AT&T ASM và ARM Các bộ xử lý cùng kiến trúc thường ít có thay đổi về Assembly Language, tuy nhiên 2 kiến trúc khác nhau thì thường có Assembly Language khác nhau ARM : Hiện tại chưa tìm hiểu được. Nếu bỏ qua ARM, ta có thể chia ra làm 2 loại Assembly Language sau theo tiêu chí lệnh gợi nhớ, đó là Intel và AT&T. Về sự khác nhau của 2 loại này: Hầu hết sự khác biệt xuất hiện ở một dài định dạng cụ thể. Nhưng những điểm khác nhau chính giữa Intel và AT&T được đưa ra dưới đây: AT&T sử dụng $ để kí hiệu, còn Intel thì không. Vì thế, khi biểu diễn giá trị 4, AT&T sẽ sử dụng $4, còn Intel thì đơn giản viết 4. ...

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: ...

Đây là nội dung pick up từ manual của Buildroot. Nó mô tả khá rõ về /dev trong hệ thống Linux, cùng với các giải pháp dành cho hệ thống Embedded Linux. 6.2 /dev management Trên 1 hệ thống Linux, thư mục /dev chứa các file đặc biệt, được gọi là device files (hay các file thiết bị), cho phép ứng dụng phía user truy cập đến các thiết bị phần cứng mà Linux kernel quản lý. Nếu không có những file đặc biệt này, ứng dụng phía user không thể sử dụng được các thiết bị phần cứng, thậm chí chú có được Linux kernel nhận ra một cách đúng đắn đi chăng nữa. ...

Ta đã có bài giới thiệu về 4 Stage khi Compiling rồi. Đầu ra của Stage trước sẽ là đầu vào của Stage sau. Trong compile thông thường dạng $gcc -o HelloWorld HelloWorld.c Với câu lệnh trên,ta sẽ không thấy kết quả của 3 Stage đầu tiên. Để hiểu rõ hơn, chúng ta hãy thử thực hiện các Stage bằng tay xem liệu ta có thể tạo ra file chạy như câu lệnh compile trên hay không. ...

Gần đây, phải giải quyết giúp một vài vấn đề liên quan đến Cross-Compile. Có tìm hiểu kĩ một chú về Compiler, Linker, và Loader. Bài này xin nói về cơ bản về quá trình biên dịch một file source code (.c) sang dạng chạy được. Ví dụ: từ HelloWorld.c thành HelloWorld và chạy được như ví dụ dưới đây. HelloWorld.c #include int main() { print("Hello World \n"); return 0; } Kết quả chạy: ...

Gần đây, gặp một số vấn đề về Loader-Linker giữa môi trường build và môi trường chạy trong Cross-Compiling. Có thể bất kì chương nào trong Linux cũng vậy. Nhưng chỉ xét một chường trình được build bằng C thì một chương trình sẽ được chạy 2 cách dưới đây 1. Chương trình hoàn toàn là tĩnh Không có symbol nào cần phải được (resolved) trước khi chạy. Không yêu cầu bất cứ một thư viện run-time nào. Kernel cứ thế load vào, rồi nhảy đến vị trí của Program Entry là chạy. Có kích thước lớn Để build được nó thì các thư viện phụ thuộc khi build cũng phải có phiên bản static. Lấy ví dụ HelloWorld #include int main(int argc, char *args[]) { printf("Hello, Ajinomoto \n"); return 0; } Khi build tĩnh bằng (hầu như phải có -static) ...

Khi phát triển các ứng dụng trên Linux, nhúng Linux, mình hầu như cài đặt và sử dụng một máy ảo (tạo bằng VMWare hoặc VirtualBox). Cài trình biên dịch GCC lên đó. Hầu như mình có thể làm mọi việc trên môi trường máy ảo đó trừ quản lý source. Vì cty mình vẫn sử dụng SVN với Client là Tortoise. Linux cũng có rất nhiều công cụ tuơng tự Tortoise nhưng để tránh những vấn đề không cần thiết, có thể làm phiền người khác liên quan đến tương thích SVN, mình vẫn chọn quản lý bằng Tortoise trên Windows. ...