[PATCH] x86: chromebook_coral: fix C block comment

[PATCH] x86: chromebook_coral: fix C block comment

[Alistair Delva]

Fix a warning seen when compiling this dts file.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
---
 arch/x86/dts/chromebook_coral.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/dts/chromebook_coral.dts b/arch/x86/dts/chromebook_coral.dts
index f0caaacfee..69a1c1ce29 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -825,6 +825,7 @@
 	 * Refer to EDS-Vol2-22.3
 	 * [14:8] steps of delay for HS400, each 125ps
 	 * [6:0] steps of delay for SDR104/HS200, each 125ps
+	 */
 
 	/*
 	 * EMMC TX DATA Delay 2
-- 
2.30.2

[PATCH] x86: Fix i8254 ifdef include guard

[Alistair Delva]

When building U-Boot with clang, it notices that the i8254.h include
guard does not work correctly due to a typo. Fix it.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
---
 arch/x86/include/asm/i8254.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
index d769daf85d..bb8930338b 100644
--- a/arch/x86/include/asm/i8254.h
+++ b/arch/x86/include/asm/i8254.h
@@ -7,7 +7,7 @@
 /* i8254.h Intel 8254 PIT registers */
 
 #ifndef _ASMI386_I8254_H_
-#define _ASMI386_I8954_H_
+#define _ASMI386_I8254_H_
 
 #define PIT_T0		0x00	/* PIT channel 0 count/status */
 #define PIT_T1		0x01	/* PIT channel 1 count/status */
-- 
2.30.2

Re: [PATCH] x86: Fix i8254 ifdef include guard

[Simon Glass]

On Wed, 20 Oct 2021 at 15:31, Alistair Delva <adelva@google.com> wrote:
>
> When building U-Boot with clang, it notices that the i8254.h include
> guard does not work correctly due to a typo. Fix it.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  arch/x86/include/asm/i8254.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH] x86: Fix i8254 ifdef include guard

[Bin Meng]

On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva <adelva@google.com> wrote:
>
> When building U-Boot with clang, it notices that the i8254.h include
> guard does not work correctly due to a typo. Fix it.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  arch/x86/include/asm/i8254.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
> index d769daf85d..bb8930338b 100644
> --- a/arch/x86/include/asm/i8254.h
> +++ b/arch/x86/include/asm/i8254.h
> @@ -7,7 +7,7 @@
>  /* i8254.h Intel 8254 PIT registers */
>
>  #ifndef _ASMI386_I8254_H_
> -#define _ASMI386_I8954_H_
> +#define _ASMI386_I8254_H_

There is another I8954 at the end of this file. I can fix it when applying.

>
>  #define PIT_T0         0x00    /* PIT channel 0 count/status */
>  #define PIT_T1         0x01    /* PIT channel 1 count/status */

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Re: [PATCH] x86: Fix i8254 ifdef include guard

[Bin Meng]

On Wed, Oct 27, 2021 at 11:08 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva <adelva@google.com> wrote:
> >
> > When building U-Boot with clang, it notices that the i8254.h include
> > guard does not work correctly due to a typo. Fix it.
> >
> > Signed-off-by: Alistair Delva <adelva@google.com>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >  arch/x86/include/asm/i8254.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
> > index d769daf85d..bb8930338b 100644
> > --- a/arch/x86/include/asm/i8254.h
> > +++ b/arch/x86/include/asm/i8254.h
> > @@ -7,7 +7,7 @@
> >  /* i8254.h Intel 8254 PIT registers */
> >
> >  #ifndef _ASMI386_I8254_H_
> > -#define _ASMI386_I8954_H_
> > +#define _ASMI386_I8254_H_
>
> There is another I8954 at the end of this file. I can fix it when applying.
>
> >
> >  #define PIT_T0         0x00    /* PIT channel 0 count/status */
> >  #define PIT_T1         0x01    /* PIT channel 1 count/status */
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

applied to u-boot-x86, thanks!

[PATCH] efi_loader: Fix link of EFI apps with ld.lld

[Alistair Delva]

When compiling U-Boot with ld.lld as the linker, the helloworld EFI app
example fails to link:

LD      lib/efi_loader/helloworld_efi.so
ld.lld: error: section: .dynamic is not contiguous with other relro
                        sections

LLD will always create RELRO program header regardless of target
emulation, whereas BFD may automatically disable it for unsupported
targets. Add -znorelro to disable it explicitly in all cases.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Nick Desaulniers <ndesaulniers@google.com>
---
 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 07696e86bb..39f03398ed 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -403,7 +403,7 @@ $(obj)/%.efi: $(obj)/%_efi.so
 
 quiet_cmd_efi_ld = LD      $@
 cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
-		-Bsymbolic -s $^ -o $@
+		-Bsymbolic -znorelro -s $^ -o $@
 
 EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)
 
-- 
2.30.2

Re: [PATCH] efi_loader: Fix link of EFI apps with ld.lld

[Heinrich Schuchardt]

On 10/20/21 11:31 PM, Alistair Delva wrote:
> When compiling U-Boot with ld.lld as the linker, the helloworld EFI app
> example fails to link:
>
> LD      lib/efi_loader/helloworld_efi.so
> ld.lld: error: section: .dynamic is not contiguous with other relro
>                          sections
>
> LLD will always create RELRO program header regardless of target
> emulation, whereas BFD may automatically disable it for unsupported
> targets. Add -znorelro to disable it explicitly in all cases.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: Nick Desaulniers <ndesaulniers@google.com>

Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

> ---
>   scripts/Makefile.lib | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 07696e86bb..39f03398ed 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -403,7 +403,7 @@ $(obj)/%.efi: $(obj)/%_efi.so
>
>   quiet_cmd_efi_ld = LD      $@
>   cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \
> -		-Bsymbolic -s $^ -o $@
> +		-Bsymbolic -znorelro -s $^ -o $@
>
>   EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS)
>
>

[PATCH] arm64: relocate-rela: Add support for ld.lld

[Alistair Delva]

Cap end of relocations by the binary size.

Linkers like to insert some auxiliary sections between .rela.dyn and
.bss_start. These sections don't make their way to the final binary, but
reloc_rela still tries to relocate them, resulting in attempted read
past the end of file.

When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
default on arm64) breaks the build. After this patch, U-Boot can be
linked successfully with and without CONFIG_STATIC_RELA.

Originally-from: Elena Petrova <lenaptr@google.com>
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: David Brazdil <dbrazdil@google.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@konsulko.com>
---
 tools/relocate-rela.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
index 6a524014b7..f0bc548617 100644
--- a/tools/relocate-rela.c
+++ b/tools/relocate-rela.c
@@ -63,7 +63,7 @@ int main(int argc, char **argv)
 {
 	FILE *f;
 	int i, num;
-	uint64_t rela_start, rela_end, text_base;
+	uint64_t rela_start, rela_end, text_base, file_size;
 
 	if (argc != 5) {
 		fprintf(stderr, "Statically apply ELF rela relocations\n");
@@ -87,8 +87,7 @@ int main(int argc, char **argv)
 		return 3;
 	}
 
-	if (rela_start > rela_end || rela_start < text_base ||
-	    (rela_end - rela_start) % sizeof(Elf64_Rela)) {
+	if (rela_start > rela_end || rela_start < text_base) {
 		fprintf(stderr, "%s: bad rela bounds\n", argv[0]);
 		return 3;
 	}
@@ -96,6 +95,21 @@ int main(int argc, char **argv)
 	rela_start -= text_base;
 	rela_end -= text_base;
 
+	fseek(f, 0, SEEK_END);
+	file_size = ftell(f);
+	rewind(f);
+
+	if (rela_end > file_size) {
+		// Most likely compiler inserted some section that didn't get
+		// objcopy-ed into the final binary
+		rela_end = file_size;
+	}
+
+	if ((rela_end - rela_start) % sizeof(Elf64_Rela)) {
+		fprintf(stderr, "%s: rela size isn't a multiple of Elf64_Rela\n", argv[0]);
+		return 3;
+	}
+
 	num = (rela_end - rela_start) / sizeof(Elf64_Rela);
 
 	for (i = 0; i < num; i++) {
-- 
2.30.2

Re: [PATCH] arm64: relocate-rela: Add support for ld.lld

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Wed, Oct 20, 2021 at 09:31:32PM +0000, Alistair Delva wrote:

> Cap end of relocations by the binary size.
> 
> Linkers like to insert some auxiliary sections between .rela.dyn and
> .bss_start. These sections don't make their way to the final binary, but
> reloc_rela still tries to relocate them, resulting in attempted read
> past the end of file.
> 
> When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
> default on arm64) breaks the build. After this patch, U-Boot can be
> linked successfully with and without CONFIG_STATIC_RELA.
> 
> Originally-from: Elena Petrova <lenaptr@google.com>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: David Brazdil <dbrazdil@google.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Tom Rini <trini@konsulko.com>

Thanks for the patch.  Do you have any other changes for LLVM/LLDB
support on arm64 platforms?  I think I've had a few stumbles whenever
I've tried and not been able to cycle back to them.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] arm64: relocate-rela: Add support for ld.lld

[Alistair Delva]

-Scott's ancient non-functioning email address

Hi Tom,

On Mon, Oct 25, 2021 at 6:30 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 20, 2021 at 09:31:32PM +0000, Alistair Delva wrote:
>
> > Cap end of relocations by the binary size.
> >
> > Linkers like to insert some auxiliary sections between .rela.dyn and
> > .bss_start. These sections don't make their way to the final binary, but
> > reloc_rela still tries to relocate them, resulting in attempted read
> > past the end of file.
> >
> > When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
> > default on arm64) breaks the build. After this patch, U-Boot can be
> > linked successfully with and without CONFIG_STATIC_RELA.
> >
> > Originally-from: Elena Petrova <lenaptr@google.com>
> > Signed-off-by: Alistair Delva <adelva@google.com>
> > Cc: David Brazdil <dbrazdil@google.com>
> > Cc: Scott Wood <scottwood@freescale.com>
> > Cc: Tom Rini <trini@konsulko.com>
>
> Thanks for the patch.  Do you have any other changes for LLVM/LLDB
> support on arm64 platforms?  I think I've had a few stumbles whenever
> I've tried and not been able to cycle back to them.

I think the patches I posted are enough to get U-Boot to build with
LLVM LD for QEMU targets on arm64 and x86_64, but I have some other
build problems to work through on physical device targets like
rockchip.

Oddly, the arm64 binaries seem to be booting up (as far as we can see
in a debugger), but there's no serial output, so there's still some
work to do.

I'll keep upstreaming what we find. Our CI system is over here:
https://ci.android.com/builds/branches/aosp_u-boot-mainline/grid?
(using Clang but still ld.bfd for now)

> --
> Tom

Re: [PATCH] arm64: relocate-rela: Add support for ld.lld

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

On Mon, Oct 25, 2021 at 10:46:32AM -0700, Alistair Delva wrote:
> -Scott's ancient non-functioning email address
> 
> Hi Tom,
> 
> On Mon, Oct 25, 2021 at 6:30 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 20, 2021 at 09:31:32PM +0000, Alistair Delva wrote:
> >
> > > Cap end of relocations by the binary size.
> > >
> > > Linkers like to insert some auxiliary sections between .rela.dyn and
> > > .bss_start. These sections don't make their way to the final binary, but
> > > reloc_rela still tries to relocate them, resulting in attempted read
> > > past the end of file.
> > >
> > > When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
> > > default on arm64) breaks the build. After this patch, U-Boot can be
> > > linked successfully with and without CONFIG_STATIC_RELA.
> > >
> > > Originally-from: Elena Petrova <lenaptr@google.com>
> > > Signed-off-by: Alistair Delva <adelva@google.com>
> > > Cc: David Brazdil <dbrazdil@google.com>
> > > Cc: Scott Wood <scottwood@freescale.com>
> > > Cc: Tom Rini <trini@konsulko.com>
> >
> > Thanks for the patch.  Do you have any other changes for LLVM/LLDB
> > support on arm64 platforms?  I think I've had a few stumbles whenever
> > I've tried and not been able to cycle back to them.
> 
> I think the patches I posted are enough to get U-Boot to build with
> LLVM LD for QEMU targets on arm64 and x86_64, but I have some other
> build problems to work through on physical device targets like
> rockchip.
> 
> Oddly, the arm64 binaries seem to be booting up (as far as we can see
> in a debugger), but there's no serial output, so there's still some
> work to do.
> 
> I'll keep upstreaming what we find. Our CI system is over here:
> https://ci.android.com/builds/branches/aosp_u-boot-mainline/grid?
> (using Clang but still ld.bfd for now)

OK, thanks!  I would like to see this get to the point of building +
booting, so I can hopefully get a platform or two both in CI and my
local HW CI loop building with clang as well.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] arm64: relocate-rela: Add support for ld.lld

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

On Wed, Oct 20, 2021 at 09:31:32PM +0000, Alistair Delva wrote:

> Cap end of relocations by the binary size.
> 
> Linkers like to insert some auxiliary sections between .rela.dyn and
> .bss_start. These sections don't make their way to the final binary, but
> reloc_rela still tries to relocate them, resulting in attempted read
> past the end of file.
> 
> When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
> default on arm64) breaks the build. After this patch, U-Boot can be
> linked successfully with and without CONFIG_STATIC_RELA.
> 
> Originally-from: Elena Petrova <lenaptr@google.com>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: David Brazdil <dbrazdil@google.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Tom Rini <trini@konsulko.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

[PATCH] x86: Fix linking u-boot with ld.lld

[Alistair Delva]

When linking the final u-boot binary with LLD, the following link errors
are seen:

ld.lld: error: can't create dynamic relocation R_386_32 against local
               symbol in readonly segment; recompile object files with
               -fPIC or pass '-Wl,-z,notext' to allow text relocations
               in the output
>>> defined in arch/x86/cpu/start.o
>>> referenced by arch/x86/cpu/start.o:(.text.start+0x32)
[...]
>>> defined in arch/x86/cpu/start16.o
>>> referenced by arch/x86/cpu/start16.o:(.start16+0x1C)

According to Nick Desaulniers:

"This is a known difference between GNU and LLVM linkers; the GNU
 linkers permit relocations in readonly segments (making them not read
 only), LLVM does not (by default)."

Since U-Boot apparently seems to use relocations in readonly segments,
change the global linker flags to permit them when linking with LLD by
specifying '-z notext'.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
---
 Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Makefile b/Makefile
index 6f2474baeb..3488b83e14 100644
--- a/Makefile
+++ b/Makefile
@@ -997,6 +997,9 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
 LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
 
+# ld.lld support
+LDFLAGS_u-boot += -z notext
+
 LDFLAGS_u-boot += --build-id=none
 
 ifeq ($(CONFIG_ARC)$(CONFIG_NIOS2)$(CONFIG_X86)$(CONFIG_XTENSA),)
-- 
2.30.2

Re: [PATCH] x86: Fix linking u-boot with ld.lld

[Simon Glass]

On Wed, 20 Oct 2021 at 15:31, Alistair Delva <adelva@google.com> wrote:
>
> When linking the final u-boot binary with LLD, the following link errors
> are seen:
>
> ld.lld: error: can't create dynamic relocation R_386_32 against local
>                symbol in readonly segment; recompile object files with
>                -fPIC or pass '-Wl,-z,notext' to allow text relocations
>                in the output
> >>> defined in arch/x86/cpu/start.o
> >>> referenced by arch/x86/cpu/start.o:(.text.start+0x32)
> [...]
> >>> defined in arch/x86/cpu/start16.o
> >>> referenced by arch/x86/cpu/start16.o:(.start16+0x1C)
>
> According to Nick Desaulniers:
>
> "This is a known difference between GNU and LLVM linkers; the GNU
>  linkers permit relocations in readonly segments (making them not read
>  only), LLVM does not (by default)."
>
> Since U-Boot apparently seems to use relocations in readonly segments,
> change the global linker flags to permit them when linking with LLD by
> specifying '-z notext'.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>


>
> diff --git a/Makefile b/Makefile
> index 6f2474baeb..3488b83e14 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -997,6 +997,9 @@ LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
>  LDFLAGS_u-boot += $(call ld-option, --no-dynamic-linker)
>
> +# ld.lld support
> +LDFLAGS_u-boot += -z notext
> +
>  LDFLAGS_u-boot += --build-id=none
>
>  ifeq ($(CONFIG_ARC)$(CONFIG_NIOS2)$(CONFIG_X86)$(CONFIG_XTENSA),)
> --
> 2.30.2
>

Re: [PATCH] x86: Fix linking u-boot with ld.lld

[Simon Glass]

On Wed, 20 Oct 2021 at 15:31, Alistair Delva <adelva@google.com> wrote:
>
> When linking the final u-boot binary with LLD, the following link errors
> are seen:
>
> ld.lld: error: can't create dynamic relocation R_386_32 against local
>                symbol in readonly segment; recompile object files with
>                -fPIC or pass '-Wl,-z,notext' to allow text relocations
>                in the output
> >>> defined in arch/x86/cpu/start.o
> >>> referenced by arch/x86/cpu/start.o:(.text.start+0x32)
> [...]
> >>> defined in arch/x86/cpu/start16.o
> >>> referenced by arch/x86/cpu/start16.o:(.start16+0x1C)
>
> According to Nick Desaulniers:
>
> "This is a known difference between GNU and LLVM linkers; the GNU
>  linkers permit relocations in readonly segments (making them not read
>  only), LLVM does not (by default)."
>
> Since U-Boot apparently seems to use relocations in readonly segments,
> change the global linker flags to permit them when linking with LLD by
> specifying '-z notext'.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass <sjg@chromium.org>


>
Applied to u-boot-dm, thanks!

[PATCH] RFC: arm: pci: Add PCI cam support to PCI-E ecam driver

[Alistair Delva]

When booting U-Boot in crosvm, the virtual machine emulates a PCI cam
device, not the PCI-E 'ecam' device normally seen on e.g. QEMU. This
PCI device can be supported with only trivial changes to the ecam
driver.

Instead of adding a completely new driver which is identical besides the
initialization step, add support for the PCI version to the existing
driver.

Signed-off-by: Alistair Delva <adelva@google.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: Ram Muthiah <rammuthiah@google.com>
---
 drivers/pci/pcie_ecam_generic.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie_ecam_generic.c b/drivers/pci/pcie_ecam_generic.c
index e83e5aff20..c9b55b45a9 100644
--- a/drivers/pci/pcie_ecam_generic.c
+++ b/drivers/pci/pcie_ecam_generic.c
@@ -14,6 +14,8 @@
 
 #include <asm/io.h>
 
+#define TYPE_PCI 0x1
+
 /**
  * struct generic_ecam_pcie - generic_ecam PCIe controller state
  * @cfg_base: The base address of memory mapped configuration space
@@ -46,9 +48,16 @@ static int pci_generic_ecam_conf_address(const struct udevice *bus,
 	void *addr;
 
 	addr = pcie->cfg_base;
-	addr += (PCI_BUS(bdf) - pcie->first_busno) << 20;
-	addr += PCI_DEV(bdf) << 15;
-	addr += PCI_FUNC(bdf) << 12;
+
+	if (dev_get_driver_data(bus) == TYPE_PCI) {
+		addr += (PCI_BUS(bdf) - pcie->first_busno) << 16;
+		addr += PCI_DEV(bdf) << 11;
+		addr += PCI_FUNC(bdf) << 8;
+	} else {
+		addr += (PCI_BUS(bdf) - pcie->first_busno) << 20;
+		addr += PCI_DEV(bdf) << 15;
+		addr += PCI_FUNC(bdf) << 12;
+	}
 	addr += offset;
 	*paddress = addr;
 
@@ -158,7 +167,8 @@ static const struct dm_pci_ops pci_generic_ecam_ops = {
 };
 
 static const struct udevice_id pci_generic_ecam_ids[] = {
-	{ .compatible = "pci-host-ecam-generic" },
+	{ .compatible = "pci-host-ecam-generic" /* PCI-E */ },
+	{ .compatible = "pci-host-cam-generic", .data = TYPE_PCI },
 	{ }
 };
 
-- 
2.30.2

Re: [PATCH] RFC: arm: pci: Add PCI cam support to PCI-E ecam driver

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Wed, Oct 20, 2021 at 09:31:34PM +0000, Alistair Delva wrote:

> When booting U-Boot in crosvm, the virtual machine emulates a PCI cam
> device, not the PCI-E 'ecam' device normally seen on e.g. QEMU. This
> PCI device can be supported with only trivial changes to the ecam
> driver.
> 
> Instead of adding a completely new driver which is identical besides the
> initialization step, add support for the PCI version to the existing
> driver.
> 
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> Cc: Ram Muthiah <rammuthiah@google.com>

Applied to u-boot/next, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] x86: chromebook_coral: fix C block comment

[Simon Glass]

On Wed, 20 Oct 2021 at 15:31, Alistair Delva <adelva@google.com> wrote:
>
> Fix a warning seen when compiling this dts file.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  arch/x86/dts/chromebook_coral.dts | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Simon Glass <sjg@chromium.org>


> diff --git a/arch/x86/dts/chromebook_coral.dts b/arch/x86/dts/chromebook_coral.dts
> index f0caaacfee..69a1c1ce29 100644
> --- a/arch/x86/dts/chromebook_coral.dts
> +++ b/arch/x86/dts/chromebook_coral.dts
> @@ -825,6 +825,7 @@
>          * Refer to EDS-Vol2-22.3
>          * [14:8] steps of delay for HS400, each 125ps
>          * [6:0] steps of delay for SDR104/HS200, each 125ps
> +        */
>
>         /*
>          * EMMC TX DATA Delay 2
> --
> 2.30.2
>

Re: [PATCH] x86: chromebook_coral: fix C block comment

[Bin Meng]

On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva <adelva@google.com> wrote:
>
> Fix a warning seen when compiling this dts file.
>
> Signed-off-by: Alistair Delva <adelva@google.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>  arch/x86/dts/chromebook_coral.dts | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Re: [PATCH] x86: chromebook_coral: fix C block comment

[Bin Meng]

On Wed, Oct 27, 2021 at 11:07 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva <adelva@google.com> wrote:
> >
> > Fix a warning seen when compiling this dts file.
> >
> > Signed-off-by: Alistair Delva <adelva@google.com>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >  arch/x86/dts/chromebook_coral.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

applied to u-boot-x86, thanks!