как ( да го ... цензура ) се калкулира 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

изчетох всички подобни ... дори се намира и сорс за 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 и С версии на проблема, но ме е страх да не внеса допълнителни мои грешки ( поради липса на информация )
мислех и да пиша на производителя, но се отказах поради ред причини

та го оставам както си е: работи ли - не го барай...

за тези които им е интересно или мислят да работят с 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()



и те така...

някой ще кажат: Защо Ардуино или Ардуино не е "по-по-най" за "индустриални" цели ... но това е друга тема

Информацията е полезна и добре систематизирана.
Това с getmessage() е event loop модела. Ако има шедюлър/ОС, това би трябвало да тича в отделен тред, който като приоритет да е принизен до ниво, в което блокиране няма да спре нищо жизненоважно. Чрез пращане на съобщения (асинхронно И/О) навън/към "ОС-а", изискваш определени действия, които се вършат в други тредове (системни) и ти връщат резултат като съобщение в следващ GetMessage. Това е основата на nodejs и там самия event loop с асинхронно I/O е направен във C библиотека - libuv и подобни (май я смениха). Тая libuv има портове и за ембедед, ама си иска шедюлър - за да я направиш ти трябва нещо, което да има идеята за тредове - може да е просто ексепшън/софтуерно/хардуерно прекъсване, ако софтуера е прост спрямо възможностите на ядрото и интерръпт контролера, или истински шедюлър като RTOS (който ползва ексешшъните и другите фийчъри на ядрото за да симулира повече ексепшъни).
В тия системи (дето има "кърнел"/системни неща и отделно произволно "приложение") това е големият проблем - как потребителят, пишейки с краката си, да не убие важните неща отзад. За пълна защита си трябват мускули - изолиране на паметта (поне защита на зони), възможност да се прекъсне потребителското приложение/тред в момент, в който на системата и е нужно да обработи събитие/прекъсване и т.н.
То това е голямата разлика между "десктоп" ОС-овете и ембеддед приложенията - първите не знаят какви приложения и как ще се опитват да ги убият, другите го знаят още по дизайн и могат всичките мерки на защита да се изпълнят още на ниво компилиране. Опитите да се вкарат изисквания от десктоп (къстъм приложение) в ембедед (trusted environment) са обречени на неуспех, ако не се покрият поне основните специфики по защитата. Т.е. разни виртуални машини, интерпретатори.
То и затова често линукс намира място за псевдо-ембедед - лесно получаваш наготово 40+ години ноу-хау в посоката гъвкава система, която можеш да я разширяваш и променяш след доставката.
Аз съм привърженик на запазването на разделението - щом ще е ембедед устройство, то си има точно дефинирана функция - с дадения фирмуер. Ако ще сменяш функцията, флашиш нов фирмуер. Ако искаш да спестиш време и трафик, правиш ефективно бинарно пачване на далечната страна.
За "частични" решения слагаш виртуална машина/интерпретатор и там правиш логиката. Ако решението с виртуална машина не ти пасва, щото примерно искаш от javascript-а да обработваш real-time процес, значи идеята е сбъркана - или слагаш нещо, което предлага истинско динамично линкване (линукс/позикс и сие), или се връщаш на дизайн фазата и почваш да търсиш друг подход.
Гледам, много народ реве че ESP-тата не ставали за real-time щото все нещо отзад прекъсвало ОС-а и разбърквало времената - да, там чукат прекъсванията за вифи-то. Ако някой тръгне да го прави без ОС-a, на гола поляна, пак ще удари до проблема че трябва да реагира навреме/с приоритет на вифи прекъсванията.

хванах го ... за дедовия



декодирането на JMP адреса е



обаче, ако имитирам PIC ( Position-Independent Code ) пачване става "по-сложно" от - ако пренеса ASM от ИДА-та ... и го редактирам и прекомпилирам
така или иначе ми прябват 19 кернел адреса ... става много Firmware зависимо

най-доброто решение е производителя да си "пачне" функцията ... и става много готино ( с допълнителни екстри ) без да се отрази на старите Firmware
но с джикитайци не ми се разправя.... ибал съм ги

BTW @ gicho
Mediatek, Qualcomm ... GSM SoC & SDK ... са се постарали достатъчно добре: прецизните неща да са "прецизно сготвени" @ на времена, приоритети, прекъсвания ...
просто джигитайските APP Firmware .... абе немам думи ...