Re: [PATCH 08/16] edison: Remove empty config header
On Mon, Jan 22, 2024 at 05:39:12PM -0500, Tom Rini wrote: > Now that we support having CONFIG_SYS_CONFIG_NAME be unset to indicate a > lack of board.h file, unset this on the edison platform and remove > the otherwise empty file. Acked-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 1/4] acpi: fix FADT table
On Fri, Dec 15, 2023 at 07:26:55PM +0100, Heinrich Schuchardt wrote: > Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to > to uintptr_t to fill these. > > If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If > field X_DSDT is filled, field DSDT must be ignored. We should not fill > unused fields. ... > v2: > no change Have you seen my email? -- With Best Regards, Andy Shevchenko
Re: [PATCH 3/3] cmd: acpi: check HW reduced flag in acpi list
On Fri, Dec 15, 2023 at 05:40:16PM +0100, Heinrich Schuchardt wrote:
> On non x86 platforms the hardware reduce flag must be set in the FADT
> table. Write an error message if the flag is missing.
...
> + if (!IS_ENABLED(CONFIG_X86) &&
> + !(fadt->flags & ACPI_FADT_HW_REDUCED_ACPI))
> + log_err("FADT not ACPI hardware reduced compliant\n");
I guess it's half baked solution as this, HW reduced, flag adds more
limitations even on x86. If you want a good validation it should be done
in a separate function taking others aspects into account.
But since it doesn't affect my area of interest in U-Boot, I won't prevent
you from doing this way, it's up to the U-Boot maintainers how to proceed
with it.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/3] acpi: fix FADT table
On Fri, Dec 15, 2023 at 05:40:14PM +0100, Heinrich Schuchardt wrote: > Fields X_FIRMWAE_CTRL and X_DSDT must be 64bit wide. Convert pointers to > to uintptr_t to fill these. > > If field X_FIRMWARE_CTRL is filled, field FIRMWARE must be ignored. If > field X_DSDT is filled, field DSDT must be ignored. We should not fill > unused fields. Is it dictated by the specifications? Please, put the reference here in the commit message (section X.Y.Z "Goo bar"). ... >From code perspective LGTM. -- With Best Regards, Andy Shevchenko
Re: Setting up boot chain ACPI on ARM with STM32MPU
On Wed, Nov 29, 2023 at 6:25 PM Andy Shevchenko wrote: > On Wed, Nov 29, 2023 at 5:29 PM Ba Gia Bao Phan > wrote: > > > > Hello everyone, > > > > I am a trainee at STMicroelectronics France. I am working on a project > > "Setting up a boot chain ACPI" for STM32MPU, which is based on ARM Cortex-A > > . The objective of my project is to add a way of booting (with ACPI) > > besides Device Tree available on STM32MPU. > > > > I found that ACPI was enabled on some x86 platforms > > I believe you meant here the niche of the (x86) platforms that are not > ACPI-enabled. By default 99% of the x86 platforms are ACPI enabled > with the exceptions: > - Intel MID (2010-2015, SFI based, enabled in U-Boot) For the sake of completeness it was started in 2007 according to the list https://en.wikipedia.org/wiki/Mobile_Internet_device. And - Intel SoFIA (2015) is missing and I don't even know what is used there for platform description. > - Tunnel Creek (2010, DT based) > - A few SpreadTrum SoCs (2017, DT based) > > > but I don't know whether it was set up on ARM or not. I found a PATCH that > > discussed Enabling ACPI booting on ARM with Raspberry Pi 4 but I don't know > > if it functioned or not. Did anyone here succeed in setting up ACPI on ARM > > by U-boot? > > > > What are the differences between x86 and ARM platforms when enabling ACPI? > > The architecture of my board STM32PMU is ARM so can I apply the technique > > used on platform x86 for my board? -- With Best Regards, Andy Shevchenko
Re: Setting up boot chain ACPI on ARM with STM32MPU
On Wed, Nov 29, 2023 at 5:29 PM Ba Gia Bao Phan wrote: > > Hello everyone, > > I am a trainee at STMicroelectronics France. I am working on a project > "Setting up a boot chain ACPI" for STM32MPU, which is based on ARM Cortex-A . > The objective of my project is to add a way of booting (with ACPI) besides > Device Tree available on STM32MPU. > > I found that ACPI was enabled on some x86 platforms I believe you meant here the niche of the (x86) platforms that are not ACPI-enabled. By default 99% of the x86 platforms are ACPI enabled with the exceptions: - Intel MID (2010-2015, SFI based, enabled in U-Boot) - Tunnel Creek (2010, DT based) - A few SpreadTrum SoCs (2017, DT based) > but I don't know whether it was set up on ARM or not. I found a PATCH that > discussed Enabling ACPI booting on ARM with Raspberry Pi 4 but I don't know > if it functioned or not. Did anyone here succeed in setting up ACPI on ARM by > U-boot? > > What are the differences between x86 and ARM platforms when enabling ACPI? > The architecture of my board STM32PMU is ARM so can I apply the technique > used on platform x86 for my board? -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
On Wed, Mar 30, 2022 at 12:21:25PM +0300, Andy Shevchenko wrote: > On Mon, Oct 25, 2021 at 09:52:45PM +0300, Andy Shevchenko wrote: > > On Mon, Oct 25, 2021 at 09:18:56AM -0600, Simon Glass wrote: > > > On Mon, 25 Oct 2021 at 01:34, Andy Shevchenko > > > wrote: > > > > On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > > > > > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > > > > > wrote: > > > > > > > > > > > > The dsdt.asl is usually combined out of several files that are > > > > > > included > > > > > > in the main one. Whenever we change the content of any of such > > > > > > files, > > > > > > build system is not able to recognize them. Hence the easiest way > > > > > > is to > > > > > > force DSDT rebuild each time we run make. > > > > > > > > > Ick. Since it uses #include, doesn't the dependency generation work > > > > > with this? > > > > > > > > How? > > > > > > If you do a sandbox build you will see this file: > > > > > > arch/sandbox/dts/.sandbox.dtb.cmd > > > > > > It contains the dependencies used to compile the device tree. Can we > > > use the same mechanism? There is a .cmd file for the dsdt file but it > > > does not seem to have the correct contents. > > > > A spent more than couple of hours to fight with `make` and failed. > > Maybe you can improve the below (it still rebuilds always) > > So, can we fix this annoying bug, please? Any news here? If no other solution, please apply this patch. -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 2/2] cmd: acpi: fix acpi list command
On Mon, Nov 20, 2023 at 01:34:22PM +0100, Heinrich Schuchardt wrote: > On 11/20/23 12:28, Andy Shevchenko wrote: > > On Sat, Nov 18, 2023 at 11:52:48PM +0100, Heinrich Schuchardt wrote: ... > > (Side question: Do you use --histogram when preparing patches? if no, try > > it.) > > Thanks for reviewing. > > No I don't use --histogram. > > Without --histogram: > 2 files changed, 45 insertions(+), 40 deletions(-) > > With --histogram: > 2 files changed, 54 insertions(+), 49 deletions(-) > > The histogram algorithms finds less commonalities. Why should I prefer this? Readability of the patch. -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 2/2] cmd: acpi: fix acpi list command
On Sat, Nov 18, 2023 at 11:52:48PM +0100, Heinrich Schuchardt wrote:
> ACPI tables may comprise either RSDT, XSDT, or both. The current code fails
> to check the presence of the RSDT table before accessing it. This leads to
> an exception if the RSDT table is not provided.
>
> The XSDT table takes precedence over the RSDT table.
>
> The return values of list_rsdt() and list_rsdp() are always zero and not
> checked. Remove the return values.
>
> Addresses in the XSDT table are 64-bit. Adjust the output accordingly.
>
> As the RSDT table has to be ignored if the XSDT command is present there is
> no need to compare the tables in a display command. Anyway the
> specification does not require that the sequence of addresses in the RSDT
> and XSDT table are the same.
>
> The FACS table header does not provide revision information. Correct the
> description of dump_hdr().
>
> Adjust the ACPI test to match the changed output format of the 'acpi list'
> command.
(Side question: Do you use --histogram when preparing patches? if no, try it.)
...
> + if (rsdp->xsdt_address) {
> + if (!xsdt->entry[i])
> + break;
> + hdr = map_sysmem(xsdt->entry[i], 0);
> + } else {
> + if (!rsdt->entry[i])
> + break;
> + hdr = map_sysmem(rsdt->entry[i], 0);
> + }
With a help of temporary variable this can be rewritten as
tmp = 0; // or NULL, I haven't checked the type.
if (rsdp->xsdt_address)
tmp = xsdt->entry[i];
else
tmp = rsdt->entry[i];
if (!tmp)
break;
hdr = map_sysmem(tmp, 0);
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/2] Reland "x86: Move FACP table into separate functions""
On Wed, Aug 30, 2023 at 09:13:34PM -0600, Simon Glass wrote: > Each board has its own way of creating this table. Rather than calling the > acpi_create_fadt() function for each one from a common acpi_write_fadt() > function, just move the writer into the board-specific code. > > Signed-off-by: Simon Glass > Signed-off-by: Andy Shevchenko Not sure this is correct SoB chain. In kernel project we would do Co-developed-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Simon Glass > --- > (Now fixed - thank you Andy!) Right, Tested-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 2/2] x86: Prevent from missing the FADT chaining
On Fri, Aug 25, 2023 at 04:51:41PM +0300, Andy Shevchenko wrote:
...
> +static inline int acpi_add_fadt(struct acpi_ctx *ctx, struct acpi_fadt *fadt)
> +{
> + acpi_add_table(ctx, fadt);
> + acpi_inc(ctx, sizeof(struct acpi_fadt));
> + return 0;
> +}
Ideally it should be like
int ret;
ret = acpi_add_table(ctx, fadt);
if (ret)
return ret;
acpi_inc(ctx, sizeof(struct acpi_fadt));
return 0;
--
With Best Regards,
Andy Shevchenko
[PATCH v1 2/2] x86: Prevent from missing the FADT chaining
Recent approach with FADT writer shows that there is
a room for subtle errors. Prevent this from happening
again by introducing acpi_add_fadt() helper.
Signed-off-by: Andy Shevchenko
---
arch/x86/cpu/apollolake/acpi.c | 6 +-
arch/x86/cpu/baytrail/acpi.c | 6 +-
arch/x86/cpu/quark/acpi.c | 6 +-
arch/x86/cpu/tangier/acpi.c| 6 +-
include/acpi/acpi_table.h | 7 +++
5 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/x86/cpu/apollolake/acpi.c b/arch/x86/cpu/apollolake/acpi.c
index 16aaed7238ab..c610a7f44770 100644
--- a/arch/x86/cpu/apollolake/acpi.c
+++ b/arch/x86/cpu/apollolake/acpi.c
@@ -158,11 +158,7 @@ static int apl_write_fadt(struct acpi_ctx *ctx, const
struct acpi_writer *entry)
header = >header;
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", apl_write_fadt, 0);
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index 4c526ff27310..4378846f8b0c 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -142,11 +142,7 @@ static int baytrail_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", baytrail_write_fadt, 0);
diff --git a/arch/x86/cpu/quark/acpi.c b/arch/x86/cpu/quark/acpi.c
index 92fa5bc30c36..9a2d682451be 100644
--- a/arch/x86/cpu/quark/acpi.c
+++ b/arch/x86/cpu/quark/acpi.c
@@ -137,11 +137,7 @@ static int quark_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", quark_write_fadt, 0);
diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c
index ffaa56ab6f87..1c667c7d5693 100644
--- a/arch/x86/cpu/tangier/acpi.c
+++ b/arch/x86/cpu/tangier/acpi.c
@@ -52,11 +52,7 @@ static int tangier_write_fadt(struct acpi_ctx *ctx,
header->checksum = table_compute_checksum(fadt, header->length);
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
+ return acpi_add_fadt(ctx, fadt);
}
ACPI_WRITER(5fadt, "FADT", tangier_write_fadt, 0);
diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
index 7ed0443c821a..1f85de091d39 100644
--- a/include/acpi/acpi_table.h
+++ b/include/acpi/acpi_table.h
@@ -883,6 +883,13 @@ void acpi_inc_align(struct acpi_ctx *ctx, uint amount);
*/
int acpi_add_table(struct acpi_ctx *ctx, void *table);
+static inline int acpi_add_fadt(struct acpi_ctx *ctx, struct acpi_fadt *fadt)
+{
+ acpi_add_table(ctx, fadt);
+ acpi_inc(ctx, sizeof(struct acpi_fadt));
+ return 0;
+}
+
/**
* acpi_write_rsdp() - Write out an RSDP indicating where the ACPI tables are
*
--
2.40.0.1.gaa8946217a0b
[PATCH v1 1/2] TO BE FOLDED: x86: tangier: Add FADT to the chain
The Simon's patch missed the FADT to be added to the chain, hence all the issues on Intel Tangier. Signed-off-by: Andy Shevchenko --- arch/x86/cpu/tangier/acpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/cpu/tangier/acpi.c b/arch/x86/cpu/tangier/acpi.c index 01b30553818c..ffaa56ab6f87 100644 --- a/arch/x86/cpu/tangier/acpi.c +++ b/arch/x86/cpu/tangier/acpi.c @@ -52,6 +52,8 @@ static int tangier_write_fadt(struct acpi_ctx *ctx, header->checksum = table_compute_checksum(fadt, header->length); + acpi_add_table(ctx, fadt); + acpi_inc(ctx, sizeof(struct acpi_fadt)); return 0; -- 2.40.0.1.gaa8946217a0b
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Fri, Aug 25, 2023 at 04:25:29PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 25, 2023 at 04:17:58PM +0300, Andy Shevchenko wrote:
> > On Fri, Aug 25, 2023 at 02:06:34PM +0300, Andy Shevchenko wrote:
> > > On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote:
> > > > Each board has its own way of creating this table. Rather than calling
> > > > the
> > > > acpi_create_fadt() function for each one from a common acpi_write_fadt()
> > > > function, just move the writer into the board-specific code.
> > >
> > > No luck, but I have a bit of time to debug more.
> >
> > Okay, after your patch even U-Boot can't see those tables
> >
> > => acpi list
> > Name Base Size Detail
> > - --
> > RSDP 000e4500 24 v02 U-BOOT
> > RSDT 000e4530 34 v01 U-BOOT U-BOOTBL 20231001 INTL 0
> > XSDT 000e45e0 44 v01 U-BOOT U-BOOTBL 20231001 INTL 0
> > CSRT 000e5490 58 v00 U-BOOT U-BOOTBL 20231001 INTL 0
> > MCFG 000e5610 3c v01 U-BOOT U-BOOTBL 20231001 INTL 0
> > SPCR 000e5650 50 v02 U-BOOT U-BOOTBL 20231001 INTL 0
> > APIC 000e56a0 48 v02 U-BOOT U-BOOTBL 20231001 INTL 0
> >
> > Because the base is badly corrupted:
> >
> > -0030: 52 53 44 54 38 00 00 00 01 95 55 2d 42 4f 4f 54 RSDT8.U-BOOT
> > +0030: 52 53 44 54 34 00 00 00 01 eb 55 2d 42 4f 4f 54 RSDT4.U-BOOT
>
> Length -4 bytes, another checksum as a result.
>
> > -0050: 00 00 00 00 90 54 0e 00 f0 54 0e 00 10 56 0e 00 .T...T...V..
> > +0050: 00 00 00 00 90 54 0e 00 10 56 0e 00 50 56 0e 00 .T...V..PV..
>
> Missing pointer to 0x0e54f0 which is... FADT!
>
> > -0060: 50 56 0e 00 a0 56 0e 00 00 00 00 00 00 00 00 00 PV...V..
> > +0060: a0 56 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 .V..
> >
> > -00e0: 58 53 44 54 4c 00 00 00 01 7b 55 2d 42 4f 4f 54 XSDTL{U-BOOT
> > +00e0: 58 53 44 54 44 00 00 00 01 d5 55 2d 42 4f 4f 54 XSDTD.U-BOOT
>
> Wrong length, another checksum.
>
> > -0100: 00 00 00 00 90 54 0e 00 00 00 00 00 f0 54 0e 00 .T...T..
> > +0100: 00 00 00 00 90 54 0e 00 00 00 00 00 10 56 0e 00 .T...V..
> >
> > -0110: 00 00 00 00 10 56 0e 00 00 00 00 00 50 56 0e 00 .V..PV..
> > +0110: 00 00 00 00 50 56 0e 00 00 00 00 00 a0 56 0e 00 PV...V..
> >
> > -0120: 00 00 00 00 a0 56 0e 00 00 00 00 00 00 00 00 00 .V..
> > +0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Same reason. So, your code forgot to link FADT to the main tables.
By code analysis you simply missed
+ acpi_add_table(ctx, fadt);
I'm going to check this right now... Stay tuned!
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Fri, Aug 25, 2023 at 04:17:58PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 25, 2023 at 02:06:34PM +0300, Andy Shevchenko wrote:
> > On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote:
> > > Each board has its own way of creating this table. Rather than calling the
> > > acpi_create_fadt() function for each one from a common acpi_write_fadt()
> > > function, just move the writer into the board-specific code.
> >
> > No luck, but I have a bit of time to debug more.
>
> Okay, after your patch even U-Boot can't see those tables
>
> => acpi list
> Name Base Size Detail
> - --
> RSDP 000e4500 24 v02 U-BOOT
> RSDT 000e4530 34 v01 U-BOOT U-BOOTBL 20231001 INTL 0
> XSDT 000e45e0 44 v01 U-BOOT U-BOOTBL 20231001 INTL 0
> CSRT 000e5490 58 v00 U-BOOT U-BOOTBL 20231001 INTL 0
> MCFG 000e5610 3c v01 U-BOOT U-BOOTBL 20231001 INTL 0
> SPCR 000e5650 50 v02 U-BOOT U-BOOTBL 20231001 INTL 0
> APIC 000e56a0 48 v02 U-BOOT U-BOOTBL 20231001 INTL 0
>
> Because the base is badly corrupted:
>
> -0030: 52 53 44 54 38 00 00 00 01 95 55 2d 42 4f 4f 54 RSDT8.U-BOOT
> +0030: 52 53 44 54 34 00 00 00 01 eb 55 2d 42 4f 4f 54 RSDT4.U-BOOT
Length -4 bytes, another checksum as a result.
> -0050: 00 00 00 00 90 54 0e 00 f0 54 0e 00 10 56 0e 00 .T...T...V..
> +0050: 00 00 00 00 90 54 0e 00 10 56 0e 00 50 56 0e 00 .T...V..PV..
Missing pointer to 0x0e54f0 which is... FADT!
> -0060: 50 56 0e 00 a0 56 0e 00 00 00 00 00 00 00 00 00 PV...V..
> +0060: a0 56 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 .V..
>
> -00e0: 58 53 44 54 4c 00 00 00 01 7b 55 2d 42 4f 4f 54 XSDTL{U-BOOT
> +00e0: 58 53 44 54 44 00 00 00 01 d5 55 2d 42 4f 4f 54 XSDTD.U-BOOT
Wrong length, another checksum.
> -0100: 00 00 00 00 90 54 0e 00 00 00 00 00 f0 54 0e 00 .T...T..
> +0100: 00 00 00 00 90 54 0e 00 00 00 00 00 10 56 0e 00 .T...V..
>
> -0110: 00 00 00 00 10 56 0e 00 00 00 00 00 50 56 0e 00 .V..PV..
> +0110: 00 00 00 00 50 56 0e 00 00 00 00 00 a0 56 0e 00 PV...V..
>
> -0120: 00 00 00 00 a0 56 0e 00 00 00 00 00 00 00 00 00 .V..
> +0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Same reason. So, your code forgot to link FADT to the main tables.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Fri, Aug 25, 2023 at 02:06:34PM +0300, Andy Shevchenko wrote:
> On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote:
> > Each board has its own way of creating this table. Rather than calling the
> > acpi_create_fadt() function for each one from a common acpi_write_fadt()
> > function, just move the writer into the board-specific code.
>
> No luck, but I have a bit of time to debug more.
Okay, after your patch even U-Boot can't see those tables
=> acpi list
Name Base Size Detail
- --
RSDP 000e4500 24 v02 U-BOOT
RSDT 000e4530 34 v01 U-BOOT U-BOOTBL 20231001 INTL 0
XSDT 000e45e0 44 v01 U-BOOT U-BOOTBL 20231001 INTL 0
CSRT 000e5490 58 v00 U-BOOT U-BOOTBL 20231001 INTL 0
MCFG 000e5610 3c v01 U-BOOT U-BOOTBL 20231001 INTL 0
SPCR 000e5650 50 v02 U-BOOT U-BOOTBL 20231001 INTL 0
APIC 000e56a0 48 v02 U-BOOT U-BOOTBL 20231001 INTL 0
Because the base is badly corrupted:
-0030: 52 53 44 54 38 00 00 00 01 95 55 2d 42 4f 4f 54 RSDT8.U-BOOT
+0030: 52 53 44 54 34 00 00 00 01 eb 55 2d 42 4f 4f 54 RSDT4.U-BOOT
-0050: 00 00 00 00 90 54 0e 00 f0 54 0e 00 10 56 0e 00 .T...T...V..
+0050: 00 00 00 00 90 54 0e 00 10 56 0e 00 50 56 0e 00 .T...V..PV..
-0060: 50 56 0e 00 a0 56 0e 00 00 00 00 00 00 00 00 00 PV...V..
+0060: a0 56 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 .V..
-00e0: 58 53 44 54 4c 00 00 00 01 7b 55 2d 42 4f 4f 54 XSDTL{U-BOOT
+00e0: 58 53 44 54 44 00 00 00 01 d5 55 2d 42 4f 4f 54 XSDTD.U-BOOT
-0100: 00 00 00 00 90 54 0e 00 00 00 00 00 f0 54 0e 00 .T...T..
+0100: 00 00 00 00 90 54 0e 00 00 00 00 00 10 56 0e 00 .T...V..
-0110: 00 00 00 00 10 56 0e 00 00 00 00 00 50 56 0e 00 .V..PV..
+0110: 00 00 00 00 50 56 0e 00 00 00 00 00 a0 56 0e 00 PV...V..
-0120: 00 00 00 00 a0 56 0e 00 00 00 00 00 00 00 00 00 .V..
+0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Fri, Aug 25, 2023 at 02:10:05PM +0300, Andy Shevchenko wrote: > On Fri, Aug 25, 2023 at 02:06:34PM +0300, Andy Shevchenko wrote: > > On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote: > > > Each board has its own way of creating this table. Rather than calling the > > > acpi_create_fadt() function for each one from a common acpi_write_fadt() > > > function, just move the writer into the board-specific code. > > > > No luck, but I have a bit of time to debug more. > > U-boot: > > Writing tables to e4500: > ACPI: Writing ACPI tables at e4500 > writing acpi tables > 0base: writing table '' at 000e4500 > - return code 0 > 1facs: writing table 'FACS' at 000e4740 > - return code 0 > 3dsdt: writing table 'DSDT' at 000e4780 > - return code 0 > 4gnvs: writing table 'GNVS' at 000e5390 > - return code 0 > 5csrt: writing table 'CSRT' at 000e5490 > - return code 0 > 5fadt: writing table 'FADT' at 000e54f0 > - return code 0 > 5mcfg: writing table 'MCFG' at 000e5610 > - return code 0 > 5spcr: writing table 'SPCR' at 000e5650 > - return code 0 > 5tcpa: writing table 'TCPA' at 000e56a0 > 5tcpa: Omitted due to being empty > - return code 0 > 5tpm2: writing table 'TPM2' at 000e56a0 > 5tpm2: Omitted due to being empty > - return code 0 > 5x86: writing table '' at 000e56a0 > - return code 0 > 6ssdt: writing table 'SSDT' at 000e56f0 > 6ssdt: Omitted due to being empty > - return code 0 > 8dev: writing table '' at 000e56f0 > - return code 0 > writing acpi tables done ok > ACPI current = e56f0 > - wrote 'acpi' to e4500, end e56f0 > - wrote 'smbios' to e56f0, end e584f > - done writing tables > Linux: > > [0.003034] ACPI: RSDP 0x000E4500 24 (v02 U-BOOT) > [0.003090] ACPI: XSDT 0x000E45E0 44 (v01 U-BOOT U-BOOTBL > 20231001 INTL ) > [0.003158] ACPI: CSRT 0x000E5490 58 (v00 U-BOOT U-BOOTBL > 20231001 INTL ) > [0.003219] ACPI: MCFG 0x000E5610 3C (v01 U-BOOT U-BOOTBL > 20231001 INTL ) > [0.003277] ACPI: SPCR 0x000E5650 50 (v02 U-BOOT U-BOOTBL > 20231001 INTL ) > [0.003332] ACPI: APIC 0x000E56A0 48 (v02 U-BOOT U-BOOTBL > 20231001 INTL ) > [0.003382] ACPI: Reserving CSRT table memory at [mem 0xe5490-0xe54e7] > [0.003403] ACPI: Reserving MCFG table memory at [mem 0xe5610-0xe564b] > [0.003421] ACPI: Reserving SPCR table memory at [mem 0xe5650-0xe569f] > [0.003437] ACPI: Reserving APIC table memory at [mem 0xe56a0-0xe56e7] > > As you can see a few tables are missing: > FACS, DSDT, GNVS, FADT I added a debug to the ACPI writer, so with your patch Writing tables to e4500: ACPI: Writing ACPI tables at e4500 writing acpi tables 0base: writing table '' at 000e4500 * other: Added type 3, 000e4500, size 240 - return code 0 1facs: writing table 'FACS' at 000e4740 * other: Added type 3, 000e4740, size 40 - return code 0 3dsdt: writing table 'DSDT' at 000e4780 Writing DSDT tables Writing DSDT finished, err=0 Failed to find ordering, leaving as is * other: Added type 3, 000e4780, size c10 - return code 0 4gnvs: writing table 'GNVS' at 000e5390 * other: Added type 3, 000e5390, size 100 - return code 0 5csrt: writing table 'CSRT' at 000e5490 * other: Added type 3, 000e5490, size 60 - return code 0 5fadt: writing table 'FADT' at 000e54f0 * other: Added type 3, 000e54f0, size 120 - return code 0 5mcfg: writing table 'MCFG' at 000e5610 * other: Added type 3, 000e5610, size 40 - return code 0 5spcr: writing table 'SPCR' at 000e5650 * other: Added type 3, 000e5650, size 50 - return code 0 5tcpa: writing table 'TCPA' at 000e56a0 5tcpa: Omitted due to being empty - return code 0 5tpm2: writing table 'TPM2' at 000e56a0 5tpm2: Omitted due to being empty - return code 0 5x86: writing table '' at 000e56a0 * other: Added type 3, 000e56a0, size 50 - return code 0 6ssdt: writing table 'SSDT' at 000e56f0 Writing SSDT tables Writing SSDT finished, err=0 Failed to find ordering, leaving as is 6ssdt: Omitted due to being empty - return code 0 8dev: writing table '' at 000e56f0 Writing device tables Writing finished, err=0 - return code 0 writing acpi tables done ok ACPI current = e56f0 - wrote 'acpi' to e4500, end e56f0 - wrote 'smbios' to e56f0, end e584f - done writing tables Without your patch (to save your time: there is no single character difference 100% copy): Writing tables to e4500: ACPI: Writing ACPI tables at e4500 writing acpi tables 0base: writing table '' at 000e4500 * other: Added type 3, 000e4500, size 240 - return code 0 1facs: writing table 'FACS' at 000e4740 * other: Added type 3, 000e4740, size 40 - return code 0 3dsdt: writing table 'DSDT' at 000e4780 Writing DSDT tables Writing DSDT finished, err=0 Failed to find ordering, leaving as is * other:
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Fri, Aug 25, 2023 at 02:06:34PM +0300, Andy Shevchenko wrote: > On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote: > > Each board has its own way of creating this table. Rather than calling the > > acpi_create_fadt() function for each one from a common acpi_write_fadt() > > function, just move the writer into the board-specific code. > > No luck, but I have a bit of time to debug more. U-boot: Writing tables to e4500: ACPI: Writing ACPI tables at e4500 writing acpi tables 0base: writing table '' at 000e4500 - return code 0 1facs: writing table 'FACS' at 000e4740 - return code 0 3dsdt: writing table 'DSDT' at 000e4780 - return code 0 4gnvs: writing table 'GNVS' at 000e5390 - return code 0 5csrt: writing table 'CSRT' at 000e5490 - return code 0 5fadt: writing table 'FADT' at 000e54f0 - return code 0 5mcfg: writing table 'MCFG' at 000e5610 - return code 0 5spcr: writing table 'SPCR' at 000e5650 - return code 0 5tcpa: writing table 'TCPA' at 000e56a0 5tcpa: Omitted due to being empty - return code 0 5tpm2: writing table 'TPM2' at 000e56a0 5tpm2: Omitted due to being empty - return code 0 5x86: writing table '' at 000e56a0 - return code 0 6ssdt: writing table 'SSDT' at 000e56f0 6ssdt: Omitted due to being empty - return code 0 8dev: writing table '' at 000e56f0 - return code 0 writing acpi tables done ok ACPI current = e56f0 - wrote 'acpi' to e4500, end e56f0 - wrote 'smbios' to e56f0, end e584f - done writing tables Linux: [0.003034] ACPI: RSDP 0x000E4500 24 (v02 U-BOOT) [0.003090] ACPI: XSDT 0x000E45E0 44 (v01 U-BOOT U-BOOTBL 20231001 INTL ) [0.003158] ACPI: CSRT 0x000E5490 58 (v00 U-BOOT U-BOOTBL 20231001 INTL ) [0.003219] ACPI: MCFG 0x000E5610 3C (v01 U-BOOT U-BOOTBL 20231001 INTL ) [0.003277] ACPI: SPCR 0x000E5650 50 (v02 U-BOOT U-BOOTBL 20231001 INTL ) [0.003332] ACPI: APIC 0x000E56A0 48 (v02 U-BOOT U-BOOTBL 20231001 INTL ) [0.003382] ACPI: Reserving CSRT table memory at [mem 0xe5490-0xe54e7] [0.003403] ACPI: Reserving MCFG table memory at [mem 0xe5610-0xe564b] [0.003421] ACPI: Reserving SPCR table memory at [mem 0xe5650-0xe569f] [0.003437] ACPI: Reserving APIC table memory at [mem 0xe56a0-0xe56e7] As you can see a few tables are missing: FACS, DSDT, GNVS, FADT -- With Best Regards, Andy Shevchenko
Re: [PATCH 1/2] Reland "x86: Move FACP table into separate functions""
On Thu, Aug 24, 2023 at 12:23:32PM -0600, Simon Glass wrote: > Each board has its own way of creating this table. Rather than calling the > acpi_create_fadt() function for each one from a common acpi_write_fadt() > function, just move the writer into the board-specific code. No luck, but I have a bit of time to debug more. -- With Best Regards, Andy Shevchenko
Re: [PATCH 00/22] x86: Move some boards to text environment
On Mon, Aug 07, 2023 at 03:30:25PM +0200, Michael Nazzareno Trimarchi wrote: > On Mon, Aug 7, 2023 at 3:04 PM Andy Shevchenko > wrote: > > On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote: > > > Hi Pali > > > > > > Can you just filter emails on your side? > > > > Independently on the question is default setup is good or not > > (from _this_ point of view, I *disagree* with Pali), we have to > > have a possibility to filter on _our_ side the email addresses > > to make people happy. If Pali by some reasons does not want to > > see, it must be easy to keep some deny list in the repository. > > > > What you are suggesting is not polite I believe. > > I understand what you mean, I never consider emails to me as a problem > if I'm working > on an opensource project and mostly of the time I'm happy to receive them It really depends. I agree with Bin on that, but we should respect someone's wishes (in case it's done automatically by heuristics [git history] rather than letter of law [MAINTAINERS database]). > > > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár wrote: > > > > > > > > So remove me from that list of dram.c file. I'm not interested to > > > > receive emails from people who are ignoring me about unrelated things. > > > > > > > > On Monday 07 August 2023 09:43:01 Bin Meng wrote: > > > > > Hi Pali, > > > > > > > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár wrote: > > > > > > > > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár wrote: > > > > > > > > > > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So > > > > > > > > please > > > > > > > > do not send me these emails. I have expressed it many times. > > > > > > > > > > > > > > You were sent one patch (and the cover letter) because you are the > > > > > > > second committer on arch/x86/cpu/qemu/dram.c > > > > > > > > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I > > > > > > have to > > > > > > repeat it? You do not understand? Or what you are trying to do now? > > > > > > > > > > I believe this cc list comes from patman which calls get_maintainer.pl > > > > > to get the cc list. > > > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of > > > > > the changed file 2. git commit history of the changed file. > > > > > > > > > > I can see the philosophy was that someone who touched the changed file > > > > > should be copied for review. > > > > > We certainly could argue that and just get the list solely from the > > > > > MAINTAINERS file. -- With Best Regards, Andy Shevchenko
Re: [PATCH 00/22] x86: Move some boards to text environment
On Mon, Aug 07, 2023 at 02:44:31PM +0200, Michael Nazzareno Trimarchi wrote: > Hi Pali > > Can you just filter emails on your side? Independently on the question is default setup is good or not (from _this_ point of view, I *disagree* with Pali), we have to have a possibility to filter on _our_ side the email addresses to make people happy. If Pali by some reasons does not want to see, it must be easy to keep some deny list in the repository. What you are suggesting is not polite I believe. > On Mon, Aug 7, 2023 at 2:18 PM Pali Rohár wrote: > > > > So remove me from that list of dram.c file. I'm not interested to > > receive emails from people who are ignoring me about unrelated things. > > > > On Monday 07 August 2023 09:43:01 Bin Meng wrote: > > > Hi Pali, > > > > > > On Sun, Aug 6, 2023 at 11:55 PM Pali Rohár wrote: > > > > > > > > On Sunday 06 August 2023 08:39:43 Simon Glass wrote: > > > > > Hi Pali, > > > > > > > > > > On Sun, 6 Aug 2023 at 04:51, Pali Rohár wrote: > > > > > > > > > > > > I'm not x86 maintainer, and I'm not going to review changes. So > > > > > > please > > > > > > do not send me these emails. I have expressed it many times. > > > > > > > > > > You were sent one patch (and the cover letter) because you are the > > > > > second committer on arch/x86/cpu/qemu/dram.c > > > > > > > > I'm not maintainer of arch/x86/cpu/qemu/dram.c. How many times I have to > > > > repeat it? You do not understand? Or what you are trying to do now? > > > > > > I believe this cc list comes from patman which calls get_maintainer.pl > > > to get the cc list. > > > get_maintainer.pl determines the person names from 1. MAINTAINERS of > > > the changed file 2. git commit history of the changed file. > > > > > > I can see the philosophy was that someone who touched the changed file > > > should be copied for review. > > > We certainly could argue that and just get the list solely from the > > > MAINTAINERS file. > > > > > > Regards, > > > Bin > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > __ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com -- With Best Regards, Andy Shevchenko
Re: [PATCH 00/22] x86: Move some boards to text environment
On Sun, Jul 30, 2023 at 09:01:43PM -0600, Simon Glass wrote: > This series starts the process of moving x86 boards to a text environment. > > This includes conversions for about half the boards. > > The rest (including the more complicated Chromebooks) can come in a later > series. Patch wise it looks good to me Reviewed-by: Andy Shevchenko # Intel Edison Where can I read about this new edison.env file and what is expected to be there? > doc: Explain how to avoid the distro-boot scripts > env: Use include/env for text-environment includes > env: Explain how to use #include files in text environment > x86: Drop CFG_SYS_STACK_SIZE > x86: i8254: Include required ibmpc.h header > x86: edison: Drop inclusion of ibmpc.h > x86: Drop inclusion of ibmpc.h > x86: Drop unused distro settings > x86: Add a common include for environment settings > x86: coreboot: Convert to text environment > x86: crownbay: Convert to text environment > x86: bayleybay: Convert to text environment > x86: galileo: Convert to text environment > x86: edison: Convert to text environment > x86: cherryhill: Convert to text environment > x86: cougarcanyon2: Convert to text environment > x86: minnowmax: Convert to text environment > x86: slimbootloader: Convert to text environment > x86: efi-x86_app: Convert to text environment > x86: efi-x86_payload: Convert to text environment > x86: qemu: Add required linux/sizes.h include > x86: qemu-x86: Convert to text environment > > arch/x86/cpu/qemu/dram.c | 1 + > arch/x86/cpu/qemu/e820.c | 1 + > arch/x86/lib/i8254.c | 1 + > arch/x86/lib/physmem.c| 3 +- > board/coreboot/coreboot/coreboot.env | 9 + > board/efi/efi-x86_app/efi-x86_app.env | 6 > board/efi/efi-x86_payload/efi-x86_payload.env | 6 > board/emulation/qemu-x86/qemu-x86.env | 6 > board/intel/bayleybay/bayleybay.env | 9 + > board/intel/cherryhill/cherryhill.env | 9 + > board/intel/cougarcanyon2/cougarcanyon2.env | 6 > board/intel/crownbay/crownbay.env | 6 > board/intel/edison/edison.env | 6 > board/intel/galileo/galileo.env | 11 ++ > board/intel/minnowmax/minnowmax.env | 11 ++ > board/intel/slimbootloader/slimbootloader.env | 25 + > board/keymile/km83xx/km83xx.env | 4 +-- > board/keymile/kmcent2/kmcent2.env | 2 +- > .../keymile/pg-wcom-ls102xa/pg-wcom-expu1.env | 2 +- > .../keymile/pg-wcom-ls102xa/pg-wcom-seli8.env | 2 +- > board/siemens/iot2050/iot2050.env | 2 +- > board/ti/am62ax/am62ax.env| 4 +-- > board/ti/am62x/am62x.env | 4 +-- > board/ti/am64x/am64x.env | 6 ++-- > board/ti/am65x/am65x.env | 8 ++--- > board/ti/j721e/j721e.env | 10 +++--- > board/ti/j721s2/j721s2.env| 10 +++--- > board/ti/ks2_evm/k2e_evm.env | 4 +-- > board/ti/ks2_evm/k2g_evm.env | 6 ++-- > board/ti/ks2_evm/k2hk_evm.env | 4 +-- > board/ti/ks2_evm/k2l_evm.env | 4 +-- > doc/usage/environment.rst | 8 - > include/configs/am335x_evm.h | 2 +- > include/configs/am43xx_evm.h | 2 +- > include/configs/am57xx_evm.h | 2 +- > include/configs/am62ax_evm.h | 4 +-- > include/configs/am62x_evm.h | 2 +- > include/configs/am64x_evm.h | 4 +-- > include/configs/am65x_evm.h | 6 ++-- > include/configs/bayleybay.h | 17 - > include/configs/cherryhill.h | 13 --- > include/configs/coreboot.h| 20 --- > include/configs/cougarcanyon2.h | 13 --- > include/configs/crownbay.h| 17 - > include/configs/da850evm.h| 2 +- > include/configs/dra7xx_evm.h | 2 +- > include/configs/edison.h | 11 -- > include/configs/efi-x86_app.h | 11 -- > include/configs/efi-x86_payload.h | 17 - > include/configs/galileo.h | 19 -- > include/configs/minnowmax.h | 16 - > include/configs/omap3_evm.h | 2 +- > include/configs/omapl138_lcdk.h | 2 +- > include/configs/phycore_am335x_r2.h | 4 +-- > include/configs/qe
Re: [PATCH v2] IOMUX: Fix access past end of console_devices
On Wed, Apr 06, 2022 at 02:36:35PM -0400, Sean Anderson wrote:
> We should only access console_devices[file][i] once we have checked that i
> < cd_count[file]. Otherwise, we will access uninitialized memory at the end
> of the loop. console_devices[file][i] should not be NULL, but putting the
> assignment in the loop condition allows us to ensure that i is checked
> beforehand. This isn't a bug, but it does make valgrind stop complaining.
Acked-by: Andy Shevchenko
> Fixes: 400797cad3 ("IOMUX: Split out for_each_console_dev() helper macro")
> Signed-off-by: Sean Anderson
> Reviewed-by: Andrew Scull
> ---
>
> Changes in v2:
> - Put each clause of the for loop on its own line
>
> include/iomux.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/iomux.h b/include/iomux.h
> index 37f5f6dee6..35caa697eb 100644
> --- a/include/iomux.h
> +++ b/include/iomux.h
> @@ -24,10 +24,10 @@ extern struct stdio_dev **console_devices[MAX_FILES];
> */
> extern int cd_count[MAX_FILES];
>
> -#define for_each_console_dev(i, file, dev) \
> - for (i = 0, dev = console_devices[file][i]; \
> - i < cd_count[file];\
> - i++, dev = console_devices[file][i])
> +#define for_each_console_dev(i, file, dev) \
> + for (i = 0; \
> + i < cd_count[file] && (dev = console_devices[file][i]);\
> + i++)
>
> int iomux_match_device(struct stdio_dev **, const int, struct stdio_dev *);
> int iomux_doenv(const int, const char *);
> --
> 2.35.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] IOMUX: Fix access past end of console_devices
On Wed, Mar 30, 2022 at 01:25:59PM -0400, Sean Anderson wrote: > On 3/30/22 1:13 PM, Andy Shevchenko wrote: > > On Wed, Mar 30, 2022 at 7:49 PM Sean Anderson wrote: > > > > Also I don't like to have workarounds for the broken tools. > > But if you still want to have something, what about rather this > > > > > #define for_each_console_dev(i, file, dev) \ > > > - for (i = 0, dev = console_devices[file][i]; \ > > > -i < cd_count[file];\ > > > -i++, dev = console_devices[file][i]) > > > + for (i = 0; i < cd_count[file] && \ > > > + (dev = console_devices[file][i]); i++) > > > > for (i = 0, dev = console_devices[file][0]; \ > > i < cd_count[file];\ > > i++, dev = console_devices[file][i]) > > > > ? > > > > Or if it's still complains > > > > for (i = 0, dev = cd_count[file] ? console_devices[file][0] : NULL; > > \ > > i < cd_count[file];\ > > i++, dev = console_devices[file][i]) > > > > ? > > The problem is not the first assignment but the last. Consider the case when > cd_count[file] = 1 Following that logic the first one is also problematic when cd_count[file] == 0. > i = 0, dev = console_devices[file][0]; // OK > i < cd_count[file] // 0 < 1 > // loop body > i++, dev = console_devices[file][1] // Oops, past the end > i < cd_count[file] // 1 < 1, loop exit I don't see good solution. :-( Maybe moving to dev as a loop variable and having NULL terminated arrays should fix that. For now probably your solution is a good compromise. But, please rewrite it to have all three more visible in a for-loop: for (i = 0; \ i < cd_count[file] && (dev = console_devices[file][i]);\ i++) -- With Best Regards, Andy Shevchenko
Re: [PATCH] IOMUX: Fix access past end of console_devices
On Wed, Mar 30, 2022 at 7:49 PM Sean Anderson wrote: Also I don't like to have workarounds for the broken tools. But if you still want to have something, what about rather this > #define for_each_console_dev(i, file, dev) \ > - for (i = 0, dev = console_devices[file][i]; \ > -i < cd_count[file];\ > -i++, dev = console_devices[file][i]) > + for (i = 0; i < cd_count[file] && \ > + (dev = console_devices[file][i]); i++) for (i = 0, dev = console_devices[file][0]; \ i < cd_count[file];\ i++, dev = console_devices[file][i]) ? Or if it's still complains for (i = 0, dev = cd_count[file] ? console_devices[file][0] : NULL; \ i < cd_count[file];\ i++, dev = console_devices[file][i]) ? -- With Best Regards, Andy Shevchenko
Re: [PATCH] IOMUX: Fix access past end of console_devices
On Wed, Mar 30, 2022 at 8:05 PM Sean Anderson wrote: > On 3/30/22 1:01 PM, Andy Shevchenko wrote: > > On Wed, Mar 30, 2022 at 7:49 PM Sean Anderson wrote: ... > >> #define for_each_console_dev(i, file, dev) \ > >> - for (i = 0, dev = console_devices[file][i]; \ > > > > When we enter the loop, the dev is assigned and perhaps valid > > > >> -i < cd_count[file];\ > >> -i++, dev = console_devices[file][i]) > >> + for (i = 0; i < cd_count[file] && \ > > > > Not the case anymore. > > The loop condition is evaluated before we enter the loop, > which includes the first assignment to dev. Yeah, I just sent a reply to my reply :-) > >> + (dev = console_devices[file][i]); i++) So, what I don't like is exactly this hidenness, which I have stumbled upon. -- With Best Regards, Andy Shevchenko
Re: [PATCH] IOMUX: Fix access past end of console_devices
On Wed, Mar 30, 2022 at 8:01 PM Andy Shevchenko wrote: > On Wed, Mar 30, 2022 at 7:49 PM Sean Anderson wrote: ... > > #define for_each_console_dev(i, file, dev) \ > > - for (i = 0, dev = console_devices[file][i]; \ > > When we enter the loop, the dev is assigned and perhaps valid > > > -i < cd_count[file];\ > > -i++, dev = console_devices[file][i]) > > + for (i = 0; i < cd_count[file] && \ > > Not the case anymore. > > > + (dev = console_devices[file][i]); i++) On the second look, it seems a bit unusual, but for loop checks the condition before entering and in such case the dev will be assigned if the count is greater than 0. So, basically the difference is that dev is left completely uninitialized in case of count==0. However, it may not be a problem. Anyways, I would rather see better written for-loop that we see the iterations -- With Best Regards, Andy Shevchenko
Re: [PATCH] IOMUX: Fix access past end of console_devices
On Wed, Mar 30, 2022 at 7:49 PM Sean Anderson wrote:
>
> We should only access console_devices[file][i] once we have checked that
> i < cd_count[file]. Otherwise, we will access uninitialized memory at the end
> of
> the loop. console_devices[file][i] should not be NULL, but putting the
> assignment in the loop condition allows us to ensure that i is checked
> beforehand. This isn't a bug, but it does make valgrind stop complaining.
> Fixes: 400797cad3 ("IOMUX: Split out for_each_console_dev() helper macro")
Has this been tested? See below.
...
> #define for_each_console_dev(i, file, dev) \
> - for (i = 0, dev = console_devices[file][i]; \
When we enter the loop, the dev is assigned and perhaps valid
> -i < cd_count[file];\
> -i++, dev = console_devices[file][i])
> + for (i = 0; i < cd_count[file] && \
Not the case anymore.
> + (dev = console_devices[file][i]); i++)
--
With Best Regards,
Andy Shevchenko
[PATCH v1 1/1] Revert "x86: Move FACP table into separate functions"
Before the culprit patch (see BugLink for the details):
=> acpi list
Name Base Size Detail
- --
RSDP 000e4500 24 v02 U-BOOT
RSDT 000e4530 38 v01 U-BOOT U-BOOTBL 20220401 INTL 0
XSDT 000e45e0 4c v01 U-BOOT U-BOOTBL 20220401 INTL 0
CSRT 000e5490 58 v00 U-BOOT U-BOOTBL 20220401 INTL 0
FACP 000e54f0114 v06 U-BOOT U-BOOTBL 20220401 INTL 0
DSDT 000e4780c06 v02 U-BOOT U-BOOTBL 1 INTL 20200925
FACS 000e4740 40
MCFG 000e5610 3c v01 U-BOOT U-BOOTBL 20220401 INTL 0
SPCR 000e5650 50 v02 U-BOOT U-BOOTBL 20220401 INTL 0
APIC 000e56a0 48 v02 U-BOOT U-BOOTBL 20220401 INTL 0
After the culprit patch:
=> acpi list
Name Base Size Detail
- --
RSDP 000e4500 24 v02 U-BOOT
RSDT 000e4530 34 v01 U-BOOT U-BOOTBL 20220401 INTL 0
XSDT 000e45e0 44 v01 U-BOOT U-BOOTBL 20220401 INTL 0
CSRT 000e53a0 58 v00 U-BOOT U-BOOTBL 20220401 INTL 0
MCFG 000e5520 3c v01 U-BOOT U-BOOTBL 20220401 INTL 0
SPCR 000e5560 50 v02 U-BOOT U-BOOTBL 20220401 INTL 0
APIC 000e55b0 48 v02 U-BOOT U-BOOTBL 20220401 INTL 0
As a result Linux kernel can't find mandatory tables and fails
to boot.
Hence, revert it for good.
This reverts commit 379d3c1fd6aa490b1ad5697525cfc89b615cf25a.
BugLink: https://lore.kernel.org/all/20220131225930.GJ7515@bill-the-cat/
Signed-off-by: Andy Shevchenko
---
arch/x86/cpu/apollolake/acpi.c| 17 -
arch/x86/cpu/baytrail/acpi.c | 27 ---
arch/x86/cpu/quark/acpi.c | 27 ---
arch/x86/cpu/tangier/acpi.c | 25 -
arch/x86/include/asm/acpi_table.h | 2 ++
arch/x86/lib/acpi_table.c | 15 +++
6 files changed, 45 insertions(+), 68 deletions(-)
diff --git a/arch/x86/cpu/apollolake/acpi.c b/arch/x86/cpu/apollolake/acpi.c
index a3dd7373af0d..fd21c0b49684 100644
--- a/arch/x86/cpu/apollolake/acpi.c
+++ b/arch/x86/cpu/apollolake/acpi.c
@@ -146,25 +146,16 @@ void fill_fadt(struct acpi_fadt *fadt)
fadt->x_pm_tmr_blk.addrl = IOMAP_ACPI_BASE + PM1_TMR;
}
-static int apl_write_fadt(struct acpi_ctx *ctx, const struct acpi_writer
*entry)
+void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
+ void *dsdt)
{
- struct acpi_table_header *header;
- struct acpi_fadt *fadt;
+ struct acpi_table_header *header = >header;
- fadt = ctx->current;
- acpi_fadt_common(fadt, ctx->facs, ctx->dsdt);
+ acpi_fadt_common(fadt, facs, dsdt);
intel_acpi_fill_fadt(fadt);
fill_fadt(fadt);
- header = >header;
header->checksum = table_compute_checksum(fadt, header->length);
-
- acpi_add_table(ctx, fadt);
-
- acpi_inc(ctx, sizeof(struct acpi_fadt));
-
- return 0;
}
-ACPI_WRITER(5fadt, "FACS", apl_write_fadt, 0);
int apl_acpi_fill_dmar(struct acpi_ctx *ctx)
{
diff --git a/arch/x86/cpu/baytrail/acpi.c b/arch/x86/cpu/baytrail/acpi.c
index 59db2e2c5d84..07757b88a305 100644
--- a/arch/x86/cpu/baytrail/acpi.c
+++ b/arch/x86/cpu/baytrail/acpi.c
@@ -15,24 +15,20 @@
#include
#include
-static int baytrail_write_fadt(struct acpi_ctx *ctx,
- const struct acpi_writer *entry)
+void acpi_create_fadt(struct acpi_fadt *fadt, struct acpi_facs *facs,
+ void *dsdt)
{
- struct acpi_table_header *header;
- struct acpi_fadt *fadt;
-
- fadt = ctx->current;
- header = >header;
+ struct acpi_table_header *header = &(fadt->header);
u16 pmbase = ACPI_BASE_ADDRESS;
- memset(fadt, '\0', sizeof(struct acpi_fadt));
+ memset((void *)fadt, 0, sizeof(struct acpi_fadt));
acpi_fill_header(header, "FACP");
header->length = sizeof(struct acpi_fadt);
header->revision = 4;
- fadt->firmware_ctrl = (u32)ctx->facs;
- fadt->dsdt = (u32)ctx->dsdt;
+ fadt->firmware_ctrl = (u32)facs;
+ fadt->dsdt = (u32)dsdt;
fadt->preferred_pm_profile = ACPI_PM_MOBILE;
fadt->sci_int = 9;
fadt->smi_cmd = 0;
@@ -79,9 +75,9 @@ static int baytrail_write_fadt(struct acpi_ctx *ctx,
fadt->reset_reg.addrh = 0;
fadt->reset_value = SYS_RST | RST_CPU | FULL_RST;
- fadt->x_firmware_ctl_l = (u32)ctx->facs;
+ fadt->x_firmware_ctl_l = (u32)facs;
fadt->x_firmware_ctl_h = 0;
- fadt->x_dsdt_l = (u32)ctx->dsdt;
+ fadt->x_dsdt_l = (u32)dsdt;
fadt->x_dsdt_h = 0;
fadt->x_pm1a_evt_blk.space_id = ACPI_ADDRESS_SPACE_IO;
@@ -141,14 +137,7 @@ static int baytrail_write_fadt(struct acpi_ctx *ctx,
fadt->x_gpe1_blk.addrh = 0x0;
header->checksum = table_compute_checksum(fadt, header->length)
Re: [ANN] U-Boot v2022.04-rc1 released
On Sat, Feb 12, 2022 at 05:02:00PM +0200, Andy Shevchenko wrote: > On Fri, Feb 11, 2022 at 9:15 PM Andy Shevchenko > wrote: > > On Fri, Feb 11, 2022 at 8:46 PM Andy Shevchenko > > wrote: > > > On Fri, Feb 11, 2022 at 8:31 PM Andy Shevchenko > > > wrote: > > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > ... > > > > git bisect bad 379d3c1fd6aa490b1ad5697525cfc89b615cf25a > > > # first bad commit: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: > > > Move FACP table into separate functions > > > u-boot((379d3c1fd6aa...)|BISECTING)$ > > > > For the record, these two > > acpi: Move MCFG implementation to common lib > > arch: x86: lib: acpi_table: Fix MCFG entries > > > > do not help. > > > > > Irony is that I have reviewed it, but that time I was busy and couldn't > > > test. > > > > > > > Simon, can you prioritize setting up Edison to make it available for > > > > tests? > > > > So, I'm open to testing any other suggestions. > > Meanwhile I will try to revert and if it works and no other solution > comes, I will send it out. Revert has been sent. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/2] hexdump: Introduce debug APIs
On Sat, Nov 13, 2021 at 11:14:28AM -0700, Simon Glass wrote: > On Tue, 9 Nov 2021 at 05:03, Andy Shevchenko > wrote: > > > > debug_hex_dump() and debug_hex_dump_bytes() conditionally print > > the dump based on DEBUG definition. > > > > Signed-off-by: Andy Shevchenko > > --- > > include/hexdump.h | 4 > > lib/hexdump.c | 60 --- > > 2 files changed, 56 insertions(+), 8 deletions(-) > > +Heinrich Schuchardt Heinrich, it's several months passed. What should we do? > Is it possible to resolve this in the header file? It is a bit odd to > have to add DEBUG to hexdump.c in order to get debug output. > > Note also the logging system so you can do > > log(LOG_CATEGORY, dbg ? LOGL_DEBUG : LOGL_INFO, "fmt ...", ...) -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] Makefile.lib: Re-use $(UBOOTINCLUDE) in dtc_cpp_flags
As in ASL case use same basic set of the inclusions. Signed-off-by: Andy Shevchenko --- scripts/Makefile.lib | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index c14da10de780..2ff39d39dc8a 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -185,12 +185,10 @@ u_boot_dtsi = $(strip $(u_boot_dtsi_options_debug) \ # Modified for U-Boot dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc\ +$(UBOOTINCLUDE) \ -I$(srctree)/arch/$(ARCH)/dts \ -I$(srctree)/arch/$(ARCH)/dts/include \ --Iinclude \ -I$(srctree)/include\ --I$(srctree)/arch/$(ARCH)/include \ --include $(srctree)/include/linux/kconfig.h \ -D__ASSEMBLY__ \ -undef -D__DTS__ -- 2.35.1
Re: [ANN] U-Boot v2022.04-rc5 released
On Mon, Mar 28, 2022 at 5:17 PM Tom Rini wrote: > > Hey all, > > It's release day and so here's v2022.04-rc5. The release itself is next > week and the next branch is open. I've merged all regression and > critical fixes I know of so if something else is missing please speak up > as soon as possible. > > In terms of a changelog, > git log --merges v2022.04-rc4..v2022.04-rc5 > contains what I've pulled but as always, better PR messages and tags > will provide better results here. > > The next release will be the final one in this cycle, April 4th 2022. > Thanks all! What is the status of the ACPI series that broke at least Edison at rc1 time? Simon never returned to me with answers to my questions. P.S. I'll re-test today rc5. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
On Mon, Oct 25, 2021 at 09:52:45PM +0300, Andy Shevchenko wrote: > On Mon, Oct 25, 2021 at 09:18:56AM -0600, Simon Glass wrote: > > On Mon, 25 Oct 2021 at 01:34, Andy Shevchenko > > wrote: > > > On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > > > > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > > > > wrote: > > > > > > > > > > The dsdt.asl is usually combined out of several files that are > > > > > included > > > > > in the main one. Whenever we change the content of any of such files, > > > > > build system is not able to recognize them. Hence the easiest way is > > > > > to > > > > > force DSDT rebuild each time we run make. > > > > > > > Ick. Since it uses #include, doesn't the dependency generation work > > > > with this? > > > > > > How? > > > > If you do a sandbox build you will see this file: > > > > arch/sandbox/dts/.sandbox.dtb.cmd > > > > It contains the dependencies used to compile the device tree. Can we > > use the same mechanism? There is a .cmd file for the dsdt file but it > > does not seem to have the correct contents. > > A spent more than couple of hours to fight with `make` and failed. > Maybe you can improve the below (it still rebuilds always) So, can we fix this annoying bug, please? -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 09:54:38PM +0200, Andy Shevchenko wrote: > On Fri, Feb 11, 2022 at 09:47:52PM +0200, Andy Shevchenko wrote: > > On Fri, Feb 11, 2022 at 12:31:46PM -0700, Simon Glass wrote: > > > On Fri, 11 Feb 2022 at 12:29, Andy Shevchenko > > > wrote: > > > > On Fri, Feb 11, 2022 at 9:26 PM Simon Glass wrote: > > ... > > > > > To the topic, any suggestions on how to fix the current U-Boot > > > > regression? > > > > > > The easiest thing is to use 'acpi list' and 'acpi dump facp' etc. to > > > see what is different between the two commits. My testing was on coral > > > and minnowmax and I must have missed it. We don't actually have any > > > test coverage on the board-specific code. > > > > => acpi dump facp > > Table 'FACP' not found > > > > This explains I believe everything. > > So, how is this ACPI_WRITER() supposed to work? Any documentation, please? So. what's news here, please? -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] efi_loader: initrddump: Actually use the custom CFLAGS
It seems a copy'n'paste typo when tool had been introduced.
It has never had the 'exit' suffix in the file name. Hence,
the custom CFLAGS never been applied and, for example, BFD
linker complains:
LD lib/efi_loader/initrddump_efi.so
ld.bfd: lib/efi_loader/initrddump.o: warning: relocation in read-only section
`.text.efi_main'
ld.bfd: warning: creating DT_TEXTREL in a shared object
Remove wrong 'exit' suffix from the custom CFLAGS variable.
Fixes: 65ab48d69ddb ("efi_selftest: provide initrddump test tool")
Signed-off-by: Andy Shevchenko
---
lib/efi_loader/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index befed7144e78..034d26cf0109 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -16,7 +16,7 @@ CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
CFLAGS_dtbdump.o := $(CFLAGS_EFI) -Os -ffreestanding
CFLAGS_REMOVE_dtbdump.o := $(CFLAGS_NON_EFI)
-CFLAGS_initrddump_exit.o := $(CFLAGS_EFI) -Os -ffreestanding
+CFLAGS_initrddump.o := $(CFLAGS_EFI) -Os -ffreestanding
CFLAGS_REMOVE_initrddump.o := $(CFLAGS_NON_EFI)
ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
--
2.35.1
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 9:15 PM Andy Shevchenko wrote: > On Fri, Feb 11, 2022 at 8:46 PM Andy Shevchenko > wrote: > > On Fri, Feb 11, 2022 at 8:31 PM Andy Shevchenko > > wrote: > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: ... > > git bisect bad 379d3c1fd6aa490b1ad5697525cfc89b615cf25a > > # first bad commit: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: > > Move FACP table into separate functions > > u-boot((379d3c1fd6aa...)|BISECTING)$ > > For the record, these two > acpi: Move MCFG implementation to common lib > arch: x86: lib: acpi_table: Fix MCFG entries > > do not help. > > > Irony is that I have reviewed it, but that time I was busy and couldn't > > test. > > > > > Simon, can you prioritize setting up Edison to make it available for > > > tests? > > So, I'm open to testing any other suggestions. Meanwhile I will try to revert and if it works and no other solution comes, I will send it out. -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 09:47:52PM +0200, Andy Shevchenko wrote: > On Fri, Feb 11, 2022 at 12:31:46PM -0700, Simon Glass wrote: > > On Fri, 11 Feb 2022 at 12:29, Andy Shevchenko > > wrote: > > > On Fri, Feb 11, 2022 at 9:26 PM Simon Glass wrote: ... > > > To the topic, any suggestions on how to fix the current U-Boot regression? > > > > The easiest thing is to use 'acpi list' and 'acpi dump facp' etc. to > > see what is different between the two commits. My testing was on coral > > and minnowmax and I must have missed it. We don't actually have any > > test coverage on the board-specific code. > > => acpi dump facp > Table 'FACP' not found > > This explains I believe everything. So, how is this ACPI_WRITER() supposed to work? Any documentation, please? -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 09:47:52PM +0200, Andy Shevchenko wrote: > On Fri, Feb 11, 2022 at 12:31:46PM -0700, Simon Glass wrote: > > On Fri, 11 Feb 2022 at 12:29, Andy Shevchenko > > wrote: > > > On Fri, Feb 11, 2022 at 9:26 PM Simon Glass wrote: > > > > On Fri, 11 Feb 2022 at 11:28, Andy Shevchenko > > > > wrote: > > > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > > > > > ... > > > > > > > FWIW here is my tboot flash script for Edison: > > > > > > This is rather unbriking script, DFU (luckily) works > > > > Not if it is bricked: :-) I need something that always works. > > > > > > > > > def flash_edison(self, repo): > > > > vid = 0x8086 > > > > pid = 0xe005 > > > > expect = "%04x:%04x" % (vid, pid) > > > > self.wait_for_dfu(expect) > > > > u_boot = os.path.join(repo._local_str(), "u-boot-edison.img") > > > > bindir = self.usbboot_xfstk_dir > > > > self.host.exec0( > > > > "xfstk-dldr-solo", "--gpflags", "0x8007", > > > > "--osimage", u_boot, > > > > "--fwdnx", os.path.join(bindir, "edison_dnx_fwr.bin"), > > > > "--fwimage", os.path.join(bindir, "edison_ifwi-dbg-00.bin"), > > > > "--osdnx", os.path.join(bindir, "edison_dnx_osr.bin")) > > > > > > To the topic, any suggestions on how to fix the current U-Boot regression? > > > > The easiest thing is to use 'acpi list' and 'acpi dump facp' etc. to > > see what is different between the two commits. My testing was on coral > > and minnowmax and I must have missed it. We don't actually have any > > test coverage on the board-specific code. > > => acpi dump facp > Table 'FACP' not found > > This explains I believe everything. Side question(s): - Why out of a sudden different name here: ACPI_WRITER(5fadt, "FACS", apl_write_fadt, 0); FACS vs FACP - Why do you need double assignment of the same revision in acpi_fadt_common() header->revision = 4; ... /* Use ACPI 3.0 revision */ fadt->header.revision = 4; -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 12:31:46PM -0700, Simon Glass wrote: > On Fri, 11 Feb 2022 at 12:29, Andy Shevchenko > wrote: > > On Fri, Feb 11, 2022 at 9:26 PM Simon Glass wrote: > > > On Fri, 11 Feb 2022 at 11:28, Andy Shevchenko > > > wrote: > > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > > > ... > > > > > FWIW here is my tboot flash script for Edison: > > > > This is rather unbriking script, DFU (luckily) works > > Not if it is bricked: :-) I need something that always works. > > > > > > def flash_edison(self, repo): > > > vid = 0x8086 > > > pid = 0xe005 > > > expect = "%04x:%04x" % (vid, pid) > > > self.wait_for_dfu(expect) > > > u_boot = os.path.join(repo._local_str(), "u-boot-edison.img") > > > bindir = self.usbboot_xfstk_dir > > > self.host.exec0( > > > "xfstk-dldr-solo", "--gpflags", "0x8007", > > > "--osimage", u_boot, > > > "--fwdnx", os.path.join(bindir, "edison_dnx_fwr.bin"), > > > "--fwimage", os.path.join(bindir, "edison_ifwi-dbg-00.bin"), > > > "--osdnx", os.path.join(bindir, "edison_dnx_osr.bin")) > > > > To the topic, any suggestions on how to fix the current U-Boot regression? > > The easiest thing is to use 'acpi list' and 'acpi dump facp' etc. to > see what is different between the two commits. My testing was on coral > and minnowmax and I must have missed it. We don't actually have any > test coverage on the board-specific code. => acpi dump facp Table 'FACP' not found This explains I believe everything. -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 9:26 PM Simon Glass wrote: > On Fri, 11 Feb 2022 at 11:28, Andy Shevchenko > wrote: > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: ... > FWIW here is my tboot flash script for Edison: This is rather unbriking script, DFU (luckily) works > def flash_edison(self, repo): > vid = 0x8086 > pid = 0xe005 > expect = "%04x:%04x" % (vid, pid) > self.wait_for_dfu(expect) > u_boot = os.path.join(repo._local_str(), "u-boot-edison.img") > bindir = self.usbboot_xfstk_dir > self.host.exec0( > "xfstk-dldr-solo", "--gpflags", "0x8007", > "--osimage", u_boot, > "--fwdnx", os.path.join(bindir, "edison_dnx_fwr.bin"), > "--fwimage", os.path.join(bindir, "edison_ifwi-dbg-00.bin"), > "--osdnx", os.path.join(bindir, "edison_dnx_osr.bin")) To the topic, any suggestions on how to fix the current U-Boot regression? -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 8:46 PM Andy Shevchenko wrote: > > On Fri, Feb 11, 2022 at 8:31 PM Andy Shevchenko > wrote: > > > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > > Hey all, > > > > > > It's release day and so here's v2022.04-rc1. While there's much in here > > > that needed to come in, there's a few big things outstanding, including > > > but not limited to i.MX and layerscape syncs and further sunxi changes. > > > > > > In terms of a changelog, > > > git log --merges v2022.01..v2022.04-rc1 > > > contains what I've pulled but as always, better PR messages and tags > > > will provide better results here. > > > > > > So we're now looking at regular releases every other Monday, and with > > > final release on April 4th, 2022. Thanks all! > > > > As usual I haven't kept an eye for a while and Edison is completely broken. > > v2021.10 works, this one doesn't. > > > > The symptoms on all kernels I tried (v5.17-rc3, v5.16, v5.15) is that: > > > > [0.852822] PCI host bridge to bus :00 > > [0.853684] pci_bus :00: root bus resource [io 0x-0x] > > [0.854680] pci_bus :00: root bus resource [mem > > 0x-0xf] > > [0.855679] pci_bus :00: No busn resource found for root bus, will > > use [bus 00-ff] > > [0.856700] BUG: kernel NULL pointer dereference, address: > > > > [0.857666] #PF: supervisor read access in kernel mode > > [0.857666] #PF: error_code(0x) - not-present page > > [0.857666] PGD 0 P4D 0 > > [0.857666] Oops: [#1] SMP PTI > > [0.857666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0+ #23 > > [0.857666] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS > > 542 2015.01.21:18.19.48 > > [0.857666] RIP: 0010:pci_read+0x47/0x80 > > ... > > > > Bisection started... > > u-boot((379d3c1fd6aa...)|BISECTING)$ git bisect log > git bisect start > # good: [d637294e264adfeb29f390dfc393106fd4d41b17] Prepare v2022.01 > git bisect good d637294e264adfeb29f390dfc393106fd4d41b17 > # bad: [df887a045a1d726bbd654ef266e5cbe8cc0c2db3] Prepare v2022.04-rc1 > git bisect bad df887a045a1d726bbd654ef266e5cbe8cc0c2db3 > # good: [25711b07ca1dcf73dc41b45ca040dadbcff0fa08] Merge tag > 'dm-pull-13jan22' of https://source.denx.de/u-boot/c > ustodians/u-boot-dm > git bisect good 25711b07ca1dcf73dc41b45ca040dadbcff0fa08 > # good: [16f4d36c7b8b6aeb0374485acb91afee795ccfc9] arm: dts: > rz-g2-beacon-u-boot: Enable pinmux for QSPI > git bisect good 16f4d36c7b8b6aeb0374485acb91afee795ccfc9 > # bad: [e1b7e4ddb6b1a1d0b416facbd0f576dde9c404e6] binman: Add a > bintool implementation for mkimage > git bisect bad e1b7e4ddb6b1a1d0b416facbd0f576dde9c404e6 > # good: [6146cd62aedc4849fec66f10ab0aa57f1dc64b8e] Merge branch > '2022-01-24-assorted-updates' > git bisect good 6146cd62aedc4849fec66f10ab0aa57f1dc64b8e > # bad: [9d2adca8c3e8d195fa4be5acc8c6dfe14933e826] x86: Move > acpi_get_rsdp_addr() ACPI tables to the writer > git bisect bad 9d2adca8c3e8d195fa4be5acc8c6dfe14933e826 > # good: [31c27eb83084e77921b82e7e631ecd6ae8b904da] x86: Use the ACPI > table writer > git bisect good 31c27eb83084e77921b82e7e631ecd6ae8b904da > # bad: [d953137526cce48002ef1e313592d28b66cc9c48] x86: Move SSDT table > to a writer function > git bisect bad d953137526cce48002ef1e313592d28b66cc9c48 > # good: [eacb6d0ba205cae472c46a974fb16fcd783680b1] x86: Move DSDT > table to a writer function > git bisect good eacb6d0ba205cae472c46a974fb16fcd783680b1 > # good: [138d7ece70e7835ffd120da254af1abdb953e6da] x86: Move FADT > table to a writer function > git bisect good 138d7ece70e7835ffd120da254af1abdb953e6da > # bad: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: Move FACP table > into separate functions > git bisect bad 379d3c1fd6aa490b1ad5697525cfc89b615cf25a > # first bad commit: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: > Move FACP table into separate functions > u-boot((379d3c1fd6aa...)|BISECTING)$ For the record, these two acpi: Move MCFG implementation to common lib arch: x86: lib: acpi_table: Fix MCFG entries do not help. > Irony is that I have reviewed it, but that time I was busy and couldn't test. > > > Simon, can you prioritize setting up Edison to make it available for tests? So, I'm open to testing any other suggestions. -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Fri, Feb 11, 2022 at 8:31 PM Andy Shevchenko wrote: > > On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > > Hey all, > > > > It's release day and so here's v2022.04-rc1. While there's much in here > > that needed to come in, there's a few big things outstanding, including > > but not limited to i.MX and layerscape syncs and further sunxi changes. > > > > In terms of a changelog, > > git log --merges v2022.01..v2022.04-rc1 > > contains what I've pulled but as always, better PR messages and tags > > will provide better results here. > > > > So we're now looking at regular releases every other Monday, and with > > final release on April 4th, 2022. Thanks all! > > As usual I haven't kept an eye for a while and Edison is completely broken. > v2021.10 works, this one doesn't. > > The symptoms on all kernels I tried (v5.17-rc3, v5.16, v5.15) is that: > > [0.852822] PCI host bridge to bus :00 > [0.853684] pci_bus :00: root bus resource [io 0x-0x] > [0.854680] pci_bus :00: root bus resource [mem 0x-0xf] > [0.855679] pci_bus :00: No busn resource found for root bus, will use > [bus 00-ff] > [0.856700] BUG: kernel NULL pointer dereference, address: > [0.857666] #PF: supervisor read access in kernel mode > [0.857666] #PF: error_code(0x) - not-present page > [0.857666] PGD 0 P4D 0 > [0.857666] Oops: [#1] SMP PTI > [0.857666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0+ #23 > [0.857666] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS > 542 2015.01.21:18.19.48 > [0.857666] RIP: 0010:pci_read+0x47/0x80 > ... > > Bisection started... u-boot((379d3c1fd6aa...)|BISECTING)$ git bisect log git bisect start # good: [d637294e264adfeb29f390dfc393106fd4d41b17] Prepare v2022.01 git bisect good d637294e264adfeb29f390dfc393106fd4d41b17 # bad: [df887a045a1d726bbd654ef266e5cbe8cc0c2db3] Prepare v2022.04-rc1 git bisect bad df887a045a1d726bbd654ef266e5cbe8cc0c2db3 # good: [25711b07ca1dcf73dc41b45ca040dadbcff0fa08] Merge tag 'dm-pull-13jan22' of https://source.denx.de/u-boot/c ustodians/u-boot-dm git bisect good 25711b07ca1dcf73dc41b45ca040dadbcff0fa08 # good: [16f4d36c7b8b6aeb0374485acb91afee795ccfc9] arm: dts: rz-g2-beacon-u-boot: Enable pinmux for QSPI git bisect good 16f4d36c7b8b6aeb0374485acb91afee795ccfc9 # bad: [e1b7e4ddb6b1a1d0b416facbd0f576dde9c404e6] binman: Add a bintool implementation for mkimage git bisect bad e1b7e4ddb6b1a1d0b416facbd0f576dde9c404e6 # good: [6146cd62aedc4849fec66f10ab0aa57f1dc64b8e] Merge branch '2022-01-24-assorted-updates' git bisect good 6146cd62aedc4849fec66f10ab0aa57f1dc64b8e # bad: [9d2adca8c3e8d195fa4be5acc8c6dfe14933e826] x86: Move acpi_get_rsdp_addr() ACPI tables to the writer git bisect bad 9d2adca8c3e8d195fa4be5acc8c6dfe14933e826 # good: [31c27eb83084e77921b82e7e631ecd6ae8b904da] x86: Use the ACPI table writer git bisect good 31c27eb83084e77921b82e7e631ecd6ae8b904da # bad: [d953137526cce48002ef1e313592d28b66cc9c48] x86: Move SSDT table to a writer function git bisect bad d953137526cce48002ef1e313592d28b66cc9c48 # good: [eacb6d0ba205cae472c46a974fb16fcd783680b1] x86: Move DSDT table to a writer function git bisect good eacb6d0ba205cae472c46a974fb16fcd783680b1 # good: [138d7ece70e7835ffd120da254af1abdb953e6da] x86: Move FADT table to a writer function git bisect good 138d7ece70e7835ffd120da254af1abdb953e6da # bad: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: Move FACP table into separate functions git bisect bad 379d3c1fd6aa490b1ad5697525cfc89b615cf25a # first bad commit: [379d3c1fd6aa490b1ad5697525cfc89b615cf25a] x86: Move FACP table into separate functions u-boot((379d3c1fd6aa...)|BISECTING)$ Irony is that I have reviewed it, but that time I was busy and couldn't test. > Simon, can you prioritize setting up Edison to make it available for tests? -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2022.04-rc1 released
On Mon, Jan 31, 2022 at 05:59:30PM -0500, Tom Rini wrote: > Hey all, > > It's release day and so here's v2022.04-rc1. While there's much in here > that needed to come in, there's a few big things outstanding, including > but not limited to i.MX and layerscape syncs and further sunxi changes. > > In terms of a changelog, > git log --merges v2022.01..v2022.04-rc1 > contains what I've pulled but as always, better PR messages and tags > will provide better results here. > > So we're now looking at regular releases every other Monday, and with > final release on April 4th, 2022. Thanks all! As usual I haven't kept an eye for a while and Edison is completely broken. v2021.10 works, this one doesn't. The symptoms on all kernels I tried (v5.17-rc3, v5.16, v5.15) is that: [0.852822] PCI host bridge to bus :00 [0.853684] pci_bus :00: root bus resource [io 0x-0x] [0.854680] pci_bus :00: root bus resource [mem 0x-0xf] [0.855679] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [0.856700] BUG: kernel NULL pointer dereference, address: [0.857666] #PF: supervisor read access in kernel mode [0.857666] #PF: error_code(0x) - not-present page [0.857666] PGD 0 P4D 0 [0.857666] Oops: [#1] SMP PTI [0.857666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0+ #23 [0.857666] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 [0.857666] RIP: 0010:pci_read+0x47/0x80 ... Bisection started... Simon, can you prioritize setting up Edison to make it available for tests? -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 1/2] binman: Do not pollute source tree when build with `make O=...`
On Thu, Dec 23, 2021 at 7:08 AM Simon Glass wrote: > On Tue, 14 Dec 2021 at 17:33, Simon Glass wrote: > > > > Importing libraries in Python caches the bytecode by default. > > Since we run scripts in source tree it ignores the current directory > > settings, which is $(srctree), and creates cache just in the middle > > of the source tree. Move cache to the current directory. > > > > Signed-off-by: Andy Shevchenko > > --- > > v3: avoided crash (Simon), preserved tree hierarchy > > tools/binman/main.py | 13 - > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > Applied to u-boot-dm/next, thanks! > > I didn't notice this before, but this seems to create files like this: > > ./tools/binman/usr/lib/python3/dist-packages/elftools/common/construct_utils.cpython-39.pyc > > We don't really want to 'recache' the common Python files. Do you > think we should revert this patch, or find another fix? I'm not sure I understand. efitools is not common, it's a separate (non-standard) module and it's cached. -- With Best Regards, Andy Shevchenko
[PATCH v3 2/2] binman: Use less hard coded magic when inserting new PATH
Instead of joining hard coded '..' to the run-time path of the executable,
take just a dirname out of it. Besides that, use $(srctree) where it makes
sense.
Signed-off-by: Andy Shevchenko
---
v3: avoided crash (Simon), reused one level up folder variable
tools/binman/main.py | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/binman/main.py b/tools/binman/main.py
index d19ded491af7..6f5ee4e21db7 100755
--- a/tools/binman/main.py
+++ b/tools/binman/main.py
@@ -21,24 +21,26 @@ our_path = os.path.dirname(os.path.realpath(__file__))
our1_path = os.path.dirname(our_path)
our2_path = os.path.dirname(our1_path)
+# Extract $(srctree) from Kbuild environment, or use relative paths below
+srctree = os.environ.get('srctree', our2_path)
+
#
# Do not pollute source tree with cache files:
# https://stackoverflow.com/a/60024195/2511795
# https://bugs.python.org/issue33499
#
-sys.pycache_prefix = os.path.relpath(our_path, os.environ.get('srctree',
our2_path))
+sys.pycache_prefix = os.path.relpath(our_path, srctree)
# Bring in the patman and dtoc libraries (but don't override the first path
# in PYTHONPATH)
-sys.path.insert(2, os.path.join(our_path, '..'))
+sys.path.insert(2, our1_path)
from patman import test_util
# Bring in the libfdt module
sys.path.insert(2, 'scripts/dtc/pylibfdt')
-sys.path.insert(2, os.path.join(our_path, '../../scripts/dtc/pylibfdt'))
-sys.path.insert(2, os.path.join(our_path,
-'../../build-sandbox_spl/scripts/dtc/pylibfdt'))
+sys.path.insert(2, os.path.join(srctree, 'scripts/dtc/pylibfdt'))
+sys.path.insert(2, os.path.join(srctree,
'build-sandbox_spl/scripts/dtc/pylibfdt'))
# When running under python-coverage on Ubuntu 16.04, the dist-packages
# directories are dropped from the python path. Add them in so that we can find
--
2.33.0
[PATCH v3 1/2] binman: Do not pollute source tree when build with `make O=...`
Importing libraries in Python caches the bytecode by default.
Since we run scripts in source tree it ignores the current directory
settings, which is $(srctree), and creates cache just in the middle
of the source tree. Move cache to the current directory.
Signed-off-by: Andy Shevchenko
---
v3: avoided crash (Simon), preserved tree hierarchy
tools/binman/main.py | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tools/binman/main.py b/tools/binman/main.py
index 8c1e478d54ce..d19ded491af7 100755
--- a/tools/binman/main.py
+++ b/tools/binman/main.py
@@ -16,9 +16,20 @@ import sys
import traceback
import unittest
+# Get the absolute path to this file at run-time
+our_path = os.path.dirname(os.path.realpath(__file__))
+our1_path = os.path.dirname(our_path)
+our2_path = os.path.dirname(our1_path)
+
+#
+# Do not pollute source tree with cache files:
+# https://stackoverflow.com/a/60024195/2511795
+# https://bugs.python.org/issue33499
+#
+sys.pycache_prefix = os.path.relpath(our_path, os.environ.get('srctree',
our2_path))
+
# Bring in the patman and dtoc libraries (but don't override the first path
# in PYTHONPATH)
-our_path = os.path.dirname(os.path.realpath(__file__))
sys.path.insert(2, os.path.join(our_path, '..'))
from patman import test_util
--
2.33.0
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
On Fri, Dec 03, 2021 at 10:29:10PM +0200, Andy Shevchenko wrote:
> On Fri, Dec 03, 2021 at 01:13:12PM -0700, Simon Glass wrote:
...
> Ah, you mean you run it manually and not via `make`.
>
> os.environ.get('srctree', '')
>
> should help I suppose.
I haven't heard back from you, I suppose that the above solves the issue,
I'm about to send v3.
> P.S. What is the 'srcdir' you are referring to all the time?
And please clarify, maybe I missed something, what is the 'srcdir'?
Should I use it instead of 'srctree' or what?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
On Fri, Dec 03, 2021 at 01:13:12PM -0700, Simon Glass wrote:
> On Fri, 3 Dec 2021 at 00:55, Andy Shevchenko
> wrote:
> > On Friday, December 3, 2021, Simon Glass wrote:
> >> On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko
> >> wrote:
...
> >> This look useful, but we cannot rely on 'srcdir' being in the
> >> environment.
> >
> > True and code is aware of that. Nothing needs to be fixed.
>
> What am I missing?
>
> $ binman test
> Traceback (most recent call last):
> File "/home/sglass/bin/binman", line 23, in
> srctree = os.environ['srctree']
> File "/usr/lib/python3.8/os.py", line 675, in __getitem__
> raise KeyError(key) from None
> KeyError: 'srctree'
I see, you mean that you run it when it's not in build tree?
> >> For example, most binman development is done just by
> >> running 'binman test' in the source tre. So perhaps default to the
> >> current directory is 'srcdir' is not set?
Ah, you mean you run it manually and not via `make`.
os.environ.get('srctree', '')
should help I suppose.
P.S. What is the 'srcdir' you are referring to all the time?
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
On Friday, December 3, 2021, Simon Glass wrote: > Hi Andy, > > On Tue, 30 Nov 2021 at 12:04, Andy Shevchenko > wrote: > > > > Importing libraries in Python caches the bytecode by default. > > Since we run scripts in source tree it ignores the current directory > > settings, which is $(srctree), and creates cache just in the middle > > of the source tree. Move cache to the current directory. > > > > Signed-off-by: Andy Shevchenko > > --- > > v2: reused our_path > > tools/binman/main.py | 11 ++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > This look useful, but we cannot rely on 'srcdir' being in the > environment. True and code is aware of that. Nothing needs to be fixed. > > For example, most binman development is done just by > running 'binman test' in the source tre. So perhaps default to the > current directory is 'srcdir' is not set? > > Regards, > Simon > > > > > > diff --git a/tools/binman/main.py b/tools/binman/main.py > > index 8c1e478d54ce..4d8b124c7468 100755 > > --- a/tools/binman/main.py > > +++ b/tools/binman/main.py > > @@ -16,9 +16,18 @@ import sys > > import traceback > > import unittest > > > > +# Get the absolute path to this file at run-time > > +our_path = os.path.dirname(sys.argv[0]) > > + > > +# > > +# Do not pollute source tree with cache files: > > +# https://stackoverflow.com/a/60024195/2511795 > > +# https://bugs.python.org/issue33499 > > +# > > +sys.pycache_prefix = os.path.relpath(our_path, os.environ['srctree']) > > + > > # Bring in the patman and dtoc libraries (but don't override the first > path > > # in PYTHONPATH) > > -our_path = os.path.dirname(os.path.realpath(__file__)) > > sys.path.insert(2, os.path.join(our_path, '..')) > > > > from patman import test_util > > -- > > 2.33.0 > > > -- With Best Regards, Andy Shevchenko
Re: [PATCH 00/40] RFC: rpi: Enable ACPI booting on ARM with Raspberry Pi 4
mode 100644 arch/arm/mach-bcm283x/include/mach/acpi/bcm2836_gpu.h > create mode 100644 arch/arm/mach-bcm283x/include/mach/acpi/bcm2836_pwm.h > create mode 100644 arch/arm/mach-bcm283x/include/mach/acpi/bcm2836_sdhost.h > create mode 100644 arch/arm/mach-bcm283x/include/mach/acpi/bcm2836_sdio.h > create mode 100644 arch/sandbox/include/asm/tables.h > create mode 100644 board/raspberrypi/rpi/acpitables.h > create mode 100644 board/raspberrypi/rpi/acpitables.inf > create mode 100644 board/raspberrypi/rpi/csrt.aslc > create mode 100644 board/raspberrypi/rpi/dbg2miniuart.aslc > create mode 100644 board/raspberrypi/rpi/dbg2pl011.aslc > create mode 100644 board/raspberrypi/rpi/dsdt.asl > create mode 100644 board/raspberrypi/rpi/emmc.asl > create mode 100644 board/raspberrypi/rpi/fadt.aslc > create mode 100644 board/raspberrypi/rpi/gpudevs.asl > create mode 100644 board/raspberrypi/rpi/gtdt.aslc > create mode 100644 board/raspberrypi/rpi/iort.aslc > create mode 100644 board/raspberrypi/rpi/madt.aslc > create mode 100644 board/raspberrypi/rpi/pci.asl > create mode 100644 board/raspberrypi/rpi/pep.asl > create mode 100644 board/raspberrypi/rpi/pep.c > create mode 100644 board/raspberrypi/rpi/pep.h > create mode 100644 board/raspberrypi/rpi/pptt.aslc > create mode 100644 board/raspberrypi/rpi/rhpx.asl > create mode 100644 board/raspberrypi/rpi/rpi4.dsc > create mode 100644 board/raspberrypi/rpi/sdhc.asl > create mode 100644 board/raspberrypi/rpi/spcrminiuart.aslc > create mode 100644 board/raspberrypi/rpi/spcrpl011.aslc > create mode 100644 board/raspberrypi/rpi/ssdtthermal.asl > create mode 100644 board/raspberrypi/rpi/uart.asl > create mode 100644 board/raspberrypi/rpi/xhci.asl > create mode 100644 doc/usage/acpi.rst > create mode 100644 lib/acpi/acpi_writer.c > create mode 100644 lib/acpi/base.c > create mode 100644 lib/acpi/csrt.c > create mode 100644 lib/acpi/dsdt.c > create mode 100644 lib/acpi/facs.c > create mode 100644 lib/acpi/ssdt.c > > -- > 2.34.0.rc2.393.gf8c9666880-goog > -- With Best Regards, Andy Shevchenko
Re: [PATCH 40/40] RFC: rpi: Enable booting with ACPI tables
On Wed, Dec 1, 2021 at 6:15 PM Simon Glass wrote: > > This is only partially implemented and includes RFC patches. > > So far it boots into grub but is unable to read the OS from the USB stick, > presumably because the XHCI SSDT is missing. I would recommend enabling SPCR and then pass `earlycon` to see if it gives anything. Nevertheless, I'm in favour of this series, thanks! For patches 21 and 27 (are they the only ones that touch tangier?) take my Reviewed-by: Andy Shevchenko -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/1] binman: Do not pollute source tree when build with `make O=...`
On Tue, Nov 30, 2021 at 9:06 PM Tom Rini wrote: > On Tue, Nov 30, 2021 at 08:58:25PM +0200, Andy Shevchenko wrote: > > On Tue, Nov 30, 2021 at 8:52 PM Tom Rini wrote: > > > On Tue, Nov 30, 2021 at 09:42:04PM +0300, Andy Shevchenko wrote: > > > > +# > > > > +# Do not pollute source tree with cache files: > > > > +# https://stackoverflow.com/a/60024195/2511795 > > > > +# https://bugs.python.org/issue33499 > > > > +# > > > > +sys.pycache_prefix = os.path.relpath(os.path.dirname(sys.argv[0]), > > > > os.environ['srctree']) > > > > + > > > > # Bring in the patman and dtoc libraries (but don't override the first > > > > path > > > > # in PYTHONPATH) > > > > our_path = os.path.dirname(os.path.realpath(__file__)) > > > > > > Do we need some wrapper around this so it doesn't blow up on older than > > > Python 3.8? > > > > Why does it blow? Some global variables which won't be used by older > > versions. > > Does it? I don't know, I wasn't clear enough, sorry. What happens on > an older python here? Silent ignore is fine. Usually that's the idea that new features are hardly tried to be backward compatible (yes, I know that the history of Python had a lot of counter examples, but still). In any case, that one was never used before. You may try yourself, btw: sys.foobar = "blablabla" -- With Best Regards, Andy Shevchenko
[PATCH v2 1/2] binman: Do not pollute source tree when build with `make O=...`
Importing libraries in Python caches the bytecode by default. Since we run scripts in source tree it ignores the current directory settings, which is $(srctree), and creates cache just in the middle of the source tree. Move cache to the current directory. Signed-off-by: Andy Shevchenko --- v2: reused our_path tools/binman/main.py | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/tools/binman/main.py b/tools/binman/main.py index 8c1e478d54ce..4d8b124c7468 100755 --- a/tools/binman/main.py +++ b/tools/binman/main.py @@ -16,9 +16,18 @@ import sys import traceback import unittest +# Get the absolute path to this file at run-time +our_path = os.path.dirname(sys.argv[0]) + +# +# Do not pollute source tree with cache files: +# https://stackoverflow.com/a/60024195/2511795 +# https://bugs.python.org/issue33499 +# +sys.pycache_prefix = os.path.relpath(our_path, os.environ['srctree']) + # Bring in the patman and dtoc libraries (but don't override the first path # in PYTHONPATH) -our_path = os.path.dirname(os.path.realpath(__file__)) sys.path.insert(2, os.path.join(our_path, '..')) from patman import test_util -- 2.33.0
[PATCH v2 2/2] binman: Use less hard coded magic when inserting new PATH
Instead of joining hard coded '..' to the run-time path of the executable, take just a dirname out of it. Besides that, use $(srctree) where it makes sense. Signed-off-by: Andy Shevchenko --- v2: new patch tools/binman/main.py | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tools/binman/main.py b/tools/binman/main.py index 4d8b124c7468..2b3e58d1aabd 100755 --- a/tools/binman/main.py +++ b/tools/binman/main.py @@ -19,24 +19,26 @@ import unittest # Get the absolute path to this file at run-time our_path = os.path.dirname(sys.argv[0]) +# Extract $(srctree) from Kbuild environment +srctree = os.environ['srctree'] + # # Do not pollute source tree with cache files: # https://stackoverflow.com/a/60024195/2511795 # https://bugs.python.org/issue33499 # -sys.pycache_prefix = os.path.relpath(our_path, os.environ['srctree']) +sys.pycache_prefix = os.path.relpath(our_path, srctree) # Bring in the patman and dtoc libraries (but don't override the first path # in PYTHONPATH) -sys.path.insert(2, os.path.join(our_path, '..')) +sys.path.insert(2, os.path.dirname(our_path)) from patman import test_util # Bring in the libfdt module sys.path.insert(2, 'scripts/dtc/pylibfdt') -sys.path.insert(2, os.path.join(our_path, '../../scripts/dtc/pylibfdt')) -sys.path.insert(2, os.path.join(our_path, -'../../build-sandbox_spl/scripts/dtc/pylibfdt')) +sys.path.insert(2, os.path.join(srctree, 'scripts/dtc/pylibfdt')) +sys.path.insert(2, os.path.join(srctree, 'build-sandbox_spl/scripts/dtc/pylibfdt')) # When running under python-coverage on Ubuntu 16.04, the dist-packages # directories are dropped from the python path. Add them in so that we can find -- 2.33.0
Re: [PATCH v1 1/1] binman: Do not pollute source tree when build with `make O=...`
On Tue, Nov 30, 2021 at 8:52 PM Tom Rini wrote: > On Tue, Nov 30, 2021 at 09:42:04PM +0300, Andy Shevchenko wrote: > > +# > > +# Do not pollute source tree with cache files: > > +# https://stackoverflow.com/a/60024195/2511795 > > +# https://bugs.python.org/issue33499 > > +# > > +sys.pycache_prefix = os.path.relpath(os.path.dirname(sys.argv[0]), > > os.environ['srctree']) > > + > > # Bring in the patman and dtoc libraries (but don't override the first path > > # in PYTHONPATH) > > our_path = os.path.dirname(os.path.realpath(__file__)) > > Do we need some wrapper around this so it doesn't blow up on older than > Python 3.8? Why does it blow? Some global variables which won't be used by older versions. > Looking over the logs, we force 3.8 to be the minimum > version, I think it's 3.6. Which means that we aren't documenting the > minimum version well, and should. But, 3.8 is only 2 years old and I > always get a little itchy around saying we need tools that feel to me to > be super recent still. P.S. scratch above, I have a v2 -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] binman: Do not pollute source tree when build with `make O=...`
Importing libraries in Python caches the bytecode by default. Since we run scripts in source tree it ignores the current directory settings, which is $(srctree), and creates cache just in the middle of the source tree. Move cache to the current directory. Signed-off-by: Andy Shevchenko --- tools/binman/main.py | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/binman/main.py b/tools/binman/main.py index 8c1e478d54ce..d5ab59948ec9 100755 --- a/tools/binman/main.py +++ b/tools/binman/main.py @@ -16,6 +16,13 @@ import sys import traceback import unittest +# +# Do not pollute source tree with cache files: +# https://stackoverflow.com/a/60024195/2511795 +# https://bugs.python.org/issue33499 +# +sys.pycache_prefix = os.path.relpath(os.path.dirname(sys.argv[0]), os.environ['srctree']) + # Bring in the patman and dtoc libraries (but don't override the first path # in PYTHONPATH) our_path = os.path.dirname(os.path.realpath(__file__)) -- 2.33.0
Re: ignore more files in Git?
On Tue, Nov 30, 2021 at 5:28 PM Andy Shevchenko wrote: > On Tue, Nov 30, 2021 at 3:23 PM Tom Rini wrote: > > On Tue, Nov 30, 2021 at 03:06:23PM +0200, Andy Shevchenko wrote: > > > > > Am I doing something wrong? > > > > > > $ git status --ignored > > > On branch edison-acpi > > > Your branch is up to date with 'gh-andy-shev/edison-acpi'. > > > > > > Ignored files: > > > (use "git add -f ..." to include in what will be committed) > > >tools/binman/__pycache__/ > > >tools/binman/etype/__pycache__/ > > >tools/concurrencytest/__pycache__/ > > >tools/dtoc/__pycache__/ > > >tools/patman/__pycache__/ > > > > > > nothing to commit, working tree clean > > > > I don't know? `git status --ignored` shows ignored files and > > __pycache__ is in the top-level .gitignore file. > > These files are products of `make O=...`. There are no issues when I > build inside the tree (dunno why). But I definitely won't build in the > source tree folder. I realized that I might be unclear about the point. The problem here is that the source tree becomes dirty after clear instruction to get all temporary stuff out of the tree folder. -- With Best Regards, Andy Shevchenko
Re: ignore more files in Git?
On Tue, Nov 30, 2021 at 3:23 PM Tom Rini wrote: > > On Tue, Nov 30, 2021 at 03:06:23PM +0200, Andy Shevchenko wrote: > > > Am I doing something wrong? > > > > $ git status --ignored > > On branch edison-acpi > > Your branch is up to date with 'gh-andy-shev/edison-acpi'. > > > > Ignored files: > > (use "git add -f ..." to include in what will be committed) > >tools/binman/__pycache__/ > >tools/binman/etype/__pycache__/ > >tools/concurrencytest/__pycache__/ > >tools/dtoc/__pycache__/ > >tools/patman/__pycache__/ > > > > nothing to commit, working tree clean > > I don't know? `git status --ignored` shows ignored files and > __pycache__ is in the top-level .gitignore file. These files are products of `make O=...`. There are no issues when I build inside the tree (dunno why). But I definitely won't build in the source tree folder. -- With Best Regards, Andy Shevchenko
ignore more files in Git?
Am I doing something wrong? $ git status --ignored On branch edison-acpi Your branch is up to date with 'gh-andy-shev/edison-acpi'. Ignored files: (use "git add -f ..." to include in what will be committed) tools/binman/__pycache__/ tools/binman/etype/__pycache__/ tools/concurrencytest/__pycache__/ tools/dtoc/__pycache__/ tools/patman/__pycache__/ nothing to commit, working tree clean -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 04/11] Convert CONFIG_PHYSMEM to Kconfig
On Thu, Nov 25, 2021 at 2:12 AM Simon Glass wrote: > On Wed, 24 Nov 2021 at 09:33, Andy Shevchenko > wrote: > > > > On Wed, Nov 24, 2021 at 6:28 PM Simon Glass wrote: > > > > > > This converts the following to Kconfig: > > >CONFIG_PHYSMEM > > > > Why? > > Because we want to avoid ad-hoc CONFIG options. I mean why to do this effort if it can be simply removed for good. > > And why my message [1] left unanswered? > > > > [1]: > > https://lore.kernel.org/u-boot/cahp75vcvpvupwkjcufwjcs0roq7woiz_cud57vpzd5hf6se...@mail.gmail.com/T/#u > > Because I have not got to it yet. It can take me a week or more to > catch up on email. I do it in batches. > > We could enable this option always, but it is a bit risky as it > doesn't work on 32-bit machines unless there is an implementation > available. I haven't got this. It's always enabled on x86. And it seems the only user of it. I don't see any benefit of keeping this option. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/1] tools/netconsole: Add support for socat
On Fri, Nov 19, 2021 at 1:29 AM Ferry Toth wrote:
>
> Hi,
>
> Op 17-11-2021 om 18:15 schreef Andy Shevchenko:
> > socat is a very powerful tool to work with socets (and not only)
> > in UNIX systems. Let's add support for it in netconsole.
> >
> > Signed-off-by: Andy Shevchenko
> Tested-by: Ferry Toth
Thanks!
Can thi be applied, please?
> > ---
> > tools/netconsole | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/netconsole b/tools/netconsole
> > index 1a0ef22244e3..155453320f73 100755
> > --- a/tools/netconsole
> > +++ b/tools/netconsole
> > @@ -34,7 +34,7 @@ if [ -z "${ip}" ] || [ -n "$4" ] ; then
> > usage "Invalid number of arguments"
> > fi
> >
> > -for nc in netcat nc ; do
> > +for nc in socat netcat nc ; do
> > type ${nc} >/dev/null 2>&1 && break
> > done
> >
> > @@ -47,6 +47,10 @@ if type ncb 2>/dev/null ; then
> > # see if ncb is in $PATH
> > exec ncb ${board_out_port}
> >
> > +elif [ "${nc}" = "socat" ] ; then
> > + # socat does support broadcast
> > + while ${nc} STDIO "UDP4-LISTEN:${board_out_port}"; do :; done
> > +
> > elif [ -x ${0%/*}/ncb ] ; then
> > # maybe it's in the same dir as the netconsole script
> > exec ${0%/*}/ncb ${board_out_port}
> > @@ -59,5 +63,9 @@ else
> > fi
> > ) &
> > pid=$!
> > -${nc} -u ${ip} ${board_in_port}
> > +if [ "${nc}" = "socat" ] ; then
> > + ${nc} - "UDP4:${ip}:${board_in_port}"
> > +else
> > + ${nc} -u ${ip} ${board_in_port}
> > +fi
> > kill ${pid} 2>/dev/null
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 04/11] Convert CONFIG_PHYSMEM to Kconfig
On Wed, Nov 24, 2021 at 6:28 PM Simon Glass wrote: > > This converts the following to Kconfig: >CONFIG_PHYSMEM Why? And why my message [1] left unanswered? [1]: https://lore.kernel.org/u-boot/cahp75vcvpvupwkjcufwjcs0roq7woiz_cud57vpzd5hf6se...@mail.gmail.com/T/#u -- With Best Regards, Andy Shevchenko
CONFIG_PHYSMEM subject to remove?
Hi! It seems that lib/physmem.c is either not used or used only by sandbox (not sure). Do we need CONFIG_PHYSMEM at all? Note x86 has its own implementation that is always present for all platforms. -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] tools/netconsole: Add support for socat
socat is a very powerful tool to work with socets (and not only)
in UNIX systems. Let's add support for it in netconsole.
Signed-off-by: Andy Shevchenko
---
tools/netconsole | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/netconsole b/tools/netconsole
index 1a0ef22244e3..155453320f73 100755
--- a/tools/netconsole
+++ b/tools/netconsole
@@ -34,7 +34,7 @@ if [ -z "${ip}" ] || [ -n "$4" ] ; then
usage "Invalid number of arguments"
fi
-for nc in netcat nc ; do
+for nc in socat netcat nc ; do
type ${nc} >/dev/null 2>&1 && break
done
@@ -47,6 +47,10 @@ if type ncb 2>/dev/null ; then
# see if ncb is in $PATH
exec ncb ${board_out_port}
+elif [ "${nc}" = "socat" ] ; then
+ # socat does support broadcast
+ while ${nc} STDIO "UDP4-LISTEN:${board_out_port}"; do :; done
+
elif [ -x ${0%/*}/ncb ] ; then
# maybe it's in the same dir as the netconsole script
exec ${0%/*}/ncb ${board_out_port}
@@ -59,5 +63,9 @@ else
fi
) &
pid=$!
-${nc} -u ${ip} ${board_in_port}
+if [ "${nc}" = "socat" ] ; then
+ ${nc} - "UDP4:${ip}:${board_in_port}"
+else
+ ${nc} -u ${ip} ${board_in_port}
+fi
kill ${pid} 2>/dev/null
--
2.33.0
Re: netconsole over USB net not working
On Wed, Nov 10, 2021 at 9:47 PM Andy Shevchenko
wrote:
>
> Hi!
>
> What is the Best Known Method to enable NetConsole over USB ethernet
> gadget on DWC3?
Any insight anyone? v2022.01-rc2 behaves the same way.
It was checked that in USB host mode and external card the netconsole
setup works.
> Currently I have a "blinking" type of network interface (from the host
> side) and it's too hard to understand all the mysterious ways of this
> setup.
>
> I have set std* to "nc,serial" (*) to be able to have the network
> console be set up and running.
>
> *) "serial" is just for the initial boot strap, this is a product
> ready Android tablet that users are not supposed to solder wires on
> its PCB. No need to say that I have another similar device
> (https://lore.kernel.org/u-boot/cahp75vdptu-ththi3erid7rd_tc90fc66aiuvzmnof2ky0j...@mail.gmail.com/T/#u)
> that has no serial interface at all, and I can't do anything about it
> due to lack of support from U-Boot.
>
> Unfortunately it goes this direction (in net_loop() call)
>net_init();
>if (eth_is_on_demand_init()) {
>eth_halt();
>eth_set_current();
>ret = eth_init();
>if (ret < 0) {
>eth_halt();
>return ret;
>}
>
> The problem here is that the gadget timeouts for some reason and of
> course for the default 3 seconds I may not have enough time to set up
> the network on the host side. Moreover, if by luck I manage to achieve
> that, it still doesn't work.
>
> --- net_loop Entry
> Trying usb_ether
> 0
> - 0 'dwc3'
> - found
> using dwc3-gadget, OUT ep2out IN ep2in STATUS ep3in
> MAC de:ad:be:ef:00:01
> HOST MAC de:ad:be:ef:00:00
> ...
> dwc3-generic-peripheral dwc3: Transfer Not Ready while ep0out in state
> 'Data Phase'dwc3-generic-peripheral dwc3:
> Transfer Complete while ep0out in state 'Status Phase'The remote end
> did not respond in time.eth_reset_config
> dwc3-generic-peripheral dwc3: request 36561380 from ep3in completed
> 0/8 ===> -108
> event 00 --> -108
> eth_unbind...
> FAIL
>
> ...and repeat...
>
> Conclusion it is not working at all.
>
> Expectations:
> the USB gadget leaves UDC in state that the host would be able to set
> up the link and the netconsole would be able to send data to it.
>
> How to achieve that?
>
> Alternative: serial function of the composite device. As of today not
> an option — it simply does not exist in the U-Boot. Anybody is working
> on that?
>
> --
> With Best Regards,
> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 1/1] usb: doc: Fix spelling issues in README.usb
On Fri, Nov 12, 2021 at 5:44 PM Marek Vasut wrote: > On 11/12/21 4:37 PM, Andy Shevchenko wrote: > > Fix spelling issues in README.usb. > > I'll let Tom do expert review on this and pick it if that's fine. That will work for me, thanks! > btw as a separate patch, would you be willing to convert this to RST format? Unfortunately this file was a 1 time read to me. In case you saw my message [1] the main topic I'm currently struggling with is USB netconsole enablement. [1]: https://lore.kernel.org/u-boot/CAHp75VcyvKDhgtCKugq9AVN0hS-k4Ckfy-=qc-tbngie9zt...@mail.gmail.com/T/#u -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] usb: doc: Fix spelling issues in README.usb
Fix spelling issues in README.usb. Signed-off-by: Andy Shevchenko --- doc/README.usb | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/doc/README.usb b/doc/README.usb index 05c62c3413c5..650a6daae0a5 100644 --- a/doc/README.usb +++ b/doc/README.usb @@ -18,8 +18,8 @@ How it works: - The USB (at least the USB UHCI) needs a frame list (4k), transfer -descripor and queue headers which are all located in the main memory. -The UHCI allocates every milisecond the PCI bus and reads the current +descriptor and queue headers which are all located in the main memory. +The UHCI allocates every millisecond the PCI bus and reads the current frame pointer. This may cause to crash the OS during boot. So the USB _MUST_ be stopped during OS boot. This is the reason, why the USB is NOT automatically started during start-up. If someone needs the USB @@ -27,10 +27,10 @@ he has to start it and should therefore be aware that he had to stop it before booting the OS. For USB keyboards this can be done by a script which is automatically -started after the U-Boot is up and running. To boot an OS with a an +started after the U-Boot is up and running. To boot an OS with a USB keyboard another script is necessary, which first disables the USB and then executes the boot command. If the boot command fails, -the script can reenable the USB kbd. +the script can re-enable the USB keyboard. Common USB Commands: - usb start: @@ -40,10 +40,10 @@ Common USB Commands: - usb info [dev]: shows all USB infos of the device dev, or of all the devices - usb stop [f]:stops the USB. If f==1 the USB will also stop if - an USB keyboard is assigned as stdin. The stdin + a USB keyboard is assigned as stdin. The stdin is then switched to serial input. Storage USB Commands: -- usb scan:scans the USB for storage devices.The USB must be +- usb scan:scans the USB for storage devices. The USB must be running for this command (usb start) - usb device [dev]: show or set current USB storage device - usb part [dev]: print partition table of one or all USB storage @@ -57,7 +57,7 @@ Storage USB Commands: Config Switches: CONFIG_CMD_USB enables basic USB support and the usb command -CONFIG_USB_UHCIdefines the lowlevel part.A lowlevel part must be defined +CONFIG_USB_UHCIdefines the lowlevel part. A lowlevel part must be defined if using CONFIG_CMD_USB CONFIG_USB_KEYBOARD enables the USB Keyboard CONFIG_USB_STORAGE enables the USB storage devices @@ -124,7 +124,7 @@ bootp To enable USB Host Ethernet in U-Boot, your platform must of course support USB with CONFIG_CMD_USB enabled and working. You will need to -add some config settings to your board config: +add some settings to your board configuration: CONFIG_CMD_USB=y /* the 'usb' interactive command */ CONFIG_USB_HOST_ETHER=y/* Enable USB Ethernet adapters */ @@ -158,7 +158,7 @@ settings should start you off: You can also set the default IP address of your board and the server as well as the default file to load when a 'bootp' command is issued. However note that encoding these individual network settings into a -common exectuable is discouraged, as it leads to potential conflicts, +common executable is discouraged, as it leads to potential conflicts, and all the parameters can either get stored in the board's external environment, or get obtained from the bootp server if not set. @@ -166,7 +166,6 @@ environment, or get obtained from the bootp server if not set. #define CONFIG_SERVERIP10.0.0.1 (replace with your value) #define CONFIG_BOOTFILE"uImage" - The 'usb start' command should identify the adapter something like this: CrOS> usb start @@ -211,8 +210,8 @@ MAC Addresses Most Ethernet dongles have a built-in MAC address which is unique in the world. This is important so that devices on the network can be -distinguised from each other. MAC address conflicts are evil and -generally result in strange and eratic behaviour. +distinguished from each other. MAC address conflicts are evil and +generally result in strange and erratic behaviour. Some boards have USB Ethernet chips on-board, and these sometimes do not have an assigned MAC address. In this case it is up to you to assign -- 2.33.0
netconsole over USB net not working
Hi!
What is the Best Known Method to enable NetConsole over USB ethernet
gadget on DWC3?
Currently I have a "blinking" type of network interface (from the host
side) and it's too hard to understand all the mysterious ways of this
setup.
I have set std* to "nc,serial" (*) to be able to have the network
console be set up and running.
*) "serial" is just for the initial boot strap, this is a product
ready Android tablet that users are not supposed to solder wires on
its PCB. No need to say that I have another similar device
(https://lore.kernel.org/u-boot/cahp75vdptu-ththi3erid7rd_tc90fc66aiuvzmnof2ky0j...@mail.gmail.com/T/#u)
that has no serial interface at all, and I can't do anything about it
due to lack of support from U-Boot.
Unfortunately it goes this direction (in net_loop() call)
net_init();
if (eth_is_on_demand_init()) {
eth_halt();
eth_set_current();
ret = eth_init();
if (ret < 0) {
eth_halt();
return ret;
}
The problem here is that the gadget timeouts for some reason and of
course for the default 3 seconds I may not have enough time to set up
the network on the host side. Moreover, if by luck I manage to achieve
that, it still doesn't work.
--- net_loop Entry
Trying usb_ether
0
- 0 'dwc3'
- found
using dwc3-gadget, OUT ep2out IN ep2in STATUS ep3in
MAC de:ad:be:ef:00:01
HOST MAC de:ad:be:ef:00:00
...
dwc3-generic-peripheral dwc3: Transfer Not Ready while ep0out in state
'Data Phase'dwc3-generic-peripheral dwc3:
Transfer Complete while ep0out in state 'Status Phase'The remote end
did not respond in time.eth_reset_config
dwc3-generic-peripheral dwc3: request 36561380 from ep3in completed
0/8 ===> -108
event 00 --> -108
eth_unbind...
FAIL
...and repeat...
Conclusion it is not working at all.
Expectations:
the USB gadget leaves UDC in state that the host would be able to set
up the link and the netconsole would be able to send data to it.
How to achieve that?
Alternative: serial function of the composite device. As of today not
an option — it simply does not exist in the U-Boot. Anybody is working
on that?
--
With Best Regards,
Andy Shevchenko
[PATCH v1 1/2] hexdump: Introduce debug APIs
debug_hex_dump() and debug_hex_dump_bytes() conditionally print
the dump based on DEBUG definition.
Signed-off-by: Andy Shevchenko
---
include/hexdump.h | 4
lib/hexdump.c | 60 ---
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/include/hexdump.h b/include/hexdump.h
index f2ca4793d699..390af4c8da1e 100644
--- a/include/hexdump.h
+++ b/include/hexdump.h
@@ -147,6 +147,8 @@ int hex_dump_to_buffer(const void *buf, size_t len, int
rowsize, int groupsize,
*/
int print_hex_dump(const char *prefix_str, int prefix_type, int rowsize,
int groupsize, const void *buf, size_t len, bool ascii);
+int debug_hex_dump(const char *prefix_str, int prefix_type, int rowsize,
+ int groupsize, const void *buf, size_t len, bool ascii);
/**
* print_hex_dump_bytes - shorthand form of print_hex_dump() with default
params
@@ -162,5 +164,7 @@ int print_hex_dump(const char *prefix_str, int prefix_type,
int rowsize,
*/
void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
const void *buf, size_t len);
+void debug_hex_dump_bytes(const char *prefix_str, int prefix_type,
+ const void *buf, size_t len);
#endif /* HEXDUMP_H */
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 149c93ead8b8..39c9e86649a0 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -125,8 +125,9 @@ overflow1:
return ascii ? ascii_column + len : (groupsize * 2 + 1) * ngroups - 1;
}
-int print_hex_dump(const char *prefix_str, int prefix_type, int rowsize,
- int groupsize, const void *buf, size_t len, bool ascii)
+static int do_print_hex_dump(const char *prefix_str, int prefix_type, int
rowsize,
+int groupsize, const void *buf, size_t len, bool
ascii,
+bool dbg)
{
const u8 *ptr = buf;
int i, linelen, remaining = len;
@@ -146,15 +147,27 @@ int print_hex_dump(const char *prefix_str, int
prefix_type, int rowsize,
switch (prefix_type) {
case DUMP_PREFIX_ADDRESS:
- printf("%s%0*lx: %s\n", prefix_str,
- IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8,
- (ulong)map_to_sysmem(ptr) + i, linebuf);
+ if (dbg) {
+ debug("%s%0*lx: %s\n", prefix_str,
+ IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8,
+ (ulong)map_to_sysmem(ptr) + i, linebuf);
+ } else }
+ printf("%s%0*lx: %s\n", prefix_str,
+ IS_ENABLED(CONFIG_PHYS_64BIT) ? 16 : 8,
+ (ulong)map_to_sysmem(ptr) + i, linebuf);
+ }
break;
case DUMP_PREFIX_OFFSET:
- printf("%s%.8x: %s\n", prefix_str, i, linebuf);
+ if (dbg)
+ debug("%s%.8x: %s\n", prefix_str, i, linebuf);
+ else
+ printf("%s%.8x: %s\n", prefix_str, i, linebuf);
break;
default:
- printf("%s%s\n", prefix_str, linebuf);
+ if (dbg)
+ debug("%s%s\n", prefix_str, linebuf);
+ else
+ printf("%s%s\n", prefix_str, linebuf);
break;
}
if (!IS_ENABLED(CONFIG_SPL_BUILD) && ctrlc())
@@ -164,10 +177,30 @@ int print_hex_dump(const char *prefix_str, int
prefix_type, int rowsize,
return 0;
}
+int print_hex_dump(const char *prefix_str, int prefix_type, int rowsize,
+ int groupsize, const void *buf, size_t len, bool ascii)
+{
+ return do_print_hex_dump(prefix_str, prefix_type, rowsize, groupsize,
+buf, len, ascii, false);
+}
+
+int debug_hex_dump(const char *prefix_str, int prefix_type, int rowsize,
+ int groupsize, const void *buf, size_t len, bool ascii)
+{
+ return do_print_hex_dump(prefix_str, prefix_type, rowsize, groupsize,
+buf, len, ascii, true);
+}
+
void print_hex_dump_bytes(const char *prefix_str, int prefix_type,
const void *buf, size_t len)
{
- print_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true);
+ do_print_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true,
false);
+}
+
+void debug_hex_dump_bytes(const char *prefix_str, int prefix_type,
+ const void *buf, size_t len)
+{
+ do_print_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true, true);
}
#else
[PATCH v1 2/2] x86: scu: Add a few debug messages to the driver
For some devices that have slightly different firmware implementation
it's good to see what's going on when communicating with the SCU. Add
a few debug messages for that purpose.
Signed-off-by: Andy Shevchenko
---
arch/x86/lib/scu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/lib/scu.c b/arch/x86/lib/scu.c
index 90ef239bcd3d..c7274e064647 100644
--- a/arch/x86/lib/scu.c
+++ b/arch/x86/lib/scu.c
@@ -11,6 +11,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -48,6 +49,7 @@ struct scu {
*/
static void scu_ipc_send_command(struct ipc_regs *regs, u32 cmd)
{
+ debug("%s(): 0x%08x\n", __func__, cmd);
writel(cmd, >cmd);
}
@@ -92,12 +94,18 @@ static int scu_ipc_cmd(struct ipc_regs *regs, u32 cmd, u32
sub,
for (i = 0; i < inlen; i++)
writel(*in++, >wbuf[i]);
+ debug_hex_dump("SCU in", DUMP_PREFIX_OFFSET, 16, 4, in, inlen * 4,
false);
+
scu_ipc_send_command(regs, (inlen << 16) | (sub << 12) | cmd);
err = scu_ipc_check_status(regs);
if (!err) {
+ u32 *buf = out;
+
for (i = 0; i < outlen; i++)
*out++ = readl(>rbuf[i]);
+
+ debug_hex_dump("SCU out", DUMP_PREFIX_OFFSET, 16, 4, buf,
outlen * 4, false);
}
return err;
--
2.33.0
[PATCH v2 2/2] image: Explicitly declare do_bdinfo()
Compiler is not happy: common/image-board.c: In function ‘boot_get_kbd’: common/image-board.c:902:17: warning: implicit declaration of function ‘do_bdinfo’ [-Wimplicit-function-declaration] 902 | do_bdinfo(NULL, 0, 0, NULL); | ^ Move the forward declaration to a header. Signed-off-by: Andy Shevchenko --- v2: dropped ifdeffery and extern (Simon), included header to the users common/image-board.c | 1 + common/image.c | 6 +- include/init.h | 2 ++ 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/common/image-board.c b/common/image-board.c index ddf30c67302e..bf8817165cab 100644 --- a/common/image-board.c +++ b/common/image-board.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include diff --git a/common/image.c b/common/image.c index 3fa60b582796..5ef15c45d286 100644 --- a/common/image.c +++ b/common/image.c @@ -9,6 +9,7 @@ #ifndef USE_HOSTCC #include #include +#include #include #include #include @@ -29,11 +30,6 @@ #include #include -#ifdef CONFIG_CMD_BDI -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, -char *const argv[]); -#endif - DECLARE_GLOBAL_DATA_PTR; /* Set this if we have less than 4 MB of malloc() space */ diff --git a/include/init.h b/include/init.h index c781789e367e..f2cd46dead04 100644 --- a/include/init.h +++ b/include/init.h @@ -332,6 +332,8 @@ void bdinfo_print_mhz(const char *name, unsigned long hz); /* Show arch-specific information for the 'bd' command */ void arch_print_bdinfo(void); +int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]); + #endif /* __ASSEMBLY__ */ /* Put only stuff here that the assembler can digest */ -- 2.33.0
[PATCH v2 1/2] image: Fix typo in boot_get_kbd()
After the commit 4ed37abc49c2 ("image: Remove ifdefs around
image_setup_linux() el at"):
common/image-board.c: In function ‘boot_get_kbd’:
common/image-board.c:902:17: error: expected ‘)’ before ‘do_bdinfo’
902 | do_bdinfo(NULL, 0, 0, NULL);
| ^
common/image-board.c:901:12: note: to match this ‘(’
901 | if (IS_ENABLED(CONFIG_CMD_BDI)
|^
common/image-board.c:906:1: error: expected expression before ‘}’ token
906 | }
| ^
common/image-board.c:906:1: warning: control reaches end of non-void function
[-Wreturn-type]
906 | }
| ^
Fix obvious typo.
Fixes: 4ed37abc49c2 ("image: Remove ifdefs around image_setup_linux() el at")
Signed-off-by: Andy Shevchenko
Reviewed-by: Simon Glass
---
v2: added tag (Simon)
common/image-board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/image-board.c b/common/image-board.c
index e7660352e96a..ddf30c67302e 100644
--- a/common/image-board.c
+++ b/common/image-board.c
@@ -898,7 +898,7 @@ int boot_get_kbd(struct lmb *lmb, struct bd_info **kbd)
debug("## kernel board info at 0x%08lx\n", (ulong)*kbd);
#if defined(DEBUG)
- if (IS_ENABLED(CONFIG_CMD_BDI)
+ if (IS_ENABLED(CONFIG_CMD_BDI))
do_bdinfo(NULL, 0, 0, NULL);
#endif
--
2.33.0
Re: [PATCH v1 2/2] image: Explicitly declare do_bdinfo()
On Sun, Nov 7, 2021 at 6:43 PM Simon Glass wrote: > On Sat, 6 Nov 2021 at 01:59, Andy Shevchenko > wrote: > > On Saturday, November 6, 2021, Simon Glass wrote: > >> On Fri, 5 Nov 2021 at 14:10, Andy Shevchenko > >> wrote: > >> > > >> > Compiler is not happy: > >> > > >> > common/image-board.c: In function ‘boot_get_kbd’: > >> > common/image-board.c:902:17: warning: implicit declaration of function > >> > ‘do_bdinfo’ [-Wimplicit-function-declaration] > >> > 902 | do_bdinfo(NULL, 0, 0, NULL); > >> > | ^ > >> > > >> > Move the forward declaration to a header. > >> > > >> > Signed-off-by: Andy Shevchenko > >> > --- > >> > common/image.c | 5 - > >> > include/init.h | 5 + > >> > 2 files changed, 5 insertions(+), 5 deletions(-) > >> > > >> > diff --git a/common/image.c b/common/image.c > >> > index 3fa60b582796..57bf86278149 100644 > >> > --- a/common/image.c > >> > +++ b/common/image.c > >> > @@ -29,11 +29,6 @@ > >> > #include > >> > #include > >> > > >> > -#ifdef CONFIG_CMD_BDI > >> > -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > >> > -char *const argv[]); > >> > -#endif > >> > - > >> > DECLARE_GLOBAL_DATA_PTR; > >> > > >> > /* Set this if we have less than 4 MB of malloc() space */ > >> > diff --git a/include/init.h b/include/init.h > >> > index c781789e367e..37ca9905414f 100644 > >> > --- a/include/init.h > >> > +++ b/include/init.h > >> > @@ -332,6 +332,11 @@ void bdinfo_print_mhz(const char *name, unsigned > >> > long hz); > >> > /* Show arch-specific information for the 'bd' command */ > >> > void arch_print_bdinfo(void); > >> > > >> > +#if defined(CONFIG_CMD_BDI) > >> > +extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > >> > +char *const argv[]); > >> > +#endif > >> > >> Can we drop the #if..#endif? > > > > > > No, AFAICT, but you can do it later somehow. Currently this fixes a warning. > > I mean drop the #if line and the #endif line. And we will have a dangling prototype when !CONFIG_CMD_BDI ? Is it okay? > We try to avoid this > sort that things like IS_ENABLED() work. -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 2/2] image: Explicitly declare do_bdinfo()
On Saturday, November 6, 2021, Simon Glass wrote: > Hi Andy, > > On Fri, 5 Nov 2021 at 14:10, Andy Shevchenko > wrote: > > > > Compiler is not happy: > > > > common/image-board.c: In function ‘boot_get_kbd’: > > common/image-board.c:902:17: warning: implicit declaration of function > ‘do_bdinfo’ [-Wimplicit-function-declaration] > > 902 | do_bdinfo(NULL, 0, 0, NULL); > > | ^ > > > > Move the forward declaration to a header. > > > > Signed-off-by: Andy Shevchenko > > --- > > common/image.c | 5 - > > include/init.h | 5 + > > 2 files changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/common/image.c b/common/image.c > > index 3fa60b582796..57bf86278149 100644 > > --- a/common/image.c > > +++ b/common/image.c > > @@ -29,11 +29,6 @@ > > #include > > #include > > > > -#ifdef CONFIG_CMD_BDI > > -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > > -char *const argv[]); > > -#endif > > - > > DECLARE_GLOBAL_DATA_PTR; > > > > /* Set this if we have less than 4 MB of malloc() space */ > > diff --git a/include/init.h b/include/init.h > > index c781789e367e..37ca9905414f 100644 > > --- a/include/init.h > > +++ b/include/init.h > > @@ -332,6 +332,11 @@ void bdinfo_print_mhz(const char *name, unsigned > long hz); > > /* Show arch-specific information for the 'bd' command */ > > void arch_print_bdinfo(void); > > > > +#if defined(CONFIG_CMD_BDI) > > +extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, > > +char *const argv[]); > > +#endif > > Can we drop the #if..#endif? No, AFAICT, but you can do it later somehow. Currently this fixes a warning. > > > + > > #endif /* __ASSEMBLY__ */ > > /* Put only stuff here that the assembler can digest */ > > > > -- > > 2.33.0 > > > > Regards, > SImon > -- With Best Regards, Andy Shevchenko
[PATCH v1 2/2] image: Explicitly declare do_bdinfo()
Compiler is not happy: common/image-board.c: In function ‘boot_get_kbd’: common/image-board.c:902:17: warning: implicit declaration of function ‘do_bdinfo’ [-Wimplicit-function-declaration] 902 | do_bdinfo(NULL, 0, 0, NULL); | ^ Move the forward declaration to a header. Signed-off-by: Andy Shevchenko --- common/image.c | 5 - include/init.h | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/common/image.c b/common/image.c index 3fa60b582796..57bf86278149 100644 --- a/common/image.c +++ b/common/image.c @@ -29,11 +29,6 @@ #include #include -#ifdef CONFIG_CMD_BDI -extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, -char *const argv[]); -#endif - DECLARE_GLOBAL_DATA_PTR; /* Set this if we have less than 4 MB of malloc() space */ diff --git a/include/init.h b/include/init.h index c781789e367e..37ca9905414f 100644 --- a/include/init.h +++ b/include/init.h @@ -332,6 +332,11 @@ void bdinfo_print_mhz(const char *name, unsigned long hz); /* Show arch-specific information for the 'bd' command */ void arch_print_bdinfo(void); +#if defined(CONFIG_CMD_BDI) +extern int do_bdinfo(struct cmd_tbl *cmdtp, int flag, int argc, +char *const argv[]); +#endif + #endif /* __ASSEMBLY__ */ /* Put only stuff here that the assembler can digest */ -- 2.33.0
[PATCH v1 1/2] image: Fix typo in boot_get_kbd()
After the commit 4ed37abc49c2 ("image: Remove ifdefs around
image_setup_linux() el at"):
common/image-board.c: In function ‘boot_get_kbd’:
common/image-board.c:902:17: error: expected ‘)’ before ‘do_bdinfo’
902 | do_bdinfo(NULL, 0, 0, NULL);
| ^
common/image-board.c:901:12: note: to match this ‘(’
901 | if (IS_ENABLED(CONFIG_CMD_BDI)
|^
common/image-board.c:906:1: error: expected expression before ‘}’ token
906 | }
| ^
common/image-board.c:906:1: warning: control reaches end of non-void function
[-Wreturn-type]
906 | }
| ^
Fix obvious typo.
Fixes: 4ed37abc49c2 ("image: Remove ifdefs around image_setup_linux() el at")
Signed-off-by: Andy Shevchenko
Revert "image: Partially revert too aggressive ifdeferry removal"
This reverts commit 84631af9d0454ff8252c1aebb1e9c232b8077692.
Signed-off-by: Andy Shevchenko
---
common/image-board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/image-board.c b/common/image-board.c
index e7660352e96a..ddf30c67302e 100644
--- a/common/image-board.c
+++ b/common/image-board.c
@@ -898,7 +898,7 @@ int boot_get_kbd(struct lmb *lmb, struct bd_info **kbd)
debug("## kernel board info at 0x%08lx\n", (ulong)*kbd);
#if defined(DEBUG)
- if (IS_ENABLED(CONFIG_CMD_BDI)
+ if (IS_ENABLED(CONFIG_CMD_BDI))
do_bdinfo(NULL, 0, 0, NULL);
#endif
--
2.33.0
[PATCH v1 1/2] x86: tangier: pinmux: Move is_protected assignment closer to its user
Move is_protected assignment closer to its user. This increases readability and makes maintenance easier. Signed-off-by: Andy Shevchenko --- arch/x86/cpu/tangier/pinmux.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c index 8385167b2b6b..883860f75e28 100644 --- a/arch/x86/cpu/tangier/pinmux.c +++ b/arch/x86/cpu/tangier/pinmux.c @@ -162,8 +162,6 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node) u32 mask; int ret; - is_protected = ofnode_read_bool(pin_node, "protected"); - pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1); if (pad_offset == -1) return -EINVAL; @@ -178,6 +176,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node) if (mode & ~mask) return -ENOTSUPP; + is_protected = ofnode_read_bool(pin_node, "protected"); if (is_protected) ret = mrfld_pinconfig_protected(pad_offset, mask, mode); else -- 2.33.0
[PATCH v1 2/2] x86: tangier: pinmux: Move error message to the caller
Move error message to the caller of mrfld_pinconfig*() in order
to unify them in the future.
Signed-off-by: Andy Shevchenko
---
arch/x86/cpu/tangier/pinmux.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
index 883860f75e28..7b2c35fbf794 100644
--- a/arch/x86/cpu/tangier/pinmux.c
+++ b/arch/x86/cpu/tangier/pinmux.c
@@ -117,13 +117,7 @@ static int mrfld_pinconfig_protected(unsigned int pin, u32
mask, u32 bits)
debug("scu: v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
v, (u32)bufcfg, bits, mask, bufcfg);
- ret = scu_ipc_raw_command(IPCMSG_INDIRECT_WRITE, 0, , 4,
- NULL, 0, (u32)bufcfg, 0);
- if (ret)
- pr_err("Failed to set mode via SCU for pin %u (%d)\n",
- pin, ret);
-
- return ret;
+ return scu_ipc_raw_command(IPCMSG_INDIRECT_WRITE, 0, , 4, NULL, 0,
(u32)bufcfg, 0);
}
static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
@@ -181,6 +175,8 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
else
ret = mrfld_pinconfig(pad_offset, mask, mode);
+ if (ret)
+ pr_err("Failed to set mode for pin %u (%d)\n", pad_offset, ret);
return ret;
}
--
2.33.0
[PATCH v2 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
We would need to quirk out the Card Detect case and for that we allow
configuring the SD/SDIO family of pins.
Signed-off-by: Andy Shevchenko
Reviewed-by: Bin Meng
---
v2: added tag, promised to deduplicate the code in the future (Bin)
arch/x86/cpu/tangier/pinmux.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
index acf97e3af51d..8385167b2b6b 100644
--- a/arch/x86/cpu/tangier/pinmux.c
+++ b/arch/x86/cpu/tangier/pinmux.c
@@ -37,8 +37,9 @@ struct mrfld_family {
.npins = (e) - (s) + 1, \
}
-/* Now we only support I2C family of pins */
+/* Now we only support SD/SDIO and I2C families of pins */
static struct mrfld_family mrfld_families[] = {
+ MRFLD_FAMILY(3, 37, 56),
MRFLD_FAMILY(7, 101, 114),
};
@@ -125,6 +126,34 @@ static int mrfld_pinconfig_protected(unsigned int pin, u32
mask, u32 bits)
return ret;
}
+static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
+{
+ struct mrfld_pinctrl *pinctrl;
+ struct udevice *dev;
+ void __iomem *bufcfg;
+ u32 v, value;
+ int ret;
+
+ ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
+ if (ret)
+ return ret;
+
+ pinctrl = dev_get_priv(dev);
+
+ bufcfg = mrfld_get_bufcfg(pinctrl, pin);
+ if (!bufcfg)
+ return -EINVAL;
+
+ value = readl(bufcfg);
+ v = (value & ~mask) | (bits & mask);
+ writel(v, bufcfg);
+
+ debug("v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
+ v, (u32)bufcfg, bits, mask, bufcfg);
+
+ return 0;
+}
+
static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
{
bool is_protected;
@@ -133,10 +162,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
u32 mask;
int ret;
- /* For now we only support just protected Family of pins */
is_protected = ofnode_read_bool(pin_node, "protected");
- if (!is_protected)
- return -ENOTSUPP;
pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1);
if (pad_offset == -1)
@@ -152,7 +178,10 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
if (mode & ~mask)
return -ENOTSUPP;
- ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ if (is_protected)
+ ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ else
+ ret = mrfld_pinconfig(pad_offset, mask, mode);
return ret;
}
--
2.33.0
[PATCH v2 2/2] x86: edison: Don't take SD card detect pin into consideration
There are two PCB designs in the wild which use the opposite
signaling for SD card detection. This makes U-Boot working
in one case and failing in the other. Quirk this out by
disconnecting SD card detection pin from the PCB by switching
it to mode 3. In the disconnected state the read value is always
the same and inverted to what we are expecting in the code.
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
Signed-off-by: Andy Shevchenko
Reviewed-by: Bin Meng
---
v2: added tag, updated commit message and comments in DTS (Bin)
arch/x86/dts/edison.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 2c8cf6c07102..b3658b8c3049 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -94,6 +94,12 @@
sdcard: mmc@ff3fa000 {
compatible = "intel,sdhci-tangier";
reg = <0xff3fa000 0x1000>;
+ /*
+* In the disconnected state of the SD Card Detection pin
+* the read value is always the same and inverted to what
+* we are expecting in the code.
+*/
+ cd-inverted;
};
pmu: power@ff00b000 {
@@ -131,6 +137,17 @@
compatible = "intel,pinctrl-tangier";
reg = <0xff0c 0x8000>;
+ /*
+* Disconnect SD card detection pin, so it won't affect
+* the reality on two different PCB designs where it's
+* using the opposite signaling: Edison/Arduino uses
+* Active Low, while SparkFun went with Active High.
+*/
+ sd_cd@0 {
+ pad-offset = <37>;
+ mode-func = <3>;
+ };
+
/*
* Initial configuration came from the firmware.
* Which quite likely has been used in the phones, where I2C #8,
--
2.33.0
Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
On Wed, Oct 27, 2021 at 06:10:59PM +0800, Bin Meng wrote: > On Wed, Oct 27, 2021 at 4:52 PM Andy Shevchenko > wrote: > > On Wed, Oct 27, 2021 at 5:57 AM Bin Meng wrote: > > > On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko > > > wrote: ... > > > > + cd-inverted; > > > > > > So I wonder how sd card ever worked without the "cd-inverted" property? > > > > TL;DR: it worked on one PCB design and did not work on the other. When > > we disconnect the pin the read value is always the same and inverted > > to what we expected in the code. > > Great. That explains. Although I read the below comments a couple of > times, it just did not come to my head that "when we disconnect the > pin the read value is always the same and inverted to what we expected > in the code." Sure! > > Have you read the commit message and the comment below? Have you read > > the bug report? > > Yes, but it's not crystal clear hence the ask. So maybe we can update > the comments to make such clearer? Yep, I'll do it for the next version. > > > > + /* > > > > +* Disconnect SD card detect, so it won't affect the > > > > reality > > > > +* on two different PCB designs where it's using the > > > > opposite > > > > +* signaling: Edison/Arduino uses Active Low, while > > > > SparkFun > > > > +* went with Active High. > > > > +*/ > > FWIW, > Reviewed-by: Bin Meng Thanks! -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
On Wed, Oct 27, 2021 at 1:14 PM Bin Meng wrote: > On Wed, Oct 27, 2021 at 4:54 PM Andy Shevchenko > wrote: > > On Wed, Oct 27, 2021 at 5:49 AM Bin Meng wrote: > > > On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko > > > wrote: ... > > > This function can be consolidated with mrfld_pinconfig_protected(), > > > ie: updating mrfld_pinconfig_protected() to call mrfld_pinconfig(). > > > > Can it be done in a separate patch? This is a fix related and tested, > > it will take time to retest this by all parties. > > Sure please send a follow-up patch when you are free. I will do it later on. > Reviewed-by: Bin Meng Thanks! -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
On Wed, Oct 27, 2021 at 5:49 AM Bin Meng wrote:
> On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
> wrote:
> >
> > We would need to quirk out Card Detect case and for that we allow
> > configuring SD/SDIO family of pins.
...
> > +static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
> > +{
> This function can be consolidated with mrfld_pinconfig_protected(),
> ie: updating mrfld_pinconfig_protected() to call mrfld_pinconfig().
Can it be done in a separate patch? This is a fix related and tested,
it will take time to retest this by all parties.
> > +}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
On Wed, Oct 27, 2021 at 5:57 AM Bin Meng wrote:
> On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
> wrote:
> >
> > There are two PCB designs in the wild which use the opposite
> > signaling for SD card detect. This makes U-Boot working in one case
> > and failing in the other. Quirk this out by disconnecting SD card
> > detect pin from the PCB by switching to mode 3.
> >
> > BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
...
> > sdcard: mmc@ff3fa000 {
> > compatible = "intel,sdhci-tangier";
> > reg = <0xff3fa000 0x1000>;
> > + cd-inverted;
>
> So I wonder how sd card ever worked without the "cd-inverted" property?
TL;DR: it worked on one PCB design and did not work on the other. When
we disconnect the pin the read value is always the same and inverted
to what we expected in the code.
Have you read the commit message and the comment below? Have you read
the bug report?
> > + /*
> > +* Disconnect SD card detect, so it won't affect the reality
> > +* on two different PCB designs where it's using the
> > opposite
> > +* signaling: Edison/Arduino uses Active Low, while SparkFun
> > +* went with Active High.
> > +*/
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
On Mon, Oct 25, 2021 at 09:18:56AM -0600, Simon Glass wrote: > On Mon, 25 Oct 2021 at 01:34, Andy Shevchenko > wrote: > > On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > > > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > > > wrote: > > > > > > > > The dsdt.asl is usually combined out of several files that are included > > > > in the main one. Whenever we change the content of any of such files, > > > > build system is not able to recognize them. Hence the easiest way is to > > > > force DSDT rebuild each time we run make. > > > > > Ick. Since it uses #include, doesn't the dependency generation work with > > > this? > > > > How? > > If you do a sandbox build you will see this file: > > arch/sandbox/dts/.sandbox.dtb.cmd > > It contains the dependencies used to compile the device tree. Can we > use the same mechanism? There is a .cmd file for the dsdt file but it > does not seem to have the correct contents. A spent more than couple of hours to fight with `make` and failed. Maybe you can improve the below (it still rebuilds always) >From 2fa93fdc376b60c69ff1a2e9ffd16d30702c6399 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Wed, 20 Oct 2021 15:21:49 +0300 Subject: [PATCH 1/1] Makefile.lib: Always rebuild DSDT The dsdt.asl is usually combined out of several files that are included in the main one. Whenever we change the content of any of such files, build system is not able to recognize them. Hence the easiest way is to force DSDT rebuild each time we run make. Signed-off-by: Andy Shevchenko --- scripts/Makefile.lib | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index ac270844c2e1..939f99dee9f9 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -432,16 +432,21 @@ CFLAGS_REMOVE_efi_freestanding.o := $(LTO_CFLAGS) # renamed to dsdt.c for consumption by the build system. ASL_TMP = $(patsubst %.c,%.asl.tmp,$@) +asl_cpp_flags = -Wp,-MD,$(depfile) -nostdinc \ +$(UBOOTINCLUDE)\ +-I$(srctree)/include \ +-D__ASSEMBLY__ \ +-undef -D__ACPI__ + quiet_cmd_acpi_c_asl= ASL $< cmd_acpi_c_asl= \ - $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -D__ACPI__ \ - -P $(UBOOTINCLUDE) -o $(ASL_TMP) $< && \ + $(HOSTCC) -P -E $(asl_cpp_flags) -x assembler-with-cpp -o $(ASL_TMP) $< && \ iasl -p $@ -tc $(ASL_TMP) $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \ - mv $(patsubst %.c,%.hex,$@) $@ + mv $(patsubst %.c,%.hex,$@) $@ && \ + sed -i -e "s,dsdt_aml_code,AmlCode," $@ -$(obj)/dsdt.c:$(src)/dsdt.asl - $(call cmd,acpi_c_asl) - $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ +$(obj)/dsdt.c:$(src)/dsdt.asl FORCE + $(call if_changed_dep,acpi_c_asl) # Bzip2 # --- -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
On Sun, Oct 24, 2021 at 11:00 PM Simon Glass wrote: > On Wed, 20 Oct 2021 at 06:37, Andy Shevchenko > wrote: > > > > The dsdt.asl is usually combined out of several files that are included > > in the main one. Whenever we change the content of any of such files, > > build system is not able to recognize them. Hence the easiest way is to > > force DSDT rebuild each time we run make. > Ick. Since it uses #include, doesn't the dependency generation work with this? How? -- With Best Regards, Andy Shevchenko
Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
On Thu, Oct 21, 2021 at 12:41 AM Ferry Toth wrote: > Op 15-10-2021 om 19:11 schreef Andy Shevchenko: > > There are two PCB designs in the wild which use the opposite > > signaling for SD card detect. This makes U-Boot working in one case > > and failing in the other. Quirk this out by disconnecting SD card > > detect pin from the PCB by switching to mode 3. > > > Tested-by: Ferry Toth @ Intel Edison-Arduino board Thank you, Ferry. And AFAICS the original reporter had confirmed that this fixes the issue on his SparkFun board. Bin, can this be reviewed and applied? -- With Best Regards, Andy Shevchenko
[PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object
There is no point to use Method() for the constant.
Replace it with Name() defined object. For the _STA
case it saves 3 bytes per each entry.
Before: 2881
After: 2833
Signed-off-by: Andy Shevchenko
---
.../asm/arch-tangier/acpi/southcluster.asl| 81 ---
1 file changed, 17 insertions(+), 64 deletions(-)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index a8852f8202c7..4a7c85426182 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -123,10 +123,7 @@ Device (PCI0)
}
})
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
}
Device (SDHC)
@@ -138,10 +135,7 @@ Device (PCI0)
})
Name (PSTS, Zero)
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Method (_PS3, 0, NotSerialized)
{
@@ -168,10 +162,7 @@ Device (PCI0)
GPIO
})
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Method (_RMV, 0, NotSerialized)
{
@@ -203,10 +194,8 @@ Device (PCI0)
Device (BRC2)
{
Name (_ADR, 0x02)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+
+Name (_STA, STA_VISIBLE)
Method (_RMV, 0, NotSerialized)
{
@@ -257,20 +246,14 @@ Device (PCI0)
}
})
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
}
Device (I2C1)
{
Name (_ADR, 0x0008)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (SSCN, Package ()
{
@@ -303,10 +286,7 @@ Device (PCI0)
{
Name (_ADR, 0x00090001)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (SSCN, Package ()
{
@@ -328,10 +308,7 @@ Device (PCI0)
{
Name (_ADR, 0x000c)
-Method (_STA)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
@@ -361,10 +338,7 @@ Device (PCI0)
^IPC1.PMIC
})
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Device (RHUB)
{
@@ -404,20 +378,14 @@ Device (PCI0)
{
Name (_ADR, 0x0017)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
}
Device (HSU0)
{
Name (_ADR, 0x00040001)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Device (BTH0)
{
@@ -428,10 +396,7 @@ Device (PCI0)
HSU0
})
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (RBUF, ResourceTemplate()
{
@@ -466,10 +431,7 @@ Device (PCI0)
{
Name (_ADR, 0x0013)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Device (PMIC)
{
@@ -481,10 +443,7 @@ Device (PCI0)
IPC1
})
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (RBUF, ResourceTemplate()
{
@@ -554,10 +513,7 @@ Device (PCI0)
Name (_ADR, 0x0015)
Name (_UID, Zero)
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
Name (RBUF, ResourceTemplate ()
{
@@ -594,8 +550,5 @@ Device (FLIS)
Return (RBUF)
}
-Method (_STA, 0, NotSerialized)
-{
-Return (STA_VISIBLE)
-}
+Name (_STA, STA_VISIBLE)
}
--
2.33.0
[PATCH v1 1/1] Makefile.lib: Always rebuild DSDT
The dsdt.asl is usually combined out of several files that are included in the main one. Whenever we change the content of any of such files, build system is not able to recognize them. Hence the easiest way is to force DSDT rebuild each time we run make. Signed-off-by: Andy Shevchenko --- scripts/Makefile.lib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 07696e86bb54..8c3c893b398a 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -441,7 +441,7 @@ cmd_acpi_c_asl= \ iasl -p $@ -tc $(ASL_TMP) $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \ mv $(patsubst %.c,%.hex,$@) $@ -$(obj)/dsdt.c:$(src)/dsdt.asl +$(obj)/dsdt.c:$(src)/dsdt.asl FORCE $(call cmd,acpi_c_asl) $(Q)sed -i -e "s,dsdt_aml_code,AmlCode," $@ -- 2.33.0
[PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
We would need to quirk out Card Detect case and for that we allow
configuring SD/SDIO family of pins.
Signed-off-by: Andy Shevchenko
---
arch/x86/cpu/tangier/pinmux.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
index acf97e3af51d..8385167b2b6b 100644
--- a/arch/x86/cpu/tangier/pinmux.c
+++ b/arch/x86/cpu/tangier/pinmux.c
@@ -37,8 +37,9 @@ struct mrfld_family {
.npins = (e) - (s) + 1, \
}
-/* Now we only support I2C family of pins */
+/* Now we only support SD/SDIO and I2C families of pins */
static struct mrfld_family mrfld_families[] = {
+ MRFLD_FAMILY(3, 37, 56),
MRFLD_FAMILY(7, 101, 114),
};
@@ -125,6 +126,34 @@ static int mrfld_pinconfig_protected(unsigned int pin, u32
mask, u32 bits)
return ret;
}
+static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
+{
+ struct mrfld_pinctrl *pinctrl;
+ struct udevice *dev;
+ void __iomem *bufcfg;
+ u32 v, value;
+ int ret;
+
+ ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
+ if (ret)
+ return ret;
+
+ pinctrl = dev_get_priv(dev);
+
+ bufcfg = mrfld_get_bufcfg(pinctrl, pin);
+ if (!bufcfg)
+ return -EINVAL;
+
+ value = readl(bufcfg);
+ v = (value & ~mask) | (bits & mask);
+ writel(v, bufcfg);
+
+ debug("v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
+ v, (u32)bufcfg, bits, mask, bufcfg);
+
+ return 0;
+}
+
static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
{
bool is_protected;
@@ -133,10 +162,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
u32 mask;
int ret;
- /* For now we only support just protected Family of pins */
is_protected = ofnode_read_bool(pin_node, "protected");
- if (!is_protected)
- return -ENOTSUPP;
pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1);
if (pad_offset == -1)
@@ -152,7 +178,10 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
if (mode & ~mask)
return -ENOTSUPP;
- ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ if (is_protected)
+ ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
+ else
+ ret = mrfld_pinconfig(pad_offset, mask, mode);
return ret;
}
--
2.33.0
[PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
There are two PCB designs in the wild which use the opposite
signaling for SD card detect. This makes U-Boot working in one case
and failing in the other. Quirk this out by disconnecting SD card
detect pin from the PCB by switching to mode 3.
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
Signed-off-by: Andy Shevchenko
---
arch/x86/dts/edison.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 2c8cf6c07102..04e8a4e457c8 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -94,6 +94,7 @@
sdcard: mmc@ff3fa000 {
compatible = "intel,sdhci-tangier";
reg = <0xff3fa000 0x1000>;
+ cd-inverted;
};
pmu: power@ff00b000 {
@@ -131,6 +132,17 @@
compatible = "intel,pinctrl-tangier";
reg = <0xff0c 0x8000>;
+ /*
+* Disconnect SD card detect, so it won't affect the reality
+* on two different PCB designs where it's using the opposite
+* signaling: Edison/Arduino uses Active Low, while SparkFun
+* went with Active High.
+*/
+ sd_cd@0 {
+ pad-offset = <37>;
+ mode-func = <3>;
+ };
+
/*
* Initial configuration came from the firmware.
* Which quite likely has been used in the phones, where I2C #8,
--
2.33.0
[PATCH v3 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Intel Tangier the SDHCI #2 provides SD card connection.
Add GPIO card detection for it.
Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
Signed-off-by: Andy Shevchenko
Acked-by: Bin Meng
---
v3: basically returned to the content of v2 (pull bias back to none)
since there is nothing special about the signal which is supposed
to be triggered by both edges
.../asm/arch-tangier/acpi/southcluster.asl| 32 +++
1 file changed, 32 insertions(+)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 01077293bb91..41facdde6a3d 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -97,6 +97,38 @@ Device (PCI0)
}
}
+Device (SDHB)
+{
+Name (_ADR, 0x00010002)
+Name (_DEP, Package ()
+{
+GPIO
+})
+
+Name (RBUF, ResourceTemplate()
+{
+GpioInt(Edge, ActiveBoth, SharedAndWake, PullNone, 1,
+"\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 77 }
+})
+
+Method (_CRS, 0, Serialized)
+{
+Return (RBUF)
+}
+
+Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package () { "cd-gpios", Package () { ^SDHB, 0, 0, 0 } },
+}
+})
+
+Method (_STA)
+{
+Return (STA_VISIBLE)
+}
+}
+
Device (SDHC)
{
Name (_ADR, 0x00010003)
--
2.33.0
Re: [PATCH v2 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Fri, Sep 10, 2021 at 09:04:53PM +0300, Andy Shevchenko wrote:
> On Intel Tangier the SDHCI #2 provides SD card connection.
> Add GPIO card detection for it.
>
> Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
> BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
> Signed-off-by: Andy Shevchenko
> Acked-by: Bin Meng
> ---
> v2: switched to pull up bias (WA against some PCBs), added tag (Bin)
It seems I need more testing into all this.
So, please defer for a while (*), I would like to be 100% all these parameters
will work for most of the users.
*) couple of days, perhaps?
--
With Best Regards,
Andy Shevchenko
[PATCH v2 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Intel Tangier the SDHCI #2 provides SD card connection.
Add GPIO card detection for it.
Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
Signed-off-by: Andy Shevchenko
Acked-by: Bin Meng
---
v2: switched to pull up bias (WA against some PCBs), added tag (Bin)
.../asm/arch-tangier/acpi/southcluster.asl| 32 +++
1 file changed, 32 insertions(+)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 01077293bb91..e6bbef108a7b 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -97,6 +97,38 @@ Device (PCI0)
}
}
+Device (SDHB)
+{
+Name (_ADR, 0x00010002)
+Name (_DEP, Package ()
+{
+GPIO
+})
+
+Name (RBUF, ResourceTemplate()
+{
+GpioInt(Edge, ActiveBoth, SharedAndWake, PullUp, 1,
+"\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 77 }
+})
+
+Method (_CRS, 0, Serialized)
+{
+Return (RBUF)
+}
+
+Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package () { "cd-gpios", Package () { ^SDHB, 0, 0, 0 } },
+}
+})
+
+Method (_STA)
+{
+Return (STA_VISIBLE)
+}
+}
+
Device (SDHC)
{
Name (_ADR, 0x00010003)
--
2.33.0
Re: [PATCH v1 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Fri, Sep 10, 2021 at 7:16 PM Bin Meng wrote:
> On Sat, Sep 11, 2021 at 12:07 AM Andy Shevchenko
> wrote:
> > On Fri, Sep 10, 2021 at 2:38 PM Bin Meng wrote:
> > > On Fri, Sep 10, 2021 at 3:59 PM Andy Shevchenko
> > > wrote:
> > > > On Intel Tangier the SDHCI #2 provides SD card connection.
> > > > Add GPIO card detection for it.
> > > >
> > > > Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel
> > > > Tangier")
> > > > BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
> > > > Signed-off-by: Andy Shevchenko
> > > > ---
> > > > .../asm/arch-tangier/acpi/southcluster.asl| 32 +++
> > > > 1 file changed, 32 insertions(+)
> > >
> > > Acked-by: Bin Meng
> >
> > Thanks!
> >
> > I think I need to adjust the IRQ flags, i.e. to put it as Exclusive and
> > Wake.
> > So I'll send a v2, but I'll keep your tag, I hope that's fine.
>
> Sure!
Thinkg more about it. Intel Edison is a DIY-ish module and perhaps not
everybody want to use SD card or (since there are not so many GPIOs
are made out for use) take SD CD exclusively for it. So, I think the
initial intention is better, But what I would change is a bias to be
PullUp dues to some PCB misconfigurations (no external PU resistor).
v2 soon on its way.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Fri, Sep 10, 2021 at 2:38 PM Bin Meng wrote:
>
> On Fri, Sep 10, 2021 at 3:59 PM Andy Shevchenko
> wrote:
> >
> > On Intel Tangier the SDHCI #2 provides SD card connection.
> > Add GPIO card detection for it.
> >
> > Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
> > BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
> > Signed-off-by: Andy Shevchenko
> > ---
> > .../asm/arch-tangier/acpi/southcluster.asl| 32 +++
> > 1 file changed, 32 insertions(+)
> >
>
> Acked-by: Bin Meng
Thanks!
I think I need to adjust the IRQ flags, i.e. to put it as Exclusive and Wake.
So I'll send a v2, but I'll keep your tag, I hope that's fine.
--
With Best Regards,
Andy Shevchenko
[PATCH v1 1/1] x86: tangier: acpi: Add GPIO card detection to SDHCI #2
On Intel Tangier the SDHCI #2 provides SD card connection.
Add GPIO card detection for it.
Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
BugLink: https://github.com/edison-fw/meta-intel-edison/issues/135
Signed-off-by: Andy Shevchenko
---
.../asm/arch-tangier/acpi/southcluster.asl| 32 +++
1 file changed, 32 insertions(+)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index 01077293bb91..41facdde6a3d 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -97,6 +97,38 @@ Device (PCI0)
}
}
+Device (SDHB)
+{
+Name (_ADR, 0x00010002)
+Name (_DEP, Package ()
+{
+GPIO
+})
+
+Name (RBUF, ResourceTemplate()
+{
+GpioInt(Edge, ActiveBoth, SharedAndWake, PullNone, 1,
+"\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 77 }
+})
+
+Method (_CRS, 0, Serialized)
+{
+Return (RBUF)
+}
+
+Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package () { "cd-gpios", Package () { ^SDHB, 0, 0, 0 } },
+}
+})
+
+Method (_STA)
+{
+Return (STA_VISIBLE)
+}
+}
+
Device (SDHC)
{
Name (_ADR, 0x00010003)
--
2.33.0
[PATCH v1 1/1] x86: edison: Mark eMMC non-removable
eMMC is non-removable on Intel Edison board. Fix the DTS accordingly.
Signed-off-by: Andy Shevchenko
---
arch/x86/dts/edison.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 64b622836377..2c8cf6c07102 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -88,6 +88,7 @@
emmc: mmc@ff3fc000 {
compatible = "intel,sdhci-tangier";
reg = <0xff3fc000 0x1000>;
+ non-removable;
};
sdcard: mmc@ff3fa000 {
--
2.33.0
USB endpoints exclusion
Hi! It seems already some of the platforms are using USB endpoints for dedicated purposes (such as debugging). Those endpoints can't be used for anything else (sounds like hw wired). What is the solution in U-Boot (DTS + generic? code) to make this supported? -- With Best Regards, Andy Shevchenko
