I have following U-Boot environment variables:
nas220> printenv
autoload=no
autostart=no
baudrate=115200
bootargs=console=ttyS0,115200
bootargs_base=console=ttyS0,115200
bootcmd=run bootcmd_nand
bootcmd_nand=setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a40000#0x5c0000(rootfs)
bootcmd_rescue=setenv bootargs_extra rescue/enable=true; run bootcmd_usb
bootcmd_usb=setenv bootargs ${bootargs_base} ${mtdparts} ${bootargs_extra}; usb start; fatload usb 0:1 0x40000 uImage-dtb; fatload usb 0:1 0x800000 uInitrd; bootm 0x40000 0x800000
bootdelay=3
ethact=egiga0
ethaddr=00:10:75:07:0D:8D
ethadr=00:10:75:07:0D:8D
mtdids=nand0=orion_nand
mtdparts=cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a40000#0x5c0000(rootfs)
stderr=serial
stdin=serial
stdout=serial
Environment size: 876/65532 bytes
I need to change the bootcmd_nand variable from:
setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a40000#0x5c0000(rootfs)
to
setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a30000#0x5c0000(rootfs)
however when I try to run:
setenv bootcmd_nand setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a30000#0x5c0000(rootfs)
The system reads from the nand and boots so I'm not able to run the saveenv command to save the changes persistently.
How to I make the change without the system booting?
I figured out my mistake, but leaving the question up in case anyone else comes across this. To run a setenv command without actually running the code you just have the enclose the variable in single quotes. For example running,
setenv bootcmd_nand setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a30000#0x5c0000(rootfs)
will run the code and read from the nand not saving the variable permanently. However running,
setenv bootcmd_nand 'setenv bootargs console=ttyS0,115200 cmdlinepart.mtdparts=orion_nand:0xa0000#0x0(uboot),0x010000#0xa0000(env),0x500000#0xc0000(uimage),0x1a30000#0x5c0000(rootfs)'
Sets the variable without running the code so I can run the saveenv and save permanently.
Related
I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image sd.img which contains a partition.
I've compiled u-boot (v2022.10) with qemu-x86_64_defconfig
I run qemu with qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img
u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type ext4ls ide 0:1, I can clearly see hello_world.bin (3932704 hello_world.bin).
When I do a ext4load ide 0:1 0x40000 hello_world.bin (in preparation for go 40000 This is another test), qemu/u-boot restarts.
0x40000 is the CONFIG_STANDALONE_LOAD_ADDR for x86.
I have even tried making an image of hello_world mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x40000 -d hello_world.bin -v hello_world.img and tried to load the image into 0x40000 with the intention of using bootm in case of cache issues - qemu/u-boot still resets.
Could anyone possibly point out the basic mistake I'm making.
Cheers
The memory area 0xa0000-0xffffff is reserved and you are overwriting it when loading your 4 MiB file to 040000 due to the excessive size of the file.
If you build hello_world.bin correctly, it will be a few kilobytes.
I´m trying to pass variables to my post-installation script but seems like isn´t available.
I tried this but doesn´t work:
sudo MY_VAR=VALUE installer -pkg my_package.pkg -target /
I need to access environments variables, without a config file, in post-installation script.
Thanks!
Use export var_name=value won't work in this case. To achieve this you must use launchctl and export your variables by running launchctl setenv var_name value. After that, you can get the value of your variables using launchctl getenv var_name. Here you can see an example:
sh-3.2# launchctl setenv var1 hello
sh-3.2# launchctl setenv var2 world
sh-3.2# launchctl getenv var1
hello
sh-3.2# launchctl getenv var2
world
You can also set multiple variables at once:
sh-3.2# launchctl setenv var3 one var4 line
sh-3.2# launchctl getenv var3
one
sh-3.2# launchctl getenv var4
line
To use this with your package, you can run something like this:
sh-3.2# launchctl setenv var_name value && installer -pkg your_package.pkg -target /
I'm running into an issue where when I power up my device, it hangs at
Starting kernel ...
Or it loops with
Starting kernel ...
resetting ...
However, if I interrupt the boot process and manually run boot, ie:
=> run bootcmd
or
=> boot
then the kernel loads fine.
According to DENX (5.9.6.5) this is equivalent to what Uboot should be doing automatically.
Does anyone know if there is a difference between letting uboot run on it's own and interrupting and running boot manually? Otherwise, how do I start debugging this?
ENVIRONMENT
=> printenv
autoload=no
baudrate=115200
board_name=EVK
board_rev=pilot
boot_fdt=try
bootcmd=echo Booting from network ...; usb start; setenv ethact asx0; if dhcp && tftp $loadaddr $bootfile && tftp $f
dt_addr $fdt_file; then run nfsboot; else echo WARN: Issue with TFTP.; run sdboot; fi;
bootdelay=3
bootfile=zImage
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc1
ethact=asx0
ethprime=FEC
fdt_addr=0x83000000
fdt_file=imx6ul-pilot-v1-evk.dtb
fdt_high=0xffffffff
image=zImage
initrd_high=0xffffffff
ip_dyn=yes
loadaddr=0x80800000
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}
mmcautodetect=yes
mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcdev=1
mmcpart=1
mmcroot=/dev/mmcblk1p2 rootwait rw
netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
nfsboot=run netargs; bootz $loadaddr - $fdt_addr
nfsroot=/nfs/rootfs
script=boot.scr
sdboot=echo Booting from mmc ...; mmc dev ${mmcdev}; mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if run loadimage; then run mmcboot; else echo ERROR: Cannot run loadimage; fi; fi; else run ERROR: Cannot run mmc rescan; fi;
serverip=192.168.0.219
Environment size: 1714/8188 bytes
This issue was with the SDBOOT env var:
sdboot = echo Booting from mmc ...; mmc dev ${mmcdev}; mmc dev ${mmcdev};
if mmc rescan; then
if run loadbootscript; then
run bootscript;
else
if run loadimage; then
run mmcboot;
else
echo ERROR: Cannot run loadimage;
fi;
fi;
else
echo ERROR: Cannot run mmc rescan;
fi;
Load bootscript kept failing with "** Unable to read file boot.scr **". I'm still not sure what was causing the difference but removing the loadbootscript branch and going straight to loadimage fixed the issue.
I am running Docker Machine on Mac.
docker-machine version 0.6.0, build e27fb87
In my shell I have done
export DOCKER_HOST=tcp://docker.local:2375
export DOCKER_TLS_VERIFY=0
Restarted the machine
When I do
docker-machine env
These do not seem to have been set. I am using the ZSH shell, could this be an issue?
docker-machine env
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.99.100:2376"
export DOCKER_CERT_PATH="/Users/ciaran/.docker/machine/machines/default"
export DOCKER_MACHINE_NAME="default"
When you run docker-machine env it will show the variables that are needed in order to connect to the default machine. It has nothing to do with the variables in the current shell, and will not set any variables in your shell.
To see the current docker variables in your shell, you can run
$ env | grep DOCKER
If you want to set your shell ENV variables to the ones in docker-machine env, you will need to either copy and paste the output of docker-machine env, or eval the output like this.
$ eval $(docker-machine env <machine name>)
That will set the variables in your shell. This command is actually given to you when you run docker-machine env look at the end of the output.
To confirm it worked, check the shell again.
$ env | grep DOCKER
I have installed sun-java in archlinux kde by first building the package and then installing it. This is the way the environment variables are set in my machine:
file: /etc/profile
# /etc/profile
#Set our umask
umask 022
# Set our default path
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin"
export PATH
# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
for profile in /etc/profile.d/*.sh; do
test -r "$profile" && . "$profile"
done
unset profile
fi
# Source global bash config
if test "$PS1" && test "$BASH" && test -r /etc/bash.bashrc; then
. /etc/bash.bashrc
fi
# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP
# Man is much better than us at figuring this out
unset MANPATH
and file: /etc/profile.d/jdk.sh
export J2SDKDIR=/opt/java
export PATH=$PATH:/opt/java/bin:/opt/java/db/bin
export JAVA_HOME=/opt/java
export DERBY_HOME=/opt/java/db
what I understand from this is, jdk path should be set in the path environment variable but its not. But the attribute $JAVA_HOME is set correctly. Any reasons why am I facing this problem?
/etc/profile and /etc/profile.d are processed only for login shells, so unless you're doing ssh into the machine where java is installed you won't get those variables.
To have them locally (e.g. when you open an xterm on a workstation) put them in the file /etc/bash.bashrc.
Hope this helps.
Actually, it was a silly mistake on my part. I am using zsh shell. So I was required to put:
export PATH=$PATH:$JAVA_HOME/bin
in .zshrc file instead of .bashrc.