As I understand, If I build an UEFI application with the StdLib Pkg, it has a dependency to the ShellPKg and the application must be started through the new Shell (UEFI Interactive Shell v2.1 EDK II UEFI v2.60). So starting the application manually through the 2.1 Shell built with ShellPkg works, but not with the EBL shell, or through the gBS->StartImage.
To my question: is it possible to start an UEFI application that is using a Library built with StdLib through the BDS (boot device selection), without starting an Shell first and use startup.nsh to startup the UEFI application that you want?
For example trying to bootup the UEFI application with StdLib, with the following command in BDS won't work as its not started through Shell:
Status = gBS->StartImage(ImageHandle, NULL, NULL);
So what I would like to achieve is a function call to execute a UEFI application with StdLib package during the boot in BDS. Most preferable not through startup scripts.
BR
Gigu
Yes, you can execute UEFI application through BDS.
To launch/execute UEFI application through BDS we need to use BOOT#### NV variable to launch/execute UEFI application.
To load UEFI driver through BDS we can use DRIVER#### NV variable to load DXE, UEFI drivers.
Using this way we don't need to use Starup.nsh way or Shell environment to launch/execute UEFI application.
Related
I need to implement a system with a third party device using a Raspberry Pi.
The device is connected using USB, and the manufacturer has provided a few software implementation demos, and the driver library includes a C++ header file and a C shared object file compiled for i386.
I need to be able to run this driver library on the RPi. My idea is to build a C++ program I can use to get the data from the device, compile for i386, and run it with qemu-i386. I have tried to execute this idea, but have run into some problems relating to the linking, like the executable looking for ld-linux.so.2, which my RPi doesn't have.
How can I get this to work?
It's a bad idea to run it for QEMU, instead install box86, link, it'll automatically take over when it detects a 32bit x86 executable and should work great for your use case
Take python as example, a C/C++ program can load libpython.so dynamically and create a python VM, and then feed user scripts to the python VM.
Is their a way to use go like this? Namely, dynamically load it from the user's system environment.
We want to embed go to our project for scripting, but we don't want to package it to our final binary program.
Thanks.
On some platforms like Linux you can build your Go code with -buildmode=c-shared to get a shared library which can then be linked into a program written in another language like C.
Some examples and documentation are here: https://github.com/vladimirvivien/go-cshared-examples
Note that this does not make Go a scripting language--you still need to build shared libraries from Go code. However, you could conceivably build them while your application is running and load them using dlopen() and dlsym(). This is the same as how you could compile C code by launching a C compiler from inside your application, then load it.
How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot. My requirement is to reinitialize the board and drivers using my binary...
I can replace the U-Boot in the boot medium(here NOR Flash) with my binary but my requirement is to not removing the U-boot from NOR flash and I should load my binary from LAN network using "tftp" command.
Thanks and Regards,
Veerendranath
How to boot bare board binary from U-Boot?
Use U-Boot's go command to execute any kind of standalone program.
How can we boot independent bare board binary(not standalone binary which runs using U-Boot environment and not linux kernel) from U-Boot.
Use U-Boot's go command to execute any kind of standalone program.
... I should load my binary from LAN network using "tftp" command.
Use U-Boot's tftpboot and go commands to execute any kind of standalone program. (The abbreviated tftp command has been deprecated now that there's also a tftpput command.)
Here problem is when I use go command my program has to use U-Boot service functions(I mean standalone binaries will run in U-Boot environment)...
You're misinformed, there is no requirement that you have to "use U-Boot service functions".
Build your standalone program independently of U-Boot, and it will execute completely independent of U-Boot.
But I can't boot using bootm or any other boot commands provided by U-Boot as my binary is not in kernel format.
There is no "kernel format"; that's why U-Boot uses the mkimage wrapper to identify binaries.
The bootm command is designed specifically for the booting requirements of OSes such as the Linux kernel (e.g. a buffer containing the command line parameters) by specifying the characteristics of the binary.
Use U-Boot's go command to execute any kind of simple, standalone program.
If you have issues executing your binary when using the go command, then the problem lies with your program, e.g. taking control of the processor and initializing its C environment.
ADDENDUM
When I use the term standalone program, I'm referring to the generic definition (aka bare-metal), and not the U-Boot-specific definition related to its examples/ directory.
FWIW I have used the go command for both kinds of "standalone" programs.
U-Boot describes its "standalone" as
* "Standalone Programs" are directly runnable in the environment
* provided by U-Boot; it is expected that (if they behave
* well) you can continue to work in U-Boot after return from
* the Standalone Program.
Note that the use of the U-Boot environment is optional.
A standalone program is not required to use the U-Boot environment, especially if there is no intention of returning back to U-Boot.
There is nothing in U-Boot to detect or restrict the behavior of a standalone program.
If you cannot get your standalone program to work with the go command, then the problem lies with your program, and not the go command.
The go command merely transfers control (i.e. a branch instruction to the specified memory location), and places no restrictions or requirements whatsoever on that code (other than what is sensible for operation of the system).
Use an in-circuit emulator (ICE) or JTAG debugger to resolve problems with your code, especially when your program does not use the existing stack.
ADDENDUM 2
Instead of the ambiguous go command, the mkimage wrapper does provide for the standalone image-type for use with the bootm command.
See Creating a bare metal boot image, but don't expect different results from a go command.
The advantages of using a wrapper and bootm over go is that the downloaded image (a uImage file) can be:
identified/verified with the iminfo command,
compressed (e.g. gzip, bzip2, lzo) or uncompressed.
You can create the boot.bin with fsbl, bitstream, uboot.elf and you applications. Then flash in the QSPI flash and choose to boot from it.
Or you can boot from TFTP. Here you need to create the boot.bin just with fsb, bitstream, and uboot.elf. You need the change the uboot header file to force it boot from tftp like tftpboot 0x0 hello.elf. Once booted it will grab the elf/bin file with tftp and boot the board with bootelf or go command.
The same you can boot from SD card if there is one.
iam currently using NIOS II with Quartus II v12.0
Since Nios II uses Language C, it would be allowed to open files, but the command fopen("filename","readmode"); is not avaiable for using, cause its not located on stdio.h from Nios, so my doubt is, how can I open a file in Nios? would I need to use a new library? will I have to change my codeblocks stdio.h to my Nios one?
Thanks for now.
I just took a look at the Nios II Software Developers Handbook, and see that uses the Newlib C library, and the developer manual refers to fopen() so I can only assume that you are incorrect. Newlib is open-source, so you could investigate for yourself.
Even then Newlib library does not implement a file-system in any case - stdio is not a filesystem; rather it provides a standard interface to any stream I/O device. The file-system itself is normally provided by an operating-system or third-party library.
Even if you have a file-system, you still have to provide the low-level interfacing between it and stdio in any case, via the Newlib syscalls stubs in this case.
NiosII defines only the processor architecture, any file system hardware would be entirely proprietary, so it is not possible to have file-system support that works out of the box in any case - it would have to be adapted to your hardware.
What kind of device are you intending on creating a file-system on? You might use a third-party library such as EFSL or ELM FatFs. You could use them stand-alone or integrate them into stdio by implementing appropriate syscalls.
I have used the Demonstration project from DE2-115 DVD and got an FAT library, now I can open files.
I am working on ARM processor based system which runs linux. I have an application running on it which is based on Qt. This Qt application is linked with static library which is my main concern. This Qt app invokes threads from this library.
I want to know the RAM used by the threads which are invoked from the library.
Please note that I want RAM usage from those invoked from this library alone not Qt.
Thanks in advance!
Regards,
Rocky.
How about ps -m -o rss,vsz?