My phone’s Android has under /system/lib/hw the following files among others:
sensors.exynos4.so
sensors.smdk4210.so
Those dynamic libraries are somewhere in the chain for sensors like compass, gyroscope and ambient light.
The first file (sensors.exynos4.so) comes from the the distribution itself (running CyanogenMod 10.1 for i9100), the second (sensors.smdk4210.so) is what I fished out of the stock ROM for my phone (SHW-M250S, “Korean S2”, a variant of the i9100) and copied it there.
Question1: What is using those files?
Doing an ldd (actually a readelf or objdump) over all binaries and libraries in the system did not reveal any users of those files. My conclusion: someone has to load them like plugins during runtime after dynamic linking! But who/what? (source code file name or link to a code browser, please)
The users of those libraries switched from the first to the second without any configuration (after I placed it there). I would like to dig into this mystery.
Question2: Where is the source of those files?
The files contain (at least) the configuration of the sensors (like it’s positioning on the board, value ranges and steps). I want to generate a correct one for my phone. If I have the source of both, it would be easy to do so. – With only the CyanogenMod version, I can at least guess the necessary corrections.
Notes:
No guesswork answers.
If part of your answer is “binary”:
point me to the blobs in the CyanogenMod source or the script that pulls them.
follow the chain to the first open source library/program which uses them.
The questions are not really device specific. – Answer with any device in mind, the situation should be similar (AOSP, AOKP, CyanogenMod, ...).
They are binary blobs.
Has the sensors.exynos4.so and other proprietary blobs
https://github.com/chris41g/proprietary_samsung_epic4gtouch/tree/master/proprietary/lib/hw
The blobs can be pulled from a running device with the extract-files script which reads a list of the proprietary files from proprietary-files.txt in the project for whatever device you are building CM for.
Try googling the files maybe or looking through the CM tree or their wiki.
The HAL is the Hardware Abstraction Layer is the interface that is used to get sensor data from the kernel/device drivers back to userspace.
Found this pdf which discussed building the Android HAL but for a different device and the output described there is
After having successfully downloaded and compiled the Android sources, the user can compile and add/substitute the sensor HAL library.To do this, copy the sensor HAL library folder in the android sources path, usually located in:
[Root Android Sources]/vendor/[vendor name]/[boardname]/
Before the build operation of the library, the user must initialize the Android environment:
[Root Android Sources]$ source build/envsetup.sh
[Root Android Sources]$ lunch [target board]
It is now possible to build the library; just launch the “mm” command in the HAL folder. The result of this process is a dynamic library located in:
[Root Android Sources]/out/target/product/[board name]/system/lib/hw/sensors.[board name].so
In the case of the sensors, the SensorService loads the HAL so it can talk to the sensors.
HAL
Building HAL
Update:
Did some more digging around my CM tree
device/samsung/i9100 contains an Android.mk file that builds sensors.exynos4.so.
The .mk file specifieds the module as
LOCAL_MODULE := sensors.$(TARGET_BOARD_PLATFORM) which is set in
device/samsung/galaxys2-common/BoardCommonConfig.mk.
There is source in device/samsung/i9100/libsensors for this device. Looking at device/samsung/i9100g however there is no libsensors and that device requires running the CM scripts to pull the blob from a running device so the availability of source still varies based on device.
Also just an observation that the BoardConfig sets some values to smdk4210.
I can’t answer yet what uses those files, but the source for sensors.*.so is nice to navigate to in CyanogenMod:
Each supported device has a wiki entry which points to the github repo (e.g. i9100 source). There you find additional repositories in cm.dependencies which together cover what you need to build CM for the device in question (e.g. the kernel, common files shared among a group of devices, ...).
In case of the i9100, we can stay in the root repository. In libsensors/Android.mk we see that sensors.<ro.product.board>.so is produced by the files in this directory. The source is all there (for the i9100 device), except libakm.so (binary, according to ../proprietary-files.txt), which is dlopen()ed in AkmSensors.cpp. libakm.so is used for enabling and disabling some sensors, but also creates /dev/input/eventX, a virtual input device reflecting three of the sensors available (compass, acceleration, orientation). (I don’t know how the kernel “runs” virtual devices.)
(sensors.*.so is the Hardware Abstraction Layer. – For the i9100 it handles some /dev/input/event* devices. I didn’t check the kernel for details of those...)
Related
This is the first time I am building yocto images. I first read this list of images in the documentation and selected core-image-sato-dev, since I wanted to have some image where I could do some hello world .
The doc says
core-image-sato-dev: A core-image-sato image suitable for development
using the host. The image includes libraries needed to build
applications on the device itself, testing and profiling tools, and
debug symbols. This image was formerly core-image-sdk.
Something that I misunderstood was that the development is using the host
Yes, I cannot find gcc in /usr/bin. So this image does not have the c compiler (it has make though)
So what should I do? Is there a way to add it? Or should I go for core-image-sato-sdk??
What exactly does this imply?
core-image-sato-sdk: A core-image-sato image that includes everything
in the cross-toolchain. The image also includes development headers
and libraries to form a complete standalone SDK and is suitable for
development using the target.
GCC or any other compiler is not meant to be part of that image. As the quote from the docs you've provided says, The image includes libraries needed to build applications on the device itself.
All core-image-sato-dev does it inherits core-iamge-sate and adds dev-pkgs to IMAGE_FEATURES which ships development packages.
What you're looking for is tools-sdk in IMAGE_FEATURES.
This question already has answers here:
CMSIS & STM32, How to begin? [closed]
(2 answers)
Closed 1 year ago.
As I want to write an efficient program to use minimal RAM & Flash, I want to remove HAL library completely from my project & program only in registers.
I want to use cubeIDE for compiling & Debugging but I do not know how to remove HAL library from my project(It seems that HAL library created and attached to project by default when generating project).
Is there any practical way?
Best!
There is an option in STM32CubeIDE project generation which allows you to create empty projects.
The empty project comes with the following:
main.c : Mostly empty
syscalls.c : I don't know what it is for but probably useless.
sysmem.c : Implements _sbrk() function, which is used by malloc() & new()
startup_stm32[xxxxxxxx].s : Startup file in assembly. You can leave it as it is
[xxxxxx]_FLASH.ld : Linker script file. Most of the time, this can be left unchanged.
But you need some additional libraries & files.
CMSIS Library : This includes some core functions common to all Cortex M devices. The core library is header only, and it's the only one you need to get started. There are some additional CMSIS libraries, like the DSP library which you may need depending on your project requirements. I suggest downloading it from its official repository.
Official STM32 headers from ST : This is actually called STM32Cube[xx] (STM32CubeF4 for example) and includes the Cube & HAL framework you want to get rid off. But we're interested in CMSIS compliant device headers. You can delete the rest. It also includes a version of CMSIS which lags behind the official one. Since you can download the latest CMSIS from its official repository, you don't need the one included in Cube package. You can download the relevant package from ST. For example, this one is for F4 series.
Once you have the needed packages, you need to configure STM32CubeIDE such that your project uses the newly obtained libraries. Basically, you need to add some additional include directories and symbol definitions. And there is an additional system_stm32[xxxxx].c file, which can be found in STM32Cube package and needs to be included in your project.
Here you can find a somewhat related answer.
Here is an example STM32CubeIDE blinky project I've created for the Blue Pill board (STM32F103C8). It may be somewhat outdated but it's probably still useful.
The method I've described probably isn't very practical. Some people suggest creating a normal Cube & HAL project and than pruning the unused parts.
I am working with STM32 B-L072Z-LRWAN1 discovery kit. How can I add I-CUBE-LRWAN libraries externally, after i have created a project on CubeMX for B-L072Z-LRWAN1 discovery kit. Because project which i have created have not radio libraries. I am coding with System Workbench.
Before this project, i used Ping-Pong example. It was divergent for create a fresh project. So i am trying to make a new project for Lora.
Thanks for answers.
I'm going to answer it from te point of view of a Keil project because that is the program wherein I've done it but these steps should be interchangeable with the IDE. It mostly involves copying the code and adding the right linker and source paths.
The I-CUBE-LRWAN project has been setup such as that the parts of the project have been separated. The root directory of the project consists of three folders: Middlewares, Projects and Drivers. These folders contain both .h and .c files inside their tree structure.
Drivers
The Drivers folder contains all the files related to the specific board you are using, the HAL (Hardware Abstraction Layer), CMSIS and the BSP (Board Support Package). The HAL and CMSIS provide a generalized interface towards the device and when using these creates code that can be ported to other STM32 platforms by changing out the CMSIS board specific definitions. I would recommend that when you create a project you tick the box to include all library files in your project. This will make compilation take longer and your project bigger but will also prevent you from fussing about with missing libraries. The BSP contains Board Specific interfaces for interfaces present on your platform. This includes LEDs and buttons on the L072Z-LRWAN1 and in case of the STM32l4 nucleo the joystick/LCD.
I would recommend that you copy your board specific BSP (.h and .c) into your project and use them as a standardized interface to board specific features. You should create a new BSP .h/.c pair when you are using a custom board.
Projects
The Projects contains your project specific code and contains the business end of your application. A bit of a bump in the road comes up here as ST has chosen to implement all their LoRaWAN code inside the main.c file. I would recommend that you take out all the LoRaWAN related initialization and transmission code (generally anything related to LoRaMainCallback_t) and put it inside a separate file with a defined interface. This is a bit of work but will pay dividend in the fact that your normal code has been separated from your LoRaWAN handling. I've stored my LoRaWAN code inside the file lorawan.<h|c>. With regard to the rest of the files: move the contents to a separate folders in your project called LoRaWAN/App/inc/ and LoRaWAN/App/src/. This pertains to the files: debug.c, hw_gpio.c, hw_rtc.c, hw_rtc.c, vcom.c, debug.h, hw.h, hw_conf.h, hw_gpio.h, hw_msp.h, hw_rtc.h, hw_spi.h, utilities_conf.h and vcom.h. Add the inc folder to your include path (the -I option) and the source files to your project.
Middlewares
The Middlewares folder needs to be copied from the source project to your target project and every inc folder or folder with .h files needs to be added to your include path and every source file needs to be added to your project. I would recommend that the folder structure is kept inside your IDE as to make your navigation between project and folder structure easier.
Another postive effect of keeping the folder structures similar is that upgrading your code with a newer stack should be easier as the files can be found in a somewhat same place in both projects.
Preprocessor defines
And a most important step. You need to take the DEFINE parameters defined inside the project and copy the into your own project. This can be found inside the Keil project (and the other projects also but in other places) under: options for target x->C/C++->define. It contains something akin to these values: STM32L072xx,USE_B_<board name>,USE_HAL_DRIVER,REGION_EU868,DEBUG,TRACE. As you can see I'm using: a Murata radio with integrated STM32, the EU 868 region and debugging and tracing options.
It should be possible to include "hw.h" and compile your program when you've done everything right.
I want to change the current implementation of MTD (flash drives) while using YOCTO project, to support new commands using its ioctl commands. Yet, I couldn't find the implementation of the MTD flash drivers, just the header files and the usage of the driver while the kernel loads and makes the partitions. Can someone please point me to the the implementation files?
Thanks.
The implementation of the MTD drivers is not directly related to the Yocto Project, but part of the Linux kernel. So if you want to modify the drivers, you have to work on those in the kernel itself. They are located in the source tree at drivers/mtd.
See also:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/mtd
I'm developing a bare-metal embedded application; no OS or MMU. I'm using a toolchain that consists of arm-none-eabi-gcc, ld and make. It requires some plugins to be dynamically loaded/unloaded and I don't know how to create script for this configuration.
The host application has a defined API for plugin system, it consists of function declarations for init_plugin() and execute_plugin().
There's several C files called plugin01.c, plugin02.c..., which are all implementing that defined API. I want to compile them and then place all plugins in exactly the same address space. There's only a single plugin loaded at once, so there's no problem with memory collisions. After compiling and linking I would extract these plugins from output file and load them separately into the target hardware.
I need help with solving two problems:
Linker should not complain about multiple different definitions of same function
Linker needs to place all code from pluginXX.c files into same memory range. It should reset the location counter after linking each plugin. It should assign same VMA and different LMA. Same VMA allows running plugin when it is loaded in that location, and different LMA allows me to extract compiled and linked plugins from output file.
For anyone interested, I managed to solve it.
The problem of conflicts in symbol names was solved by prefixing all sections with .pluginXX string, and renaming symbols to pluginXX_init_plugin and pluginXX_execute_plugin.
The problem of placing all plugin code into same address space was solved by using OVERLAY feature of linker. All plugins linked together with the host with just one linker pass, which guarantees that everything is linked correctly.
Before this, I tried two-step linking by partially linking only host code into an object file, which would then be linked with each plugin separately. This was waste of time. During the partial linking step, unused code could not be discarded (--gc-sections option was not available together with partial linking --relocatable option) and code would not fit into available memory.