Re: [PATCH v2] dt-bindings: mtd: Add a schema for binman
On Fri, 22 Sep 2023 13:34:15 -0600, Simon Glass wrote: > Binman[1] is a tool for creating firmware images. It allows you to > combine various binaries and place them in an output file. > > Binman uses a DT schema to describe an image, in enough detail that > it can be automatically built from component parts, disassembled, > replaced, listed, etc. > > Images are typically stored in flash, which is why this binding is > targeted at mtd. Previous discussion is at [2] [3]. > > This is only a starting point, an attempt to align on the best way to > add this to the schema. > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > [2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Use "binman" for compatible instead of "u-boot,binman" > - Significantly rework the patch > - Use make dt_binding_check DT_SCHEMA_FILES=Documentation/../partitions > > .../bindings/mtd/partitions/binman.yaml | 59 ++ > .../mtd/partitions/binman/atf-bl31.yaml | 43 + > .../bindings/mtd/partitions/binman/entry.yaml | 62 +++ > .../mtd/partitions/binman/u-boot.yaml | 43 + > .../bindings/mtd/partitions/partitions.yaml | 1 + > MAINTAINERS | 5 ++ > 6 files changed, 213 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.yaml > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman/u-boot.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.example.dtb: /example-0/binman/partition@0: failed to match any schema with compatible: ['binman,entry'] Documentation/devicetree/bindings/mtd/partitions/binman/entry.example.dtb: /example-0/binman/partition@0: failed to match any schema with compatible: ['binman,entry'] Documentation/devicetree/bindings/mtd/partitions/binman/entry.example.dtb: /example-0/binman/partition@10: failed to match any schema with compatible: ['binman,entry'] doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230922193417.1697379-1-...@chromium.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: Reading from ISO9660 in U-Boot
On 9/23/23 00:13, Simon Glass wrote: Hi Heinrich & Bin, I'd like to be able to figure out in U-Boot what OS is on a USB stick. For example, with the Ubuntu installer, I can boot it (through grub), but I cannot see how to read anything useful from the USB stick that would indicate that it is Ubuntu, what version it is, etc. Does U-Boot need an ISO9660-filesystem driver for that? Is there any other way? With Debian I can see the actual files (linux and initrd) , so it is a bit easier. Regards, SImon U-Boot only needs to support reading the ESP to boot. GRUB comes with a 9660 driver. On Ubuntu server installer images linux and initrd are in directory casper/ in the ISO9660 file-system. There is also a file dists/mantic/Release $ cat dists/mantic/Release Origin: Ubuntu Label: Ubuntu Suite: mantic Version: 23.10 Codename: mantic Date: Tue, 19 Sep 2023 23:07:01 UTC Architectures: amd64 i386 Components: main restricted Description: Ubuntu Mantic 23.10 Acquire-By-Hash: yes Best regards Heinrich
Re: Reading from ISO9660 in U-Boot
On 9/23/23 00:13, Simon Glass wrote: Hi Heinrick & Bin, I'd like to be able to figure out in U-Boot what OS is on a USB stick. For example, with the Ubuntu installer, I can boot it (through grub), but I cannot see how to read anything useful from the USB stick that would indicate that it is Ubuntu, what version it is, etc. Does U-Boot need an ISO9660-filesystem driver for that? Is there any other way? With Debian I can see the actual files (linux and initrd) , so it is a bit easier. Regards, SImon The format of the Ubuntu images depends on the architecture. Let's assume that you relate to amd64 (https://cdimage.ubuntu.com/daily-live/current/mantic-desktop-amd64.iso). This is a hybrid image, which can be either read as ISO 9660 or as a GPT partitioned image. This is the gdisk output: Number Start (sector)End (sector) Size Code Name 1 6410049451 4.8 GiB 0700 ISO9660 21004945210059487 4.9 MiB EF00 Appended2 31005948810060087 300.0 KiB 0700 Gap1 You can mount partition 2 as FAT file system in Linux: $ sudo kpartx mantic-desktop-amd64.iso -a -v [sudo] password for zfsdt: add map loop1p1 (252:4): 0 10049388 linear 7:1 64 add map loop1p2 (252:5): 0 10036 linear 7:1 10049452 add map loop1p3 (252:6): 0 600 linear 7:1 10059488 $ sudo mount /dev/mapper/loop1p2 /mnt $ mount /dev/mapper/loop1p2 on /mnt type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) The problem is upstream U-Boot is that the partition drivers are scanned alphabetically: a_efi, dos, iso If we change this to a_iso, b_efi, dos, we can read the ISO image: => host bind 0 /tmp/mantic-desktop-amd64.iso => part list host 0 Partition Map for HOST device 0 -- Partition Type: ISO Part Start Sect x Size Type 1 36844512 U-Boot 2 1004945210036512 U-Boot => ls host 0:2 EFI/ => load host 0:2 $kernel_addr_r EFI/boot/bootx64.efi 960472 bytes read in 0 ms Unfortunately the sandbox crashes when executing the EFI binary. So let't try qemu-x86_64_defconfig: qemu-system-x86_64 -m 3G -nographic -bios u-boot.rom \ -drive if=none,file=/tmp/mantic-desktop-amd64.iso,format=raw,id=VIRTIO1 \ -device virtio-blk,drive=VIRTIO1 And voilá your are in GRUB. As it does not find the /boot directory let's go to the GRUB console: grub> root=(cd0,gpt1) grub> linux /casper/vmlinuz root=/dev/vda1 efi=debug console=/dev/ttyS0 grub> initrd /casper/initrd grub> boot EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path I have no clue why it stops here. Best regards Heinrich
[PATCH 1/1] riscv: enable CONFIG_DEBUG_UART by default
Most boards don't enable the pre-console buffer. So we will not see any early messages. OpenSBI 1.3 provides us with the debug console extension that can fill this gap. For S-Mode U-Boot enable CONFIG_DEBUG_UART by default. Signed-off-by: Heinrich Schuchardt --- arch/riscv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 1c62c2345b..06fae7ebe8 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -141,6 +141,7 @@ config RISCV_MMODE config RISCV_SMODE bool "Supervisor" + imply DEBUG_UART help Choose this option to build U-Boot for RISC-V S-Mode. -- 2.40.1
Re: [PATCH 09/32] spl: Avoid an #ifdef when printing gd->malloc_ptr
Hi Tom,
On Fri, 22 Sept 2023 at 13:28, Tom Rini wrote:
>
> On Fri, Sep 22, 2023 at 12:27:36PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 21 Sept 2023 at 09:36, Tom Rini wrote:
> > >
> > > On Wed, Sep 20, 2023 at 07:03:34PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 30 Aug 2023 at 15:39, Tom Rini wrote:
> > > > >
> > > > > On Wed, Aug 30, 2023 at 12:04:40PM -0600, Simon Glass wrote:
> > > > > > Use an accessor in the header file to avoid this.
> > > > > >
> > > > > > Signed-off-by: Simon Glass
> > > > > > ---
> > > > > >
> > > > > > common/spl/spl.c | 9 +
> > > > > > include/asm-generic/global_data.h | 7 +++
> > > > > > 2 files changed, 12 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > > > > > index f0a90c280da..f5cef81000c 100644
> > > > > > --- a/common/spl/spl.c
> > > > > > +++ b/common/spl/spl.c
> > > > > > @@ -876,10 +876,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > > > > } else {
> > > > > > debug("Unsupported OS image.. Jumping
> > > > > > nevertheless..\n");
> > > > > > }
> > > > > > -#if CONFIG_VAL(SYS_MALLOC_F_LEN) &&
> > > > > > !defined(CONFIG_SPL_SYS_MALLOC_SIZE)
> > > > > > - debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > > > > gd->malloc_ptr,
> > > > > > - gd->malloc_ptr / 1024);
> > > > > > -#endif
> > > > > > + if (IS_ENABLED(CONFIG_SYS_MALLOC_F) &&
> > > > > > + !IS_ENABLED(CONFIG_SPL_SYS_MALLOC_SIZE))
> > > > > > + debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > > > > + gd_malloc_ptr(), gd_malloc_ptr() / 1024);
> > >
> > > This is not more readable. But I guess my comment was unclear as you're
> > > mixing changes here. gd_malloc_ptr() rather than gd->malloc_ptr is a
> > > wash, to me. I think one could argue it's not a helpful abstraction.
> > > but it's so that you can avoid CONFIG_VAL here, and say "if (...)" not
> > > "#if ..." here.
> >
> > Yes,
> >
> > >
> > > > > > +
> > > > > > bootstage_mark_name(get_bootstage_id(false), "end phase");
> > > > > > #ifdef CONFIG_BOOTSTAGE_STASH
> > > > > > ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> > > > > > diff --git a/include/asm-generic/global_data.h
> > > > > > b/include/asm-generic/global_data.h
> > > > > > index 8fc205ded1a..edf9ff6823f 100644
> > > > > > --- a/include/asm-generic/global_data.h
> > > > > > +++ b/include/asm-generic/global_data.h
> > > > > > @@ -573,6 +573,13 @@ static_assert(sizeof(struct global_data) ==
> > > > > > GD_SIZE);
> > > > > > #define gd_malloc_start()0
> > > > > > #define gd_set_malloc_start(val)
> > > > > > #endif
> > > > > > +
> > > > > > +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
> > > > > > +#define gd_malloc_ptr() gd->malloc_ptr
> > > > > > +#else
> > > > > > +#define gd_malloc_ptr() 0L
> > > > > > +#endif
> > > > > > +
> > > > > > /**
> > > > > > * enum gd_flags - global data flags
> > > > > > *
> > > > >
> > > > > This is another case where readability is not improved. I also have a
> > > > > bad feeling that changing that exact area had some unintended
> > > > > consequences from the compiler, that totally should not have happened.
> > > > > But maybe that was something in a similar code section instead.
> > > >
> > > > The improvement is in the C file...here we have an accessor in the
> > > > header file as has been done elsewhere.
> > > >
> > > > Do you have any more details on the problem you mention? I will align
> > > > the accessor to the struct member which should resolve it.
> > >
> > > It's unfortunately one of those cases to do a global before/after build
> > > and see if anything does or does not get tripped up. As I believe I did
> > > use CONFIG_VAL there and not a check on CONFIG_SYS_MALLOC_F itself for a
> > > reason, at the time.
> >
> > But the CONFIG_VAL symbols actually depends on CONFIG_SYS_MALLOC_F, so
> > I can't imagine what it might be. Of course if the value is 0, then
> > the 'if CONFIG_VAL()' test would fail, but to what purpose?
>
> Yes, there's been a time or two where I banged my head against the
> figurative wall trying to understand what exactly the compiler could be
> seeing as why to change something. I don't have a "reasonable"
> explanation. Readability aside, "tidy things up" changes need to be on
> their own so that their impact can be seen aside from the new
> functionality changes.
>
Ah, I see. Yes this is quite a mess. I had not noticed exactly what
was going on there. The _F suffix is not really correct, but I suppose
we want the same symbol in SPL and proper.
I will add a new patch before this one.
Regards,
Simon
Re: [PATCH] MAINTAINERS: Step up as maintainers of UniPhier SoC platform
On Fri, Sep 22, 2023 at 05:54:09PM +0900, Kunihiko Hayashi wrote: > Update maintainers for UniPhier SoC platform. > > Signed-off-by: Kunihiko Hayashi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] pico-imx7d: Remove Vanessa from MAINTAINERS
On Tue, Sep 19, 2023 at 10:39:11AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Vanessa's NXP e-mail is no longer active. > > Contacted her offline and she told me that she does not have > access to the board anymore and it is OK to remove her > from MAINTAINERS. > > Signed-off-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] drivers: mediatek: Fix error handling in mtk_i2c_do_transfer
On Fri, Sep 08, 2023 at 06:47:46PM +0200, Francois Berder wrote: > Errors were handled only if an I2C transfer timed out > and received a NACK which is very unlikely. This commit > changes the condition such that errors are handled if > an I2C transfer times out or received a NACK. > > Signed-off-by: Francois Berder > Reviewed-by: Heiko Schocher Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] configs: am65x_evm_r5_usbmsc_defconfig: Enable DWC3 wrapper for SPL
On Fri, Sep 08, 2023 at 04:33:51PM +0530, Ravi Gunasekaran wrote:
> commit 280f45d23977 ("configs: get rid of build warnings due to
> SPL_USB_DWC3_GENERIC") missed enabling DWC3 glue layer for
> usbmsc_defconfig and this broke boot from USB mass storage.
> Fix this by enabling DWC3 glue layer.
>
> Fixes: 280f45d23977 ("configs: get rid of build warnings due to
> SPL_USB_DWC3_GENERIC")
> Signed-off-by: Ravi Gunasekaran
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] net: sni_netsec: Add workaround for timeout error
On Thu, Aug 03, 2023 at 11:56:48PM +0900, Ryosuke Saito wrote: > The NETSEC GMAC occasionally falls into a weird state where > MAC_REG_DESC_SOFT_RST has never been cleared and shows errors like the > below when networking commands are issued: > > => ping 192.168.1.1 > ethernet@522d Waiting for PHY auto negotiation to complete... done > netsec_wait_while_busy: timeout > Using ethernet@522d device > > ARP Retry count exceeded; starting again > ping failed; host 192.168.1.1 is not alive > > It happens on not only 'ping' but also 'dhcp', 'tftp' and so on. > > Luckily, restarting the NETSEC GMAC and trying again seems to fix the > problematic state. So first ensure that we haven't entered the state by > checking MAC_REG_DESC_SOFT_RST to be cleared; otherwise, restarting > NETSEC/PHY and trying again would work as a workaround. > > Signed-off-by: Ryosuke Saito > Tested-By: Masahisa Kojima Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: wget: Avoid packet queue overflow
On Thu, Jul 20, 2023 at 02:51:56PM +0200, Richard Weinberger wrote: > Make sure to stay within bounds, as a misbehaving HTTP server > can trigger a buffer overflow if not properly handled. > > Cc: Joe Hershberger > Cc: Ramon Fried > Signed-off-by: Richard Weinberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Reading from ISO9660 in U-Boot
Hi Heinrick & Bin, I'd like to be able to figure out in U-Boot what OS is on a USB stick. For example, with the Ubuntu installer, I can boot it (through grub), but I cannot see how to read anything useful from the USB stick that would indicate that it is Ubuntu, what version it is, etc. Does U-Boot need an ISO9660-filesystem driver for that? Is there any other way? With Debian I can see the actual files (linux and initrd) , so it is a bit easier. Regards, SImon
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
Hi Simon,
On 22/09/23 23:57, Simon Glass wrote:
Hi Devarsh,
On Tue, 12 Sept 2023 at 08:35, Devarsh Thakkar wrote:
Hi Simon,
On 11/09/23 04:44, Simon Glass wrote:
Hi Devarsh,
On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote:
On Wed, Aug 16, 2023 at 09:16:05PM +0530, Devarsh Thakkar wrote:
Hi Simon,
On 15/08/23 20:14, Simon Glass wrote:
Hi Devarsh,
On Tue, 15 Aug 2023 at 03:23, Devarsh Thakkar wrote:
Hi Simon, Tom,
On 15/08/23 04:13, Simon Glass wrote:
Hi Devarsh, Nikhil, Tom,
On Wed, 9 Aug 2023 at 09:29, Bin Meng wrote:
On Thu, Aug 3, 2023 at 7:03 PM Bin Meng wrote:
On Thu, Aug 3, 2023 at 6:37 PM Bin Meng wrote:
On Tue, Aug 1, 2023 at 12:00 AM Simon Glass wrote:
When the video framebuffer comes from the bloblist, we should not change
relocaddr to this address, since it interfers with the normal memory
typo: interferes
allocation.
This fixes a boot loop in qemu-x86_64
Signed-off-by: Simon Glass
Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL to
u-boot")
Suggested-by: Nikhil M Jain
---
Changes in v3:
- Reword the Kconfig help as suggested
Changes in v2:
- Add a Kconfig as the suggested conditional did not work
common/board_f.c | 3 ++-
drivers/video/Kconfig | 9 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 7d2c380e91e..5173d0a0c2d 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -419,7 +419,8 @@ static int reserve_video(void)
if (!ho)
return log_msg_ret("blf", -ENOENT);
video_reserve_from_bloblist(ho);
- gd->relocaddr = ho->fb;
+ if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
+ gd->relocaddr = ho->fb;
} else if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index b41dc60cec5..f2e56204d52 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
if this option is enabled video driver will be removed at the end
of
SPL stage, beforeloading the next stage.
+config VIDEO_RESERVE_SPL
+ bool
+ help
+ This adjusts reserve_video() to redirect memory reservation when it
+ sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This avoids the
+ memory used for framebuffer from being allocated by U-Boot proper,
+ thus preventing any further memory reservations done by U-Boot proper
+ from overwriting the framebuffer.
+
if SPL_SPLASH_SCREEN
config SPL_SPLASH_SCREEN_ALIGN
Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Dropped this one from the x86 queue per the discussion.
I just wanted to come back to this discussion.
Do we have an agreed way forward? Who is waiting for who?
I was waiting on feedback on
https://lore.kernel.org/all/3b1e8005-f161-8058-13e7-3de2316aa...@ti.com/
but per my opinion, I would prefer to go with "Approach 2" with a
Kconfig as it looks simpler to me. It would look something like below :
if (gd->relocaddr > (unsigned long)ho->fb) {
ulong fb_reloc_gap = gd->relocaddr - gd->ho->fb;
/* Relocate after framebuffer area if nearing too close to it */
if (fb_reloc_gap < CONFIG_BLOBLIST_FB_RELOC_MIN_GAP)
gd->relocaddr = ho->fb;
}
Regarding CONFIG_BLOBLIST_FB_RELOC_MIN_GAP
-> This describes minimum gap to keep between framebuffer address and
relocation address to avoid overlap when framebuffer address used by
blob is below the current relocation address
-> It would be selected as default when CONFIG_BLOBLIST is selected with
default value set to 100Mb
-> SoC specific Vendors can override this in their defconfigs to a
custom value if they feel 100Mb is not enough
Also probably we can have some debug/error prints in the code to show
overlap happened (or is going happen) so that users can fine tune this
Kconfig if they got it wrong at first place.
I can re-spin updated patch if we are aligned on this,
Kindly let me know your opinion.
I'm just nervous about the whole idea, TBH. Perhaps I am missing some
documentation on how people are supposed to lay out memory in SPL and
U-Boot properr, but I'm not really aware of any guidance we give.
Perhaps we should say that the SPL frame buffer should be at the top
of memory, and U-Boot's reserve area should start below that?
1) As per my personal opinion, I don't like putting such constraints and would
instead like to give some flexibility to end user for choosing
framebuffer area as I earlier mentioned, as for that matter if we are using a
predefined address then there is no need of using framebuffer address on
videoblob,
I think this is the wrong direction. We need to offer strong defaults
that shouldn't be deviated without good reason, rather than "pick what
you want". Very few cases will deviate from th
[PATCH v2 4/4] usb: Avoid unbinding devices in use by bootflows
When a USB device is unbound, it causes any bootflows attached to it to
be removed, via a call to bootdev_clear_bootflows() from
bootdev_pre_unbind(). This obviously makes it impossible to boot the
bootflow.
However, when booting a bootflow that relies on USB, usb_stop() is
called, which unbinds the device. For EFI, this happens in
efi_exit_boot_services() which means that the bootflow disappears
before it is finished with.
There is no need to unbind all the USB devices just to quiesce them.
Add a new usb_pause() call which removes them but leaves them bound.
This resolves a hang on x86 when booting a distro from USB. This was
found using a device with 4 bootflows, the last of which was USB.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to avoid unbinding devices in use by bootflows
boot/bootm.c | 2 +-
common/usb.c | 7 ++-
drivers/usb/host/usb-uclass.c | 14 --
include/usb.h | 15 ++-
4 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index b1c3afe0a3a..5c9ba083e64 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -501,7 +501,7 @@ ulong bootm_disable_interrupts(void)
* updated every 1 ms within the HCCA structure in SDRAM! For more
* details see the OpenHCI specification.
*/
- usb_stop();
+ usb_pause();
#endif
return iflag;
}
diff --git a/common/usb.c b/common/usb.c
index 836506dcd9e..4d6ac69111e 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -126,7 +126,7 @@ int usb_init(void)
/**
* Stop USB this stops the LowLevel Part and deregisters USB devices.
*/
-int usb_stop(void)
+int usb_pause(void)
{
int i;
@@ -144,6 +144,11 @@ int usb_stop(void)
return 0;
}
+int usb_stop(void)
+{
+ return usb_pause();
+}
+
/**
* Detect if a USB device has been plugged or unplugged.
*/
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index a1cd0ad2d66..c26c65d7986 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -173,7 +173,7 @@ int usb_get_max_xfer_size(struct usb_device *udev, size_t
*size)
return ops->get_max_xfer_size(bus, size);
}
-int usb_stop(void)
+static int usb_finish(bool unbind_all)
{
struct udevice *bus;
struct udevice *rh;
@@ -195,7 +195,7 @@ int usb_stop(void)
/* Locate root hub device */
device_find_first_child(bus, &rh);
- if (rh) {
+ if (rh && unbind_all) {
/*
* All USB devices are children of root hub.
* Unbinding root hub will unbind all of its children.
@@ -222,6 +222,16 @@ int usb_stop(void)
return err;
}
+int usb_stop(void)
+{
+ return usb_finish(true);
+}
+
+int usb_pause(void)
+{
+ return usb_finish(false);
+}
+
static void usb_scan_bus(struct udevice *bus, bool recurse)
{
struct usb_bus_priv *priv;
diff --git a/include/usb.h b/include/usb.h
index 09e3f0cb309..ad39b09a6e4 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -265,7 +265,20 @@ int usb_kbd_deregister(int force);
*/
int usb_init(void);
-int usb_stop(void); /* stop the USB Controller */
+/**
+ * usb_stop() - stop the USB Controller and unbind all USB controllers/devices
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int usb_stop(void);
+
+/**
+ * usb_pause() - stop the USB Controller DMA, etc.
+ *
+ * Return: 0 if OK, -ve on error
+ */
+int usb_pause(void);
+
int usb_detect_change(void); /* detect if a USB device has been (un)plugged */
--
2.42.0.515.g380fc7ccd1-goog
[PATCH v2 1/4] efi: Correct handling of frame buffer
The efi_gop driver uses private fields from the video uclass to obtain a
pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once
the next stage is running (and making use of U-Boot's EFI boot services)
U-Boot does not handle copying from priv->fb to the hardware framebuffer,
so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just
document how it works. The original change ignored an explicit comment
in the video.h file ("Things that are private to the uclass: don't use
these in the driver") which is why this was missed when the VIDEO_COPY
feature was added.
Signed-off-by: Simon Glass
Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
---
Changes in v2:
- Rebase to -next
- Add some more comments to the header file
- Add fixes tag
include/video.h | 9 ++---
lib/efi_loader/efi_gop.c | 12 +++-
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/video.h b/include/video.h
index 5048116a3d5..4d8df9baaad 100644
--- a/include/video.h
+++ b/include/video.h
@@ -21,9 +21,12 @@ struct udevice;
* @align: Frame-buffer alignment, indicating the memory boundary the frame
* buffer should start on. If 0, 1MB is assumed
* @size: Frame-buffer size, in bytes
- * @base: Base address of frame buffer, 0 if not yet known
- * @copy_base: Base address of a hardware copy of the frame buffer. See
- * CONFIG_VIDEO_COPY.
+ * @base: Base address of frame buffer, 0 if not yet known. If
CONFIG_VIDEO_COPY
+ * is enabled, this is the software copy, so writes to this will not be
+ * visible until vidconsole_sync_copy() is called. If CONFIG_VIDEO_COPY is
+ * disabled, this is the hardware framebuffer.
+ * @copy_base: Base address of a hardware copy of the frame buffer. If
+ * CONFIG_VIDEO_COPY is disabled, this is not used.
* @copy_size: Size of copy framebuffer, used if @size is 0
* @hide_logo: Hide the logo (used for testing)
*/
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 778b693f983..a09db31eb46 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -467,10 +468,10 @@ efi_status_t efi_gop_register(void)
struct efi_gop_obj *gopobj;
u32 bpix, format, col, row;
u64 fb_base, fb_size;
- void *fb;
efi_status_t ret;
struct udevice *vdev;
struct video_priv *priv;
+ struct video_uc_plat *plat;
/* We only support a single video output device for now */
if (uclass_first_device_err(UCLASS_VIDEO, &vdev)) {
@@ -483,9 +484,10 @@ efi_status_t efi_gop_register(void)
format = priv->format;
col = video_get_xsize(vdev);
row = video_get_ysize(vdev);
- fb_base = (uintptr_t)priv->fb;
- fb_size = priv->fb_size;
- fb = priv->fb;
+
+ plat = dev_get_uclass_plat(vdev);
+ fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
+ fb_size = plat->size;
switch (bpix) {
case VIDEO_BPP16:
@@ -547,7 +549,7 @@ efi_status_t efi_gop_register(void)
}
gopobj->info.pixels_per_scanline = col;
gopobj->bpix = bpix;
- gopobj->fb = fb;
+ gopobj->fb = map_sysmem(fb_base, fb_size);
return EFI_SUCCESS;
}
--
2.42.0.515.g380fc7ccd1-goog
[PATCH v2 3/4] x86: coreboot: Add a boot script
Provide the user with a list of available boot options. Selecting one causes it to be booted. Pressing causes U-Boot to return to the command-line prompt. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch to add a coreboot boot script configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 555d281ef3c..dfd47ebb1cf 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -17,6 +17,7 @@ CONFIG_SYS_MONITOR_BASE=0x0112 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" +CONFIG_BOOTCOMMAND="bootflow scan -l; if bootflow menu; then bootflow boot; fi" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_LOG=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index edc38f1f592..ca5e581f8f2 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -15,6 +15,7 @@ CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" +CONFIG_BOOTCOMMAND="bootflow scan -l; if bootflow menu; then bootflow boot; fi" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_LOG=y -- 2.42.0.515.g380fc7ccd1-goog
[PATCH v2 2/4] bootstd: Add a return code to bootflow menu
Return an error when the user does not select an OS, so we know whether
to boot or not.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch to add a return code to bootflow menu
cmd/bootflow.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmd/bootflow.c b/cmd/bootflow.c
index 300ad3aaa76..dbc47961a76 100644
--- a/cmd/bootflow.c
+++ b/cmd/bootflow.c
@@ -459,10 +459,10 @@ static int do_bootflow_menu(struct cmd_tbl *cmdtp, int
flag, int argc,
if (ret) {
if (ret == -EAGAIN)
printf("Nothing chosen\n");
- else {
+ else
printf("Menu failed (err=%d)\n", ret);
- return CMD_RET_FAILURE;
- }
+
+ return CMD_RET_FAILURE;
}
printf("Selected: %s\n", bflow->os_name ? bflow->os_name : bflow->name);
--
2.42.0.515.g380fc7ccd1-goog
[PATCH v2 0/4] Resolve issues with booting distros on x86
This little series reprises the EFI-video fix, fixes a USB problem and enables a boot script for coreboot. With these changes it is possible to boot a Linux distro automatically with U-Boot on x86, including when U-Boot is the second-stage bootloader. Changes in v2: - Rebase to -next - Add some more comments to the header file - Add fixes tag - Add new patch to add a return code to bootflow menu - Add new patch to add a coreboot boot script - Add new patch to avoid unbinding devices in use by bootflows Simon Glass (4): efi: Correct handling of frame buffer bootstd: Add a return code to bootflow menu x86: coreboot: Add a boot script usb: Avoid unbinding devices in use by bootflows boot/bootm.c | 2 +- cmd/bootflow.c| 6 +++--- common/usb.c | 7 ++- configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig| 1 + drivers/usb/host/usb-uclass.c | 14 -- include/usb.h | 15 ++- include/video.h | 9 ++--- lib/efi_loader/efi_gop.c | 12 +++- 9 files changed, 51 insertions(+), 16 deletions(-) -- 2.42.0.515.g380fc7ccd1-goog
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Hi Rob, On Fri, 22 Sept 2023 at 13:43, Rob Herring wrote: > > On Fri, Sep 22, 2023 at 1:12 PM Simon Glass wrote: > > > > Hi Rob, > > > > On Fri, 22 Sept 2023 at 11:46, Rob Herring wrote: > > > > > > On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote: > > > > Hi Rob, > > > > > > > > On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote: > > > > > > > > > > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > > > > > > > > > > > Binman[1] is a tool for creating firmware images. It allows you to > > > > > > combine various binaries and place them in an output file. > > > > > > > > > > > > Binman uses a DT schema to describe an image, in enough detail that > > > > > > it can be automatically built from component parts, disassembled, > > > > > > replaced, listed, etc. > > > > > > > > > > > > Images are typically stored in flash, which is why this binding is > > > > > > targeted at mtd. Previous discussion is at [2] [3]. > > > > > > > > > > > > [1] > > > > > > https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > > > > > [2] > > > > > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > > > > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > > > > > > > > > You missed: > > > > > > > > > > https://github.com/devicetree-org/dt-schema/pull/110 > > > > > > > > > > where I said: We certainly shouldn't duplicate the existing partitions > > > > > bindings. What's missing from them (I assume we're mostly talking > > > > > about "fixed-partitions" which has been around forever I think (before > > > > > me))? > > > > > > > > > > To repeat, unless there is some reason binman partitions conflict with > > > > > fixed-partitions, you need to start there and extend it. From what's > > > > > posted here, it neither conflicts nor needs extending. > > > > > > > > I think at this point I am just hopelessly confused. Have you taken a > > > > look at the binman schema? [1] > > > > > > Why do I need to? That's used for some tool and has nothing to do with a > > > device's DTB. However, I thought somewhere in this discussion you showed > > > it under a flash device node. > > > > Yes, that is the intent (under a flash node). > > > > > Then I care because then it overlaps with > > > what we already have for partitions. If I misunderstood that, then just > > > put your schema with your tool. Only users of the tool should care about > > > the tool's schema. > > > > OK. I believe that binman will fit into both camps, since its input is > > not necessarily fully formed. E.g. if you don't specify the offset of > > an entry, then it will be packed automatically. But the output is > > fully formed, in that Binman now knows the offset so can write it to > > the DT. > > I suppose it could take its own format as input and then write out > something different for the "on the device" format (i.e. > fixed-partitions). At least for the dynamic offsets, we may need > something allowed for binman input, but not allowed on device. In > general, there is support for partitions without addresses/offsets, > but only for partitions that have some other way to figure that out > (on disk partition info). > > There's also the image filename which doesn't really belong in the on > device partitions. So maybe the input and output schemas should be > separate. OK, I'll focus on the output schema for now. I suspect this will be a grey area though. As an example, if you replace a binary in the firmware, Binman can repack the firmware to make room, respecting the alignment and size constraints. So these need to be in the output schema somehow. > > > > > I saw this file, which seems to extend a partition. > > > > > > > > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml > > > > > > IIRC, that's a different type where partition locations are stored in > > > the flash, so we don't need location and size in DT. > > > > OK. > > > > > > > > > > > > > I was assuming that I should create a top-level compatible = "binman" > > > > node, with subnodes like compatible = "binman,bl31-atf", for example. > > > > I should use the compatible string to indicate the contents, right? > > > > > > Yes for subnodes, and we already have some somewhat standard ones for > > > "u-boot" and "u-boot-env". Though historically, "label" was used. > > > > Binman has common properties for all entries, including "compress" > > which sets the compression algorithm. > > I see no issue with adding that. It seems useful and something missing > in the existing partition schemas. OK I sent a patch with that. > > > So perhaps I should start by defining a new binman,bl31-atf which has > > common properties from an "binman,entry" definition? > > I don't understand the binman prefix. The contents are ATF (or TF-A > now). Who wrote it to the flash image is not relevant. Are you suggesting just "atf-bl31", or "arm,atf-bl31" ? Or should we change it to "tfa-bl31"? > > We already have some compatibles in u
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
On Fri, Sep 22, 2023 at 1:12 PM Simon Glass wrote: > > Hi Rob, > > On Fri, 22 Sept 2023 at 11:46, Rob Herring wrote: > > > > On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote: > > > Hi Rob, > > > > > > On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote: > > > > > > > > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > > > > > > > > > Binman[1] is a tool for creating firmware images. It allows you to > > > > > combine various binaries and place them in an output file. > > > > > > > > > > Binman uses a DT schema to describe an image, in enough detail that > > > > > it can be automatically built from component parts, disassembled, > > > > > replaced, listed, etc. > > > > > > > > > > Images are typically stored in flash, which is why this binding is > > > > > targeted at mtd. Previous discussion is at [2] [3]. > > > > > > > > > > [1] > > > > > https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > > > > [2] > > > > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > > > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > > > > > > > You missed: > > > > > > > > https://github.com/devicetree-org/dt-schema/pull/110 > > > > > > > > where I said: We certainly shouldn't duplicate the existing partitions > > > > bindings. What's missing from them (I assume we're mostly talking > > > > about "fixed-partitions" which has been around forever I think (before > > > > me))? > > > > > > > > To repeat, unless there is some reason binman partitions conflict with > > > > fixed-partitions, you need to start there and extend it. From what's > > > > posted here, it neither conflicts nor needs extending. > > > > > > I think at this point I am just hopelessly confused. Have you taken a > > > look at the binman schema? [1] > > > > Why do I need to? That's used for some tool and has nothing to do with a > > device's DTB. However, I thought somewhere in this discussion you showed > > it under a flash device node. > > Yes, that is the intent (under a flash node). > > > Then I care because then it overlaps with > > what we already have for partitions. If I misunderstood that, then just > > put your schema with your tool. Only users of the tool should care about > > the tool's schema. > > OK. I believe that binman will fit into both camps, since its input is > not necessarily fully formed. E.g. if you don't specify the offset of > an entry, then it will be packed automatically. But the output is > fully formed, in that Binman now knows the offset so can write it to > the DT. I suppose it could take its own format as input and then write out something different for the "on the device" format (i.e. fixed-partitions). At least for the dynamic offsets, we may need something allowed for binman input, but not allowed on device. In general, there is support for partitions without addresses/offsets, but only for partitions that have some other way to figure that out (on disk partition info). There's also the image filename which doesn't really belong in the on device partitions. So maybe the input and output schemas should be separate. > > > I saw this file, which seems to extend a partition. > > > > > > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml > > > > IIRC, that's a different type where partition locations are stored in > > the flash, so we don't need location and size in DT. > > OK. > > > > > > > > > I was assuming that I should create a top-level compatible = "binman" > > > node, with subnodes like compatible = "binman,bl31-atf", for example. > > > I should use the compatible string to indicate the contents, right? > > > > Yes for subnodes, and we already have some somewhat standard ones for > > "u-boot" and "u-boot-env". Though historically, "label" was used. > > Binman has common properties for all entries, including "compress" > which sets the compression algorithm. I see no issue with adding that. It seems useful and something missing in the existing partition schemas. > So perhaps I should start by defining a new binman,bl31-atf which has > common properties from an "binman,entry" definition? I don't understand the binman prefix. The contents are ATF (or TF-A now). Who wrote it to the flash image is not relevant. We already have some compatibles in use. We should reuse them if possible. Not sure about TF-A though. Rob
Re: [Question] TI's u-boot.img is built twice
Hi Andrew, On Fri, 22 Sept 2023 at 12:44, Andrew Davis wrote: > > On 9/22/23 1:29 PM, Simon Glass wrote: > > Hi Andrew, > > > > On Fri, 22 Sept 2023 at 12:14, Andrew Davis wrote: > >> > >> On 9/22/23 11:40 AM, Simon Glass wrote: > >>> Hi Andrew, > >>> > >>> On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote: > > On 9/22/23 10:01 AM, Simon Glass wrote: > > Hi Masahiro, > > > > On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada > > wrote: > >> > >> Hi. > >> > >> Since the TI platform migrated to binman, > >> u-boot.img is built twice. > >> > >> It is created by "mkimage -E", > >> then overwritten by binman. > >> > >> > >> So, the data are embedded in the FIT structure > >> instead of being appended. > >> > >> Is this intentional? > >> > >> To me, it looks weird. > >> > >> > >> > >> > >> To confirm it, apply the following hack. > >> > >> Since u-boot.img is overwritten by binman, > >> copy it to u-boot.img.backup. > >> > >> > >> > >> > >> diff --git a/Makefile b/Makefile > >> index 87f9fc786e..4cffa8a061 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -1112,6 +1112,7 @@ endef > >> # Timestamp file to make sure that binman always runs > >> .binman_stamp: $(INPUTS-y) FORCE > >> ifeq ($(CONFIG_BINMAN),y) > >> + cp u-boot.img u-boot.img.backup > >>$(call if_changed,binman) > >> endif > >>@touch $@ > >> > >> > >> > >> Then, build it for the main core. > >> > >> > >> make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- > >> am64x_evm_a53_defconfig all > >> TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin > >> BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin > >> BINMAN_INDIRS=~/ref/ti-linux-firmware > >> > >> > >> > >> > >> Compare the two files. > >> Run fdtdump to see what happened to them. > >> > >> > >> $ diff -u u-boot.img u-boot.img.backup > >> Binary files u-boot.img and u-boot.img.backup differ > >> > >> > >> $ fdtdump u-boot.img > >>=> u-boot and dt are embedded. > >> > >> $ fdtdump u-boot.img.backup > >>=> u-boot and dt are appended after the > >> FIT structure > > > > That seems like a bug to me...at some point we might consider building > > u-boot.img with Binman, but for now it is built by the Makefile. > > > > This is not true for K3 as we now use Binman for u-boot.img generation > (we need this as we have a signing step injected at this point). > >>> > >>> No, no. > >>> > >>> You must not mess with the outputs of Makefile - create a new file > >>> with what you need, e.g. u-boot-ti.img > >>> > >>> While we could use Binman to produce the .img we are quite a way from > >>> doing that as not that many boards have been converted to binman. > >>> > >> > >> Too late, we already use Binman to generate u-boot.img on K3, why > >> would we want to go back to using Makefile? > > > > I don't mean that, I mean give it another name. The u-boot.img file is > > intended to be a certain format, and it seems this is being changed. > > > > Well we need u-boot.img, and it needs to be called that, and > it needs to be the one generated by Binman (the one generated by > Makefile can only boot on GP devices, but not HS-SE). > > The format produced by Makefile and Binman will be identical after > we fix Binman to put the data at the end. At which point why not > drop the Makefile made one? I think you understand my concern, which is really around overwriting an existing file with Binman. So long as you can resolve that in a deterministic way (i.e. Kconfig) then I am happy. Regards, Simon > > Andrew > > > Really, this is a problem with binman, as it should have refused to > > creating u-boot.img...? > > > >> > >> Let's go with what you suggest below and add a Kconfig that can > >> be used for boards that have already switched to binman that disables > >> the Makefile generator for u-boot.img. > >> > >> Once all boards have switched to Binman, then we could refactor > >> the implementations into something more common. > > > > That seems OK to me. > > > > Regards, > > Simon > > > >> > >> Andrew > >> > > So as Masahiro suggested in the other branch of this thread, we need > to disable the Makefile generation of u-boot.img for K3. > > Neha, > > Can you take this action? I assume you can add it as part of your > work in making the data external again, which would make the u-boot.img > identical to before and hence Makefile version could be disabled at > the same time/series. > >>> > >>> If you are suggesting that we slowly migrate boards away from > >>> generating the .img using Makefile...perhaps that makes sense? I'm not > >>>
[PATCH v2] dt-bindings: mtd: Add a schema for binman
Binman[1] is a tool for creating firmware images. It allows you to
combine various binaries and place them in an output file.
Binman uses a DT schema to describe an image, in enough detail that
it can be automatically built from component parts, disassembled,
replaced, listed, etc.
Images are typically stored in flash, which is why this binding is
targeted at mtd. Previous discussion is at [2] [3].
This is only a starting point, an attempt to align on the best way to
add this to the schema.
[1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html
[2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/
[3] https://www.spinics.net/lists/devicetree/msg626149.html
Signed-off-by: Simon Glass
---
Changes in v2:
- Use "binman" for compatible instead of "u-boot,binman"
- Significantly rework the patch
- Use make dt_binding_check DT_SCHEMA_FILES=Documentation/../partitions
.../bindings/mtd/partitions/binman.yaml | 59 ++
.../mtd/partitions/binman/atf-bl31.yaml | 43 +
.../bindings/mtd/partitions/binman/entry.yaml | 62 +++
.../mtd/partitions/binman/u-boot.yaml | 43 +
.../bindings/mtd/partitions/partitions.yaml | 1 +
MAINTAINERS | 5 ++
6 files changed, 213 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/partitions/binman.yaml
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.yaml
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
create mode 100644
Documentation/devicetree/bindings/mtd/partitions/binman/u-boot.yaml
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
new file mode 100644
index ..31accab37055
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binman firmware layout
+
+maintainers:
+ - Simon Glass
+
+select: false
+
+description: |
+ The binman node provides a layout for firmware, used when packaging firmware
+ from multiple projects. For now it just supports a very simple set of
+ features, as a starting point for discussion.
+
+ Documentation for Binman is available at:
+
+ https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
+
+ with the current image-description format at:
+
+
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
+
+properties:
+ reg:
+description: partition's offset and size within the flash
+maxItems: 1
+
+ compatible:
+const: binman
+
+ "#address-cells":
+enum: [ 1, 2 ]
+
+ "#size-cells":
+enum: [ 1, 2 ]
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+binman {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@10 {
+compatible = "brcm,bcm4908-firmware";
+reg = <0x10 0xf0>;
+};
+};
diff --git
a/Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.yaml
new file mode 100644
index ..7d28e7e1d01d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman/atf-bl31.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/partitions/binman/atf-bl31.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Trusted Firmware BL31
+
+maintainers:
+ - Simon Glass
+
+description:
+ Holds a BL31 binary file from the ARM Trusted Firmware project.
+
+allOf:
+ - $ref: entry.yaml#
+
+properties:
+ compatible:
+const: binman,atf-bl31
+
+unevaluatedProperties: false
+
+examples:
+ - |
+binman {
+compatible = "binman";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+reg = <0x0 0xa>;
+compatible = "binman,entry";
+};
+
+partition@10 {
+reg = <0x10 0x20>;
+compatible = "binman,atf-bl31";
+compression = "lz4";
+};
+};
diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
new file mode 100644
index ..9991c83aa0cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2023 Google LLC
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schema
Re: [PATCH 09/32] spl: Avoid an #ifdef when printing gd->malloc_ptr
On Fri, Sep 22, 2023 at 12:27:36PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 21 Sept 2023 at 09:36, Tom Rini wrote:
> >
> > On Wed, Sep 20, 2023 at 07:03:34PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 30 Aug 2023 at 15:39, Tom Rini wrote:
> > > >
> > > > On Wed, Aug 30, 2023 at 12:04:40PM -0600, Simon Glass wrote:
> > > > > Use an accessor in the header file to avoid this.
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > > > ---
> > > > >
> > > > > common/spl/spl.c | 9 +
> > > > > include/asm-generic/global_data.h | 7 +++
> > > > > 2 files changed, 12 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > > > > index f0a90c280da..f5cef81000c 100644
> > > > > --- a/common/spl/spl.c
> > > > > +++ b/common/spl/spl.c
> > > > > @@ -876,10 +876,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > > > } else {
> > > > > debug("Unsupported OS image.. Jumping
> > > > > nevertheless..\n");
> > > > > }
> > > > > -#if CONFIG_VAL(SYS_MALLOC_F_LEN) &&
> > > > > !defined(CONFIG_SPL_SYS_MALLOC_SIZE)
> > > > > - debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > > > gd->malloc_ptr,
> > > > > - gd->malloc_ptr / 1024);
> > > > > -#endif
> > > > > + if (IS_ENABLED(CONFIG_SYS_MALLOC_F) &&
> > > > > + !IS_ENABLED(CONFIG_SPL_SYS_MALLOC_SIZE))
> > > > > + debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > > > + gd_malloc_ptr(), gd_malloc_ptr() / 1024);
> >
> > This is not more readable. But I guess my comment was unclear as you're
> > mixing changes here. gd_malloc_ptr() rather than gd->malloc_ptr is a
> > wash, to me. I think one could argue it's not a helpful abstraction.
> > but it's so that you can avoid CONFIG_VAL here, and say "if (...)" not
> > "#if ..." here.
>
> Yes,
>
> >
> > > > > +
> > > > > bootstage_mark_name(get_bootstage_id(false), "end phase");
> > > > > #ifdef CONFIG_BOOTSTAGE_STASH
> > > > > ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> > > > > diff --git a/include/asm-generic/global_data.h
> > > > > b/include/asm-generic/global_data.h
> > > > > index 8fc205ded1a..edf9ff6823f 100644
> > > > > --- a/include/asm-generic/global_data.h
> > > > > +++ b/include/asm-generic/global_data.h
> > > > > @@ -573,6 +573,13 @@ static_assert(sizeof(struct global_data) ==
> > > > > GD_SIZE);
> > > > > #define gd_malloc_start()0
> > > > > #define gd_set_malloc_start(val)
> > > > > #endif
> > > > > +
> > > > > +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
> > > > > +#define gd_malloc_ptr() gd->malloc_ptr
> > > > > +#else
> > > > > +#define gd_malloc_ptr() 0L
> > > > > +#endif
> > > > > +
> > > > > /**
> > > > > * enum gd_flags - global data flags
> > > > > *
> > > >
> > > > This is another case where readability is not improved. I also have a
> > > > bad feeling that changing that exact area had some unintended
> > > > consequences from the compiler, that totally should not have happened.
> > > > But maybe that was something in a similar code section instead.
> > >
> > > The improvement is in the C file...here we have an accessor in the
> > > header file as has been done elsewhere.
> > >
> > > Do you have any more details on the problem you mention? I will align
> > > the accessor to the struct member which should resolve it.
> >
> > It's unfortunately one of those cases to do a global before/after build
> > and see if anything does or does not get tripped up. As I believe I did
> > use CONFIG_VAL there and not a check on CONFIG_SYS_MALLOC_F itself for a
> > reason, at the time.
>
> But the CONFIG_VAL symbols actually depends on CONFIG_SYS_MALLOC_F, so
> I can't imagine what it might be. Of course if the value is 0, then
> the 'if CONFIG_VAL()' test would fail, but to what purpose?
Yes, there's been a time or two where I banged my head against the
figurative wall trying to understand what exactly the compiler could be
seeing as why to change something. I don't have a "reasonable"
explanation. Readability aside, "tidy things up" changes need to be on
their own so that their impact can be seen aside from the new
functionality changes.
--
Tom
signature.asc
Description: PGP signature
Re: [Question] TI's u-boot.img is built twice
On 9/22/23 1:29 PM, Simon Glass wrote: Hi Andrew, On Fri, 22 Sept 2023 at 12:14, Andrew Davis wrote: On 9/22/23 11:40 AM, Simon Glass wrote: Hi Andrew, On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote: On 9/22/23 10:01 AM, Simon Glass wrote: Hi Masahiro, On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote: Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure That seems like a bug to me...at some point we might consider building u-boot.img with Binman, but for now it is built by the Makefile. This is not true for K3 as we now use Binman for u-boot.img generation (we need this as we have a signing step injected at this point). No, no. You must not mess with the outputs of Makefile - create a new file with what you need, e.g. u-boot-ti.img While we could use Binman to produce the .img we are quite a way from doing that as not that many boards have been converted to binman. Too late, we already use Binman to generate u-boot.img on K3, why would we want to go back to using Makefile? I don't mean that, I mean give it another name. The u-boot.img file is intended to be a certain format, and it seems this is being changed. Well we need u-boot.img, and it needs to be called that, and it needs to be the one generated by Binman (the one generated by Makefile can only boot on GP devices, but not HS-SE). The format produced by Makefile and Binman will be identical after we fix Binman to put the data at the end. At which point why not drop the Makefile made one? Andrew Really, this is a problem with binman, as it should have refused to creating u-boot.img...? Let's go with what you suggest below and add a Kconfig that can be used for boards that have already switched to binman that disables the Makefile generator for u-boot.img. Once all boards have switched to Binman, then we could refactor the implementations into something more common. That seems OK to me. Regards, Simon Andrew So as Masahiro suggested in the other branch of this thread, we need to disable the Makefile generation of u-boot.img for K3. Neha, Can you take this action? I assume you can add it as part of your work in making the data external again, which would make the u-boot.img identical to before and hence Makefile version could be disabled at the same time/series. If you are suggesting that we slowly migrate boards away from generating the .img using Makefile...perhaps that makes sense? I'm not really sure. But in that case we need another Kconfig option. Regards, Simon
Re: [Question] TI's u-boot.img is built twice
Hi Andrew, On Fri, 22 Sept 2023 at 12:14, Andrew Davis wrote: > > On 9/22/23 11:40 AM, Simon Glass wrote: > > Hi Andrew, > > > > On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote: > >> > >> On 9/22/23 10:01 AM, Simon Glass wrote: > >>> Hi Masahiro, > >>> > >>> On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada > >>> wrote: > > Hi. > > Since the TI platform migrated to binman, > u-boot.img is built twice. > > It is created by "mkimage -E", > then overwritten by binman. > > > So, the data are embedded in the FIT structure > instead of being appended. > > Is this intentional? > > To me, it looks weird. > > > > > To confirm it, apply the following hack. > > Since u-boot.img is overwritten by binman, > copy it to u-boot.img.backup. > > > > > diff --git a/Makefile b/Makefile > index 87f9fc786e..4cffa8a061 100644 > --- a/Makefile > +++ b/Makefile > @@ -1112,6 +1112,7 @@ endef > # Timestamp file to make sure that binman always runs > .binman_stamp: $(INPUTS-y) FORCE > ifeq ($(CONFIG_BINMAN),y) > + cp u-boot.img u-boot.img.backup > $(call if_changed,binman) > endif > @touch $@ > > > > Then, build it for the main core. > > > make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- > am64x_evm_a53_defconfig all > TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin > BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin > BINMAN_INDIRS=~/ref/ti-linux-firmware > > > > > Compare the two files. > Run fdtdump to see what happened to them. > > > $ diff -u u-boot.img u-boot.img.backup > Binary files u-boot.img and u-boot.img.backup differ > > > $ fdtdump u-boot.img > => u-boot and dt are embedded. > > $ fdtdump u-boot.img.backup > => u-boot and dt are appended after the > FIT structure > >>> > >>> That seems like a bug to me...at some point we might consider building > >>> u-boot.img with Binman, but for now it is built by the Makefile. > >>> > >> > >> This is not true for K3 as we now use Binman for u-boot.img generation > >> (we need this as we have a signing step injected at this point). > > > > No, no. > > > > You must not mess with the outputs of Makefile - create a new file > > with what you need, e.g. u-boot-ti.img > > > > While we could use Binman to produce the .img we are quite a way from > > doing that as not that many boards have been converted to binman. > > > > Too late, we already use Binman to generate u-boot.img on K3, why > would we want to go back to using Makefile? I don't mean that, I mean give it another name. The u-boot.img file is intended to be a certain format, and it seems this is being changed. Really, this is a problem with binman, as it should have refused to creating u-boot.img...? > > Let's go with what you suggest below and add a Kconfig that can > be used for boards that have already switched to binman that disables > the Makefile generator for u-boot.img. > > Once all boards have switched to Binman, then we could refactor > the implementations into something more common. That seems OK to me. Regards, Simon > > Andrew > > >> > >> So as Masahiro suggested in the other branch of this thread, we need > >> to disable the Makefile generation of u-boot.img for K3. > >> > >> Neha, > >> > >> Can you take this action? I assume you can add it as part of your > >> work in making the data external again, which would make the u-boot.img > >> identical to before and hence Makefile version could be disabled at > >> the same time/series. > > > > If you are suggesting that we slowly migrate boards away from > > generating the .img using Makefile...perhaps that makes sense? I'm not > > really sure. But in that case we need another Kconfig option. > > > > Regards, > > Simon
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
Hi Devarsh,
On Tue, 12 Sept 2023 at 08:35, Devarsh Thakkar wrote:
>
> Hi Simon,
>
> On 11/09/23 04:44, Simon Glass wrote:
> > Hi Devarsh,
> >
> > On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote:
> >>
> >> On Wed, Aug 16, 2023 at 09:16:05PM +0530, Devarsh Thakkar wrote:
> >>> Hi Simon,
> >>>
> >>> On 15/08/23 20:14, Simon Glass wrote:
> Hi Devarsh,
>
> On Tue, 15 Aug 2023 at 03:23, Devarsh Thakkar wrote:
> >
> > Hi Simon, Tom,
> >
> > On 15/08/23 04:13, Simon Glass wrote:
> >> Hi Devarsh, Nikhil, Tom,
> >>
> >> On Wed, 9 Aug 2023 at 09:29, Bin Meng wrote:
> >>>
> >>> On Thu, Aug 3, 2023 at 7:03 PM Bin Meng wrote:
>
> On Thu, Aug 3, 2023 at 6:37 PM Bin Meng wrote:
> >
> > On Tue, Aug 1, 2023 at 12:00 AM Simon Glass
> > wrote:
> >>
> >> When the video framebuffer comes from the bloblist, we should not
> >> change
> >> relocaddr to this address, since it interfers with the normal
> >> memory
> >
> > typo: interferes
> >
> >> allocation.
> >>
> >> This fixes a boot loop in qemu-x86_64
> >>
> >> Signed-off-by: Simon Glass
> >> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from
> >> SPL to u-boot")
> >> Suggested-by: Nikhil M Jain
> >> ---
> >>
> >> Changes in v3:
> >> - Reword the Kconfig help as suggested
> >>
> >> Changes in v2:
> >> - Add a Kconfig as the suggested conditional did not work
> >>
> >> common/board_f.c | 3 ++-
> >> drivers/video/Kconfig | 9 +
> >> 2 files changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/common/board_f.c b/common/board_f.c
> >> index 7d2c380e91e..5173d0a0c2d 100644
> >> --- a/common/board_f.c
> >> +++ b/common/board_f.c
> >> @@ -419,7 +419,8 @@ static int reserve_video(void)
> >> if (!ho)
> >> return log_msg_ret("blf", -ENOENT);
> >> video_reserve_from_bloblist(ho);
> >> - gd->relocaddr = ho->fb;
> >> + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> >> + gd->relocaddr = ho->fb;
> >> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> >> ulong addr;
> >> int ret;
> >> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >> index b41dc60cec5..f2e56204d52 100644
> >> --- a/drivers/video/Kconfig
> >> +++ b/drivers/video/Kconfig
> >> @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> >>if this option is enabled video driver will be removed
> >> at the end of
> >>SPL stage, beforeloading the next stage.
> >>
> >> +config VIDEO_RESERVE_SPL
> >> + bool
> >> + help
> >> + This adjusts reserve_video() to redirect memory
> >> reservation when it
> >> + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This
> >> avoids the
> >> + memory used for framebuffer from being allocated by
> >> U-Boot proper,
> >> + thus preventing any further memory reservations done by
> >> U-Boot proper
> >> + from overwriting the framebuffer.
> >> +
> >> if SPL_SPLASH_SCREEN
> >>
> >> config SPL_SPLASH_SCREEN_ALIGN
> >
> > Reviewed-by: Bin Meng
>
> applied to u-boot-x86, thanks!
> >>>
> >>> Dropped this one from the x86 queue per the discussion.
> >>
> >> I just wanted to come back to this discussion.
> >>
> >> Do we have an agreed way forward? Who is waiting for who?
> >>
> >
> > I was waiting on feedback on
> > https://lore.kernel.org/all/3b1e8005-f161-8058-13e7-3de2316aa...@ti.com/
> > but per my opinion, I would prefer to go with "Approach 2" with a
> > Kconfig as it looks simpler to me. It would look something like below :
> >
> > if (gd->relocaddr > (unsigned long)ho->fb) {
> > ulong fb_reloc_gap = gd->relocaddr - gd->ho->fb;
> >
> > /* Relocate after framebuffer area if nearing too close to it */
> > if (fb_reloc_gap < CONFIG_BLOBLIST_FB_RELOC_MIN_GAP)
> > gd->relocaddr = ho->fb;
> > }
> >
> > Regarding CONFIG_BLOBLIST_FB_RELOC_MIN_GAP
> > -> This describes minimum gap to keep between framebuffer address and
> > relocation address to avoid overlap when framebuffer address used by
> > blob is below the current relocation address
> >
> > -> It would be selected as default when CONFIG_BLOBLIST is selected with
> > default value s
Re: [PATCH 09/32] spl: Avoid an #ifdef when printing gd->malloc_ptr
Hi Tom,
On Thu, 21 Sept 2023 at 09:36, Tom Rini wrote:
>
> On Wed, Sep 20, 2023 at 07:03:34PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 30 Aug 2023 at 15:39, Tom Rini wrote:
> > >
> > > On Wed, Aug 30, 2023 at 12:04:40PM -0600, Simon Glass wrote:
> > > > Use an accessor in the header file to avoid this.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > ---
> > > >
> > > > common/spl/spl.c | 9 +
> > > > include/asm-generic/global_data.h | 7 +++
> > > > 2 files changed, 12 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > > > index f0a90c280da..f5cef81000c 100644
> > > > --- a/common/spl/spl.c
> > > > +++ b/common/spl/spl.c
> > > > @@ -876,10 +876,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > > } else {
> > > > debug("Unsupported OS image.. Jumping nevertheless..\n");
> > > > }
> > > > -#if CONFIG_VAL(SYS_MALLOC_F_LEN) &&
> > > > !defined(CONFIG_SPL_SYS_MALLOC_SIZE)
> > > > - debug("SPL malloc() used 0x%lx bytes (%ld KB)\n", gd->malloc_ptr,
> > > > - gd->malloc_ptr / 1024);
> > > > -#endif
> > > > + if (IS_ENABLED(CONFIG_SYS_MALLOC_F) &&
> > > > + !IS_ENABLED(CONFIG_SPL_SYS_MALLOC_SIZE))
> > > > + debug("SPL malloc() used 0x%lx bytes (%ld KB)\n",
> > > > + gd_malloc_ptr(), gd_malloc_ptr() / 1024);
>
> This is not more readable. But I guess my comment was unclear as you're
> mixing changes here. gd_malloc_ptr() rather than gd->malloc_ptr is a
> wash, to me. I think one could argue it's not a helpful abstraction.
> but it's so that you can avoid CONFIG_VAL here, and say "if (...)" not
> "#if ..." here.
Yes,
>
> > > > +
> > > > bootstage_mark_name(get_bootstage_id(false), "end phase");
> > > > #ifdef CONFIG_BOOTSTAGE_STASH
> > > > ret = bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> > > > diff --git a/include/asm-generic/global_data.h
> > > > b/include/asm-generic/global_data.h
> > > > index 8fc205ded1a..edf9ff6823f 100644
> > > > --- a/include/asm-generic/global_data.h
> > > > +++ b/include/asm-generic/global_data.h
> > > > @@ -573,6 +573,13 @@ static_assert(sizeof(struct global_data) ==
> > > > GD_SIZE);
> > > > #define gd_malloc_start()0
> > > > #define gd_set_malloc_start(val)
> > > > #endif
> > > > +
> > > > +#if CONFIG_VAL(SYS_MALLOC_F_LEN)
> > > > +#define gd_malloc_ptr() gd->malloc_ptr
> > > > +#else
> > > > +#define gd_malloc_ptr() 0L
> > > > +#endif
> > > > +
> > > > /**
> > > > * enum gd_flags - global data flags
> > > > *
> > >
> > > This is another case where readability is not improved. I also have a
> > > bad feeling that changing that exact area had some unintended
> > > consequences from the compiler, that totally should not have happened.
> > > But maybe that was something in a similar code section instead.
> >
> > The improvement is in the C file...here we have an accessor in the
> > header file as has been done elsewhere.
> >
> > Do you have any more details on the problem you mention? I will align
> > the accessor to the struct member which should resolve it.
>
> It's unfortunately one of those cases to do a global before/after build
> and see if anything does or does not get tripped up. As I believe I did
> use CONFIG_VAL there and not a check on CONFIG_SYS_MALLOC_F itself for a
> reason, at the time.
But the CONFIG_VAL symbols actually depends on CONFIG_SYS_MALLOC_F, so
I can't imagine what it might be. Of course if the value is 0, then
the 'if CONFIG_VAL()' test would fail, but to what purpose?
Regards,
Simon
Re: [PATCH 4/9] configs: sandbox: Enable GETOPT for sandbox and sandbox64 target
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Enable GETOPT so that 'bdinfo' command with getopt() support can be > tested in CI. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > configs/sandbox64_defconfig | 1 + > configs/sandbox_defconfig | 1 + > 2 files changed, 2 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH 7/9] test: bdinfo: Test bdinfo -h
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > The bdinfo -h should print error message that -h is an unknown > parameter and then command help text. Test the expected output. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > test/cmd/bdinfo.c | 17 + > 1 file changed, 17 insertions(+) Reviewed-by: Simon Glass e
Re: [PATCH 6/9] test: bdinfo: Test both bdinfo and bdinfo -a
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Factor out the core of test for all bdinfo output into bdinfo_test_all() > and then reuse it to verify that both 'bdinfo' and 'bdinfo -a' print all > the bdinfo output. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > test/cmd/bdinfo.c | 17 - > 1 file changed, 12 insertions(+), 5 deletions(-) > Reviewed-by: Simon Glass
Re: [RFC 6/6] test: dm: add SCMI pinctrl test
Hi,
On Sun, 10 Sept 2023 at 23:47, AKASHI Takahiro
wrote:
>
> On Sun, Sep 10, 2023 at 01:13:30PM -0600, Simon Glass wrote:
> > Hi AKASHI,
> >
> > On Tue, 5 Sept 2023 at 20:41, AKASHI Takahiro
> > wrote:
> > >
> > > In this test, SCMI-based pinmux feature is exercised.
> > >
> > > Signed-off-by: AKASHI Takahiro
> > > ---
> > > test/dm/scmi.c | 62 ++
> > > 1 file changed, 62 insertions(+)
> > >
> > > diff --git a/test/dm/scmi.c b/test/dm/scmi.c
> > > index 423b6ef70b29..ca5a2e9c781e 100644
> > > --- a/test/dm/scmi.c
> > > +++ b/test/dm/scmi.c
> > > @@ -21,6 +21,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -395,3 +396,64 @@ static int dm_test_scmi_voltage_domains(struct
> > > unit_test_state *uts)
> > > return release_sandbox_scmi_test_devices(uts, dev);
> > > }
> > > DM_TEST(dm_test_scmi_voltage_domains, UT_TESTF_SCAN_FDT);
> > > +
> > > +/*
> > > + * This part is derived from test/dm/pinmux.c, So
> > > + *
> > > + * Copyright (C) 2020 Sean Anderson
> > > + */
> > > +
> > > +static char buf[64];
> > > +#define test_muxing(selector, expected) do { \
> > > + ut_assertok(pinctrl_get_pin_muxing(dev, selector, buf,
> > > sizeof(buf))); \
> > > + ut_asserteq_str(expected, (char *)&buf); \
> >
> > Can you instead make this a function?
>
> Sure, but please note that the whole scheme was borrowed
> from test/dm/pinmux.c.
I'm not sure if it is needed there, either. It is pretty ugly.
>
> > > +} while (0)
> > > +
> > > +#define test_name(selector, expected) do { \
> > > + ut_assertok(pinctrl_get_pin_name(dev, selector, buf,
> > > sizeof(buf))); \
> > > + ut_asserteq_str(expected, (char *)&buf); \
> > > +} while (0)
> > > +
> > > +static int dm_test_scmi_pinmux(struct unit_test_state *uts)
> > > +{
> > > + struct udevice *dev;
> > > +
> > > + ut_assertok(uclass_get_device_by_name(UCLASS_PINCTRL,
> > > "protocol@19",
> > > + &dev));
> > > + ut_assertok(pinctrl_select_state(dev, "default"));
> > > + test_muxing(0, "");
> >
> > ut_assertok(check_muxing(uts, ...));
>
> Assertion for
>
> > > + test_muxing(1, "");
> > > + test_muxing(2, "I2S.");
> > > + test_muxing(3, "I2S.");
> > > + test_muxing(4, "I2S.");
> > > + test_muxing(5, "GPIO bias-pull-up.");
> > > + test_muxing(6, "GPIO drive-open-drain output-mode output-value.");
> > > + test_muxing(7, "GPIO bias-pull-down input-mode.");
> > > + test_muxing(8, "GPIO bias-disable.");
>
> this chunk of code?
> It is not clear to me what is the advantage, though.
Avoiding macros, which are not needed.
>
> -Takahiro Akashi
>
> > > +
> > > + ut_assertok(pinctrl_select_state(dev, "alternate"));
> > > + test_muxing(0, "I2C drive-open-drain.");
> > > + test_muxing(1, "I2C drive-open-drain.");
> > > + test_muxing(2, "SPI.");
> > > + test_muxing(3, "SPI.");
> > > + test_muxing(4, "SPI.");
> > > + test_muxing(5, "CS bias-pull-up.");
> > > + test_muxing(6, "CS drive-open-drain output-mode output-value.");
> > > + test_muxing(7, "GPIO bias-pull-down input-mode.");
> > > + test_muxing(8, "GPIO bias-disable.");
> > > +
> > > + ut_assertok(pinctrl_select_state(dev, "0"));
> > > + test_muxing(0, "I2C drive-open-drain.");
> > > + test_muxing(1, "I2C drive-open-drain.");
> > > + test_muxing(2, "I2S.");
> > > + test_muxing(3, "I2S.");
> > > + test_muxing(4, "I2S.");
> > > + test_muxing(5, "GPIO bias-pull-up.");
> > > + test_muxing(6, "GPIO drive-open-drain output-mode output-value.");
> > > + test_muxing(7, "GPIO bias-pull-down input-mode.");
> > > + test_muxing(8, "GPIO bias-disable.");
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +DM_TEST(dm_test_scmi_pinmux, UT_TESTF_SCAN_FDT);
> > > --
> > > 2.34.1
> > >
> >
> > Regards,
> > Simon
Regards,
Simon
Re: [PATCH 5/9] test: bdinfo: Rename bdinfo_test_move() to bdinfo_test_full()
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Rename bdinfo_test_move() to bdinfo_test_full(). The former is a > remnant of deriving this test from another test. No functional > change. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > test/cmd/bdinfo.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 1/9] cmd: bdinfo: Optionally use getopt and implement bdinfo -a
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Add optional support for getopt() and in case this is enabled via > GETOPT configuration option, implement support for 'bdinfo -a'. > The 'bdinfo -a' behaves exactly like bdinfo and prints 'all' the > bdinfo information. This is implemented in preparation for other > more fine-grained options. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > cmd/bdinfo.c | 29 + > 1 file changed, 25 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 8/9] test: bdinfo: Test bdinfo -m
On Wed, 20 Sept 2023 at 16:58, Marek Vasut
wrote:
>
> The bdinfo -m should print only the board memory layout.
> Test the expected output.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Bin Meng
> Cc: Mario Six
> Cc: Nikhil M Jain
> Cc: Simon Glass
> ---
> test/cmd/bdinfo.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/test/cmd/bdinfo.c b/test/cmd/bdinfo.c
> index 2f34d877e5c..f090667fb42 100644
> --- a/test/cmd/bdinfo.c
> +++ b/test/cmd/bdinfo.c
> @@ -130,13 +130,11 @@ static int lmb_test_dump_all(struct unit_test_state
> *uts, struct lmb *lmb)
> return 0;
> }
>
> -static int bdinfo_test_all(struct unit_test_state *uts)
> +static int bdinfo_test_mem(struct unit_test_state *uts)
Since this is not a standalone test now, I think the word 'check' is
better than test. I try to reserve ''test' for a top-level test that
can be run.
> {
> struct bd_info *bd = gd->bd;
> int i;
>
> - ut_assertok(test_num_l(uts, "boot_params", 0));
> -
> for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> if (bd->bi_dram[i].size) {
> ut_assertok(test_num_l(uts, "DRAM bank", i));
> @@ -147,6 +145,15 @@ static int bdinfo_test_all(struct unit_test_state *uts)
> }
> }
>
> + return 0;
> +}
> +
> +static int bdinfo_test_all(struct unit_test_state *uts)
> +{
> + ut_assertok(test_num_l(uts, "boot_params", 0));
> +
> + ut_assertok(bdinfo_test_mem(uts));
> +
> /* CONFIG_SYS_HAS_SRAM testing not supported */
> ut_assertok(test_num_l(uts, "flashstart", 0));
> ut_assertok(test_num_l(uts, "flashsize", 0));
> @@ -243,6 +250,19 @@ static int bdinfo_test_help(struct unit_test_state *uts)
>
> BDINFO_TEST(bdinfo_test_help, UT_TESTF_CONSOLE_REC);
>
> +static int bdinfo_test_memory(struct unit_test_state *uts)
> +{
> + /* Test BDINFO memory layout only print */
> + ut_assertok(console_record_reset_enable());
> + ut_assertok(run_commandf("bdinfo -m"));
> + ut_assertok(bdinfo_test_mem(uts));
> + ut_assertok(ut_check_console_end(uts));
> +
> + return 0;
> +}
> +
> +BDINFO_TEST(bdinfo_test_memory, UT_TESTF_CONSOLE_REC);
> +
> int do_ut_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> {
> struct unit_test *tests = UNIT_TEST_SUITE_START(bdinfo_test);
> --
> 2.40.1
>
Regards,
Simon
Re: [PATCH v4] bootstd: sata: Add bootstd support for ahci sata
On Sun, 17 Sept 2023 at 17:07, Tony Dinh wrote: > > Add ahci sata bootdev and corresponding hunting function. > > Signed-off-by: Tony Dinh > --- > > Changes in v4: > - Revise logic in bootmeth_script() to set devtype to sata for non-scsi > SATA device > - Rewrite sata_rescan() logic to properly remove all devices before probing > - Add description to sata_rescan() header > > Changes in v3: > - Correct drivers/ata/Makefile to compile sata_bootdev only if > ahci sata is enabled. > > Changes in v2: > - set devtype to sata in bootmeth_script for non-scsi SATA device. > > boot/bootmeth_script.c | 14 +++-- > drivers/ata/Makefile | 2 +- > drivers/ata/sata.c | 32 > drivers/ata/sata_bootdev.c | 62 ++ > include/sata.h | 6 > 5 files changed, 112 insertions(+), 4 deletions(-) > create mode 100644 drivers/ata/sata_bootdev.c > Reviewed-by: Simon Glass
Re: [PATCH 2/9] cmd: bdinfo: Implement support for printing memory layout via bdinfo -m
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Add support for printing memory layout only via 'bdinfo -m' . > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > cmd/bdinfo.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 9/9] test: bdinfo: Test bdinfo -e
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > The bdinfo -e should print only the board ethernet settings. > Test the expected output. > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > test/cmd/bdinfo.c | 14 ++ > 1 file changed, 14 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 3/9] cmd: bdinfo: Implement support for printing ethernet settings via bdinfo -e
On Wed, 20 Sept 2023 at 16:58, Marek Vasut wrote: > > Add support for printing ethernet settings only via 'bdinfo -e' . > > Signed-off-by: Marek Vasut > --- > Cc: Bin Meng > Cc: Mario Six > Cc: Nikhil M Jain > Cc: Simon Glass > --- > cmd/bdinfo.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v2] bootstd: Make efi_mgr bootmeth work for non-sandbox setups
On Tue, 12 Sept 2023 at 14:06, Mark Kettenis wrote:
>
> > From: Simon Glass
> > Date: Sun, 10 Sep 2023 13:13:16 -0600
> >
> > Hi Mark,
> >
> > On Sun, 10 Sept 2023 at 08:57, Mark Kettenis
> > wrote:
> > >
> > > > From: Simon Glass
> > > > Date: Thu, 7 Sep 2023 09:57:34 -0600
> > > >
> > > > Hi Mark,
> > > >
> > > > On Thu, 7 Sept 2023 at 07:08, Mark Kettenis
> > > > wrote:
> > > > >
> > > > > > From: Simon Glass
> > > > > > Date: Thu, 7 Sep 2023 06:23:10 -0600
> > > > > >
> > > > > > Hi Mark,
> > > > > >
> > > > > > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis
> > > > > > wrote:
> > > > > > >
> > > > > > > Enable the bootflow based on this bootmeth if the BootOrder EFI
> > > > > > > variable is set.
> > > > > > >
> > > > > > > Signed-off-by: Mark Kettenis
> > > > > > > ---
> > > > > > >
> > > > > > > ChangeLog:
> > > > > > >
> > > > > > > v2: - Initialize EFI subsystem to populate EFI variables
> > > > > > >
> > > > > > >
> > > > > > > boot/bootmeth_efi_mgr.c | 17 -
> > > > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c
> > > > > > > index e9d973429f..e6c42d41fb 100644
> > > > > > > --- a/boot/bootmeth_efi_mgr.c
> > > > > > > +++ b/boot/bootmeth_efi_mgr.c
> > > > > > > @@ -14,6 +14,8 @@
> > > > > > > #include
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > >
> > > > > > > /**
> > > > > > > * struct efi_mgr_priv - private info for the efi-mgr driver
> > > > > > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev,
> > > > > > > struct bootflow_iter *iter)
> > > > > > > static int efi_mgr_read_bootflow(struct udevice *dev, struct
> > > > > > > bootflow *bflow)
> > > > > > > {
> > > > > > > struct efi_mgr_priv *priv = dev_get_priv(dev);
> > > > > > > + efi_status_t ret;
> > > > > > > + efi_uintn_t size;
> > > > > > > + u16 *bootorder;
> > > > > > >
> > > > > > > if (priv->fake_dev) {
> > > > > > > bflow->state = BOOTFLOWST_READY;
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > - /* To be implemented */
> > > > > > > + ret = efi_init_obj_list();
> > > > > >
> > > > > > Doesn't this start up the whole EFI system? Is there a cheaper way
> > > > > > to
> > > > > > see if the variable subsystem exists, or can work?
> > > > >
> > > > > A fair bit of it at least. With the possible exception of launching
> > > > > EFI capsules (which shouldn't happen for a "normal" boot), I don't
> > > > > think this is very expensive though.
> > > > >
> > > > > There currently isn't a way to only initialize the variable subsystem;
> > > > > we can't just call efi_init_variables() here since we have to also
> > > > > call efi_disks_register() and a later efi_init_obj_list() call would
> > > > > call efi_init_variables() again, which would leak memory.
> > > > >
> > > > > Alternatively we could just unconditionally declare the efi_mgr
> > > > > bootmeth as "ready" (like you already do for sandbox). That would
> > > > > postpone initialization of the EFI subsystem until we actually execute
> > > > > this bootmeth.
> > > > >
> > > > > But we need to do something before we switch more targets to standard
> > > > > boot since otherwise booting through the EFI boot manager is just
> > > > > plain broken.
> > > >
> > > > Yes...
> > > >
> > > > I don't have any great ideas on this. If we could get the EFI code
> > > > better integrated into U-Boot then perhaps we would not need this
> > > > 'monolithm' init?
> > >
> > > You'll have to take that up with the maintainers of the EFI loader
> > > subsystem. I just want to repair the breakage that was introduced
> > > with bootstd.
> >
> > Yes, understood. Do you know how long it takes to do this step?
>
> It is instant. But then this is on a fast machine with the EFI
> variables stored on the internal NVMe disk, which is plenty fast as
> well. And I haven't enabled any of the capsule or TPM stuff hich may
> take more time.
>
> > The control for this feature is CMD_BOOTEFI_BOOTMGR...I think it would
> > be better to have BOOTEFI_BOOTMGR as well as CMD_BOOTEFI_BOOTMGR,
> > since it is strange to have a CMD Kconfig in lib/efi_loader
> >
> > I am OK with this patch as I don't see any alternative. We need to do
> > something and we can always improve it if it causes problems.
> >
> > Heinrich?
Reviewed-by: Simon Glass
Re: [Question] TI's u-boot.img is built twice
On 9/22/23 11:40 AM, Simon Glass wrote: Hi Andrew, On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote: On 9/22/23 10:01 AM, Simon Glass wrote: Hi Masahiro, On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote: Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure That seems like a bug to me...at some point we might consider building u-boot.img with Binman, but for now it is built by the Makefile. This is not true for K3 as we now use Binman for u-boot.img generation (we need this as we have a signing step injected at this point). No, no. You must not mess with the outputs of Makefile - create a new file with what you need, e.g. u-boot-ti.img While we could use Binman to produce the .img we are quite a way from doing that as not that many boards have been converted to binman. Too late, we already use Binman to generate u-boot.img on K3, why would we want to go back to using Makefile? Let's go with what you suggest below and add a Kconfig that can be used for boards that have already switched to binman that disables the Makefile generator for u-boot.img. Once all boards have switched to Binman, then we could refactor the implementations into something more common. Andrew So as Masahiro suggested in the other branch of this thread, we need to disable the Makefile generation of u-boot.img for K3. Neha, Can you take this action? I assume you can add it as part of your work in making the data external again, which would make the u-boot.img identical to before and hence Makefile version could be disabled at the same time/series. If you are suggesting that we slowly migrate boards away from generating the .img using Makefile...perhaps that makes sense? I'm not really sure. But in that case we need another Kconfig option. Regards, Simon
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Hi Rob, On Fri, 22 Sept 2023 at 11:46, Rob Herring wrote: > > On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote: > > Hi Rob, > > > > On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote: > > > > > > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > > > > > > > Binman[1] is a tool for creating firmware images. It allows you to > > > > combine various binaries and place them in an output file. > > > > > > > > Binman uses a DT schema to describe an image, in enough detail that > > > > it can be automatically built from component parts, disassembled, > > > > replaced, listed, etc. > > > > > > > > Images are typically stored in flash, which is why this binding is > > > > targeted at mtd. Previous discussion is at [2] [3]. > > > > > > > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > > > [2] > > > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > > > > > You missed: > > > > > > https://github.com/devicetree-org/dt-schema/pull/110 > > > > > > where I said: We certainly shouldn't duplicate the existing partitions > > > bindings. What's missing from them (I assume we're mostly talking > > > about "fixed-partitions" which has been around forever I think (before > > > me))? > > > > > > To repeat, unless there is some reason binman partitions conflict with > > > fixed-partitions, you need to start there and extend it. From what's > > > posted here, it neither conflicts nor needs extending. > > > > I think at this point I am just hopelessly confused. Have you taken a > > look at the binman schema? [1] > > Why do I need to? That's used for some tool and has nothing to do with a > device's DTB. However, I thought somewhere in this discussion you showed > it under a flash device node. Yes, that is the intent (under a flash node). > Then I care because then it overlaps with > what we already have for partitions. If I misunderstood that, then just > put your schema with your tool. Only users of the tool should care about > the tool's schema. OK. I believe that binman will fit into both camps, since its input is not necessarily fully formed. E.g. if you don't specify the offset of an entry, then it will be packed automatically. But the output is fully formed, in that Binman now knows the offset so can write it to the DT. > > > > > I saw this file, which seems to extend a partition. > > > > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml > > IIRC, that's a different type where partition locations are stored in > the flash, so we don't need location and size in DT. OK. > > > > > I was assuming that I should create a top-level compatible = "binman" > > node, with subnodes like compatible = "binman,bl31-atf", for example. > > I should use the compatible string to indicate the contents, right? > > Yes for subnodes, and we already have some somewhat standard ones for > "u-boot" and "u-boot-env". Though historically, "label" was used. Binman has common properties for all entries, including "compress" which sets the compression algorithm. So perhaps I should start by defining a new binman,bl31-atf which has common properties from an "binman,entry" definition? > > Top-level, meaning the root of the DT? That sound like just something > for the tool, so I don't care, but it doesn't belong in the DTB. Sorry, I mean 'top-level' with respect to the partitions. > > > > > Re extending, what is the minimum I can do? Are you looking for > > something like a "compress" property that indicates that the entry is > > compressed? > > > > I'm really just a bit lost. > > Me too. Regards, Simon
Re: Please pull u-boot-x86 into -next
On Fri, Sep 22, 2023 at 11:04:24PM +0800, Bin Meng wrote: > Hi Tom, > > The following changes since commit 5d2fae79c7d60eaf7f50322e4ec125d2f58544e9: > > Merge tag 'xilinx-for-v2024.01-rc1-v2' of > https://source.denx.de/u-boot/custodians/u-boot-microblaze into next > (2023-09-21 10:51:58 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86.git > tags/x86-pull-20230922 > > for you to fetch changes up to 5728246dfa11400d4f7aa8262ea630d8c09a85b9: > > x86: doc: coreboot: Mention 64-bit Linux distros (2023-09-22 06:05:40 +0800) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
On Fri, Sep 22, 2023 at 11:01:18AM -0600, Simon Glass wrote: > Hi Rob, > > On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote: > > > > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > > > > > Binman[1] is a tool for creating firmware images. It allows you to > > > combine various binaries and place them in an output file. > > > > > > Binman uses a DT schema to describe an image, in enough detail that > > > it can be automatically built from component parts, disassembled, > > > replaced, listed, etc. > > > > > > Images are typically stored in flash, which is why this binding is > > > targeted at mtd. Previous discussion is at [2] [3]. > > > > > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > > [2] > > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > > > You missed: > > > > https://github.com/devicetree-org/dt-schema/pull/110 > > > > where I said: We certainly shouldn't duplicate the existing partitions > > bindings. What's missing from them (I assume we're mostly talking > > about "fixed-partitions" which has been around forever I think (before > > me))? > > > > To repeat, unless there is some reason binman partitions conflict with > > fixed-partitions, you need to start there and extend it. From what's > > posted here, it neither conflicts nor needs extending. > > I think at this point I am just hopelessly confused. Have you taken a > look at the binman schema? [1] Why do I need to? That's used for some tool and has nothing to do with a device's DTB. However, I thought somewhere in this discussion you showed it under a flash device node. Then I care because then it overlaps with what we already have for partitions. If I misunderstood that, then just put your schema with your tool. Only users of the tool should care about the tool's schema. > > I saw this file, which seems to extend a partition. > > Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml IIRC, that's a different type where partition locations are stored in the flash, so we don't need location and size in DT. > > I was assuming that I should create a top-level compatible = "binman" > node, with subnodes like compatible = "binman,bl31-atf", for example. > I should use the compatible string to indicate the contents, right? Yes for subnodes, and we already have some somewhat standard ones for "u-boot" and "u-boot-env". Though historically, "label" was used. Top-level, meaning the root of the DT? That sound like just something for the tool, so I don't care, but it doesn't belong in the DTB. > > Re extending, what is the minimum I can do? Are you looking for > something like a "compress" property that indicates that the entry is > compressed? > > I'm really just a bit lost. Me too. Rob
Re: [PATCH] net: wget: Avoid packet queue overflow
- Ursprüngliche Mail -
> Von: "Tom Rini"
> An: "richard"
> CC: "u-boot" , "Joe Hershberger"
> , "Ramon Fried"
> Gesendet: Donnerstag, 31. August 2023 18:27:03
> Betreff: Re: [PATCH] net: wget: Avoid packet queue overflow
> On Thu, Aug 31, 2023 at 12:27:59PM +0200, Richard Weinberger wrote:
>> - Ursprüngliche Mail -
>> > Von: "richard"
>> > An: u-boot@lists.denx.de
>> > CC: "richard" , "Joe Hershberger" ,
>> > "Ramon Fried"
>> > Gesendet: Donnerstag, 20. Juli 2023 14:51:56
>> > Betreff: [PATCH] net: wget: Avoid packet queue overflow
>>
>> > Make sure to stay within bounds, as a misbehaving HTTP server
>> > can trigger a buffer overflow if not properly handled.
>> >
>> > Cc: Joe Hershberger
>> > Cc: Ramon Fried
>> > Signed-off-by: Richard Weinberger
>> > ---
>> > net/wget.c | 10 +-
>> > 1 file changed, 9 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/net/wget.c b/net/wget.c
>> > index 2dbfeb1a1d5b..8bb4d72db1ae 100644
>> > --- a/net/wget.c
>> > +++ b/net/wget.c
>> > @@ -35,7 +35,8 @@ struct pkt_qd {
>> > * The actual packet bufers are in the kernel space, and are
>> > * expected to be overwritten by the downloaded image.
>> > */
>> > -static struct pkt_qd pkt_q[PKTBUFSRX / 4];
>> > +#define PKTQ_SZ (PKTBUFSRX / 4)
>> > +static struct pkt_qd pkt_q[PKTQ_SZ];
>> > static int pkt_q_idx;
>> > static unsigned long content_length;
>> > static unsigned int packets;
>> > @@ -202,6 +203,13 @@ static void wget_connected(uchar *pkt, unsigned int
>> > tcp_seq_num,
>> >pkt_q[pkt_q_idx].tcp_seq_num = tcp_seq_num;
>> >pkt_q[pkt_q_idx].len = len;
>> >pkt_q_idx++;
>> > +
>> > + if (pkt_q_idx >= PKTQ_SZ) {
>> > + printf("wget: Fatal error, queue overrun!\n");
>> > + net_set_state(NETLOOP_FAIL);
>> > +
>> > + return;
>> > + }
>> >} else {
>> >debug_cond(DEBUG_WGET, "wget: Connected HTTP Header %p\n", pkt);
>> >/* sizeof(http_eom) - 1 is the string length of (http_eom) */
>
> This seems fine and I'll pick it up soon. Thanks!
Is there something I can do to help this merged?
Thanks,
//richard
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Hi Rob, On Fri, 22 Sept 2023 at 10:00, Rob Herring wrote: > > On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > > > Binman[1] is a tool for creating firmware images. It allows you to > > combine various binaries and place them in an output file. > > > > Binman uses a DT schema to describe an image, in enough detail that > > it can be automatically built from component parts, disassembled, > > replaced, listed, etc. > > > > Images are typically stored in flash, which is why this binding is > > targeted at mtd. Previous discussion is at [2] [3]. > > > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > [2] > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > You missed: > > https://github.com/devicetree-org/dt-schema/pull/110 > > where I said: We certainly shouldn't duplicate the existing partitions > bindings. What's missing from them (I assume we're mostly talking > about "fixed-partitions" which has been around forever I think (before > me))? > > To repeat, unless there is some reason binman partitions conflict with > fixed-partitions, you need to start there and extend it. From what's > posted here, it neither conflicts nor needs extending. I think at this point I am just hopelessly confused. Have you taken a look at the binman schema? [1] I saw this file, which seems to extend a partition. Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml I was assuming that I should create a top-level compatible = "binman" node, with subnodes like compatible = "binman,bl31-atf", for example. I should use the compatible string to indicate the contents, right? Re extending, what is the minimum I can do? Are you looking for something like a "compress" property that indicates that the entry is compressed? I'm really just a bit lost. > > I did a bit more research. "fixed-partitions" as a compatible has > "only" been around since 2015. Prior to that, it was implicit with > just partition nodes with addresses (i.e. reg) and that dates back to > 2007. Looks like u-boot only supports the newer form and since 2021. OK Regards, Simon [1] https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
Re: [Question] TI's u-boot.img is built twice
Hi Andrew, On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote: > > On 9/22/23 10:01 AM, Simon Glass wrote: > > Hi Masahiro, > > > > On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote: > >> > >> Hi. > >> > >> Since the TI platform migrated to binman, > >> u-boot.img is built twice. > >> > >> It is created by "mkimage -E", > >> then overwritten by binman. > >> > >> > >> So, the data are embedded in the FIT structure > >> instead of being appended. > >> > >> Is this intentional? > >> > >> To me, it looks weird. > >> > >> > >> > >> > >> To confirm it, apply the following hack. > >> > >> Since u-boot.img is overwritten by binman, > >> copy it to u-boot.img.backup. > >> > >> > >> > >> > >> diff --git a/Makefile b/Makefile > >> index 87f9fc786e..4cffa8a061 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -1112,6 +1112,7 @@ endef > >> # Timestamp file to make sure that binman always runs > >> .binman_stamp: $(INPUTS-y) FORCE > >> ifeq ($(CONFIG_BINMAN),y) > >> + cp u-boot.img u-boot.img.backup > >> $(call if_changed,binman) > >> endif > >> @touch $@ > >> > >> > >> > >> Then, build it for the main core. > >> > >> > >> make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- > >> am64x_evm_a53_defconfig all > >> TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin > >> BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin > >> BINMAN_INDIRS=~/ref/ti-linux-firmware > >> > >> > >> > >> > >> Compare the two files. > >> Run fdtdump to see what happened to them. > >> > >> > >> $ diff -u u-boot.img u-boot.img.backup > >> Binary files u-boot.img and u-boot.img.backup differ > >> > >> > >> $ fdtdump u-boot.img > >> => u-boot and dt are embedded. > >> > >> $ fdtdump u-boot.img.backup > >> => u-boot and dt are appended after the > >> FIT structure > > > > That seems like a bug to me...at some point we might consider building > > u-boot.img with Binman, but for now it is built by the Makefile. > > > > This is not true for K3 as we now use Binman for u-boot.img generation > (we need this as we have a signing step injected at this point). No, no. You must not mess with the outputs of Makefile - create a new file with what you need, e.g. u-boot-ti.img While we could use Binman to produce the .img we are quite a way from doing that as not that many boards have been converted to binman. > > So as Masahiro suggested in the other branch of this thread, we need > to disable the Makefile generation of u-boot.img for K3. > > Neha, > > Can you take this action? I assume you can add it as part of your > work in making the data external again, which would make the u-boot.img > identical to before and hence Makefile version could be disabled at > the same time/series. If you are suggesting that we slowly migrate boards away from generating the .img using Makefile...perhaps that makes sense? I'm not really sure. But in that case we need another Kconfig option. Regards, Simon
Re: [Question] TI's u-boot.img is built twice
On 9/22/23 10:01 AM, Simon Glass wrote: Hi Masahiro, On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote: Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure That seems like a bug to me...at some point we might consider building u-boot.img with Binman, but for now it is built by the Makefile. This is not true for K3 as we now use Binman for u-boot.img generation (we need this as we have a signing step injected at this point). So as Masahiro suggested in the other branch of this thread, we need to disable the Makefile generation of u-boot.img for K3. Neha, Can you take this action? I assume you can add it as part of your work in making the data external again, which would make the u-boot.img identical to before and hence Makefile version could be disabled at the same time/series. Andrew -- Best Regards Masahiro Yamada Regards, Simon
Re: [PATCHv8 00/15] net/lwip: add lwip library for the network stack
On Fri, Sep 22, 2023 at 12:56:58PM +0200, Simon Goldschmidt wrote: > > > On 21.09.2023 18:29, Simon Glass wrote: > > Hi, > > > > On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov wrote: > > > > > > > > > > > > On Wed, 13 Sept 2023 at 19:14, Tom Rini wrote: > > > > > > > > On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote: > > > > > > > > Then if for development you need to pull he history of lwip, > > > > > > > > you can do it with: > > > > > > > > git pull -s subtree lwip master --allow-unrelated-histories > > > > > > > > (but I think nobody will need this.) > > > > > > > > > > > > > > > > New update of the lwip net/lwip/lwip-external dir will be done > > > > > > > > with: > > > > > > > > git pull -s subtree lwip master --allow-unrelated-histories > > > > > > > > --squash > > > > > > > > Squash commit also has to be git format-patch friendly. > > > > > > > > > > > > > > > > If you are ok with that proposal I will send v9 with the first > > > > > > > > patch created with steps above. > > > > > > > > > > > > > > We've gone through this before. The whole purpose of this is not > > > > > > > having to maintain patches. > > > > > > > Simon, instead of "I had problems in the past", can you elaborate > > > > > > > a bit more? > > > > > > > > > > > > > > Tom said he is fine with subtrees instead of submodules and I > > > > > > > know for > > > > > > > a fact EDK2 doesn't have too many issues with submodules. > > > > > > > Their documentation is pretty clear on building and requires > > > > > > > > > > > > > > git clone https://github.com/tianocore/edk2.git > > > > > > > cd edk2 > > > > > > > git submodule update --init > > > > > > > > > > > > > > Perhaps the situation has improved since you had issues? > > > > Nope. > > > > > > > > > > > > > > While I don't really care how you solve this technically, I'd > > > > > > *strongly* > > > > > > be interested for U-Boot to use *unmodified* lwIP sources where an > > > > > > explicit reference to an lwIP commit is used. I'd rather integrate > > > > > > bugfixes for U-Boot into lwIP than having the sources drift apart. > > > > > > > > > > Strongly agree here, we want to use upstream and all the combined > > > > > development and reviews etc rather than forking off and ending up with > > > > > yet another slightly different IP stack. The whole advantage of > > > > > adopting LWIP is the advantage of combined security, features and bugs > > > > > from a wide range of projects :-) > > > > > > > > Yes, this is what I want as well, and why I'm perhaps more agreeable > > > > with the approaches where it's a lot harder for us to start forking > > > > things unintentionally. I gather submodule rather than subtree would be > > > > better for that case? > > > > > > > > -- > > > > Tom > > > > > > > > > Yes, submodule will be a much better solution for us. And I also don't > > > think that today > > > there are any issues with submodules. It works well of OE, RPM and DEB > > > builds, > > > distributions should not have problems with it. > > > > My particular experience is with coreboot. Some problems I have: > > > > 1. Updating the modules doesn't work and I need to reset, try the > > --init thing, fetch things manually, etc. etc. > > 2. In ChromiumOS coreboot we can't use submodules internally since > > each package has its own build script. E.g. we need to build coreboot > > separately from its blobs, fsp, external libraries, etc. At least > > there we can do this, but if U-Boot adopts a submodule for a core > > feature, this is going to create no end of problems. > > 3. It makes it impossible to patch lwip for any fix we need for a release > > 4. We still have to 'fast forward' to a new commit every now and then, > > which really is no easier than doing a merge commit for the changes > > since the last sync, is it? > > > > Really, we need a maintainer for the lwip piece, if we are to adopt > > it. Using submodules is not a substitute for that. > > As an lwIP maintainer, I cannot step up as a maintainer of lwIP in > U-Boot, however, I can assure you I will do my best to work with you on > integrating fixes into upstream lwIP if required. > > Without wanting to promote using submodules: all other examples of lwIP > being copied into another repository have practically never resulted in > bugfixes being sent back to us (ok, that's not 100% true, but we do get > them only once in a while) and being like that, those projects are > facing problems upgrading our stack in turn. I wouldn't want to be a > maintainer of such code, either. So, ideally once we've integrated lwip, I'd be having us track the stable tags, rather than top of tree. Is this what you'd recommend, first of all? And second, assuming we can take STABLE_2_2_0 once it's released how often do you envision updates? I ask since maybe things do move slow enough that if I make some of my local every-time test scripts stop and confirm it's OK to have some changes to net/ (or w
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
On Thu, Sep 21, 2023 at 1:45 PM Simon Glass wrote: > > Binman[1] is a tool for creating firmware images. It allows you to > combine various binaries and place them in an output file. > > Binman uses a DT schema to describe an image, in enough detail that > it can be automatically built from component parts, disassembled, > replaced, listed, etc. > > Images are typically stored in flash, which is why this binding is > targeted at mtd. Previous discussion is at [2] [3]. > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > [2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > [3] https://www.spinics.net/lists/devicetree/msg626149.html You missed: https://github.com/devicetree-org/dt-schema/pull/110 where I said: We certainly shouldn't duplicate the existing partitions bindings. What's missing from them (I assume we're mostly talking about "fixed-partitions" which has been around forever I think (before me))? To repeat, unless there is some reason binman partitions conflict with fixed-partitions, you need to start there and extend it. From what's posted here, it neither conflicts nor needs extending. I did a bit more research. "fixed-partitions" as a compatible has "only" been around since 2015. Prior to that, it was implicit with just partition nodes with addresses (i.e. reg) and that dates back to 2007. Looks like u-boot only supports the newer form and since 2021. Rob
Re: [PATCH 0/4] Add support for sam9x60 curiosity
On Fri, Sep 22, 2023 at 09:00:38AM +0200, Alexander Dahl wrote: > Hello Durai, > > Am Thu, Sep 21, 2023 at 10:36:27PM +0530 schrieb Durai Manickam KR: > > This patch series adds boot from NAND support, configs update and > > fixes. The changes has been done on top of u-boot version 2023.07. > > Well, interesting. I sent patches for NAND flash support on that very > board some weeks ago which were already applied to the at91 custodian > tree: > > https://source.denx.de/u-boot/custodians/u-boot-at91/-/tree/next?ref_type=heads > > Tom already merged that to the mainline next branch. I suggest you > rebase on next. > > Add Eugen to Cc, since he still is officially listed as maintainer of > the at91 stuff. And please make sure that the DTS changes are syncing back from the kernel and note what release they are part of. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] mkimage: also honour -B even without external data
Hi Rasmus,
On Thu, 21 Sept 2023 at 01:57, Rasmus Villemoes
wrote:
>
> On 21/09/2023 03.02, Simon Glass wrote:
> > Hi Rasmus,
> >
> > On Tue, 19 Sept 2023 at 05:37, Rasmus Villemoes
> > wrote:
> >>
> >> In some cases, using the "external data" feature is impossible or
> >> undesirable, but one may still want (or need) the FIT image to have a
> >> certain alignment. Also, given the current 'mkimage -h' output,
> >>
> >> -B => align size in hex for FIT structure and header
> >>
> >> it is quite unexpected for -B to be effectively ignored without -E.
> >>
> >> Signed-off-by: Rasmus Villemoes
> >> ---
> >> tools/fit_image.c | 40
> >> 1 file changed, 40 insertions(+)
> >
> > Reviewed-by: Simon Glass
> >
> > Q below
> >
> >>
> >> diff --git a/tools/fit_image.c b/tools/fit_image.c
> >> index 9fe69ea0d9..2f5b25098a 100644
> >> --- a/tools/fit_image.c
> >> +++ b/tools/fit_image.c
> >> @@ -712,6 +712,42 @@ err:
> >> return ret;
> >> }
> >>
> >> +/**
> >> + * fit_align() - Ensure FIT image has certain alignment
> >> + *
> >> + * This takes a normal FIT file (with embedded data) and increases its
> >> + * size so that it is a multiple of params->bl_len.
> >> + */
> >> +static int fit_align(struct image_tool_params *params, const char *fname)
> >> +{
> >> + int fit_size, new_size;
> >> + int fd;
> >> + struct stat sbuf;
> >> + void *fdt;
> >> + int ret = 0;
> >> + int align_size;
> >> +
> >> + align_size = params->bl_len;
> >> + fd = mmap_fdt(params->cmdname, fname, 0, &fdt, &sbuf, false,
> >> false);
> >> + if (fd < 0)
> >> + return -EIO;
> >> +
> >> + fit_size = fdt_totalsize(fdt);
> >> + new_size = ALIGN(fit_size, align_size);
> >> + fdt_set_totalsize(fdt, new_size);
> >
> > Shouldn't this be fdt_open_into()?
>
> I honestly just copy-pasted fit_extract_data() and shaved it down to the
> part that does the "align the FDT part of the file".
>
> I don't really understand your question. Are you saying this doesn't
> work (or maybe doesn't work in some cases), or are you saying that
> there's a simpler way to do this? For the latter, sure, one doesn't
> really need to parse the whole FDT; we could just
>
> open()
> pread() length from FDT header, convert to cpu-endianness
> length = ALIGN(length)
> pwrite() the new length in fdt-endianness
> ftruncate()
> close()
>
> but I thought it was better to stay closer to how fit_extract_data() was
> done.
I mean that fdt_open_into() does more than just set the size (from
what I can tell). But looking further I see other code which calls
fdt_set_totalsize() so perhaps it is fine.
Regards,
SImon
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Hi Krzysztof,
On Fri, 22 Sept 2023 at 01:02, Krzysztof Kozlowski
wrote:
>
> On 21/09/2023 20:45, Simon Glass wrote:
> > Binman[1] is a tool for creating firmware images. It allows you to
> > combine various binaries and place them in an output file.
> >
> > Binman uses a DT schema to describe an image, in enough detail that
> > it can be automatically built from component parts, disassembled,
> > replaced, listed, etc.
> >
> > Images are typically stored in flash, which is why this binding is
> > targeted at mtd. Previous discussion is at [2] [3].
> >
> > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html
> > [2]
> > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/
> > [3] https://www.spinics.net/lists/devicetree/msg626149.html
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > .../bindings/mtd/partitions/binman.yaml | 50 +++
> > .../bindings/mtd/partitions/binman/entry.yaml | 61 +++
> > .../bindings/mtd/partitions/partitions.yaml | 1 +
> > MAINTAINERS | 5 ++
> > 4 files changed, 117 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/mtd/partitions/binman.yaml
> > create mode 100644
> > Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
> > b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
> > new file mode 100644
> > index 00..c792d5a37b700a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml
> > @@ -0,0 +1,50 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2023 Google LLC
> > +
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Binman firmware layout
> > +
> > +maintainers:
> > + - Simon Glass
> > +
> > +description: |
> > + The binman node provides a layout for firmware, used when packaging
> > firmware
> > + from multiple projects. For now it just supports a very simple set of
> > + features, as a starting point for discussion.
> > +
> > + Documentation for Binman is available at:
> > +
> > + https://u-boot.readthedocs.io/en/latest/develop/package/binman.html
> > +
> > + with the current image-description format at:
> > +
> > +
> > https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#image-description-format
> > +
> > +properties:
> > + compatible:
> > +const: u-boot,binman
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +firmware {
> > + binman {
> > +compatible = "u-boot,binman";
> > +
> > +u-boot {
>
> It does not look like you tested the bindings, at least after quick
> look. Please run `make dt_binding_check` (see
> Documentation/devicetree/bindings/writing-schema.rst for instructions).
> Maybe you need to update your dtschema and yamllint.
Yes this came out of dt-schema and I assumed it was similar. I will rework it.
>
>
> > + size = <0xa>;
> > +};
> > +
> > +atf-bl31 {
> > + offset = <0x10>;
> > +};
> > + };
> > +};
> > diff --git
> > a/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
> > b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
> > new file mode 100644
> > index 00..8003eb4f1a994f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml
> > @@ -0,0 +1,61 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# Copyright 2023 Google LLC
> > +
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mtd/partitions/binman/entry.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Binman entry
> > +
> > +maintainers:
> > + - Simon Glass
> > +
> > +description: |
> > + The entry node specifies a single entry in the firmware.
> > +
> > + Entries have a specific type, such as "u-boot" or "atf-bl31". If the type
> > + is missing, the name is used as the type.
> > +
> > + Note: This definition is intended to be hierarchical, so that entries can
> > + appear in other entries. Schema for that is TBD.
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^[-a-z]+(-[0-9]+)?$"
>
> Why do you need this?
It seemed to be needed in dt-schema. I will drop it.
Regards,
Simon
Re: [NEW FEATURE] RFC: Add Intel GMBUS support
Hello, That is correct. The new later revision Baytrail chips do not reliably initialize video upon boot. I have taken a significant amount of time to analyze the issue. The SOCs produced after 2019 show this issue, although I dont have the specific SKU or stepping details as our production team has not been logging that data. We have several hundred of these SOCs in inventory and are seeing a 20% failure rate resulting in these boards being marked bad. The vendor (Advantech) uses an AMI BIOS on the SOM which we replace with U-Boot. The AMI BIOS is able to reliably initialize the video on the SOCs in question. I have captured the communication on the GMBUS for both the U-Boot initialization and the AMI initialization. Both can be clearly seen running the Intel VBIOS, but the vendors BIOS then additionally gathers data approx 100ms later from the GMBUS to be used to properly initialize the GPU. This can be seen on the google drive link below in the file "Logic-Capture.png". I have also done a register dump comparison between a known good SOC and a known bad SOC. The register "PIPEAFRAMECOUNT", offset 0x70040 can be seen that the monitor does not report back sufficient VSYNC on the newer silicon. This can be seen on the google drive link below in the file "Register-Comparison.png". I have also included the full register dumps in the text files. If you would like I can add the actual Logic capture files for further inspection. The Intel doc "intel-os-gfx-prm-vol10-display.pdf" does not show confidential or NDA so I believe this is a public document that we can use to implement the needed features. Google Drive with referenced data: https://drive.google.com/drive/folders/1OpXT7Faks2sfIKBIv-JmhEYeLzFYwvmF?usp=sharing Eric Schikschneit Senior Embedded Linux Engineer III NovaTech, LLC 13555 W. 107th Street | Lenexa, LS 66215 O: 913.451.1880 novatechautomation.com | NovaTechLinkedIn Receipt of this email implies compliance with our terms and conditions. From: Bin Meng Sent: Thursday, September 21, 2023 8:14 PM To: Eric Schikschneit; Simon Glass Cc: u-boot@lists.denx.de Subject: Re: [NEW FEATURE] RFC: Add Intel GMBUS support +Simon Hi Eric, On Fri, Sep 22, 2023 at 6:10 AM Eric Schikschneit wrote: > > I have begun working on adding support for the Intel Graphics Management bus > to U-Boot. Currently the x86 bring up process (as explored on the Baytrail > series of Atom SOCs) relys on the Intel Video BIOS to do all setup and > configuration of the GPU. This method of adding video support works on > earlier versions of the silicon. With later versions I have found that the > OEM BIOS needs to capture the monitor data over the GMBUS in order to > initialize the GPU properly. I have logic analyzer captures available for > anyone who is curious. My purpose for this patch is a skeleton placeholder > that I will be working from, and I am asking for community collaboration with > this. I have hardware available for testing as needed, and some details can > be provided upon request. Would you share the documentation that describes the Intel GM bus, if publicly available? Based on the info you provided, did you mean with later new revision BayTrail chips, the video bios initialization is not enough in U-Boot? AFAIU, the U-Boot BayTrail support relies on Intel FSP to do any chipset-specific work, including the video bios setup. Regards, Bin
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
Hi Alper, On Fri, 22 Sept 2023 at 07:57, Alper Nebi Yasak wrote: > > On 2023-09-21 21:45 +03:00, Simon Glass wrote: > > Binman[1] is a tool for creating firmware images. It allows you to > > combine various binaries and place them in an output file. > > > > Binman uses a DT schema to describe an image, in enough detail that > > it can be automatically built from component parts, disassembled, > > replaced, listed, etc. > > > > Images are typically stored in flash, which is why this binding is > > targeted at mtd. Previous discussion is at [2] [3]. > > > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > > [2] > > https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > > > Signed-off-by: Simon Glass > > --- > > > > .../bindings/mtd/partitions/binman.yaml | 50 +++ > > .../bindings/mtd/partitions/binman/entry.yaml | 61 +++ > > .../bindings/mtd/partitions/partitions.yaml | 1 + > > MAINTAINERS | 5 ++ > > 4 files changed, 117 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > create mode 100644 > > Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml > > This doesn't match the schema in [2], but seems more like v1 of that. Is > that intentional? Yes. Based on discussions with Rob, the idea of setting a general format seems to be too ambitious, at least for now. Regards, Simon
Please pull u-boot-x86 into -next
Hi Tom, The following changes since commit 5d2fae79c7d60eaf7f50322e4ec125d2f58544e9: Merge tag 'xilinx-for-v2024.01-rc1-v2' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next (2023-09-21 10:51:58 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86.git tags/x86-pull-20230922 for you to fetch changes up to 5728246dfa11400d4f7aa8262ea630d8c09a85b9: x86: doc: coreboot: Mention 64-bit Linux distros (2023-09-22 06:05:40 +0800) - Add bootstd support to 64-bit efi payload - Fix a bug of missing setting size of initrd in pxeboot - Allow Python packages to be dropped - Reland "x86: Move FACP table into separate functions" - Fixes for chromebook_link64 and chromebook_samus_tpl - Fixes and improvements for coreboot - x86 documentation updates Andy Shevchenko (1): x86: Prevent from missing the FADT chaining Simon Glass (35): Allow Python packages to be dropped x86: coreboot: Avoid a declaration after a label Reland "x86: Move FACP table into separate functions"" x86: doc: Document the -cdrom issues I ran into dm: core: Allow marking driver model as dead x86: broadwell: Show the memory delay x86: Add some log categories x86: samus_tpl: Correct text base and alloc sizes x86: spl: Change the condition for copying U-Boot to RAM x86: broadwell: Avoid initing the CPU twice x86: broadwell: Set up MTRRs x86: dm: Mark driver model as dead when disabling CAR x86: doc: Update the list of supported Chromebooks x86: coreboot: Document cbmem console struct x86: Update cbmem driver x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros Thomas Mittelstaedt (3): x86: efi-payload64: Add support for SCSI devices x86: efi-payload64: Add bootstd support x86: pxeboot: bugfix: Set variable for size of initrd Troy Kisky (1): x86: cpu: i386: cpu: only set pci_ram_top if CONFIG_IS_ENABLED(PCI) Makefile| 9 +++ arch/arm/include/asm/global_data.h | 3 + arch/riscv/include/asm/global_data.h| 3 + arch/sandbox/include/asm/global_data.h | 1 + arch/x86/cpu/apollolake/acpi.c | 13 ++-- arch/x86/cpu/baytrail/acpi.c| 23 +--- arch/x86/cpu/broadwell/cpu.c| 10 ++-- arch/x86/cpu/broadwell/sdram.c | 2 + arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c| 16 ++--- arch/x86/cpu/i386/cpu.c | 2 +- arch/x86/cpu/intel_common/mrc.c | 18 +- arch/x86/cpu/quark/acpi.c | 23 +--- arch/x86/cpu/tangier/acpi.c | 23 +--- arch/x86/cpu/x86_64/cpu.c | 7 +++ arch/x86/dts/chromebook_samus.dts | 1 + arch/x86/dts/coreboot.dts | 1 + arch/x86/include/asm/acpi_table.h | 2 - arch/x86/include/asm/coreboot_tables.h | 17 +- arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/acpi_table.c | 15 - arch/x86/lib/coreboot/cb_sysinfo.c | 1 + arch/x86/lib/init_helpers.c | 7 +-- arch/x86/lib/spl.c | 5 +- arch/x86/lib/tables.c | 3 + arch/x86/lib/tpl.c | 2 + board/Marvell/mvebu_armada-37xx/board.c | 3 +- board/coreboot/coreboot/coreboot.c | 14 ++--- boot/bootdev-uclass.c | 27 + boot/pxe_utils.c| 2 +- common/spl/spl.c| 2 +- configs/chromebook_samus_tpl_defconfig | 4 +- configs/coreboot64_defconfig| 25 configs/coreboot_defconfig | 21 --- configs/efi-x86_payload64_defconfig | 6 +- doc/arch/index.rst | 2 +- doc/arch/x86/index.rst | 12 doc/arch/x
Re: [Question] TI's u-boot.img is built twice
Hi Masahiro, On Fri, 22 Sept 2023 at 01:19, Masahiro Yamada wrote: > > On Fri, Sep 22, 2023 at 2:27 PM Neha Malcom Francis wrote: > > > > Hi Masahiro > > > > On 21/09/23 21:06, Masahiro Yamada wrote: > > > Hi. > > > > > > Since the TI platform migrated to binman, > > > u-boot.img is built twice. > > > > > > It is created by "mkimage -E", > > > then overwritten by binman. > > > > > > > > > So, the data are embedded in the FIT structure > > > instead of being appended. > > > > > > Is this intentional? > > > > > > To me, it looks weird. > > > > > > > > > > I haven't added the fit,external-offset property in the binman.dtsi so it > > was > > not appended as external data and I did not find reason to. Is there any > > benefit > > in having the data appended than embedded? > > > > Placing payload data outside the FIT structure is a U-Boot hack. No, it isn't a hack. It is part of the specification[1]. [..] Regards, Simon [1] https://github.com/open-source-firmware/flat-image-tree/releases/tag/v0.8
Re: [Question] TI's u-boot.img is built twice
Hi Masahiro, On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote: > > Hi. > > Since the TI platform migrated to binman, > u-boot.img is built twice. > > It is created by "mkimage -E", > then overwritten by binman. > > > So, the data are embedded in the FIT structure > instead of being appended. > > Is this intentional? > > To me, it looks weird. > > > > > To confirm it, apply the following hack. > > Since u-boot.img is overwritten by binman, > copy it to u-boot.img.backup. > > > > > diff --git a/Makefile b/Makefile > index 87f9fc786e..4cffa8a061 100644 > --- a/Makefile > +++ b/Makefile > @@ -1112,6 +1112,7 @@ endef > # Timestamp file to make sure that binman always runs > .binman_stamp: $(INPUTS-y) FORCE > ifeq ($(CONFIG_BINMAN),y) > + cp u-boot.img u-boot.img.backup > $(call if_changed,binman) > endif > @touch $@ > > > > Then, build it for the main core. > > > make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- >am64x_evm_a53_defconfig all >TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin >BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin >BINMAN_INDIRS=~/ref/ti-linux-firmware > > > > > Compare the two files. > Run fdtdump to see what happened to them. > > > $ diff -u u-boot.img u-boot.img.backup > Binary files u-boot.img and u-boot.img.backup differ > > > $ fdtdump u-boot.img > => u-boot and dt are embedded. > > $ fdtdump u-boot.img.backup > => u-boot and dt are appended after the >FIT structure That seems like a bug to me...at some point we might consider building u-boot.img with Binman, but for now it is built by the Makefile. > > > > -- > Best Regards > Masahiro Yamada Regards, Simon
Re: [PATCH] dt-bindings: mtd: Add a schema for binman
On 2023-09-21 21:45 +03:00, Simon Glass wrote: > Binman[1] is a tool for creating firmware images. It allows you to > combine various binaries and place them in an output file. > > Binman uses a DT schema to describe an image, in enough detail that > it can be automatically built from component parts, disassembled, > replaced, listed, etc. > > Images are typically stored in flash, which is why this binding is > targeted at mtd. Previous discussion is at [2] [3]. > > [1] https://u-boot.readthedocs.io/en/stable/develop/package/binman.html > [2] https://lore.kernel.org/u-boot/20230821180220.2724080-3-...@chromium.org/ > [3] https://www.spinics.net/lists/devicetree/msg626149.html > > Signed-off-by: Simon Glass > --- > > .../bindings/mtd/partitions/binman.yaml | 50 +++ > .../bindings/mtd/partitions/binman/entry.yaml | 61 +++ > .../bindings/mtd/partitions/partitions.yaml | 1 + > MAINTAINERS | 5 ++ > 4 files changed, 117 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman/entry.yaml This doesn't match the schema in [2], but seems more like v1 of that. Is that intentional?
Re: [PATCH 1/1] riscv: set fdtfile on VisionFive 2
Hello Leo,
This patch seems only landed in next branch, not master. It is seriously
needed to make visionfive 2 working properly. Could you merge it to
master branch?
Best regards,
Shengyu
Multiple revisions of the StarFive VisionFive 2 board exist. They can be
identified by reading their EEPROM.
Linux uses two differently named device-tree files. To load the correct
device-tree we need to set $fdtfile to the device-tree file name that
matches the board revision.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Leo Yu-Chi Liang
Tested-by: Milan P. Stanić
---
arch/riscv/Kconfig| 1 +
.../visionfive2/starfive_visionfive2.c| 43 ++-
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6771d8d919..1c62c2345b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -26,6 +26,7 @@ config TARGET_SIFIVE_UNMATCHED
config TARGET_STARFIVE_VISIONFIVE2
bool "Support StarFive VisionFive2 Board"
+ select BOARD_LATE_INIT
config TARGET_TH1520_LPI4A
bool "Support Sipeed's TH1520 Lichee PI 4A Board"
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index d609262b67..05d8d2d657 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -5,14 +5,20 @@
*/
#include
-#include
-#include
#include
#include
+#include
+#include
+#include
+#include
#include
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
+#define FDTFILE_VISIONFIVE2_1_2A \
+ "starfive/jh7110-starfive-visionfive-2-v1.2a.dtb"
+#define FDTFILE_VISIONFIVE2_1_3B \
+ "starfive/jh7110-starfive-visionfive-2-v1.3b.dtb"
/* enable U74-mc hart1~hart4 prefetcher */
static void enable_prefetcher(void)
@@ -33,6 +39,31 @@ static void enable_prefetcher(void)
}
}
+/**
+ * set_fdtfile() - set the $fdtfile variable based on the board revision
+ */
+static void set_fdtfile(void)
+{
+ u8 version;
+ const char *fdtfile;
+
+ version = get_pcb_revision_from_eeprom();
+ switch (version) {
+ case 'a':
+ case 'A':
+ fdtfile = FDTFILE_VISIONFIVE2_1_2A;
+ break;
+
+ case 'b':
+ case 'B':
+ default:
+ fdtfile = FDTFILE_VISIONFIVE2_1_3B;
+ break;
+ };
+
+ env_set("fdtfile", fdtfile);
+}
+
int board_init(void)
{
enable_caches();
@@ -41,6 +72,14 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+ if (CONFIG_IS_ENABLED(ID_EEPROM))
+ set_fdtfile();
+
+ return 0;
+}
+
void *board_fdt_blob_setup(int *err)
{
*err = 0;
[PATCH v2] arm64: versal: Add SelectMAP boot mode identification
The SelectMAP configuration interface provides an 8-bit, 16-bit or
32-bit bidirectional data bus interface to the Versal FPGA
configuration logic that can be used for both configuration and
readback.
A connected microcontoller to the SelectMAP interface can load boot
image with bitstream, TF-A (ARM Trusted Firmware) and U-Boot.
This commit adds the missing identification of the SelectMAP mode.
Signed-off-by: Leszek Polak
Reviewed-by: Stefan Roese
Cc: Michal Simek
Cc: Stefan Roese
---
v2:
- Drop assignment of 'mode' as selectmap is not be supported
by distro boot
---
arch/arm/mach-versal-net/include/mach/hardware.h | 1 +
arch/arm/mach-versal/include/mach/hardware.h | 1 +
board/xilinx/versal-net/board.c | 3 +++
board/xilinx/versal/board.c | 4
4 files changed, 9 insertions(+)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 9bddb8b007..767cdd3686 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -66,6 +66,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/arch/arm/mach-versal/include/mach/hardware.h
b/arch/arm/mach-versal/include/mach/hardware.h
index 000af974e8..9d1c2f0dcf 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -82,6 +82,7 @@ struct crp_regs {
#define EMMC_MODE 0x0006
#define USB_MODE 0x0007
#define OSPI_MODE 0x0008
+#define SELECTMAP_MODE 0x000A
#define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index f0d2224b33..651b7d24d7 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -260,6 +260,9 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 60bf37d3c9..26b4c7bf39 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -182,6 +182,9 @@ int board_late_init(void)
mode = "mmc";
bootseq = dev_seq(dev);
break;
+ case SELECTMAP_MODE:
+ puts("SELECTMAP_MODE\n");
+ break;
case SD_MODE:
puts("SD_MODE\n");
if (uclass_get_device_by_name(UCLASS_MMC,
@@ -298,6 +301,7 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_SPI_FLASH;
return ENVL_NOWHERE;
case JTAG_MODE:
+ case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
--
2.34.1
Re: [PATCHv9 01/15] submodule: add lwIP as git submodule
On 2023-09-21 18:39 +03:00, Tom Rini wrote: > On Wed, Sep 20, 2023 at 07:03:07PM -0600, Simon Glass wrote: >> Hi Maxim, >> >> On Thu, 14 Sept 2023 at 10:20, Maxim Uvarov wrote: >>> >>> add external lwIP library as a git submodule. If we add submodules, they should point to mirrors on source.denx.de, in case upstream repositories vanish. >> >> Oh dear...what is the motivation for using a submodule? > > That we don't have a better alternative. Using "git subtree" has it's > own problems and won't make things overall better. I need to raise a technical concern here, buildman uses "git worktree" to save disk space (provides git functionality in .bm-work source copies without copying .git into N such dirs), and there's this warning in the git-worktree(1) manual page: Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject. It's been there for a while, and I don't know what the current status is. But if we decide to add submodules we'll most likely need to rework some stuff in buildman to support that. Besides that, I've been running into git submodule problems in other projects and don't like it at all. It doesn't seem to play nice with even fundamental git features/commands like git pull and git checkout. >> Our current stack is nicely integrated into U-Boot. This would make >> moving between development branches much more painful. > > It really shouldn't matter in that case. Unless you're trying out a new > lwip upstream commit, nothing changes in there. It _may_ mean that if > we want to update lwip it's not something that can be staged first in > the -next branch but instead something to pull in just after release, > but I'd need to see how smart or not git is today about things like > that. > >> I would much prefer that we bring in the necessary code, and that you >> send a patch every 3 months or so to deal with updates, making sure >> there are no code-size regressions. > > And I much prefer something that will make sure that we don't start > making changes in upstream code and diverging. I don't think there's a > mechanic short of submodule that will do that for us. Coreboot clones some payload repositories in Makefiles (although they use submodules a lot as well). Another alternative is having buildman manage external sources like how binman can download sources and build the tools it needs. Or maybe just assume the source already exists at ../lwip/ or $LWIP_SOURCE and raise an error if we can't find it there. I admit these might sound worse than git submodules, but at least any problems with them will be our fault and would be solvable in U-Boot instead of requiring a trip to upstream git.
bootefi with initramfs
Hi all, I am currently in the process of booting the Linux kernel using the U-boot 'bootefi' command. However, I am facing an issue with the root file system (rootfs) disk, which is not functioning properly. As a solution, I am considering providing an initramfs to the kernel. The problem I encountered is that the 'bootefi' command does not accept an argument for the initramfs, unlike the 'bootm' command. Upon further investigation, I noticed that the kernel attempts to load the initramfs from the EFI tables. However, I have been unable to find any information on how to define an initramfs table for EFI. I would greatly appreciate any suggestions or guidance regarding this matter. Thank you, Sam Song
[NEW FEATURE] RFC: Add Intel GMBUS support
I have begun working on adding support for the Intel Graphics Management bus to
U-Boot. Currently the x86 bring up process (as explored on the Baytrail series
of Atom SOCs) relys on the Intel Video BIOS to do all setup and configuration
of the GPU. This method of adding video support works on earlier versions of
the silicon. With later versions I have found that the OEM BIOS needs to
capture the monitor data over the GMBUS in order to initialize the GPU
properly. I have logic analyzer captures available for anyone who is curious.
My purpose for this patch is a skeleton placeholder that I will be working
from, and I am asking for community collaboration with this. I have hardware
available for testing as needed, and some details can be provided upon request.
Eric Schikschneit
Senior Embedded Linux Engineer III
NovaTech, LLC
13555 W. 107th Street | Lenexa, LS 66215
O: 913.451.1880
novatechautomation.com | NovaTechLinkedIn
Receipt of this email implies compliance with our terms and conditions.From 66ef768fce7c41fd784b622b92c07f201982a678 Mon Sep 17 00:00:00 2001
From: Eric Schikschneit
Date: Thu, 21 Sep 2023 16:11:23 -0500
Subject: [PATCH] WIP: Add Intel GMBUS support
This will allow uboot to communicate over the GMBUS to an attached
monitor to gather EDID information in order to properly setup video
during the boot process.
This is being tested as it is being developed on an Intel Bayrail SOC.
Signed-off-by: Eric Schikschneit
---
drivers/video/Kconfig | 5 +++
drivers/video/Makefile| 1 +
drivers/video/intel_gmbus.c | 77 +++
drivers/video/psb_intel_reg.h | 55 +
4 files changed, 138 insertions(+)
create mode 100644 drivers/video/intel_gmbus.c
create mode 100644 drivers/video/psb_intel_reg.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index ed0b21f2a7..7bc433d9af 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -683,4 +683,9 @@ config VIDEO_DT_SIMPLEFB
The video output is initialized by U-Boot, and kept by the
kernel.
+config VIDEO_INTEL_BAYTRAIL
+ bool "Enable GMBUS support for Intel Baytrail SOCs"
+ help
+ Enables support for interfacing with monitors to gather EDID
+ information to aid video bringup.
endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 0f41a23193..4ff710e41a 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_VIDEO_SIMPLE) += simplefb.o
obj-$(CONFIG_VIDEO_TEGRA20) += tegra.o
obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
obj-$(CONFIG_VIDEO_VESA) += vesa.o
+obj-$(CONFIG_VIDEO_INTEL_BAYTRAIL) += intel_gmbus.o
obj-y += bridge/
obj-y += sunxi/
diff --git a/drivers/video/intel_gmbus.c b/drivers/video/intel_gmbus.c
new file mode 100644
index 00..e23e8030f2
--- /dev/null
+++ b/drivers/video/intel_gmbus.c
@@ -0,0 +1,77 @@
+/* This file is loosly based off of the file found in the linux kernel,
+ * modified for use with u-boot.
+ * File in kernel: drivers/gpu/drm/gma500/intel_gmbus.c
+ *
+ * Authors:
+ * Eric Schikschneit
+
+#include "psb_intel_reg.h"
+
+// struct intel_gpio {
+// struct i2c_adapter adapter;
+// struct i2c_algo_bit_data algo;
+// struct drm_psb_private *dev_priv;
+// u32 reg;
+// };
+
+#define GMBUS_REG_READ(reg) ioread32(dev_priv->gmbus_reg + (reg))
+#define GMBUS_REG_WRITE(reg, val) iowrite32((val), dev_priv->gmbus_reg + (reg))
+
+void intel_gmbus_i2c_reset() {
+}
+
+static void intel_gmbus_i2c_quirk_set() {
+}
+
+static u32 intel_gmbus_get_reserved() {
+return 0;
+}
+
+static void intel_gmbus_set_clock (void *data, int state_high) {
+}
+
+static int intel_gmbus_get_clock(void *data) {
+return 0;
+}
+
+static void intel_gmbus_set_data(void *data, int state_high) {
+}
+
+static int intel_gmbus_get_data(void *data) {
+return 0;
+}
+
+static struct i2c_adapter * intel_gmbus_gpio_create() { // Use u-boot compatible struct
+return;
+}
+
+static int intel_gmbus_i2c_quirk_xfer() {
+return 0;
+}
+
+static int intel_gmbus_xfer() {
+return 0;
+}
+
+static u32 intel_gmbus_func() {
+return 0;
+}
+
+void intel_gmbus_setup() {
+}
+
+void intel_gmbus_set_speed(struct pci_dev_t *dev) {
+}
+
+void intel_gmbus_get_speed(struct pci_dev_t *dev) {
+}
+
+void intel_gmbus_force_bit() {
+}
+
+void intel_gmbus_teardown() {
+}
+
diff --git a/drivers/video/psb_intel_reg.h b/drivers/video/psb_intel_reg.h
new file mode 100644
index 00..51ba722177
--- /dev/null
+++ b/drivers/video/psb_intel_reg.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2009, Intel Corporation.
+ * Modified for uboot by Eric Schikschneit (eric.schikschn...@novatechautomation.com)
+ */
+#ifndef __PSB_INTEL_REG_H__
+#define __PSB_INTEL_REG_H__
+
+#define GMBUS0 0x5100 /* clock/port select */
+#define GMBUS_RATE_100KHZ (0<<8)
+#define GMBUS_RATE_50KHZ (1<<8)
+#define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
+#define
Re: [PATCHv9 01/15] submodule: add lwIP as git submodule
On 21.09.2023 09:09, Maxim Uvarov wrote: On Thu, 21 Sept 2023 at 07:06, Simon Glass wrote: Hi Maxim, On Thu, 14 Sept 2023 at 10:20, Maxim Uvarov wrote: add external lwIP library as a git submodule. Oh dear...what is the motivation for using a submodule? Our current stack is nicely integrated into U-Boot. This would make moving between development branches much more painful. I would much prefer that we bring in the necessary code, and that you send a patch every 3 months or so to deal with updates, making sure there are no code-size regressions. Regards, Simon I would like the project maintainer to make the final decision. And this time I'm trying to understand how lwIP maintenance works. And how long does it take to merge a patch to lwip. For the latest Ilias comment I did a fix to lwip, which is pending. https://lists.nongnu.org/archive/html/lwip-devel/2023-09/msg4.html and created a bug with the same patch: https://savannah.nongnu.org/bugs/?64697 And it's interesting when patches get merged. Also there is a long list of not yet accepted patches (86 open items): https://savannah.nongnu.org/patch/?group=lwip The list of open bugs and patches has largely to do with users sending things in the form of "this or that doesn't work for me, here's my poor quality patch that fixes exactly my issue". We simply don't have the manpower to check all that for correctness and for not breaking other use cases. Nearly noone sends a working test case for things. But we're trying to catch up. I am afraid that if lwip patch acceptance will be too slow it also can slow down U-Boot development. Our response time greatly varies and greatly depends on how the supplier of a patch works with us. Many bugs in our bug tracker are like "this doesn't work for me, please do my work and fix it for me". Nearly noone even sends so much as a working reproduction. We're not a project like that. We need people needing things fixed to implement the fix. However, if you're talking about accepting and pushing code that easy for us to review, clear, and in good form, accepting should normally be a matter of some days. Regards, Simon
Re: [PATCHv8 00/15] net/lwip: add lwip library for the network stack
On 21.09.2023 18:29, Simon Glass wrote: Hi, On Wed, 13 Sept 2023 at 07:35, Maxim Uvarov wrote: On Wed, 13 Sept 2023 at 19:14, Tom Rini wrote: On Wed, Sep 13, 2023 at 11:06:13AM +0100, Peter Robinson wrote: Then if for development you need to pull he history of lwip, you can do it with: git pull -s subtree lwip master --allow-unrelated-histories (but I think nobody will need this.) New update of the lwip net/lwip/lwip-external dir will be done with: git pull -s subtree lwip master --allow-unrelated-histories --squash Squash commit also has to be git format-patch friendly. If you are ok with that proposal I will send v9 with the first patch created with steps above. We've gone through this before. The whole purpose of this is not having to maintain patches. Simon, instead of "I had problems in the past", can you elaborate a bit more? Tom said he is fine with subtrees instead of submodules and I know for a fact EDK2 doesn't have too many issues with submodules. Their documentation is pretty clear on building and requires git clone https://github.com/tianocore/edk2.git cd edk2 git submodule update --init Perhaps the situation has improved since you had issues? Nope. While I don't really care how you solve this technically, I'd *strongly* be interested for U-Boot to use *unmodified* lwIP sources where an explicit reference to an lwIP commit is used. I'd rather integrate bugfixes for U-Boot into lwIP than having the sources drift apart. Strongly agree here, we want to use upstream and all the combined development and reviews etc rather than forking off and ending up with yet another slightly different IP stack. The whole advantage of adopting LWIP is the advantage of combined security, features and bugs from a wide range of projects :-) Yes, this is what I want as well, and why I'm perhaps more agreeable with the approaches where it's a lot harder for us to start forking things unintentionally. I gather submodule rather than subtree would be better for that case? -- Tom Yes, submodule will be a much better solution for us. And I also don't think that today there are any issues with submodules. It works well of OE, RPM and DEB builds, distributions should not have problems with it. My particular experience is with coreboot. Some problems I have: 1. Updating the modules doesn't work and I need to reset, try the --init thing, fetch things manually, etc. etc. 2. In ChromiumOS coreboot we can't use submodules internally since each package has its own build script. E.g. we need to build coreboot separately from its blobs, fsp, external libraries, etc. At least there we can do this, but if U-Boot adopts a submodule for a core feature, this is going to create no end of problems. 3. It makes it impossible to patch lwip for any fix we need for a release 4. We still have to 'fast forward' to a new commit every now and then, which really is no easier than doing a merge commit for the changes since the last sync, is it? Really, we need a maintainer for the lwip piece, if we are to adopt it. Using submodules is not a substitute for that. As an lwIP maintainer, I cannot step up as a maintainer of lwIP in U-Boot, however, I can assure you I will do my best to work with you on integrating fixes into upstream lwIP if required. Without wanting to promote using submodules: all other examples of lwIP being copied into another repository have practically never resulted in bugfixes being sent back to us (ok, that's not 100% true, but we do get them only once in a while) and being like that, those projects are facing problems upgrading our stack in turn. I wouldn't want to be a maintainer of such code, either. Regards, Simon
[PATCH v3 5/6] arm: dts: k3-j721e-r5: Clean up inclusion hierarchy
Get rid of k3-j721e-r5-*-u-boot.dtsi as it is not
necessary. Change the inclusion hierarchy to be as follows:
k3-j721e-.dts---
-
-->k3-j721e-r5-.dts
-
k3-j721e--u-boot.dtsi---
Reason for explicitly mentioning the inclusion of -u-boot.dtsi in code
although it could've been automatically done by U-Boot is to resolve
some of the dependencies that R5 file requires.
Also remove duplicate phandles while making this shift as well as remove
firmware-loader as it serves no purpose without "phandlepart" property.
Signed-off-by: Neha Malcom Francis
---
.../k3-j721e-r5-common-proc-board-u-boot.dtsi | 29
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 38 +++
arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi | 31
arch/arm/dts/k3-j721e-r5-sk.dts | 47 ---
4 files changed, 16 insertions(+), 129 deletions(-)
delete mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
delete mode 100644 arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
deleted file mode 100644
index f9746d33ec..00
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi
+++ /dev/null
@@ -1,29 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
- */
-
-#include "k3-j721e-common-proc-board-u-boot.dtsi"
-
-/ {
- chosen {
- firmware-loader = &fs_loader0;
- };
-
- aliases {
- remoteproc0 = &sysctrler;
- remoteproc1 = &a72_0;
- };
-
- fs_loader0: fs_loader@0 {
- bootph-all;
- compatible = "u-boot,fs-loader";
- };
-};
-
-&tps659413a {
- esm: esm {
- compatible = "ti,tps659413-esm";
- bootph-pre-ram;
- };
-};
diff --git a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
index 32f71e9b6a..7bb5ce775c 100644
--- a/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j721e-r5-common-proc-board.dts
@@ -5,10 +5,10 @@
/dts-v1/;
-#include "k3-j721e-som-p0.dtsi"
+#include "k3-j721e-common-proc-board.dts"
#include "k3-j721e-ddr-evm-lp4-4266.dtsi"
#include "k3-j721e-ddr.dtsi"
-#include "k3-j721e-binman.dtsi"
+#include "k3-j721e-common-proc-board-u-boot.dtsi"
#include
/ {
@@ -198,27 +198,6 @@
>;
};
- main_usbss0_pins_default: main_usbss0_pins_default {
- pinctrl-single,pins = <
- J721E_IOPAD(0x290, PIN_OUTPUT, 0) /* (U6) USB0_DRVVBUS
*/
- J721E_IOPAD(0x210, PIN_INPUT, 7) /* (W3)
MCAN1_RX.GPIO1_3 */
- >;
- };
-
- main_mmc1_pins_default: main_mmc1_pins_default {
- pinctrl-single,pins = <
- J721E_IOPAD(0x254, PIN_INPUT, 0) /* (R29) MMC1_CMD */
- J721E_IOPAD(0x250, PIN_INPUT, 0) /* (P25) MMC1_CLK */
- J721E_IOPAD(0x2ac, PIN_INPUT, 0) /* (P25) MMC1_CLKLB */
- J721E_IOPAD(0x24c, PIN_INPUT, 0) /* (R24) MMC1_DAT0 */
- J721E_IOPAD(0x248, PIN_INPUT, 0) /* (P24) MMC1_DAT1 */
- J721E_IOPAD(0x244, PIN_INPUT, 0) /* (R25) MMC1_DAT2 */
- J721E_IOPAD(0x240, PIN_INPUT, 0) /* (R26) MMC1_DAT3 */
- J721E_IOPAD(0x258, PIN_INPUT, 0) /* (P23) MMC1_SDCD */
- J721E_IOPAD(0x25c, PIN_INPUT, 0) /* (R28) MMC1_SDWP */
- >;
- };
-
main_i2c0_pins_default: main-i2c0-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0x220, PIN_INPUT_PULLUP, 0) /* (AC5)
I2C0_SCL */
@@ -300,6 +279,11 @@
bootph-pre-ram;
};
};
+
+ esm: esm {
+ compatible = "ti,tps659413-esm";
+ bootph-pre-ram;
+ };
};
};
@@ -424,14 +408,6 @@
assigned-clocks = <&serdes0 CDNS_SIERRA_PLL_CMNLC>, <&serdes0
CDNS_SIERRA_PLL_CMNLC1>;
assigned-clock-parents = <&wiz0_pll1_refclk>, <&wiz0_pll1_refclk>;
- serdes0_pcie_link: link@0 {
- reg = <0>;
- cdns,num-lanes = <1>;
- #phy-cells = <0>;
- cdns,phy-type = ;
- resets = <&serdes_wiz0 1>;
- };
-
serdes0_qsgmii_link: phy@1 {
reg = <1>;
cdns,num-lanes = <1>;
diff --git a/arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi
deleted file mode 100644
index 733d69cd00..00
--- a/arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi
+++ /dev/null
@@ -1,31 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Cop
[PATCH v3 4/6] configs: j721e: Remove HBMC_AM654 config
Kernel commit d93036b47f35 ("arm64: dts: ti: k3-j721e-mcu_wakeup: Add
HyperBus node") was merged to kernel without its dependent patch [1].
Similar fix is needed in U-Boot, and hbmc currently breaks boot. Till
this gets fixed in U-Boot, disable the config by default so that the
hbmc probe that happens in board/ti/j721e/evm.c will not take place
and lead to boot failure.
[1] https://lore.kernel.org/all/20230424184810.29453-1-...@ti.com/
Signed-off-by: Neha Malcom Francis
---
configs/j721e_evm_a72_defconfig | 1 -
configs/j721e_evm_r5_defconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 214fa8b2f3..beea948c4e 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -140,7 +140,6 @@ CONFIG_CFI_FLASH=y
CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_STMICRO=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index cf7bc872b5..d974be275f 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -127,7 +127,6 @@ CONFIG_CFI_FLASH=y
CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
CONFIG_FLASH_CFI_MTD=y
CONFIG_SYS_FLASH_CFI=y
-CONFIG_HBMC_AM654=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPI_FLASH_STMICRO=y
--
2.34.1
[PATCH v3 3/6] drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up
When setting up boot media to load the TIFS binary in legacy boot flow
(followed by J721E), get_timer() is called which calls dm_timer_init()
which then gets the tick-timer: mcu_timer0. mcu_timer0 uses k3_clks
(clock controller) and k3_pds (power controller) from the dmsc node that
forces probe of the ti_sci driver of TIFS that hasn't been loaded yet!
Running ti_sci_cmd_get_revision from the probe leads to panic since no
TIFS and board config binaries have been loaded yet. Resolve this by
moving ti_sci_cmd_get_revision to ti_sci_get_handle_from_sysfw as a
common point of invocation for both legacy and combined boot flows.
Before doing this, it is important to go through whether any sync points
exist where revision is needed before ti_sci_get_handle_from_sysfw is
invoked. Going through the code along with boot tests on both flows
ensures that there are none.
Signed-off-by: Neha Malcom Francis
---
drivers/firmware/ti_sci.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 72f572d824..45406e24d2 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2690,6 +2690,8 @@ static void ti_sci_setup_ops(struct ti_sci_info *info)
const
struct ti_sci_handle *ti_sci_get_handle_from_sysfw(struct udevice *sci_dev)
{
+ int ret;
+
if (!sci_dev)
return ERR_PTR(-EINVAL);
@@ -2703,6 +2705,11 @@ struct ti_sci_handle
*ti_sci_get_handle_from_sysfw(struct udevice *sci_dev)
if (!handle)
return ERR_PTR(-EINVAL);
+ ret = ti_sci_cmd_get_revision(handle);
+
+ if (ret)
+ return ret;
+
return handle;
}
@@ -2825,11 +2832,9 @@ static int ti_sci_probe(struct udevice *dev)
list_add_tail(&info->list, &ti_sci_list);
ti_sci_setup_ops(info);
- ret = ti_sci_cmd_get_revision(&info->handle);
-
INIT_LIST_HEAD(&info->dev_list);
- return ret;
+ return 0;
}
/**
--
2.34.1
[PATCH v3 2/6] arm: mach-k3: j721e_init: Move clk_k3 probe before loading TIFS
When setting boot media to load the TIFS binary in legacy boot flow
(followed by J721E), get_timer() is called which eventually calls
dm_timer_init() to grab the tick-timer, which is mcu_timer0. Since we
need to set up the clocks before using the timer, move clk_k3 driver
probe before k3_sysfw_loader to ensure we have all necessary clocks set
up before.
Signed-off-by: Neha Malcom Francis
---
arch/arm/mach-k3/j721e_init.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index b6164575b7..b1f7e25ed0 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -228,6 +228,18 @@ void board_init_f(ulong dummy)
if (!ret)
pinctrl_select_state(dev, "default");
+ /*
+* Force probe of clk_k3 driver here to ensure basic default clock
+* configuration is always done.
+*/
+ if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
+ ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(ti_clk),
+ &dev);
+ if (ret)
+ panic("Failed to initialize clk-k3!\n");
+ }
+
/*
* Load, start up, and configure system controller firmware. Provide
* the U-Boot console init function to the SYSFW post-PM configuration
@@ -241,18 +253,6 @@ void board_init_f(ulong dummy)
do_dt_magic();
#endif
- /*
-* Force probe of clk_k3 driver here to ensure basic default clock
-* configuration is always done.
-*/
- if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
- ret = uclass_get_device_by_driver(UCLASS_CLK,
- DM_DRIVER_GET(ti_clk),
- &dev);
- if (ret)
- panic("Failed to initialize clk-k3!\n");
- }
-
/* Prepare console output */
preloader_console_init();
--
2.34.1
[PATCH v3 1/6] arm: mach-k3: j721e: dev-data: Add mcu_timer0 ID
U-Boot uses mcu_timer0 as the tick-timer, so add it to device list.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Manorit Chawdhry
---
arch/arm/mach-k3/j721e/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j721e/dev-data.c
b/arch/arm/mach-k3/j721e/dev-data.c
index 97f017f8af..b0adb1857b 100644
--- a/arch/arm/mach-k3/j721e/dev-data.c
+++ b/arch/arm/mach-k3/j721e/dev-data.c
@@ -56,6 +56,7 @@ static struct ti_dev soc_dev_list[] = {
PSC_DEV(4, &soc_lpsc_list[8]),
PSC_DEV(202, &soc_lpsc_list[9]),
PSC_DEV(203, &soc_lpsc_list[10]),
+ PSC_DEV(35, &soc_lpsc_list[11]),
PSC_DEV(102, &soc_lpsc_list[11]),
PSC_DEV(103, &soc_lpsc_list[11]),
PSC_DEV(104, &soc_lpsc_list[11]),
--
2.34.1
[PATCH v3 0/6] [PATCH v3 0/6] J721E DTS Sync with Kernel v6.6-rc1
This series aims to sync kernel.org v6.6-rc1 DTS with that of U-Boot. It also includes cleanups where necessary along with certain changes to ensure boot is unaffected. Same as with other board series that have taken up this effort, cleanup of mcu_ringacc and mcu_udmap are dependent on MCU DMA [1] fixes. Also adding TPS6594 PMIC support is still under review [2] in the Kernel. These will be taken up after their merge to Linux. [1] https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [2] https://lore.kernel.org/all/20230810-tps6594-v6-0-2b2e2399e...@ti.com/ Boot logs: https://gist.github.com/nehamalcom/52dd8f2b553952108c0d16556f58077a Changes in v3: - Nishanth: - synced to v6.6-rc1 from v6.5-rc1 - reworded commit messages - removed patch adding k3_avs compatible since it has been merged to -next separately - removed unnecessary #includes - added extra comments for OSPI reg overrides - removed hbmc node from R5 DTS - changed ti_sci_get_cmd_revision to be at a common point for all boot flows - Manorit: - added Reviewed-by tag for mcu_timer0 ID patch (2/7) - removed all aliases - removed unnecessary properties Changes in v2: - Nishanth: - synced k3-j721e-som-0.dtsi 6.5-rc1 - delete tick-timer from -u-boot.dtsi - remove unnecessary aliases - remove SERDES overrides in U-Boot - formatting changes - drop repeated nodes and properties in U-Boot dts - drop nodes and properties not related to U-Boot from U-Boot dts - drop all /delete Neha Malcom Francis (6): arm: mach-k3: j721e: dev-data: Add mcu_timer0 ID arm: mach-k3: j721e_init: Move clk_k3 probe before loading TIFS drivers: firmware: ti_sci: Get SCI revision only if TIFS/SYSFW is up configs: j721e: Remove HBMC_AM654 config arm: dts: k3-j721e-r5: Clean up inclusion hierarchy arm: dts: k3-j721e: Sync with v6.6-rc1 .../k3-j721e-common-proc-board-u-boot.dtsi| 153 +-- arch/arm/dts/k3-j721e-common-proc-board.dts | 513 ++--- arch/arm/dts/k3-j721e-main.dtsi | 1018 +++-- arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 305 - .../k3-j721e-r5-common-proc-board-u-boot.dtsi | 29 - .../arm/dts/k3-j721e-r5-common-proc-board.dts | 363 +- arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi | 31 - arch/arm/dts/k3-j721e-r5-sk.dts | 572 + arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 184 +-- arch/arm/dts/k3-j721e-sk.dts | 673 +++ arch/arm/dts/k3-j721e-som-p0.dtsi | 217 ++-- arch/arm/dts/k3-j721e-thermal.dtsi| 75 ++ arch/arm/dts/k3-j721e.dtsi| 32 +- arch/arm/mach-k3/j721e/dev-data.c |1 + arch/arm/mach-k3/j721e_init.c | 24 +- configs/j721e_evm_a72_defconfig |1 - configs/j721e_evm_r5_defconfig|1 - drivers/firmware/ti_sci.c | 11 +- 18 files changed, 2415 insertions(+), 1788 deletions(-) delete mode 100644 arch/arm/dts/k3-j721e-r5-common-proc-board-u-boot.dtsi delete mode 100644 arch/arm/dts/k3-j721e-r5-sk-u-boot.dtsi create mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi -- 2.34.1
[PATCH 14/14] arm64: zynqmp: Aligned QSPI configuration with latest spec
Official DT binding description for dual stacked/paralllel configurations
have been merged that's why switch to it.
Link:
https://lore.kernel.org/r/20220126112608.955728-3-miquel.ray...@bootlin.com
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 4 +++-
arch/arm/dts/zynqmp-zcu102-revA.dts | 4 +++-
arch/arm/dts/zynqmp-zcu106-revA.dts | 4 +++-
arch/arm/dts/zynqmp-zcu111-revA.dts | 4 +++-
arch/arm/dts/zynqmp-zcu208-revA.dts | 4 +++-
arch/arm/dts/zynqmp-zcu216-revA.dts | 4 +++-
6 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index 4fcb46605537..e72ed50b1cb2 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -354,11 +354,13 @@
&qspi {
status = "okay";
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* Micron
MT25QU512ABB8ESF */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>; /* Based on DC1 spec */
diff --git a/arch/arm/dts/zynqmp-zcu102-revA.dts
b/arch/arm/dts/zynqmp-zcu102-revA.dts
index 025e6519ea6a..be75ca6443d8 100644
--- a/arch/arm/dts/zynqmp-zcu102-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu102-revA.dts
@@ -972,11 +972,13 @@
&qspi {
status = "okay";
is-dual = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>; /* FIXME also DUAL configuration
possible */
spi-max-frequency = <10800>; /* Based on DC1 spec */
diff --git a/arch/arm/dts/zynqmp-zcu106-revA.dts
b/arch/arm/dts/zynqmp-zcu106-revA.dts
index 776373d517b3..6cae681dc29f 100644
--- a/arch/arm/dts/zynqmp-zcu106-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu106-revA.dts
@@ -979,11 +979,13 @@
&qspi {
status = "okay";
is-dual = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>; /* FIXME also DUAL configuration
possible */
spi-max-frequency = <10800>; /* Based on DC1 spec */
diff --git a/arch/arm/dts/zynqmp-zcu111-revA.dts
b/arch/arm/dts/zynqmp-zcu111-revA.dts
index 62a8be9a537f..d08865203ecf 100644
--- a/arch/arm/dts/zynqmp-zcu111-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu111-revA.dts
@@ -790,11 +790,13 @@
&qspi {
status = "okay";
is-dual = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x1000 0x1000>; /* 256MB
*/
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>; /* FIXME also DUAL configuration
possible */
spi-max-frequency = <10800>; /* Based on DC1 spec */
diff --git a/arch/arm/dts/zynqmp-zcu208-revA.dts
b/arch/arm/dts/zynqmp-zcu208-revA.dts
index 01fc3d47f81e..ab3ec80a55f6 100644
--- a/arch/arm/dts/zynqmp-zcu208-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu208-revA.dts
@@ -644,11 +644,13 @@
&qspi {
status = "okay";
is-dual = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* U11 and U12
MT25QU02GCBBE12 1Gb */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x1000 0x1000>; /* 256MB
*/
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>; /* FIXME also DUAL configuration
possible */
spi-max-frequency = <10800>; /* Based on DC1 spec */
diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts
b/arch/arm/dts/zynqmp-zcu216-revA.dts
index 2973e939b0ed..5e076faa254b 100644
--- a/arch/arm/dts/zynqmp-zcu216-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
@@ -654,11 +654,13 @@
&qspi {
status = "okay";
is-dual = <1>;
+ num-cs = <2>;
flash@0 {
[PATCH 13/14] ARM: zynq: Describe nand device in DT
Linux requires to describe nand structure under nand controller.
If it is not described nand device is not detected by Linux.
Error shown by Linux kernel:
pl35x-nand-controller e100.nand-controller: Incorrect number of NAND chips
(0)
pl35x-nand-controller: probe of e100.nand-controller failed with error -22
When wired:
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
Signed-off-by: Michal Simek
---
arch/arm/dts/bitmain-antminer-s9.dts | 3 +++
arch/arm/dts/zynq-zc770-xm011.dts| 3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/dts/bitmain-antminer-s9.dts
b/arch/arm/dts/bitmain-antminer-s9.dts
index 6c47396ce759..0228b4b30e5b 100644
--- a/arch/arm/dts/bitmain-antminer-s9.dts
+++ b/arch/arm/dts/bitmain-antminer-s9.dts
@@ -52,6 +52,9 @@
&nfc0 {
status = "okay";
+ nand@0 {
+ reg = <0>;
+ };
};
&smcc {
diff --git a/arch/arm/dts/zynq-zc770-xm011.dts
b/arch/arm/dts/zynq-zc770-xm011.dts
index 02214349feb7..d1e971254e51 100644
--- a/arch/arm/dts/zynq-zc770-xm011.dts
+++ b/arch/arm/dts/zynq-zc770-xm011.dts
@@ -49,6 +49,9 @@
&nfc0 {
status = "okay";
+ nand@0 {
+ reg = <0>;
+ };
};
&smcc {
--
2.36.1
[PATCH 11/14] arm64: zynqmp: Convert kv260-revA overlay to ASCII text
File was in UTF-8 format but there is no reason for it. Convert it to ASCII/plain text. Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso index 72361f6f9e4a..530bc9076d94 100644 --- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso +++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso @@ -5,9 +5,9 @@ * (C) Copyright 2020 - 2021, Xilinx, Inc. * * SD level shifter: - * "A" – A01 board un-modified (NXP) - * "Y" – A01 board modified with legacy interposer (Nexperia) - * "Z" – A01 board modified with Diode interposer + * "A" - A01 board un-modified (NXP) + * "Y" - A01 board modified with legacy interposer (Nexperia) + * "Z" - A01 board modified with Diode interposer * * Michal Simek */ -- 2.36.1
[PATCH 12/14] arm64: zynqmp: Sync licenses with Linux kernel
There is difference between licenses in the Linux kernel and there shouldn't be any diff because all changes are coming from the same source at the same time. The difference is really in a time when they were upstreamed. That's why sync it up. Signed-off-by: Michal Simek --- arch/arm/dts/avnet-ultra96-rev1.dts | 2 +- arch/arm/dts/zynqmp-clk-ccf.dtsi | 3 ++- arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 3 ++- arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 3 ++- arch/arm/dts/zynqmp-zc1254-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 3 ++- arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 3 ++- arch/arm/dts/zynqmp-zcu102-rev1.0.dts| 2 +- arch/arm/dts/zynqmp-zcu102-revA.dts | 3 ++- arch/arm/dts/zynqmp-zcu102-revB.dts | 3 ++- arch/arm/dts/zynqmp-zcu104-revA.dts | 3 ++- arch/arm/dts/zynqmp-zcu104-revC.dts | 5 +++-- arch/arm/dts/zynqmp-zcu106-revA.dts | 3 ++- arch/arm/dts/zynqmp-zcu111-revA.dts | 3 ++- 14 files changed, 26 insertions(+), 15 deletions(-) diff --git a/arch/arm/dts/avnet-ultra96-rev1.dts b/arch/arm/dts/avnet-ultra96-rev1.dts index 96a6403efaf3..4c1bd69e7553 100644 --- a/arch/arm/dts/avnet-ultra96-rev1.dts +++ b/arch/arm/dts/avnet-ultra96-rev1.dts @@ -2,7 +2,7 @@ /* * dts file for Avnet Ultra96 rev1 * - * (C) Copyright 2018 - 2020, Xilinx, Inc. + * (C) Copyright 2018, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-clk-ccf.dtsi b/arch/arm/dts/zynqmp-clk-ccf.dtsi index 9c0aa073dd94..4044b62d27a2 100644 --- a/arch/arm/dts/zynqmp-clk-ccf.dtsi +++ b/arch/arm/dts/zynqmp-clk-ccf.dtsi @@ -2,7 +2,8 @@ /* * Clock specification for Xilinx ZynqMP * - * (C) Copyright 2017 - 2021, Xilinx, Inc. + * (C) Copyright 2017 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso index 530bc9076d94..22e7d68d02b3 100644 --- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso +++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso @@ -2,7 +2,8 @@ /* * dts file for KV260 revA Carrier Card * - * (C) Copyright 2020 - 2021, Xilinx, Inc. + * (C) Copyright 2020 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. * * SD level shifter: * "A" - A01 board un-modified (NXP) diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso index 44738cef23be..eadc2563064b 100644 --- a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso +++ b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso @@ -2,7 +2,8 @@ /* * dts file for KV260 revA Carrier Card * - * (C) Copyright 2020 - 2021, Xilinx, Inc. + * (C) Copyright 2020 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-zc1254-revA.dts b/arch/arm/dts/zynqmp-zc1254-revA.dts index c6a63201c1c4..cb9ef3746803 100644 --- a/arch/arm/dts/zynqmp-zc1254-revA.dts +++ b/arch/arm/dts/zynqmp-zc1254-revA.dts @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP ZC1254 * - * (C) Copyright 2015 - 2020, Xilinx, Inc. + * (C) Copyright 2015 - 2021, Xilinx, Inc. * * Michal Simek * Siva Durga Prasad Paladugu diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts index 5b592324021a..4fcb46605537 100644 --- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts +++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts @@ -2,7 +2,8 @@ /* * dts file for Xilinx ZynqMP zc1751-xm015-dc1 * - * (C) Copyright 2015 - 2021, Xilinx, Inc. + * (C) Copyright 2015 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts index 83648c2a1c54..23a3ff2fed98 100644 --- a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts +++ b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts @@ -2,7 +2,8 @@ /* * dts file for Xilinx ZynqMP zc1751-xm016-dc2 * - * (C) Copyright 2015 - 2021, Xilinx, Inc. + * (C) Copyright 2015 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanced Micro Devices, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-zcu102-rev1.0.dts b/arch/arm/dts/zynqmp-zcu102-rev1.0.dts index c0a4d913afea..c8f71a1aec89 100644 --- a/arch/arm/dts/zynqmp-zcu102-rev1.0.dts +++ b/arch/arm/dts/zynqmp-zcu102-rev1.0.dts @@ -2,7 +2,7 @@ /* * dts file for Xilinx ZynqMP ZCU102 Rev1.0 * - * (C) Copyright 2016 - 2020, Xilinx, Inc. + * (C) Copyright 2016 - 2018, Xilinx, Inc. * * Michal Simek */ diff --git a/arch/arm/dts/zynqmp-zcu102-revA.dts b/arch/arm/dts/zynqmp-zcu102-revA.dts index 0f7230b9526e..025e6519ea6a 100644 --- a/arch/arm/dts/zynqmp-zcu102-revA.dts +++ b/arch/arm/dts/zynqmp-zcu102-revA.dts @@ -2,7 +2,8 @@ /* * dts file for Xilinx ZynqMP ZCU102 RevA * - * (C) Copyright 2015 - 2021, Xilinx, Inc. + * (C) Copyright 2015 - 2022, Xilinx, Inc. + * (C) Copyright 2022 - 2023, Advanc
[PATCH 10/14] arm64: dts: zynqmp: Add ports for the DisplayPort subsystem
From: Laurent Pinchart
The DPSUB DT bindings now specify ports to model the connections with
the programmable logic and the DisplayPort output. Add them to the
device tree.
Signed-off-by: Laurent Pinchart
Acked-by: Michal Simek
Link:
https://lore.kernel.org/r/1f367ee9554af5d67c86f206e1d6889cc99f6f45.1695049771.git.michal.si...@amd.com
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 20a954e69db0..f03c201caee9 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -1075,6 +1075,30 @@
<&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO1>,
<&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO2>,
<&zynqmp_dpdma ZYNQMP_DPDMA_GRAPHICS>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+ port@1 {
+ reg = <1>;
+ };
+ port@2 {
+ reg = <2>;
+ };
+ port@3 {
+ reg = <3>;
+ };
+ port@4 {
+ reg = <4>;
+ };
+ port@5 {
+ reg = <5>;
+ };
+ };
};
};
};
--
2.36.1
[PATCH 09/14] arm64: dts: zynqmp: zcu106a: Describe DisplayPort connector
From: Laurent Pinchart
Add a device tree node to describe the DisplayPort connector, and
connect it to the DPSUB output.
Signed-off-by: Laurent Pinchart
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu106-revA.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zcu106-revA.dts
b/arch/arm/dts/zynqmp-zcu106-revA.dts
index f8019c592a7f..4b8c69407ff6 100644
--- a/arch/arm/dts/zynqmp-zcu106-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu106-revA.dts
@@ -150,6 +150,18 @@
#clock-cells = <0>;
clock-frequency = <114285000>;
};
+
+ dpcon {
+ compatible = "dp-connector";
+ label = "P11";
+ type = "full-size";
+
+ port {
+ dpcon_in: endpoint {
+ remote-endpoint = <&dpsub_dp_out>;
+ };
+ };
+ };
};
&can1 {
@@ -1065,4 +1077,12 @@
phy-names = "dp-phy0", "dp-phy1";
phys = <&psgtr 1 PHY_TYPE_DP 0 3>,
<&psgtr 0 PHY_TYPE_DP 1 3>;
+
+ ports {
+ port@5 {
+ dpsub_dp_out: endpoint {
+ remote-endpoint = <&dpcon_in>;
+ };
+ };
+ };
};
--
2.36.1
[PATCH 08/14] arm64: xilinx: Remove address/size-cells from gem nodes
Some boards are using one mdio bus which holds multiple phys and also boards are using mdio node for bus description. That's why there are cases where address/size-cells are unnecessary which is also reported by make W=1 dtbs. That's why remove them from zynqmp.dtsi and let board DTSes to handle it based on used description. Error log: /axi/ethernet@ff0e: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp.dtsi | 8 1 file changed, 8 deletions(-) diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index 5c67c6f602f2..20a954e69db0 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -603,8 +603,6 @@ ; reg = <0x0 0xff0b 0x0 0x1000>; clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; - #address-cells = <1>; - #size-cells = <0>; iommus = <&smmu 0x874>; power-domains = <&zynqmp_firmware PD_ETH_0>; resets = <&zynqmp_reset ZYNQMP_RESET_GEM0>; @@ -619,8 +617,6 @@ ; reg = <0x0 0xff0c 0x0 0x1000>; clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; - #address-cells = <1>; - #size-cells = <0>; iommus = <&smmu 0x875>; power-domains = <&zynqmp_firmware PD_ETH_1>; resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>; @@ -635,8 +631,6 @@ ; reg = <0x0 0xff0d 0x0 0x1000>; clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; - #address-cells = <1>; - #size-cells = <0>; iommus = <&smmu 0x876>; power-domains = <&zynqmp_firmware PD_ETH_2>; resets = <&zynqmp_reset ZYNQMP_RESET_GEM2>; @@ -651,8 +645,6 @@ ; reg = <0x0 0xff0e 0x0 0x1000>; clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; - #address-cells = <1>; - #size-cells = <0>; iommus = <&smmu 0x877>; power-domains = <&zynqmp_firmware PD_ETH_3>; resets = <&zynqmp_reset ZYNQMP_RESET_GEM3>; -- 2.36.1
[PATCH 07/14] arm64: xilinx: Put ethernet phys to mdio node
All zynqmp boards have been already described via mdio node that's why also
convert the rest of the boards. With using mdio node there is an option to
add reset property for the whole mdio bus which is reflected by
's/phy-reset-gpios/reset-gpios/g' for some boards.
Signed-off-by: Michal Simek
---
we will investigate if we can remove also that xlnx,phy-type if it is
deprecated now.
---
arch/arm/dts/zynqmp-dlc21-revA.dts | 10 ++---
arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 10 ++---
arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 10 ++---
arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 10 ++---
arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 10 ++---
arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 10 ++---
arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 8 ++--
arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 16 +--
arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 8 ++--
arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 26 ++--
arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 8 ++--
11 files changed, 85 insertions(+), 41 deletions(-)
diff --git a/arch/arm/dts/zynqmp-dlc21-revA.dts
b/arch/arm/dts/zynqmp-dlc21-revA.dts
index 016081ef7b99..f737004d7943 100644
--- a/arch/arm/dts/zynqmp-dlc21-revA.dts
+++ b/arch/arm/dts/zynqmp-dlc21-revA.dts
@@ -88,9 +88,13 @@
phy-handle = <&phy0>;
phy-mode = "sgmii"; /* DTG generates this properly 1512 */
is-internal-pcspma;
- /* phy-reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>; */
- phy0: ethernet-phy@0 {
- reg = <0>;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ /* reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>; */
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
};
};
diff --git a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
index d5cfc61faf71..36a0db44fd28 100644
--- a/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
+++ b/arch/arm/dts/zynqmp-g-a2197-00-revA.dts
@@ -81,10 +81,14 @@
phy-handle = <&phy0>;
phy-mode = "sgmii";
is-internal-pcspma;
- phy0: ethernet-phy@0 { /* marwell m88e1512 */
- reg = <0>;
- reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy@0 { /* marwell m88e1512 */
+ reg = <0>;
+ reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
/* xlnx,phy-type = ; */
+ };
};
};
diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index 56653ec234ee..24573f7b6c2a 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -110,10 +110,14 @@
status = "okay";
phy-handle = <&phy0>;
phy-mode = "sgmii"; /* DTG generates this properly 1512 */
- phy-reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
- phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
- reg = <0>;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
+ phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
+ reg = <0>;
/* xlnx,phy-type = ; */
+ };
};
};
diff --git a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
index 4c8ae80f6f17..58566fbea78e 100644
--- a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
@@ -106,9 +106,13 @@
status = "okay";
phy-handle = <&phy0>;
phy-mode = "sgmii";
- phy-reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
- phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
- reg = <0>;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
+ phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
+ reg = <0>;
+ };
};
};
diff --git a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
index 4bdf58d11e11..529c98cf543d 100644
--- a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
@@ -106,9 +106,13 @@
status = "okay";
phy-handle = <&phy0>;
phy-mode = "sgmii";
- phy-reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
- phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
- reg = <0>;
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&gpio 142 GPIO_ACTIVE_LOW>;
+ phy0: ethernet-phy@0 { /* marwell m88e1512 - SGMII */
+ reg = <0>;
+
[PATCH 06/14] arm64: zynqmp: Fix Siva's email address format
Some patches didn't have his full name and also there was one more ">" at
the end of email address. That's why correct both of these issues.
Fixes: 174d728471d5 ("arm64: zynqmp: Switch to amd.com emails")
Signed-off-by: Michal Simek
---
arch/arm/dts/versal-mini-emmc0.dts | 2 +-
arch/arm/dts/versal-mini-emmc1.dts | 2 +-
arch/arm/dts/versal-mini-ospi.dtsi | 2 +-
arch/arm/dts/versal-mini-qspi.dtsi | 2 +-
arch/arm/dts/versal-mini.dts | 2 +-
arch/arm/dts/zynqmp-mini-emmc0.dts | 2 +-
arch/arm/dts/zynqmp-mini-emmc1.dts | 2 +-
arch/arm/dts/zynqmp-mini-nand.dts| 2 +-
arch/arm/dts/zynqmp-mini-qspi.dts| 2 +-
arch/arm/dts/zynqmp-zc1254-revA.dts | 2 +-
arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 2 +-
arch/arm/dts/zynqmp-zcu1275-revA.dts | 2 +-
arch/arm/dts/zynqmp-zcu1275-revB.dts | 2 +-
arch/arm/dts/zynqmp-zcu1285-revA.dts | 2 +-
arch/arm/mach-versal/mp.c| 2 +-
drivers/fpga/zynqmppl.c | 2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/versal-mini-emmc0.dts
b/arch/arm/dts/versal-mini-emmc0.dts
index bd685ddfdb42..60b1c0e1fc44 100644
--- a/arch/arm/dts/versal-mini-emmc0.dts
+++ b/arch/arm/dts/versal-mini-emmc0.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018-2019, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/versal-mini-emmc1.dts
b/arch/arm/dts/versal-mini-emmc1.dts
index fbdcf5d77f56..751cc38ee5c0 100644
--- a/arch/arm/dts/versal-mini-emmc1.dts
+++ b/arch/arm/dts/versal-mini-emmc1.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018-2019, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/versal-mini-ospi.dtsi
b/arch/arm/dts/versal-mini-ospi.dtsi
index 5683a2306bde..1abe44f40426 100644
--- a/arch/arm/dts/versal-mini-ospi.dtsi
+++ b/arch/arm/dts/versal-mini-ospi.dtsi
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018-2019, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/versal-mini-qspi.dtsi
b/arch/arm/dts/versal-mini-qspi.dtsi
index 2fec92ce3ec8..9347ea32c9cb 100644
--- a/arch/arm/dts/versal-mini-qspi.dtsi
+++ b/arch/arm/dts/versal-mini-qspi.dtsi
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018-2019, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/versal-mini.dts b/arch/arm/dts/versal-mini.dts
index a213b745bc26..844e3840acec 100644
--- a/arch/arm/dts/versal-mini.dts
+++ b/arch/arm/dts/versal-mini.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2019, Xilinx, Inc.
*
- * Siva Durga Prasad Paladugu >
+ * Siva Durga Prasad Paladugu
*/
/dts-v1/;
diff --git a/arch/arm/dts/zynqmp-mini-emmc0.dts
b/arch/arm/dts/zynqmp-mini-emmc0.dts
index 08ec2f7b4a9a..02e80bd85e1a 100644
--- a/arch/arm/dts/zynqmp-mini-emmc0.dts
+++ b/arch/arm/dts/zynqmp-mini-emmc0.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
*/
/dts-v1/;
diff --git a/arch/arm/dts/zynqmp-mini-emmc1.dts
b/arch/arm/dts/zynqmp-mini-emmc1.dts
index 905de08fdb0b..ce1cdb207538 100644
--- a/arch/arm/dts/zynqmp-mini-emmc1.dts
+++ b/arch/arm/dts/zynqmp-mini-emmc1.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
*/
/dts-v1/;
diff --git a/arch/arm/dts/zynqmp-mini-nand.dts
b/arch/arm/dts/zynqmp-mini-nand.dts
index e5688fd703e6..e0517cf46017 100644
--- a/arch/arm/dts/zynqmp-mini-nand.dts
+++ b/arch/arm/dts/zynqmp-mini-nand.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2018, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/zynqmp-mini-qspi.dts
b/arch/arm/dts/zynqmp-mini-qspi.dts
index fc0a2e801e49..ee8be5360004 100644
--- a/arch/arm/dts/zynqmp-mini-qspi.dts
+++ b/arch/arm/dts/zynqmp-mini-qspi.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2015 - 2020, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/zynqmp-zc1254-revA.dts
b/arch/arm/dts/zynqmp-zc1254-revA.dts
index 5c4acd17cc5d..c6a63201c1c4 100644
--- a/arch/arm/dts/zynqmp-zc1254-revA.dts
+++ b/arch/arm/dts/zynqmp-zc1254-revA.dts
@@ -5,7 +5,7 @@
* (C) Copyright 2015 - 2020, Xilinx, Inc.
*
* Michal Simek
- * Siva Durga Prasad Paladugu >
+ * Siva Durga Prasad Paladugu
*/
/dts-v1/;
diff --git a/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
b/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
index 74a5b020e863..0d2ea9c09a0a 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts
@@ -4,7 +4,7 @@
*
* (C) Copyright 2015 - 2021, Xilinx, Inc.
*
- * Siva Durga Prasad >
+ * Siva Durga Prasad Paladugu
* Michal Simek
*/
diff --git a/arch/arm/dts/zynqm
[PATCH 05/14] arm64: zynqmp: Describe bus-width for SD card on KV260
SD card is connected with 4 data lines which should be described properly.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 2 +-
arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
index 55bef1df75d0..72361f6f9e4a 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revA.dtso
@@ -156,7 +156,7 @@
disable-wp;
xlnx,mio-bank = <1>;
assigned-clock-rates = <187498123>;
- bus-width = <8>;
+ bus-width = <4>;
};
&gem3 {
diff --git a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
index 1b1d9e772f55..44738cef23be 100644
--- a/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
+++ b/arch/arm/dts/zynqmp-sck-kv-g-revB.dtso
@@ -144,7 +144,7 @@
clk-phase-uhs-sdr25 = <120>, <60>;
clk-phase-uhs-ddr50 = <126>, <48>;
assigned-clock-rates = <187498123>;
- bus-width = <8>;
+ bus-width = <4>;
};
&gem3 {
--
2.36.1
[PATCH 03/14] arm64: xilinx: Remove address/size-cells from flash node
Partitions are described via fixed-partitions that's why there is no need
to have address/size-cells in flash node.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sm-k26-revA.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts
b/arch/arm/dts/zynqmp-sm-k26-revA.dts
index 80b9face7483..47e8e747ba36 100644
--- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
+++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
@@ -145,8 +145,6 @@
status = "okay";
spi_flash: flash@0 { /* MT25QU512A */
compatible = "mt25qu512a", "jedec,spi-nor"; /* 64MB */
- #address-cells = <1>;
- #size-cells = <1>;
reg = <0>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
--
2.36.1
[PATCH 04/14] arm64: xilinx: Use lower case for partition address
Lower case should be used for register address.
Issue is reported as:
flash@0: partitions: Unevaluated properties are not allowed
('partition@22A' was unexpected)
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-sm-k26-revA.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-sm-k26-revA.dts
b/arch/arm/dts/zynqmp-sm-k26-revA.dts
index 47e8e747ba36..1d62c48e062e 100644
--- a/arch/arm/dts/zynqmp-sm-k26-revA.dts
+++ b/arch/arm/dts/zynqmp-sm-k26-revA.dts
@@ -233,9 +233,9 @@
label = "Secure OS Storage";
reg = <0x228 0x2>; /* 128KB */
};
- partition@22A {
+ partition@22a {
label = "User";
- reg = <0x22A 0x1d6>; /* 29.375 MB */
+ reg = <0x22a 0x1d6>; /* 29.375 MB */
};
};
};
--
2.36.1
[PATCH 02/14] arm64: dts: xilinx: zynqmp: Add RPU subsystem device node
From: Tanmay Shah
RPU subsystem can be configured in cluster-mode or split mode.
Also each r5 core has separate power domains.
Signed-off-by: Tanmay Shah
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 951f3f795e97..5c67c6f602f2 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -120,6 +120,22 @@
};
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ rproc_0_fw_image: memory@3ed0 {
+ no-map;
+ reg = <0x0 0x3ed0 0x0 0x4>;
+ };
+
+ rproc_1_fw_image: memory@3ef0 {
+ no-map;
+ reg = <0x0 0x3ef0 0x0 0x4>;
+ };
+ };
+
zynqmp_ipi: zynqmp-ipi {
bootph-all;
compatible = "xlnx,zynqmp-ipi-mailbox";
@@ -248,6 +264,23 @@
power-domains = <&zynqmp_firmware PD_PL>;
};
+ remoteproc {
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <1>;
+
+ r5f-0 {
+ compatible = "xlnx,zynqmp-r5f";
+ power-domains = <&zynqmp_firmware PD_RPU_0>;
+ memory-region = <&rproc_0_fw_image>;
+ };
+
+ r5f-1 {
+ compatible = "xlnx,zynqmp-r5f";
+ power-domains = <&zynqmp_firmware PD_RPU_1>;
+ memory-region = <&rproc_1_fw_image>;
+ };
+ };
+
amba: axi {
compatible = "simple-bus";
bootph-all;
--
2.36.1
[PATCH 01/14] arm64: zynqmp: Describe interrupts by using macros
Use arm-gic.h and irq.h for interrupt description. It helps to improve
readability of device tree file.
Suggested-by: Laurent Pinchart
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 184 +++
1 file changed, 110 insertions(+), 74 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 8d3501018455..951f3f795e97 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -14,6 +14,8 @@
#include
#include
+#include
+#include
#include
#include
@@ -122,7 +124,7 @@
bootph-all;
compatible = "xlnx,zynqmp-ipi-mailbox";
interrupt-parent = <&gic>;
- interrupts = <0 35 4>;
+ interrupts = ;
xlnx,ipi-id = <0>;
#address-cells = <2>;
#size-cells = <2>;
@@ -152,10 +154,10 @@
pmu {
compatible = "arm,armv8-pmuv3";
interrupt-parent = <&gic>;
- interrupts = <0 143 4>,
-<0 144 4>,
-<0 145 4>,
-<0 146 4>;
+ interrupts = ,
+,
+,
+;
interrupt-affinity = <&cpu0>,
<&cpu1>,
<&cpu2>,
@@ -183,7 +185,7 @@
bootph-all;
compatible = "xlnx,zynqmp-power";
interrupt-parent = <&gic>;
- interrupts = <0 35 4>;
+ interrupts = ;
mboxes = <&ipi_mailbox_pmu1 0>,
<&ipi_mailbox_pmu1 1>;
mbox-names = "tx", "rx";
};
@@ -227,10 +229,10 @@
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
- interrupts = <1 13 0xf08>,
-<1 14 0xf08>,
-<1 11 0xf08>,
-<1 10 0xf08>;
+ interrupts = ,
+,
+,
+;
};
edac {
@@ -258,7 +260,7 @@
status = "disabled";
clock-names = "can_clk", "pclk";
reg = <0x0 0xff06 0x0 0x1000>;
- interrupts = <0 23 4>;
+ interrupts = ;
interrupt-parent = <&gic>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
@@ -271,7 +273,7 @@
status = "disabled";
clock-names = "can_clk", "pclk";
reg = <0x0 0xff07 0x0 0x1000>;
- interrupts = <0 24 4>;
+ interrupts = ;
interrupt-parent = <&gic>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
@@ -291,11 +293,11 @@
compatible = "arm,cci-400-pmu,r1";
reg = <0x9000 0x5000>;
interrupt-parent = <&gic>;
- interrupts = <0 123 4>,
-<0 123 4>,
-<0 123 4>,
-<0 123 4>,
-<0 123 4>;
+ interrupts = ,
+,
+,
+,
+;
};
};
@@ -305,7 +307,7 @@
compatible = "xlnx,zynqmp-dma-1.0";
reg = <0x0 0xfd50 0x0 0x1000>;
interrupt-parent = <&gic>;
- interrupts = <0 124 4>;
+ interrupts = ;
clock-names = "clk_main", "clk_apb";
#dma-cells = <1>;
xlnx,bus-width = <128>;
@@ -318,7 +320,7 @@
compatible = "xlnx,zynqmp-dma-1.0";
reg = <0x0 0xfd51 0x0 0x1000>;
interrupt-parent = <&gic>;
- interrupts = <0 125 4>;
+ interrupts = ;
clock-names = "clk_main", "clk_apb";
#dma-cells = <1>;
xlnx,bus-width = <128>;
@@ -331,7 +333,7 @@
compatible = "xlnx,zynqmp-dma-1.0";
reg = <0x0 0xfd52 0x0 0x1000>;
interrupt-parent = <&gic>;
-
[PATCH 00/14] arm64: xilinx: Sync with Linux kernel
Hi, this series is syncing DTs with Linux kernel. A lot of patches are simply taken from the Linux kernel and taken to U-Boot. But there are also some new one which are trying to fix violations. There is still some work to happen to be 100% in sync but we are getting closer and closer. Thanks, Michal Laurent Pinchart (2): arm64: dts: zynqmp: zcu106a: Describe DisplayPort connector arm64: dts: zynqmp: Add ports for the DisplayPort subsystem Michal Simek (11): arm64: zynqmp: Describe interrupts by using macros arm64: xilinx: Remove address/size-cells from flash node arm64: xilinx: Use lower case for partition address arm64: zynqmp: Describe bus-width for SD card on KV260 arm64: zynqmp: Fix Siva's email address format arm64: xilinx: Put ethernet phys to mdio node arm64: xilinx: Remove address/size-cells from gem nodes arm64: zynqmp: Convert kv260-revA overlay to ASCII text arm64: zynqmp: Sync licenses with Linux kernel ARM: zynq: Describe nand device in DT arm64: zynqmp: Aligned QSPI configuration with latest spec Tanmay Shah (1): arm64: dts: xilinx: zynqmp: Add RPU subsystem device node arch/arm/dts/avnet-ultra96-rev1.dts | 2 +- arch/arm/dts/bitmain-antminer-s9.dts | 3 + arch/arm/dts/versal-mini-emmc0.dts | 2 +- arch/arm/dts/versal-mini-emmc1.dts | 2 +- arch/arm/dts/versal-mini-ospi.dtsi | 2 +- arch/arm/dts/versal-mini-qspi.dtsi | 2 +- arch/arm/dts/versal-mini.dts | 2 +- arch/arm/dts/zynq-zc770-xm011.dts| 3 + arch/arm/dts/zynqmp-clk-ccf.dtsi | 3 +- arch/arm/dts/zynqmp-dlc21-revA.dts | 10 +- arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 10 +- arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 10 +- arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 10 +- arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 10 +- arch/arm/dts/zynqmp-mini-emmc0.dts | 2 +- arch/arm/dts/zynqmp-mini-emmc1.dts | 2 +- arch/arm/dts/zynqmp-mini-nand.dts| 2 +- arch/arm/dts/zynqmp-mini-qspi.dts| 2 +- arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 10 +- arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 11 +- arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 5 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 6 +- arch/arm/dts/zynqmp-zc1254-revA.dts | 4 +- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 15 +- arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 19 +- arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 8 +- arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 26 ++- arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 10 +- arch/arm/dts/zynqmp-zcu102-rev1.0.dts| 2 +- arch/arm/dts/zynqmp-zcu102-revA.dts | 7 +- arch/arm/dts/zynqmp-zcu102-revB.dts | 3 +- arch/arm/dts/zynqmp-zcu104-revA.dts | 3 +- arch/arm/dts/zynqmp-zcu104-revC.dts | 5 +- arch/arm/dts/zynqmp-zcu106-revA.dts | 27 ++- arch/arm/dts/zynqmp-zcu111-revA.dts | 7 +- arch/arm/dts/zynqmp-zcu1275-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu1275-revB.dts | 2 +- arch/arm/dts/zynqmp-zcu1285-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu208-revA.dts | 4 +- arch/arm/dts/zynqmp-zcu216-revA.dts | 4 +- arch/arm/dts/zynqmp.dtsi | 249 +++ arch/arm/mach-versal/mp.c| 2 +- drivers/fpga/zynqmppl.c | 2 +- 43 files changed, 345 insertions(+), 169 deletions(-) -- 2.36.1
Re: [PATCH v2 01/17] dm: usb: udc: Factor out plain udevice handler functions
Hi Marek, I'm answering here as there is no cover letter. Just to let you know I'm still concerned by the series and want to test it but did not had the time to do so recently. Hopefully next week. Sorry for the delay. Miquèl ma...@denx.de wrote on Fri, 1 Sep 2023 11:49:47 +0200: > Pull the functionality of UDC uclass that operates on plain udevice > and does not use this dev_array array into separate functions and > expose those functions, so that as much code as possible can be > switched over to these functions and the dev_array can be dropped. > > Reviewed-by: Mattijs Korpershoek > Signed-off-by: Marek Vasut > --- > Cc: Angus Ainslie > Cc: Dmitrii Merkurev > Cc: Eddie Cai > Cc: Kever Yang > Cc: Lukasz Majewski > Cc: Miquel Raynal > Cc: Mattijs Korpershoek > Cc: Nishanth Menon > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Philipp Tomsich > Cc: Simon Glass > Cc: Stefan Roese > Cc: ker...@puri.sm > --- > V2: Add RB from Mattijs > --- > drivers/usb/gadget/udc/Makefile | 2 +- > drivers/usb/gadget/udc/udc-uclass.c | 57 + > include/linux/usb/gadget.h | 17 + > 3 files changed, 68 insertions(+), 8 deletions(-)
Re: [PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL
On 9/22/23 03:48, Kever Yang wrote: On 2023/9/21 22:47, Eugen Hristev wrote: On 8/1/23 10:28, Eugen Hristev wrote: This series adds support for DFU in SPL for rockchip rk3588 on rock5b board. Namely, when SPL is loaded via rockusb (thus via USB), having the `same-as-spl` boot order item, after having detected that it was loaded from USB, it will lookup the gadget USB node in DT and boot via DFU. Some changes were required namely: - DFU needs environment, hence adding environment variables into DFU - added bootph-all to nodes such that they are available in SPL - insert gadget into boot order I had to port one patch for DWC3 from Linux, and include in this series the patches that are floating from Venkatesh that fixup the DWC3 (https://marc.info/?l=u-boot&m=168351919807081&w=2 ) I know that Marek NAKed them and I am fine with it, I am not trying to sneak in any patches, they are not to be merged, also this patch `usb: dwc3: Increase DWC3 controller halt timeout` is in the same bucket so Marek you can NAK this one as well, no problem, I am just sending out all the series so maybe the rockchip part for the gadget can be picked up and if people want to use the DFU SPL gadget can also manually pick the DWC3 patches. The branch with all the patches is available here : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot Thanks! Changes in v2: - rebased on latest upstream which caused a change in the config patch. Eugen Hristev (7): rockchip: allow env defines for SPL build usb: dwc3: Increase DWC3 controller halt timeout ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes ARM: mach-rockchip: spl-boot-order: add possibility to DFU ARM: mach-rockchip: rk3588: add gadget device to the boot order rockchip: rk3588: prepare env for DFU configs: rockchip: rock5b-rk3588: enable DFU and related configs Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 + arch/arm/mach-rockchip/rk3588/rk3588.c | 1 + arch/arm/mach-rockchip/spl-boot-order.c | 3 +++ configs/rock5b-rk3588_defconfig | 18 +++--- drivers/usb/dwc3/core.c | 32 +++-- drivers/usb/dwc3/gadget.c | 20 +++- drivers/usb/dwc3/gadget.h | 14 +++ include/configs/rk3588_common.h | 9 ++- include/configs/rockchip-common.h | 4 9 files changed, 76 insertions(+), 31 deletions(-) Hello Kever, I see in patchwork this series is marked as 'Changes requested'. Do you wish to tell me which are the changes you requested, as I did not see anything in your replies. I am interested to see the patches related to rockchip (not the DWC3), if it's fine for you to merge them. Hi Eugen, For rockchip platform part is fine to me, but as a patchset, the dwc3 part is NAKed by Marek, so patch set not able to merge. If rockchip part can work without dwc3 change, you can send a separate patch set for it, so that I can merge it. Hi Kever, The rockchip part works except the fact that sometimes the dwc3 gadget does not power up correctly (hence the three patches that fix the problem). If you are fine to take the rockchip part I can resend it as a separate series. It would be useful for people to have the gadget devicetree and configs in upstream, and only the DWC3 part missing. Otherwise, this series will float until someone brings DWC3 up to date in U-boot as Marek requested. Let me know what do you think. Thanks, Eugen Thanks, - Kever Thanks, Eugen
Re: [Question] TI's u-boot.img is built twice
On Fri, Sep 22, 2023 at 5:04 PM Neha Malcom Francis wrote: > > Hi Masahiro > > On 22/09/23 12:48, Masahiro Yamada wrote: > > On Fri, Sep 22, 2023 at 2:27 PM Neha Malcom Francis > > wrote: > >> > >> Hi Masahiro > >> > >> On 21/09/23 21:06, Masahiro Yamada wrote: > >>> Hi. > >>> > >>> Since the TI platform migrated to binman, > >>> u-boot.img is built twice. > >>> > >>> It is created by "mkimage -E", > >>> then overwritten by binman. > >>> > >>> > >>> So, the data are embedded in the FIT structure > >>> instead of being appended. > >>> > >>> Is this intentional? > >>> > >>> To me, it looks weird. > >>> > >>> > >> > >> I haven't added the fit,external-offset property in the binman.dtsi so it > >> was > >> not appended as external data and I did not find reason to. Is there any > >> benefit > >> in having the data appended than embedded? > > > > > > > > Placing payload data outside the FIT structure is a U-Boot hack. > > > > > > The motivation was explained in the commit log of > > 722ebc8f84d5bccd2e70fad1079a0dd40cceddec > > > > > > Thanks for this! Makes sense, I think we should make it appended again in > binman. Can reduce boot time. > > > > Before TI migrated to binman, > > u-boot.img was the "payload outside" structure > > but it is not any more. > > > > I do not mind the implementation details as long as > > U-Boot is able to boot the Linux kernel. > > > > > > I was just suffering from the AM64-SK boot failure > > (as I asked in another thread) and just noticed > > something odd when I was poking the SPL code. > > > > > > At least, .u-boot.img.cmd is not telling the truth. > > > > Usually, the build command is saved in a *.cmd file > > but this does not reflect the reality, because > > it is binman that created the final u-boot.img > > > > > > $ cat .u-boot.img.cmd > > cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none > > -O u-boot -a 0x8080 -e 0x8080 -p 0x0 -n "U-Boot > > 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b > > arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d > > u-boot-nodtb.bin u-boot.img >/dev/null > > > > > > I will not track it down any further, though. > > It is too complicated. > > > > > > > > I am not too sure about the .cmd files but looks like its misleading probably > because the replacing of the binman generated image takes under cmd_binman and > not directly from the Makefile (just a guess). >From my view as a user, building images without k3-image-gen seems like a benefit, but binman is not mandatory for u-boot.img. With line 255-339 of arch/arm/dts/k3-am64x-binman.dtsi deleted, u-boot.img was still generated in the same structure as before. (payload appended) The confusion came from u-boot.img being first created by line 1439 of the top Makefile (mkimage), then overwritten by line 1113 (binman). If you use binman for u-boot.img, the line 1439 does not need to run, but it runs because u-boot.img is added to INPUTS-y. Perhaps, you may want to hack line 978 because IMX is doing something there. ifeq ($(CONFIG_MX7)$(CONFIG_IMX_HAB), yy) INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img else INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.img endif For the *.cmd files, the mkimage command is saved in .u-boot.img.cmd and the binman command is saved in ..binman_stamp.cmd $ cat .u-boot.img.cmd cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none -O u-boot -a 0x8080 -e 0x8080 -p 0x0 -n "U-Boot 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d u-boot-nodtb.bin u-boot.img >/dev/null $ cat ..binman_stamp.cmd cmd_.binman_stamp := ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O . -m --allow-missing -I . -I . -I ./board/ti/am64x -I arch/arm/dts -a of-list="k3-am642-evm k3-am642-sk" -I /home/masahiro/ref/ti-linux-firmware -a atf-bl31-path=/home/masahiro/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin -a tee-os-path=/home/masahiro/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin -a opensbi-path= -a default-dt="k3-am642-evm" -a scp-path= -a rockchip-tpl-path= -a spl-bss-pad= -a tpl-bss-pad=1 -a spl-dtb=y -a tpl-dtb= -a pre-load-key-path= -- Best Regards Masahiro Yamada
Re: [PATCH v2 1/1] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
On 9/22/23 12:08, Alexander Dahl wrote:
Adapt behaviour to Linux kernel driver.
The return value of gpio_request_by_name_nodev() was not checked before,
and thus in case 'rb-gpios' was missing in DT, rb.type was set to
ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
example (on sam9x60-curiosity with the line removed from dts):
NAND: Could not find valid ONFI parameter page; aborting
device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
Macronix NAND 512MiB 3,3V 8-bit
512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
atmel-nand-controller nand-controller: NAND scan failed: -22
Failed to probe nand driver (err = -22)
Failed to initialize NAND controller. (error -22)
0 MiB
Note: not having that gpio assigned in dts is possible, the driver does
not override nand_chip->dev_ready() then and a generic solution is used.
Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
Signed-off-by: Alexander Dahl
---
Reviewed-by: Eugen Hristev
Notes:
v1 -> v2:
- Only issue error message if error is not ENOENT. If the node just is
missing, move on without error message.
drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
[PATCH] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts
According to the TRMs of K3 platform of devices, the ROM boot image
format specifies a "Core Options Field" that provides the capability to
set the Dual MCU present to lockstep when set to 0 or to split mode when
set to 2. Add support for providing the same from the binman DTS. Also
modify existing test case for ensuring future coverage.
Signed-off-by: Neha Malcom Francis
---
tools/binman/btool/openssl.py | 6 --
tools/binman/etype/ti_secure_rom.py | 12 ++--
tools/binman/etype/x509_cert.py | 3 ++-
tools/binman/test/297_ti_secure_rom.dts | 1 +
4 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index aad3b61ae2..86cc56fbd7 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -155,6 +155,7 @@ authInPlace = INTEGER:2
C, ST, L, O, OU, CN and emailAddress
cert_type (int): Certification type
bootcore (int): Booting core
+bootcore_opts(int): Booting core option (split/lockstep mode)
load_addr (int): Load address of image
sha (int): Hash function
@@ -225,7 +226,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
imagesize_sbl, hashval_sbl, load_addr_sysfw, imagesize_sysfw,
hashval_sysfw, load_addr_sysfw_data, imagesize_sysfw_data,
hashval_sysfw_data, sysfw_inner_cert_ext_boot_block,
- dm_data_ext_boot_block):
+ dm_data_ext_boot_block, bootcore_opts):
"""Create a certificate
Args:
@@ -241,6 +242,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
bootcore (int): Booting core
load_addr (int): Load address of image
sha (int): Hash function
+bootcore_opts (int): Boot core option (split/lockstep mode)
Returns:
str: Tool output
@@ -285,7 +287,7 @@ sysfw_data=SEQUENCE:sysfw_data
[sbl]
compType = INTEGER:1
bootCore = INTEGER:16
-compOpts = INTEGER:0
+compOpts = INTEGER:{bootcore_opts}
destAddr = FORMAT:HEX,OCT:{load_addr:08x}
compSize = INTEGER:{imagesize_sbl}
shaType = OID:{sha_type}
diff --git a/tools/binman/etype/ti_secure_rom.py
b/tools/binman/etype/ti_secure_rom.py
index 9a7ac9e9e0..780f132ea5 100644
--- a/tools/binman/etype/ti_secure_rom.py
+++ b/tools/binman/etype/ti_secure_rom.py
@@ -32,6 +32,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
- core: core on which bootloader runs, valid cores are 'secure' and
'public'
- content: phandle of SPL in case of legacy bootflow or phandles of
component binaries
in case of combined bootflow
+- bootcore_opts (optional): split-mode (0) or lockstep mode (1) set to
0 by default
The following properties are only for generating a combined bootflow
binary:
- sysfw-inner-cert: boolean if binary contains sysfw inner certificate
@@ -69,6 +70,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
self.sw_rev = fdt_util.GetInt(self._node, 'sw-rev', 1)
self.sha = fdt_util.GetInt(self._node, 'sha', 512)
self.core = fdt_util.GetString(self._node, 'core', 'secure')
+self.bootcore_opts = fdt_util.GetInt(self._node, 'core-opts')
self.key_fname = self.GetEntryArgsOrProps([
EntryArg('keyfile', str)], required=True)[0]
if self.combined:
@@ -103,11 +105,14 @@ class Entry_ti_secure_rom(Entry_x509_cert):
else:
self.cert_type = 2
self.bootcore = 0
-self.bootcore_opts = 32
+if self.bootcore_opts is None:
+self.bootcore_opts = 32
else:
self.cert_type = 1
self.bootcore = 16
-self.bootcore_opts = 0
+if self.bootcore_opts is None:
+self.bootcore_opts = 0
+
return super().GetCertificate(required=required, type='rom')
def CombinedGetCertificate(self, required):
@@ -126,6 +131,9 @@ class Entry_ti_secure_rom(Entry_x509_cert):
self.num_comps = 3
self.sha_type = SHA_OIDS[self.sha]
+if self.bootcore_opts is None:
+self.bootcore_opts = 0
+
# sbl
self.content = fdt_util.GetPhandleList(self._node, 'content-sbl')
input_data_sbl = self.GetContents(required)
diff --git a/tools/binman/etype/x509_cert.py b/tools/binman/etype/x509_cert.py
index d028cfe38c..fc0bb12278 100644
--- a/tools/binman/etype/x509_cert.py
+++ b/tools/binman/etype/x509_cert.py
@@ -136,7 +136,8 @@ class Entry_x509_cert(Entry_collection):
imagesize_sysfw_data=self.imagesize_sysfw_data,
hashval_sysfw_data=self.hashval_sysfw_data,
sysfw_inner_cert_ext_boot_block=self.sysfw_inner_cert_ext_boot_block,
-dm_data_ext_boot_block=self.dm_data_ext_boot_block
+dm_data_ext_boot_block=se
[PATCH v2 0/1] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hei hei, after sending v1 of this patch Eugen and Michael discussed what would be the right approach in U-Boot here. Actually now I saw I did not correctly port what Linux does here in v1, but this v2 should be what I understood would be the preferred solution and should be similar to what Linux does now. The original patch series had two patches, from which one was applied already. To not confuse patchwork or mailing setups, I send v2 with a cover letter too, although it is only one patch left in the series. Link to v1 below. Greets Alex Alexander Dahl (1): mtd: nand: raw: atmel: Add error handling when rb-gpios missing drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Link: https://lore.kernel.org/u-boot/20230808130250.188588-3-...@thorsis.com/ base-commit: 5d2fae79c7d60eaf7f50322e4ec125d2f58544e9 -- 2.30.2
[PATCH v2 1/1] mtd: nand: raw: atmel: Add error handling when rb-gpios missing
Adapt behaviour to Linux kernel driver.
The return value of gpio_request_by_name_nodev() was not checked before,
and thus in case 'rb-gpios' was missing in DT, rb.type was set to
ATMEL_NAND_GPIO_RB nevertheless, leading to output like this for
example (on sam9x60-curiosity with the line removed from dts):
NAND: Could not find valid ONFI parameter page; aborting
device found, Manufacturer ID: 0xc2, Chip ID: 0xdc
Macronix NAND 512MiB 3,3V 8-bit
512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB size: 64
atmel-nand-controller nand-controller: NAND scan failed: -22
Failed to probe nand driver (err = -22)
Failed to initialize NAND controller. (error -22)
0 MiB
Note: not having that gpio assigned in dts is possible, the driver does
not override nand_chip->dev_ready() then and a generic solution is used.
Fixes: 6a8dfd57220d ("nand: atmel: Add DM based NAND driver")
Signed-off-by: Alexander Dahl
---
Notes:
v1 -> v2:
- Only issue error message if error is not ENOENT. If the node just is
missing, move on without error message.
drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c
b/drivers/mtd/nand/raw/atmel/nand-controller.c
index 2b29c8def6..fa962ba591 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1600,10 +1600,13 @@ static struct atmel_nand *atmel_nand_create(struct
atmel_nand_controller *nc,
nand->cs[i].rb.type = ATMEL_NAND_NATIVE_RB;
nand->cs[i].rb.id = val;
} else {
- gpio_request_by_name_nodev(np, "rb-gpios", 0,
- &nand->cs[i].rb.gpio,
- GPIOD_IS_IN);
- nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
+ ret = gpio_request_by_name_nodev(np, "rb-gpios", 0,
+&nand->cs[i].rb.gpio,
+GPIOD_IS_IN);
+ if (ret && ret != -ENOENT)
+ dev_err(nc->dev, "Failed to get R/B gpio (err =
%d)\n", ret);
+ if (!ret)
+ nand->cs[i].rb.type = ATMEL_NAND_GPIO_RB;
}
gpio_request_by_name_nodev(np, "cs-gpios", 0,
--
2.30.2
[PATCH] MAINTAINERS: Step up as maintainers of UniPhier SoC platform
Update maintainers for UniPhier SoC platform. Signed-off-by: Kunihiko Hayashi --- MAINTAINERS | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0a10a436bcec..281a3f81f73a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -723,7 +723,10 @@ F: drivers/usb/musb-new/ux500.c F: drivers/video/mcde_simple.c ARM UNIPHIER -S: Orphan (Since 2020-09) +M: Kunihiko Hayashi +R: Dai Okamura +S: Maintained +F: arch/arm/dts/uniphier-* F: arch/arm/mach-uniphier/ F: configs/uniphier_*_defconfig N: uniphier -- 2.25.1
Re: [PATCH v2] env: ti: ti_common.env: Fix get_overlaystring for FIT Image
Hi Andrew,
On 12:03-20230921, Andrew Davis wrote:
> On 9/21/23 5:49 AM, Manorit Chawdhry wrote:
> > After the refactor with conf- nodes in fitImage, overlaystring wasn't
> > didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
> > to handle conf- nodes.
> >
> > Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get
> > FIT config string")
> > Reported-by: Aniket Limaye
> > Signed-off-by: Manorit Chawdhry
> > ---
> > Test Logs:
> > => setenv name_overlays ti/k3-dt.dtbo ti/k3-dt1.dtbo
> > => run get_overlaystring
> > => printenv overlaystring
> > overlaystring=#conf-ti_k3-dt.dtbo#conf-ti_k3-dt1.dtbo
> > ---
> > Changes in v2:
> > - Fix tabs
> > - Link to v1:
> > https://lore.kernel.org/r/20230919-b4-upstream-overlaystring-v1-1-4c56e8d66...@ti.com
> > ---
> > include/env/ti/ti_common.env | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/env/ti/ti_common.env b/include/env/ti/ti_common.env
> > index e87a41a6590b..bc554fe7ca6d 100644
> > --- a/include/env/ti/ti_common.env
> > +++ b/include/env/ti/ti_common.env
> > @@ -16,9 +16,14 @@ addr_fit=0x9000
> > name_fit=fitImage
> > update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
> > get_overlaystring=
> > - for overlay in $name_overlays;
> > - do;
> > - setenv overlaystring ${overlaystring}'#'${overlay};
> > + for overlay in $name_overlays; do;
> > + if test ${boot_fit} -eq 1;
> > + then
>
> Why is the `then` tabbed out here, you can make it on the end of
> the above line, same as you changed for `do`. Then untab all this
> by one.
>
> > + setexpr name_fit_overlay gsub / _
> > conf-${overlay};
> > + setenv overlaystring
> > ${overlaystring}'#'${name_fit_overlay};
> > + else
> > + setenv overlaystring
> > ${overlaystring}'#'${overlay};
>
> If you set `overlay` using setexpr, then this line is common and doesn't need
> to
> be out here. Also do we use this overlaystring for anything other than the
> FIT case? And if not, why do we need this boot_fit == 1 check at all?
Ah, I see this is only for FIT usecase. I'll refactor the name too to
get_fit_overlaystring as that makes more sense then.
Regards,
Manorit
>
> Andrew
>
> > + fi;
> > done;
> > get_fit_config=setexpr name_fit_config gsub / _ conf-${fdtfile}
> > run_fit=run get_fit_config; bootm
> > ${addr_fit}#${name_fit_config}${overlaystring}
> >
> > ---
> > base-commit: 2fe4b54556ea6271237b35de68dc458bfceab94c
> > change-id: 20230915-b4-upstream-overlaystring-207e28b8c5fb
> >
> > Best regards,
Re: [Question] TI's u-boot.img is built twice
Hi Masahiro On 22/09/23 12:48, Masahiro Yamada wrote: On Fri, Sep 22, 2023 at 2:27 PM Neha Malcom Francis wrote: Hi Masahiro On 21/09/23 21:06, Masahiro Yamada wrote: Hi. Since the TI platform migrated to binman, u-boot.img is built twice. It is created by "mkimage -E", then overwritten by binman. So, the data are embedded in the FIT structure instead of being appended. Is this intentional? To me, it looks weird. I haven't added the fit,external-offset property in the binman.dtsi so it was not appended as external data and I did not find reason to. Is there any benefit in having the data appended than embedded? Placing payload data outside the FIT structure is a U-Boot hack. The motivation was explained in the commit log of 722ebc8f84d5bccd2e70fad1079a0dd40cceddec Thanks for this! Makes sense, I think we should make it appended again in binman. Can reduce boot time. Before TI migrated to binman, u-boot.img was the "payload outside" structure but it is not any more. I do not mind the implementation details as long as U-Boot is able to boot the Linux kernel. I was just suffering from the AM64-SK boot failure (as I asked in another thread) and just noticed something odd when I was poking the SPL code. At least, .u-boot.img.cmd is not telling the truth. Usually, the build command is saved in a *.cmd file but this does not reflect the reality, because it is binman that created the final u-boot.img $ cat .u-boot.img.cmd cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none -O u-boot -a 0x8080 -e 0x8080 -p 0x0 -n "U-Boot 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d u-boot-nodtb.bin u-boot.img >/dev/null I will not track it down any further, though. It is too complicated. I am not too sure about the .cmd files but looks like its misleading probably because the replacing of the binman generated image takes under cmd_binman and not directly from the Makefile (just a guess). To confirm it, apply the following hack. Since u-boot.img is overwritten by binman, copy it to u-boot.img.backup. diff --git a/Makefile b/Makefile index 87f9fc786e..4cffa8a061 100644 --- a/Makefile +++ b/Makefile @@ -1112,6 +1112,7 @@ endef # Timestamp file to make sure that binman always runs .binman_stamp: $(INPUTS-y) FORCE ifeq ($(CONFIG_BINMAN),y) + cp u-boot.img u-boot.img.backup $(call if_changed,binman) endif @touch $@ Then, build it for the main core. make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- am64x_evm_a53_defconfig all TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin BINMAN_INDIRS=~/ref/ti-linux-firmware Compare the two files. Run fdtdump to see what happened to them. $ diff -u u-boot.img u-boot.img.backup Binary files u-boot.img and u-boot.img.backup differ $ fdtdump u-boot.img => u-boot and dt are embedded. $ fdtdump u-boot.img.backup => u-boot and dt are appended after the FIT structure -- Thanking You Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [Question] TI's u-boot.img is built twice
On Fri, Sep 22, 2023 at 2:27 PM Neha Malcom Francis wrote: > > Hi Masahiro > > On 21/09/23 21:06, Masahiro Yamada wrote: > > Hi. > > > > Since the TI platform migrated to binman, > > u-boot.img is built twice. > > > > It is created by "mkimage -E", > > then overwritten by binman. > > > > > > So, the data are embedded in the FIT structure > > instead of being appended. > > > > Is this intentional? > > > > To me, it looks weird. > > > > > > I haven't added the fit,external-offset property in the binman.dtsi so it was > not appended as external data and I did not find reason to. Is there any > benefit > in having the data appended than embedded? Placing payload data outside the FIT structure is a U-Boot hack. The motivation was explained in the commit log of 722ebc8f84d5bccd2e70fad1079a0dd40cceddec Before TI migrated to binman, u-boot.img was the "payload outside" structure but it is not any more. I do not mind the implementation details as long as U-Boot is able to boot the Linux kernel. I was just suffering from the AM64-SK boot failure (as I asked in another thread) and just noticed something odd when I was poking the SPL code. At least, .u-boot.img.cmd is not telling the truth. Usually, the build command is saved in a *.cmd file but this does not reflect the reality, because it is binman that created the final u-boot.img $ cat .u-boot.img.cmd cmd_u-boot.img := ./tools/mkimage -f auto -A arm -T firmware -C none -O u-boot -a 0x8080 -e 0x8080 -p 0x0 -n "U-Boot 2023.10-rc4-00047-gb9b83a86f0-dirty for am64x board" -E -b arch/arm/dts/k3-am642-evm.dtb -b arch/arm/dts/k3-am642-sk.dtb -d u-boot-nodtb.bin u-boot.img >/dev/null I will not track it down any further, though. It is too complicated. > > > > > > To confirm it, apply the following hack. > > > > Since u-boot.img is overwritten by binman, > > copy it to u-boot.img.backup. > > > > > > > > > > diff --git a/Makefile b/Makefile > > index 87f9fc786e..4cffa8a061 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1112,6 +1112,7 @@ endef > > # Timestamp file to make sure that binman always runs > > .binman_stamp: $(INPUTS-y) FORCE > > ifeq ($(CONFIG_BINMAN),y) > > + cp u-boot.img u-boot.img.backup > > $(call if_changed,binman) > > endif > > @touch $@ > > > > > > > > Then, build it for the main core. > > > > > > make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- > > am64x_evm_a53_defconfig all > > TEE=~/ref/OP-TEE/optee_os/out/arm-plat-k3/core/tee-raw.bin > > BL31=~/ref/trusted-firmware-a/build/k3/lite/release/bl31.bin > > BINMAN_INDIRS=~/ref/ti-linux-firmware > > > > > > > > > > Compare the two files. > > Run fdtdump to see what happened to them. > > > > > > $ diff -u u-boot.img u-boot.img.backup > > Binary files u-boot.img and u-boot.img.backup differ > > > > > > $ fdtdump u-boot.img > > => u-boot and dt are embedded. > > > > $ fdtdump u-boot.img.backup > > => u-boot and dt are appended after the > > FIT structure > > > > > > > > -- > Thanking You > Neha Malcom Francis -- Best Regards Masahiro Yamada
[PATCH v4 8/8] efi_loader: create BlockIo device boot option
Current efibootmgr automatically creates the boot options
of all the disks and partitions installing
SIMPLE_FILE_SYSTEM_PROTOCOL. These boot options are created
to load and start the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
Now efibootmgr can scan the BlockIo device and try to boot
with the default file on the fly, this commit creates the
boot options only for the BlockIo devices exluding the logical
partition.
Signed-off-by: Masahisa Kojima
---
include/efi_loader.h | 1 +
lib/efi_loader/efi_bootmgr.c | 47 +---
lib/efi_loader/efi_device_path.c | 20 ++
3 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c4207edc91..cc292f0553 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -932,6 +932,7 @@ struct efi_device_path *efi_dp_from_lo(struct
efi_load_option *lo,
struct efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2);
struct efi_device_path *search_gpt_dp_node(struct efi_device_path
*device_path);
+struct efi_device_path *efi_search_file_path_dp_node(struct efi_device_path
*device_path);
efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
efi_uintn_t *size);
unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data);
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 4991056946..b55d651d1b 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -387,7 +387,6 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle,
}
if (lo.attributes & LOAD_OPTION_ACTIVE) {
- struct efi_device_path *file_path;
u32 attributes;
log_debug("trying to load \"%ls\" from %pD\n", lo.label,
@@ -405,11 +404,14 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle,
lo.file_path,
lo.label, handle);
}
- } else {
- file_path = expand_media_path(lo.file_path);
- ret = EFI_CALL(efi_load_image(true, efi_root, file_path,
+ } else if (efi_search_file_path_dp_node(lo.file_path)) {
+ ret = EFI_CALL(efi_load_image(true, efi_root,
lo.file_path,
NULL, 0, handle));
- efi_free_pool(file_path);
+ } else {
+ efi_handle_t h;
+
+ h = efi_dp_find_obj(lo.file_path, &efi_block_io_guid,
NULL);
+ ret = load_default_file_from_blk_dev(h->dev, handle);
}
if (ret != EFI_SUCCESS) {
log_warning("Loading %ls '%ls' failed\n",
@@ -549,13 +551,13 @@ error:
*/
static efi_status_t efi_bootmgr_enumerate_boot_option(struct
eficonfig_media_boot_option *opt,
efi_handle_t
*volume_handles,
- efi_status_t count)
+ efi_uintn_t *count)
{
- u32 i;
+ u32 i, num = 0;
struct efi_handler *handler;
efi_status_t ret = EFI_SUCCESS;
- for (i = 0; i < count; i++) {
+ for (i = 0; i < *count; i++) {
u16 *p;
u16 dev_name[BOOTMENU_DEVICE_NAME_MAX];
char *optional_data;
@@ -563,6 +565,16 @@ static efi_status_t
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
char buf[BOOTMENU_DEVICE_NAME_MAX];
struct efi_device_path *device_path;
struct efi_device_path *short_dp;
+ struct efi_block_io *blkio;
+
+ ret = efi_search_protocol(volume_handles[i],
&efi_block_io_guid, &handler);
+ blkio = handler->protocol_interface;
+ /*
+* The logical partition is excluded since the bootmgr tries to
+* boot with the default file by scanning the default file on
the fly.
+*/
+ if (blkio->media->logical_partition)
+ continue;
ret = efi_search_protocol(volume_handles[i],
&efi_guid_device_path, &handler);
if (ret != EFI_SUCCESS)
@@ -596,16 +608,18 @@ static efi_status_t
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
* to store guid, instead of realloc the load_option.
*/
lo.optional_data = "1234567";
- opt[i].size = efi_serialize_load_option(&lo, (u8 **)&opt[i].lo);
- if (!opt[i].size) {
+ opt[num].size = efi_serialize_load_option(&lo, (u8
**)&opt[num].lo);
+
[PATCH v4 7/8] doc: uefi: add HTTP Boot support
This adds the description about HTTP Boot. Signed-off-by: Masahisa Kojima --- doc/develop/uefi/uefi.rst | 30 ++ 1 file changed, 30 insertions(+) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index a7a41f2fac..65eea89265 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -594,6 +594,36 @@ UEFI variables. Booting according to these variables is possible via:: As of U-Boot v2020.10 UEFI variables cannot be set at runtime. The U-Boot command 'efidebug' can be used to set the variables. +UEFI HTTP Boot +~~ + +HTTP Boot provides the capability for system deployment and configuration +over the network. HTTP Boot can be activated by specifying:: + +CONFIG_CMD_DNS +CONFIG_CMD_WGET +CONFIG_BLKMAP + +Set up the load option specifying the target URI:: + +efidebug boot add -u 1 netinst http://foo/bar + +When this load option is selected as boot selection, resolve the +host ip address by dns, then download the file with wget. +If the downloaded file extension is .iso or .img file, efibootmgr tries to +mount the image and boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI). +If the downloaded file is PE-COFF image, load the downloaded file and +start it. + +There is a limitation that current implementation tries to resolve +the IP address as a host name. If the uri is like "http://192.168.1.1/foobar";, +the dns process tries to resolve the host "192.168.1.1" and it will +end up with "host not found". + +We need to preset the "httpserverip" environment variable to proceed the wget:: + +setenv httpserverip 192.168.1.1 + Executing the built in hello world application ~~ -- 2.34.1
[PATCH v4 6/8] cmd: efidebug: add uri device path
This adds the URI device path option for 'boot add' subcommand.
User can add the URI load option for downloading ISO image file
or EFI application through network. Currently HTTP is only supported.
Signed-off-by: Masahisa Kojima
---
cmd/efidebug.c | 50 +++
include/net.h | 8 ++
net/wget.c | 72 ++
3 files changed, 130 insertions(+)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 0be3af3e76..f2fd6ba71d 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -829,6 +830,52 @@ static int do_efi_boot_add(struct cmd_tbl *cmdtp, int flag,
argc -= 1;
argv += 1;
break;
+#if (IS_ENABLED(CONFIG_BLKMAP) && IS_ENABLED(CONFIG_CMD_WGET) &&
IS_ENABLED(CONFIG_CMD_DNS))
+ case 'u':
+ {
+ char *pos;
+ int uridp_len;
+ struct efi_device_path_uri *uridp;
+
+ if (argc < 3 || lo.label) {
+ r = CMD_RET_USAGE;
+ goto out;
+ }
+ id = (int)hextoul(argv[1], &endp);
+ if (*endp != '\0' || id > 0x)
+ return CMD_RET_USAGE;
+
+ efi_create_indexed_name(var_name16, sizeof(var_name16),
+ "Boot", id);
+
+ label = efi_convert_string(argv[2]);
+ if (!label)
+ return CMD_RET_FAILURE;
+ lo.label = label;
+
+ uridp_len = sizeof(struct efi_device_path) +
strlen(argv[3]) + 1;
+ fp_free = efi_alloc(uridp_len + sizeof(END));
+ uridp = (struct efi_device_path_uri *)fp_free;
+ uridp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
+ uridp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_URI;
+ uridp->dp.length = uridp_len;
+ if (!wget_validate_uri(argv[3])) {
+ printf("ERROR: invalid URI\n");
+ r = CMD_RET_FAILURE;
+ goto out;
+ }
+
+ strcpy(uridp->uri, argv[3]);
+ pos = (char *)uridp + uridp_len;
+ memcpy(pos, &END, sizeof(END));
+ fp_size += uridp_len + sizeof(END);
+ file_path = (struct efi_device_path *)uridp;
+ argc -= 3;
+ argv += 3;
+ break;
+ }
+#endif
+
default:
r = CMD_RET_USAGE;
goto out;
@@ -1492,6 +1539,9 @@ static char efidebug_help_text[] =
" -b|-B[:] \n"
" -i|-I [:] \n"
" (-b, -i for short form device path)\n"
+#if (IS_ENABLED(CONFIG_BLKMAP) && IS_ENABLED(CONFIG_CMD_WGET) &&
IS_ENABLED(CONFIG_CMD_DNS))
+ " -u \n"
+#endif
" -s ''\n"
"efidebug boot rm [ [ [...]]]\n"
" - delete UEFI Boot variables\n"
diff --git a/include/net.h b/include/net.h
index 57889d8b7a..c748974573 100644
--- a/include/net.h
+++ b/include/net.h
@@ -935,4 +935,12 @@ static inline void eth_set_enable_bootdevs(bool enable) {}
*/
int wget_with_dns(ulong dst_addr, char *uri);
+/**
+ * wget_validate_uri() - varidate the uri
+ *
+ * @uri: uri string of target file of wget
+ * Return: true if uri is valid, false if uri is invalid
+ */
+bool wget_validate_uri(char *uri);
+
#endif /* __NET_H__ */
diff --git a/net/wget.c b/net/wget.c
index 4801e28eb9..6a4d22be32 100644
--- a/net/wget.c
+++ b/net/wget.c
@@ -558,3 +558,75 @@ out:
return ret;
}
#endif
+
+/**
+ * wget_validate_uri() - validate the uri for wget
+ *
+ * @uri: uri string
+ * Return: true on success, false on failure
+ */
+bool wget_validate_uri(char *uri)
+{
+ char c;
+ bool ret = true;
+ char *str_copy, *s, *authority;
+
+ /* TODO: strict uri conformance check */
+
+ /*
+* Uri is expected to be correctly percent encoded.
+* This is the minimum check, control codes(0x1-0x19, 0x7F, except '\0')
+* and space character(0x20) are not allowed.
+*/
+ for (c = 0x1; c < 0x21; c++) {
+ if (strchr(uri, c)) {
+ printf("invalid character is used\n");
+ return false;
+ }
+ }
+ if (strchr(uri, 0x7f)) {
+ printf("invalid character is used\n");
+ return false;
+ }
+
+ /*
+* This follows the current U-Boot wget implementation.
+* sche
