Re: [ipxe-devel] 64 bit?

[Michael Brown]

On 22/01/2019 18:01, Johannes Thoma wrote:

Thanks for your quick reply.

When running

make bin-i386-linux/tests.linux

I run in an endless loop when building the dependencies.


That's an annoying quirk of the build process when there are missing 
headers, sorry.  It arises from some nasty interaction patterns between 
the bits of Makefile that autogenerate other bits of Makefile and empty 
header files.  It's not normally an issue since iPXE is self-contained, 
but it does arise when building the bin-*-linux targets.


From testing, it looks as though Ubuntu installs the kernel headers in 
an unexpected place.  You may get it to work using:


  make EXTRA_CFLAGS=-I/usr/include/x86_64-linux-gnu \
bin-i386-linux/tests.linux

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit?

[Johannes Thoma]

Am 22.01.19 um 17:16 schrieb Michael Brown:


The easiest way is to build the Linux userspace test suite:

   make bin-x86_64-linux/tests.linux bin-i386-linux/tests.linux



Thanks for your quick reply.

When running

make bin-i386-linux/tests.linux

I run in an endless loop when building the dependencies. I also
tried a fresh checkout:

  [DEPS] 
  [DEPS] interface/linux/linux_timer.c
  [DEPS] interface/linux/linux_entropy.c
  [DEPS] interface/linux/linux_time.c
  [DEPS] interface/linux/linux_smbios.c
  [DEPS] interface/linux/linux_umalloc.c
  [DEPS] interface/linux/linux_nap.c
  [DEPS] interface/linux/linux_pci.c
  [DEPS] interface/linux/linux_console.c
  [DEPS] arch/i386/core/linux/linuxprefix.S
  [DEPS] arch/x86/core/linux/linux_api.c
  [DEPS] arch/x86/core/linux/linux_strerror.c
  [DEPS] drivers/linux/af_packet.c
  [DEPS] drivers/linux/tap.c
  [DEPS] interface/linux/linux_timer.c
  [DEPS] interface/linux/linux_entropy.c
  [DEPS] interface/linux/linux_time.c
  [DEPS] interface/linux/linux_smbios.c
  [DEPS] interface/linux/linux_umalloc.c
  [DEPS] interface/linux/linux_nap.c
  [DEPS] interface/linux/linux_pci.c
  [DEPS] interface/linux/linux_console.c

(deps linux_console.c takes a little bit longer).

My build environment is the one from Ubuntu 16.04:

johannes@johannes-VirtualBox:~/Linbit/ipxe2/ipxe/src$ make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
johannes@johannes-VirtualBox:~/Linbit/ipxe2/ipxe/src$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Am I doing something wrong? Is there a quick way to fix this?

make bin-x86_64-linux/tests.linux

works perfect.




And is there a way to compile 'everything' in order to check that my patch
doesn't break other builds?


Yes:

   make everything



That absolutely makes sense to me ;)

Thanks a lot,

- Johannes
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit?

[Michael Brown]

On 22/01/2019 16:07, Johannes Thoma wrote:
 From memory: the issue in 32-bit builds is that format_decimal() in 
core/vsprintf.c will handle only 32-bit (signed) integers and so the 
HTTP range request headers cannot be constructed correctly for >2GB.


This limitation in format_decimal() is originally intended to allow 
for the binary to be kept as small as possible, by avoiding the need 
to link in the 64-bit division code.  This is arguably obsolete nowadays.


I have prepared the patch for booting images > 2GB over http also on 32-bit
systems, before I submit it, I would like to do further tests.

How do I run the regression tests (especially the vsprintf_test)?


The easiest way is to build the Linux userspace test suite:

  make bin-x86_64-linux/tests.linux bin-i386-linux/tests.linux

You can then run those as normal executables.  I would typically run 
them under Valgrind, e.g.:


  make bin-x86_64-linux/tests.linux bin-i386-linux/tests.linux && \
valgrind ./bin-x86_64-linux/tests.linux && \
valgrind ./bin-i386-linux/tests.linux

You can also build individual test executables using e.g.

  make bin-x86_64-linux/vsprintf_test.linux

The tests can run in any environment, so if you really want to then you 
can build e.g.


  make bin/tests.iso

and boot that ISO on a VM (or physical machine).


And is there a way to compile 'everything' in order to check that my patch
doesn't break other builds?


Yes:

  make everything

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit?

[Michael Brown]

On 10/01/2019 19:21, Johannes Thoma wrote:

I will try that, in theory it should work then. Does it make sense
to support loading images > 2GB in 32-bit version also? One has to
change some size_t declarations to uint64_t then (it almost works
for me), if I keep on trying I think that I can do that (it currently
boots a 32GB image in a 32-bit test version).


From memory: the issue in 32-bit builds is that format_decimal() in 
core/vsprintf.c will handle only 32-bit (signed) integers and so the 
HTTP range request headers cannot be constructed correctly for >2GB.


This limitation in format_decimal() is originally intended to allow for 
the binary to be kept as small as possible, by avoiding the need to link 
in the 64-bit division code.  This is arguably obsolete nowadays.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit?

[Johannes Thoma]

Hi Michael,

Thank you for your quick response.

Am 10.01.19 um 20:00 schrieb Michael Brown:

Before continuing I would like to know if there is a way to compile ipxe
in 64 bit mode ( -m64 ), so that size_t is 64 bit and if that would work.


Yes, there are 64-bit iPXE builds available for both UEFI and BIOS, e.g.:

   make bin-x86_64-efi/ipxe.efi
   make bin-x86_64-pcbios/ipxe.pxe



I will try that, in theory it should work then. Does it make sense
to support loading images > 2GB in 32-bit version also? One has to
change some size_t declarations to uint64_t then (it almost works
for me), if I keep on trying I think that I can do that (it currently
boots a 32GB image in a 32-bit test version).

Background: I am working on WinDRBD (www.github.com/LINBIT/windrbd)
and we would like to provide diskless clients over DRBD for Windows.
Since porting DRBD to ipxe is not an option at the moment (DRBD
is highly stateful in the protocol), we boot our clients via
http (using a cgi-bin script delivering via dd from the block
device) and once the drivers are loaded serve the System volume
via our WinDRBD Windows driver.

Please let me know,

- Johannes
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit?

[Michael Brown]

On 10/01/2019 18:57, Johannes Thoma wrote:

I would like to sanboot images larger than 2GB via http. I already changed
some of the size_t declarations to uint64_t but am currently stuck.
I can boot 7.8 GB images but no 32 GB images (the capacity of the
block device is truncated).

Before continuing I would like to know if there is a way to compile ipxe
in 64 bit mode ( -m64 ), so that size_t is 64 bit and if that would work.


Yes, there are 64-bit iPXE builds available for both UEFI and BIOS, e.g.:

  make bin-x86_64-efi/ipxe.efi
  make bin-x86_64-pcbios/ipxe.pxe

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit bARS support.

[Michael Brown]

On Sunday 26 May 2013 14:08:59 Alex Markuze wrote:
> Thanks for the prompt answer.
> But looking at the download page and your answer it's unclear whether we
> can compile legacy iPXE (not UEFI) in 64 bit mode.
> 
> So the questions is : Can Legacy iPXE work with 64 bit BAR's?

Yes.  You do not need to compile in 64-bit mode to use 64-bit BARs.

Provided that the BIOS assigns an address below 4GB (i.e. within 32-bit 
address space), then a 64-bit BAR can still be used from within a 32-bit 
binary such as the BIOS version of iPXE.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit bARS support.

[Alex Markuze]

Thanks for the prompt answer.
But looking at the download page and your answer it's unclear whether we can 
compile legacy iPXE (not UEFI) in 64 bit mode.

So the questions is : Can Legacy iPXE work with 64 bit BAR's?

Thanks.

-Original Message-
From: Michael Brown [mailto:mbr...@fensystems.co.uk] 
Sent: Friday, May 24, 2013 3:16 PM
To: Alex Markuze
Cc: ipxe-devel@lists.ipxe.org
Subject: Re: [ipxe-devel] 64 bit bARS support.

On 24/05/13 10:54, Alex Markuze wrote:
> I've noticed that the iPXE code has macros and comments regarding the 
> support of 64 bit BAR addresses.
>
> Has this code been ever validated? Does it work or does it still need 
> patching?

The code is working as far as I know.

The special handling for 64-bit BARs is twofold: firstly we need to detect BARs 
that are 64-bit capable and treat them as such (i.e. treat the next BAR as the 
high dword rather than being a separate BAR); secondly we need to fail to map 
64-bit capable BARs if there's no way for the CPU to access them (i.e. if the 
BIOS has assigned an address above 4GB and we are running a 32-bit binary).

Most BIOSes should assign addresses below 4GB even for 64-bit capable BARs, to 
allow for access from within a 32-bit OS.

Under UEFI, the problem goes away since we (usually) run as a 64-bit binary.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel

Re: [ipxe-devel] 64 bit bARS support.

[Michael Brown]

On 24/05/13 10:54, Alex Markuze wrote:

I’ve noticed that the iPXE code has macros and comments regarding the
support of 64 bit BAR addresses.

Has this code been ever validated? Does it work or does it still need
patching?


The code is working as far as I know.

The special handling for 64-bit BARs is twofold: firstly we need to 
detect BARs that are 64-bit capable and treat them as such (i.e. treat 
the next BAR as the high dword rather than being a separate BAR); 
secondly we need to fail to map 64-bit capable BARs if there's no way 
for the CPU to access them (i.e. if the BIOS has assigned an address 
above 4GB and we are running a 32-bit binary).


Most BIOSes should assign addresses below 4GB even for 64-bit capable 
BARs, to allow for access from within a 32-bit OS.


Under UEFI, the problem goes away since we (usually) run as a 64-bit binary.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel