The U-Boot v2021.01 configuration menu has a configuration option Enable U-Boot API under the API section. The help page provided below isn't explanatory enough.
This option enables the U-Boot API.
So, what actually is the U-Boot API? What kind of things does it offer us?
It is an API that can be used to create a standalone application that is run by U-Boot and then typically returns control to U-Boot. In general, it's use is discouraged, and on modern systems if you must have a standalone application, using the EFI API instead is preferred.
Related
Iam working yet with C program on STM32 microproc, what contains a web server, accesible by the user via web gui(HTML and javascript files). The web gui part became more complex, and it needs higher level operations.
The questions: is it possible to embed a node.js program with some node modules? Does it work with the C webserver, or the node program have to make the webserver, and communicate with the C program?
Or there is an other solution what is better in this case?
This question maybe seems dumb, but i didnt find documentation about it.
After a research I found some solutions:
Node.js for Embedded Systems
The book can then guide you to jerryscript which:
is a lightweight JavaScript engine for resource-constrained devices
such as microcontrollers
You can find there that it's also used with the STM32-Discovery board.
Node.js on clientside
This article guides to Browserify which allows to run node on clientside.
Just make it simpler
You could use HTTPD implementation shipped with LwIP. There is a script called makefsdata which allows to convert html, js, css ... files into c-arrays. This implementation also supports POST method.
I'm looking for an embedded RTOS that supports the dynamic upgrade/replacement of a thread. This should be used to allow the user to perform a network based upgrade of the running application. This should basically work like a bootloader, but without replacing the entire application.
My target architecture is an ARM Cortex-M4 processor, so I am looking for a deeply embedded RTOS such as FreeRTOS.
I'am not sure that I get your question right, but for me it seems that dynamic modules support is what you need. Using this feature you could implement partial-firmware OTA update. If so, you could look at NuttX, RIOT OS or Contiki. It looks like that they all support the requested feature. If you are asking about live update, than you probably should consider Minix 3, but I'am not sure that it fits your target device.
I have noticed there are some profiling source code under arch/arm/kernel:
perf_event.c
perf_event_cpu.c
perf_event_v6.c
perf_event_v7.c
perf_event_xscale.c
I can't understand the hierarchy of those files and how can I use them? can I assume they are always exists and use them in a kernel module? my kernel module runs on Cortex-A7 or Cortex-A15 cores.
There seems to be a lot of very useful things under /arch/arm/kernel/ directory but no documentation about the capabilities ? how comes ?
Perf_event does provide an API that can be used programmatically, but the documentation is sparse at best. Vince Weaver made the best resource for using the perf_event API here: http://web.eece.maine.edu/~vweaver/projects/perf_events/
He also provides some example code for recording counters.
However your best bet is to use an API that wraps perf_event and makes it more accessible, like PAPI (http://icl.cs.utk.edu/papi/)
EDIT: Since you want to do this from a kernel module, PAPI will not be available. The perf_event API still is, however.
The functionality in the perf_* files is used by/provided for tools like oprofile and perf tools.
And no, they are not ALWAYS available, as there is a config option (CONFIG_PERF_EVENTS) to enable/disable performance measurements.
The functionality is not really meant to be used from another driver. I'm pretty sure that will "upset" any user of oprofile or perf.
Is there any C/C++ lib(of course Open-sourced) for developing applications of stateful inspection on network session, for instance, following the FTP session state?
I know there is a pre-processor module in Snort namely stream4. But an independent lib is more flexible for us which implemented in C is preferred.
Thanks.
I'm not sure how applicable this will be to whatever you're doing, but you could try to extract the Linux NAT connection tracking code and adapting it to your needs. It's not a nice pre-made library, but it's a start.
I need to create a web-controlled application (that lives in the browser) that can connect to and read data from devices connected via USB or the serial port.
At the moment, I'm using an ActiveX control to do this. However, I'm like to re-write this system to make it cross-browser (support Firefox) and eventually cross-platform (support Safari on Mac). ActiveX is neither cross-browser or cross-platform, so I'm looking for an alternative technology.
My first inclination would have been to use Silverlight, because Silverlight 4 grants access to COM Automation. Unfortunately, this only works with OOB (Out of browser) Silverlight applications - in-browser systems are still bound in a sandbox and do not have access.
So, what technologies exist (frameworks, browser plug-ins, etc) that will allow me to interface with a USB/Serial device from within a browser-based web application? What are the pros/cons of each?
I think your best bet is probably Java in this case. USB, though an industry standard in terms of protocol is definitely not standardised in terms of bare-metal implementation. For this reason, you will still need a different Java USB implementation for each distinct platform (windows, linux, osx, bsd) that you intend to support. Of course you will also have to pay for code-signing certificates so you can try to convince people to grant your application the kind of access it requires; something that browsers try very hard to deny access to and most people in this day and age are very unwilling to grant. That said, there's an old IBM article here on the various Java USB projects that makes a good read. Good luck.
http://www.ibm.com/developerworks/library/j-usb.html
-Oisin
It might be painful, but you could use a signed Java applet. Signed Java applets can have full access to the user's system.
Java does not have built in USB support, so you would probably need to roll your own JNI interface to native USB APIs.
Using JNI in an applet can be tricky. I've done it before. If you Google the topic, most results say "don't do it" or "you can't do it." Well, you can do it.
This is how I did: I packaged the native libraries (DLL, so, etc) inside the applet's JAR, and then read the native libraries out of the JAR using e.g. getResourceAsStream. I then wrote the libraries out to an appropriate location on disk (e.g. ${user.home}/.myapp/.) I then used System.load to load the JNI DLL.
There can be some ClassLoader issues with JNI libraries and applets. The issues are subtle and difficult to explain. They basically have to do with the fact that a JVM can only load and bind a given JNI library once per VM instance, but applets get instantiated a lot, often with their own new ClassLoader, which can be problematic. The work that Sun did on process separation in the Next Generation Browser Plugin may have relieved some of these issues, but your users will only have this if they are using Java 1.6.0_10 or later.
It is also possible to use JNA within a signed applet. I would not recommend using JNA to access USB APIs directly. But JNA can sometimes be a big time saver for accessing simple native functions. Although once you've set up your JNI infrastructure, JNA probably has less value.
Here are a few other random thoughts:
Java WebStart - Can be launched from browser, but runs outside the browser
Microsoft ClickOnce - Can be launched from browser, but runs outside the browser
Flash / AIR - Can't escape its sandbox
The best solution I've come across thus far is the cross-browser/cross-platform plug-in system called FireBreath. This is a framework built in C++ that allows you to generate plug-ins for both ActiveX and NPAPI from the same codebase.
So build it once, make it work, and it compiles to one DLL that you can deploy in either environment: ActiveX for IE, NPAPI for everyone else.