前一段時間解決的乙個問題，看起來是個小問題，實際解決這個問題卻花了乙個星期的晚上休息時間，記錄分享一下。
問題描述：
linux核心配置中nls（native language support）已經選擇了預設語言配置為utf8，幷包含一些其他常用語言的編碼，但是在securecrt的telnet和串列埠終端顯示中文檔名均為亂碼。
解決過程：
1.剛開始以為是簡單的編碼不匹配的問題，修改securecrt中的傳輸編碼方式從預設變為utf8，中文不再亂碼，但變成了問號，「??????」；
2.因為中文目錄是在掛載的sd卡中的（居然沒有嘗試一下網路掛載或者其他的方式下中文是否亂碼，汗），懷疑是掛載sd卡方式不對。網上解答全部都是說，編譯核心的時候fat檔案系統的codepage和isochaset配置對，掛載時選擇vfat，-o命令選擇codepage和isocharset匹配就好了，具體的命令是，mount -t vfat -o codepage=936,iocharset=utf8 /dev/mmcblk0p1 /home/。然後接下來幾天晚上就一直在鼓搗這些東西，無解；
3.有一天忽然找到一篇博文，說是busybox的原因，高版本的busybox取消了中文支援，想不到還有這茬。進入busybox配置，發現已經勾選了unicode的支援。如此按博文提示，還需要修改busybox中的另外兩個檔案printable_string.c以及unicode.c，把大於0x7f替換為問號的這個選擇條件去掉才行。看了一下原始碼，覺得改的地方都是不勾unicode才需要改的……不過還是試一下吧，重新配置編譯busybox，替換根檔案系統，不過問題依舊……
4.既然上面的提示中已經發現不勾選unicode支援中文的方式，那就先試一下不支援unicode顯示中文的方式吧，修改printable_string.c以及unicode.c，重新編譯，燒寫啟動裝置，發現去掉unicode果然中文支援了，不再顯示問號；
5.但是這樣子草草了事明顯是不行的，那又是為什麼勾選unicode支援後中文變問號呢？那就只能讀原始碼了，還好範圍也可以接受，問題應該就出在修改的兩個檔案裡面。
6.last_supported_wchar，通過busybox原始碼，可以發現有這麼乙個判斷if (wc > config_last_supported_wchar)，而在subset的地方，wc被賦值為問號，這下問題就明朗了，明顯是這個last_supported_wchar搞的鬼；
7.檢視busybox配置，發現這個巨集定義表示的是range of supported unicode characters，預設填的值才700多，而中文在unicode中的位置查了一下最高到u+2fa1d，隨便給這個值改了乙個大於2fa1d的值，重新編譯燒寫根檔案系統，中文顯示成功！
走了不少彎路，好在最後問題是解決了！最後記錄一下，busybox版本是1.19.4！
嵌入式ARM LINUX系統搭建vlan服務
1.核心移植支援vlan 配置編譯即可 networking support networking options 802.1q vlan support 編譯為模組載入 gvrp garp vlan registration protocol support 不選，即不編譯 燒錄核心後，系統啟動，...
嵌入式 ARM Linux啟動流程
bootloader 翻譯為 第一階段 引導裝入程式 bootstrap loader 翻譯為 第二階段引導裝入程式 bootloader不用多解釋都能理解 上電後執行的第乙個程式，它絕對不會依賴核心。比如uboot vivi bootstrap，第二階段引導裝入程式，屬於核心 沒有被編譯進vmli...
ARM Linux與嵌入式開發
arm linux開發與mcu開發有何不同？針對arm linux程式的開發，主要分為三類 應用程式開發 驅動程式開發 系統核心開發。linux核心與驅動 會51嗎？會c嗎？如bai果不會的話就有點難du度哦！會的話就學起來稍微輕zhi松一點，只dao是輕鬆一點。學arm肯定要先看彙編指令的，等指令...