[U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper

[U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper

[Bin Meng]

With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
built for qemu-x86_64 target does not boot. It keeps resetting
soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
that the reset happens inside env_callback_init().

000000000113dd85 <env_callback_init>:
 113dd85:       41 54                   push   %r12
 113dd87:       55                      push   %rbp
 113dd88:       31 c0                   xor    %eax,%eax
 113dd8a:       53                      push   %rbx
 113dd8b:       0f 57 c0                xorps  %xmm0,%xmm0

Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset.
However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04)
does not generate such instructions that utilizes SSE for this
function - env_callback_init() and U-Boot boots without any issue.
Explicitly specifying -march=core2 for newer GCC allows U-Boot
proper to boot again. Examine assembly codes of env_callback_init
and there is no SSE instruction in that function hence U-Boot
continues to boot.

core2 seems to be the oldest arch in GCC that supports 64-bit.
Like 32-bit U-Boot build we use -march=i386 which is the most
conservative cpu type so that the image can run on any x86
processor, let's do the same for the 64-bit U-Boot build.

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

 arch/x86/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index cc94071..576501e 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -23,7 +23,7 @@ endif
 ifeq ($(IS_32BIT),y)
 PLATFORM_CPPFLAGS += -march=i386 -m32
 else
-PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64
+PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64
 endif
 
 PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
-- 
2.7.4

[U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build

[Bin Meng]

With the '-march=core2' fix, it seems that we have some luck that
the 64-bit U-Boot boots again. However if we examine the disassembly
codes there are still SSE instructions elsewhere which means passing
cpu type to GCC is not enough to prevent it from generating these
instructions. A simple test case is doing a 'bootefi selftest' from
the U-Boot shell and it leads to a reset too.

The 'bootefi selftest' reset is even seen with the image created by
the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.

To make sure no MMX/SSE instruction sets are generated, tell GCC not
to do this. Note AVX is out of the question as CORE2 is old enough
to support AVX yet.

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

 arch/x86/config.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 576501e..8151e47 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y)
 PLATFORM_CPPFLAGS += -march=i386 -m32
 else
 PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64
+PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
 endif
 
 PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
-- 
2.7.4

[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

[Bin Meng]

Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
the 64-bit support.

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

 doc/README.x86 | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index 8cc4672..ab48466 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -32,7 +32,7 @@ are supported:
    - Link (Chromebook Pixel)
    - Minnowboard MAX
    - Samus (Chromebook Pixel 2015)
-   - QEMU x86
+   - QEMU x86 (32-bit & 64-bit)
 
 As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
 Linux kernel as part of a FIT image. It also supports a compressed zImage.
@@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
 
 To build u-boot.rom for QEMU x86 targets, just simply run
 
-$ make qemu-x86_defconfig
+$ make qemu-x86_defconfig (for 32-bit)
+or
+$ make qemu-x86_64_defconfig (for 64-bit)
 $ make all
 
 Note this default configuration will build a U-Boot for the QEMU x86 i440FX
@@ -387,6 +389,8 @@ Device Tree Control  --->
 	...
 	(qemu-x86_q35) Default Device Tree for DT control
 
+To run 64-bit U-Boot, qemu-system-x86_64 should be used instead.
+
 Test with coreboot
 ------------------
 For testing U-Boot as the coreboot payload, there are things that need be paid
-- 
2.7.4

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Bin Meng]

Add qemu-x86_64 to the list of targets we use for test.py runs.

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

---
testp.py testing is currently failing at 'bootefi selftest'.

 .travis.yml | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 2b759c9..9d0531f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -408,6 +408,14 @@ matrix:
           BUILDMAN="^qemu-x86$"
           TOOLCHAIN="x86_64"
           BUILD_ROM="yes"
+    - name: "test/py qemu-x86_64"
+      env:
+        - TEST_PY_BD="qemu-x86_64"
+          TEST_PY_TEST_SPEC="not sleep"
+          QEMU_TARGET="x86_64-softmmu"
+          BUILDMAN="^qemu-x86_64$"
+          TOOLCHAIN="x86_64"
+          BUILD_ROM="yes"
     - name: "test/py zynq_zc702"
       env:
         - TEST_PY_BD="zynq_zc702"
-- 
2.7.4

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Bin Meng]

Hi Heinrich,

On Thu, Oct 11, 2018 at 9:48 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Add qemu-x86_64 to the list of targets we use for test.py runs.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
> testp.py testing is currently failing at 'bootefi selftest'.
>

Can you try this series for the 'bootefi selftest' testing?

BTW:  do you know how to call test.py on the local machine to do
testing on QEMU? The doc does not provide enough information ..

>  .travis.yml | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/.travis.yml b/.travis.yml
> index 2b759c9..9d0531f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -408,6 +408,14 @@ matrix:
>            BUILDMAN="^qemu-x86$"
>            TOOLCHAIN="x86_64"
>            BUILD_ROM="yes"
> +    - name: "test/py qemu-x86_64"
> +      env:
> +        - TEST_PY_BD="qemu-x86_64"
> +          TEST_PY_TEST_SPEC="not sleep"
> +          QEMU_TARGET="x86_64-softmmu"
> +          BUILDMAN="^qemu-x86_64$"
> +          TOOLCHAIN="x86_64"
> +          BUILD_ROM="yes"
>      - name: "test/py zynq_zc702"
>        env:
>          - TEST_PY_BD="zynq_zc702"
> --

Regards,
Bin

[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

[Heinrich Schuchardt]

On 10/11/2018 03:53 AM, Bin Meng wrote:
> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
> the 64-bit support.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  doc/README.x86 | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/README.x86 b/doc/README.x86
> index 8cc4672..ab48466 100644
> --- a/doc/README.x86
> +++ b/doc/README.x86
> @@ -32,7 +32,7 @@ are supported:
>     - Link (Chromebook Pixel)
>     - Minnowboard MAX
>     - Samus (Chromebook Pixel 2015)
> -   - QEMU x86
> +   - QEMU x86 (32-bit & 64-bit)
>  
>  As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
>  Linux kernel as part of a FIT image. It also supports a compressed zImage.
> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
>  
>  To build u-boot.rom for QEMU x86 targets, just simply run
>  
> -$ make qemu-x86_defconfig
> +$ make qemu-x86_defconfig (for 32-bit)
> +or
> +$ make qemu-x86_64_defconfig (for 64-bit)
>  $ make all

If your patch series creates a U-Boot usable with QEMU depends on the
chosen CPU:

This one seems to work:
qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo

This one fails (as expected):
qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium

I could not get the emulation running without -nographic. Do you know why?

The documentation above is insufficient. Please, provide a minimum QEMU
command line which includes a CPU specification.

I would prefer if you could specify two lines per bitness - one with kvm
and one without, e.g.

qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host
qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo

qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host
qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo

Best regards

Heinrich

>  
>  Note this default configuration will build a U-Boot for the QEMU x86 i440FX
> @@ -387,6 +389,8 @@ Device Tree Control  --->
>  	...
>  	(qemu-x86_q35) Default Device Tree for DT control
>  
> +To run 64-bit U-Boot, qemu-system-x86_64 should be used instead.
> +
>  Test with coreboot
>  ------------------
>  For testing U-Boot as the coreboot payload, there are things that need be paid
> 

[U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper

[Heinrich Schuchardt]

On 10/11/2018 03:53 AM, Bin Meng wrote:
> With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
> built for qemu-x86_64 target does not boot. It keeps resetting
> soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
> that the reset happens inside env_callback_init().
> 
> 000000000113dd85 <env_callback_init>:
>  113dd85:       41 54                   push   %r12
>  113dd87:       55                      push   %rbp
>  113dd88:       31 c0                   xor    %eax,%eax
>  113dd8a:       53                      push   %rbx
>  113dd8b:       0f 57 c0                xorps  %xmm0,%xmm0
> 
> Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset.
> However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04)
> does not generate such instructions that utilizes SSE for this
> function - env_callback_init() and U-Boot boots without any issue.
> Explicitly specifying -march=core2 for newer GCC allows U-Boot
> proper to boot again. Examine assembly codes of env_callback_init
> and there is no SSE instruction in that function hence U-Boot
> continues to boot.
> 
> core2 seems to be the oldest arch in GCC that supports 64-bit.
> Like 32-bit U-Boot build we use -march=i386 which is the most
> conservative cpu type so that the image can run on any x86
> processor, let's do the same for the 64-bit U-Boot build.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

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

> ---
> 
>  arch/x86/config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index cc94071..576501e 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -23,7 +23,7 @@ endif
>  ifeq ($(IS_32BIT),y)
>  PLATFORM_CPPFLAGS += -march=i386 -m32
>  else
> -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64
> +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64
>  endif
>  
>  PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
> 

[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

[Bin Meng]

Hi Heinrich,

On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 10/11/2018 03:53 AM, Bin Meng wrote:
> > Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
> > the 64-bit support.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> >  doc/README.x86 | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/README.x86 b/doc/README.x86
> > index 8cc4672..ab48466 100644
> > --- a/doc/README.x86
> > +++ b/doc/README.x86
> > @@ -32,7 +32,7 @@ are supported:
> >     - Link (Chromebook Pixel)
> >     - Minnowboard MAX
> >     - Samus (Chromebook Pixel 2015)
> > -   - QEMU x86
> > +   - QEMU x86 (32-bit & 64-bit)
> >
> >  As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
> >  Linux kernel as part of a FIT image. It also supports a compressed zImage.
> > @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
> >
> >  To build u-boot.rom for QEMU x86 targets, just simply run
> >
> > -$ make qemu-x86_defconfig
> > +$ make qemu-x86_defconfig (for 32-bit)
> > +or
> > +$ make qemu-x86_64_defconfig (for 64-bit)
> >  $ make all
>
> If your patch series creates a U-Boot usable with QEMU depends on the
> chosen CPU:
>
> This one seems to work:
> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo
>
> This one fails (as expected):
> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium

Pentium does not support 64-bit, so it is expected. In my testing I
always omit the '-cpu' so this is not a problem. But I can document
this.

>
> I could not get the emulation running without -nographic. Do you know why?
>

This is due to currently the VGA support is missing in the 64-bit U-Boot.

> The documentation above is insufficient. Please, provide a minimum QEMU
> command line which includes a CPU specification.
>
> I would prefer if you could specify two lines per bitness - one with kvm
> and one without, e.g.

I doubt -enable-kvm works with U-Boot.

>
> qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host
> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo
>
> qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host
> qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo
>

Will add more info in v2.

Regards,
Bin

[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

[Heinrich Schuchardt]

On 10/11/2018 05:27 PM, Bin Meng wrote:
> Hi Heinrich,
> 
> On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 10/11/2018 03:53 AM, Bin Meng wrote:
>>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
>>> the 64-bit support.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  doc/README.x86 | 8 ++++++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/README.x86 b/doc/README.x86
>>> index 8cc4672..ab48466 100644
>>> --- a/doc/README.x86
>>> +++ b/doc/README.x86
>>> @@ -32,7 +32,7 @@ are supported:
>>>     - Link (Chromebook Pixel)
>>>     - Minnowboard MAX
>>>     - Samus (Chromebook Pixel 2015)
>>> -   - QEMU x86
>>> +   - QEMU x86 (32-bit & 64-bit)
>>>
>>>  As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
>>>  Linux kernel as part of a FIT image. It also supports a compressed zImage.
>>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
>>>
>>>  To build u-boot.rom for QEMU x86 targets, just simply run
>>>
>>> -$ make qemu-x86_defconfig
>>> +$ make qemu-x86_defconfig (for 32-bit)
>>> +or
>>> +$ make qemu-x86_64_defconfig (for 64-bit)
>>>  $ make all
>>
>> If your patch series creates a U-Boot usable with QEMU depends on the
>> chosen CPU:
>>
>> This one seems to work:
>> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo
>>
>> This one fails (as expected):
>> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium
> 
> Pentium does not support 64-bit, so it is expected. In my testing I
> always omit the '-cpu' so this is not a problem. But I can document
> this.
> 
>>
>> I could not get the emulation running without -nographic. Do you know why?
>>
> 
> This is due to currently the VGA support is missing in the 64-bit U-Boot.
> 
>> The documentation above is insufficient. Please, provide a minimum QEMU
>> command line which includes a CPU specification.
>>
>> I would prefer if you could specify two lines per bitness - one with kvm
>> and one without, e.g.
> 
> I doubt -enable-kvm works with U-Boot.

Why? It is just an instruction how QEMU should emulate the CPU. KVM does
not require anything on the target software side.

I have had no problem with KVM on the i386 target.

Regards

Heinrich

> 
>>
>> qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host
>> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo
>>
>> qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host
>> qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo
>>
> 
> Will add more info in v2.
> 
> Regards,
> Bin
> 

[U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support

[Bin Meng]

Hi Heinrich,

On Thu, Oct 11, 2018 at 11:32 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 10/11/2018 05:27 PM, Bin Meng wrote:
> > Hi Heinrich,
> >
> > On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 10/11/2018 03:53 AM, Bin Meng wrote:
> >>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention
> >>> the 64-bit support.
> >>>
> >>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >>> ---
> >>>
> >>>  doc/README.x86 | 8 ++++++--
> >>>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/doc/README.x86 b/doc/README.x86
> >>> index 8cc4672..ab48466 100644
> >>> --- a/doc/README.x86
> >>> +++ b/doc/README.x86
> >>> @@ -32,7 +32,7 @@ are supported:
> >>>     - Link (Chromebook Pixel)
> >>>     - Minnowboard MAX
> >>>     - Samus (Chromebook Pixel 2015)
> >>> -   - QEMU x86
> >>> +   - QEMU x86 (32-bit & 64-bit)
> >>>
> >>>  As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit
> >>>  Linux kernel as part of a FIT image. It also supports a compressed zImage.
> >>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode:
> >>>
> >>>  To build u-boot.rom for QEMU x86 targets, just simply run
> >>>
> >>> -$ make qemu-x86_defconfig
> >>> +$ make qemu-x86_defconfig (for 32-bit)
> >>> +or
> >>> +$ make qemu-x86_64_defconfig (for 64-bit)
> >>>  $ make all
> >>
> >> If your patch series creates a U-Boot usable with QEMU depends on the
> >> chosen CPU:
> >>
> >> This one seems to work:
> >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo
> >>
> >> This one fails (as expected):
> >> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium
> >
> > Pentium does not support 64-bit, so it is expected. In my testing I
> > always omit the '-cpu' so this is not a problem. But I can document
> > this.
> >
> >>
> >> I could not get the emulation running without -nographic. Do you know why?
> >>
> >
> > This is due to currently the VGA support is missing in the 64-bit U-Boot.
> >
> >> The documentation above is insufficient. Please, provide a minimum QEMU
> >> command line which includes a CPU specification.
> >>
> >> I would prefer if you could specify two lines per bitness - one with kvm
> >> and one without, e.g.
> >
> > I doubt -enable-kvm works with U-Boot.
>
> Why? It is just an instruction how QEMU should emulate the CPU. KVM does
> not require anything on the target software side.
>
> I have had no problem with KVM on the i386 target.

I suspect some drivers may have issues when working with KVM, eg: some
memory barriers might be needed due to guest (U-Boot) and host (x86
machine) are speaking the same language. But I have never fully test
this configuration.

Regards,
Bin

[U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build

[Heinrich Schuchardt]

On 10/11/2018 03:53 AM, Bin Meng wrote:
> With the '-march=core2' fix, it seems that we have some luck that
> the 64-bit U-Boot boots again. However if we examine the disassembly
> codes there are still SSE instructions elsewhere which means passing
> cpu type to GCC is not enough to prevent it from generating these
> instructions. A simple test case is doing a 'bootefi selftest' from
> the U-Boot shell and it leads to a reset too.

I can confirm that an unexpected reset patch occurs without the patch.

> 
> The 'bootefi selftest' reset is even seen with the image created by
> the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.
> 
> To make sure no MMX/SSE instruction sets are generated, tell GCC not
> to do this. Note AVX is out of the question as CORE2 is old enough
> to support AVX yet.
> 
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>  arch/x86/config.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> index 576501e..8151e47 100644
> --- a/arch/x86/config.mk
> +++ b/arch/x86/config.mk
> @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y)
>  PLATFORM_CPPFLAGS += -march=i386 -m32
>  else
>  PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64
> +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse

According to https://wiki.osdev.org/SSE SSE has to be initialized.
Otherwise SSE instructions lead to an undefined instruction exception.
Is it this initialization that we lack? If this is your motivation
please, state it in the commit message.

I think this patch could be squashed with the prior one.

Heinrich

>  endif
>  
>  PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden
> 

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Heinrich Schuchardt]

On 10/11/2018 03:57 AM, Bin Meng wrote:
> Hi Heinrich,
> 
> On Thu, Oct 11, 2018 at 9:48 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Add qemu-x86_64 to the list of targets we use for test.py runs.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>
>> ---
>> testp.py testing is currently failing at 'bootefi selftest'.
>>
> 
> Can you try this series for the 'bootefi selftest' testing?

I am clueless why the EFI subsystems is failing completely on
qemu-x86_64_defconfig.

Any printf() or puts() statement I put into
lib/efi_loader/efi_boottime.c leads to no output at all.

I connected gdb with

gdb u-boot -ex 'target remote localhost:1234'
add-symbol-file u-boot <relocaddr>

But the debugger did not stop at breakpoints.

Regards

Heinrich

> 
> BTW:  do you know how to call test.py on the local machine to do
> testing on QEMU? The doc does not provide enough information ..
> 
>>  .travis.yml | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/.travis.yml b/.travis.yml
>> index 2b759c9..9d0531f 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -408,6 +408,14 @@ matrix:
>>            BUILDMAN="^qemu-x86$"
>>            TOOLCHAIN="x86_64"
>>            BUILD_ROM="yes"
>> +    - name: "test/py qemu-x86_64"
>> +      env:
>> +        - TEST_PY_BD="qemu-x86_64"
>> +          TEST_PY_TEST_SPEC="not sleep"
>> +          QEMU_TARGET="x86_64-softmmu"
>> +          BUILDMAN="^qemu-x86_64$"
>> +          TOOLCHAIN="x86_64"
>> +          BUILD_ROM="yes"
>>      - name: "test/py zynq_zc702"
>>        env:
>>          - TEST_PY_BD="zynq_zc702"
>> --
> 
> Regards,
> Bin
> 

[U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper

[Simon Glass]

On 10 October 2018 at 19:53, Bin Meng <bmeng.cn@gmail.com> wrote:
> With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image
> built for qemu-x86_64 target does not boot. It keeps resetting
> soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows
> that the reset happens inside env_callback_init().
>
> 000000000113dd85 <env_callback_init>:
>  113dd85:       41 54                   push   %r12
>  113dd87:       55                      push   %rbp
>  113dd88:       31 c0                   xor    %eax,%eax
>  113dd8a:       53                      push   %rbx
>  113dd8b:       0f 57 c0                xorps  %xmm0,%xmm0
>
> Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset.
> However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04)
> does not generate such instructions that utilizes SSE for this
> function - env_callback_init() and U-Boot boots without any issue.
> Explicitly specifying -march=core2 for newer GCC allows U-Boot
> proper to boot again. Examine assembly codes of env_callback_init
> and there is no SSE instruction in that function hence U-Boot
> continues to boot.
>
> core2 seems to be the oldest arch in GCC that supports 64-bit.
> Like 32-bit U-Boot build we use -march=i386 which is the most
> conservative cpu type so that the image can run on any x86
> processor, let's do the same for the 64-bit U-Boot build.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  arch/x86/config.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Bin Meng]

Hi Heinrich,

On Fri, Oct 12, 2018 at 6:10 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 10/11/2018 03:57 AM, Bin Meng wrote:
> > Hi Heinrich,
> >
> > On Thu, Oct 11, 2018 at 9:48 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >>
> >> Add qemu-x86_64 to the list of targets we use for test.py runs.
> >>
> >> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >>
> >> ---
> >> testp.py testing is currently failing at 'bootefi selftest'.
> >>
> >
> > Can you try this series for the 'bootefi selftest' testing?
>
> I am clueless why the EFI subsystems is failing completely on
> qemu-x86_64_defconfig.
>
> Any printf() or puts() statement I put into
> lib/efi_loader/efi_boottime.c leads to no output at all.
>
> I connected gdb with
>
> gdb u-boot -ex 'target remote localhost:1234'
> add-symbol-file u-boot <relocaddr>
>
> But the debugger did not stop at breakpoints.

I encountered exactly the same issue that breakpoint is not hit when
debugging this endless loop issue. And I finally figured it out:

The symbol table should not be loaded to <relocaddr>, instead it needs
to be loaded to <relocaddr + .text - .text.start>.

The .text.start was introduced in commit
7e21fbca26d18327cf7cabaad08df276a06a07d8 "efi_loader: Rename sections
to allow for implicit data", and its commit message mentioned: [agraf:
Fix x86_64 breakage], although I was not sure what x86_64 breakage was
fixed.

Please have a try.

Regards,
Bin

[U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build

[Bin Meng]

Hi Heinrich,

On Fri, Oct 12, 2018 at 2:04 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 10/11/2018 03:53 AM, Bin Meng wrote:
> > With the '-march=core2' fix, it seems that we have some luck that
> > the 64-bit U-Boot boots again. However if we examine the disassembly
> > codes there are still SSE instructions elsewhere which means passing
> > cpu type to GCC is not enough to prevent it from generating these
> > instructions. A simple test case is doing a 'bootefi selftest' from
> > the U-Boot shell and it leads to a reset too.
>
> I can confirm that an unexpected reset patch occurs without the patch.
>

I think you mean "bootefi selftest" reset, right?

> >
> > The 'bootefi selftest' reset is even seen with the image created by
> > the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04.
> >
> > To make sure no MMX/SSE instruction sets are generated, tell GCC not
> > to do this. Note AVX is out of the question as CORE2 is old enough
> > to support AVX yet.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> >  arch/x86/config.mk | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/x86/config.mk b/arch/x86/config.mk
> > index 576501e..8151e47 100644
> > --- a/arch/x86/config.mk
> > +++ b/arch/x86/config.mk
> > @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y)
> >  PLATFORM_CPPFLAGS += -march=i386 -m32
> >  else
> >  PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64
> > +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse
>
> According to https://wiki.osdev.org/SSE SSE has to be initialized.
> Otherwise SSE instructions lead to an undefined instruction exception.
> Is it this initialization that we lack? If this is your motivation
> please, state it in the commit message.
>

Yes, it's intentional. U-Boot as a bootloader does not want to handle
these advanced SIMD stuff.

> I think this patch could be squashed with the prior one.

They are different thing, although they solved similar reset. The
first patch is adding the -march=core2 which is the counterpart of
-march=i386 for 32-bit U-Boot. This patch is to disable MMX/SSE
completely which I think deserve a separate patch.

Regards,
Bin

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Heinrich Schuchardt]

On 10/12/2018 03:45 AM, Bin Meng wrote:
> Hi Heinrich,
> 
> On Fri, Oct 12, 2018 at 6:10 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 10/11/2018 03:57 AM, Bin Meng wrote:
>>> Hi Heinrich,
>>>
>>> On Thu, Oct 11, 2018 at 9:48 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> Add qemu-x86_64 to the list of targets we use for test.py runs.
>>>>
>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>>
>>>> ---
>>>> testp.py testing is currently failing at 'bootefi selftest'.
>>>>
>>>
>>> Can you try this series for the 'bootefi selftest' testing?
>>
>> I am clueless why the EFI subsystems is failing completely on
>> qemu-x86_64_defconfig.
>>
>> Any printf() or puts() statement I put into
>> lib/efi_loader/efi_boottime.c leads to no output at all.
>>
>> I connected gdb with
>>
>> gdb u-boot -ex 'target remote localhost:1234'
>> add-symbol-file u-boot <relocaddr>
>>
>> But the debugger did not stop at breakpoints.
> 
> I encountered exactly the same issue that breakpoint is not hit when
> debugging this endless loop issue. And I finally figured it out:
> 
> The symbol table should not be loaded to <relocaddr>, instead it needs
> to be loaded to <relocaddr + .text - .text.start>.
> 
> The .text.start was introduced in commit
> 7e21fbca26d18327cf7cabaad08df276a06a07d8 "efi_loader: Rename sections
> to allow for implicit data", and its commit message mentioned: [agraf:
> Fix x86_64 breakage], although I was not sure what x86_64 breakage was
> fixed.
> 
> Please have a try.
> 
> Regards,
> Bin
> 

Hello Bin,

thanks for your hint. Now I was able to debug the problem.

The code is not correctly relocated.

Function do_elf_reloc_fixups64() only analyzes re_src->r_offset but not
the relocation type.

I put a print statement into the relocation loop and found the
relocation type of the first relocation to be reported as having an
illegal value of 0x10ff70. All other relocation types were reported as
0x8 as expected.

diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..095374830f 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -55,6 +55,7 @@ static void do_elf_reloc_fixups64(unsigned int
text_base, uintptr_t size,
do {
.   /* Get the location from the relocation entry */
.   offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
+   printf("Reloc type %llx\n", ELF64_R_TYPE(re_src->r_info));
.
.   /* Check that the location of the relocation is in .text */
.   if (offset_ptr_rom >= (Elf64_Addr *)(uintptr_t)text_base &&


Reloc type 10ff70
Reloc type 8
Reloc type 8
Reloc type 8
..


The relocation types in efi_runtime_relocate() are complete garbage:

efi_runtime_relocate: 8
efi_runtime_relocate: 30
efi_runtime_relocate: b0
efi_runtime_relocate: 8
efi_runtime_relocate: 50
efi_runtime_relocate: 20
efi_runtime_relocate: 8
efi_runtime_relocate: 60
efi_runtime_relocate: 20
efi_runtime_relocate: 8
efi_runtime_relocate: a0
efi_runtime_relocate: b5
efi_runtime_relocate: 8
efi_runtime_relocate: b0
efi_runtime_relocate: aa
efi_runtime_relocate: 8
efi_runtime_relocate: c0
efi_runtime_relocate: c0
efi_runtime_relocate: 8
efi_runtime_relocate: d0
efi_runtime_relocate: 68
efi_runtime_relocate: 8
efi_runtime_relocate: e0
efi_runtime_relocate: b5
efi_runtime_relocate: 8
efi_runtime_relocate: f0
efi_runtime_relocate: cb
efi_runtime_relocate: 8
efi_runtime_relocate: 0
efi_runtime_relocate: e1

I will send a patch for efi_runtime_relocate().

Bin, can you please, have a look at the first problem.

Best regards

Heinrich

[U-Boot] [PATCH 4/4] WIP: travis: Add qemu-x86_64 target for test.py testing

[Heinrich Schuchardt]

On 10/12/2018 11:02 PM, Heinrich Schuchardt wrote:
> On 10/12/2018 03:45 AM, Bin Meng wrote:
>> Hi Heinrich,
>>
>> On Fri, Oct 12, 2018 at 6:10 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>
>>> On 10/11/2018 03:57 AM, Bin Meng wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Thu, Oct 11, 2018 at 9:48 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>
>>>>> Add qemu-x86_64 to the list of targets we use for test.py runs.
>>>>>
>>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>
>>>>> ---
>>>>> testp.py testing is currently failing at 'bootefi selftest'.
>>>>>
>>>>
>>>> Can you try this series for the 'bootefi selftest' testing?
>>>
>>> I am clueless why the EFI subsystems is failing completely on
>>> qemu-x86_64_defconfig.
>>>
>>> Any printf() or puts() statement I put into
>>> lib/efi_loader/efi_boottime.c leads to no output at all.
>>>
>>> I connected gdb with
>>>
>>> gdb u-boot -ex 'target remote localhost:1234'
>>> add-symbol-file u-boot <relocaddr>
>>>
>>> But the debugger did not stop at breakpoints.
>>
>> I encountered exactly the same issue that breakpoint is not hit when
>> debugging this endless loop issue. And I finally figured it out:
>>
>> The symbol table should not be loaded to <relocaddr>, instead it needs
>> to be loaded to <relocaddr + .text - .text.start>.
>>
>> The .text.start was introduced in commit
>> 7e21fbca26d18327cf7cabaad08df276a06a07d8 "efi_loader: Rename sections
>> to allow for implicit data", and its commit message mentioned: [agraf:
>> Fix x86_64 breakage], although I was not sure what x86_64 breakage was
>> fixed.
>>
>> Please have a try.
>>
>> Regards,
>> Bin
>>
> 
> Hello Bin,
> 
> thanks for your hint. Now I was able to debug the problem.
> 
> The code is not correctly relocated.
> 
> Function do_elf_reloc_fixups64() only analyzes re_src->r_offset but not
> the relocation type.
> 
> I put a print statement into the relocation loop and found the
> relocation type of the first relocation to be reported as having an
> illegal value of 0x10ff70. All other relocation types were reported as
> 0x8 as expected.
> 
> diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
> index ed10755d9c..095374830f 100644
> --- a/arch/x86/lib/relocate.c
> +++ b/arch/x86/lib/relocate.c
> @@ -55,6 +55,7 @@ static void do_elf_reloc_fixups64(unsigned int
> text_base, uintptr_t size,
> do {
> .   /* Get the location from the relocation entry */
> .   offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
> +   printf("Reloc type %llx\n", ELF64_R_TYPE(re_src->r_info));
> .
> .   /* Check that the location of the relocation is in .text */
> .   if (offset_ptr_rom >= (Elf64_Addr *)(uintptr_t)text_base &&
> 
> 
> Reloc type 10ff70
> Reloc type 8
> Reloc type 8
> Reloc type 8
> ..
> 
> 
> The relocation types in efi_runtime_relocate() are complete garbage:
> 
> efi_runtime_relocate: 8
> efi_runtime_relocate: 30
> efi_runtime_relocate: b0
> efi_runtime_relocate: 8
> efi_runtime_relocate: 50
> efi_runtime_relocate: 20
> efi_runtime_relocate: 8
> efi_runtime_relocate: 60
> efi_runtime_relocate: 20
> efi_runtime_relocate: 8
> efi_runtime_relocate: a0
> efi_runtime_relocate: b5
> efi_runtime_relocate: 8
> efi_runtime_relocate: b0
> efi_runtime_relocate: aa
> efi_runtime_relocate: 8
> efi_runtime_relocate: c0
> efi_runtime_relocate: c0
> efi_runtime_relocate: 8
> efi_runtime_relocate: d0
> efi_runtime_relocate: 68
> efi_runtime_relocate: 8
> efi_runtime_relocate: e0
> efi_runtime_relocate: b5
> efi_runtime_relocate: 8
> efi_runtime_relocate: f0
> efi_runtime_relocate: cb
> efi_runtime_relocate: 8
> efi_runtime_relocate: 0
> efi_runtime_relocate: e1
> 
> I will send a patch for efi_runtime_relocate().
> 
> Bin, can you please, have a look at the first problem.
> 
> Best regards
> 
> Heinrich
> 
> 
> 

Using a memory watchpoint pinpoints the culprit overwriting the
relocation table with an illegal relocation type:

Hardware access (read/write) watchpoint 1: *0x118b188

Old value = 8
New value = 1113968
arch_setup_gd (new_gd=0x10ff70) at arch/x86/cpu/x86_64/cpu.c:32
(gdb)

0x111173e <arch_setup_gd>               mov    %rdi,0x79a43(%rip)
# 0x118b188

0x1111745 <arch_setup_gd+7>             mov    $0x20,%edi


0x111174a <arch_setup_gd+12>            jmpq   0x11399fb <printch>


0x111174f <cpu_has_64bit>               mov    $0x1,%eax

The global_data_ptr and the relocation table occupy the same memory
location:

 .bss.global_data_ptr
                0x000000000118b188        0x8 arch/x86/cpu/built-in.o
                0x000000000118b188                global_data_ptr

 .rela.got      0x000000000118b180       0x90 arch/x86/cpu/start64.o
 .rela.bss      0x000000000118b210        0x0 arch/x86/cpu/start64.o

Essentially we have to relocate before accessing any global symbols in
the data section. I have sent a patch moving global_data_ptr to the
.text section.

Best regards

Heinrich