Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
On Friday, December 3, 2021, Simon Glass wrote: > Hi Andy, > > On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko > wrote: > > > > Importing libraries in Python caches the bytecode by default. > > Since we run scripts in source tree it ignores the current directory > > settings, which is $(srctree), and creates cache just in the middle > > of the source tree. Move cache to the current directory. > > > > Signed-off-by: Andy Shevchenko > > --- > > v2: reused our_path > > tools/binman/main.py | 11 ++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > This look useful, but we cannot rely on 'srcdir' being in the > environment. True and code is aware of that. Nothing needs to be fixed. > > For example, most binman development is done just by > running 'binman test' in the source tre. So perhaps default to the > current directory is 'srcdir' is not set? > > Regards, > Simon > > > > > > diff --git a/tools/binman/main.py b/tools/binman/main.py > > index 8c1e478d54ce..4d8b124c7468 100755 > > --- a/tools/binman/main.py > > +++ b/tools/binman/main.py > > @@ -16,9 +16,18 @@ import sys > > import traceback > > import unittest > > > > +# Get the absolute path to this file at run-time > > +our_path = os.path.dirname(sys.argv[0]) > > + > > +# > > +# Do not pollute source tree with cache files: > > +# https://stackoverflow.com/a/60024195/2511795 > > +# https://bugs.python.org/issue33499 > > +# > > +sys.pycache_prefix = os.path.relpath(our_path, os.environ['srctree']) > > + > > # Bring in the patman and dtoc libraries (but don't override the first > path > > # in PYTHONPATH) > > -our_path = os.path.dirname(os.path.realpath(__file__)) > > sys.path.insert(2, os.path.join(our_path, '..')) > > > > from patman import test_util > > -- > > 2.33.0 > > > -- With Best Regards, Andy Shevchenko
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > Eh? If the device tree files are actually common then there should be > a single source. If U-Boot has a copy then it should be identical. > > The special node thing makes no sense for U-Boot. We just need to > upstream our bindings and I am working on that. Yea we discussed this on v5. If the device bindings are upstreamed things gets substantially easier. But that's a big if. > > Are the device tree files moving out of Linux? There was an effort from Linaro and iirc we tried to move a few and see how things would work out, but there's nothing official. Regards /Ilias
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, > > > > > [...] > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... Last time we said we don't really have to remove them, but I get the point. > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes for the power domain controllers need to have the > "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't > be able to bind the power domain controller driver in this phase and > binding the serial port driver itself will fail. Which makes U-Boot > hang without any visible output on the serial console. Very relevant indeed. That's close to what I was afraid of when I said "if we could figure out were the specific U-Boot config nodes are needed and *when* are they needed". Obviously this is a clear no go, since more boards will have similar requirements in the future. > > Within the Asahi Linux group we're currently discussing how to solve > this. We could just add the "u-boot,dm-pre-reloc" properties in the > device trees that we're going to distribute as part of m1n1 (the > "bootloader" than embeds U-Boot). Or we can write some code that adds > those properties to the device tree nodes that are dependencies for > the serial port. That might make sense for a project like m1n1 were you are dealing with a handful of devices, but I think it's going to be a pain on a larger scale, unless of course the bindings are documented in upstream. In that case we could ask previous bootloaders to add them etc. > > I don't think the suggestion of applying an overlay embedded in U-Boot > would work here. The code applying the overlay would need to run very > early on in the pre-relocation phase. Yep it wouldn't > We'd also have to include > overlays for all the models that Apple offers and pick the right one. > And if a new model appears we can no longer just add a new device tree > to m1n1. > > But maybe there is a case where the overlay approach would make sense... I think there is, for example I was thinking of TF-A doing all the hardware init and then handover a DTB into u-boot on a register. In that case U-boot could fixup the DTB before initialing the rest of the subsystems and make DM happy. However as you pointed out that's not the case for all boards and dealing with this in the early pre-relocation stage is close to impossible, so let's drop that. Thanks! /Ilias
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Heinrich, On Tue, Nov 16, 2021 at 12:01:27PM +0900, AKASHI Takahiro wrote: > On Tue, Nov 16, 2021 at 01:02:55AM +0100, Heinrich Schuchardt wrote: > > On 11/16/21 00:51, AKASHI Takahiro wrote: > > > > > Is the patch good enough to include in the series? > > > > > > > > > > If not, you could reply to it with what needs doing. > > > ? I have already replied to your patch:) > > > Basically, it seems to be fine to me. > > > > > > > > Regards, > > > > > Simon > > > > > > > > > The patch is not usable as is. It assumes only GPT partioning is used. > > > @Heinrich > > > I don't get your point. Either my patch or Simon's is not specific > > > to GPT at all. > > > > > > So I'm going to start respinning my patch for a next round of discussion. > > > > A field name gpt_part_info obviously relates to GPT? > > No. > > IICU, the structure, disk_partition, is not particularly GPT-specific > as such type of data are used over various partition drivers. > In my patch series, I simply reuse "struct disk_part" as a structure > holding a partition number and partition information (= disk_partition). So do you agree that we won't have "partition-table" devices for now? -Takahiro Akashi > -Takahiro Akashi > > > Up to now this string exists only in cmd/gpt.c. > > > > Best regards > > > > Heinrich > > > > > > > > -Takahiro Akashi > > > > > > > Instead all partition table drivers need to be converted to drivers for > > > > the new uclass. > > > > > > > > Best regards > > > > > > > > Heinrich > >
Re: [BUG] efi_loader: incorrect creation of device paths
Heinrich, On Thu, Nov 25, 2021 at 02:44:28PM +0900, AKASHI Takahiro wrote: > Heinrich, > > On Wed, Nov 24, 2021 at 12:10:32PM +0900, AKASHI Takahiro wrote: > > On Sat, Nov 20, 2021 at 01:54:30PM +0100, Heinrich Schuchardt wrote: > > > Hello Takahiro, > > > > > > in a prior mail we have discussed the creation of device paths for USB > > > mass storage devices. > > > > > > On the sand boxyou get the following devices after 'usb start': > > > > > > Class Index Probed DriverName > > > --- > > > usb 0 [ + ] usb_sandbox |-- usb@1 > > > usb_hub 0 [ + ] usb_hub | `-- hub > > > usb_mass_s0 [ + ] usb_mass_storage | |-- > > > usb_mass_storage > > > blk 3 [ ] usb_storage_blk | | `-- > > > usb_mass_storage.lun0 > > > usb_mass_s1 [ + ] usb_mass_storage | |-- > > > usb_mass_storage > > > blk 4 [ ] usb_storage_blk | | `-- > > > usb_mass_storage.lun0 > > > usb_mass_s2 [ + ] usb_mass_storage | `-- > > > usb_mass_storage > > > blk 5 [ ] usb_storage_blk | `-- > > > usb_mass_storage.lun0 > > > > > > For of these storage devices we try to create the same device path which > > > is not allowable: > > > > > > => usb start > > > starting USB... > > > Bus usb@1: scanning bus usb@1 for devices... 5 USB Device(s) found > > >scanning usb for storage devices... 3 Storage Device(s) found > > > => > > > => efidebug dh > > > Scanning disk mmc2.blk... > > > handle 15e34f00, > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(2)/SD(0) > > > Scanning disk mmc1.blk... > > > handle 15e36b30, > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(1)/SD(1) > > > Scanning disk mmc0.blk... > > > handle 15e35b00, > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(2) > > > Scanning disk usb_mass_storage.lun0... > > > handle 15e35c10, > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0) > > > fs_devread read outside partition 2 > > > Failed to mount ext2 filesystem... > > > BTRFS: superblock end 69632 is larger than device size 512 > > > Scanning disk usb_mass_storage.lun0... > > > handle 15e361f0, > > > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x1234,0x5678,0x9,0x0,0x0)/UsbClass(0x1234,0x5678,0x0,0x0,0x0) > > > ERROR: failure to add disk device usb_mass_storage.lun0, r = 20 > > > Error: Cannot initialize UEFI sub-system, r = 20 > > > > > > I will provide a patch that will allow the first USB device to be used > > > and avoids stopping the boot process. But we really have to walk the dm > > > tree to create a device patch for USB devices based on port IDs. > > > > > > We should add a new field to struct uclass_driver: > > > > > > struct efi_device_path *get_node(udevice *dev); > > > > > > This function shall return a pointer to an freshly allocated buffer with > > > the device node for the device. To build the devicepath we can then walk > > > the dm tree. > > > > I'm not sure this is an acceptable solution. > > > > Let me make sure: > > The goal would be to create a device path like > >.../USB(0x1,0x0)/HD(1,...) > > instead of > >.../UsbHub(0x0,0x0,0x0,0x3)/UsbMassStorage(0x46f4,0x1,0x0,0x0)/HD(1,...) > > as we already see this format for SCSI: > >.../Scsi(0,0)/HD(1,..) > > > > Right? > > Please try the tweak attached below. > (I think what I did here is trivial.) > > If you like, I will post it as a patch. > (See "10.3.4.5.1 USB Device Path Example".) Any comment on my proposal? > -Takahiro Akashi > > >>> From cda91e9d8144f89f0d73738b338289a7940bbe0e Mon Sep 17 00:00:00 2001 > >>> From: AKASHI Takahiro > >>> Date: Thu, 25 Nov 2021 14:20:08 +0900 > >>> Subject: [PATCH] efi_loader: disk: usb mass-storage > > - use path_usb instead of path_usb_class for existing USB dp nodes > - add a dp node for UCLASS_USB > > => usb start > starting USB... > Bus xhci_pci: Register 8001040 NbrPorts 8 > Starting the controller > USB XHCI 1.00 > scanning bus xhci_pci for devices... 4 USB Device(s) found >scanning usb for storage devices... 2 Storage Device(s) found > => dm tree > Class Index Probed DriverName > --- > root 0 [ + ] root_driver root_driver > ... > pci 0 [ + ] pci_generic_ecam |-- pcie@1000 > pci_generi0 [ ] pci_generic_drv | |-- pci_0:0.0 > virtio 32 [ + ] virtio-pci.l | |-- virtio-pci.l#0 > ethernet 0 [ + ] virtio-net| | `-- virtio-net#32 > usb 0 [ + ] xhci_pci | `-- xhci_pci > usb_hub 0 [ + ] usb_hub | `-- usb_hub > usb_dev_ge0 [ + ] usb_dev_generic
Re: [PATCH v7 00/12] efi_loader: capsule: improve capsule authentication support
Heinrich, On Thu, Nov 25, 2021 at 03:02:35PM +0900, AKASHI Takahiro wrote: > Hi Heinrich > > On Tue, Nov 16, 2021 at 01:32:26PM +0900, AKASHI Takahiro wrote: > > As I proposed and discussed in [1] and [2], I have made a couple of > > improvements on the current implementation of capsule update in this > > patch set. > > For this version(v7), I have seen your review comments only > on patch#1 and #2. > Please take your time to review the rest (the main part of > commits) as well. > I don't want to respin the patch series and post its new version > which is almost the same as the old one(v7). Ping. -Takahiro Akashi > -Takahiro Akashi > > > > * add signing feature to mkeficapsule > > * add "--guid" option to mkeficapsule > > * add man page of mkeficapsule > > * update uefi document regarding capsule update > > * revise pytests > > * (as RFC) add CONFIG_EFI_CAPSULE_KEY_PATH > > > > # We have had some discussion about fdtsig.sh. > > # So RFCs (patch#11,#12) are still included for further discussion > > # if they are useful or not. > > # For smooth merge, the rest (patch#1-10) should work without them. > > > > [1] https://lists.denx.de/pipermail/u-boot/2021-April/447918.html > > [2] https://lists.denx.de/pipermail/u-boot/2021-July/455292.html > > > > Prerequisite patches > > > > None > > > > Test > > > > * locally passed the pytest which is included in this patch series > > on sandbox built. > > (CONFIG_EFI_CAPSULE_AUTHENTICATE should explicitly be turned on > > in order to exercise the authentication code.) > > > > Changes > > === > > v7 (Nov 16, 2021) > > * rebased on pre-v2022.01-rc2 > > * drop already-merged patch > > * check for a size of firmware binary file (patch#1) > > * enable mkeficapsule in tools-only_defconfig (patch#2) > > * define eficapsule.h and include it from mkeficapsule (patch#3) > > Hopefully, the tool can now compile on non-linux host. > > > > v6 (Nov 02, 2021) > > * rebased on pre-v2022.01-rc1 > > * add patch#2 to rework/refactor the code for better readability (patch#2) > > * use exit(EXIT_SUCCESS/FAILURE) (patch#3) > > * truncate >80chars lines in pytest scripts (patch#6) > > > > v5 (Oct 27, 2021) > > * rebased on pre-v2022.01-rc1 (WIP/26Oct2021) > > * drop already-merged patches > > * drop __weak from efi_get_public_key_data() (patch#1) > > * describe the format of public key node in device tree (patch#4) > > * re-order patches by grouping closely-related patches (patch#6-8) > > * modify pytest to make the test results correctly verified > > either with or without CONFIG_EFI_CAPSULE_AUTHENTICATE (patch#9) > > * add RFCs for embedding public keys during the build process (patch#10,11) > > > > v4 (Oct 7, 2021) > > * rebased on v2021.10 > > * align with "Revert "efi_capsule: Move signature from DTB to .rodata"" > > * add more missing *revert* commits (patch#1,#2,#3) > > * add fdtsig.sh, replacing dtb support in mkeficapsule (patch#4) > > * update/revise the man/uefi doc (patch#6,#7) > > * fix a bug in parsing guid string (patch#8) > > * add a test for "--guid" option (patch#10) > > * use dtb-based authentication test as done in v1 (patch#11) > > > > v3 (Aug 31, 2021) > > * rebased on v2021.10-rc3 > > * remove pytest-related patches > > * add function descriptions in mkeficapsule.c > > * correct format specifiers in printf() > > * let main() return 0 or -1 only > > * update doc/develop/uefi/uefi.rst for syntax change of mkeficapsule > > > > v2 (July 28, 2021) > > * rebased on v2021.10-rc* > > * removed dependency on target's configuration > > * removed fdtsig.sh and others > > * add man page > > * update the UEFI document > > * add dedicate defconfig for testing on sandbox > > * add gitlab CI support > > * add "--guid" option to mkeficapsule > > (yet rather RFC) > > > > Initial release (May 12, 2021) > > * based on v2021.07-rc2 > > > > AKASHI Takahiro (12): > > tools: mkeficapsule: rework the code a little bit > > tools: build mkeficapsule with tools-only_defconfig > > tools: mkeficapsule: add firmwware image signing > > tools: mkeficapsule: add man page > > doc: update UEFI document for usage of mkeficapsule > > test/py: efi_capsule: add image authentication test > > tools: mkeficapsule: allow for specifying GUID explicitly > > test/py: efi_capsule: align with the syntax change of mkeficapsule > > test/py: efi_capsule: add a test for "--guid" option > > test/py: efi_capsule: check the results in case of > > CAPSULE_AUTHENTICATE > > (RFC) tools: add fdtsig.sh > > (RFC) efi_loader, dts: add public keys for capsules to device tree > > > > MAINTAINERS | 2 + > > configs/tools-only_defconfig | 1 + > > doc/develop/uefi/uefi.rst | 143 ++-- > > doc/mkeficapsule.1| 107 +++ > > dts/Makefile | 23 +- > > lib/efi_loader/Kconfig| 7 + > > .../py/te
[PULL] u-boot-riscv/master
Hi Tom, The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-11-30 08:59:22 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-riscv.git for you to fetch changes up to c0ffc12a701621dc72dfc896965cbfe5b0dbf9b4: riscv: Enable SPI flash env for SiFive Unmatched. (2021-12-02 16:43:56 +0800) CI result shows no issue: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/10128 Leo Yu-Chi Liang (1): board: ae350: Support autoboot from RAM Padmarao Begari (5): net: macb: Remove Microchip compatible string i2c: Add Microchip PolarFire SoC I2C driver riscv: dts: Split Microchip device tree riscv: Update Microchip MPFS Icicle Kit support doc: board: Update Microchip MPFS Icicle Kit doc Thomas Skibo (2): riscv: Support booting SiFive Unmatched from SPI. riscv: Enable SPI flash env for SiFive Unmatched. arch/riscv/cpu/fu740/Kconfig | 13 + arch/riscv/dts/hifive-unmatched-a00-u-boot.dtsi| 11 + arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 518 +-- arch/riscv/dts/microchip-mpfs.dtsi | 571 + board/microchip/mpfs_icicle/Kconfig| 5 + board/microchip/mpfs_icicle/mpfs_icicle.c | 17 +- board/sifive/unmatched/Kconfig | 1 + board/sifive/unmatched/spl.c | 3 + configs/microchip_mpfs_icicle_defconfig| 1 - configs/sifive_unmatched_defconfig | 6 + doc/board/microchip/mpfs_icicle.rst| 7 +- doc/board/sifive/unmatched.rst | 31 ++ drivers/i2c/Kconfig| 6 + drivers/i2c/Makefile | 1 + drivers/i2c/i2c-microchip.c| 482 + drivers/net/macb.c | 18 +- include/configs/ax25-ae350.h | 13 +- .../interrupt-controller/microchip-mpfs-plic.h | 196 +++ .../dt-bindings/interrupt-controller/riscv-hart.h | 17 + 19 files changed, 1512 insertions(+), 405 deletions(-) create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi create mode 100644 drivers/i2c/i2c-microchip.c create mode 100644 include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h Best regards, Leo
Re: [RESEND RFC PATCH 04/10] FWU: Add metadata access functions for GPT partitioned block devices
hi Simon, On Thu, 2 Dec 2021 at 19:04, Simon Glass wrote: > Hi Sughosh, > > On Thu, 2 Dec 2021 at 01:05, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Wed, 1 Dec 2021 at 23:32, Simon Glass wrote: > >> > >> Hi Sughosh, > >> > >> On Thu, 25 Nov 2021 at 00:13, Sughosh Ganu > wrote: > >> > > >> > In the FWU Multi Bank Update feature, the information about the > >> > updatable images is stored as part of the metadata, on a separate > >> > partition. Add functions for reading from and writing to the metadata > >> > when the updatable images and the metadata are stored on a block > >> > device which is formated with GPT based partition scheme. > >> > > >> > Signed-off-by: Sughosh Ganu > >> > --- > >> > lib/fwu_updates/fwu_metadata_gpt_blk.c | 716 > + > >> > 1 file changed, 716 insertions(+) > >> > create mode 100644 lib/fwu_updates/fwu_metadata_gpt_blk.c > >> > >> Can we pick a better name than metadata? It is just so > >> vague...everything is metadata. > > > > > > The specification calls it metadata. And the functions in this file are > for accessing the metadata on a GPT partitioned block device. Do you have > any alternate name for this? > > Well lots of things call their metadata "metadata". That doesn't mean > it is a good name for the code base. Which specification? Do you have > a link? > I am referring to the FWU specification[1]. Please refer to section 4 in the document. -sughosh [1] - https://developer.arm.com/documentation/den0118/a
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 02.12.21 19:57, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko > wrote: >> Hi, Simon! >> >> Sorry for being late to the party >> >> On 02.12.21 17:59, Simon Glass wrote: >>> Add an empty file to prevent build errors when building with >>> CONFIG_OF_SEPARATE enabled. >>> >>> The build instructions in U-Boot do not provide enough detail to build a >>> useful devicetree, unfortunately. >> Xen guest doesn't use any built-in device trees as the guest's device tree >> is provided >> by the Xen hypervisor itself and is generated at the virtual machine >> creation time: it is >> populated with memory size, number of CPUs etc. based on [1]. >> So, even if we provide some device tree here it must not be used by U-boot at >> the end of the day. Thus, it might be a reasonable solution to provide an >> empty device >> tree as you do, but put a comment that it is not used. > OK we can go with an empty one if we have to, but where are the > instructions to create the DT that is used? You don't need to create the device tree yourself, but instead it is provided by Xen and generated at run-time while creating a virtual machine. So, it is up to Xen to provide one. There are cases [1] when you may want providing a so called partial device tree to better tune what a virtual machine gets. But again, it is used by Xen toolstack outside of the virtual machine and serves as a sort of overlay to the generated device tree. So, we can provide some device tree to be embedded in U-boot, but it will have no practical meaning and will make more harm than good > > I'm not even sure how to run U-Boot with Xen? The in-tree instructions > don't help... This is just a virtual machine from Xen POV, so U-boot is nothing different here from Linux kernel or anything else. Thus no specific instructions are needed nor provided Thank you, Oleksandr > > Regards, > Simon [1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
Re: [PATCH 01/15] i2c: muxes: pca954x: add PCA9847 variant
Hello Vladimir, On 02.12.21 15:53, Vladimir Oltean wrote: > This seems to be very similar to the already existing PCA9547, save for > the fact that it supports 0.8V and doesn't support 5V. In fact, it is so > similar to the PCA9547 that the NXP LS1028A-RDB board has been driving > this chip using a "nxp,pca9547" compatible string. > > Create a new compatible for the PCA9847 (which is the same as in Linux) > and define the same operating parameters for it as for PCA9547. > > Cc: Heiko Schocher > Signed-off-by: Vladimir Oltean > --- > drivers/i2c/muxes/pca954x.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Reviewed-by: Heiko Schocher Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH 3/3] efi_loader: correctly handle tcg2_measure_pe_image() error
When the TCG2 protocol is installed in efi_tcg2_register(),
TPM2 device must be present.
tcg2_measure_pe_image() expects that TCP2 protocol is installed
and TPM device is available. If TCG2 Protocol is installed but
TPM device is not found, tcg2_measure_pe_image() returns
EFI_SECURITY_VIOLATION efi_load_image() ends with failure.
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_image_loader.c | 11 +--
lib/efi_loader/efi_tcg2.c | 2 +-
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index eb95580538..426f096574 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -934,9 +934,16 @@ efi_status_t efi_load_pe(struct efi_loaded_image_obj
*handle,
#if CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL)
/* Measure an PE/COFF image */
- if (tcg2_measure_pe_image(efi, efi_size, handle,
- loaded_image_info))
+ ret = tcg2_measure_pe_image(efi, efi_size, handle, loaded_image_info);
+ if (ret == EFI_SECURITY_VIOLATION) {
+ /*
+* TCG2 Protocol is installed but no TPM device found,
+* this is not expected.
+*/
log_err("PE image measurement failed\n");
+ goto err;
+ }
+
#endif
/* Copy PE headers */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 2b7b7cbbae..c19f73dc10 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -977,7 +977,7 @@ efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
ret = platform_get_tpm2_device(&dev);
if (ret != EFI_SUCCESS)
- return ret;
+ return EFI_SECURITY_VIOLATION;
switch (handle->image_type) {
case IMAGE_SUBSYSTEM_EFI_APPLICATION:
--
2.17.1
[PATCH 2/3] efi_loader: check tcg2 protocol installation outside the TCG protocol
There are functions that calls tcg2_agile_log_append() outside
of the TCG protocol invocation (e.g tcg2_measure_pe_image).
These functions must to check that TCG2 protocol is installed.
If not, measurement shall be skipped.
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_tcg2.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 6dbdd35f29..2b7b7cbbae 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -972,6 +972,9 @@ efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
IMAGE_NT_HEADERS32 *nt;
struct efi_handler *handler;
+ if (!is_tcg2_protocol_installed())
+ return EFI_SUCCESS;
+
ret = platform_get_tpm2_device(&dev);
if (ret != EFI_SUCCESS)
return ret;
@@ -2189,6 +2192,9 @@ efi_status_t efi_tcg2_measure_efi_app_invocation(struct
efi_loaded_image_obj *ha
u32 event = 0;
struct smbios_entry *entry;
+ if (!is_tcg2_protocol_installed())
+ return EFI_SUCCESS;
+
if (tcg2_efi_app_invoked)
return EFI_SUCCESS;
@@ -2239,6 +2245,9 @@ efi_status_t efi_tcg2_measure_efi_app_exit(void)
efi_status_t ret;
struct udevice *dev;
+ if (!is_tcg2_protocol_installed())
+ return EFI_SUCCESS;
+
ret = platform_get_tpm2_device(&dev);
if (ret != EFI_SUCCESS)
return ret;
@@ -2264,6 +2273,12 @@ efi_tcg2_notify_exit_boot_services(struct efi_event
*event, void *context)
EFI_ENTRY("%p, %p", event, context);
event_log.ebs_called = true;
+
+ if (!is_tcg2_protocol_installed()) {
+ ret = EFI_SUCCESS;
+ goto out;
+ }
+
ret = platform_get_tpm2_device(&dev);
if (ret != EFI_SUCCESS)
goto out;
@@ -2293,6 +2308,9 @@ efi_status_t
efi_tcg2_notify_exit_boot_services_failed(void)
struct udevice *dev;
efi_status_t ret;
+ if (!is_tcg2_protocol_installed())
+ return EFI_SUCCESS;
+
ret = platform_get_tpm2_device(&dev);
if (ret != EFI_SUCCESS)
goto out;
--
2.17.1
[PATCH 0/3] fix TCG2 error handling
This series fix the efi_tcg2.c error handling. Masahisa Kojima (3): efi_loader: efi_tcg2_register returns appropriate error efi_loader: check tcg2 protocol installation outside the TCG protocol efi_loader: correctly handle tcg2_measure_pe_image() error include/efi_loader.h | 2 + lib/efi_loader/Kconfig| 2 + lib/efi_loader/efi_image_loader.c | 11 +++- lib/efi_loader/efi_setup.c| 2 + lib/efi_loader/efi_tcg2.c | 85 --- 5 files changed, 81 insertions(+), 21 deletions(-) -- 2.17.1
[PATCH 1/3] efi_loader: efi_tcg2_register returns appropriate error
This commit modify efi_tcg2_register() to return the
appropriate error.
With this fix, sandbox will not boot because efi_tcg2_register()
fails due to some missing feature in GetCapabilities.
So disable sandbox if EFI_TCG2_PROTOCOL is enabled.
UEFI secure boot variable measurement is not directly related
to TCG2 protocol installation, tcg2_measure_secure_boot_variable()
is moved to the separate function.
Signed-off-by: Masahisa Kojima
---
include/efi_loader.h | 2 ++
lib/efi_loader/Kconfig | 2 ++
lib/efi_loader/efi_setup.c | 2 ++
lib/efi_loader/efi_tcg2.c | 65 +++---
4 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 67c40ca57a..f4860e87fc 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -525,6 +525,8 @@ efi_status_t efi_disk_register(void);
efi_status_t efi_rng_register(void);
/* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
efi_status_t efi_tcg2_register(void);
+/* Called by efi_init_obj_list() to do initial measurement */
+efi_status_t efi_tcg2_do_initial_measurement(void);
/* measure the pe-coff image, extend PCR and add Event Log */
efi_status_t tcg2_measure_pe_image(void *efi, u64 efi_size,
struct efi_loaded_image_obj *handle,
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 700dc838dd..24f9a2bb75 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -308,6 +308,8 @@ config EFI_TCG2_PROTOCOL
bool "EFI_TCG2_PROTOCOL support"
default y
depends on TPM_V2
+ # Sandbox TPM currently fails on GetCapabilities needed for TCG2
+ depends on !SANDBOX
select SHA1
select SHA256
select SHA384
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 1aba71cd96..f58a4afa7f 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -241,6 +241,8 @@ efi_status_t efi_init_obj_list(void)
ret = efi_tcg2_register();
if (ret != EFI_SUCCESS)
goto out;
+
+ efi_tcg2_do_initial_measurement();
}
/* Secure boot */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 5f71b188a0..6dbdd35f29 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -153,6 +153,15 @@ static u16 alg_to_len(u16 hash_alg)
return 0;
}
+static bool is_tcg2_protocol_installed(void)
+{
+ struct efi_handler *handler;
+ efi_status_t ret;
+
+ ret = efi_search_protocol(efi_root, &efi_guid_tcg2_protocol, &handler);
+ return ret == EFI_SUCCESS;
+}
+
static u32 tcg_event_final_size(struct tpml_digest_values *digest_list)
{
u32 len;
@@ -1664,6 +1673,14 @@ void tcg2_uninit(void)
event_log.buffer = NULL;
efi_free_pool(event_log.final_buffer);
event_log.final_buffer = NULL;
+
+ if (!is_tcg2_protocol_installed())
+ return;
+
+ ret = efi_remove_protocol(efi_root, &efi_guid_tcg2_protocol,
+ (void *)&efi_tcg2_protocol);
+ if (ret != EFI_SUCCESS)
+ log_err("Failed to remove EFI TCG2 protocol\n");
}
/**
@@ -2345,12 +2362,37 @@ error:
return ret;
}
+/**
+ * efi_tcg2_do_initial_measurement() - do initial measurement
+ *
+ * Return: status code
+ */
+efi_status_t efi_tcg2_do_initial_measurement(void)
+{
+ efi_status_t ret;
+ struct udevice *dev;
+
+ if (!is_tcg2_protocol_installed())
+ return EFI_SUCCESS;
+
+ ret = platform_get_tpm2_device(&dev);
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+ ret = tcg2_measure_secure_boot_variable(dev);
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+out:
+ return ret;
+}
+
/**
* efi_tcg2_register() - register EFI_TCG2_PROTOCOL
*
* If a TPM2 device is available, the TPM TCG2 Protocol is registered
*
- * Return: An error status is only returned if adding the protocol fails.
+ * Return: status code
*/
efi_status_t efi_tcg2_register(void)
{
@@ -2373,8 +2415,10 @@ efi_status_t efi_tcg2_register(void)
}
ret = efi_init_event_log();
- if (ret != EFI_SUCCESS)
+ if (ret != EFI_SUCCESS) {
+ tcg2_uninit();
goto fail;
+ }
ret = efi_add_protocol(efi_root, &efi_guid_tcg2_protocol,
(void *)&efi_tcg2_protocol);
@@ -2391,24 +2435,9 @@ efi_status_t efi_tcg2_register(void)
goto fail;
}
- ret = tcg2_measure_secure_boot_variable(dev);
- if (ret != EFI_SUCCESS) {
- tcg2_uninit();
- goto fail;
- }
-
return ret;
fail:
log_err("Cannot install EFI_TCG2_PROTOCOL\n");
- /*
-* Return EFI_SUCCESS and don't stop the EFI subsystem.
-* That's done for 2 reasons
-
Re: [PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
Hi Peter, On Wed, 1 Dec 2021 at 07:23, Peter Robinson wrote: > > On Thu, Nov 25, 2021 at 5:39 PM Alper Nebi Yasak > wrote: > > > > I have recently started testing booting U-Boot from SPI on my gru-kevin > > (as opposed to chainloading it from vendor coreboot + depthcharge) and > > brought it to a better working state based on an initial support patch > > from Marty [1][2] and some follow-up work by Simon [3]. > > > > I tried to keep them as the git author when I took things from their > > work, but squashing other changes into those and rewriting commit > > messages makes things a bit weird in my opinion, especially for keeping > > their signoff. Do tell me if there is a better way to that. > > > > As the Kevin and Bob boards are very similar. I assumed the config and > > devicetree changes will be appropriate for Bob as well, and applied them > > to it first. I do not have a Bob, so could not test on one myself, but > > Simon did test an earlier version of this and it appears to work [4]. > > > > Other useful things for these boards: > > - Patch to fix a hang when usb controllers exit [5] > > - Series to support HS400ES mode as HS400 training fails [6] > > - Hack to skip eMMC reinitialization so it keeps working [7] > > Is there docs updates to be done in doc/chromium/ for this so people > know how to use it ? This is for bare-metal use though, so it isn't anything to do with Chromium at present. Regards, Simon
Re: [PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
Hi Alper, On Thu, 25 Nov 2021 at 10:39, Alper Nebi Yasak wrote: > > I have recently started testing booting U-Boot from SPI on my gru-kevin > (as opposed to chainloading it from vendor coreboot + depthcharge) and > brought it to a better working state based on an initial support patch > from Marty [1][2] and some follow-up work by Simon [3]. > > I tried to keep them as the git author when I took things from their > work, but squashing other changes into those and rewriting commit > messages makes things a bit weird in my opinion, especially for keeping > their signoff. Do tell me if there is a better way to that. > > As the Kevin and Bob boards are very similar. I assumed the config and > devicetree changes will be appropriate for Bob as well, and applied them > to it first. I do not have a Bob, so could not test on one myself, but > Simon did test an earlier version of this and it appears to work [4]. > > Other useful things for these boards: > - Patch to fix a hang when usb controllers exit [5] > - Series to support HS400ES mode as HS400 training fails [6] > - Hack to skip eMMC reinitialization so it keeps working [7] > > [1] https://patchwork.ozlabs.org/patch/1053386/ > [2] https://patchwork.ozlabs.org/comment/2488899/ > [3] https://github.com/sjg20/u-boot/commits/kevin > [4] > https://lore.kernel.org/u-boot/capnjgz23jd92y9ni8yw1ftl0a1sjhgouoakx13zkokn6t-s...@mail.gmail.com/ > [5] > https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icen...@aosc.io/ > [6] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 > [7] https://patchwork.ozlabs.org/comment/2779784/ > > > Alper Nebi Yasak (2): > rockchip: gru: Set up SoC IO domain registers > rockchip: bob: Enable more configs > > Marty E. Plummer (1): > rockchip: rk3399: Add support for chromebook_kevin > > Simon Glass (1): > rockchip: gru: Add more devicetree settings > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ > arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 + > arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ > arch/arm/mach-rockchip/rk3399/rk3399.c| 4 +- > arch/arm/mach-rockchip/spl.c | 3 +- > board/google/gru/Kconfig | 16 +++ > board/google/gru/MAINTAINERS | 8 ++ > board/google/gru/gru.c| 56 - > configs/chromebook_bob_defconfig | 27 +++- > configs/chromebook_kevin_defconfig| 116 ++ > doc/board/rockchip/rockchip.rst | 1 + > include/configs/gru.h | 3 + > include/dt-bindings/input/linux-event-codes.h | 3 +- > 14 files changed, 309 insertions(+), 6 deletions(-) > create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi > create mode 100644 configs/chromebook_kevin_defconfig > > -- > 2.34.0 > My test results below. It seems that MMC is broken (I think by a previous change). The garbage on the console with kevin is new but may be unrelated to your patches, not sure. So it seems that your patches work for me on both. Bob: do-try-int.sh bob Revision 68acce8a08beb24618343a1ce7ee6c0c4c234b97, board bob Checking revision 68acce8a08beb24618343a1ce7ee6c0c4c234b97 /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev= '68acce8a08beb24618343a1ce7ee6c0c4c234b97' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: bob │ │ │ └─Done. (1.104s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (10.289s) │ │ └─Done. (11.767s) │ ├─Calling uboot_flash ... │ │ └─Done. (2.209s) │ └─Done. (14.438s) ├─ └─SUCCESS (16.780s) tbot starting ... ├─Calling interactive_board ... │ ├─bob is on port 9904 and uses /dev/pts/37 │ ├─POWERON (bob) │ ├─Entering interactive shell (CTRL+D to exit) ... Channel 0: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB Channel 1: LPDDR3, 933MHz BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB 256B stride U-Boot SPL 2022.01-rc3-00130-g68acce8a08b (Dec 02 2021 - 20:05:54 -0700) Trying to boot from SPI rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 rockchip_rk3399_pinctrl pinctrl: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 ns16550_serial serial@ff1a: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2022.01-rc3-00130-g68acce8a08b (Dec 02 2021 - 20:05:54 -0700) Model: Google Bob DRAM: 3.9 GiB MMC: mmc@fe32: 1, mmc@fe33: 0 Loading Environment from MMC... Select HS400ES failed -524 unable to select a mode : -5 *** Warning - No block device, using default environment In:cros-ec-keyb O
Re: [PATCH u-boot-marvell RESEND 04/11] fdt_support: Remove FDT_STATUS_FAIL_ERROR_CODE
On Fri, 26 Nov 2021 at 06:57, Marek Behún wrote: > > From: Marek Behún > > Since no one uses this feature and I am not aware of any parsers of this > in Linux, remove it. > > Signed-off-by: Marek Behún > Reviewed-by: Stefan Roese > Cc: Simon Glass > Cc: Andy Shevchenko > Cc: Pratyush Yadav > Cc: Tim Harvey > Cc: Michael Walle > Cc: Priyanka Jain > --- > arch/arm/cpu/armv7/ls102xa/fdt.c | 6 +++--- > board/gateworks/gw_ventana/common.c | 3 +-- > board/kontron/sl28/sl28.c| 2 +- > common/fdt_support.c | 20 +--- > drivers/pci/pcie_layerscape_fixup.c | 8 > drivers/pci/pcie_layerscape_gen4_fixup.c | 8 > include/fdt_support.h| 18 -- > 7 files changed, 26 insertions(+), 39 deletions(-) Reviewed-by: Simon Glass OpenBSD?
Re: [PATCH 4/4] rockchip: rk3399: Add support for chromebook_kevin
Hi Alper, On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak wrote: > > From: "Marty E. Plummer" > > Add support for Kevin, an RK3399-based convertible chromebook that is > very similar to Bob. This patch is mostly based on existing support for > Bob, with only minor changes for Kevin-specific things. > > Unlike other Gru boards, coreboot sets Kevin's center logic to 925 mV, > so adjust it here in the dts as well. The rk3399-gru-kevin devicetree > has an unknown event code reference which has to be defined, set it > to the Linux counterpart. The new defconfig is copied from Bob with the > diffconfig: > > DEFAULT_DEVICE_TREE "rk3399-gru-bob" -> "rk3399-gru-kevin" > DEFAULT_FDT_FILE "rockchip/rk3399-gru-bob.dtb" -> > "rockchip/rk3399-gru-kevin.dtb" > VIDEO_ROCKCHIP_MAX_XRES 1280 -> 2400 > VIDEO_ROCKCHIP_MAX_YRES 800 -> 1600 > +TARGET_CHROMEBOOK_KEVIN y > > With this Kevin can boot from SPI flash to a usable U-Boot prompt on the > display with the keyboard working, but cannot boot into Linux for > unknown reasons. > > eMMC starts in a working state but fails to re-init, microSD card works > but at a lower-than-expected speed, USB works but causes a hang on > de-init. There are known workarounds to solve eMMC and USB issues. > > Cc: Marty E. Plummer > Cc: Simon Glass > [Alper: commit message, resync config with Bob, update MAINTAINERS, > add to Rockchip doc, add Kconfig help message, set regulator] > Co-developed-by: Alper Nebi Yasak > Signed-off-by: Alper Nebi Yasak > --- > Marty had signed-off an earlier version of this [1], but not the updated > version I continued on top of [2]. So I'm not sure if I can add his > sign-off to this as is, and I hope he can reply to this with a sign-off. > > [1] https://patchwork.ozlabs.org/patch/1053386/ > [2] https://patchwork.ozlabs.org/comment/2488899/ > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ > arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ > arch/arm/mach-rockchip/rk3399/rk3399.c| 4 +- > arch/arm/mach-rockchip/spl.c | 3 +- > board/google/gru/Kconfig | 16 +++ > board/google/gru/MAINTAINERS | 8 ++ > board/google/gru/gru.c| 2 +- > configs/chromebook_kevin_defconfig| 116 ++ > doc/board/rockchip/rockchip.rst | 1 + > include/dt-bindings/input/linux-event-codes.h | 3 +- > 11 files changed, 171 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi > create mode 100644 configs/chromebook_kevin_defconfig This needs a rebase on next, just for a change in rk3399.c but I suppose it could be done when applying. Regards, Simon
Re: [PATCH u-boot-marvell RESEND 03/11] fdt_support: Remove fdt_alloc_phandle() in favor of fdt_generate_phandle()
On Fri, 26 Nov 2021 at 06:57, Marek Behún wrote:
>
> From: Marek Behún
>
> Commit f0921f5098d ("fdt: Sync up to the latest libfdt") introduced
> fdt_generate_phandle() in libfdt, making fdt_alloc_phandle() obsolete in
> fdt_support.
>
> Signed-off-by: Marek Behún
> Reviewed-by: Stefan Roese
> Cc: Simon Glass
> Cc: "hui.song"
> Cc: Meenakshi Aggarwal
> Cc: Priyanka Jain
> Cc: Ioana Ciornei
> ---
> board/freescale/lx2160a/eth_lx2160aqds.c | 8 +--
> board/freescale/lx2160a/eth_lx2162aqds.c | 8 +--
> common/fdt_support.c | 28 +++-
> include/fdt_support.h| 1 -
> 4 files changed, 20 insertions(+), 25 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH 1/4] rockchip: gru: Set up SoC IO domain registers
Hi Alper,
On Thu, 25 Nov 2021 at 10:40, Alper Nebi Yasak wrote:
>
> The RK3399 SoC needs to know the voltage value provided by some
> regulators, which is done by setting relevant register bits. Configure
> these the way other RK3399 boards do, but with values set in coreboot.
What do you mean by values set in coreboot? We don't need that to run
here, do we?
>
> Signed-off-by: Alper Nebi Yasak
> ---
> There is a driver for this on Rockchip's repo, I managed to forward-port
> it and get it working. If that's more desirable than doing it per-board
> like this I can send that upstream (but I'd prefer to do it after this).
>
> board/google/gru/gru.c | 54 ++
> 1 file changed, 54 insertions(+)
>
> diff --git a/board/google/gru/gru.c b/board/google/gru/gru.c
> index 23080c1798b7..cddcb286a380 100644
> --- a/board/google/gru/gru.c
> +++ b/board/google/gru/gru.c
> @@ -6,6 +6,17 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_IO_VSEL_BT656_SHIFT 0
> +#define GRF_IO_VSEL_AUDIO_SHIFT 1
> +#define PMUGRF_CON0_VSEL_SHIFT 8
> +#define PMUGRF_CON0_VOL_SHIFT 9
>
> #ifdef CONFIG_SPL_BUILD
> /* provided to defeat compiler optimisation in board_init_f() */
> @@ -54,3 +65,46 @@ int board_early_init_r(void)
> return 0;
> }
> #endif
> +
> +#ifdef CONFIG_MISC_INIT_R
Can you just drop this #ifdef? It doesn't seem necessasry.
> +static void setup_iodomain(void)
> +{
> + struct rk3399_grf_regs *grf =
> + syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> + struct rk3399_pmugrf_regs *pmugrf =
> + syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
> +
> + /* BT656 and audio is in 1.8v domain */
> + rk_setreg(&grf->io_vsel, (1 << GRF_IO_VSEL_BT656_SHIFT |
> + 1 << GRF_IO_VSEL_AUDIO_SHIFT));
> +
> + /*
> +* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL
> +* and explicitly configure that PMU1830_VOL to be 1.8V
> +*/
> + rk_setreg(&pmugrf->soc_con0, (1 << PMUGRF_CON0_VSEL_SHIFT |
> + 1 << PMUGRF_CON0_VOL_SHIFT));
> +}
> +
> +int misc_init_r(void)
> +{
> + const u32 cpuid_offset = 0x7;
> + const u32 cpuid_length = 0x10;
> + u8 cpuid[cpuid_length];
> + int ret;
> +
> + setup_iodomain();
> +
> + ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> + if (ret)
> + return ret;
> +
> + ret = rockchip_cpuid_set(cpuid, cpuid_length);
> + if (ret)
> + return ret;
> +
> + ret = rockchip_setup_macaddr();
> +
> + return ret;
> +}
> +#endif
> --
> 2.34.0
>
Regards,
Simon
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
Hi Andy, On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko wrote: > > Importing libraries in Python caches the bytecode by default. > Since we run scripts in source tree it ignores the current directory > settings, which is $(srctree), and creates cache just in the middle > of the source tree. Move cache to the current directory. > > Signed-off-by: Andy Shevchenko > --- > v2: reused our_path > tools/binman/main.py | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) This look useful, but we cannot rely on 'srcdir' being in the environment. For example, most binman development is done just by running 'binman test' in the source tre. So perhaps default to the current directory is 'srcdir' is not set? Regards, Simon > > diff --git a/tools/binman/main.py b/tools/binman/main.py > index 8c1e478d54ce..4d8b124c7468 100755 > --- a/tools/binman/main.py > +++ b/tools/binman/main.py > @@ -16,9 +16,18 @@ import sys > import traceback > import unittest > > +# Get the absolute path to this file at run-time > +our_path = os.path.dirname(sys.argv[0]) > + > +# > +# Do not pollute source tree with cache files: > +# https://stackoverflow.com/a/60024195/2511795 > +# https://bugs.python.org/issue33499 > +# > +sys.pycache_prefix = os.path.relpath(our_path, os.environ['srctree']) > + > # Bring in the patman and dtoc libraries (but don't override the first path > # in PYTHONPATH) > -our_path = os.path.dirname(os.path.realpath(__file__)) > sys.path.insert(2, os.path.join(our_path, '..')) > > from patman import test_util > -- > 2.33.0 >
Re: [PATCH v2 2/2] binman: Use less hard coded magic when inserting new PATH
Hi Andy, On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko wrote: > > Instead of joining hard coded '..' to the run-time path of the executable, > take just a dirname out of it. Besides that, use $(srctree) where it makes > sense. > > Signed-off-by: Andy Shevchenko > --- > v2: new patch > tools/binman/main.py | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) Looks good, apart from my comment on the previous patch, which applies here too. Regards, Simon
Re: [RFC Patch v2] binman: add support for creating dummy files for external blobs
Hi Heiko, On Mon, 29 Nov 2021 at 02:48, Heiko Thiery wrote: > > While converting to binman for an imx8mq board, it has been found that > building in the u-boot CI fails. This is because an imx8mq requires an > external binary (signed_hdmi_imx8m.bin). If this file cannot be found > mkimage fails. > To be able to build this board in the u-boot CI a binman option > (--fake-ext-blobs) is introduced that can be switched on via the u-boot > makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are > created. > > Signed-off-by: Heiko Thiery > --- > v2: > - pass allow_fake_blobs to ProcessImage() > - set AllowAllowFakeBlob() to images/entries > - create fake blob in Entry_blot.ObtainContents() when file is missing and >creation is allowed > > still missing: > - unittest > - option to set BINMAN_FAKE_EXT_BLOBS in Makefile via environment > variable. With that we could simply set this env variable in the CI > (gitlab-ci.yml) with adding support to buildman. > > Makefile | 1 + > tools/binman/cmdline.py| 2 ++ > tools/binman/control.py| 9 +++-- > tools/binman/entry.py | 11 +++ > tools/binman/etype/blob.py | 7 +++ > tools/binman/etype/blob_ext.py | 8 > tools/binman/etype/mkimage.py | 9 + > tools/binman/etype/section.py | 9 + > 8 files changed, 54 insertions(+), 2 deletions(-) This looks good to me! The only thing is that instead of the warning you should just print a single line at the end saying which blobs were faked. See missing_list in ProcessImage() for how that could work. You can set self.fake_blob in your blob.ObtainContents() and then have a similar thing to CheckMissing() to actually collect the list of entries which were faked. Also, for the real version can you please add a test (so 'binman test -T' stays at 100% test coverage) and some docs in binman.rst ? You can use testMissingBlob() as a template. Regards, Simon
[PATCH v2] RFC: gitlab: x86: Add a coreboot test
Coreboot supports U-Boot as a payload and this recently got a bit of a
facelist. Add a test for this.
For now this uses a binary build of coreboot (v4.15). Future work could
potentially build it from source, but we need to figure out the
toolchain problems first, since coreboot uses its own toolchain.
This needs some changes to the hooks scripts as well. An example build
is at https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/359687
Signed-off-by: Simon Glass
---
Changes in v2:
- Drop the local CI changes; we need the real ones applied first anyway
.gitlab-ci.yml | 26 ++
1 file changed, 26 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 4c89daeadcf..065d8d6158e 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -52,6 +52,16 @@ stages:
genimage --inputpath . --config
board/sifive/unleashed/genimage_spi-nor.cfg;
cp images/spi-nor.img ${UBOOT_TRAVIS_BUILD_DIR}/;
fi
+- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
+wget -O -
+
"https://drive.google.com/uc?id=1x6nrtWIyIRPLS2cQBwYTnT2TbOI8UjmM&export=download";
|
+ xz -dc >${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
+wget -O -
+
"https://drive.google.com/uc?id=149Cz-5SZXHNKpi9xg6R_5XITWohu348y&export=download";
>
+ cbfstool;
+chmod a+x cbfstool;
+./cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom add-flat-binary -f
${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c LZMA -l 0x111
-e 0x111;
+ fi
- virtualenv -p /usr/bin/python3 /tmp/venv
- . /tmp/venv/bin/activate
- pip install -r test/py/requirements.txt
@@ -61,6 +71,10 @@ stages:
./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
--build-dir "$UBOOT_TRAVIS_BUILD_DIR"
+# It seems that the files in /tmp go away, so copy out what we need
+- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
+cp -v /tmp/coreboot/*.{html,css} .;
+ fi
build all 32bit ARM platforms:
stage: world build
@@ -366,3 +380,15 @@ xtfpga test.py:
TEST_PY_TEST_SPEC: "not sleep"
TEST_PY_ID: "--id qemu"
<<: *buildman_and_testpy_dfn
+
+coreboot test.py:
+ variables:
+TEST_PY_BD: "coreboot"
+TEST_PY_TEST_SPEC: "not sleep"
+TEST_PY_ID: "--id qemu"
+ artifacts:
+paths:
+ - "*.html"
+ - "*.css"
+expire_in: 1 week
+ <<: *buildman_and_testpy_dfn
--
2.34.0.384.gca35af8252-goog
[PATCH] RFC: gitlab: x86: Add a coreboot test
Coreboot supports U-Boot as a payload and this recently got a bit of a
facelist. Add a test for this.
For now this uses a binary build of coreboot (v4.15). Future work could
potentially build it from source, but we need to figure out the
toolchain problems first, since coreboot uses its own toolchain.
This needs some changes to the hooks scripts as well. An example build
is at https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/359687
Signed-off-by: Simon Glass
---
.gitlab-ci.yml | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 4c89daeadcf..f5d7e0f77e2 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -14,7 +14,7 @@ stages:
stage: test.py
before_script:
# Clone uboot-test-hooks
-- git clone --depth=1 https://source.denx.de/u-boot/u-boot-test-hooks
/tmp/uboot-test-hooks
+- git clone -b try --depth=1 https://github.com/sjg20/uboot-test-hooks.git
/tmp/uboot-test-hooks
- ln -s travis-ci /tmp/uboot-test-hooks/bin/`hostname`
- ln -s travis-ci /tmp/uboot-test-hooks/py/`hostname`
- grub-mkimage --prefix="" -o ~/grub_x86.efi -O i386-efi normal echo
lsefimmap lsefi lsefisystab efinet tftp minicmd
@@ -52,6 +52,16 @@ stages:
genimage --inputpath . --config
board/sifive/unleashed/genimage_spi-nor.cfg;
cp images/spi-nor.img ${UBOOT_TRAVIS_BUILD_DIR}/;
fi
+- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
+wget -O -
+
"https://drive.google.com/uc?id=1x6nrtWIyIRPLS2cQBwYTnT2TbOI8UjmM&export=download";
|
+ xz -dc >${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
+wget -O -
+
"https://drive.google.com/uc?id=149Cz-5SZXHNKpi9xg6R_5XITWohu348y&export=download";
>
+ cbfstool;
+chmod a+x cbfstool;
+./cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom add-flat-binary -f
${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c LZMA -l 0x111
-e 0x111;
+ fi
- virtualenv -p /usr/bin/python3 /tmp/venv
- . /tmp/venv/bin/activate
- pip install -r test/py/requirements.txt
@@ -61,6 +71,10 @@ stages:
./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
--build-dir "$UBOOT_TRAVIS_BUILD_DIR"
+# It seems that the files in /tmp go away, so copy out what we need
+- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
+cp -v /tmp/coreboot/*.{html,css} .;
+ fi
build all 32bit ARM platforms:
stage: world build
@@ -366,3 +380,15 @@ xtfpga test.py:
TEST_PY_TEST_SPEC: "not sleep"
TEST_PY_ID: "--id qemu"
<<: *buildman_and_testpy_dfn
+
+coreboot test.py:
+ variables:
+TEST_PY_BD: "coreboot"
+TEST_PY_TEST_SPEC: "not sleep"
+TEST_PY_ID: "--id qemu"
+ artifacts:
+paths:
+ - "*.html"
+ - "*.css"
+expire_in: 1 week
+ <<: *buildman_and_testpy_dfn
--
2.34.0.384.gca35af8252-goog
[u-boot-test-hooks PATCH] travis-ci: Add tests for booting from coreboot
Add a means of testing a coreboot + U-Boot build using qemu.
Signed-off-by: Simon Glass
---
bin/ellesmere/conf.coreboot_qemu | 1 +
bin/travis-ci/conf.coreboot_qemu | 28
2 files changed, 29 insertions(+)
create mode 12 bin/ellesmere/conf.coreboot_qemu
create mode 100644 bin/travis-ci/conf.coreboot_qemu
diff --git a/bin/ellesmere/conf.coreboot_qemu b/bin/ellesmere/conf.coreboot_qemu
new file mode 12
index 000..c81eb3f
--- /dev/null
+++ b/bin/ellesmere/conf.coreboot_qemu
@@ -0,0 +1 @@
+../travis-ci/conf.coreboot_qemu
\ No newline at end of file
diff --git a/bin/travis-ci/conf.coreboot_qemu b/bin/travis-ci/conf.coreboot_qemu
new file mode 100644
index 000..76d6927
--- /dev/null
+++ b/bin/travis-ci/conf.coreboot_qemu
@@ -0,0 +1,28 @@
+# Copyright (c) 2016 Konsulko Group. All rights reserved.
+# Copyright 2021 Google LLC
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+console_impl=qemu
+qemu_machine="pc"
+qemu_binary="qemu-system-i386"
+qemu_extra_args="-nographic -cpu qemu32 -netdev
user,id=net0,tftp=${UBOOT_TRAVIS_BUILD_DIR} -device e1000,netdev=net0"
+qemu_kernel_args="-bios ${U_BOOT_BUILD_DIR}/coreboot.rom"
+reset_impl=none
+flash_impl=none
--
2.34.0.384.gca35af8252-goog
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Andre, On Thu, 2 Dec 2021 at 18:59, Andre Przywara wrote: > > On Thu, 2 Dec 2021 13:34:07 -0500 > Tom Rini wrote: > > Hi, > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > > OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > > built and > > > > > > > > > > appended to U-Boot > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > > embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > > needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > > don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > > devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > > bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available > > > > > > > > > > in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > > should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > > devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 13:34:07 -0500 Tom Rini wrote: Hi, > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > > the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Andre, On Thu, 2 Dec 2021 at 18:31, Andre Przywara wrote: > > On Thu, 2 Dec 2021 11:17:38 -0700 > Simon Glass wrote: > > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > > the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > > > > > I underst
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 11:17:38 -0700 Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > built and > > > > > > > > appended to U-Boot > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > > > > > > Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > > > > > Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > bootloader and its > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > > > > > > > > be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance this
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 19:03:46 +0200 Ilias Apalodimas wrote: Hi, > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > > > > its > > > > caller may have a better idea about the hardware available in the > > > > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I agree on that, I always felt like U-Boot is abusing the DT here for its own purposes. If it needs to convey some configuration information, it should do it separately. It can use the DTB *format* (hierarchically organised key/value pairs), but this should not really be mingled with the hardware information. Trusted-Firmware is using this idea: they use the already included libfdt for parsing, but load the various config "DTB"s separately. The "hw_config" DTB (as they call the actual DTB) is treated separately. Cheers, Andre
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 09:39:52 -0700 Simon Glass wrote: Hi, wow, this thread quickly exploded, jumping in here randomly to add my thoughts: > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >>- OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >>- OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >>- OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its > >> caller may have a better idea about the hardware available in the machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > >> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! But why? Actually it's the exact opposite, Highbank is somewhat of a (sadly abandoned) poster book child of DT usage: Before the Cortex-A cores boot, the DTB gets loaded by the management processor (ECME) from NOR flash into DRAM. There the memory node gets populated, based on what the ECME detected (it has a DIMM slot!). Then this DTB gets used by U-Boot, which adds the command line and initrd information, based on user choices. And this is eventually consumed by a kernel. So the base DTB here is provided by the system, and software just reacts to it - how it should be. The (arm64) Linux kernel works on this idea: exactly *one* binary image, and the drivers that are needed by the hardware get loaded based on DT information. The fact the .dts files live in the kernel tree is more for practical reasons, because it started there, we enhance DTs and should have a repo holding them, plus all the review knowledge is in the kernel community. Cheers, Andre P.S. I started writing some documentation for Highbank, to be posted soonish. > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >
[PATCH 1/2] board/sunxi/dram_sun4i_auto: use DRAM_MEMORY_TYPE_DDR3 instead of magic number 3
Since DRAM_MEMORY_TYPE_DDR3 is defined let's use it instead of magic
number 3.
Signed-off-by: Giulio Benetti
---
board/sunxi/dram_sun4i_auto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/dram_sun4i_auto.c b/board/sunxi/dram_sun4i_auto.c
index e8bbee4ee5..547d1c0cb4 100644
--- a/board/sunxi/dram_sun4i_auto.c
+++ b/board/sunxi/dram_sun4i_auto.c
@@ -4,7 +4,7 @@
static struct dram_para dram_para = {
.clock = CONFIG_DRAM_CLK,
- .type = 3,
+ .type = DRAM_MEMORY_TYPE_DDR3,
.rank_num = 1,
.density = 0,
.io_width = 0,
--
2.25.1
[PATCH 2/2] board/sunxi/dram_sun5i_auto: use DRAM_MEMORY_TYPE_DDR3 instead of magic number 3
Since DRAM_MEMORY_TYPE_DDR3 is defined let's use it instead of magic
number 3.
Signed-off-by: Giulio Benetti
---
board/sunxi/dram_sun5i_auto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/dram_sun5i_auto.c b/board/sunxi/dram_sun5i_auto.c
index a5f4f8b743..517506ccc4 100644
--- a/board/sunxi/dram_sun5i_auto.c
+++ b/board/sunxi/dram_sun5i_auto.c
@@ -7,7 +7,7 @@
static struct dram_para dram_para = {
.clock = CONFIG_DRAM_CLK,
.mbus_clock = CONFIG_DRAM_MBUS_CLK,
- .type = 3,
+ .type = DRAM_MEMORY_TYPE_DDR3,
.rank_num = 1,
.density = 0,
.io_width = 0,
--
2.25.1
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 15:47, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > > > OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree > > > > > > > > > > > is built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > > > > > > > > > > > is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > > > needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > > > don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the > > > > > > > > > > > board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > > > devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > > > bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware > > > > > > > > > > > available in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > > > should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > > > devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > > > possible outcomes of > > > > > > > > > > not using the one provided
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 15:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > > Hi Simon,Tom > > > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > > > is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the > > > board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware available > > > in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible > > > outcomes of > > > > > > > > > > not using the one provided by the platform and the right way > > > of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > want > > > > > > > > > reference or fake or whatever device trees in the U-Boot > > > source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not > > > req
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > Hi Simon,Tom > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > built and > > > > > > > > > > appended to U-Boot > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > > is embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the > > board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available > > in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > want > > > > > > > > reference or fake or whatever device trees in the U-Boot > > source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not > > required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > > wish > > > > > > > it had not come to this. > > > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > > OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > > built and > > > > > > > > > > appended to U-Boot > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > > embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > > needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > > don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > > devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > > bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available > > > > > > > > > > in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > > should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > > devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the U-Bo
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 14:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > > wrote: > > > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > > > OF_HOSTFILE so > > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree > > > > > > > > > > > is built and > > > > > > > > > > > appended to U-Boot > > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > > > > > > > > > > > is embedded in > > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > > > needed at all > > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > > > don't. Some > > > > > > > > > > > don't even provide instructions on how to boot on the > > > > > > > > > > > board. > > > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > > > patch in this > > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > > > devicetree built > > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > > > bootloader and its > > > > > > > > > > > caller may have a better idea about the hardware > > > > > > > > > > > available in the machine. > > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > > > should be an > > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > > > devicetree files > > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own > > > > > > > > > > > patch to add the > > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along > > > > > > > > > > > the way. The > > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > > current state > > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > > *control* devicetrees > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon,Tom Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the > board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available > in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two > *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > there are good > > > > > > > > advances in the documentation and other areas that would be > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > > > > > would love there is a warning in capital letters at the top > of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > > > > > not using the one provided by the platform and the right way > of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > want > > > > > > > reference or fake or whatever device trees in the U-Boot > source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which > don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > add > > > > > > whatever caveats and documentation people want to clarify what is
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > Hi Mark, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > > OF_HOSTFILE so > > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > > built and > > > > > > > > > > appended to U-Boot > > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > > embedded in > > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > > needed at all > > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > > don't. Some > > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > > patch in this > > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > > devicetree built > > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > > bootloader and its > > > > > > > > > > caller may have a better idea about the hardware available > > > > > > > > > > in the machine. > > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > > should be an > > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > > devicetree files > > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > > > > > > > > > > to add the > > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > > way. The > > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > > current state > > > > > > > > > > - Explain that the 'two devicetrees' refers to two > > > > > > > > > > *control* devicetrees > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > >
Re: [PATCH 04/17] binman: Tidy up style in cmdline
Update this file to improve the pylint score a little. The remaining item is: Function name "ParseArgs" doesn't conform to snake_case naming style which needs some binman-wide renaming. Signed-off-by: Simon Glass --- scripts/pylint.base | 2 +- tools/binman/cmdline.py | 45 - 2 files changed, 28 insertions(+), 19 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH] drivers: core: lists: fix for loop index type
On Sat, 6 Nov 2021 at 09:11, wrote: > > From: Alexander Preißner > > * fixes the bug in function bind_drivers_pass that for > CONFIG_CC_OPTIMIZE_FOR_SIZE=n and no entries in the driver_info list, > i.e. n_ents == 0, the processor steps into the first loop iteration > despite the loop condition being false. > * the Xilinx Zynq-7000 device would eventually hang due to an attempted > access to an invalid memory address > * the bug is fixed by changing the type of idx from uint to int > > Board: zynq-zybo > Target: ARM > Compiler: arm-none-eabi-gcc 9.2.1 > > Signed-off-by: Alexander Preissner > --- > drivers/core/lists.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: replace putchar(ch) by fputc(ch, stdout)
On Sat, 20 Nov 2021 at 05:28, Heinrich Schuchardt wrote: > > When compiled with -Og for better debugability u-boot ends up in a stack > overflow using > > gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 > GNU Binutils for Ubuntu 2.37 > > putchar(ch) is defined as a macro which ends up calling U-Boot's putc() > implementation instead of the glibc one, which calls os_putc() ... > > Let's use fputc(ch, stdout) instead as fputc() does not exist in U-Boot. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/os.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 01/17] dtoc: Bring in the libfdt module automatically
Use the same technique as with binman to load this module from the U-Boot tree if available. This allows running tests without having to specify the PYTHONPATH variable. Signed-off-by: Simon Glass --- tools/dtoc/test_fdt.py | 6 ++ 1 file changed, 6 insertions(+) Applied to u-boot-dm/next, thanks!
Re: [PATCH 02/17] dtoc: Add support for reading 64-bit ints
Add functions to read a 64-bit integer property from the devicetree. Signed-off-by: Simon Glass --- tools/dtoc/fdt_util.py | 35 tools/dtoc/test/dtoc_test_simple.dts | 1 + tools/dtoc/test_dtoc.py | 2 ++ tools/dtoc/test_fdt.py | 21 ++--- 4 files changed, 56 insertions(+), 3 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 05/17] binman: Add a way to obtain the version
Add a -V option which shows the version number of binman. For now this just uses a local 'version' file. Once the tool is packaged in some way we can figure out an approach that suits. Signed-off-by: Simon Glass --- tools/binman/cmdline.py | 29 + tools/binman/ftest.py | 20 tools/binman/state.py | 18 ++ 3 files changed, 67 insertions(+) Applied to u-boot-dm/next, thanks!
Re: [PATCH 03/17] dtoc: Add support for reading fixed-length bytes properties
Add functions to read a sequence of bytes from the devicetree. Signed-off-by: Simon Glass --- scripts/pylint.base| 4 ++-- tools/dtoc/fdt_util.py | 20 tools/dtoc/test_fdt.py | 17 + 3 files changed, 39 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 06/17] binman: Correct init of entry in Entry class
This should not have an underscore. Drop it so that derived classes can rely on it being set correctly. Signed-off-by: Simon Glass --- tools/binman/entry.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 08/17] binman: Drop the underscore in _ReadEntries()
This function can be overridden so should not have an underscore. Drop it. Signed-off-by: Simon Glass --- tools/binman/etype/blob_phase.py | 2 +- tools/binman/etype/cbfs.py | 4 ++-- tools/binman/etype/files.py | 2 +- tools/binman/etype/section.py| 8 4 files changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 07/17] binman: Correct comments for ReadChildData()
The comment here is incomplete. Fix it. Signed-off-by: Simon Glass --- tools/binman/entry.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 10/17] binman: Allow overriding BuildSectionData()
This method is currently marked private. However it is useful to be able to subclass it, since much of the entry_Section code can be reused. Rename it. Also document one confusing part of this code, so people can understand how to add a test for this case. Fix up a few pylint warnings to avoid regressing the score. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 16 tools/binman/ftest.py | 2 +- 2 files changed, 13 insertions(+), 5 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 11/17] binman: Allow control of which entries to read
The ObtainContents() and GetEntryContents() methods in this file read every single entry in the section. This is the common case. However when one of the entries has had its data updated (e.g. with 'binman replace') we don't want to read it again from the file. Allow the entry to be skipped, for this purpose. This is currently done in the CBFS implementation, so adding it here will allow that to use more of the entry_Section code. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 09/17] binman: Drop the filename property in entry_Section
This is not used and does nothing. Drop it. Add a tweak to avoid reducing the pylint score. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 12/17] binman: Update the section documentation
Expand this to explain subclassing better and also to tidy up formatting for rST. Fix a few pylint warnings to avoid dropping the score. Signed-off-by: Simon Glass --- tools/binman/entries.rst | 149 +++--- tools/binman/etype/section.py | 148 +++-- 2 files changed, 242 insertions(+), 55 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 13/17] binman: Move cbfs.ObtainContents() down a bit
It is easier to understand this file if reading the entries comes before obtaining the contents, since that is the order in which Binman proceeds. Move the function down a bit. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 14/17] binman: Use normal entries in cbfs
This currently uses _cbfs_entries[] to store entries. Since the entries are in fact valid etypes, we may as well use the same name as entry_Section uses, which is _entries. This allows reusing more of the code there (in a future patch). Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 16 1 file changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 16/17] binman: cfbs: Refactor ObtainContents() for consistency
Update this to use the same arguments as entry_Section uses. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 40 ++ 1 file changed, 23 insertions(+), 17 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 15/17] binman: cbfs: Refactor the init process
Update the constructor to work in the recommended way, where the node properties are read in a separate function. This makes it more similar to entry_Section. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 17/17] binman: Rename testCbfsNoCOntents()
Use a lower-case O as was intended. Signed-off-by: Simon Glass --- tools/binman/ftest.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm/next, thanks!
Re: Question/issues about i.MX6 DDR configuration
Hi Michael, On Thu, Dec 2, 2021 at 5:36 PM Michael Nazzareno Trimarchi wrote: > The bootrom loads the dcd using some logic and you write the register > in sequence. > You don't respect the ddr initialization or this delay on MMDC > according to 44.4.2. > Is that not necessary? I don't see in 44.4.2 where it mentions the requirement of delay between register writes. The part that Francesco quoted: "A Precharge All command must be issued prior to the MRW command to ensure robust DDR initialization. This command is required to be issued to both chip selects if two chip selects are utilized in the system." Does not apply to mx6sabresd as it only has one chip select. Regards, Fabio Estevam
Re: Question/issues about i.MX6 DDR configuration
Hi Fabio On Thu, Dec 2, 2021 at 9:14 PM Fabio Estevam wrote: > > Hi Francesco, > > On Thu, Dec 2, 2021 at 1:14 PM Francesco Dolcini > wrote: > > > > Hello Fabio, Tim and all, > > in the last few weeks I have been debugging some sporadic i.MX6 board > > boot failures (2020.07 U-Boot, if that matters) and we have some loose > > indication that they could be RAM related. The effect is that SPL is not > > able to load U-Boot from the eMMC to DDR and dqs|write_level calibration > > is failing. > > > > We do write the memory configuration in a pretty simple way, SPL is just > > iterating thought a list of register address/value, in a very similar > > way to what was done using the DCD table. Today most of the boards > > however use a more programmatic approach as introduced by Tim in 2014 [1]. > > > > Contrary to that, however, Fabio moved away from this new approach to > > just raw registers writing for the sabre board [2][3]. > > > > I'm a little bit puzzled at the moment, according to the iMX6 reference > > manual[4], 44.4.2 MMDC initialization, a specific sequence is required > > to be followed and this is implemented by the `mx6_dram_cfg()`[5] > > function, but according to what Fabio wrote the raw initialization of > > registers was just more reliable for mx6sabresd. Fabio, what was the > > reason? > > The reason is that I wanted to keep the DDR initialization 100% the > same in U-Boot > mainline versus NXP U-Boot for mx6sabresd board. > > The mx6_ddr_sysinfo approach is more elegant, for sure. > The bootrom loads the dcd using some logic and you write the register in sequence. You don't respect the ddr initialization or this delay on MMDC according to 44.4.2. Is that not necessary? Michael > It is just that I wanted to keep 100% in sync with the initialization > done by the NXP hardware team. > > Regards, > > Fabio Estevam
Re: Question/issues about i.MX6 DDR configuration
Hi Francesco, On Thu, Dec 2, 2021 at 1:14 PM Francesco Dolcini wrote: > > Hello Fabio, Tim and all, > in the last few weeks I have been debugging some sporadic i.MX6 board > boot failures (2020.07 U-Boot, if that matters) and we have some loose > indication that they could be RAM related. The effect is that SPL is not > able to load U-Boot from the eMMC to DDR and dqs|write_level calibration > is failing. > > We do write the memory configuration in a pretty simple way, SPL is just > iterating thought a list of register address/value, in a very similar > way to what was done using the DCD table. Today most of the boards > however use a more programmatic approach as introduced by Tim in 2014 [1]. > > Contrary to that, however, Fabio moved away from this new approach to > just raw registers writing for the sabre board [2][3]. > > I'm a little bit puzzled at the moment, according to the iMX6 reference > manual[4], 44.4.2 MMDC initialization, a specific sequence is required > to be followed and this is implemented by the `mx6_dram_cfg()`[5] > function, but according to what Fabio wrote the raw initialization of > registers was just more reliable for mx6sabresd. Fabio, what was the > reason? The reason is that I wanted to keep the DDR initialization 100% the same in U-Boot mainline versus NXP U-Boot for mx6sabresd board. The mx6_ddr_sysinfo approach is more elegant, for sure. It is just that I wanted to keep 100% in sync with the initialization done by the NXP hardware team. Regards, Fabio Estevam
Re: Please pull u-boot-net/master
On Thu, Dec 02, 2021 at 10:22:52AM +0200, Ramon Fried wrote: > Hi Tom, > The below contains two fixes from Marek for designware and mdio. > > The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95: > > Merge https://source.denx.de/u-boot/custodians/u-boot-marvell > (2021-11-30 08:59:22 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-net.git/ > > for you to fetch changes up to 3fbd17aadf792735846a5f2052b3f68f7075201f: > > net: dwc_eth_qos: Enable clock in probe (2021-12-02 08:35:44 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v3] xilinx: Kconfig: add XILINX_OF_BOARD_DTB_ADDR default value for microblaze
The xilinx board_fdt_blob_setup() implementation makes use of XILINX_OF_BOARD_DTB_ADDR, but no default value is currently defined for microblaze. Add one so that microblaze could also work with CONFIG_OF_SEPARATE. Signed-off-by: Ovidiu Panait --- board/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index 64507b5d84..1788066173 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -43,6 +43,7 @@ endif config XILINX_OF_BOARD_DTB_ADDR hex "Default DTB pickup address" default 0x1000 if ARCH_VERSAL + default 0x8000 if MICROBLAZE default 0x10 if ARCH_ZYNQ || ARCH_ZYNQMP depends on OF_BOARD || OF_SEPARATE help -- 2.25.1
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Ilias Apalodimas > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > > the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more.
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:44, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: >> >> Hi François, >> >> On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: >> > >> > Hi Simon >> > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> >> >> Hi Tom, >> >> >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> >> > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> >> > > Hi, Simon! >> >> > > >> >> > > Sorry for being late to the party >> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: >> >> > > > Add an empty file to prevent build errors when building with >> >> > > > CONFIG_OF_SEPARATE enabled. >> >> > > > >> >> > > > The build instructions in U-Boot do not provide enough detail to >> >> > > > build a >> >> > > > useful devicetree, unfortunately. >> >> > > Xen guest doesn't use any built-in device trees as the guest's device >> >> > > tree is provided >> >> > > by the Xen hypervisor itself and is generated at the virtual machine >> >> > > creation time: it is >> >> > > populated with memory size, number of CPUs etc. based on [1]. >> >> > > So, even if we provide some device tree here it must not be used by >> >> > > U-boot at >> >> > > the end of the day. Thus, it might be a reasonable solution to >> >> > > provide an empty device >> >> > > tree as you do, but put a comment that it is not used. >> >> > >> >> > So another example of why this series is taking things in the wrong >> >> > direction. >> >> >> >> Why? >> > >> > I only had that comment in mind: "there is none so deaf as he who will not >> > hear." >> >> Hey, stop the pile-on. It's not useful. >> >> I've guided U-Boot's use of devicetree for 10 years successfully. The >> current state is a mess and I just to straighten it out. >> > I admire your talent and knowledge. > I know you are 99,99% of the time correct and spot on for your comments in > many meetings we were attending. > When you questioned a number of points I made, I first tried to understand > what I got wrong because you said it. > And you were right ;-) > For this topic, I made every effort to come to your position, but > definitively can't. Thank you. I think this will come together in a few years when devicetree is sorted out in U-Boot and Binman is more widely used. For this series, if and when it is applied, I predict: - it will not cause any confusion - it will aid development - it will help with discoverability, pressuring people to explain how to build for their systems - it will be a good basis for future work (we have a long list) - everyone will wonder what the fuss was about Here is the commit that introduced OF_PRIOR_STAGE. It attracted no such push-back. commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 Author: Thomas Fitzsimmons Date: Fri Jun 8 17:59:45 2018 -0400 board: arm: Add support for Broadcom BCM7445 Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas Fitzsimmons Cc: Stefan Roese Cc: Tom Rini Cc: Florian Fainelli Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > wrote: > > > > > > > > > From: Ilias Apalodimas > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > built and > > > > > > > > appended to U-Boot > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > > > > > > Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > > > > > Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > bootloader and its > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > > > > > > > > be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move ou
[PATCH] mkimage: fix segfault on MacOS arm64
mkimage segfaults due ASLR mechasim on MacOS arm64
It is required to use _dyld_get_image_vmaddr_slide()
to prevent segfault on MacOS arm64
This patch ased on the discussion
https://github.com/u-boot/u-boot/commit/3b142045e8a7f0ab17b6099e9226296af45967d0
Thanks to Ronny Kotzschmar and ptpt52 github user
Signed-off-by: Sergey V. Lobanov
---
tools/imagetool.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/imagetool.h b/tools/imagetool.h
index e229a34ffc..13775ff9b3 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -271,11 +271,16 @@ int rockchip_copy_image(int fd, struct image_tool_params
*mparams);
* b) we need a API call to get the respective section symbols */
#if defined(__MACH__)
#include
+#include
-#define INIT_SECTION(name) do { \
+#define INIT_SECTION(name) struct image_type_params\
+ **__cat(__start_, name), **__cat(__stop_, name);\
+ do {\
unsigned long name ## _len; \
char *__cat(pstart_, name) = getsectdata("__DATA", \
#name, &__cat(name, _len)); \
+ __cat(pstart_, name) += \
+ _dyld_get_image_vmaddr_slide(0);\
char *__cat(pstop_, name) = __cat(pstart_, name) + \
__cat(name, _len); \
__cat(__start_, name) = (void *)__cat(pstart_, name); \
@@ -283,7 +288,6 @@ int rockchip_copy_image(int fd, struct image_tool_params
*mparams);
} while (0)
#define SECTION(name) __attribute__((section("__DATA, " #name)))
-struct image_type_params **__start_image_type, **__stop_image_type;
#else
#define INIT_SECTION(name) /* no-op for ELF */
#define SECTION(name) __attribute__((section(#name)))
--
2.30.1 (Apple Git-130)
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > > embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > > > > > > > > > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > > > > > > > > > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > > > > > > > > > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > > the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > > > > > > > > > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > > add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > > > > > > > > > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > > > > > > > > > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > > devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > > more. > > > > > > > > > > > > I understand y
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: François Ozog > Date: Thu, 2 Dec 2021 19:32:17 +0100 > > On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch > in this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > caller may have a better idea about the hardware available in > the machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to > add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better > in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source > tree. > > > We should be able to _remove_ the ones we have, that are not > required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm addi
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > > > From: Ilias Apalodimas > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > OF_HOSTFILE so > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built > > > > > > > and > > > > > > > appended to U-Boot > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > embedded in > > > > > > > the ELF file (also used for EFI) > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed > > > > > > > at all > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > > > > > Some > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > The problems with this approach are documented in another patch > > > > > > > in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > > > > Any board > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > > > built > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > bootloader and its > > > > > > > caller may have a better idea about the hardware available in the > > > > > > > machine. > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > > > > > > > an > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree > > > > > > > files > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > > the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > with this approach. This proposal is working in the *exact* opposite > > > > direction and we'll never be able to get rid of device trees from > > > > U-Boot, even if at some point they move out of the kernel to a > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > Personally I'd be way happier if we could figure out were the specific > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > what we figure out we could, pick up the device tree from
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > > > > > > so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > embedded in > > > > > > the ELF file (also used for EFI) > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at > > > > > > all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > > > > > > board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > > built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > > > > > > and its > > > > > > caller may have a better idea about the hardware available in the > > > > > > machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree > > > > > > files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sens
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > Hi François, > > On Thu, 2 Dec 2021 at 11:17, François Ozog > wrote: > > > > Hi Simon > > > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko > wrote: > >> > > Hi, Simon! > >> > > > >> > > Sorry for being late to the party > >> > > > >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > > Add an empty file to prevent build errors when building with > >> > > > CONFIG_OF_SEPARATE enabled. > >> > > > > >> > > > The build instructions in U-Boot do not provide enough detail to > build a > >> > > > useful devicetree, unfortunately. > >> > > Xen guest doesn't use any built-in device trees as the guest's > device tree is provided > >> > > by the Xen hypervisor itself and is generated at the virtual > machine creation time: it is > >> > > populated with memory size, number of CPUs etc. based on [1]. > >> > > So, even if we provide some device tree here it must not be used by > U-boot at > >> > > the end of the day. Thus, it might be a reasonable solution to > provide an empty device > >> > > tree as you do, but put a comment that it is not used. > >> > > >> > So another example of why this series is taking things in the wrong > >> > direction. > >> > >> Why? > > > > I only had that comment in mind: "there is none so deaf as he who will > not hear." > > Hey, stop the pile-on. It's not useful. > > I've guided U-Boot's use of devicetree for 10 years successfully. The > current state is a mess and I just to straighten it out. > > I admire your talent and knowledge. I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending. When you questioned a number of points I made, I first tried to understand what I got wrong because you said it. And you were right ;-) For this topic, I made every effort to come to your position, but definitively can't. >> > >> At least we might figure out where to get the DT and how to run > >> Xen with U-Boot. I don't see any down-side to having a basic DT in the > >> tree along with instructions on how to run Xen. > > > > If an EMPTY device is what is required to pass current build > constraints, so be it, and let's correct that in a later patch. And EMPTY > is not basic. > > The problem here is a difference in philosophy around device tree. > > Indeed! > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:21:22AM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > > > > > > so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > embedded in > > > > > > the ELF file (also used for EFI) > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at > > > > > > all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > > > > > > board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > > built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > > > > > > and its > > > > > > caller may have a better idea about the hardware available in the > > > > > > machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree > > > > > > files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > > OF_HOSTFILE so > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > > > > > > > > built and > > > > > > > > appended to U-Boot > > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > > embedded in > > > > > > > > the ELF file (also used for EFI) > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > > > > > > > > needed at all > > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > > > > > > Some > > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > > > The problems with this approach are documented in another patch > > > > > > > > in this > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > > > > > Any board > > > > > > > > can obtain its devicetree at runtime, even it is has a > > > > > > > > devicetree built > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > > bootloader and its > > > > > > > > caller may have a better idea about the hardware available in > > > > > > > > the machine. > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should > > > > > > > > be an > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > This series makes this change, adding various missing > > > > > > > > devicetree files > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to > > > > > > > > add the > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > > The > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > [1] > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > > state > > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > > devicetrees > > > > > > > > - Expand the commit message based on comments > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > > it had not come to this. > > > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > > have a devicetree anywhere I can find. > > > > > > > > > > I think on balance this is a substa
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit > : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > > caller may have a better idea about the hardware available in the > machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes fo
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> Hi Tom, >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> > > Hi, Simon! >> > > >> > > Sorry for being late to the party >> > > >> > > On 02.12.21 17:59, Simon Glass wrote: >> > > > Add an empty file to prevent build errors when building with >> > > > CONFIG_OF_SEPARATE enabled. >> > > > >> > > > The build instructions in U-Boot do not provide enough detail to build >> > > > a >> > > > useful devicetree, unfortunately. >> > > Xen guest doesn't use any built-in device trees as the guest's device >> > > tree is provided >> > > by the Xen hypervisor itself and is generated at the virtual machine >> > > creation time: it is >> > > populated with memory size, number of CPUs etc. based on [1]. >> > > So, even if we provide some device tree here it must not be used by >> > > U-boot at >> > > the end of the day. Thus, it might be a reasonable solution to provide >> > > an empty device >> > > tree as you do, but put a comment that it is not used. >> > >> > So another example of why this series is taking things in the wrong >> > direction. >> >> Why? > > I only had that comment in mind: "there is none so deaf as he who will not > hear." Hey, stop the pile-on. It's not useful. I've guided U-Boot's use of devicetree for 10 years successfully. The current state is a mess and I just to straighten it out. >> >> At least we might figure out where to get the DT and how to run >> Xen with U-Boot. I don't see any down-side to having a basic DT in the >> tree along with instructions on how to run Xen. > > If an EMPTY device is what is required to pass current build constraints, so > be it, and let's correct that in a later patch. And EMPTY is not basic. The problem here is a difference in philosophy around device tree. Regards, Simon
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Hi Mark, On Thu, 2 Dec 2021 at 10:34, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 08:59:01 -0700 > > > > Add this file, obtained from the Raspbian boot disk, so there is a > > reference devicetree in the U-Boot tree. The same one is used for > > 32- and 64-bit variants. > > > > Note that U-Boot does not normally need this at runtime, since > > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a > > devicetree at runtime. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v1) > > > > arch/arm/dts/Makefile|3 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++ > > configs/rpi_4_32b_defconfig |1 + > > configs/rpi_4_defconfig |1 + > > configs/rpi_arm64_defconfig |1 + > > 5 files changed, 1963 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 2d92b2f940d..9cddab37207 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \ > > bcm2837-rpi-3-a-plus.dtb \ > > bcm2837-rpi-3-b.dtb \ > > bcm2837-rpi-3-b-plus.dtb \ > > - bcm2837-rpi-cm3-io3.dtb > > + bcm2837-rpi-cm3-io3.dtb \ > > + bcm2711-rpi-4-b.dtb > > > > dtb-$(CONFIG_ARCH_BCM63158) += \ > > bcm963158.dtb > > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts > > b/arch/arm/dts/bcm2711-rpi-4-b.dts > > new file mode 100644 > > index 000..425e9fb91c4 > > --- /dev/null > > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts > > @@ -0,0 +1,1958 @@ > > +// SPDX-License-Identifier: GPL-2.0+ OR MIT > > +/* > > + * Sample device tree for rpi_4 > > + > > + * Copyright 2021 Google LLC > > + */ > > This is of course an utter lie. This wasn't written from scratch by a > Google employee. > > The original copyright and license for the dtb files you > "disassembled" applies. You don't specify exactly where you obtained > the file from, but it probably came from here: > > https://github.com/raspberrypi/firmware > > And the README.md for that repo states that: > > "The dtbs, overlays and associated README are built from Linux >kernel sources, released under the GPL (see boot/COPYING.linux)" > > They're probably talking about their own fork of the Linux kernel > sources here as there are still differences between their device trees > and the the device trees in the official Linux tree. But if you > insist on having a device tree in the U-Boot tree, that's where you > should look. IANAL and didn't consider this point. I got this from the boot disk (using fdtdump) and it does not include a copyright message. I'll change this in the next version. Regards, Simon
[PATCH v4 3/6] ARM: dts: sync Actions Semi S700 DT from Linux v5.16-rc3
From: Amit Singh Tomar
This Synchronizes the Actions Semi S700 SoC DT changes from
commit "g58e1100fdc59" ("Linux v5.16-rc3").
Signed-off-by: Amit Singh Tomar
---
arch/arm/dts/s700.dtsi| 17 -
.../dt-bindings/power/owl-s700-powergate.h| 19 +++
2 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/power/owl-s700-powergate.h
diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
index 2006ad5424fa..2c78caebf515 100644
--- a/arch/arm/dts/s700.dtsi
+++ b/arch/arm/dts/s700.dtsi
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
/ {
@@ -231,7 +232,7 @@
pinctrl: pinctrl@e01b {
compatible = "actions,s700-pinctrl";
- reg = <0x0 0xe01b 0x0 0x1000>;
+ reg = <0x0 0xe01b 0x0 0x100>;
clocks = <&cmu CLK_GPIO>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 136>;
@@ -244,5 +245,19 @@
,
;
};
+
+ dma: dma-controller@e023 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe023 0x0 0x1000>;
+ interrupts = ,
+,
+,
+;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = <&cmu CLK_DMAC>;
+ power-domains = <&sps S700_PD_DMA>;
+ };
};
};
diff --git a/include/dt-bindings/power/owl-s700-powergate.h
b/include/dt-bindings/power/owl-s700-powergate.h
new file mode 100644
index ..4cf1aefbf09c
--- /dev/null
+++ b/include/dt-bindings/power/owl-s700-powergate.h
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Actions Semi S700 SPS
+ *
+ * Copyright (c) 2017 Andreas Färber
+ */
+#ifndef DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+#define DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+
+#define S700_PD_VDE0
+#define S700_PD_VCE_SI 1
+#define S700_PD_USB2_1 2
+#define S700_PD_HDE3
+#define S700_PD_DMA4
+#define S700_PD_DS 5
+#define S700_PD_USB3 6
+#define S700_PD_USB2_0 7
+
+#endif
--
2.27.0
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > > appended to U-Boot > > > > >- OF_EMBED - for development purposes, the devicetree is embedded > > > > > in > > > > > the ELF file (also used for EFI) > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed at > > > > > all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in > > > > > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > > > > > board > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > > > > > and its > > > > > caller may have a better idea about the hardware available in the > > > > > machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Hi Mark,
On Thu, 2 Dec 2021 at 18:34, Mark Kettenis wrote:
> > From: Simon Glass
> > Date: Thu, 2 Dec 2021 08:59:01 -0700
> >
> > Add this file, obtained from the Raspbian boot disk, so there is a
> > reference devicetree in the U-Boot tree. The same one is used for
> > 32- and 64-bit variants.
> >
> > Note that U-Boot does not normally need this at runtime, since
> > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > devicetree at runtime.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/Makefile|3 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> > configs/rpi_4_32b_defconfig |1 +
> > configs/rpi_4_defconfig |1 +
> > configs/rpi_arm64_defconfig |1 +
> > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2d92b2f940d..9cddab37207 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > bcm2837-rpi-3-a-plus.dtb \
> > bcm2837-rpi-3-b.dtb \
> > bcm2837-rpi-3-b-plus.dtb \
> > - bcm2837-rpi-cm3-io3.dtb
> > + bcm2837-rpi-cm3-io3.dtb \
> > + bcm2711-rpi-4-b.dtb
> >
> > dtb-$(CONFIG_ARCH_BCM63158) += \
> > bcm963158.dtb
> > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > new file mode 100644
> > index 000..425e9fb91c4
> > --- /dev/null
> > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > @@ -0,0 +1,1958 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +/*
> > + * Sample device tree for rpi_4
> > +
> > + * Copyright 2021 Google LLC
> > + */
>
> This is of course an utter lie. This wasn't written from scratch by a
> Google employee.
>
> The original copyright and license for the dtb files you
> "disassembled" applies. You don't specify exactly where you obtained
> the file from, but it probably came from here:
>
> https://github.com/raspberrypi/firmware
>
> And the README.md for that repo states that:
>
> "The dtbs, overlays and associated README are built from Linux
>kernel sources, released under the GPL (see boot/COPYING.linux)"
>
> That's quite a point! thanks for bringing this additional "legal"
standpoint.
> They're probably talking about their own fork of the Linux kernel
> sources here as there are still differences between their device trees
> and the the device trees in the official Linux tree. But if you
> insist on having a device tree in the U-Boot tree, that's where you
> should look.
> > +
> > +/dts-v1/;
> > +
> > +/memreserve/ 0x 0x1000;
> > +/ {
> > + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> > + model = "Raspberry Pi 4 Model B";
> > + interrupt-parent = <0x01>;
> > + #address-cells = <0x02>;
> > + #size-cells = <0x01>;
> > +
> > + aliases {
> > + serial0 = "/soc/serial@7e215040";
> > + serial1 = "/soc/serial@7e201000";
> > + audio = "/soc/audio";
> > + aux = "/soc/aux@7e215000";
> > + sound = "/soc/sound";
> > + soc = "/soc";
> > + dma = "/soc/dma@7e007000";
> > + watchdog = "/soc/watchdog@7e10";
> > + random = "/soc/rng@7e104000";
> > + mailbox = "/soc/mailbox@7e00b880";
> > + gpio = "/soc/gpio@7e20";
> > + uart0 = "/soc/serial@7e201000";
> > + sdhost = "/soc/mmc@7e202000";
> > + mmc0 = "/soc/emmc2@7e34";
> > + i2s = "/soc/i2s@7e203000";
> > + spi0 = "/soc/spi@7e204000";
> > + i2c0 = "/soc/i2c@7e205000";
> > + uart1 = "/soc/serial@7e215040";
> > + spi1 = "/soc/spi@7e215080";
> > + spi2 = "/soc/spi@7e2150c0";
> > + mmc = "/soc/mmc@7e30";
> > + mmc1 = "/soc/mmcnr@7e30";
> > + i2c1 = "/soc/i2c@7e804000";
> > + i2c2 = "/soc/i2c@7e805000";
> > + usb = "/soc/usb@7e98";
> > + leds = "/leds";
> > + fb = "/soc/fb";
> > + thermal = "/soc/thermal@7d5d2200";
> > + axiperf = "/soc/axiperf";
> > + mmc2 = "/soc/mmc@7e202000";
> > + ethernet0 = "/scb/genet@7d58";
> > + };
> > +
> > + chosen {
> > + bootargs = "8250.nr_uarts=1 cma=64M";
> > + };
> > +
> > + thermal-zones {
> > +
> > + cpu-thermal {
> > + polling-delay-passive = <0x00>;
> > + polling-delay = <0x3e8>;
> > + thermal-sensors = <0x02>;
> > + coefficients = <0xfe19 0x641b8>;
> > + phandle = <0x2f>;
> > +
> > + cooling-maps {
> > + };
> > +
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > > > > > > > OF_HOSTFILE so > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built > > > > > > > and > > > > > > > appended to U-Boot > > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > > embedded in > > > > > > > the ELF file (also used for EFI) > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed > > > > > > > at all > > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > > > > > > > Some > > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > > > The problems with this approach are documented in another patch > > > > > > > in this > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > > > > > > > Any board > > > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > > > built > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > > > > > > > bootloader and its > > > > > > > caller may have a better idea about the hardware available in the > > > > > > > machine. > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > > > > > > > an > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > This series makes this change, adding various missing devicetree > > > > > > > files > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > > the > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > > > > The > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > [1] > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > Changes in v6: > > > > > > > - Fix description of OF_BOARD so it refers just to the current > > > > > > > state > > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > > devicetrees > > > > > > > - Expand the commit message based on comments > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > it had not come to this. > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > have a devicetree anywhere I can find. > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > whatever caveats and documentation people want to clarify what is > > > > going on here. I'm happy to look at future options where the > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > within U-Boot for development purposes. > > >
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to > build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide > an empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? I only had that comment in mind: "there is none so deaf as he who will not hear." > At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. > If an EMPTY device is what is required to pass current build constraints, so be it, and let's correct that in a later patch. And EMPTY is not basic. > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Ilias Apalodimas > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > > > > its > > > > caller may have a better idea about the hardware available in the > > > > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. I don't think it makes sense to put stuff in the DT that is specific for U-Boot only to pull it out moments later. Maybe it does make some sense to do this to pass information between TPL/SPL and U-Boot proper. But otherwise you can just use global variables... Now I just ran into an issue on Apple M1 that may have some relevance here. I'm adding support for power domains and the serial port requires certain power domains to be on. Since the serial port is initialized in the pre-relocation phase this means that the device tree nodes for the power domain controllers need to have the "u-boot,dm-pre-reloc" property on them. Otherwise the DM code won't be able to bind the power domain controller driver in this phase and binding the serial port driver itself will fail. Which make
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 11:05:16AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > > > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > > > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > > > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide an > > > empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. I agree with everything except "a basic DT in the tree". It's not used. If you're going to do something with it, the instructions on where the DT comes from will get you there. If the instructions are something like "Well, it's actually horribly complex and depends on what you're doing Xen on and ...", then that's even more of an argument for not having "a basic DT" that will be misleading as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Tom, On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > > > Sorry for being late to the party > > > > On 02.12.21 17:59, Simon Glass wrote: > > > Add an empty file to prevent build errors when building with > > > CONFIG_OF_SEPARATE enabled. > > > > > > The build instructions in U-Boot do not provide enough detail to build a > > > useful devicetree, unfortunately. > > Xen guest doesn't use any built-in device trees as the guest's device tree > > is provided > > by the Xen hypervisor itself and is generated at the virtual machine > > creation time: it is > > populated with memory size, number of CPUs etc. based on [1]. > > So, even if we provide some device tree here it must not be used by U-boot > > at > > the end of the day. Thus, it might be a reasonable solution to provide an > > empty device > > tree as you do, but put a comment that it is not used. > > So another example of why this series is taking things in the wrong > direction. Why? At least we might figure out where to get the DT and how to run Xen with U-Boot. I don't see any down-side to having a basic DT in the tree along with instructions on how to run Xen. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > > > > > > so > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > > > appended to U-Boot > > > > > >- OF_EMBED - for development purposes, the devicetree is > > > > > > embedded in > > > > > > the ELF file (also used for EFI) > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > The last one is currently set up so that no devicetree is needed at > > > > > > all > > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > > > The problems with this approach are documented in another patch in > > > > > > this > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > > > > > > board > > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > > built > > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > > > > > > and its > > > > > > caller may have a better idea about the hardware available in the > > > > > > machine. > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > This series makes this change, adding various missing devicetree > > > > > > files > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > > > > > > the > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > Changes in v6: > > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > > devicetrees > > > > > > - Expand the commit message based on comments > > > > > > - Expand the commit message based on comments > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > I understand you don't like it and that others don't as well. I wish > > > it had not come to this. > > > > > > However we are only talking about 10 boards, three of which don't even > > > have a devicetree anywhere I can find. > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > whatever caveats and documentation people want to clarify what is > > > going on here. I'm happy to look at future options where the > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > within U-Boot for development purposes. > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > But for now, I still feel this is the best path forward. > > > > I'm not sure how to proceed here. The reviews are rather strongly > > against the "include a device tree that won't be used". The use case of > >
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Oleksandr, On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. OK we can go with an empty one if we have to, but where are the instructions to create the DT that is used? I'm not even sure how to run U-Boot with Xen? The in-tree instructions don't help... Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. So another example of why this series is taking things in the wrong direction. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon!
Sorry for being late to the party
On 02.12.21 17:59, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
Xen guest doesn't use any built-in device trees as the guest's device tree is
provided
by the Xen hypervisor itself and is generated at the virtual machine creation
time: it is
populated with memory size, number of CPUs etc. based on [1].
So, even if we provide some device tree here it must not be used by U-boot at
the end of the day. Thus, it might be a reasonable solution to provide an empty
device
tree as you do, but put a comment that it is not used.
Thank you,
Oleksandr
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 000..52d3b062248
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a
> real
> + * devicetree.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig
> b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x4008
> CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x4000
> CONFIG_BOOTDELAY=10
[1] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
> From: Simon Glass
> Date: Thu, 2 Dec 2021 08:59:01 -0700
>
> Add this file, obtained from the Raspbian boot disk, so there is a
> reference devicetree in the U-Boot tree. The same one is used for
> 32- and 64-bit variants.
>
> Note that U-Boot does not normally need this at runtime, since
> CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> devicetree at runtime.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile|3 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> configs/rpi_4_32b_defconfig |1 +
> configs/rpi_4_defconfig |1 +
> configs/rpi_arm64_defconfig |1 +
> 5 files changed, 1963 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 2d92b2f940d..9cddab37207 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> - bcm2837-rpi-cm3-io3.dtb
> + bcm2837-rpi-cm3-io3.dtb \
> + bcm2711-rpi-4-b.dtb
>
> dtb-$(CONFIG_ARCH_BCM63158) += \
> bcm963158.dtb
> diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 000..425e9fb91c4
> --- /dev/null
> +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,1958 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for rpi_4
> +
> + * Copyright 2021 Google LLC
> + */
This is of course an utter lie. This wasn't written from scratch by a
Google employee.
The original copyright and license for the dtb files you
"disassembled" applies. You don't specify exactly where you obtained
the file from, but it probably came from here:
https://github.com/raspberrypi/firmware
And the README.md for that repo states that:
"The dtbs, overlays and associated README are built from Linux
kernel sources, released under the GPL (see boot/COPYING.linux)"
They're probably talking about their own fork of the Linux kernel
sources here as there are still differences between their device trees
and the the device trees in the official Linux tree. But if you
insist on having a device tree in the U-Boot tree, that's where you
should look.
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x 0x1000;
> +/ {
> + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> + model = "Raspberry Pi 4 Model B";
> + interrupt-parent = <0x01>;
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> +
> + aliases {
> + serial0 = "/soc/serial@7e215040";
> + serial1 = "/soc/serial@7e201000";
> + audio = "/soc/audio";
> + aux = "/soc/aux@7e215000";
> + sound = "/soc/sound";
> + soc = "/soc";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e10";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e20";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e34";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + i2c0 = "/soc/i2c@7e205000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + mmc = "/soc/mmc@7e30";
> + mmc1 = "/soc/mmcnr@7e30";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e98";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d58";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e00 0x00 0xfe00 0x180
> + 0x7c00 0x00 0xfc00 0x200
> + 0x4000 0x00 0xff80 0x80>;
> + dma-ranges = <0xc000 0x00 0x0
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Ilias, On Thu, 2 Dec 2021 at 10:04, Ilias Apalodimas wrote: > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > > > > its > > > > caller may have a better idea about the hardware available in the > > > > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. Eh? If the device tree files are actually common then there should be a single source. If U-Boot has a copy then it should be identical. The special node thing makes no sense for U-Boot. We just need to upstream our bindings and I am working on that. Are the device tree files moving out of Linux? Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > > appended to U-Boot > > > > >- OF_EMBED - for development purposes, the devicetree is embedded > > > > > in > > > > > the ELF file (also used for EFI) > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed at > > > > > all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in > > > > > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > > > > > board > > > > > can obtain its devicetree at runtime, even it is has a devicetree > > > > > built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > > > > > and its > > > > > caller may have a better idea about the hardware available in the > > > > > machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > > - Explain that the 'two devicetrees' refers to two *control* > > > > > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > I understand you don't like it and that others don't as well. I wish > > it had not come to this. > > > > However we are only talking about 10 boards, three of which don't even > > have a devicetree anywhere I can find. > > > > I think on balance this is a substantial clean-up. I am happy to add > > whatever caveats and documentation people want to clarify what is > > going on here. I'm happy to look at future options where the > > devicetree is hosted elsewhere, so long as it is trivial to build it > > within U-Boot for development purposes. > > > > I'll also note that the bootstd series shows the devicetree source: > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > But for now, I still feel this is the best path forward. > > I'm not sure how to proceed here. The reviews are rather strongly > against the "include a device tree that won't be used". The use case of > "but for development someone might need to modify the device tree" is > handled by platforms documenting where / how to get the real one. We > should even update the Kconfig help to note that if you enable this your > board docs MUST explain where the device tree can be seen (or have some > legal reason you think it's OK to not...). Right, we can do
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > >- OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented in another patch in this > > > series: "doc: Add documentation about devicetree usage" > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > > > caller may have a better idea about the hardware available in the machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > > > Note: If board maintainers are able to add their own patch to add the > > > files, some patches in this series can be dropped. > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > qemu-riscv64_spl problem is fixed. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > Changes in v6: > > > - Fix description of OF_BOARD so it refers just to the current state > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > - Expand the commit message based on comments > > > - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. So this is a key point for me and the reason I completely disagree with this approach. This proposal is working in the *exact* opposite direction and we'll never be able to get rid of device trees from U-Boot, even if at some point they move out of the kernel to a 'common' repo'. I'll just repeat what I've been saying since v1. Personally I'd be way happier if we could figure out were the specific U-Boot config nodes are needed and when are they needed. Based on what we figure out we could, pick up the device tree from a previous state bootloader and fix it up with our special nodes before we start using it, using internal DTS files (compiled to .dtbos or similar) that indeed belong in the u-boot tree. Regards /Ilias > > -- > Tom
Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
On Thu, Dec 02, 2021 at 05:30:20PM +0100, Heinrich Schuchardt wrote: > On 12/2/21 16:58, Simon Glass wrote: > > QEMU currently generates a devicetree for use with U-Boot. Explain how to > > obtain it. > > > > Also explain how to merge it to produce a devicetree with the U-Boot > > features included. > > Information like the number of CPUs and the memory must be accurate in > the devicetree and match the call parameter of QEMU. > > This worked without this series and must work afterwards. How do you > achieve this? I don't see the problem with _this_ patch. It documents how to have QEMU dump the would-be-used device tree, and how to then modify and pass in a new one. Perhaps it needs a sentence stressing that the included commands are samples and need to match how QEMU is actually invoked? -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > > the ELF file (also used for EFI) > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented in another patch in this > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > > > > its > > > > caller may have a better idea about the hardware available in the > > > > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree files > > > > (and placeholders) to make the build work. > > > > > > > > Note: If board maintainers are able to add their own patch to add the > > > > files, some patches in this series can be dropped. > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > [1] > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > Changes in v6: > > > > - Fix description of OF_BOARD so it refers just to the current state > > > > - Explain that the 'two devicetrees' refers to two *control* devicetrees > > > > - Expand the commit message based on comments > > > > - Expand the commit message based on comments > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > I understand you don't like it and that others don't as well. I wish > it had not come to this. > > However we are only talking about 10 boards, three of which don't even > have a devicetree anywhere I can find. > > I think on balance this is a substantial clean-up. I am happy to add > whatever caveats and documentation people want to clarify what is > going on here. I'm happy to look at future options where the > devicetree is hosted elsewhere, so long as it is trivial to build it > within U-Boot for development purposes. > > I'll also note that the bootstd series shows the devicetree source: > > Core: 246 devices, 88 uclasses, devicetree: board > > But for now, I still feel this is the best path forward. I'm not sure how to proceed here. The reviews are rather strongly against the "include a device tree that won't be used". The use case of "but for development someone might need to modify the device tree" is handled by platforms documenting where / how to get the real one. We should even update the Kconfig help to note that if you enable this your board docs MUST explain where the device tree can be seen (or have some legal reason you think it's OK to not...). And yes, we're "only" talking about 10 platforms, which include things like the "everyone" has one Pi family, the extraordinarily flexible (and so easy for the reference device tree to be very wrong) QEMU families and then platforms that are including a dts in-tree now because they were told that was required. How about adjusti
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:40, Simon Glass a écrit : > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog > wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >>- OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >>- OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >>- OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are > good advances in the documentation and other areas that would be better in > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), Qemu is another one, and then you will have all SystemReady compliant boards. > where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. I proposed this as a last resort if I was the only one with concerns. But sounds like I am not the only one strongly opinionated here. Another trick would be to use a “.dts.doc” extension so that it is not compiled unless someone is knowingly deciding to use the fake DT for debug purposes (the warning message is still valid). (This is an effort to advance on the good things of the patch) > > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand o
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 16:40, Simon Glass wrote: > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! Isn't highbank https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts ? -- PMM
Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
Hi Heinrich, On Thu, 2 Dec 2021 at 09:35, Heinrich Schuchardt wrote: > > On 12/2/21 16:58, Simon Glass wrote: > > QEMU currently generates a devicetree for use with U-Boot. Explain how to > > obtain it. > > > > Also explain how to merge it to produce a devicetree with the U-Boot > > features included. > > Information like the number of CPUs and the memory must be accurate in > the devicetree and match the call parameter of QEMU. > > This worked without this series and must work afterwards. How do you > achieve this? Because it does not change how things work. Please test it for yourself and let me know if you have any problems. Regards, Simon
