I have 2 images stored in predefined addresses in flash that are loaded based on some criteria I can test for on bootup.
Can someone please suggest a method to programmatically launch either image using uboot's tools like bootm, etc? Or point to an example of this procedure.
Thanks in advance.
I assume whatever method you use to load the images takes an address, so just set that before running it. bootcmd is the main entry point, boot is basically the same as run bootcmd.
setenv flashload 'fooload $imageflashaddr $loadaddr'
setenv setimageflashaddr 'if something; then setenv imageflashaddr xxx ; else setenv imageflashaddr yyy; fi'
setenv bootcmd 'run setimageflashaddr && run flashload && bootm $loadaddr'
u-boot is enormously flexible; there are many ways to do this. This uses environment variables. You can also do this from C code or from a script file you load at run time.
If you want to do it in C code, you can edit your board's C file (usually in board/vendor_name/board_name.c. You can define a board_late_init() (there are other hooks, but this one is usually a good place to start). You can use env_get() and env_set() to set your address so your bootcmd loads from different places.
Related
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.
Consider the following code in mono/domain.c:
static MonoDomain *mono_root_domain = NULL;
...
MonoDomain* mono_get_root_domain (void)
{
return mono_root_domain;
}
My task is to read the struct data pointed by the mono_root_domain pointer in runtime from another process. (Attaching, reading, locating dylibs, etc. from this other process is solved already)
Looking into the generated libmono dylib I can find the corresponding symbol:
This symbol points to the address of 0x2621A8 which in the local relocation section (__DATA, __bss):
This points to the address of 0x1A7690 (__TEXT, __symbol_stub):
The target is
so 0x1A7DF8 (__TEXT, __stub_helper):
At this point I am completely lost of how to retrieve the actual pointer to the MonoDomain struct. Any help is appreciated.
For security reasons and to prevent buffer overflow attacks and other exploits, you can't know that, because of a security measure called PIE or ASLR (address space layout randomization). However, this can be disabled for debugging purposes. LLDB and GDB do/did it in order to debug executables. The way this can be done with a CLI app is as follows:
Copy or download this python script from GitHub
https://github.com/thlorenz/chromium-build/blob/master/mac/change_mach_o_flags.py
Save the python script, for example, next to your executable
If so, open Terminal and cd to where your executable is
enter chmod +x ./change_mach_o_flags.py to make the script executable
enter ./change_mach_o_flags.py --no-pie ./YourExecutable
Now the addresses of your executable should not be randomized anymore. Because of that, to calculate the addresses of your static / global variables is possible. To do that, do the following in Terminal (I am assuming you are using a 64-bit machine):
otool -v -l ./YourExecutable | open -f(this will generate a file text with the commands inside your executable of how to layout DATA, TEXT, etc. in memory)
Look for the section you are interested in. Look at the addr field. If it contains let's say 0x0000000100001020 then the variable will be placed exactly there with ASLR disabled.
I am not sure if this works with dylibs but you can try it. Now I ran out of time, but I can try at home and see if this is doable with dylibs.
I need to have different variants of a device tree passed to my linux kernel dependant on a board revision that can only be determined at run time.
What's the established way of setting up the boot of the kernel to deal with various hardware layouts that can only be determined at boot time from within u-boot?
The bootm command is taking three parameters:
bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}
While the third one is the address of the flattened device tree blob in the memory. So if you have different device trees, either load them into different memory addresses and pass them to bootm, or load that memory address with different blobs.
Late answer, but i recently add to deal with the same problem.
Using u-boot , you can actually write a macro for that.
The u-boot environment variable for the device tree file is "fdtfile".
From there, you can define a macro that set this variable according to your specific need for example :
setenv findfdt '
if test $mycondition = value1; then setenv fdtfile devicetree1.dtb; fi;
if test $mycondition = value2; then setenv fdtfile devicetree2.dtb; fi;
..'
Then you can just create a .txt file to register this macro and then use mkimage tool to create a binary image .img for u-boot to load :
mkimage -T script -d macros.txt macros.img
You can of course wrap this macro with a more sophisticated one that will be executed at each boot.
I have a build machine server I am maintaining which is using Makefiles infrastructure.
As part of that infrastructure, I'm passing a few arguments to the Makefile from the build machine (example: user, build-server name, and various build variables known only when compiling for a specific project).
Some of these variables are aggregated to the code using gcc -D directive
-DSOME_VAR=VAL
I've now been asked to migrate an Iar Project into my build system. That is not a problem in itself, only I can't find any way to introduce preprocessor defines using iarbuild.exe command line tool.
I guess I could use an existing H file and edit it before compiling (using sed for example), but that's an ugly hack I would rather avoid if I can.
How do I properly achieve this with IAR?
I recently solved this using a combination of option #2 and the -varfile argvarfile option to iarbuild.exe. For my case I am controlling the output of cpputest. I need easy to read outputs for IDE builds but junit formatted outputs for build server builds. Here's my setup as an example.
Create a global variable in the IDE. Tools->Configure Custom Argument Variables...
Select global tab. Create group JUNIT. Create variable USE_JUNIT. Set the value to 0.
In the Project->Options->C/C++ Compiler->Preprocessor section add an entry for
JUNIT_OUTPUT=$USE_JUNIT$
In the code use
#if JUNIT_OUTPUT == 1
#define FLAGS "-ojunit"
#else
#define FLAGS "-v"
#endif
Create a file called jUnitOut.txt and put the following into it.
<?xml version="1.0" encoding="iso-8859-1"?>
<iarUserArgVars>
<group active="true" name="JUNIT">
<variable>
<name>USE_JUNIT</name>
<value>1</value>
</variable>
</group>
</iarUserArgVars>
Call iarbuild.exe with the normal options plus -varfile jUnitOut.txt
Some observations
Regarding #1 you don't actually need to create a global variable but when you do IAR creates ...\AppData\Roaming\IAR Embedded Workbench\global.custom_argvars. This file must be present for iarbuild.exe to use the -varfile you provide. Also, you can create workspace variables as well. These are stored in a file in the local project directory. This file can be added to source control so global variables can be avoided. IDE builds use the global and workspace variables while iarbuild will use the -varfile
Regarding #4 I didn't find any documentation on how to format the argvarfile. So, I created a workspace variable in the IDE, found the file it created to store the variable and then cut/pasted from that file into my jUnitOut.txt
To my understanding iarbuild does not support passing such parameters directly.
There are two possibilities that were suggested by IAR support and that both work for me (using 7.40.2):
1) Use a preinclude file
Go to Project->Options->C/C++ Compiler->Preprocessor
Add a preinclude file (e.g. preinclude.h)
Now have your build script generate that preinclude file before starting iarbuild
2) Use "Defined symbols"
Go to Project->Options->C/C++ Compiler->Preprocessor
Add an option to "Defined symbols" and use environment variable, e.g. "SOMEVAR=$_SOMEVAL_$"
On the cmd line, set the environment variable, e.g. "set SOMEVAR=myvalue"
Run iarbuild
The 2nd method is little more elegant, but the build will fail if the environment variable is not set, so I'll probably go with the 1st method.
This may answer your question:
To see the command line parameters, enable the option IAR Embedded Workbench IDE > Tools > Options... > IDE Options > Messages > Show build messages > select 'All'.
which is part of the web page at:
http://supp.iar.com/Support/?Note=47884
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.