| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| ARM ( v5 ) HACK BL <label> http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=18180 |
Страница 1 от 1 |
| Автор: | TheWizard [ Сря Яну 12, 2022 7:28 pm ] | |||||||||
| Заглавие: | ARM ( v5 ) HACK BL <label> | |||||||||
как ( да го ... цензура ) се калкулира BL label ( armv5te ) ROM:0x1005067A [95 F0 0D F8] BL function_original ( 0x100E5698 ) ROM:0xXXXXXXXX [?? ?? ?? ??] BL function_hacked ( 0xYYYYYYYY ) function_original() ме дразни със една еденица ( която значи - WAIT_FOREVER, а искам да не блокира... демек 0 ) обаче ако хакна еденицата с нула ще омажа кернела... та искам да си взема foo() и правим my_foo() във my space
|
||||||||||
| Автор: | _oXo_ [ Пет Яну 14, 2022 9:11 pm ] |
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> |
https://stackoverflow.com/questions/420 ... nstruction |
|
| Автор: | TheWizard [ Съб Яну 15, 2022 11:15 am ] |
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> |
изчетох всички подобни ... дори се намира и сорс за ARMv7 ( не става за v5 ) https://gist.github.com/jeremy-allen-cs ... ode-py-L34 преди години портвах Ардуино за ГСМ модул и там има една блокираща функция, която ми пречеше да направя while(1) { .... } за loop() на ардуиното та тогава измислих едно просто решение, което работи безупречно, но ми изглежда тъпо... та реших да го направя по-по-най но се оказва, че това просто решение има "безплатен разход" : не използам други, най-вече кернел функции, които правят User APP - Firmware зависима с горното исках да дръпна оригиналната ROM функция в RAM или my ROM space, да пре-калкулирам BL-ите и да си направя новите неща, нещо като PIC ( position-independent code ) ... но в крайна сметка разхода е 19 кернел адреса имам работещи ASM и С версии на проблема, но ме е страх да не внеса допълнителни мои грешки ( поради липса на информация ) мислех и да пиша на производителя, но се отказах поради ред причини та го оставам както си е: работи ли - не го барай... |
|
| Автор: | TheWizard [ Съб Яну 15, 2022 3:42 pm ] | ||||||||||||||||||||||||||||||||||||
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> | ||||||||||||||||||||||||||||||||||||
за тези които им е интересно или мислят да работят с GSM модули - обяснявам ... в някой ( в повечето ) GSM модули може да се пише и изпълнява UserWare апликация вътре в модула, без контрол от външно MCU в момента най-разпространените SDK ( User API ) са: OpenCPU, ThreadX, Linux ... това си е нормално C/C++ Линукс приложение ( PIC (Position-Independent Code) библиотека ) или static libraries. при първите две връзката кернел - узер е следната: OpenCPU: string( "function_foo"... трябва ни тази функция ) = Hash(на стринга) --> има API_Table[ Hash ] - и съответен мост между kernel_foo() и user_foo() ... това накратко ThreadX: софтуерно прекъсване syscall( функция_номер, функция_параметри ... ) или просто статично линкване на прекомпилирани кернел библиотеки със user appication сорс код има и "по-прости" PIC ( position-independent code ) User APP като PIC библиотека - разхода е че се зареждат/изпълняват в RAM ... в повечето потребителски USER_MAIN() е организиран така: ( например: ESP32 )
което си е super loop + rtos task yield <--- това ако го няма - кучето ще ритне "апликацията" или другите задачи няма да се изпълняват При OpenCPU положението е почти същото
та тук super loop е обработка на съобщения, а yield() го прави GetMessage() прозрачно за нас какво точно прави GetMessage() . получаване и обработка на съобщения от кернела и разпределение на USER_MESSAGES между USER_TASKS . обработка и транслация на периферия ( kernel to user space ) уж защита на ресурси, но без MMU това се обезсмисля... . ако няма съобщения - блокиране на таска, демек yield() . ако има съобщение за нас - switch/case някаква си наша обработка на приетото съобщение GetMessage() може да се замени с task_delay( време ) но таска няма да получава кернел съобщения и няма да може да работи с периферия като UART, TIMERS ... etc, използващи прекъсвания, транслирани то user space като callbacks() Транслацията на периферията работи така: в който таск е open( периферия ) то там ще бъде изпратено съобщение и ще се изпълни callback( периферия ) и само там може да се modify/close( периферия ) забележка: така са го "измислили" джигитайците ... уж защита на ресурси, макар че разработката не е джигитайска ( нямат толкова акъл ) ... автор неизвестен ... реално има две фунции GetMessage(&msg) OS kernel_GetMessage( нямаме достъп до тази ) и APP user_GetMessage( с тази работим ) тази е само "мост" / API към kernel_GetMessage() която прави следното накратко
та WAIT_FOREVER предизвика моя "проблем" няма как да се изпълнява Ардуино loop(); що то таска е блокирал преди или след него простото/тъпо решение беше да изпращам винаги едно празно съобщение в опашката на OS_TASK_n_QUEUE, ако има нещо, кернела си го обработва, ако "няма" ... но "винаги" има едно мое "празно" съобщение от което kernel_GetMessage() излиза и изпълнава loop()
и те така... някой ще кажат: Защо Ардуино или Ардуино не е "по-по-най" за "индустриални" цели ... но това е друга тема |
|||||||||||||||||||||||||||||||||||||
| Автор: | gicho [ Нед Яну 16, 2022 11:42 am ] |
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> |
Информацията е полезна и добре систематизирана. Това с getmessage() е event loop модела. Ако има шедюлър/ОС, това би трябвало да тича в отделен тред, който като приоритет да е принизен до ниво, в което блокиране няма да спре нищо жизненоважно. Чрез пращане на съобщения (асинхронно И/О) навън/към "ОС-а", изискваш определени действия, които се вършат в други тредове (системни) и ти връщат резултат като съобщение в следващ GetMessage. Това е основата на nodejs и там самия event loop с асинхронно I/O е направен във C библиотека - libuv и подобни (май я смениха). Тая libuv има портове и за ембедед, ама си иска шедюлър - за да я направиш ти трябва нещо, което да има идеята за тредове - може да е просто ексепшън/софтуерно/хардуерно прекъсване, ако софтуера е прост спрямо възможностите на ядрото и интерръпт контролера, или истински шедюлър като RTOS (който ползва ексешшъните и другите фийчъри на ядрото за да симулира повече ексепшъни). В тия системи (дето има "кърнел"/системни неща и отделно произволно "приложение") това е големият проблем - как потребителят, пишейки с краката си, да не убие важните неща отзад. За пълна защита си трябват мускули - изолиране на паметта (поне защита на зони), възможност да се прекъсне потребителското приложение/тред в момент, в който на системата и е нужно да обработи събитие/прекъсване и т.н. То това е голямата разлика между "десктоп" ОС-овете и ембеддед приложенията - първите не знаят какви приложения и как ще се опитват да ги убият, другите го знаят още по дизайн и могат всичките мерки на защита да се изпълнят още на ниво компилиране. Опитите да се вкарат изисквания от десктоп (къстъм приложение) в ембедед (trusted environment) са обречени на неуспех, ако не се покрият поне основните специфики по защитата. Т.е. разни виртуални машини, интерпретатори. То и затова често линукс намира място за псевдо-ембедед - лесно получаваш наготово 40+ години ноу-хау в посоката гъвкава система, която можеш да я разширяваш и променяш след доставката. Аз съм привърженик на запазването на разделението - щом ще е ембедед устройство, то си има точно дефинирана функция - с дадения фирмуер. Ако ще сменяш функцията, флашиш нов фирмуер. Ако искаш да спестиш време и трафик, правиш ефективно бинарно пачване на далечната страна. За "частични" решения слагаш виртуална машина/интерпретатор и там правиш логиката. Ако решението с виртуална машина не ти пасва, щото примерно искаш от javascript-а да обработваш real-time процес, значи идеята е сбъркана - или слагаш нещо, което предлага истинско динамично линкване (линукс/позикс и сие), или се връщаш на дизайн фазата и почваш да търсиш друг подход. Гледам, много народ реве че ESP-тата не ставали за real-time щото все нещо отзад прекъсвало ОС-а и разбърквало времената - да, там чукат прекъсванията за вифи-то. Ако някой тръгне да го прави без ОС-a, на гола поляна, пак ще удари до проблема че трябва да реагира навреме/с приоритет на вифи прекъсванията. |
|
| Автор: | TheWizard [ Нед Яну 16, 2022 4:16 pm ] | ||||||||||||||||||
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> | ||||||||||||||||||
хванах го ... за дедовия
декодирането на JMP адреса е
обаче, ако имитирам PIC ( Position-Independent Code ) пачване става "по-сложно" от - ако пренеса ASM от ИДА-та ... и го редактирам и прекомпилирам така или иначе ми прябват 19 кернел адреса ... става много Firmware зависимо най-доброто решение е производителя да си "пачне" функцията ... и става много готино ( с допълнителни екстри ) без да се отрази на старите Firmware но с джикитайци не ми се разправя.... ибал съм ги |
|||||||||||||||||||
| Автор: | TheWizard [ Нед Яну 16, 2022 4:23 pm ] |
| Заглавие: | Re: ARM ( v5 ) HACK BL <label> |
BTW @ gicho Mediatek, Qualcomm ... GSM SoC & SDK ... са се постарали достатъчно добре: прецизните неща да са "прецизно сготвени" @ на времена, приоритети, прекъсвания ... просто джигитайските APP Firmware .... абе немам думи ... |
|
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|