Re: Docs for RISC-V
Hi Zong, > From: Leo Yu-Chi Liang(梁育齊) > Sent: Monday, February 06, 2023 3:58 PM > To: Simon Glass > Cc: U-Boot Mailing List ; Rick Jian-Zhi Chen(陳建志) > ; zong...@sifive.com; vincent.c...@sifive.com > Subject: Re: Docs for RISC-V > > Hi Simon, > > On Thu, Feb 02, 2023 at 10:25:36AM -0700, Simon Glass wrote: > > Hi, > > > > On Thu, 2 Feb 2023 at 10:18, Simon Glass wrote: > > > > > > Hi Rick & Leo, > > > > > > I see docs for one board at [1] but I'm not sure what to do with > > > unleashed. > > > > > > It seems to need a 'genimage' tool, going on what I see in CI. Would you please take a look at this item ? Thanks, Rick > > > > > It does seem like that accroding to "sifive_unleashed_sdcard test.py". > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/568342) > > > > Could you adjust it to use binman to output an image suitable for > > > writing to an SD card in a single 'dd' step, as Rockchip does? > > > > > I think I will both take a look at it and forward this message to guys at > sifive. > > > > Also, how about adding a RISC-V section here? > > > > > > https://u-boot.readthedocs.io/en/latest/arch/index.html > > > > > Sounds great! > I will reference what other architectures have and create a RISC-V section. > > > > > Also I notice that this is incorrect: > > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unleashed.html?hi > > ghlight=fw_dynamic.bin > > > > since 'make PLATFORM=generic' gives errors. I think it needs > > CROSS_COMPILE > > > > There is already an 'export CROSS_COMPILE' in the previous "building" section > before 'make PLATFROM=generic', so I guess that is why CROSS_COMPILE is > omitted in make command. > > > One other thing...binman output is this: > > > > binman: Filename 'fw_dynamic.bin' not found in input path (...) > > > > You should add something to tools/binman/missing-blob-help so that it > > tells the user where to find the blob. > > > > Same as the above, I will forward this to guys at sifive to see what they > would like to do. > > > Thanks for all the catches! > Best regards, > Leo > > > Thanks again, > > Simon > > > > > Thanks, > > > Simon > > > > > > [1] > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unmatched.html
Re: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
Hi Jaehoon,
On Mon, 6 Feb 2023 at 06:05, Jaehoon Chung wrote:
>
> Hi,
>
> > -Original Message-
> > From: Loic Poulain
> > Sent: Thursday, January 26, 2023 6:24 PM
> > To: s...@chromium.org; peng@nxp.com; jh80.ch...@samsung.com
> > Cc: u-boot@lists.denx.de; Loic Poulain
> > Subject: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
> >
> > The default erase command applies on erase group unit, and
> > simply round down to erase group size. When the start block
> > is not aligned to erase group size (e.g. erasing partition)
> > it causes unwanted erasing of the previous blocks, part of
> > the same erase group (e.g. owned by other logical partition,
> > or by the partition table itself).
> >
> > To prevent this issue, a simple solution is to use TRIM as
> > argument of the Erase command, which is usually supported
> > with eMMC > 4.0, and allow to apply erase operation to write
> > blocks instead of erase group
> >
> > Signed-off-by: Loic Poulain
> > ---
> > v2: Add mmc unit test change to the series
> >
> > drivers/mmc/mmc_write.c | 34 +++---
> > 1 file changed, 23 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> > index 5b7aeeb012..a6f93380dd 100644
> > --- a/drivers/mmc/mmc_write.c
> > +++ b/drivers/mmc/mmc_write.c
> > @@ -15,7 +15,7 @@
> > #include
> > #include "mmc_private.h"
> >
> > -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> > +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt,
> > u32 args)
> > {
> > struct mmc_cmd cmd;
> > ulong end;
> > @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
> > lbaint_t blkcnt)
> > goto err_out;
> >
> > cmd.cmdidx = MMC_CMD_ERASE;
> > - cmd.cmdarg = MMC_ERASE_ARG;
> > + cmd.cmdarg = args ? args : MMC_ERASE_ARG;
>
> It there any case to pass by other value?
Not at the moment, but it can be used to support eMMC 'Secure Erase' arg.
Regards,
Loic
Re: [PATCH v2 3/3] test: dm: mmc: Check block erasing boundaries
On Fri, 27 Jan 2023 at 15:30, Simon Glass wrote: > > Hi Loic, > > On Thu, 26 Jan 2023 at 02:24, Loic Poulain wrote: > > > > Verify that erasing blocks does not impact adjacent ones. > > - Write four blocks [0 1 2 3] > > - Erase two blocks [ 1 2 ] > > - Verify [0 1 2 3 ] > > > > Signed-off-by: Loic Poulain > > --- > > v2: Add this change to the series > > > > test/dm/mmc.c | 14 +++--- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > This looks good, but can you add the trim command to > sandbox_mmc_send_cmd()? Then you can test that as well. The TRIM option is not exposed, it is internally managed inside mmc depending on the need for it. So from a testing perspective, I can only test that the mmc erase is doing what we ask correctly. Regards, Loic
Re: [PATCH] schemas: Add schema for firmware logs
On Tue, 2023-02-07 at 11:39 -0700, Simon Glass wrote: > Hi Jan, > > On Tue, 7 Feb 2023 at 08:39, Jan Lübbe wrote: > > > > On Tue, 2023-02-07 at 06:38 -0700, Simon Glass wrote: > > > Hi Jan, > > > > > > On Tue, 7 Feb 2023 at 04:56, Jan Lübbe wrote: > > > [snip] > > > Thanks for the pointer. I had a look at this. How do you deal with > > > updating a filesystem that might be corrupt? Is that even a good idea, > > > if the purpose of it is to collect data from a kernel crash? > > > > This uses only the ramoops "backend" in pstore, so no filesystems are > > involved. > > If I remember correctly, ramoops in the kernel just discards any data that > > is > > too corrupted to process. Barebox should behave the same, as the code was > > ported > > from the kernel. > > Yes...actually I found that U-Boot has pstore too, but it does not > support writing the console into it. I suppose it would be easy > enough, but it seems that U-Boot's pstore is not as advanced. > > > > > We are working on a firmware 'Transfer List' which is a simple data > > > structure to communicate through the different firmware phases. Since > > > U-Boot is the last one, in this case, I suppose it could do the > > > ramoops thing and add files for each of the firmware phases. > > > > For passing logs "forward" to the next step in the boot chain, this should > > work > > as well and could be more explicit than the ramoops console. One benefit > > would > > be that keeping the logs from each step separate, right? > > Yes. But we can't use this to pass it to the kernel. > Hmm, because we would need to reserve space for the text memory regions, which couldn't be used by the kernel later? > > ramoops has additional mechanisms to deal with the possible corruption > > caused by > > the crash or reset cycle, which shouldn't be needed in to "forward" > > direction. > > But if there is corruption there, what does U-Boot do? > > 1. Clear the ramoops and write its console info (that will be annoying > for people trying to debug kernel crashes) > 2. Leave it alone and not write the console info (then it is non-functional) > 3. Or is it possible to write even when some things are corrupted? As the console is protected by ECC in blocks, you can have corrupted blocks in the middle and still continue logging at the end, if you want. The corrupted block can then either be repaired when reading or need to be skipped. > > > What about logging support? It would be nice to have a format that > > > understands logging level, category, filename/function, etc. > > > > ramoops console is just unstructured text, Linux and Barebox just write > > characters to it. More structure might be nice some cases, but the necessary > > coordination between different projects could be a high barrier. ;) > > Indeed it is, but that is the point of the binding :-) > > > > > Perhaps a simple list of text blocks would be enough, though. > > Do you mean a list of nul-terminated strings? What format are you thinking of? > > > I think the format described in the binding should work well enough (ASCII lines, with NUL termination). And it's readable on a terminal. :) > > > > Regards, > > > > Jan > > > > > > > > > I think any new DT binding is premature and pstore/ramoops was just a > > > > > suggestion to consider. This needs wider consideration of how to > > > > > handle all the various (boot) firmware logs. I've added the > > > > > boot-architecture list for a bit more visibility. > > > > > > If this needs a call, I have not seen one for quite a while. It seems > > > to get cancelled at the last minute. I would be happy to attend one to > > > discuss this topic. But if people have ideas here, please weigh in. > > > > Looking at the proposed schema, I'd prefer to drop the boot-phase and > > project > > patterns and use the lists as suggestions only. The order of > > /chosen/logs/log@N > > should be enough to make sense of those. > > Yes I suppose so, but I would really like to have a clear view of what > booted and which project it came from. Do you think it is an undue > burden? > I didn't mean to drop the properties, but to allow free-form text. Not all firmware stacks use the same phases and not all bootloader project names start with "^U-Boot|TF-A". :) I don't think we'll see project name collisions, and the boot-phase name should be unique with in a project, so free-form should be fine. > > Also to keep it simple, perhaps support the memory reference only, and drop > > the > > in-DTB string? > > Yes, that can work. We can always add it later...copying the text into > the DT does add overhead so it would be better to avoid it where > possible. Agreed. Regards, Jan -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax:
[RESEND PATCH v2] configs: imx8mn_bsh_smm_s2: remove console from bootargs
The Linux kernel device tree already specifies the device to be used for
boot console output with a stdout-path property under /chosen.
Commit 36b661dc919da ("Merge branch 'next'") re-added the console
setting that commit bede82f750752 ("configs: imx8mn_bsh_smm_s2: remove
console from bootargs") had previously removed.
Fixes: 36b661dc919da ("Merge branch 'next'")
Signed-off-by: Dario Binacchi
Reviewed-by: Fabio Estevam
---
Changes in v2:
- Add the 'Reviewed-by' tag.
- Improve commit message.
include/configs/imx8mn_bsh_smm_s2.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/imx8mn_bsh_smm_s2.h
b/include/configs/imx8mn_bsh_smm_s2.h
index e97b8e871d22..deeed9c2f582 100644
--- a/include/configs/imx8mn_bsh_smm_s2.h
+++ b/include/configs/imx8mn_bsh_smm_s2.h
@@ -14,7 +14,7 @@
#include
#define NANDARGS \
- "nandargs=setenv bootargs console=${console} " \
+ "nandargs=setenv bootargs " \
"${optargs} " \
"mtdparts=${mtdparts} " \
"root=${nandroot} " \
--
2.32.0
Re: [PATCH 1/2] arm: cpu: Add optional CMOs by VA
On Tue, 07 Feb 2023 17:18:27 +, Paul Liu wrote: > > Hi Marc, > > I think you are the author. I'm just making some minor fixes and > then upstreaming to the mailing list. What is the correct way to > make the Signed-off-by list? In general, and unless you have completely rewritten the patch (it doesn't seem so in this particular case), you should keep the original authorship and sign-off chain, and add your own Signed-off-by: tag *after* the previous ones. You should also document what changes you have made, if any, when picking up the patch. When posting it, it should read something like: From: Random Developer Fix foo handling in bar(). Signed-off-by: Random Developer Signed-off-by: Random Committer [Paul: picked from the FooBar tree, fixed the return value for bar() and rebased to upstream] Signed-off-by: Paul Liu Link: https://git.foobar.com/commit/?df2d85d0b0b5b1533d6db9079f0a0a7b73ef6a34 where "Random Developer" is the original author, and "Random Committer" is someone who picked up the patch the first place. The important thing here is that, just by looking at the sign-off chain, you can tell how the patch has been handled. The additional information (enclosed in square bracket) is optional but much appreciated by the reviewers, and so is the link to the original patch, which helps seeing it in context. If the commits have lost the original authorship (which sometimes happen as you rebase patches and resolve conflicts), you can fix it with: git commit --amend --author="Random Developer " on each individual commit. Tom's email also has a good pointer to what is expected from contributors (most of which is applicable to a large number of open-source projects). Hope this helps, M. -- Without deviation from the norm, progress is not possible.
Re: [PATCH v1] RFC: rtc: rv8803: avoid bootloop on low voltage of button cell
Am 2023-02-08 08:38, schrieb Oliver Graute: if the rtc button cell is on low voltage this can result in a permanent bootloop in u-boot because V2F Register is permanent set. ### Warning: temperature compensation has stopped ### Warning: Voltage low, data is invalid resetting ... With this patch the bootloop is prevented Signed-off-by: Oliver Graute I'm curious, how is the call tree here? I don't see the dm_rtc_get() being called during boot. Basically, you are now just ignoring the error. -michael
Re: Docs for RISC-V
On Wed, Feb 8, 2023 at 4:07 PM Rick Chen wrote: > > Hi Zong, > > > From: Leo Yu-Chi Liang(梁育齊) > > Sent: Monday, February 06, 2023 3:58 PM > > To: Simon Glass > > Cc: U-Boot Mailing List ; Rick Jian-Zhi Chen(陳建志) > > ; zong...@sifive.com; vincent.c...@sifive.com > > Subject: Re: Docs for RISC-V > > > > Hi Simon, > > > > On Thu, Feb 02, 2023 at 10:25:36AM -0700, Simon Glass wrote: > > > Hi, > > > > > > On Thu, 2 Feb 2023 at 10:18, Simon Glass wrote: > > > > > > > > Hi Rick & Leo, > > > > > > > > I see docs for one board at [1] but I'm not sure what to do with > > > > unleashed. > > > > > > > > It seems to need a 'genimage' tool, going on what I see in CI. > > Would you please take a look at this item ? Hi Rick, No problem, let me take a look at it, and give you all some feedback later. Thanks. > > Thanks, > Rick > > > > > > > > > It does seem like that accroding to "sifive_unleashed_sdcard test.py". > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/568342) > > > > > > Could you adjust it to use binman to output an image suitable for > > > > writing to an SD card in a single 'dd' step, as Rockchip does? > > > > > > > > I think I will both take a look at it and forward this message to guys at > > sifive. > > > > > > Also, how about adding a RISC-V section here? > > > > > > > > https://u-boot.readthedocs.io/en/latest/arch/index.html > > > > > > > > Sounds great! > > I will reference what other architectures have and create a RISC-V section. > > > > > > > > Also I notice that this is incorrect: > > > > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unleashed.html?hi > > > ghlight=fw_dynamic.bin > > > > > > since 'make PLATFORM=generic' gives errors. I think it needs > > > CROSS_COMPILE > > > > > > > There is already an 'export CROSS_COMPILE' in the previous "building" > > section before 'make PLATFROM=generic', so I guess that is why > > CROSS_COMPILE is omitted in make command. > > > > > One other thing...binman output is this: > > > > > > binman: Filename 'fw_dynamic.bin' not found in input path (...) > > > > > > You should add something to tools/binman/missing-blob-help so that it > > > tells the user where to find the blob. > > > > > > > Same as the above, I will forward this to guys at sifive to see what they > > would like to do. > > > > > > Thanks for all the catches! > > Best regards, > > Leo > > > > > Thanks again, > > > Simon > > > > > > > Thanks, > > > > Simon > > > > > > > > [1] > > > > https://u-boot.readthedocs.io/en/latest/board/sifive/unmatched.html
Re: [PATCH v3 17/19] doc: android: add documentation for v3,v4 boot image header
On lun., févr. 06, 2023 at 00:50, Safae Ouajih wrote: > Update the Android documentation to describe version 3 and 4 of boot > image header. > > Signed-off-by: Safae Ouajih > --- Reviewed-by: Mattijs Korpershoek > doc/android/boot-image.rst | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/doc/android/boot-image.rst b/doc/android/boot-image.rst > index 71db02521b..c719b4d711 100644 > --- a/doc/android/boot-image.rst > +++ b/doc/android/boot-image.rst > @@ -27,11 +27,21 @@ next image headers: > * v2: used in devices launched with Android 10; adds ``dtb`` field, which >references payload containing DTB blobs (either concatenated one after the >other, or in Android DTBO image format) > +* v3: used in devices launched with Android 11; adds ``vendor_boot`` > partition > + and removes the second-stage bootloader and recovery image support. The new > + ``vendor_boot`` partition holds the device tree blob (DTB) and a vendor > ramdisk. > + The generic ramdisk in ``boot`` partition is loaded immediately following > + the vendor ramdisk. > +* v4: used in devices launched with Android 12; provides a boot signature in > boot > + image header, supports multiple vendor ramdisk fragments in ``vendor_boot`` > + partition. This version also adds a bootconfig section at the end of the > vendor > + boot image, this section contains boot configuration parameters known at > build time > + (see [9]_ for details). > > v2, v1 and v0 formats are backward compatible. > > The Android Boot Image format is represented by > -:c:type:`struct andr_img_hdr ` in U-Boot, and can be seen in > +:c:type:`struct andr_image_data ` in U-Boot, and can be > seen in > ``include/android_image.h``. U-Boot supports booting Android Boot Image and > also > has associated command > > @@ -153,3 +163,4 @@ References > .. [6] :doc:`avb2` > .. [7] https://source.android.com/devices/bootloader > .. [8] https://connect.linaro.org/resources/san19/san19-217/ > +.. [9] > https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig > -- > 2.34.1
Re: [PATCH v2 036/169] Correct SPL uses of CMD_BOOTEFI_BOOTMGR
On 2/7/23 15:50, Tom Rini wrote: On Tue, Feb 07, 2023 at 08:39:38AM +0100, Heinrich Schuchardt wrote: On 2/7/23 01:00, Tom Rini wrote: On Tue, Feb 07, 2023 at 12:54:03AM +0100, Heinrich Schuchardt wrote: On 2/6/23 01:53, Simon Glass wrote: This converts 3 usages of this option to the non-SPL form, since there is no SPL_CMD_BOOTEFI_BOOTMGR defined in Kconfig Signed-off-by: Simon Glass --- (no changes since v1) boot/Makefile | 2 +- cmd/bootmenu.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/boot/Makefile b/boot/Makefile index 69c31adb77d..73b5b19816b 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -29,7 +29,7 @@ obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_EFILOADER) += bootmeth_efi.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SANDBOX) += bootmeth_sandbox.o obj-$(CONFIG_$(SPL_TPL_)BOOTMETH_SCRIPT) += bootmeth_script.o ifdef CONFIG_$(SPL_TPL_)BOOTSTD_FULL -obj-$(CONFIG_$(SPL_TPL_)CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o +obj-$(CONFIG_CMD_BOOTEFI_BOOTMGR) += bootmeth_efi_mgr.o obj-$(CONFIG_$(SPL_TPL_)BOOTSTD) += bootflow_menu.o endif diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c index 3236ca5d799..422ab411252 100644 --- a/cmd/bootmenu.c +++ b/cmd/bootmenu.c @@ -223,7 +223,7 @@ static int prepare_bootmenu_entry(struct bootmenu_data *menu, return 1; } -#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR)) && (CONFIG_IS_ENABLED(CMD_EFICONFIG)) +#if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) && (CONFIG_IS_ENABLED(CMD_EFICONFIG)) There is no reason whatsoever for using different macros for the two options. Here and elsewhere, one CONFIG is being fixed at a time. If at the end of the series this is not fixed, then that's an issue to address. This cannot be reviewed easily. I never received the complete series. This, and the related series, are among the most reviewed we've had in quite some time. Just FWIW. CONFIG_IS_ENABLED() is more restrictive than IS_ENABLED(). No motivation is provided why the condition should be relaxed in the commit message. The idea of "restrictive" is not how either of those macros should be evaluated. Cover-letters are not in the commit history. But anyway the cover-letter does not provide any motivation for the change either. NAK to this patch. It's incorrect to use CONFIG_IS_ENABLED() instead of IS_ENABLED() outside of: - CONFIG_FOO, CONFIG_SPL_FOO (etc) exist - The code in question is compiled in the SPL (etc) context and we do need to know if the code block in question is required here and the implicit value of SPL_FOO being false is useful. This case is why Simon insists that adding def_bool n for SPL_EFI_LOADER, etc, is correct, but I'm not convinced. I will be taking most of these patches in the next day or two, but I can avoid the EFI ones if you insist. They are however I believe correct. The code changes are ok with me. It were simply the commit messages which were insufficient. Acked-by: Heinrich Schuchardt
RE: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
Hi Loic,
> -Original Message-
> From: Loic Poulain
> Sent: Wednesday, February 8, 2023 5:09 PM
> To: Jaehoon Chung
> Cc: s...@chromium.org; peng@nxp.com; u-boot@lists.denx.de
> Subject: Re: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
>
> Hi Jaehoon,
>
> On Mon, 6 Feb 2023 at 06:05, Jaehoon Chung wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Loic Poulain
> > > Sent: Thursday, January 26, 2023 6:24 PM
> > > To: s...@chromium.org; peng@nxp.com; jh80.ch...@samsung.com
> > > Cc: u-boot@lists.denx.de; Loic Poulain
> > > Subject: [PATCH v2 2/3] mmc: erase: Use TRIM erase when available
> > >
> > > The default erase command applies on erase group unit, and
> > > simply round down to erase group size. When the start block
> > > is not aligned to erase group size (e.g. erasing partition)
> > > it causes unwanted erasing of the previous blocks, part of
> > > the same erase group (e.g. owned by other logical partition,
> > > or by the partition table itself).
> > >
> > > To prevent this issue, a simple solution is to use TRIM as
> > > argument of the Erase command, which is usually supported
> > > with eMMC > 4.0, and allow to apply erase operation to write
> > > blocks instead of erase group
> > >
> > > Signed-off-by: Loic Poulain
> > > ---
> > > v2: Add mmc unit test change to the series
> > >
> > > drivers/mmc/mmc_write.c | 34 +++---
> > > 1 file changed, 23 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
> > > index 5b7aeeb012..a6f93380dd 100644
> > > --- a/drivers/mmc/mmc_write.c
> > > +++ b/drivers/mmc/mmc_write.c
> > > @@ -15,7 +15,7 @@
> > > #include
> > > #include "mmc_private.h"
> > >
> > > -static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
> > > +static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt,
> > > u32 args)
> > > {
> > > struct mmc_cmd cmd;
> > > ulong end;
> > > @@ -52,7 +52,7 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
> > > lbaint_t blkcnt)
> > > goto err_out;
> > >
> > > cmd.cmdidx = MMC_CMD_ERASE;
> > > - cmd.cmdarg = MMC_ERASE_ARG;
> > > + cmd.cmdarg = args ? args : MMC_ERASE_ARG;
> >
> > It there any case to pass by other value?
>
> Not at the moment, but it can be used to support eMMC 'Secure Erase' arg.
I had mis-read. I had read the MMC_TRIM_ARG as MMC_ERASE_ARG. Thanks for kindly
explanation. :)
Best Regards,
Jaehoon Chung
>
> Regards,
> Loic
[PATCH v3 00/10] usb: dwc3: Refactor dwc3-generic and apply to dwc3-uniphier
This series achieves refactoring of dwc3-generic. First, dwc3-generic allows DT controller nodes to be children of glue nodes, but outside of glue nodes. To achieve this goal, define a glue-specific function to get controller node, look up more reference clocks in the controller node, and initialize clocks in children of glue node before access to the controller, Next, this series exports the structures and functions from the driver source to the header, and replaces dwc3-uniphier driver as one implementation using them. This expects dwc3-generic to prevent more SoC-dependent codes. The dwc3-uniphier has original USB node, however, tentatively added its own node dedicated to U-Boot. After this refactoring, the driver needs to add clock entries and PHY driver to enable them corresponding to the properties in the original node. PATCH 1 has been provided below. https://patchwork.ozlabs.org/project/uboot/patch/20221215223822.137739-1-ma...@denx.de/ PATCH 2 is based on the suggested patch from Marek. PATCH 4-5 and 9-10 have been already reviewed in the previous v1. https://lists.denx.de/pipermail/u-boot/2023-January/505689.html Changes since v2: - Add Reviewed-by: tags - Add more details to reset-uniphier patch log - Add error release for clock/reset initializer in phy-uniphier-usb3 patch - Fix release year in in phy-uniphier-usb3 patch - Enable PHY_UNIPHIER_USB3 with DWC3_UNIPHIER - Separate devicetree patches Changes since v1: - Add a patch to refer to the clock in top level generic node - Add a patch to allow controller DT node outside of glue node - Add a patch to initialize clocks in children of glue node - Update dwc3_glue_ops to add the function to get controller device - Add a patch to support USB glue reset - Add a patch to add missing PHY clocks - Add a patch to enable the driver to enable PHY clocks and resets - Add a patch to fix node names and missing properties - Add a patch to switch to the original USB node in DT Kunihiko Hayashi (9): usb: dwc3-generic: Allow different controller DT node pattern usb: dwc3-generic: Add clock initialization in child DT node usb: dwc3-generic: Export glue structures and functions usb: dwc3-generic: Add the size of regs property to glue structure reset: uniphier: Add USB glue reset support clk: uniphier: Add missing USB SS-PHY clocks phy: socionext: Add UniPhier USB3 PHY driver usb: dwc3-uniphier: Use dwc3-generic instead of xhci-dwc3 uniphier_defconfig: Disable USB_XHCI_DWC3 Marek Vasut (1): usb: dwc3: Look up reference clock DT phandle in both controller DT nodes configs/uniphier_v7_defconfig | 1 - configs/uniphier_v8_defconfig | 1 - drivers/clk/uniphier/clk-uniphier-sys.c | 5 + drivers/phy/socionext/Kconfig | 8 ++ drivers/phy/socionext/Makefile| 1 + drivers/phy/socionext/phy-uniphier-usb3.c | 93 +++ drivers/reset/reset-uniphier.c| 78 - drivers/usb/dwc3/Kconfig | 4 +- drivers/usb/dwc3/dwc3-generic.c | 132 ++ drivers/usb/dwc3/dwc3-generic.h | 33 ++ drivers/usb/dwc3/dwc3-uniphier.c | 116 --- 11 files changed, 378 insertions(+), 94 deletions(-) create mode 100644 drivers/phy/socionext/phy-uniphier-usb3.c create mode 100644 drivers/usb/dwc3/dwc3-generic.h -- 2.25.1
[PATCH v3 02/10] usb: dwc3-generic: Allow different controller DT node pattern
The most of devicetree has the following USB node structure.
The controller node is placed as a child node of the glue node.
Current dwc3-generic driver works on this premise.
glue {
/* glue node */
usb {
/* controller node */
};
};
However, UniPhier original devicetree has the following USB node structure.
The controller node is separately placed from the glue node.
usb {
/* controller node */
};
glue {
/* glue node */
};
In dwc_glue_bind(), this patch provides .glue_get_ctrl_dev() callback to
get such a controller node and binds the driver related to the node.
If this callback isn't defined, dwc_glue_bind() looks for the controller
nodes from the child nodes, as before.
Suggested-by: Marek Vasut
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/usb/dwc3/dwc3-generic.c | 93 -
1 file changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 42e92478f25a..e32003d68e01 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -276,6 +276,7 @@ U_BOOT_DRIVER(dwc3_generic_host) = {
#endif
struct dwc3_glue_ops {
+ int (*glue_get_ctrl_dev)(struct udevice *parent, ofnode *node);
void (*glue_configure)(struct udevice *dev, int index,
enum usb_dr_mode mode);
};
@@ -415,54 +416,74 @@ struct dwc3_glue_ops ti_ops = {
.glue_configure = dwc3_ti_glue_configure,
};
-static int dwc3_glue_bind(struct udevice *parent)
+static int dwc3_glue_bind_common(struct udevice *parent, ofnode node)
{
- ofnode node;
- int ret;
+ const char *name = ofnode_get_name(node);
+ const char *driver = NULL;
enum usb_dr_mode dr_mode;
+ struct udevice *dev;
+ int ret;
- dr_mode = usb_get_dr_mode(dev_ofnode(parent));
-
- ofnode_for_each_subnode(node, dev_ofnode(parent)) {
- const char *name = ofnode_get_name(node);
- struct udevice *dev;
- const char *driver = NULL;
-
- debug("%s: subnode name: %s\n", __func__, name);
+ debug("%s: subnode name: %s\n", __func__, name);
- /* if the parent node doesn't have a mode check the leaf */
- if (!dr_mode)
- dr_mode = usb_get_dr_mode(node);
+ /* if the parent node doesn't have a mode check the leaf */
+ dr_mode = usb_get_dr_mode(dev_ofnode(parent));
+ if (!dr_mode)
+ dr_mode = usb_get_dr_mode(node);
- switch (dr_mode) {
- case USB_DR_MODE_PERIPHERAL:
- case USB_DR_MODE_OTG:
+ switch (dr_mode) {
+ case USB_DR_MODE_PERIPHERAL:
+ case USB_DR_MODE_OTG:
#if CONFIG_IS_ENABLED(DM_USB_GADGET)
- debug("%s: dr_mode: OTG or Peripheral\n", __func__);
- driver = "dwc3-generic-peripheral";
+ debug("%s: dr_mode: OTG or Peripheral\n", __func__);
+ driver = "dwc3-generic-peripheral";
#endif
- break;
+ break;
#if defined(CONFIG_SPL_USB_HOST) || !defined(CONFIG_SPL_BUILD)
- case USB_DR_MODE_HOST:
- debug("%s: dr_mode: HOST\n", __func__);
- driver = "dwc3-generic-host";
- break;
+ case USB_DR_MODE_HOST:
+ debug("%s: dr_mode: HOST\n", __func__);
+ driver = "dwc3-generic-host";
+ break;
#endif
- default:
- debug("%s: unsupported dr_mode\n", __func__);
- return -ENODEV;
- };
+ default:
+ debug("%s: unsupported dr_mode\n", __func__);
+ return -ENODEV;
+ };
- if (!driver)
- continue;
+ if (!driver)
+ return -ENXIO;
+
+ ret = device_bind_driver_to_node(parent, driver, name,
+node, &dev);
+ if (ret) {
+ debug("%s: not able to bind usb device mode\n",
+ __func__);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int dwc3_glue_bind(struct udevice *parent)
+{
+ struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(parent);
+ ofnode node;
+ int ret;
- ret = device_bind_driver_to_node(parent, driver, name,
-node, &dev);
- if (ret) {
- debug("%s: not able to bind usb device mode\n",
- __func__);
+ if (ops && ops->glue_get_ctrl_dev) {
+ ret = ops->glue_get_ctrl_dev(parent, &node);
+ if (ret)
+ return ret;
+
+ return dwc3_glue_bind_common(parent, node);
[PATCH v3 01/10] usb: dwc3: Look up reference clock DT phandle in both controller DT nodes
From: Marek Vasut
There are currently four disparate placement possibilities of DWC3
reference clock phandle in SoC DTs:
- in top level glue node, with generic subnode without clock (ZynqMP)
- in top level generic node, with no subnode (i.MX8MQ)
- in generic subnode, with other clock in top level node (i.MX8MP)
- in both top level node and generic subnode (Rockchip)
Cover all the possibilities here by looking into both nodes, start
with the top level node as that seems to be used in majority of DTs
to reference the clock.
Signed-off-by: Marek Vasut
Acked-by: Kunihiko Hayashi
---
drivers/usb/dwc3/dwc3-generic.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 78966718d01d..42e92478f25a 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -68,10 +68,27 @@ static int dwc3_generic_probe(struct udevice *dev,
#if CONFIG_IS_ENABLED(OF_CONTROL)
dwc3_of_parse(dwc3);
+ /*
+* There are currently four disparate placement possibilities of DWC3
+* reference clock phandle in SoC DTs:
+* - in top level glue node, with generic subnode without clock (ZynqMP)
+* - in top level generic node, with no subnode (i.MX8MQ)
+* - in generic subnode, with other clock in top level node (i.MX8MP)
+* - in both top level node and generic subnode (Rockchip)
+* Cover all the possibilities here by looking into both nodes, start
+* with the top level node as that seems to be used in majority of DTs
+* to reference the clock.
+*/
node = dev_ofnode(dev->parent);
index = ofnode_stringlist_search(node, "clock-names", "ref");
if (index < 0)
index = ofnode_stringlist_search(node, "clock-names",
"ref_clk");
+ if (index < 0) {
+ node = dev_ofnode(dev);
+ index = ofnode_stringlist_search(node, "clock-names", "ref");
+ if (index < 0)
+ index = ofnode_stringlist_search(node, "clock-names",
"ref_clk");
+ }
if (index >= 0)
dwc3->ref_clk = &glue->clks.clks[index];
#endif
--
2.25.1
[PATCH v3 03/10] usb: dwc3-generic: Add clock initialization in child DT node
Same as the reset cotnrol, should add a clock initialization in child DT
node, if the glue node doesn't have any clocks.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/usb/dwc3/dwc3-generic.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index e32003d68e01..8fa56e1ac173 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -572,6 +572,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
+ if (glue->clks.count == 0) {
+ ret = dwc3_glue_clk_init(child, glue);
+ if (ret)
+ return ret;
+ }
+
if (glue->resets.count == 0) {
ret = dwc3_glue_reset_init(child, glue);
if (ret)
--
2.25.1
[PATCH v3 07/10] clk: uniphier: Add missing USB SS-PHY clocks
The USB SS-PHY needs its own clock, however, some clocks don't have
clock gates. Define missing clock entries for the PHY as reference
clock.
Signed-off-by: Kunihiko Hayashi
---
drivers/clk/uniphier/clk-uniphier-sys.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c
b/drivers/clk/uniphier/clk-uniphier-sys.c
index ff5d364f5978..3b8595fe610a 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -28,7 +28,10 @@ const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[]
= {
UNIPHIER_CLK_GATE_SIMPLE(14, 0x2104, 16), /* usb30 (Pro4, Pro5,
PXs2) */
UNIPHIER_CLK_GATE_SIMPLE(15, 0x2104, 17), /* usb31 (Pro4, Pro5,
PXs2) */
UNIPHIER_CLK_GATE_SIMPLE(16, 0x2104, 19), /* usb30-phy (PXs2) */
+ UNIPHIER_CLK_RATE(17, 2500),/* usb30-phy2 (PXs2) */
+ UNIPHIER_CLK_RATE(18, 2500),/* usb30-phy3 (PXs2) */
UNIPHIER_CLK_GATE_SIMPLE(20, 0x2104, 20), /* usb31-phy (PXs2) */
+ UNIPHIER_CLK_RATE(21, 2500),/* usb31-phy2 (PXs2) */
UNIPHIER_CLK_GATE_SIMPLE(24, 0x2108, 2),/* pcie (Pro5) */
{ /* sentinel */ }
#endif
@@ -44,6 +47,8 @@ const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] =
{
UNIPHIER_CLK_GATE_SIMPLE(14, 0x210c, 14), /* usb30 (LD20) */
UNIPHIER_CLK_GATE_SIMPLE(16, 0x210c, 12), /* usb30-phy0 (LD20) */
UNIPHIER_CLK_GATE_SIMPLE(17, 0x210c, 13), /* usb30-phy1 (LD20) */
+ UNIPHIER_CLK_RATE(18, 2500),/* usb30-phy2 (LD20) */
+ UNIPHIER_CLK_RATE(19, 2500),/* usb30-phy3 (LD20) */
UNIPHIER_CLK_GATE_SIMPLE(24, 0x210c, 4),/* pcie */
{ /* sentinel */ }
#endif
--
2.25.1
[PATCH v3 06/10] reset: uniphier: Add USB glue reset support
Add reset control support in USB glue logic. This needs to control
the external clocks and resets for the logic before accessing the
glue logic.
The USB dm tree when using dwc3-generic is the following:
USB glue
+-- controller (need controller-reset)
+-- controller-reset (need syscon-reset)
+-- phy
The controller needs to deassert "controller-reset" in USB glue before
the controller registers are accessed. The glue needs to deassert
"syscon-reset" before the glue registers are accessed.
The glue itself doesn't have "syscon-reset", so the controller-reset
controls "syscon-reset" instead.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/reset/reset-uniphier.c | 78 +-
1 file changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index 7adae51873f3..35e3ccebd72e 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -2,6 +2,7 @@
/*
* Copyright (C) 2016 Socionext Inc.
* Author: Masahiro Yamada
+ * Author: Kunihiko Hayashi
*/
#include
@@ -9,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -178,10 +181,17 @@ static const struct uniphier_reset_data
uniphier_pro4_peri_reset_data[] = {
UNIPHIER_RESET_END,
};
+/* Glue reset data */
+static const struct uniphier_reset_data uniphier_pro4_usb3_reset_data[] = {
+ UNIPHIER_RESETX(15, 0, 15)
+};
+
/* core implementaton */
struct uniphier_reset_priv {
void __iomem *base;
const struct uniphier_reset_data *data;
+ struct clk_bulk clks;
+ struct reset_ctl_bulk rsts;
};
static int uniphier_reset_update(struct reset_ctl *reset_ctl, int assert)
@@ -233,10 +243,47 @@ static const struct reset_ops uniphier_reset_ops = {
.rst_deassert = uniphier_reset_deassert,
};
+static int uniphier_reset_rst_init(struct udevice *dev)
+{
+ struct uniphier_reset_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = reset_get_bulk(dev, &priv->rsts);
+ if (ret == -ENOSYS || ret == -ENOENT)
+ return 0;
+ else if (ret)
+ return ret;
+
+ ret = reset_deassert_bulk(&priv->rsts);
+ if (ret)
+ reset_release_bulk(&priv->rsts);
+
+ return ret;
+}
+
+static int uniphier_reset_clk_init(struct udevice *dev)
+{
+ struct uniphier_reset_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = clk_get_bulk(dev, &priv->clks);
+ if (ret == -ENOSYS || ret == -ENOENT)
+ return 0;
+ if (ret)
+ return ret;
+
+ ret = clk_enable_bulk(&priv->clks);
+ if (ret)
+ clk_release_bulk(&priv->clks);
+
+ return ret;
+}
+
static int uniphier_reset_probe(struct udevice *dev)
{
struct uniphier_reset_priv *priv = dev_get_priv(dev);
fdt_addr_t addr;
+ int ret;
addr = dev_read_addr(dev->parent);
if (addr == FDT_ADDR_T_NONE)
@@ -248,7 +295,11 @@ static int uniphier_reset_probe(struct udevice *dev)
priv->data = (void *)dev_get_driver_data(dev);
- return 0;
+ ret = uniphier_reset_clk_init(dev);
+ if (ret)
+ return ret;
+
+ return uniphier_reset_rst_init(dev);
}
static const struct udevice_id uniphier_reset_match[] = {
@@ -355,6 +406,31 @@ static const struct udevice_id uniphier_reset_match[] = {
.compatible = "socionext,uniphier-pxs3-peri-reset",
.data = (ulong)uniphier_pro4_peri_reset_data,
},
+ /* USB glue reset */
+ {
+ .compatible = "socionext,uniphier-pro4-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pro5-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs2-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-ld20-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-pxs3-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
+ {
+ .compatible = "socionext,uniphier-nx1-usb3-reset",
+ .data = (ulong)uniphier_pro4_usb3_reset_data,
+ },
{ /* sentinel */ }
};
--
2.25.1
[PATCH v3 04/10] usb: dwc3-generic: Export glue structures and functions
In order to allow external SoC-dependent glue drivers to use dwc3-generic
functions, push the glue structures and export the functions to a header
file.
The exported structures and functions are:
- struct dwc3_glue_data
- struct dwc3_glue_ops
- dwc3_glue_bind()
- dwc3_glue_probe()
- dwc3_glue_remove()
The SoC-dependent glue drivers can only define their own wrapper driver
and specify these functions. The drivers can also add their own compatible
strings and configure functions.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/usb/dwc3/dwc3-generic.c | 18 --
drivers/usb/dwc3/dwc3-generic.h | 32
2 files changed, 36 insertions(+), 14 deletions(-)
create mode 100644 drivers/usb/dwc3/dwc3-generic.h
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 8fa56e1ac173..4576390ec7cd 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -28,11 +28,7 @@
#include
#include
-struct dwc3_glue_data {
- struct clk_bulk clks;
- struct reset_ctl_bulk resets;
- fdt_addr_t regs;
-};
+#include "dwc3-generic.h"
struct dwc3_generic_plat {
fdt_addr_t base;
@@ -275,12 +271,6 @@ U_BOOT_DRIVER(dwc3_generic_host) = {
};
#endif
-struct dwc3_glue_ops {
- int (*glue_get_ctrl_dev)(struct udevice *parent, ofnode *node);
- void (*glue_configure)(struct udevice *dev, int index,
- enum usb_dr_mode mode);
-};
-
void dwc3_imx8mp_glue_configure(struct udevice *dev, int index,
enum usb_dr_mode mode)
{
@@ -464,7 +454,7 @@ static int dwc3_glue_bind_common(struct udevice *parent,
ofnode node)
return 0;
}
-static int dwc3_glue_bind(struct udevice *parent)
+int dwc3_glue_bind(struct udevice *parent)
{
struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(parent);
ofnode node;
@@ -531,7 +521,7 @@ static int dwc3_glue_clk_init(struct udevice *dev,
return 0;
}
-static int dwc3_glue_probe(struct udevice *dev)
+int dwc3_glue_probe(struct udevice *dev)
{
struct dwc3_glue_ops *ops = (struct dwc3_glue_ops
*)dev_get_driver_data(dev);
struct dwc3_glue_data *glue = dev_get_plat(dev);
@@ -597,7 +587,7 @@ static int dwc3_glue_probe(struct udevice *dev)
return 0;
}
-static int dwc3_glue_remove(struct udevice *dev)
+int dwc3_glue_remove(struct udevice *dev)
{
struct dwc3_glue_data *glue = dev_get_plat(dev);
diff --git a/drivers/usb/dwc3/dwc3-generic.h b/drivers/usb/dwc3/dwc3-generic.h
new file mode 100644
index ..824f678841a8
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-generic.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * dwc3-generic.h - Generic DWC3 Glue layer header
+ *
+ * Copyright (C) 2016 - 2018 Xilinx, Inc.
+ * Copyright (C) 2023 Socionext Inc.
+ */
+
+#ifndef __DRIVERS_USB_DWC3_GENERIC_H
+#define __DRIVERS_USB_DWC3_GENERIC_H
+
+#include
+#include
+#include
+
+struct dwc3_glue_data {
+ struct clk_bulk clks;
+ struct reset_ctl_bulk resets;
+ fdt_addr_t regs;
+};
+
+struct dwc3_glue_ops {
+ int (*glue_get_ctrl_dev)(struct udevice *parent, ofnode *node);
+ void (*glue_configure)(struct udevice *dev, int index,
+ enum usb_dr_mode mode);
+};
+
+int dwc3_glue_bind(struct udevice *parent);
+int dwc3_glue_probe(struct udevice *dev);
+int dwc3_glue_remove(struct udevice *dev);
+
+#endif
--
2.25.1
[PATCH v3 09/10] usb: dwc3-uniphier: Use dwc3-generic instead of xhci-dwc3
dwc3-uniphier depends on xhci-dwc3 framework, however, it is preferable
to use dwc3-generic.
This driver calls the exported dwc3-generic functions and redefine
the SoC-dependent operations to fit dwc3-generic.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/usb/dwc3/Kconfig | 4 +-
drivers/usb/dwc3/dwc3-uniphier.c | 116 ---
2 files changed, 78 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f010291d0223..7ddfa94e518d 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -55,7 +55,9 @@ config USB_DWC3_MESON_GXL
config USB_DWC3_UNIPHIER
bool "DesignWare USB3 Host Support on UniPhier Platforms"
- depends on ARCH_UNIPHIER && USB_XHCI_DWC3
+ depends on ARCH_UNIPHIER && USB_DWC3
+ select USB_DWC3_GENERIC
+ select PHY_UNIPHIER_USB3
help
Support of USB2/3 functionality in Socionext UniPhier platforms.
Say 'Y' here if you have one such device.
diff --git a/drivers/usb/dwc3/dwc3-uniphier.c b/drivers/usb/dwc3/dwc3-uniphier.c
index 54b52dcd66a9..ab85428a7003 100644
--- a/drivers/usb/dwc3/dwc3-uniphier.c
+++ b/drivers/usb/dwc3/dwc3-uniphier.c
@@ -4,14 +4,17 @@
*
* Copyright (C) 2016-2017 Socionext Inc.
* Author: Masahiro Yamada
+ * Author: Kunihiko Hayashi
*/
#include
-#include
+#include
#include
-#include
-#include
-#include
+#include
+
+#include "core.h"
+#include "gadget.h"
+#include "dwc3-generic.h"
#define UNIPHIER_PRO4_DWC3_RESET 0x40
#define UNIPHIER_PRO4_DWC3_RESET_XIOMMU BIT(5)
@@ -27,8 +30,11 @@
#define UNIPHIER_PXS2_DWC3_RESET 0x00
#define UNIPHIER_PXS2_DWC3_RESET_XLINK BIT(15)
-static int uniphier_pro4_dwc3_init(void __iomem *regs)
+static void uniphier_pro4_dwc3_init(struct udevice *dev, int index,
+ enum usb_dr_mode mode)
{
+ struct dwc3_glue_data *glue = dev_get_plat(dev);
+ void *regs = map_physmem(glue->regs, glue->size, MAP_NOCACHE);
u32 tmp;
tmp = readl(regs + UNIPHIER_PRO4_DWC3_RESET);
@@ -36,11 +42,14 @@ static int uniphier_pro4_dwc3_init(void __iomem *regs)
tmp |= UNIPHIER_PRO4_DWC3_RESET_XIOMMU | UNIPHIER_PRO4_DWC3_RESET_XLINK;
writel(tmp, regs + UNIPHIER_PRO4_DWC3_RESET);
- return 0;
+ unmap_physmem(regs, MAP_NOCACHE);
}
-static int uniphier_pro5_dwc3_init(void __iomem *regs)
+static void uniphier_pro5_dwc3_init(struct udevice *dev, int index,
+ enum usb_dr_mode mode)
{
+ struct dwc3_glue_data *glue = dev_get_plat(dev);
+ void *regs = map_physmem(glue->regs, glue->size, MAP_NOCACHE);
u32 tmp;
tmp = readl(regs + UNIPHIER_PRO5_DWC3_RESET);
@@ -49,72 +58,97 @@ static int uniphier_pro5_dwc3_init(void __iomem *regs)
tmp |= UNIPHIER_PRO5_DWC3_RESET_XLINK | UNIPHIER_PRO5_DWC3_RESET_XIOMMU;
writel(tmp, regs + UNIPHIER_PRO5_DWC3_RESET);
- return 0;
+ unmap_physmem(regs, MAP_NOCACHE);
}
-static int uniphier_pxs2_dwc3_init(void __iomem *regs)
+static void uniphier_pxs2_dwc3_init(struct udevice *dev, int index,
+ enum usb_dr_mode mode)
{
+ struct dwc3_glue_data *glue = dev_get_plat(dev);
+ void *regs = map_physmem(glue->regs, glue->size, MAP_NOCACHE);
u32 tmp;
tmp = readl(regs + UNIPHIER_PXS2_DWC3_RESET);
tmp |= UNIPHIER_PXS2_DWC3_RESET_XLINK;
writel(tmp, regs + UNIPHIER_PXS2_DWC3_RESET);
- return 0;
+ unmap_physmem(regs, MAP_NOCACHE);
}
-static int uniphier_dwc3_probe(struct udevice *dev)
+static int dwc3_uniphier_glue_get_ctrl_dev(struct udevice *dev, ofnode *node)
{
- fdt_addr_t base;
- void __iomem *regs;
- int (*init)(void __iomem *regs);
- int ret;
+ struct udevice *child;
+ const char *name;
+ ofnode subnode;
+
+ /*
+* "controller reset" belongs to glue logic, and it should be
+* accessible in .glue_configure() before access to the controller
+* begins.
+*/
+ ofnode_for_each_subnode(subnode, dev_ofnode(dev)) {
+ name = ofnode_get_name(subnode);
+ if (!strncmp(name, "reset", 5))
+ device_bind_driver_to_node(dev, "uniphier-reset",
+ name, subnode, &child);
+ }
+
+ /* Get controller node that is placed separately from the glue node */
+ *node = ofnode_by_compatible(dev_ofnode(dev->parent),
+"socionext,uniphier-dwc3");
- base = dev_read_addr(dev);
- if (base == FDT_ADDR_T_NONE)
- return -EINVAL;
-
- regs = ioremap(base, SZ_32K);
- if (!regs)
- return -ENOMEM;
+ return 0;
+}
- init = (typeof(init))dev_get_driver_data(dev);
- ret = init(regs);
- i
[PATCH v3 05/10] usb: dwc3-generic: Add the size of regs property to glue structure
Add the size of regs property to the glue structure to correctly
specify the register region to map.
Signed-off-by: Kunihiko Hayashi
Reviewed-by: Marek Vasut
---
drivers/usb/dwc3/dwc3-generic.c | 2 +-
drivers/usb/dwc3/dwc3-generic.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 4576390ec7cd..acbf7acb1918 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -542,7 +542,7 @@ int dwc3_glue_probe(struct udevice *dev)
phy.dev = NULL;
}
- glue->regs = dev_read_addr(dev);
+ glue->regs = dev_read_addr_size_index(dev, 0, &glue->size);
ret = dwc3_glue_clk_init(dev, glue);
if (ret)
diff --git a/drivers/usb/dwc3/dwc3-generic.h b/drivers/usb/dwc3/dwc3-generic.h
index 824f678841a8..40902c8923f5 100644
--- a/drivers/usb/dwc3/dwc3-generic.h
+++ b/drivers/usb/dwc3/dwc3-generic.h
@@ -17,6 +17,7 @@ struct dwc3_glue_data {
struct clk_bulk clks;
struct reset_ctl_bulk resets;
fdt_addr_t regs;
+ fdt_size_t size;
};
struct dwc3_glue_ops {
--
2.25.1
[PATCH v3 10/10] uniphier_defconfig: Disable USB_XHCI_DWC3
Replacing with dwc3-generic, no need USB_XHCI_DWC3 anymore. Signed-off-by: Kunihiko Hayashi Reviewed-by: Marek Vasut --- configs/uniphier_v7_defconfig | 1 - configs/uniphier_v8_defconfig | 1 - 2 files changed, 2 deletions(-) diff --git a/configs/uniphier_v7_defconfig b/configs/uniphier_v7_defconfig index d626968c76d4..03feb04b9378 100644 --- a/configs/uniphier_v7_defconfig +++ b/configs/uniphier_v7_defconfig @@ -82,7 +82,6 @@ CONFIG_DM_SPI=y CONFIG_UNIPHIER_SPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y diff --git a/configs/uniphier_v8_defconfig b/configs/uniphier_v8_defconfig index 6a0e2666cf18..ed58b5746e72 100644 --- a/configs/uniphier_v8_defconfig +++ b/configs/uniphier_v8_defconfig @@ -71,7 +71,6 @@ CONFIG_SYSRESET=y CONFIG_SYSRESET_PSCI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -CONFIG_USB_XHCI_DWC3=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_DWC3=y -- 2.25.1
[PATCH v3 08/10] phy: socionext: Add UniPhier USB3 PHY driver
Add USB3 PHY driver support to control clocks and resets for the phy.
Signed-off-by: Kunihiko Hayashi
---
drivers/phy/socionext/Kconfig | 8 ++
drivers/phy/socionext/Makefile| 1 +
drivers/phy/socionext/phy-uniphier-usb3.c | 93 +++
3 files changed, 102 insertions(+)
create mode 100644 drivers/phy/socionext/phy-uniphier-usb3.c
diff --git a/drivers/phy/socionext/Kconfig b/drivers/phy/socionext/Kconfig
index bcd579e98ec1..de87d5b0109b 100644
--- a/drivers/phy/socionext/Kconfig
+++ b/drivers/phy/socionext/Kconfig
@@ -10,3 +10,11 @@ config PHY_UNIPHIER_PCIE
help
Enable this to support PHY implemented in PCIe controller
on UniPhier SoCs.
+
+config PHY_UNIPHIER_USB3
+ bool "UniPhier USB3 PHY driver"
+ depends on PHY && ARCH_UNIPHIER
+ imply REGMAP
+ help
+ Enable this to support PHY implemented in USB3 controller
+ on UniPhier SoCs.
diff --git a/drivers/phy/socionext/Makefile b/drivers/phy/socionext/Makefile
index 5484360b70ff..94d3aa68cfac 100644
--- a/drivers/phy/socionext/Makefile
+++ b/drivers/phy/socionext/Makefile
@@ -4,3 +4,4 @@
#
obj-$(CONFIG_PHY_UNIPHIER_PCIE)+= phy-uniphier-pcie.o
+obj-$(CONFIG_PHY_UNIPHIER_USB3)+= phy-uniphier-usb3.o
diff --git a/drivers/phy/socionext/phy-uniphier-usb3.c
b/drivers/phy/socionext/phy-uniphier-usb3.c
new file mode 100644
index ..ec3774569287
--- /dev/null
+++ b/drivers/phy/socionext/phy-uniphier-usb3.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * phy_uniphier_usb3.c - Socionext UniPhier Usb3 PHY driver
+ * Copyright 2019-2023 Socionext, Inc.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+struct uniphier_usb3phy_priv {
+ struct clk_bulk clks;
+ struct reset_ctl_bulk rsts;
+};
+
+static int uniphier_usb3phy_init(struct phy *phy)
+{
+ struct uniphier_usb3phy_priv *priv = dev_get_priv(phy->dev);
+ int ret;
+
+ ret = clk_enable_bulk(&priv->clks);
+ if (ret)
+ goto out_clk;
+
+ ret = reset_deassert_bulk(&priv->rsts);
+ if (ret)
+ goto out_rst;
+
+ return 0;
+
+out_rst:
+ reset_release_bulk(&priv->rsts);
+out_clk:
+ clk_release_bulk(&priv->clks);
+
+ return ret;
+}
+
+static int uniphier_usb3phy_probe(struct udevice *dev)
+{
+ struct uniphier_usb3phy_priv *priv = dev_get_priv(dev);
+ int ret;
+
+ ret = clk_get_bulk(dev, &priv->clks);
+ if (ret) {
+ if (ret != -ENOSYS && ret != -ENOENT) {
+ printf("Failed to get clocks\n");
+ return ret;
+ }
+ }
+
+ ret = reset_get_bulk(dev, &priv->rsts);
+ if (ret) {
+ if (ret != -ENOSYS && ret != -ENOENT) {
+ printf("Failed to get resets\n");
+ clk_release_bulk(&priv->clks);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static struct phy_ops uniphier_usb3phy_ops = {
+ .init = uniphier_usb3phy_init,
+};
+
+static const struct udevice_id uniphier_usb3phy_ids[] = {
+ { .compatible = "socionext,uniphier-pro4-usb3-ssphy" },
+ { .compatible = "socionext,uniphier-pro5-usb3-hsphy" },
+ { .compatible = "socionext,uniphier-pro5-usb3-ssphy" },
+ { .compatible = "socionext,uniphier-pxs2-usb3-hsphy" },
+ { .compatible = "socionext,uniphier-pxs2-usb3-ssphy" },
+ { .compatible = "socionext,uniphier-ld20-usb3-hsphy" },
+ { .compatible = "socionext,uniphier-ld20-usb3-ssphy" },
+ { .compatible = "socionext,uniphier-pxs3-usb3-hsphy" },
+ { .compatible = "socionext,uniphier-pxs3-usb3-ssphy" },
+ { .compatible = "socionext,uniphier-nx1-usb3-hsphy" },
+ { .compatible = "socionext,uniphier-nx1-usb3-ssphy" },
+ { }
+};
+
+U_BOOT_DRIVER(uniphier_usb3_phy) = {
+ .name = "uniphier-usb3-phy",
+ .id = UCLASS_PHY,
+ .of_match = uniphier_usb3phy_ids,
+ .ops= &uniphier_usb3phy_ops,
+ .probe = uniphier_usb3phy_probe,
+ .priv_auto = sizeof(struct uniphier_usb3phy_priv),
+};
--
2.25.1
Re: [PATCH v1] RFC: rtc: rv8803: avoid bootloop on low voltage of button cell
> Am 08.02.2023 um 09:32 schrieb Michael Walle : > > Am 2023-02-08 08:38, schrieb Oliver Graute: >> if the rtc button cell is on low voltage this can result in a permanent >> bootloop in u-boot because V2F Register is permanent set. >> ### Warning: temperature compensation has stopped >> ### Warning: Voltage low, data is invalid >> resetting ... >> With this patch the bootloop is prevented >> Signed-off-by: Oliver Graute > > I'm curious, how is the call tree here? I don't see the dm_rtc_get() > being called during boot. Basically, you are now just ignoring the error. I use dm_rtc_get() in a modified boot/bootm.c to check for a End-Off Live booting date. Just to prevent that testers uses devices with out-dated images. So if this only affects me so this patch can be ignored. Best regards, Oliver signature.asc Description: Message signed with OpenPGP
[PATCH 1/2] env: mmc: Clean up macro usage
Consistently use 'if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID))' instead of
mix of ifdef and IS_ENABLED. This deals with xPL variants of the config
option and trims ifdeffery.
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
env/mmc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/env/mmc.c b/env/mmc.c
index 5b01f657a7a..b34a8dd982e 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
if (str && !strncmp((const char *)info.name, str,
sizeof(info.name)))
break;
-#ifdef CONFIG_PARTITION_TYPE_GUID
- if (!str) {
+ if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) && !str) {
const efi_guid_t env_guid =
PARTITION_U_BOOT_ENVIRONMENT;
efi_guid_t type_guid;
@@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
break;
}
-#endif
}
/* round up to info.blksz */
@@ -121,7 +119,7 @@ static inline s64 mmc_offset(int copy)
}
/* try the GPT partition with "U-Boot ENV" TYPE GUID */
- if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)) {
+ if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID)) {
err = mmc_offset_try_partition(NULL, copy, &val);
if (!err)
return val;
--
2.39.1
[PATCH 2/2] env: mmc: Apply GPT only on eMMC user HW partition
Apply the GPT U-Boot environment GUID type look up only on eMMC user
HW partition, do not apply the look up on eMMC boot HW partitions as
mmc_offset_try_partition() assumes either SD partitions or eMMC user
HW partition.
This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
env/mmc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/env/mmc.c b/env/mmc.c
index b34a8dd982e..25df750ffd9 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -92,7 +92,7 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
return 0;
}
-static inline s64 mmc_offset(int copy)
+static inline s64 mmc_offset(struct mmc *mmc, int copy)
{
const struct {
const char *offset_redund;
@@ -106,8 +106,12 @@ static inline s64 mmc_offset(int copy)
s64 val = 0, defvalue;
const char *propname;
const char *str;
+ int hwpart = 0;
int err;
+ if (IS_ENABLED(CONFIG_SYS_MMC_ENV_PART))
+ hwpart = mmc_get_env_part(mmc);
+
/* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
str = ofnode_conf_read_str(dt_prop.partition);
if (str) {
@@ -119,7 +123,7 @@ static inline s64 mmc_offset(int copy)
}
/* try the GPT partition with "U-Boot ENV" TYPE GUID */
- if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID)) {
+ if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) && hwpart == 0) {
err = mmc_offset_try_partition(NULL, copy, &val);
if (!err)
return val;
@@ -136,7 +140,7 @@ static inline s64 mmc_offset(int copy)
return ofnode_conf_read_int(propname, defvalue);
}
#else
-static inline s64 mmc_offset(int copy)
+static inline s64 mmc_offset(struct mmc *mmc, int copy)
{
s64 offset = ENV_MMC_OFFSET;
@@ -149,7 +153,7 @@ static inline s64 mmc_offset(int copy)
__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
{
- s64 offset = mmc_offset(copy);
+ s64 offset = mmc_offset(mmc, copy);
if (offset == ENV_MMC_INVALID_OFFSET) {
printf("Invalid ENV offset in MMC, copy=%d\n", copy);
--
2.39.1
[PATCH v2] ARM: dts: imx: Add support for Data Modul i.MX8M Plus eDM SBC
Add support for Data Modul i.MX8M Plus eDM SBC board. This is an
evaluation board for various custom display units. Currently
supported are serial console, ethernet, eMMC, SD, SPI NOR, USB.
Signed-off-by: Marek Vasut
---
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
V2: Rebase on current u-boot master and add changes which landed in
U-Boot upstream since the last submission, i.e. macro rename.
---
arch/arm/dts/Makefile |1 +
.../dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi | 130 ++
arch/arm/dts/imx8mp-data-modul-edm-sbc.dts| 973 +
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/data_modul/imx8mp_edm_sbc/Kconfig | 15 +
board/data_modul/imx8mp_edm_sbc/MAINTAINERS |8 +
board/data_modul/imx8mp_edm_sbc/Makefile | 13 +
.../imx8mp_data_modul_edm_sbc.c | 93 +
board/data_modul/imx8mp_edm_sbc/imximage.cfg |8 +
.../data_modul/imx8mp_edm_sbc/lpddr4_timing.h | 11 +
.../imx8mp_edm_sbc/lpddr4_timing_4G_32.c | 1852 +
board/data_modul/imx8mp_edm_sbc/spl.c | 124 ++
configs/imx8mp_data_modul_edm_sbc_defconfig | 267 +++
include/configs/imx8mp_data_modul_edm_sbc.h | 45 +
14 files changed, 3548 insertions(+)
create mode 100644 arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mp-data-modul-edm-sbc.dts
create mode 100644 board/data_modul/imx8mp_edm_sbc/Kconfig
create mode 100644 board/data_modul/imx8mp_edm_sbc/MAINTAINERS
create mode 100644 board/data_modul/imx8mp_edm_sbc/Makefile
create mode 100644 board/data_modul/imx8mp_edm_sbc/imx8mp_data_modul_edm_sbc.c
create mode 100644 board/data_modul/imx8mp_edm_sbc/imximage.cfg
create mode 100644 board/data_modul/imx8mp_edm_sbc/lpddr4_timing.h
create mode 100644 board/data_modul/imx8mp_edm_sbc/lpddr4_timing_4G_32.c
create mode 100644 board/data_modul/imx8mp_edm_sbc/spl.c
create mode 100644 configs/imx8mp_data_modul_edm_sbc_defconfig
create mode 100644 include/configs/imx8mp_data_modul_edm_sbc.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d9b719f85dd..1159d1b133f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -986,6 +986,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-beacon-kit.dtb \
imx8mq-mnt-reform2.dtb \
imx8mq-phanbell.dtb \
+ imx8mp-data-modul-edm-sbc.dtb \
imx8mp-dhcom-pdk2.dtb \
imx8mp-evk.dtb \
imx8mp-icore-mx8mp-edimm2.2.dtb \
diff --git a/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
b/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
new file mode 100644
index 000..76eb6ef4d0c
--- /dev/null
+++ b/arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 Marek Vasut
+ */
+
+#include "imx8mp-u-boot.dtsi"
+
+/ {
+ aliases {
+ eeprom0 = &eeprom;
+ mmc0 = &usdhc3; /* eMMC */
+ mmc1 = &usdhc2; /* MicroSD */
+ spi0 = &ecspi1;
+ };
+
+ config {
+ dmo,ram-coding-gpios = <&gpio3 20 0>, <&gpio4 3 0>, <&gpio4 1
0>;
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <&wdog1>;
+ u-boot,dm-spl;
+ };
+};
+
+&buck4 {
+ u-boot,dm-spl;
+};
+
+&buck5 {
+ u-boot,dm-spl;
+};
+
+&ecspi1 {
+ u-boot,dm-spl;
+ flash@0 {
+ u-boot,dm-spl;
+ };
+};
+
+&eqos {
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+&gpio1 {
+ u-boot,dm-spl;
+};
+
+&gpio2 {
+ u-boot,dm-spl;
+};
+
+&gpio3 {
+ u-boot,dm-spl;
+};
+
+&gpio4 {
+ u-boot,dm-spl;
+};
+
+&gpio5 {
+ u-boot,dm-spl;
+};
+
+&i2c3 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_ecspi1 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_hog_sbc {
+ u-boot,dm-spl;
+};
+
+&pinctrl_i2c3 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_i2c3_gpio {
+ u-boot,dm-spl;
+};
+
+&pinctrl_pmic {
+ u-boot,dm-spl;
+};
+
+&pinctrl_uart3 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc2 {
+ u-boot,dm-spl;
+};
+
+&pinctrl_usdhc3 {
+ u-boot,dm-spl;
+};
+
+&pmic {
+ u-boot,dm-spl;
+
+ regulators {
+ u-boot,dm-spl;
+ };
+};
+
+&uart3 {
+ u-boot,dm-spl;
+};
+
+&usdhc2 {
+ u-boot,dm-spl;
+ sd-uhs-sdr104;
+ sd-uhs-ddr50;
+};
+
+&usdhc3 {
+ u-boot,dm-spl;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+};
+
+&wdog1 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mp-data-modul-edm-sbc.dts
b/arch/arm/dts/imx8mp-data-modul-edm-sbc.dts
new file mode 100644
index 000..8066f7fb649
--- /dev/null
+++ b/arch/arm/dts/imx8mp-data-modul-edm-sbc.dts
@@ -0,0 +1,973 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2022 Marek Vasut
+ */
+
+/dts-v1/;
+
+#include
+#include "imx
Re: [PATCH v1] RFC: rtc: rv8803: avoid bootloop on low voltage of button cell
Am 2023-02-08 12:29, schrieb Oliver Graute: Am 08.02.2023 um 09:32 schrieb Michael Walle : Am 2023-02-08 08:38, schrieb Oliver Graute: if the rtc button cell is on low voltage this can result in a permanent bootloop in u-boot because V2F Register is permanent set. ### Warning: temperature compensation has stopped ### Warning: Voltage low, data is invalid resetting ... With this patch the bootloop is prevented Signed-off-by: Oliver Graute I'm curious, how is the call tree here? I don't see the dm_rtc_get() being called during boot. Basically, you are now just ignoring the error. I use dm_rtc_get() in a modified boot/bootm.c to check for a End-Off Live booting date. Just to prevent that testers uses devices with out-dated images. So if this only affects me so this patch can be ignored. In this case you should just ignore the return value (and live with bogus values). Or.. handle it gracefully. -michael
Re: [PATCH] doc: Link to some useful talks
On 2/5/23 17:30, Simon Glass wrote: Talks are a great way to learn about U-Boot and have been lost now that the Denx Wiki has gone away. These are stored at elinux.org so link to that . Signed-off-by: Simon Glass --- doc/index.rst | 1 + doc/learn/index.rst | 9 + doc/learn/talks.rst | 11 +++ 3 files changed, 21 insertions(+) create mode 100644 doc/learn/index.rst create mode 100644 doc/learn/talks.rst diff --git a/doc/index.rst b/doc/index.rst index 02de1d46842..57b42c68e44 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -25,6 +25,7 @@ trying to get it to work optimally on a given system. :maxdepth: 2 build/index + learn/index usage/index Developer-oriented documentation diff --git a/doc/learn/index.rst b/doc/learn/index.rst new file mode 100644 index 000..8075c01d1df --- /dev/null +++ b/doc/learn/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Learn about U-Boot +== + +.. toctree:: + :maxdepth: 1 + + talks diff --git a/doc/learn/talks.rst b/doc/learn/talks.rst new file mode 100644 index 000..33bac483e17 --- /dev/null +++ b/doc/learn/talks.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +U-Boot Talks + + +U-Boot is a topic at various conferences each year. These talkes might help you +learn a bit about U-Boot. + +See elinux_talks_ for a list. + +.. _elinux_talks: https://elinux.org/Boot_Loaders#U-Boot Reviewed-by: Sean Anderson
[PATCH 1/1] cmd: CONFIG_CMD_EFICONFIG requires CONFIG_MENU
The eficonfig command invokes functions implemented in common/menu.c like
* menu_default_set()
* menu_get_choice()
* menu_destroy()
* menu_item_add()
Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
Signed-off-by: Heinrich Schuchardt
---
cmd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index c7344ee1f6..aef99d2eb8 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2001,6 +2001,7 @@ config CMD_EFIDEBUG
config CMD_EFICONFIG
bool "eficonfig - provide menu-driven uefi variables maintenance
interface"
depends on CMD_BOOTEFI_BOOTMGR
+ select MENU
help
Enable the 'eficonfig' command which provides the menu-driven UEFI
variable maintenance interface.
--
2.38.1
Re: [PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS
Hi Tom, We currently face an issue on our apalis-imx8 machine, that is not able to boot with a ramdisk. What happens is that there are all 8 of 8 LMBs reserved and fdt tries to allocate one more, probably for relocation. I now stumbled on this recent patch and noticed that in my understanding this is introducing a regression to all the boards you remove `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? For the other question this raises to me is it in general safe to just increase this limit, let's say to 16? And since it was quite an effort debugging this issue I thought of adding a debug print if the MAX cnt in lmb.c is being hit to ease that pain for other devs, would you be fine with something like this? Thanks in advance for your answers, Philippe On Wed, 2023-01-25 at 18:08 -0500, Tom Rini wrote: > The LMB code allows for picking a hard limit on the number of regions > it > can know of, or to dynamically allocate these regions. The reason for > this choice is to allow for the compiler to perform a size > optimization > in the common case. This optimization however, is very small, ranging > from 196 bytes to 15 bytes saved, or in some cases, being larger. Now > that we also have more regions covered by LMB (in order to protect > various parts of our self at run time), the default of 8 is also much > easier to hit and leads to non-obvious error messages (which imply > that > an area is protected, not that we're out of areas to add to the list). > > Switch to the dynamic use as the default. > > Signed-off-by: Tom Rini > --- > configs/a3y17lte_defconfig | 1 - > configs/a5y17lte_defconfig | 1 - > configs/a7y17lte_defconfig | 1 - > configs/dragonboard845c_defconfig | 1 - > configs/mt7981_emmc_rfb_defconfig | 1 - > configs/mt7981_rfb_defconfig | 1 - > configs/mt7981_sd_rfb_defconfig | 1 - > configs/mt7986_rfb_defconfig | 1 - > configs/mt7986a_bpir3_emmc_defconfig | 1 - > configs/mt7986a_bpir3_sd_defconfig | 1 - > configs/qcs404evb_defconfig | 1 - > configs/starqltechn_defconfig | 1 - > lib/Kconfig | 1 - > 13 files changed, 13 deletions(-) > > diff --git a/configs/a3y17lte_defconfig b/configs/a3y17lte_defconfig > index 124fb8d47617..0215c5f234bb 100644 > --- a/configs/a3y17lte_defconfig > +++ b/configs/a3y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/a5y17lte_defconfig b/configs/a5y17lte_defconfig > index ffb0b3f474a6..d1cd97baf512 100644 > --- a/configs/a5y17lte_defconfig > +++ b/configs/a5y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/a7y17lte_defconfig b/configs/a7y17lte_defconfig > index 8c1229d8d5ec..bef2d0945aec 100644 > --- a/configs/a7y17lte_defconfig > +++ b/configs/a7y17lte_defconfig > @@ -24,4 +24,3 @@ CONFIG_SYS_BOOTM_LEN=0x200 > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_DM_I2C_GPIO=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/dragonboard845c_defconfig > b/configs/dragonboard845c_defconfig > index a69d82761a8d..cef82f56108e 100644 > --- a/configs/dragonboard845c_defconfig > +++ b/configs/dragonboard845c_defconfig > @@ -26,4 +26,3 @@ CONFIG_DM_PMIC=y > CONFIG_PMIC_QCOM=y > CONFIG_MSM_GENI_SERIAL=y > CONFIG_SPMI_MSM=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_emmc_rfb_defconfig > b/configs/mt7981_emmc_rfb_defconfig > index b3b37b6e5ed4..4832a2264395 100644 > --- a/configs/mt7981_emmc_rfb_defconfig > +++ b/configs/mt7981_emmc_rfb_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_rfb_defconfig > b/configs/mt7981_rfb_defconfig > index b7ffb4dfa74d..c3975278871e 100644 > --- a/configs/mt7981_rfb_defconfig > +++ b/configs/mt7981_rfb_defconfig > @@ -64,4 +64,3 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_MTK_SPIM=y > CONFIG_HEXDUMP=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7981_sd_rfb_defconfig > b/configs/mt7981_sd_rfb_defconfig > index 85be9bbc5030..17592dc22b9a 100644 > --- a/configs/mt7981_sd_rfb_defconfig > +++ b/configs/mt7981_sd_rfb_defconfig > @@ -62,4 +62,3 @@ CONFIG_MTK_SERIAL=y > CONFIG_FAT_WRITE=y > CONFIG_HEXDUMP=y > # CONFIG_EFI_LOADER is not set > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7986_rfb_defconfig > b/configs/mt7986_rfb_defconfig > index ac91c93efb42..1363f9dc6d0b 100644 > --- a/configs/mt7986_rfb_defconfig > +++ b/configs/mt7986_rfb_defconfig > @@ -64,4 +64,3 @@ CONFIG_SPI=y > CONFIG_DM_SPI=y > CONFIG_MTK_SPIM=y > CONFIG_HEXDUMP=y > -CONFIG_LMB_MAX_REGIONS=64 > diff --git a/configs/mt7986a_bpir3_emmc_defconfig > b/configs/mt7986a_bpir3_emmc_defconfig > index 2d4876f299f4..
Re: [PATCH v2 1/2] rockchip: sdram: add basic support for sdram reg info version 3
On 2023/2/8 01:27, Jonas Karlman wrote:
Newer DRAM initialization blobs from vendor can encode sdram info in a
new version 3 format. The new format makes use of more bits in sys_reg3
compared to the version 2 format.
Add basic support for detecting the version 3 format and decoding the
high bits used for ddrtype.
This fixes decode of sdram size on my RK3568 boards that have LPDDR4X.
Details on the new format was deciphered from vendor u-boot commit [1].
[1]
https://github.com/rockchip-linux/u-boot/commit/c69667e0e2bf4290ab1f408fcde58b8806ac266b
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v2:
- No change
arch/arm/include/asm/arch-rockchip/sdram.h | 28 +++---
arch/arm/mach-rockchip/sdram.c | 9 +--
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/arch-rockchip/sdram.h
b/arch/arm/include/asm/arch-rockchip/sdram.h
index cf2a7b7d105f..4fb45ac5c76e 100644
--- a/arch/arm/include/asm/arch-rockchip/sdram.h
+++ b/arch/arm/include/asm/arch-rockchip/sdram.h
@@ -8,10 +8,13 @@
enum {
DDR4 = 0,
- DDR3 = 0x3,
- LPDDR2 = 0x5,
- LPDDR3 = 0x6,
- LPDDR4 = 0x7,
+ DDR3 = 3,
+ LPDDR2 = 5,
+ LPDDR3 = 6,
+ LPDDR4 = 7,
+ LPDDR4X = 8,
+ LPDDR5 = 9,
+ DDR5 = 10,
UNUSED = 0xFF
};
@@ -21,16 +24,16 @@ enum {
* [30] row_3_4_ch0
* [29:28]chinfo
* [27] rank_ch1
- * [26:25] col_ch1
+ * [26:25] cs0_col_ch1
* [24] bk_ch1
* [23:22]low bits of cs0_row_ch1
* [21:20]low bits of cs1_row_ch1
* [19:18]bw_ch1
- * [17:16] dbw_ch1;
- * [15:13] ddrtype
+ * [17:16] dbw_ch1
+ * [15:13] low bits of ddrtype
* [12] channelnum
- * [11]rank_ch0
- * [10:9] col_ch0,
+ * [11]low bit of rank_ch0
+ * [10:9] cs0_col_ch0
* [8]bk_ch0
* [7:6] low bits of cs0_row_ch0
* [5:4] low bits of cs1_row_ch0
@@ -61,6 +64,11 @@ enum {
/*
* sys_reg3 bitfield struct
+ * [31:28] version
+ * [16]cs3_delta_row
+ * [15]cs2_delta_row
+ * [14]high bit of rank_ch0
+ * [13:12] high bits of ddrtype
* [7]high bit of cs0_row_ch1
* [6]high bit of cs1_row_ch1
* [5]high bit of cs0_row_ch0
@@ -70,6 +78,8 @@ enum {
*/
#define SYS_REG_VERSION_SHIFT 28
#define SYS_REG_VERSION_MASK 0xf
+#define SYS_REG_EXTEND_DDRTYPE_SHIFT 12
+#define SYS_REG_EXTEND_DDRTYPE_MASK3
#define SYS_REG_EXTEND_CS0_ROW_SHIFT(ch) (5 + (ch) * 2)
#define SYS_REG_EXTEND_CS0_ROW_MASK 1
#define SYS_REG_EXTEND_CS1_ROW_SHIFT(ch) (4 + (ch) * 2)
diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index e086c47f3c00..91951e4b8ccf 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -88,9 +88,15 @@ size_t rockchip_sdram_size(phys_addr_t reg)
u32 sys_reg3 = readl(reg + 4);
u32 ch_num = 1 + ((sys_reg2 >> SYS_REG_NUM_CH_SHIFT)
& SYS_REG_NUM_CH_MASK);
+ u32 version = (sys_reg3 >> SYS_REG_VERSION_SHIFT) &
+ SYS_REG_VERSION_MASK;
dram_type = (sys_reg2 >> SYS_REG_DDRTYPE_SHIFT) & SYS_REG_DDRTYPE_MASK;
+ if (version >= 3)
+ dram_type |= ((sys_reg3 >> SYS_REG_EXTEND_DDRTYPE_SHIFT) &
+ SYS_REG_EXTEND_DDRTYPE_MASK) << 3;
debug("%s %x %x\n", __func__, (u32)reg, sys_reg2);
+ debug("%s %x %x\n", __func__, (u32)reg + 4, sys_reg3);
for (ch = 0; ch < ch_num; ch++) {
rank = 1 + (sys_reg2 >> SYS_REG_RANK_SHIFT(ch) &
SYS_REG_RANK_MASK);
@@ -98,8 +104,7 @@ size_t rockchip_sdram_size(phys_addr_t reg)
SYS_REG_COL_MASK);
cs1_col = cs0_col;
bk = 3 - ((sys_reg2 >> SYS_REG_BK_SHIFT(ch)) & SYS_REG_BK_MASK);
- if ((sys_reg3 >> SYS_REG_VERSION_SHIFT &
-SYS_REG_VERSION_MASK) == 0x2) {
+ if (version >= 2) {
cs1_col = 9 + (sys_reg3 >> SYS_REG_CS1_COL_SHIFT(ch) &
SYS_REG_CS1_COL_MASK);
if (((sys_reg3 >> SYS_REG_EXTEND_CS0_ROW_SHIFT(ch) &
Re: [PATCH v2 2/2] rockchip: sdram: add dram bank with usable memory beyond 4GB
On 2023/2/8 01:27, Jonas Karlman wrote:
Add a second dram bank of usable memory beyond the blob of space for
peripheral near 4GB. Any memory that exists beyond the 4GB mark is added
to the second bank.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v2:
- Change CONFIG_SYS_SDRAM_BASE to CFG_SYS_SDRAM_BASE
arch/arm/mach-rockchip/sdram.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-rockchip/sdram.c b/arch/arm/mach-rockchip/sdram.c
index 91951e4b8ccf..1d17a740ade9 100644
--- a/arch/arm/mach-rockchip/sdram.c
+++ b/arch/arm/mach-rockchip/sdram.c
@@ -37,13 +37,19 @@ struct tos_parameter_t {
int dram_init_banksize(void)
{
- size_t top = min((unsigned long)(gd->ram_size + CFG_SYS_SDRAM_BASE),
-(unsigned long)(gd->ram_top));
+ size_t ram_top = (unsigned long)(gd->ram_size + CFG_SYS_SDRAM_BASE);
+ size_t top = min((unsigned long)ram_top, (unsigned long)(gd->ram_top));
#ifdef CONFIG_ARM64
/* Reserve 0x20 for ATF bl31 */
gd->bd->bi_dram[0].start = 0x20;
gd->bd->bi_dram[0].size = top - gd->bd->bi_dram[0].start;
+
+ /* Add usable memory beyond the blob of space for peripheral near 4GB */
+ if (ram_top > SZ_4G && top < SZ_4G) {
+ gd->bd->bi_dram[1].start = SZ_4G;
+ gd->bd->bi_dram[1].size = ram_top - gd->bd->bi_dram[1].start;
+ }
#else
#ifdef CONFIG_SPL_OPTEE_IMAGE
struct tos_parameter_t *tos_parameter;
@@ -181,7 +187,7 @@ size_t rockchip_sdram_size(phys_addr_t reg)
* 2. update board_get_usable_ram_top() and dram_init_banksize()
* to reserve memory for peripheral space after previous update.
*/
- if (size_mb > (SDRAM_MAX_SIZE >> 20))
+ if (!IS_ENABLED(CONFIG_ARM64) && size_mb > (SDRAM_MAX_SIZE >> 20))
size_mb = (SDRAM_MAX_SIZE >> 20);
return (size_t)size_mb << 20;
Re: [PATCH 0/3] rockchip: Use external TPL binary to create a working firmware image
Hi Simon, On 2023-02-07 05:02, Simon Glass wrote: > Hi Jonas, > > On Sun, 5 Feb 2023 at 13:21, Jonas Karlman wrote: >> >> Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps >> back to boot-rom to load the next stage of the boot flow, U-Boot SPL. >> >> For RK356x there is currently no support to initialize DRAM using U-Boot >> TPL and instead an external TPL binary must be used to generate a >> working u-boot-rockchip.bin image. > > Who is working on this suppose? Having a binary blob is a pain. Not sure if anyone is working on this, but I am hoping that someday someone will work on this :-) > >> >> This adds a new generic external-tpl entry to binman and make use of >> this new entry in rockchip-u-boot.dtsi. >> >> Please note that the allow-missing flag and the added missing-msg entry >> does not work as expected becuase the wrapping mkimage entry used >> requires that the files to all child entries exists. >> Instead without a provided EXTERNAL_TPL the build fails with: >> >> ValueError: Filename 'ddr.bin' not found in input path (...) >> >> originating from >> >> Entry_mkimage.ObtainContents: >> fnames.append(tools.get_input_filename(entry.GetDefaultFilename())) >> >> Not sure how to properly add support for allow-missing flag to mkimage >> entry, possible something for another series? > > If it's an input file, then Bincan supports creating a fake external > blob, which should already be handled in mkimage.py > > But if I misunderstand, or there is a bug, let me know. I think there may be a bug, mkimage with multiple-data-files does not handle missing/optional external blobs in a way that I was expecting. Will take a closer look for v2, or at least create a testcase to reproduce such issue. Will also rename to rockchip-tpl and address rest of your comments in v2. Regards, Jonas > > Eegards, > SImon > > > >> >> Regards, >> Jonas >> >> Jonas Karlman (3): >> binman: Add support for an external-tpl entry >> rockchip: Require an external TPL binary when TPL is missing >> Revert "board: rockchip: Fix binman_init failure on EVB-RK3568" >> >> Makefile | 1 + >> arch/arm/dts/rockchip-u-boot.dtsi | 16 >> configs/evb-rk3568_defconfig | 1 - >> tools/binman/entries.rst | 12 >> tools/binman/etype/external_tpl.py | 18 ++ >> tools/binman/ftest.py | 7 +++ >> tools/binman/missing-blob-help | 5 + >> tools/binman/test/277_external_tpl.dts | 16 >> 8 files changed, 71 insertions(+), 5 deletions(-) >> create mode 100644 tools/binman/etype/external_tpl.py >> create mode 100644 tools/binman/test/277_external_tpl.dts >> >> -- >> 2.39.1 >>
Re: [PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS
On Wed, Feb 08, 2023 at 02:33:58PM +, Philippe Schenker wrote: > Hi Tom, > > We currently face an issue on our apalis-imx8 machine, that is not able > to boot with a ramdisk. What happens is that there are all 8 of 8 LMBs > reserved and fdt tries to allocate one more, probably for relocation. > > I now stumbled on this recent patch and noticed that in my understanding > this is introducing a regression to all the boards you remove > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > For the other question this raises to me is it in general safe to just > increase this limit, let's say to 16? > > And since it was quite an effort debugging this issue I thought of > adding a debug print if the MAX cnt in lmb.c is being hit to ease that > pain for other devs, would you be fine with something like this? Right, so with the late in the cycle change to make EFI use LMBs as well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The change here switches from a static allocation of a maximum number of LMBs to dynamically allocating as many of them as needed. -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] lmb: Treat a region which is a subset as equal
On Wed, Feb 08, 2023 at 08:37:15AM +0100, Sjoerd Simons wrote:
> On Mon, 2023-02-06 at 13:04 -0500, Tom Rini wrote:
> > On Thu, Jan 19, 2023 at 09:38:19AM +0100, Sjoerd Simons wrote:
> >
> > > In various cases logical memory blocks are coalesced; As a result
> > > doing
> > > a strict check whether memory blocks are the same doesn't
> > > necessarily
> > > work as a previous addition of a given block might have been merged
> > > into
> > > a bigger block.
> > >
> > > Fix this by considering a block is already registered if it's a
> > > pure
> > > subset of one of the existing blocks.
> > >
> > > Signed-off-by: Sjoerd Simons
> > > ---
> > >
> > > lib/lmb.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/lib/lmb.c b/lib/lmb.c
> > > index f447c639a60..b09a043f4c2 100644
> > > --- a/lib/lmb.c
> > > +++ b/lib/lmb.c
> > > @@ -248,7 +248,7 @@ static long lmb_add_region_flags(struct
> > > lmb_region *rgn, phys_addr_t base,
> > > phys_size_t rgnsize = rgn->region[i].size;
> > > phys_size_t rgnflags = rgn->region[i].flags;
> > >
> > > - if (rgnbase == base && rgnsize == size) {
> > > + if (rgnbase <= base && rgnbase + rgnsize >= base +
> > > size) {
> > > if (flags == rgnflags)
> > > /* Already have this region, so
> > > we're done */
> > > return 0;
> >
> > This breaks lib_test_lmb_simple, lib_test_lmb_simple_x2 and
> > lib_test_lmb_alloc_addr.
>
> Oh sorry for missing that; I'll get those fixed. Does the direction at
> least seem sensible to you ?
I think so, yes.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS
On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: > On Wed, Feb 08, 2023 at 02:33:58PM +, Philippe Schenker wrote: > > > Hi Tom, > > > > We currently face an issue on our apalis-imx8 machine, that is not > > able > > to boot with a ramdisk. What happens is that there are all 8 of 8 > > LMBs > > reserved and fdt tries to allocate one more, probably for > > relocation. > > > > I now stumbled on this recent patch and noticed that in my > > understanding > > this is introducing a regression to all the boards you remove > > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > > > For the other question this raises to me is it in general safe to > > just > > increase this limit, let's say to 16? > > > > And since it was quite an effort debugging this issue I thought of > > adding a debug print if the MAX cnt in lmb.c is being hit to ease > > that > > pain for other devs, would you be fine with something like this? > > Right, so with the late in the cycle change to make EFI use LMBs as > well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The > change here switches from a static allocation of a maximum number of > LMBs to dynamically allocating as many of them as needed. But since you no longer enable LMB_USE_MAX_REGIONS then theres the two limits (default=8) LMB_MEMORY_REGIONS=8 LMB_RESERVED_REGIONS=8 that are limiting the maximum LMB numbers. So in my view this commit does create a regression for all boards you delete `CONFIG_LMB_MAX_REGIONS=64`. At least for me rgn->max is still set to 8 and also after this commit I hit that limit. [1] [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288
Re: [PATCH] lmb: Default to not-LMB_USE_MAX_REGIONS
On Wed, Feb 08, 2023 at 03:13:31PM +, Philippe Schenker wrote: > On Wed, 2023-02-08 at 09:54 -0500, Tom Rini wrote: > > On Wed, Feb 08, 2023 at 02:33:58PM +, Philippe Schenker wrote: > > > > > Hi Tom, > > > > > > We currently face an issue on our apalis-imx8 machine, that is not > > > able > > > to boot with a ramdisk. What happens is that there are all 8 of 8 > > > LMBs > > > reserved and fdt tries to allocate one more, probably for > > > relocation. > > > > > > I now stumbled on this recent patch and noticed that in my > > > understanding > > > this is introducing a regression to all the boards you remove > > > `CONFIG_LMB_MAX_REGIONS=64` isn't it? Or do I miss something? > > > > > > For the other question this raises to me is it in general safe to > > > just > > > increase this limit, let's say to 16? > > > > > > And since it was quite an effort debugging this issue I thought of > > > adding a debug print if the MAX cnt in lmb.c is being hit to ease > > > that > > > pain for other devs, would you be fine with something like this? > > > > Right, so with the late in the cycle change to make EFI use LMBs as > > well, a lot of platforms hit the 8 of 8 LMBs now in use problem. The > > change here switches from a static allocation of a maximum number of > > LMBs to dynamically allocating as many of them as needed. > > > But since you no longer enable LMB_USE_MAX_REGIONS then theres the two > limits (default=8) > > LMB_MEMORY_REGIONS=8 > LMB_RESERVED_REGIONS=8 > > that are limiting the maximum LMB numbers. So in my view this commit > does create a regression for all boards you delete > `CONFIG_LMB_MAX_REGIONS=64`. > > At least for me rgn->max is still set to 8 and also after this commit I > hit that limit. [1] > > [1] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/lmb.c#L288 Ugh, you're right and I missed what this ended up doing, thanks for explaining it. I'll go revert my commit shortly and pick up one of the ones that raised the default. -- Tom signature.asc Description: PGP signature
[PATCH] Revert "lmb: Default to not-LMB_USE_MAX_REGIONS"
As explained by Philippe Schenker, I was misinterpreting what happened in the case where we do not set LMB_USE_MAX_REGIONS and so had re-introduced the problem I was attempting to more widely resolve. This reverts commit 007ae5d108a37564905ea1588cb279f3a522cc3d. Reported-by: Philippe Schenker Signed-off-by: Tom Rini --- configs/a3y17lte_defconfig | 1 + configs/a5y17lte_defconfig | 1 + configs/a7y17lte_defconfig | 1 + configs/dragonboard845c_defconfig| 1 + configs/mt7981_emmc_rfb_defconfig| 1 + configs/mt7981_rfb_defconfig | 1 + configs/mt7981_sd_rfb_defconfig | 1 + configs/mt7986_rfb_defconfig | 1 + configs/mt7986a_bpir3_emmc_defconfig | 1 + configs/mt7986a_bpir3_sd_defconfig | 1 + configs/qcs404evb_defconfig | 1 + configs/starqltechn_defconfig| 1 + lib/Kconfig | 1 + 13 files changed, 13 insertions(+) diff --git a/configs/a3y17lte_defconfig b/configs/a3y17lte_defconfig index 0215c5f234bb..124fb8d47617 100644 --- a/configs/a3y17lte_defconfig +++ b/configs/a3y17lte_defconfig @@ -24,3 +24,4 @@ CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/a5y17lte_defconfig b/configs/a5y17lte_defconfig index d1cd97baf512..ffb0b3f474a6 100644 --- a/configs/a5y17lte_defconfig +++ b/configs/a5y17lte_defconfig @@ -24,3 +24,4 @@ CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/a7y17lte_defconfig b/configs/a7y17lte_defconfig index bef2d0945aec..8c1229d8d5ec 100644 --- a/configs/a7y17lte_defconfig +++ b/configs/a7y17lte_defconfig @@ -24,3 +24,4 @@ CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_DM_I2C_GPIO=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/dragonboard845c_defconfig b/configs/dragonboard845c_defconfig index cef82f56108e..a69d82761a8d 100644 --- a/configs/dragonboard845c_defconfig +++ b/configs/dragonboard845c_defconfig @@ -26,3 +26,4 @@ CONFIG_DM_PMIC=y CONFIG_PMIC_QCOM=y CONFIG_MSM_GENI_SERIAL=y CONFIG_SPMI_MSM=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_emmc_rfb_defconfig b/configs/mt7981_emmc_rfb_defconfig index 4832a2264395..b3b37b6e5ed4 100644 --- a/configs/mt7981_emmc_rfb_defconfig +++ b/configs/mt7981_emmc_rfb_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_rfb_defconfig b/configs/mt7981_rfb_defconfig index c3975278871e..b7ffb4dfa74d 100644 --- a/configs/mt7981_rfb_defconfig +++ b/configs/mt7981_rfb_defconfig @@ -64,3 +64,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_sd_rfb_defconfig b/configs/mt7981_sd_rfb_defconfig index 17592dc22b9a..85be9bbc5030 100644 --- a/configs/mt7981_sd_rfb_defconfig +++ b/configs/mt7981_sd_rfb_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986_rfb_defconfig b/configs/mt7986_rfb_defconfig index 1363f9dc6d0b..ac91c93efb42 100644 --- a/configs/mt7986_rfb_defconfig +++ b/configs/mt7986_rfb_defconfig @@ -64,3 +64,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_emmc_defconfig b/configs/mt7986a_bpir3_emmc_defconfig index 354159df9b2e..2d4876f299f4 100644 --- a/configs/mt7986a_bpir3_emmc_defconfig +++ b/configs/mt7986a_bpir3_emmc_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_sd_defconfig b/configs/mt7986a_bpir3_sd_defconfig index db7ef98d807b..08edfe7ac409 100644 --- a/configs/mt7986a_bpir3_sd_defconfig +++ b/configs/mt7986a_bpir3_sd_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/qcs404evb_defconfig b/configs/qcs404evb_defconfig index d3608cae9f90..dae155141152 100644 --- a/configs/qcs404evb_defconfig +++ b/configs/qcs404evb_defconfig @@ -51,3 +51,4 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y CONFIG_USB_DWC3_GENERIC=y CONFIG_USB_STORAGE=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/starqltechn_defconfig b/configs/starqltechn_defconfig index 81fd7b22676e..7a64f2a7a088 100644 --- a/configs/starqltechn_defconfig +++ b/configs/starqltechn_defconfig @@ -33,3 +33,4 @@ CONFIG_VIDEO=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_VIDEO_SIMPLE=y CONFIG_VIDEO_DT_SIMPLEFB=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/lib/Kconfig b/lib/Kconfig index 59e4304afd1a..549bd3577851 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -1028,6 +1028,7 @@ config LMB config LMB_USE_MAX_REGIONS bool "Use a common numbe
Re: [PATCH 1/2] env: mmc: Clean up macro usage
On Wed, Feb 08, 2023 at 12:32:43PM +0100, Marek Vasut wrote:
> Consistently use 'if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID))' instead of
> mix of ifdef and IS_ENABLED. This deals with xPL variants of the config
> option and trims ifdeffery.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Tom Rini
> ---
> env/mmc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index 5b01f657a7a..b34a8dd982e 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
>
> if (str && !strncmp((const char *)info.name, str,
> sizeof(info.name)))
> break;
> -#ifdef CONFIG_PARTITION_TYPE_GUID
> - if (!str) {
> + if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) && !str) {
> const efi_guid_t env_guid =
> PARTITION_U_BOOT_ENVIRONMENT;
> efi_guid_t type_guid;
>
> @@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
> if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
> break;
> }
> -#endif
> }
>
> /* round up to info.blksz */
> @@ -121,7 +119,7 @@ static inline s64 mmc_offset(int copy)
> }
>
> /* try the GPT partition with "U-Boot ENV" TYPE GUID */
> - if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)) {
> + if (CONFIG_IS_ENABLED(PARTITION_TYPE_GUID)) {
> err = mmc_offset_try_partition(NULL, copy, &val);
> if (!err)
> return val;
I don't think this is right as we don't have xPL options for
PARTITION_TYPE_GUID and do want to have the same environment location
used in all stages (aside from when xPL says it only has no where for
the env), yes?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/3] rockchip: Require an external TPL binary when TPL is missing
Hi Quentin,
On 2023/2/6 19:26, Quentin Schulz wrote:
Hi Jonas,
On 2/5/23 21:21, Jonas Karlman wrote:
Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps
back to boot-rom to load the next stage of the boot flow, U-Boot SPL.
For RK356x there is currently no support to initialize DRAM using U-Boot
TPL and instead an external TPL binary must be used to generate a
working u-boot-rockchip.bin image.
Use the new external-tpl entry unless CONFIG_TPL=y to indicate that an
external TPL binary must be provided to generate a working firmware.
Signed-off-by: Jonas Karlman
---
Makefile | 1 +
arch/arm/dts/rockchip-u-boot.dtsi | 16
tools/binman/missing-blob-help | 5 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 7eaf45496c1c..7e9272be937f 100644
--- a/Makefile
+++ b/Makefile
@@ -1332,6 +1332,7 @@ cmd_binman = $(srctree)/tools/binman/binman
$(if $(BINMAN_DEBUG),-D) \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
+ -a external-tpl-path=$(EXTERNAL_TPL) \
-a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index 6c662a72d4f9..bc3bc9bc3e37 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -20,12 +20,16 @@
mkimage {
filename = "idbloader.img";
args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
-#ifdef CONFIG_TPL
multiple-data-files;
+#ifdef CONFIG_TPL
u-boot-tpl {
- };
+#else
+ external-tpl {
+ filename = "ddr.bin";
+ missing-msg = "external-tpl-rockchip";
#endif
+ };
NACK. This forces the use of a TPL (either built by U-Boot or
external) which is not always the case. There are still boards without
a TPL which work perfectly fine (at least I would hope so :) ).
Basically there are three possible cases:
SPL
TPL+SPL
TPL(external blob)+SPL
I'm afraid all the boards support by mainline U-Boot is using
"TPL(U-Boot or external)+SPL+U-Boot" mode, and this mode also always
used by rockchip vendor branch.
For "SPL+U-Boot" use case, it only happen many years ago in some of
rk3288 board and rk3399 board,
the SPL will need to support both sdram driver and storage(SPI, SDCard,
eMMC) driver and without back to BootRom,
and other function may add to SPL, but the sram size limit is always
there, so all the rk3288 and rk3399 board have migrate to use
"TPL+SPL+U-Boot.itb" mode.
The "TPL+SPL+U-Boot.itb" is much clear and easy to maintine for all the
boards and will be the only accept mode for new board support in the
future on rockchip platform:
- TPL for dram init;
- SPL for storage init and load next stage firmware, decode FIT image
with ATF/OPTEE support, secure boot support and etc;
- U-Boot.itb including ATF and U-Boot proper, maybe also OPTEE.
This model can very easy to do the debug with replace the binary from
rockchip vendor tree during board bringup.
The SPL+U-Boot mode can only happen for legacy board with only need
U-Boot raw image instead of itb which including trust support,
this kind of board can get the image with only one mkimage command, I
don't think it will need binman support because it only have one image.
Thanks,
- Kever
Here you remove the ability to have SPL only.
Hence why I suggested we add a new Kconfig option for EXTERNAL_TPL,
not for the path but to explicit this third possibility.
Cheers,
Quentin
u-boot-spl {
};
};
@@ -134,12 +138,16 @@
mkimage {
filename = "idbloader-spi.img";
args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
-#ifdef CONFIG_TPL
multiple-data-files;
+#ifdef CONFIG_TPL
u-boot-tpl {
- };
+#else
+ external-tpl {
+ filename = "ddr.bin";
+ missing-msg = "external-tpl-rockchip";
#endif
+ };
u-boot-spl {
};
};
diff --git a/tools/binman/missing-blob-help
b/tools/binman/missing-blob-help
index c61ca02a35ee..e850824032dd 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -14,6 +14,11 @@ atf-bl31-sunxi:
Please read the section on ARM Trusted Firmware (ATF) in
board/sunxi/README.sunxi64
+external-tpl-rockchip:
+External TPL is required to initialize DRAM. Get external TPL binary
and
+build with EXTERNAL_TPL=/path/to/ddr.bin. One possible source for
+external TPL binary is
https://urldefense.com/v3/__https://github.com/rockchip-linux/rkbin__;!!OOPJP91ZZw!jRwonQRHKoxzegx3S3cRYfalkhW1ESLyBCTmVc2c6fnmPaQBOZyxG2I7phwM3pEZxR2QIHQG8Hw3JStyx4tDcMsalwYDCg$
.
+
Re: [PATCH 2/3] rockchip: Require an external TPL binary when TPL is missing
Hi Kever,
On 2/8/23 16:41, Kever Yang wrote:
Hi Quentin,
On 2023/2/6 19:26, Quentin Schulz wrote:
Hi Jonas,
On 2/5/23 21:21, Jonas Karlman wrote:
Rockchip SoCs typically use U-Boot TPL to initialize DRAM, then jumps
back to boot-rom to load the next stage of the boot flow, U-Boot SPL.
For RK356x there is currently no support to initialize DRAM using U-Boot
TPL and instead an external TPL binary must be used to generate a
working u-boot-rockchip.bin image.
Use the new external-tpl entry unless CONFIG_TPL=y to indicate that an
external TPL binary must be provided to generate a working firmware.
Signed-off-by: Jonas Karlman
---
Makefile | 1 +
arch/arm/dts/rockchip-u-boot.dtsi | 16
tools/binman/missing-blob-help | 5 +
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 7eaf45496c1c..7e9272be937f 100644
--- a/Makefile
+++ b/Makefile
@@ -1332,6 +1332,7 @@ cmd_binman = $(srctree)/tools/binman/binman
$(if $(BINMAN_DEBUG),-D) \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
+ -a external-tpl-path=$(EXTERNAL_TPL) \
-a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index 6c662a72d4f9..bc3bc9bc3e37 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -20,12 +20,16 @@
mkimage {
filename = "idbloader.img";
args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
-#ifdef CONFIG_TPL
multiple-data-files;
+#ifdef CONFIG_TPL
u-boot-tpl {
- };
+#else
+ external-tpl {
+ filename = "ddr.bin";
+ missing-msg = "external-tpl-rockchip";
#endif
+ };
NACK. This forces the use of a TPL (either built by U-Boot or
external) which is not always the case. There are still boards without
a TPL which work perfectly fine (at least I would hope so :) ).
Basically there are three possible cases:
SPL
TPL+SPL
TPL(external blob)+SPL
I'm afraid all the boards support by mainline U-Boot is using
"TPL(U-Boot or external)+SPL+U-Boot" mode, and this mode also always
used by rockchip vendor branch.
That seems to be incorrect.
for conf in $(git grep -l ARCH_ROCKCHIP configs); do
make $(basename $conf) > /dev/null 2>&1
if ! grep -q CONFIG_TPL=y .config; then
echo $conf does not enable TPL;
fi
done
returns:
configs/chromebit_mickey_defconfig does not enable TPL
configs/chromebook_bob_defconfig does not enable TPL
configs/chromebook_jerry_defconfig does not enable TPL
configs/chromebook_kevin_defconfig does not enable TPL
configs/chromebook_minnie_defconfig does not enable TPL
configs/chromebook_speedy_defconfig does not enable TPL
configs/elgin-rv1108_defconfig does not enable TPL
configs/evb-rk3036_defconfig does not enable TPL
configs/evb-rk3128_defconfig does not enable TPL
configs/evb-rk3308_defconfig does not enable TPL
configs/evb-rk3568_defconfig does not enable TPL
configs/evb-rv1108_defconfig does not enable TPL
configs/ficus-rk3399_defconfig does not enable TPL
configs/geekbox_defconfig does not enable TPL
configs/kylin-rk3036_defconfig does not enable TPL
configs/miqi-rk3288_defconfig does not enable TPL
configs/phycore-rk3288_defconfig does not enable TPL
configs/popmetal-rk3288_defconfig does not enable TPL
configs/roc-cc-rk3308_defconfig does not enable TPL
configs/rock2_defconfig does not enable TPL
configs/rock_defconfig does not enable TPL
configs/sheep-rk3368_defconfig does not enable TPL
is there something I'm missing?
For "SPL+U-Boot" use case, it only happen many years ago in some of
rk3288 board and rk3399 board,
the SPL will need to support both sdram driver and storage(SPI, SDCard,
eMMC) driver and without back to BootRom,
and other function may add to SPL, but the sram size limit is always
there, so all the rk3288 and rk3399 board have migrate to use
"TPL+SPL+U-Boot.itb" mode.
It seems not all have migrated.
The "TPL+SPL+U-Boot.itb" is much clear and easy to maintine for all the
boards and will be the only accept mode for new board support in the
future on rockchip platform:
- TPL for dram init;
- SPL for storage init and load next stage firmware, decode FIT image
with ATF/OPTEE support, secure boot support and etc;
- U-Boot.itb including ATF and U-Boot proper, maybe also OPTEE.
This model can very easy to do the debug with replace the binary from
rockchip vendor tree during board bringup.
That's fine by me, but we currently have Rockchip boards in mainline
which do NOT have TPL enabled, so we need to handle those properly, in
binman since it's now the only way to generate the images.
The SPL+U-Boot mode can only happen for legacy
[PATCH] doc: sl-mx8mm: Fix mistake in merge conflict resolution
From: Frieder Schrempf
There was a conflict between the following two commits, that wasn't
resolved correctly. Fix this.
a93985ddfcc3 ("doc: sl-mx8mm: Update the NXP TF-A source reference")
f0f461287eff ("imx: Suggest the NXP ATF github repo")
Signed-off-by: Frieder Schrempf
Cc: Heinrich Schuchardt
Cc: Fabio Estevam
Cc: Stefano Babic
---
doc/board/kontron/sl-mx8mm.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/board/kontron/sl-mx8mm.rst b/doc/board/kontron/sl-mx8mm.rst
index 09c50aa8b1..702db60fe3 100644
--- a/doc/board/kontron/sl-mx8mm.rst
+++ b/doc/board/kontron/sl-mx8mm.rst
@@ -40,7 +40,7 @@ There are two sources for the TF-A. Mainline and NXP. Get the
one you prefer
**NXP's imx-atf**
-1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: imx_5.4.70_2.3.0
+1. Get TF-A from: https://github.com/nxp-imx/imx-atf, branch: lf_v2.6
2. Build
.. code-block:: bash
--
2.39.1
Re: [PATCH 1/1] cmd: CONFIG_CMD_EFICONFIG requires CONFIG_MENU
On Wed, 8 Feb 2023 at 06:02, Heinrich Schuchardt
wrote:
>
> The eficonfig command invokes functions implemented in common/menu.c like
>
> * menu_default_set()
> * menu_get_choice()
> * menu_destroy()
> * menu_item_add()
>
> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Simon Glass
Re: [PATCH] Revert "lmb: Default to not-LMB_USE_MAX_REGIONS"
On Wed, 8 Feb 2023 at 08:19, Tom Rini wrote: > > As explained by Philippe Schenker, I was misinterpreting what happened > in the case where we do not set LMB_USE_MAX_REGIONS and so had > re-introduced the problem I was attempting to more widely resolve. > > This reverts commit 007ae5d108a37564905ea1588cb279f3a522cc3d. > > Reported-by: Philippe Schenker > Signed-off-by: Tom Rini > --- > configs/a3y17lte_defconfig | 1 + > configs/a5y17lte_defconfig | 1 + > configs/a7y17lte_defconfig | 1 + > configs/dragonboard845c_defconfig| 1 + > configs/mt7981_emmc_rfb_defconfig| 1 + > configs/mt7981_rfb_defconfig | 1 + > configs/mt7981_sd_rfb_defconfig | 1 + > configs/mt7986_rfb_defconfig | 1 + > configs/mt7986a_bpir3_emmc_defconfig | 1 + > configs/mt7986a_bpir3_sd_defconfig | 1 + > configs/qcs404evb_defconfig | 1 + > configs/starqltechn_defconfig| 1 + > lib/Kconfig | 1 + > 13 files changed, 13 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH] doc: sl-mx8mm: Fix mistake in merge conflict resolution
On 08/02/2023 13:20, Frieder Schrempf wrote:
From: Frieder Schrempf
There was a conflict between the following two commits, that wasn't
resolved correctly. Fix this.
a93985ddfcc3 ("doc: sl-mx8mm: Update the NXP TF-A source reference")
f0f461287eff ("imx: Suggest the NXP ATF github repo")
Signed-off-by: Frieder Schrempf
Cc: Heinrich Schuchardt
Cc: Fabio Estevam
Cc: Stefano Babic
Reviewed-by: Fabio Estevam
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
Hello,
On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > It is reported that in some configurations it is not possible to boot
> > because u-boot runs out of lmbs.
> >
> > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> > hence is likely the cause of the lmb overflow.
> >
> > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > Signed-off-by: Michal Suchanek
Reviewed-by: Francesco Dolcini
> I plan to pick up
> https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> as the alternative fix for this issue and would suggest that any distro
> hitting the problem on v2023.01 apply the above instead of increasing
> the limit.
Tom, my understanding is that you plan to merge this or an equivalent
change, correct? Otherwise I would need to send some more patches to
update a few board defconfig that are affected by this specific issue.
Thanks,
Francesco
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> Hello,
>
> On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > It is reported that in some configurations it is not possible to boot
> > > because u-boot runs out of lmbs.
> > >
> > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> > > hence is likely the cause of the lmb overflow.
> > >
> > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > Signed-off-by: Michal Suchanek
>
> Reviewed-by: Francesco Dolcini
>
> > I plan to pick up
> > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > as the alternative fix for this issue and would suggest that any distro
> > hitting the problem on v2023.01 apply the above instead of increasing
> > the limit.
>
> Tom, my understanding is that you plan to merge this or an equivalent
> change, correct? Otherwise I would need to send some more patches to
> update a few board defconfig that are affected by this specific issue.
Yes, I was hoping to push the equivalent of this patch a few hours ago,
along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
scale past 8, and I just now figured out what that should look like
instead, I believe.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> It is reported that in some configurations it is not possible to boot
> because u-boot runs out of lmbs.
>
> commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> hence is likely the cause of the lmb overflow.
>
> Fixes: 06d514d77c ("lmb: consider EFI memory map")
> Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> Signed-off-by: Michal Suchanek
In the interest of completeness, I was wrong in what I was thinking was
the wider fix and have taken
https://patchwork.ozlabs.org/project/uboot/patch/20230119083820.2656710-2-sjo...@collabora.com/
as it was posted first, but added the fixes/link to that commit as well.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Filip,
On Wed, 18 Jan 2023 at 09:03, Filip Žaludek wrote:
>
>
>
> Hi Michal,
>
> thanks for testing! Do you consider keyboard as working once it is detected
> without
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from
> subsequent
> typing? Note that issue is reproducible only in about 20% of reboots.
> For me I can always enter 'U-Boot>' shell, but then keyboard usually does not
> work.
> And yes, resetting the usb controller with pressing a key afterwards will
> finally break the keyboard. ('usb reset' typed from keyboard)
> If you are Prague located I am ready to demonstrate what I am talking about.
>
> Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme
> Pro' detection,
> printed complaints but keyboard still works..
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get
> keyboard state from device 0c40:8000'
> Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is
> 046d:c31c (Logitech Keyboard K120)?
>
> What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users
> wanting to boot non-default?
> Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub
> entry..?
>
>
> Reverting either from the two makes it non issue for me:
> 'dwc2: use the nonblock argument in submit_int_msg'
> commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
>
> 'console: usb: kbd: Limit poll frequency to improve performance'
> commit 96991e652f541323a03c5b7e075d54a117091618
>
>
> What will be attitude on this, should we try to bring workaround preserving
> both patches?
(please try to avoid top-posting)
You can use a USB quirk to handle this.
Marek do you have any thoughts here?
Regards,
Simon
>
>
>
> Regards,
> Filip
>
>
>
>
>
>
> On 1/17/23 19:46, Michal Suchánek wrote:
> > Hello,
> >
> > On Sat, Dec 17, 2022 at 01:49:47PM +0100, Filip Žaludek wrote:
> >>
> >>
> >> Hello,
> >> change seems to be unfriendly to RPi3B+, it allows to enter 'U-Boot>'
> >> shell but usb keyboard
> >> does not respond. Keyboard is detected by 'usb info' in v2023.01-rc3, not
> >> in v2022.10.
> >> When reverted, usb keyboard works as expected.
> >>
> >> Anybody sitting front of RPi3B+ care to confirm?
> >
> > For me an USB keyboard connected to a Raspberry Pi 3B+ is only detected
> > when something is typed during the probe.
> >
> > The message
> >
> > usb_kbd usb_kbd: Timeout poll on interrupt endpoint
> >
> > is a sign of nothing typed on the keyboard and then it does not work.
> >
> > It is limitation of the dwc2 hardware with hardwired USB hub.
> >
> > Same on both v2022.10 & v2023.01 rpiarm64 and rpi_3 configs.
> >
> > Thanks
> >
> > Michal
> >
> >>
> >>
> >> Regards,
> >> Filip
> >>
> >>
> >>
> >>
> >>
> >> Patch:
> >> https://urldefense.com/v3/__https://github.com/u-boot/u-boot/commit/96991e652f541323a03c5b7e075d54a117091618__;!!ACWV5N9M2RV99hQ!J3bR4ePIrYCcbqK8Zd5qG9y4yP6W_sNqMV0BhlIJqrwImk8KRkbMK8K5tzXHZU3BZ3ai6k7v25WDUCtgOBMVk8o$
> >>
> >>
> >> Debug:
> >> USB KBD: found interrupt EP: 0x81
> >> USB KBD: set boot protocol
> >> dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00,
> >> udev->dev='usb_kbd', portnr=3
> >> USB KBD: set idle interval...
> >> dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00,
> >> udev->dev='usb_kbd', portnr=3
> >> USB KBD: enable interrupt pipe...
> >> usb_kbd usb_kbd: Timeout poll on interrupt endpoint
> >>
> >>
> >> Tested:
> >> SW: v2022.10 & v2023.01-rc3 compiled from sources as 'rpiarm64'
> >> HW: USB 1.1 and 2.0 keyboards, RPi3B+
> >> JeOS:
> >> https://urldefense.com/v3/__http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.10.11-Snapshot20221112.raw.xz__;!!ACWV5N9M2RV99hQ!J3bR4ePIrYCcbqK8Zd5qG9y4yP6W_sNqMV0BhlIJqrwImk8KRkbMK8K5tzXHZU3BZ3ai6k7v25WDUCtgKPUw0V8$
> >> (u-boot-rpiarm64-2022.10-1.1.aarch64)
> >>
> >>
Re: [PATCH v2 4/5] lib: sha256: Add support for hardware specific sha256_process
Hi Tom,
On Tue, 7 Feb 2023 at 17:10, Tom Rini wrote:
>
> On Tue, Feb 07, 2023 at 03:25:16PM -0700, Simon Glass wrote:
> > Hi Loic,
> >
> > On Tue, 7 Feb 2023 at 14:47, Loic Poulain wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, 7 Feb 2023 at 05:05, Simon Glass wrote:
> > > >
> > > > Hi Loic,
> > > >
> > > > On Mon, 6 Feb 2023 at 15:12, Loic Poulain
> > > > wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Le lun. 6 févr. 2023 à 18:12, Simon Glass a écrit
> > > > > :
> > > > >>
> > > > >> Hi Loic,
> > > > >>
> > > > >> On Wed, 1 Jun 2022 at 12:27, Loic Poulain
> > > > >> wrote:
> > > > >> >
> > > > >> > Mark sha256_process as weak to allow hardware specific
> > > > >> > implementation.
> > > > >> > Add parameter for supporting multiple blocks processing.
> > > > >> >
> > > > >> > Signed-off-by: Loic Poulain
> > > > >> > ---
> > > > >> > lib/sha256.c | 26 +++---
> > > > >> > 1 file changed, 19 insertions(+), 7 deletions(-)
> > > > >> >
> > > [...]
> > > > >> > +__weak void sha256_process(sha256_context *ctx, const unsigned
> > > > >> > char *data,
> > > > >> > + unsigned int blocks)
> > > > >> > +{
> > > > >> > + if (!blocks)
> > > > >> > + return;
> > > > >> > +
> > > > >> > + while (blocks--) {
> > > > >> > + sha256_process_one(ctx, data);
> > > > >> > + data += 64;
> > > > >> > + }
> > > > >> > +}
> > > > >> > +
> > > > >> > void sha256_update(sha256_context *ctx, const uint8_t *input,
> > > > >> > uint32_t length)
> > > > >> > {
> > > > >> > uint32_t left, fill;
> > > > >> > @@ -204,17 +218,15 @@ void sha256_update(sha256_context *ctx,
> > > > >> > const uint8_t *input, uint32_t length)
> > > > >> >
> > > > >> > if (left && length >= fill) {
> > > > >> > memcpy((void *) (ctx->buffer + left), (void *)
> > > > >> > input, fill);
> > > > >> > - sha256_process(ctx, ctx->buffer);
> > > > >> > + sha256_process(ctx, ctx->buffer, 1);
> > > > >> > length -= fill;
> > > > >> > input += fill;
> > > > >> > left = 0;
> > > > >> > }
> > > > >> >
> > > > >> > - while (length >= 64) {
> > > > >> > - sha256_process(ctx, input);
> > > > >> > - length -= 64;
> > > > >> > - input += 64;
> > > > >> > - }
> > > > >> > + sha256_process(ctx, input, length / 64);
> > > > >> > + input += length / 64 * 64;
> > > > >> > + length = length % 64;
> > > > >> >
> > > > >> > if (length)
> > > > >> > memcpy((void *) (ctx->buffer + left), (void *)
> > > > >> > input, length);
> > > > >> > --
> > > > >> > 2.7.4
> > > > >> >
> > > > >>
> > > > >> I just came across this patch as it broke minnowmax.
> > > > >
> > > > >
> > > > > Ok, is it a build time or runtime break?
> > > >
> > > > Build, but you need the binary blobs to see it :-(
> > > > >>
> > > > >> This should be using driver model, not weak functions. Please can you
> > > > >> take a look?
> > >
> > > Just tested the minnowmax build (b69026c91f2e; minnowmax_defconfig;
> > > gcc-11.3.0), and I've not observed any issue (but I had to fake some
> > > of the binary blobs...). Could you share the build problem/error you
> >
> > Unfortunately you need the blobs!
> >
> > > encountered? As you mentioned it, Is the error specifically related to
> > > _weak function linking? Would like to have a simple and quick fix
> > > before trying to move on to a more proper DM based solution.
> >
> > It is just because of the code size increase, I believe. I am planning
> > to dig into it a bit as Bin Meng asked for more info as to why I sent
> > a revert for his patch moving U-Boot.
>
> That honestly makes more sense, having stared at the commit in
> question. Perhaps Minnow needs LTO enabled.
Yes, that would likely help. But Bin's point is that it should be
possible to move the text base.
Anyway, the point of this thread is that this needs to be done as
drivers rather than weak functions. Unfortunately hash.c has grown a
few appendages...this is yet another.
Regards,
Simon
Re: [PATCH v3 01/76] moveconfig: Add an option to compare Kconfig against source
Hi Tom, On Tue, 7 Feb 2023 at 18:37, Tom Rini wrote: > > On Wed, Feb 01, 2023 at 01:19:12PM -0700, Simon Glass wrote: > > > Sometimes the Makefile rules or source code refers to Kconfig options > > which don't exist. Update the moveconfig tool to check this and produce > > a series of reports about inconsistencies. > > > > This can then be used to generate patches to correct the problems. > > > > Signed-off-by: Simon Glass > > For the series, except for 46/76 which was a rename not dropped in v3, > and the one or two that look to be missing in patchwork, applied to > u-boot/master, thanks! OK thanks. It looks like these four patches: sh4: Drop unused twl6030 driver samsung: Rename PINCTRL_EXYNOS78x0 (should be dropped) mtd: Drop unused CONFIG_ONENAND_U_BOOT mtd: Drop unused kb9202_nand driver I'm not sure what is wrong with patchwork, or even if it is patchwork, but things seem to be lost sometimes. Regards, Simon
Re: [PATCH v3 01/76] moveconfig: Add an option to compare Kconfig against source
On Wed, Feb 08, 2023 at 11:28:22AM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 7 Feb 2023 at 18:37, Tom Rini wrote: > > > > On Wed, Feb 01, 2023 at 01:19:12PM -0700, Simon Glass wrote: > > > > > Sometimes the Makefile rules or source code refers to Kconfig options > > > which don't exist. Update the moveconfig tool to check this and produce > > > a series of reports about inconsistencies. > > > > > > This can then be used to generate patches to correct the problems. > > > > > > Signed-off-by: Simon Glass > > > > For the series, except for 46/76 which was a rename not dropped in v3, > > and the one or two that look to be missing in patchwork, applied to > > u-boot/master, thanks! > > OK thanks. It looks like these four patches: > > sh4: Drop unused twl6030 driver > samsung: Rename PINCTRL_EXYNOS78x0 (should be dropped) > mtd: Drop unused CONFIG_ONENAND_U_BOOT > mtd: Drop unused kb9202_nand driver > > I'm not sure what is wrong with patchwork, or even if it is patchwork, > but things seem to be lost sometimes. I suspect Google dropped them on the floor as lore.kernel.org is also missing v3 for the 3 of those that weren't supposed to be dropped. I noticed you had some of the problems I've also had when posting very large/long series where sometimes it'll get rejected and you need to pick up and continue after a bit. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/5] lib: sha256: Add support for hardware specific sha256_process
On Wed, Feb 08, 2023 at 11:28:21AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 7 Feb 2023 at 17:10, Tom Rini wrote:
> >
> > On Tue, Feb 07, 2023 at 03:25:16PM -0700, Simon Glass wrote:
> > > Hi Loic,
> > >
> > > On Tue, 7 Feb 2023 at 14:47, Loic Poulain wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Tue, 7 Feb 2023 at 05:05, Simon Glass wrote:
> > > > >
> > > > > Hi Loic,
> > > > >
> > > > > On Mon, 6 Feb 2023 at 15:12, Loic Poulain
> > > > > wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Le lun. 6 févr. 2023 à 18:12, Simon Glass a
> > > > > > écrit :
> > > > > >>
> > > > > >> Hi Loic,
> > > > > >>
> > > > > >> On Wed, 1 Jun 2022 at 12:27, Loic Poulain
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > Mark sha256_process as weak to allow hardware specific
> > > > > >> > implementation.
> > > > > >> > Add parameter for supporting multiple blocks processing.
> > > > > >> >
> > > > > >> > Signed-off-by: Loic Poulain
> > > > > >> > ---
> > > > > >> > lib/sha256.c | 26 +++---
> > > > > >> > 1 file changed, 19 insertions(+), 7 deletions(-)
> > > > > >> >
> > > > [...]
> > > > > >> > +__weak void sha256_process(sha256_context *ctx, const unsigned
> > > > > >> > char *data,
> > > > > >> > + unsigned int blocks)
> > > > > >> > +{
> > > > > >> > + if (!blocks)
> > > > > >> > + return;
> > > > > >> > +
> > > > > >> > + while (blocks--) {
> > > > > >> > + sha256_process_one(ctx, data);
> > > > > >> > + data += 64;
> > > > > >> > + }
> > > > > >> > +}
> > > > > >> > +
> > > > > >> > void sha256_update(sha256_context *ctx, const uint8_t *input,
> > > > > >> > uint32_t length)
> > > > > >> > {
> > > > > >> > uint32_t left, fill;
> > > > > >> > @@ -204,17 +218,15 @@ void sha256_update(sha256_context *ctx,
> > > > > >> > const uint8_t *input, uint32_t length)
> > > > > >> >
> > > > > >> > if (left && length >= fill) {
> > > > > >> > memcpy((void *) (ctx->buffer + left), (void *)
> > > > > >> > input, fill);
> > > > > >> > - sha256_process(ctx, ctx->buffer);
> > > > > >> > + sha256_process(ctx, ctx->buffer, 1);
> > > > > >> > length -= fill;
> > > > > >> > input += fill;
> > > > > >> > left = 0;
> > > > > >> > }
> > > > > >> >
> > > > > >> > - while (length >= 64) {
> > > > > >> > - sha256_process(ctx, input);
> > > > > >> > - length -= 64;
> > > > > >> > - input += 64;
> > > > > >> > - }
> > > > > >> > + sha256_process(ctx, input, length / 64);
> > > > > >> > + input += length / 64 * 64;
> > > > > >> > + length = length % 64;
> > > > > >> >
> > > > > >> > if (length)
> > > > > >> > memcpy((void *) (ctx->buffer + left), (void *)
> > > > > >> > input, length);
> > > > > >> > --
> > > > > >> > 2.7.4
> > > > > >> >
> > > > > >>
> > > > > >> I just came across this patch as it broke minnowmax.
> > > > > >
> > > > > >
> > > > > > Ok, is it a build time or runtime break?
> > > > >
> > > > > Build, but you need the binary blobs to see it :-(
> > > > > >>
> > > > > >> This should be using driver model, not weak functions. Please can
> > > > > >> you
> > > > > >> take a look?
> > > >
> > > > Just tested the minnowmax build (b69026c91f2e; minnowmax_defconfig;
> > > > gcc-11.3.0), and I've not observed any issue (but I had to fake some
> > > > of the binary blobs...). Could you share the build problem/error you
> > >
> > > Unfortunately you need the blobs!
> > >
> > > > encountered? As you mentioned it, Is the error specifically related to
> > > > _weak function linking? Would like to have a simple and quick fix
> > > > before trying to move on to a more proper DM based solution.
> > >
> > > It is just because of the code size increase, I believe. I am planning
> > > to dig into it a bit as Bin Meng asked for more info as to why I sent
> > > a revert for his patch moving U-Boot.
> >
> > That honestly makes more sense, having stared at the commit in
> > question. Perhaps Minnow needs LTO enabled.
>
> Yes, that would likely help. But Bin's point is that it should be
> possible to move the text base.
I suspect that might just be more fall-out of the size problem and
possibly some hard coded assumptions in the blobs?
> Anyway, the point of this thread is that this needs to be done as
> drivers rather than weak functions. Unfortunately hash.c has grown a
> few appendages...this is yet another.
I don't know, it seems fine, especially since we aren't really talking
about a "hash driver" but rather introducing some performance sensitive
code.
--
Tom
signature.asc
Description: PGP signature
[PATCH] test: lmb: Rework lib_test_lmb_max_regions test to scale
First, this test depends on CONFIG_LMB_USE_MAX_REGIONS, so add that as a
test before building. Second, instead of using a hard-coded value of 8,
which is the default of CONFIG_LMB_USE_MAX_REGIONS previously, use that
directly and update the comments. The only trick here is that one part
of the test itself also was written with the value of 8 itself in mind.
Rework the size of the lmb region we allocate to scale with the value of
CONFIG_LMB_USE_MAX_REGIONS.
Cc: Simon Glass
Signed-off-by: Tom Rini
---
test/lib/lmb.c | 44 ++--
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 157c26394d6f..b24c85d203ae 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -665,10 +665,17 @@ static int lib_test_lmb_get_free_size(struct
unit_test_state *uts)
DM_TEST(lib_test_lmb_get_free_size,
UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+#ifdef CONFIG_LMB_USE_MAX_REGIONS
static int lib_test_lmb_max_regions(struct unit_test_state *uts)
{
const phys_addr_t ram = 0x;
- const phys_size_t ram_size = 0x800;
+ /*
+* All of 32bit memory space will be contain regionns for this test, so
+* we need to scale ram_size (which in this case is the size of the lmb
+* region) to match.
+*/
+ const phys_size_t ram_size = ((0x >> CONFIG_LMB_MAX_REGIONS)
+ + 1) * CONFIG_LMB_MAX_REGIONS;
const phys_size_t blk_size = 0x1;
phys_addr_t offset;
struct lmb lmb;
@@ -677,54 +684,55 @@ static int lib_test_lmb_max_regions(struct
unit_test_state *uts)
lmb_init(&lmb);
ut_asserteq(lmb.memory.cnt, 0);
- ut_asserteq(lmb.memory.max, 8);
+ ut_asserteq(lmb.memory.max, CONFIG_LMB_MAX_REGIONS);
ut_asserteq(lmb.reserved.cnt, 0);
- ut_asserteq(lmb.reserved.max, 8);
+ ut_asserteq(lmb.reserved.max, CONFIG_LMB_MAX_REGIONS);
- /* Add 8 memory regions */
- for (i = 0; i < 8; i++) {
+ /* Add CONFIG_LMB_MAX_REGIONS memory regions */
+ for (i = 0; i < CONFIG_LMB_MAX_REGIONS; i++) {
offset = ram + 2 * i * ram_size;
ret = lmb_add(&lmb, offset, ram_size);
ut_asserteq(ret, 0);
}
- ut_asserteq(lmb.memory.cnt, 8);
+ ut_asserteq(lmb.memory.cnt, CONFIG_LMB_MAX_REGIONS);
ut_asserteq(lmb.reserved.cnt, 0);
- /* error for the 9th memory regions */
- offset = ram + 2 * 8 * ram_size;
+ /* error for the (CONFIG_LMB_MAX_REGIONS + 1) memory regions */
+ offset = ram + 2 * (CONFIG_LMB_MAX_REGIONS + 1) * ram_size;
ret = lmb_add(&lmb, offset, ram_size);
ut_asserteq(ret, -1);
- ut_asserteq(lmb.memory.cnt, 8);
+ ut_asserteq(lmb.memory.cnt, CONFIG_LMB_MAX_REGIONS);
ut_asserteq(lmb.reserved.cnt, 0);
- /* reserve 8 regions */
- for (i = 0; i < 8; i++) {
+ /* reserve CONFIG_LMB_MAX_REGIONS regions */
+ for (i = 0; i < CONFIG_LMB_MAX_REGIONS; i++) {
offset = ram + 2 * i * blk_size;
ret = lmb_reserve(&lmb, offset, blk_size);
ut_asserteq(ret, 0);
}
- ut_asserteq(lmb.memory.cnt, 8);
- ut_asserteq(lmb.reserved.cnt, 8);
+ ut_asserteq(lmb.memory.cnt, CONFIG_LMB_MAX_REGIONS);
+ ut_asserteq(lmb.reserved.cnt, CONFIG_LMB_MAX_REGIONS);
/* error for the 9th reserved blocks */
- offset = ram + 2 * 8 * blk_size;
+ offset = ram + 2 * (CONFIG_LMB_MAX_REGIONS + 1) * blk_size;
ret = lmb_reserve(&lmb, offset, blk_size);
ut_asserteq(ret, -1);
- ut_asserteq(lmb.memory.cnt, 8);
- ut_asserteq(lmb.reserved.cnt, 8);
+ ut_asserteq(lmb.memory.cnt, CONFIG_LMB_MAX_REGIONS);
+ ut_asserteq(lmb.reserved.cnt, CONFIG_LMB_MAX_REGIONS);
/* check each regions */
- for (i = 0; i < 8; i++)
+ for (i = 0; i < CONFIG_LMB_MAX_REGIONS; i++)
ut_asserteq(lmb.memory.region[i].base, ram + 2 * i * ram_size);
- for (i = 0; i < 8; i++)
+ for (i = 0; i < CONFIG_LMB_MAX_REGIONS; i++)
ut_asserteq(lmb.reserved.region[i].base, ram + 2 * i *
blk_size);
return 0;
}
+#endif
DM_TEST(lib_test_lmb_max_regions,
UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.34.1
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hello,
On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:
>
>
> Hi Michal,
>
> thanks for testing! Do you consider keyboard as working once it is detected
> without
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from
> subsequent
> typing? Note that issue is reproducible only in about 20% of reboots.
I rely on keyboard input to boot so if it was 20% broken I would notice.
I don't use the rPi all that much so if it was broken only a few
% of the time there is a chance I would miss it.
However, for me not typing on the keyboard during usb detection it is
100% not detected, typing on it during usb detection it is 100%
detected.
The timeout is limitation of the dwc2 controller handling of usb hubs.
There might be a possibility to improve the driver so that it handles
the condition but it might be that the Linux driver relies on a separate
thread handling the controller which is not acceptable for u-boot.
I am not usb expert and definitely not dwc2 expert so I cannot do more
than workaround the current driver limitation.
> For me I can always enter 'U-Boot>' shell, but then keyboard usually does not
> work.
> And yes, resetting the usb controller with pressing a key afterwards will
> finally break the keyboard. ('usb reset' typed from keyboard)
> If you are Prague located I am ready to demonstrate what I am talking about.
>
> Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme
> Pro' detection,
> printed complaints but keyboard still works..
> 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get
> keyboard state from device 0c40:8000'
> Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is
> 046d:c31c (Logitech Keyboard K120)?
>
> What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users
> wanting to boot non-default?
> Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub
> entry..?
>
> Reverting either from the two makes it non issue for me:
> 'dwc2: use the nonblock argument in submit_int_msg'
> commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
Without this booting from USB is not feasible because reading every
block from the USB drive waits for the keyboard to time out.
> 'console: usb: kbd: Limit poll frequency to improve performance'
> commit 96991e652f541323a03c5b7e075d54a117091618
No idea about this one, for me it doea not give any substantial
difference in behavior.
Thanks
Michal
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
> Date: Wed, 8 Feb 2023 19:45:36 +0100
> From: Michal Suchánek
>
> Hello,
>
> On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:
> >
> >
> > Hi Michal,
> >
> > thanks for testing! Do you consider keyboard as working once it is
> > detected without
> > 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from
> > subsequent
> > typing? Note that issue is reproducible only in about 20% of reboots.
>
> I rely on keyboard input to boot so if it was 20% broken I would notice.
> I don't use the rPi all that much so if it was broken only a few
> % of the time there is a chance I would miss it.
>
> However, for me not typing on the keyboard during usb detection it is
> 100% not detected, typing on it during usb detection it is 100%
> detected.
>
> The timeout is limitation of the dwc2 controller handling of usb hubs.
>
> There might be a possibility to improve the driver so that it handles
> the condition but it might be that the Linux driver relies on a separate
> thread handling the controller which is not acceptable for u-boot.
>
> I am not usb expert and definitely not dwc2 expert so I cannot do more
> than workaround the current driver limitation.
>
> > For me I can always enter 'U-Boot>' shell, but then keyboard usually does
> > not work.
> > And yes, resetting the usb controller with pressing a key afterwards will
> > finally break the keyboard. ('usb reset' typed from keyboard)
> > If you are Prague located I am ready to demonstrate what I am talking about.
> >
> > Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme
> > Pro' detection,
> > printed complaints but keyboard still works..
> > 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get
> > keyboard state from device 0c40:8000'
> > Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is
> > 046d:c31c (Logitech Keyboard K120)?
> >
> > What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users
> > wanting to boot non-default?
> > Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub
> > entry..?
> >
> > Reverting either from the two makes it non issue for me:
> > 'dwc2: use the nonblock argument in submit_int_msg'
> > commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
>
> Without this booting from USB is not feasible because reading every
> block from the USB drive waits for the keyboard to time out.
>
> > 'console: usb: kbd: Limit poll frequency to improve performance'
> > commit 96991e652f541323a03c5b7e075d54a117091618
>
> No idea about this one, for me it doea not give any substantial
> difference in behavior.
Reverting that commit leads to a significant slowdown loading a kernel
from disk with a usb keyboard connected. The slowdown is somewhat
hardware dependent but on some systems loading the OpenBSD/arm64
kernel would take minutes instead of seconds.
[PATCH 0/2] odroid: fix boot issues on u2, xu4 and siblings
Hi,
Patch 1 fixes issue reported in [1], which happens on odroid-u2 and
probably other devices in that family. Re-adding this quirk was
discussed already by Jaehoon and Andy in the patch that
(re-)introduced this issue [2], but I do not think a patch was sent
for it.
Patch 2 fixes issue reported in [3], which happens on odroid-{u2,xu4}
and other devices in that family. An alternative fix was sent
previously by Joost [4], but has not been picked up yet.
Tested on odroid-u2 and odroid-xu4 on top of master branch, I am able
to boot from sdcard on both without issues.
[1] https://lists.denx.de/pipermail/u-boot/2023-January/504116.html
[2] https://lists.denx.de/pipermail/u-boot/2021-March/445243.html
[3] https://lists.denx.de/pipermail/u-boot/2023-January/504115.html
[4] https://lists.denx.de/pipermail/u-boot/2023-January/505551.html
Henrik Grimler (2):
Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
samsung: common: only load CROS_EC if enabled in config
board/samsung/common/board.c | 27 ++-
drivers/mmc/s5p_sdhci.c | 2 +-
2 files changed, 15 insertions(+), 14 deletions(-)
--
2.30.2
[PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
there are data"") reverted the alternative fix that was added for
Exynos 4 devices, causing an error when trying to boot from an sdcard:
<...>
Loading Environment from MMC... sdhci_send_command: Timeout for status
update!
mmc fail to send stop cmd
<...>
Re-add the quirk to allow booting from sdcards again.
Signed-off-by: Henrik Grimler
---
drivers/mmc/s5p_sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index dee84263c3fd..3b74feae68c7 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host *host)
host->name = S5P_NAME;
host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
- SDHCI_QUIRK_32BIT_DMA_ADDR |
+ SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
host->max_clk = 5200;
host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
--
2.30.2
[PATCH 2/2] samsung: common: only load CROS_EC if enabled in config
Otherwise non-ChromeOS samsung devices, like the odroid boards, are
stuck in a bootloop if CONFIG_CROS_EC is not enabled:
<...>
MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment
cros-ec communications failure -96
Please reset with Power+Refresh
Cannot init cros-ec device
resetting ...
Issue started after commit e44d7e73fe0d ("dm: core: Switch
uclass_*_device_err to use uclass_*_device_check").
Signed-off-by: Henrik Grimler
---
board/samsung/common/board.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 16ce5cb89253..78161b807bac 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -217,26 +217,27 @@ int checkboard(void)
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
- struct udevice *dev;
- int ret;
int mmcbootdev = get_boot_mmc_dev();
char mmcbootdev_str[16];
- ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
- if (ret && ret != -ENODEV) {
- /* Force console on */
- gd->flags &= ~GD_FLG_SILENT;
-
- printf("cros-ec communications failure %d\n", ret);
- puts("\nPlease reset with Power+Refresh\n\n");
- panic("Cannot init cros-ec device");
- return -1;
- }
-
printf("Boot device: MMC(%u)\n", mmcbootdev);
sprintf(mmcbootdev_str, "%u", mmcbootdev);
env_set("mmcbootdev", mmcbootdev_str);
+ if (IS_ENABLED(CONFIG_CROS_EC)) {
+ struct udevice *dev;
+ int ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
+ if (ret && ret != -ENODEV) {
+ /* Force console on */
+ gd->flags &= ~GD_FLG_SILENT;
+
+ printf("cros-ec communications failure %d\n", ret);
+ puts("\nPlease reset with Power+Refresh\n\n");
+ panic("Cannot init cros-ec device");
+ return -1;
+ }
+ }
+
return 0;
}
#endif
--
2.30.2
Re: [PATCH v3 01/76] moveconfig: Add an option to compare Kconfig against source
Hi Tom, On Wed, 8 Feb 2023 at 11:35, Tom Rini wrote: > > On Wed, Feb 08, 2023 at 11:28:22AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 7 Feb 2023 at 18:37, Tom Rini wrote: > > > > > > On Wed, Feb 01, 2023 at 01:19:12PM -0700, Simon Glass wrote: > > > > > > > Sometimes the Makefile rules or source code refers to Kconfig options > > > > which don't exist. Update the moveconfig tool to check this and produce > > > > a series of reports about inconsistencies. > > > > > > > > This can then be used to generate patches to correct the problems. > > > > > > > > Signed-off-by: Simon Glass > > > > > > For the series, except for 46/76 which was a rename not dropped in v3, > > > and the one or two that look to be missing in patchwork, applied to > > > u-boot/master, thanks! > > > > OK thanks. It looks like these four patches: > > > > sh4: Drop unused twl6030 driver > > samsung: Rename PINCTRL_EXYNOS78x0 (should be dropped) > > mtd: Drop unused CONFIG_ONENAND_U_BOOT > > mtd: Drop unused kb9202_nand driver > > > > I'm not sure what is wrong with patchwork, or even if it is patchwork, > > but things seem to be lost sometimes. > > I suspect Google dropped them on the floor as lore.kernel.org is also > missing v3 for the 3 of those that weren't supposed to be dropped. I > noticed you had some of the problems I've also had when posting very > large/long series where sometimes it'll get rejected and you need to > pick up and continue after a bit. Sadly, I think you are right. Regards, Simon
Re: [PATCH] test: lmb: Rework lib_test_lmb_max_regions test to scale
On Wed, 8 Feb 2023 at 11:39, Tom Rini wrote:
>
> First, this test depends on CONFIG_LMB_USE_MAX_REGIONS, so add that as a
> test before building. Second, instead of using a hard-coded value of 8,
> which is the default of CONFIG_LMB_USE_MAX_REGIONS previously, use that
> directly and update the comments. The only trick here is that one part
> of the test itself also was written with the value of 8 itself in mind.
> Rework the size of the lmb region we allocate to scale with the value of
> CONFIG_LMB_USE_MAX_REGIONS.
>
> Cc: Simon Glass
> Signed-off-by: Tom Rini
> ---
> test/lib/lmb.c | 44 ++--
> 1 file changed, 26 insertions(+), 18 deletions(-)
Reviewed-by: Simon Glass
nit below
>
> diff --git a/test/lib/lmb.c b/test/lib/lmb.c
> index 157c26394d6f..b24c85d203ae 100644
> --- a/test/lib/lmb.c
> +++ b/test/lib/lmb.c
> @@ -665,10 +665,17 @@ static int lib_test_lmb_get_free_size(struct
unit_test_state *uts)
> DM_TEST(lib_test_lmb_get_free_size,
> UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
>
> +#ifdef CONFIG_LMB_USE_MAX_REGIONS
> static int lib_test_lmb_max_regions(struct unit_test_state *uts)
> {
> const phys_addr_t ram = 0x;
> - const phys_size_t ram_size = 0x800;
> + /*
> +* All of 32bit memory space will be contain regionns for this
test, so
regions
Should the word 'be' be there?
[..]
Regards,
Simon
Re: [PATCH] test: lmb: Rework lib_test_lmb_max_regions test to scale
On Wed, Feb 08, 2023 at 12:07:00PM -0700, Simon Glass wrote:
> On Wed, 8 Feb 2023 at 11:39, Tom Rini wrote:
> >
> > First, this test depends on CONFIG_LMB_USE_MAX_REGIONS, so add that as a
> > test before building. Second, instead of using a hard-coded value of 8,
> > which is the default of CONFIG_LMB_USE_MAX_REGIONS previously, use that
> > directly and update the comments. The only trick here is that one part
> > of the test itself also was written with the value of 8 itself in mind.
> > Rework the size of the lmb region we allocate to scale with the value of
> > CONFIG_LMB_USE_MAX_REGIONS.
> >
> > Cc: Simon Glass
> > Signed-off-by: Tom Rini
> > ---
> > test/lib/lmb.c | 44 ++--
> > 1 file changed, 26 insertions(+), 18 deletions(-)
>
> Reviewed-by: Simon Glass
>
> nit below
>
> >
> > diff --git a/test/lib/lmb.c b/test/lib/lmb.c
> > index 157c26394d6f..b24c85d203ae 100644
> > --- a/test/lib/lmb.c
> > +++ b/test/lib/lmb.c
> > @@ -665,10 +665,17 @@ static int lib_test_lmb_get_free_size(struct
> unit_test_state *uts)
> > DM_TEST(lib_test_lmb_get_free_size,
> > UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
> >
> > +#ifdef CONFIG_LMB_USE_MAX_REGIONS
> > static int lib_test_lmb_max_regions(struct unit_test_state *uts)
> > {
> > const phys_addr_t ram = 0x;
> > - const phys_size_t ram_size = 0x800;
> > + /*
> > +* All of 32bit memory space will be contain regionns for this
> test, so
>
> regions
>
> Should the word 'be' be there?
My re-re-word was wrong, I'll adjust it, read it aloud and repeat until
it's right before pushing, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
Hello,
On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > Hello,
> >
> > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > It is reported that in some configurations it is not possible to boot
> > > > because u-boot runs out of lmbs.
> > > >
> > > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb usage,
> > > > hence is likely the cause of the lmb overflow.
> > > >
> > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > Signed-off-by: Michal Suchanek
> >
> > Reviewed-by: Francesco Dolcini
> >
> > > I plan to pick up
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > > as the alternative fix for this issue and would suggest that any distro
> > > hitting the problem on v2023.01 apply the above instead of increasing
> > > the limit.
> >
> > Tom, my understanding is that you plan to merge this or an equivalent
> > change, correct? Otherwise I would need to send some more patches to
> > update a few board defconfig that are affected by this specific issue.
>
> Yes, I was hoping to push the equivalent of this patch a few hours ago,
> along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
> scale past 8, and I just now figured out what that should look like
> instead, I believe.
reportedly neither fixes the problem in all cases, and raising
CONFIG_LMB_RESERVED_REGIONS is required.
Looks like the mechanism to add regions above the default number does
not work as intended.
The test is to boot rPi 4 from USB directly with recent firmware.
Thanks
Michal
Re: [PATCH 0/2] odroid: fix boot issues on u2, xu4 and siblings
I missed CC:ing MMC maintainer Peng Fan (CC:ed here), apologies for
this.
Best regards,
Henrik Grimler
On Wed, Feb 08, 2023 at 08:04:19PM +0100, Henrik Grimler wrote:
> Hi,
>
> Patch 1 fixes issue reported in [1], which happens on odroid-u2 and
> probably other devices in that family. Re-adding this quirk was
> discussed already by Jaehoon and Andy in the patch that
> (re-)introduced this issue [2], but I do not think a patch was sent
> for it.
>
> Patch 2 fixes issue reported in [3], which happens on odroid-{u2,xu4}
> and other devices in that family. An alternative fix was sent
> previously by Joost [4], but has not been picked up yet.
>
> Tested on odroid-u2 and odroid-xu4 on top of master branch, I am able
> to boot from sdcard on both without issues.
>
> [1] https://lists.denx.de/pipermail/u-boot/2023-January/504116.html
> [2] https://lists.denx.de/pipermail/u-boot/2021-March/445243.html
> [3] https://lists.denx.de/pipermail/u-boot/2023-January/504115.html
> [4] https://lists.denx.de/pipermail/u-boot/2023-January/505551.html
>
>
> Henrik Grimler (2):
> Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
> samsung: common: only load CROS_EC if enabled in config
>
> board/samsung/common/board.c | 27 ++-
> drivers/mmc/s5p_sdhci.c | 2 +-
> 2 files changed, 15 insertions(+), 14 deletions(-)
>
> --
> 2.30.2
>
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
On Wed, Feb 08, 2023 at 08:11:34PM +0100, Michal Suchánek wrote:
> Hello,
>
> On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> > On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > > Hello,
> > >
> > > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > > It is reported that in some configurations it is not possible to boot
> > > > > because u-boot runs out of lmbs.
> > > > >
> > > > > commit 06d514d77c ("lmb: consider EFI memory map") increases lmb
> > > > > usage,
> > > > > hence is likely the cause of the lmb overflow.
> > > > >
> > > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > > Signed-off-by: Michal Suchanek
> > >
> > > Reviewed-by: Francesco Dolcini
> > >
> > > > I plan to pick up
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > > > as the alternative fix for this issue and would suggest that any distro
> > > > hitting the problem on v2023.01 apply the above instead of increasing
> > > > the limit.
> > >
> > > Tom, my understanding is that you plan to merge this or an equivalent
> > > change, correct? Otherwise I would need to send some more patches to
> > > update a few board defconfig that are affected by this specific issue.
> >
> > Yes, I was hoping to push the equivalent of this patch a few hours ago,
> > along with the revert. Then I noticed the test in test/lib/lmb.c doesn't
> > scale past 8, and I just now figured out what that should look like
> > instead, I believe.
>
> reportedly neither fixes the problem in all cases, and raising
> CONFIG_LMB_RESERVED_REGIONS is required.
>
> Looks like the mechanism to add regions above the default number does
> not work as intended.
>
> The test is to boot rPi 4 from USB directly with recent firmware.
Well, given 0089affee275 ("configs: stm32mp15: increase the number of
reserved memory region in lmb") I guess this has been run in to before,
but not resolved more generically.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/3] Bump LMB_MAX_REGIONS default to 16
On Thu, Jan 19, 2023 at 09:38:17AM +0100, Sjoerd Simons wrote:
> Since commit 06d514d77c37 ("lmb: consider EFI memory map") the EFI regions
> are also pushed into the lmb if EFI_LOADER is enabled (which is by
> default on most system). Which can cause the number of entries to go
> over the maximum as it's default is only 8.
>
> Specifically i ran into this case on an TI am62 which has an fdt with
> 4 reserved regions (in practice 3 lmb entries due to adjecent ranges).
>
> As this is likely to impact more devices bump the default max
> regions to 16 so there is a bit more slack.
>
> Signed-off-by: Sjoerd Simons
As Philippe Schenker explained, I was mis-interpreting what my attempted
solution would do, so I've reverted that and this patch here makes the
most sense to use as a general fix. As such I've now applied this to
u-boot/master.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] test: lmb: Rework lib_test_lmb_max_regions test to scale
On Wed, Feb 08, 2023 at 01:39:18PM -0500, Tom Rini wrote: > First, this test depends on CONFIG_LMB_USE_MAX_REGIONS, so add that as a > test before building. Second, instead of using a hard-coded value of 8, > which is the default of CONFIG_LMB_USE_MAX_REGIONS previously, use that > directly and update the comments. The only trick here is that one part > of the test itself also was written with the value of 8 itself in mind. > Rework the size of the lmb region we allocate to scale with the value of > CONFIG_LMB_USE_MAX_REGIONS. > > Cc: Simon Glass > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert "lmb: Default to not-LMB_USE_MAX_REGIONS"
On Wed, Feb 08, 2023 at 10:19:19AM -0500, Tom Rini wrote: > As explained by Philippe Schenker, I was misinterpreting what happened > in the case where we do not set LMB_USE_MAX_REGIONS and so had > re-introduced the problem I was attempting to more widely resolve. > > This reverts commit 007ae5d108a37564905ea1588cb279f3a522cc3d. > > Reported-by: Philippe Schenker > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2 0/2] arm: cpu: Add optional CMOs by VA
Exposing set/way cache maintenance to a virtual machine is unsafe, not least because the instructions are not permission-checked but also because they are not broadcast between CPUs. Consequently, KVM traps and emulates such maintenance in the host kernel using by-VA operations and looping over the stage-2 page-tables. However, when running under protected KVM, these instructions are not able to be emulated and will instead result in an exception being delivered to the guest. Introduce CONFIG_CMO_BY_VA_ONLY so that virtual platforms can select this option and perform by-VA cache maintenance instead of using the set/way instructions. Marc Zyngier (1): arm: cpu: Add optional CMOs by VA Pierre-Clément Tosi (1): arm64: Initialize TLB memory if CMO_BY_VA_ONLY v2: Fix the Signed-off-by list. arch/arm/cpu/armv8/Kconfig| 4 ++ arch/arm/cpu/armv8/cache.S| 50 +- arch/arm/cpu/armv8/cache_v8.c | 97 ++- arch/arm/cpu/armv8/cpu.c | 30 +++ arch/arm/lib/cache.c | 9 5 files changed, 164 insertions(+), 26 deletions(-) -- 2.39.1
[PATCH v2 1/2] arm: cpu: Add optional CMOs by VA
From: Marc Zyngier
Exposing set/way cache maintenance to a virtual machine is unsafe, not
least because the instructions are not permission-checked but also
because they are not broadcast between CPUs. Consequently, KVM traps and
emulates such maintenance in the host kernel using by-VA operations and
looping over the stage-2 page-tables. However, when running under
protected KVM, these instructions are not able to be emulated and will
instead result in an exception being delivered to the guest.
Introduce CONFIG_CMO_BY_VA_ONLY so that virtual platforms can select
this option and perform by-VA cache maintenance instead of using the
set/way instructions.
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Pierre-Clément Tosi
[ Paul: pick from the Android tree. Fixup Pierre's commit. And fix some
checkpatch warnings. Rebased to upstream. ]
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Tom Rini
Link:
https://android.googlesource.com/platform/external/u-boot/+/db5507f47f4f57f766d52f753ff2cc761afc213b
Link:
https://android.googlesource.com/platform/external/u-boot/+/2baf54e743380a1e4a6bc2dbdde020a2e783ff67
---
v2: Fix the Signed-off-by list.
---
arch/arm/cpu/armv8/Kconfig| 4 ++
arch/arm/cpu/armv8/cache.S| 50 +-
arch/arm/cpu/armv8/cache_v8.c | 97 ++-
arch/arm/cpu/armv8/cpu.c | 30 +++
4 files changed, 155 insertions(+), 26 deletions(-)
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 1305238c9d..7d5cf1594d 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -1,5 +1,9 @@
if ARM64
+config CMO_BY_VA_ONLY
+ bool "Force cache maintenance to be exclusively by VA"
+ depends on !SYS_DISABLE_DCACHE_OPS
+
config ARMV8_SPL_EXCEPTION_VECTORS
bool "Install crash dump exception vectors"
depends on SPL
diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S
index d1cee23437..3fe935cf28 100644
--- a/arch/arm/cpu/armv8/cache.S
+++ b/arch/arm/cpu/armv8/cache.S
@@ -12,6 +12,7 @@
#include
#include
+#ifndef CONFIG_CMO_BY_VA_ONLY
/*
* void __asm_dcache_level(level)
*
@@ -116,6 +117,41 @@ ENTRY(__asm_invalidate_dcache_all)
ENDPROC(__asm_invalidate_dcache_all)
.popsection
+.pushsection .text.__asm_flush_l3_dcache, "ax"
+WEAK(__asm_flush_l3_dcache)
+ mov x0, #0 /* return status as success */
+ ret
+ENDPROC(__asm_flush_l3_dcache)
+.popsection
+
+.pushsection .text.__asm_invalidate_l3_icache, "ax"
+WEAK(__asm_invalidate_l3_icache)
+ mov x0, #0 /* return status as success */
+ ret
+ENDPROC(__asm_invalidate_l3_icache)
+.popsection
+
+#else /* CONFIG_CMO_BY_VA */
+
+/*
+ * Define these so that they actively clash with in implementation
+ * accidentally selecting CONFIG_CMO_BY_VA
+ */
+
+.pushsection .text.__asm_invalidate_l3_icache, "ax"
+ENTRY(__asm_invalidate_l3_icache)
+ mov x0, xzr
+ ret
+ENDPROC(__asm_invalidate_l3_icache)
+.popsection
+.pushsection .text.__asm_flush_l3_dcache, "ax"
+ENTRY(__asm_flush_l3_dcache)
+ mov x0, xzr
+ ret
+ENDPROC(__asm_flush_l3_dcache)
+.popsection
+#endif /* CONFIG_CMO_BY_VA */
+
/*
* void __asm_flush_dcache_range(start, end)
*
@@ -189,20 +225,6 @@ WEAK(__asm_invalidate_l3_dcache)
ENDPROC(__asm_invalidate_l3_dcache)
.popsection
-.pushsection .text.__asm_flush_l3_dcache, "ax"
-WEAK(__asm_flush_l3_dcache)
- mov x0, #0 /* return status as success */
- ret
-ENDPROC(__asm_flush_l3_dcache)
-.popsection
-
-.pushsection .text.__asm_invalidate_l3_icache, "ax"
-WEAK(__asm_invalidate_l3_icache)
- mov x0, #0 /* return status as success */
- ret
-ENDPROC(__asm_invalidate_l3_icache)
-.popsection
-
/*
* void __asm_switch_ttbr(ulong new_ttbr)
*
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 2a226fd063..f333ad8889 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -163,6 +163,83 @@ static u64 *find_pte(u64 addr, int level)
return NULL;
}
+#ifdef CONFIG_CMO_BY_VA_ONLY
+static void __cmo_on_leaves(void (*cmo_fn)(unsigned long, unsigned long),
+ u64 pte, int level, u64 base)
+{
+ u64 *ptep;
+ int i;
+
+ ptep = (u64 *)(pte & GENMASK_ULL(47, PAGE_SHIFT));
+ for (i = 0; i < PAGE_SIZE / sizeof(u64); i++) {
+ u64 end, va = base + i * BIT(level2shift(level));
+ u64 type, attrs;
+
+ pte = ptep[i];
+ type = pte & PTE_TYPE_MASK;
+ attrs = pte & PMD_ATTRINDX_MASK;
+ debug("PTE %llx at level %d VA %llx\n", pte, level, va);
+
+ /* Not valid? next! */
+ if (!(type & PTE_TYPE_VALID))
+ continue;
+
+ /* Not a leaf? Recurse on the next level */
+ if (!(type == PTE_TYPE_BLOCK ||
[PATCH v2 2/2] arm64: Initialize TLB memory if CMO_BY_VA_ONLY
From: Pierre-Clément Tosi
Memory used to hold the page tables is allocated from the top of RAM
with no prior initialization and could therefore hold invalid data. As
invalidate_dcache_all() will be called before the MMU has been
initialized and as that function relies indirectly on the page tables
when using CMO_BY_VA_ONLY, these must be in a valid state from their
allocation.
Signed-off-by: Pierre-Clément Tosi
[ Paul: pick from the Android tree. Fix checkpatch warnings, and rebased
to the upstream. ]
Signed-off-by: Ying-Chun Liu (PaulLiu)
Cc: Tom Rini
Link:
https://android.googlesource.com/platform/external/u-boot/+/e3ceef4230b772186c6853cace4a676a407e6ab7
---
v2: Fix the Signed-off-by list.
---
arch/arm/lib/cache.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index 1a589c7e2a..7a16015867 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -159,6 +159,15 @@ __weak int arm_reserve_mmu(void)
*/
gd->arch.tlb_allocated = gd->arch.tlb_addr;
#endif
+
+ if (IS_ENABLED(CONFIG_CMO_BY_VA_ONLY)) {
+ /*
+* As invalidate_dcache_all() will be called before
+* mmu_setup(), we should make sure that the PTs are
+* already in a valid state.
+*/
+ memset((void *)gd->arch.tlb_addr, 0, gd->arch.tlb_size);
+ }
#endif
return 0;
--
2.39.1
Re: [PATCH 0/2] odroid: fix boot issues on u2, xu4 and siblings
On Wed, Feb 8, 2023 at 20:04, Henrik Grimler wrote:
Hi,
Hi Henrik,
Thanks for picking this up.
Patch 1 fixes issue reported in [1], which happens on odroid-u2 and
probably other devices in that family. Re-adding this quirk was
discussed already by Jaehoon and Andy in the patch that
(re-)introduced this issue [2], but I do not think a patch was sent
for it.
Patch 2 fixes issue reported in [3], which happens on odroid-{u2,xu4}
and other devices in that family. An alternative fix was sent
previously by Joost [4], but has not been picked up yet.
Patch 2 is anyhow a better fix than [4].
Tested on odroid-u2 and odroid-xu4 on top of master branch, I am able
to boot from sdcard on both without issues.
I can confirm that the patches work for me as well - not a surprise as
we have the same board.
Best, Joost
[1] https://lists.denx.de/pipermail/u-boot/2023-January/504116.html
[2] https://lists.denx.de/pipermail/u-boot/2021-March/445243.html
[3] https://lists.denx.de/pipermail/u-boot/2023-January/504115.html
[4] https://lists.denx.de/pipermail/u-boot/2023-January/505551.html
Henrik Grimler (2):
Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
samsung: common: only load CROS_EC if enabled in config
board/samsung/common/board.c | 27 ++-
drivers/mmc/s5p_sdhci.c | 2 +-
2 files changed, 15 insertions(+), 14 deletions(-)
--
2.30.2
Re: [PATCH v2 124/169] Correct SPL use of PHY_CADENCE_TORRENT
On Sun, Feb 05, 2023 at 03:40:33PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_PHY_CADENCE_TORRENT defined in Kconfig > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/phy/cadence/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile > index c247feb8262..a1cb6868c9e 100644 > --- a/drivers/phy/cadence/Makefile > +++ b/drivers/phy/cadence/Makefile > @@ -1,2 +1,2 @@ > obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o > -obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o > +obj-$(CONFIG_PHY_CADENCE_TORRENT) += phy-cadence-torrent.o This is a size increase on j7200_evm_a72 where we do not want this PHY in SPL. And FWIW, the sierra one is the same case, on other TI K3 platforms. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 068/169] Correct SPL use of DM_RNG
On Sun, Feb 05, 2023 at 03:39:37PM -0700, Simon Glass wrote:
> This converts 1 usage of this option to the non-SPL form, since there is
> no SPL_DM_RNG defined in Kconfig
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> boot/vbe_request.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/boot/vbe_request.c b/boot/vbe_request.c
> index 45f1d2b7e17..312edfa2bdb 100644
> --- a/boot/vbe_request.c
> +++ b/boot/vbe_request.c
> @@ -36,7 +36,7 @@ static int handle_random_req(ofnode node, int default_size,
> u32 size;
> int ret;
>
> - if (!CONFIG_IS_ENABLED(DM_RNG))
> + if (!IS_ENABLED(CONFIG_DM_RNG))
> return -ENOTSUPP;
>
> if (ofnode_read_u32(node, "vbe,size", &size)) {
This breaks sandbox_vpl.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/2] samsung: common: only load CROS_EC if enabled in config
On Wed, 8 Feb 2023 at 12:04, Henrik Grimler wrote:
>
> Otherwise non-ChromeOS samsung devices, like the odroid boards, are
> stuck in a bootloop if CONFIG_CROS_EC is not enabled:
>
> <...>
> MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> cros-ec communications failure -96
>
> Please reset with Power+Refresh
>
> Cannot init cros-ec device
> resetting ...
>
> Issue started after commit e44d7e73fe0d ("dm: core: Switch
> uclass_*_device_err to use uclass_*_device_check").
>
> Signed-off-by: Henrik Grimler
> ---
> board/samsung/common/board.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 16ce5cb89253..78161b807bac 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -217,26 +217,27 @@ int checkboard(void)
> #ifdef CONFIG_BOARD_LATE_INIT
> int board_late_init(void)
> {
> - struct udevice *dev;
> - int ret;
> int mmcbootdev = get_boot_mmc_dev();
> char mmcbootdev_str[16];
>
> - ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
> - if (ret && ret != -ENODEV) {
> - /* Force console on */
> - gd->flags &= ~GD_FLG_SILENT;
> -
> - printf("cros-ec communications failure %d\n", ret);
> - puts("\nPlease reset with Power+Refresh\n\n");
> - panic("Cannot init cros-ec device");
> - return -1;
> - }
> -
> printf("Boot device: MMC(%u)\n", mmcbootdev);
> sprintf(mmcbootdev_str, "%u", mmcbootdev);
> env_set("mmcbootdev", mmcbootdev_str);
>
> + if (IS_ENABLED(CONFIG_CROS_EC)) {
> + struct udevice *dev;
> + int ret = uclass_first_device_err(UCLASS_CROS_EC, &dev);
> + if (ret && ret != -ENODEV) {
> + /* Force console on */
> + gd->flags &= ~GD_FLG_SILENT;
> +
> + printf("cros-ec communications failure %d\n", ret);
> + puts("\nPlease reset with Power+Refresh\n\n");
> + panic("Cannot init cros-ec device");
> + return -1;
> + }
> + }
> +
> return 0;
> }
> #endif
> --
> 2.30.2
>
Reviewed-by: Simon Glass
Another option would be to change the check for -ENODEV to also check
for -EEPFNOSUPPORT (missing uclass).
Re: [PATCH v2 068/169] Correct SPL use of DM_RNG
Hi Tom,
On Wed, 8 Feb 2023 at 17:40, Tom Rini wrote:
>
> On Sun, Feb 05, 2023 at 03:39:37PM -0700, Simon Glass wrote:
>
> > This converts 1 usage of this option to the non-SPL form, since there is
> > no SPL_DM_RNG defined in Kconfig
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > boot/vbe_request.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/boot/vbe_request.c b/boot/vbe_request.c
> > index 45f1d2b7e17..312edfa2bdb 100644
> > --- a/boot/vbe_request.c
> > +++ b/boot/vbe_request.c
> > @@ -36,7 +36,7 @@ static int handle_random_req(ofnode node, int
> > default_size,
> > u32 size;
> > int ret;
> >
> > - if (!CONFIG_IS_ENABLED(DM_RNG))
> > + if (!IS_ENABLED(CONFIG_DM_RNG))
> > return -ENOTSUPP;
> >
> > if (ofnode_read_u32(node, "vbe,size", &size)) {
>
> This breaks sandbox_vpl.
Yes I think I mentioned that this needs dropping for ordering reasons.
I've moved it into splc.
Regards,
Simon
Re: [PATCH v2 091/169] Correct SPL uses of FSL_ISBC_KEY_EXT
On Sun, Feb 05, 2023 at 03:40:00PM -0700, Simon Glass wrote:
> This converts 9 usages of this option to the non-SPL form, since there is
> no SPL_FSL_ISBC_KEY_EXT defined in Kconfig
>
> Signed-off-by: Simon Glass
This is used to avoid including things in SPL that aren't required,
in commit 3a581af21af0 ("Convert CONFIG_FLASH_SPANSION_S29WS_N et al to
Kconfig") it shows why this is an example of CONFIG_IS_ENABLED() for
this case.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 068/169] Correct SPL use of DM_RNG
On Wed, Feb 08, 2023 at 06:08:11PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 8 Feb 2023 at 17:40, Tom Rini wrote:
> >
> > On Sun, Feb 05, 2023 at 03:39:37PM -0700, Simon Glass wrote:
> >
> > > This converts 1 usage of this option to the non-SPL form, since there is
> > > no SPL_DM_RNG defined in Kconfig
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > boot/vbe_request.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/boot/vbe_request.c b/boot/vbe_request.c
> > > index 45f1d2b7e17..312edfa2bdb 100644
> > > --- a/boot/vbe_request.c
> > > +++ b/boot/vbe_request.c
> > > @@ -36,7 +36,7 @@ static int handle_random_req(ofnode node, int
> > > default_size,
> > > u32 size;
> > > int ret;
> > >
> > > - if (!CONFIG_IS_ENABLED(DM_RNG))
> > > + if (!IS_ENABLED(CONFIG_DM_RNG))
> > > return -ENOTSUPP;
> > >
> > > if (ofnode_read_u32(node, "vbe,size", &size)) {
> >
> > This breaks sandbox_vpl.
>
> Yes I think I mentioned that this needs dropping for ordering reasons.
> I've moved it into splc.
OK, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 137/169] Correct SPL uses of SEC_FIRMWARE_ARMV8_PSCI
On Sun, Feb 05, 2023 at 05:55:04PM -0700, Simon Glass wrote: > This converts 2 usages of this option to the non-SPL form, since there is > no SPL_SEC_FIRMWARE_ARMV8_PSCI defined in Kconfig > > Signed-off-by: Simon Glass This usage avoids adding the fixup for arch_fixup_fdt to SPL where we don't need it. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 141/169] Correct SPL use of SPI_FLASH_BAR
On Sun, Feb 05, 2023 at 05:55:08PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_SPI_FLASH_BAR defined in Kconfig > > Signed-off-by: Simon Glass This is used to avoid unused code on at least xilinx_zynqmp_virt. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 096/169] Correct SPL uses of GMAC_ROCKCHIP
On Sun, Feb 05, 2023 at 03:40:05PM -0700, Simon Glass wrote: > This converts 2 usages of this option to the non-SPL form, since there is > no SPL_GMAC_ROCKCHIP defined in Kconfig > > Signed-off-by: Simon Glass This is used to avoid code in SPL/TPL on these platforms. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/3] net: ftmac100: change driver name from nds32_mac to ftmac100
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 1/3] net: ftmac100: change driver name from nds32_mac to > ftmac100 > > So it will be named similarly to the related ftgmac100 driver. > The old name 'nds32_mac' is not referred to anywhere in U-Boot. > > Signed-off-by: Sergei Antonov > Reviewed-by: Ramon Fried Reviewed-by: Rick Chen
Re: [PATCH v2 112/169] Correct SPL uses of NXP_FSPI
On Sun, Feb 05, 2023 at 03:40:21PM -0700, Simon Glass wrote: > This converts 2 usages of this option to the non-SPL form, since there is > no SPL_NXP_FSPI defined in Kconfig > > Signed-off-by: Simon Glass This is used to avoid code in SPL. -- Tom signature.asc Description: PGP signature
U-boot not loading NVMe driver on Pi CM4
Hi all, I'm using U-boot 2022.07 from Yocto Langdale distribution, with the following NVMe related kconfigs manually enabled through menuconfig: CONFIG_NVME CONFIG_NVME_PCI CONFIG_CMD_NVME and logging turned into max The SSD is Kioxia SSD, and it works with Pi 4 bootloader as I can boot Raspberry Pi OS from the NVMe drive. U boot is installed in the fat32 partition in the NVMe SSD for this Yocto poky build. When I boot to U boot prompt, I can see that the SSD is detected by pci U-Boot> pci long 0 - 0 'pcie@7d50' - found Found PCI device 00.00.00: vendor ID = 0x14e4 device ID = 0x2711 command register ID = 0x0006 status register = 0x0010 revision ID = 0x20 class code = 0x06 (Bridge device) sub class code = 0x04 programming interface = 0x00 cache line = 0x08 latency time =0x00 header type = 0x01 BIST =0x00 base address 0 = 0x base address 1 = 0x primary bus number = 0x00 secondary bus number =0x01 subordinate bus number = 0x01 secondary latency timer = 0x00 IO base = 0x00 IO limit =0x00 secondary status =0x memory base = 0xc000 memory limit =0xc000 prefetch memory base =0xfff1 prefetch memory limit = 0x0001 prefetch memory base upper = 0x prefetch memory limit upper = 0x IO base upper 16 bits = 0x IO limit upper 16 bits = 0x expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x01 bridge control = 0x 1 - 0 'pcie@7d50' - 1 'pci_0:0.0' - found Found PCI device 01.00.00: vendor ID = 0x1e0f device ID = 0x0001 command register ID = 0x0006 status register = 0x0010 revision ID = 0x00 class code = 0x01 (Mass storage controller) sub class code = 0x08 programming interface = 0x02 cache line = 0x08 latency time =0x00 header type = 0x00 BIST =0x00 base address 0 = 0xc004 base address 1 = 0x base address 2 = 0x base address 3 = 0x base address 4 = 0x base address 5 = 0x cardBus CIS pointer = 0x sub system vendor ID =0x1e0f sub system ID = 0x0001 expansion ROM base address = 0x interrupt line = 0x00 interrupt pin = 0x01 min Grant = 0x00 max Latency = 0x00 2 - 0 'pcie@7d50' - 1 'pci_0:0.0' - not found but it doesn't show up in nvme scan or nvme info U-Boot> nvme info U-Boot> nvme scan I know that U boot can boot from NVMe, as I can run Home Assistant OS that's based on U boot on NVMe drive. I just don't know if I missed a kconfig somewhere, or this U boot version haven't implement it Can anyone help me with this? Thanks Ignatius
Re: [PATCH v2 103/169] Correct SPL uses of IMX_RDC
On Sun, Feb 05, 2023 at 03:40:12PM -0700, Simon Glass wrote: > This converts 2 usages of this option to the non-SPL form, since there is > no SPL_IMX_RDC defined in Kconfig > > Signed-off-by: Simon Glass This is used to avoid the code in SPL in some cases. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 095/169] Correct SPL use of GENERATE_SMBIOS_TABLE
On Sun, Feb 05, 2023 at 03:40:04PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_GENERATE_SMBIOS_TABLE defined in Kconfig > > Signed-off-by: Simon Glass This is used to avoid increasing the size of SPL in some cases. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/3] net: ftmac100: simplify priv->iobase casting
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 2/3] net: ftmac100: simplify priv->iobase casting > > Replace 'phys_addr_t iobase' with 'struct ftmac100 *ftmac100' in struct > ftmac100_data. It allows to remove casting in a number of places. > > Since priv->iobase is phys_addr_t, use phys_to_virt() to make a pointer from > it. > > Signed-off-by: Sergei Antonov Reviewed-by: Rick Chen
Re: [PATCH v3 3/3] net: ftmac100: add mii read and write callbacks
> From: U-Boot On Behalf Of Sergei Antonov > Sent: Saturday, February 04, 2023 3:09 AM > To: u-boot@lists.denx.de; rfried@gmail.com; joe.hershber...@ni.com > Cc: Sergei Antonov > Subject: [PATCH v3 3/3] net: ftmac100: add mii read and write callbacks > > Register mii_bus with read and write callbacks to allow the 'mii' > command to work. Use a timeout of 10 ms to wait for the R/W operations to > complete. > > Signed-off-by: Sergei Antonov > --- Reviewed-by: Rick Chen Tested-by: Rick Chen I have verified this patch on AE350 platform and it work well with dhcp command as below: U-Boot 2023.04-rc1-00032-gf9f161b600-dirty (Feb 09 2023 - 10:55:03 +0800) DRAM: 1 GiB Core: 16 devices, 12 uclasses, devicetree: board Flash: 64 MiB MMC: Loading Environment from SPIFlash... SF: Detected mx25u1635e with page size 256 Bytes, erase size 4 KiB, total 2 MiB OK In:serial@f030 Out: serial@f030 Err: serial@f030 Net: no alias for ethernet0 eth0: mac@e010 Hit any key to stop autoboot: 0 RISC-V # RISC-V # dhcp 0x0600 10.0.12.60:Image-518 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 10.0.12.91 (280 ms) Using mac@e010 device TFTP from server 10.0.12.60; our IP address is 10.0.12.91 Filename 'Image-518'. Load address: 0x600 Loading: # # # # # # # # # # # # # # ### 300.8 KiB/s done Bytes transferred = 14098060 (d71e8c hex) RISC-V # mii device MII devices: 'eth0' Current device: 'eth0' RISC-V # mii info PHY 0x00: OUI = 0x606E, Model = 0x0B, Rev = 0x01, 100baseT, FDX RISC-V #
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi Stefan,
On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh wrote:
>
> Hi Pali,
>
> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár wrote:
> >
> > On Thursday 02 February 2023 19:04:45 Pali Rohár wrote:
> > > On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote:
> > > > Hi all,
> > > >
> > > > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote:
> > > > >
> > > > > On Wednesday 01 February 2023 09:17:15 Michael Walle wrote:
> > > > > > > > > When DM_SERIAL is enabled, the device-tree property
> > > > > > > > > dm-pre-reloc is
> > > > > > > > > required to boot over UART with kwboot. Enable this in a
> > > > > > > > > Kirkwood
> > > > > > > > > common u-boot dtsi.
> > > > > > > >
> > > > > > > > My (dev) board unfortunately, have a bootloader which can't
> > > > > > > > boot over
> > > > > > > > serial.
> > > > > > >
> > > > > > > This is feature of Marvell BootROM and does not require any
> > > > > > > special from
> > > > > > > Bootloader. So you should be able to boot over UART (if you have
> > > > > > > accessible pins).
> > > > > >
> > > > > > I know, but there are known versions ob the bootrom where uart boot
> > > > > > isn't supported (correctly).
> > > > >
> > > > > I heard about it... maybe it is a bug in client software (kwboot)? I
> > > > > do
> > > > > not have such board if you are interested in it I could try to send
> > > > > some
> > > > > details how to debug it.
> > > >
> > > > The Kirkwood SoCs came with different BootROM versions. Version 1.1
> > > > cannot be booted over UART, but version 1.2 can. I think there must
> > > > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug,
> > > > Dockstar, iConnect boards come with BootROM 1.1. Later version of
> > > > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel
> > > > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is
> > > > the same SoC, eg. 6281, they are actually produced at a different time
> > > > and have different BootROM versions.
> > >
> > > There are always multiple revisions of the same SoC. So it is possible
> > > that something was broken on first revision of 88F6281 and in next
> > > revision was updated BootROM with some fixes. Revision is written on
> > > package label and for Armada SoCs it is available also in some register
> > > (not sure about Kirkwood). It looks like that there is at least revision
> > > Z0 and revision A0 of some Kirkwood SoC.
> > >
> > > If there is a bug in first revisions then it should be documented in
> > > some Kirkwood Errata document. Unfortunately I have never seen it, it is
> > > not public, so I have no idea. In any case, if somebody has access to
> > > Marvell documents, interesting are these document numbers:
> > >
> > > * MV-S105223-001 - Differences Between the 88F6192, and 88F6281 Stepping
> > > Z0 and A0
> > > * MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata,
> > > Interface Guidelines, and Restrictions
> > > * MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional
> > > Errata, Interface Guidelines, and Restrictions
> > >
> > > One of the option how to investigate or debug this issue without
> > > documentation is to dump both BootROM versions (1.1, 1.2) and compare
> > > them. Either there is different UART protocol for booting (which needs
> > > to be implemented) or UART protocol is buggy and needs some workaround
> > > or it is completely broken and does not work.
> >
> > BootROM is mapped to 0xF800 address and is 64 kB long. So via U-Boot
> > md command it is possible to dump it over console. Or via ext4write
> > command store it so ext4 fs on sd card / sata disk.
>
> Thanks for the info. It will be a while before I can get back to this
> BootROM 1.1 vs 1.2 topic.
>
I have run some more tests, and am quite positive that if the uart0
node exists in the DTS, it must be tagged with dm,pre-reloc. That is
consistent with the serial documentation in
doc/develop/driver-model/serial-howto.rst. The issue is whether the
uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag
must also be used.
To prove my theory, I've modified the Pogo V4 DTS to look exactly like
the NSA310S, as far as uart0 is concerned. The NSA310S does not even
have a uart0 node! and DM_SERIAL boots fine with this box. With the
patch below, the Pogo V4 can be kwboot and run normally. No
dm-pre-reloc tag is needed.
diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
index 5aa4669ae2..227d5ff802 100644
--- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
+++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
@@ -24,7 +24,8 @@
};
chosen {
- stdout-path = "uart0:115200n8";
+ bootargs = "console=ttyS0,115200";
+ stdout-path = &uart0;
};
gpio_keys {
@@ -97,10 +98,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
/*
* This PCIE controller has a USB 3.0 XHCI controller at 1,0
*/
Also, note that just
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi Tony,
On 2/9/23 04:17, Tony Dinh wrote:
Hi Stefan,
On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh wrote:
Hi Pali,
On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár wrote:
On Thursday 02 February 2023 19:04:45 Pali Rohár wrote:
On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote:
Hi all,
On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote:
On Wednesday 01 February 2023 09:17:15 Michael Walle wrote:
When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is
required to boot over UART with kwboot. Enable this in a Kirkwood
common u-boot dtsi.
My (dev) board unfortunately, have a bootloader which can't boot over
serial.
This is feature of Marvell BootROM and does not require any special from
Bootloader. So you should be able to boot over UART (if you have
accessible pins).
I know, but there are known versions ob the bootrom where uart boot
isn't supported (correctly).
I heard about it... maybe it is a bug in client software (kwboot)? I do
not have such board if you are interested in it I could try to send some
details how to debug it.
The Kirkwood SoCs came with different BootROM versions. Version 1.1
cannot be booted over UART, but version 1.2 can. I think there must
be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug,
Dockstar, iConnect boards come with BootROM 1.1. Later version of
Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel
NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is
the same SoC, eg. 6281, they are actually produced at a different time
and have different BootROM versions.
There are always multiple revisions of the same SoC. So it is possible
that something was broken on first revision of 88F6281 and in next
revision was updated BootROM with some fixes. Revision is written on
package label and for Armada SoCs it is available also in some register
(not sure about Kirkwood). It looks like that there is at least revision
Z0 and revision A0 of some Kirkwood SoC.
If there is a bug in first revisions then it should be documented in
some Kirkwood Errata document. Unfortunately I have never seen it, it is
not public, so I have no idea. In any case, if somebody has access to
Marvell documents, interesting are these document numbers:
* MV-S105223-001 - Differences Between the 88F6192, and 88F6281 Stepping Z0 and
A0
* MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata, Interface
Guidelines, and Restrictions
* MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional Errata,
Interface Guidelines, and Restrictions
One of the option how to investigate or debug this issue without
documentation is to dump both BootROM versions (1.1, 1.2) and compare
them. Either there is different UART protocol for booting (which needs
to be implemented) or UART protocol is buggy and needs some workaround
or it is completely broken and does not work.
BootROM is mapped to 0xF800 address and is 64 kB long. So via U-Boot
md command it is possible to dump it over console. Or via ext4write
command store it so ext4 fs on sd card / sata disk.
Thanks for the info. It will be a while before I can get back to this
BootROM 1.1 vs 1.2 topic.
I have run some more tests, and am quite positive that if the uart0
node exists in the DTS, it must be tagged with dm,pre-reloc. That is
consistent with the serial documentation in
doc/develop/driver-model/serial-howto.rst. The issue is whether the
uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag
must also be used.
To prove my theory, I've modified the Pogo V4 DTS to look exactly like
the NSA310S, as far as uart0 is concerned. The NSA310S does not even
have a uart0 node! and DM_SERIAL boots fine with this box. With the
patch below, the Pogo V4 can be kwboot and run normally. No
dm-pre-reloc tag is needed.
diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
index 5aa4669ae2..227d5ff802 100644
--- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
+++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
@@ -24,7 +24,8 @@
};
chosen {
- stdout-path = "uart0:115200n8";
+ bootargs = "console=ttyS0,115200";
+ stdout-path = &uart0;
};
gpio_keys {
@@ -97,10 +98,6 @@
};
};
-&uart0 {
- status = "okay";
-};
-
/*
* This PCIE controller has a USB 3.0 XHCI controller at 1,0
*/
FWIU, you are hitting a bug in the early serial console code, perhaps
in serial_check_stdout()?
Could you please check if Pogo V4 boots with
CONFIG_REQUIRE_SERIAL_CONSOLE unset?
Also, note that just enabling DEBUG_UART would always make the board
frozen when u-boot starts.
This should not be the case of course. Are you sure you've correctly
configured the DEBUG UART?
So this was another factor why it took me
so long to figure this out :) I've just restored everything and
removed the uart0 node from the Pogo V4 DTS like above and it is
working.
But of cours
