Unable to set environment variable in compile time of uBoot - yocto

I am trying to bring net-console in uboot. For that, I first added 'ncip' in "uboot-imx/include/configs/imx8mm_evk.h" as following. Later, DFMC_SWUG is called at the end of CONFIG_EXTRA_ENV_SETTINGS.
#define DFMC_SWUG \
"setenv ncip 192.168.100.98 \0" \
"ethaddr=00:80:A3:CA:B5:77 \0" \
"swugip=192.168.100.16 \0" \
"ipaddr=192.168.100.2 \0" \
"serverip=192.168.100.16 \0" \
"bootdelay=3\0" \
#define CONFIG_EXTRA_ENV_SETTINGS \
CONFIG_MFG_ENV_SETTINGS \
JAILHOUSE_ENV \
"script=boot.scr\0" \
--
--
--
"fi;\0" \
DFMC_SWUG
Interestingly, I was able to set 'ethaddr', "swugip" and other variables except "ncip". I guess, I am doing some formatting mistakes in line --> "setenv ncip 192.168.100.98 \0" \
Later I tried setting some dummy variables named dummy_var_1, dummy_var_2, dummy_var_3. Even they are not getting set.
Can some one please guide me here?

The U-Boot environment consists of strings in the form <env_var>=<string value><null> (and preceded with a CRC32 word).
So strings for environment variables have to conform to that template when predefining them in code using CONFIG_EXTRA_ENV_SETTINGS.
That also means that you cannot install raw commands in the environment such as "setenv ncip 192.168.100.98 \0".
The U-Boot documentation is clear on this topic.
Note the last sentence of the warning.
- Default Environment:
CONFIG_EXTRA_ENV_SETTINGS
Define this to contain any number of null terminated
strings (variable = value pairs) that will be part of
the default environment compiled into the boot image.
For example, place something like this in your
board's config file:
#define CONFIG_EXTRA_ENV_SETTINGS \
"myvar1=value1\0" \
"myvar2=value2\0"
Warning: This method is based on knowledge about the
internal format how the environment is stored by the
U-Boot code. This is NOT an official, exported
interface! Although it is unlikely that this format
will change soon, there is no guarantee either.
You better know what you are doing here.
I did try "ncip=192.168.100.98" ...
That looks almost correct, but needs the explicit null terminator.
Interestingly, I was able to set 'ethaddr', "swugip" and other variables except "ncip".
...
Later I tried setting some dummy variables named dummy_var_1, dummy_var_2, dummy_var_3. Even they are not getting set.
You have only provided your vague summations of the actual results.
Did you inspect any .o object files to check what text strings were stored?
Did you perform a strings u-boot.bin | less on the U-Boot image file to review the default environment embedded in the image?
Note that you could be making an additional mistake.
The environment variables defined in CONFIG_EXTRA_ENV_SETTINGS will only (initially) exist in the default environment of U-Boot.
You have been very parsimonious with details, and neglect to mention your setup. If there is an existing and valid stored environment in the nonvolatile boot medium, then specific procedures need to be performed to suppress the existing stored environment in order to revert to the default environment with the "new" environment variables.
Failure to disable/delete an existing stored environment when installing a new/different version of u-boot.bin will conceal the new/different default environment and all the new/different variables in it. If U-Boot does not issue the message similar to:
Loading Environment from xxx... *** Warning - bad CRC, using default environment
then you can be assured that your new/different environment variables are not in the current runtime environment.
IOW you want to see this warning message on (initial) boot.

If one wishes to compile u-boot with netconsole then following changes have to be done for the file in uboot-imx/include/configs/imx8mm_evk.h
Add ‘ncip’ i.e., IP address of the computer/device which holds net console along with other network settings. Please note that every variable in u-boot will be null terminated string.
Also add a variable (in following case it is dfmcswug) which will set the standard input, output and error reporting over netconsole. This variable will be called later.
Include the DFMC_SWUG macro inside CONFIG_EXTRA_ENV_SETTINGS macro so that our new settings will be added along with other environmental settings.
Add dfmcswug variable in CONFIG_BOOTCOMMAND so that it will get executed by tool chain during run time.
With the above steps, u-boot should output its console over netconsole.
On the client-side use Or similar.
nc -u -l -p 6666 <ip_address_of_uboot_host>

Related

Is there a way to configure pytest_plugins from a pytest.ini file?

I may have missed this detail but I'm trying to see if I can control the set of plugins made available through the ini configuration itself.
I did not find that item enumerated in any of the configurable command-line options nor in any of the documentation around the pytest_plugins global.
The goal is to reuse a given test module with different fixture implementations.
#hoefling is absolutely right, there is actually a pytest command line argument that can specify plugins to be used, which along with the addopts ini configuration can be used to select a set of plugin files, one per -p command.
As an example the following ini file selects three separate plugins, the plugins specified later in the list take precedence over those that came earlier.
projX.ini
addopts =
-p projX.plugins.plugin_1
-p projX.plugins.plugin_2
-p projY.plugins.plugin_1
We can then invoke this combination on a test module with a command like
python -m pytest projX -c projX.ini
A full experiment is detailed here in this repository
https://github.com/jxramos/pytest_behavior/tree/main/ini_plugin_selection

Preventing the accidentally marking of all conflicts as resolved in Mercurial

It doesn't happen too often, but every once in a while I'll fumble with my typing and accidentally invoke "hg resolve -m" without a file argument. This then helpfully marks all the conflicts resolved. Is there any way to prevent it from resolving without one or more file arguments?
You can do this with a pre-resolve hook but you'd have to parse the arguments yourself to ensure that they are valid which could be tricky.
The relevant environment variables that you might need to look at are:
HG_ARGS - the contents of the whole command line e.g. resolve -m
HG_OPTS - a dictionary object containing options specified. This would have an an entry called mark with a value of True if -m had been specified
HG_PATS - this is the list of files specified
Depending upon the scripting language you would use, you should be able to test if HG_OPTS contains a value of True for mark and fail if it does and the HG_PATS array is empty.
It starts to get complicated when you take into account the --include and --exclude arguments.
If you specify the files to resolve as part of the --include option then the files to include would be in HG_OPTS, not HG_PATS. Also, I don't know what would happen if you specified hg resolve -m test.txt --exclude test.txt. I'd hope that it would not resolve anything but you'd need to test that.
Once you've parsed the command arguments, you'd return either 0 to allow the command or 1 to prevent it. You should echo a reason for the failure if you return 1 to avoid confusion later.
If you don't know how to do this then you'd need to specify what OS and shell you are using for anyone to provide more specific help.

Read environment variable using Macros iOS [duplicate]

In the code below, I would like the value of THE_VERSION_STRING to be taken from the value of the environment variable MY_VERSION at compile time
namespace myPluginStrings {
const char* pluginVendor = "me";
const char* pluginRequires = THE_VERSION_STRING;
};
So that if I type:
export MY_VERSION="2010.4"
pluginRequires will be set at "2010.4", even if MY_VERSION is set to something else at run time.
UPDATE: (feb 21) Thanks for your help everyone. It works.
As I'm using Rake as a build system, each of my CFLAGS is a ruby variable. Also the values need to end up in quotes. Therefore the gcc command line for me needs to look like this:
gcc file.c -o file -D"PLUGIN_VERSION=\"6.5\""
Which means this is in my Rakefile:
"-D\"PLUGIN_VERSION=\\\"#{ENV['MY_VERSION']}\\\"\""
If I recall correctly, you can use the command line parameter -D with gcc to #define a value at compile time.
i.e.:
$ gcc file.c -o file -D"THE_VERSION_STRING=${THE_VERSION_STRING}"
In the code below, I would like the value of THE_VERSION_STRING to be taken from the value of the environment variable MY_VERSION at compile time
No, you can't do it like this. The only way to extract environment variables is at runtime with the getenv() function. You will need to explicitly extract the value and copy it to pluginRequires.
If you want the effect of a compile-time constant, then you'll have to specify the definition on the compiler commandline as Seth suggests.

dpkg: How to use trigger?

I wrote a little CDN server that rebuilds its registry pool when new pool-content-packages are installed into that registry pool.
Instead of having each pool-content-package call the init.d of the cdn-server, I'd like to use triggers. That way it would restart the server only once at the end of an installation run, after all packages were installed.
What have I to do to use triggers in my packages with debhelper support?
What you are looking for is dpkg-triggers.
One solution with use of debhelper to build the debian packages is this:
Step 1)
Create file debian/<serverPackageName>.triggers (replace <serverPackageName> with name of your server package).
Step 1a)
Define a trigger that watch the directory of your pool. The content of file would be:
interest /path/to/my/pool
Step 1b)
But you can also define a named trigger, which have to be fired explicit (see step 3).
content of file:
interest cdn-pool-changed
The name of the trigger cdn-pool-changed is free. You can take what ever you want.
Step 2)
Add handler for trigger to file debian/<serverPackageName>.postinst (replace <serverPackageName> with name of your server package).
Example:
#!/bin/sh
set -e
case "$1" in
configure)
;;
triggered)
#here is the handler
/etc/init.d/<serverPackageName> restart
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
#DEBHELPER#
exit 0
Replace <serverPackageName> with name of your server package.
Step 3) (only for named triggers, step 1b) )
Add in every content package the file debian/<contentPackageName>.triggers (replace <contentPackageName> with names of your content packages).
content of file:
activate cdn-pool-changed
Use same name for trigger you defined in step 1.
More detailed Information
The best description for dpkg-triggers I could found is "How to use dpkg triggers". The corresponding git repository with examples you can get here:
git clone git://anonscm.debian.org/users/seanius/dpkg-triggers-example.git
I had a need and read and re-read the docs many times. I think that the process is not clearly explain or rather what goes where is not clearly explained. Here I hope to clarify the use of Debian package triggers.
Service with Configuration Directory
A service reading its settings in a specific directory can mark that directory as being of interest.
Say I create a new service which reads settings from /usr/share/my-service/config/...
That service gets two additions:
In its debian directory I add my-service.triggers
And here are the contents:
# my-service.triggers
interest /usr/share/my-service/config
This means if any other package installs or removes a file from that directory, the trigger enters its "needs to be run" state.
In its debian directory I also add my-service.postinst
And I have a script as follow to check whether the trigger happened and run a process as required:
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "/usr/share/my-service/config" ]
then
# this may or may not be what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
That's it.
Now packages adding extensions to your service can add their own configuration file(s) under /usr/share/my-service/config (or a directory under /etc/my-service/my-service.d/... or /var/lib/my-service/..., although that last one should be reserved for dynamic files, not files installed from a package) and dpkg automatically calls your postinst script with:
postinst triggered /usr/share/my-service/config
# where /usr/share/my-service/config is your <interest-path>
This call happens only once and after all the packages were installed, hence the advantage of having a trigger in the first place. This way each package does not need to know that it has to restart my-service and it does not happen more than once, which could cause all sorts of side effects (i.e. the service tries to listen on a TCP port and get error: address already in use).
IMPORTANT: keep in mind that the postinst should include a line with #DEBHELPER#.
So you do not have to do anything special in other packages. Only make sure to install the configuration files in the correct directory and dpkg picks up from there (i.e. in my example under /usr/share/my-service/config).
I have an extension to BIND9 called ipmgr which makes use of .ini files saved in a specific folder. It uses the files to generate DNS zones (way less errors that way! and it includes support for getting letsencrypt certificates and settings for dmarc/dkim). This package uses this case: a simple directory where configuration files get installed. Other packages do not need to do anything other than install files in the right place (/usr/share/ipmgr/zones, for this package).
Service without a Configuration Folder
In some (rare?) cases, you may need to trigger something in a service which is not driven by the installation of a new configuration file.
In this case, you can use an arbitrary name (it should include your package name to make sure it is unique since this name is global to the entire Debian/Ubuntu system).
To make this one work, you need three files, one of which is a trigger in the other packages.
State the Interest
As above, we have an interest. In this case, the interest is stated as a name on its own. The dpkg system distinguish between a name and a path because a name cannot include a slash (/) character. Names are limited to ASCII except control characters and spaces. I would suggest you stick to a-z, 0-9 and dashes (-).
# my-service.triggers
interest my-service-settings
This is useful if you cannot simply track a folder. For example, the settings could come from a network connection that a package offers once installed.
Listen for the Triggers
Again, as above, you need a postinst script in your Service Package. This captures the trigger and allows you to run a command. The script is the same, only you test for the name instead of the folder (note that you can have any number of triggers, so you could also have both: a folder as above and a special name as here).
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "my-service-settings" ]
then
# this may or may not what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
The Trigger
As mentioned above, we need a third file. An arbitrary name is not going to be triggered automatically by dpkg. It wouldn't know whether your other package needs to trigger something just like that (although it is fairly automated as it is already).
So in other packages, you create a trigger file which looks like this:
# other-package.triggers
activate my-service-settings
Now we recognize the name, it is the same as the interest stated above.
In other words, if the trigger needs to run for something other than just the installation of files in a given location, use a special name and add this triggers file with the activate keyword.
Other Features
I have not tested the other features of the dpkg-trigger(1) tool. There are other keywords support in the triggers files:
interest
interest-await
interest-noawait
activate
activate-await
activate-noawait
The deb-triggers manual page has additional information about those. I am not too sure what the await/noawait implies other than the trigger may happen at any time when nowait is used.
Automatic Trigger Added
The build system on Ubuntu (probably Debian too) automatically adds a triggers file with the following when your package includes a library:
$ cat triggers
# Triggers added by dh_makeshlibs/11.1.6ubuntu2
activate-noawait ldconfig
I suggest you exercise caution if your package includes libraries. If you have your own triggers file, I do not know whether this addition will still happen automatically.
This also shows us a special case where it wants to use the noawait. If I understand correctly, it has to run the ldconfig trigger ASAP so your commands will work as expected after the unpack. Otherwise ldd will not know anything about your newly installed library.

scripting buildroot configuration file

I am trying to switch between external and internal build via some export variable in a script. I am able to do this partially meaning for bool values but for those which take in strings how to tell buildroot to continue with default value and not prompt for values to the user.
For e.g., BR2_TOOLCHAIN_EXTERNAL_STRIP=y works fine, as it takes in bool value, but BR2_TOOLCHAIN_EXTERNAL_PATH prompts for a value, even though default is set to the correct path.
Thanks for any help
If you want to switch easily between internal and external toolchain builds, then I would suggest creating fragments of defconfig files:
One defining the internal toolchain configuration
One defining the external toolchain configuration
One defining the common options
And then, you just to :
cat internal-toolchain.config common.config > configs/myown_defconfig
make myown_defconfig
and there you are. And similarly with external-toolchain.config.