Re: [PATCH] x86: Drop duplicate declaration of emulator state
Am 21. September 2020 03:58:31 MESZ schrieb Bin Meng : >Hi Simon, > >On Sun, Sep 6, 2020 at 3:15 AM Simon Glass wrote: >> >> With x86 we can execute an option ROM either natively or using the >x86 >> emulator (if enabled with CONFIG_BIOSEMU). Both of these share the >> _X86EMU_env variable, with the native code using it to hold register >state >> during interrupt processing. >> >> At present, in 32-bit U-Boot, the variable is declared twice, once in >> common code and once in code only compiled with CONFIG_BIOSEMU. >> >> With gcc-10 this causes a 'multiple definitions' error on boards with >> CONFIG_BIOSEMU. >> >> Drop the emulator definition, except for 64-bit builds. >> >> Also drop inclusion of the emulator in 64-bit U-Boot since this does >not >> work at present, and generally isn't needed if 32-bit code has >already set >> up the option ROMs. >> >> Reported-by: Heinrich Schuchardt >> Signed-off-by: Simon Glass >> --- >> >> drivers/bios_emulator/x86emu/sys.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/bios_emulator/x86emu/sys.c >b/drivers/bios_emulator/x86emu/sys.c >> index c2db1213fe6..146586b3ceb 100644 >> --- a/drivers/bios_emulator/x86emu/sys.c >> +++ b/drivers/bios_emulator/x86emu/sys.c >> @@ -44,7 +44,11 @@ >> >> /*- Global Variables >--*/ >> >> +/* Definite this here since the emulator is not present on 64-bit */ %s/Definite/Define/ >> +#ifdef CONFIG_X86_64 > >I believe the correct fix is to drop the one in arch/x86/lib/bios.c > >> X86EMU_sysEnv _X86EMU_env; /* Global emulator machine state */ >> +#endif >> + >> X86EMU_intrFuncs _X86EMU_intrTab[256]; >> >> int debug_intr; >> -- > >Regards, >Bin
RE: [PATCH 2/2] ram: add ddr4 dual x8 configuration
> -Original Message- > From: Dylan Hung > Sent: Monday, September 7, 2020 4:25 PM > To: Ryan Chen ; u-boot@lists.denx.de > Cc: BMC-SW > Subject: [PATCH 2/2] ram: add ddr4 dual x8 configuration > > the aspeed ddr sdram controller needs to know if the memory chip mounted > on the board is dual x8 die or not. Or it may get the wrong size of the memory > space. > > Signed-off-by: Dylan Hung Reviewed-by: Ryan Chen > --- > drivers/ram/Kconfig| 1 + > drivers/ram/aspeed/Kconfig | 10 ++ > drivers/ram/aspeed/sdram_ast2500.c | 2 +- > 3 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 > drivers/ram/aspeed/Kconfig > > diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index > 7e6e981897..d277237288 100644 > --- a/drivers/ram/Kconfig > +++ b/drivers/ram/Kconfig > @@ -76,3 +76,4 @@ config IMXRT_SDRAM > source "drivers/ram/rockchip/Kconfig" > source "drivers/ram/sifive/Kconfig" > source "drivers/ram/stm32mp1/Kconfig" > +source "drivers/ram/aspeed/Kconfig" > diff --git a/drivers/ram/aspeed/Kconfig b/drivers/ram/aspeed/Kconfig new file > mode 100644 index 00..020c913188 > --- /dev/null > +++ b/drivers/ram/aspeed/Kconfig > @@ -0,0 +1,10 @@ > +if RAM || SPL_RAM > +config ASPEED_DDR4_DUALX8 > + bool "Enable Dual X8 DDR4 die" > + depends on DM && OF_CONTROL && ARCH_ASPEED > + default n > + help > + Say Y if dual X8 DDR4 die is used on the board. The aspeed ddr > sdram > + controller needs to know if the memory chip mounted on the board > is dual > + x8 die or not. Or it may get the wrong size of the memory > space. > +endif > diff --git a/drivers/ram/aspeed/sdram_ast2500.c > b/drivers/ram/aspeed/sdram_ast2500.c > index a3adaa8a99..8bfbf562c3 100644 > --- a/drivers/ram/aspeed/sdram_ast2500.c > +++ b/drivers/ram/aspeed/sdram_ast2500.c > @@ -247,7 +247,7 @@ static int ast2500_sdrammc_init_ddr4(struct > dram_info *info) > | SDRAM_PCR_RESETN_DIS > | SDRAM_PCR_RGAP_CTRL_EN | SDRAM_PCR_ODT_EN | > SDRAM_PCR_ODT_EXT_EN; > const u32 conf = (SDRAM_CONF_CAP_1024M << > SDRAM_CONF_CAP_SHIFT) -#ifdef CONFIG_DUALX8_RAM > +#ifdef CONFIG_ASPEED_DDR4_DUALX8 > | SDRAM_CONF_DUALX8 > #endif > | SDRAM_CONF_SCRAMBLE | SDRAM_CONF_SCRAMBLE_PAT2 | > SDRAM_CONF_DDR4; > -- > 2.17.1
RE: [PATCH 1/2] ram: move aspeed ram driver into drivers/ directory
> -Original Message-
> From: Dylan Hung
> Sent: Monday, September 7, 2020 4:25 PM
> To: Ryan Chen ; u-boot@lists.denx.de
> Cc: BMC-SW
> Subject: [PATCH 1/2] ram: move aspeed ram driver into drivers/ directory
>
> to improve the maintainability. It is more easier to modify and add
> configurations of the driver in the centralized ram driver directory.
>
> Signed-off-by: Dylan Hung
Reviewed-by: Ryan Chen
> ---
> arch/arm/mach-aspeed/ast2500/Makefile | 2
> +-
> drivers/ram/Makefile | 1
> +
> drivers/ram/aspeed/Makefile| 3
> +++
> .../mach-aspeed/ast2500 => drivers/ram/aspeed}/sdram_ast2500.c | 0
> 4 files changed, 5 insertions(+), 1 deletion(-) create mode 100644
> drivers/ram/aspeed/Makefile rename {arch/arm/mach-aspeed/ast2500 =>
> drivers/ram/aspeed}/sdram_ast2500.c (100%)
>
> diff --git a/arch/arm/mach-aspeed/ast2500/Makefile
> b/arch/arm/mach-aspeed/ast2500/Makefile
> index 4c27c8fc46..db70432ad0 100644
> --- a/arch/arm/mach-aspeed/ast2500/Makefile
> +++ b/arch/arm/mach-aspeed/ast2500/Makefile
> @@ -1,3 +1,3 @@
> obj-y += lowlevel_init.o
> obj-y += board_common.o
> -obj-y += clk_ast2500.o sdram_ast2500.o
> +obj-y += clk_ast2500.o
> diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile index
> 769c9d6218..a57d506752 100644
> --- a/drivers/ram/Makefile
> +++ b/drivers/ram/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>
> obj-$(CONFIG_K3_AM654_DDRSS) += k3-am654-ddrss.o
> obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
> obj-$(CONFIG_K3_J721E_DDRSS) += k3-j721e/
>
> obj-$(CONFIG_IMXRT_SDRAM) += imxrt_sdram.o diff --git
> a/drivers/ram/aspeed/Makefile b/drivers/ram/aspeed/Makefile new file mode
> 100644 index 00..af604f8a4b
> --- /dev/null
> +++ b/drivers/ram/aspeed/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +obj-$(CONFIG_ASPEED_AST2500) += sdram_ast2500.o
> \ No newline at end of file
> diff --git a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
> b/drivers/ram/aspeed/sdram_ast2500.c
> similarity index 100%
> rename from arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
> rename to drivers/ram/aspeed/sdram_ast2500.c
> --
> 2.17.1
Re: Pending x86 patches
Hi Simon, On Mon, Sep 21, 2020 at 3:19 AM Simon Glass wrote: > > Hi Bin, > > At present I have a lot of x86 patches pending, such that it is very > difficult to make further progress. > > I'd like to suggest that we get these into a 'next' branch ASAP so I > can finalise the coral ACPI support. > > I'm happy to do this if you are busy. If there are review comments we > can squash them in before applying to master. > Sorry for the delay. I will try to clean up the queue this week, and have the next branch as soon as possible. Regards, Bin
Re: [PATCH v2 01/16] x86: Update the bootparam header
Hi Andy,
On Tue, Sep 8, 2020 at 10:06 PM Andy Shevchenko
wrote:
>
> On Tue, Sep 01, 2020 at 04:23:45PM +0800, Bin Meng wrote:
> > On Sun, Aug 30, 2020 at 5:42 AM Simon Glass wrote:
> > >
> > > This header is missing a few of the newer features from the specification.
> > > Add these as well as a link to the spec. Also use the BIT() macros where
> > > appropriate.
>
> > > +/**
> > > + * struct setup_header - Information needed by Linux to boot
> > > + *
> > > + * See https://www.kernel.org/doc/html/latest/x86/boot.html
> >
> > Now I am confused. This kernel document says:
> >
> > Protocol 2.14 BURNT BY INCORRECT COMMIT
> > ae7e1238e68f2a472a125673ab506d49158c1889 (x86/boot: Add ACPI RSDP
> > address to setup_header) DO NOT USE!!! ASSUME SAME AS 2.13.
>
> Where did you get this "DO NOT USE!!! ASSUME SAME AS 2.13" from?
Please see:
https://www.kernel.org/doc/html/latest/x86/boot.html
Chapter "1. The Linux/x86 Boot Protocol"
Protocol 2.14 BURNT BY INCORRECT COMMIT
ae7e1238e68f2a472a125673ab506d49158c1889 (x86/boot: Add ACPI RSDP
address to setup_header) DO NOT USE!!! ASSUME SAME AS 2.13.
>
>
> > However in U-Boot there was a commit from Andy saying that:
> >
> > commit d905aa8a4277e200e11fdf6d73a7c76d0e6f34a4 (<=== U-Boot commit)
> > Author: Andy Shevchenko
> > Date: Fri Sep 13 18:42:00 2019 +0300
> >
> > x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters
> >
> > ...
> >
> > after upstream got eventually the Linux kernel
> >
> > commit e6e094e053af75cbc164e950814d3d084fb1e698
> > Author: Juergen Gross
> > Date: Tue Nov 20 08:25:29 2018 +0100
> >
> > x86/acpi, x86/boot: Take RSDP address from boot params if available
> >
> > So there are 2 commits in the Linux kernel that do the same thing, one
> > in boot_params, the other one in setup_header?
>
> I think this
> 384184044981 ("x86/boot: Mostly revert commit ae7e1238e68f2a ("Add ACPI RSDP
> address to setup_header")")
> explains what happened.
Thanks for the info.
>
> > e6e094e053af75cbc164e950814d3d084fb1e698 : x86/acpi, x86/boot: Take
> > RSDP address from boot params if available
> > ae7e1238e68f2a472a125673ab506d49158c1889 : x86/boot: Add ACPI RSDP
> > address to setup_header
> >
Regards,
Bin
RE: [PATCH] pci: layerscape: Remove the shadow SVR definitiones
Hi Priyanka, Thanks a lot for your comments! > -Original Message- > From: Priyanka Jain > Sent: 2020年9月18日 21:53 > To: Z.q. Hou ; u-boot@lists.denx.de; Wasim Khan > > Cc: Z.q. Hou > Subject: RE: [PATCH] pci: layerscape: Remove the shadow SVR definitiones > > >-Original Message- > >From: Zhiqiang Hou > >Sent: Friday, September 18, 2020 1:53 PM > >To: u-boot@lists.denx.de; Priyanka Jain ; Wasim > >Khan > >Cc: Z.q. Hou > >Subject: [PATCH] pci: layerscape: Remove the shadow SVR definitiones > > > sp mistake: definitions I'll correct in next version. Regards, Zhiqiang > >From: Hou Zhiqiang > > > >This patch moves the SVR definitiones to a new svr.h for Layerscape > >armv7 > sp mistake: definitions > > >and armv8 platforms respectively, so that the PCIe driver can reuse them. > > > >Signed-off-by: Hou Zhiqiang > >--- > > > Regards > Priyanka
Re: [PATCH v1] cmd: acpi: Print revisions in hex format
Hi Andy,
On Tue, Sep 8, 2020 at 10:30 PM Andy Shevchenko
wrote:
>
> The revisions are usually dates in hex-decimal format representing
> mmdd. Print them in hex to see this clearly.
>
> Before:
> ...
> FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 538970376 INTL 0)
> DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 65536 INTL 538968870)
> ...
> After:
> ...
> FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 20200908 INTL 0)
> DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 1 INTL 20200326)
> ...
>
> Fixes: 0b885bcfd9b0 ("acpi: Add an acpi command")
> Cc: Wolfgang Wallner
> Signed-off-by: Andy Shevchenko
> ---
> cmd/acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/acpi.c b/cmd/acpi.c
> index 085a3a650d1a..a3419b42b556 100644
> --- a/cmd/acpi.c
> +++ b/cmd/acpi.c
> @@ -26,7 +26,7 @@ static void dump_hdr(struct acpi_table_header *hdr)
> printf("%.*s %08lx %06x", ACPI_NAME_LEN, hdr->signature,
>(ulong)map_to_sysmem(hdr), hdr->length);
> if (has_hdr) {
> - printf(" (v%02d %.6s %.8s %u %.4s %d)\n", hdr->revision,
> + printf(" (v%02d %.6s %.8s %x %.4s %x)\n", hdr->revision,
>hdr->oem_id, hdr->oem_table_id, hdr->oem_revision,
>hdr->aslc_id, hdr->aslc_revision);
> } else {
> --
This unfortunately breaks the unit test.
/u/test/dm/acpi.c:371, dm_test_acpi_cmd_list(): console:
Expected 'RSDT 0570ebf0 30 (v01 U-BOOT U-BOOTBL 538970401 INTL 0)',
got 'RSDT 0570ebf0 30 (v01 U-BOOT U-BOOTBL 20200921 INTL 0)'
Failures: 2
Would you please resend v2 to fix this?
Regards,
Bin
Re: [PATCH] x86: Drop duplicate declaration of emulator state
Hi Simon, On Sun, Sep 6, 2020 at 3:15 AM Simon Glass wrote: > > With x86 we can execute an option ROM either natively or using the x86 > emulator (if enabled with CONFIG_BIOSEMU). Both of these share the > _X86EMU_env variable, with the native code using it to hold register state > during interrupt processing. > > At present, in 32-bit U-Boot, the variable is declared twice, once in > common code and once in code only compiled with CONFIG_BIOSEMU. > > With gcc-10 this causes a 'multiple definitions' error on boards with > CONFIG_BIOSEMU. > > Drop the emulator definition, except for 64-bit builds. > > Also drop inclusion of the emulator in 64-bit U-Boot since this does not > work at present, and generally isn't needed if 32-bit code has already set > up the option ROMs. > > Reported-by: Heinrich Schuchardt > Signed-off-by: Simon Glass > --- > > drivers/bios_emulator/x86emu/sys.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/bios_emulator/x86emu/sys.c > b/drivers/bios_emulator/x86emu/sys.c > index c2db1213fe6..146586b3ceb 100644 > --- a/drivers/bios_emulator/x86emu/sys.c > +++ b/drivers/bios_emulator/x86emu/sys.c > @@ -44,7 +44,11 @@ > > /*- Global Variables --*/ > > +/* Definite this here since the emulator is not present on 64-bit */ > +#ifdef CONFIG_X86_64 I believe the correct fix is to drop the one in arch/x86/lib/bios.c > X86EMU_sysEnv _X86EMU_env; /* Global emulator machine state */ > +#endif > + > X86EMU_intrFuncs _X86EMU_intrTab[256]; > > int debug_intr; > -- Regards, Bin
Re: [PATCH v2 1/2] x86: acpi: Fix calculation of DSDT length
On Mon, Sep 21, 2020 at 9:42 AM Bin Meng wrote: > > On Wed, Sep 16, 2020 at 10:57 PM Wolfgang Wallner > wrote: > > > > Currently, the calculation for the length of the DSDT table includes any > > bytes that are added for alignment, but those bytes are not initialized. > > > > This is because the DSDT length is calculated after a call to > > acpi_inc_align(). Split this up into the following sequence: > > > > * acpi_inc() > > * Calculate DSDT length > > * acpi_align() > > > > Signed-off-by: Wolfgang Wallner > > Reviewed-by: Andy Shevchenko > > Reviewed-by: Simon Glass > > > > --- > > > > Changes in v2: > > - Added Reviewed-by tags > > > > arch/x86/lib/acpi_table.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v2 2/2] x86: acpi: Add memset to initialize SPCR table
On Mon, Sep 21, 2020 at 9:43 AM Bin Meng wrote:
>
> On Wed, Sep 16, 2020 at 11:12 PM Andy Shevchenko
> wrote:
> >
> > On Wed, Sep 16, 2020 at 04:57:53PM +0200, Wolfgang Wallner wrote:
> > > Add a missing memset to acpi_create_spcr().
> > >
> > > The other acpi_create_() functions perform a memset on their
> > > structures, acpi_create_spcr() does not and as a result the contents of
> > > this table are partly uninitialized (and thus random after every reset).
> >
> > > Fixes: commit b288cd960072 ("x86: acpi: Generate SPCR table")
> > >
> > > Signed-off-by: Wolfgang Wallner
> >
> > In tag block should not be any blank line, but I guess maintainer can fix
> > this
> > when applying (i.o.w. no need to resend).
>
> Yep, normally I will fix such kinds of issues when applying. Thanks
> for pointing it out.
Fixed the tags format, and
>
> >
> > > Reviewed-by: Andy Shevchenko
> > > Reviewed-by: Simon Glass
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - Removed unrelated whitespace change
> > > - Added Reviewed-by tags
> > >
> > > arch/x86/lib/acpi_table.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> > > index 6b827bfa3f..c445aa6870 100644
> > > --- a/arch/x86/lib/acpi_table.c
> > > +++ b/arch/x86/lib/acpi_table.c
> > > @@ -252,6 +252,8 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
> > > int space_id;
> > > int ret = -ENODEV;
> > >
> > > + memset((void *)spcr, 0, sizeof(struct acpi_spcr));
> > > +
> > > /* Fill out header fields */
> > > acpi_fill_header(header, "SPCR");
> > > header->length = sizeof(struct acpi_spcr);
> > > --
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Re: [PATCH v2 2/2] x86: acpi: Add memset to initialize SPCR table
On Wed, Sep 16, 2020 at 11:12 PM Andy Shevchenko
wrote:
>
> On Wed, Sep 16, 2020 at 04:57:53PM +0200, Wolfgang Wallner wrote:
> > Add a missing memset to acpi_create_spcr().
> >
> > The other acpi_create_() functions perform a memset on their
> > structures, acpi_create_spcr() does not and as a result the contents of
> > this table are partly uninitialized (and thus random after every reset).
>
> > Fixes: commit b288cd960072 ("x86: acpi: Generate SPCR table")
> >
> > Signed-off-by: Wolfgang Wallner
>
> In tag block should not be any blank line, but I guess maintainer can fix this
> when applying (i.o.w. no need to resend).
Yep, normally I will fix such kinds of issues when applying. Thanks
for pointing it out.
>
> > Reviewed-by: Andy Shevchenko
> > Reviewed-by: Simon Glass
> >
> > ---
> >
> > Changes in v2:
> > - Removed unrelated whitespace change
> > - Added Reviewed-by tags
> >
> > arch/x86/lib/acpi_table.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> > index 6b827bfa3f..c445aa6870 100644
> > --- a/arch/x86/lib/acpi_table.c
> > +++ b/arch/x86/lib/acpi_table.c
> > @@ -252,6 +252,8 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
> > int space_id;
> > int ret = -ENODEV;
> >
> > + memset((void *)spcr, 0, sizeof(struct acpi_spcr));
> > +
> > /* Fill out header fields */
> > acpi_fill_header(header, "SPCR");
> > header->length = sizeof(struct acpi_spcr);
> > --
Reviewed-by: Bin Meng
Re: [PATCH v2 1/2] x86: acpi: Fix calculation of DSDT length
On Wed, Sep 16, 2020 at 10:57 PM Wolfgang Wallner wrote: > > Currently, the calculation for the length of the DSDT table includes any > bytes that are added for alignment, but those bytes are not initialized. > > This is because the DSDT length is calculated after a call to > acpi_inc_align(). Split this up into the following sequence: > > * acpi_inc() > * Calculate DSDT length > * acpi_align() > > Signed-off-by: Wolfgang Wallner > Reviewed-by: Andy Shevchenko > Reviewed-by: Simon Glass > > --- > > Changes in v2: > - Added Reviewed-by tags > > arch/x86/lib/acpi_table.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH] x86: fsp: Replace e-mmc with emmc in devicetree bindings
On Mon, Sep 21, 2020 at 9:33 AM Bin Meng wrote: > > On Fri, Sep 11, 2020 at 10:52 PM Wolfgang Wallner > wrote: > > > > The term eMMC is used inconsistently within the FSP devicetree > > bindigs (e-mmc and emmc), especially for "emmc-host-max-speed" > > typo: bindings > > I can fix this when applying Fixed the typo, and > > > documentation and code disagree. > > > > Change all eMMC instances within the FSP bindings to consistently > > use "emmc". The term "emmc" is already used a lot within U-Boot, > > while "e-mmc" is only used in the FSP bindings. > > > > Signed-off-by: Wolfgang Wallner > > > > --- > > > > arch/x86/cpu/apollolake/fsp_bindings.c | 6 +++--- > > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt | 2 +- > > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt | 2 +- > > 3 files changed, 5 insertions(+), 5 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v1] cmd: acpi: Print revisions in hex format
On Mon, Sep 21, 2020 at 9:31 AM Bin Meng wrote:
>
> On Tue, Sep 8, 2020 at 10:30 PM Andy Shevchenko
> wrote:
> >
> > The revisions are usually dates in hex-decimal format representing
> > mmdd. Print them in hex to see this clearly.
> >
> > Before:
> > ...
> > FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 538970376 INTL 0)
> > DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 65536 INTL 538968870)
> > ...
> > After:
> > ...
> > FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 20200908 INTL 0)
> > DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 1 INTL 20200326)
> > ...
> >
> > Fixes: 0b885bcfd9b0 ("acpi: Add an acpi command")
> > Cc: Wolfgang Wallner
> > Signed-off-by: Andy Shevchenko
> > ---
> > cmd/acpi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Re: [PATCH v1] x86: edison: Move config SYS_MALLOC_LEN to Kconfig
On Mon, Sep 21, 2020 at 9:29 AM Bin Meng wrote:
>
> On Tue, Sep 8, 2020 at 9:57 PM Andy Shevchenko
> wrote:
> >
> > This patch moves the the config SYS_MALLOC_LEN to Kconfig
> > as it is already done for zynq arch in commit 01aa5b8f0503
> > ("Kconfig: Move config SYS_MALLOC_LEN to Kconfig for zynq").
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> > board/intel/edison/Kconfig | 3 +++
> > include/configs/edison.h | 4
> > 2 files changed, 3 insertions(+), 4 deletions(-)
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
Re: [PATCH] x86: fsp: Replace e-mmc with emmc in devicetree bindings
On Fri, Sep 11, 2020 at 10:52 PM Wolfgang Wallner wrote: > > The term eMMC is used inconsistently within the FSP devicetree > bindigs (e-mmc and emmc), especially for "emmc-host-max-speed" typo: bindings I can fix this when applying > documentation and code disagree. > > Change all eMMC instances within the FSP bindings to consistently > use "emmc". The term "emmc" is already used a lot within U-Boot, > while "e-mmc" is only used in the FSP bindings. > > Signed-off-by: Wolfgang Wallner > > --- > > arch/x86/cpu/apollolake/fsp_bindings.c | 6 +++--- > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-m.txt | 2 +- > doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v1] cmd: acpi: Print revisions in hex format
On Tue, Sep 8, 2020 at 10:30 PM Andy Shevchenko
wrote:
>
> The revisions are usually dates in hex-decimal format representing
> mmdd. Print them in hex to see this clearly.
>
> Before:
> ...
> FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 538970376 INTL 0)
> DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 65536 INTL 538968870)
> ...
> After:
> ...
> FACP 000e5420 f4 (v06 U-BOOT U-BOOTBL 20200908 INTL 0)
> DSDT 000e4780 000ba0 (v02 U-BOOT U-BOOTBL 1 INTL 20200326)
> ...
>
> Fixes: 0b885bcfd9b0 ("acpi: Add an acpi command")
> Cc: Wolfgang Wallner
> Signed-off-by: Andy Shevchenko
> ---
> cmd/acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v1] x86: edison: Move config SYS_MALLOC_LEN to Kconfig
On Tue, Sep 8, 2020 at 9:57 PM Andy Shevchenko
wrote:
>
> This patch moves the the config SYS_MALLOC_LEN to Kconfig
> as it is already done for zynq arch in commit 01aa5b8f0503
> ("Kconfig: Move config SYS_MALLOC_LEN to Kconfig for zynq").
>
> Signed-off-by: Andy Shevchenko
> ---
> board/intel/edison/Kconfig | 3 +++
> include/configs/edison.h | 4
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
Reviewed-by: Bin Meng
Re: [PATCH] acpi: device: Fix check for sequence number
Hi Wolfgang,
On Thu, Sep 10, 2020 at 3:01 PM Wolfgang Wallner
wrote:
>
> Hi Simon,
>
> -"Simon Glass" schrieb: -
> > Betreff: Re: [PATCH] acpi: device: Fix check for sequence number
> >
> > Hi Wolfgang,
> >
> > On Thu, 13 Aug 2020 at 01:23, Wolfgang Wallner
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > -"Simon Glass" schrieb: -
> > > > Betreff: Re: [PATCH] acpi: device: Fix check for sequence number
> > > >
> > > > Hi Wolfgang,
> > > >
> > > > On Thu, 30 Jul 2020 at 06:47, Wolfgang Wallner
> > > > wrote:
> > > > >
> > > > > Currently the function acpi_check_seq() checks whether dev->req_seq is
> > > > > unequal to "-1", but it should actually check dev->seq. Change it to
> > > > > check dev->seq.
> > > > >
> > > > > For req_seq the value "-1" would be a valid (meaning 'any'), while for
> > > > > seq the value "-1" means 'none' and is not valid.
> > > > >
> > > > > Quoting the description of udevice in device.h:
> > > > > * @req_seq: Requested sequence number for this device (-1 = any)
> > > > > * @seq: Allocated sequence number for this device (-1 = none).
> > > > > * This is set up when the device is probed and will be unique
> > > > > * within the device's uclass.
> > > > >
> > > > > Signed-off-by: Wolfgang Wallner
> > > > >
> > > > > Fixes: commit fefac0b0643b ("dm: acpi: Enhance acpi_get_name()")
> > > > >
> > > > > ---
> > > > >
> > > > > lib/acpi/acpi_device.c | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > >
> > > > What problem are you seeing without this patch?
> > >
> > > I see the following warning: "Device 'serial@18,2' has no seq".
> > >
> > > In my case req_seq for the UART is -1 ("any"), while seq is 0.
> > > Why would we check for req_seq and not for seq in this function?
> > >
> > > > At present the ACPI device may not always be probed, and probing is
> > > > when the sequence number is currently set up.
> > >
> > > In my case the UART is already probed before the ACPI tables are
> > > generated.
> >
> > I would expect req_seq to be set to the UART number, i.e. the value of
> > the alias (uart0, uart1) that points to the node.
> >
> > I wonder why that doesn't work in your case?
>
> I did not have an alias for my serial. I have added one and now it works as
> expected.
>
> I misunderstood how that code is expected to work. Thanks for the explanation,
> now it makes sense.
>
> This also means that my patch is wrong and should be dropped.
> @Bin: please drop this patch.
Thanks. Have updated the status of this patch in patchwork.
>
> > Are you sure that all UARTs are probed before ACPI tables are created?
> > Normally U-Boot would only probe the one being used for the console.
> >
> > >
> > > >
> > > > I have been thinking about dropping req_seq and doing everything when
> > > > the device is bound, but haven't dug into it in detail yet.
>
Regards,
Bin
Re: x86: apl: Acessing SPI flash when booting with Coreboot/U-Boot
Hi Simon, Wolfgang,
On Sun, Aug 16, 2020 at 11:40 AM Simon Glass wrote:
>
> Hi Wolfgang,
>
> On Fri, 14 Aug 2020 at 08:04, Wolfgang Wallner
> wrote:
> >
> > Hi Simon,
> >
> > Since commit 609b90a6a9c0 ("x86: spi: Rewrite logic for obtaining the SPI
> > memory map") I have trouble accessing the SPI flash on my Apollo Lake board
> > when booting with Coreboot and having U-Boot as the payload.
> >
> > Accessing the SPI flash returns -91 (EPROTOTYPE).
> >
> > My understanding of what happens is the following:
> >
> > - ich_spi_ofdata_to_platdata() calls ich_spi_get_basics(), the parameter
> >'can_probe' is hardcoded to true
> > - There is no PCH device in my devicetree (there is also no PCH driver
> >contained in my build)
> > - As can_probe is true, ich_spi_get_basics() tries to find a PCH device
> >and returns -EPROTOTYPE as it finds none
> >
> > As far as I see the PCH is not used in the code paths relevant to Apollo
> > Lake.
> > I think this behavior can not be triggered in a standalone U-Boot on Apollo
> > Lake,
> > as in this case arch_cpu_init_tpl() requires an LPC, which is below the PCH,
> > and so a PCH has to be part of the devicetree anyway. In this case a PCH
> > would
> > be found in ich_spi_get_basics(), but it would not get used.
> >
> > As a quick workaround [1], I have set can_probe hardcoded to false, and with
> > this change I can access the SPI flash again.
> >
> > Do you have any advice on how to fix this?
> > How about making the value for can_probe depend on a check for
> > ich_version == ICHV_APL?
>
> That might be OK I think.
>
> I am quite unhappy with how this has turned out. It seems like we
> might be able to refactor it to reduce the number of cases.
Since this patch is viewed as only a workaround, would you propose a
fix for this issue?
Regards,
Bin
Re: [PATCH 3/3] Fix missing __udivdi3 in SquashFS implementation.
On Sun, Sep 20, 2020 at 06:29:01PM +0200, Mauro Condarelli wrote:
> Signed-off-by: Mauro Condarelli
> ---
> fs/squashfs/sqfs.c| 45 +--
> fs/squashfs/sqfs_inode.c | 8 +++
> include/configs/vocore2.h | 2 +-
> 3 files changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> index 15208b4dab..b49331ce93 100644
> --- a/fs/squashfs/sqfs.c
> +++ b/fs/squashfs/sqfs.c
> @@ -18,6 +18,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "sqfs_decompressor.h"
> #include "sqfs_filesystem.h"
> @@ -82,13 +84,16 @@ static int sqfs_count_tokens(const char *filename)
> */
> static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
> {
> - u64 start_, table_size;
> + u64 start_, table_size, blks;
>
> table_size = le64_to_cpu(end) - le64_to_cpu(start);
> - start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
> + start_ = le64_to_cpu(start);
> + do_div(start_, ctxt.cur_dev->blksz);
> *offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
>
> - return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
> + blks = table_size + *offset;
> + if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
> + return blks;
> }
>
> /*
> @@ -109,8 +114,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
> if (inode_fragment_index >= get_unaligned_le32(>fragments))
> return -EINVAL;
>
> - start = get_unaligned_le64(>fragment_table_start) /
> - ctxt.cur_dev->blksz;
> + start = get_unaligned_le64(>fragment_table_start);
> + do_div(start, ctxt.cur_dev->blksz);
> n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
> sblk->export_table_start,
> _offset);
> @@ -135,7 +140,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
> start_block = get_unaligned_le64(table + table_offset + block *
>sizeof(u64));
>
> - start = start_block / ctxt.cur_dev->blksz;
> + start = start_block;
> + do_div(start, ctxt.cur_dev->blksz);
> n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
> sblk->fragment_table_start, _offset);
>
> @@ -641,8 +647,8 @@ static int sqfs_read_inode_table(unsigned char
> **inode_table)
>
> table_size = get_unaligned_le64(>directory_table_start) -
> get_unaligned_le64(>inode_table_start);
> - start = get_unaligned_le64(>inode_table_start) /
> - ctxt.cur_dev->blksz;
> + start = get_unaligned_le64(>inode_table_start);
> + do_div(start, ctxt.cur_dev->blksz);
> n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
> sblk->directory_table_start, _offset);
>
> @@ -725,8 +731,8 @@ static int sqfs_read_directory_table(unsigned char
> **dir_table, u32 **pos_list)
> /* DIRECTORY TABLE */
> table_size = get_unaligned_le64(>fragment_table_start) -
> get_unaligned_le64(>directory_table_start);
> - start = get_unaligned_le64(>directory_table_start) /
> - ctxt.cur_dev->blksz;
> + start = get_unaligned_le64(>directory_table_start);
> + do_div(start, ctxt.cur_dev->blksz);
> n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
> sblk->fragment_table_start, _offset);
>
> @@ -1158,6 +1164,7 @@ static int sqfs_get_regfile_info(struct
> squashfs_reg_inode *reg,
> fentry);
> if (ret < 0)
> return -EINVAL;
> +
> finfo->comp = true;
> if (fentry->size < 1 || fentry->start == 0x7FFF)
> return -EINVAL;
> @@ -1328,17 +1335,19 @@ int sqfs_read(const char *filename, void *buf, loff_t
> offset, loff_t len,
> data_offset = finfo.start;
> datablock = malloc(get_unaligned_le32(>block_size));
> if (!datablock) {
> + printf("Error: malloc(%u) failed.\n",
> get_unaligned_le32(>block_size));
> ret = -ENOMEM;
> goto free_paths;
> }
> }
>
> for (j = 0; j < datablk_count; j++) {
> - start = data_offset / ctxt.cur_dev->blksz;
> + start = data_offset;
> + do_div(start, ctxt.cur_dev->blksz);
> table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
> table_offset = data_offset - (start * ctxt.cur_dev->blksz);
> - n_blks = DIV_ROUND_UP(table_size + table_offset,
> - ctxt.cur_dev->blksz);
> + n_blks = table_size + table_offset;
> + if (do_div(n_blks, ctxt.cur_dev->blksz)) n_blks++;
>
> data_buffer = malloc_cache_aligned(n_blks *
> ctxt.cur_dev->blksz);
>
> @@ -1365,8 +1374,10 @@
Re: [PATCH] usb: storage: increase retries to 20
On 2020-09-20 21:01, Stefan Agner wrote:
> A JMicron JMS583 based NVMe to USB 3.1 enclosure connected to a Raspberry
> Pi 4 fails to enumerate as a USB Mass Storage device on first try:
>
> ...
> startig USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devces... Device NOT ready
> Request Sense returned 02 04 01
> 4 USB Device(s) found
> scanning usb for storage devices... 0 Sorage Device(s) found
It turned out, the device was not sufficiently powered. Even after I was
able to use U-Boot to boot from it, Linux reported USB resets every ~30s
or so.
Supplying the device with enough power (e.g. by connecting via powered
USB 3.0 Hub) things started to work better: The device was always ready
below 1s (8 tries). So it seems that the default of 10 is actually good
enough also for this device.
--
Stefan
>
> However, it consistently works on the second try. It seems that the
> device takes longer than 1s to detect the media. With debug enabled
> it shows that the 11th retry count typically works.
>
> Increase retries to 20 for a startup time of up to 2s.
>
> Signed-off-by: Stefan Agner
> ---
> common/usb_storage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index ff25441995..04910de21f 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -1019,7 +1019,7 @@ static int usb_request_sense(struct scsi_cmd
> *srb, struct us_data *ss)
>
> static int usb_test_unit_ready(struct scsi_cmd *srb, struct us_data *ss)
> {
> - int retries = 10;
> + int retries = 20;
>
> do {
> memset(>cmd[0], 0, 12);
Pending x86 patches
Hi Bin, At present I have a lot of x86 patches pending, such that it is very difficult to make further progress. I'd like to suggest that we get these into a 'next' branch ASAP so I can finalise the coral ACPI support. I'm happy to do this if you are busy. If there are review comments we can squash them in before applying to master. Regards, Simon
[PATCH] usb: storage: increase retries to 20
A JMicron JMS583 based NVMe to USB 3.1 enclosure connected to a Raspberry
Pi 4 fails to enumerate as a USB Mass Storage device on first try:
...
startig USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devces... Device NOT ready
Request Sense returned 02 04 01
4 USB Device(s) found
scanning usb for storage devices... 0 Sorage Device(s) found
However, it consistently works on the second try. It seems that the
device takes longer than 1s to detect the media. With debug enabled
it shows that the 11th retry count typically works.
Increase retries to 20 for a startup time of up to 2s.
Signed-off-by: Stefan Agner
---
common/usb_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/usb_storage.c b/common/usb_storage.c
index ff25441995..04910de21f 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -1019,7 +1019,7 @@ static int usb_request_sense(struct scsi_cmd *srb, struct
us_data *ss)
static int usb_test_unit_ready(struct scsi_cmd *srb, struct us_data *ss)
{
- int retries = 10;
+ int retries = 20;
do {
memset(>cmd[0], 0, 12);
--
2.28.0
[PATCH 2/2] microblaze: start.S: Use board_init_f_alloc/init in early init
Implement early init by calling generic board_init_f_alloc_reserve and board_init_f_init_reserve functions: * drop SYS_MALLOC_F_LEN related code, as allocation and gd->malloc_base assignment are taken care of by the generic functions * drop _gd logic Signed-off-by: Ovidiu Panait --- arch/microblaze/cpu/start.S | 45 ++--- 1 file changed, 22 insertions(+), 23 deletions(-) diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S index f3be014317..1f580b1112 100644 --- a/arch/microblaze/cpu/start.S +++ b/arch/microblaze/cpu/start.S @@ -17,25 +17,40 @@ _start: addir8, r0, __end mts rslr, r8 - /* TODO: Redo this code to call board_init_f_*() */ + #if defined(CONFIG_SPL_BUILD) addir1, r0, CONFIG_SPL_STACK_ADDR - mts rshr, r1 - addir1, r1, -4 /* Decrement SP to top of memory */ -#else -#if CONFIG_VAL(SYS_MALLOC_F_LEN) - addir1, r0, CONFIG_SYS_INIT_SP_OFFSET - CONFIG_VAL(SYS_MALLOC_F_LEN) #else addir1, r0, CONFIG_SYS_INIT_SP_OFFSET #endif + mts rshr, r1 addir1, r1, -4 /* Decrement SP to top of memory */ + /* Call board_init_f_alloc_reserve with the current stack pointer as +* parameter. */ + add r5, r0, r1 + bralid r15, board_init_f_alloc_reserve + nop + + /* board_init_f_alloc_reserve returns a pointer to the allocated area +* in r3. Set the new stack pointer below this area. */ + add r1, r0, r3 + mts rshr, r1 + addir1, r1, -4 + + /* Call board_init_f_init_reserve with the address returned by +* board_init_f_alloc_reserve as parameter. */ + add r5, r0, r3 + bralid r15, board_init_f_init_reserve + nop + +#if !defined(CONFIG_SPL_BUILD) /* Setup vectors with pre-relocation symbols */ or r5, r0, r0 bralid r15, __setup_exceptions nop -#endif /* CONFIG_SPL_BUILD */ +#endif /* Flush cache before enable cache */ addik r5, r0, 0 @@ -48,7 +63,6 @@ _start: ori r12, r12, 0x1a0 mts rmsr, r12 - /* TODO: Redo this code to call board_init_f_*() */ clear_bss: /* clear BSS segments */ addir5, r0, __bss_start @@ -67,27 +81,12 @@ clear_bss: #endif #ifndef CONFIG_SPL_BUILD or r5, r0, r0 /* flags - empty */ - addir31, r0, _gd -#if CONFIG_VAL(SYS_MALLOC_F_LEN) - addir6, r0, CONFIG_SYS_INIT_SP_OFFSET - swi r6, r31, GD_MALLOC_BASE -#endif braiboard_init_f #else - addir31, r0, _gd -#if CONFIG_VAL(SYS_MALLOC_F_LEN) - addir6, r0, CONFIG_SPL_STACK_ADDR - swi r6, r31, GD_MALLOC_BASE -#endif braiboard_init_r #endif 1: bri 1b - .section .bss -.align 4 -_gd: - .space GENERATED_GBL_DATA_SIZE - #ifndef CONFIG_SPL_BUILD .text .ent__setup_exceptions -- 2.17.1
[PATCH 1/2] microblaze: start.S: Factor out exception setup code to __setup_exceptions
Currently, the exceptions setup code is duplicated in pre-relocation and post-relocation init. Factor out this code to __setup_exceptions asm routine to get rid of the duplication. __setup_exceptions is called with a relocation offset parameter (r5) which is set to zero for pre-reloc init and gd->reloc_off for post-reloc exception setup. Signed-off-by: Ovidiu Panait --- arch/microblaze/cpu/start.S | 183 +--- 1 file changed, 88 insertions(+), 95 deletions(-) diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S index cbec299b7d..f3be014317 100644 --- a/arch/microblaze/cpu/start.S +++ b/arch/microblaze/cpu/start.S @@ -13,13 +13,6 @@ .text .global _start _start: - /* -* reserve registers: -* r10: Stores little/big endian offset for vectors -* r2: Stores imm opcode -* r3: Stores brai opcode -*/ - mts rmsr, r0/* disable cache */ addir8, r0, __end @@ -38,6 +31,84 @@ _start: mts rshr, r1 addir1, r1, -4 /* Decrement SP to top of memory */ + /* Setup vectors with pre-relocation symbols */ + or r5, r0, r0 + bralid r15, __setup_exceptions + nop +#endif /* CONFIG_SPL_BUILD */ + + /* Flush cache before enable cache */ + addik r5, r0, 0 + addik r6, r0, XILINX_DCACHE_BYTE_SIZE + bralid r15, flush_cache + nop + + /* enable instruction and data cache */ + mfs r12, rmsr + ori r12, r12, 0x1a0 + mts rmsr, r12 + + /* TODO: Redo this code to call board_init_f_*() */ +clear_bss: + /* clear BSS segments */ + addir5, r0, __bss_start + addir4, r0, __bss_end + cmp r6, r5, r4 + beqir6, 3f +2: + swi r0, r5, 0 /* write zero to loc */ + addir5, r5, 4 /* increment to next loc */ + cmp r6, r5, r4 /* check if we have reach the end */ + bneir6, 2b +3: /* jumping to board_init */ +#ifdef CONFIG_DEBUG_UART + bralid r15, debug_uart_init + nop +#endif +#ifndef CONFIG_SPL_BUILD + or r5, r0, r0 /* flags - empty */ + addir31, r0, _gd +#if CONFIG_VAL(SYS_MALLOC_F_LEN) + addir6, r0, CONFIG_SYS_INIT_SP_OFFSET + swi r6, r31, GD_MALLOC_BASE +#endif + braiboard_init_f +#else + addir31, r0, _gd +#if CONFIG_VAL(SYS_MALLOC_F_LEN) + addir6, r0, CONFIG_SPL_STACK_ADDR + swi r6, r31, GD_MALLOC_BASE +#endif + braiboard_init_r +#endif +1: bri 1b + + .section .bss +.align 4 +_gd: + .space GENERATED_GBL_DATA_SIZE + +#ifndef CONFIG_SPL_BUILD + .text + .ent__setup_exceptions + .align 2 +/* + * Set up reset, interrupt, user exception and hardware exception vectors. + * + * Parameters: + * r5 - relocation offset (zero when setting up vectors before + * relocation, and gd->reloc_off when setting up vectors after + * relocation) + *- the relocation offset is added to the _exception_handler, + * _interrupt_handler and _hw_exception_handler symbols to reflect the + * post-relocation memory addresses + * + * Reserve registers: + * r10: Stores little/big endian offset for vectors + * r2: Stores imm opcode + * r3: Stores brai opcode + */ +__setup_exceptions: /* Find-out if u-boot is running on BIG/LITTLE endian platform * There are some steps which is necessary to keep in mind: * 1. Setup offset value to r6 @@ -76,7 +147,7 @@ _start: swi r2, r0, 0x8 /* user vector exception - imm opcode */ swi r3, r0, 0xC /* user vector exception - brai opcode */ - addik r6, r0, _exception_handler + addik r6, r5, _exception_handler sw r6, r1, r0 /* * BIG ENDIAN memory map for user exception @@ -109,7 +180,7 @@ _start: swi r2, r0, 0x10/* interrupt - imm opcode */ swi r3, r0, 0x14/* interrupt - brai opcode */ - addik r6, r0, _interrupt_handler + addik r6, r5, _interrupt_handler sw r6, r1, r0 lhu r7, r1, r10 rsubi r8, r10, 0x12 @@ -121,67 +192,18 @@ _start: swi r2, r0, 0x20/* hardware exception - imm opcode */ swi r3, r0, 0x24/* hardware exception - brai opcode */ - addik r6, r0, _hw_exception_handler + addik r6, r5, _hw_exception_handler sw r6, r1, r0 lhu r7, r1, r10 rsubi r8, r10, 0x22 sh r7, r0, r8 rsubi r8, r10, 0x26 sh r6, r0, r8 -#endif /* CONFIG_SPL_BUILD */ - - /* Flush cache before enable cache */ - addik r5, r0, 0 - addik r6, r0, XILINX_DCACHE_BYTE_SIZE - bralid r15, flush_cache - nop - - /* enable instruction and data cache */ - mfs r12, rmsr - ori r12, r12, 0x1a0 - mts
[PATCH 1/3] Small fixes to reduce size and ensure correct console output.
Signed-off-by: Mauro Condarelli --- arch/mips/dts/vocore_vocore2.dts | 2 +- include/configs/vocore2.h| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/mips/dts/vocore_vocore2.dts b/arch/mips/dts/vocore_vocore2.dts index 3502e4b8b7..9adf39652f 100644 --- a/arch/mips/dts/vocore_vocore2.dts +++ b/arch/mips/dts/vocore_vocore2.dts @@ -59,7 +59,7 @@ #address-cells = <1>; #size-cells = <1>; compatible = "jedec,spi-nor"; - spi-max-frequency = <2500>; + spi-max-frequency = <4000>; reg = <0>; }; }; diff --git a/include/configs/vocore2.h b/include/configs/vocore2.h index 40467b737c..29a57ad233 100644 --- a/include/configs/vocore2.h +++ b/include/configs/vocore2.h @@ -25,6 +25,7 @@ #define CONFIG_SPL_BSS_START_ADDR 0x8001 #define CONFIG_SPL_BSS_MAX_SIZE0x1 #define CONFIG_SPL_MAX_SIZE0x1 +#define CONFIG_SPL_PAD_TO 0 /* Dummy value */ #define CONFIG_SYS_UBOOT_BASE 0 @@ -34,6 +35,7 @@ #define CONFIG_SYS_NS16550_CLK 4000 #define CONFIG_SYS_NS16550_REG_SIZE-4 #define CONFIG_SYS_NS16550_COM30xbe00 +#define CONFIG_CONS_INDEX 3 /* RAM */ -- 2.25.1
[PATCH 3/3] Fix missing __udivdi3 in SquashFS implementation.
Signed-off-by: Mauro Condarelli
---
fs/squashfs/sqfs.c| 45 +--
fs/squashfs/sqfs_inode.c | 8 +++
include/configs/vocore2.h | 2 +-
3 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 15208b4dab..b49331ce93 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include "sqfs_decompressor.h"
#include "sqfs_filesystem.h"
@@ -82,13 +84,16 @@ static int sqfs_count_tokens(const char *filename)
*/
static int sqfs_calc_n_blks(__le64 start, __le64 end, u64 *offset)
{
- u64 start_, table_size;
+ u64 start_, table_size, blks;
table_size = le64_to_cpu(end) - le64_to_cpu(start);
- start_ = le64_to_cpu(start) / ctxt.cur_dev->blksz;
+ start_ = le64_to_cpu(start);
+ do_div(start_, ctxt.cur_dev->blksz);
*offset = le64_to_cpu(start) - (start_ * ctxt.cur_dev->blksz);
- return DIV_ROUND_UP(table_size + *offset, ctxt.cur_dev->blksz);
+ blks = table_size + *offset;
+ if (do_div(blks, ctxt.cur_dev->blksz)) blks++;
+ return blks;
}
/*
@@ -109,8 +114,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
if (inode_fragment_index >= get_unaligned_le32(>fragments))
return -EINVAL;
- start = get_unaligned_le64(>fragment_table_start) /
- ctxt.cur_dev->blksz;
+ start = get_unaligned_le64(>fragment_table_start);
+ do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->fragment_table_start,
sblk->export_table_start,
_offset);
@@ -135,7 +140,8 @@ static int sqfs_frag_lookup(u32 inode_fragment_index,
start_block = get_unaligned_le64(table + table_offset + block *
sizeof(u64));
- start = start_block / ctxt.cur_dev->blksz;
+ start = start_block;
+ do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(cpu_to_le64(start_block),
sblk->fragment_table_start, _offset);
@@ -641,8 +647,8 @@ static int sqfs_read_inode_table(unsigned char
**inode_table)
table_size = get_unaligned_le64(>directory_table_start) -
get_unaligned_le64(>inode_table_start);
- start = get_unaligned_le64(>inode_table_start) /
- ctxt.cur_dev->blksz;
+ start = get_unaligned_le64(>inode_table_start);
+ do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->inode_table_start,
sblk->directory_table_start, _offset);
@@ -725,8 +731,8 @@ static int sqfs_read_directory_table(unsigned char
**dir_table, u32 **pos_list)
/* DIRECTORY TABLE */
table_size = get_unaligned_le64(>fragment_table_start) -
get_unaligned_le64(>directory_table_start);
- start = get_unaligned_le64(>directory_table_start) /
- ctxt.cur_dev->blksz;
+ start = get_unaligned_le64(>directory_table_start);
+ do_div(start, ctxt.cur_dev->blksz);
n_blks = sqfs_calc_n_blks(sblk->directory_table_start,
sblk->fragment_table_start, _offset);
@@ -1158,6 +1164,7 @@ static int sqfs_get_regfile_info(struct
squashfs_reg_inode *reg,
fentry);
if (ret < 0)
return -EINVAL;
+
finfo->comp = true;
if (fentry->size < 1 || fentry->start == 0x7FFF)
return -EINVAL;
@@ -1328,17 +1335,19 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
data_offset = finfo.start;
datablock = malloc(get_unaligned_le32(>block_size));
if (!datablock) {
+ printf("Error: malloc(%u) failed.\n",
get_unaligned_le32(>block_size));
ret = -ENOMEM;
goto free_paths;
}
}
for (j = 0; j < datablk_count; j++) {
- start = data_offset / ctxt.cur_dev->blksz;
+ start = data_offset;
+ do_div(start, ctxt.cur_dev->blksz);
table_size = SQFS_BLOCK_SIZE(finfo.blk_sizes[j]);
table_offset = data_offset - (start * ctxt.cur_dev->blksz);
- n_blks = DIV_ROUND_UP(table_size + table_offset,
- ctxt.cur_dev->blksz);
+ n_blks = table_size + table_offset;
+ if (do_div(n_blks, ctxt.cur_dev->blksz)) n_blks++;
data_buffer = malloc_cache_aligned(n_blks *
ctxt.cur_dev->blksz);
@@ -1365,8 +1374,10 @@ int sqfs_read(const char *filename, void *buf, loff_t
offset, loff_t len,
dest_len = get_unaligned_le32(>block_size);
ret
[PATCH 0/3] Patches to allow running u-boot on vocore2 board
There are two distinct things here: - a few small fixes specific to vocore2 board. - fixes to SquashFS to allow compilation on 32-bit architectures. Mauro Condarelli (3): Small fixes to reduce size and ensure correct console output. Enlarge SPL malloc area to prevent failure in lzma decompression. Fix missing __udivdi3 in SquashFS implementation. arch/mips/dts/vocore_vocore2.dts | 2 +- configs/vocore2_defconfig| 2 +- fs/squashfs/sqfs.c | 45 fs/squashfs/sqfs_inode.c | 8 +++--- include/configs/vocore2.h| 4 ++- 5 files changed, 38 insertions(+), 23 deletions(-) -- 2.25.1
[PATCH 2/3] Enlarge SPL malloc area to prevent failure in lzma decompression.
Signed-off-by: Mauro Condarelli --- configs/vocore2_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/vocore2_defconfig b/configs/vocore2_defconfig index 99a1143e6e..5776aada15 100644 --- a/configs/vocore2_defconfig +++ b/configs/vocore2_defconfig @@ -6,7 +6,7 @@ CONFIG_ENV_SIZE=0x1000 CONFIG_ENV_OFFSET=0x04e000 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c -CONFIG_SPL_SYS_MALLOC_F_LEN=0x2 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x4 CONFIG_SPL=y CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_ARCH_MTMIPS=y -- 2.25.1
[PATCH 5/5] x86: video: Show information about each video device
At present the 'bdinfo' command shows the framebuffer address, but not the
address of the copy framebuffer, if present. Add support for this.
Signed-off-by: Simon Glass
---
cmd/bdinfo.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 9593b345a3d..2d88eb18ba7 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -8,9 +8,11 @@
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -66,6 +68,26 @@ __weak void arch_print_bdinfo(void)
{
}
+static void show_video_info(void)
+{
+ const struct udevice *dev;
+ struct uclass *uc;
+
+ uclass_id_foreach_dev(UCLASS_VIDEO, dev, uc) {
+ printf("%-12s= %s %sactive\n", "Video", dev->name,
+ device_active(dev) ? "" : "in");
+ if (device_active(dev)) {
+ struct video_priv *upriv = dev_get_uclass_priv(dev);
+
+ print_phys_addr("FB base", (ulong)upriv->fb);
+ if (upriv->copy_fb)
+ print_phys_addr("FB copy",
(ulong)upriv->copy_fb);
+ printf("%-12s= %dx%dx%d\n", "FB size", upriv->xsize,
+ upriv->ysize, 1 << upriv->bpix);
+ }
+ }
+}
+
int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct bd_info *bd = gd->bd;
@@ -96,7 +118,9 @@ int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
bdinfo_print_num("fdt_blob", (ulong)gd->fdt_blob);
bdinfo_print_num("new_fdt", (ulong)gd->new_fdt);
bdinfo_print_num("fdt_size", (ulong)gd->fdt_size);
-#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO) || defined(CONFIG_DM_VIDEO)
+ if (IS_ENABLED(CONFIG_DM_VIDEO))
+ show_video_info();
+#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
bdinfo_print_num("FB base ", gd->fb_base);
#endif
#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 3/5] x86: Allow showing details about a HOB entry
Some HOBs include information that can be decoded. Add a -v option to the
hob command, to allow this to be displayed. Add the ability to decode a
resource descriptor.
Signed-off-by: Simon Glass
---
cmd/x86/hob.c | 49 +
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/cmd/x86/hob.c b/cmd/x86/hob.c
index bbe38bbf20e..2933bc08c76 100644
--- a/cmd/x86/hob.c
+++ b/cmd/x86/hob.c
@@ -27,6 +27,16 @@ static char *hob_type[] = {
"Capsule",
};
+static char *res_type[] = {
+ "system",
+ "Memory-mapped I/O",
+ "I/O",
+ "Firmware device",
+ "Memory-mapped I/O port",
+ "Reserved",
+ "I/O reserved",
+};
+
static struct guid_name {
efi_guid_t guid;
const char *name;
@@ -58,6 +68,26 @@ static const char *guid_to_name(const efi_guid_t *guid)
return NULL;
}
+static void show_hob_details(const struct hob_header *hdr)
+{
+ const void *ptr = hdr;
+
+ switch (hdr->type) {
+ case HOB_TYPE_RES_DESC: {
+ const struct hob_res_desc *res = ptr;
+ const char *typename;
+
+ typename = res->type > 0 && res->type <= RES_MAX_MEM_TYPE ?
+ res_type[res->type] : "unknown";
+
+ printf(" base = %08llx, len = %08llx, end = %08llx, type =
%d (%s)\n\n",
+ res->phys_start, res->len, res->phys_start + res->len,
+ res->type, typename);
+ break;
+ }
+ }
+}
+
static int do_hob(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
const struct hob_header *hdr;
@@ -66,12 +96,20 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
int i = 0;
efi_guid_t *guid;
char uuid[UUID_STR_LEN + 1];
+ bool verbose = false;
int seq = -1; /* Show all by default */
argc--;
argv++;
- if (argc)
- seq = simple_strtol(*argv, NULL, 16);
+ if (argc) {
+ if (!strcmp("-v", *argv)) {
+ verbose = true;
+ argc--;
+ argv++;
+ }
+ if (argc)
+ seq = simple_strtol(*argv, NULL, 16);
+ }
hdr = gd->arch.hob_list;
printf("HOB list address: 0x%08x\n\n", (unsigned int)hdr);
@@ -111,13 +149,16 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
printf("%36s", "Not Available");
}
printf("\n");
+ if (verbose)
+ show_hob_details(hdr);
}
return 0;
}
-U_BOOT_CMD(hob, 2, 1, do_hob,
- "[seq] Print Hand-Off Block (HOB) information"
+U_BOOT_CMD(hob, 3, 1, do_hob,
+ "[-v] [seq] Print Hand-Off Block (HOB) information"
+ " -v - Show detailed HOB information where available"
" seq - Record # to show (all by default)",
""
);
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 4/5] x86: Add support for more than 8 MTRRs
At present the mtrr command only support 8 MTRRs. Some SoCs have more than
that. Update the implementation to support up to 10. Read the number of
MTRRs dynamically instead.
Signed-off-by: Simon Glass
---
arch/x86/cpu/mtrr.c | 12 +++-
arch/x86/include/asm/mtrr.h | 15 ---
cmd/x86/mtrr.c | 9 +
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/x86/cpu/mtrr.c b/arch/x86/cpu/mtrr.c
index 2468d88a80a..aed4c411367 100644
--- a/arch/x86/cpu/mtrr.c
+++ b/arch/x86/cpu/mtrr.c
@@ -66,9 +66,10 @@ static void set_var_mtrr(uint reg, uint type, uint64_t
start, uint64_t size)
void mtrr_read_all(struct mtrr_info *info)
{
+ int reg_count = mtrr_get_var_count();
int i;
- for (i = 0; i < MTRR_COUNT; i++) {
+ for (i = 0; i < reg_count; i++) {
info->mtrr[i].base = native_read_msr(MTRR_PHYS_BASE_MSR(i));
info->mtrr[i].mask = native_read_msr(MTRR_PHYS_MASK_MSR(i));
}
@@ -76,10 +77,11 @@ void mtrr_read_all(struct mtrr_info *info)
void mtrr_write_all(struct mtrr_info *info)
{
+ int reg_count = mtrr_get_var_count();
struct mtrr_state state;
int i;
- for (i = 0; i < MTRR_COUNT; i++) {
+ for (i = 0; i < reg_count; i++) {
mtrr_open(, true);
wrmsrl(MTRR_PHYS_BASE_MSR(i), info->mtrr[i].base);
wrmsrl(MTRR_PHYS_MASK_MSR(i), info->mtrr[i].mask);
@@ -144,7 +146,7 @@ int mtrr_commit(bool do_caches)
/* Clear the ones that are unused */
debug("clear\n");
- for (; i < MTRR_COUNT; i++)
+ for (; i < MTRR_MAX_COUNT; i++)
wrmsrl(MTRR_PHYS_MASK_MSR(i), 0);
debug("close\n");
mtrr_close(, do_caches);
@@ -184,7 +186,7 @@ int mtrr_add_request(int type, uint64_t start, uint64_t
size)
return 0;
}
-static int get_var_mtrr_count(void)
+int mtrr_get_var_count(void)
{
return msr_read(MSR_MTRR_CAP_MSR).lo & MSR_MTRR_CAP_VCNT;
}
@@ -195,7 +197,7 @@ static int get_free_var_mtrr(void)
int vcnt;
int i;
- vcnt = get_var_mtrr_count();
+ vcnt = mtrr_get_var_count();
/* Identify the first var mtrr which is not valid */
for (i = 0; i < vcnt; i++) {
diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 48db1dd82f7..3a98aacdef5 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -36,8 +36,8 @@
#define MTRR_BASE_TYPE_MASK0x7
-/* Number of MTRRs supported */
-#define MTRR_COUNT 8
+/* Maximum number of MTRRs supported - see also mtrr_get_var_count() */
+#define MTRR_MAX_COUNT 10
#define NUM_FIXED_MTRRS11
#define RANGES_PER_FIXED_MTRR 8
@@ -87,7 +87,7 @@ struct mtrr {
* @mtrr: Information about each mtrr
*/
struct mtrr_info {
- struct mtrr mtrr[MTRR_COUNT];
+ struct mtrr mtrr[MTRR_MAX_COUNT];
};
/**
@@ -180,6 +180,15 @@ int mtrr_set_valid(int cpu_select, int reg, bool valid);
*/
int mtrr_set(int cpu_select, int reg, u64 base, u64 mask);
+/**
+ * mtrr_get_var_count() - Get the number of variable MTRRs
+ *
+ * Some CPUs have more than 8 MTRRs. This function returns the actual number
+ *
+ * @return number of variable MTRRs
+ */
+int mtrr_get_var_count(void);
+
#endif
#if ((CONFIG_XIP_ROM_SIZE & (CONFIG_XIP_ROM_SIZE - 1)) != 0)
diff --git a/cmd/x86/mtrr.c b/cmd/x86/mtrr.c
index 99efecb9d8e..fc61a549b02 100644
--- a/cmd/x86/mtrr.c
+++ b/cmd/x86/mtrr.c
@@ -27,7 +27,7 @@ static void read_mtrrs(void *arg)
mtrr_read_all(info);
}
-static int do_mtrr_list(int cpu_select)
+static int do_mtrr_list(int reg_count, int cpu_select)
{
struct mtrr_info info;
int ret;
@@ -39,7 +39,7 @@ static int do_mtrr_list(int cpu_select)
ret = mp_run_on_cpus(cpu_select, read_mtrrs, );
if (ret)
return log_msg_ret("run", ret);
- for (i = 0; i < MTRR_COUNT; i++) {
+ for (i = 0; i < reg_count; i++) {
const char *type = "Invalid";
uint64_t base, mask, size;
bool valid;
@@ -98,6 +98,7 @@ static int do_mtrr_set(int cpu_select, uint reg, int argc,
char *const argv[])
static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ int reg_count = mtrr_get_var_count();
int cmd;
int cpu_select;
uint reg;
@@ -126,7 +127,7 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int
argc,
if (argc < 2)
return CMD_RET_USAGE;
reg = simple_strtoul(argv[1], NULL, 16);
- if (reg >= MTRR_COUNT) {
+ if (reg >= reg_count) {
printf("Invalid register number\n");
return CMD_RET_USAGE;
}
@@ -145,7 +146,7 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int
argc,
if (!first)
[PATCH 0/5] x86: Updates to some commands
This series adds a few more features to some x86-specific commands. Simon Glass (5): x86: hob: Add way to show a single hob entry x86: hob: Try to show a name instead of a GUID x86: Allow showing details about a HOB entry x86: Add support for more than 8 MTRRs x86: video: Show information about each video device arch/x86/cpu/mtrr.c| 12 ++-- arch/x86/include/asm/fsp/fsp_hob.h | 25 arch/x86/include/asm/mtrr.h| 15 - cmd/bdinfo.c | 26 +++- cmd/x86/hob.c | 100 +++-- cmd/x86/mtrr.c | 9 +-- 6 files changed, 167 insertions(+), 20 deletions(-) -- 2.28.0.681.g6f77f65b4e-goog
[PATCH 2/5] x86: hob: Try to show a name instead of a GUID
GUIDs are one of the seven evils of the computer world. They obfuscate the
meaning and require people to look up long hex strings to decode it.
Luckily only a miniscule fraction of the 10^38 possible GUIDs are in use.
Add a way to decode the GUIDs known to U-Boot. Add a few more to the list
for good measure.
Signed-off-by: Simon Glass
---
arch/x86/include/asm/fsp/fsp_hob.h | 25 +
cmd/x86/hob.c | 43 --
2 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/fsp/fsp_hob.h
b/arch/x86/include/asm/fsp/fsp_hob.h
index d248520e972..ea3983e04ff 100644
--- a/arch/x86/include/asm/fsp/fsp_hob.h
+++ b/arch/x86/include/asm/fsp/fsp_hob.h
@@ -99,4 +99,29 @@ struct __packed hob_graphics_info {
EFI_GUID(0x39f62cce, 0x6825, 0x4669, \
0xbb, 0x56, 0x54, 0x1a, 0xba, 0x75, 0x3a, 0x07)
+/* The following GUIDs are observed with FSP 2.1 / Apollo Lake */
+#define FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID \
+ EFI_GUID(0x6dadf1d1, 0xd4cc, 0x4910, \
+ 0xbb, 0x6e, 0x82, 0xb1, 0xfd, 0x80, 0xff, 0x3d)
+
+#define FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1 \
+ EFI_GUID(0xea296d92, 0x0b69, 0x423c, \
+ 0x8c, 0x28, 0x33, 0xb4, 0xe0, 0xa9, 0x12, 0x68)
+
+#define FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2 \
+ EFI_GUID(0x9b3ada4f, 0xae56, 0x4c24, \
+ 0x8d, 0xea, 0xf0, 0x3b, 0x75, 0x58, 0xae, 0x50)
+
+#define FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID \
+ EFI_GUID(0x86d70125, 0xbaa3, 0x4296, \
+ 0xa6, 0x2f, 0x60, 0x2b, 0xeb, 0xbb, 0x90, 0x81)
+
+#define FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID \
+ EFI_GUID(0x4ed4bf27, 0x4092, 0x42e9, \
+ 0x80, 0x7d, 0x52, 0x7b, 0x1d, 0x00, 0xc9, 0xbd)
+
+#define FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID \
+ EFI_GUID(0x01a1108c, 0x9dee, 0x4984, \
+ 0x88, 0xc3, 0xee, 0xe8, 0xc4, 0x9e, 0xfb, 0x89)
+
#endif
diff --git a/cmd/x86/hob.c b/cmd/x86/hob.c
index e3f512beee8..bbe38bbf20e 100644
--- a/cmd/x86/hob.c
+++ b/cmd/x86/hob.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -26,6 +27,37 @@ static char *hob_type[] = {
"Capsule",
};
+static struct guid_name {
+ efi_guid_t guid;
+ const char *name;
+} guid_name[] = {
+ { FSP_HOB_RESOURCE_OWNER_TSEG_GUID, "TSEG" },
+ { FSP_HOB_RESOURCE_OWNER_FSP_GUID, "FSP" },
+ { FSP_HOB_RESOURCE_OWNER_SMM_PEI_SMRAM_GUID, "SMM PEI SMRAM" },
+ { FSP_NON_VOLATILE_STORAGE_HOB_GUID, "NVS" },
+ { FSP_VARIABLE_NV_DATA_HOB_GUID, "Variable NVS" },
+ { FSP_GRAPHICS_INFO_HOB_GUID, "Graphics info" },
+ { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID1, "PCD database ea" },
+ { FSP_HOB_RESOURCE_OWNER_PCD_DATABASE_GUID2, "PCD database 93" },
+ { FSP_HOB_RESOURCE_OWNER_PEIM_DXE_GUID, "PEIM Init DXE" },
+ { FSP_HOB_RESOURCE_OWNER_ALLOC_STACK_GUID, "Alloc stack" },
+ { FSP_HOB_RESOURCE_OWNER_SMBIOS_MEMORY_GUID, "SMBIOS memory" },
+ { {}, "zero-guid" },
+ {}
+};
+
+static const char *guid_to_name(const efi_guid_t *guid)
+{
+ struct guid_name *entry;
+
+ for (entry = guid_name; entry->name; entry++) {
+ if (!guidcmp(guid, >guid))
+ return entry->name;
+ }
+
+ return NULL;
+}
+
static int do_hob(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
const struct hob_header *hdr;
@@ -65,9 +97,16 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
if (type == HOB_TYPE_MEM_ALLOC || type == HOB_TYPE_RES_DESC ||
type == HOB_TYPE_GUID_EXT) {
+ const char *name;
+
guid = (efi_guid_t *)(hdr + 1);
- uuid_bin_to_str(guid->b, uuid, UUID_STR_FORMAT_GUID);
- printf("%s", uuid);
+ name = guid_to_name(guid);
+ if (!name) {
+ uuid_bin_to_str(guid->b, uuid,
+ UUID_STR_FORMAT_GUID);
+ name = uuid;
+ }
+ printf("%36s", name);
} else {
printf("%36s", "Not Available");
}
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 1/5] x86: hob: Add way to show a single hob entry
The 'hob' command currently lists all HOB entries. Add way to list a
single entry, by index.
Signed-off-by: Simon Glass
---
cmd/x86/hob.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/cmd/x86/hob.c b/cmd/x86/hob.c
index 6b1f7bda5b8..e3f512beee8 100644
--- a/cmd/x86/hob.c
+++ b/cmd/x86/hob.c
@@ -34,7 +34,12 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
int i = 0;
efi_guid_t *guid;
char uuid[UUID_STR_LEN + 1];
+ int seq = -1; /* Show all by default */
+ argc--;
+ argv++;
+ if (argc)
+ seq = simple_strtol(*argv, NULL, 16);
hdr = gd->arch.hob_list;
printf("HOB list address: 0x%08x\n\n", (unsigned int)hdr);
@@ -43,7 +48,9 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
printf("%36s\n", "GUID");
printf("---|--|---|--|-");
printf("\n");
- while (!end_of_hob(hdr)) {
+ for (i = 0; !end_of_hob(hdr); i++, hdr = get_next_hob(hdr)) {
+ if (seq != -1 && seq != i)
+ continue;
printf("%02x | %08x | ", i, (unsigned int)hdr);
type = hdr->type;
if (type == HOB_TYPE_UNUSED)
@@ -65,14 +72,13 @@ static int do_hob(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
printf("%36s", "Not Available");
}
printf("\n");
- hdr = get_next_hob(hdr);
- i++;
}
return 0;
}
-U_BOOT_CMD(hob, 1, 1, do_hob,
- "Print Hand-Off Block (HOB) information",
+U_BOOT_CMD(hob, 2, 1, do_hob,
+ "[seq] Print Hand-Off Block (HOB) information"
+ " seq - Record # to show (all by default)",
""
);
--
2.28.0.681.g6f77f65b4e-goog
[PATCH 0/5] x86: Updates to some commands
This series adds a few more features to some x86-specific commands. Simon Glass (5): x86: hob: Add way to show a single hob entry x86: hob: Try to show a name instead of a GUID x86: Allow showing details about a HOB entry x86: Add support for more than 8 MTRRs x86: video: Show information about each video device arch/x86/cpu/mtrr.c| 12 ++-- arch/x86/include/asm/fsp/fsp_hob.h | 25 arch/x86/include/asm/mtrr.h| 15 - cmd/bdinfo.c | 26 +++- cmd/x86/hob.c | 100 +++-- cmd/x86/mtrr.c | 9 +-- 6 files changed, 167 insertions(+), 20 deletions(-) -- 2.28.0.681.g6f77f65b4e-goog
Re: Pull request for UEFI sub-system for efi-2020-10-rc5 (2)
On Sat, Sep 19, 2020 at 07:24:22AM +0200, Heinrich Schuchardt wrote: > Hello Tom, > > The following changes since commit 9de3126e80cdac7ee15b6671065a952184533dda: > > Merge branch '2020-09-16-assorted-fixes' (2020-09-17 09:53:57 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-10-rc5-2 > > for you to fetch changes up to 8f0ac536d4937d07a95fcc56756c14ef7a94e397: > > efi: change 'env -e -i' usage syntax (2020-09-18 22:23:58 +0200) > > Gitlab CI and Travis CI showed no problems: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/4709 > https://travis-ci.org/github/xypron2/u-boot/builds/728440733 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 1/1] doc/build/gcc.rst: add missing apt-get *install*
The install command is missing for an apt-get command. Signed-off-by: Heinrich Schuchardt --- doc/build/gcc.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index fcb0b1ffb3..1ceba0b699 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -17,7 +17,7 @@ You could install GCC and the GCC cross compiler for the ARMv8 architecture with .. code-block:: bash -sudo apt-get gcc gcc-aarch64-linux-gnu +sudo apt-get install gcc gcc-aarch64-linux-gnu Depending on the build targets further packages maybe needed -- 2.28.0
[RFC 1/1] doc/build/gcc.rst: required packages for Suse
Describe the packages required to build U-Boot on Suse. Signed-off-by: Heinrich Schuchardt --- Hello Matthias, I would like to add a sub-chapter to our documentation describing what is needed to build U-Boot on Suse. Cf. https://u-boot.readthedocs.io/en/latest/build/gcc.html Unfortunately I could not find all the packages that need to be installed in the Suse Tumbleweed Docker image. For 'make qemu_arm64_defconfig && make' I get an error aarch64-suse-linux-ld.bfd: cannot find -lgcc For 'make tests' a lot more seems to be missing. Do you have a list of required packages? Best regards Heinrich --- doc/build/gcc.rst | 20 1 file changed, 20 insertions(+) diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst index fcb0b1ffb3..6250dc1880 100644 --- a/doc/build/gcc.rst +++ b/doc/build/gcc.rst @@ -29,6 +29,26 @@ Depending on the build targets further packages maybe needed lzma-alone openssl python3 python3-coverage python3-pyelftools \ python3-pytest python3-sphinxcontrib.apidoc python3-sphinx-rtd-theme swig +Suse based +~~ + +On Suse based systems the cross compiler packages are named +cross--gcc. + +You could install GCC and the GCC 10 cross compiler for the ARMv8 architecture +with + +.. code-block:: bash + +sudo zypper install gcc cross-aarch64-gcc10 + +Depending on the build targets further packages maybe needed. + +.. code-block:: bash + +zypper install bc bison flex gcc libopenssl-devel libSDL2-devel make \ + ncurses-devel python3-devel python3-pytest swig + Prerequisites - -- 2.28.0
Re: RPi4 U-Boot freeze
On 2020-09-19 23:20, Sean Anderson wrote:
> On 9/19/20 7:55 AM, Stefan Agner wrote:
>> On 2020-09-14 10:15, Matthias Brugger wrote:
>>> On 10/09/2020 23:12, Stefan Agner wrote:
On 2020-09-07 16:36, Peter Robinson wrote:
>> Any thoughts on this issue?
>
> Any reason why you're using 2020.01 and not at least 2020.07, or at
> least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has
> changed quite a bit since then I suspect.
>
Hi Peter,
It's a stable release and we support a couple of devices with the same
U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
We are on 2020.07 on development branch, and it does work fine there. So
I thought it can't be that hard, just bisect and backport whatever fixes
it... Unfortunately, it seems that there is no particular commit which
fixes it (the bisect ended up in a random unrelated commit, and it seems
that the issue appears/disappears depending on alignment/size...).
I also did applied pretty much every RPi4 related commit made after
2020.01 up until master back to 2020.01, no success either.
>>>
>>> Which version of the Raspberry Pi firmware did you use?
>>> Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
>>>
>>
>> Ok, I am now able to reproduce the issue on master as well as 2020.07
>> with standard rpi_4_32b_defconfig, but I still need to have parts of a
>> change which seems to trigger the issue in. From what I can tell, the
>> change *really* should not lead to a freeze. The change is just
>> accessing global variables from the data section... (see below).
>>
>> To me it still seems as if relocation somehow did not work correctly in
>> one way or another.
>>
>> Are there maybe restrictions in U-Boot when the data section can be
>> accessed? E.g. is it not legal to access the data section from the
>> serial driver?
>
> One thing bit me recently, and might be relevant here. Because
> putc_retry is initialized to zero, it is located in bss and not data.
> In U-Boot, bss is not accessable before relocation. The serial driver is
> one of the devices which U-Boot needs before relocating, so setting
> putc_retry may overwrite data in the device tree. To get around this,
> you could try adding __attribute__((section(".data"))) to that variable.
Thanks a lot for that hint, I did not know that bss is not accessible
before relocation.
That indeed seems to be the problem! Actually just removing the
initialization is fine here, as global variables are initialized to zero
anyways (from what it seems also in U-Boot's implementation).
I wonder if some compile time warning/check could be introduced, but I
guess there is not really a way to know what code is used before
relocation.
Anyways, thanks a lot, sorry for the noise. We can consider this solved.
--
Stefan
>
> --Sean
>
>>
>>
>> diff --git a/drivers/serial/serial_bcm283x_mu.c
>> b/drivers/serial/serial_bcm283x_mu.c
>> index 8a4af87eb6..74de6801ab 100644
>> --- a/drivers/serial/serial_bcm283x_mu.c
>> +++ b/drivers/serial/serial_bcm283x_mu.c
>> @@ -50,7 +50,8 @@ struct bcm283x_mu_regs {
>> struct bcm283x_mu_priv {
>> struct bcm283x_mu_regs *regs;
>> };
>> -
>> +static char *fs_argv[15];
>> +static uint32_t putc_retry = 0;
>> static int bcm283x_mu_serial_getc(struct udevice *dev);
>>
>> static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate)
>> @@ -95,6 +96,8 @@ static int bcm283x_mu_serial_putc(struct udevice *dev,
>> const char data)
>> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>> struct bcm283x_mu_regs *regs = priv->regs;
>>
>> + putc_retry++;
>> +
>> /* Wait until there is space in the FIFO */
>> if (!(readl(>lsr) & BCM283X_MU_LSR_TX_EMPTY))
>> return -EAGAIN;
>> @@ -162,6 +165,10 @@ static int bcm283x_mu_serial_probe(struct udevice
>> *dev)
>> struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>> fdt_addr_t addr;
>>
>> + /* Make sure compiler does not optimize out this fs_argv
>> instance */
>> + if (fs_argv[0])
>> + fs_argv[0] = "test";
>> +
>> /* Don't spawn the device if it's not muxed */
>> if (!bcm283x_is_serial_muxed())
>> return -ENODEV;
>>
>> Most curious of all, it seems that the name (!!!) of the variable
>> fs_argv matters! I am not sure if that changes order of variables in
>> data section or something. I can also reproduce the issue with two
>> compilers (GCC 8.3 and GCC 9.2), so a compiler error seems somewhat
>> unlikely...
>>
>> Any ideas? I am a bit out of idea how to debug this (I guess JTAG/gdb
>> might help, but I don't have such a setup).
>>
>> FWIW, I plan to just drop the change which seems to at least partially
>> cause the isssue
>>
[PATCH v2 2/3] global_data.h: add Sphinx documentation
Add the missing Sphinx documentation for struct global_data and
gd_board_type().
Signed-off-by: Heinrich Schuchardt
---
v2:
no change
---
include/asm-generic/global_data.h | 354 ++
1 file changed, 308 insertions(+), 46 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index e4a68e0d91..7222fa1241 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -24,121 +24,383 @@
#include
#include
-typedef struct global_data {
+typedef struct global_data gd_t;
+
+/**
+ * struct global_data - global data structure
+ */
+struct global_data {
+ /**
+* @bd: board information
+*/
struct bd_info *bd;
+ /**
+* @flags: global data flags
+*
+* See gd_flags
+*/
unsigned long flags;
+ /**
+* @baudrate: baud rate of the serial interface
+*/
unsigned int baudrate;
- unsigned long cpu_clk; /* CPU clock in Hz! */
+ /**
+* @cpu_clk: CPU clock rate in Hz
+*/
+ unsigned long cpu_clk;
+ /**
+* @bus_clk: platform clock rate in Hz
+*/
unsigned long bus_clk;
+ /**
+* @pci_clk: PCI clock rate in Hz
+*/
/* We cannot bracket this with CONFIG_PCI due to mpc5xxx */
unsigned long pci_clk;
+ /**
+* @mem_clk: memory clock rate in Hz
+*/
unsigned long mem_clk;
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO) || defined(CONFIG_DM_VIDEO)
- unsigned long fb_base; /* Base address of framebuffer mem */
+ /**
+* @fb_base: base address of frame buffer memory
+*/
+ unsigned long fb_base;
#endif
#if defined(CONFIG_POST)
+ /**
+* @post_log_word: active POST tests
+*
+* @post_log_word is a bit mask defining which POST tests are recorded
+* (see constants POST_*).
+*/
unsigned long post_log_word;/* Record POST activities */
- unsigned long post_log_res; /* success of POST test */
- unsigned long post_init_f_time; /* When post_init_f started */
+ /**
+* @post_log_res: POST results
+*
+* @post_log_res is a bit mask with the POST results. A bit with value 1
+* indicates successful execution.
+*/
+ unsigned long post_log_res;
+ /**
+* @post_init_f_time: time in ms when post_init_f() started
+*/
+ unsigned long post_init_f_time;
#endif
#ifdef CONFIG_BOARD_TYPES
+ /**
+* @board_type: board type
+*
+* If a U-Boot configuration supports multiple board types, the actual
+* board type may be stored in this field.
+*/
unsigned long board_type;
#endif
+ /**
+* @have_console: console is available
+*
+* A value of 1 indicates that serial_init() was called and a console
+* is available.
+* A value of 0 indicates that console input and output drivers shall
+* not be called.
+*/
unsigned long have_console; /* serial_init() was called */
#if CONFIG_IS_ENABLED(PRE_CONSOLE_BUFFER)
+ /**
+* @precon_buf_idx: pre-console buffer index
+*
+* @precon_buf_idx indicates the current position of the buffer used to
+* collect output before the console becomes available
+*/
unsigned long precon_buf_idx; /* Pre-Console buffer index */
#endif
- unsigned long env_addr; /* Address of Environment struct */
- unsigned long env_valid;/* Environment valid? enum env_valid */
- unsigned long env_has_init; /* Bitmask of boolean of struct
env_location offsets */
- int env_load_prio; /* Priority of the loaded environment */
-
- unsigned long ram_base; /* Base address of RAM used by U-Boot */
+ /**
+* @env_addr: address of environment structure
+*
+* @env_addr contains the address of the structure holding the
+* environment variables.
+*/
+ unsigned long env_addr;
+ /**
+* @env_valid: environment is valid
+*
+* See env_valid
+*/
+ unsigned long env_valid;
+ /**
+* @env_has_init: bit mask indicating environment locations
+*
+* env_location defines which bit relates to which location
+*/
+ unsigned long env_has_init;
+ /**
+* @env_load_prio: priority of the loaded environment
+*/
+ int env_load_prio;
+ /**
+* @ram_base: base address of RAM used by U-Boot
+*/
+ unsigned long ram_base;
+ /**
+* @ram_top: top address of RAM used by U-Boot
+*/
unsigned long ram_top; /* Top address of RAM used by U-Boot */
+ /**
+* @relocaddr:
[PATCH v2 3/3] doc: global data pointer
Add the description of the global data pointer to the generated HTML documentation. Signed-off-by: Heinrich Schuchardt --- v2: no change --- doc/develop/global_data.rst | 53 + doc/develop/index.rst | 1 + 2 files changed, 54 insertions(+) create mode 100644 doc/develop/global_data.rst diff --git a/doc/develop/global_data.rst b/doc/develop/global_data.rst new file mode 100644 index 00..9e7c8a24da --- /dev/null +++ b/doc/develop/global_data.rst @@ -0,0 +1,53 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Global data +=== + +Globally required fields are held in the global data structure. A pointer to the +structure is available as symbol gd. The symbol is made available by the macro +%DECLARE_GLOBAL_DATA_PTR. + +Register pointing to global data + + +On most architectures the global data pointer is stored in a register. + +++--+ +| ARC| r25 | +++--+ +| ARM 32bit | r9 | +++--+ +| ARM 64bit | x18 | +++--+ +| M68000 | d7 | +++--+ +| MicroBlaze | r31 | +++--+ +| NDS32 | r10 | +++--+ +| Nios II| gp | +++--+ +| PowerPC| r2 | +++--+ +| RISC-V | gp (x3) | +++--+ +| SuperH | r13 | +++--+ + +The sandbox, x86, and Xtensa are notable exceptions. + +Clang for ARM does not support assigning a global register. When using Clang +gd is defined as an inline function using assembly code. This adds a few bytes +to the code size. + +Binaries called by U-Boot are not aware of the register usage and will not +conserve gd. UEFI binaries call the API provided by U-Boot and may return to +U-Boot. The value of gd has to be saved every time U-Boot is left and restored +whenever U-Boot is reentered. This is also relevant for the implementation of +function tracing. For setting the value of gd function set_gd() can be used. + +Global data structure +- + +.. kernel-doc:: include/asm-generic/global_data.h + :internal: diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 98a95ad434..89e80eab94 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -9,4 +9,5 @@ Develop U-Boot coccinelle crash_dumps + global_data logging -- 2.28.0
[PATCH v2 1/3] global_data.h: convert GD_FLG_* to enum
Sphinx documentation is only available for enums not for #defines.
Anyway it is better to keep related definitions in an enum.
Signed-off-by: Heinrich Schuchardt
---
v2:
enum gd_flags must not be exposed to assembler code
---
include/asm-generic/global_data.h | 106 +++---
1 file changed, 84 insertions(+), 22 deletions(-)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index d4a4e2215d..e4a68e0d91 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -138,7 +138,6 @@ typedef struct global_data {
struct udevice *watchdog_dev;
#endif
} gd_t;
-#endif
#ifdef CONFIG_BOARD_TYPES
#define gd_board_type()gd->board_type
@@ -146,27 +145,90 @@ typedef struct global_data {
#define gd_board_type()0
#endif
-/*
- * Global Data Flags
+/**
+ * enum gd_flags - global data flags
+ *
+ * See field flags of global_data.
*/
-#define GD_FLG_RELOC 0x1 /* Code was relocated to RAM */
-#define GD_FLG_DEVINIT 0x2 /* Devices have been initialized */
-#define GD_FLG_SILENT 0x4 /* Silent mode */
-#define GD_FLG_POSTFAIL0x8 /* Critical POST test failed
*/
-#define GD_FLG_POSTSTOP0x00010 /* POST seqeunce aborted
*/
-#define GD_FLG_LOGINIT 0x00020 /* Log Buffer has been initialized */
-#define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in & out) */
-#define GD_FLG_ENV_READY 0x00080 /* Env. imported into hash table */
-#define GD_FLG_SERIAL_READY0x00100 /* Pre-reloc serial console ready */
-#define GD_FLG_FULL_MALLOC_INIT0x00200 /* Full malloc() is ready
*/
-#define GD_FLG_SPL_INIT0x00400 /* spl_init() has been called
*/
-#define GD_FLG_SKIP_RELOC 0x00800 /* Don't relocate */
-#define GD_FLG_RECORD 0x01000 /* Record console */
-#define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */
-#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done */
-#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
-#define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
-#define GD_FLG_SKIP_LL_INIT0x2 /* Don't perform low-level init*/
-#define GD_FLG_SMP_READY 0x4 /* SMP init is complete*/
+enum gd_flags {
+ /**
+* @GD_FLG_RELOC: code was relocated to RAM
+*/
+ GD_FLG_RELOC = 0x1,
+ /**
+* @GD_FLG_DEVINIT: devices have been initialized
+*/
+ GD_FLG_DEVINIT = 0x2,
+ /**
+* @GD_FLG_SILENT: silent mode
+*/
+ GD_FLG_SILENT = 0x4,
+ /**
+* @GD_FLG_POSTFAIL: critical POST test failed
+*/
+ GD_FLG_POSTFAIL = 0x8,
+ /**
+* @GD_FLG_POSTSTOP: POST sequence aborted
+*/
+ GD_FLG_POSTSTOP = 0x00010,
+ /**
+* @GD_FLG_LOGINIT: log Buffer has been initialized
+*/
+ GD_FLG_LOGINIT = 0x00020,
+ /**
+* @GD_FLG_DISABLE_CONSOLE: disable console (in & out)
+*/
+ GD_FLG_DISABLE_CONSOLE = 0x00040,
+ /**
+* @GD_FLG_ENV_READY: environment imported into hash table
+*/
+ GD_FLG_ENV_READY = 0x00080,
+ /**
+* @GD_FLG_SERIAL_READY: pre-relocation serial console ready
+*/
+ GD_FLG_SERIAL_READY = 0x00100,
+ /**
+* @GD_FLG_FULL_MALLOC_INIT: full malloc() is ready
+*/
+ GD_FLG_FULL_MALLOC_INIT = 0x00200,
+ /**
+* @GD_FLG_SPL_INIT: spl_init() has been called
+*/
+ GD_FLG_SPL_INIT = 0x00400,
+ /**
+* @GD_FLG_SKIP_RELOC: don't relocate
+*/
+ GD_FLG_SKIP_RELOC = 0x00800,
+ /**
+* @GD_FLG_RECORD: record console
+*/
+ GD_FLG_RECORD = 0x01000,
+ /**
+* @GD_FLG_ENV_DEFAULT: default variable flag
+*/
+ GD_FLG_ENV_DEFAULT = 0x02000,
+ /**
+* @GD_FLG_SPL_EARLY_INIT: early SPL initialization is done
+*/
+ GD_FLG_SPL_EARLY_INIT = 0x04000,
+ /**
+* @GD_FLG_LOG_READY: log system is ready for use
+*/
+ GD_FLG_LOG_READY = 0x08000,
+ /**
+* @GD_FLG_WDT_READY: watchdog is ready for use
+*/
+ GD_FLG_WDT_READY = 0x1,
+ /**
+* @GD_FLG_SKIP_LL_INIT: don't perform low-level initialization
+*/
+ GD_FLG_SKIP_LL_INIT = 0x2,
+ /**
+* @GD_FLG_SMP_READY: SMP initialization is complete
+*/
+ GD_FLG_SMP_READY = 0x4,
+};
+
+#endif /* __ASSEMBLY__ */
#endif /* __ASM_GENERIC_GBL_DATA_H */
--
2.28.0
[PATCH v2 0/3] doc: global data pointer
Add the description of the global data pointer to the generated HTML documentation. The first patch converts the GD_FLG_* constants to an enum. The second adds move Sphinx comments. The third finally provides the HTML documentation. v2: enum gd_flags must not be exposed to assembler code. This avoids a build failure on x86. Heinrich Schuchardt (3): global_data.h: convert GD_FLG_* to enum global_data.h: add Sphinx documentation doc: global data pointer doc/develop/global_data.rst | 53 doc/develop/index.rst | 1 + include/asm-generic/global_data.h | 460 +- 3 files changed, 446 insertions(+), 68 deletions(-) create mode 100644 doc/develop/global_data.rst -- 2.28.0
RE: [PATCH] net: ravb: Fix NULL pointer access
Hi Marek, Thanks for the feedback. > Subject: Re: [PATCH] net: ravb: Fix NULL pointer access > > On 9/19/20 8:14 PM, Biju Das wrote: > > Hi, > > [...] > > > By looking at [1], only this driver is using writeext. > > [1]https://elixir.bootlin.com/u-boot/v2020.10-rc4/A/ident/writeext > > git grep indicates a couple more sites where the writeext is called. > But look into the KSZ9031 datasheet, that particular writeext call > seems to be setting up RGMII Clock Pad Skew (MMD Address 2, > Register 8), and I think there is a matching DT binding to set > those up too, rxc-skew-ps and txc- skew-ps I think. > >>> > >>> Thanks for the pointers. I checked the configs[2] which uses > >>> renesas ravb driver and found that we are defining only rxc-skew-ps in > all dts. > >>> > >>> since CONFIG DM_ETH is defined it is already picking the value > >> corresponding to "rxc-skew-ps". > >>> > >>> For txc-skew-ps anyway the value is default one. So we don't care. > >> > >> Are you sure (0xf << 5) | 0x19 is the same as the default value of > >> the clock pad skew register ? > > > > No. > > As per [1] & [2], the default values for this registers are 0xf > > So the combined value of the MMD 2-8 register is (0xf << 5) | (0xf << 0) , > right. > > > [1] > > https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/ > > micrel_ksz90x1.c#L105 [2] > > http://ww1.microchip.com/downloads/en/devicedoc/2117f.pdf > > > > if we remove writephyext, by looking the code at [1], rxc-skew-ps will be > taken from the device tree[3] and "txc-skew-pc" will be the default > value(0xf). > > [3]https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/arch/arm/dts/ > > salvator-common.dtsi#L331 > > So you want to check whether each RCar3 DT contains a PHY node and that > PHY node has rxc-skew-ps and txc-skew-ps , which combined then results > into a register value (0xf << 5) | (0x19 << 0) . rxc-skew-ps set in DTS is 1500. 1 step is 60 ps, so 1500/60 = 25 which is 0x19 and this value will be overridden and stored in ofcfg->grp's val[0]. > > I will check this and let you know the results after checking on RCar board. > Unfortunately currently I don't have RCar board. > > It's enough to just check the DTs and verify that they set the matching > correct values of rxc-skew-ps/txc-skew-ps . I can test it on the real > hardware. Yes, that way we can make sure the mapping operation is correct for this phy. 1500 in dts after mapping operation should override ofcfg->grp's val[0] with 0x19. > If you want, you can add the txc-skew-ps into the Linux R-Car3 DTs too. We don't need to set txc-skew-ps in dts, since it is same as default value and is filled in ofcfg->grp's val[1]. We can avoid unnecessary mapping operations by not specifying in device tree, for default values. > btw unrelated, you seem to have rxc-skew-ps in your hihope-rzg2-ex.dtsi, > but I think you don't have KSZ9031 PHY, so maybe you want to remove it > form your DT too. OK. Thanks for reporting this. Will fix this in kernel as well as here. Cheers, Biju Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
