Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi Andy,
On 3/15/23 14:26, andy...@sony.com wrote:
> Hi Jaehoon
>
>> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
>> Author: yuezhang...@sony.com
>> Date: Wed Mar 17 06:44:37 2021 +
>>
>> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
>>
>> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
>>
>> Revert the above commit.
>>
>> To Andy,
>>
>> Was there any problem without above commit?
>
> Without above revert commit, we found "sdhci_transfer_data: Transfer data
> timeout" on db410c board with v2018.01.
Thanks for sharing it. I had been trying to find db410c board.
I found its board, so I will try to check with/without its patch.
After checked, I will reply again ASAP.
Best Regards,
Jaehoon Chung
>
> Best Regards
> Andy Wu
>
>> -Original Message-
>> From: Jaehoon Chung
>> Sent: Monday, March 13, 2023 9:03 PM
>> To: Henrik Grimler ; Jaehoon Chung
>>
>> Cc: jo...@diskos.nl; peng@nxp.com; Wu, Andy ;
>> s...@chromium.org; u-boot@lists.denx.de;
>> ~postmarketos/upstream...@lists.sr.ht
>> Subject: Re: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the
>> SDHCI_QUIRK_BROKEN_R1B"
>>
>> Hi,
>>
>> On 3/11/23 19:31, Henrik Grimler wrote:
>>> Hi Jaehoon,
>>>
>>> On Fri, Feb 10, 2023 at 09:00:33AM +0900, Jaehoon Chung wrote:
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Henrik
> Grimler
> Sent: Thursday, February 9, 2023 4:04 AM
> To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
> s...@chromium.org; m.szyprow...@samsung.com; u-boot@lists.denx.de;
> ~postmarketos/upstream...@lists.sr.ht
> Cc: Henrik Grimler
> Subject: [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
> <...>
Thanks for sharing issue.
I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
Because it was verified that it was working fine without
>> SDHCI_QUIKR_BROKEN_RIB.
>>>
>>> Just wondering if you have had an opportunity to test this on any of
>>> your devices? You can find v2 here, though this patch had no changes:
>>> INVALID URI REMOVED
>>>
>> 3-February/508928.html__;!!JmoZiZGBv3RvKRSx!5wpP-x5Y69S7MynP1sOmQI
>> HaVG
>>> N9_ZLl5dxDDenNWPHdwFnNPdAEvBrUt69tSpQ9o0Nv-LQ9Gie_aGgP$
>>
>> In my opinion,
>>
>> commit 4a3ea75de4c5b3053eac326bf1c753ed65df8cb9
>> Author: yuezhang...@sony.com
>> Date: Wed Mar 17 06:44:37 2021 +
>>
>> Revert "mmc: sdhci: set to INT_DATA_END when there are data"
>>
>> This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.
>>
>> Revert the above commit.
>>
>> To Andy,
>>
>> Was there any problem without above commit?
>>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>
>>>
Best Regards,
Jaehoon Chung
>>>
>>> Best regards,
>>> Henrik Grimler
>>>
>
> 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
Re: [PATCH v3 3/4] efi_loader: check lowest supported version in capsule update
On Wed, 22 Mar 2023 at 09:36, Masahisa Kojima
wrote:
>
> On Tue, 21 Mar 2023 at 15:42, Heinrich Schuchardt wrote:
> >
> > On 3/20/23 06:54, Masahisa Kojima wrote:
> > > The FMP Payload Header which EDK2 capsule generation scripts
> > > insert contains lowest supported version.
> > > This commit reads the lowest supported version stored in the
> > > "FmpState" EFI non-volatile variable, then check if the
> > > firmware version of ongoing capsule is equal or greater than
> > > the lowest supported version.
> > >
> > > Signed-off-by: Masahisa Kojima
> > > ---
> > > No changes since v2
> > >
> > > Changes in v2:
> > > - add error message when the firmware version is lower than
> > >lowest supported version
> > >
> > > lib/efi_loader/efi_firmware.c | 50 ++-
> > > 1 file changed, 49 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> > > index 289456ecbb..8d6e32006d 100644
> > > --- a/lib/efi_loader/efi_firmware.c
> > > +++ b/lib/efi_loader/efi_firmware.c
> > > @@ -391,6 +391,39 @@ void efi_firmware_parse_payload_header(const void
> > > **p_image,
> > > *p_image_size = image_size;
> > > }
> > >
> > > +/**
> > > + * efi_firmware_get_lowest_supported_version - get the lowest supported
> > > version
> > > + * @image_index: image_index
> > > + *
> > > + * Get the lowest supported version from FmpState variable.
> > > + *
> > > + * Return: lowest supported version, return 0 if reading
> > > FmpState
> > > + * variable failed
> > > + */
> > > +static
> > > +u32 efi_firmware_get_lowest_supported_version(u8 image_index)
> > > +{
> > > + u16 varname[13]; /* u"FmpState" */
> > > + efi_status_t ret;
> > > + efi_uintn_t size;
> > > + efi_guid_t *image_type_id;
> > > + struct fmp_state var_state = { 0 };
> > > +
> > > + image_type_id = efi_firmware_get_image_type_id(image_index);
> > > + if (!image_type_id)
> > > + return 0;
> > > +
> > > + efi_create_indexed_name(varname, sizeof(varname), "FmpState",
> > > + image_index);
> > > + size = sizeof(var_state);
> > > + ret = efi_get_variable_int(varname, image_type_id, NULL, ,
> > > +_state, NULL);
> > > + if (ret != EFI_SUCCESS)
> > > + return 0;
> > > +
> > > + return var_state.lowest_supported_version;
> > > +}
> > > +
> > > /**
> > >* efi_firmware_verify_image - verify image
> > >* @p_image:Pointer to new image
> > > @@ -398,7 +431,8 @@ void efi_firmware_parse_payload_header(const void
> > > **p_image,
> > >* @image_index Image index
> > >* @state Pointer to fmp state
> > >*
> > > - * Verify the capsule file
> > > + * Verify the capsule authentication and check if the fw_version
> > > + * is equal or greater than the lowest supported version.
> > >*
> > >* Return: status code
> > >*/
> > > @@ -409,10 +443,24 @@ efi_status_t efi_firmware_verify_image(const void
> > > **p_image,
> > > struct fmp_state *state)
> > > {
> > > efi_status_t ret;
> > > + u32 lowest_supported_version;
> > >
> > > ret = efi_firmware_capsule_authenticate(p_image, p_image_size,
> > > state);
> > > efi_firmware_parse_payload_header(p_image, p_image_size, state);
> > >
> > > + /* check lowest_supported_version if capsule authentication passes
> > > */
> > > + if (ret == EFI_SUCCESS) {
> > > + lowest_supported_version =
> > > +
> > > efi_firmware_get_lowest_supported_version(image_index);
> > > + if (lowest_supported_version > state->fw_version) {
> > > + printf("fw_version(%u) is too low(expected >%u).
> > > Aborting update\n",
> > > +state->fw_version, lowest_supported_version);
> >
> > Please, use log_warning() or log_err() instead of printf().
> >
> > The addressee is a user not a developer:
> >
> > "Firmware version %u too low. Expecting >= %u"
>
> OK.
>
> >
> > We should have one central place where upon exit we write a message
> > indicating that either the capsule update was successful or failed.
> >
> > "Firmware updated to version %u" : "Firmware update failed"
>
> Yes, I will add the log output for the user.
For failure cases, UpdateCapsule runtime service outputs the result as follows.
"Firmware update failed:
Applying capsule Test08 failed."
So I will not add the "Firmware update failed" in FMP->SetImage() function.
Thanks,
Masahisa Kojima
>
> Thanks,
> Masahisa Kojima
>
> >
> > Best regards
> >
> > Heinrich
> >
> > > + state->last_attempt_status =
> > > + LAST_ATTEMPT_STATUS_ERROR_INCORRECT_VERSION;
> > > + ret = EFI_INVALID_PARAMETER;
> > > + }
> > > + }
> > > +
> >
Re: [PATCH 5/6] purism: librem5: Fix a function declaration in spl.c
On Thu, Mar 09, 2023 at 11:22:11AM -0500, Tom Rini wrote: > Here we implement usb_gadget_handle_interrupts() but did not include > so did not have the declaration correct. Fix this > and add the missing include. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/6] examples: Don't use LTO for hello_world
On Thu, Mar 09, 2023 at 11:22:09AM -0500, Tom Rini wrote: > If we're building U-Boot with LTO, we don't want to use that for > examples as it's more work than required. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/6] spl: Add function prototype for spl_mmc_get_uboot_raw_sector
On Thu, Mar 09, 2023 at 11:22:08AM -0500, Tom Rini wrote: > We did not add a prototype for spl_mmc_get_uboot_raw_sector to > include/spl.h before, so add and document one now. Correct the incorrect > prototype in board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c and > ensure that we have spl.h where we define a non-weak > spl_mmc_get_uboot_raw_sector as well. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/6] arm: Correct cpu_reset function prototype on some platforms
On Thu, Mar 09, 2023 at 11:22:07AM -0500, Tom Rini wrote: > Some platforms were not including which sets the prototype > for reset_cpu, and in turn had it set wrong. Correct these cases. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/7] proftool: Remove unused variables in make_flame_tree
On Mon, Feb 27, 2023 at 05:08:38PM -0500, Tom Rini wrote: > With clang-15 we now get reported that in the make_flame_tree function, > neither the missing_count nor depth variables are used, only > incremenete/decremented. Remove these. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/7] imx8image: Remove unused cont_img_count variable
On Mon, Feb 27, 2023 at 05:08:37PM -0500, Tom Rini wrote: > With clang-15, it is now reported that cont_img_count is unused. This is > true as the code will increment / reset this counter, but never > functionally use it. Remove it. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass > Reviewed-by: Fabio Estevam > Reviewed-by: Peng Fan Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/7] zlib: trees.c: Fix a warning with clang-15
On Mon, Feb 27, 2023 at 05:08:36PM -0500, Tom Rini wrote: > With clang-15 we now will get warnings such as: > > warning: a function declaration without a prototype is deprecated in all > versions of C [-Wstrict-prototypes] > > And it is easy enough to address this warning here, even if we would > like to stay in sync more with upstream as it's a single location. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/7] libavb: Fix a warning with clang-15
On Mon, Feb 27, 2023 at 05:08:35PM -0500, Tom Rini wrote: > With clang-15 we now will get warnings such as: > > warning: a function declaration without a prototype is deprecated in all > versions of C [-Wstrict-prototypes] > > And it is easy enough to address this warning here, as we aren't > concerned with re-syncing with an upstream. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/7] dlmalloc: Fix a warning with clang-15
On Mon, Feb 27, 2023 at 05:08:34PM -0500, Tom Rini wrote: > With clang-15 we now will get warnings such as: > > warning: a function declaration without a prototype is deprecated in all > versions of C [-Wstrict-prototypes] > > And it is easy enough to address this warning here, as we aren't > concerned with re-syncing with an upstream. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/7] global: Disable deprecated-non-prototype warning with clang
On Mon, Feb 27, 2023 at 05:08:33PM -0500, Tom Rini wrote:
> We have a number of places in the code which use the following syntax:
>
> void func(a, b, c)
> int a; /* Does a */
> something_t *b; /* Pointer to b */
> int c; /* Does c */
> {
> ...
> }
>
> Which while not what we document as our coding style, this is also code
> which we have imported from other projects, and would like to re-sync
> with in the future. While the biggest example of this is the zlib code,
> there are other places as well. For now, we will silence this warning.
>
> Signed-off-by: Tom Rini
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
How to add eth1 to test device tree?
Hi All, When running the sandbox tests, I want to know how to enable eth1 in order to be able to test network features. The following command is used to run sandbox tests. ./test/py/test.py -k testname.py I am specifically interested in running the network tests. ./test/py/test.py -k test_net.py These Python tests use test.dts device tree which does not have eth1 in it. I can replace the test.dts file with sandbox.dts to enable eth1 and run the network tests; however, I think there should be a better way to do it. Can anyone help me with this issue? When running U-Boot, the -T option could be used to tell it to use the test.dts or -D to use sandbox.dts; however, there is no such option when running test.py. Eth1 is needed in order to enable the network. Enabling the sandbox network is explained after line 250 in doc/arch/sandbox.rst. For more information, the following is the list of network interfaces when each device tree is used. arch/sandbox/dts/sandbox.dts Net: eth0: host_lo, eth1: host_eth0, eth2: host_br1, eth3: eth@10002000 arch/sandbox/dts/test.dts Net: eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth6: eth@10004000, eth4: dsa-test-eth, eth2: lan0, eth7: lan1
[PATCH v2] CI: Add m68k target
Add M5208EVBE board to CI. This does not use default config due to limitations of QEMU emulation, instead the timer is switched from DMA timer to PIT timer and RAMBAR accesses are inhibited. Local QEMU launch command is as follows: $ qemu-system-m68k -nographic -machine mcf5208evb -cpu m5208 -bios u-boot.bin Signed-off-by: Marek Vasut --- Cc: Angelo Dureghello Cc: Huan Wang Cc: Marek Vasut Cc: Simon Glass Cc: Stefan Roese Cc: Tom Rini --- V2: Disable CONFIG_MCFTMR using -a ~CONFIG_MCFTMR --- .azure-pipelines.yml | 5 + .gitlab-ci.yml | 8 2 files changed, 13 insertions(+) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 5594a67d6b5..6452127ff42 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -297,6 +297,11 @@ stages: qemu_arm64: TEST_PY_BD: "qemu_arm64" TEST_PY_TEST_SPEC: "not sleep" +qemu_m68k: + TEST_PY_BD: "M5208EVBE" + TEST_PY_ID: "--id qemu" + TEST_PY_TEST_SPEC: "not sleep and not efi" + OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR" qemu_malta: TEST_PY_BD: "malta" TEST_PY_ID: "--id qemu" diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 5431bf6011a..a06c2aa4be9 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -355,6 +355,14 @@ qemu_arm64 test.py: TEST_PY_TEST_SPEC: "not sleep" <<: *buildman_and_testpy_dfn +qemu_m68k test.py: + variables: +TEST_PY_BD: "M5208EVBE" +TEST_PY_ID: "--id qemu" +TEST_PY_TEST_SPEC: "not sleep and not efi" +OVERRIDE: "-a CONFIG_M68K_QEMU=y -a ~CONFIG_MCFTMR" + <<: *buildman_and_testpy_dfn + qemu_malta test.py: variables: TEST_PY_BD: "malta" -- 2.39.2
[PATCH] configs: m68k: Use default shell prompt
The current shell prompt '->' interferes with CI matching on 'bdinfo' output. When CI test.py attempts to locate memory information in the 'bdinfo' output, it matches on '->' prefix which is identical to the shell prefix. Switch the prompt to default '=>' one to avoid this interference. Suggested-by: Tom Rini # found the CI oddity Signed-off-by: Marek Vasut --- Cc: Angelo Dureghello Cc: Huan Wang Cc: Marek Vasut Cc: Simon Glass Cc: Stefan Roese Cc: Tom Rini --- configs/M5208EVBE_defconfig | 1 - configs/M5235EVB_defconfig | 1 - configs/M5272C3_defconfig | 1 - configs/M5275EVB_defconfig | 1 - configs/M5282EVB_defconfig | 1 - configs/M53017EVB_defconfig | 1 - configs/M5329AFEE_defconfig | 1 - configs/M5329BFEE_defconfig | 1 - configs/M5373EVB_defconfig | 1 - 9 files changed, 9 deletions(-) diff --git a/configs/M5208EVBE_defconfig b/configs/M5208EVBE_defconfig index 3263414d1c2..bc98d7fd641 100644 --- a/configs/M5208EVBE_defconfig +++ b/configs/M5208EVBE_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5208EVBE" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x4001 CONFIG_ENV_ADDR=0x2000 CONFIG_TARGET_M5208EVBE=y diff --git a/configs/M5235EVB_defconfig b/configs/M5235EVB_defconfig index fbd3e086ec3..ac696d8a8d6 100644 --- a/configs/M5235EVB_defconfig +++ b/configs/M5235EVB_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5235EVB" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x2 CONFIG_ENV_ADDR=0xFFE04000 CONFIG_TARGET_M5235EVB=y diff --git a/configs/M5272C3_defconfig b/configs/M5272C3_defconfig index 1c51c4a1666..6b46c6f4f51 100644 --- a/configs/M5272C3_defconfig +++ b/configs/M5272C3_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x4 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5272C3" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x2 CONFIG_ENV_ADDR=0xFFE04000 CONFIG_TARGET_M5272C3=y diff --git a/configs/M5275EVB_defconfig b/configs/M5275EVB_defconfig index ca1c18420ff..8eb551678b9 100644 --- a/configs/M5275EVB_defconfig +++ b/configs/M5275EVB_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x4 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5275EVB" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_ENV_ADDR=0xFFE04000 CONFIG_TARGET_M5275EVB=y diff --git a/configs/M5282EVB_defconfig b/configs/M5282EVB_defconfig index 2b053e3bbfe..1997f3800bb 100644 --- a/configs/M5282EVB_defconfig +++ b/configs/M5282EVB_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x4 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5282EVB" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x2 CONFIG_ENV_ADDR=0xFFE04000 CONFIG_TARGET_M5282EVB=y diff --git a/configs/M53017EVB_defconfig b/configs/M53017EVB_defconfig index c70964f7aa0..92445feb7d2 100644 --- a/configs/M53017EVB_defconfig +++ b/configs/M53017EVB_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_SECT_SIZE=0x8000 CONFIG_DEFAULT_DEVICE_TREE="M53017EVB" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x4001 CONFIG_ENV_ADDR=0x4 CONFIG_TARGET_M53017EVB=y diff --git a/configs/M5329AFEE_defconfig b/configs/M5329AFEE_defconfig index 455eea255ae..238413d2d5c 100644 --- a/configs/M5329AFEE_defconfig +++ b/configs/M5329AFEE_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5329AFEE" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x4001 CONFIG_ENV_ADDR=0x4000 CONFIG_TARGET_M5329EVB=y diff --git a/configs/M5329BFEE_defconfig b/configs/M5329BFEE_defconfig index 0251444b3bf..43cfc0e94db 100644 --- a/configs/M5329BFEE_defconfig +++ b/configs/M5329BFEE_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5329BFEE" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x4001 CONFIG_ENV_ADDR=0x4000 CONFIG_TARGET_M5329EVB=y diff --git a/configs/M5373EVB_defconfig b/configs/M5373EVB_defconfig index eec95da8573..db85e3401f4 100644 --- a/configs/M5373EVB_defconfig +++ b/configs/M5373EVB_defconfig @@ -4,7 +4,6 @@ CONFIG_SYS_MALLOC_LEN=0x2 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_DEFAULT_DEVICE_TREE="M5373EVB" -CONFIG_SYS_PROMPT="-> " CONFIG_SYS_LOAD_ADDR=0x4001 CONFIG_ENV_ADDR=0x4000 CONFIG_TARGET_M5373EVB=y -- 2.39.2
[PATCH v2 2/3] arch: m68k: Introduce trivial PIT based timer
The QEMU emulation of m68k does not support DMA timer, the only timer that is supported is the PIT timer. Implement trivial PIT timer support for m68k. Signed-off-by: Marek Vasut --- Cc: Angelo Dureghello Cc: Huan Wang Cc: Marek Vasut Cc: Simon Glass Cc: Stefan Roese Cc: Tom Rini --- V2: Replace CFG_MCFTMR with CONFIG_MCFTMR in common/board_f.c --- arch/m68k/include/asm/immap.h | 24 +++ arch/m68k/lib/time.c | 36 +-- common/board_f.c | 2 +- 3 files changed, 59 insertions(+), 3 deletions(-) diff --git a/arch/m68k/include/asm/immap.h b/arch/m68k/include/asm/immap.h index 3b515fe2c65..aafa4f40cb3 100644 --- a/arch/m68k/include/asm/immap.h +++ b/arch/m68k/include/asm/immap.h @@ -25,6 +25,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(6) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) @@ -47,6 +49,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(0x1E) /* Level must include inorder to work */ #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) @@ -72,6 +76,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(MCFSIM_ICR_AUTOVEC | MCFSIM_ICR_LEVEL7 | MCFSIM_ICR_PRI3) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 200) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5249 */ @@ -95,6 +101,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(MCFSIM_ICR_AUTOVEC | MCFSIM_ICR_LEVEL3 | MCFSIM_ICR_PRI3) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 200) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5253 */ @@ -114,6 +122,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(0x1E) /* Interrupt level 3, priority 6 */ #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) @@ -139,6 +149,8 @@ #define CFG_SYS_TMRINTR_PEND (0) #define CFG_SYS_TMRINTR_PRI(INT_ICR1_TMR3PI | INT_ICR1_TMR3IPL(5)) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5272 */ @@ -161,6 +173,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(0x1E) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5275 */ @@ -183,6 +197,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(0x1E) /* Level must include inorder to work */ #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5282 */ @@ -207,6 +223,8 @@ #define CFG_SYS_TMRINTR_PRI (MCFSIM_ICR_AUTOVEC | \ MCFSIM_ICR_LEVEL7 | MCFSIM_ICR_PRI3) #define CFG_SYS_TIMER_PRESCALER (((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #endif /* CONFIG_M5307 */ @@ -226,6 +244,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(6) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) @@ -248,6 +268,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(6) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) @@ -278,6 +300,8 @@ #define CFG_SYS_TMRINTR_PEND (CFG_SYS_TMRINTR_MASK) #define CFG_SYS_TMRINTR_PRI(6) #define CFG_SYS_TIMER_PRESCALER(((gd->bus_clk / 100) - 1) << 8) +#else +#define CFG_SYS_UDELAY_BASE(MMAP_PIT0) #endif #define CFG_SYS_INTR_BASE (MMAP_INTC0) diff --git a/arch/m68k/lib/time.c b/arch/m68k/lib/time.c index 500e4dbbba2..61db1e6c500
[PATCH v2 3/3] arch: m68k: Add QEMU specific RAMBAR workaround
The QEMU emulation of m68k does not support RAMBAR accesses, add Kconfig option which inhibits those accesses, so that U-Boot can be started in m68k QEMU for CI testing purpopses until QEMU emulation improves. Signed-off-by: Marek Vasut --- Cc: Angelo Dureghello Cc: Huan Wang Cc: Marek Vasut Cc: Simon Glass Cc: Stefan Roese Cc: Tom Rini --- V2: No change --- arch/m68k/Kconfig | 11 ++- arch/m68k/cpu/mcf52x2/start.S | 4 ++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 32759cde47d..1911563e540 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -198,8 +198,17 @@ source "board/freescale/m5373evb/Kconfig" source "board/sysam/amcore/Kconfig" source "board/sysam/stmark2/Kconfig" +config M68K_QEMU + bool "Build with workarounds for incomplete QEMU emulation" + default n + help + QEMU 8.x currently does not implement RAMBAR accesses and + DMA timers. Enable this option for U-Boot CI purposes only + to skip the RAMBAR accesses. + config MCFTMR bool "Use DMA timer" - default y + default y if !M68K_QEMU + default n if M68K_QEMU endmenu diff --git a/arch/m68k/cpu/mcf52x2/start.S b/arch/m68k/cpu/mcf52x2/start.S index d48d0192eea..51d2e23df10 100644 --- a/arch/m68k/cpu/mcf52x2/start.S +++ b/arch/m68k/cpu/mcf52x2/start.S @@ -98,7 +98,7 @@ _start: nop move.w #0x2700,%sr -#if defined(CONFIG_M5208) +#if defined(CONFIG_M5208) && !defined(CONFIG_M68K_QEMU) /* Initialize RAMBAR: locate SRAM and validate it */ move.l #(CFG_SYS_INIT_RAM_ADDR + CFG_SYS_INIT_RAM_CTRL), %d0 movec %d0, %RAMBAR1 @@ -120,7 +120,7 @@ _start: movec %d0, %RAMBAR0 #endif /* CONFIG_M5272 || CONFIG_M5249 || CONFIG_M5253 */ -#if defined(CONFIG_M5282) || defined(CONFIG_M5271) +#if (defined(CONFIG_M5282) || defined(CONFIG_M5271)) && !defined(CONFIG_M68K_QEMU) /* set MBAR address + valid flag */ move.l #(CFG_SYS_MBAR + 1), %d0 move.l %d0, 0x4000 -- 2.39.2
[PATCH v2 1/3] arch: m68k: Use existing CONFIG_MCFTMR instead of CFG_MCFTMR
There is an existing CONFIG_MCFTMR Kconfig symbol,
use it and drop all other instances of CFG_MCFTMR.
This duality is likely a result of bogus conversion
to Kconfig.
Fixes: 7ff7b46e6ce ("m68k: rename CONFIG_MCFTMR to CFG_MCFTMR")
Signed-off-by: Marek Vasut
---
Cc: Angelo Dureghello
Cc: Huan Wang
Cc: Marek Vasut
Cc: Simon Glass
Cc: Stefan Roese
Cc: Tom Rini
---
V2: Add Fixes tag
---
arch/m68k/Kconfig | 1 +
arch/m68k/cpu/mcf523x/interrupts.c | 2 +-
arch/m68k/cpu/mcf52x2/interrupts.c | 12 ++--
arch/m68k/cpu/mcf532x/interrupts.c | 2 +-
arch/m68k/cpu/mcf5445x/interrupts.c | 2 +-
arch/m68k/include/asm/immap.h | 24
arch/m68k/lib/time.c| 4 ++--
board/freescale/m53017evb/README| 2 +-
board/freescale/m5373evb/README | 2 +-
include/configs/M5208EVBE.h | 1 -
include/configs/M5235EVB.h | 1 -
include/configs/M5249EVB.h | 1 -
include/configs/M5253DEMO.h | 1 -
include/configs/M5272C3.h | 1 -
include/configs/M5275EVB.h | 1 -
include/configs/M5282EVB.h | 1 -
include/configs/M53017EVB.h | 1 -
include/configs/M5329EVB.h | 1 -
include/configs/M5373EVB.h | 1 -
include/configs/amcore.h| 1 -
include/configs/astro_mcf5373l.h| 1 -
include/configs/cobra5272.h | 1 -
include/configs/eb_cpu5282.h| 1 -
include/configs/stmark2.h | 1 -
24 files changed, 26 insertions(+), 40 deletions(-)
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 76233ef563f..32759cde47d 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -200,5 +200,6 @@ source "board/sysam/stmark2/Kconfig"
config MCFTMR
bool "Use DMA timer"
+ default y
endmenu
diff --git a/arch/m68k/cpu/mcf523x/interrupts.c
b/arch/m68k/cpu/mcf523x/interrupts.c
index b02ea29f635..09c7f9e67cc 100644
--- a/arch/m68k/cpu/mcf523x/interrupts.c
+++ b/arch/m68k/cpu/mcf523x/interrupts.c
@@ -22,7 +22,7 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
int0_t *intp = (int0_t *) (CFG_SYS_INTR_BASE);
diff --git a/arch/m68k/cpu/mcf52x2/interrupts.c
b/arch/m68k/cpu/mcf52x2/interrupts.c
index e787c7605f8..c5ed0600736 100644
--- a/arch/m68k/cpu/mcf52x2/interrupts.c
+++ b/arch/m68k/cpu/mcf52x2/interrupts.c
@@ -34,7 +34,7 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
intctrl_t *intp = (intctrl_t *) (CFG_SYS_INTR_BASE);
@@ -42,7 +42,7 @@ void dtimer_intr_setup(void)
clrbits_be32(>int_icr1, INT_ICR1_TMR3MASK);
setbits_be32(>int_icr1, CFG_SYS_TMRINTR_PRI);
}
-#endif /* CFG_MCFTMR */
+#endif /* CONFIG_MCFTMR */
#endif /* CONFIG_M5272 */
#if defined(CONFIG_M5208) || defined(CONFIG_M5282) || \
@@ -63,7 +63,7 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
int0_t *intp = (int0_t *) (CFG_SYS_INTR_BASE);
@@ -72,7 +72,7 @@ void dtimer_intr_setup(void)
clrbits_be32(>imrl0, 0x0001);
clrbits_be32(>imrl0, CFG_SYS_TMRINTR_MASK);
}
-#endif /* CFG_MCFTMR */
+#endif /* CONFIG_MCFTMR */
#endif /* CONFIG_M5282 | CONFIG_M5271 | CONFIG_M5275 */
#if defined(CONFIG_M5249) || defined(CONFIG_M5253)
@@ -83,11 +83,11 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
mbar_writeLong(MCFSIM_IMR, mbar_readLong(MCFSIM_IMR) & ~0x0400);
mbar_writeByte(MCFSIM_TIMER2ICR, CFG_SYS_TMRINTR_PRI);
}
-#endif /* CFG_MCFTMR */
+#endif /* CONFIG_MCFTMR */
#endif /* CONFIG_M5249 || CONFIG_M5253 */
diff --git a/arch/m68k/cpu/mcf532x/interrupts.c
b/arch/m68k/cpu/mcf532x/interrupts.c
index bbe823c0cf7..4f72fa88e58 100644
--- a/arch/m68k/cpu/mcf532x/interrupts.c
+++ b/arch/m68k/cpu/mcf532x/interrupts.c
@@ -23,7 +23,7 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
int0_t *intp = (int0_t *) (CFG_SYS_INTR_BASE);
diff --git a/arch/m68k/cpu/mcf5445x/interrupts.c
b/arch/m68k/cpu/mcf5445x/interrupts.c
index fb80a879c7e..400f3dee879 100644
--- a/arch/m68k/cpu/mcf5445x/interrupts.c
+++ b/arch/m68k/cpu/mcf5445x/interrupts.c
@@ -26,7 +26,7 @@ int interrupt_init(void)
return 0;
}
-#if defined(CFG_MCFTMR)
+#if CONFIG_IS_ENABLED(MCFTMR)
void dtimer_intr_setup(void)
{
int0_t *intp = (int0_t *) (CFG_SYS_INTR_BASE);
diff --git a/arch/m68k/include/asm/immap.h b/arch/m68k/include/asm/immap.h
index
Re: [PATCH] linker_lists.h: Add attribute used to ll_entry_start macro
On Tue, Feb 21, 2023 at 03:33:20PM -0800, Aditya Kumar wrote:
> The variable gets dropped by clang compiler in an optimized builds.
> Adding attribute((used)) allows the symbol to be preserved. Similar
> changes have been proposed in the past e.g.,
> 569524741a01e1a96fc2b75dd7e5d12e41ce6c2b for ll_entry_declare macro.
>
> Signed-off-by: AdityaK
> Reviewed-by: Simon Glass
> ---
> include/linker_lists.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linker_lists.h b/include/linker_lists.h
> index d3da9d44e8..4cd13c3bc8 100644
> --- a/include/linker_lists.h
> +++ b/include/linker_lists.h
> @@ -125,7 +125,7 @@
> #define ll_entry_start(_type, _list) \
> ({ \
> static char start[0] __aligned(CONFIG_LINKER_LIST_ALIGN) \
> - __attribute__((unused)) \
> + __attribute__((unused)) __attribute__((used)) \
> __section("__u_boot_list_2_"#_list"_1"); \
> (_type *) \
> })
So, saying "unused" and then "used" doesn't seem to make any sense. And
given some other problems we see with newer clang, which Simon reports
this patch doesn't fully fix, we probably need to give that area a good
going over to see what attributes do and don't make sense, really.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 14/17] riscv: dts: jh7110: Add initial StarFive JH7110 device tree
On Thu, Mar 16, 2023 at 10:53:29AM +0800, Yanhong Wang wrote:
> Add initial device tree for the JH7110 RISC-V SoC.
>
> Signed-off-by: Yanhong Wang
> Tested-by: Conor Dooley
> + S7_0: cpu@0 {
> + compatible = "sifive,s7", "riscv";
> + reg = <0>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <64>;
> + d-cache-size = <8192>;
> + d-tlb-sets = <1>;
> + d-tlb-size = <40>;
> + device_type = "cpu";
> + i-cache-block-size = <64>;
> + i-cache-sets = <64>;
> + i-cache-size = <16384>;
> + i-tlb-sets = <1>;
> + i-tlb-size = <40>;
> + mmu-type = "riscv,sv39";
Copy-pasting from my identical post on linux-riscv:
Jess pointed out on IRC that this S7 entry looks wrong as it is claiming
that the S7 has an mmu. I didn't go looking back in the history of
u74-mc core complex manuals, but the latest version does not show an mmu
for the S7.
Cheers,
Conor.
> + next-level-cache = <>;
> + riscv,isa = "rv64imac_zba_zbb";
> + tlb-split;
> + status = "disabled";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> + };
signature.asc
Description: PGP signature
Re: [PATCH] imx6sx-udoo-neo-basic: Introduce the u-boot.dtsi
Hi Tom, On Wed, Mar 22, 2023 at 5:12 PM Tom Rini wrote: > Is this for master? If so, OK, we'll pick it up. If not, NAK, these are > all bootph- properties now, and need to go upstream too. Yes, this is for master as it is a regression. Thanks.
Re: [PATCH] imx6sx-udoo-neo-basic: Introduce the u-boot.dtsi
On Wed, Mar 22, 2023 at 04:59:31PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> After the conversion to DM_SERIAL in commit 01f372d8d62b ("udoo_neo:
> Select DM_SERIAL and drop iomux board level init") the SPL log is gone
> and the U-Boot proper log becomes incomplete:
>
> Core: 80 devices, 18 uclasses, devicetree: separate
> MMC: FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:serial@202
> Out: serial@202
> Err: serial@202
> Net: eth0: ethernet@2188000
> Hit any key to stop autoboot: 0
>
> Introduce the u-boot.dtsi file that passes the u-boot,dm-pre-reloc
> properties to the relevant nodes so that UART can be used early in SPL.
>
> With this change, the complete SPL and U-Boot messages are seen again.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi | 17 +
> 1 file changed, 17 insertions(+)
> create mode 100644 arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi
Is this for master? If so, OK, we'll pick it up. If not, NAK, these are
all bootph- properties now, and need to go upstream too.
--
Tom
signature.asc
Description: PGP signature
[PATCH v2 u-boot] cmd: mmc: Return CMD_RET_* from commands
Numeric return values may cause strange errors line:
exit not allowed from main input shell.
Signed-off-by: Pali Rohár
---
Rename r to ret.
---
cmd/mmc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index c79d9407986d..539d3e0bf768 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -175,7 +175,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, int
argc,
curr_device = 0;
else {
puts("No MMC device available\n");
- return 1;
+ return CMD_RET_FAILURE;
}
}
@@ -927,7 +927,7 @@ static int mmc_partconf_print(struct mmc *mmc, const char
*varname)
static int do_mmc_partconf(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
- int dev;
+ int ret, dev;
struct mmc *mmc;
u8 ack, part_num, access;
@@ -953,13 +953,17 @@ static int do_mmc_partconf(struct cmd_tbl *cmdtp, int
flag,
access = dectoul(argv[4], NULL);
/* acknowledge to be sent during boot operation */
- return mmc_set_part_conf(mmc, ack, part_num, access);
+ ret = mmc_set_part_conf(mmc, ack, part_num, access);
+ if (ret != 0)
+ return CMD_RET_FAILURE;
+
+ return CMD_RET_SUCCESS;
}
static int do_mmc_rst_func(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
- int dev;
+ int ret, dev;
struct mmc *mmc;
u8 enable;
@@ -988,7 +992,11 @@ static int do_mmc_rst_func(struct cmd_tbl *cmdtp, int flag,
return CMD_RET_FAILURE;
}
- return mmc_set_rst_n_function(mmc, enable);
+ ret = mmc_set_rst_n_function(mmc, enable);
+ if (ret != 0)
+ return CMD_RET_FAILURE;
+
+ return CMD_RET_SUCCESS;
}
#endif
static int do_mmc_setdsr(struct cmd_tbl *cmdtp, int flag,
--
2.20.1
[PATCH] imx6sx-udoo-neo-basic: Introduce the u-boot.dtsi
From: Fabio Estevam
After the conversion to DM_SERIAL in commit 01f372d8d62b ("udoo_neo:
Select DM_SERIAL and drop iomux board level init") the SPL log is gone
and the U-Boot proper log becomes incomplete:
Core: 80 devices, 18 uclasses, devicetree: separate
MMC: FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial@202
Out: serial@202
Err: serial@202
Net: eth0: ethernet@2188000
Hit any key to stop autoboot: 0
Introduce the u-boot.dtsi file that passes the u-boot,dm-pre-reloc
properties to the relevant nodes so that UART can be used early in SPL.
With this change, the complete SPL and U-Boot messages are seen again.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi | 17 +
1 file changed, 17 insertions(+)
create mode 100644 arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi
diff --git a/arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi
b/arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi
new file mode 100644
index ..cb9e83fde6b7
--- /dev/null
+++ b/arch/arm/dts/imx6sx-udoo-neo-basic-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_uart1 {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.34.1
[PATCH 1/2] Dockerfile: Populate a pip cache
Given the number of jobs in CI we have which use python and pip install packages, we should do this once in the Dockerfile, in order to populate the cache. We let each job continue to create and use the virtual environments they need to facilitate making updates to these environments easier. Signed-off-by: Tom Rini --- tools/docker/Dockerfile | 13 + 1 file changed, 13 insertions(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index bd02531be249..27205002005c 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -265,6 +265,19 @@ RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot RUN useradd -m -U uboot USER uboot:uboot +# Populate the cache for pip to use +RUN wget -O /tmp/pytest-requirements.txt https://source.denx.de/u-boot/u-boot/-/raw/master/test/py/requirements.txt +RUN wget -O /tmp/sphinx-requirements.txt https://source.denx.de/u-boot/u-boot/-/raw/master/doc/sphinx/requirements.txt +RUN virtualenv -p /usr/bin/python3 /tmp/venv && \ + . /tmp/venv/bin/activate && \ + pip install -r /tmp/pytest-requirements.txt \ + -r /tmp/sphinx-requirements.txt && \ + deactivate && \ + rm -rf /tmp/venv /tmp/pytest-requirements.txt /tmp/sphinx-requirements.txt +#RUN pip download -r /tmp/pytest-requirements.txt \ +# -r /tmp/sphinx-requirements.txt && \ +# rm -f /tmp/pytest-requirements.txt /tmp/sphinx-requirements.txt + # Create the buildman config file RUN /bin/echo -e "[toolchain]\nroot = /usr" > ~/.buildman RUN /bin/echo -e "kernelorg = /opt/gcc-12.2.0-nolibc/*" >> ~/.buildman -- 2.34.1
[PATCH 2/2] CI: Update to have pip cache
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 2 +-
.gitlab-ci.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 5594a67d6b52..71b6ba4bcf01 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -2,7 +2,7 @@ variables:
windows_vm: windows-2019
ubuntu_vm: ubuntu-22.04
macos_vm: macOS-12
- ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230308-21Mar2023
+ ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230308-22Mar2023
# Add '-u 0' options for Azure pipelines, otherwise we get "permission
# denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
# since our $(ci_runner_image) user is not root.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5431bf6011a6..dbf80ca676a8 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -10,7 +10,7 @@ default:
# Grab our configured image. The source for this is found
# in the u-boot tree at tools/docker/Dockerfile
-image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20230308-21Mar2023
+image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20230308-22Mar2023
# We run some tests in different order, to catch some failures quicker.
stages:
--
2.34.1
Re: [PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
Hi
On 3/22/23 12:26, haibo.c...@nxp.com wrote:
From: Haibo Chen
dm_gpio_set_dir_flags() will clear GPIOD_MASK_DIR and set new flags.
But there are cases like i2c_deblock_gpio_loop() will do like this:
-first conifg GPIO(SDA) output with GPIOD_ACTIVE_LOW
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW |
GPIOD_IS_OUT_ACTIVE);
-then config GPIO input
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
-then get the GPIO input value:
dm_gpio_get_value(pin);
When config the GPIO input, only set GPIOD_IS_IN, but unfortunately
since the previous GPIOD_ACTIVE_LOW is not cleared, still keep in
flags, make the value from dm_gpio_get_value() not logic correct.
So add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR to avoid this issue.
Signed-off-by: Haibo Chen
---
include/asm-generic/gpio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index dd0bdf2315..903b237aac 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -131,7 +131,7 @@ struct gpio_desc {
/* Flags for updating the above */
#define GPIOD_MASK_DIR(GPIOD_IS_OUT | GPIOD_IS_IN | \
- GPIOD_IS_OUT_ACTIVE)
+GPIOD_IS_OUT_ACTIVE | GPIOD_ACTIVE_LOW)
#define GPIOD_MASK_DSTYPE (GPIOD_OPEN_DRAIN | GPIOD_OPEN_SOURCE)
#define GPIOD_MASK_PULL (GPIOD_PULL_UP | GPIOD_PULL_DOWN)
I think you are breaking the management of GPIOD_ACTIVE_LOW, provided by
device tree in the GPIO uclass:
because the modified GPIOD_MASK_DIR is used in other location
normally GPIOD_ACTIVE_LOW is saved in desc->flags
it is the "desciptor flags" and must be not cleary by normal API
see gpio_xlate_offs_flags() => gpio_flags_xlate()
For example in gpio_request_tail(), in the line:
/* Keep any direction flags provided by the devicetree */
ret = dm_gpio_set_dir_flags(desc,
flags | (desc->flags& GPIOD_MASK_DIR));
With your patch the descriptor flags is cleared / so DT information is lost.
For me GPIOD_ACTIVE_LOW must be managed carefully to avoid side effect.
and if you inverse the PIN logical in device tree (GPIOD_ACTIVE_LOW) it
is normal to inverse it for INPUT and OUTPUT
it is managed in GPIO U-Class
=> dm_gpio_set_dir_flagsshould not cleared this flag GPIOD_ACTIVE_LOW
you can change the caller ?
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit) { if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN); else dm_gpio_set_dir_flags(pin,
GPIOD_IS_OUT | GPIOD_ACTIVE_LOW | GPIOD_IS_OUT_ACTIVE); }
=>
static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit)
{
if (bit)
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
else
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT);
}
The output value is the same => GPIOD_ACTIVE_LOW and GPIOD_IS_OUT_ACTIVE
not active
but you don't need to modify GPIOD_ACTIVE_LOW outside the GPIO uclass.
Patrick
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote: > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote: > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe wrote: > > > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > > >> > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > >> > > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > >> > > > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár > > >> > > > > > wrote: > > >> > > > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as > > >> > > possible)? > > >> > > > > > > > > >> > > > > > > > >> > > > > > In SPL mmc->part_config is 255 > > >> > > > > > In main u-boot at the start of clearfog.c board_init() > > >> > > mmc->part_config > > >> > > > > is > > >> > > > > > 255 > > >> > > > > > In main u-boot at the start of clearfog.c checkboard() > > >> > > mmc->part_config > > >> > > > > is > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > >> > > > > > > >> > > > > 255 is uninitialized value. > > >> > > > > > > >> > > > > > If I set partition_enable to 2, I get the same result except > > >> > > > > > the > > >> > > value is > > >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for > > >> > > > > > the > > >> > > last > > >> > > > > value > > >> > > > > > > >> > > > > Try to change "access" bits. > > >> > > > > > > >> > > > > > > > >> > > > > > BootROM - 1.73 > > >> > > > > > > > >> > > > > > Booting from MMC > > >> > > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > >> > > 10:05:32 > > >> > > > > > +1000) > > >> > > > > > High speed PHY - Version: 2.0 > > >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog > > >> > > > > > Pro. > > >> > > > > > Detected Device ID 6828 > > >> > > > > > board SerDes lanes topology details: > > >> > > > > > | Lane # | Speed | Type | > > >> > > > > > > > >> > > > > > | 0| 3 | SATA0 | > > >> > > > > > | 1| 0 | SGMII1 | > > >> > > > > > | 2| 5 | PCIe1 | > > >> > > > > > | 3| 5 | USB3 HOST1 | > > >> > > > > > | 4| 5 | PCIe2 | > > >> > > > > > | 5| 0 | SGMII2 | > > >> > > > > > > > >> > > > > > High speed PHY - Ended Successfully > > >> > > > > > mv_ddr: 14.0.0 > > >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath > > >> > > > > > Window > > >> > > > > > mv_ddr: completed successfully > > >> > > > > > spl.c spl_boot_device part_config = 255 > > >> > > > > > Trying to boot from MMC1 > > >> > > > > > > > >> > > > > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > >> > > > > > 10:05:32 > > >> > > +1000) > > >> > > > > > > > >> > > > > > SoC: MV88F6828-A0 at 1600 MHz > > >> > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > >> > > > > > clearfog.c board_init part_config = 255 > > >> > > > > > Core: 38 devices, 22 uclasses, devicetree: separate > > >> > > > > > MMC: mv_sdh: 0 > > >> > > > > > Loading Environment from MMC... *** Warning - bad CRC, using > > >> > > > > > default > > >> > > > > > environment > > >> > > > > > > > >> > > > > > Model: SolidRun Clearfog A1 > > >> > > > > > clearfog.c checkboard part_config = 8 > > >> > > > > > Board: SolidRun Clearfog Pro > > >> > > > > > Net: > > >> > > > > > Warning: ethernet@7 (eth1) using random MAC address - > > >> > > > > 32:16:0e:b4:d1:d8 > > >> > > > > > eth1: ethernet@7 > > >> > > > > > Warning: ethernet@3 (eth2) using random MAC address - > > >> > > > > 72:30:3f:79:07:12 > > >> > > > > > , eth2: ethernet@3 > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > >> > > > > 82:fb:71:23:46:4f > > >> > > > > > , eth3: ethernet@34000 > > >> > > > > > Hit any key to stop autoboot: 0 > > >> > > > > > => mmc partconf 0 > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG: > > >> > > > > > BOOT_ACK: 0x0 > > >> > > > > > BOOT_PARTITION_ENABLE: 0x1 > > >> > > > > > PARTITION_ACCESS: 0x0 > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > BootROM - 1.73 > > >> > > > > > > > >> > > > > > Booting from MMC > > >> > > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > >> > > 10:05:32 > > >> > > > > > +1000) > > >> > > > > > High speed PHY - Version: 2.0 > > >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog > > >> > > > > > Pro. > > >> > > > > > Detected Device ID 6828 > > >> > > > > > board SerDes lanes topology details: > > >> > > > > > | Lane # | Speed | Type | > > >> > > > > > > > >> > > > > > | 0| 3 | SATA0 | > > >> > > > > > |
[PATCH v2 1/2] lmb: Fix LMB_MEMORY_REGIONS flag usage
Remove test on CONFIG_LMB_MEMORY_REGIONS introduced by commit
7c1860fce4e3 ("lmb: Fix lmb property's defination under struct lmb").
This code in lmb_init() is strange, because if CONFIG_LMB_USE_MAX_REGIONS
and CONFIG_LMB_MEMORY_REGIONS are not defined, the implicit #else is empty
and the required initialization is not done:
lmb->memory.max = ?
lmb->reserved.max = ?
But this setting is not possible:
- CONFIG_LMB_USE_MAX_REGIONS not defined
- CONFIG_LMB_MEMORY_REGIONS not defined
because CONFIG_LMB_MEMORY_REGIONS and CONFIG_LMB_RESERVED_REGIONS are
defined as soon as the CONFIG_LMB_USE_MAX_REGIONS is not defined.
This patch removes this impossible case #elif and I add some
explanation in lmb.h to explain why in the struct lmb {} the lmb
property is defined if CONFIG_LMB_MEMORY_REGIONS is NOT defined.
This patch also removes CONFIG_LMB_XXX dependency on CONFIG_LMB as these
defines are used in API file lmb.h and not only in library file.
Fixes: 5e2548c1d6e03 ("lmb: Fix LMB_MEMORY_REGIONS flag usage")
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- Remove CONFIG_LMB_XXX dependency on CONFIG_LMB as these defines are
used in lmb.h file, include by default to export the LMB API
and not only in LMB libary code. This modification is required to
avoid issue in API definition when CONFIG_LMB is not set.
- Fix some typo in commit message and in comment
include/lmb.h | 20 +++-
lib/Kconfig | 7 +++
lib/lmb.c | 2 +-
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 7298c2ccc403..07bf22144eac 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -35,6 +35,24 @@ struct lmb_property {
enum lmb_flags flags;
};
+/*
+ * For regions size management, see LMB configuration in KConfig
+ * all the #if test are done with CONFIG_LMB_USE_MAX_REGIONS (boolean)
+ *
+ * case 1. CONFIG_LMB_USE_MAX_REGIONS is defined (legacy mode)
+ * => CONFIG_LMB_MAX_REGIONS is used to configure the region size,
+ * directly in the array lmb_region.region[], with the same
+ * configuration for memory and reserved regions.
+ *
+ * case 2. CONFIG_LMB_USE_MAX_REGIONS is not defined, the size of each
+ * region is configurated *independently* with
+ * => CONFIG_LMB_MEMORY_REGIONS: struct lmb.memory_regions
+ * => CONFIG_LMB_RESERVED_REGIONS: struct lmb.reserved_regions
+ * lmb_region.region is only a pointer to the correct buffer,
+ * initialized in lmb_init(). This configuration is useful to manage
+ * more reserved memory regions with CONFIG_LMB_RESERVED_REGIONS.
+ */
+
/**
* struct lmb_region - Description of a set of region.
*
@@ -68,7 +86,7 @@ struct lmb_region {
struct lmb {
struct lmb_region memory;
struct lmb_region reserved;
-#ifdef CONFIG_LMB_MEMORY_REGIONS
+#if !IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
struct lmb_property memory_regions[CONFIG_LMB_MEMORY_REGIONS];
struct lmb_property reserved_regions[CONFIG_LMB_RESERVED_REGIONS];
#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 83e5edd73b0e..da6c7cd5f628 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -1027,7 +1027,6 @@ config LMB
config LMB_USE_MAX_REGIONS
bool "Use a common number of memory and reserved regions in lmb lib"
- depends on LMB
default y
help
Define the number of supported memory regions in the library logical
@@ -1037,7 +1036,7 @@ config LMB_USE_MAX_REGIONS
config LMB_MAX_REGIONS
int "Number of memory and reserved regions in lmb lib"
- depends on LMB && LMB_USE_MAX_REGIONS
+ depends on LMB_USE_MAX_REGIONS
default 16
help
Define the number of supported regions, memory and reserved, in the
@@ -1045,7 +1044,7 @@ config LMB_MAX_REGIONS
config LMB_MEMORY_REGIONS
int "Number of memory regions in lmb lib"
- depends on LMB && !LMB_USE_MAX_REGIONS
+ depends on !LMB_USE_MAX_REGIONS
default 8
help
Define the number of supported memory regions in the library logical
@@ -1054,7 +1053,7 @@ config LMB_MEMORY_REGIONS
config LMB_RESERVED_REGIONS
int "Number of reserved regions in lmb lib"
- depends on LMB && !LMB_USE_MAX_REGIONS
+ depends on !LMB_USE_MAX_REGIONS
default 8
help
Define the number of supported reserved regions in the library logical
diff --git a/lib/lmb.c b/lib/lmb.c
index 2444b2a62121..8fbe453dfa9d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -110,7 +110,7 @@ void lmb_init(struct lmb *lmb)
#if IS_ENABLED(CONFIG_LMB_USE_MAX_REGIONS)
lmb->memory.max = CONFIG_LMB_MAX_REGIONS;
lmb->reserved.max = CONFIG_LMB_MAX_REGIONS;
-#elif defined(CONFIG_LMB_MEMORY_REGIONS)
+#else
lmb->memory.max = CONFIG_LMB_MEMORY_REGIONS;
lmb->reserved.max = CONFIG_LMB_RESERVED_REGIONS;
lmb->memory.region = lmb->memory_regions;
--
2.25.1
[PATCH v2 2/2] lmb: add max number of region in lmb_dump_region() output
Add the max number of region in lmb dump; this patch allows to
check the limit for usage of the LMB regions, memory or reserved.
Result on STM32MP157C-DK2:
STM32MP> bdinfo
.
lmb_dump_all:
memory.cnt = 0x1 / max = 0x2
memory[0] [0xc000-0xdfff], 0x2000 bytes flags: 0
reserved.cnt = 0x6 / max = 0x10
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xd400-0xd7ff], 0x0400 bytes flags: 4
reserved[4][0xdcae5000-0xdfff], 0x0351b000 bytes flags: 0
reserved[5][0xddafb5b8-0xdfff], 0x02504a48 bytes flags: 0
Reported-by: Mark Millard
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
lib/lmb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index 8fbe453dfa9d..b2c233edb64e 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -27,7 +27,7 @@ static void lmb_dump_region(struct lmb_region *rgn, char
*name)
enum lmb_flags flags;
int i;
- printf(" %s.cnt = 0x%lx\n", name, rgn->cnt);
+ printf(" %s.cnt = 0x%lx / max = 0x%lx\n", name, rgn->cnt, rgn->max);
for (i = 0; i < rgn->cnt; i++) {
base = rgn->region[i].base;
--
2.25.1
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár > > wrote: > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which > > specifies > > > > boot > > > > > > > mode > > > > > > > > > > source. > > > > > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still > > configured > > > > into > > > > > > > UART > > > > > > > > > > > > booting mode via HW switches and if it still works > > > > correctly? > > > > > > > First > > > > > > > > > > > > patch is reverting UART related commit for Clearfog > > which I > > > > > > > think it > > > > > > > > > > not > > > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef > > before > > > > the > > > > > > > switch > > > > > > > > > > that > > > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > > processed. It > > > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > > probably > > > > > > > because > > > > > > > > > > of > > > > > > > > > > > the invalid boot workaround for broken UART selection > > that > > > > you > > > > > > > > > > identified. > > > > > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or > > if I > > > > select > > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work > > with > > > > the MMC > > > > > > > or > > > > > > > > > > SATA > > > > > > > > > > > defconfigs. I get the same result without this patch > > series > > > > > > > applied, > > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > > header > > > > > > > patching > > > > > > > > > > > output) until after sending boot image data is complete. > > The > > > > > > > output stops > > > > > > > > > > > after: > > > > > > > > > > > > > > > > > > > > > > 98 % > > > > > > > > > [. > > > > > > > > > > > ] > > > > > > > > > > > Done > > > > > > > > > > > Finishing transfer > > > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very strange because > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > > > > just > > > > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was > > booted, it > > > > > > > correctly > > > > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > > > > sending > > > > > > > main > > > > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and > > main > > > > > > > u-boot > > > > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I > > was > > > > sure > > > > > > > was > > > > > > > > > > > working after the last patches but I can no longer > > reproduce > > > > a > > > > > > > successful > > > > > > > > > > > boot. > > > > > > > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot > > from > > > > > > > version > > > > > > > > > > with applying _all_ my patches recently sent to ML? Because > > > > both > > > > > > > mkimage > > > > > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those > > changes in > > > > it. > > > > > > > Steps: > > > > > > > > > - Set UART boot mode on device > > > > > > > > > - make clean > > > > > > > > > - make clearfog_defconfig > > > > > > > > > - make > > > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > > > > > For me it looks like that either mkimage generated incorrect > > > > image size > > > > > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that > > > > image size > > > > > > > > > > from kwbimage header and sent smaller image. > > >
Re: [PATCH] console: Use flush() before panic and reset
On Tue, Mar 14, 2023 at 05:24:26PM -0700, Tony Dinh wrote: > To make sure the panic and the reset messages will go out, console flush() > should be used. > Sleep periods do not work in early u-boot phase when timer driver is not > initialized yet. > > Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html > > Signed-off-by: Tony Dinh > Reviewed-by: Simon Glass > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: total_compute: Remap console logs
On Mon, Mar 13, 2023 at 02:27:15PM +0530, Annam Sai Manisha wrote: > From: annsai01 > > Remapping console logs from soc uart2 (s1 terminal) > to css non-secure (uart_ap terminal) > > Change-Id: I554f3ab6eb8439c54f5568c47e48f1543ac67b44 > Signed-off-by: Annam Sai Manisha Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] gitattributes: Treat .bin files as binary.
On Fri, Mar 10, 2023 at 02:52:30PM +0100, Sebastian Andrzej Siewior wrote: > Binary files, which are committed to a private fork of this repository, > will be subject to line feed substitution unless marked as binary. > > Mark .bin files as binary. > > Signed-off-by: Sebastian Andrzej Siewior Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: ext4: check the minimal partition size to mount
On Wed, Mar 08, 2023 at 09:49:54AM +0100, Patrick Delaunay wrote: > No need to mount a too small partition to handle a EXT4 file system. > > This patch add a test on partition size before to read the > SUPERBLOCK_SIZE buffer and avoid error latter in fs_devread() function. > > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] README.mpc85xx-sd-spi-boot: Suggest the NXP boot format github repo
On Thu, Jan 12, 2023 at 10:04:46PM -0300, Fabio Estevam wrote: > As explained in the text at the bottom of the page > https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/boot-format: > > "QUIC repositories on this site will not receive any updates after > March 31, 2022, and will be deleted on March 31, 2023." > > Point to the NXP boot format github repo instead. > > Signed-off-by: Fabio Estevam > Reviewed-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] configs: am62x_evm_a53_defconfig: Fix SF_DEFAULT_MODE
On Sat, Mar 11, 2023 at 09:24:23PM +0530, Nikhil M Jain wrote:
> Setting sf default mode to 0x3 breaks sf update when we do SF read
> through u-boot console.
>
> This issue arises when we do a splash image through OSPI flash media,
> to fix this set the default mode to 0x0.
>
> Fixes: 04150400c967 ("configs: enable OSPI related configs in AM62x")
> Signed-off-by: Nikhil M Jain
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] dma: ti: k3-udma: Fix channel hang on teardown
On Wed, Mar 08, 2023 at 09:42:57AM +0530, Vignesh Raghavendra wrote:
> Setting RX flow error handling will stall the channel until descriptors
> are available to move RX data. Setting this bit causes issues when
> tearing down ethernet DMA channel at the end of TFTP transfer as
> unrelated network packets can cause teardown to stall indefinitely waiting
> for driver to queue add more desc leading to channel hang with error
> logs:
> udma_stop_dev2mem TIMEOUT !
> udma_stop_dev2mem: peer not stopped TIMEOUT !
> udma_stop_dev2mem TIMEOUT !
>
> Fix this by clearing rx_error_handling similar to how its done for UDMA
> as part of udma_alloc_rchan_sci_req()
>
> This fixes occasional TFTP Failures seen when downloading multiple files
> one after the other on AM64/AM62 SoCs.
>
> Fixes: 9a92851c33e8 ("dma: ti: k3-udma: Add BCDMA and PKTDMA support")
> Reported-by: Nishanth Menon
> Signed-off-by: Vignesh Raghavendra
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/2] configs: am62: move stack and heap to HSM RAM
On Thu, Mar 02, 2023 at 07:40:47PM +0530, kaml...@ti.com wrote: > From: Kamlesh Gurudasani > > On high security devices, ROM enables firewalls to protect the OCSRAM > region access during bootup. Only after TIFS has started (and had > time to disable the OCSRAM firewall region) will we have write access to > the region. > > This means we will need to move the stack & heap from OCSRAM to HSM RAM > and reduce the size of BSS and the SPL to allow it to fit properly. > > To protect us from overflowing our ~256k of HSM SRAM, add limits and > check during the wakeup SPL build. > > Signed-off-by: Kamlesh Gurudasani Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] arm: mach-k3: am62: move scratch board area to HSM RAM
On Thu, Mar 02, 2023 at 07:40:46PM +0530, kaml...@ti.com wrote: > From: Kamlesh Gurudasani > > On high security devices, ROM enables firewalls to protect the OCSRAM > region access during bootup. Only after TIFS has started (and had > time to disable the OCSRAM firewall region) will we have write access to > the region. > > So, move scratch board area to HSM RAM. > > Signed-off-by: Kamlesh Gurudasani Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote: > On Wed, 22 Mar 2023 at 12:38, Martin Rowe wrote: > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > >> > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > >> > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > >> > > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > >> > > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as > >> > > possible)? > >> > > > > > > > >> > > > > > > >> > > > > > In SPL mmc->part_config is 255 > >> > > > > > In main u-boot at the start of clearfog.c board_init() > >> > > mmc->part_config > >> > > > > is > >> > > > > > 255 > >> > > > > > In main u-boot at the start of clearfog.c checkboard() > >> > > mmc->part_config > >> > > > > is > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > >> > > > > > >> > > > > 255 is uninitialized value. > >> > > > > > >> > > > > > If I set partition_enable to 2, I get the same result except the > >> > > value is > >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > >> > > last > >> > > > > value > >> > > > > > >> > > > > Try to change "access" bits. > >> > > > > > >> > > > > > > >> > > > > > BootROM - 1.73 > >> > > > > > > >> > > > > > Booting from MMC > >> > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > >> > > 10:05:32 > >> > > > > > +1000) > >> > > > > > High speed PHY - Version: 2.0 > >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog > >> > > > > > Pro. > >> > > > > > Detected Device ID 6828 > >> > > > > > board SerDes lanes topology details: > >> > > > > > | Lane # | Speed | Type | > >> > > > > > > >> > > > > > | 0| 3 | SATA0 | > >> > > > > > | 1| 0 | SGMII1 | > >> > > > > > | 2| 5 | PCIe1 | > >> > > > > > | 3| 5 | USB3 HOST1 | > >> > > > > > | 4| 5 | PCIe2 | > >> > > > > > | 5| 0 | SGMII2 | > >> > > > > > > >> > > > > > High speed PHY - Ended Successfully > >> > > > > > mv_ddr: 14.0.0 > >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > >> > > > > > mv_ddr: completed successfully > >> > > > > > spl.c spl_boot_device part_config = 255 > >> > > > > > Trying to boot from MMC1 > >> > > > > > > >> > > > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > >> > > > > > 10:05:32 > >> > > +1000) > >> > > > > > > >> > > > > > SoC: MV88F6828-A0 at 1600 MHz > >> > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > >> > > > > > clearfog.c board_init part_config = 255 > >> > > > > > Core: 38 devices, 22 uclasses, devicetree: separate > >> > > > > > MMC: mv_sdh: 0 > >> > > > > > Loading Environment from MMC... *** Warning - bad CRC, using > >> > > > > > default > >> > > > > > environment > >> > > > > > > >> > > > > > Model: SolidRun Clearfog A1 > >> > > > > > clearfog.c checkboard part_config = 8 > >> > > > > > Board: SolidRun Clearfog Pro > >> > > > > > Net: > >> > > > > > Warning: ethernet@7 (eth1) using random MAC address - > >> > > > > 32:16:0e:b4:d1:d8 > >> > > > > > eth1: ethernet@7 > >> > > > > > Warning: ethernet@3 (eth2) using random MAC address - > >> > > > > 72:30:3f:79:07:12 > >> > > > > > , eth2: ethernet@3 > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > >> > > > > 82:fb:71:23:46:4f > >> > > > > > , eth3: ethernet@34000 > >> > > > > > Hit any key to stop autoboot: 0 > >> > > > > > => mmc partconf 0 > >> > > > > > EXT_CSD[179], PARTITION_CONFIG: > >> > > > > > BOOT_ACK: 0x0 > >> > > > > > BOOT_PARTITION_ENABLE: 0x1 > >> > > > > > PARTITION_ACCESS: 0x0 > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > BootROM - 1.73 > >> > > > > > > >> > > > > > Booting from MMC > >> > > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > >> > > 10:05:32 > >> > > > > > +1000) > >> > > > > > High speed PHY - Version: 2.0 > >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog > >> > > > > > Pro. > >> > > > > > Detected Device ID 6828 > >> > > > > > board SerDes lanes topology details: > >> > > > > > | Lane # | Speed | Type | > >> > > > > > > >> > > > > > | 0| 3 | SATA0 | > >> > > > > > | 1| 0 | SGMII1 | > >> > > > > > | 2| 5 | PCIe1 | > >> > > > > > | 3| 5 | USB3 HOST1 | > >> > > > > > | 4| 5 | PCIe2 | > >> > > > > > | 5| 0 | SGMII2 | > >> > > > > > > >> > > > > > High speed PHY - Ended Successfully > >> > > > > > mv_ddr: 14.0.0 > >> > >
Re: [PATCH] pci: Handle failed calloc in decode_regions()
Hi
>
> Hi,
>
> On Tue, Mar 21, 2023 at 08:57:18AM +0100, Christian Gmeiner wrote:
> > Am So., 4. Dez. 2022 um 22:22 Uhr schrieb Pierre-Clément Tosi
> > :
> > >
> > > Hi,
> > >
> > > On Fri, Dec 02, 2022 at 08:38:37PM +0100, s...@geanix.com wrote:
> > > >
> > > > Quoting Pierre-Clément Tosi :
> > > >
> > > > > Add a check for calloc() failing to allocate the requested memory.
> > > > >
> > > > > Make decode_regions() return an error code.
> > > > >
> > > > > Cc: Bin Meng
> > > > > Cc: Simon Glass
> > > > > Cc: Stefan Roese
> > > > > Signed-off-by: Pierre-Clément Tosi
> > > > > ---
> > > >
> > > > Hi,
> > > >
> > > > We upgraded from v2022.04 -> v2022.10, and this PATCH breaks PCI
> > > > (scsi/sata)
> > > > support for x86_64.
> > > > I have seen this in qemu, i havn't had the time to test this on real
> > > > hardware.
> > > >
> > > > Steps to reproduce:
> > > > $ make efi-x86_payload64_defconfig && make -j32 && scripts/build-efi.sh
> > > > -sPrp
> > >
> >
> > Breaks my use case too and is basically a revert of
> > https://source.denx.de/u-boot/u-boot/-/commit/f2825f6ec0bb50e7bd9376828a32212f1961f979
> > In my use case we are using coreboot for different Intel SoCs with a
> > generic U-Boot payload.
> >
> > > Decompiling the resulting u-boot.dtb shows
> > >
> > > pci {
> > > compatible = "pci-x86";
> > > u-boot,dm-pre-reloc;
> > > };
> > >
> >
> > Yes.. that is what can be found here:
> > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/x86/dts/coreboot.dts#L34
> >
> >
> > > which isn't supported by the patch as we return -EINVAL when missing
> > > "ranges".
> > > The rationale here was that the property seemed mandatory (see [1] and
> > > [2]); was
> > > this a misunderstanding of potential corner cases?
> > >
> >
> > At the moment I would like to revert this change.
> >
>
> Thanks for sharing such a corner case.
>
> IMO, normal operation shouldn't rely on errors being silently skipped because
> return values are being blindly ignored. Instead, we could limit EINVAL to
> libfdt errors that aren't FDT_ERR_NOTFOUND, which would address your use-case,
> where "ranges" is missing from the DT node.
>
> Is your issue fixed by this patch:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20230220194927.476708-8-...@chromium.org/
>
Yes .. the regression is fixed with this patch \o/
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
Re: [PATCH 07/13] pci: coreboot: Don't read regions when booting
> > When U-Boot is the second-stage bootloader, PCI is already set up. We > > cannot read the regions from the device tree. There is no point anyway, > > since PCI devices have already been allocated according to the regions > > and it is not safe for U-Boot to make any changes. > > > > Signed-off-by: Simon Glass > > --- > > > > drivers/pci/pci-uclass.c | 4 > > 1 file changed, 4 insertions(+) > > > Tested-by: Christian Gmeiner -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
[PATCH] ARM: imx: imx8mp: fix enable_i2c_clk
In order for i2c_num==4 and 5 to stay invalid for non-imx8mp SOCs, the
i2c_ccgr[] array must be sized by the number of initializers present,
not with a hard-coded 6 which would implicitly initialize the last two
elements with zeroes.
Also, the bounds check is off-by-one.
Fixes: c92c3a4453b8 "ARM: imx: imx8mp: Enable support for i2c5 and i2c6 on
i.MX8MP"
Signed-off-by: Rasmus Villemoes
---
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 1f69047988..b0361944b4 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -36,14 +36,14 @@ void enable_ocotp_clk(unsigned char enable)
int enable_i2c_clk(unsigned char enable, unsigned i2c_num)
{
- u8 i2c_ccgr[6] = {
+ u8 i2c_ccgr[] = {
CCGR_I2C1, CCGR_I2C2, CCGR_I2C3, CCGR_I2C4,
#if (IS_ENABLED(CONFIG_IMX8MP))
CCGR_I2C5_8MP, CCGR_I2C6_8MP
#endif
};
- if (i2c_num > ARRAY_SIZE(i2c_ccgr))
+ if (i2c_num >= ARRAY_SIZE(i2c_ccgr))
return -EINVAL;
clock_enable(i2c_ccgr[i2c_num], !!enable);
--
2.37.2
Re: [PATCH 2/2] Dockerfile: Update to latest "Jammy" tag
On Tue, Mar 21, 2023 at 03:31:43PM -0400, Tom Rini wrote: > Update to using the latest "Jammy" tag as our base. > > Signed-off-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Dockerfile: Add m68k-softmmu to qemu
On Tue, Mar 21, 2023 at 03:31:42PM -0400, Tom Rini wrote: > Given efforts to add an m68k target to CI, build qemu for it. > > Signed-off-by: Tom Rini > Reviewed-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] CI: Allow a mirror to be specified for Docker Hub
On Fri, Mar 10, 2023 at 09:53:03AM +, Peter Hoyes wrote: > From: Peter Hoyes > > To conserve bandwidth and potentially avoid rate limits, allow a local > mirror of Docker Hub to be specified globally. The default value is > unchanged. > > Signed-off-by: Peter Hoyes > Reviewed-by: Simon Glass > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] CI: Allow job tag to be optionally set globally
On Fri, Mar 10, 2023 at 09:53:02AM +, Peter Hoyes wrote: > From: Peter Hoyes > > The default behavior of Gitlab runners is to only run jobs which match > the configured tag, although there is an option to run untagged jobs > [1]. > > To support running the CI in more complex environments where different > types of runners may be present that support different tags, allow the > DEFAULT_TAG for all jobs in the pipeline to be set globally using an > environment variable. An empty default value is provided to retain > support for untagged runners. > > [1] > https://docs.gitlab.com/ee/ci/runners/configure_runners.html#use-tags-to-control-which-jobs-a-runner-can-run > > Signed-off-by: Peter Hoyes > Reviewed-by: Simon Glass > Reviewed-by: Tom Rini Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] CI: gitlab: Collect pytest artifacts
On Fri, Mar 03, 2023 at 02:22:25AM +0100, Marek Vasut wrote: > Copy build artifacts for all test.py tests, so they show up in > artifacts storage for later inspection. The test.py tests output > in CI is basically useless, but it is far more useful in the html > output for analysis and debugging. > > Reviewed-by: Simon Glass > Reviewed-by: Tom Rini > Suggested-by: Simon Glass > Signed-off-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] Azure CI: Be explicit about pytest cache directory
On Tue, Feb 28, 2023 at 03:28:49PM -0500, Tom Rini wrote: > The default pytest cache directory is in a read-only directory in Azure, > which results in a warning on the build page. Use the pytest command > line option to set the cache dir to somewhere writable. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] Azure CI: Save pytest output automatically
On Tue, Feb 28, 2023 at 03:28:48PM -0500, Tom Rini wrote: > Enable use of the python-azurepipelines package which provides automatic > formatting and uploading of the pytest output. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/33] doc: board: amlogic: spring clean-up of Amlogic docs
Hi, On Mon, 20 Mar 2023 11:45:36 +, Christian Hewitt wrote: > Amlogic documentation spans U-Boot support from 2015-current resulting > in older content being harder to follow. And due to many international > contributors the docs also contain grammar quirks. > > This series reworks all board documents to be more consistent. There is > deliberate emphasis on using the amlogic-boot-fip repo for signing tasks > as this is easier for most users to follow. The original/longer signing > process (described as Manual Signing) has been tidied up. > > [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-amlogic (u-boot-amlogic-test) [01/33] doc: boards: amlogic: update documentation for index page https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/862b7c1fcc5e94c7d91cc9caf22c7b6205b7fffd [02/33] doc: boards: amlogic: update documentation for boot-flow https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/4ce746b8cf07ed4c532a36fda587104d667bf54a [03/33] doc: boards: amlogic: update documentation for pre-generated-fip's https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/3d1744b392ae57adfa1c068acb9f94a44cc82070 [04/33] doc: boards: amlogic: update documentation for Beelink GT-King https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/d0d4a85d14b18dda87ef0111a03644a9886aebd4 [05/33] doc: boards: amlogic: update documentation for Beelink GT-King Pro https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/c03d19d5dc0e20dde9c4b34feb0f47c59a82a640 [06/33] doc: boards: amlogic: update documentation for JetHub J100 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/cf43c9f7d3c7b4b83a94a9ff961b0807f4f92c47 [07/33] doc: boards: amlogic: update documentation for JetHub J80 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/47ab069e9a9dd047dcad3c984d8e6cbcb6e26a04 [08/33] doc: boards: amlogic: update documentation for Khadas VIM https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/329794577adf7e53ba1e0c3a86686e21655965c1 [09/33] doc: boards: amlogic: update documentation for Khadas VIM2 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/e3de21c60685d15fd5746b23a7d72545889580cd [10/33] doc: boards: amlogic: update documentation for Khadas VIM3 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/de54d4cc16b9d4bfdda196dac5bdbd0d8128cd02 [11/33] doc: boards: amlogic: update documentation for Khadas VIM3L https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/3240318b212d46e1e5ea4af92eec6b26b67f5ad4 [12/33] doc: boards: amlogic: update documentation for LaFrite https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/cb197ca63debc82d23a8ca419623278839b6ff48 [13/33] doc: boards: amlogic: update documentation for LePotato https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/ba07d965dd5ee74e66c32bc5a3fce5c69ed4b2d2 [14/33] doc: boards: amlogic: update documentation for NanoPi-K2 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/7c7ecc84f1c1edb79e7e2b1e0070b288cf1e22fc [15/33] doc: boards: amlogic: update documentation for ODROID-C2 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/665633ec055d15989e187861ea419518bf517017 [16/33] doc: boards: amlogic: update documentation for ODROID-C4 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/4760b2e8e2e46ad61ab7ed91733786d9a9e4696c [17/33] doc: boards: amlogic: update documentation for ODROID GO ULTRA https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/144ffe96aa1638028593afa2b669bcf08ac0ad38 [18/33] doc: boards: amlogic: update documentation for ODROID-N2/N2+ https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/11a1fc1d305e773f27135adad56cbcc5e1c2bd6a [19/33] doc: boards: amlogic: update documentation for ODROID-N2L https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/6ba5d42c42752829b22f80748972716d5bb27c59 [20/33] doc: boards: amlogic: update documentation for P200 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/f0b8c1f6a54b8ef45972a18e969250d859c9a866 [21/33] doc: boards: amlogic: update documentation for P201 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/db6b333e37c2a98e2bcc09a5545635aaeb2c1301 [22/33] doc: boards: amlogic: update documentation for Q200 https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/3ce3109c3783c27aa18b0a17eb6d8ead23f92d85 [23/33] doc: boards: amlogic: update documentation for Radxa Zero https://source.denx.de/u-boot/custodians/u-boot-amlogic/-/commit/1b23862b4177151b477d740e8760d45978549926 [24/33] doc: boards: amlogic: update documentation for S400
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Wed, 22 Mar 2023 at 12:38, Martin Rowe wrote: > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: >> >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: >> > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: >> > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: >> > > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as >> > > possible)? >> > > > > > > >> > > > > > >> > > > > > In SPL mmc->part_config is 255 >> > > > > > In main u-boot at the start of clearfog.c board_init() >> > > mmc->part_config >> > > > > is >> > > > > > 255 >> > > > > > In main u-boot at the start of clearfog.c checkboard() >> > > mmc->part_config >> > > > > is >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0) >> > > > > >> > > > > 255 is uninitialized value. >> > > > > >> > > > > > If I set partition_enable to 2, I get the same result except the >> > > value is >> > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the >> > > last >> > > > > value >> > > > > >> > > > > Try to change "access" bits. >> > > > > >> > > > > > >> > > > > > BootROM - 1.73 >> > > > > > >> > > > > > Booting from MMC >> > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - >> > > 10:05:32 >> > > > > > +1000) >> > > > > > High speed PHY - Version: 2.0 >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. >> > > > > > Detected Device ID 6828 >> > > > > > board SerDes lanes topology details: >> > > > > > | Lane # | Speed | Type | >> > > > > > >> > > > > > | 0| 3 | SATA0 | >> > > > > > | 1| 0 | SGMII1 | >> > > > > > | 2| 5 | PCIe1 | >> > > > > > | 3| 5 | USB3 HOST1 | >> > > > > > | 4| 5 | PCIe2 | >> > > > > > | 5| 0 | SGMII2 | >> > > > > > >> > > > > > High speed PHY - Ended Successfully >> > > > > > mv_ddr: 14.0.0 >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window >> > > > > > mv_ddr: completed successfully >> > > > > > spl.c spl_boot_device part_config = 255 >> > > > > > Trying to boot from MMC1 >> > > > > > >> > > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 >> > > +1000) >> > > > > > >> > > > > > SoC: MV88F6828-A0 at 1600 MHz >> > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) >> > > > > > clearfog.c board_init part_config = 255 >> > > > > > Core: 38 devices, 22 uclasses, devicetree: separate >> > > > > > MMC: mv_sdh: 0 >> > > > > > Loading Environment from MMC... *** Warning - bad CRC, using >> > > > > > default >> > > > > > environment >> > > > > > >> > > > > > Model: SolidRun Clearfog A1 >> > > > > > clearfog.c checkboard part_config = 8 >> > > > > > Board: SolidRun Clearfog Pro >> > > > > > Net: >> > > > > > Warning: ethernet@7 (eth1) using random MAC address - >> > > > > 32:16:0e:b4:d1:d8 >> > > > > > eth1: ethernet@7 >> > > > > > Warning: ethernet@3 (eth2) using random MAC address - >> > > > > 72:30:3f:79:07:12 >> > > > > > , eth2: ethernet@3 >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address - >> > > > > 82:fb:71:23:46:4f >> > > > > > , eth3: ethernet@34000 >> > > > > > Hit any key to stop autoboot: 0 >> > > > > > => mmc partconf 0 >> > > > > > EXT_CSD[179], PARTITION_CONFIG: >> > > > > > BOOT_ACK: 0x0 >> > > > > > BOOT_PARTITION_ENABLE: 0x1 >> > > > > > PARTITION_ACCESS: 0x0 >> > > > > > >> > > > > > >> > > > > > >> > > > > > BootROM - 1.73 >> > > > > > >> > > > > > Booting from MMC >> > > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - >> > > 10:05:32 >> > > > > > +1000) >> > > > > > High speed PHY - Version: 2.0 >> > > > > > EEPROM TLV detection failed: Using static config for Clearfog Pro. >> > > > > > Detected Device ID 6828 >> > > > > > board SerDes lanes topology details: >> > > > > > | Lane # | Speed | Type | >> > > > > > >> > > > > > | 0| 3 | SATA0 | >> > > > > > | 1| 0 | SGMII1 | >> > > > > > | 2| 5 | PCIe1 | >> > > > > > | 3| 5 | USB3 HOST1 | >> > > > > > | 4| 5 | PCIe2 | >> > > > > > | 5| 0 | SGMII2 | >> > > > > > >> > > > > > High speed PHY - Ended Successfully >> > > > > > mv_ddr: 14.0.0 >> > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window >> > > > > > mv_ddr: completed successfully >> > > > > > spl.c spl_boot_device part_config = 255 >> > > > > > Trying to boot from MMC1 >> > > > > > >> > > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 >> > > +1000) >> > > > > > >> > > >
Re: [GIT PULL] Please pull u-boot-amlogic-20230131
On Wed, Mar 22, 2023 at 11:46:42AM +0100, Neil Armstrong wrote: > > Hi Tom, > > A single change to enable the odroid-go-ultra PMIC regulator at boot. > > The CI job is at > https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/15691 > > Thanks, > Neil > > The following changes since commit 88e08fc5f6e508eac46cd1dfb0379b11ae032c0a: > > Prepare v2023.04-rc4 (2023-03-13 20:52:48 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20230322 > > for you to fetch changes up to de58694f0d5431627d7389f50a6b2034a682ba24: > > ARM: meson: odroid-go-ultra: setup PMIC regulators are board init > (2023-03-14 09:03:16 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: fat: do not mangle short filenames
On Wed, Mar 22, 2023 at 09:51:32AM +0100, Stefan Herbrechtsmeier wrote: > Am 21.03.2023 um 16:54 schrieb Tom Rini: > > On Tue, Mar 21, 2023 at 04:53:22PM +0100, Stefan Herbrechtsmeier wrote: > > > Am 21.03.2023 um 16:35 schrieb Tom Rini: > > > > On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: > > > > > Am 20.03.2023 um 18:01 schrieb Tom Rini: > > > > > > On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier > > > > > > wrote: > > > > > > > > > > > > > From: Stefan Herbrechtsmeier > > > > > > > > > > > > > > > > > > > > > Do not mangle lower or mixed case filenames which fit into the > > > > > > > upper > > > > > > > case 8.3 short filename. This ensures FAT standard compatible > > > > > > > short > > > > > > > filenames (SFN) to support systems without long filename (LFN) > > > > > > > support > > > > > > > like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN > > > > > > > boot.bin). > > > > > > > > > > > > > > Signed-off-by: Stefan Herbrechtsmeier > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > fs/fat/fat_write.c | 11 +++ > > > > > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > Can we update test/py/tests/test_fs/ somewhere to have a test for > > > > > > this > > > > > > case? Thanks. > > > > > What is the recommended approach to test internal behavior? The short > > > > > name > > > > > isn't avialable at the terminal because u-boot support VFAT. > > > > Well, you triggered this problem with a filesystem that had contents > > > > that were "just so" and then didn't work as expected, yes? > > > > > > No, I write a file to a file system and the boot rom do not find the file > > > because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). > > > > > > The mdir command shows the short and long file name. I will add a > > > test_fat.py with a test. > > Ah, ok, and great, thanks! > > > I have send a separate patch `test: fs: Check fat short file name` or should > I send a new series with both patches? A follow-up is fine. -- Tom signature.asc Description: PGP signature
Re: [PATCH] pci: Handle failed calloc in decode_regions()
Hi,
On Tue, Mar 21, 2023 at 08:57:18AM +0100, Christian Gmeiner wrote:
> Am So., 4. Dez. 2022 um 22:22 Uhr schrieb Pierre-Clément Tosi
> :
> >
> > Hi,
> >
> > On Fri, Dec 02, 2022 at 08:38:37PM +0100, s...@geanix.com wrote:
> > >
> > > Quoting Pierre-Clément Tosi :
> > >
> > > > Add a check for calloc() failing to allocate the requested memory.
> > > >
> > > > Make decode_regions() return an error code.
> > > >
> > > > Cc: Bin Meng
> > > > Cc: Simon Glass
> > > > Cc: Stefan Roese
> > > > Signed-off-by: Pierre-Clément Tosi
> > > > ---
> > >
> > > Hi,
> > >
> > > We upgraded from v2022.04 -> v2022.10, and this PATCH breaks PCI
> > > (scsi/sata)
> > > support for x86_64.
> > > I have seen this in qemu, i havn't had the time to test this on real
> > > hardware.
> > >
> > > Steps to reproduce:
> > > $ make efi-x86_payload64_defconfig && make -j32 && scripts/build-efi.sh
> > > -sPrp
> >
>
> Breaks my use case too and is basically a revert of
> https://source.denx.de/u-boot/u-boot/-/commit/f2825f6ec0bb50e7bd9376828a32212f1961f979
> In my use case we are using coreboot for different Intel SoCs with a
> generic U-Boot payload.
>
> > Decompiling the resulting u-boot.dtb shows
> >
> > pci {
> > compatible = "pci-x86";
> > u-boot,dm-pre-reloc;
> > };
> >
>
> Yes.. that is what can be found here:
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/x86/dts/coreboot.dts#L34
>
>
> > which isn't supported by the patch as we return -EINVAL when missing
> > "ranges".
> > The rationale here was that the property seemed mandatory (see [1] and
> > [2]); was
> > this a misunderstanding of potential corner cases?
> >
>
> At the moment I would like to revert this change.
>
Thanks for sharing such a corner case.
IMO, normal operation shouldn't rely on errors being silently skipped because
return values are being blindly ignored. Instead, we could limit EINVAL to
libfdt errors that aren't FDT_ERR_NOTFOUND, which would address your use-case,
where "ranges" is missing from the DT node.
Is your issue fixed by this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230220194927.476708-8-...@chromium.org/
?
> > OTOH, I see that most DTS using "pci-x86" (a pseudo-device intended to act
> > as a
> > PCI bus) actually provide "ranges". In particular, a comment added by
> > 0ced70a0bb7a ("x86: tpl: Add a fake PCI bus") states that
> >
> > The BARs are allocated statically in the device tree.
> >
> > So I'll let others comment on this but either:
> >
> > - arch/x86/dts/efi-x86_payload.dts (and a few other DTS) is missing
> > "ranges"; or
> > - pci_uclass_pre_probe() should treat UCLASS_SIMPLE_BUS differently.
> >
> > [1]:
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> > [2]: IEEE Std 1275-1994
> >
> > >
> > > Br,
> > > /Sean
> > >
> > > > drivers/pci/pci-uclass.c | 15 ++-
> > > > 1 file changed, 10 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> > > > index 970ee1adf1..2c85e78a13 100644
> > > > --- a/drivers/pci/pci-uclass.c
> > > > +++ b/drivers/pci/pci-uclass.c
> > > > @@ -954,7 +954,7 @@ int pci_bind_bus_devices(struct udevice *bus)
> > > > return 0;
> > > > }
> > > >
> > > > -static void decode_regions(struct pci_controller *hose, ofnode
> > > > parent_node,
> > > > +static int decode_regions(struct pci_controller *hose, ofnode
> > > > parent_node,
> > > >ofnode node)
> > > > {
> > > > int pci_addr_cells, addr_cells, size_cells;
> > > > @@ -968,7 +968,7 @@ static void decode_regions(struct pci_controller
> > > > *hose, ofnode parent_node,
> > > > prop = ofnode_get_property(node, "ranges", );
> > > > if (!prop) {
> > > > debug("%s: Cannot decode regions\n", __func__);
> > > > - return;
> > > > + return -EINVAL;
> > > > }
> > > >
> > > > pci_addr_cells = ofnode_read_simple_addr_cells(node);
> > > > @@ -986,6 +986,8 @@ static void decode_regions(struct pci_controller
> > > > *hose, ofnode parent_node,
> > > > max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS;
> > > > hose->regions = (struct pci_region *)
> > > > calloc(1, max_regions * sizeof(struct pci_region));
> > > > + if (!hose->regions)
> > > > + return -ENOMEM;
> > > >
> > > > for (i = 0; i < max_regions; i++, len -= cells_per_record) {
> > > > u64 pci_addr, addr, size;
> > > > @@ -1053,7 +1055,7 @@ static void decode_regions(struct pci_controller
> > > > *hose, ofnode parent_node,
> > > > /* Add a region for our local memory */
> > > > bd = gd->bd;
> > > > if (!bd)
> > > > - return;
> > > > + return 0;
> > > >
> > > > for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
> > > > if (bd->bi_dram[i].size) {
> > > > @@ -1068,7 +1070,7 @@ static void decode_regions(struct pci_controller
> > > > *hose, ofnode
Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
On Tue, 21 Mar 2023 at 08:08, Pali Rohár wrote: > On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 17:33, Pali Rohár wrote: > > > > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote: > > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár wrote: > > > > > > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote: > > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár wrote: > > > > > > > > > > > > > Could you try to print mmc->part_config (ideally as early as > > > possible)? > > > > > > > > > > > > > > > > > > > In SPL mmc->part_config is 255 > > > > > > In main u-boot at the start of clearfog.c board_init() > > > mmc->part_config > > > > > is > > > > > > 255 > > > > > > In main u-boot at the start of clearfog.c checkboard() > > > mmc->part_config > > > > > is > > > > > > 8 (ack: 0, partition_enable: 1, access: 0) > > > > > > > > > > 255 is uninitialized value. > > > > > > > > > > > If I set partition_enable to 2, I get the same result except the > > > value is > > > > > > 16 (ack: 0, partition_enable: 2, access: 0) instead of 8 for the > > > last > > > > > value > > > > > > > > > > Try to change "access" bits. > > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > > > Booting from MMC > > > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > > 10:05:32 > > > > > > +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > > board SerDes lanes topology details: > > > > > > | Lane # | Speed | Type | > > > > > > > > > > > > | 0| 3 | SATA0 | > > > > > > | 1| 0 | SGMII1 | > > > > > > | 2| 5 | PCIe1 | > > > > > > | 3| 5 | USB3 HOST1 | > > > > > > | 4| 5 | PCIe2 | > > > > > > | 5| 0 | SGMII2 | > > > > > > > > > > > > High speed PHY - Ended Successfully > > > > > > mv_ddr: 14.0.0 > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > > > mv_ddr: completed successfully > > > > > > spl.c spl_boot_device part_config = 255 > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > +1000) > > > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > > clearfog.c board_init part_config = 255 > > > > > > Core: 38 devices, 22 uclasses, devicetree: separate > > > > > > MMC: mv_sdh: 0 > > > > > > Loading Environment from MMC... *** Warning - bad CRC, using > default > > > > > > environment > > > > > > > > > > > > Model: SolidRun Clearfog A1 > > > > > > clearfog.c checkboard part_config = 8 > > > > > > Board: SolidRun Clearfog Pro > > > > > > Net: > > > > > > Warning: ethernet@7 (eth1) using random MAC address - > > > > > 32:16:0e:b4:d1:d8 > > > > > > eth1: ethernet@7 > > > > > > Warning: ethernet@3 (eth2) using random MAC address - > > > > > 72:30:3f:79:07:12 > > > > > > , eth2: ethernet@3 > > > > > > Warning: ethernet@34000 (eth3) using random MAC address - > > > > > 82:fb:71:23:46:4f > > > > > > , eth3: ethernet@34000 > > > > > > Hit any key to stop autoboot: 0 > > > > > > => mmc partconf 0 > > > > > > EXT_CSD[179], PARTITION_CONFIG: > > > > > > BOOT_ACK: 0x0 > > > > > > BOOT_PARTITION_ENABLE: 0x1 > > > > > > PARTITION_ACCESS: 0x0 > > > > > > > > > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > > > Booting from MMC > > > > > > > > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > > > 10:05:32 > > > > > > +1000) > > > > > > High speed PHY - Version: 2.0 > > > > > > EEPROM TLV detection failed: Using static config for Clearfog > Pro. > > > > > > Detected Device ID 6828 > > > > > > board SerDes lanes topology details: > > > > > > | Lane # | Speed | Type | > > > > > > > > > > > > | 0| 3 | SATA0 | > > > > > > | 1| 0 | SGMII1 | > > > > > > | 2| 5 | PCIe1 | > > > > > > | 3| 5 | USB3 HOST1 | > > > > > > | 4| 5 | PCIe2 | > > > > > > | 5| 0 | SGMII2 | > > > > > > > > > > > > High speed PHY - Ended Successfully > > > > > > mv_ddr: 14.0.0 > > > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > > > mv_ddr: completed successfully > > > > > > spl.c spl_boot_device part_config = 255 > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - > 10:05:32 > > > +1000) > > > > > > > > > > > > SoC: MV88F6828-A0 at 1600 MHz > > > > > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > > > > > clearfog.c board_init part_config = 255 > > > > > > Core: 38 devices, 22
Re: [PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
Reviewed-by: Alexander Kochetkov
> 22 марта 2023 г., в 14:26, haibo.c...@nxp.com написал(а):
>
> From: Haibo Chen
>
> dm_gpio_set_dir_flags() will clear GPIOD_MASK_DIR and set new flags.
> But there are cases like i2c_deblock_gpio_loop() will do like this:
>
> -first conifg GPIO(SDA) output with GPIOD_ACTIVE_LOW
> dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
> GPIOD_ACTIVE_LOW |
> GPIOD_IS_OUT_ACTIVE);
>
> -then config GPIO input
> dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
>
> -then get the GPIO input value:
> dm_gpio_get_value(pin);
>
> When config the GPIO input, only set GPIOD_IS_IN, but unfortunately
> since the previous GPIOD_ACTIVE_LOW is not cleared, still keep in
> flags, make the value from dm_gpio_get_value() not logic correct.
>
> So add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR to avoid this issue.
>
> Signed-off-by: Haibo Chen
> ---
> include/asm-generic/gpio.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index dd0bdf2315..903b237aac 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -131,7 +131,7 @@ struct gpio_desc {
>
> /* Flags for updating the above */
> #define GPIOD_MASK_DIR (GPIOD_IS_OUT | GPIOD_IS_IN | \
> - GPIOD_IS_OUT_ACTIVE)
> + GPIOD_IS_OUT_ACTIVE | GPIOD_ACTIVE_LOW)
> #define GPIOD_MASK_DSTYPE (GPIOD_OPEN_DRAIN | GPIOD_OPEN_SOURCE)
> #define GPIOD_MASK_PULL (GPIOD_PULL_UP | GPIOD_PULL_DOWN)
>
> --
> 2.34.1
>
[PATCH] gpio: add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR
From: Haibo Chen
dm_gpio_set_dir_flags() will clear GPIOD_MASK_DIR and set new flags.
But there are cases like i2c_deblock_gpio_loop() will do like this:
-first conifg GPIO(SDA) output with GPIOD_ACTIVE_LOW
dm_gpio_set_dir_flags(pin, GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW |
GPIOD_IS_OUT_ACTIVE);
-then config GPIO input
dm_gpio_set_dir_flags(pin, GPIOD_IS_IN);
-then get the GPIO input value:
dm_gpio_get_value(pin);
When config the GPIO input, only set GPIOD_IS_IN, but unfortunately
since the previous GPIOD_ACTIVE_LOW is not cleared, still keep in
flags, make the value from dm_gpio_get_value() not logic correct.
So add GPIOD_ACTIVE_LOW into GPIOD_MASK_DIR to avoid this issue.
Signed-off-by: Haibo Chen
---
include/asm-generic/gpio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index dd0bdf2315..903b237aac 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -131,7 +131,7 @@ struct gpio_desc {
/* Flags for updating the above */
#define GPIOD_MASK_DIR (GPIOD_IS_OUT | GPIOD_IS_IN | \
- GPIOD_IS_OUT_ACTIVE)
+GPIOD_IS_OUT_ACTIVE | GPIOD_ACTIVE_LOW)
#define GPIOD_MASK_DSTYPE (GPIOD_OPEN_DRAIN | GPIOD_OPEN_SOURCE)
#define GPIOD_MASK_PULL(GPIOD_PULL_UP | GPIOD_PULL_DOWN)
--
2.34.1
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár wrote: > > > > > On Monday 20 March 2023 18:45:01 Pali Rohár wrote: > > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > > > On Sun, 19 Mar 2023 at 18:20, Pali Rohár wrote: > > > > > > > > > > > On Sunday 19 March 2023 17:47:57 Pali Rohár wrote: > > > > > > > On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > > > > > > > > On Sun, 5 Mar 2023 at 11:55, Pali Rohár > wrote: > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which > specifies > > > boot > > > > > > mode > > > > > > > > > source. > > > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still > configured > > > into > > > > > > UART > > > > > > > > > > > booting mode via HW switches and if it still works > > > correctly? > > > > > > First > > > > > > > > > > > patch is reverting UART related commit for Clearfog > which I > > > > > > think it > > > > > > > > > not > > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef > before > > > the > > > > > > switch > > > > > > > > > that > > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > processed. It > > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > probably > > > > > > because > > > > > > > > > of > > > > > > > > > > the invalid boot workaround for broken UART selection > that > > > you > > > > > > > > > identified. > > > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or > if I > > > select > > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work > with > > > the MMC > > > > > > or > > > > > > > > > SATA > > > > > > > > > > defconfigs. I get the same result without this patch > series > > > > > > applied, > > > > > > > > > though. > > > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > header > > > > > > patching > > > > > > > > > > output) until after sending boot image data is complete. > The > > > > > > output stops > > > > > > > > > > after: > > > > > > > > > > > > > > > > > > > > 98 % > > > > > > > [. > > > > > > > > > > ] > > > > > > > > > > Done > > > > > > > > > > Finishing transfer > > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is very strange because > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > > > just > > > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was > booted, it > > > > > > correctly > > > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > > > sending > > > > > > main > > > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and > main > > > > > > u-boot > > > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I > was > > > sure > > > > > > was > > > > > > > > > > working after the last patches but I can no longer > reproduce > > > a > > > > > > successful > > > > > > > > > > boot. > > > > > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot > from > > > > > > version > > > > > > > > > with applying _all_ my patches recently sent to ML? Because > > > both > > > > > > mkimage > > > > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > > > > > > > > > > I tested using the latest next branch which has those > changes in > > > it. > > > > > > Steps: > > > > > > > > - Set UART boot mode on device > > > > > > > > - make clean > > > > > > > > - make clearfog_defconfig > > > > > > > > - make > > > > > > > > - ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > > > > > > > > > For me it looks like that either mkimage generated incorrect > > > image size > > > > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that > > > image size > > > > > > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0 > > > > > > > > kwboot version 2023.04-rc4-00339-gcefd0449d6 > > > > > > > > Detected kwbimage v1 with SDIO boot signature > > > > > > > > Patching image boot signature to UART > > > > > > > > Aligning image
[GIT PULL] Please pull u-boot-amlogic-20230131
Hi Tom, A single change to enable the odroid-go-ultra PMIC regulator at boot. The CI job is at https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/15691 Thanks, Neil The following changes since commit 88e08fc5f6e508eac46cd1dfb0379b11ae032c0a: Prepare v2023.04-rc4 (2023-03-13 20:52:48 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20230322 for you to fetch changes up to de58694f0d5431627d7389f50a6b2034a682ba24: ARM: meson: odroid-go-ultra: setup PMIC regulators are board init (2023-03-14 09:03:16 +0100) - odroid-go-ultra: setup PMIC regulators at board init Neil Armstrong (1): ARM: meson: odroid-go-ultra: setup PMIC regulators are board init .../arm/dts/meson-g12b-odroid-go-ultra-u-boot.dtsi | 8 board/amlogic/odroid-go-ultra/MAINTAINERS | 7 +++ board/amlogic/odroid-go-ultra/Makefile | 5 + board/amlogic/odroid-go-ultra/odroid-go-ultra.c| 22 ++ configs/odroid-go-ultra_defconfig | 4 ++-- 5 files changed, 44 insertions(+), 2 deletions(-) create mode 100644 board/amlogic/odroid-go-ultra/MAINTAINERS create mode 100644 board/amlogic/odroid-go-ultra/Makefile create mode 100644 board/amlogic/odroid-go-ultra/odroid-go-ultra.c
Re: [PATCH v4 16/17] riscv: dts: jh7110: Add initial StarFive VisionFive v2 board device tree
On 22 March 2023 01:37:53 GMT, yanhong wang wrote: > > >On 2023/3/21 5:25, Conor Dooley wrote: >> On Thu, Mar 16, 2023 at 10:53:31AM +0800, Yanhong Wang wrote: >>> Add initial device tree for StarFive VisionFive v2 board. >>> >>> Signed-off-by: Yanhong Wang >>> Tested-by: Conor Dooley >> >> btw, are you running some sort of cc suppression argument to >> send-email? There's not much reason to do so for submissions to a public >> ML, and it would be nice to get subsequent revisions of a patchset that >> I have given a tested-by for in my inbox. >> > >Yes, the --suppress-cc=all parameter was added to the send-email. Do you >suggest canceling this parameter? Please. If you're sending to a public mailing list, I don't really see the point in suppression.
Re: [PATCH] fs: fat: do not mangle short filenames
Am 21.03.2023 um 16:54 schrieb Tom Rini: On Tue, Mar 21, 2023 at 04:53:22PM +0100, Stefan Herbrechtsmeier wrote: Am 21.03.2023 um 16:35 schrieb Tom Rini: On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT. Well, you triggered this problem with a filesystem that had contents that were "just so" and then didn't work as expected, yes? No, I write a file to a file system and the boot rom do not find the file because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). The mdir command shows the short and long file name. I will add a test_fat.py with a test. Ah, ok, and great, thanks! I have send a separate patch `test: fs: Check fat short file name` or should I send a new series with both patches? Regards Stefan
[PATCH] test: fs: Check fat short file name
From: Stefan Herbrechtsmeier
Ensure that a freshly written fat file with a lower case filename which
fits into the upper case 8.3 short filename is not mangeled with a tilde
and number.
Signed-off-by: Stefan Herbrechtsmeier
---
test/py/tests/test_fs/test_ext.py | 36 +++
1 file changed, 36 insertions(+)
diff --git a/test/py/tests/test_fs/test_ext.py
b/test/py/tests/test_fs/test_ext.py
index dba874fc59..05fefa53a0 100644
--- a/test/py/tests/test_fs/test_ext.py
+++ b/test/py/tests/test_fs/test_ext.py
@@ -8,11 +8,24 @@
This test verifies extended write operation on file system.
"""
+import os.path
import pytest
import re
+from subprocess import check_output
from fstest_defs import *
from fstest_helpers import assert_fs_integrity
+PLAIN_FILE='abcdefgh.txt'
+MANGLE_FILE='abcdefghi.txt'
+
+def str2fat(long_filename):
+splitext = os.path.splitext(long_filename.upper())
+name = splitext[0]
+ext = splitext[1][1:]
+if len(name) > 8:
+name = '%s~1' % name[:6]
+return '%-8s %s' % (name, ext)
+
@pytest.mark.boardspec('sandbox')
@pytest.mark.slow
class TestFsExt(object):
@@ -317,3 +330,26 @@ class TestFsExt(object):
assert('FILE0123456789_79' in output)
assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext12(self, u_boot_console, fs_obj_ext):
+"""
+Test Case 12 - write plain and mangle file
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 12 - write plain and mangle
file'):
+# Test Case 12a - Check if command successfully returned
+output = u_boot_console.run_command_list([
+'host bind 0 %s' % fs_img,
+'%swrite host 0:0 %x /%s 0'
+% (fs_type, ADDR, PLAIN_FILE),
+'%swrite host 0:0 %x /%s 0'
+% (fs_type, ADDR, MANGLE_FILE)])
+assert('0 bytes written' in ''.join(output))
+# Test Case 12b - Read file system content
+output = check_output('mdir -i %s' % fs_img, shell=True).decode()
+# Test Case 12c - Check if short filename is not mangled
+assert(str2fat(PLAIN_FILE) in ''.join(output))
+# Test Case 12d - Check if long filename is mangled
+assert(str2fat(MANGLE_FILE) in ''.join(output))
+
+assert_fs_integrity(fs_type, fs_img)
--
2.30.2
[PATCH v2] net: phy: gmii2rgmii: Support external rgmii-id phy
From: Stefan Herbrechtsmeier
Read the phy mode of the external phy from the device tree if available
and check that it is a RGMII variant.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v2:
- Check that the external phy mode is a RGMII variant
drivers/net/phy/xilinx_gmii2rgmii.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c
b/drivers/net/phy/xilinx_gmii2rgmii.c
index 7376283956..853a0df659 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -48,7 +48,14 @@ static int xilinxgmiitorgmii_config(struct phy_device
*phydev)
return -EINVAL;
}
- ext_phydev->interface = PHY_INTERFACE_MODE_RGMII;
+ ext_phydev->interface = ofnode_read_phy_mode(node);
+ if (ext_phydev->interface == PHY_INTERFACE_MODE_NA) {
+ ext_phydev->interface = PHY_INTERFACE_MODE_RGMII;
+ } else if (!phy_interface_is_rgmii(ext_phydev)) {
+ printf("Incorrect external interface type\n");
+ return -EINVAL;
+ }
+
ext_phydev->node = phandle.node;
phydev->priv = ext_phydev;
--
2.30.2
Re: [PATCH] net: phy: gmii2rgmii: Support external rgmii-id phy
On 3/20/23 16:55, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Read the phy mode of the external phy from the device tree if available. Signed-off-by: Stefan Herbrechtsmeier --- drivers/net/phy/xilinx_gmii2rgmii.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c index 7376283956..12519a8d57 100644 --- a/drivers/net/phy/xilinx_gmii2rgmii.c +++ b/drivers/net/phy/xilinx_gmii2rgmii.c @@ -48,7 +48,10 @@ static int xilinxgmiitorgmii_config(struct phy_device *phydev) return -EINVAL; } - ext_phydev->interface = PHY_INTERFACE_MODE_RGMII; + ext_phydev->interface = ofnode_read_phy_mode(node); + if (ext_phydev->interface == PHY_INTERFACE_MODE_NA) + ext_phydev->interface = PHY_INTERFACE_MODE_RGMII; + This is open a way to pretty much define any mode which doesn't look right. I think it would be good to also check that mode is setup based on what IP itself supports. It means check that rgmii or rgmii-id are selected. If in DT someone put sgmii it should error out. Thanks, Michal
