8000 [fw_printenv] Delete lock file after file descriptor close by DanielKupiniak · Pull Request #11 · u-boot/u-boot · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[fw_printenv] Delete lock file after file descriptor close #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

DanielKupiniak
Copy link

After fw_printenv call, the lock file still exists, should be removed to allow another call.

After fw_printenv call, the lock file still exists, should be removed to allow another call.
@bufferoverflow
Copy link
Member

u-boot community does not handle PRs on GitHub, please read https://github.com/u-boot/u-boot/blob/master/README

fbertux pushed a commit to OSSystems/u-boot that referenced this pull request Sep 29, 2020
Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:

 => avb init 0
 => avb verify
 ## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org>

=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
    (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
    #0 0x4b467e in mmc_byte_io common/avb_verify.c:407
    #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
    #2 0x4b4c47 in read_from_partition common/avb_verify.c:533
    #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
    #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
    #5 0x45dabd in do_avb_verify_part cmd/avb.c:245
    #6 0x4af77c in cmd_call common/command.c:499
    u-boot#7 0x4af77c in cmd_process common/command.c:538
    u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
    u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875
    u-boot#10 0x46c780 in run_list common/cli_hush.c:2024
    u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
    u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    u-boot#13 0x4ad609 in cli_loop common/cli.c:217
    u-boot#14 0x4625ae in main_loop common/main.c:65
    u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648
    u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30
    u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879
    u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321
    u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    u-boot#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING

Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
nekromant pushed a commit to RC-MODULE/u-boot that referenced this pull request Feb 3, 2021
…r-uboot to tx018-develop

* commit '75071fa0ab82689a82aeb8f63979d928839573c7': (31 commits)
  Some changes has been made. This code can build in kernel and it working correctly
  Excessive #ifdef was deleted
  1. loading from spl in both versions - mcif and lsif with dts support 2. some corrections
  Function for autoload u-boot from spl is on
  1. Change in format dts-file of remap addresses 2. Some little corrections
  Next iteration of corrections
  This is first commit with corrections according review of code
  Load from SPL
  Intermediate for prepare loading u-boot f
8000
rom spl Reverse order is now for bytes by read from nor
  1. Parameters for memory mapping are reading from fdt 2. Environment of uboot are reading from valid address(remap+offset)for any memory mapping  but always from first mtd 3. Some little corrrections 4. This version was tested for both variants: MCIF and LSIF
  MCIF support
  Now load is working for fdt and kernel (from nor) and ubifs too
  Intermediate, before correction for valid order of bytes
  1. Initialization for NOR, connected via LSIF 2. Two MTD device: nor0 and nor1 3. Partitions: device nor0 <mtd0>, # parts = 4  #: name                size            offset          mask_flags  0: uboot_env           0x00040000      0x00000000      0  1: kernel_dtb          0x00040000      0x00040000      0  2: kernel              0x00800000      0x00080000      0  3: reserved            0x07780000      0x00880000      0 device nor1 <mtd1>, # parts = 1  #: name                size            offset          mask_flags  0: rootfs              0x08000000      0x00000000      0 4. U-boot is saving environment in NOR:uboot_env
  Intermediate
  Intermediate
  Using nand_ids.c instead rcm_nandids.h Other some little correction
  Codestyle corrected
  Intermediate commit
  intermediate
  ...
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 reverts this commit as it broken all boards that have not converted
  to driver model PCI.
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#18-20 are 85xx PCI driver fixes. It adds the support to 64-bit bus and cpu
address as current upstream QEMU uses 64-bit cpu address.

Patch u-boot#23 is minor fix to the 'virtio' command dependency.

Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 reverts this commit as it broken all boards that have not converted
  to driver model PCI.
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#18-20 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Patch u-boot#23 is minor fix to the 'virtio' command dependency.

Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 18, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Series-version: 2
Series-changes: 2
- add descriptions for VirtIO BLK, RTC and power off

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the
  PCI regions, to keep in sync with the pci uclass driver
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Starting from patch#24, these are additional driver support patches.

Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency.

Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#27 enables the VirtIO BLK driver support.

Patch u-boot#28-30 enables the GPIO support.

Patch u-boot#31-32 enables poweroff via GPIO.

Patch u-boot#33 enables RTC over the I2C bus.

Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
lbmeng added a commit to lbmeng/u-boot that referenced this pull request Feb 25, 2021
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>

Series-version: 3
Series-changes: 3
- rebase on top of u-boot/master

Series-changes: 2
- add descriptions for VirtIO BLK, RTC and power off

Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com>
Series-cc: Tom, U-Boot
Cover-letter:
ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
At present when building qemu-ppce500 the following warnings are seen:

===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD     include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================

The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the
  PCI regions, to keep in sync with the pci uclass driver
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Starting from patch#24, these are additional driver support patches.

Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency.

Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch u-boot#27 enables the VirtIO BLK driver support.

Patch u-boot#28-30 enables the GPIO support.

Patch u-boot#31-32 enables poweroff via GPIO.

Patch u-boot#33 enables RTC over the I2C bus.

Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
END
shenki pushed a commit to shenki/u-boot that referenced this pull request Jul 28, 2022
Change-Id: I558d5a04f25c77da71b9ef210e4f37ecd0c49dc1
charkear pushed a commit to HewlettPackard/gxp-uboot that referenced this pull request Jun 28, 2023
rafluan pushed a commit to OSSystems/u-boot that referenced this pull request Jul 25, 2023
…t#11)

omni1000: Add support for the 10" Z101WX16J-CT736 panel

Approved-by: Luan Rafael Carneiro
trini added a commit that referenced this pull request Mar 1, 2024
…U-Boot"

Sumit Garg <sumit.garg@linaro.org> says:

Prerequisite
------------

This patch series requires devicetree-rebasing git repo to be added as a
subtree to the main U-Boot repo via:

$ git subtree add --prefix dts/upstream \
      https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
      v6.7-dts --squash

Background
----------

This effort started while I was reviewing patch series corresponding to
Qcom platforms [1] which was about to import modified devicetree source
files from Linux kernel. I suppose keeping devicetree files sync with
Linux kernel without any DT bindings schema validation has been a pain
for U-Boot SoC/platform maintainers. There has been past discussions
about a single DT repo but that hasn't come up and Linux kernel remained
the place where DT source files as well as bindings are placed and
maintained.

However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
use devicetree-rebasing repo [3] which is a forked copy from Linux
kernel for DT source files as well as bindings. It is tagged at every
Linux kernel major release or intermideate release candidates. So here I
have tried to reuse that to bring DT bingings compliance as well as a
standard way to maintain a regular sync of DT source files with Linux
kernel.

In order to maintain devicetree files sync, U-Boot will maintains a Git
subtree for devicetee-rebasing repo as `dts/upstream` sub-directory.
U-Boot will regularly sync `dts/upstream/` subtree whenever the next window
opens with the next available kernel major release.
`dts/update-dts-subtree.sh` script provides a wrapper around git subtree
pull command, usage from the top level U-Boot source tree, run:

$ ./dts/update-dts-subtree.sh pull <devicetree-rebasing-release-tag>

If required it is also possible to cherry-pick fixes from
devicetree-rebasing tree prior to next sync, usage:

$ ./dts/update-dts-subtree.sh pick <devicetree-rebasing-commit-id>

The RFC/prototype for this series has been discussed with Linux DT
maintainers as well as U-Boot maintainers here [4]. Now we would like to
reach out to wider U-Boot community to seek feedback.

[1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/
[2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
[4] #451

Changes
-------

Traditionally, U-Boot placed copies of devicetree source files from Linux
kernel into `arch/<arch>/dts/<name>.dts` which can be selected via setting
"<name>" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.

SoC/board maintainers are encouraged to migrate to use synced copies from
`dts/upstream/src/<arch>/<vendor>`. To do that enable `OF_UPSTREAM` for the
SoC being used via Kconfig and set up "<vendor>/<name>" when prompted for
`DEFAULT_DEVICE_TREE` by Kconfig.

An example have been shown for Amlogic meson-gxbb SoC and corresponding
derived boards via patch #10 and #11.

Devicetree bindings schema checks
---------------------------------

With devicetee-rebasing Git subtree, the devicetree bindings are also
regularly synced with Linux kernel as `dts/upstream/Bindings/`
sub-directory. This allows U-Boot to run devicetree bindings schema checks
which will bring compliance to U-Boot core/drivers regarding usage of
devicetree.

Dependencies
------------

The DT schema project must be installed in order to validate the DT schema
binding documents and validate DTS files using the DT schema. The DT schema
project can be installed with pip:

$ pip3 install dtschema

Note that 'dtschema' installation requires 'swig' and Python development
files installed first. On Debian/Ubuntu systems:

$ apt install swig python3-dev

Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be
installed. Ensure they are in your PATH (~/.local/bin by default).

Recommended is also to install yamllint (used by dtschema when present).

$ apt install yamllint

Running checks
--------------

In order to perform validation of DTB files, use the ``dtbs_check`` target:

$ make dtbs_check

It is also possible to run checks with a subset of matching schema files by
setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files
or patterns (partial match of a fixed string). Each file or pattern should
be separated by ':'.

$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml
$ make dtbs_check DT_SCHEMA_FILES=/gpio/
$ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0