移植鴻蒙系統(tǒng)到STM32L476RG_NUCLEO開發(fā)板的一點小經(jīng)驗

小嵌 · 發(fā)表于 2020-11-12 15:56:35

移植鴻蒙系統(tǒng)到STM32L476RG_NUCLEO開發(fā)板的一點小經(jīng)驗,
本帖最后由死龍于 2020-11-12 14:51 編輯

https://gitee.com/walker2048/hmos_iot

復(fù)制代碼 目前移植STM32L476的相關(guān)代碼已上傳在gitee，有興趣的同學(xué)可以自行下載研究。

編譯命令為 python build.py stm32l476rg_nucleo

移植鴻蒙的建議：

一步一步來，別想一口吃成胖子，給自己定計劃。

多看源碼以及編譯日志，多想，多動手。

源碼既是文檔，別想著百度或者google能幫你直接解決問題。

修改完代碼后，完成了小部分功能的，也要及時提交git。

1、第一步肯定是創(chuàng)建廠商文件夾

   首先按移植LiteOS教程里的說明，使用CubeMX工具生成makefile格式的項目（包含了stm32l4xx標準hal庫和ll庫實現(xiàn)代碼及makefile），并把項目文件復(fù)制到vendor/st/stm32l4xx目錄里。

這就是2020-11-06日  dbbaf5f  這個提交所包含的內(nèi)容

然后在該目錄執(zhí)行命令  make > build.log，這樣一是測試代碼是否能正常編譯，二是可以把stm官方提供的makefile實際執(zhí)行指令信息存儲到build.log文件里，方便以后修改gn系統(tǒng)的編譯配置時做參考用。

2、第二步，配置編譯環(huán)境及組件。

   根據(jù)以往閱讀makefile和嵌入式開發(fā)經(jīng)驗，應(yīng)該先確定編譯工具鏈。不同硬件架構(gòu)，需要的編譯工具鏈并不一樣，哪怕是一個最簡單的helloworld，也沒辦法實現(xiàn)同一個bin文件，能在不同架構(gòu)的硬件上直接運行。目前鴻蒙2.0配置好的兩套編譯工具（主要是gcc），并不能完成stm32的編譯工作。

   打開build/lite/toolchain/目錄，復(fù)制gcc.gni文件的內(nèi)容到arm_none_eabi_gcc.gni，并將第14行的ohos_kernel_type （內(nèi)核類型）修改成liteos_m，并將15行的ohos_build_compiler_prefix 設(shè)置為正確的gcc工具前綴arm-none-eabi。其他內(nèi)容暫時沒動，然后根據(jù)其他開發(fā)板的設(shè)置，又復(fù)制粘貼了一遍各種配置，例如

build/lite/config/boards/stm32l476rg_nucleo.gni

復(fù)制代碼 等等配置先抄一遍hi3861的，期間各種嘗試使用編譯命令python build.py stm32l476rg_nucleo，直到不再提示找不到stm32l476rg_nucleo目標板，進入下一個確認工具鏈環(huán)節(jié)為止。

這一環(huán)節(jié)中，比較重要的應(yīng)該是build/lite/product/stm32l476rg_nucleo.json文件，該文件定義了目標板名稱，編譯工具鏈，內(nèi)核等等重要信息。

當編譯命令提示arm-none-eabi-gcc不是OHOS的編譯器時，我也楞了一會兒。翻了build目錄下各種配置也找不到對應(yīng)配置時，我就放棄找配置了。直接在VScode中全局搜索包含not OHOS compiler字段的文件，最終在build/lite/config.py的124行和158行找到了對應(yīng)判斷語句，并增加了arm-none-eabi-gcc的判斷語句。

隨后測試編譯時，又發(fā)現(xiàn)編譯腳本會針對ohos_kernel_type 進行各種優(yōu)化和設(shè)置。沒辦法，就只能搜索ohos_kernel_type == “l(fā)iteos_riscv“，并將對應(yīng)腳本一一修改

。涉及到的文件也很多，詳細請看gitee上的變更記錄。

最終各組件的配置判斷語句沒問題了，能順利進入到編譯狀態(tài)，出現(xiàn)類似以下信息了

=== start build ===
Done. Made 39 targets from 41 files in 648ms
ninja: Entering directory `/mnt/out/stm32l476rg_nucleo\“
[1/112] cross compiler obj/applications/sample/wifi-iot/app/demolink/helloworld.o
[2/112] AR libs/libdemolink.a

復(fù)制代碼 也就是說能出現(xiàn)[1/112]之類的，恭喜你，編譯配置已經(jīng)完成了80%了。期間還刪除了大量容易出現(xiàn)問題的組件，例如wifi功能等等一堆組件。

3、調(diào)整頭文件配置

   為了減少以后找文件找目錄頭疼，我在源碼目錄新建了一個include文件夾，并將疑似應(yīng)該從廠商目錄中提取出來的頭文件放在該目錄的hal目錄下，并將難以解決的頭文件錯誤組件去掉，不編譯對應(yīng)組件。

   最終編譯命令都順利通過了，只差最后一步生成elf和bin文件了。

4、根據(jù)原廠makefile修改和調(diào)整編譯細節(jié)

   重頭戲是此文件build/lite/toolchain/arm_none_eabi_gcc.gni

   查看原廠makefile的build.log文件，可以看出編譯過程為

   .c文件=>.o文件，然后.S文件=>.o文件，然后將所有的.o文件以及

STM32L476RGTx_FLASH.ld文件一起鏈接成elf文件。最后再由elf文件生成bin和hex。

   多次嘗試修改后，最終調(diào)整為以下內(nèi)容

template（“gcc_toolchain“） {
toolchain（target_name） {
assert（defined（invoker.cc）, “gcc toolchain must specify a \“cc\“ value“）
assert（defined（invoker.cxx）, “gcc toolchain must specify a \“cxx\“ value“）
assert（defined（invoker.ld）, “gcc toolchain must specify a \“l(fā)d\“ value“）
assert（defined（invoker.ar）, “gcc toolchain must specify a \“ar\“ value“）
assert（defined（invoker.as）, “clang toolchain must specify a \“as\“ value“）
assert（defined（invoker.cp）, “clang toolchain must specify a \“cp\“ value“）
ar = invoker.ar
as = invoker.as
cc = invoker.cc
cxx = invoker.cxx
ld = invoker.ld
cp = invoker.cp
need_strip = false
if（defined（invoker.strip）） {
strip = invoker.strip
need_strip = true
}
if （defined（invoker.extra_ldflags） && invoker.extra_ldflags != ““） {
extra_ldflags = ““
} else {
extra_ldflags = ““
}
tool（“cc“） {
command = “$cc -c {{cflags}} {{defines}} {{include_dirs}} {{cflags_c}} “ +
# “-MMD -MP -MF‘{{source_out_dir}}/{{source_name_part}}.d’ “ +
# “-Wa,-a,-ad,-alms={{source_out_dir}}/{{source_name_part}}.lst “ +
“{{source}} -o {{output}}“
depsformat = “gcc“
description = “cross compiler {{output}}“
outputs = [
“{{source_out_dir}}/{{source_name_part}}.o“,
]
}
tool（“cxx“） {
depfile = “{{output}}.d“
command = “$cxx -c {{cflags}} {{defines}} {{include_dirs}} {{cflags_c}} “ +
# “-MMD -MP -MF‘{{source_out_dir}}/{{source_name_part}}.d’ “ +
# “-Wa,-a,-ad,-alms={{source_out_dir}}/{{source_name_part}}.lst “ +
“{{source}} -o {{output}}“
depsformat = “gcc“
description = “CXX {{output}}“
outputs = [
“{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o“,
]
}
tool（“asm“） {
depfile = “{{output}}.d“
command = “$as -c {{cflags}} {{defines}} {{include_dirs}} {{asmflags}} {{source}} {{cflags_c}} “ +
“-o {{output}}“
depsformat = “gcc“
description = “cross compiler {{output}}“
outputs = [
“{{source_out_dir}}/{{source_name_part}}.o“
]
}
tool（“alink“） {
outfile = “{{output_dir}}/{{target_output_name}}{{output_extension}}“
rspfile = “{{output}}.rsp“
rspfile_content = “{{inputs}}“
command = “$ar cr {{output}} @\“$rspfile\““
description = “AR {{output}}“
outputs = [
outfile
]
default_output_dir = “{{root_out_dir}}/libs“
default_output_extension = “.a“
output_prefix = “l(fā)ib“
}
tool（“l(fā)ink“） {
outfile = “{{output_dir}}/bin/{{target_output_name}}.elf“
rspfile = “$outfile.rsp“
command = “$ld {{inputs}} {{ldflags}} $extra_ldflags -specs=nano.specs “ +
# set ld file patch in vendor path
“-lc -lm -lnosys {{libs}} -Wl,-Map={{target_output_name}}.map,--cref “ +
“-Wl,--gc-sections -o $outfile “
if（need_strip） {
command += “&& $cp -O binary -S $outfile {{output_dir}}/bin/{{target_output_name}}.bin“
}
description = “LINK $outfile“
default_output_dir = “{{root_out_dir}}“
rspfile_content = “{{inputs}}“
outputs = [
outfile
]
}
tool（“stamp“） {
if （host_os == “win“） {
command = “cmd /c type nul > \“{{output}}\““
} else {
command = “/usr/bin/touch {{output}}“
}
description = “STAMP {{output}}“
}
tool（“copy“） {
command = “$cp -O binary -S {{source}} {{output}}.bin && echo $strip“
description = “COPY {{source}} {{output}}“
}
}

復(fù)制代碼

同時在stm32l4xx/Src/BUILD.gn文件中添加ldflags，實現(xiàn)ld文件在廠商文件內(nèi)設(shè)置。

ldflags = [
“-T“,
“../../vendor/st/stm32l4xx/STM32L476RGTx_FLASH.ld“
]

復(fù)制代碼

最終，順利生成了elf文件，bin文件以及hex文件。

其實gn配置相對來說，命令行的提示，以及配置的可讀性都是相當不錯的。還是建議大家多動手，多看，多想。

移植鴻蒙系統(tǒng)到STM32L476RG_NUCLEO開發(fā)板的一點小經(jīng)驗

發(fā)表回復(fù)

精選推薦