[PATCH v5 1/1] sf: Provide a command to access memory-mapped SPI
Add a new 'sf mmap' function to show the address of a SPI offset, if the
hardware supports it. This is useful on x86 systems.
Signed-off-by: Simon Glass
---
(no changes since v4)
Changes in v4:
- Drop patches previously applied
- Fix succeded typo
Changes in v3:
- Add configuration and return value also
arch/Kconfig | 2 ++
cmd/Kconfig | 8 ++
cmd/sf.c | 35 +++
doc/usage/sf.rst | 63
4 files changed, 108 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index 3e2cc84ab2c..6333757f0ec 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -160,6 +160,7 @@ config SANDBOX
imply CMD_LZMADEC
imply CMD_SATA
imply CMD_SF
+ imply CMD_SF_MMAP
imply CMD_SF_TEST
imply CRC32_VERIFY
imply FAT_WRITE
@@ -225,6 +226,7 @@ config X86
imply CMD_IRQ
imply CMD_PCI
imply CMD_SF
+ imply CMD_SF_MMAP
imply CMD_SF_TEST
imply CMD_ZBOOT
imply DM_ETH
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e438..3627c1cbd44 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1300,6 +1300,14 @@ config CMD_SF
help
SPI Flash support
+config CMD_SF_MMAP
+ bool "sf mmap - Access memory-mapped SPI flash"
+ depends on CMD_SF
+ help
+ On some systems part of the SPI flash is mapped into mmemory. This
+ command provides a way to map a SPI-flash offset to a memory address,
+ so that the contents can be browsed using 'md', for example.
+
config CMD_SF_TEST
bool "sf test - Allow testing of SPI flash"
depends on CMD_SF
diff --git a/cmd/sf.c b/cmd/sf.c
index 72246d912fe..c78cd7e6342 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -384,6 +384,36 @@ static int do_spi_protect(int argc, char *const argv[])
return ret == 0 ? 0 : 1;
}
+static int do_spi_flash_mmap(int argc, char *const argv[])
+{
+ loff_t offset, len, maxsize;
+ uint map_offset, map_size;
+ ulong map_base;
+ int dev = 0;
+ int ret;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ ret = mtd_arg_off_size(argc - 1, [1], , , ,
+ , MTD_DEV_TYPE_NOR, flash->size);
+ if (ret)
+ return ret;
+
+ ret = dm_spi_get_mmap(flash->dev, _base, _size, _offset);
+ if (ret) {
+ printf("Mapping not available (err=%d)\n", ret);
+ return CMD_RET_FAILURE;
+ }
+ if (offset < 0 || offset + len > map_size) {
+ printf("Offset out of range (map size %x)\n", map_size);
+ return CMD_RET_FAILURE;
+ }
+ printf("%lx\n", map_base + (ulong)offset);
+
+ return 0;
+}
+
enum {
STAGE_ERASE,
STAGE_CHECK,
@@ -580,6 +610,8 @@ static int do_spi_flash(struct cmd_tbl *cmdtp, int flag,
int argc,
ret = do_spi_flash_erase(argc, argv);
else if (strcmp(cmd, "protect") == 0)
ret = do_spi_protect(argc, argv);
+ else if (IS_ENABLED(CONFIG_CMD_SF_MMAP) && !strcmp(cmd, "mmap"))
+ ret = do_spi_flash_mmap(argc, argv);
else if (IS_ENABLED(CONFIG_CMD_SF_TEST) && !strcmp(cmd, "test"))
ret = do_spi_flash_test(argc, argv);
else
@@ -611,6 +643,9 @@ static const char long_help[] =
" or to start of mtd
`partition'\n"
"sf protect lock/unlock sector len - protect/unprotect 'len' bytes
starting\n"
" at address 'sector'"
+#ifdef CONFIG_CMD_SF_MMAP
+ "\nsf mmap offset len - get memory address of SPI-flash
offset\n"
+#endif
#ifdef CONFIG_CMD_SF_TEST
"\nsf test offset len - run a very basic destructive test"
#endif
diff --git a/doc/usage/sf.rst b/doc/usage/sf.rst
index 71bd1be5175..0452a762398 100644
--- a/doc/usage/sf.rst
+++ b/doc/usage/sf.rst
@@ -14,6 +14,7 @@ Synopis
sf erase |
sf update |
sf protect lock|unlock
+sf mmap |
sf test |
Description
@@ -143,6 +144,16 @@ lock|unlock
Number of bytes to lock/unlock
+Memory-mapped flash
+---
+
+On some systems part of the SPI flash is mapped into mmemory. With *sf mmap*
+you can map a SPI-flash offset to a memory address, so that the contents can be
+browsed using 'md', for example.
+
+The command will fail if this is not supported by the hardware or driver.
+
+
Test
@@ -240,6 +251,58 @@ This second example is running on coral, an x86
Chromebook::
2 write: 227 ticks, 2255 KiB/s 18.040 Mbps
3 read: 189 ticks, 2708 KiB/s 21.664 Mbps
+ # On coral, SPI flash offset 0 corresponds to address ff081000 in memory
+ => sf mmap 0 1000
+ device 0 offset 0x0, size 0x1000
+ ff081000
+
+ # See below for how this address was obtained
+ => sf mmap e8 11e18
+ device 0 offset 0xe8, size 0x11e18
+
[PATCH v5 0/1] sf: Add documentation and an 'sf mmap' command
This little series adds documentation and a few other tidy-ups to the 'sf' command. It also provides a way to access memory-mapped SPI via the command line. NOTE: I am resending this as I didn't get a response to the question on the review. I suggest we apply it as is unless there is a better idea. (no changes since v4) Changes in v4: - Drop patches previously applied - Fix succeded typo Changes in v3: - Add configuration and return value also Simon Glass (1): sf: Provide a command to access memory-mapped SPI arch/Kconfig | 2 ++ cmd/Kconfig | 8 ++ cmd/sf.c | 35 +++ doc/usage/sf.rst | 63 4 files changed, 108 insertions(+) -- 2.34.1.400.ga245620fadb-goog
Re: [PATCH 08/15] rtc: pcf2127: remove U-Boot specific compatible string
On Fri, 3 Dec 2021 at 15:09, Vladimir Oltean wrote:
>
> Hi Simon,
>
> On Fri, Dec 03, 2021 at 01:13:15PM -0700, Simon Glass wrote:
> > Hi Vladimir,
> >
> > On Thu, 2 Dec 2021 at 07:54, Vladimir Oltean
> > wrote:
> > >
> > > Now that all in-tree boards have been converted to the compatible
> > > strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.
> > >
> > > Cc: Simon Glass
> > > Signed-off-by: Vladimir Oltean
> > > ---
> > > drivers/rtc/pcf2127.c | 1 -
> > > 1 file changed, 1 deletion(-)
> >
> > Reviewed-by: Simon Glass
>
> Thanks for the review!
>
> > This seems to still be used in the tree. I assume there are other
> > patches that fix that.
> >
> > git grep pcf2127-rtc
> > arch/arm/dts/fsl-ls1028a-qds.dtsi: compatible = "pcf2127-rtc";
> > arch/arm/dts/fsl-ls1028a-rdb.dts:
> > compatible = "pcf2127-rtc";
> > arch/arm/dts/fsl-ls1088a-qds.dtsi:
> > compatible = "pcf2127-rtc";
> > arch/arm/dts/fsl-ls1088a-rdb.dts:
> > compatible = "pcf2127-rtc";
> > arch/arm/dts/fsl-lx2160a-qds.dtsi:
> > compatible = "pcf2127-rtc";
> > arch/arm/dts/fsl-lx2160a-rdb.dts: compatible = "pcf2127-rtc";
> > drivers/rtc/pcf2127.c: { .compatible = "pcf2127-rtc" },
>
> Yes, indeed there are:
> https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-4-vladimir.olt...@nxp.com/
> https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-5-vladimir.olt...@nxp.com/
> https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-6-vladimir.olt...@nxp.com/
> https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-7-vladimir.olt...@nxp.com/
> https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-8-vladimir.olt...@nxp.com/
> I didn't want to spam your mailbox with those.
Very kind :-)
- Simon
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
Hi Heinrich, On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt wrote: > > On 12/3/21 9:13 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt wrote: > >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote: > >>> On 12/2/21 16:58, Simon Glass wrote: > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > Reviewed-by: Marcel Ziswiler > --- > This patch attracted quite a bit of discussion here: > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > > > I have not included the text suggested by François. While I agree that > it would be useful to have an introduction in this space, I do not agree > that we should have two devicetrees or that U-Boot should not have its > own > things in the devicetree, so it is not clear to me what we should > actually > write. > > The 'Devicetree Control in U-Boot' docs were recently merged and these > provide some base info, for now. > > 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 > > 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 > > 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 on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > doc/develop/devicetree/dt_update.rst | 555 +++ > doc/develop/devicetree/index.rst | 1 + > 2 files changed, 556 insertions(+) > create mode 100644 doc/develop/devicetree/dt_update.rst > > > [..] > > > + > +- The other project may not provide a way to support U-Boot's > requirements for > + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > >>> > >>> Even if you remove these lines in 17/25 I would prefer not to introduce > >>> typos here: > >>> > >>> %s/linst/list/ > >>> > > > > OK I can fix that. > > > > [..] > > > +Normally, supporting U-Boot's features is trivial, since the > devicetree compiler > +(dtc) can compile the source, including any U-Boot pieces. So the > burden is > +extremely low. > + > +In this case, the devicetree in the other project must track U-Boot's > use of > +device tree, so that it remains compatible. See `Devicetree in > another project`_ > +for reasons why. > >>> > >>> Did you ever ask the QEMU community what they think about your ideas? > >>> What was the reply? > >> > >> Looking at the thread > >> https://lore.kernel.org/all/20210926183410.256484-1-...@chromium.org/ > >> the QEMU project said NAK. This matches the expectation that I expressed > >> repeatedly. > >> > >> Why don't you mention the QEMU reply in this patch series and adjust > >> your design accordingly? > > > > The QEMU maintainer may react when he sees a problem. > > Why are you unwilling to admit the problem? QEMU will never support > U-Boot specific stuff. > > Please, develop concepts that solve U-Boot's needs within U-Boot. So you are saying that because QEMU wrote it's devicetree support with Linux in mind, we should, what...? Spent 500ms merging devicetrees before relocation? Move back to platdata? Delete driver model? Rewrite U-Boot? U-Boot works quite nicely as it is. The problem is that
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Fri, 3 Dec 2021 at 13:43, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > > 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 > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 12:25, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> > is generallyHi Tom,
> >
> > On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > > > >
> > > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > > > >
> > > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > Note that I can't run-time test this as the last patch fails to
> > > > > > > apply
> > > > > > > and is dependent on non-trivial missing changes ("/* The
> > > > > > > devicetree is
> > > > > > > typically appended to U-Boot */" doesn't exist at all in
> > > > > > > lib/fdtdec.c
> > > > > > > and that's part of the unchanging context where things fail to
> > > > > > > apply).
> > > > > >
> > > > > > That code is the penultimate patch ("fdt: Drop remaining
> > > > > > preprocessor
> > > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > > -next and is at dm/ofb-working if you want to compare.
> > > > >
> > > > > I just fetch'd and built that instead, thanks.
> > > > >
> > > > > > > So, here's my first bit of confusion. Today, I build for
> > > > > > > rpi_arm64 and
> > > > > > > no dtb files are built. I run this on my Pi 3 and everything
> > > > > > > works.
> > > > > > > With your series, I see all the dtbs have been built, and
> > > > > > > dts/dt.dtb and
> > > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > > >
> > > > > > Yes, so long as OF_BOARD is enabled, which it is in this series.
> > > > > > This
> > > > > > is basically the same as the situation with rpi3, except it uses
> > > > > > OF_EMBED (need to fix...)
> > > > >
> > > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > > never ever use this dtb, under any circumstance, right?
> > > >
> > > > That's right, unless you disable OF_BOARD and build U-Boot again.
> > >
> > > And then it would fail to boot, because I'm on a 3, not a 4.
> >
> > Yes, but that's because the DT is wrong, right? The build builds all
> > the different DTs but just selects one (the default) to put into
> > u-boot.dtb and u-boot.bin
> >
> > We could make it generate images for all of them. I have thought about
> > that as it stops us
Re: [PATCH 08/15] rtc: pcf2127: remove U-Boot specific compatible string
Hi Simon,
On Fri, Dec 03, 2021 at 01:13:15PM -0700, Simon Glass wrote:
> Hi Vladimir,
>
> On Thu, 2 Dec 2021 at 07:54, Vladimir Oltean wrote:
> >
> > Now that all in-tree boards have been converted to the compatible
> > strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.
> >
> > Cc: Simon Glass
> > Signed-off-by: Vladimir Oltean
> > ---
> > drivers/rtc/pcf2127.c | 1 -
> > 1 file changed, 1 deletion(-)
>
> Reviewed-by: Simon Glass
Thanks for the review!
> This seems to still be used in the tree. I assume there are other
> patches that fix that.
>
> git grep pcf2127-rtc
> arch/arm/dts/fsl-ls1028a-qds.dtsi: compatible = "pcf2127-rtc";
> arch/arm/dts/fsl-ls1028a-rdb.dts:
> compatible = "pcf2127-rtc";
> arch/arm/dts/fsl-ls1088a-qds.dtsi:
> compatible = "pcf2127-rtc";
> arch/arm/dts/fsl-ls1088a-rdb.dts:
> compatible = "pcf2127-rtc";
> arch/arm/dts/fsl-lx2160a-qds.dtsi:
> compatible = "pcf2127-rtc";
> arch/arm/dts/fsl-lx2160a-rdb.dts: compatible = "pcf2127-rtc";
> drivers/rtc/pcf2127.c: { .compatible = "pcf2127-rtc" },
Yes, indeed there are:
https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-4-vladimir.olt...@nxp.com/
https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-5-vladimir.olt...@nxp.com/
https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-6-vladimir.olt...@nxp.com/
https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-7-vladimir.olt...@nxp.com/
https://patchwork.ozlabs.org/project/uboot/patch/20211202145409.2482099-8-vladimir.olt...@nxp.com/
I didn't want to spam your mailbox with those.
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 07:03:30PM -0700, Simon Glass wrote: > 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
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
On Fri, Dec 03, 2021 at 01:13:12PM -0700, Simon Glass wrote:
> On Fri, 3 Dec 2021 at 00:55, Andy Shevchenko
> wrote:
> > On Friday, December 3, 2021, Simon Glass wrote:
> >> On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko
> >> wrote:
...
> >> 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.
>
> What am I missing?
>
> $ binman test
> Traceback (most recent call last):
> File "/home/sglass/bin/binman", line 23, in
> srctree = os.environ['srctree']
> File "/usr/lib/python3.8/os.py", line 675, in __getitem__
> raise KeyError(key) from None
> KeyError: 'srctree'
I see, you mean that you run it when it's not in build tree?
> >> 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?
Ah, you mean you run it manually and not via `make`.
os.environ.get('srctree', '')
should help I suppose.
P.S. What is the 'srcdir' you are referring to all the time?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
On 12/3/21 9:13 PM, Simon Glass wrote: Hi Heinrich, On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt wrote: On 12/3/21 13:34, Heinrich Schuchardt wrote: On 12/2/21 16:58, Simon Glass wrote: At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass Reviewed-by: Marcel Ziswiler --- This patch attracted quite a bit of discussion here: https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write. The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now. 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 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 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 on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' doc/develop/devicetree/dt_update.rst | 555 +++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 556 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst [..] + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this Even if you remove these lines in 17/25 I would prefer not to introduce typos here: %s/linst/list/ OK I can fix that. [..] +Normally, supporting U-Boot's features is trivial, since the devicetree compiler +(dtc) can compile the source, including any U-Boot pieces. So the burden is +extremely low. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. See `Devicetree in another project`_ +for reasons why. Did you ever ask the QEMU community what they think about your ideas? What was the reply? Looking at the thread https://lore.kernel.org/all/20210926183410.256484-1-...@chromium.org/ the QEMU project said NAK. This matches the expectation that I expressed repeatedly. Why don't you mention the QEMU reply in this patch series and adjust your design accordingly? The QEMU maintainer may react when he sees a problem. Why are you unwilling to admit the problem? QEMU will never support U-Boot specific stuff. Please, develop concepts that solve U-Boot's needs within U-Boot. Best regards Heinrich I have already clearly stated that there is no way we are have two control DTBs. The overlay is also unworkable and unnecessary. That is why I put so much effort into this patch, after all. So for now, people will just have to deal with what QEMU provides. I sent a patch to resolve the problem which can be accepted at any point if people complain enough. So far only François has offered support for it. Regards, Simon
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Le ven. 3 déc. 2021 à 21:14, Simon Glass a écrit : > Hi François, > > On Fri, 3 Dec 2021 at 10:03, François Ozog > wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > >> > > Hi François, > >> > > > >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog < > francois.o...@linaro.org> 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 < > francois.o...@linaro.org> 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 > >> > > >> > I want to cycle back over here. Yes, historically a number of things > >> > came in that perhaps shouldn't have. I went with "well, this is what > we > >> > need to handle this case I suppose" and applied it. > >> > >> Yes and we need to move things forward. We can't just object to things > >> without an alternative. > > > > As far as I can follow the threads, I proposed the dts to be empty to > pass compilation and move forward, but I think you haven't replied. The > empty dts can contain a comment pointing to documentation, which could > describe the DT lifecycle of the platform, and a
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Fri, Dec 03, 2021 at 01:14:04PM -0700, Simon Glass wrote: > Hi François, > > On Fri, 3 Dec 2021 at 10:03, François Ozog wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > >> > > 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 > >> > > >> > I want to cycle back over here. Yes, historically a number of things > >> > came in that perhaps shouldn't have. I went with "well, this is what we > >> > need to handle this case I suppose" and applied it. > >> > >> Yes and we need to move things forward. We can't just object to things > >> without an alternative. > > > > As far as I can follow the threads, I proposed the dts to be empty to pass > > compilation
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Fri, 3 Dec 2021 at 10:03, François Ozog wrote: > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: >> >> Hi Tom, >> >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: >> > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: >> > > 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 >> > >> > I want to cycle back over here. Yes, historically a number of things >> > came in that perhaps shouldn't have. I went with "well, this is what we >> > need to handle this case I suppose" and applied it. >> >> Yes and we need to move things forward. We can't just object to things >> without an alternative. > > As far as I can follow the threads, I proposed the dts to be empty to pass > compilation and move forward, but I think you haven't replied. The empty dts > can contain a comment pointing to documentation, which could describe the DT > lifecycle of the platform, and a template dts that could be used for > adventurous developers. That does not go far enough for me. We actually do want to be able to build U-Boot and run it on the board,
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
Hi Heinrich, On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt wrote: > > On 12/3/21 13:34, Heinrich Schuchardt wrote: > > On 12/2/21 16:58, Simon Glass wrote: > >> At present some of the ideas and techniques behind devicetree in U-Boot > >> are assumed, implied or unsaid. Add some documentation to cover how > >> devicetree is build, how it can be modified and the rules about using > >> the various CONFIG_OF_... options. > >> > >> Signed-off-by: Simon Glass > >> Reviewed-by: Marcel Ziswiler > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> > >> > >> I have not included the text suggested by François. While I agree that > >> it would be useful to have an introduction in this space, I do not agree > >> that we should have two devicetrees or that U-Boot should not have its > >> own > >> things in the devicetree, so it is not clear to me what we should > >> actually > >> write. > >> > >> The 'Devicetree Control in U-Boot' docs were recently merged and these > >> provide some base info, for now. > >> > >> 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 > >> > >> 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 > >> > >> 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 on why we should have rules for other projects in > >>'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >>points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> doc/develop/devicetree/dt_update.rst | 555 +++ > >> doc/develop/devicetree/index.rst | 1 + > >> 2 files changed, 556 insertions(+) > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> [..] > >> + > >> +- The other project may not provide a way to support U-Boot's > >> requirements for > >> + devicetree, such as the /config node. Note: On the U-Boot mailing > >> linst, this > > > > Even if you remove these lines in 17/25 I would prefer not to introduce > > typos here: > > > > %s/linst/list/ > > OK I can fix that. [..] > >> +Normally, supporting U-Boot's features is trivial, since the > >> devicetree compiler > >> +(dtc) can compile the source, including any U-Boot pieces. So the > >> burden is > >> +extremely low. > >> + > >> +In this case, the devicetree in the other project must track U-Boot's > >> use of > >> +device tree, so that it remains compatible. See `Devicetree in > >> another project`_ > >> +for reasons why. > > > > Did you ever ask the QEMU community what they think about your ideas? > > What was the reply? > > Looking at the thread > https://lore.kernel.org/all/20210926183410.256484-1-...@chromium.org/ > the QEMU project said NAK. This matches the expectation that I expressed > repeatedly. > > Why don't you mention the QEMU reply in this patch series and adjust > your design accordingly? The QEMU maintainer may react when he sees a problem. I have already clearly stated that there is no way we are have two control DTBs. The overlay is also unworkable and unnecessary. That is why I put so much effort into this patch, after all. So for now, people will just have to deal with what QEMU provides. I sent a patch to resolve the problem which can be accepted at any point if people complain enough. So far only François has offered support for it. Regards, Simon
Re: [PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
Hi Peter, On Fri, 3 Dec 2021 at 05:20, Peter Robinson wrote: > > On Fri, Dec 3, 2021 at 3:32 AM Simon Glass wrote: > > > > 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. > > So are there docs for how do this? I didn't manage to find any, > although the docs I find can be a little over the place in U-Boot so > they may be there and I missed them, so either way docs would be fab. There are SPI instructions at doc/board/rockchip but they are pretty 'one way'. So you would need a way to get your old SPI-flash contents back when it doesn't work, because I don't think these platforms support SD boot. I use a 'servo' board and a Dediprog em100 SPI emulator. I know that kevin does not support CCD (Close-Case Debugging) so you cannot program the SPI flash that way... Regards, Simon
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Hi Peter, Taking another look at https://github.com/raspberrypi/firmware.git I see that the README says that the .dtb files are build from Linux. So it seems I can simply grab them from there. Regards, Simon On Fri, 3 Dec 2021 at 05:16, Peter Robinson wrote: > > On Thu, Dec 2, 2021 at 6:26 PM Simon Glass wrote: > > > > 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. > > Should probably just get the original one from their upstream source > repo then rather than decompiling it.
Re: [PATCH 08/15] rtc: pcf2127: remove U-Boot specific compatible string
Hi Vladimir,
On Thu, 2 Dec 2021 at 07:54, Vladimir Oltean wrote:
>
> Now that all in-tree boards have been converted to the compatible
> strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.
>
> Cc: Simon Glass
> Signed-off-by: Vladimir Oltean
> ---
> drivers/rtc/pcf2127.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Simon Glass
This seems to still be used in the tree. I assume there are other
patches that fix that.
git grep pcf2127-rtc
arch/arm/dts/fsl-ls1028a-qds.dtsi: compatible = "pcf2127-rtc";
arch/arm/dts/fsl-ls1028a-rdb.dts:
compatible = "pcf2127-rtc";
arch/arm/dts/fsl-ls1088a-qds.dtsi:
compatible = "pcf2127-rtc";
arch/arm/dts/fsl-ls1088a-rdb.dts:
compatible = "pcf2127-rtc";
arch/arm/dts/fsl-lx2160a-qds.dtsi:
compatible = "pcf2127-rtc";
arch/arm/dts/fsl-lx2160a-rdb.dts: compatible = "pcf2127-rtc";
drivers/rtc/pcf2127.c: { .compatible = "pcf2127-rtc" },
Regards,
Simon
Re: [PATCH 02/15] rtc: pcf2127: sync with Linux compatible strings
On Thu, 2 Dec 2021 at 07:54, Vladimir Oltean wrote: > > Allow this driver to be used by boards which inherit their device trees > from Linux. Compatibility is temporarily retained with the old > compatible string which is U-Boot specific, and will be removed after a > few changes. > > Cc: Simon Glass > Signed-off-by: Vladimir Oltean > --- > drivers/rtc/pcf2127.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
Hi Andy, On Fri, 3 Dec 2021 at 00:55, Andy Shevchenko wrote: > > > > 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. What am I missing? $ binman test Traceback (most recent call last): File "/home/sglass/bin/binman", line 23, in srctree = os.environ['srctree'] File "/usr/lib/python3.8/os.py", line 675, in __getitem__ raise KeyError(key) from None KeyError: 'srctree' >> >> >> 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
Re: [PATCH v2] RFC: gitlab: x86: Add a coreboot test
Hi Tom, On Fri, 3 Dec 2021 at 09:05, Tom Rini wrote: > > On Fri, Dec 03, 2021 at 08:47:55AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 3 Dec 2021 at 08:00, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 07:26:21PM -0700, Simon Glass wrote: > > > > > > > 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 > > > > > > We should build coreboot in the Dockerfile like we do grub and so forth, > > > then not have to worry about the toolchain things since it's just a > > > one-time cost to me (or anyone else doing docker build). > > > > OK...it does take an age though, since it builds various toolchains > > before it will even build coreboot. I'm going to talk to them about > > why they can't use 'normal' toolchains. Anyway, I'll add it in and see > > how it looks. > > > > Do you want me to try the DockerFile thing first, or is having a > > download OK for now? What do you think about doing a docker thing for > > nikia_rx51 ? > > For coreboot, lets see what the feedback you get is, and we can deal > with adding the test soon like this I suppose. OK, it might take some weeks to figure it out but am having a chat next week. > > For nokia_rx51, I assume you mean building qemu and I'm not sure we can > without making the test more fragile for non-CI? It doesn't tend to be > much of a bottleneck so I'd rather not tweak it further. Ah OK I hadn't thought of that side. It fails for me a fair bit which is why I think of it. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 09:45:12AM -0700, Simon Glass wrote:
> is generallyHi Tom,
>
> On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > > >
> > > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > > >
> > > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > Note that I can't run-time test this as the last patch fails to
> > > > > > apply
> > > > > > and is dependent on non-trivial missing changes ("/* The devicetree
> > > > > > is
> > > > > > typically appended to U-Boot */" doesn't exist at all in
> > > > > > lib/fdtdec.c
> > > > > > and that's part of the unchanging context where things fail to
> > > > > > apply).
> > > > >
> > > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > > -next and is at dm/ofb-working if you want to compare.
> > > >
> > > > I just fetch'd and built that instead, thanks.
> > > >
> > > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64
> > > > > > and
> > > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > > With your series, I see all the dtbs have been built, and
> > > > > > dts/dt.dtb and
> > > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > > >
> > > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > > is basically the same as the situation with rpi3, except it uses
> > > > > OF_EMBED (need to fix...)
> > > >
> > > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > > .config, so I'm telling it to use the run-time device tree. It will
> > > > never ever use this dtb, under any circumstance, right?
> > >
> > > That's right, unless you disable OF_BOARD and build U-Boot again.
> >
> > And then it would fail to boot, because I'm on a 3, not a 4.
>
> Yes, but that's because the DT is wrong, right? The build builds all
> the different DTs but just selects one (the default) to put into
> u-boot.dtb and u-boot.bin
>
> We could make it generate images for all of them. I have thought about
> that as it stops us needing different boards just to handle having
> multiple DT options. But I haven't really looked at it.
It would be wrong because it's the wrong device tree for the hardware,
yes. And we don't want to build N different binaries, the point of the
target is that everything works like a good data-driven
Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot
On Fri, Dec 03, 2021 at 09:17:20AM -0700, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 09:02, Tom Rini wrote: > > > > On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote: > > > > > Add a means of testing a coreboot + U-Boot build using qemu. > > > > > > Signed-off-by: Simon Glass > > > --- > > > As to what to do with people's labs, I think applying these patches does > > > encourage them and provide people with examples. Having 'no mainline' for > > > these is going to be an impediment I think. > > > > > > Changes in v2: > > > - Drop the ellesmere symlink > > > > > > bin/travis-ci/conf.coreboot_qemu | 28 > > > 1 file changed, 28 insertions(+) > > > create mode 100644 bin/travis-ci/conf.coreboot_qemu > > > > So, now we have the conf, for something 100% virtual, in bin/travis-ci > > (which yes, ugh, bad name). If we had a top-level README.rst how would > > it be unclear that this is a functional example? In fact, maybe we > > should clear something up. How does the network test work for you? I > > have to modify them to pass -tftp=/tftpboot so that I can then give it > > things like helloworld.efi and appropriate grub.efi. Are you using some > > wrapper to make things look more like what CI does? > > I haven't tried the network tests, actually. Mostly I run individual > tests or just boot to a prompt and try things out. One day I would > like to get labman closer to making this automatic. Ah. I have a wrapper to activate a virtualenv for the pytest stuff, then set PYTHONPATH / UBOOT_TRAVIS_BUILD_DIR and it all just works. Except since I want to test the network a bit more heavily, I pass in my own tftpboot dir, with a larger test file. I could possibly change things to wrap up and look more like CI does, and require less tweaking. -- Tom signature.asc Description: PGP signature
[PATCH] pinctrl: single: add support for pinctrl-single, pins when #pinctrl-cells = 2
Changes to the am33xx device (33e9021a) trees have been merged in from
the upstream linux kernel which now means the device tree uses the new
pins format (as of 5.10) where the confinguration can be stores as a
separate configuration value and pin mux mode which are then OR'd
together.
This patch adds support for the new format to u-boot so that
pinctrl-cells is now respected when reading in pinctrl-single,pins
---
drivers/pinctrl/pinctrl-single.c | 55 +---
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 8fc07e3498..bc9c17bce8 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -28,6 +28,7 @@ struct single_pdata {
int offset;
u32 mask;
u32 width;
+ u32 args_count;
bool bits_per_mux;
};
@@ -78,20 +79,6 @@ struct single_priv {
struct list_head gpiofuncs;
};
-/**
- * struct single_fdt_pin_cfg - pin configuration
- *
- * This structure is used for the pin configuration parameters in case
- * the register controls only one pin.
- *
- * @reg: configuration register offset
- * @val: configuration register value
- */
-struct single_fdt_pin_cfg {
- fdt32_t reg;
- fdt32_t val;
-};
-
/**
* struct single_fdt_bits_cfg - pin configuration
*
@@ -314,25 +301,28 @@ static int single_pin_compare(const void *s1, const void
*s2)
* @dev: Pointer to single pin configuration device which is the parent of
* the pins node holding the pin configuration data.
* @pins: Pointer to the first element of an array of register/value pairs
- *of type 'struct single_fdt_pin_cfg'. Each such pair describes the
- *the pin to be configured and the value to be used for configuration.
+ *of type 'u32'. Each such pair describes the pin to be configured
+ *and the value to be used for configuration.
+ *The value can either be a simple value if #pinctrl-cells = 1
+ *or a configuration value and a pin mux mode value if it is 2
*This pointer points to a 'pinctrl-single,pins' property in the
*device-tree.
* @size: Size of the 'pins' array in bytes.
- *The number of register/value pairs in the 'pins' array therefore
- *equals to 'size / sizeof(struct single_fdt_pin_cfg)'.
+ *The number of cells in the array therefore equals to
+ *'size / sizeof(u32)'.
* @fname: Function name.
*/
static int single_configure_pins(struct udevice *dev,
-const struct single_fdt_pin_cfg *pins,
+const u32 *pins,
int size, const char *fname)
{
struct single_pdata *pdata = dev_get_plat(dev);
struct single_priv *priv = dev_get_priv(dev);
- int n, pin, count = size / sizeof(struct single_fdt_pin_cfg);
+ int stride = pdata->args_count + 1;
+ int n, pin, count = size / sizeof(u32);
struct single_func *func;
phys_addr_t reg;
- u32 offset, val;
+ u32 offset, val, mux;
/* If function mask is null, needn't enable it. */
if (!pdata->mask)
@@ -344,16 +334,22 @@ static int single_configure_pins(struct udevice *dev,
func->name = fname;
func->npins = 0;
- for (n = 0; n < count; n++, pins++) {
- offset = fdt32_to_cpu(pins->reg);
+ for (n = 0; n < count; n += stride) {
+ offset = fdt32_to_cpu(pins[n]);
if (offset > pdata->offset) {
dev_err(dev, " invalid register offset 0x%x\n",
offset);
continue;
}
+ /* if the pinctrl-cells is 2 then the second cell contains the
mux */
+ if (stride == 3)
+ mux = fdt32_to_cpu(pins[n + 2]);
+ else
+ mux = 0;
+
reg = pdata->base + offset;
- val = fdt32_to_cpu(pins->val) & pdata->mask;
+ val = (fdt32_to_cpu(pins[n + 1]) | mux) & pdata->mask;
pin = single_get_pin_by_offset(dev, offset);
if (pin < 0) {
dev_err(dev, " failed to get pin by offset %x\n",
@@ -453,7 +449,7 @@ static int single_configure_bits(struct udevice *dev,
static int single_set_state(struct udevice *dev,
struct udevice *config)
{
- const struct single_fdt_pin_cfg *prop;
+ const u32 *prop;
const struct single_fdt_bits_cfg *prop_bits;
int len;
@@ -461,7 +457,7 @@ static int single_set_state(struct udevice *dev,
if (prop) {
dev_dbg(dev, "configuring pins for %s\n", config->name);
- if (len % sizeof(struct single_fdt_pin_cfg)) {
+ if (len % sizeof(u32)) {
dev_dbg(dev, " invalid pin configuration
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > > > 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 < > francois.o...@linaro.org> 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 > > > > I want to cycle back over here. Yes, historically a number of things > > came in that perhaps shouldn't have. I went with "well, this is what we > > need to handle this case I suppose" and applied it. > > Yes and we need to move things forward. We can't just object to things > without an alternative. As far as I can follow the threads, I proposed the dts to be empty to pass compilation and move forward, but I think you haven't replied. The empty dts can contain a comment pointing to documentation, which could describe the DT lifecycle of the platform, and a template dts that could be used for adventurous developers. > As I have mentioned before, I think, I did > actually review this (there was a question about sequence numbers or > something) and didn't even notice the devicetree thing! It should have > been a separate patch, I suppose. But even with the other patch > (OF_BOARD), I did not at the time understand the implications. I feel > very bad about the situation we are in and I wish I had thought it > through properly at the
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 03.12.21 18:23, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko > wrote: >> 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 > I'd like to try it out. How?? Well, it can be tricky a bit. There are number of ARM64 platforms which have Xen running: Arm, Renesas, Xilinx, iMX8, Rpi4... You can probably start from QEMU, for example OP-TEE has a way to build Xen + QEMU, please see [1]. The build has Xen in it and a virtual machine [2]. You will need to tweak [3] and put U-boot instead of the Linux kernel. I never tried that build myself, but I know it is used for OP-TEE tests for Xen. Hope this helps, Oleksandr > > Regards, > Simon [1] https://github.com/OP-TEE/manifest/blob/master/qemu_v8.xml [2] https://github.com/OP-TEE/build/tree/master/qemu_v8/xen [3] https://github.com/OP-TEE/build/blob/master/qemu_v8/xen/guest.cfg#L1
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
is generallyHi Tom,
On Fri, 3 Dec 2021 at 09:31, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> > >
> > > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > > >
> > > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > > >
> > > > > > 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.
> > > > >
> > > > > Note that I can't run-time test this as the last patch fails to apply
> > > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > > and that's part of the unchanging context where things fail to apply).
> > > >
> > > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > > -next and is at dm/ofb-working if you want to compare.
> > >
> > > I just fetch'd and built that instead, thanks.
> > >
> > > > > So, here's my first bit of confusion. Today, I build for rpi_arm64
> > > > > and
> > > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > > With your series, I see all the dtbs have been built, and dts/dt.dtb
> > > > > and
> > > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > > >
> > > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > > is basically the same as the situation with rpi3, except it uses
> > > > OF_EMBED (need to fix...)
> > >
> > > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > > .config, so I'm telling it to use the run-time device tree. It will
> > > never ever use this dtb, under any circumstance, right?
> >
> > That's right, unless you disable OF_BOARD and build U-Boot again.
>
> And then it would fail to boot, because I'm on a 3, not a 4.
Yes, but that's because the DT is wrong, right? The build builds all
the different DTs but just selects one (the default) to put into
u-boot.dtb and u-boot.bin
We could make it generate images for all of them. I have thought about
that as it stops us needing different boards just to handle having
multiple DT options. But I haven't really looked at it.
>
> > Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> > I didn't even know that...yet another example of the confusion of the
> > current state.
>
> So, I'm trying to use this example here to lead to what I think is a
> reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
> built trees, and the embedded tree, will not ever be used. But it makes
(except during development and for build testing)
> the make logic a tiny bit easier to have some tree, not no tree. Why
> can't we:
> - When CONFIG_OF_BOARD=y not build those
Re: [BUG] efi_loader: incorrect creation of device paths
On 11/25/21 06:44, 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".) -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_drv | |-- generic_bus_0_dev_2 usb_mass_s0 [ + ] usb_mass_storage | |-- usb_mass_storage blk 0 [ ] usb_storage_blk | | `-- usb_mass_storage.lun0 usb_mass_s1 [ + ] usb_mass_storage | `-- usb_mass_storage blk 1 [ ] usb_storage_blk | `-- usb_mass_storage.lun0 ... => efidebug devices Scanning disk usb_mass_storage.lun0... Scanning disk usb_mass_storage.lun0... Found 6 disks Missing RNG device for EFI_RNG_PROTOCOL ** Unable
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 09:18:27AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
> >
> > On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > > >
> > > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > > >
> > > > > 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.
> > > >
> > > > Note that I can't run-time test this as the last patch fails to apply
> > > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > > and that's part of the unchanging context where things fail to apply).
> > >
> > > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > > -next and is at dm/ofb-working if you want to compare.
> >
> > I just fetch'd and built that instead, thanks.
> >
> > > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> > >
> > > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > > is basically the same as the situation with rpi3, except it uses
> > > OF_EMBED (need to fix...)
> >
> > OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> > rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> > .config, so I'm telling it to use the run-time device tree. It will
> > never ever use this dtb, under any circumstance, right?
>
> That's right, unless you disable OF_BOARD and build U-Boot again.
And then it would fail to boot, because I'm on a 3, not a 4.
> Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
> I didn't even know that...yet another example of the confusion of the
> current state.
So, I'm trying to use this example here to lead to what I think is a
reasonable compromise. As you note, with CONFIG_OF_BOARD=y all of those
built trees, and the embedded tree, will not ever be used. But it makes
the make logic a tiny bit easier to have some tree, not no tree. Why
can't we:
- When CONFIG_OF_BOARD=y not build those trees as part of "all"
(individual rules should still work).
- For linking, use an empty minimal valid dts.
Because when CONFIG_OF_BOARD=y you will HAVE TO change the configuration
to know what device tree you want it to even use if you disable
CONFIG_OF_BOARD. You cannot assume that CONFIG_DEFAULT_DEVICE_TREE is
correct, which is why it's unset currently.
Does this make sense? If not, why not? And I have thoughts about other
platforms too, but I want to stick with a fairly concrete example first.
--
Tom
signature.asc
Description: PGP signature
Re: Issue building flash.bin for imx8mq_evk
Hi Angus, On Tue, Nov 30, 2021 at 2:40 PM Angus Ainslie wrote: > Are there binman updates for the imx8mq_evk ? Yes, Andrey has sent the following patch: https://lists.denx.de/pipermail/u-boot/2021-December/468983.html
Re: [PATCH v2] imx8mq_evk: switch board to use binman for images
Hi Andrey, On Fri, Dec 3, 2021 at 1:18 PM Andrey Zhizhikin wrote: > > Currently i.MX8MQ EVK board still targeting the old image generation > approach for image generation, which relies on the FIT generator that > has been dropped from the tree. > > Switch the board to use binman instead, which is a standard image > generator now. > > Update board documentation to correct build command, and advise latest > firmware and TF-A versions to use. > > NOTE: New image produced by binman does not have Signed HDMI FW support, > this has been left on the side and does not interfere with the general > boot flow. > > Tested on: [i.MX8MQ rev2.0] > > Signed-off-by: Andrey Zhizhikin > --- > > Changes in V2: > - Modify binman and documentation to use single flash.bin file instead > of flash.bin+u-boot.itb combination, suggested by Fabio Estevam. Thanks for the rework: Reviewed-by: Fabio Estevam
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Oleksandr, On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko wrote: > > 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 I'd like to try it out. How?? Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 08:57, Tom Rini wrote:
>
> On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> > >
> > > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> > >
> > > > 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.
> > >
> > > Note that I can't run-time test this as the last patch fails to apply
> > > and is dependent on non-trivial missing changes ("/* The devicetree is
> > > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > > and that's part of the unchanging context where things fail to apply).
> >
> > That code is the penultimate patch ("fdt: Drop remaining preprocessor
> > macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> > -next and is at dm/ofb-working if you want to compare.
>
> I just fetch'd and built that instead, thanks.
>
> > > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > > no dtb files are built. I run this on my Pi 3 and everything works.
> > > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
> >
> > Yes, so long as OF_BOARD is enabled, which it is in this series. This
> > is basically the same as the situation with rpi3, except it uses
> > OF_EMBED (need to fix...)
>
> OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
> rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
> .config, so I'm telling it to use the run-time device tree. It will
> never ever use this dtb, under any circumstance, right?
That's right, unless you disable OF_BOARD and build U-Boot again.
Oddly enough with rpi_3_32b it uses EMBED and ignores the DT provided.
I didn't even know that...yet another example of the confusion of the
current state.
Regards,
Simon
[PATCH v2] imx8mq_evk: switch board to use binman for images
Currently i.MX8MQ EVK board still targeting the old image generation
approach for image generation, which relies on the FIT generator that
has been dropped from the tree.
Switch the board to use binman instead, which is a standard image
generator now.
Update board documentation to correct build command, and advise latest
firmware and TF-A versions to use.
NOTE: New image produced by binman does not have Signed HDMI FW support,
this has been left on the side and does not interfere with the general
boot flow.
Tested on: [i.MX8MQ rev2.0]
Signed-off-by: Andrey Zhizhikin
---
Changes in V2:
- Modify binman and documentation to use single flash.bin file instead
of flash.bin+u-boot.itb combination, suggested by Fabio Estevam.
arch/arm/dts/imx8mq-evk-u-boot.dtsi | 124 ++
arch/arm/mach-imx/imx8m/Kconfig | 1 +
board/freescale/imx8mq_evk/Kconfig| 2 +-
.../imx8mq_evk/imximage-8mq-lpddr4.cfg| 9 ++
configs/imx8mq_evk_defconfig | 2 +-
doc/board/nxp/imx8mq_evk.rst | 21 +--
6 files changed, 148 insertions(+), 11 deletions(-)
create mode 100644 board/freescale/imx8mq_evk/imximage-8mq-lpddr4.cfg
diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
index 2cfc12b7e0..e3f780ca75 100644
--- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
@@ -1,5 +1,129 @@
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ spl {
+ filename = "spl.bin";
+
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before U-Boot";
+ #address-cells = <1>;
+ fit,external-offset = ;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+
+ uboot_blob: blob-ext {
+ filename = "u-boot-nodtb.bin";
+ };
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x91>;
+ entry = <0x91>;
+
+ atf_blob: blob-ext {
+ filename = "bl31.bin";
+ };
+ };
+
+ fdt {
+ description = "NAME";
+ type = "flat_dt";
+ compression = "none";
+
+ uboot_fdt_blob: blob-ext {
+ filename = "u-boot.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf";
+
+ conf {
+ description = "NAME";
+
Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot
Hi Tom, On Fri, 3 Dec 2021 at 09:02, Tom Rini wrote: > > On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote: > > > Add a means of testing a coreboot + U-Boot build using qemu. > > > > Signed-off-by: Simon Glass > > --- > > As to what to do with people's labs, I think applying these patches does > > encourage them and provide people with examples. Having 'no mainline' for > > these is going to be an impediment I think. > > > > Changes in v2: > > - Drop the ellesmere symlink > > > > bin/travis-ci/conf.coreboot_qemu | 28 > > 1 file changed, 28 insertions(+) > > create mode 100644 bin/travis-ci/conf.coreboot_qemu > > So, now we have the conf, for something 100% virtual, in bin/travis-ci > (which yes, ugh, bad name). If we had a top-level README.rst how would > it be unclear that this is a functional example? In fact, maybe we > should clear something up. How does the network test work for you? I > have to modify them to pass -tftp=/tftpboot so that I can then give it > things like helloworld.efi and appropriate grub.efi. Are you using some > wrapper to make things look more like what CI does? I haven't tried the network tests, actually. Mostly I run individual tests or just boot to a prompt and try things out. One day I would like to get labman closer to making this automatic. Regards, Simon
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
On 12/3/21 08:16, AKASHI Takahiro wrote: 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 We don't need the partition-table to be a udevice now. We still can later convert the partition drivers to a uclass if we deem it helpful. Best regards Heinrich -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: [PATCH v2] RFC: gitlab: x86: Add a coreboot test
On Fri, Dec 03, 2021 at 08:47:55AM -0700, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 08:00, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 07:26:21PM -0700, Simon Glass wrote: > > > > > 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 > > > > We should build coreboot in the Dockerfile like we do grub and so forth, > > then not have to worry about the toolchain things since it's just a > > one-time cost to me (or anyone else doing docker build). > > OK...it does take an age though, since it builds various toolchains > before it will even build coreboot. I'm going to talk to them about > why they can't use 'normal' toolchains. Anyway, I'll add it in and see > how it looks. > > Do you want me to try the DockerFile thing first, or is having a > download OK for now? What do you think about doing a docker thing for > nikia_rx51 ? For coreboot, lets see what the feedback you get is, and we can deal with adding the test soon like this I suppose. For nokia_rx51, I assume you mean building qemu and I'm not sure we can without making the test more fragile for non-CI? It doesn't tend to be much of a bottleneck so I'd rather not tweak it further. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Tom, On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > > 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 > > I want to cycle back over here. Yes, historically a number of things > came in that perhaps shouldn't have. I went with "well, this is what we > need to handle this case I suppose" and applied it. Yes and we need to move things forward. We can't just object to things without an alternative. As I have mentioned before, I think, I did actually review this (there was a question about sequence numbers or something) and didn't even notice the devicetree thing! It should have been a separate patch, I suppose. But even with the other patch (OF_BOARD), I did not at the time understand the implications. I feel very bad about the situation we are in and I wish I had thought it through properly at the time. Mea culpa. Regards, Simon
Re: [u-boot-test-hooks PATCH v2] travis-ci: Add tests for booting from coreboot
On Fri, Dec 03, 2021 at 08:52:38AM -0700, Simon Glass wrote: > Add a means of testing a coreboot + U-Boot build using qemu. > > Signed-off-by: Simon Glass > --- > As to what to do with people's labs, I think applying these patches does > encourage them and provide people with examples. Having 'no mainline' for > these is going to be an impediment I think. > > Changes in v2: > - Drop the ellesmere symlink > > bin/travis-ci/conf.coreboot_qemu | 28 > 1 file changed, 28 insertions(+) > create mode 100644 bin/travis-ci/conf.coreboot_qemu So, now we have the conf, for something 100% virtual, in bin/travis-ci (which yes, ugh, bad name). If we had a top-level README.rst how would it be unclear that this is a functional example? In fact, maybe we should clear something up. How does the network test work for you? I have to modify them to pass -tftp=/tftpboot so that I can then give it things like helloworld.efi and appropriate grub.efi. Are you using some wrapper to make things look more like what CI does? -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: usage: Fix command in fdt overlay apply sequence
On 12/3/21 15:46, Alexander Dahl wrote:
Literally adhering to the docs gave this wrong output:
U-Boot> setenv fdtaddr 0x87f0
U-Boot> fdtaddr $fdtaddr
Unknown command 'fdtaddr' - try 'help'
Fixes: d80162cfc559 ("doc: Document how to apply fdt overlays")
Signed-off-by: Alexander Dahl
Reviewed-by: Heinrich Schuchardt
---
doc/usage/fdt_overlays.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/usage/fdt_overlays.rst b/doc/usage/fdt_overlays.rst
index ea39713434..7f113edae3 100644
--- a/doc/usage/fdt_overlays.rst
+++ b/doc/usage/fdt_overlays.rst
@@ -102,7 +102,7 @@ Manually Loading and Applying Overlays
::
-=> fdtaddr $fdtaddr
+=> fdt addr $fdtaddr
4. Grow it enough so it can encompass all applied overlays
base-commit: 5b9ee01685290653671072d0030cd7ba9da3a705
RE: [PATCH] imx8mq_evk: switch board to use binman for images
Hello Fabio,
> -Original Message-
> From: Fabio Estevam
> Sent: Friday, December 3, 2021 4:54 PM
> To: ZHIZHIKIN Andrey
> Cc: U-Boot-Denx ; Stefano Babic ;
> dl-uboot-
> imx ; Peng Fan ; Heiko Schocher
> ; Teresa Remmet ; Jagan Teki
> ; Marcel Ziswiler ;
> Ilko
> Iliev ; Heinrich Schuchardt
> Subject: Re: [PATCH] imx8mq_evk: switch board to use binman for images
>
>
> Hi Andrey,
>
> Thanks for the patch.
>
> On Fri, Dec 3, 2021 at 12:30 PM Andrey Zhizhikin
> wrote:
>
> > -Burn the flash.bin to MicroSD card offset 33KB:
> > +Burn the flash.bin (offset 33KB) and u-boot.itb (offset 384KB) to MicroSD
> card:
>
> Could you please use the single flash.bin approach here too?
>
> Please see commit:
> 028abfd9b157 ("imx8mm-evk: Generate a single bootable flash.bin again")
Sure thing! Thanks for pointing this out, I do remember there has
been quite a discussion regarding this point, but I totally missed
what was the outcome. Now I can see it in this commit quite clear. :)
I'll change the binman DT node now and push a V2.
>
> Thanks
-- andrey
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 08:39:34AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
> >
> > On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> >
> > > 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.
> >
> > Note that I can't run-time test this as the last patch fails to apply
> > and is dependent on non-trivial missing changes ("/* The devicetree is
> > typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> > and that's part of the unchanging context where things fail to apply).
>
> That code is the penultimate patch ("fdt: Drop remaining preprocessor
> macros in fdtdec_setup()"). Did that patch apply OK? It is based on
> -next and is at dm/ofb-working if you want to compare.
I just fetch'd and built that instead, thanks.
> > So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> > no dtb files are built. I run this on my Pi 3 and everything works.
> > With your series, I see all the dtbs have been built, and dts/dt.dtb and
> > u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
>
> Yes, so long as OF_BOARD is enabled, which it is in this series. This
> is basically the same as the situation with rpi3, except it uses
> OF_EMBED (need to fix...)
OK, so my Pi 3 still boots on rpi_arm64, good. But why did I embed a
rpi4 device tree to u-boot.bin ? CONFIG_OF_BOARD=y is set in the
.config, so I'm telling it to use the run-time device tree. It will
never ever use this dtb, under any circumstance, right?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] imx8mq_evk: switch board to use binman for images
Hi Andrey,
Thanks for the patch.
On Fri, Dec 3, 2021 at 12:30 PM Andrey Zhizhikin
wrote:
> -Burn the flash.bin to MicroSD card offset 33KB:
> +Burn the flash.bin (offset 33KB) and u-boot.itb (offset 384KB) to MicroSD
> card:
Could you please use the single flash.bin approach here too?
Please see commit:
028abfd9b157 ("imx8mm-evk: Generate a single bootable flash.bin again")
Thanks
[u-boot-test-hooks PATCH v2] 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
---
As to what to do with people's labs, I think applying these patches does
encourage them and provide people with examples. Having 'no mainline' for
these is going to be an impediment I think.
Changes in v2:
- Drop the ellesmere symlink
bin/travis-ci/conf.coreboot_qemu | 28
1 file changed, 28 insertions(+)
create mode 100644 bin/travis-ci/conf.coreboot_qemu
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 v2] RFC: gitlab: x86: Add a coreboot test
Hi Tom, On Fri, 3 Dec 2021 at 08:00, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 07:26:21PM -0700, Simon Glass wrote: > > > 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 > > We should build coreboot in the Dockerfile like we do grub and so forth, > then not have to worry about the toolchain things since it's just a > one-time cost to me (or anyone else doing docker build). OK...it does take an age though, since it builds various toolchains before it will even build coreboot. I'm going to talk to them about why they can't use 'normal' toolchains. Anyway, I'll add it in and see how it looks. Do you want me to try the DockerFile thing first, or is having a download OK for now? What do you think about doing a docker thing for nikia_rx51 ? Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Fri, 3 Dec 2021 at 08:14, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: > > [snip] > > So now we find out the full horror of the fragmented mess that things > > are to become. No way does this make sense. > > > > It is already too hard to build things. Just look at the meson/binman > > series I sent last week. We need to make things easier for people, not > > harder. > > I think this gets at one of my points. It seems exceedingly unlikely to > me that every semi vendor is going to stop making their own tooling and > per SoC requirements here and instead converge on a common one. I feel > like that's not even true in x86, but it's largely just Intel or AMD > rather than a handful of vendors. I see places we can make change > happen and places we're going to have to use what we're given. Unless > Arm Ltd pushes something, every semi gets to "innovate" in this area up > until the point where SystemReady (well, the underlying specifications) > say you MUST do X. Yes, I think you are right. So I think the best we can do for now is describe the image and the tools needed to make it, leaving the user to collect the required binaries and tools that are needed, repeating until binman stops saying 'missing external blobs'. BTW binman does have a way to show help for how to get each blob (tools/binman/missing-blob-help) and I plan to do the same for tools when I respin the meson series. For x86, Intel tools have ended up open source over time, e.g. under the influence of Chrome OS. I am less sure on the AMD side though, but will check that and push there if needed. I'd suggest that Arm should require the tools to be open-source. I will make that point next time I have a chance. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Fri, 3 Dec 2021 at 07:55, Tom Rini wrote:
>
> On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
>
> > 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.
>
> Note that I can't run-time test this as the last patch fails to apply
> and is dependent on non-trivial missing changes ("/* The devicetree is
> typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> and that's part of the unchanging context where things fail to apply).
That code is the penultimate patch ("fdt: Drop remaining preprocessor
macros in fdtdec_setup()"). Did that patch apply OK? It is based on
-next and is at dm/ofb-working if you want to compare.
>
> So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> no dtb files are built. I run this on my Pi 3 and everything works.
> With your series, I see all the dtbs have been built, and dts/dt.dtb and
> u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
Yes, so long as OF_BOARD is enabled, which it is in this series. This
is basically the same as the situation with rpi3, except it uses
OF_EMBED (need to fix...)
If we get as far as the std passage stuff then it will print out the
source of the DT when it starts. If you like I could move three
patches into this series:
f88bd6a431a (HEAD -> ofb6) dm: core: Allow getting some basic stats
8121102a004 passage: Report the devicetree source
c9c791ddedf passage: Record where the devicetree came from
5a0b7505498 (dm/ofb-working, dm-public/ofb-working) fdt: Don't call
board_fdt_blob_setup() without OF_BOARD
Booting with rpi3 and rpi4 I get (see the "devicetree:" bit):
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:32:41 -0700)
DRAM: 992 MiB
RPI 3 Model B (0xa02082)
Core: 61 devices, 11 uclasses, devicetree: embed
MMC: mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In:serial
Out: vidconsole
Err: vidconsole
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:33:43 -0700)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
Core: 197 devices, 13 uclasses, devicetree: board
MMC: mmcnr@7e30: 1, mmc@7e34: 0
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In:serial
Out: vidconsole
Regards,
Simon
[PATCH] imx8mq_evk: switch board to use binman for images
Currently i.MX8MQ EVK board still targeting the old image generation
approach for image generation, which relies on the FIT generator that
has been dropped from the tree.
Switch the board to use binman instead, which is a standard image
generator now.
Update board documentation to correct build command, and advise latest
firmware and TF-A versions to use.
NOTE: New image produced by binman does not have Signed HDMI FW support,
this has been left on the side and does not interfere with the general
boot flow.
Tested on: [i.MX8MQ rev2.0]
Signed-off-by: Andrey Zhizhikin
---
arch/arm/dts/imx8mq-evk-u-boot.dtsi | 107 ++
arch/arm/mach-imx/imx8m/Kconfig | 1 +
board/freescale/imx8mq_evk/Kconfig| 2 +-
.../imx8mq_evk/imximage-8mq-lpddr4.cfg| 9 ++
configs/imx8mq_evk_defconfig | 2 +-
doc/board/nxp/imx8mq_evk.rst | 24 ++--
6 files changed, 133 insertions(+), 12 deletions(-)
create mode 100644 board/freescale/imx8mq_evk/imximage-8mq-lpddr4.cfg
diff --git a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
index 2cfc12b7e0..a602ae55eb 100644
--- a/arch/arm/dts/imx8mq-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mq-evk-u-boot.dtsi
@@ -1,5 +1,112 @@
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ flash {
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before U-Boot";
+ #address-cells = <1>;
+ fit,external-offset = ;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+
+ uboot_blob: blob-ext {
+ filename = "u-boot-nodtb.bin";
+ };
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x91>;
+ entry = <0x91>;
+
+ atf_blob: blob-ext {
+ filename = "bl31.bin";
+ };
+ };
+
+ fdt {
+ description = "NAME";
+ type = "flat_dt";
+ compression = "none";
+
+ uboot_fdt_blob: blob-ext {
+ filename = "u-boot.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf";
+
+ conf {
+ description = "NAME";
+ firmware = "uboot";
+ loadables = "atf";
+ fdt = "fdt";
+ };
+
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 03:55:03PM -0700, Simon Glass wrote: [snip] > So now we find out the full horror of the fragmented mess that things > are to become. No way does this make sense. > > It is already too hard to build things. Just look at the meson/binman > series I sent last week. We need to make things easier for people, not > harder. I think this gets at one of my points. It seems exceedingly unlikely to me that every semi vendor is going to stop making their own tooling and per SoC requirements here and instead converge on a common one. I feel like that's not even true in x86, but it's largely just Intel or AMD rather than a handful of vendors. I see places we can make change happen and places we're going to have to use what we're given. Unless Arm Ltd pushes something, every semi gets to "innovate" in this area up until the point where SystemReady (well, the underlying specifications) say you MUST do X. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, > > > > > > > > > > > > > > > > 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. > > > > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > > before the first usage of the devicetree to initialize devices (there > > > are some that are initialized before relocation). > > > > Thanks for digging this up. Tbh I misunderstood the original mail from > > Mark. When I read pre-reloc I assumed no C environment was up yet. > > However this raises a few questions. > > 1. The .dtbos will need to be embedded in the u-boot binary since > > there's no FS access (or in some cases storage access to begin with) > > 2. The RAM we have is going to be limited if we want to apply the overlays > > before consoles etc are up, since it basically has to happen at some point > > near 'fdtdec_setup' > > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think > > of > > the same hardware with different configuration. You'll be able to use the > > same binary, if you can somehow configure which overlays you want to apply. > > This has come up before and the answer has been "doing it this early > will be too large" where large can mean either of .text space (we have > many constrained platforms) or memory usage (this is before DRAM > potentially). It's also on the flip side one of those places where > maybe it's less of a problem on arm64 (where prior stages will have > initialized much already) than arm32 (where we are very early) and other > platforms. And we need solutions that work for both cases. So I have an answer on my (3).a We can use the bloblist for that. We could do something along the lines of 1. Include .dtbos in u-boot source 2. Standardize the bloblist handover discussion we had across bootloaders, so that the bloblist contains information of what .dtbos to apply. We can even take it a step further and request specific .dtbos to be applied before/after DRAM init to save some boards from the DRAM issue. 3. U-Boot applies the .dtbos on the fly. What's more interesting is that looking around what we currently have, the renesas RCAR platform is already doing something *very* similar [1]. [1] board/renesas/rcar-common/common.c -> fdtdec_board_setup Cheers /Ilias > > -- > Tom
Re: [PATCH v2] RFC: gitlab: x86: Add a coreboot test
On Thu, Dec 02, 2021 at 07:26:21PM -0700, Simon Glass wrote: > 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 We should build coreboot in the Dockerfile like we do grub and so forth, then not have to worry about the toolchain things since it's just a one-time cost to me (or anyone else doing docker build). -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
> 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.
Note that I can't run-time test this as the last patch fails to apply
and is dependent on non-trivial missing changes ("/* The devicetree is
typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
and that's part of the unchanging context where things fail to apply).
So, here's my first bit of confusion. Today, I build for rpi_arm64 and
no dtb files are built. I run this on my Pi 3 and everything works.
With your series, I see all the dtbs have been built, and dts/dt.dtb and
u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
--
Tom
signature.asc
Description: PGP signature
[PATCH] doc: usage: Fix command in fdt overlay apply sequence
Literally adhering to the docs gave this wrong output:
U-Boot> setenv fdtaddr 0x87f0
U-Boot> fdtaddr $fdtaddr
Unknown command 'fdtaddr' - try 'help'
Fixes: d80162cfc559 ("doc: Document how to apply fdt overlays")
Signed-off-by: Alexander Dahl
---
doc/usage/fdt_overlays.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/usage/fdt_overlays.rst b/doc/usage/fdt_overlays.rst
index ea39713434..7f113edae3 100644
--- a/doc/usage/fdt_overlays.rst
+++ b/doc/usage/fdt_overlays.rst
@@ -102,7 +102,7 @@ Manually Loading and Applying Overlays
::
-=> fdtaddr $fdtaddr
+=> fdt addr $fdtaddr
4. Grow it enough so it can encompass all applied overlays
base-commit: 5b9ee01685290653671072d0030cd7ba9da3a705
--
2.30.2
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Fri, Dec 03, 2021 at 04:30:40PM +0200, Ilias Apalodimas wrote: > Hi Heinrich, > > On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > > On 12/3/21 11:27, Mark Kettenis wrote: > > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > > From: Ilias Apalodimas > > > > > > > > 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. > > > > > Applying a devicetree overlay can be implemented in common/board_f.c > > before the first usage of the devicetree to initialize devices (there > > are some that are initialized before relocation). > > Thanks for digging this up. Tbh I misunderstood the original mail from > Mark. When I read pre-reloc I assumed no C environment was up yet. > However this raises a few questions. > 1. The .dtbos will need to be embedded in the u-boot binary since > there's no FS access (or in some cases storage access to begin with) > 2. The RAM we have is going to be limited if we want to apply the overlays > before consoles etc are up, since it basically has to happen at some point > near 'fdtdec_setup' > 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of > the same hardware with different configuration. You'll be able to use the > same binary, if you can somehow configure which overlays you want to apply. This has come up before and the answer has been "doing it this early will be too large" where large can mean either of .text space (we have many constrained platforms) or memory usage (this is before DRAM potentially). It's also on the flip side one of those places where maybe it's less of a problem on arm64 (where prior stages will have initialized much already) than arm32 (where we are very early) and other platforms. And we need solutions that work for both cases. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Heinrich, On Fri, Dec 03, 2021 at 02:59:44PM +0100, Heinrich Schuchardt wrote: > On 12/3/21 11:27, Mark Kettenis wrote: > > > Date: Fri, 3 Dec 2021 09:50:44 +0200 > > > From: Ilias Apalodimas > > > > > > 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. > > Applying a devicetree overlay can be implemented in common/board_f.c > before the first usage of the devicetree to initialize devices (there > are some that are initialized before relocation). Thanks for digging this up. Tbh I misunderstood the original mail from Mark. When I read pre-reloc I assumed no C environment was up yet. However this raises a few questions. 1. The .dtbos will need to be embedded in the u-boot binary since there's no FS access (or in some cases storage access to begin with) 2. The RAM we have is going to be limited if we want to apply the overlays before consoles etc are up, since it basically has to happen at some point near 'fdtdec_setup' 3.Are we are going to need some logic on how to apply the .dtbos? E.g think of the same hardware with different configuration. You'll be able to use the same binary, if you can somehow configure which overlays you want to apply. Thanks /Ilias > > > > > > > > > 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... > > Linux will silently ignore any node for which it does not have a > compatible string. So application of an overlay once in U-Boot is > sufficient. > > Best regards > > Heinrich > > > > > > > Last time we said we don't really have to remove them, but I get the > > > point. > > > > Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > > > > > 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
Re: [u-boot-test-hooks PATCH] travis-ci: Add tests for booting from coreboot
On Thu, Dec 02, 2021 at 07:05:47PM -0700, Simon Glass wrote: > 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 Please just include this in travis-ci. I'm not exactly sure of the best way to handle the existing deployment dirs and turn them in to examples for others, without breaking existing deployments, but I don't want to add to this problem. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On 12/3/21 11:27, Mark Kettenis wrote: Date: Fri, 3 Dec 2021 09:50:44 +0200 From: Ilias Apalodimas 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. Applying a devicetree overlay can be implemented in common/board_f.c before the first usage of the devicetree to initialize devices (there are some that are initialized before relocation). 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... Linux will silently ignore any node for which it does not have a compatible string. So application of an overlay once in U-Boot is sufficient. Best regards Heinrich Last time we said we don't really have to remove them, but I get the point. Ah, when I said "pull it out" I meant "read it back"; not "delete it". 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
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
On 12/3/21 13:34, Heinrich Schuchardt wrote: On 12/2/21 16:58, Simon Glass wrote: At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass Reviewed-by: Marcel Ziswiler --- This patch attracted quite a bit of discussion here: https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write. The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now. 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 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 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 on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' doc/develop/devicetree/dt_update.rst | 555 +++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 556 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 000..a1429d6e21a --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,555 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this Even if you remove these lines in 17/25 I would prefer not to introduce typos here: %s/linst/list/ + was only discovered after weeks of
Re: [PATCH v3] xilinx: Kconfig: add XILINX_OF_BOARD_DTB_ADDR default value for microblaze
On 12/2/21 20:56, Ovidiu Panait wrote: 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 Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
On 12/2/21 16:58, Simon Glass wrote: At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass Reviewed-by: Marcel Ziswiler --- This patch attracted quite a bit of discussion here: https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write. The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now. 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 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 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 on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' doc/develop/devicetree/dt_update.rst | 555 +++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 556 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 000..a1429d6e21a --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,555 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this Even if you remove these lines in 17/25 I would prefer not to introduce typos here: %s/linst/list/ + was only discovered after weeks of discussion and confusion + +- For QEMU specifically,
Re: [PATCH 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
On Fri, Dec 3, 2021 at 3:32 AM Simon Glass wrote: > > 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. So are there docs for how do this? I didn't manage to find any, although the docs I find can be a little over the place in U-Boot so they may be there and I missed them, so either way docs would be fab.
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
On Thu, Dec 2, 2021 at 6:26 PM Simon Glass wrote: > > 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. Should probably just get the original one from their upstream source repo then rather than decompiling it.
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > 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 I want to cycle back over here. Yes, historically a number of things came in that perhaps shouldn't have. I went with "well, this is what we need to handle this case I suppose" and applied it. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v3 7/8] mkimage: add public key for image pre-load stage
Hi Simon, Le 25/11/2021 à 01:13, Simon Glass a écrit : Hi Philippe, On Wed, 17 Nov 2021 at 10:52, Philippe Reynes wrote: This commit enhances mkimage to update the node /image/pre-load/sig with the public key. Signed-off-by: Philippe Reynes --- include/image.h| 15 ++ tools/fit_image.c | 3 ++ tools/image-host.c | 116 + 3 files changed, 134 insertions(+) I'm a bit unsure about the format of the key here. Is it different from the normal one used by U-Boot? The format used by pkey is the der format without the first 24 bytes. For example, to create this key in a shell, I use the following commands : openssl rsa -in private.pem -pubout -outform der -out public.der dd if=public.der of=public.raw bs=24 skip=1 As described in the comment line 340 in the file test/lib/asn1.c. Regards, Simon Regards, Philippe -- This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome’s ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> Date: Fri, 3 Dec 2021 09:50:44 +0200 > From: Ilias Apalodimas > > 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. Ah, when I said "pull it out" I meant "read it back"; not "delete it". > > 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
Re: [PATCH v2 03/14] clk: mtmips: add clock driver for MediaTek MT7621 SoC
On Fri, 2021-11-26 at 12:44 -0500, Sean Anderson wrote:
> On 11/18/21 8:35 PM, Weijie Gao wrote:
> > This patch adds a clock driver for MediaTek MT7621 SoC.
> > This driver provides clock gate control as well as getting clock
> > frequency
> > for CPU/SYS/XTAL and some peripherals.
> >
> > Signed-off-by: Weijie Gao
> > ---
> > v2 changes: none
> > ---
> > drivers/clk/mtmips/Makefile| 1 +
> > drivers/clk/mtmips/clk-mt7621.c| 260
> > +
> > include/dt-bindings/clock/mt7621-clk.h | 42
> > 3 files changed, 303 insertions(+)
> > create mode 100644 drivers/clk/mtmips/clk-mt7621.c
> > create mode 100644 include/dt-bindings/clock/mt7621-clk.h
> >
> > diff --git a/drivers/clk/mtmips/Makefile
> > b/drivers/clk/mtmips/Makefile
> > index 732e7f2545..ee8b5afe87 100644
> > --- a/drivers/clk/mtmips/Makefile
> > +++ b/drivers/clk/mtmips/Makefile
> > @@ -1,4 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > obj-$(CONFIG_SOC_MT7620) += clk-mt7620.o
> > +obj-$(CONFIG_SOC_MT7621) += clk-mt7621.o
> > obj-$(CONFIG_SOC_MT7628) += clk-mt7628.o
> > diff --git a/drivers/clk/mtmips/clk-mt7621.c
> > b/drivers/clk/mtmips/clk-mt7621.c
> > new file mode 100644
> > index 00..3799d1806a
> > --- /dev/null
> > +++ b/drivers/clk/mtmips/clk-mt7621.c
> > @@ -0,0 +1,260 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2021 MediaTek Inc. All Rights Reserved.
> > + *
> > + * Author: Weijie Gao
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define SYSC_MAP_SIZE 0x100
> > +#define MEMC_MAP_SIZE 0x1000
> > +
> > +/* SYSC */
> > +#define SYSCFG0_REG0x10
> > +#define XTAL_MODE_SEL_S6
> > +#define XTAL_MODE_SEL_M0x1c0
>
> Please use genmask to define this:
>
> #define XTAL_MODE_SEL_M GENMASK(8, 6)
>
> and SEL_S is unnecessary, see commentary below.
>
> > +
> > +#define CLKCFG0_REG0x2c
> > +#define CPU_CLK_SEL_S 30
> > +#define CPU_CLK_SEL_M 0xc000
> > +#define PERI_CLK_SEL 0x10
> > +
> > +#define CLKCFG1_REG0x30
> > +
> > +#define CUR_CLK_STS_REG0x44
> > +#define CUR_CPU_FDIV_S 8
> > +#define CUR_CPU_FDIV_M 0x1f00
> > +#define CUR_CPU_FFRAC_S0
> > +#define CUR_CPU_FFRAC_M0x1f
> > +
> > +/* MEMC */
> > +#define MEMPLL1_REG0x0604
> > +#define RG_MEPL_DIV2_SEL_S 1
> > +#define RG_MEPL_DIV2_SEL_M 0x06
> > +
> > +#define MEMPLL6_REG0x0618
> > +#define MEMPLL18_REG 0x0648
> > +#define RG_MEPL_PREDIV_S 12
> > +#define RG_MEPL_PREDIV_M 0x3000
> > +#define RG_MEPL_FBDIV_S4
> > +#define RG_MEPL_FBDIV_M0x7f0
> > +
> > +/* Clock sources */
> > +#define CLK_SRC_CPU-1
> > +#define CLK_SRC_CPU_D2 -2
> > +#define CLK_SRC_DDR-3
> > +#define CLK_SRC_SYS-4
> > +#define CLK_SRC_XTAL -5
> > +#define CLK_SRC_PERI -6
>
> Please use an enum. And why are these negative?
I'll rewrite this
>
> > +/* EPLL clock */
> > +#define EPLL_CLK 5000
> > +
> > +struct mt7621_clk_priv {
> > + void __iomem *sysc_base;
> > + void __iomem *memc_base;
> > + int cpu_clk;
> > + int ddr_clk;
> > + int sys_clk;
> > + int xtal_clk;
> > +};
> > +
> > +static const int mt7621_clks[] = {
> > + [CLK_SYS] = CLK_SRC_SYS,
> > + [CLK_DDR] = CLK_SRC_DDR,
> > + [CLK_CPU] = CLK_SRC_CPU,
> > + [CLK_XTAL] = CLK_SRC_XTAL,
> > + [CLK_MIPS_CNT] = CLK_SRC_CPU_D2,
> > + [CLK_UART3] = CLK_SRC_PERI,
> > + [CLK_UART2] = CLK_SRC_PERI,
> > + [CLK_UART1] = CLK_SRC_PERI,
> > + [CLK_SPI] = CLK_SRC_SYS,
> > + [CLK_I2C] = CLK_SRC_PERI,
> > + [CLK_TIMER] = CLK_SRC_PERI,
> > +};
> > +
> > +static ulong mt7621_clk_get_rate(struct clk *clk)
> > +{
> > + struct mt7621_clk_priv *priv = dev_get_priv(clk->dev);
> > + u32 val;
> > +
> > + if (clk->id >= ARRAY_SIZE(mt7621_clks))
> > + return 0;
> > +
> > + switch (mt7621_clks[clk->id]) {
> > + case CLK_SRC_CPU:
> > + return priv->cpu_clk;
> > + case CLK_SRC_CPU_D2:
> > + return priv->cpu_clk / 2;
> > + case CLK_SRC_DDR:
> > + return priv->ddr_clk;
> > + case CLK_SRC_SYS:
> > + return priv->sys_clk;
> > + case CLK_SRC_XTAL:
> > + return priv->xtal_clk;
> > + case CLK_SRC_PERI:
> > + val = readl(priv->sysc_base + CLKCFG0_REG);
> > + if (val & PERI_CLK_SEL)
> > + return
Re: [PATCH 00/15] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
Hi Priyanka, On Thu, Dec 02, 2021 at 04:53:54PM +0200, Vladimir Oltean wrote: > The changes were intended to be minimal, but unfortunately I discovered > some other stuff as well: > - we need to make some changes to the compatible strings of RTC devices > and I2C muxes. This has ramifications to other NXP boards which were > also updated. > - I broke Ethernet on LS1028A boards through a patch that is currently > in Ramon's tree. > > Therefore this patch set is a bit larger than would be otherwise > expected. > > The Linux device tree changes have just been posted by me here and are > currently in flight, but they are rather small so I don't expect too > much pushback on them: > https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395 > > Cc: Heiko Schocher > Cc: Simon Glass > Cc: Ramon Fried > > Vladimir Oltean (15): > i2c: muxes: pca954x: add PCA9847 variant > rtc: pcf2127: sync with Linux compatible strings > arm: dts: ls1028a-qds: use Linux compatible string for RTC > arm: ls1088a-qds: use Linux compatible string for RTC > arm: ls1088a-rdb: use Linux compatible string for RTC > arm: lx2160a-qds: use Linux compatible string for RTC > arm: dts: lx2160a-rdb: use Linux compatible string for RTC > rtc: pcf2127: remove U-Boot specific compatible string > arm: dts: ls1028a-rdb: sort nodes alphabetically > arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux > arm: dts: ls1028a-rdb: disable DSPI nodes > arm: dts: ls1028a-rdb: disable I2C buses 1 through 7 > arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi > arm: dts: ls1028a-rdb: sync device tree with Linux > arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports > > .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 1 + > .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 1 + > .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 + > .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 4 + > .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 + > .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4 + > arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +- > arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi | 14 + > arch/arm/dts/fsl-ls1028a-rdb.dts | 295 -- > arch/arm/dts/fsl-ls1088a-qds.dtsi | 2 +- > arch/arm/dts/fsl-ls1088a-rdb.dts | 2 +- > arch/arm/dts/fsl-lx2160a-qds.dtsi | 2 +- > arch/arm/dts/fsl-lx2160a-rdb.dts | 2 +- > drivers/i2c/muxes/pca954x.c | 9 +- > drivers/rtc/pcf2127.c | 4 +- > 15 files changed, 241 insertions(+), 109 deletions(-) > create mode 100644 arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi > > -- > 2.25.1 > There is a slight sense of urgency to these patches, especially "arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux" and "arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports", since these fix broken networking on LS1028A boards. I would therefore be very appreciative if you could review the changes soon.
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On 12/2/21 17:50, Simon Glass wrote: Hi Heinrich, On Thu, 2 Dec 2021 at 09:47, Heinrich Schuchardt wrote: On 12/2/21 16:58, Simon Glass wrote: 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. Distros like Ubuntu are provided as preinstalled images using U-Boot to launch Linux for usage with QEMU. A single image must be able to be usable in the future irrespective of the QEMU command line device configuration. This means that the devicetree coming from QEMU must be accurately parsed in U-Boot to setup the UEFI memory map. The number and type of CPUs and the NUMA configuration must be accurate. All devices enabled via the QEMU command line must be visible in the device-tree of Linux. Please, observe that information like number of CPU cores, number and type of block devices, namespace IDs used for NVMe drives, etc. cannot be available at build time. It this all guaranteed with this series? If not, this would unfortunately imply a NAK. Yes, it is guaranteed and there is no change there. Compiling qemu_arm64_defconfig yields dtbdump.efi. I used this to dump the devicetree exposed to UEFI binaries. The number of CPUs and the memory size matches the call parameters of QEMU. Emulated devices like SCSI and NVMe drives and TPMv2 work inside U-Boot. I also tested: * qemu-riscv64_smode_defconfig as fw_jump payload for OpenSBI * qemu-riscv64_spl_defconfig and found no issues. Tested-by: Heinrich Schuchardt
[PATCH] mtd: cfi_mtd: populate mtd->dev with flash_info->dev
Populate mtd->dev with flash_info->dev which allows to get full mtd information using the "mtd list" command. Before, "mtd list" command returns : List of MTD devices: * nor0 - type: NOR flash - block size: 0x4 bytes - min I/O: 0x1 bytes - 0x-0x0400 : "nor0" After this patch we get for example: List of MTD devices: * nor0 - device: flash@0 - parent: spi@4043 - driver: cfi_flash - path: /soc/spi@4043/flash@0 - type: NOR flash - block size: 0x4 bytes - min I/O: 0x1 bytes - 0x-0x0400 : "nor0" Signed-off-by: Patrice Chotard --- drivers/mtd/cfi_mtd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mtd/cfi_mtd.c b/drivers/mtd/cfi_mtd.c index 2295bb7220..1475461a59 100644 --- a/drivers/mtd/cfi_mtd.c +++ b/drivers/mtd/cfi_mtd.c @@ -221,6 +221,9 @@ int cfi_mtd_init(void) continue; sprintf(cfi_mtd_names[i], "nor%d", i); +#ifdef CONFIG_CFI_FLASH + mtd->dev= fi->dev; +#endif mtd->name = cfi_mtd_names[i]; mtd->type = MTD_NORFLASH; mtd->flags = MTD_CAP_NORFLASH; -- 2.17.1
RE: a question about falcon mode
Hi, Alex and Abder,
Thank you for the comments.
Those will be a good hint for me (especially CONFIG_SPL_RAM_SUPPORT , using FIT
image etc..) in reading the document and doing the experiment later.
Best regards
Chan
> -Original Message-
> From: Abder
> Sent: Wednesday, December 1, 2021 9:16 PM
> To: Alex G.
> Cc: Chan Kim ; U-Boot Mailing List
> Subject: Re: a question about falcon mode
>
> Hi Alex,
>
> Well yeah! I thought about that, my question was deliberately open to that
> answer too... but what I was looking for is if a dynamic capability was
> (already) implemented in the SPL for generating the fdtargs i.e., taking
> the dtb and the bootargs env variable (plus calculating the address and
> size of the initramfs if used) and putting all that info in the fdtarg
> blob just like u-boot does !
> But surely that also can be implemented in the SPL. I'm willing to try
> that in the near future... and eventually submit a patch for it, if
> everything goes as expected !
>
> Thanks for the reply though, and the snippet code too !
>
> Best regards
> --
> Abder
>
>
> Le lun. 29 nov. 2021 à 23:12, Alex G. a écrit :
> >
> >
> >
> > On 11/26/21 4:36 PM, Abder wrote:
> > > Hi Alex,
> > >
> > > Just a quick remarque that intrigued me:
> > >
> > > Le jeu. 25 nov. 2021 à 15:57, Alex G. a écrit :
> > >>
> > >> On 11/25/21 1:07 AM, Chan Kim wrote:
> > >>> Hello all,
> > >>>
> > >>> I'm trying to implement falcon mode for our board. Then should I
> > >>> first implement the normal mode(spl + proper)?
> > >>>
> > >>> It looks like so while I'm reading doc/README.falcon. (It says,
> > >>> after loading kernel, DT etc. I should give 'spl export' command).
> > >>>
> > >>
> > >> Falcon mode is a bit board dependent. There are a couple of ways
> > >> you could go about this.
> > >>
> > >> The first is to have an "fdtargs" partition. This is where "spl
> export"
> > >> comes in. Once you run "spl export", it will give a modified dtb at
> > >> "$fdtargsaddr". It's that DTB that you need to write to your
> > >> ftdargs partition. For example:
> > >>
> > >> > spl export fdt $loadaddr - $fdt_addr_r
> > >> > mmc write $fdtargsaddr 0x9800 0x8000
> > >>
> > >> In this example the ftdargs partition starts at sector 0x9800, and
> > >> is
> > >> 0x800 sectors long.
> > >>
> > >>
> > >> The second option is to forget about "spl export" and "fdtargs",
> > >> and package your kernel, devicetree, and overlays in a FIT
> > >> container. You'd make sure to enable SPL_LOAD_FIT_APPLY_OVERLAY.
> > >> There isn't much more to this other than the usual gotcha's with FIT
> and overlays.
> > >>
> > >
> > > Do you mean by this that the SPL has the capability to generate the
> > > "fdtargs" by it self (if we provide it with the dtb in the fitImage) ?
> > >
> > > Form my last experience with the falcon mode, I had a - not sure -
> > > conclusion that the only way to generate the "fdtargs" is by using
> > > the "spl export" command from uboot cmdline !
> > > because the reality of the fdtargs blob, as its name indicates, is
> > > not just the fdt but it has also the bootargs (inside the chosen
> > > node ) that are required by the kernel. So if you give only the DTB
> > > to the SPL it will not work - to my knowledge -, cuz the data that
> > > will be passed to the kernel needs to contain also the bootargs !
> > >
> > > Can you please confirm to me if this capability is implemented on
> > > the SPL and that we can actually forget about the "spl export"
> command ?
> >
> > It might not be obvious that an overlay can contain the "/chosen" node
> > with the appropriate bootargs:
> >
> > /dts-v1/;
> > /plugin/;
> > / {
> > fragment@1 {
> > target-path = "/chosen";
> > __overlay__ {
> > bootargs = "root=blablabla console=ttyeS0";
> > };
> > };
> > };
> >
> > > Thanks
> > > And apologies Chan for jumping on your thread,
> > >
> > >
> > > Best regards,
> > > --
> > > Abder
> > >
Re: Question/issues about i.MX6 DDR configuration
On Thu, Dec 02, 2021 at 05:56:38PM -0300, Fabio Estevam wrote: > 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. I think that this applies even with just one chip select, it is just prescribing a procedure and explicitly saying that it must be done for all the chip select in use, either 1 or 2. Not sure if this is the reason for the sporadic failures I'm debugging, what triggered my attention was that this is supposed to be needed for a more "robust" initialization, whatever that means ... Francesco
Re: Question/issues about i.MX6 DDR configuration
Hello Fabio and Michael, On Thu, Dec 02, 2021 at 09:36:44PM +0100, Michael Nazzareno Trimarchi wrote: > On Thu, Dec 2, 2021 at 9:14 PM Fabio Estevam wrote: > > On Thu, Dec 2, 2021 at 1:14 PM Francesco Dolcini > > wrote: > > > 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 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? This is my main doubt, is the bootrom loading the DCD using some logic or it is really equivalent to the raw register writing we are doing in SPL? I'm not thinking only at delays (if any), but the complete MMDC initialization flow as documented in the reference manual. > > It is just that I wanted to keep 100% in sync with the initialization > > done by the NXP hardware team. Thanks Fabio for the clarification. Francesco
Re: [PATCH 1/2] clk: cdce9xx: Convert .of_xlate to .request
On 01/12/2021 22:10, Sean Anderson wrote:
On 12/1/21 3:08 PM, Tom Rini wrote:
On Wed, Dec 01, 2021 at 02:44:02PM -0500, Sean Anderson wrote:
This xlate function just performs some checking. We can do this in
request() instead and use the default xlate.
Signed-off-by: Sean Anderson
Hi Sean,
Did you compile this? I see...
---
drivers/clk/clk-cdce9xx.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/clk-cdce9xx.c b/drivers/clk/clk-cdce9xx.c
index 6634b7b799..c15e9f210e 100644
--- a/drivers/clk/clk-cdce9xx.c
+++ b/drivers/clk/clk-cdce9xx.c
@@ -86,19 +86,13 @@ static int cdce9xx_reg_write(struct udevice *dev,
u8 addr, u8 val)
return ret;
}
-static int cdce9xx_clk_of_xlate(struct clk *clk,
- struct ofnode_phandle_args *args)
+static int cdce9xx_clk_of_request(struct clk *clk)
cdce9xx_clk_of_request here...
{
struct cdce9xx_clk_data *data = dev_get_priv(clk->dev);
- if (args->args_count != 1)
+ if (clk->id > data->chip->num_outputs)
return -EINVAL;
- if (args->args[0] > data->chip->num_outputs)
- return -EINVAL;
-
- clk->id = args->args[0];
-
return 0;
}
@@ -241,7 +235,7 @@ static const struct udevice_id
cdce9xx_clk_of_match[] = {
};
static const struct clk_ops cdce9xx_clk_ops = {
- .of_xlate = cdce9xx_clk_of_xlate,
+ .request = cdce9xx_clk_request,
but cdce9xx_clk_request here.
Other than that, looks fine to me.
-Tero
.get_rate = cdce9xx_clk_get_rate,
.set_rate = cdce9xx_clk_set_rate,
};
Adding Tero...
Thanks. Perhaps .mailmap should be updated?
--Sean
