hubris
sidecar release
Hubris는 신뢰성 요구 사항이있는 심하게 매립 된 시스템을 위해 설계된 마이크로 컨트롤러 운영 환경입니다. 그 설계는 처음에 RFD41에서 제안되었지만 그 이후로 상당히 진화했습니다.
개발자 문서는 doc/ Directory의 Asciidoc에 있습니다. GitHub 페이지를 통해 렌더링되며 https://oxidecomputer.github.io/hubris에서 제공됩니다.
리포는 다음과 같이 배치됩니다.
app/ 는 응용 프로그램을위한 최상위 바이너리 상자가 살고있는 곳입니다. 예를 들어 app/gimlet 에는 Gimlet 용 펌웨어 상자가 포함되어 있습니다. 일반적으로, 무언가에 대한 이미지를 만들고 싶다면 여기를보십시오.
build/ 빌드 시스템 및 지원 상자를 포함합니다.
chip/ 에는 주변 정의가 포함되어 있으며 개별 마이크로 컨트롤러에 대한 지원 파일을 디버깅합니다.
doc/ 개발자 문서가 포함되어 있습니다.
drv/ 에는 드라이버가 포함되어 있으며 간단한 드라이버 LIB 상자 및 본격적인 서버 빈 상자가 혼합되어 있습니다. 현재 규칙은 drv/SYSTEM-DEVICE SYSTEM 의 장치 DEVICE ( SYSTEM 이 일반적으로 SOC 이름 인 경우) 인 반면 drv/SYSTEM-DEVICE-server 서버 빈 상자라는 것입니다.
idl/ 우상으로 작성된 인터페이스 정의를 포함합니다
lib/ 우리가 쓴 다양한 유틸리티 라이브러리를 포함합니다. 다른 디렉토리 중 하나에 맞지 않는 재사용 가능한 상자를 만들어야한다면 아마 여기에 속합니다.
stage0/ 주로 LPC55의 부트 로더/ 하이포이저입니다.
가짜 인증서 및 프로그래머 펌웨어 이미지와 같은 일부 인터페이스 및 프로그래밍 지원 파일을 support/ 포함합니다.
sys/ 에는 Hubris의 "시스템"비트, 즉 커널 ( sys/kern ), ABI ( sys/abi )를 정의하는 공유 상자 및 작업 ( sys/userlib )에서 사용하는 사용자 라이브러리가 포함됩니다.
task/ 운전자가 아닌 재사용 가능한 작업이 포함됩니다. task 에 사는 것과 drv/something-server 에서 사는 것의 구별은 모호합니다. 당신의 판단을 사용하십시오.
test/ 에는 다양한 보드를위한 테스트 프레임 워크 및 이진 상자가 포함되어 있습니다.
website/ Hubris 웹 사이트의 소스 코드가 포함되어 있습니다
우리는 현재 Linux 및 Windows를 1 단계 플랫폼으로 지원합니다. MACOS는 산화 직원이 매일 사용하지만 CI에서는 테스트되지 않습니다. 빌드는 아마도 일루모스에서도 작동합니다. 누군가가 일루모스 또는 MACOS를위한 지속적인 빌드를 유지하기 위해 노력하고 싶다면 도움을 좋아합니다.
검토를 위해 변경 사항을 제출하려면 포크의 지점에 밀어 넣고 해당 지점을 master 로 병합하기위한 풀 요청을 제출하십시오. 자세한 내용은 CONTRIBUTING.md 참조하십시오.
당신은 필요할 것입니다 :
rustup 기반 도구 체인 설치. rustup 처음 구축을 시도 할 때 고정 된 도구 체인 버전과 교차 컴파일 대상을 자동으로 설치해야합니다.
openocd (이상적으로 0.11) 또는 (LPC55를 사용하는 경우) pyocd (0.27 이상). OpenOCD의 0.10 방출은 Stlink v3을 선행합니다. 사람들은 0.10 이후 다양한 시스템 패키지 관리자가 제공하는 0.11 Pre Builds를 사용하고 있지만 약간의 성공을 거두고 있지만 시스템이 0.11을 포장하지 않으면 아직 패배하지 않습니다. MacOS에서 Homebrew를 사용하여 OpenOCD를 설치하려면 brew install --head openocd 사용하여 최신 바이너리 릴리스를 사용하지 않고 기본 지점의 팁을 구축해야합니다. 소스에서 빌드 해야하는 경우 여기에서 OpenOCD v0.11.0을 찾을 수 있습니다. ./configure 실행할 때 ST-Link Programmer 활성화되어 있는지 확인하십시오 (기본값이어야 함).
Libusb, 일반적으로 시스템 패키지 관리자에서 libusb-1.0.0 이상으로 발견되었습니다.
libfdti1, libftdi1-dev 또는 이와 유사한 것으로 밝혀졌다.
GDB를 실행하는 경우 arm-none-eabi-gdb 설치해야합니다. 이것은 일반적으로 arm-none-eabi-gdb 또는 gdb-multiarch 와 같은 패키지 이름을 가진 시스템 패키지 관리자의 것입니다. MACOS 사용자는 brew install --cask gcc-arm-embedded 실행하여 공식 팔 바이너리를 설치할 수 있습니다.
Hubris Debugger, 겸손. cargo install 이 저장소의 루트에있는 rust-toolchain.toml 파일과 이상하게 상호 작용합니다. 겸손을 설치하기 위해 다음 명령 verbatim을 실행하는 경우 다른 디렉토리에서 그렇게하십시오.
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo install cargo-readme 의존성으로 cargo-readme 필요합니다OpenOCD를 설치하는 세 가지 대안적인 방법이 있습니다.
openocd 의 출처를 얻거나 비공식 바이너리를 얻으려면 여기를 참조하십시오.
또는 초콜릿으로 설치할 수 있습니다.
> choco install openocd 마지막으로 Scoop으로 openocd 설치할 수 있습니다.
> scoop bucket add extras
> scoop install openocd 참고 : scoop 통해 설치 한 openocd 일부 사용자에게 문제가있는 것으로 입증되었습니다. 문제가 발생하면 choco 통해 또는 소스에서 설치하십시오 (위 참조).
ST-Link 프로그래머를 사용하려면이 드라이버를 설치해야 할 것입니다.
Hubris를 구축하고 실행할 필요는 없지만 직렬 링크를 통해 통신하려면 (그리고 터미널에서 지원하지 않으면) Putty를 사용하고 싶을 것입니다. 이 안내서는 방법을 설명하는 데 도움이됩니다.
우리는 cargo build 나 cargo run 직접 사용하지 않습니다. 우리는 복잡한 멀티 아키텍처 빌드를 가지고 있으며, 그 이상입니다.
대신,이 리포에는 사용자 정의 빌드 명령을 네임 스페이스하는 xtask 라는화물 확장이 포함되어 있습니다.
cargo xtask dist TOMLFILE Toml 파일에서 설명한 응용 프로그램의 배포 이미지를 빌드합니다.
cargo xtask dist app/demo-stm32f4-discovery/app.toml -STM32F4-DISCOVERYcargo xtask dist app/demo-stm32f4-discovery/app-f3.toml -STM32F3-DISCOVERYcargo xtask dist app/lpc55xpresso/app.toml -LPCXPRESSO55S69cargo xtask dist app/demo-stm32g0-nucleo/app-g031.toml -STM32G031-NUCLEOcargo xtask dist app/demo-stm32g0-nucleo/app-g070.toml -STM32G070-NUCLEOcargo xtask dist app/demo-stm32h7-nucleo/app-h743.toml -Nucleo-IH743ZI2cargo xtask dist app/demo-stm32h7-nucleo/app-h753.toml -Nucleo-IH753ZIcargo xtask dist app/gemini-bu/app.toml -Gemini Bringup 보드 전체 이미지 빌드는 10 초 이상이 걸릴 수 있으므로 변경 사항에 따라 작업이나 커널을 반복 할 때 개별적으로 빌드하고 싶을 것입니다. 이것이 cargo xtask build 의 것입니다.
예를 들어, 이미지 중 하나에 구축 될 때와 같이 task-ping 구축하려면 나머지 데모를 만들지 않고 실행하십시오.
$ cargo xtask build app/gimletlet/app.toml ping clippy 달리기 cargo xtask clippy 부계 명령은 특정 이미지의 맥락에서 하나 이상의 작업에 대해 clippy 실행하는 데 사용될 수 있습니다.
$ cargo xtask clippy app/gimletlet/app.toml ping pong rust-analyzer 와 통합 Hubris 빌드 시스템은 rust-analyzer 와 함께 작동하지 않습니다.
그러나 cargo xtask lsp 도움을주기 위해 여기에 있습니다. 논쟁으로 Rust 파일을 사용하고 rust-analyzer 설정하는 방법에 대한 JSON에 인코딩 된 구성을 반환합니다.
이 데이터를 사용하려면 일부 편집기 구성이 필요합니다!
(우리는 아직 플러그인을 만들지 않았지만 확실히 가능할 것입니다)
Neovim 및 rust-tools 사용하면 다음은 다음과 같습니다.
-- monkeypatch rust-tools to correctly detect our custom rust-analyzer
require ' rust-tools.utils.utils ' . is_ra_server = function ( client )
local name = client . name
local target = " rust_analyzer "
return string.sub ( client . name , 1 , string.len ( target )) == target
or client . name == " rust_analyzer-standalone "
end
-- Configure LSP through rust-tools.nvim plugin, with lots of bonus
-- content for Hubris compatibility
local cache = {}
local clients = {}
require ' rust-tools ' . setup {
tools = { -- rust-tools options
autoSetHints = true ,
inlay_hints = {
show_parameter_hints = false ,
parameter_hints_prefix = " " ,
other_hints_prefix = " " ,
-- do other configuration here as desired
},
},
server = {
on_new_config = function ( new_config , new_root_dir )
local bufnr = vim . api . nvim_get_current_buf ()
local bufname = vim . api . nvim_buf_get_name ( bufnr )
local dir = new_config . root_dir ()
if string.find ( dir , " hubris " ) then
-- Run `xtask lsp` for the target file, which gives us a JSON
-- dictionary with bonus configuration.
local prev_cwd = vim . fn . getcwd ()
vim . cmd ( " cd " .. dir )
local cmd = dir .. " /target/debug/xtask lsp "
-- Notify `xtask lsp` of existing clients in the CLI invocation,
-- so it can check against them first (which would mean a faster
-- attach)
for _ , v in pairs ( clients ) do
local c = vim . fn . escape ( vim . json . encode ( v ), ' " ' )
cmd = cmd .. ' -c" ' .. c .. ' " '
end
local handle = io.popen ( cmd .. bufname )
handle : flush ()
local result = handle : read ( " *a " )
handle : close ()
vim . cmd ( " cd " .. prev_cwd )
-- If `xtask` doesn't know about `lsp`, then it will print an error to
-- stderr and return nothing on stdout.
if result == " " then
vim . notify ( " recompile `xtask` for `lsp` support " , vim . log . levels . WARN )
end
-- If the given file should be handled with special care, then
-- we give the rust-analyzer client a custom name (to prevent
-- multiple buffers from attaching to it), then cache the JSON in
-- a local variable for use in `on_attach`
local json = vim . json . decode ( result )
if json [ " Ok " ] ~= nil then
new_config . name = " rust_analyzer_ " .. json . Ok . hash
cache [ bufnr ] = json
table.insert ( clients , { toml = json . Ok . app , task = json . Ok . task })
else
-- TODO:
-- vim.notify(vim.inspect(json.Err), vim.log.levels.ERROR)
end
end
end ,
on_attach = function ( client , bufnr )
local json = cache [ bufnr ]
if json ~= nil then
local config = vim . deepcopy ( client . config )
local ra = config . settings [ " rust-analyzer " ]
-- Do rust-analyzer builds in a separate folder to avoid blocking
-- the main build with a file lock.
table.insert ( json . Ok . buildOverrideCommand , " --target-dir " )
table.insert ( json . Ok . buildOverrideCommand , " target/rust-analyzer " )
ra . cargo = {
extraEnv = json . Ok . extraEnv ,
features = json . Ok . features ,
noDefaultFeatures = true ,
target = json . Ok . target ,
buildScripts = {
overrideCommand = json . Ok . buildOverrideCommand ,
},
}
ra . check = {
overrideCommand = json . Ok . buildOverrideCommand ,
}
config . lspinfo = function ()
return { " Hubris app: " .. json . Ok . app ,
" Hubris task: " .. json . Ok . task }
end
client . config = config
end
end ,
settings = {
[ " rust-analyzer " ] = {
-- enable clippy on save
checkOnSave = {
command = " clippy " ,
extraArgs = { ' --target-dir ' , ' target/rust-analyzer ' },
},
diagnostics = {
disabled = { " inactive-code " },
},
}
}
},
}
end 새 LSP 구성이 생성되면 ( on_new_config ) 대상 파일에서 cargo xtask lsp 실행합니다. JSON 구성에는 구성의 해시가 포함됩니다. 우리는 해시를 사용하여 rust_analyzer 에서 rust_analyzer_$HASH 까지 클라이언트의 이름을 수정합니다. 이로 인해 Neovim은 일반적으로 클라이언트 이름과 작업 공간 루트 디렉토리에 의해 중복 제거되는 기존 클라이언트를 재사용하려고 시도하지 않습니다. Hubris에서는 여러 클라이언트가 동일한 작업 공간 루트와 공존하기를 원하므로 다른 이름이 필요합니다. 그런 다음 나머지 구성을 로컬 변수 ( cache )에 보관 하고이 클라이언트의 존재를 clients 에 기록합니다.
LSP에 부착 할 때 cache 에서 구성을 빼내려고합니다. 하나가 존재한다면, 우리는 우리가 Hubris 버퍼를 다루고 있다는 것을 알고 있습니다. 구성의 관련 부분에 대해 복사하십시오.
이것은 당신을 위해 xtask 컴파일하지 않습니다. target/debug/xtask 에 이미 존재한다고 가정합니다. Hubris를 정기적으로 사용하고 새 파일을 열 때 상당한 시간을 절약하는 경우에는 사실입니다.
자신만의 작업을 만들려면 가장 쉬운 방법은 다음과 같습니다.
task/template 새 이름으로 복사하십시오.Cargo.toml 을 편집하십시오.Cargo.toml 에서 작업 공간 멤버 목록에 추가하십시오.app.toml 파일을 편집하여 시스템 이미지에 추가하십시오.cargo xtask build 실행하여 컴파일하십시오. 메모리 매핑 된 주변 장치를 사용하지 않는 작은 작업을위한 일반적인 app.toml 항목
[ tasks . name_for_task_in_this_image ]
name = " my-task-target-name "
priority = 1
requires = { flash = 1024 , ram = 1024 }
start = true 다양한 작업의 관계와 우선 순위를 보여주는 그래프를 생성 할 수 있습니다. 결과 파일은 GraphViz의 dot 형식입니다. Dot 소스는 Asciidoctor 소스에 포함되거나 다양한 형식으로 렌더링 될 수 있습니다.
우분투에서 gimletlet 용 SVG 그래프를 작성하고 보려면 graphviz 패키지가 설치되어 있는지 확인하십시오. 그런 다음 그래프를 생성합니다.
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svg모든 그래프를 생성하기위한 BASH 명령 :
APPS=( $(find app -name '*.toml' ! -name Cargo.toml) )
for app in "${APPS[@]}"
do
out=$(basename ${app////_} .toml).dot
svg=$(basename $out .dot).svg
cargo xtask graph -o $out $app
dot -Tsvg $out > $svg
done
first="${APPS[0]}"
out="$(basename ${first////_} .toml).dot"
svg="$(basename $out .dot).svg"
xdg-open "${svg}" eog 기본 뷰어 인 경우 디렉토리에서 첫 번째 SVG를 열면 동일한 창을 사용하여 사용 가능한 모든 그래프를 사이클링 할 수 있습니다.
Hubris는 디버거 인 겸손과 밀접하게 결합되어 있으며, 이는 암시 적으로 ( cargo xtask flash 에서) 또는 명시 적으로 ( cargo xtask humility 에서) 아래 명령에 사용됩니다.
$PATH 에서 humility 바이너리를 사용할 수없는 경우 HUBRIS_HUMILITY_PATH 환경 변수를 사용하여 이진 경로를 제공 할 수 있습니다.
Hubris 아카이브 내의 이미지는 cargo xtask flash 실행하고 적절한 TOML 파일을 지정하여 대상 보드에 직접 플래시 할 수 있습니다. 이것은 cargo xtask dist 실행 한 다음 결과 빌드 아카이브를 humility flash 로 전달합니다. humility OpenOCD 또는 PYOCD를 호출하여 이미지를 플래시합니다. 정확한 호출은 보드에 따라 다르며 빌드 아카이브에 인코딩됩니다.
cargo xtask flash app/lpc55xpresso/app.tomlcargo xtask flash app/demo-stm32f4-discovery/app.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h743.tomlcargo xtask flash app/demo-stm32h7-nucleo/app-h753.tomlcargo xtask flash app/gemini-bu/app.toml 겸손은 직접 연결된 보드에 아카이브를 지정하여 또는 덤프를 지정하여 사후 모임을 지정하여 현장에서 실행됩니다. 개발을위한 편의성으로, STM32F4 Discovery Board가 직접 첨부 된 기계의 적절한 TOML을 지정함으로써 겸손도 현장에서 실행할 수 있습니다.
$ cargo xtask humility app/demo-stm32f4-discovery/app.toml -- tasks
Finished dev [optimized + debuginfo] target(s) in 0.17s
Running `target/debug/xtask humility demo/app.toml -- tasks`
humility: attached via ST-Link
ID ADDR TASK GEN STATE
0 20000108 jefe 0 Healthy(InRecv(None))
1 20000178 rcc_driver 0 Healthy(InRecv(None))
2 200001e8 usart_driver 0 Healthy(InRecv(None))
3 20000258 user_leds 0 Healthy(Runnable) <-
4 200002c8 ping 48 Healthy(Runnable)
5 20000338 pong 0 Healthy(InRecv(None))
6 200003a8 idle 0 Healthy(Runnable) humility 에는 arm-none-eabi-gdb 사용하여 실행중인 시스템에 첨부 된 gdb 서브 커드 맨이 포함되어 있으며, 선택적으로 빌드 아카이브의 구성 데이터를 기반으로 자체 openocd 인스턴스를 실행합니다.
편의를 위해 적절한 빌드 아카이브로 humility 이라고 부르는 cargo xtask gdb 외관도 있습니다.
$ cargo xtask gdb app/demo-stm32f4-discovery/app.toml -- --run-openocd
# ... lots of output elided ...
task_idle::main () at task/idle/src/main.rs:14
14 loop {
Breakpoint 1 at 0x800434c: file /crates.io/cortex-m-rt-0.6.15/src/lib.rs, line 560.
Note: automatically using hardware breakpoints for read-only addresses.
semihosting is enabled
semihosting is enabled
(gdb) cargo xtask gdb (기본적으로) 칩의 이미지가 최신 상태인지 확인하기 위해 dist 및 flash 실행됩니다. -n / --noflash 옵션은이 단계를 건너 뜁니다.
Hubris 커널은 테스트 러너, 어시스턴트 및 테스트 스위트가 포함 된 전용 테스트 이미지 로 테스트됩니다. 테스트 이미지는 ITM을 통해 결과를 방출합니다. 이러한 결과는 수동으로 해석 될 수 있지만 humility test 이를 자동화합니다. humility test 자체는화물 cargo xtask dist cargo xtask flash 및 cargo xtask humility test 와 동등한 cargo xtask test 통해 가장 쉽게 실행됩니다. 정확한 호출은 보드에 따라 다릅니다.
cargo xtask test test/tests-lpc55xpresso/app.tomlcargo xtask test test/tests-stm32fx/app-f3.tomlcargo xtask test test/tests-stm32fx/app.tomlcargo xtask test test/tests-stm32h7/app-h743.tomlcargo xtask test test/tests-stm32h7/app-h753.toml 참고 : cargo xtask humility test OpenOCD를 실행하여 장치에 연결합니다. 테스트를 실행하기 전에 장치에 연결된 OpenOCD의 다른 인스턴스를 종료해야합니다.
테스트 결과에 대한 자세한 내용은 humility test 문서를 참조하십시오.
테스트의 출력은 humility test 로 캡처됩니다. sys_log!() 테스트에 대한 호출을 추가 한 다음 humility test 덤프에 캡처 할 수 있습니다. 그렇지 않으면 통과하는 테스트에서 덤프를 캡처하려면 cargo xtask humility 직접 사용하고 -d 플래그를 전달하십시오.
$ cargo xtask humility test/tests-stm32fx/app.toml -- test -d
...
humility: attached via ST-Link
humility: TPIU sync packet found at offset 1
humility: ITM synchronization packet found at offset 12
humility: expecting 22 cases
humility: running test_send ... ok
...
humility: running test_timer_notify ... ok
humility: running test_timer_notify_past ... ok
humility: tests completed: pass
humility: test output dumped to hubris.testout.2 GDB와 테스트 스위트를 모두 실행 해야하는 경우 테스트 이미지의 TOML 및 적절한 GDB 파일과 함께 cargo xtask gdb 사용한 다음 관심 테스트에 중단 점을 배치하십시오.
Gemini Bringup Getting Docs (내부 산화물 repo)를 참조하십시오.
STM32F3 Discovery Board의 경우 SB10은 ITM이 작동하려면 폐쇄되어야합니다! 이 솔더 브리지는 기본적으로 열려있어 SWO가 연결이 끊어집니다. 회로도 및 세부 사항은 STM32F3 Discovery User Manual (UM1570)을 참조하십시오.
LPCXPRESSO55S69를 사용하려면 PYOCD 버전 0.27.0 이상이 필요합니다.
LPCXPRESSO55S69는 내장 온칩 디버거 인 LPC-Link2가 SWO/SWV를 올바르게 지원하지 않기 때문에 다소 혼란 스럽습니다.
재고 LPC-Link2가있는 경우 pyocd list 통해 다음과 같은 방식으로보고합니다.
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ pyocd list 실행할 때마다 라이센스 용어를 수락하도록 촉구하여 낙관적 인 존재를 알리는 펌웨어 인 Segger J-Link 펌웨어가있을 수도 있습니다!
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936이 경우 중 하나의 경우 일회성 단계로 LPC-Link2에 새 펌웨어를 설치해야합니다. 새로운 펌웨어는 (오픈 소스) DAPLINK의 빌드로, 우리는 작은 위업이없는 엔지니어를 얻은 엔지니어를 따라 RickLink를 애정 적으로 호출합니다!
Hubris 저장소에 포함 된 두 가지 파일이 있습니다.
NXP의 LPCSCrypt 프로그램이 추가로 필요합니다.
RickLink를 설치하는 단계는 다음과 같습니다.
DFU 점퍼를 설치하십시오. 이것은 보드의 왼쪽에있는 SWD 헤더 옆에서 찾을 수 있습니다. "DFU"로 표시되어 있습니다.
설치된 LPCSCrypt 소프트웨어에서 scripts/boot_lpcscrypt :
$ /usr/local/lpcscrypt/scripts/boot_lpcscrypt
Looking for DFU devices with VID 1fc9 PID 000c ...
dfu-util -d 1fc9:000c -c 1 -i 0 -t 2048 -R -D /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
Booted LPCScrypt target (1fc9:000c) with /usr/local/lpcscrypt/scripts/../bin/LPCScrypt_228.bin.hdr
$lpcscrypt clockslow 실행 : $ /usr/local/lpcscrypt/bin/lpcscrypt clockslow
$lpcscrypt program +w1 0x0 BankA 실행 $ /usr/local/lpcscrypt/bin/lpcscrypt program +w1 0x0 BankA
................
Programmed 524288 bytes to 0x1a000000 in 2.610s (196.165KB/sec)
$lpcscrypt program +c <path-to-lpc4322_bl_crc.bin> BankA : banka : $ /usr/local/lpcscrypt/bin/lpcscrypt program +c ~ /hubris/support/lpc4322_bl_crc.bin BankA
..
Programmed 57344 bytes to 0x1a000000 in 0.827s (67.717KB/sec)
$성공했다고 가정하면 DFU 점퍼를 제거하고 USB를 분리/다시 연결하십시오.
이제 MAINTENANCE 라는 USB 대량 저장 장치가 있어야합니다.
# fdisk -l
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Micron 2200S NVMe 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A8653F99-39AB-4F67-A9C9-524A2864856E
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 967393279 966342656 460.8G Linux filesystem
/dev/nvme0n1p3 967393280 1000214527 32821248 15.7G Linux swap
Disk /dev/sda: 64.1 MiB, 67174400 bytes, 131200 sectors
Disk model: VFS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
# mount /dev/sda /mnt
# ls /mnt
DETAILS.TXT PRODINFO.HTM
# cat /mnt/DETAILS.TXT
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 02360b000d96e4fc00000000000000000000000097969905
HIC ID: 97969905
Auto Reset: 1
Automation allowed: 1
Overflow detection: 1
Daplink Mode: Interface
Interface Version: 0254
Bootloader Version: 0254
Git SHA: f499eb6ec4a847a2b78831fe1acc856fd8eb2f28
Local Mods: 1
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x09974fb3
Interface CRC: 0x7174ab4c
Remount count: 0
URL: https://os.mbed.com/platforms/LPCXpresso55S69/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin USB 드라이브로 복사하십시오 $ sudo cp ~ /hubris/support/lpc4322_lpc55s69xpresso_if_rla_swo_hacks.bin /mnt
$# umount /mnt
# pyocd list 실행하여 새 펌웨어에 있는지 확인하십시오.
$ pyocd list
# Probe Unique ID
-------------------------------------------------------------------------------------
0 LPCXpresso55S69 [lpc55s69] 02360b000d96e4fc00000000000000000000000097969905 LPCXPRESSO55S69에서 실행하는 RickLink는 Gemini 캐리어 보드의 LPC55S28의 디버거로 사용될 수 있습니다 . 이렇게하려면 먼저 위의 모든 지침에 따라 LPCXPRESSO55S69에 RickLink를 가져옵니다. 그 다음에:
납땜 철을 사용하여 J5의 2 핀 헤더를 납땜하십시오. J5는 P1의 왼쪽과 "디버거"점퍼 (j3) 아래에서 발견 될 수 있습니다.
새 헤더에 점퍼를 넣으십시오
"디버거"점퍼 (j3)를 "ext"로 이동하십시오.
SWD 케이블 (10 핀 2x5 1.27mm 피치 케이블)을 사용하여 LPCXPRESSO55S69의 SWD를 Gemini (J202)의 캐리어 보드 아래 SWD에 연결하십시오.
(RickLink가 다시 로컬 LPC55S69를 디버깅하도록하려면 J5의 점퍼를 제거하고 J3를 "LOC"로 이동하십시오.)
여러 프로브가 부착되면 도구는 적절한 시간에 올바른 프로브를 찾기 위해 고군분투 할 수 있습니다. 특히, OpenOCD는 그것이 찾은 첫 번째 것을 선택할 것입니다. OpenOCD를 강제로 특정 프로브를 선택하도록하려면 프로브의 일련 번호 (예 : humility probe 에서)를 확인한 다음 해당 openocd.cfg 의 일련 번호를 추가하여 다음과 같이 지정할 수 있습니다.
interface hla
hla_serial 271828182845904523536028
(여기서 271828182845904523536028 은 프로브의 일련 번호입니다.)
Debugging Dongles 및 Nucleo 시리즈와 같은 내장 디버그 하드웨어가 장착 된 개발 보드는 이전 펌웨어와 함께 제공되는 것이 일반적입니다.
오래된 ST-Link 펌웨어로 굴욕을 사용할 수 없습니다. 겸손은 예를 들어 humility test 시도 할 때 다음과 같은 경우입니다.
...
Warn : Adding extra erase range, 0x08020060 .. 0x0803ffff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
humility: test failed: The firmware on the probe is outdated
Error: test failed
이 "ST-Link 펌웨어 업그레이드"링크를 따라 현재 펌웨어를 설치하는 데 필요한 소프트웨어 및 지침을 찾으십시오.
