Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> Add a python test script for testing the FWU Multi Bank Update
> functionality on the sandbox platform. The script has test cases for
> updation of the u-boot binary and the u-boot environment image to the
> non active bank.
>
> The FWU metadata is being stored on the SPI NOR flash, along with the
> updatable images, and the FWU metadata driver for MTD devices is being
> used for accessing the metadata. Certain FWU boottime checks are
> bypassed due to the unavailability of the EFI variable access very
> early in the boot on the sandbox platform -- the variable access is
> only available once the block disk image has been bound through the
> host interface.
>
> The FWU Multi Bank feature being enabled on the sandbox64 platform is
> enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> the FIT FMP instance is being removed -- the FIT FMP is already being
> tested on the sandbox flattree variant.
IMO,
Thinking of the importance of this feature, FIT FMP should also be
tested *with FWU*.
> Signed-off-by: Sughosh Ganu
> ---
> arch/sandbox/Kconfig | 6 +
> arch/sandbox/dts/test.dts | 45 ++-
> board/sandbox/sandbox.c | 49 +++
> configs/sandbox64_defconfig | 12 +-
> include/fwu.h | 2 +
> lib/fwu_updates/Kconfig | 2 +-
> lib/fwu_updates/fwu.c | 18 +-
> lib/fwu_updates/fwu_mtd.c | 10 +-
> .../test_capsule_firmware_fit.py | 1 -
> .../py/tests/test_fwu_updates/capsule_defs.py | 10 +
> test/py/tests/test_fwu_updates/conftest.py| 78
> .../test_fwu_updates/test_fwu_updates.py | 367 ++
> 12 files changed, 587 insertions(+), 13 deletions(-)
> create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
> create mode 100644 test/py/tests/test_fwu_updates/conftest.py
> create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
>
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 5f55c7f28e..2985572083 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>
> endmenu
> +
> +config FWU_NUM_BANKS
> + default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8f93775ff4..f11fa8733f 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1145,11 +1145,48 @@
> pinctrl-names = "default";
> pinctrl-0 = <_spi0_pins>;
>
> - spi.bin@0 {
> + spi0: spi.bin@0 {
> reg = <0>;
> compatible = "spansion,m25p16", "jedec,spi-nor";
> spi-max-frequency = <4000>;
> sandbox,filename = "spi.bin";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> +
> + partition@0 {
> + label = "Metadata";
> + reg = <0x0 0x2>;
> + };
> +
> + /* FWU Multi bank update partitions */
> + partition@10 {
> + label = "U-Boot-Bank0";
> + reg = <0x10 0x1>;
> + uuid =
> "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> + };
> +
> + partition@12 {
> + label = "U-Boot-ENV-Bank0";
> + reg = <0x12 0x1>;
> + uuid =
> "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> + };
> +
> + partition@14 {
> + label = "U-Boot-Bank1";
> + reg = <0x14 0x1>;
> + uuid =
> "52377abf-c4e4-4d0b-aafd-ba081a500847";
> + };
> +
> + partition@16 {
> + label = "U-Boot-ENV-Bank1";
> + reg = <0x16 0x1>;
> + uuid =
> "4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
> + };
> + };
> };
> spi.bin@1 {
> reg = <1>;
> @@ -1633,6 +1670,12 @@
Re: [PATCH v5 11/23] mkeficapsule: Add support for generating empty capsules
On Thu, Jun 09, 2022 at 05:59:58PM +0530, Sughosh Ganu wrote:
> The Dependable Boot specification[1] describes the structure of the
> firmware accept and revert capsules. These are empty capsules which
> are used for signalling the acceptance or rejection of the updated
> firmware by the OS. Add support for generating these empty capsules.
>
> [1] -
> https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf
>
> Signed-off-by: Sughosh Ganu
> ---
> doc/mkeficapsule.1 | 29 ++---
> tools/eficapsule.h | 8 +++
> tools/mkeficapsule.c | 139 +--
> 3 files changed, 151 insertions(+), 25 deletions(-)
>
> diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
> index 09bdc24295..77ca061efd 100644
> --- a/doc/mkeficapsule.1
> +++ b/doc/mkeficapsule.1
> @@ -8,7 +8,7 @@ mkeficapsule \- Generate EFI capsule file for U-Boot
>
> .SH SYNOPSIS
> .B mkeficapsule
> -.RI [ options "] " image-blob " " capsule-file
> +.RI [ options ] " " [ image-blob ] " " capsule-file
>
> .SH "DESCRIPTION"
> .B mkeficapsule
> @@ -23,8 +23,13 @@ Optionally, a capsule file can be signed with a given
> private key.
> In this case, the update will be authenticated by verifying the signature
> before applying.
>
> +Additionally, an empty capsule file can be generated for acceptance or
> +rejection of firmware images by a governing component like an Operating
> +System. The empty capsules do not require an image-blob input file.
> +
> +
> .B mkeficapsule
> -takes any type of image files, including:
> +takes any type of image files when generating non empty capsules, including:
> .TP
> .I raw image
> format is a single binary blob of any type of firmware.
> @@ -36,18 +41,16 @@ multiple binary blobs in a single capsule file.
> This type of image file can be generated by
> .BR mkimage .
>
> -.PP
> -If you want to use other types than above two, you should explicitly
> -specify a guid for the FMP driver.
> -
> .SH "OPTIONS"
> +
> .TP
> .BI "-g\fR,\fB --guid " guid-string
> Specify guid for image blob type. The format is:
> ----
>
> The first three elements are in little endian, while the rest
> -is in big endian.
> +is in big endian. The option must be specified for all non empty and
> +image acceptance capsules
"image acceptance" -> "firmware acceptance"
I don't still understand why we need a guid for acceptance
while revert doesn't require it.
I believe that firmware update is "all or nothing", isn't it?
If there is a good reason, please describe a possible/expected
scenario.
> .TP
> .BI "-i\fR,\fB --index " index
> @@ -57,6 +60,18 @@ Specify an image index
> .BI "-I\fR,\fB --instance " instance
> Specify a hardware instance
>
> +.PP
> +For generation of firmware accept empty capsule
> +.BR --guid
> +is mandatory
> +.TP
> +.BI "-A\fR,\fB --fw-accept "
> +Generate a firmware acceptance empty capsule
> +
> +.TP
> +.BI "-R\fR,\fB --fw-revert "
> +Generate a firmware revert empty capsule
> +
> .TP
> .BR -h ", " --help
> Print a help message
> diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> index d63b831443..072a4b5598 100644
> --- a/tools/eficapsule.h
> +++ b/tools/eficapsule.h
> @@ -41,6 +41,14 @@ typedef struct {
> EFI_GUID(0x4aafd29d, 0x68df, 0x49ee, 0x8a, 0xa9, \
>0x34, 0x7d, 0x37, 0x56, 0x65, 0xa7)
>
> +#define FW_ACCEPT_OS_GUID \
> + EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
> + 0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
> +
> +#define FW_REVERT_OS_GUID \
> + EFI_GUID(0xacd58b4b, 0xc0e8, 0x475f, 0x99, 0xb5, \
> + 0x6b, 0x3f, 0x7e, 0x07, 0xaa, 0xf0)
> +
> /* flags */
> #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
>
> diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
> index 5f74d23b9e..e8eb6b070d 100644
> --- a/tools/mkeficapsule.c
> +++ b/tools/mkeficapsule.c
> @@ -29,7 +29,16 @@ static const char *tool_name = "mkeficapsule";
> efi_guid_t efi_guid_fm_capsule = EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
>
> -static const char *opts_short = "g:i:I:v:p:c:m:dh";
> +static const char *opts_short = "g:i:I:v:p:c:m:dhAR";
> +
> +static bool empty_capsule;
> +static unsigned char capsule;
> +
> +enum {
> + CAPSULE_NORMAL_BLOB = 0,
> + CAPSULE_ACCEPT,
> + CAPSULE_REVERT,
> +} capsule_type;
>
> static struct option options[] = {
> {"guid", required_argument, NULL, 'g'},
> @@ -39,24 +48,47 @@ static struct option options[] = {
> {"certificate", required_argument, NULL, 'c'},
> {"monotonic-count", required_argument, NULL, 'm'},
> {"dump-sig", no_argument, NULL, 'd'},
> + {"fw-accept", no_argument, NULL, 'A'},
> + {"fw-revert", no_argument, NULL, 'R'},
> {"help", no_argument, NULL, 'h'},
> {NULL, 0, NULL, 0},
> };
>
> static void print_usage(void)
> {
> -
Re: [PATCH v7 0/9] enable menu-driven UEFI variable maintenance
On Mon, Jun 13, 2022 at 06:38:44PM +0900, Masahisa Kojima wrote: > This series add the menu-driven UEFI boot variable maintenance > and removable media support in bootmenu. > > Different from previous version, thie series adds a new U-Boot > command "efimenu" to invoke the UEFI boot-related variable > maintenance menu. Thanks. I'd like to give this command a more *specific* name rather than just "menu" :) For example, eficontrol or eficonfig. The followings are my comments mostly from user's perspective (or user-friendliness). So you may take them as improvements. * make menuconfig, "provide menu-driven uefi variables maintenance feature" Please add the command name, so "efimenu - ..." * the command can lead to a segmentation fault. I see it on sandbox. efi_init_obj_list() must always be called at the beginning. * If no boot option is defined yet, "Edit/Order/Delete" menu's simply return to the top menu. I expect some (error) message here. * This may happen even at "Add" if there is no block device. * Boot options without file paths (mostly for removable disks) appear in "Change Order" only if "bootmenu" is executed beforehand. This looks weird. * Some menu's have "Quit", others not. In some menu's, "Quit" means "quit without change" which is equivalent to "Esc". It looks a bit inconsistent. * Some menu's have "Save", others not. For instance, "Change Order" should have explicit "Save" so that user may cancel the change. * "Add" - The header line is "Edit Boot Option". -> Add Boot Option - Users may want to add an additional device path, especially for initrd. * "Edit" - The header line is "Select Boot Order". -> Select Boot Option - If "Description" is selected, I expect the current value is shown at editing screen. - If "File" is selected, I expect I can start with the last component (i.e. a file path). This might be arguable, though. - Users may want to have a short-form path. - Users may want to have a file path without a device media path. Now those variants for device path are acceptable in U-Boot implementation. * "Change Boot Order" - Users may want to remove a boot option (for a removable disk) which is automatically inserted by "bootmenu" from BootOrder. (The given boot option may still exist as a variable.) - As I said above, "Save" and "Quit" should be shown. * "Delete" - The header line is "Select Boot Order". -> Delete Boot Option -Takahiro Akashi > Note that menu-driven UEFI Secure Boot key management patch series > will follow. > > [Major Changes] > - rebased to v2022.07-rc4 > - there is detailed changelog in each commit > > Masahisa Kojima (9): > efi_loader: expose END device path node > efimenu: menu-driven addition of UEFI boot option > efimenu: add "Edit Boot Option" menu entry > menu: add KEY_PLUS and KEY_MINUS handling > efimenu: add "Change Boot Order" menu entry > efimenu: add "Delete Boot Option" menu entry > bootmenu: add removable media entries > doc:bootmenu: add description for UEFI boot support > doc:efimenu: add documentation for efimenu command > > cmd/Kconfig |7 + > cmd/Makefile |1 + > cmd/bootmenu.c | 99 +- > cmd/efimenu.c| 1824 ++ > common/menu.c|6 + > doc/usage/cmd/bootmenu.rst | 74 ++ > doc/usage/cmd/efimenu.rst| 50 + > doc/usage/index.rst |1 + > include/efi_loader.h | 63 ++ > include/efi_menu.h | 91 ++ > include/menu.h |2 + > lib/efi_loader/efi_boottime.c| 52 +- > lib/efi_loader/efi_console.c | 78 ++ > lib/efi_loader/efi_device_path.c |2 +- > lib/efi_loader/efi_disk.c| 11 + > lib/efi_loader/efi_file.c| 75 +- > 16 files changed, 2385 insertions(+), 51 deletions(-) > create mode 100644 cmd/efimenu.c > create mode 100644 doc/usage/cmd/efimenu.rst > create mode 100644 include/efi_menu.h > > -- > 2.17.1 >
Re: [PATCH] tools: binman: install btool
On Wed, Jun 15, 2022 at 12:34:17AM +0300, Alper Nebi Yasak wrote: > On 14/06/2022 13:42, Peng Fan (OSS) wrote: > > From: Peng Fan > > > > btool is needed after install binman to system. > > > > Signed-off-by: Peng Fan > > --- > > Reviewed-by: Alper Nebi Yasak > > > Tom, Simon, Alper > > This is a bug fix, if possible, please pick it up. I'll put it in my queue, thanks. -- Tom signature.asc Description: PGP signature
RE: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)
> Subject: Re: [PATCH 7/8] binman_sym: guard with > CONFIG_IS_ENABLED(BINMAN_SYMBOLS) > > On 13/06/2022 05:34, Peng Fan (OSS) wrote: > > 在 2022/6/11 20:44, Alper Nebi Yasak 写道: > >> CONFIG_IS_ENABLED(BINMAN) doesn't work, but > IS_ENABLED(CONFIG_BINMAN) > >> worked for me. I see all 8 symbols in spl/u-boot-spl.sym. I can send > >> you a git branch if you want? > > > > But now with your suggestion, that means all i.MX8M boards should use > > the i.MX binman symbols, that is not expected. The i.MX driver code is > > expected to support w/o i.MX binman symbols. > > In my series I'll add a macro like BINMAN_SYMS_OK that is true if binman wrote > the declared symbols, and false if it didn't. Then you can check 'if > (BINMAN_SYMS_OK)' to decide if the driver should use the symbols. > It'll take a day or two for me to test and send. If the macro isn't good > enough, > maybe you can add a new config for the driver's binman symbols. Thanks for helping, please also share me a git repo. > > (Is there any i.MX8M board that won't have working symbols for ddr_fw files > after this series?) I think NO, but I still prefer symbols could be disabled on demand, some NXP downstream validation boards not have symbols enabled. Thanks, Peng.
Re: [PATCH] tools: binman: install btool
On 14/06/2022 13:42, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> btool is needed after install binman to system.
>
> Signed-off-by: Peng Fan
> ---
Reviewed-by: Alper Nebi Yasak
> Tom, Simon, Alper
> This is a bug fix, if possible, please pick it up.
>
> tools/binman/setup.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/binman/setup.py b/tools/binman/setup.py
> index 5ed94abdaf9..9a9206eb044 100644
> --- a/tools/binman/setup.py
> +++ b/tools/binman/setup.py
> @@ -5,7 +5,7 @@ setup(name='binman',
>version='1.0',
>license='GPL-2.0+',
>scripts=['binman'],
> - packages=['binman', 'binman.etype'],
> + packages=['binman', 'binman.etype', 'binman.btool'],
>package_dir={'binman': ''},
>package_data={'binman': ['README.rst', 'entries.rst']},
>classifiers=['Environment :: Console',
Re: [PATCH v2] crypto/fsl: fsl_hash: Fix crash in flush dcache
Hi Gaurav,
On Thu, Jun 9, 2022 at 9:47 AM Gaurav Jain wrote:
> + flush_dcache_range((ulong)ctx->sg_tbl,
> + (ulong)(ctx->sg_tbl) + (ctx->sg_num *
> sizeof(struct sg_entry)));
> + for (i = 0; i < ctx->sg_num; i++) {
> + sg_entry_len = (sec_in32(>sg_tbl[i].len_flag) &
> + SG_ENTRY_LENGTH_MASK);
> + len += sg_entry_len;
> + addr = sec_in32(>sg_tbl[i].addr_hi);
> + addr = (addr << 32) | sec_in32(>sg_tbl[i].addr_lo);
This breaks the build:
arm: + ls1021aiot_qspi
1183+drivers/crypto/fsl/fsl_hash.c: In function 'caam_hash_finish':
1184+drivers/crypto/fsl/fsl_hash.c:150:30: error: left shift count >=
width of type [-Werror=shift-count-overflow]
1185+ 150 | addr = (addr << 32) | sec_in32(>sg_tbl[i].addr_lo);
1186+ | ^~
1187+cc1: all warnings being treated as errors
Please check:
https://source.denx.de/u-boot/custodians/u-boot-imx/-/jobs/448344
Re: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)
On 13/06/2022 05:34, Peng Fan (OSS) wrote: > 在 2022/6/11 20:44, Alper Nebi Yasak 写道: >> CONFIG_IS_ENABLED(BINMAN) doesn't work, but IS_ENABLED(CONFIG_BINMAN) >> worked for me. I see all 8 symbols in spl/u-boot-spl.sym. I can send you >> a git branch if you want? > > But now with your suggestion, that means all i.MX8M boards should use > the i.MX binman symbols, that is not > expected. The i.MX driver code is expected to support w/o i.MX binman > symbols. In my series I'll add a macro like BINMAN_SYMS_OK that is true if binman wrote the declared symbols, and false if it didn't. Then you can check 'if (BINMAN_SYMS_OK)' to decide if the driver should use the symbols. It'll take a day or two for me to test and send. If the macro isn't good enough, maybe you can add a new config for the driver's binman symbols. (Is there any i.MX8M board that won't have working symbols for ddr_fw files after this series?)
Re: [PATCH 7/8] binman_sym: guard with CONFIG_IS_ENABLED(BINMAN_SYMBOLS)
On 13/06/2022 05:31, Peng Fan (OSS) wrote:
>> 在 2022/6/11 0:47, Alper Nebi Yasak 写道:
>>> Looks like I have misunderstood things here a bit. CONFIG_BINMAN enables
>>> you to declare and use symbols. CONFIG_SPL/TPL_BINMAN_SYMBOLS declares
>>> certain symbols ('u_boot_any'). The name is a bit misleading, as if it
>>> enables support for using symbols, and that confused me.
>> I am not sure, but I think CONFIG_SPL/TPL_BINMAN_SYMBOLS are only for
>> certain symbols saying u_boot_any.
>
> I mean I not think BINMAN_SYMBOLS are only for certtain symbols.
They are right now, your patch changes that.
I wasn't sure about changing it at first, but it makes more sense to me
now. I'll update my series and split things out:
- BINMAN: to run binman after build
- BINMAN_SYMBOLS: to enable binman symbols, binman_sym.h
- BINMAN_UBOOT_SYMBOLS: new config to declare u_boot_any symbols
Re: [PATCH v2] armv8: always use current exception level for TCR_ELx access
> From: Andre Przywara
> Date: Tue, 14 Jun 2022 00:11:10 +0100
>
> Currently get_tcr() takes an "el" parameter, to select the proper
> version of the TCR_ELx system register.
> This is problematic in case of the Apple M1, since it runs with
> HCR_EL2.E2H fixed to 1, so TCR_EL2 is actually using the TCR_EL1 layout,
> and we get the wrong version.
>
> For U-Boot's purposes the only sensible choice here is the current
> exception level, and indeed most callers treat it like that, so let's
> remove that parameter and read the current EL inside the function.
> This allows us to check for the E2H bit, and pretend it's EL1 in this
> case.
>
> There are two callers which don't care about the EL, and they pass 0,
> which looks wrong, but is irrelevant in these two cases, since we don't
> use the return value there. So the change cannot affect those two.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Mark Kettenis
Tested-by: Mark Kettenis
> ---
> Changelog v1 ... v2:
> - Give bit 34 a name, and also use that in start.S
>
> Mark, can you please test this? The A53s I have here for a quick test
> are igorant of this patch ...
>
> arch/arm/cpu/armv8/cache_v8.c | 28 +
> arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 4 ++--
> arch/arm/cpu/armv8/start.S | 2 +-
> arch/arm/include/asm/armv8/mmu.h| 4 +++-
> 4 files changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 3de18c7675b..e4736e56436 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -39,8 +39,28 @@ DECLARE_GLOBAL_DATA_PTR;
> *off: FFF
> */
>
> -u64 get_tcr(int el, u64 *pips, u64 *pva_bits)
> +static int get_effective_el(void)
> {
> + int el = current_el();
> +
> + if (el == 2) {
> + u64 hcr_el2;
> +
> + /*
> + * If we are using the EL2&0 translation regime, the TCR_EL2
> + * looks like the EL1 version, even though we are in EL2.
> + */
> + __asm__ ("mrs %0, HCR_EL2\n" : "=r" (hcr_el2));
> + if (hcr_el2 & BIT(HCR_EL2_E2H_BIT))
> + return 1;
> + }
> +
> + return el;
> +}
> +
> +u64 get_tcr(u64 *pips, u64 *pva_bits)
> +{
> + int el = get_effective_el();
> u64 max_addr = 0;
> u64 ips, va_bits;
> u64 tcr;
> @@ -115,7 +135,7 @@ static u64 *find_pte(u64 addr, int level)
>
> debug("addr=%llx level=%d\n", addr, level);
>
> - get_tcr(0, NULL, _bits);
> + get_tcr(NULL, _bits);
> if (va_bits < 39)
> start_level = 1;
>
> @@ -343,7 +363,7 @@ __weak u64 get_page_table_size(void)
> u64 va_bits;
> int start_level = 0;
>
> - get_tcr(0, NULL, _bits);
> + get_tcr(NULL, _bits);
> if (va_bits < 39)
> start_level = 1;
>
> @@ -415,7 +435,7 @@ __weak void mmu_setup(void)
> setup_all_pgtables();
>
> el = current_el();
> - set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
> + set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
> MEMORY_ATTRIBUTES);
>
> /* enable the mmu */
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index 253008a9c13..c989a43cbeb 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -454,7 +454,7 @@ static inline void early_mmu_setup(void)
>
> /* point TTBR to the new table */
> set_ttbr_tcr_mair(el, gd->arch.tlb_addr,
> - get_tcr(el, NULL, NULL) &
> + get_tcr(NULL, NULL) &
> ~(TCR_ORGN_MASK | TCR_IRGN_MASK),
> MEMORY_ATTRIBUTES);
>
> @@ -609,7 +609,7 @@ static inline void final_mmu_setup(void)
> invalidate_icache_all();
>
> /* point TTBR to the new table */
> - set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
> + set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(NULL, NULL),
> MEMORY_ATTRIBUTES);
>
> set_sctlr(get_sctlr() | CR_M);
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index d328e8c08a1..28f0df13f0d 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -125,7 +125,7 @@ pie_fixup_done:
> msr cptr_el3, xzr /* Enable FP/SIMD */
> b 0f
> 2: mrs x1, hcr_el2
> - tbnzx1, #34, 1f /* HCR_EL2.E2H */
> + tbnzx1, #HCR_EL2_E2H_BIT, 1f/* HCR_EL2.E2H */
> orr x1, x1, #HCR_EL2_AMO_EL2/* Route SErrors to EL2 */
> msr hcr_el2, x1
> set_vbar vbar_el2, x0
> diff --git a/arch/arm/include/asm/armv8/mmu.h
> b/arch/arm/include/asm/armv8/mmu.h
> index c36b2cf5a58..9f58cedb650 100644
> ---
[PATCH v3] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
V2: Use uclass_get_device_by_name()
V3: Reinstate the device-internal.h, needed for device_probe()
---
.../imx8mm_data_modul_edm_sbc.c | 9 +
configs/imx8mm_data_modul_edm_sbc_defconfig | 1 +
include/configs/imx8mm_data_modul_edm_sbc.h | 20 ---
3 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..07d9effbbb9 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -104,7 +105,15 @@ int board_init(void)
int board_late_init(void)
{
+ struct udevice *dev;
+ int ret;
+
setup_boot_device();
setup_mac_address();
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+ if (!ret)
+ device_probe(dev);
+
return 0;
}
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
CONFIG_DM_I2C=y
# CONFIG_INPUT is not set
CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
CONFIG_I2C_EEPROM=y
CONFIG_SYS_I2C_EEPROM_ADDR=0x50
CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0" \
"dmo_preboot=" \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
- "run dmo_usb_start_hub ; " \
/* Attempt to start USB and Network console */ \
"run dmo_usb_cdc_acm_start ; " \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; " \
"fi ; " \
"fi\0" \
- "dmo_usb_start_hub="\
- "i2c dev 1 ; " \
- /* Reset the USB USB */ \
- "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
- "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */ \
- /* Write chunks of descriptor into the USB HUB */ \
- "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
- "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
- "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
- "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; " \
- "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
- "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
- "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; " \
- "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
- "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
- "mw.l 0x7e1010 0x6900 ; " \
- "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; " \
- "mw.l 0x7e1000 0x0101 ; " \
- "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
--
2.35.1
[PATCH v2] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
V2: Use uclass_get_device_by_name()
---
.../imx8mm_data_modul_edm_sbc.c | 8
configs/imx8mm_data_modul_edm_sbc_defconfig | 1 +
include/configs/imx8mm_data_modul_edm_sbc.h | 20 ---
3 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..1e20fb46fef 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -104,7 +104,15 @@ int board_init(void)
int board_late_init(void)
{
+ struct udevice *dev;
+ int ret;
+
setup_boot_device();
setup_mac_address();
+
+ ret = uclass_get_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+ if (!ret)
+ device_probe(dev);
+
return 0;
}
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
CONFIG_DM_I2C=y
# CONFIG_INPUT is not set
CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
CONFIG_I2C_EEPROM=y
CONFIG_SYS_I2C_EEPROM_ADDR=0x50
CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0" \
"dmo_preboot=" \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
- "run dmo_usb_start_hub ; " \
/* Attempt to start USB and Network console */ \
"run dmo_usb_cdc_acm_start ; " \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; " \
"fi ; " \
"fi\0" \
- "dmo_usb_start_hub="\
- "i2c dev 1 ; " \
- /* Reset the USB USB */ \
- "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
- "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */ \
- /* Write chunks of descriptor into the USB HUB */ \
- "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
- "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
- "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
- "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; " \
- "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
- "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
- "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; " \
- "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
- "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
- "mw.l 0x7e1010 0x6900 ; " \
- "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; " \
- "mw.l 0x7e1000 0x0101 ; " \
- "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
--
2.35.1
Re: [PATCH v3 8/8] board: gw_ventana: enable MV88E61XX DSA support
Hi Tim, On Tue, Jun 14, 2022 at 10:00:57AM -0700, Tim Harvey wrote: > Vladimir, > > I'm not sure if you've had a chance to look at this latest patch > revision yet. I believe above is what you were describing as the > correct way to do this (without modifying the Linux driver and > improving bindings) > > Best Regards, > > Tim I'm currently on vacation but I'm slowly working through my inbox. This is certainly one of the reasonable ways of doing things, but it will require modifying the mv88e6xxx Linux driver to support an "mdios" subnode (something which nobody should object against, I believe). I'll follow up with more comments when I get to these patches.
Re: [PATCH 2/2] rockchip: rk3399: enable spl-fifo-mode for sdmmc only when needed
On 6/9/22 08:23, Jerome Forissier wrote:
> Commit 5c606ca35c42 ("rockchip: rk3399: enable spl-fifo-mode for sdmmc")
> mentions that the RK3399 SoC can't do DMA between SDMMC and SRAM.
> According to the TRM "7.3.2 Embedded SRAM access path" [1], only the
> 8KB SRAM at 0xff3b (INTMEM1) is in this situation. The 192KB SRAM
> can be accessed by both DMA controllers.
>
> Assuming the only use case for writing from MMC to INTMEM1 is loading
> a FIT image, and with the introduction of a temporary buffer for that
> purpose (CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE, which is required
> anyways to ensure the destination boundaries are enforced), then
> spl-fifo-mode is not needed anymore and DMA can be enabled safely.
>
> Link: [1] https://www.rockchip.fr/Rockchip%20RK3399%20TRM%20V1.4%20Part1.pdf
> CC: Deepak Das
> Signed-off-by: Jerome Forissier
> ---
> arch/arm/dts/rk3399-u-boot.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 716b9a433a..a1b6d6f007 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -124,8 +124,10 @@
> {
> u-boot,dm-pre-reloc;
>
> +#ifndef CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE
Oops, that should rather be:
+#if (CONFIG_SPL_LOAD_FIT_IMAGE_BUFFER_SIZE == 0)
> /* mmc to sram can't do dma, prevent aborts transferring TF-A parts */
> u-boot,spl-fifo-mode;
> +#endif
> };
>
> {
Re: [PATCH] dtoc: Update test_src_scan.py for new tegra compatibles
On Tue, Jun 14, 2022 at 02:00:48PM -0400, Tom Rini wrote:
> This test was written to match up with the list of compatibles in
> drivers/i2c/tegra_i2c.c so adding another one requires the test to be
> updated to match.
>
> Fixes: 0d2105ae5e32 ("arm: tegra: Update some DT compatibles")
> Signed-off-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH] dtoc: Update test_src_scan.py for new tegra compatibles
This test was written to match up with the list of compatibles in
drivers/i2c/tegra_i2c.c so adding another one requires the test to be
updated to match.
Fixes: 0d2105ae5e32 ("arm: tegra: Update some DT compatibles")
Signed-off-by: Tom Rini
---
tools/dtoc/test_src_scan.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/dtoc/test_src_scan.py b/tools/dtoc/test_src_scan.py
index bdfa669d816f..f93cd7f5a3a9 100644
--- a/tools/dtoc/test_src_scan.py
+++ b/tools/dtoc/test_src_scan.py
@@ -151,6 +151,7 @@ class TestSrcScan(unittest.TestCase):
self.assertEqual('UCLASS_I2C', drv.uclass_id)
self.assertEqual(
{'nvidia,tegra114-i2c': 'TYPE_114',
+ 'nvidia,tegra124-i2c': 'TYPE_114',
'nvidia,tegra20-i2c': 'TYPE_STD',
'nvidia,tegra20-i2c-dvc': 'TYPE_DVC'}, drv.compat)
self.assertEqual('i2c_bus', drv.priv)
--
2.25.1
Re: Pull request, u-boot-tegra/master
On Tue, Jun 14, 2022 at 01:24:13PM -0400, Tom Rini wrote: > On Tue, Jun 14, 2022 at 09:05:11AM -0700, Tom Warren wrote: > > > Tom, > > > > Please pull u-boot-tegra/master into U-Boot/master. Thanks. > > > > The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad: > > > > Merge tag 'efi-2022-07-rc5' of > > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37 > > -0400) > > > > are available in the git repository at: > > > > https://source.denx.de/u-boot/custodians/u-boot-tegra.git master > > > > for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca: > > > > board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt > > (2022-06-13 15:31:15 -0700) > > > > Applied to u-boot/master, thanks! That said, please put things through CI before sending a PR. I did a quick local build test, and found a warning being introduced because of a missing include. I fixed that and figured it was enough, which is on me. Next up: commit 0d2105ae5e32ef5c87246054b2638fe50e62448c Author: Peter Robinson Date: Tue May 3 09:32:54 2022 +0100 arm: tegra: Update some DT compatibles breaks the dtoc tests: https://source.denx.de/u-boot/u-boot/-/jobs/448215 and I'm going to fix that momentarily. -- Tom signature.asc Description: PGP signature
Re: [PATCH] tbs2910: Convert to DM_SERIAL
On 14.06.22 18:27, Fabio Estevam wrote: On Sat, Mar 19, 2022 at 10:31 AM Fabio Estevam wrote: Fabio, will you sync the imx6qdl.dtsi changes to linux? Or how is this supposed to keep in sync? Yes, I plan to submit these imx6qdl.dtsi changes (and similar changes to the other i.MX dtsi files too) to the mainline kernel. I will do it after 5.18-rc1 is out and will keep you on Cc when I submit it. I missed the last cycle, but just sent the two patches upstream: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751353.html http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751354.html Yes, I saw your patches. Thanks, Soeren Regards, Fabio Estevam
Re: [PATCH v3 0/3] usb: add isp1760 hcd support
Hi *,
On Wed, May 25, 2022 at 02:22:48PM +0100, Rui Miguel Silva wrote:
> Add support for the usb isp1760 host controller family, which
> for example is present in MPS3 FPGA board from Arm (isp1763).
>
> First we move some helper functions and defines to a more
> common place to be shared by several urb users. (patch 1/3)
>
> Then add the driver itself, is a ported version of the kernel
> actual driver, which I am also the maintainer. (patch 2/3)
>
> And last, enable it for the corstone1000 platform that uses
> that MPS3 board for its implementation (patch 3/3).
>
Any chance this series get some feedback?
Thanks in advance,
Cheers,
Rui
>
> Cheers,
>Rui
>
> v2[3] -> v3:
> - when you think you have amend commit and fix stay
> uncommitted.
> s/[HC_FIELD_MAX] = {};/[HC_FIELD_MAX] = {},/
> v1[0] -> v2:
> - gentle ping
> - merge fix from kernel upstream [1]
>
> PS: This should go on top of the corstone1000 platform enable
> series [2]
>
> 0:
> https://lore.kernel.org/u-boot/20220512142016.2025129-1-rui.si...@linaro.org/
> 1:
> https://lore.kernel.org/linux-usb/20220516091424.391209-1-linus.wall...@linaro.org/
> 2:
> https://lore.kernel.org/u-boot/20220511095541.1461937-1-rui.si...@linaro.org/T/#t
> 3:
> https://lore.kernel.org/u-boot/20220523090119.1212016-1-rui.si...@linaro.org/
>
> Rui Miguel Silva (3):
> usb: common: move urb code to common
> usb: add isp1760 family driver
> corstone1000: enable isp1763 usb controller and mmc
>
> Makefile |1 +
> configs/corstone1000_defconfig|3 +
> drivers/usb/Kconfig |2 +
> drivers/usb/common/Makefile |3 +
> drivers/usb/common/usb_urb.c | 160 ++
> drivers/usb/host/r8a66597-hcd.c | 30 +-
> drivers/usb/isp1760/Kconfig | 12 +
> drivers/usb/isp1760/Makefile |6 +
> drivers/usb/isp1760/isp1760-core.c| 380 +++
> drivers/usb/isp1760/isp1760-core.h| 96 +
> drivers/usb/isp1760/isp1760-hcd.c | 2477 +
> drivers/usb/isp1760/isp1760-hcd.h | 81 +
> drivers/usb/isp1760/isp1760-if.c | 125 +
> drivers/usb/isp1760/isp1760-regs.h| 292 ++
> drivers/usb/isp1760/isp1760-uboot.c | 75 +
> drivers/usb/isp1760/isp1760-uboot.h | 27 +
> drivers/usb/musb-new/musb_core.c |2 +-
> drivers/usb/musb-new/musb_host.c |2 +-
> drivers/usb/musb-new/musb_host.h |2 +-
> drivers/usb/musb-new/musb_uboot.c | 38 +-
> drivers/usb/musb-new/musb_uboot.h |2 +-
> include/configs/corstone1000.h|6 +
> .../linux/usb/usb_urb_compat.h| 47 +-
> include/usb_defs.h| 32 +
> 24 files changed, 3825 insertions(+), 76 deletions(-)
> create mode 100644 drivers/usb/common/usb_urb.c
> create mode 100644 drivers/usb/isp1760/Kconfig
> create mode 100644 drivers/usb/isp1760/Makefile
> create mode 100644 drivers/usb/isp1760/isp1760-core.c
> create mode 100644 drivers/usb/isp1760/isp1760-core.h
> create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
> create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
> create mode 100644 drivers/usb/isp1760/isp1760-if.c
> create mode 100644 drivers/usb/isp1760/isp1760-regs.h
> create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
> create mode 100644 drivers/usb/isp1760/isp1760-uboot.h
> rename drivers/usb/musb-new/usb-compat.h =>
> include/linux/usb/usb_urb_compat.h (59%)
>
> --
> 2.36.1
>
Re: Pull request, u-boot-tegra/master
On Tue, Jun 14, 2022 at 09:05:11AM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks. > > The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad: > > Merge tag 'efi-2022-07-rc5' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37 > -0400) > > are available in the git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tegra.git master > > for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca: > > board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt > (2022-06-13 15:31:15 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 8/8] board: gw_ventana: enable MV88E61XX DSA support
On Mon, May 23, 2022 at 11:26 AM Tim Harvey wrote:
>
> Add MV88E61XX DSA support:
> - update dt: U-Boot dsa driver requires different device-tree syntax
>than the linux driver in order to link the dsa ports to the mdio bus.
> - update defconfig
> - replace mv88e61xx_hw_reset weak override with board_phy_config support
>for mv88e61xx configuration that is outside the scope of the DSA driver
>
> Signed-off-by: Tim Harvey
> ---
> v3:
> - move mdio's mdio@0 subnode
> v2: no changes
> ---
> arch/arm/dts/imx6qdl-gw5904.dtsi| 41
> board/gateworks/gw_ventana/gw_ventana.c | 50 +
> configs/gwventana_gw5904_defconfig | 7 ++--
> 3 files changed, 62 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/dts/imx6qdl-gw5904.dtsi
> b/arch/arm/dts/imx6qdl-gw5904.dtsi
> index 286c7a9924c2..1b2f70d1ccb2 100644
> --- a/arch/arm/dts/imx6qdl-gw5904.dtsi
> +++ b/arch/arm/dts/imx6qdl-gw5904.dtsi
> @@ -219,6 +219,33 @@
> compatible = "marvell,mv88e6085";
> reg = <0>;
>
> + mdios {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mdio@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sw_phy0: ethernet-phy@0 {
> + reg = <0x0>;
> + };
> +
> + sw_phy1: ethernet-phy@1 {
> + reg = <0x1>;
> + };
> +
> + sw_phy2: ethernet-phy@2 {
> + reg = <0x2>;
> + };
> +
> + sw_phy3: ethernet-phy@3 {
> + reg = <0x3>;
> + };
> + };
> + };
> +
Vladimir,
I'm not sure if you've had a chance to look at this latest patch
revision yet. I believe above is what you were describing as the
correct way to do this (without modifying the Linux driver and
improving bindings)
Best Regards,
Tim
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -226,27 +253,41 @@
> port@0 {
> reg = <0>;
> label = "lan4";
> + phy-mode = "internal";
> + phy-handle = <_phy0>;
> };
>
> port@1 {
> reg = <1>;
> label = "lan3";
> + phy-mode = "internal";
> + phy-handle = <_phy1>;
> };
>
> port@2 {
> reg = <2>;
> label = "lan2";
> + phy-mode = "internal";
> + phy-handle = <_phy2>;
> };
>
> port@3 {
> reg = <3>;
> label = "lan1";
> + phy-mode = "internal";
> + phy-handle = <_phy3>;
> };
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <>;
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
> };
> };
> diff --git a/board/gateworks/gw_ventana/gw_ventana.c
> b/board/gateworks/gw_ventana/gw_ventana.c
> index c06630a66b66..bef3f7ef0d2b 100644
> --- a/board/gateworks/gw_ventana/gw_ventana.c
> +++ b/board/gateworks/gw_ventana/gw_ventana.c
> @@ -68,44 +68,30 @@ int board_phy_config(struct phy_device *phydev)
> phy_write(phydev, MDIO_DEVAD_NONE, 14, val);
> }
>
> + /* Fixed PHY: for GW5904/GW5909 this is Marvell 88E6176 GbE
Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT
On Tue, Jun 14, 2022 at 9:18 AM Tom Rini wrote:
>
> On Tue, Jun 14, 2022 at 09:14:03AM -0700, Tim Harvey wrote:
> > On Mon, Jun 13, 2022 at 7:57 PM Tom Rini wrote:
> > >
> > > Move the environment text over from being set via
> > > CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> > > to plain text in board/gateworks/gw_ventana/gw_ventana.env. This lets
> > > us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> > > single environment file now.
> > >
> > > Cc: Tim Harvey
> > > Signed-off-by: Tom Rini
> > > ---
> > > board/gateworks/gw_ventana/gw_ventana.env | 145 +
> > > include/configs/gw_ventana.h | 148 --
> > > 2 files changed, 145 insertions(+), 148 deletions(-)
> > > create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
> > >
> > > diff --git a/board/gateworks/gw_ventana/gw_ventana.env
> > > b/board/gateworks/gw_ventana/gw_ventana.env
> > > new file mode 100644
> > > index ..9a316c74f215
> > > --- /dev/null
> > > +++ b/board/gateworks/gw_ventana/gw_ventana.env
> > > @@ -0,0 +1,145 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright (C) 2013 Gateworks Corporation
> > > + */
> > > +
> > > +splashpos=m,m
> > > +splashimage=CONFIG_SYS_LOAD_ADDR
> > > +usb_pgood_delay=2000
> > > +console=ttymxc1
> > > +bootdevs=usb mmc sata flash
> > > +hwconfig=_UNKNOWN_
> > > +
> > > +disk=0
> > > +part=1
> > > +
> > > +fdt_high=0x
> > > +fdt_addr=0x1800
> > > +initrd_high=0x
> > > +fixfdt=fdt addr ${fdt_addr}
> > > +bootdir=boot
> > > +loadfdt=
> > > + if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> > > + echo Loaded DTB from ${bootdir}/${fdt_file};
> > > + run fixfdt;
> > > + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> > > + echo Loaded DTB from ${bootdir}/${fdt_file1};
> > > + run fixfdt;
> > > + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> > > + echo Loaded DTB from ${bootdir}/${fdt_file2};
> > > + run fixfdt;
> > > + fi
> > > +
> > > +fs=ext4
> > > +script=6x_bootscript-ventana
> > > +loadscript=
> > > + if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> > > + source ${loadaddr};
> > > + fi
> > > +
> > > +uimage=uImage
> > > +mmc_root=mmcblk0p1
> > > +mmc_boot=
> > > + setenv fsload "${fs}load mmc ${disk}:${part}";
> > > + mmc dev ${disk} && mmc rescan &&
> > > + setenv dtype mmc; run loadscript;
> > > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > + setenv bootargs console=${console},${baudrate}
> > > + root=/dev/${mmc_root} rootfstype=${fs}
> > > + rootwait rw ${video} ${extra};
> > > + if run loadfdt; then
> > > + bootm ${loadaddr} - ${fdt_addr};
> > > + else
> > > + bootm;
> > > + fi;
> > > + fi
> > > +
> > > +sata_boot=
> > > + setenv fsload "${fs}load sata ${disk}:${part}";
> > > + sata init &&
> > > + setenv dtype sata; run loadscript;
> > > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > + setenv bootargs console=${console},${baudrate}
> > > + root=/dev/sda1 rootfstype=${fs}
> > > + rootwait rw ${video} ${extra};
> > > + if run loadfdt; then
> > > + bootm ${loadaddr} - ${fdt_addr};
> > > + else
> > > + bootm;
> > > + fi;
> > > + fi
> > > +
> > > +usb_boot=
> > > + setenv fsload "${fs}load usb ${disk}:${part}";
> > > + usb start && usb dev ${disk} &&
> > > + setenv dtype usb; run loadscript;
> > > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > > + setenv bootargs console=${console},${baudrate}
> > > + root=/dev/sda1 rootfstype=${fs}
> > > + rootwait rw ${video} ${extra};
> > > + if run loadfdt; then
> > > + bootm ${loadaddr} - ${fdt_addr};
> > > + else
> > > + bootm;
> > > + fi;
> > > + fi
> > > +
> > > +#ifdef CONFIG_SPI_FLASH
> > > +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> > > +image_uboot=ventana/u-boot_spi.imx
> > > +
> > > +spi_koffset=0x9
> > > +spi_klen=0x20
> > > +
> > > +spi_updateuboot=echo Updating uboot from
> > > + ${serverip}:${image_uboot}...;
> > > + tftpboot ${loadaddr} ${image_uboot} &&
> > > + sf probe && sf erase 0 8 &&
> > > + sf write ${loadaddr} 400 ${filesize}
> > > +spi_update=echo Updating OS from ${serverip}:${image_os}
> > > + to ${spi_koffset} ...;
> > > + tftp ${loadaddr} ${image_os} &&
> > > + sf probe &&
> > > +
Re: [PATCH] tbs2910: Convert to DM_SERIAL
On Sat, Mar 19, 2022 at 10:31 AM Fabio Estevam wrote: > > Fabio, will you sync the imx6qdl.dtsi changes to linux? > > Or how is this supposed to keep in sync? > > Yes, I plan to submit these imx6qdl.dtsi changes (and similar changes > to the other i.MX dtsi files too) to the mainline kernel. > > I will do it after 5.18-rc1 is out and will keep you on Cc when I submit it. I missed the last cycle, but just sent the two patches upstream: http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751353.html http://lists.infradead.org/pipermail/linux-arm-kernel/2022-June/751354.html Regards, Fabio Estevam
Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address
Hi Michal, Am 14.06.2022 um 17:49 schrieb Michal Simek: On 6/14/22 17:34, Stefan Herbrechtsmeier wrote: Hi, Am 14.06.2022 um 15:03 schrieb Michal Simek: Hi, On 6/13/22 11:02, Stefan Herbrechtsmeier wrote: [CAUTION: External Email] Hi Michal, Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier: Hi Michal, Am 13.06.2022 um 09:20 schrieb Michal Simek: Hi, On 6/10/22 18:48, Xavier Drudis Ferran wrote: El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia: Hi Michal, what is the default entry address for the aft / bl31.bin? I have a bl31.bin with an entry address of 0x1000 and this is inside the BSS. Me too, load address at 0x1000, but for me in SPL text, not BSS. I have a litle customized, a little old TF-A for rk3399 / Rock pi 4 loading at address 0 with entry at 0x1000. But include/configs/rk3399_common.h sets my CONFIG_SPL_BSS_START_ADDR=0x40, away from harm. I had problems booting anyway. Now I can load U-Boot from MMC with these patches https://lists.denx.de/pipermail/u-boot/2022-June/485497.html In particular CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000 This is defined in arch/arm/mach-rockchip/Kconfig and says it's to avoid conflicts with SPL text area, not BSS But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000, so I thought some low addresses where normal. I don't know. I had to modify the code loading from SPI because, unlike MMC code, it thought address 0 meant no destination (I can send those patches when I have them cleaner if anyone wants them). I just realised that I have CONFIG_SPL_TEXT_BASE=0x0. I'm not finding where that's defined, maybe it's simply because it's not defined anywhere, so maybe the solution for me would be setting CONFIG_SPL_TEXT_BASE to 0x1000 or something. Or maybe it needs to be at 0x0 because it is bootrom who is loading it, and it won't look where I define it? I can't remember whether I tried this. Maybe you can try to look at the size of a file bl31_0x.bin that is generated when you build U-boot with BL31 pointing at your bl31.elf (check u-boot.its if that's not the name for you). Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load property in entry atf_1 of u-boot.its). This should leave a hole at the beginning of U-Boot to make room for your TF-A, and leave BSS elsewhere. The sources and build scripts for TF-A are public, so maybe one could look at what's the criteria for putting images at different addresses? I have no idea what rockchip has to do with memory layout on zynqmp. Anyway SPL must be placed to OCM that's why text base is at 0xfffc where OCM starts and which is also default address where a53s starts. TF-A can be placed to any address but address which I use in SPL flow is 0xfffe5000. PetaLinux which uses FSBL is using different address 0xfffea000 which is default in TF-A. In DDR I normally use end of low ddr locations. It means 0x7fxx. And of course you can't place TFA to location which is used by SPL or by u-boot or other SW. Thanks for the information. I will check why our TF-A is linked to the lower DDR and move it back to the default address. The TF-A was build with debug flag [1]: > By default, the Arm-trusted firmware builds for OCM space at address > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by > default with DEBUG=1, it builds for DDR location 0x1000 with build > flag DEBUG=1 mentioned while building. Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A with DEBUG flag should be changed. [1] https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware It is really question what should be default address with DEBUG=1. I tried this diff --git a/plat/xilinx/zynqmp/include/platform_def.h b/plat/xilinx/zynqmp/include/platform_def.h index 9c1600a7b7e3..66bbf30a65a4 100644 --- a/plat/xilinx/zynqmp/include/platform_def.h +++ b/plat/xilinx/zynqmp/include/platform_def.h @@ -40,8 +40,8 @@ # define BL31_BASE U(0xfffea000) # define BL31_LIMIT U(0x1) #else -# define BL31_BASE U(0x1000) -# define BL31_LIMIT U(0x7) +# define BL31_BASE U(0xfff5a000) +# define BL31_LIMIT U(0x1) #endif #else # define BL31_BASE (ZYNQMP_ATF_MEM_BASE) And with the latest TF-A this works fine. No problem to change TF-A code to place it to different addresses. I think it should stay in OCM if possible or allocate space at the end of of low ddr address. It means any 0x7fxx address should be fine. With any SPD on we won't be able to fit OCM anyway. Thanks for your work. I think it should stay in OCM and we should use the lower DDR address for BSS. that sort of mean that you want the change above to be upstream. Do you want me to send the patch or do you want to send it patch there? Would
Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT
On Tue, Jun 14, 2022 at 09:14:03AM -0700, Tim Harvey wrote:
> On Mon, Jun 13, 2022 at 7:57 PM Tom Rini wrote:
> >
> > Move the environment text over from being set via
> > CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> > to plain text in board/gateworks/gw_ventana/gw_ventana.env. This lets
> > us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> > single environment file now.
> >
> > Cc: Tim Harvey
> > Signed-off-by: Tom Rini
> > ---
> > board/gateworks/gw_ventana/gw_ventana.env | 145 +
> > include/configs/gw_ventana.h | 148 --
> > 2 files changed, 145 insertions(+), 148 deletions(-)
> > create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
> >
> > diff --git a/board/gateworks/gw_ventana/gw_ventana.env
> > b/board/gateworks/gw_ventana/gw_ventana.env
> > new file mode 100644
> > index ..9a316c74f215
> > --- /dev/null
> > +++ b/board/gateworks/gw_ventana/gw_ventana.env
> > @@ -0,0 +1,145 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2013 Gateworks Corporation
> > + */
> > +
> > +splashpos=m,m
> > +splashimage=CONFIG_SYS_LOAD_ADDR
> > +usb_pgood_delay=2000
> > +console=ttymxc1
> > +bootdevs=usb mmc sata flash
> > +hwconfig=_UNKNOWN_
> > +
> > +disk=0
> > +part=1
> > +
> > +fdt_high=0x
> > +fdt_addr=0x1800
> > +initrd_high=0x
> > +fixfdt=fdt addr ${fdt_addr}
> > +bootdir=boot
> > +loadfdt=
> > + if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> > + echo Loaded DTB from ${bootdir}/${fdt_file};
> > + run fixfdt;
> > + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> > + echo Loaded DTB from ${bootdir}/${fdt_file1};
> > + run fixfdt;
> > + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> > + echo Loaded DTB from ${bootdir}/${fdt_file2};
> > + run fixfdt;
> > + fi
> > +
> > +fs=ext4
> > +script=6x_bootscript-ventana
> > +loadscript=
> > + if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> > + source ${loadaddr};
> > + fi
> > +
> > +uimage=uImage
> > +mmc_root=mmcblk0p1
> > +mmc_boot=
> > + setenv fsload "${fs}load mmc ${disk}:${part}";
> > + mmc dev ${disk} && mmc rescan &&
> > + setenv dtype mmc; run loadscript;
> > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > + setenv bootargs console=${console},${baudrate}
> > + root=/dev/${mmc_root} rootfstype=${fs}
> > + rootwait rw ${video} ${extra};
> > + if run loadfdt; then
> > + bootm ${loadaddr} - ${fdt_addr};
> > + else
> > + bootm;
> > + fi;
> > + fi
> > +
> > +sata_boot=
> > + setenv fsload "${fs}load sata ${disk}:${part}";
> > + sata init &&
> > + setenv dtype sata; run loadscript;
> > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > + setenv bootargs console=${console},${baudrate}
> > + root=/dev/sda1 rootfstype=${fs}
> > + rootwait rw ${video} ${extra};
> > + if run loadfdt; then
> > + bootm ${loadaddr} - ${fdt_addr};
> > + else
> > + bootm;
> > + fi;
> > + fi
> > +
> > +usb_boot=
> > + setenv fsload "${fs}load usb ${disk}:${part}";
> > + usb start && usb dev ${disk} &&
> > + setenv dtype usb; run loadscript;
> > + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> > + setenv bootargs console=${console},${baudrate}
> > + root=/dev/sda1 rootfstype=${fs}
> > + rootwait rw ${video} ${extra};
> > + if run loadfdt; then
> > + bootm ${loadaddr} - ${fdt_addr};
> > + else
> > + bootm;
> > + fi;
> > + fi
> > +
> > +#ifdef CONFIG_SPI_FLASH
> > +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> > +image_uboot=ventana/u-boot_spi.imx
> > +
> > +spi_koffset=0x9
> > +spi_klen=0x20
> > +
> > +spi_updateuboot=echo Updating uboot from
> > + ${serverip}:${image_uboot}...;
> > + tftpboot ${loadaddr} ${image_uboot} &&
> > + sf probe && sf erase 0 8 &&
> > + sf write ${loadaddr} 400 ${filesize}
> > +spi_update=echo Updating OS from ${serverip}:${image_os}
> > + to ${spi_koffset} ...;
> > + tftp ${loadaddr} ${image_os} &&
> > + sf probe &&
> > + sf update ${loadaddr} ${spi_koffset} ${filesize}
> > +
> > +flash_boot=
> > + if sf probe &&
> > + sf read ${loadaddr} ${spi_koffset} ${spi_klen}; then
> > + setenv bootargs console=${console},${baudrate}
> > + root=/dev/mtdblock3
> > +
Re: [PATCH 8/8] gw_ventana: Migrate to using CONFIG_EXTRA_ENV_TEXT
On Mon, Jun 13, 2022 at 7:57 PM Tom Rini wrote:
>
> Move the environment text over from being set via
> CONFIG_EXTRA_ENV_SETTINGS in include/configs/gw_ventana.h and over
> to plain text in board/gateworks/gw_ventana/gw_ventana.env. This lets
> us drop CONFIG_EXTRA_ENV_SETTINGS_COMMON as everything resides in a
> single environment file now.
>
> Cc: Tim Harvey
> Signed-off-by: Tom Rini
> ---
> board/gateworks/gw_ventana/gw_ventana.env | 145 +
> include/configs/gw_ventana.h | 148 --
> 2 files changed, 145 insertions(+), 148 deletions(-)
> create mode 100644 board/gateworks/gw_ventana/gw_ventana.env
>
> diff --git a/board/gateworks/gw_ventana/gw_ventana.env
> b/board/gateworks/gw_ventana/gw_ventana.env
> new file mode 100644
> index ..9a316c74f215
> --- /dev/null
> +++ b/board/gateworks/gw_ventana/gw_ventana.env
> @@ -0,0 +1,145 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2013 Gateworks Corporation
> + */
> +
> +splashpos=m,m
> +splashimage=CONFIG_SYS_LOAD_ADDR
> +usb_pgood_delay=2000
> +console=ttymxc1
> +bootdevs=usb mmc sata flash
> +hwconfig=_UNKNOWN_
> +
> +disk=0
> +part=1
> +
> +fdt_high=0x
> +fdt_addr=0x1800
> +initrd_high=0x
> +fixfdt=fdt addr ${fdt_addr}
> +bootdir=boot
> +loadfdt=
> + if ${fsload} ${fdt_addr} ${bootdir}/${fdt_file}; then
> + echo Loaded DTB from ${bootdir}/${fdt_file};
> + run fixfdt;
> + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file1}; then
> + echo Loaded DTB from ${bootdir}/${fdt_file1};
> + run fixfdt;
> + elif ${fsload} ${fdt_addr} ${bootdir}/${fdt_file2}; then
> + echo Loaded DTB from ${bootdir}/${fdt_file2};
> + run fixfdt;
> + fi
> +
> +fs=ext4
> +script=6x_bootscript-ventana
> +loadscript=
> + if ${fsload} ${loadaddr} ${bootdir}/${script}; then
> + source ${loadaddr};
> + fi
> +
> +uimage=uImage
> +mmc_root=mmcblk0p1
> +mmc_boot=
> + setenv fsload "${fs}load mmc ${disk}:${part}";
> + mmc dev ${disk} && mmc rescan &&
> + setenv dtype mmc; run loadscript;
> + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> + setenv bootargs console=${console},${baudrate}
> + root=/dev/${mmc_root} rootfstype=${fs}
> + rootwait rw ${video} ${extra};
> + if run loadfdt; then
> + bootm ${loadaddr} - ${fdt_addr};
> + else
> + bootm;
> + fi;
> + fi
> +
> +sata_boot=
> + setenv fsload "${fs}load sata ${disk}:${part}";
> + sata init &&
> + setenv dtype sata; run loadscript;
> + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> + setenv bootargs console=${console},${baudrate}
> + root=/dev/sda1 rootfstype=${fs}
> + rootwait rw ${video} ${extra};
> + if run loadfdt; then
> + bootm ${loadaddr} - ${fdt_addr};
> + else
> + bootm;
> + fi;
> + fi
> +
> +usb_boot=
> + setenv fsload "${fs}load usb ${disk}:${part}";
> + usb start && usb dev ${disk} &&
> + setenv dtype usb; run loadscript;
> + if ${fsload} ${loadaddr} ${bootdir}/${uimage}; then
> + setenv bootargs console=${console},${baudrate}
> + root=/dev/sda1 rootfstype=${fs}
> + rootwait rw ${video} ${extra};
> + if run loadfdt; then
> + bootm ${loadaddr} - ${fdt_addr};
> + else
> + bootm;
> + fi;
> + fi
> +
> +#ifdef CONFIG_SPI_FLASH
> +image_os=ventana/openwrt-imx6-imx6q-gw5400-a-squashfs.bin
> +image_uboot=ventana/u-boot_spi.imx
> +
> +spi_koffset=0x9
> +spi_klen=0x20
> +
> +spi_updateuboot=echo Updating uboot from
> + ${serverip}:${image_uboot}...;
> + tftpboot ${loadaddr} ${image_uboot} &&
> + sf probe && sf erase 0 8 &&
> + sf write ${loadaddr} 400 ${filesize}
> +spi_update=echo Updating OS from ${serverip}:${image_os}
> + to ${spi_koffset} ...;
> + tftp ${loadaddr} ${image_os} &&
> + sf probe &&
> + sf update ${loadaddr} ${spi_koffset} ${filesize}
> +
> +flash_boot=
> + if sf probe &&
> + sf read ${loadaddr} ${spi_koffset} ${spi_klen}; then
> + setenv bootargs console=${console},${baudrate}
> + root=/dev/mtdblock3
> + rootfstype=squashfs,jffs2
> + ${video} ${extra};
> + bootm;
> + fi
> +#else
> +image_rootfs=openwrt-imx6-ventana-rootfs.ubi
> +nand_update=echo Updating NAND from ${serverip}:${image_rootfs}...;
> + tftp ${loadaddr} ${image_rootfs} &&
> + nand erase.part rootfs &&
> +
Pull request, u-boot-tegra/master
Tom, Please pull u-boot-tegra/master into U-Boot/master. Thanks. The following changes since commit 92a8bc6b419f548230f10a924db2b3ef10a5edad: Merge tag 'efi-2022-07-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-06-13 09:33:37 -0400) are available in the git repository at: https://source.denx.de/u-boot/custodians/u-boot-tegra.git master for you to fetch changes up to 8f27bf114ef48e681f00fcb38ad48d4ab581d0ca: board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt (2022-06-13 15:31:15 -0700) Marcel Ziswiler (1): board: apalis_t30/tk1/colibri_t20/t30: integrate mac address via dt Peter Robinson (3): ARM: tegra: XUSB padctl: Add new lines for errors pci: tegra: Update error prints with new lines arm: tegra: Update some DT compatibles arch/arm/mach-tegra/xusb-padctl-common.c | 12 ++-- board/toradex/apalis-tk1/apalis-tk1.c| 19 +++ board/toradex/apalis_t30/apalis_t30.c| 20 board/toradex/colibri_t20/colibri_t20.c | 19 +++ board/toradex/colibri_t30/colibri_t30.c | 20 drivers/i2c/tegra_i2c.c | 1 + drivers/pci/pci_tegra.c | 4 ++-- drivers/video/tegra124/dp.c | 1 + 8 files changed, 88 insertions(+), 8 deletions(-)
Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address
On 6/14/22 17:34, Stefan Herbrechtsmeier wrote: Hi, Am 14.06.2022 um 15:03 schrieb Michal Simek: Hi, On 6/13/22 11:02, Stefan Herbrechtsmeier wrote: [CAUTION: External Email] Hi Michal, Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier: Hi Michal, Am 13.06.2022 um 09:20 schrieb Michal Simek: Hi, On 6/10/22 18:48, Xavier Drudis Ferran wrote: El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia: Hi Michal, what is the default entry address for the aft / bl31.bin? I have a bl31.bin with an entry address of 0x1000 and this is inside the BSS. Me too, load address at 0x1000, but for me in SPL text, not BSS. I have a litle customized, a little old TF-A for rk3399 / Rock pi 4 loading at address 0 with entry at 0x1000. But include/configs/rk3399_common.h sets my CONFIG_SPL_BSS_START_ADDR=0x40, away from harm. I had problems booting anyway. Now I can load U-Boot from MMC with these patches https://lists.denx.de/pipermail/u-boot/2022-June/485497.html In particular CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000 This is defined in arch/arm/mach-rockchip/Kconfig and says it's to avoid conflicts with SPL text area, not BSS But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000, so I thought some low addresses where normal. I don't know. I had to modify the code loading from SPI because, unlike MMC code, it thought address 0 meant no destination (I can send those patches when I have them cleaner if anyone wants them). I just realised that I have CONFIG_SPL_TEXT_BASE=0x0. I'm not finding where that's defined, maybe it's simply because it's not defined anywhere, so maybe the solution for me would be setting CONFIG_SPL_TEXT_BASE to 0x1000 or something. Or maybe it needs to be at 0x0 because it is bootrom who is loading it, and it won't look where I define it? I can't remember whether I tried this. Maybe you can try to look at the size of a file bl31_0x.bin that is generated when you build U-boot with BL31 pointing at your bl31.elf (check u-boot.its if that's not the name for you). Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load property in entry atf_1 of u-boot.its). This should leave a hole at the beginning of U-Boot to make room for your TF-A, and leave BSS elsewhere. The sources and build scripts for TF-A are public, so maybe one could look at what's the criteria for putting images at different addresses? I have no idea what rockchip has to do with memory layout on zynqmp. Anyway SPL must be placed to OCM that's why text base is at 0xfffc where OCM starts and which is also default address where a53s starts. TF-A can be placed to any address but address which I use in SPL flow is 0xfffe5000. PetaLinux which uses FSBL is using different address 0xfffea000 which is default in TF-A. In DDR I normally use end of low ddr locations. It means 0x7fxx. And of course you can't place TFA to location which is used by SPL or by u-boot or other SW. Thanks for the information. I will check why our TF-A is linked to the lower DDR and move it back to the default address. The TF-A was build with debug flag [1]: > By default, the Arm-trusted firmware builds for OCM space at address > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by > default with DEBUG=1, it builds for DDR location 0x1000 with build > flag DEBUG=1 mentioned while building. Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A with DEBUG flag should be changed. [1] https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware It is really question what should be default address with DEBUG=1. I tried this diff --git a/plat/xilinx/zynqmp/include/platform_def.h b/plat/xilinx/zynqmp/include/platform_def.h index 9c1600a7b7e3..66bbf30a65a4 100644 --- a/plat/xilinx/zynqmp/include/platform_def.h +++ b/plat/xilinx/zynqmp/include/platform_def.h @@ -40,8 +40,8 @@ # define BL31_BASE U(0xfffea000) # define BL31_LIMIT U(0x1) #else -# define BL31_BASE U(0x1000) -# define BL31_LIMIT U(0x7) +# define BL31_BASE U(0xfff5a000) +# define BL31_LIMIT U(0x1) #endif #else # define BL31_BASE (ZYNQMP_ATF_MEM_BASE) And with the latest TF-A this works fine. No problem to change TF-A code to place it to different addresses. I think it should stay in OCM if possible or allocate space at the end of of low ddr address. It means any 0x7fxx address should be fine. With any SPD on we won't be able to fit OCM anyway. Thanks for your work. I think it should stay in OCM and we should use the lower DDR address for BSS. that sort of mean that you want the change above to be upstream. Do you want me to send the patch or do you want to send it patch there? M
Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address
Hi, Am 14.06.2022 um 15:03 schrieb Michal Simek: Hi, On 6/13/22 11:02, Stefan Herbrechtsmeier wrote: [CAUTION: External Email] Hi Michal, Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier: Hi Michal, Am 13.06.2022 um 09:20 schrieb Michal Simek: Hi, On 6/10/22 18:48, Xavier Drudis Ferran wrote: El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia: Hi Michal, what is the default entry address for the aft / bl31.bin? I have a bl31.bin with an entry address of 0x1000 and this is inside the BSS. Me too, load address at 0x1000, but for me in SPL text, not BSS. I have a litle customized, a little old TF-A for rk3399 / Rock pi 4 loading at address 0 with entry at 0x1000. But include/configs/rk3399_common.h sets my CONFIG_SPL_BSS_START_ADDR=0x40, away from harm. I had problems booting anyway. Now I can load U-Boot from MMC with these patches https://lists.denx.de/pipermail/u-boot/2022-June/485497.html In particular CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000 This is defined in arch/arm/mach-rockchip/Kconfig and says it's to avoid conflicts with SPL text area, not BSS But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000, so I thought some low addresses where normal. I don't know. I had to modify the code loading from SPI because, unlike MMC code, it thought address 0 meant no destination (I can send those patches when I have them cleaner if anyone wants them). I just realised that I have CONFIG_SPL_TEXT_BASE=0x0. I'm not finding where that's defined, maybe it's simply because it's not defined anywhere, so maybe the solution for me would be setting CONFIG_SPL_TEXT_BASE to 0x1000 or something. Or maybe it needs to be at 0x0 because it is bootrom who is loading it, and it won't look where I define it? I can't remember whether I tried this. Maybe you can try to look at the size of a file bl31_0x.bin that is generated when you build U-boot with BL31 pointing at your bl31.elf (check u-boot.its if that's not the name for you). Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load property in entry atf_1 of u-boot.its). This should leave a hole at the beginning of U-Boot to make room for your TF-A, and leave BSS elsewhere. The sources and build scripts for TF-A are public, so maybe one could look at what's the criteria for putting images at different addresses? I have no idea what rockchip has to do with memory layout on zynqmp. Anyway SPL must be placed to OCM that's why text base is at 0xfffc where OCM starts and which is also default address where a53s starts. TF-A can be placed to any address but address which I use in SPL flow is 0xfffe5000. PetaLinux which uses FSBL is using different address 0xfffea000 which is default in TF-A. In DDR I normally use end of low ddr locations. It means 0x7fxx. And of course you can't place TFA to location which is used by SPL or by u-boot or other SW. Thanks for the information. I will check why our TF-A is linked to the lower DDR and move it back to the default address. The TF-A was build with debug flag [1]: > By default, the Arm-trusted firmware builds for OCM space at address > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by > default with DEBUG=1, it builds for DDR location 0x1000 with build > flag DEBUG=1 mentioned while building. Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A with DEBUG flag should be changed. [1] https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware It is really question what should be default address with DEBUG=1. I tried this diff --git a/plat/xilinx/zynqmp/include/platform_def.h b/plat/xilinx/zynqmp/include/platform_def.h index 9c1600a7b7e3..66bbf30a65a4 100644 --- a/plat/xilinx/zynqmp/include/platform_def.h +++ b/plat/xilinx/zynqmp/include/platform_def.h @@ -40,8 +40,8 @@ # define BL31_BASE U(0xfffea000) # define BL31_LIMIT U(0x1) #else -# define BL31_BASE U(0x1000) -# define BL31_LIMIT U(0x7) +# define BL31_BASE U(0xfff5a000) +# define BL31_LIMIT U(0x1) #endif #else # define BL31_BASE (ZYNQMP_ATF_MEM_BASE) And with the latest TF-A this works fine. No problem to change TF-A code to place it to different addresses. I think it should stay in OCM if possible or allocate space at the end of of low ddr address. It means any 0x7fxx address should be fine. With any SPD on we won't be able to fit OCM anyway. Thanks for your work. I think it should stay in OCM and we should use the lower DDR address for BSS. Regards Stefan
[PATCH 5/5] configs: am62x_evm_r5: Add CONFIG_NR_DRAM_BANKS as done in a53 defconfig
Add CONFIG_NR_DRAM_BANKS from am62x_evm_a53_defconfig as this is needed to calculate the size of DDR that is available. Signed-off-by: Georgi Vlaev --- configs/am62x_evm_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig index 2e340cd6f416..deafb92fc142 100644 --- a/configs/am62x_evm_r5_defconfig +++ b/configs/am62x_evm_r5_defconfig @@ -3,6 +3,7 @@ CONFIG_ARCH_K3=y CONFIG_SYS_MALLOC_F_LEN=0x9000 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y CONFIG_TARGET_AM625_R5_EVM=y CONFIG_DM_GPIO=y -- 2.30.2
[PATCH 4/5] board: ti: am62x: Account for DDR size fixups if ECC is enabled
Call into k3-ddrss driver to fixup device tree and resize
the available amount of DDR if ECC is enabled.
A second fixup is required from A53 SPL to take the fixup
as done from R5 SPL and apply it to DT passed to A53 U-boot,
which in turn passes this to the OS.
Signed-off-by: Georgi Vlaev
---
board/ti/am62x/evm.c | 53
1 file changed, 53 insertions(+)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index fb5106d1f3c8..d65ee1d69606 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -9,6 +9,8 @@
#include
#include
+#include
+#include
#include
#include
#include
@@ -30,3 +32,54 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_K3_AM64_DDRSS)
+static void fixup_ddr_driver_for_ecc(struct spl_image_info *spl_image)
+{
+ struct udevice *dev;
+ int ret;
+
+ dram_init_banksize();
+
+ ret = uclass_get_device(UCLASS_RAM, 0, );
+ if (ret)
+ panic("Cannot get RAM device for ddr size fixup: %d\n", ret);
+
+ ret = k3_ddrss_ddr_fdt_fixup(dev, spl_image->fdt_addr, gd->bd);
+ if (ret)
+ printf("Error fixing up ddr node for ECC use! %d\n", ret);
+}
+#else
+static void fixup_memory_node(struct spl_image_info *spl_image)
+{
+ u64 start[CONFIG_NR_DRAM_BANKS];
+ u64 size[CONFIG_NR_DRAM_BANKS];
+ int bank;
+ int ret;
+
+ dram_init();
+ dram_init_banksize();
+
+ for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+ start[bank] = gd->bd->bi_dram[bank].start;
+ size[bank] = gd->bd->bi_dram[bank].size;
+ }
+
+ /* dram_init functions use SPL fdt, and we must fixup u-boot fdt */
+ ret = fdt_fixup_memory_banks(spl_image->fdt_addr, start, size,
+CONFIG_NR_DRAM_BANKS);
+ if (ret)
+ printf("Error fixing up memory node! %d\n", ret);
+}
+#endif
+
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+#if defined(CONFIG_K3_AM64_DDRSS)
+ fixup_ddr_driver_for_ecc(spl_image);
+#else
+ fixup_memory_node(spl_image);
+#endif
+}
+#endif
--
2.30.2
[PATCH 3/5] board: ti: am62x: Use fdt functions for ram and bank init
Use the appropriate fdtdec_setup_mem_size_base() call in
dram_init() and fdtdec_setup_bank_size() in dram_bank_init()
to pull these values from DT, where they are already available,
instead of hardcoding them.
Signed-off-by: Georgi Vlaev
---
board/ti/am62x/evm.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 4dd5e64299bf..fb5106d1f3c8 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -23,17 +23,10 @@ int board_init(void)
int dram_init(void)
{
- gd->ram_size = 0x8000;
-
- return 0;
+ return fdtdec_setup_mem_size_base();
}
int dram_init_banksize(void)
{
- /* Bank 0 declares the memory available in the DDR low region */
- gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
- gd->bd->bi_dram[0].size = 0x8000;
- gd->ram_size = 0x8000;
-
- return 0;
+ return fdtdec_setup_memory_banksize();
}
--
2.30.2
[PATCH 2/5] arm: dts: k3-am625-*: Mark memory with u-boot,dm-spl
Mark the memory node with u-boot,dm-spl so we can use it
from early SPL on both R5 and A53.
Signed-off-by: Georgi Vlaev
---
arch/arm/dts/k3-am625-r5-sk.dts | 1 +
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 2691af40a145..5aab858edd14 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -28,6 +28,7 @@
/* 2G RAM */
reg = <0x 0x8000 0x 0x8000>;
+ u-boot,dm-spl;
};
reserved-memory {
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index e1971ecdfedb..159fa36bbe9f 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -13,6 +13,10 @@
aliases {
mmc1 =
};
+
+ memory@8000 {
+ u-boot,dm-spl;
+ };
};
_main{
--
2.30.2
[PATCH 1/5] arm: mach-k3: common: Use ddr_init in spl_enable_dcache
The spl_enable_dcache() function calls dram_init_banksize() to get the total memory size. Normally the dram_init_banksize() setups the memory banks, while the total size is reported by ddr_init(). This worked so far for K3 since we set the gd->ram_size in dram_init_banksize() as well. Signed-off-by: Georgi Vlaev --- arch/arm/mach-k3/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c index b4b75f4e6c86..70f6444e7988 100644 --- a/arch/arm/mach-k3/common.c +++ b/arch/arm/mach-k3/common.c @@ -516,7 +516,7 @@ void spl_enable_dcache(void) #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF)) phys_addr_t ram_top = CONFIG_SYS_SDRAM_BASE; - dram_init_banksize(); + dram_init(); /* reserve TLB table */ gd->arch.tlb_size = PGTABLE_SIZE; -- 2.30.2
[PATCH 0/5] board: ti: am62x: Add support for 1-bit inline DDRSS ECC
Hi, This series enables the 1-bit inline DDR ECC support in the TI DDRSS bridge for AM62x. The base DDRSS ECC support was merged for k3-ddrss in a previous series for AM64x [1]. The ECC data is stored together with the data, which will reduce the total available memory with 1/9th. The k3-ddrss driver enables the ECC support and primes the full memory from the R5 SPL, so the the memory size changes must propagate from the R5 SPL to A53 SPL and then to A53 u-boot. The patches are similar to those we have for AM64x, with one exception: "arm: mach-k3: common: Use ddr_init in spl_enable_dcache". Since we've switched the boards to DT to fetch the memory configuration, dram_init_banksize() will no longer set the total memory size in the global data. And spl_enable_dcache() uses dram_init_banksize() instead of dram_init(), which actually sets the memory base/size. Note this doesn't enable the 1-bit ECC on any platform by default. This can be done by adding the "ti,ecc-enable" property to the memorycontroller node in k3-am6*-ddr.dtsi. [1] https://lore.kernel.org/u-boot/20220317170346.31162-1-d-gerl...@ti.com/ The patches depend on the base AM62 support, which was recently merged in u-boot/next. Georgi Vlaev (5): arm: mach-k3: common: Use ddr_init in spl_enable_dcache arm: dts: k3-am625-*: Mark memory with u-boot,dm-spl board: ti: am62x: Use fdt functions for ram and bank init board: ti: am62x: Account for DDR size fixups if ECC is enabled configs: am62x_evm_r5: Add CONFIG_NR_DRAM_BANKS as done in a53 defconfig arch/arm/dts/k3-am625-r5-sk.dts | 1 + arch/arm/dts/k3-am625-sk-u-boot.dtsi | 4 ++ arch/arm/mach-k3/common.c| 2 +- board/ti/am62x/evm.c | 62 configs/am62x_evm_r5_defconfig | 1 + 5 files changed, 61 insertions(+), 9 deletions(-) base-commit: a87a6fcd20c0e29fe55bfbb6917c4aa1f1bbce74 -- 2.30.2
Re: [PATCH 1/1] efi_loader: initialize console size late
Hi,
Am Di., 14. Juni 2022 um 08:02 Uhr schrieb Heinrich Schuchardt
:
>
> From: Heinrich Schuchardt
>
> If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> Especially when using a remote console the response can be so late that
> it interferes with autoboot.
>
> Only query the console size when running an EFI binary.
>
> Add debug output showing the determined console size.
>
> Reported-by: Fabio Estevam
> Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk
> objects from udevice")
> Signed-off-by: Heinrich Schuchardt
Tested-by: Heiko Thiery
Tested on an imx8mn-ddr3l-evk board.
Thank you
--
Heiko
> ---
> include/efi_loader.h | 2 ++
> lib/efi_loader/efi_console.c | 20 +---
> lib/efi_loader/efi_setup.c | 4
> 3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f6651e2c60..c1e00ebac3 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
> int efi_init_early(void);
> /* Initialize efi execution environment */
> efi_status_t efi_init_obj_list(void);
> +/* Set up console modes */
> +void efi_setup_console_size(void);
> /* Install device tree */
> efi_status_t efi_install_fdt(void *fdt);
> /* Run loaded UEFI image */
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 60a3fc85ac..3164fd484e 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -5,6 +5,8 @@
> * Copyright (c) 2016 Alexander Graf
> */
>
> +#define LOG_CATEGORY LOGC_EFI
> +
> #include
> #include
> #include
> @@ -12,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
> #define cESC '\x1b'
> #define ESC "\x1b"
>
> -/* Default to mode 0 */
> +/*
> + * efi_con_mode - mode information of the Simple Text Output Protocol
> + *
> + * Use safe settings before efi_setup_console_size() is called.
> + * By default enable only the 80x25 mode which must always exist.
> + */
> static struct simple_text_output_mode efi_con_mode = {
> .max_mode = 1,
> .mode = 0,
> @@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int *rows,
> int *cols)
> }
>
> /**
> - * query_console_size() - update the mode table.
> + * efi_setup_console_size() - update the mode table.
> *
> * By default the only mode available is 80x25. If the console has at least
> 50
> * lines, enable mode 80x50. If we can query the console size and it is
> neither
> * 80x25 nor 80x50, set it as an additional mode.
> */
> -static void query_console_size(void)
> +void efi_setup_console_size(void)
> {
> int rows = 25, cols = 80;
> int ret = -ENODEV;
> @@ -351,6 +359,8 @@ static void query_console_size(void)
> if (ret)
> return;
>
> + log_debug("Console size %dx%d\n", rows, cols);
> +
> /* Test if we can have Mode 1 */
> if (cols >= 80 && rows >= 50) {
> efi_cout_modes[1].present = 1;
> @@ -371,7 +381,6 @@ static void query_console_size(void)
> }
> }
>
> -
> /**
> * efi_cout_query_mode() - get terminal size for a text mode
> *
> @@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
> efi_status_t r;
> struct efi_device_path *dp;
>
> - /* Set up mode information */
> - query_console_size();
> -
> /* Install protocols on root node */
> r = EFI_CALL(efi_install_multiple_protocol_interfaces
> (_root,
> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> index 250eeb2fcd..492ecf4cb1 100644
> --- a/lib/efi_loader/efi_setup.c
> +++ b/lib/efi_loader/efi_setup.c
> @@ -243,6 +243,10 @@ efi_status_t efi_init_obj_list(void)
> goto out;
> }
>
> + /* Set up console modes */
> + efi_setup_console_size();
> +
> + /* Install EFI_RNG_PROTOCOL */
> if (IS_ENABLED(CONFIG_EFI_RNG_PROTOCOL)) {
> ret = efi_rng_register();
> if (ret != EFI_SUCCESS)
> --
> 2.36.1
>
[PATCH] spl: fit: Allocate buffers aligned to cache line size
From: Stefan Herbrechtsmeier
Allocate memory for buffers at a cache-line boundary to avoid
misaligned buffer address for subsequent reads. This avoids an
additional sector-based memory copy in the fat file system driver:
FAT: Misaligned buffer address (...)
Signed-off-by: Stefan Herbrechtsmeier
---
common/spl/spl_fit.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 1bbf824684..d61e1556ae 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -429,7 +429,9 @@ static int spl_fit_append_fdt(struct spl_image_info
*spl_image,
* depending on how the overlay is stored, so
* don't fail yet if the allocation failed.
*/
- tmpbuffer =
malloc(CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ);
+ size_t size =
CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY_BUF_SZ;
+
+ tmpbuffer = malloc_cache_aligned(size);
if (!tmpbuffer)
debug("%s: unable to allocate space for
overlays\n",
__func__);
@@ -537,7 +539,7 @@ static void *spl_get_fit_load_buffer(size_t size)
{
void *buf;
- buf = malloc(size);
+ buf = malloc_cache_aligned(size);
if (!buf) {
pr_err("Could not get FIT buffer of %lu bytes\n", (ulong)size);
pr_err("\tcheck CONFIG_SYS_SPL_MALLOC_SIZE\n");
--
2.30.2
Re: [PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET
On 6/14/22 3:44 AM, Corentin LABBE wrote:
The origin of this patch is the breaking of am335x-hs boot
due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
HS boards have less SRAM for SPL and so this commit increased memory usage
beyond am335x limit.
This commit added 10 driver binding pass and am335x boot only if one pass is
done.
SPL try to do more than one pass due to eth_cpsw failing.
Since HS SPL does not need network (and NET is already disabled in config),
the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.
Signed-off-by: Corentin LABBE
---
If no one was using this data I wonder if the compiler could have removed
it with LTO enabled.. Something to think on.
Acked-by: Andrew Davis
board/ti/am335x/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 7c0545892c..2cb5b1cb3f 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -902,7 +902,7 @@ int board_late_init(void)
#endif
/* CPSW plat */
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(NET) && !CONFIG_IS_ENABLED(OF_CONTROL)
struct cpsw_slave_data slave_data[] = {
{
.slave_reg_ofs = CPSW_SLAVE0_OFFSET,
Re: [PATCH v3 0/2] usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver
Did this fix the CI issues now ? On 2022-05-30 10:15, Angus Ainslie wrote: Changes since v2: Add a second patch to deal with CI failures due to the new options. Changes since v1: Updated Kconfig depends Angus Ainslie (2): usb: dwc3: add a SPL_USB_DWC3_GENERIC option for the dwc3 driver configs: get rid of build warnings due to SPL_USB_DWC3_GENERIC configs/am43xx_evm_defconfig | 2 ++ configs/am43xx_evm_usbhost_boot_defconfig | 2 ++ configs/am43xx_hs_evm_defconfig | 2 ++ configs/am57xx_hs_evm_usb_defconfig | 2 ++ configs/am65x_evm_a53_defconfig | 2 ++ configs/am65x_evm_r5_usbdfu_defconfig | 2 ++ configs/dra7xx_evm_defconfig | 2 ++ configs/dra7xx_hs_evm_defconfig | 2 ++ configs/dra7xx_hs_evm_usb_defconfig | 2 ++ drivers/usb/dwc3/Kconfig | 7 +++ drivers/usb/dwc3/Makefile | 2 +- 11 files changed, 26 insertions(+), 1 deletion(-)
[PATCH 2/2] misc: usb251xb: Support 8/16 bit device tree values
From: Stefan Herbrechtsmeier
The device tree binding [1] specify the vendor-id, product-id, device-id
and language-id as 16 bit values and the linux driver reads the boost-up
value as 8 bit value.
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb251xb.txt
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/misc/usb251xb.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/usb251xb.c b/drivers/misc/usb251xb.c
index 077edc2504..a78ad1843a 100644
--- a/drivers/misc/usb251xb.c
+++ b/drivers/misc/usb251xb.c
@@ -400,14 +400,14 @@ static int usb251xb_of_to_plat(struct udevice *dev)
}
}
- if (dev_read_u32(dev, "vendor-id", >vendor_id))
- hub->vendor_id = USB251XB_DEF_VENDOR_ID;
+ hub->vendor_id = dev_read_u16_default(dev, "vendor-id",
+ USB251XB_DEF_VENDOR_ID);
- if (dev_read_u32(dev, "product-id", >product_id))
- hub->product_id = data->product_id;
+ hub->product_id = dev_read_u16_default(dev, "product-id",
+ data->product_id);
- if (dev_read_u32(dev, "device-id", >device_id))
- hub->device_id = USB251XB_DEF_DEVICE_ID;
+ hub->device_id = dev_read_u16_default(dev, "device-id",
+ USB251XB_DEF_DEVICE_ID);
hub->conf_data1 = USB251XB_DEF_CONFIG_DATA_1;
if (dev_read_bool(dev, "self-powered")) {
@@ -513,11 +513,11 @@ static int usb251xb_of_to_plat(struct udevice *dev)
if (!dev_read_u32(dev, "power-on-time-ms", _u32))
hub->power_on_time = min_t(u8, property_u32 / 2, 255);
- if (dev_read_u32(dev, "language-id", >lang_id))
- hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
+ hub->lang_id = dev_read_u16_default(dev, "language-id",
+ USB251XB_DEF_LANGUAGE_ID);
- if (!dev_read_u32(dev, "boost-up", >boost_up))
- hub->boost_up = USB251XB_DEF_BOOST_UP;
+ hub->boost_up = dev_read_u8_default(dev, "boost-up",
+ USB251XB_DEF_BOOST_UP);
cproperty_char = dev_read_string(dev, "manufacturer");
strlcpy(str, cproperty_char ? : USB251XB_DEF_MANUFACTURER_STRING,
--
2.30.2
[PATCH 1/2] dm: core: Add functions to read 8/16-bit integers
From: Stefan Herbrechtsmeier
Add functions to read 8/16-bit integers like the existing functions for
32/64-bit to simplify read of 8/16-bit integers from device tree
properties.
Signed-off-by: Stefan Herbrechtsmeier
---
arch/sandbox/dts/test.dts | 2 ++
drivers/core/of_access.c | 38 +++
drivers/core/ofnode.c | 62 +
drivers/core/read.c | 21 +
include/dm/of_access.h| 32 +++
include/dm/ofnode.h | 40
include/dm/read.h | 65 +++
test/dm/test-fdt.c| 19
8 files changed, 279 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8f93775ff4..035f5edfa2 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -226,6 +226,8 @@
test5-gpios = <_a 19>;
bool-value;
+ int8-value = /bits/ 8 <0x12>;
+ int16-value = /bits/ 16 <0x1234>;
int-value = <1234>;
uint-value = <(-1234)>;
int64-value = /bits/ 64 <0x>;
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index c20b19cb50..0efcde3ba5 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -482,6 +482,44 @@ static void *of_find_property_value_of_size(const struct
device_node *np,
return prop->value;
}
+int of_read_u8(const struct device_node *np, const char *propname, u8 *outp)
+{
+ const u8 *val;
+
+ debug("%s: %s: ", __func__, propname);
+ if (!np)
+ return -EINVAL;
+ val = of_find_property_value_of_size(np, propname, sizeof(*outp));
+ if (IS_ERR(val)) {
+ debug("(not found)\n");
+ return PTR_ERR(val);
+ }
+
+ *outp = *val;
+ debug("%#x (%d)\n", *outp, *outp);
+
+ return 0;
+}
+
+int of_read_u16(const struct device_node *np, const char *propname, u16 *outp)
+{
+ const __be16 *val;
+
+ debug("%s: %s: ", __func__, propname);
+ if (!np)
+ return -EINVAL;
+ val = of_find_property_value_of_size(np, propname, sizeof(*outp));
+ if (IS_ERR(val)) {
+ debug("(not found)\n");
+ return PTR_ERR(val);
+ }
+
+ *outp = be16_to_cpup(val);
+ debug("%#x (%d)\n", *outp, *outp);
+
+ return 0;
+}
+
int of_read_u32(const struct device_node *np, const char *propname, u32 *outp)
{
return of_read_u32_index(np, propname, 0, outp);
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index a59832ebbf..ce411b7c35 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -31,6 +31,68 @@ bool ofnode_name_eq(ofnode node, const char *name)
return (strlen(name) == len) && !strncmp(node_name, name, len);
}
+int ofnode_read_u8(ofnode node, const char *propname, u8 *outp)
+{
+ const u8 *cell;
+ int len;
+
+ assert(ofnode_valid(node));
+ debug("%s: %s: ", __func__, propname);
+
+ if (ofnode_is_np(node))
+ return of_read_u8(ofnode_to_np(node), propname, outp);
+
+ cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
+ );
+ if (!cell || len < sizeof(*cell)) {
+ debug("(not found)\n");
+ return -EINVAL;
+ }
+ *outp = *cell;
+ debug("%#x (%d)\n", *outp, *outp);
+
+ return 0;
+}
+
+u8 ofnode_read_u8_default(ofnode node, const char *propname, u8 def)
+{
+ assert(ofnode_valid(node));
+ ofnode_read_u8(node, propname, );
+
+ return def;
+}
+
+int ofnode_read_u16(ofnode node, const char *propname, u16 *outp)
+{
+ const fdt16_t *cell;
+ int len;
+
+ assert(ofnode_valid(node));
+ debug("%s: %s: ", __func__, propname);
+
+ if (ofnode_is_np(node))
+ return of_read_u16(ofnode_to_np(node), propname, outp);
+
+ cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
+ );
+ if (!cell || len < sizeof(*cell)) {
+ debug("(not found)\n");
+ return -EINVAL;
+ }
+ *outp = be16_to_cpup(cell);
+ debug("%#x (%d)\n", *outp, *outp);
+
+ return 0;
+}
+
+u16 ofnode_read_u16_default(ofnode node, const char *propname, u16 def)
+{
+ assert(ofnode_valid(node));
+ ofnode_read_u16(node, propname, );
+
+ return def;
+}
+
int ofnode_read_u32(ofnode node, const char *propname, u32 *outp)
{
return ofnode_read_u32_index(node, propname, 0, outp);
diff --git a/drivers/core/read.c b/drivers/core/read.c
index c73508d276..07ab8ab41c 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -13,6 +13,27 @@
#include
#include
+int dev_read_u8(const struct udevice *dev, const char *propname, u8 *outp)
+{
+ return ofnode_read_u8(dev_ofnode(dev), propname, outp);
+}
+
+u8
Re: [PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property
Am 14.06.22 um 15:13 schrieb Fabio Estevam: > Hi Frieder, > > On 14/06/2022 10:03, Frieder Schrempf wrote: >> From: Frieder Schrempf >> >> This was previously needed, but U-Boot is now capable of parsing >> the new "phy-connection-type" property that is already used in >> the main devicetree. >> >> Signed-off-by: Frieder Schrempf > > Should the Subject say "unneeded" instead of "deprecated"? Maybe that would be more appropriate, yes. I just checked the kernel bindings and it seems like in contrast to what I memorized, "phy-mode" is actually not (yet?) marked as deprecated.
Re: [PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property
Hi Frieder, On 14/06/2022 10:03, Frieder Schrempf wrote: From: Frieder Schrempf This was previously needed, but U-Boot is now capable of parsing the new "phy-connection-type" property that is already used in the main devicetree. Signed-off-by: Frieder Schrempf Should the Subject say "unneeded" instead of "deprecated"? Reviewed-by: Fabio Estevam
[PATCH 2/2] imx: kontron-sl-mx8mm: Remove deprecated phy-mode property
From: Frieder Schrempf
This was previously needed, but U-Boot is now capable of parsing
the new "phy-connection-type" property that is already used in
the main devicetree.
Signed-off-by: Frieder Schrempf
---
arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
index 6fdc1968158..2c62f05cec1 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
@@ -41,10 +41,6 @@
u-boot,dm-spl;
};
- {
- phy-mode = "rgmii-rxid";
-};
-
{
u-boot,dm-spl;
u-boot,dm-pre-reloc;
--
2.36.1
[PATCH 1/2] imx: kontron-sl-mx8mm: Sync dts files and fix ethernet
From: Frieder Schrempf
This syncs the devicetree files with the latest Linux kernel (5.19-rc2).
This also fixes the currently broken ethernet support:
Before:
Net: Could not get PHY for FEC0: addr 0
After:
Net: eth0: ethernet@30be
Signed-off-by: Frieder Schrempf
---
arch/arm/dts/imx8mm-kontron-n801x-s.dts| 48 +++---
arch/arm/dts/imx8mm-kontron-n801x-som.dtsi | 6 +--
2 files changed, 8 insertions(+), 46 deletions(-)
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s.dts
b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
index c796d144e22..23be1ec538b 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-s.dts
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s.dts
@@ -6,7 +6,6 @@
/dts-v1/;
#include "imx8mm-kontron-n801x-som.dtsi"
-#include
/ {
model = "Kontron i.MX8MM N801X S";
@@ -81,7 +80,6 @@
regulator-name = "vdd-5v";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- regulator-always-on;
};
};
@@ -124,38 +122,14 @@
#size-cells = <0>;
ethphy: ethernet-phy@0 {
- compatible = "ethernet-phy-id0007.0570";
reg = <0>;
- reset-assert-us = <100>;
- reset-deassert-us = <100>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <15000>;
reset-gpios = < 27 GPIO_ACTIVE_LOW>;
- vsc8531,led-0-mode = ;
- vsc8531,led-1-mode = ;
- vsc8531,led-0-combine-disable;
};
};
};
- {
- dsi_mux_sel: dsi_mux_sel {
- gpio-hog;
- gpios = <14 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "dsi-mux-sel";
- pinctrl-names = "default";
- pinctrl-0 = <_dsi_sel>;
- };
-
- dsi_mux_oe {
- gpio-hog;
- gpios = <15 GPIO_ACTIVE_LOW>;
- output-high;
- line-name = "dsi-mux-oe";
- pinctrl-names = "default";
- pinctrl-0 = <_dsi_oe>;
- };
-};
-
{
clock-frequency = <10>;
pinctrl-names = "default";
@@ -208,7 +182,7 @@
#address-cells = <1>;
#size-cells = <0>;
- usbnet: usbether@1 {
+ usbnet: ethernet@1 {
compatible = "usb424,ec00";
reg = <1>;
local-mac-address = [ 00 00 00 00 00 00 ];
@@ -237,18 +211,6 @@
>;
};
- pinctrl_dsi_sel: dsiselgrp {
- fsl,pins = <
- MX8MM_IOMUXC_SAI1_TXD2_GPIO4_IO14 0x19
- >;
- };
-
- pinctrl_dsi_oe: dsioegrp {
- fsl,pins = <
- MX8MM_IOMUXC_SAI1_TXD3_GPIO4_IO15 0x19
- >;
- };
-
pinctrl_ecspi2: ecspi2grp {
fsl,pins = <
MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO0x82
@@ -362,7 +324,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -374,7 +336,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
index c3418d263eb..8f90eb02550 100644
--- a/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
+++ b/arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
@@ -63,10 +63,10 @@
{
pinctrl-names = "default";
pinctrl-0 = <_ecspi1>;
- cs-gpios = < 9 GPIO_ACTIVE_HIGH>;
+ cs-gpios = < 9 GPIO_ACTIVE_LOW>;
status = "okay";
- spi-flash@0 {
+ flash@0 {
compatible = "mxicy,mx25r1635f", "jedec,spi-nor";
spi-max-frequency = <8000>;
reg = <0>;
@@ -154,7 +154,7 @@
reg_vdd_snvs: LDO2 {
regulator-name = "ldo2";
regulator-min-microvolt = <80>;
- regulator-max-microvolt = <80>;
+ regulator-max-microvolt = <90>;
regulator-boot-on;
regulator-always-on;
};
--
2.36.1
Re: [SPAM] Re: [PATCH v2] xilinx: zynqmp: Do not use 0 as spl bss start address
Hi, On 6/13/22 11:02, Stefan Herbrechtsmeier wrote: [CAUTION: External Email] Hi Michal, Am 13.06.2022 um 10:21 schrieb Stefan Herbrechtsmeier: Hi Michal, Am 13.06.2022 um 09:20 schrieb Michal Simek: Hi, On 6/10/22 18:48, Xavier Drudis Ferran wrote: El Fri, Jun 10, 2022 at 04:42:55PM +0200, Stefan Herbrechtsmeier deia: Hi Michal, what is the default entry address for the aft / bl31.bin? I have a bl31.bin with an entry address of 0x1000 and this is inside the BSS. Me too, load address at 0x1000, but for me in SPL text, not BSS. I have a litle customized, a little old TF-A for rk3399 / Rock pi 4 loading at address 0 with entry at 0x1000. But include/configs/rk3399_common.h sets my CONFIG_SPL_BSS_START_ADDR=0x40, away from harm. I had problems booting anyway. Now I can load U-Boot from MMC with these patches https://lists.denx.de/pipermail/u-boot/2022-June/485497.html In particular CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x15000 This is defined in arch/arm/mach-rockchip/Kconfig and says it's to avoid conflicts with SPL text area, not BSS But I found other boards with CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000, so I thought some low addresses where normal. I don't know. I had to modify the code loading from SPI because, unlike MMC code, it thought address 0 meant no destination (I can send those patches when I have them cleaner if anyone wants them). I just realised that I have CONFIG_SPL_TEXT_BASE=0x0. I'm not finding where that's defined, maybe it's simply because it's not defined anywhere, so maybe the solution for me would be setting CONFIG_SPL_TEXT_BASE to 0x1000 or something. Or maybe it needs to be at 0x0 because it is bootrom who is loading it, and it won't look where I define it? I can't remember whether I tried this. Maybe you can try to look at the size of a file bl31_0x.bin that is generated when you build U-boot with BL31 pointing at your bl31.elf (check u-boot.its if that's not the name for you). Then set CONFIG_SPL_BSS_START_ADDR to that size + L (L= value of load property in entry atf_1 of u-boot.its). This should leave a hole at the beginning of U-Boot to make room for your TF-A, and leave BSS elsewhere. The sources and build scripts for TF-A are public, so maybe one could look at what's the criteria for putting images at different addresses? I have no idea what rockchip has to do with memory layout on zynqmp. Anyway SPL must be placed to OCM that's why text base is at 0xfffc where OCM starts and which is also default address where a53s starts. TF-A can be placed to any address but address which I use in SPL flow is 0xfffe5000. PetaLinux which uses FSBL is using different address 0xfffea000 which is default in TF-A. In DDR I normally use end of low ddr locations. It means 0x7fxx. And of course you can't place TFA to location which is used by SPL or by u-boot or other SW. Thanks for the information. I will check why our TF-A is linked to the lower DDR and move it back to the default address. The TF-A was build with debug flag [1]: > By default, the Arm-trusted firmware builds for OCM space at address > 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by > default with DEBUG=1, it builds for DDR location 0x1000 with build > flag DEBUG=1 mentioned while building. Either the CONFIG_SPL_BSS_START_ADDR or the default location of the TF-A with DEBUG flag should be changed. [1] https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842107/Arm+Trusted+Firmware It is really question what should be default address with DEBUG=1. I tried this diff --git a/plat/xilinx/zynqmp/include/platform_def.h b/plat/xilinx/zynqmp/include/platform_def.h index 9c1600a7b7e3..66bbf30a65a4 100644 --- a/plat/xilinx/zynqmp/include/platform_def.h +++ b/plat/xilinx/zynqmp/include/platform_def.h @@ -40,8 +40,8 @@ # define BL31_BASE U(0xfffea000) # define BL31_LIMITU(0x1) #else -# define BL31_BASE U(0x1000) -# define BL31_LIMITU(0x7) +# define BL31_BASE U(0xfff5a000) +# define BL31_LIMITU(0x1) #endif #else # define BL31_BASE (ZYNQMP_ATF_MEM_BASE) And with the latest TF-A this works fine. No problem to change TF-A code to place it to different addresses. I think it should stay in OCM if possible or allocate space at the end of of low ddr address. It means any 0x7fxx address should be fine. With any SPD on we won't be able to fit OCM anyway. Thanks, Michal
Re: [PATCH] arm64: dts: imx8mq-kontron-pitx-imx8m-u-boot.dtsi: disable assigned clocks
On Tue, Jun 14, 2022 at 06:11:11AM +0200, Heiko Thiery wrote:
> Hi Tom,
>
> Am Sa., 11. Juni 2022 um 16:56 Uhr schrieb Heiko Thiery
> :
> >
> > Hi Marek,
> >
> > Am Sa., 11. Juni 2022 um 12:15 Uhr schrieb Marek Vasut :
> > >
> > > On 6/11/22 08:09, Heiko Thiery wrote:
> > > > With the move to use DM_CLK the boards uart stops working. The used
> > > > properties are not supported by the imx8mq clock driver. Thus
> > > > the correct baudrate cannot be selected. Remove this properties here and
> > > > the board can start with working uart. Keep it in the main dts because
> > > > linux handles these porperties fine.
> > >
> > > Is this yet another
> > >
> > > 75f080df46f ("Revert "clk: Detect failure to set defaults"")
> > >
> > > kind of failure, where the clock uclass returns error code on something?
> > >
> > > Maybe the clock uclass should rather warn than fail outright, so we
> > > won't need these workarounds in DT files ?
> >
> > I think this is another kind of issue here. I had already tried to
> > solve the problem [1], but had not been able to follow it through to
> > the end.
> >
> > Maybe now is the right time to tackle it again. But due to lack of
> > time i can't say when i will get to it yet.
> >
> > [1]
> > https://patchwork.ozlabs.org/project/uboot/patch/20220317124127.1783768-1-heiko.thi...@gmail.com/
>
> Is there a chance that this patch can still come in the next RC?
> Without this change, the board no longer starts correctly.
I've put it in my queue.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET
On Tue, Jun 14, 2022 at 08:44:07AM +, Corentin LABBE wrote:
> The origin of this patch is the breaking of am335x-hs boot
> due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
> HS boards have less SRAM for SPL and so this commit increased memory usage
> beyond am335x limit.
> This commit added 10 driver binding pass and am335x boot only if one pass is
> done.
> SPL try to do more than one pass due to eth_cpsw failing.
> Since HS SPL does not need network (and NET is already disabled in config),
> the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.
>
> Signed-off-by: Corentin LABBE
Fixes: e41651fffda7 ("dm: Support parent devices with of-platdata")
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4] imx: add i.MX8MN DDR3L evk board support
Hi Michael,
Am Di., 14. Juni 2022 um 08:56 Uhr schrieb Michael Nazzareno Trimarchi
:
>
> Hi
>
> On Mon, Jun 13, 2022 at 11:10 PM Heiko Thiery wrote:
> >
> > Add the support for the 8MNANOD3L-EVK board. The board has an i.MX8MNano
> > UltraLite Quad SoC and uses 1GB DDR3L memory.
> >
> > U-Boot SPL 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
> > Normal Boot
> > WDT: Started watchdog@3028 with servicing (60s timeout)
> > Trying to boot from BOOTROM
> > image offset 0x8000, pagesize 0x200, ivt offset 0x0
> > NOTICE: BL31: v2.6(release):v2.6-5-g9b1a4d832
> > NOTICE: BL31: Built : 14:03:53, May 10 2022
> >
> > U-Boot 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
> >
> > CPU: Freescale i.MX8MNano UltraLite Quad rev1.0 at 1200 MHz
> > Reset cause: WDOG
> > Model: NXP i.MX8MNano DDR3L EVK board
> > DRAM: 1 GiB
> > Core: 142 devices, 19 uclasses, devicetree: separate
> > WDT: Started watchdog@3028 with servicing (60s timeout)
> > MMC: FSL_SDHC: 1, FSL_SDHC: 2
> > Loading Environment from MMC... OK
> > In:serial@3089
> > Out: serial@3089
> > Err: serial@3089
> > Net: eth0: ethernet@30be
> > Hit any key to stop autoboot: 0
> >
> > Signed-off-by: Heiko Thiery
> > Reviewed-by: Fabio Estevam
> > ---
> > v4:
> > - rebase on current master to fix merge conflicts
> > - remove config options from defconfig
> > - enable SPL_DM_SERIAL
> > - include imx8mn-ddr4-evk-u-boot.dtsi in imx8mn-ddr3l-evk-u-boot.dtsi
> > v3:
> > - fix config option description in Kconfig (TARGET_IMX8MN_DDR3L_EVK)
> > v2:
> > - change license formatting (thanks Marcel)
> >
> > arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi | 34 +
> > arch/arm/dts/imx8mn-ddr3l-evk.dts | 114 +++
> > arch/arm/dts/imx8mn-u-boot.dtsi | 12 +
> > arch/arm/mach-imx/imx8m/Kconfig | 7 +
> > board/freescale/imx8mn_evk/Kconfig| 2 +-
> > board/freescale/imx8mn_evk/Makefile | 1 +
> > board/freescale/imx8mn_evk/ddr3l_timing.c | 943 ++
> > board/freescale/imx8mn_evk/spl.c | 9 +
> > configs/imx8mn_ddr3l_evk_defconfig| 95 +++
> > include/configs/imx8mn_evk.h | 4 +
> > 10 files changed, 1220 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk.dts
> > create mode 100644 board/freescale/imx8mn_evk/ddr3l_timing.c
> > create mode 100644 configs/imx8mn_ddr3l_evk_defconfig
> >
> > diff --git a/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > new file mode 100644
> > index 00..b9192515e5
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> > @@ -0,0 +1,34 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +#include "imx8mn-u-boot.dtsi"
> > +#include "imx8mn-ddr4-evk-u-boot.dtsi"
> > +
> > +
> > +&{/soc@0} {
> > + u-boot,dm-pre-reloc;
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > + u-boot,dm-pre-reloc;
> > + /delete-property/ assigned-clocks;
> > + /delete-property/ assigned-clock-parents;
> > + /delete-property/ assigned-clock-rates;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > +&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
> > + u-boot,dm-spl;
> > +};
> > +
> > +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > diff --git a/arch/arm/dts/imx8mn-ddr3l-evk.dts
> > b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> > new file mode 100644
> > index 00..4cdc03c8f2
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> > @@ -0,0 +1,114 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +/dts-v1/;
> > +
> > +#include "imx8mn.dtsi"
> > +#include "imx8mn-evk.dtsi"
> > +#include
> > +
> > +/ {
> > + model = "NXP i.MX8MNano DDR3L EVK board";
> > + compatible = "fsl,imx8mn-ddr3l-evk", "fsl,imx8mn";
> > +};
> > +
> > +_0 {
> > + cpu-supply = <>;
> > +};
> > +
> > +_1 {
> > + cpu-supply = <>;
> > +};
> > +
> > +_2 {
> > + cpu-supply = <>;
> > +};
> > +
> > +_3 {
> > + cpu-supply = <>;
> > +};
> > +
> > + {
> > + pmic: pmic@25 {
> > + compatible = "nxp,pca9450b";
> > + reg = <0x25>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pmic>;
> > + interrupt-parent = <>;
> > + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + regulators {
> > + buck1: BUCK1 {
> > + regulator-name = "VDD_SOC_0V9";
> > + regulator-min-microvolt = <85>;
> > + regulator-max-microvolt = <95>;
> > + regulator-boot-on;
> > +
Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables
On Sat, Jun 11, 2022 at 10:46:51PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
>
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment vars binary data
> 2. Extracts variables as NVMEM cells
>
> Current Linux's NVMEM sysfs API allows reading whole NVMEM data block.
> It can be used by user-space tools for reading U-Boot env vars block
> without the hassle of finding its location. Parsing will still need to
> be re-done there.
>
> Kernel-parsed NVMEM cells can be read however by Linux drivers. This may
> be uesful for Ethernet drivers for reading device MAC address which is
> often stored as U-Boot env variable.
>
> Signed-off-by: Rafał Miłecki
> ---
> V3: Use of_get_mtd_device_by_node() (thanks Ahmad) & update description
> V2: Drop ARCH_BCM4908 dependency as there are plenty architectures using
> U-Boot bootloader. Thanks Srinivas.
>
> As noticed by Ahmad a missing NVMEM subsystem feature is user-space
> access to parsed NVMEM cells. That is something I started working on
> some time ago and I'm planning to get back to at some point, please
> check:
> [PATCH 2/2] nvmem: expose NVMEM cells in sysfs
> https://lore.kernel.org/lkml/20211220064730.28806-2-zaj...@gmail.com/
> ---
> MAINTAINERS| 1 +
> drivers/nvmem/Kconfig | 11 ++
> drivers/nvmem/Makefile | 2 +
> drivers/nvmem/u-boot-env.c | 231 +
> 4 files changed, 245 insertions(+)
> create mode 100644 drivers/nvmem/u-boot-env.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 475e28365385..43b427fa76b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20411,6 +20411,7 @@ U-BOOT ENVIRONMENT VARIABLES
> M: Rafał Miłecki
> S: Maintained
> F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> +F: drivers/nvmem/u-boot-env.c
>
> UACCE ACCELERATOR FRAMEWORK
> M: Zhangfei Gao
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index d72d879a6d34..5f1b32b953b9 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -344,4 +344,15 @@ config NVMEM_APPLE_EFUSES
> This driver can also be built as a module. If so, the module will
> be called nvmem-apple-efuses.
>
> +config NVMEM_U_BOOT_ENV
> + tristate "U-Boot environment variables support"
> + depends on OF && MTD
> + select CRC32
> + help
> + U-Boot stores its setup as environment variables. This driver adds
> + support for verifying & exporting such data. It also exposes variables
> + as NVMEM cells so they can be referenced by other drivers.
> +
> + If compiled as module it will be called nvmem_u-boot-env.
> +
> endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index c710b64f9fe4..399f9972d45b 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -69,3 +69,5 @@ obj-$(CONFIG_NVMEM_APPLE_EFUSES)+= nvmem-apple-efuses.o
> nvmem-apple-efuses-y := apple-efuses.o
> obj-$(CONFIG_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
> nvmem-microchip-otpc-y := microchip-otpc.o
> +obj-$(CONFIG_NVMEM_U_BOOT_ENV) += nvmem_u-boot-env.o
> +nvmem_u-boot-env-y := u-boot-env.o
> diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
> new file mode 100644
> index ..92c2dd11d99f
> --- /dev/null
> +++ b/drivers/nvmem/u-boot-env.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Rafał Miłecki
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum u_boot_env_format {
> + U_BOOT_FORMAT_SINGLE,
> + U_BOOT_FORMAT_REDUNDANT,
> +};
> +
> +struct u_boot_env {
> + struct device *dev;
> + enum u_boot_env_format format;
> +
> + /* Parent device */
> + struct mtd_info *mtd;
> + size_t offset;
> + size_t size;
> +
> + /* Cells */
> + struct nvmem_cell_info *cells;
> + int ncells;
> +};
> +
> +struct u_boot_env_image_single {
> + __le32 crc32;
> + uint8_t data[0];
> +} __packed;
> +
> +struct u_boot_env_image_redundant {
> + __le32 crc32;
> + u8 mark;
> + uint8_t data[0];
> +} __packed;
> +
> +static int u_boot_env_read(void *context, unsigned int offset, void *val,
> +size_t bytes)
> +{
> + struct u_boot_env *priv = context;
> + struct device *dev = priv->dev;
> + size_t bytes_read;
> + int err;
> +
> + err = mtd_read(priv->mtd, priv->offset + offset, bytes, _read,
> val);
> + if (err && !mtd_is_bitflip(err)) {
> + dev_err(dev, "Failed to read from mtd: %d\n", err);
> + return err;
> + }
> +
> + if (bytes_read != bytes) {
> + dev_err(dev, "Failed to read %zd bytes\n", bytes);
> + return
Re: [PATCH 1/1] efi_loader: initialize console size late
Hi Heinrich,
On Tue, Jun 14, 2022 at 3:02 AM Heinrich Schuchardt
wrote:
>
> From: Heinrich Schuchardt
>
> If CONFIG_VIDEO_DM=n we query the display size from the serial console.
> Especially when using a remote console the response can be so late that
> it interferes with autoboot.
>
> Only query the console size when running an EFI binary.
>
> Add debug output showing the determined console size.
>
> Reported-by: Fabio Estevam
> Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk
> objects from udevice")
> Signed-off-by: Heinrich Schuchardt
This fixes the boot on a kontron-sl-mx8mm board accessed remotely.
The autoboot process is no longer interrupted.
Thanks a lot!
Tested-by: Fabio Estevam
Re: [PATCH v2] kontron-sl-mx8mm: Add CAAM support
Am 09.06.22 um 22:13 schrieb Fabio Estevam:
> Add CAAM support, which is required when enabling HAB secure boot.
>
> Select CONFIG_SPL_DRIVERS_MISC so that CONFIG_IMX_HAB could
> build successfully, if selected.
>
> Signed-off-by: Fabio Estevam
Build-tested on next and partly runtime-tested by verifying that "SEC0:
RNG instantiated" is printed to the console in SPL and U-Boot proper.
Acked-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> Changes since v1:
> - Do not disable sec_jr0 node in -u-boot.dtsi. This will get disabled
> by the imx8mm.dtsi. Sent a patch upstream doing this. (Andrey)
>
> arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 16
> arch/arm/mach-imx/imx8m/Kconfig | 3 +++
> board/kontron/sl-mx8mm/spl.c | 9 +
> configs/kontron-sl-mx8mm_defconfig| 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> index 22d18e6f1c..65ff3988d9 100644
> --- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> @@ -25,6 +25,22 @@
> };
> };
>
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
> {
> phy-mode = "rgmii-rxid";
> };
> diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
> index 61397bf88d..5c59422ecb 100644
> --- a/arch/arm/mach-imx/imx8m/Kconfig
> +++ b/arch/arm/mach-imx/imx8m/Kconfig
> @@ -106,6 +106,9 @@ config TARGET_KONTRON_MX8MM
> select IMX8MM
> select SUPPORT_SPL
> select IMX8M_LPDDR4
> + select FSL_CAAM
> + select ARCH_MISC_INIT
> + select SPL_CRYPTO if SPL
>
> config TARGET_IMX8MN_BSH_SMM_S2
> bool "imx8mn-bsh-smm-s2"
> diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
> index 4ef03c8c17..5a513722c5 100644
> --- a/board/kontron/sl-mx8mm/spl.c
> +++ b/board/kontron/sl-mx8mm/spl.c
> @@ -13,6 +13,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -213,6 +216,12 @@ void spl_board_init(void)
> struct udevice *dev;
> int ret;
>
> + if (IS_ENABLED(CONFIG_FSL_CAAM)) {
> + ret = uclass_get_device_by_driver(UCLASS_MISC,
> DM_DRIVER_GET(caam_jr), );
> + if (ret)
> + printf("Failed to initialize %s: %d\n", dev->name, ret);
> + }
> +
> puts("Normal Boot\n");
>
> ret = uclass_get_device_by_name(UCLASS_CLK,
> diff --git a/configs/kontron-sl-mx8mm_defconfig
> b/configs/kontron-sl-mx8mm_defconfig
> index 2e9d52522b..eae9ac0dbe 100644
> --- a/configs/kontron-sl-mx8mm_defconfig
> +++ b/configs/kontron-sl-mx8mm_defconfig
> @@ -16,6 +16,7 @@ CONFIG_SPL_TEXT_BASE=0x7E1000
> CONFIG_TARGET_KONTRON_MX8MM=y
> CONFIG_SPL_MMC=y
> CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_DRIVERS_MISC=y
> CONFIG_BOOTCOUNT_BOOTLIMIT=3
> CONFIG_SPL=y
> CONFIG_SYS_LOAD_ADDR=0x4200
Re: [PATCH V2 07/17] imx: kontron-sl-mx8mm: enable DM_SERIAL
Am 11.06.22 um 14:21 schrieb Peng Fan (OSS): > From: Peng Fan > > Enable CONFIG_DM_SERIAL. uart and its pinmux was already > marked with u-boot,dm-spl. > Move preloader_console_init after spl_init to make sure driver > model work. > > Signed-off-by: Peng Fan > Acked-by: Frieder Schrempf > Reviewed-by: Fabio Estevam Tested-by: Frieder Schrempf
Re: [PATCH V2 16/17] imx: imx8mn-kontron-n801x: enable pinctrl_wdog in SPL
Am 11.06.22 um 14:21 schrieb Peng Fan (OSS):
> From: Peng Fan
>
> Mark pinctrl_wdog as u-boot,dm-spl to clean up board code,
>
> The set_wdog_reset() function is not necessary as this is handled by
> the imx_watchdog.c driver due to the 'fsl,ext-reset-output' property
> being set.
>
> Signed-off-by: Peng Fan
Thanks for the cleanup!!!
The subject line should probably be:
imx: kontron-sl-mx8mm: enable pinctrl_wdog in SPL
Otherwise:
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi | 4
> board/kontron/sl-mx8mm/spl.c | 18 --
> 2 files changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> index 22d18e6f1cf..6882513f161 100644
> --- a/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-kontron-n801x-u-boot.dtsi
> @@ -126,3 +126,7 @@
> {
> u-boot,dm-spl;
> };
> +
> +_wdog {
> + u-boot,dm-spl;
> +};
> diff --git a/board/kontron/sl-mx8mm/spl.c b/board/kontron/sl-mx8mm/spl.c
> index a58a75dc958..63361f1d2ab 100644
> --- a/board/kontron/sl-mx8mm/spl.c
> +++ b/board/kontron/sl-mx8mm/spl.c
> @@ -32,7 +32,6 @@ enum {
>
> #define GPIO_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE |
> PAD_CTL_PE)
> #define I2C_PAD_CTRL (PAD_CTL_DSE6 | PAD_CTL_HYS | PAD_CTL_PUE)
> -#define WDOG_PAD_CTRL(PAD_CTL_DSE6 | PAD_CTL_ODE | PAD_CTL_PUE |
> PAD_CTL_PE)
>
> #define TOUCH_RESET_GPIO IMX_GPIO_NR(3, 23)
>
> @@ -50,10 +49,6 @@ static iomux_v3_cfg_t const touch_gpio[] = {
> IMX8MM_PAD_SAI5_RXD2_GPIO3_IO23 | MUX_PAD_CTRL(GPIO_PAD_CTRL)
> };
>
> -static iomux_v3_cfg_t const wdog_pads[] = {
> - IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B | MUX_PAD_CTRL(WDOG_PAD_CTRL),
> -};
> -
> int spl_board_boot_device(enum boot_device boot_dev_spl)
> {
> switch (boot_dev_spl) {
> @@ -216,17 +211,6 @@ void spl_board_init(void)
> printf("Failed to find clock node. Check device tree\n");
> }
>
> -int board_early_init_f(void)
> -{
> - struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
> -
> - imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));
> -
> - set_wdog_reset(wdog);
> -
> - return 0;
> -}
> -
> static int power_init_board(void)
> {
> struct udevice *dev;
> @@ -261,8 +245,6 @@ void board_init_f(ulong dummy)
>
> init_uart_clk(2);
>
> - board_early_init_f();
> -
> timer_init();
>
> /* Clear the BSS. */
[PATCH] tools: binman: install btool
From: Peng Fan
btool is needed after install binman to system.
Signed-off-by: Peng Fan
---
Tom, Simon, Alper
This is a bug fix, if possible, please pick it up.
tools/binman/setup.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/setup.py b/tools/binman/setup.py
index 5ed94abdaf9..9a9206eb044 100644
--- a/tools/binman/setup.py
+++ b/tools/binman/setup.py
@@ -5,7 +5,7 @@ setup(name='binman',
version='1.0',
license='GPL-2.0+',
scripts=['binman'],
- packages=['binman', 'binman.etype'],
+ packages=['binman', 'binman.etype', 'binman.btool'],
package_dir={'binman': ''},
package_data={'binman': ['README.rst', 'entries.rst']},
classifiers=['Environment :: Console',
--
2.36.0
Re: [PATCH] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver
Am 14.06.2022 um 10:39 schrieb Marek Vasut:
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
.../imx8mm_data_modul_edm_sbc.c | 10 ++
configs/imx8mm_data_modul_edm_sbc_defconfig | 1 +
include/configs/imx8mm_data_modul_edm_sbc.h | 20 ---
3 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..56202ca2fc8 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -104,7 +106,15 @@ int board_init(void)
int board_late_init(void)
{
+ struct udevice *dev;
+ int ret;
+
setup_boot_device();
setup_mac_address();
+
+ ret = uclass_find_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+ if (!ret)
+ device_probe(dev);
Maybe you should use uclass_get_device_by_name() from uclass.h.
+
return 0;
}
"setenv autoload false && " \
Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables
Hello,
> > +static int u_boot_env_probe(struct platform_device *pdev)
> > +{
> > + struct nvmem_config config = {
> > + .name = "u-boot-env",
> > + .reg_read = u_boot_env_read,
> > + };
> > + struct device *dev = >dev;
> > + struct device_node *np = dev->of_node;
> > + const struct of_device_id *of_id;
> > + struct u_boot_env *priv;
> > + int err;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > + priv->dev = dev;
> > +
> > + of_id = of_match_device(u_boot_env_of_match_table, dev);
> > + if (!of_id)
> > + return -EINVAL;
> > + priv->format = (uintptr_t)of_id->data;
> > +
> > + if (of_property_read_u32(np, "reg", (u32 *)>offset) ||
> > + of_property_read_u32_index(np, "reg", 1, (u32 *)>size)) {
> > + dev_err(dev, "Failed to read \"reg\" property\n");
> > + return -EINVAL;
> > + }
> > +
> > + priv->mtd = of_get_mtd_device_by_node(np->parent);
> > + if (IS_ERR(priv->mtd)) {
> > + dev_err(dev, "Failed to get %pOF MTD: %ld\n", np->parent,
> > PTR_ERR(priv->mtd));
> > + return PTR_ERR(priv->mtd);
> > + }
>
> Partitions are mtd devices themselves and the mtd layer directly
> associates these devices to their OF node, so it should be possible
> to do a of_get_mtd_device_by_node(np) which gets you the partition.
> You can use the whole mtd device then and do not have to fiddle with
> reg properties, offsets and sizes in your driver yourself.
Just for the record, there will be one mtd device per partition, but
the "full" mtd device will only exist if the configuration contains
CONFIG_MTD_PARTITIONED_MASTER.
Thanks,
Miquèl
[PATCH] board: ti: am335x: eth_cpsw should depend on CONFIG_NET
The origin of this patch is the breaking of am335x-hs boot
due to commit e41651fffda7 ("dm: Support parent devices with of-platdata")
HS boards have less SRAM for SPL and so this commit increased memory usage
beyond am335x limit.
This commit added 10 driver binding pass and am335x boot only if one pass is
done.
SPL try to do more than one pass due to eth_cpsw failing.
Since HS SPL does not need network (and NET is already disabled in config),
the easiest fix is to "remove" eth_cpsw from SPL by testing if NET is enabled.
Signed-off-by: Corentin LABBE
---
board/ti/am335x/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 7c0545892c..2cb5b1cb3f 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -902,7 +902,7 @@ int board_late_init(void)
#endif
/* CPSW plat */
-#if !CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(NET) && !CONFIG_IS_ENABLED(OF_CONTROL)
struct cpsw_slave_data slave_data[] = {
{
.slave_reg_ofs = CPSW_SLAVE0_OFFSET,
--
2.25.1
[PATCH] ARM: imx: Switch Data Modul i.MX8M Mini eDM SBC to USB251x Hub driver
Replace the ad-hoc I2C register programming scripted in board
environment with U-Boot DM driver.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
.../imx8mm_data_modul_edm_sbc.c | 10 ++
configs/imx8mm_data_modul_edm_sbc_defconfig | 1 +
include/configs/imx8mm_data_modul_edm_sbc.h | 20 ---
3 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
index 46cb6f77b59..56202ca2fc8 100644
--- a/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
+++ b/board/data_modul/imx8mm_edm_sbc/imx8mm_data_modul_edm_sbc.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -104,7 +106,15 @@ int board_init(void)
int board_late_init(void)
{
+ struct udevice *dev;
+ int ret;
+
setup_boot_device();
setup_mac_address();
+
+ ret = uclass_find_device_by_name(UCLASS_MISC, "usb-hub@2c", );
+ if (!ret)
+ device_probe(dev);
+
return 0;
}
diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig
b/configs/imx8mm_data_modul_edm_sbc_defconfig
index d55efa6d00e..99a1f862200 100644
--- a/configs/imx8mm_data_modul_edm_sbc_defconfig
+++ b/configs/imx8mm_data_modul_edm_sbc_defconfig
@@ -156,6 +156,7 @@ CONFIG_MXC_GPIO=y
CONFIG_DM_I2C=y
# CONFIG_INPUT is not set
CONFIG_MISC=y
+CONFIG_USB_HUB_USB251XB=y
CONFIG_I2C_EEPROM=y
CONFIG_SYS_I2C_EEPROM_ADDR=0x50
CONFIG_SUPPORT_EMMC_BOOT=y
diff --git a/include/configs/imx8mm_data_modul_edm_sbc.h
b/include/configs/imx8mm_data_modul_edm_sbc.h
index 67667dd523d..419258f949a 100644
--- a/include/configs/imx8mm_data_modul_edm_sbc.h
+++ b/include/configs/imx8mm_data_modul_edm_sbc.h
@@ -71,7 +71,6 @@
"mtd nor0=sf raw 0x0 0x100\0" \
"dmo_preboot=" \
"sf probe ; " /* Scan for SPI NOR, needed by DFU */ \
- "run dmo_usb_start_hub ; " \
/* Attempt to start USB and Network console */ \
"run dmo_usb_cdc_acm_start ; " \
"run dmo_netconsole_start\0"\
@@ -91,25 +90,6 @@
"setenv stdin ${stdin},usbacm ; " \
"fi ; " \
"fi\0" \
- "dmo_usb_start_hub="\
- "i2c dev 1 ; " \
- /* Reset the USB USB */ \
- "gpio clear GPIO5_2 ; sleep 0.01 ; " /* t1 > 1us */ \
- "gpio set GPIO5_2 ; sleep 0.01 ; " /* t5 > 3us */ \
- /* Write chunks of descriptor into the USB HUB */ \
- "mw.l 0x7e1000 0x14042417 ; mw.l 0x7e1004 0x9b0bb325 ; "\
- "mw.l 0x7e1008 0x0220 ; mw.l 0x7e100c 0x01320100 ; "\
- "mw.l 0x7e1010 0x3232 ; mw.l 0x7e1014 0x4d000909 ; "\
- "i2c write 0x7e1000 0x2c 0x00 0x18 -s ; " \
- "mw.l 0x7e1000 0x6300690f ; mw.l 0x7e1004 0x6f007200 ; "\
- "mw.l 0x7e1008 0x68006300 ; mw.l 0x7e100c 0x70006900 ; "\
- "i2c write 0x7e1000 0x2c 0x18 0x10 -s ; " \
- "mw.l 0x7e1000 0x53005511 ; mw.l 0x7e1004 0x32004200 ; "\
- "mw.l 0x7e1008 0x31003500 ; mw.l 0x7e100c 0x42003400 ; "\
- "mw.l 0x7e1010 0x6900 ; " \
- "i2c write 0x7e1000 0x2c 0x54 0x12 -s ; " \
- "mw.l 0x7e1000 0x0101 ; " \
- "i2c write 0x7e1000 0x2c 0xff 0x2 -s\0" \
"dmo_netconsole_start=" \
"if test \"${dmo_netconsole_enabled}\" = \"true\" ; then "\
"setenv autoload false && " \
--
2.35.1
Re: [PATCH v2 1/3] arm: apple: nvme: Add SART support and RTKit buffer management
> From: Janne Grunau
> Date: Tue, 14 Jun 2022 09:09:07 +0200
>
> The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's
> current minimal RTKit implementation. It does not provide buffers for
> the firmware's buffer requests. The ANS2 firmware included in macOS 11
> and 12 tolerates this. The firmware included in the first macOS 13 beta
> requires buffers for the crashlog and ioreport endpoints to function.
>
> In the case of the NVMe the buffers are physical memory. Access to
> physical memory is guarded by what Apple calls SART.
> Import m1n1's SART driver (exclusively used for the NVMe controller).
> Implement buffer management helpers for RTKit. These are generic since
> other devices (none in u-boot so far) require different handling.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Mark Kettenis
Tested-by: Mark Kettenis
> ---
>
> Changes in v2:
> - The generation compatible strings "apple,sart2" "apple,sart3" got
>droppend from the bindings merged for Linux 5.19. Use the SoC
>specific ones instead.
>
> arch/arm/include/asm/arch-apple/rtkit.h | 22 ++-
> arch/arm/include/asm/arch-apple/sart.h | 22 +++
> arch/arm/mach-apple/Makefile| 1 +
> arch/arm/mach-apple/rtkit.c | 159 +---
> arch/arm/mach-apple/sart.c | 230
> drivers/nvme/nvme_apple.c | 72 +++-
> 6 files changed, 474 insertions(+), 32 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-apple/sart.h
> create mode 100644 arch/arm/mach-apple/sart.c
>
> diff --git a/arch/arm/include/asm/arch-apple/rtkit.h
> b/arch/arm/include/asm/arch-apple/rtkit.h
> index 51f77f298c09..eff18ddb9d21 100644
> --- a/arch/arm/include/asm/arch-apple/rtkit.h
> +++ b/arch/arm/include/asm/arch-apple/rtkit.h
> @@ -7,5 +7,23 @@
> #define APPLE_RTKIT_PWR_STATE_QUIESCED 0x10
> #define APPLE_RTKIT_PWR_STATE_ON 0x20
>
> -int apple_rtkit_init(struct mbox_chan *);
> -int apple_rtkit_shutdown(struct mbox_chan *, int);
> +struct apple_rtkit_buffer {
> + void *buffer;
> + u64 dva;
> + size_t size;
> + bool is_mapped;
> +};
> +
> +typedef int (*apple_rtkit_shmem_setup)(void *cookie,
> +struct apple_rtkit_buffer *buf);
> +typedef void (*apple_rtkit_shmem_destroy)(void *cookie,
> + struct apple_rtkit_buffer *buf);
> +
> +struct apple_rtkit;
> +
> +struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
> + apple_rtkit_shmem_setup shmem_setup,
> + apple_rtkit_shmem_destroy shmem_destroy);
> +void apple_rtkit_free(struct apple_rtkit *rtk);
> +int apple_rtkit_boot(struct apple_rtkit *rtk);
> +int apple_rtkit_shutdown(struct apple_rtkit *rtk, int pwrstate);
> diff --git a/arch/arm/include/asm/arch-apple/sart.h
> b/arch/arm/include/asm/arch-apple/sart.h
> new file mode 100644
> index ..b99bdeafc0b3
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-apple/sart.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: MIT
> + *
> + * The sart code is copied from m1n1 (https://github.com/AsahiLinux/m1n1) and
> + * licensed as MIT.
> + *
> + * (C) Copyright 2022 The Asahi Linux Contributors
> + */
> +
> +#ifndef SART_H
> +#define SART_H
> +
> +#include
> +
> +struct apple_sart;
> +
> +struct apple_sart *sart_init(ofnode node);
> +void sart_free(struct apple_sart *sart);
> +
> +bool sart_add_allowed_region(struct apple_sart *sart, void *paddr, size_t
> sz);
> +bool sart_remove_allowed_region(struct apple_sart *sart, void *paddr, size_t
> sz);
> +
> +#endif
> diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
> index 52f30a777b2c..50b465b9473f 100644
> --- a/arch/arm/mach-apple/Makefile
> +++ b/arch/arm/mach-apple/Makefile
> @@ -3,3 +3,4 @@
> obj-y += board.o
> obj-y += lowlevel_init.o
> obj-y += rtkit.o
> +obj-$(CONFIG_NVME_APPLE) += sart.o
> diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
> index 2dcb8bdd3e44..da7771844230 100644
> --- a/arch/arm/mach-apple/rtkit.c
> +++ b/arch/arm/mach-apple/rtkit.c
> @@ -17,6 +17,7 @@
> #define APPLE_RTKIT_EP_SYSLOG 2
> #define APPLE_RTKIT_EP_DEBUG 3
> #define APPLE_RTKIT_EP_IOREPORT 4
> +#define APPLE_RTKIT_EP_TRACEKIT 10
>
> /* Messages for management endpoint. */
> #define APPLE_RTKIT_MGMT_TYPE GENMASK(59, 52)
> @@ -51,7 +52,102 @@
> #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
> #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
>
> -int apple_rtkit_init(struct mbox_chan *chan)
> +struct apple_rtkit {
> + struct mbox_chan *chan;
> + void *cookie;
> + apple_rtkit_shmem_setup shmem_setup;
> + apple_rtkit_shmem_destroy shmem_destroy;
> +
> + struct apple_rtkit_buffer syslog_buffer;
> + struct apple_rtkit_buffer crashlog_buffer;
> + struct apple_rtkit_buffer ioreport_buffer;
> +};
> +
> +struct apple_rtkit
Re: [PATCH v2 3/3] arm: apple: Increase RTKit timeouts
> From: Janne Grunau
> Date: Tue, 14 Jun 2022 09:09:09 +0200
>
> Timeouts are not expected to happen and are handled as fatal errors.
> Increase all timeouts to 1 second as defensive measure to avoid relying
> on the timing behaviour of certain firmware versions or configurations.
>
> Signed-off-by: Janne Grunau
Reviewed-by: Mark Kettenis
Tested-by: Mark Kettenis
> ---
>
> (no changes since v1)
>
> arch/arm/mach-apple/rtkit.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
> index da7771844230..a550b553b663 100644
> --- a/arch/arm/mach-apple/rtkit.c
> +++ b/arch/arm/mach-apple/rtkit.c
> @@ -52,6 +52,8 @@
> #define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
> #define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
>
> +#define TIMEOUT_1SEC_US 100
> +
> struct apple_rtkit {
> struct mbox_chan *chan;
> void *cookie;
> @@ -168,7 +170,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
> return ret;
>
> /* Wait for protocol version negotiation message. */
> - ret = mbox_recv(rtk->chan, , 1);
> + ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
> if (ret < 0)
> return ret;
>
> @@ -210,7 +212,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
>
> wait_epmap:
> /* Wait for endpoint map message. */
> - ret = mbox_recv(rtk->chan, , 1);
> + ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
> if (ret < 0)
> return ret;
>
> @@ -275,7 +277,7 @@ wait_epmap:
>
> pwrstate = APPLE_RTKIT_PWR_STATE_SLEEP;
> while (pwrstate != APPLE_RTKIT_PWR_STATE_ON) {
> - ret = mbox_recv(rtk->chan, , 10);
> + ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
> if (ret < 0)
> return ret;
>
> @@ -330,7 +332,7 @@ int apple_rtkit_shutdown(struct apple_rtkit *rtk, int
> pwrstate)
> if (ret < 0)
> return ret;
>
> - ret = mbox_recv(rtk->chan, , 10);
> + ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
> if (ret < 0)
> return ret;
>
> --
> 2.35.1
>
>
Re: [PATCH v2 2/3] MAINTAINERS: Add nvme_apple to Apple SoC section
> From: Janne Grunau > Date: Tue, 14 Jun 2022 09:09:08 +0200 > > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > > (no changes since v1) > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 28e4d3823861..a15ba7abdcd6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -121,6 +121,7 @@ F:arch/arm/include/asm/arch-m1/ > F: arch/arm/mach-apple/ > F: configs/apple_m1_defconfig > F: drivers/iommu/apple_dart.c > +F: drivers/nvme/nvme_apple.c > F: drivers/pinctrl/pinctrl-apple.c > F: drivers/watchdog/apple_wdt.c > F: include/configs/apple.h > -- > 2.35.1 > >
Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux
On 6/14/22 09:08, Stefan Herbrechtsmeier wrote: Am 13.06.2022 um 22:26 schrieb Marek Vasut: On 6/13/22 19:23, Stefan Herbrechtsmeier wrote: [snip] + if (dev_read_u32(dev, "vendor-id", >vendor_id)) + hub->vendor_id = USB251XB_DEF_VENDOR_ID; + + if (dev_read_u32(dev, "product-id", >product_id)) + hub->product_id = data->product_id; + + if (dev_read_u32(dev, "device-id", >device_id)) + hub->device_id = USB251XB_DEF_DEVICE_ID; + [snip] + if (dev_read_u32(dev, "language-id", >lang_id)) + hub->lang_id = USB251XB_DEF_LANGUAGE_ID; + This doesn't work because the ids are 16 bit [1,2] and the dev_read_u32 function checks the size. + if (!dev_read_u32(dev, "boost-up", >boost_up)) + hub->boost_up = USB251XB_DEF_BOOST_UP; This looks like a 8 bit value [1]. The dev_read_u32() is also capable of reading 0x 16bit value from DT. What kind of problem are you running into exactly ? Have you test the values from device tree binding documentation: vendor-id = /bits/ 16 <0x>; product-id = /bits/ 16 <0x>; I get an EOVERFLOW error. No, I only tested foo = <0x>; . Can you send a fix ? Should I add a function to the driver or a dev_read_u8/16, ofnode_read_u8/16 and friends function? It seems more like you would have to add the _u8 and _u16 variants into common code, alongside the _u32 variant (should be easy) and then use them in this driver (should also be easy), so two patches.
[PATCH v2 1/3] arm: apple: nvme: Add SART support and RTKit buffer management
The NVMe firmware in the macOS 13 beta blocks or crashes with u-boot's
current minimal RTKit implementation. It does not provide buffers for
the firmware's buffer requests. The ANS2 firmware included in macOS 11
and 12 tolerates this. The firmware included in the first macOS 13 beta
requires buffers for the crashlog and ioreport endpoints to function.
In the case of the NVMe the buffers are physical memory. Access to
physical memory is guarded by what Apple calls SART.
Import m1n1's SART driver (exclusively used for the NVMe controller).
Implement buffer management helpers for RTKit. These are generic since
other devices (none in u-boot so far) require different handling.
Signed-off-by: Janne Grunau
---
Changes in v2:
- The generation compatible strings "apple,sart2" "apple,sart3" got
droppend from the bindings merged for Linux 5.19. Use the SoC
specific ones instead.
arch/arm/include/asm/arch-apple/rtkit.h | 22 ++-
arch/arm/include/asm/arch-apple/sart.h | 22 +++
arch/arm/mach-apple/Makefile| 1 +
arch/arm/mach-apple/rtkit.c | 159 +---
arch/arm/mach-apple/sart.c | 230
drivers/nvme/nvme_apple.c | 72 +++-
6 files changed, 474 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/include/asm/arch-apple/sart.h
create mode 100644 arch/arm/mach-apple/sart.c
diff --git a/arch/arm/include/asm/arch-apple/rtkit.h
b/arch/arm/include/asm/arch-apple/rtkit.h
index 51f77f298c09..eff18ddb9d21 100644
--- a/arch/arm/include/asm/arch-apple/rtkit.h
+++ b/arch/arm/include/asm/arch-apple/rtkit.h
@@ -7,5 +7,23 @@
#define APPLE_RTKIT_PWR_STATE_QUIESCED 0x10
#define APPLE_RTKIT_PWR_STATE_ON 0x20
-int apple_rtkit_init(struct mbox_chan *);
-int apple_rtkit_shutdown(struct mbox_chan *, int);
+struct apple_rtkit_buffer {
+ void *buffer;
+ u64 dva;
+ size_t size;
+ bool is_mapped;
+};
+
+typedef int (*apple_rtkit_shmem_setup)(void *cookie,
+ struct apple_rtkit_buffer *buf);
+typedef void (*apple_rtkit_shmem_destroy)(void *cookie,
+ struct apple_rtkit_buffer *buf);
+
+struct apple_rtkit;
+
+struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
+apple_rtkit_shmem_setup shmem_setup,
+apple_rtkit_shmem_destroy shmem_destroy);
+void apple_rtkit_free(struct apple_rtkit *rtk);
+int apple_rtkit_boot(struct apple_rtkit *rtk);
+int apple_rtkit_shutdown(struct apple_rtkit *rtk, int pwrstate);
diff --git a/arch/arm/include/asm/arch-apple/sart.h
b/arch/arm/include/asm/arch-apple/sart.h
new file mode 100644
index ..b99bdeafc0b3
--- /dev/null
+++ b/arch/arm/include/asm/arch-apple/sart.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: MIT
+ *
+ * The sart code is copied from m1n1 (https://github.com/AsahiLinux/m1n1) and
+ * licensed as MIT.
+ *
+ * (C) Copyright 2022 The Asahi Linux Contributors
+ */
+
+#ifndef SART_H
+#define SART_H
+
+#include
+
+struct apple_sart;
+
+struct apple_sart *sart_init(ofnode node);
+void sart_free(struct apple_sart *sart);
+
+bool sart_add_allowed_region(struct apple_sart *sart, void *paddr, size_t sz);
+bool sart_remove_allowed_region(struct apple_sart *sart, void *paddr, size_t
sz);
+
+#endif
diff --git a/arch/arm/mach-apple/Makefile b/arch/arm/mach-apple/Makefile
index 52f30a777b2c..50b465b9473f 100644
--- a/arch/arm/mach-apple/Makefile
+++ b/arch/arm/mach-apple/Makefile
@@ -3,3 +3,4 @@
obj-y += board.o
obj-y += lowlevel_init.o
obj-y += rtkit.o
+obj-$(CONFIG_NVME_APPLE) += sart.o
diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
index 2dcb8bdd3e44..da7771844230 100644
--- a/arch/arm/mach-apple/rtkit.c
+++ b/arch/arm/mach-apple/rtkit.c
@@ -17,6 +17,7 @@
#define APPLE_RTKIT_EP_SYSLOG 2
#define APPLE_RTKIT_EP_DEBUG 3
#define APPLE_RTKIT_EP_IOREPORT 4
+#define APPLE_RTKIT_EP_TRACEKIT 10
/* Messages for management endpoint. */
#define APPLE_RTKIT_MGMT_TYPE GENMASK(59, 52)
@@ -51,7 +52,102 @@
#define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
#define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
-int apple_rtkit_init(struct mbox_chan *chan)
+struct apple_rtkit {
+ struct mbox_chan *chan;
+ void *cookie;
+ apple_rtkit_shmem_setup shmem_setup;
+ apple_rtkit_shmem_destroy shmem_destroy;
+
+ struct apple_rtkit_buffer syslog_buffer;
+ struct apple_rtkit_buffer crashlog_buffer;
+ struct apple_rtkit_buffer ioreport_buffer;
+};
+
+struct apple_rtkit *apple_rtkit_init(struct mbox_chan *chan, void *cookie,
+apple_rtkit_shmem_setup shmem_setup,
+apple_rtkit_shmem_destroy shmem_destroy)
+{
+ struct apple_rtkit *rtk;
+
+ rtk = calloc(sizeof(*rtk), 1);
+ if (!rtk)
+ return NULL;
+
+ rtk->chan = chan;
+
[PATCH v2 3/3] arm: apple: Increase RTKit timeouts
Timeouts are not expected to happen and are handled as fatal errors.
Increase all timeouts to 1 second as defensive measure to avoid relying
on the timing behaviour of certain firmware versions or configurations.
Signed-off-by: Janne Grunau
---
(no changes since v1)
arch/arm/mach-apple/rtkit.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-apple/rtkit.c b/arch/arm/mach-apple/rtkit.c
index da7771844230..a550b553b663 100644
--- a/arch/arm/mach-apple/rtkit.c
+++ b/arch/arm/mach-apple/rtkit.c
@@ -52,6 +52,8 @@
#define APPLE_RTKIT_BUFFER_REQUEST_SIZE GENMASK(51, 44)
#define APPLE_RTKIT_BUFFER_REQUEST_IOVA GENMASK(41, 0)
+#define TIMEOUT_1SEC_US 100
+
struct apple_rtkit {
struct mbox_chan *chan;
void *cookie;
@@ -168,7 +170,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
return ret;
/* Wait for protocol version negotiation message. */
- ret = mbox_recv(rtk->chan, , 1);
+ ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
@@ -210,7 +212,7 @@ int apple_rtkit_boot(struct apple_rtkit *rtk)
wait_epmap:
/* Wait for endpoint map message. */
- ret = mbox_recv(rtk->chan, , 1);
+ ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
@@ -275,7 +277,7 @@ wait_epmap:
pwrstate = APPLE_RTKIT_PWR_STATE_SLEEP;
while (pwrstate != APPLE_RTKIT_PWR_STATE_ON) {
- ret = mbox_recv(rtk->chan, , 10);
+ ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
@@ -330,7 +332,7 @@ int apple_rtkit_shutdown(struct apple_rtkit *rtk, int
pwrstate)
if (ret < 0)
return ret;
- ret = mbox_recv(rtk->chan, , 10);
+ ret = mbox_recv(rtk->chan, , TIMEOUT_1SEC_US);
if (ret < 0)
return ret;
--
2.35.1
[PATCH v2 2/3] MAINTAINERS: Add nvme_apple to Apple SoC section
Signed-off-by: Janne Grunau --- (no changes since v1) MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 28e4d3823861..a15ba7abdcd6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -121,6 +121,7 @@ F: arch/arm/include/asm/arch-m1/ F: arch/arm/mach-apple/ F: configs/apple_m1_defconfig F: drivers/iommu/apple_dart.c +F: drivers/nvme/nvme_apple.c F: drivers/pinctrl/pinctrl-apple.c F: drivers/watchdog/apple_wdt.c F: include/configs/apple.h -- 2.35.1
[PATCH v2 0/3] Improve robustness of NVMe suuport for Apple silicon devices
Hej, this series has assorted fixes to improve the robustness of the NVMe support on Apple silicon devices. The main change which prompted this series is "rm: apple: nvme: Add SART support and RTKit buffer management". It fixes the RTKit driver required for the NVMe with the system-wide firmware included in the first macOS 13 beta release. The increased timeouts in RTKit are a defensive change against future changes. None of the mailbox receive calls is expected to timeout so waiting up to 1 second for a fatal error seems acceptable. cheers Janne Changes in v2: - update sart compatible strings to the SoC specified ones from the Linux devicetree bindings Janne Grunau (3): arm: apple: nvme: Add SART support and RTKit buffer management MAINTAINERS: Add nvme_apple to Apple SoC section arm: apple: Increase RTKit timeouts MAINTAINERS | 1 + arch/arm/include/asm/arch-apple/rtkit.h | 22 ++- arch/arm/include/asm/arch-apple/sart.h | 22 +++ arch/arm/mach-apple/Makefile| 1 + arch/arm/mach-apple/rtkit.c | 161 ++--- arch/arm/mach-apple/sart.c | 230 drivers/nvme/nvme_apple.c | 72 +++- 7 files changed, 477 insertions(+), 32 deletions(-) create mode 100644 arch/arm/include/asm/arch-apple/sart.h create mode 100644 arch/arm/mach-apple/sart.c -- 2.35.1
Re: [PATCH] misc: Port USB251xB/xBi Hi-Speed Hub Controller Driver from Linux
Am 13.06.2022 um 22:26 schrieb Marek Vasut: On 6/13/22 19:23, Stefan Herbrechtsmeier wrote: [snip] + if (dev_read_u32(dev, "vendor-id", >vendor_id)) + hub->vendor_id = USB251XB_DEF_VENDOR_ID; + + if (dev_read_u32(dev, "product-id", >product_id)) + hub->product_id = data->product_id; + + if (dev_read_u32(dev, "device-id", >device_id)) + hub->device_id = USB251XB_DEF_DEVICE_ID; + [snip] + if (dev_read_u32(dev, "language-id", >lang_id)) + hub->lang_id = USB251XB_DEF_LANGUAGE_ID; + This doesn't work because the ids are 16 bit [1,2] and the dev_read_u32 function checks the size. + if (!dev_read_u32(dev, "boost-up", >boost_up)) + hub->boost_up = USB251XB_DEF_BOOST_UP; This looks like a 8 bit value [1]. The dev_read_u32() is also capable of reading 0x 16bit value from DT. What kind of problem are you running into exactly ? Have you test the values from device tree binding documentation: vendor-id = /bits/ 16 <0x>; product-id = /bits/ 16 <0x>; I get an EOVERFLOW error. No, I only tested foo = <0x>; . Can you send a fix ? Should I add a function to the driver or a dev_read_u8/16, ofnode_read_u8/16 and friends function?
Re: [PATCH v4] imx: add i.MX8MN DDR3L evk board support
Hi
On Mon, Jun 13, 2022 at 11:10 PM Heiko Thiery wrote:
>
> Add the support for the 8MNANOD3L-EVK board. The board has an i.MX8MNano
> UltraLite Quad SoC and uses 1GB DDR3L memory.
>
> U-Boot SPL 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
> Normal Boot
> WDT: Started watchdog@3028 with servicing (60s timeout)
> Trying to boot from BOOTROM
> image offset 0x8000, pagesize 0x200, ivt offset 0x0
> NOTICE: BL31: v2.6(release):v2.6-5-g9b1a4d832
> NOTICE: BL31: Built : 14:03:53, May 10 2022
>
> U-Boot 2022.07-rc4-00017-gcf594ebce1 (Jun 13 2022 - 22:40:31 +0200)
>
> CPU: Freescale i.MX8MNano UltraLite Quad rev1.0 at 1200 MHz
> Reset cause: WDOG
> Model: NXP i.MX8MNano DDR3L EVK board
> DRAM: 1 GiB
> Core: 142 devices, 19 uclasses, devicetree: separate
> WDT: Started watchdog@3028 with servicing (60s timeout)
> MMC: FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... OK
> In:serial@3089
> Out: serial@3089
> Err: serial@3089
> Net: eth0: ethernet@30be
> Hit any key to stop autoboot: 0
>
> Signed-off-by: Heiko Thiery
> Reviewed-by: Fabio Estevam
> ---
> v4:
> - rebase on current master to fix merge conflicts
> - remove config options from defconfig
> - enable SPL_DM_SERIAL
> - include imx8mn-ddr4-evk-u-boot.dtsi in imx8mn-ddr3l-evk-u-boot.dtsi
> v3:
> - fix config option description in Kconfig (TARGET_IMX8MN_DDR3L_EVK)
> v2:
> - change license formatting (thanks Marcel)
>
> arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi | 34 +
> arch/arm/dts/imx8mn-ddr3l-evk.dts | 114 +++
> arch/arm/dts/imx8mn-u-boot.dtsi | 12 +
> arch/arm/mach-imx/imx8m/Kconfig | 7 +
> board/freescale/imx8mn_evk/Kconfig| 2 +-
> board/freescale/imx8mn_evk/Makefile | 1 +
> board/freescale/imx8mn_evk/ddr3l_timing.c | 943 ++
> board/freescale/imx8mn_evk/spl.c | 9 +
> configs/imx8mn_ddr3l_evk_defconfig| 95 +++
> include/configs/imx8mn_evk.h | 4 +
> 10 files changed, 1220 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mn-ddr3l-evk.dts
> create mode 100644 board/freescale/imx8mn_evk/ddr3l_timing.c
> create mode 100644 configs/imx8mn_ddr3l_evk_defconfig
>
> diff --git a/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> new file mode 100644
> index 00..b9192515e5
> --- /dev/null
> +++ b/arch/arm/dts/imx8mn-ddr3l-evk-u-boot.dtsi
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "imx8mn-u-boot.dtsi"
> +#include "imx8mn-ddr4-evk-u-boot.dtsi"
> +
> +
> +&{/soc@0} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@25} {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx8mn-ddr3l-evk.dts
> b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> new file mode 100644
> index 00..4cdc03c8f2
> --- /dev/null
> +++ b/arch/arm/dts/imx8mn-ddr3l-evk.dts
> @@ -0,0 +1,114 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +/dts-v1/;
> +
> +#include "imx8mn.dtsi"
> +#include "imx8mn-evk.dtsi"
> +#include
> +
> +/ {
> + model = "NXP i.MX8MNano DDR3L EVK board";
> + compatible = "fsl,imx8mn-ddr3l-evk", "fsl,imx8mn";
> +};
> +
> +_0 {
> + cpu-supply = <>;
> +};
> +
> +_1 {
> + cpu-supply = <>;
> +};
> +
> +_2 {
> + cpu-supply = <>;
> +};
> +
> +_3 {
> + cpu-supply = <>;
> +};
> +
> + {
> + pmic: pmic@25 {
> + compatible = "nxp,pca9450b";
> + reg = <0x25>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pmic>;
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> + regulators {
> + buck1: BUCK1 {
> + regulator-name = "VDD_SOC_0V9";
> + regulator-min-microvolt = <85>;
> + regulator-max-microvolt = <95>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <3125>;
> + };
> +
> + buck4: BUCK4 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> +
Re: [PATCH V3 1/2] mtd: allow getting MTD device associated with a specific DT node
Hello Rafał,
On 11.06.22 22:46, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> MTD subsystem API allows interacting with MTD devices (e.g. reading,
> writing, handling bad blocks). So far a random driver could get MTD
> device only by its name (get_mtd_device_nm()). This change allows
> getting them also by a DT node.
>
> This API is required for drivers handling DT defined MTD partitions in a
> specific way (e.g. U-Boot (sub)partition with environment variables).
>
> Signed-off-by: Rafał Miłecki
> ---
> V3: First introduction of of_get_mtd_device_by_node()
>
> mtd maintainers: please let know how would you like this patch
> processed. Would that be OK for you to Review/Ack it and let it go
> through NVMEM tree?
> ---
> drivers/mtd/mtdcore.c | 28
> include/linux/mtd/mtd.h | 1 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 9eb0680db312..7dc214271c85 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1154,6 +1154,34 @@ int __get_mtd_device(struct mtd_info *mtd)
> }
> EXPORT_SYMBOL_GPL(__get_mtd_device);
>
> +/**
> + * of_get_mtd_device_by_node - obtain an MTD device associated with a given
> node
> + *
> + * @np: device tree node
> + */
> +struct mtd_info *of_get_mtd_device_by_node(struct device_node *np)
> +{
> + struct mtd_info *mtd = NULL;
> + struct mtd_info *tmp;
> + int err;
> +
> + mutex_lock(_table_mutex);
> +
> + err = -ENODEV;
Shouldn't this be -EPROBE_DEFER? That way drivers making
use of this function can defer probe until the device
is probed.
> + mtd_for_each_device(tmp) {
> + if (mtd_get_of_node(tmp) == np) {
> + mtd = tmp;
> + err = __get_mtd_device(mtd);
> + break;
> + }
> + }
> +
> + mutex_unlock(_table_mutex);
> +
> + return err ? ERR_PTR(err) : mtd;
> +}
> +EXPORT_SYMBOL_GPL(of_get_mtd_device_by_node);
> +
> /**
> * get_mtd_device_nm - obtain a validated handle for an MTD device by
> * device name
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 955aee14b0f7..6fc841ceef31 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -677,6 +677,7 @@ extern int mtd_device_unregister(struct mtd_info *master);
> extern struct mtd_info *get_mtd_device(struct mtd_info *mtd, int num);
> extern int __get_mtd_device(struct mtd_info *mtd);
> extern void __put_mtd_device(struct mtd_info *mtd);
> +extern struct mtd_info *of_get_mtd_device_by_node(struct device_node *np);
> extern struct mtd_info *get_mtd_device_nm(const char *name);
> extern void put_mtd_device(struct mtd_info *mtd);
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH V3 2/2] nvmem: add driver handling U-Boot environment variables
Hello Rafał,
On 11.06.22 22:46, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> U-Boot stores its setup as environment variables. It's a list of
> key-value pairs stored on flash device with a custom header.
>
> This commit adds an NVMEM driver that:
> 1. Provides NVMEM access to environment vars binary data
> 2. Extracts variables as NVMEM cells
>
> Current Linux's NVMEM sysfs API allows reading whole NVMEM data block.
> It can be used by user-space tools for reading U-Boot env vars block
> without the hassle of finding its location. Parsing will still need to
> be re-done there.
>
> Kernel-parsed NVMEM cells can be read however by Linux drivers. This may
> be uesful for Ethernet drivers for reading device MAC address which is
useful.
> often stored as U-Boot env variable.
>
> Signed-off-by: Rafał Miłecki
> ---
> V3: Use of_get_mtd_device_by_node() (thanks Ahmad) & update description
Looks better now!
> V2: Drop ARCH_BCM4908 dependency as there are plenty architectures using
> U-Boot bootloader. Thanks Srinivas.
>
> As noticed by Ahmad a missing NVMEM subsystem feature is user-space
> access to parsed NVMEM cells. That is something I started working on
> some time ago and I'm planning to get back to at some point, please
> check:
> [PATCH 2/2] nvmem: expose NVMEM cells in sysfs
> https://lore.kernel.org/lkml/20211220064730.28806-2-zaj...@gmail.com/
Thanks for the link.
> ---
> MAINTAINERS| 1 +
> drivers/nvmem/Kconfig | 11 ++
> drivers/nvmem/Makefile | 2 +
> drivers/nvmem/u-boot-env.c | 231 +
> 4 files changed, 245 insertions(+)
> create mode 100644 drivers/nvmem/u-boot-env.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 475e28365385..43b427fa76b0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20411,6 +20411,7 @@ U-BOOT ENVIRONMENT VARIABLES
> M: Rafał Miłecki
> S: Maintained
> F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
> +F: drivers/nvmem/u-boot-env.c
>
> UACCE ACCELERATOR FRAMEWORK
> M: Zhangfei Gao
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index d72d879a6d34..5f1b32b953b9 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -344,4 +344,15 @@ config NVMEM_APPLE_EFUSES
> This driver can also be built as a module. If so, the module will
> be called nvmem-apple-efuses.
>
> +config NVMEM_U_BOOT_ENV
> + tristate "U-Boot environment variables support"
> + depends on OF && MTD
> + select CRC32
> + help
> + U-Boot stores its setup as environment variables. This driver adds
> + support for verifying & exporting such data. It also exposes variables
> + as NVMEM cells so they can be referenced by other drivers.
> +
> + If compiled as module it will be called nvmem_u-boot-env.
You should probably mention that this is tied to MTD somewhere
in the help text as u-boot env on EEPROM/raw eMMC is not covered by this.
> +
> endif
> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> index c710b64f9fe4..399f9972d45b 100644
> --- a/drivers/nvmem/Makefile
> +++ b/drivers/nvmem/Makefile
> @@ -69,3 +69,5 @@ obj-$(CONFIG_NVMEM_APPLE_EFUSES)+= nvmem-apple-efuses.o
> nvmem-apple-efuses-y := apple-efuses.o
> obj-$(CONFIG_MICROCHIP_OTPC) += nvmem-microchip-otpc.o
> nvmem-microchip-otpc-y := microchip-otpc.o
> +obj-$(CONFIG_NVMEM_U_BOOT_ENV) += nvmem_u-boot-env.o
> +nvmem_u-boot-env-y := u-boot-env.o
> diff --git a/drivers/nvmem/u-boot-env.c b/drivers/nvmem/u-boot-env.c
> new file mode 100644
> index ..92c2dd11d99f
> --- /dev/null
> +++ b/drivers/nvmem/u-boot-env.c
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2022 Rafał Miłecki
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum u_boot_env_format {
> + U_BOOT_FORMAT_SINGLE,
> + U_BOOT_FORMAT_REDUNDANT,
> +};
> +
> +struct u_boot_env {
> + struct device *dev;
> + enum u_boot_env_format format;
> +
> + /* Parent device */
> + struct mtd_info *mtd;
> + size_t offset;
> + size_t size;
> +
> + /* Cells */
> + struct nvmem_cell_info *cells;
> + int ncells;
> +};
> +
> +struct u_boot_env_image_single {
> + __le32 crc32;
> + uint8_t data[0];
GCC zero-length arrays are being phased out in favor
of flexible array members. Just replace the [0] with [].
See Documentation/process/deprecated.rst for more information.
> +} __packed;
> +
> +struct u_boot_env_image_redundant {
> + __le32 crc32;
> + u8 mark;
> + uint8_t data[0];
Same here
> +} __packed;
> +
> +static int u_boot_env_read(void *context, unsigned int offset, void *val,
> +size_t bytes)
> +{
> + struct u_boot_env *priv = context;
> + struct device *dev = priv->dev;
> + size_t bytes_read;
> +
[PATCH 1/1] efi_loader: initialize console size late
From: Heinrich Schuchardt
If CONFIG_VIDEO_DM=n we query the display size from the serial console.
Especially when using a remote console the response can be so late that
it interferes with autoboot.
Only query the console size when running an EFI binary.
Add debug output showing the determined console size.
Reported-by: Fabio Estevam
Fixes: a9bf024b2933 ("efi_loader: disk: a helper function to create efi_disk
objects from udevice")
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 2 ++
lib/efi_loader/efi_console.c | 20 +---
lib/efi_loader/efi_setup.c | 4
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f6651e2c60..c1e00ebac3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -499,6 +499,8 @@ extern struct list_head efi_register_notify_events;
int efi_init_early(void);
/* Initialize efi execution environment */
efi_status_t efi_init_obj_list(void);
+/* Set up console modes */
+void efi_setup_console_size(void);
/* Install device tree */
efi_status_t efi_install_fdt(void *fdt);
/* Run loaded UEFI image */
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 60a3fc85ac..3164fd484e 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -5,6 +5,8 @@
* Copyright (c) 2016 Alexander Graf
*/
+#define LOG_CATEGORY LOGC_EFI
+
#include
#include
#include
@@ -12,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -58,7 +61,12 @@ const efi_guid_t efi_guid_text_output_protocol =
#define cESC '\x1b'
#define ESC "\x1b"
-/* Default to mode 0 */
+/*
+ * efi_con_mode - mode information of the Simple Text Output Protocol
+ *
+ * Use safe settings before efi_setup_console_size() is called.
+ * By default enable only the 80x25 mode which must always exist.
+ */
static struct simple_text_output_mode efi_con_mode = {
.max_mode = 1,
.mode = 0,
@@ -333,13 +341,13 @@ static int __maybe_unused query_vidconsole(int *rows, int
*cols)
}
/**
- * query_console_size() - update the mode table.
+ * efi_setup_console_size() - update the mode table.
*
* By default the only mode available is 80x25. If the console has at least 50
* lines, enable mode 80x50. If we can query the console size and it is neither
* 80x25 nor 80x50, set it as an additional mode.
*/
-static void query_console_size(void)
+void efi_setup_console_size(void)
{
int rows = 25, cols = 80;
int ret = -ENODEV;
@@ -351,6 +359,8 @@ static void query_console_size(void)
if (ret)
return;
+ log_debug("Console size %dx%d\n", rows, cols);
+
/* Test if we can have Mode 1 */
if (cols >= 80 && rows >= 50) {
efi_cout_modes[1].present = 1;
@@ -371,7 +381,6 @@ static void query_console_size(void)
}
}
-
/**
* efi_cout_query_mode() - get terminal size for a text mode
*
@@ -1262,9 +1271,6 @@ efi_status_t efi_console_register(void)
efi_status_t r;
struct efi_device_path *dp;
- /* Set up mode information */
- query_console_size();
-
/* Install protocols on root node */
r = EFI_CALL(efi_install_multiple_protocol_interfaces
(_root,
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 250eeb2fcd..492ecf4cb1 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -243,6 +243,10 @@ efi_status_t efi_init_obj_list(void)
goto out;
}
+ /* Set up console modes */
+ efi_setup_console_size();
+
+ /* Install EFI_RNG_PROTOCOL */
if (IS_ENABLED(CONFIG_EFI_RNG_PROTOCOL)) {
ret = efi_rng_register();
if (ret != EFI_SUCCESS)
--
2.36.1
