I need to configure u-boot to boot immediately (disabling the press key to interrupt prompt) for a yocto build.
I've added the following bbappend to do so:
# u-boot_%.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/u-boot:"
SRC_URI_append_edge = " \
file://disable-boot-delay.cfg \
"
where disable-boot-delay.cfg looks like this:
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_KEYED_CTRLC=n
CONFIG_BOOTDELAY=-2
This successfully disables the boot prompt, but also causes the FAT partition that u-boot is installed on to become corrupt:
$ # without above bbappend
$ dosfsck /dev/mapper/loop0p1
fsck.fat 4.1 (2017-01-24)
/dev/mapper/loop0p1: 49 files, 6510/20431 clusters
$ # with above bbappend
$ dosfsck /dev/mapper/loop0p1
fsck.fat 4.1 (2017-01-24)
/OVERLAYS/.
Bad short file name (.).
1) Drop file
2) Rename file
3) Auto-rename
4) Keep it
? 4
/OVERLAYS/..
Bad short file name (..).
1) Drop file
2) Rename file
3) Auto-rename
4) Keep it
? 4
/dev/mapper/loop0p1: 49 files, 6510/20431 clusters
I'm massively, massively confused as to how this change could be causing file system corruption.
Environment:
Yocto Warrior (2.7)
meta-raspberrypi (warrior branch)
RPI_USE_U_BOOT = "1"
Diffing workdir/build/.config with and without the above append:
229c229
< CONFIG_BOOTDELAY=2
---
> CONFIG_BOOTDELAY=-2
306c306,311
< # CONFIG_AUTOBOOT_KEYED is not set
---
> CONFIG_AUTOBOOT_KEYED=y
> CONFIG_AUTOBOOT_PROMPT="Autoboot in %d seconds\n"
> # CONFIG_AUTOBOOT_ENCRYPTION is not set
> CONFIG_AUTOBOOT_DELAY_STR=""
> CONFIG_AUTOBOOT_STOP_STR=""
> # CONFIG_AUTOBOOT_KEYED_CTRLC is not set
Related
I modified an existing Yocto class (sdcard_image-rpi.bbclass) which generates an SD card image. The new class has a different name as well. Everything works as expected with one exception. When bitbake is finished, symlinks are created, which point to the last built file. For the .sdcard file this symlink is not created.
It is only not clear to me where (or in which stage) this symlink should be created.
Any suggestions what might causing this ?
class file content added below. (Removed the partitioning and copy opererations for clarity). This file is derived from meta-raspberrypi
and on some locations the name "rpi-sdimg" is replaced by "dual-sdimg".
The original file does not contain a command to create a symlink to the generated sdcard image, which implies it should be done outside this class. Most likely the changed name influenced this.
inherit image_types
# This image depends on the rootfs image
IMAGE_TYPEDEP_dual-sdimg = "${SDIMG_ROOTFS_TYPE}" # Name changed
# Set kernel and boot loader
IMAGE_BOOTLOADER ?= "bootfiles"
# Kernel image name
SDIMG_KERNELIMAGE_raspberrypi ?= "kernel.img"
SDIMG_KERNELIMAGE_raspberrypi2 ?= "kernel7.img"
SDIMG_KERNELIMAGE_raspberrypi3-64 ?= "kernel8.img"
# Boot partition volume id
BOOTDD_VOLUME_ID ?= "${MACHINE}"
# Use an uncompressed ext3 by default as rootfs
SDIMG_ROOTFS_TYPE ?= "ext3"
SDIMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${SDIMG_ROOTFS_TYPE}"
# For the names of kernel artifacts
inherit kernel-artifact-names
RPI_SDIMG_EXTRA_DEPENDS ?= ""
do_image_dual_sdimg[depends] = " \ # Name changed
parted-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
dosfstools-native:do_populate_sysroot \
virtual/kernel:do_deploy \
${IMAGE_BOOTLOADER}:do_deploy \
rpi-config:do_deploy \
${#bb.utils.contains('MACHINE_FEATURES', 'armstub', 'armstubs:do_deploy', '' ,d)} \
${#bb.utils.contains('RPI_USE_U_BOOT', '1', 'u-boot:do_deploy', '',d)} \
${#bb.utils.contains('RPI_USE_U_BOOT', '1', 'u-boot-default-script:do_deploy', '',d)} \
${RPI_SDIMG_EXTRA_DEPENDS} \
"
do_image_rpi_sdimg[recrdeps] = "do_build"
# SD card image name
SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.rpi-sdimg"
# Additional files and/or directories to be copied into the vfat partition from the IMAGE_ROOTFS.
FATPAYLOAD ?= ""
# SD card vfat partition image name
SDIMG_VFAT_DEPLOY ?= "${RPI_USE_U_BOOT}"
SDIMG_VFAT = "${IMAGE_NAME}.vfat"
SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
IMAGE_CMD_dual-sdimg () {
echo "Creating SD card image of ${SDIMG_SIZE} KiB with a boot partition of ${PT_BOOT_SIZE_ALIGNED} KiB and a rootfs of ${PT_ROOTFS_SIZE_ALIGNED} KiB"
# Check if we are building with device tree support
DTS="${KERNEL_DEVICETREE}"
# Initialize sdcard image file
dd if=/dev/zero of=${SDIMG} bs=1024 count=0 seek=${SDIMG_SIZE}
# Partitioning here
# Create a vfat image with boot files
# Bootloader copying here
# Add files (eg. hypervisor binaries) from the deploy dir
# Add stamp file
# Deploy vfat partition
# Write partitions to image file
}
ROOTFS_POSTPROCESS_COMMAND += " rpi_generate_sysctl_config ; "
rpi_generate_sysctl_config() {
# systemd sysctl config
test -d ${IMAGE_ROOTFS}${sysconfdir}/sysctl.d && \
echo "vm.min_free_kbytes = 8192" > ${IMAGE_ROOTFS}${sysconfdir}/sysctl.d/rpi-vm.conf
# sysv sysctl config
IMAGE_SYSCTL_CONF="${IMAGE_ROOTFS}${sysconfdir}/sysctl.conf"
test -e ${IMAGE_ROOTFS}${sysconfdir}/sysctl.conf && \
sed -e "/vm.min_free_kbytes/d" -i ${IMAGE_SYSCTL_CONF}
echo "" >> ${IMAGE_SYSCTL_CONF} && echo "vm.min_free_kbytes = 8192" >> ${IMAGE_SYSCTL_CONF}
}
let say i have a new yocto image call stargazer-cmd
what file should i edit so that every time i source poky/oe-init-env
it display as a build option to the user?
kj#kj-Aspire-V3-471G:~/stm32Yoctominimal$ source poky/oe-init-build-env build-mp1/
### Shell environment set up for builds. ###
You can now run 'bitbake <target>'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support
I wish to add stargazer-cmd on top of core-image-minimal, i am not sure what to google and what is the file i need to change.
Let me explain how to add a custom configuration to the OpenEmbedded build process.
First of all, here is the process that is done when running:
source poky/oe-init-build-env
The oe-init-build-env script initializes OEROOT variable to point to the location of the script itself.
The oe-init-build-env script sources another file $OEROOT/scripts/oe-buildenv-internal which will:
Check if OEROOT is set
Set BUILDDIR to your custom build directory name $1, or just build if you do not provide one
Set BBPATH to the poky/bitbake folder
Adds $BBPATH/bin and OEROOT/scripts to PATH (This will enable commands like bitbake and bitbake-layers ...)
Export BUILDDIR and PATH to the next file
The oe-init-build-env script continues by running the final build script with:
TEMPLATECONF="$TEMPLATECONF" $OEROOT/scripts/oe-setup-builddir
The oe-setup-builddir script will:
Check if BUILDDIR is set
Create the conf directory under $BUILDDIR
Sources a template file that will check if there is a TEMPLATECONF variable is set:
. $OEROOT/.templateconf
That file contains:
# Template settings
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
it means that if TEMPLATECONF variable is not set, set it to meta-poky/conf, and that is where the default local.conf and bblayers.conf are coming from.
Copy $TEMPLATECONF to $BUILDDIR/conf/templateconf.cfg
Set some variables pointing to custom local.conf and bblayers.conf:
OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample"
OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
In the oe-setup-builddir there is a comment saying that TEMPLATECONF can point to a directory:
#
# $TEMPLATECONF can point to a directory for the template local.conf & bblayers.conf
#
Copy local.conf.sample and bblayers.conf.sample from TEMPLATECONF directory into BUIDDIR/conf:
cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf"
sed -e "s|##OEROOT##|$OEROOT|g" \
-e "s|##COREBASE##|$OEROOT|g" \
$OECORELAYERCONF > "$BUILDDIR/conf/bblayers.conf"
Finally it will print what is inside OECORENOTESCONF which points to TEMPLATECONF/conf-notes.txt:
[ ! -r "$OECORENOTESCONF" ] || cat $OECORENOTESCONF
and by default that is located under meta-poky/conf/conf-notes.txt:
### Shell environment set up for builds. ###
You can now run 'bitbake <target>'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
Other commonly useful commands are:
- 'devtool' and 'recipetool' handle common recipe tasks
- 'bitbake-layers' handles common layer tasks
- 'oe-pkgdata-util' handles common target package tasks
So, now, after understanding all of that, here is what you can do:
Create a custom template directory for your project, containing:
local.conf.sample
bblayers.conf.sample
conf-notes.txt
Do not forget to set the path to poky in bblayers.conf to ##OEROOT## as it will be set automatically by the build script.
Set your custom message in conf-notes.txt
Before any new build, just set TEMPLATECONF:
TEMPLATECONF="<path/to/template-directory>" source poky/oe-init-build-env <build_name>
Then, you will find a build with your custom local.conf and bblayers.conf with additional file conf/templateconf.cfg containing the path of TEMPLATECONF
conf/conf-notes.txt in your layer.
OECORENOTESCONF should point to the file.
looking to disable some SELinux modules (set to off) and create others in modules.conf. I don't see an obvious way of updating modules.conf as I tried adding my changes as a modules.conf patch but it failed given that the modules.conf file gets built and is not just downloaded by BR so it is not available for patching like other things under the refpolicy directory:
Build window output:
refpolicy 2.20190609 PatchingApplying 0001-refpolicy-update-modules-conf.patch using patch:
can't find file to patch at input line 3
I did see in the log that there is a support/sedoctool.py that autogenerates the policy/modules.conf file so that the file is NOT patchable like most other things in the ref policy.
The relevant section of the buildroot/output/build/refpolicy-2.20190609/Makefile:
# policy building support tools
support := support
genxml := $(PYTHON) $(support)/segenxml.py
gendoc := $(PYTHON) $(support)/sedoctool.py
<...snip...>
########################################
#
# Create config files
#
conf: $(mod_conf) $(booleans) generate$(booleans) $(mod_conf): conf.intermediate.INTERMEDIATE: conf.intermediate
conf.intermediate: $(polxml)
#echo "Updating $(booleans) and $(mod_conf)"
$(verbose) $(gendoc) -b $(booleans) -m $(mod_conf) -x $(polxml)
Part of the hsmlinux build.log showing the sedoctool.py (gendoc) being run:
Updating policy/booleans.conf and policy/modules.conf
.../build-buildroot-sawshark/buildroot/output/host/usr/bin/python3 support/sedoctool.py -b policy/booleans.conf -m policy/modules.conf -x doc/policy.xml
I'm sure there is a standard way of doing this, just doesn't seem to be documented anywhere I can find.
Thanks.
Turns out that the sedoctool.py script is reading the doc/policy.xml. Looking at sedoctool.py:
#modules enabled and disabled values
MOD_BASE = "base"
MOD_ENABLED = "module"
MOD_DISABLED = "off"
<...snip...>
def gen_module_conf(doc, file_name, namevalue_list):
"""
Generates the module configuration file using the XML provided and the
previous module configuration.
"""
# If file exists, preserve settings and modify if needed.
# Otherwise, create it.
<...snip...>
mod_name = node.getAttribute("name")
mod_layer = node.parentNode.getAttribute("name")
<...snip...>
if mod_name and mod_layer:
file_name.write("# Layer: %s\n# Module: %s\n" % (mod_layer,mod_name))
if required:
file_name.write("# Required in base\n")
file_name.write("#\n")
if [mod_name, MOD_DISABLED] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_DISABLED))
# If the module is set as enabled.
elif [mod_name, MOD_ENABLED] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_ENABLED))
# If the module is set as base.
elif [mod_name, MOD_BASE] in namevalue_list:
file_name.write("%s = %s\n\n" % (mod_name, MOD_BASE))
So sedoctool.py has the nice feature of: "# If file exists, preserve settings and modify if needed." and modules.conf can just be added whole here via a complete file patch and the modules that are not desired set as "off" : refpolicy-2.20190609/policy/modules.conf and the script will update as needed based on desired policy.
One more detail is that in the next stage of the refpolicy Makefile (Building) the modules.conf with the updates is deleted in the beginning which kind of clashes with the ability of sedoctool to preserve the patched version of modules.conf...so patched the removal in the Building stage of the Makefile.
[7m>>> refpolicy 2.20190609 Building^[
<...snip...>
rm -f policy/modules.conf
The Makefile in refpolicy-2.20190609 has this line that I patched out because we are patching in our own modules.conf:
bare: clean
<...snip...>
$(verbose) rm -f $(mod_conf)
That patch looks like:
--- BUILDROOT/Makefile 2020-08-17 13:25:06.963804709 -0400
+++ FIX/Makefile 2020-08-17 19:25:29.540607763 -0400
## -636,7 +636,6 ##
$(verbose) rm -f $(modxml)
$(verbose) rm -f $(tunxml)
$(verbose) rm -f $(boolxml)
- $(verbose) rm -f $(mod_conf)
$(verbose) rm -f $(booleans)
$(verbose) rm -fR $(htmldir)
$(verbose) rm -f $(tags)
BTW,
Creating a patch with a complete new file in pp1:q!:
diff -crB --new-file pp0 pp1 > pp0.patch
I am new to buildroot and working to build Linaro with buildroot ..I have multiple fragment kernel config files and specified that in buildroot defconfig.
I have specified a custom kernel patches directory with BR2_LINUX_PATCH_DIR .
I dont have some of the config flags not set which are supposed to be there in the .config files..so i suspect that the Patches are applied successfully..so i tried giving a non existing location as Linux Patch dir and it does not give any error..
Is there anything other than giving value to BR2_LINUX_PATCH_DIR and what should be the format of the dir structure...in buildroot manual it says it should be
Package_name/patch name..For linux what should be the package name? It should be the same with which linux dir is created.for example for me it is linux-custom
Plz suggest and guide me in this.
Thanks in Advance
The option is named BR2_LINUX_KERNEL_PATCH, there is nothing named BR2_LINUX_PATCH_DIR. It applies all patches listed in this option (if those are files), or all files named *.patch if what's given in this option is a directory. See the code in linux/linux.mk:
define LINUX_APPLY_LOCAL_PATCHES
for p in $(filter-out ftp://% http://% https://%,$(LINUX_PATCHES)) ; do \
if test -d $$p ; then \
$(APPLY_PATCHES) $(#D) $$p \*.patch || exit 1 ; \
else \
$(APPLY_PATCHES) $(#D) `dirname $$p` `basename $$p` || exit 1; \
fi \
done
endef
Also, I would recommend that you watch the output of Buildroot: it shows everything it is doing, especially it lists the patches it applied. Look at the line >>> linux .... Patching, which is the marker for the beginning of the patching step of the linux package.
I have doxygen 1.8.5 and Doxverilog (for doxygen 1.7.0). Following the instructions quoted below I get messages saying that patches have previously been applied. Then some of the HUNKs fail.
If I proceed anyway and set up the verilog.cfg, running doxygen with this cfg produces
"Warning: ignoring unsupported tag `OPTIMIZE_OUTPUT_VERILOG =' at line 35, file verilog.cfg"
Then blank output.
The instructions I'm using to setup doxverilog are:
install the doxygen-1.7.0 sources
1. copy the Verilog files verilogparser.y verlogscanner.l and the source files to the doxygen-1.7.0\src directory
2. copy the patch file verilog.patch to directory doxygen-1.7.0
3. open a shell in the doxygen-1.7.0 directory
3.1 configure doxygen
sh configure
3.2 make patch # patch -p1 < verilog.patch
4 compile the source files
make all
5 If the compilation was successful create a doxygen configuration file with # doxygen -s -g verilog.cfg
In the configuration file you should see the option OPTIMIZE_OUTPUT_VERILOG.
The file patterns for the Verilog parser are *.v and *.V