All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Uboot as x86_64 EFI payload
@ 2018-01-29 15:18 Juan Alfonso Reyes Ajenjo
  2018-01-29 16:36 ` Javier Santos Romo
  2018-06-08 12:25 ` Bin Meng
  0 siblings, 2 replies; 7+ messages in thread
From: Juan Alfonso Reyes Ajenjo @ 2018-01-29 15:18 UTC (permalink / raw)
  To: u-boot

Hi,
I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting "U-Boot EFI Payload 2002 No memory map" error code.
As I can see in the code 2002 means (efi_stub.c):

ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
            if (ret != EFI_BUFFER_TOO_SMALL) {
                        printhex2(BITS_PER_LONG);
                        printhex2(ret);
                        puts(" No memory map\n");
                        while(1);
                        return ret;
            }

0x20   -> BITS_PER_LONG 32bits
0x02 -> EFI_INVALID_PARAMETER

32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:

In file included from include/common.h:53:0,
                 from cmd/efi.c:8:
cmd/efi.c: In function 'do_efi_mem':
./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' undeclared (first use in this function)
#define gd global_data_ptr


I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h

# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
/* TODO(sjg at chromium.org<mailto:sjg@chromium.org>): Consider using a fixed register for gd on x86_64 */
#define gd global_data_ptr

What do you mean with "Consider using a fixed register for gd" ?Can you help us to make this work? Are we in the correct direction?

Thank you very much,

Best regards,
________________________________
[cid:image001.gif at 01D39918.97D8D0B0]

Juan Alfonso Reyes Ajenjo
Ingeniero en Informatica / Computer Systems Engineer
Ingeniero en Automática y Electrónica Industrial / Automation and Industrial Electronics Engineer

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com <http://www.gmv.com/>
[cid:image002.png at 01D39918.97D8D0B0]<http://www.facebook.com/infoGMV>

[cid:image003.png at 01D39918.97D8D0B0]<http://www.twitter.com/infoGMV_es>

[cid:image004.png at 01D39918.97D8D0B0]<https://plus.google.com/+Gmvcompany>

[cid:image005.png at 01D39918.97D8D0B0]<http://www.youtube.com/infoGMV>

[cid:image006.png at 01D39918.97D8D0B0]<https://www.linkedin.com/company/gmv>

[cid:image007.png at 01D39918.97D8D0B0]<http://www.gmv.com/en/RSS>


[cid:image008.png at 01D39918.97D8D0B0]<http://www.gmv.com/blog_gmv/language/en/>






P Please consider the environment before printing this e-mail.

______________________
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

______________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 5711 bytes
Desc: image001.gif
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2914 bytes
Desc: image002.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2946 bytes
Desc: image003.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3037 bytes
Desc: image004.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 3026 bytes
Desc: image005.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 2913 bytes
Desc: image006.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 3042 bytes
Desc: image007.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 4932 bytes
Desc: image008.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/69241f8e/attachment-0006.png>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-01-29 15:18 [U-Boot] Uboot as x86_64 EFI payload Juan Alfonso Reyes Ajenjo
@ 2018-01-29 16:36 ` Javier Santos Romo
  2018-02-04 13:40   ` Simon Glass
  2018-06-08 12:25 ` Bin Meng
  1 sibling, 1 reply; 7+ messages in thread
From: Javier Santos Romo @ 2018-01-29 16:36 UTC (permalink / raw)
  To: u-boot

FYI

________________________________
[cid:image001.gif at 01D39927.A0D208D0]

Javier Santos Romo
Ingeniero de Telecomunicaciones /
Telecommunications Engineer /

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com <http://www.gmv.com/>
[cid:image002.png at 01D39927.A0D208D0]<http://www.facebook.com/infoGMV>

[cid:image003.png at 01D39927.A0D208D0]<http://www.twitter.com/infoGMV_es>

[cid:image004.png at 01D39927.A0D208D0]<https://plus.google.com/+Gmvcompany>

[cid:image005.png at 01D39927.A0D208D0]<http://www.youtube.com/infoGMV>

[cid:image006.png at 01D39927.A0D208D0]<https://www.linkedin.com/company/gmv>

[cid:image007.png at 01D39927.A0D208D0]<http://www.gmv.com/en/RSS>


[cid:image008.png at 01D39927.A0D208D0]<http://www.gmv.com/blog_gmv/language/en/>




De: Juan Alfonso Reyes Ajenjo
Enviado el: lunes, 29 de enero de 2018 16:18
Para: u-boot at lists.denx.de
CC: Javier Santos Romo <jsantos@gmv.com>
Asunto: Uboot as x86_64 EFI payload

Hi,
I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting "U-Boot EFI Payload 2002 No memory map" error code.
As I can see in the code 2002 means (efi_stub.c):

ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
            if (ret != EFI_BUFFER_TOO_SMALL) {
                        printhex2(BITS_PER_LONG);
                        printhex2(ret);
                        puts(" No memory map\n");
                        while(1);
                        return ret;
            }

0x20   -> BITS_PER_LONG 32bits
0x02 -> EFI_INVALID_PARAMETER

32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:

In file included from include/common.h:53:0,
                 from cmd/efi.c:8:
cmd/efi.c: In function 'do_efi_mem':
./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' undeclared (first use in this function)
#define gd global_data_ptr


I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h

# if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
/* TODO(sjg at chromium.org<mailto:sjg@chromium.org>): Consider using a fixed register for gd on x86_64 */
#define gd global_data_ptr

What do you mean with "Consider using a fixed register for gd" ?Can you help us to make this work? Are we in the correct direction?

Thank you very much,

Best regards,
________________________________
[cid:image001.gif at 01D39927.A0D208D0]

Juan Alfonso Reyes Ajenjo
Ingeniero en Informatica / Computer Systems Engineer
Ingeniero en Automática y Electrónica Industrial / Automation and Industrial Electronics Engineer

GMV
Juan de Herrera nº17
Boecillo
E-47151 Valladolid
Tel. +34 983 54 65 54
Fax +34 983 54 65 53
www.gmv.com <http://www.gmv.com/>
[cid:image002.png at 01D39927.A0D208D0]<http://www.facebook.com/infoGMV>

[cid:image003.png at 01D39927.A0D208D0]<http://www.twitter.com/infoGMV_es>

[cid:image004.png at 01D39927.A0D208D0]<https://plus.google.com/+Gmvcompany>

[cid:image005.png at 01D39927.A0D208D0]<http://www.youtube.com/infoGMV>

[cid:image006.png at 01D39927.A0D208D0]<https://www.linkedin.com/company/gmv>

[cid:image007.png at 01D39927.A0D208D0]<http://www.gmv.com/en/RSS>


[cid:image008.png at 01D39927.A0D208D0]<http://www.gmv.com/blog_gmv/language/en/>






P Please consider the environment before printing this e-mail.

P Please consider the environment before printing this e-mail.

______________________
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

______________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 5711 bytes
Desc: image001.gif
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2914 bytes
Desc: image002.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2946 bytes
Desc: image003.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 3037 bytes
Desc: image004.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 3026 bytes
Desc: image005.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 2913 bytes
Desc: image006.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 3042 bytes
Desc: image007.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 4932 bytes
Desc: image008.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180129/eb7bf579/attachment-0006.png>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-01-29 16:36 ` Javier Santos Romo
@ 2018-02-04 13:40   ` Simon Glass
  2018-02-05  8:07     ` Javier Santos Romo
  0 siblings, 1 reply; 7+ messages in thread
From: Simon Glass @ 2018-02-04 13:40 UTC (permalink / raw)
  To: u-boot

Hi Javier,

On 29 January 2018 at 09:36, Javier Santos Romo <jsantos@gmv.com> wrote:

> Hi,
>
> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting “U-Boot EFI Payload 2002 No memory map” error code.
>
> As I can see in the code 2002 means (efi_stub.c):
>
>
>
> ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
>
>             if (ret != EFI_BUFFER_TOO_SMALL) {
>
>                         printhex2(BITS_PER_LONG);
>
>                         printhex2(ret);
>
>                         puts(" No memory map\n");
>
>                         while(1);
>
>                         return ret;
>
>             }
>
>
>
> 0x20   -> BITS_PER_LONG 32bits
>
> 0x02 -> EFI_INVALID_PARAMETER
>
>
>
> 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:

Are you using 64-bit EFI or 32-bit?

I think you was CONFIG_EFI_STUB_64BIT

See doc/README.efi for some info about this. Note this this option
makes the stub run as a 64-bit EFI app, but U-Boot itself is still
only 32-bit.

>
>
>
> In file included from include/common.h:53:0,
>
>                  from cmd/efi.c:8:
>
> cmd/efi.c: In function ‘do_efi_mem’:
>
> ./arch/x86/include/asm/global_data.h:117:12: error: ‘global_data_ptr’ undeclared (first use in this function)
>
> #define gd global_data_ptr
>
>
>
>
>
> I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h
>
>
>
> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
>
> /* TODO(sjg at chromium.org): Consider using a fixed register for gd on x86_64 */
>
> #define gd global_data_ptr
>
>
>
> What do you mean with “Consider using a fixed register for gd” ?Can you help us to make this work? Are we in the correct direction?

This is for running U-Boot itself as a 64-bit app. This is not
currently supported as an EFI payload, only as a bar-metal U-Boot (not
run from EFI).

The meaning of the comment is that on 32-bit x86 we use the FS
register to store gd. See:

#define gd      get_fs_gd_ptr()

We could potentially make gd use a fixed x86 register on 64-bit x86 as
well. This comment is about considering that.

Regards,
Simon


>
>
>
> Thank you very much,
>
>
>
> Best regards,
>
> ________________________________
>
> Juan Alfonso Reyes Ajenjo
> Ingeniero en Informatica / Computer Systems Engineer
>
> Ingeniero en Automática y Electrónica Industrial / Automation and Industrial Electronics Engineer
>
> GMV
> Juan de Herrera nº17
> Boecillo
> E-47151 Valladolid
> Tel. +34 983 54 65 54
> Fax +34 983 54 65 53
> www.gmv.com
>
>
>
>
>
>
>
>
> P Please consider the environment before printing this e-mail.
>
>
> P Please consider the environment before printing this e-mail.

What does this mean?

>
> ________________________________
> This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. Thank you.
> ________________________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información clasificada por su emisor como confidencial en el marco de su Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración.
> ________________________________
> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, cópia ou distribuição a terceiros sem autorização expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colaboração.
> ________________________________

Would you mind trimming your signature down for the mailing list?

Regards,
Simon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-02-04 13:40   ` Simon Glass
@ 2018-02-05  8:07     ` Javier Santos Romo
  2018-02-05 16:43       ` Simon Glass
  0 siblings, 1 reply; 7+ messages in thread
From: Javier Santos Romo @ 2018-02-05  8:07 UTC (permalink / raw)
  To: u-boot

Hi Simon,

Thanks for your support. We just need a x64 bootloader because we are using a 64-bit EFI. We understood, reading README.efi file from U-boot documentation that we could use u-boot like an 64-bit payload. However, we don´t understand why we get the memory map error. Anyway, we will consider other possibilities.

Thanks a lot,
BR















-----Mensaje original-----
De: sjg at google.com [mailto:sjg at google.com] En nombre de Simon Glass
Enviado el: domingo, 4 de febrero de 2018 14:41
Para: Javier Santos Romo <jsantos@gmv.com>
CC: u-boot at lists.denx.de; bmeng.cn at gmail.com; Juan Alfonso Reyes Ajenjo <jareyes@gmv.com>
Asunto: Re: Uboot as x86_64 EFI payload

Hi Javier,

On 29 January 2018 at 09:36, Javier Santos Romo <jsantos@gmv.com> wrote:

> Hi,
>
> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting “U-Boot EFI Payload 2002 No memory map” error code.
>
> As I can see in the code 2002 means (efi_stub.c):
>
>
>
> ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
>
>             if (ret != EFI_BUFFER_TOO_SMALL) {
>
>                         printhex2(BITS_PER_LONG);
>
>                         printhex2(ret);
>
>                         puts(" No memory map\n");
>
>                         while(1);
>
>                         return ret;
>
>             }
>
>
>
> 0x20   -> BITS_PER_LONG 32bits
>
> 0x02 -> EFI_INVALID_PARAMETER
>
>
>
> 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:

Are you using 64-bit EFI or 32-bit?

I think you was CONFIG_EFI_STUB_64BIT

See doc/README.efi for some info about this. Note this this option makes the stub run as a 64-bit EFI app, but U-Boot itself is still only 32-bit.

>
>
>
> In file included from include/common.h:53:0,
>
>                  from cmd/efi.c:8:
>
> cmd/efi.c: In function ‘do_efi_mem’:
>
> ./arch/x86/include/asm/global_data.h:117:12: error: ‘global_data_ptr’
> undeclared (first use in this function)
>
> #define gd global_data_ptr
>
>
>
>
>
> I have surfed in the code and I have found this in
> ./arch/x86/include/asm/global_data.h
>
>
>
> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
>
> /* TODO(sjg at chromium.org): Consider using a fixed register for gd on
> x86_64 */
>
> #define gd global_data_ptr
>
>
>
> What do you mean with “Consider using a fixed register for gd” ?Can you help us to make this work? Are we in the correct direction?

This is for running U-Boot itself as a 64-bit app. This is not currently supported as an EFI payload, only as a bar-metal U-Boot (not run from EFI).

The meaning of the comment is that on 32-bit x86 we use the FS register to store gd. See:

#define gd      get_fs_gd_ptr()

We could potentially make gd use a fixed x86 register on 64-bit x86 as well. This comment is about considering that.

Regards,
Simon


>
>
>
> Thank you very much,
>
>
>
> Best regards,
>
> ________________________________
>
> Juan Alfonso Reyes Ajenjo
> Ingeniero en Informatica / Computer Systems Engineer
>
> Ingeniero en Automática y Electrónica Industrial / Automation and
> Industrial Electronics Engineer
>
> GMV
> Juan de Herrera nº17
> Boecillo
> E-47151 Valladolid
> Tel. +34 983 54 65 54
> Fax +34 983 54 65 53
> www.gmv.com
>
>
>
>
>
>
>
>
> P Please consider the environment before printing this e-mail.
>
>
> P Please consider the environment before printing this e-mail.

What does this mean?

>
> ________________________________
> This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. Thank you.
> ________________________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información clasificada por su emisor como confidencial en el marco de su Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración.
> ________________________________
> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, cópia ou distribuição a terceiros sem autorização expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colaboração.
> ________________________________

Would you mind trimming your signature down for the mailing list?

Regards,
Simon

P Please consider the environment before printing this e-mail.

______________________
This message including any attachments may contain confidential 
information, according to our Information Security Management System,
 and intended solely for a specific individual to whom they are addressed.
 Any unauthorised copy, disclosure or distribution of this message
 is strictly forbidden. If you have received this transmission in error,
 please notify the sender immediately and delete it.

______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
 puede contener informacion clasificada por su emisor como confidencial
 en el marco de su Sistema de Gestion de Seguridad de la 
Informacion siendo para uso exclusivo del destinatario, quedando 
prohibida su divulgacion copia o distribucion a terceros sin la 
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje 
 erroneamente, se ruega lo notifique al remitente y proceda a su borrado. 
Gracias por su colaboracion.

______________________

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-02-05  8:07     ` Javier Santos Romo
@ 2018-02-05 16:43       ` Simon Glass
  0 siblings, 0 replies; 7+ messages in thread
From: Simon Glass @ 2018-02-05 16:43 UTC (permalink / raw)
  To: u-boot

Hi Javier,

On 5 February 2018 at 01:07, Javier Santos Romo <jsantos@gmv.com> wrote:
> Hi Simon,
>
> Thanks for your support. We just need a x64 bootloader because we are using a 64-bit EFI. We understood, reading README.efi file from U-boot documentation that we could use u-boot like an 64-bit payload. However, we don´t understand why we get the memory map error. Anyway, we will consider other possibilities.

There is no need to use a 64-bit bootloader with UEFI. In fact the
U-Boot payload is specifically designed to jump from 64-bit to 32-bit
for running U-Boot. It also have native 64-bit kernel support so it
can load a 64-bit kernel.

I suggest you try it in 32-bit mode for now. That is how we use it
here. There is not a lot of benefit to using U-Boot in 64-bit mode,
but if you find something I'm interested to hear it.

If you hit a memory allocation problem in that case, please let us know.

[BTW it is best not to top-post on a mailing list]

Regards,
Simon

>
> Thanks a lot,
> BR
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: sjg at google.com [mailto:sjg at google.com] En nombre de Simon Glass
> Enviado el: domingo, 4 de febrero de 2018 14:41
> Para: Javier Santos Romo <jsantos@gmv.com>
> CC: u-boot at lists.denx.de; bmeng.cn at gmail.com; Juan Alfonso Reyes Ajenjo <jareyes@gmv.com>
> Asunto: Re: Uboot as x86_64 EFI payload
>
> Hi Javier,
>
> On 29 January 2018 at 09:36, Javier Santos Romo <jsantos@gmv.com> wrote:
>
>> Hi,
>>
>> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting “U-Boot EFI Payload 2002 No memory map” error code.
>>
>> As I can see in the code 2002 means (efi_stub.c):
>>
>>
>>
>> ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
>>
>>             if (ret != EFI_BUFFER_TOO_SMALL) {
>>
>>                         printhex2(BITS_PER_LONG);
>>
>>                         printhex2(ret);
>>
>>                         puts(" No memory map\n");
>>
>>                         while(1);
>>
>>                         return ret;
>>
>>             }
>>
>>
>>
>> 0x20   -> BITS_PER_LONG 32bits
>>
>> 0x02 -> EFI_INVALID_PARAMETER
>>
>>
>>
>> 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:
>
> Are you using 64-bit EFI or 32-bit?
>
> I think you was CONFIG_EFI_STUB_64BIT
>
> See doc/README.efi for some info about this. Note this this option makes the stub run as a 64-bit EFI app, but U-Boot itself is still only 32-bit.
>
>>
>>
>>
>> In file included from include/common.h:53:0,
>>
>>                  from cmd/efi.c:8:
>>
>> cmd/efi.c: In function ‘do_efi_mem’:
>>
>> ./arch/x86/include/asm/global_data.h:117:12: error: ‘global_data_ptr’
>> undeclared (first use in this function)
>>
>> #define gd global_data_ptr
>>
>>
>>
>>
>>
>> I have surfed in the code and I have found this in
>> ./arch/x86/include/asm/global_data.h
>>
>>
>>
>> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
>>
>> /* TODO(sjg at chromium.org): Consider using a fixed register for gd on
>> x86_64 */
>>
>> #define gd global_data_ptr
>>
>>
>>
>> What do you mean with “Consider using a fixed register for gd” ?Can you help us to make this work? Are we in the correct direction?
>
> This is for running U-Boot itself as a 64-bit app. This is not currently supported as an EFI payload, only as a bar-metal U-Boot (not run from EFI).
>
> The meaning of the comment is that on 32-bit x86 we use the FS register to store gd. See:
>
> #define gd      get_fs_gd_ptr()
>
> We could potentially make gd use a fixed x86 register on 64-bit x86 as well. This comment is about considering that.
>
> Regards,
> Simon
>
>
>>
>>
>>
>> Thank you very much,
>>
>>
>>
>> Best regards,
>>
>> ________________________________
>>
>> Juan Alfonso Reyes Ajenjo
>> Ingeniero en Informatica / Computer Systems Engineer
>>
>> Ingeniero en Automática y Electrónica Industrial / Automation and
>> Industrial Electronics Engineer
>>
>> GMV
>> Juan de Herrera nº17
>> Boecillo
>> E-47151 Valladolid
>> Tel. +34 983 54 65 54
>> Fax +34 983 54 65 53
>> www.gmv.com
>>
>>
>>
>>
>>
>>
>>
>>
>> P Please consider the environment before printing this e-mail.
>>
>>
>> P Please consider the environment before printing this e-mail.
>
> What does this mean?
>
>>
>> ________________________________
>> This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. Thank you.
>> ________________________________
>> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener información clasificada por su emisor como confidencial en el marco de su Sistema de Gestión de Seguridad de la Información siendo para uso exclusivo del destinatario, quedando prohibida su divulgación copia o distribución a terceros sin la autorización expresa del remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboración.
>> ________________________________
>> Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informação confidencial, de acordo com nosso Sistema de Gestão de Segurança da Informação, sendo para uso exclusivo do destinatário e estando proibida a sua divulgação, cópia ou distribuição a terceiros sem autorização expressa do remetente da mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o remetente e apague-a. Obrigado pela sua colaboração.
>> ________________________________
>
> Would you mind trimming your signature down for the mailing list?
>
> Regards,
> Simon
>
> P Please consider the environment before printing this e-mail.
>
> ______________________
> This message including any attachments may contain confidential
> information, according to our Information Security Management System,
>  and intended solely for a specific individual to whom they are addressed.
>  Any unauthorised copy, disclosure or distribution of this message
>  is strictly forbidden. If you have received this transmission in error,
>  please notify the sender immediately and delete it.
>
> ______________________
> Este mensaje, y en su caso, cualquier fichero anexo al mismo,
>  puede contener informacion clasificada por su emisor como confidencial
>  en el marco de su Sistema de Gestion de Seguridad de la
> Informacion siendo para uso exclusivo del destinatario, quedando
> prohibida su divulgacion copia o distribucion a terceros sin la
> autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
>  erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
> Gracias por su colaboracion.
>
> ______________________
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-01-29 15:18 [U-Boot] Uboot as x86_64 EFI payload Juan Alfonso Reyes Ajenjo
  2018-01-29 16:36 ` Javier Santos Romo
@ 2018-06-08 12:25 ` Bin Meng
  2018-06-10 14:34   ` Bin Meng
  1 sibling, 1 reply; 7+ messages in thread
From: Bin Meng @ 2018-06-08 12:25 UTC (permalink / raw)
  To: u-boot

Hi,

On Mon, Jan 29, 2018 at 11:18 PM, Juan Alfonso Reyes Ajenjo
<jareyes@gmv.com> wrote:
> Hi,
> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting "U-Boot EFI Payload 2002 No memory map" error code.
> As I can see in the code 2002 means (efi_stub.c):
>
> ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
>             if (ret != EFI_BUFFER_TOO_SMALL) {
>                         printhex2(BITS_PER_LONG);
>                         printhex2(ret);
>                         puts(" No memory map\n");
>                         while(1);
>                         return ret;
>             }
>
> 0x20   -> BITS_PER_LONG 32bits
> 0x02 -> EFI_INVALID_PARAMETER
>
> 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:
>
> In file included from include/common.h:53:0,
>                  from cmd/efi.c:8:
> cmd/efi.c: In function 'do_efi_mem':
> ./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' undeclared (first use in this function)
> #define gd global_data_ptr
>
>
> I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h
>
> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
> /* TODO(sjg at chromium.org<mailto:sjg@chromium.org>): Consider using a fixed register for gd on x86_64 */
> #define gd global_data_ptr
>
> What do you mean with "Consider using a fixed register for gd" ?Can you help us to make this work? Are we in the correct direction?
>

The EFI 64-bit payload support is broken now. I will send a patch to
fix this soon.

Regards,
Bin

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [U-Boot] Uboot as x86_64 EFI payload
  2018-06-08 12:25 ` Bin Meng
@ 2018-06-10 14:34   ` Bin Meng
  0 siblings, 0 replies; 7+ messages in thread
From: Bin Meng @ 2018-06-10 14:34 UTC (permalink / raw)
  To: u-boot

On Fri, Jun 8, 2018 at 8:25 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi,
>
> On Mon, Jan 29, 2018 at 11:18 PM, Juan Alfonso Reyes Ajenjo
> <jareyes@gmv.com> wrote:
>> Hi,
>> I am Juan Alfonso Reyes, a firmware engineer in GMV. Currently we are developing new boards based in Apollo Lake CPU.  We are trying to load uboot from UEFI. Using the default qemu-x86_efi_payload64_defconfig  we are getting "U-Boot EFI Payload 2002 No memory map" error code.
>> As I can see in the code 2002 means (efi_stub.c):
>>
>> ret = boot->get_memory_map(&size, NULL, &key, &desc_size, &version);
>>             if (ret != EFI_BUFFER_TOO_SMALL) {
>>                         printhex2(BITS_PER_LONG);
>>                         printhex2(ret);
>>                         puts(" No memory map\n");
>>                         while(1);
>>                         return ret;
>>             }
>>
>> 0x20   -> BITS_PER_LONG 32bits
>> 0x02 -> EFI_INVALID_PARAMETER
>>
>> 32bits sounds weird for me, so I changed config to use CONFIG_X86_RUN_64BIT instead of CONFIG_X86_RUN_32BIT. I have changed it and I got a compilation error:
>>
>> In file included from include/common.h:53:0,
>>                  from cmd/efi.c:8:
>> cmd/efi.c: In function 'do_efi_mem':
>> ./arch/x86/include/asm/global_data.h:117:12: error: 'global_data_ptr' undeclared (first use in this function)
>> #define gd global_data_ptr
>>
>>
>> I have surfed in the code and I have found this in ./arch/x86/include/asm/global_data.h
>>
>> # if defined(CONFIG_EFI_APP) || CONFIG_IS_ENABLED(X86_64)
>> /* TODO(sjg at chromium.org<mailto:sjg@chromium.org>): Consider using a fixed register for gd on x86_64 */
>> #define gd global_data_ptr
>>
>> What do you mean with "Consider using a fixed register for gd" ?Can you help us to make this work? Are we in the correct direction?
>>
>
> The EFI 64-bit payload support is broken now. I will send a patch to
> fix this soon.
>

This issue has been fixed by the series at:
http://patchwork.ozlabs.org/project/uboot/list/?series=49378

Regards,
Bin

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-06-10 14:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-29 15:18 [U-Boot] Uboot as x86_64 EFI payload Juan Alfonso Reyes Ajenjo
2018-01-29 16:36 ` Javier Santos Romo
2018-02-04 13:40   ` Simon Glass
2018-02-05  8:07     ` Javier Santos Romo
2018-02-05 16:43       ` Simon Glass
2018-06-08 12:25 ` Bin Meng
2018-06-10 14:34   ` Bin Meng

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.