9. Other available methods for kernel configuration include
4.2.5 Gở rối và mô phỏng
Mô phỏng và gở rối là hai công cụ thường được dùng để thử nghiệm các đoạn phần mềm quan trọng và khi kết hợp để thử nghiệm cả hai: phần cứng và phần mềm, ví dụ TĐKTB. Nói chung các đoạn mã phần mềm như vậy có ảnh hưởng lớn tới hoạt động hệ thống, đặc biệt khi liên quan tới thời gian thực.
§ Với phần mềm từ ngôn ngữ cấp cao, có thể chạy kiểm tra cả một phần lớn code mà không cần có phần cứng, thậm chí các code không liên quan tới I/O hay các tiện ích hệ thống (của HĐH), có thể chạy thử trên một máy khác (PC chẳn hạn). Cách làm này cho phép phát triển song song đồng thời cả phần cứng và phần mềm, mà khi hợp nhất đảm bảo hệ sẽ làm việc. Đối với các dữ liệu cho mô phỏng có thể nhận từ bàn phím hay tạo ra các bảng dữ liệu để chạy thử các xử lí, mà không cần có các hoạt động I/O thật sự. Tuy nhiên hạn chế của phương pháp này là ở chổ mô phỏng là sẽ chạy và dùng thư viện của HĐH trên máy thử chứ không phải trên môi trường của hệ đích. Còn nếu thư viện sử dụng là một phần của code sẽ chạy trên máy đích, thì việc sử code thư viện là cần thiết. Lí tưởng nhất là HĐH máy chạy mô phỏng giống như HĐH HTN đích, ví dụ dùng PC cài Linux chạy mô phỏng cho HTN sẽ chạy Linux. Hiện nay rất nhiều HTN sử dụng HĐH đích có nguồn gốc từ
258
UNIX/Linux (Android (cho rất nhiều thiết bị nhúng), Ubuntu, bada,,Firefox OS (project name: Boot to Gecko), Openmoko Linux, OPhone, MeeGo (from merger of Maemo &
Moblin), Mobilinux, MotoMagx, Qt Extended, Sailfish OS, Tizen (earlier called LiMo Platform), webOS, ipodlinux, Apple IOS, BusyBox (tập hợp các tiện ích của UNIX thu nhỏ), hay Microsoft Windows (Windows Embedded CE, Windows Phone OS), cho các HTN.
§ Mô phỏng mức thấp có các công cụ để chạy mô phỏng hoạt động của CPU, bộ nhớ và một số thiết bị ngoại vi đích, chạy băng ngôn ngữ máy (hợp ngữ). các mô phỏng này liên quan tới mô hình chương trình di với mô hình bộ nhớ với khả năng gỡ rối. cách mô phỏng cấp thấp này thường không cho các thực thi liên quan tới định thời, tức các code có rang buộc thời gian (cho hệ thời gian thực). Tuy nhiên đây là phương pháp thiết kế ít tốn kém khi có các dự ám HTN lớn và phức tạp.
§ Gỡ rối trên bo mạch, là cách gỡ rối trực tiếp trên phần cứng THN đích. Các nhà sản xuất luôn cài sẳn trong EPROM chương trình gõa rối (Debuger), hay một tập các khối thực thi (routine) có thể hợp nhất vào các ứng dụng (tương lai). Các công cụ như vậy tạo điều kiện thử nghiệm hệ thống rất nhanh và chuẩn xác. Các đoạn coe này thường có:
§ Khởi động CPU và các Chip khả trình trên bo mạch vào trạng thái ban đầu, hay chạy ở chế độ chờ với dấu nhắc (prompt) trên màn hình;
§ Người phát triển chạy Debuger, truy nhập vào các phần cứng qua lập trình đơn giản với các chức năng có sẳn, hay đoạn code nối với cổng truyền thông (COM port) với hệ phát triển đẻ tải xuống các phần mềm (HĐH, ứng dụng nhúng). Lần sau khi khởi động nguội bo mạch, CPU sẽ tìm trong bảng vector ngắt vector RESET có trong EPROM, khởi động bo, và chuyển điều khiển tử EPROM sang code trong RAM. Lưu ý là EPROM phải nằm ở vung địa chỉ phù hợp với địa chỉ đầu tiên sau khi RESET. Debuger cho phép truy nhập, theo dõi, thay đổi giá trị các thanh ghi của CPU, rất tiện cho gỡ rối code. Các giá trị thường biểu diễn ở dạng số hệ 16 (hexadecimal). Để tiện cho gỡ rối, khi lập trình cần tạo các bảng kí hiệu (symbol table, hay bảng các biến) khi dịch hay khi link phần mềm, tạo khả năng tra chéo giữa các nhãn và tên kí hiệu qui chiếu vào địa chỉ vật lí, từ đó theo dõi dễ dàng các giá trị cần quan sát ứng với các kí hiệu đó. Có thể theo dõi khi debug khi dùng với tệp hợp dịch ( listing file, là các tệp có phần mở rộng *.lst tạo ra sau khi dịch tệp hợp ngữ *.asm) thì rất dễ theo dõi. Debug mức thấp mang lại kết quả tin cậy về hoạt động của hệ đích, đặc biệt với các HTN khó chạy theo cách mô phỏng, hay mô phỏng không thực tế sát với hệ đích.
§ Gỡ rối ở mức tác vụ (task debug). Một số trường hợp gỡ rối mức thấp không nhiều hiệu quả tuy có thể debug cả một khối lệnh (hay routine) khi chọn điểm dừng (break point) code rồi quan sát kết quả. Thực tế cần debug cho cả các task và cách này cần debug ở mức độ HĐH, bởi các task khi chạy phụ thuộc nhiều vào bối cảnh thực thi code, nên điểm dừng chỉ có thể đặt qua (ở) các thông điệp, các sự kiện xuất hiện/kết thúc, các xử lí ngắt (bắt
259
đầu/kết thúc). Xử lí sự kiện có thể dùng cách lọc (bỏ/chấp nhận), ghi lại (trace) kết quả thực thi các thông tin về thời gian, suwrb dụng bộ nhớ, trạng thái tác vụ, giá trị các thanh ghi CPU để phán đoán, đánh giá các kết quả.
§ Gỡ rối kí hiệu (symbolic debug): Khi gỡ rối bằng ngôn ngữ bậc cao, như C, thay vì dùng tệp hợp dịch để xác định địa chi điểm dừng, gỡ rối tượng trưng cho phép dừng ở dòng lệnh hay tại tên của hàm. Cách tương tác như vậy hiệu quả hơn so với khi dùng hợp ngữ. Lí do sử dụng phương pháp này đó là cách mà gỡ rối tượng trung làm việc: có thể coi đây là kiểu đầu cuối của gỡ rối hợp ngữ khi phần mềm gỡ rối tra cứu (look-up) và chuyển đổi giữa cấu trúc của ngôn ngữ bậc cao và cách tính địa chỉ, nội dung của hợp ngữ. Chìa khóa của cách này là tạo ra bảng các kí hiệu (symbol) có khả năng cung cấp các thông tin tra chéo (look- up) mà gỡ rối cần đến. Một tệp dạng nhị phân liên quan tới object và tệp chứa địa chỉ tuyệt đối được ra, hoặc 2 tệp tách biệt. Khi gỡ rối kích hoạt tệp này. Nó sẽ tìm các thông tin kí tự để hiển thi các thông tin có nhiều ý nghĩa, và điểm dừng chương trình có thể đặt ở các câu lệnh cũng như địa chỉ cụ thể. Nói cách khác có thể gỡ rối theo giỏi code (trace) qua từng dòng lệnh, hay từng lệnh CPU. Có chút vấn đề xảy ra là: bảng kí hiệu sẽ lớn, cần nhiều bộ nhớ, kích thước tệp cũng lớn theo. Điều này sẽ rắc rối khi xây dựng ừn dụng cho một HĐH mới. Lỗi sẽ xuất hiện khi link là ‘bảng kí hiệu bị tràn (symbol table overflow error). Có thể xử lí bằng cách chặn (dừng) gỡ rối kí hiệu hay cấp thêm bộ nhóe cho trình liên kết (linker). Có thể còn có nhiều mẹo hơn khi gỡ rối !
§ Tối ưu code: tối ưu code có thể thực hiện vào lúc biên dịch mã nguồn với tùy chọn đặt với thông số tối ưu ở dòng lệnh. Khi dịch chương trình dịch sẽ kiểm tra code, thay đổi (code, trình tự gọi code …) để tăng hiệu quả thực thi mà không làm thay đôỉ tư duy logic của chương trình. Có nhiều cách, tuy nhiên có hai cách phổ biến sau đây: gỡ bỏ hay thêm hay thay đổi code. Chương trình dịch có thể boỏ ài biến, hay các đoạn code thực thi (routine) không bao giờ sử dụng hay trả lại bất kì hàm chức năng nào. Các vòng lặp cũng cần tối ưu để bỏ đi các trễ rẻ nhánh (ở các chương trình lớn). Đoạn code thực thi dấu phẩy động có thể thay vào bằng các dòng lệnh dấu phẩy động trực tiếp. kết quử cuối cùng có thể khác so với tệp *.lst trước đó, tương tự bảng các kí hiệu (symbol table) cũng có thay đổi không như hoài vọng từ mã nguồn. Tuy nhiên cách tối ưu này cũng không hẳn là đạt yêu cầu, bởi như trình bày, có thể một vài biến bị loại trừ, vòng lặp hay hàm delay có thể sẽ bị thay bằng NOP đơn giản. Hiệu quả thời gian thực thi có thể nhanh, nhưng kết quả tính toán thì cần thẩm định ! Hãy thận trọng với các đoạn code liên quan tới I/O và liên quan tới ánh xạ I/O vào bộ nhớ, tối ưu code có thể xẩy ra lỗi ! Để chắc chắn và thẩm định lại code, hãy so sánh hai kết quả thể hiện ở các têp *.lst sau khi dịch có tối ưu và không tối ưu !
§ Xray (Soi tìm lỗi kiểu chụp X quang): Gỡ rối phần mềm như mô tả có vẽ nhiều bước, tuy nhiên cũng tồn tại phần mềm mang đặc điểm hợp nhất cho gỡ rối. Đó là phần mềm của công ty Microtec có tên Xray. Xray là tập các công cụ hổ trợ gỡ rối hợp nhất của compiler, công cụ debuger liên kết với emulator, hổ trợ gỡ rối tới mức tác vụ trên bo mạch.
260 Xray structure:
Hình 4.19 Các loại công cụ hổ trợ gở rối
261
Hình 4.20 Kết quả hiển thị của gở rối
262
Hình 4.21 Liên kết giữ hệ phát triển và hệ đích đang được gở rối
§ Hệ phát triển-HPT (development system): Một giải pháp khác để phát triển phần mềm cho HTN là sử dụng HĐH đích là công cụ phát triển ngay trên bo mạch hay trên một máy tính khác tương tự. Cách này là cách truyền thống trước khi có các PC giá rẻ kết hợp phần mềm dịch chéo (cross-compilation) hợp nhất trên đó. Thuận lợi khi dùng HPT là code tạo ra chính là code cho hệ đích, kể cả các thư viện động, không có thay đổi. Phần mềm đích có thể thử nghiệm trên HPT trước khi tải xuống hệ đích. HPT có HĐH đầy đủ và có sẳn công cụ gỡ rối mà công cụ này không có trên hệ đích. Tuy nhiên cũng có vài điểm cần lưu ý:
§ Chức năng dấu phẩy động và quản lí bộ nhớ (Floating point and memory management).
Hai thành phần này có trên HPT, nhưng hệ đích không có. Có nghĩa là code tạo ra trên HPT sẽ không chạy trên hệ đích, do đó cần viết lại các code này và liên kết vào code đích.
Ngược lại code mới này có thể không chạy trên HPT, lí do là hệ mô phỏng.
§ Kỉ thuật mô phỏng (Emulation): Một trong các kỉ thuật mô phỏng là In-circuit emulation (ICE) dùng để chạy mô phỏng một CPU trong quá trinh thiết kế HTN. ICE cho ta một ‘cửa sổ” để tương tác với hệ đích. Thông thường phần mềm này sẽ nối vào đế cắm của CPU hệ đích (bo không có CPU!) qua một thiết bị hổ trợ (cổng JTAG-Joint Test Action Group hay BDM- Background Debug Mode), dùng phần mềm mô phỏng CPU, lập trình và chạy chương trình. Hệ chủ có thể là một máy Analyzer logic với nhiều đầu tín hiệu để ghi nhớ các giá trịn trên BUS của CPU. Đây là công cụ mạnh và khá đắt, nhưng rất hiệu quả để phát triển HTN. Ngoài ra còn có một thiết bị khác kết hợp với Analyzer logic với các đầu cặp (probe) vào bất kì tín hiệu nào trên bo mạch để kiểm tra, gỡ rối, đó là OnCE (on-chip emulation).