Микроконтролери и електроника
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
Код:
int my_foo( параметри )
{
    ... блах ...
 
    res = function_hacked( 0 ); // function_original( 1 )
    if(res)
        return res;
   
    ... блах ...

    return 0
}

Автор:  _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 )

Код:
void task_main(int task_id)
{
    setup();
    while( 1 )
    {
        loop();
        task_delay(1) // или yield() за блокиране и превключване на задачите
    }
}


което си е super loop + rtos task yield <--- това ако го няма - кучето ще ритне "апликацията" или другите задачи няма да се изпълняват

При OpenCPU положението е почти същото

Код:
void task_main(int task_id)
{
    setup();
    while( 1 )
    {
        GetMessage( &msg ); // <--------- важно !!!
        switch( msg.message )
        {
            case USЕR_MESSAGE_1: ... break;
            case USЕR_MESSAGE_2: ... break;
        }
        някакъв друг user код
    }
}
( забележка: всички C/C++ Windows програми работят така )


та тук 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() която прави следното накратко

Код:
int kernel_GetMessage( MSG * msg ) // msg е за резултатно съобщение за нас
{
    task_id = OS_GET_CURRENT_TASK_ID(); // само за този таск
    while( 1 )
    {
        OS_QUEUE_GET( task_id, &queue_task_record, WAIT_FOREVER ); // всеки таск си има негово си queue
       
        // пример за това от FreeRTOS е:   BaseType_t xQueueReceive( QueueHandle_t xQueue, void *pvBuffer, TickType_t xTicksToWait );
        // xTicksToWait задава време за блокиравка на таска ... в нашия случай WAIT_FOREVER
       
        switch( queue_task_record.message_id ) // обработка на истинските кернел съобщения
        {
            case MSG_UART_RX:   
                find: user_uart_callback()
                execute: user_uart_callback( params )
                break;  // демек goto while(1) в началото
           
            case MSG_TIMER:
                find: user_timer_callback()
                execute ...
                и пак while()
           
            case други системни съобщения:
           
            и те така докато:
            case MSG_USER:
                копи данни от queue_task_record към msg за нас ... в случая msg->ID(съобщение), msg->param1, msg->param2 и msg->task_sourse_id (от къде идва съобщениетo)
                и изход от тук с return 0
                // след изхода следва да си обработим каквото е дошло за нас...
                //      например: SIM картата е готова или Модема е свързан към провайдера и други такива
                // това тук разпределя и мулти-таск съобщения между наши таскове
        }   
    }
}


та WAIT_FOREVER предизвика моя "проблем"
няма как да се изпълнява Ардуино loop(); що то таска е блокирал преди или след него
простото/тъпо решение беше да изпращам винаги едно празно съобщение в опашката на OS_TASK_n_QUEUE,
ако има нещо, кернела си го обработва, ако "няма" ... но "винаги" има едно мое "празно" съобщение от което kernel_GetMessage() излиза и изпълнава loop()

Код:
SendMessage( MY_MSG ); // едно на опашката
while(1)
{
    GetMessage( msg );
    switch( msg )
        case НЯКАКВИ СЪОБЩЕНИЯ:
       
    loop(); // пример Ардуино
    SendMessage( MY_MSG )  // прати едно на опашката
    task_delay( 1 ); // грижи за други задачи и кучето
}


и те така...

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

Автор:  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>

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

Код:
ако:   
ROM: PC [ AABBCCDD ] BL <JMP>   
то:
INSTR = 0xBBAADDCC // swap инструкция
PC += 4
offset  = 0x100000000 - ( ( PC - JMP ) & 0xFFFFFFFF )
thumb_instr_1 = 0xF000 | ( offset >> 12 )
thumb_instr_2 = 0xF000 | ( offset & 0xFFF )


декодирането на JMP адреса е
Код:
offset  = ( (INSTR & 0x7FF) + ((INSTR & 0x03FF0000) >> 5) ) << 1;
JMP = PC + offset



обаче, ако имитирам 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 .... абе немам думи ... :axe:

Страница 1 от 1 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/