hubris
sidecar release
Hubris هي بيئة تشغيل متحكم مصممة للأنظمة ذات السميد العميق مع متطلبات الموثوقية. تم اقتراح تصميمه في البداية في RFD41 ، لكنه تطور بشكل كبير منذ ذلك الحين.
وثائق المطور موجودة في ASCIIDOC في doc/ الدليل. يتم تقديمه عبر صفحات github ، وهو متاح على https://oxidecomputer.github.io/hubris.
تم وضع الريبو على النحو التالي.
app/ هو المكان الذي يحتوي على الصناديق الثنائية ذات المستوى الأعلى للتطبيقات ، على سبيل المثال ، يحتوي app/gimlet على قفص البرامج الثابتة لـ Gimlet. بشكل عام ، إذا كنت ترغب في بناء صورة لشيء ما ، انظر هنا.
build/ يحتوي على نظام البناء والصناديق الداعمة.
chip/ يحتوي على تعريفات طرفية وملفات الدعم تصحيح الأخطاء لمرون متحكم فردي.
doc/ يحتوي على وثائق المطور.
drv/ يحتوي على برامج تشغيل ، مزيج من صناديق LIB للسائق البسيط وصناديق سلة الخادم بالكامل. الاتفاقية الحالية هي أن drv/SYSTEM-DEVICE هو برنامج التشغيل DEVICE على SYSTEM (حيث يكون SYSTEM عادةً اسم SOC) ، في حين أن drv/SYSTEM-DEVICE-server هو صندوق صندوق الخادم.
idl/ يحتوي على تعريفات واجهة مكتوبة في المعبود
lib/ يحتوي على مكتبات فائدة متنوعة كتبناها. إذا كنت بحاجة إلى صنع صندوق قابل لإعادة الاستخدام لا يتناسب مع أحد الأدلة الأخرى ، فمن المحتمل أن ينتمي إلى هنا.
stage0/ IS the Bootloader/ Hypovisor ، في المقام الأول لـ LPC55.
support/ يحتوي على بعض ملفات دعم الواجهة والبرمجة ، مثل الشهادات المزيفة وصور البرامج الثابتة المبرمج.
sys/ يحتوي على أجزاء "النظام" من الغطرسة ، وهي kernel ( sys/kern ) ، والصندوق المشترك الذي يحدد ABI ( sys/abi ) ، ومكتبة المستخدم المستخدمة في المهام ( sys/userlib ).
task/ تحتوي على مهام قابلة لإعادة الاستخدام التي ليست برامج تشغيل. التمييز بين الأشياء التي تعيش في task VS في drv/something-server أمر غامض. استخدم حكمك.
test/ يحتوي على إطار الاختبار والصناديق الثنائية لبناءه لمختلف المجالس.
website/ يحتوي على الرمز المصدر لموقع Hubris
نحن ندعم حاليًا Linux و Windows كمنصات من الدرجة الأولى. يستخدم MacOS أيضًا على أساس يومي من قبل موظفي الأكسيد ، ولكن لم يتم اختباره في CI. ربما يعمل البناء أيضًا على Illumos ؛ إذا كان أي شخص يرغب في تصعيد للحفاظ على الدعم وبناء مستمر لـ Illumos أو MacOS ، فنحن نحب المساعدة.
لتقديم التغييرات للمراجعة ، ادفعها إلى فرع في شوكة وتقديم طلب سحب لدمج هذا الفرع في master . لمزيد من التفاصيل ، انظر CONTRIBUTING.md .
ستحتاج:
تثبيت أدوات أدوات قائم rustup . سوف يهتم rustup بتثبيت إصدار أدوات الأدوات المثبت تلقائيًا ، وأهداف التجميع المتقاطع ، عند محاولة البناء لأول مرة.
openocd (من الناحية المثالية 0.11) أو (إذا كنت تستخدم LPC55) pyocd (0.27 أو أحدث). لاحظ أن إصدار 0.10 من OpenOCD يسبق stlink V3. يستخدم الأشخاص العديد من الإنشاءات بعد 0.10 ، قبل 0.11 مقدمة من قبل مديري حزم النظام ، مع بعض النجاح ، ولكن إذا لم يكن نظامك يعمل على تعبئة 0.11 حتى الآن ، فإنه يتنافس عليهم. إذا كنت ستستخدم Homebrew على MacOS لتثبيت OpenOCD ، فأنت بحاجة إلى استخدام brew install --head openocd لبناء طرف الفرع الرئيسي بدلاً من استخدام أحدث إصدار ثنائي. إذا كنت بحاجة إلى البناء من المصدر ، فيمكنك العثور على OpenOCD V0.11.0 هنا. عند ST-Link Programmer ./configure
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 لتثبيت ثنائيات الذراع الرسمية.
تصحيح الأخطاء ، التواضع. لاحظ أن cargo install يتفاعل بشكل غريب مع ملف rust-toolchain.toml الموجود في جذر هذا المستودع ؛ إذا قمت بتشغيل الأمر التالي الحرفي لتثبيت التواضع ، فقم بذلك من دليل مختلف:
cargo install --git https://github.com/oxidecomputer/humility.git --locked humilitycargo-readme باعتباره تبعية: cargo install cargo-readmeهناك ثلاث طرق بديلة لتثبيت OpenOCD:
انظر هنا للحصول على مصدر openocd أو الحصول على ثنائيات غير رسمية.
بدلاً من ذلك ، يمكنك التثبيت مع الشوكولاتة:
> choco install openocd أخيرًا ، يمكنك تثبيت openocd مع SCOOP:
> scoop bucket add extras
> scoop install openocd ملاحظة: أثبتت openocd المثبت عبر scoop مشكلة بالنسبة لبعض المستخدمين. إذا واجهت مشاكل ، فحاول التثبيت عبر choco أو من Source (انظر أعلاه).
لاستخدام مبرمج ST-Link ، ربما ستحتاج إلى تثبيت برنامج التشغيل هذا.
ليس من الضروري بناء وتشغيل الغطرسة ، ولكن إذا كنت ترغب في التواصل عبر رابط متسلسل (وهذا لا يدعمه المحطة الخاصة بك) ، فستحتاج إلى استخدام المعجون ؛ يقوم هذا الدليل بعمل جيد في شرح كيف.
نحن لا نستخدم cargo build أو cargo run مباشرة لأنها غير مرنة للغاية لأغراضنا. لدينا بنية متعددة البنية معقدة ، والتي تتجاوزهم قليلاً.
بدلاً من ذلك ، يتضمن Repo امتدادًا لشحنًا يسمى 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 Board نظرًا لأن بناء الصورة الكاملة قد يستغرق 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 لن يعمل نظام Build Hubris مع rust-analyzer خارج الصندوق.
ومع ذلك ، فإن cargo xtask lsp موجود هنا للمساعدة: يستغرق الأمر كملف صدأ ، ويعيد التكوين المشفر من JSON لكيفية إعداد rust-analyzer .
لاستخدام هذه البيانات ، مطلوب بعض تكوين المحرر!
(لم نقم بإنشاء ملحقات إضافية بعد ، لكن سيكون ذلك ممكنًا بالتأكيد)
باستخدام 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 من محاولة إعادة استخدام عميل موجود ، والذي يتم تكريسه عادةً بواسطة اسم العميل ودليل جذر مساحة العمل ؛ في الغطرسة ، نريد تعايش عملاء متعددين من نفس جذر مساحة العمل ، لذلك يحتاجون إلى أسماء مختلفة. بعد ذلك ، نقوم بتخليص بقية التكوين في متغير محلي ( cache ) ، وتسجيل وجود هذا العميل في clients .
عند الإرفاق بـ LSP ، نحاول سحب التكوين من cache . إذا كان أحدهم موجودًا ، فنحن نعلم أننا نتعامل مع المخزن المؤقت للغضب ؛ نسخ عبر الأجزاء ذات الصلة من التكوين.
لاحظ أن هذا لا يجمع 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 يمكن إنشاء رسم بياني يوضح علاقات المهام المختلفة وأولوياتها. الملف الناتج في تنسيق dot 's GraphViz. يمكن تضمين مصدر Dot في مصدر ASCIIDOCTOR أو تقديمه إلى مجموعة متنوعة من التنسيقات.
لإنشاء وعرض رسم بياني SVG لـ gimletlet على Ubuntu ، تأكد من تثبيت حزمة graphviz . Then generate the graph:
$ cargo xtask graph -o gimletlet.dot app/gimletlet/app.toml
$ dot -Tsvg gimletlet.dot > gimletlet.svg
$ xdg-open gimletlet.svgBash commands to generate all graphs:
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}" If eog is the default viewer, opening the first SVG in a directory will allow cycling through all of the available graphs using the same window.
يقترن Hubris بإحكام مع تصحيح الأخطاء ، والتواضع ، والذي يتم استخدامه للأوامر أدناه إما ضمنيًا (في cargo xtask flash ) أو بشكل صريح (في cargo xtask humility ).
إذا لم يكن humility الثنائي متاحًا على $PATH الخاص بك ، فقد يتم استخدام متغير بيئة HUBRIS_HUMILITY_PATH لتوفير المسار إلى الثنائي.
يمكن وميض صورة داخل أرشيف Hubris مباشرةً على لوحة الهدف عن طريق تشغيل cargo xtask flash وتحديد ملف Toml المناسب. This will run cargo xtask dist and then pass the resulting build archive to humility flash . humility will invoke either OpenOCD or pyOCD to flash the image; the exact invocation depends on the board and is encoded in the build archive.
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 يتم تشغيل التواضع في الموقع من خلال تحديد أرشيف على لوحة متصلة مباشرة ، أو ما بعد الوفاة عن طريق تحديد تفريغ. باعتبارها راحة للتنمية ، يمكن أيضًا تشغيل التواضع في الموقع من خلال تحديد TOML المناسب ، على سبيل المثال على جهاز مع لوحة اكتشاف STM32F4 المرفقة مباشرة:
$ 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 مجموعة فرعية gdb التي تعلق على نظام تشغيل باستخدام arm-none-eabi-gdb ، مما يؤدي اختيارياً إلى تشغيل مثيل openocd الخاص به استنادًا إلى بيانات التكوين في أرشيف الإنشاء.
للراحة ، هناك أيضًا واجهة cargo xtask gdb التي تدعو humility مع أرشيف الإنشاء المناسب:
$ 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 هذه الخطوات.
يتم اختبار kernel hubris مع صورة اختبار مخصصة تتضمن عداء اختبار ومساعد ومجموعة اختبار. تصدر صورة الاختبار نتائجها عبر ITM. في حين يمكن تفسير هذه النتائج يدويًا ، humility test أتمتة هذا. يتم تشغيل humility test نفسه بسهولة عبر cargo xtask test ، والذي يدير ما يعادل cargo xtask dist و cargo xtask flash و cargo xtask humility 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 وجناح الاختبار ، فاستخدم cargo xtask gdb مع TOML لصورة الاختبار وملف GDB المناسب ، ثم ضع نقاط التوقف في اختبار الاهتمام.
انظر Gemini Bringup Setting Docs (REPO) الأكسيد الداخلي)
بالنسبة إلى لوحة اكتشاف STM32F3 ، يجب إغلاق SB10 من أجل العمل! يتخلف جسر اللحام هذا إلى أن يكون مفتوحًا ، والذي يترك SWO غير متصل. راجع دليل مستخدم STM32F3 Discovery (UM1570) للاطلاع على التخطيط والتفاصيل.
لاستخدام LPCXPRESSO55S69 ، ستحتاج إلى PYOCD ، الإصدار 0.27.0 أو أحدث.
The LPCXpresso55S69 is somewhat of a mess because the built-on on-chip debugger, LPC-Link2, does not correctly support SWO/SWV
إذا كان لديك الأسهم LPC-Link2 ، فسيقوم بالإبلاغ عن نفسه بهذه الطريقة عبر pyocd list :
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------
0 NXP Semiconductors LPC-LINK2 CMSIS-DAP V5.361 JSAQCQIQ من الممكن أيضًا أن يكون لديك البرامج الثابتة لـ Segger J-Link-التي ستجعل وجودها البغيض معروفًا من خلال تقديمها إلى قبول شروط الترخيص عند تشغيل pyocd list !
$ pyocd list
# Probe Unique ID
-----------------------------------------------------------------------------
0 Segger J-Link LPCXpresso V2 compiled Apr 4 2019 16:54:03 726424936في أي من هذه الحالات ، يجب عليك-كخطوة لمرة واحدة-تثبيت البرامج الثابتة الجديدة على LPC-Link2. البرامج الثابتة الجديدة هي بناء من Daplink (مفتوح المصدر) ، والتي نسميها بشكل عاطفي Ricklink بعد المهندس الذي تمكن من بناء كل شيء - لا عمل صغير!
هناك ملفان ستحتاجهما ، كلاهما موجودان في مستودع الغطرسة:
ستحتاج بالإضافة إلى ذلك إلى برنامج LPCScrypt من NXP.
Here are the steps to install RickLink:
Install the DFU jumper. يمكن العثور على هذا بجوار رأس SWD على الجانب الأيسر من اللوحة ؛ تم تسمية "DFU".
قم بتشغيل scripts/boot_lpcscrypt من برنامج 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 : $ /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
يجب أن يكون هناك الآن جهاز تخزين كبير USB يسمى MAINTENANCE
# 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 لاحظ أنه يمكن أيضًا استخدام RickLink الذي يعمل على LPCXPresso55S69 كصحاف الأخطاء لـ LPC55S28 على لوحة الناقل الجوزاء. للقيام بذلك ، أولاً ، اتبع جميع الإرشادات أعلاه للحصول على recklink على lpcxpresso55s69. ثم:
باستخدام حديد لحام ، لحام رأس دبوس على J5. يمكن العثور على J5 على يسار P1 وتحت "Debugger" Jumper (J3).
ضع الطائر على الرأس الجديد
انقل "Debugger" Jumper (J3) إلى "تحويلة".
استخدم كابل SWD (كابل الملعب 10 دبوسة 2x5 1.27 مم) لتوصيل SWD على LPCXPresso55S69 إلى SWD أسفل لوحة الناقل على الجوزاء (J202)
(للسماح لـ RickLink مرة أخرى بتصحيح LPC55S69 المحلي ، قم بإزالة الطائر على J5 وانقل J3 إلى "LOC".)
إذا تم إرفاق تحقيقات متعددة ، فقد تكافح الأدوات من أجل العثور على واحد مناسب في الوقت المناسب. على وجه الخصوص ، سيختار OpenOCD أول واحد يجده ؛ لإجبار OpenOCD على اختيار مسبار معين ، يمكنك التأكد من الرقم التسلسلي للمسبار (على سبيل المثال ، من humility probe ) ثم حدد هذا الرقم التسلسلي في openocd.cfg المقابل عن طريق الإضافة ، على سبيل المثال:
interface hla
hla_serial 271828182845904523536028
(حيث 271828182845904523536028 هو الرقم التسلسلي للمسبار.)
من الشائع أن يتم تسليم 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 Firmware Upgrade" للعثور على البرامج والتعليمات اللازمة لتثبيت البرامج الثابتة الحالية.
