Basic

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.

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.

Đâ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ý.

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.

PER là phương thức biểu diễn dữ liệu ngắn gọn và xúc tích nhất có thể của ASN.1. Thay vì sử dụng TLV như BER, PER sử dụng Preamble (diễn cho nhiều hoặc trạng thái bị lược bỏ của một dữ liệu bên trong), giá trị kích thước(cũng có thể bị lược bỏ), giá trị (cũng có thể bị lược bỏ), hay gọi là PLV. Đơn vị biểu diễn của PER không phải Octet mà là Bit.

Khi sử dụng BER để hiện thực dữ liêu, ta thấy rằng có khá nhiều chỗ tùy ý. Tức là cùng một thông tin có nhiều cách biểu diễn khác nhau. Khi sử dụng với trường hợp chữ kí Số, phát sinh ra nhiều vấn đề. Để giải quyết những vấn đề đó, người ta thêm ràng buộc vào BER, và tạo ra CER và DER. Sự khác nhau chủ yếu giữa CER và DER là về biểu diễn trường độ dài.

Tiếp tục về ASN.1. Như bài đầu tiên, ASN.1 tách biệt phần định nghĩa dữ liệu (các file định nghĩa) với phần hiện thực dữ liệu (mỗi trường được biểu diễn bằng mấy byte, mấy bit, etc) Ta sẽ tiếp tục nói về hiện thực dữ liệu. Các phương thức để hiện thực dữ liệu gồm có: BER, CER/DER, và PER. Trong đó: BER : Basic Encoding Rules CER/DER : Canonical Encoding Rules/Distinguished Encoding Rules

Tiếp theo loạt bài về ASN.1, bài này sẽ “dịch” tài liệu của anh Isida So nói về cú pháp cơ bản của ASN.1. Việc đầu tiên khi ứng dụng ASN.1 hoặc thiết kế một giao thức mới là viết định nghĩa cho các kiểu dữ liệu có thể được sử dụng. ASN.1 là một ngôn ngữ vì thế, cũng giống với C, nó có các kiểu cơ bản và các cơ chế cho phép mở rộng để định nghĩa thêm các kiểu mới.

Mình thấy ASN.1 khá quan trọng nhất là trong thiết kế giao thức trao đổi dữ liệu giữa các thiết bị tính toán, đặc biệt là các thiết bị tài nguyên nhỏ. Google tiếng Việt thấy khá ít thông tin về ASN.1. Mình dự định sẽ tìm hiểu thêm một chút về ASN.1 và làm loại bài viết về nó. Nội dung bài này sẽ giới thiệu sơ qua về ASN.

Đây là một chủ đề hay, có rất nhiều resource bằng tiếng Việt khá dễ hiểu rồi. Bài này chỉ mô tả ngắn gọn một chút cùng với vài ví dụ thực nghiệm để hiểu các khái niệm về cơ bản về Data Structure Aligment. Giả sử ta có một cấu trúc sau: #include <stdint.h> typedef struct { uin8_t mem1; uin8_t mem2; uin32_t mem3; }ST_FOOL_1; typedef struct { uin8_t mem1; uin8_t mem2; uin8_t mem3; uin8_t mem4; uin8_t mem5; }ST_FOOL_2; Cấu trúc ST_FOOL_1 sẽ được miêu tả trong 6 byte?

Trong bài số 02, ta đã nói đến những việc mà GDB có thể giúp chúng ta. Về cơ bản GDB, có thể chạy để debug mọi chương trình, tuy nhiên nếu không muốn càng debug càng rối thì ta nên sử dụng tham số -g khi biên dịch để giúp quá trình debug xác định được vị trí mỗi đoạn binary trong source ban đầu. 0. Source code Trong bài này, ta hãy cùng xem cách sử dụng thực tế sẽ như thế nào.

Khi sử dụng GDB để debug 1 chương trình thì chương trình đó gọi là target program. Khi nói về vị trí của GDB dùng để debug và target program, ta sẽ có 2 cách trường hợp sử dụng sau: GDB và target program cùng ở 1 máy : Thường sử dụng với chính các chương trình được dev, rồi build, rồi chạy trên máy đó. Đây là trường hợp chúng ta hay thấy nhất, đó là khi phát triển các app desktop.

Trước khi nói về chủ đề chính là “GDB có thể làm gì”. GDB hay những phần mềm như GDB được viết ra để giải quyết vấn đề gì. 1. Phầm mềm Debugger sinh ra giải quyết cái gì? Phần mềm thực sự được tạo ra ở bước implementation, nó hiện thực những nội dung được mô tả trong thiết kế. Vì con người viết code tạo ra phần mềm, mà con người không phải lúc nào cũng luôn làm đúng như những gì họ đã nghĩ, đã ý định, đã thiết kế.

Đợt này ngồi Unit Test nhiều quá, mệt!!!. Mà đã mệt, sinh ra chán để tiếp tục được thì nhất phải có gì hay ho thỉnh thoảng ngó sang tí cho đỡ chán. それはアカン！！！！ Cách đặt mục tiêu để viết, dịch khá hiệu quả đối với “siêu lười” như mình, loạt về USB Basic dù nội dung chắc nhiều lỗi những ít ra nó cũng hoàn thành. Vâng, mục tiêu lần này sẽ viết một loạt bài về cách sử dụng GDB (GNU Debugger) từ cài đặt, cách sử dụng dòng lệnh đến các IDE (Eclipse hoặc VS Studio).

AWK : 1 trong 3 tool (cùng với grep và sed) mạnh dùng xử lý chuỗi, xuất hiện ban đầu ở Unix, và được mặc định có trong bất cứ bản phân phối Linux nào. Sau một hồi tìm hiểu awk trên TutorialPoint. awk là một một tool để xử lý một chuỗi, đầu vào có thể là file, là output của một câu lệnh khác. Đơn vị xử lý là dòng, tức là nó đọc vào từng dòng text từ dữ liệu đầu vào rồi thực hiện các xử lý tương ứng.

Patch, hay người ta vẫn gọi là các bản vá, víu gì đó. Cũng thấy khái niệm này từ lâu rồi. Nhưng chưa bao giờ phát sinh nhu cầu sử dụng vì đa số các dự án mình từng làm đều dùng Server SVN tập trung. Mọi thay đổi đều có quản lý chặt chẽ, cũng ít khi rẽ quá nhiều nhánh (branch). Gần đây, bắt buộc phải nghĩ đến việc sử dụng 2 tool này vì phải update source trên máy thật (một board mạch) chỉ hỗ trợ truyền Serial.

Gần đây, khi tìm hiểu cách cài đặt driver cho USB Wifi, mình có tìm hiểu thêm về quá trình tạo nhân Linux. Đặc biệt, việc thiết lập cấu hình trước khi build tạo ảnh của kernel. Mình thấy ngoài Driver, tức là thành phần trung gian giữa ứng dụng và phần cứng, còn có 1 khái niệm nữa. Đó là Firmware. Bài này sẽ dịch lại trang, để hiểu qua về Firmware trong Linux Kernel.

Trong quá trình tìm cách cài đặt driver cho bản build Raspberry PI sử dụng Yocto, mình có tìm hiểu driver trong Linux và tìm được cuốn sách Linux in A Nutshell (link tại đây ) của pro này. Chương 7, chương mà tác giả đặc biệt “tự hào”, nói về Customize một Linux Kernel. Trong chương này, tác giả cũng nói đến việc xác định các driver đang được sử dụng trên hệ thống hiện tại.