Can uefi applications make calls to DXE lib api's and vice versa - uefi

I am working in edk2 Tianocore. I have written a DXE driver for some data processing, this driver is automatically executed just before BDS phase.
I have also written an uefi Application for doing the same job, this app. can be executed from uefi shell by user.
The common code for the Dxe driver and application is put in a uefi Library. The problem is the Print () function calls in the Library are not working when called from Dxe driver, they are working well when called from app.

The Print function will not work until the output console is initialized in the BDS phase, at which point the gST->ConOut pointer is populated. You can replace the Print calls in your library with your own function, e.g. PrintApp, which internally will check gST->ConOut, and only call Print when gST->ConOut is not NULL. During development I also like calling DEBUG (...) in DXE and Print (...) after ReadyToBoot in the PrintApp function, so I see the same messages going out to either debug console or the screen.

Related

How do I add a missing peripheral register to a STM32 MCU model in Renode?

I am trying out this MCU / SoC emulator, Renode.
I loaded their existing model template under platforms/cpus/stm32l072.repl, which just includes the repl file for stm32l071 and adds one little thing.
When I then load & run a program binary built with STM32CubeIDE and ST's LL library, and the code hits the initial function of SystemClock_Config(), where the Flash:ACR register is being probed in a loop, to observe an expected change in value, it gets stuck there, as the Renode Monitor window is outputting:
[WARNING] sysbus: Read from an unimplemented register Flash:ACR (0x40022000), returning a value from SVD: 0x0
This seems to be expected, not all existing templates model nearly everything out of the box. I also found that the stm32L071 model is missing some of the USARTs and NVIC channels. I saw how, probably, the latter might be added, but there seems to be not a single among the default models defining that Flash:ACR register that I could use as example.
How would one add such a missing register for this particular MCU model?
Note1: For this test, I'm using a STM32 firmware binary which works as intended on actual hardware, e.g. a devboard for this MCU.
Note2:
The stated advantage of Renode over QEMU, which does apparently not emulate peripherals, is also allowing to stick together a more complex system, out of mocked external e.g. I2C and other devices (apparently C# modules, not yet looked into it).
They say "use the same binary as on the real system".
Which is my reason for trying this out - sounds like a lot of potential for implementing systems where the hardware is not yet fully available, and also automatted testing.
So the obvious thing, commenting out a lot of parts in init code, to only test some hardware-independent code while sidestepping such issues, would defeat the purpose here.
If you want to just provide the ACR register for the flash to pass your init, use a tag.
You can either provide it via REPL (recommended, like here https://github.com/renode/renode/blob/master/platforms/cpus/stm32l071.repl#L175) or via RESC.
Assuming that your software would like to read value 0xDEADBEEF. In the repl you'd use:
sysbus:
init:
Tag <0x40022000, 0x40022003> "ACR" 0xDEADBEEF
In the resc or in the Monitor it would be just:
sysbus Tag <0x40022000, 0x40022003> "ACR" 0xDEADBEEF
If you want more complex logic, you can use a Python peripheral, as described in the docs (https://renode.readthedocs.io/en/latest/basic/using-python.html#python-peripherals-in-a-platform-description):
flash: Python.PythonPeripheral # sysbus 0x40022000
size: 0x1000
initable: false
filename: "script_with_complex_python_logic.py"
```
If you really need advanced implementation, then you need to create a complete C# model.
As you correctly mentioned, we do not want you to modify your binary. But we're ok with mocking some parts we're not interested in for a particular use case if the software passes with these mocks.
Disclaimer: I'm one of the Renode developers.

Drawing the line between Module and ModuleManager in ThreadX priviliges

Using Module and ModuleManager with ThreadX in a MPU-enabled platform
is "default_module_start" considered part of ModuleManager and can call Tx APIs even though, it is in the app_module.c?
E.G tx_thread_create works in default_module_start but doesn't work in the modules threads and throughs an exception;
Another question why is the ModuleManager is not just using the Tx APIs to handle threats for example, instead it uses custom functions that doesn't call Tx APIs at all
Function demo_module_start is part of a module (this function is in sample_threadx_module.c). It runs in the module context. This function gets called by txm_module_thread_shell_entry.c when a module is started.
Modules run in unprivileged mode, but they call ThreadX APIs (a.k.a. kernel functions). In order to execute ThreadX APIs, the module uses the SVC instruction (for ARM processors) to get into supervisor (privileged) mode. Thus, in the module library, all of the kernel calls are just simple calls that pass the function parameters to the kernel, and the actual ThreadX function is executed in kernel (privileged) mode.
Let me know if this answers your questions or if you have more questions.
Edit:
You can call TX APIs from module threads. By default, they trap into the kernel via the SVC instruction. If you want to call TX APIs directly from a module (i.e. without trapping), the module needs to be in privileged mode execution, which you can configure by modifying the module properties in the preamble of the module (e.g. see https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/txm_module_preamble.S - change the properties from 0x00000007 to 0x00000000).
Creating a module thread is a bit different than creating a normal thread. The manager puts the TXM_MODULE_THREAD_ENTRY_INFO into the module thread stack, allocates a kernel stack for the thread, builds the module thread stack (which has a different return mode than a normal thread).
The manager can have whatever priority you want to assign it. Most if not all of our module manager examples assign a priority of 1 (https://github.com/azure-rtos/threadx/blob/master/ports_module/cortex_m7/gnu/example_build/sample_threadx_module_manager.c).

Understanding higher level call to systemcalls

I am going through the book by Galvin on OS . There is a section at the end of chapter 2 where the author writes about "adding a system call " to the kernel.
He describes how using asmlinkage we can create a file containing a function and make it qualify as a system call . But in the next part about how to call the system call he writes the following :
" Unfortunately, these are low-level operations that cannot be performed using C language statements and instead require assembly instructions. Fortunately, Linux provides macros for instantiating wrapper functions that contain the appropriate assembly instructions. For instance, the following C program uses the _syscallO() macro to invoke the newly defined system call:
Basically , I want to understand how syscall() function generally works . Now , what I understand by Macros is a system for text substitution .
(Please correct me If I am wrong)
How does a macro call an assembly language instruction ?
Is it so that syscallO() when compiled is translated into the address(op code) of the instruction to execute a trap ?(But this somehow doesn't fit with concept or definition of macros that I have )
What exactly are the wrapper functions that are contained inside and are they also written in assembly language ?
Suppose , I want to create a function of my own which performs the system call then what are the things that I need to do . Do , I need to compile it to generate the machine code for performing Trap instructions ?
Man, you have to pay $156 dollars to by the thing, then you actually have to read it. You could probably get an VMS Internals and Data Structures book for under $30.
That said, let me try to translate that gibberish into English.
System calls do not use the same kind of linkage (i.e. method of passing parameters and calling functions) that other functions use.
Rather than executing a call instruction of some kind, to execute a system service, you trigger an exception (which in Intel is bizarrely called an interrupt).
The CPU expects the operating system to create a DISPATCH TABLE and store its location and size in a special hardware register(s). The dispatch table is an array of pointers to handlers for exceptions and interrupts.
Exceptions and interrupts have numbers so, when exception or interrupt number #1 occurs, the CPU invokes the 2d exception handler (not #0, but #1) in the dispatch table in kernel mode.
What exactly are the wrapper functions that are contained inside and are they also written in assembly language ?
The operating system devotes usually one (but sometimes more) exceptions to system services. You need to do some thing like this in assembly language to invoke a system service:
INT $80 ; Explicitly trigger exception 80h
Because you have to execute a specific instruction, this has to be one in assembly language. Maybe your C compiler can do assembly language in line to call system service like that. But even if it could, it would be a royal PITA to have to do it each time you wanted to call a system service.
Plus I have not filled in all the details here (only the actual call to the system service). Normally, when you call functions in C (or whatever), the arguments are pushed on the program stack. Because the stack usually changes when you enter kernel mode, arguments to system calls need to be stored in registers.
PLUS you need to identify what system service you want to execute. Usually, system services have numbers. The number of the system service is loaded into the first register (e.g., R0 or AX).
The full process when you need to invoke a system service is:
Save the registers you are going to overwrite on the stack.
Load the arguments you want to pass to the system service into hardware registers.
Load the number of the system service into the lowest register.
Trigger the exception to enter kernel mode.
Unload the arguments returned by the system service from registers
Possibly do some error checking
Restore the registers you saved before.
Instead of doing this each time you call a system service, operating systems provide wrapper functions for high level languages to use. You call the wrapper as you would normally call a function. The wrapper (in assembly language) does the steps above for you.
Because these wrappers are pretty much the same (usually the only difference is the result of different numbers of arguments), wrappers can be created using macros. Some assemblers have powerful macro facilities that allow a single macro to define all wrappers, even with different numbers of arguments.
Linux provides multiple _syscall C macros that create wrappers. There is one for each number of arguments. Note that these macros are just for operating system developers. Once the wrapper is there, everyone can use it.
How does a macro call an assembly language instruction ?
These _syscall macros have to generate in line assembly code.
Finally, note that these wrappers do not define the actual system service. That has to be set up in the dispatch table and the system service exception handler.

How user programs like in Java, make system calls/ call kernel subroutines?

I want to have clarity on user space program and OS interaction. In the context of a file I/O, I want to know how a user app like a java file i/o API read() may work.
Since file operations are accessed by POSIX system calls like open() close() read() write(), how does the java code calls these system calls ?
When we compile the java code, what kind of instructions the java read() API would be compiled to ?
Its said, user programs raise traps/software interrupts to make system calls. So does Java read() API is also raise traps ? Are there APIs in java to Raise traps ? If yes, so those APIs might be compiled to trap instructions like 'INT' ? But then does INT calls higher layer POSIX system calls or some fixed ISRs (Interrupt Service Routines) ?
I am confused and trying to know step by step... from compilation to execution- how system calls are done in this scenario.
Please help me with this simple concept.
Perhaps I got a very good clarification on http://pages.cs.wisc.edu/~remzi/OSFEP/intro-syscall.pdf
Hence I enfer the following flow: Java Code -> JNI -> read() syscall in C -> kernel subroutines.
But last doubt: How JNI which is in Java, calls C codes ?
The answer to this question is java run time environment.It provide a system call interface which intercepts java function call in the api and invokes the necessary system call

Pause/Resume embedded python interpreter

Is there any possibility to pause/resume the work of embedded python interpreter in place, where I need? For example:
C++ pseudo-code part:
main()
{
script = "python_script.py";
...
RunScript(script); //-- python script runs till the command 'stop'
while(true)
{
//... read values from some variables in python-script
//... do some work ...
//... write new value to some other variables in python-script
ResumeScript(script); //-- python script resumes it's work where
// it was stopped. Not from begin!
}
...
}
Python script pseudo-code part:
#... do some init-work
while true:
#... do some work
stop # - here script stops and C++-function RunScript()
# returns control to C++-part
#... After calling C++-function ResumeScript
# the work continues from this line
Is this possible to do with Python/C API?
Thanks
I too have recently been searching for a way to manually "drive" an embedded language and I came across this question and figured I'd share a potential workaround.
I would implement the "blocking" behavior either through a socket, or some kind of messaging system. Instead of actually stopping the whole python interpreter, just have it block when it is waiting for C++ to do it's evaluations.
C++ will start the embedded runtime, then enter a loop of some sort that waits for python to "throw the signal" that it's ready. For instance C++ listens on port 5000, starts python, python does work, connects to port 5000 on localhost, then C++ sees the connection and grabs the data from python, performs work on it, then shuffles the data back over the socket to python, where python then receives the data and leaves the blocking loop.
I still need a way to fully pause the virtual runtime, but in your case you could achieve the same thing with a socket and some blocking behavior that uses the socket to coordinate the two pieces of code.
Good luck :)
EDIT: You may be able to hook this "injection" functionality used in this answer to completely stop python. Just modify it to inject a wait-loop perhaps.
Stopping embedded Python