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
Related
I'm doing memory optimization and replacing the HAL implementation with commands that directly change bits in registers. To validate these changes, I'm changing the functions, debugging and putting the breakpoint after the function is executed, then taking snapshots of the peripheral registers through the SFR (Special Function Registers) feature of the CUBE IDE.
These snapshots are made with printscreen, my intention would be to snapshot with a log file, export all registers in a text file to use a difference program analyse. I do this for both the code using HAL and my version, then I can validate if it is stable, assuming that if the registers are equally configured, everything will work as expected.
See some sample:
implementation direct in register
implementation using HAL lib
I discovered a software (winIDEA Community Edition) that has this functionality to export to text file, it needs a little maintenance, last release was made in 06/2020. Using the examples themselves I had some problems, including one of them the software breaks and closes.
winIDEA Community Edition exporting SFR option
Does anyone have an alternative? Eclipse plugin or even a third-party tool that debugs with stlink and captures register values.
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.
Recently, I decided to learn a new programming language and I know that C++(which is the language I am going to learn) is really good and fast.(fast execution)
And now I have a question about C++(and maybe C)
Is it possible to make a program that runs on every device?
like bypassing the OS and run commands/0s and 1s directly on the CPU?
or
run on a computer that does not have an OS installed, like creating your own OS?
And if it's possible then what is the difference between the .exes(windows executables) and the programs with No-OS support? (On compilation and on the file as file)
C is older than C++ but you are right that it is similar to C++ because it is compiled to binary code. When you write a C/C++ program you compile it to binary using a compiler.
Today, most desktop computers run on a variant of x86 architecture processor which started with Intel's 8086. The x86 processors are well documented. I never implemented an assembler so I can't tell exactly how to go from high level code (C/C++) to binary but I can link to the documentation which tells you how to do that. Here you have the download link for the Intel software developer manual: https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html. Appendix B of volume 2 of this download link has the instruction encoding explanations. Here's a picture of the format of an instruction:
On x86 (and all other architectures like ARM), the instructions have a certain conventional encoding that the compiler knows and that it will use to compile your high level code to binary code. Today, when you write an OS, you use a screen and a compiler and other tools readily available to compile to binary code. With gcc/g++ on Linux you have the freestanding and static flags which allow to include all the code in your final executable and to make sure the code is self-standing.
If you write code on Linux and want to develop an OS, you need to know C/C++ quite well because you cannot use anything which relies on the standard libraries like printf() or cout. This means that you are left with the basic C/C++ like pointers (which are very important) and function calls and other stuff. You need to know quite well how the language works to control memory properly and to be able to not use stuff of the language which depends on the presence of an OS.
The .exe file is a conventional format which contains binary code. The Linux equivalent of a .exe file is a .elf file. There's nothing wrong about compiling an OS to a .exe file (or a .elf file) and parsing that file from a bootloader to jump to its entry point. The difference is that you need to tell your compiler and you need to write a program which doesn't rely on the presence of an OS to work (because you are the one who writes the OS). You are thus left with the basic C/C++ like pointers and structs. With C++ you can use classes as well because they are compiled to function calls.
For freestanding C/C++ code to work, you need to set up a hardware stack with the RSP register of the CPU. This will allow your code to call functions (other than main()). Freestanding C/C++ code relies on the presence of a stack but nothing else to work properly because all high level lines of code that you write will be compiled to CPU instructions which don't rely on anything else. If you wanted, you could even forget the stack and do everything in the main function and forget about functions. You would thus be left with pointers and structs. I think a minimum is to have functions so that you can organize your code properly. Linux is really just a freestanding, statically linked C program compiled to a .elf file and compressed with gzip. Linux follows the multiboot specification which tells how to boot it. It means that, to write Linux, the developers used only pointers, structs and functions. Pointers are compiled to memory fetch code which is one instruction in itself. Structs are compiled to data. Functions are compiled to relative jumps (short jumps), pop and push instructions (using the stack for the arguments). This is pretty much it.
You can definitely write your own OS because otherwise how would Microsoft develop Windows. To write an OS, you need to use tools at your disposition and compile freestanding and static code. Then you need to write a custom bootloader like a legacy bootloader in assembly or a UEFI bootloader in C compiled with specialized tools like EDK2. EDK2 is a compiler for UEFI bootloaders. Once you have an EFI app, you can launch that app and parse a statically linked freestanding .elf file (or .exe file) from the app. Then you can jump to the entry point of that .elf file. You can use the UEFI environment to load the .elf file from the hard disk.
Remember when you last installed an OS. You basically use a tool like Media Creation Tool from microsoft to write a small OS on a USB stick. Then you choose that USB stick to boot from the BIOS and you install the OS to an hard disk. Developing and OS is the same. You use an existing compiler and existing OS to write custom OS code. Then you write that code to a USB stick (or an hard disk) and then you test the code. A better option is emulation. You do that using specialized virtualization software like QEMU or Virtual Box to test your custom OS.
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...)
I'm working on a cosimulation in simulink using either 2012a or 2011b, and System Generator 13.1. When building the library block for the hardware to be loaded onto the zynq fpga, I configure the system generator to be a 'Hardware Co-Sim,' everything through this step works. However, in the simulink/pc end of the simulation, I haven't found any good resources for how to configure. Am I correct in assuming it also should be set as a hardware co-sim and not some other setup (HDL netlist) or anything like that?
Currently, the system seems to be loading the block just fine, but the jtag library is missing, not sure if this is a sysgen issue, or software versioning issue. My understanding is that sysgen is still in beta for 2012a.
Thanks in advance.
Yes, it should be set as a hardware co-simulation (Your board->connection type).
Configuring of board occurs when You start simulation. (Or You can program it manually using Impact and next check "skip configuration" in block properties).