-
Notifications
You must be signed in to change notification settings - Fork 4k
[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
DanielKupiniak
wants to merge
2
commits into
u-boot:master
from
<
8000
a title="DanielKupiniak/u-boot:DanielKupiniak-RemoveLockFileAfterFileDescriptorClose" class="no-underline " href="/DanielKupiniak/u-boot/tree/DanielKupiniak-RemoveLockFileAfterFileDescriptorClose">DanielKupiniak:DanielKupiniak-RemoveLockFileAfterFileDescriptorClose
Closed
[fw_printenv] Delete lock file after file descriptor close #11
DanielKupiniak
wants to merge
2
commits into
u-boot:master
from
DanielKupiniak:DanielKupiniak-RemoveLockFileAfterFileDescriptorClose
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After fw_printenv call, the lock file still exists, should be removed to allow another call.
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
Coverity arm
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After fw_printenv call, the lock file still exists, should be removed to allow another call.