I don't understand below configuration in the configuration file in the u-boot.
CONFIG_SYS_EXTRA_OPTIONS="SYS_SDRAM_SIZE=0x20000000"
It seems like setting DRAM size in the u-boot code.
But, I can't find the code which uses this configuration.
If you know this configuration how to work, please let me know.
The little history about the configuration, earlier board.cfg is used prior to kconfig.
boards.cfg was the main database that contained ARCH, CPU, etc. This is moved to kconfig in that options field of boards.cfg was converted as
Options -> CONFIG_SYS_EXTRA_OPTIONS defined by Kconfig
CONFIG_SYS_EXTRA_OPTIONS is defined as an extra option, also this can be set using CONFIG_SYS_SDRAM_SIZE as well.
After building the uboot go to the build dir and the corresponding board dir and you can simply grep for the string and you can see the sdram size.
From the README.kconfig
The option field of boards.cfg, which was used for the pre-Kconfig configuration, moved to CONFIG_SYS_EXTRA_OPTIONS verbatim now. Board
maintainers are expected to implement proper Kconfig options and
switch over to them. Eventually CONFIG_SYS_EXTRA_OPTIONS will go
away. CONFIG_SYS_EXTRA_OPTIONS should not be used for new boards.
Related
I am trying to implement the use of DSP in the STM32 F411RE board, but I cannot seem to include the necessary files without invoking numerous errors.
Background
I have previously had CMSIS and CMSIS-DSP working in Keil uVision, but given the code limit of 32k that puts me over the evaluation limit rather quickly. As such I have been attempting to include CMSIS-DSP into Atollic TrueStudio but this seemingly is difficult to accomplish: there is limited documentation available on the CMSIS-DSP to begin with and even less so for implementation in Atollic TrueStudio.
Some related resources can be found in the
Atollic TrueStudio User Guide
as well as
StackOverflow topic #1
and
StackOverflow topic #2
. Most other related topics I could find just refer to the use of Keil uVision or the User Guide without much further help.
Atollic TrueStudio does incorporate a in-built package manager where the base CMSIS is available for download, but it does not provide this option for the CMSIS-DSP pack.
Attempted solution
I have attempted to manually download the corresponding CMSIS package (STM32Cube_FW_F4_V1.24.0) and place the corresponding DSP package into the project file structure. This then permits the use of the DSP functions such as
#include arm_math.h or arm_rfft_fast_instance_f32 S; which can also be invoked with the use of the autocomplete functionality and as such are thus recognized by the IDE.
However, this process also invokes many errors as the included functions fail to recognize their header dependencies (such as the #include arm_math.h). I find it confusing that the main.c is able to recognize the #include arm_math.h command yet the functions included are not, but I nevertheless try to fix this by adding the CMSIS DSP to the included directories (found at 'Build properties --> C/C++ Build --> Settings --> Tool Settings --> C Compiler --> Directories`). However, this does also not remedy the issue at hand.
Code results
The function cannot find the header
However the main can find the exact same header
And the header is included in the build options -> directories
Just verified that it is also included in the 'path and symbols', which it should do automagically AFAIK once you include it in the build options:
Update
Since my OP I have made some progress, mostly via messing around with the includes, symbols and linker. I have now managed to defeat the original error (though unfortunately I have no idea how), but I have now incurred a large amount of additional errors for the startup_stm32 files.
These all appear to be bad instruction errors referring to the template files included in CMSIS (CMSIS / Device / ST / STM32F4xx / Source / Templates / ARM / ...), which somehow cannot interpret the various commands listed in these templates.
Example errors: bad instruction __heap_base
I have since figured out the issue for my project: including the CMSIS folder as available from the Github repo means that a lot of templates are present throughout the entire folder structure. When attempting to build / compile whilst these templates are still present it causes a lot of issues with invalidated types and re-defining errors.
Most of these templates are in a logical location, but some are buried quite deep down and may thus be difficult to find. I will try to make a video soon describing the process of adding CMSIS (DSP) from the github repo to your project in TrueStudio.
In the meantime, the following steps should make CMSIS and CMSIS-DSP work in your STM32 TrueStudio ProjecT:
Ensure that all templates (folders) are removed from the CMSIS folder. This may require some searching and experimenting: the particularly noxious ones are hidden in
../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/Device/ST/STM32xxxx/Source/{Templates}
whilst there are also other sets at ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Examples} and ../STM32Cube_FW_xx_Vx.xx/Drivers/CMSIS/DSP/{Projects} that I had removed for my project to compile / build succesfully.
Include all the folders that are named include in the folders. AFAIK you cannot just include the main ../Drivers folder, as includes do not appear to also include the underlying structure and it also seems to include errors for my project. Best to just include the folders manually: you can so so by right-clicking on the intended folder to include, click the option near the bottom "Add/Remove include path" and tick both boxes for release and debug before pressing 'OK' to include this folder. Repeat for the other 'include' folders.
Fish up the RTE_Components.h file located at ../STM32Cube_FW_xx_Vx/STM32xxxx-Nucleo\Templates\MDK-ARM\RTE. There are also files with this name (RTE_Components.h) available in the NN (Neural Networks) CMSIS-pack folder, do not touch those. Copy this file to any location that you have previously included (placed mine in ../Drivers/CMSIS/Include), and open it up in your IDE of choice. Add the line #define CMSIS_device_header " DEVICE_NAME.h " before any of the other statements and replace device name with your STM32 board name. For example, my RTE_Components.h file looks like
/*
* Auto generated Run-Time-Environment Component Configuration File
* *** Do not modify ! ***
* Project: 'Project'
* Target: 'STM32F410Tx_Nucleo'
*/
#define CMSIS_device_header "stm32f4xx.h" // define own board header, eg stm32f4xx.h or stm32f7xx.h
#ifndef RTE_COMPONENTS_H
#define RTE_COMPONENTS_H
#endif /* RTE_COMPONENTS_H */
Make sure that the device name for the CMSIS_device_header corresponds to the header .h
file located in ../Drivers/CMSIS/Device/ST/DEVICE_NAME/Include/DEVICE_NAME.h
Add the required symbols (right-click your project, go to properties, C/C++ General, Paths and Symbols; then go to the #Symbols tab) to define the FPU and your Cortex Core type. For me I need to add __FPU_PRESENT (either with no value or value '1') and because I have the Cortex M4 chip on the STM32F411RE I add ARM_MATH_CM4. This means that my list of Symbols looks like:
__FPU_PRESENT
__packed with value __attribute__((__packed__))
__weak with value __attribute__((weak))
-ARM_MATH_CM4
STM32F411xE
USE_HAL_DRIVER though this depends if you want to use the HAL or not
Again make sure that the necessary includes are well defined, as not including only 1 directory can lead to a large amount of errors. These can be found by going to project properties (right-click your project, option at the bottom), going to the C/C++ Build, Settings, then the Tool Settings tab, C Compiler dropdown and to the Directories option.
For my project I have the following include path's inside the project properties:
../Inc (should be by default)
../Drivers/CMSIS/Device/ST/STM32F4xx/Include (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc (should be by default)
../Drivers/STM32F4xx_HAL_Driver/Inc/Legacy (should be by default)
../Drivers/CMSIS/Include (should be by default)
"${workspace_loc:/${ProjName}/Drivers/Device/ST/STM32F4xx/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/Core_A/Include}"
"${workspace_loc:/${ProjName}/Drivers/CMSIS/DSP/Include}"
Hopefully this helps and works for you too!
Question
Is there a simple/reliable way to have VIM, on a project/directory specific base, either detect a special file (ie: custom .vimrc with a couple settings), or to change run-time settings based on the presence of a special tag/string/hash in a comment at the beginning of a c source (.c) or header (.h) file? The string/hash must map to a function/setting in the .vimrc file, and must not contain the actual settings themselves.
Background
I have a mutli-developer project where we all have a common set of code style settings for our various editors (emacs and vim, primarily), and we all adhere strictly to these settings, such as newline style (CR versus CR+LF), indentation (length, hard-tabs versus expanded-as-spaces), and so on.
Problem
I'm creating a few new projects that, for reasons beyond our control (ie: static code analysis tool we have to use), will require different style settings than ours. There are ways to bypass this in the static code analysis tool, but there's a non-technical/legal requirement that we avoid disabling "features" of this tool.
For each of these new projects, I would like to somehow make vi/vim aware of some special flag, either by the presence of a special file in the root of the project's directory structure, or by a special keyword/tag/hash/etc I could put inside a /* C-style block comment */. When vi/vim is aware of the presence of this "trigger", I would want it to invoke a function to override the style settings for newlines, indentation, etc. If this is possible, is it also possible to have several, mutually exclusive such "triggers" so that everyone has a common .vimrc and the project determines which style to utilize?
Question - redux
Is there a straightforward way to accomplish this?
One solution: modelines (:help modeline) for Vim and file variables for Emacs.
Those are special comments you put in your files that are interpreted by your editor. You can use them to set indent style, file encoding, etc.
In my opinion, modelines are ugly noise.
One solution for Vim: .exrc (:help 'exrc').
You can put your project-specific settings in a .exrc file at the root of your project. The manual claims this solution is insecure but I fail to see how normal functioning adult could be beaten by it. YMMV.
One solution for Vim: directory-specific autocommands.
That's the safer alternative mentioned at the end of :help 'exrc' but it requires each contributor to add stuff to his own vimrc so… not that useful I guess.
The definitive solution: editorconfig.
You put your settings in a .editorconfig at the root of your project and let each contributor's IDE/editor deal with it.
... to change run-time settings based on the presence of a special
tag/string/hash in a comment at the beginning of a c source (.c) or
header (.h) file?
Yes, they're called modelines. http://vim.wikia.com/wiki/Modeline_magic
They can appear at the start or end of files.
An example from some C sources of mine:
/* vim:ft=c:expandtab:sw=4:ts=4:sts=4:
*/
See :help modeline in vim for more info.
Central configuration
If it's okay to configure the specific commands / local exceptions centrally, you can put such autocmds into your ~/.vimrc:
:autocmd BufRead,BufNewFile /path/to/dir/* setlocal ts=4 sw=4
It is important to use :setlocal instead of :set, and likewise :map <buffer> ... and :command! -buffer ....
On the other hand, if you want the specific configuration stored with the project (and don't want to embed this in all files via modelines), you have the following two options:
Local config with built-in functionality
If you always start Vim from the project root directory, the built-in
:set exrc
enables the reading of a .vimrc file from the current directory. You can place the :set ts=4 sw=4 commands in there.
Local config through plugin
Otherwise, you need the help of a plugin; there are several on vim.org; I can recommend the localrc plugin (especially with my own enhancements), which even allows local filetype-specific configuration.
Note that reading configuration from the file system has security implications; you may want to :set secure.
I've covered the main alternatives in this answer : https://stackoverflow.com/a/456889/15934 (Yes, your question is almost a duplicate: different formulation, but same solutions).
Modelines are really limited: you have to use a plugin to set things that are not vim options.
.exrc doesn't look behind the current directory
editorconfig is restricted to very specific options: don't expect to forward plugin specifications like where compilation directories are (this is how I support multiple compilation modes with CMake -- others prefer playing with ccache and tuning the CMakeCache, but this doesn't work well when using g++ and clang++ one after the other), how the linter shall be called, your naming conventions...
autocommand don't scale and cannot be ported easily from one directory to the other.
In the end, the best solutions are plugin based IMO: There a plenty plugin solutions see the non exhaustive list at the end of my local_vimrc plugin's README
Note also that since my previous answer, I've initiated another experiment to simplify project management. For instance, I introduce p:variables which are variables shared among all buffers belonging to a project.
On OS X, I generated a set of ctags for the system includes using the following command:
ctags -f c -h ".h" -R --c-kinds=+p --fields=+iaS --extra=+q /usr/include
This was run inside of a ~/.vim/ctags/ directory, where I put all of the ctags I generate for system-wide header files (I also have stuff for ROS and CPP that I load conditionally, but that's neither here nor there).
Anyway. The ctags file is set correctly in my .vimrc, and vim can definitely see the ctags, but for some reason the autocomplete popup will only display results from #included header files if I write out the entire symbol and then start backspacing. As an example, if I #include <string.h> in a project, and then I want to call strlen(), and I start to type str in to the active vim buffer, I will only get results for symbols that are currently in the vim buffer. But, if I type out strlen and then start backspacing one or two characters and hit <C-n>, the popup menu will be populated with matches from any other included header files.
EDIT: Turns out, if I just hit "s" then <C-n>, it works as well. So the problem seems to be that it only works if the popup menu is launched manually. Which makes me think that it's a plugin problem (see below)
Additional information:
completeopt is set to completeopt=menuone,menu,preview,longest
I have OmniCppComplete, which I suppose could be interfering with the behavior. It is currently not being conditionally loaded for C++ files only. If you want me to edit and post my OmniCppComplete settings from my .vimrc, just ask.
I also have AutoComplPop installed, but I haven't done anything to configure it, so it's running with its default settings. Haven't really researched the plugin, so no idea if some of it's behavior could be interfering with the results.
I have AutoTag and TagBar installed, but those should only be fiddling with the current directory's local tagfile.
I'm honestly pretty new to Vim, and I just have no idea where to start debugging this issue, whether it be with a random plugin or with my .vimrc settings.
Vim has many specific completion mechanisms.
<C-n> and <C-p> use many sources defined by the complete option. By default, they will provide completion using the current and all loaded and unloaded buffers, tags and included files. While you can usually get quite useful suggestions with these, it is a bit of a "catch-all" solution: it is not reliable at all if you work on reasonably large projects.
<C-x><C-]> uses only tags so it may be a little more useful to you.
And there are many more, see :h ins-completion.
Omni completion is smarter: it typically runs a custom filetype-specific script that tries hard to provide meaningful completion. It is triggered by <C-x><C-o> and you can read about it in :h ft-c-omni. Omni completion is often a better choice when working with code.
Because you have two overlaping "auto"-completion plugins it's hard to say what completion mechanism is at work. You should disable those plugins and play around with the different completion mechanisms available to you.
I have not mastered this yet, but I do think the following observation may be of help.
Vim's default auto complete which can be quite noisy, often gets in the way of what you call with <C-x><C-o>. Specifically, I found myself calling up my tags based completions with <C-x><C-o> only to have them replaced with continued typing with Vim's default suggestions using my open buffers.
The suggestion of shutting off one of the plugins makes sense. In my case the key was how to shut down Vim's default behavior. I have seen several people (and to which I now include myself), set the length of the expression to a high number before triggering Vim's default. For me that is:
let g:deoplete#auto_complete_start_length = 99
... this way you eliminate the default layer of completions that comes and goes regardless of the commands you intended to inform your work.
This still feels like a hack but it helps keep my work focused on the tag-based completions.
FYI: I use NVIM on a Mac.
On my mx53_loco board i have a problem:
when i add the command line help define (CONFIG_SYS_LONGHELP) in the board specific header, building complete successful but when i boot the board i find a corrupted environment (all commmands are unrecognized).
I have this problem even if i increase the size of the CONFIG_EXTRA_ENV_SETTINGS define.
So it seems to be a problem related to size of the u-boot code that overflows somewhere. (memory map re-definition?)
I would to be able to resize internal layout of u-boot correctly.
Can anyone explain me what happens or suggest a helpful link?
u-boot always reads the saved environment variables first. These environment variables are typically in non-volatile memory (NOR or NAND flash, or others). If the CRC of the saved environment variables are correct the saved env variables are used. If you changed your CONFIG_EXTRA_ENV_SETTINGS it won't be used!
The values in the CONFIG_EXTRA_ENV_SETTINGS will only be used when you reset the env vars to default and save them:
$ env default -f
$ saveenv
You should also take care of your mapping and sizes. When you add new env variables make sure CONFIG_ENV_SIZE and CONFIG_ENV_OFFSET are correct.
Please read the README file in the top-level directory of the u-boot sources.
And browse the mailing list: http://news.gmane.org/gmane.comp.boot-loaders.u-boot
Edit:
You should also verify that CONFIG_SYS_FLASH_BASE and CONFIG_SYS_MONITOR_LEN are correct. Just make sure you don't overlap the flash area covered by u-boot and the flash area where you write your env variables.
When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).