U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
is not perfect.

With both builds, executing the VESA ROM causes an intermittent hang, at
least on some AMD CPUs.

With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
is done in a way that works on real hardware but not with QEMU. This
means that performance is 4-5x slower than it could be, at least on my
CPU.

We can work around the first problem by using Bochs, which is anyway a
better choice than VESA for QEMU. The second can be addressed by using
the same descriptor across the jump to long mode.

With an MTRR fix this allows booting into Ubuntu on qemu-x86_64

In v3 some e820 patches are included to make booting reliable and avoid
ACPI tables being dropped. Also, several MTTR problems are addressed, to
support memory sizes above 4GB reliably.

Changes in v4:
- Rewrite the commit message
- Enable the flag by default
- Split out into separate patch
- Split out the command change into a separate patch

Changes in v3:
- Always return true from flag_is_changeable_p() on amd64
- Add new patch with functions to convert between mtrr size and mask
- Add new patch to update mtrr command to support 64-bit values
- Add new patch to update cpuid_eax et al to work on amd64
- Add new patch to correct msr operation on amd64
- Add new patch to allow adding non-aligned size for MTRR
- Support memory sizes above 3GB properly
- Add new patch to correct sizing of created disks
- Add new patch with a function to dump the e820 table
- Add new patch with an API for e820
- Add new patch to use the new e820 API
- Add new patch to support BLOBLIST_TABLES properly in QEMU
- Add new patch to support a 64-bit ramdisk address
- Add new patch to mark struct acpi_rsdp as packed
- Add new patch to consider non-bootable partitions
- Add new patch to handle running out of labels
- Add new patch to support IO UARTs for earlycon and console
- Add new patch to correct mapping in FADT
- Add new patch to add a checksum to the DMAR table
- Add new patch to correct memory leaks in the ACPI test
- Add new patch to support checking checksums with ACPI command
- Significantly expanded to correct e820 and other issues

Changes in v2:
- Redo commit message
- Add new patch to rename the _D dirty flag
- Add new patch to support CPU functions in long mode
- Add new patch to set an MTRR for the RAM in QEMU
- Add new patch with a helper to send characters
- Add new patch to allow tests to be filtered by role
- Add more patches to support booting with kvm
- Add new patch with a test for booting Ubuntu 24.04

Simon Glass (47):
  boot: Correct ramdisk address
  sandbox: Correct a typo in mapmem
  x86: Expand x86_64 early memory
  x86: qemu: Switch to bochs display
  x86: qemu: Enable dhrystone
  x86: qemu: Avoid accessing BSS too early
  x86: Drop mpspec from the SPL build
  x86: Add some log categories
  x86: Drop use of CONFIG_REALMODE_DEBUG
  x86: Avoid clearing the VESA display
  x86: Add 64-bit entries to the GDT
  x86: Use defines for the cache flags
  x86: spl: Drop duplicate CPU init
  x86: Drop the message about features missing in 64-bit
  x86: Include stdbool.h in interrupt header
  x86: Tidy up the GDT size in start/16.S
  x86: Disable paging before changing to long mode
  x86: Use the same GDT when jumping to long mode
  x86: Use a simple jump into long mode
  x86: Rename the _D dirty flag
  x86: Support CPU functions in long mode
  x86: Add functions to convert between mtrr size and mask
  x86: Update mtrr command to support 64-bit values
  x86: Update cpuid_eax et al to work on amd64
  x86: Correct msr operation on amd64
  x86: Allow adding non-aligned size for MTRR
  x86: emulation: Set an MTRR for the RAM
  x86: qemu: Support environment and cat command
  test/py: Correct sizing of created disks
  test/py: Add a helper to send characters
  test/py: Allow tests to be filtered by role
  x86: e820: Add a function to dump the e820 table
  x86: Add a new API for e820
  x86: qemu: Use the new e820 API
  x86: emulation: Support BLOBLIST_TABLES properly
  x86: Support a 64-bit ramdisk address
  acpi: Mark struct acpi_rsdp as packed
  boot: Consider non-bootable partitions
  boot: Handle running out of labels
  boot: Support IO UARTs for earlycon and console
  sandbox: acpi: Avoid a warning about FADT
  sandbox: acpi: Correct mapping in FADT
  acpi: Add a checksum to the DMAR table
  test: acpi: Correct memory leaks
  acpi: Support checking checksums
  RFC: test/py: Deal with timeouts
  test: Add a test for booting Ubuntu 24.04

 .gitlab-ci.yml                   |   5 ++
 arch/x86/cpu/cpu.c               |  24 +++++++
 arch/x86/cpu/i386/call64.S       |  35 ++++------
 arch/x86/cpu/i386/cpu.c          |  41 ++++-------
 arch/x86/cpu/mtrr.c              | 115 ++++++++++++++++++++++++-------
 arch/x86/cpu/qemu/dram.c         |  18 +++++
 arch/x86/cpu/qemu/e820.c         |  62 +++++++----------
 arch/x86/cpu/qemu/qemu.c         |  20 ++++--
 arch/x86/cpu/start.S             |   4 +-
 arch/x86/cpu/start16.S           |   3 +-
 arch/x86/cpu/x86_64/cpu.c        |   5 --
 arch/x86/include/asm/bootparam.h |  15 +++-
 arch/x86/include/asm/cpu.h       |  91 ++++++++++--------------
 arch/x86/include/asm/e820.h      |  95 ++++++++++++++++++++++++-
 arch/x86/include/asm/interrupt.h |   1 +
 arch/x86/include/asm/msr.h       |   9 ++-
 arch/x86/include/asm/mtrr.h      |  16 +++++
 arch/x86/include/asm/processor.h |   5 +-
 arch/x86/lib/Makefile            |   2 +
 arch/x86/lib/bios.c              |  27 +++++---
 arch/x86/lib/bios_interrupts.c   |   8 +--
 arch/x86/lib/e820.c              |  70 +++++++++++++++++++
 arch/x86/lib/i8259.c             |   2 +
 arch/x86/lib/spl.c               |   4 +-
 arch/x86/lib/tables.c            |   9 ++-
 arch/x86/lib/zimage.c            |  34 +++------
 boot/bootdev-uclass.c            |   7 +-
 boot/bootflow.c                  |   7 +-
 boot/pxe_utils.c                 |   3 +-
 cmd/acpi.c                       |  59 ++++++++++------
 cmd/bootflow.c                   |   2 +-
 cmd/x86/mtrr.c                   |  11 ++-
 configs/qemu-x86_64_defconfig    |  18 ++---
 configs/qemu-x86_defconfig       |  12 ++--
 doc/develop/bootstd/overview.rst |   5 +-
 doc/usage/cmd/acpi.rst           |  20 +++++-
 drivers/misc/qfw_acpi.c          |  32 +++++++--
 include/acpi/acpi_table.h        |   2 +-
 include/bootflow.h               |   2 +
 include/bootstd.h                |   3 +
 include/mapmem.h                 |   2 +-
 lib/acpi/acpi_table.c            |   5 +-
 test/boot/bootdev.c              |   1 +
 test/boot/bootflow.c             |   5 +-
 test/dm/acpi.c                   |  59 ++++++++++++++++
 test/py/conftest.py              |  22 ++++++
 test/py/console_base.py          |  33 +++++----
 test/py/pytest.ini               |   1 +
 test/py/tests/test_distro.py     |  53 ++++++++++++++
 test/py/tests/test_sleep.py      |   1 +
 test/py/tests/test_ut.py         |  17 ++++-
 51 files changed, 800 insertions(+), 302 deletions(-)
 create mode 100644 test/py/tests/test_distro.py

-- 
2.43.0

base-commit: 17657f396d03ecb875ece04e1ffbc19b31db56e5
branch: qemu4

On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:

> U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> is not perfect.
> 
> With both builds, executing the VESA ROM causes an intermittent hang, at
> least on some AMD CPUs.
> 
> With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> is done in a way that works on real hardware but not with QEMU. This
> means that performance is 4-5x slower than it could be, at least on my
> CPU.
> 
> We can work around the first problem by using Bochs, which is anyway a
> better choice than VESA for QEMU. The second can be addressed by using
> the same descriptor across the jump to long mode.
> 
> With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> 
> In v3 some e820 patches are included to make booting reliable and avoid
> ACPI tables being dropped. Also, several MTTR problems are addressed, to
> support memory sizes above 4GB reliably.

Do you plan to rebase the prerequisite series' this requires so that it
can be merged?

-- 
Tom

Hi Tom,

On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
>
> > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > is not perfect.
> >
> > With both builds, executing the VESA ROM causes an intermittent hang, at
> > least on some AMD CPUs.
> >
> > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > is done in a way that works on real hardware but not with QEMU. This
> > means that performance is 4-5x slower than it could be, at least on my
> > CPU.
> >
> > We can work around the first problem by using Bochs, which is anyway a
> > better choice than VESA for QEMU. The second can be addressed by using
> > the same descriptor across the jump to long mode.
> >
> > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> >
> > In v3 some e820 patches are included to make booting reliable and avoid
> > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > support memory sizes above 4GB reliably.
>
> Do you plan to rebase the prerequisite series' this requires so that it
> can be merged?

Here's my understanding of where things are:

1. You rejected the membuf series and my replies to try to resolve
that haven't gone anywhere yet. So your tree doesn't have any tests
for that code and still has the old naming.

2. I sent the first part of the PXE series so you could apply that.

3. You rejected the second part of this series because it didn't
include support for lwip without cmdline. I offered to handle that
case later but I'm pretty sure you rejected that too.

4. This series is now marked 'changes requested' but the only feedback
I see is in the RFC patch.

Regards,
Simon

On Fri, Mar 14, 2025 at 02:44:35PM +0000, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
> >
> > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > is not perfect.
> > >
> > > With both builds, executing the VESA ROM causes an intermittent hang, at
> > > least on some AMD CPUs.
> > >
> > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > > is done in a way that works on real hardware but not with QEMU. This
> > > means that performance is 4-5x slower than it could be, at least on my
> > > CPU.
> > >
> > > We can work around the first problem by using Bochs, which is anyway a
> > > better choice than VESA for QEMU. The second can be addressed by using
> > > the same descriptor across the jump to long mode.
> > >
> > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> > >
> > > In v3 some e820 patches are included to make booting reliable and avoid
> > > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > > support memory sizes above 4GB reliably.
> >
> > Do you plan to rebase the prerequisite series' this requires so that it
> > can be merged?
> 
> Here's my understanding of where things are:
> 
> 1. You rejected the membuf series and my replies to try to resolve
> that haven't gone anywhere yet. So your tree doesn't have any tests
> for that code and still has the old naming.

https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not
gratuitous summary of why the series as it stands is a step in the wrong
direction. Tests are good. They're not a reason to pull an otherwise bad
series. This series should be rebased to not depend on that series. The
tests from the other series should be split out.

> 2. I sent the first part of the PXE series so you could apply that.

Yes, I should be applying that next week.

> 3. You rejected the second part of this series because it didn't
> include support for lwip without cmdline. I offered to handle that
> case later but I'm pretty sure you rejected that too.

That's not how I would characterize it, no. I said you should probably
focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to
do the net_loop-alike thing, since he's one of the network custodians
and the lwip person. I was trying to direct you to where your efforts
might be most useful but if you insist on instead doing the
net_loop-alike part and Jerome ack's it, that's fine.

> 4. This series is now marked 'changes requested' but the only feedback
> I see is in the RFC patch.

Yes, rebase to something that can be applied is a change I've requested.
Because my feedback was "Do you plan to rebase the prerequisite series'
this requires so that it can be merged?". I would have otherwise merged
it by now.

Patchwork reflects mainline status.

-- 
Tom

Hi Tom,

On Fri, 14 Mar 2025 at 16:06, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Mar 14, 2025 at 02:44:35PM +0000, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
> > >
> > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > > is not perfect.
> > > >
> > > > With both builds, executing the VESA ROM causes an intermittent hang, at
> > > > least on some AMD CPUs.
> > > >
> > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > > > is done in a way that works on real hardware but not with QEMU. This
> > > > means that performance is 4-5x slower than it could be, at least on my
> > > > CPU.
> > > >
> > > > We can work around the first problem by using Bochs, which is anyway a
> > > > better choice than VESA for QEMU. The second can be addressed by using
> > > > the same descriptor across the jump to long mode.
> > > >
> > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> > > >
> > > > In v3 some e820 patches are included to make booting reliable and avoid
> > > > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > > > support memory sizes above 4GB reliably.
> > >
> > > Do you plan to rebase the prerequisite series' this requires so that it
> > > can be merged?
> >
> > Here's my understanding of where things are:
> >
> > 1. You rejected the membuf series and my replies to try to resolve
> > that haven't gone anywhere yet. So your tree doesn't have any tests
> > for that code and still has the old naming.
>
> https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not
> gratuitous summary of why the series as it stands is a step in the wrong
> direction. Tests are good. They're not a reason to pull an otherwise bad
> series. This series should be rebased to not depend on that series. The
> tests from the other series should be split out.

It's not a bad series, unfortunately. I replied with my own comments
and I stand by them.

I don't mind if you want to drop the #ifdef (which shows how a flag
could be used and the code-size impact). But other than that, I am
firm on this for now. I've already applied it to my tree and a membuf
implementation with tests and without a power-of-two limitation is
important for my current work on distros and expo.

>
> > 2. I sent the first part of the PXE series so you could apply that.
>
> Yes, I should be applying that next week.
>
> > 3. You rejected the second part of this series because it didn't
> > include support for lwip without cmdline. I offered to handle that
> > case later but I'm pretty sure you rejected that too.
>
> That's not how I would characterize it, no. I said you should probably
> focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to
> do the net_loop-alike thing, since he's one of the network custodians
> and the lwip person. I was trying to direct you to where your efforts
> might be most useful but if you insist on instead doing the
> net_loop-alike part and Jerome ack's it, that's fine.

As you know there have been many arguments from the EFI guys about
sandbox and you have already rejected my sandbox-focussed EFI-memory
series for your tree. If I were actually a guru, that wouldn't have
happened.

I see that Jerome has created some tests, which is good.

So really, you should consider applying the full PXE series so that
Jerome can build on that and add support for non-CMDLINE PXE in lwip
in a way that you would like.

>
> > 4. This series is now marked 'changes requested' but the only feedback
> > I see is in the RFC patch.
>
> Yes, rebase to something that can be applied is a change I've requested.
> Because my feedback was "Do you plan to rebase the prerequisite series'
> this requires so that it can be merged?". I would have otherwise merged
> it by now.

OK I sent a PR.

>
> Patchwork reflects mainline status.

OK. I am finding it more and more slow and painful. Since we are
talking about Patchwork, I noticed some patches assigned to me in
there, so I've assigned them to you. I'll try to look there more
often.

Regards,
Simon

On Sat, Mar 15, 2025 at 12:54:25PM +0000, Simon Glass wrote:
> Hi Tom,
> 
> On Fri, 14 Mar 2025 at 16:06, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Fri, Mar 14, 2025 at 02:44:35PM +0000, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
> > > >
> > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > > > is not perfect.
> > > > >
> > > > > With both builds, executing the VESA ROM causes an intermittent hang, at
> > > > > least on some AMD CPUs.
> > > > >
> > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > > > > is done in a way that works on real hardware but not with QEMU. This
> > > > > means that performance is 4-5x slower than it could be, at least on my
> > > > > CPU.
> > > > >
> > > > > We can work around the first problem by using Bochs, which is anyway a
> > > > > better choice than VESA for QEMU. The second can be addressed by using
> > > > > the same descriptor across the jump to long mode.
> > > > >
> > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> > > > >
> > > > > In v3 some e820 patches are included to make booting reliable and avoid
> > > > > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > > > > support memory sizes above 4GB reliably.
> > > >
> > > > Do you plan to rebase the prerequisite series' this requires so that it
> > > > can be merged?
> > >
> > > Here's my understanding of where things are:
> > >
> > > 1. You rejected the membuf series and my replies to try to resolve
> > > that haven't gone anywhere yet. So your tree doesn't have any tests
> > > for that code and still has the old naming.
> >
> > https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not
> > gratuitous summary of why the series as it stands is a step in the wrong
> > direction. Tests are good. They're not a reason to pull an otherwise bad
> > series. This series should be rebased to not depend on that series. The
> > tests from the other series should be split out.
> 
> It's not a bad series, unfortunately. I replied with my own comments
> and I stand by them.
> 
> I don't mind if you want to drop the #ifdef (which shows how a flag
> could be used and the code-size impact). But other than that, I am
> firm on this for now. I've already applied it to my tree and a membuf
> implementation with tests and without a power-of-two limitation is
> important for my current work on distros and expo.

Well, you need to rebase this series without that then as I'm not going
to take something another long time project contributor said was wrong
and offered lots of constructive feedback on.

> > > 2. I sent the first part of the PXE series so you could apply that.
> >
> > Yes, I should be applying that next week.
> >
> > > 3. You rejected the second part of this series because it didn't
> > > include support for lwip without cmdline. I offered to handle that
> > > case later but I'm pretty sure you rejected that too.
> >
> > That's not how I would characterize it, no. I said you should probably
> > focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to
> > do the net_loop-alike thing, since he's one of the network custodians
> > and the lwip person. I was trying to direct you to where your efforts
> > might be most useful but if you insist on instead doing the
> > net_loop-alike part and Jerome ack's it, that's fine.
> 
> As you know there have been many arguments from the EFI guys about
> sandbox and you have already rejected my sandbox-focussed EFI-memory
> series for your tree. If I were actually a guru, that wouldn't have
> happened.
> 
> I see that Jerome has created some tests, which is good.
> 
> So really, you should consider applying the full PXE series so that
> Jerome can build on that and add support for non-CMDLINE PXE in lwip
> in a way that you would like.

I saw that Jerome posted sandbox for lwip as well and was pleased. You
can pickup whatever is left and move forward once both your current
series and his have been merged.

> > > 4. This series is now marked 'changes requested' but the only feedback
> > > I see is in the RFC patch.
> >
> > Yes, rebase to something that can be applied is a change I've requested.
> > Because my feedback was "Do you plan to rebase the prerequisite series'
> > this requires so that it can be merged?". I would have otherwise merged
> > it by now.
> 
> OK I sent a PR.

Eh? v4 as-is needs to be rebased to mainline. That you didn't make it
against mainline but instead your tree is why this wasn't merged
already.

> > Patchwork reflects mainline status.
> 
> OK. I am finding it more and more slow and painful. Since we are
> talking about Patchwork, I noticed some patches assigned to me in
> there, so I've assigned them to you. I'll try to look there more
> often.

I guess you missed the email where I told you what was assigned to you
in patchwork and could easily be put in a pull request by you to me to
get to mainline.

-- 
Tom

Hi Tom,

On Sat, 15 Mar 2025 at 13:57, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Mar 15, 2025 at 12:54:25PM +0000, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 14 Mar 2025 at 16:06, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Fri, Mar 14, 2025 at 02:44:35PM +0000, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 7 Mar 2025 at 14:23, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote:
> > > > >
> > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 but it
> > > > > > is not perfect.
> > > > > >
> > > > > > With both builds, executing the VESA ROM causes an intermittent hang, at
> > > > > > least on some AMD CPUs.
> > > > > >
> > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode (64-bit)
> > > > > > is done in a way that works on real hardware but not with QEMU. This
> > > > > > means that performance is 4-5x slower than it could be, at least on my
> > > > > > CPU.
> > > > > >
> > > > > > We can work around the first problem by using Bochs, which is anyway a
> > > > > > better choice than VESA for QEMU. The second can be addressed by using
> > > > > > the same descriptor across the jump to long mode.
> > > > > >
> > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64
> > > > > >
> > > > > > In v3 some e820 patches are included to make booting reliable and avoid
> > > > > > ACPI tables being dropped. Also, several MTTR problems are addressed, to
> > > > > > support memory sizes above 4GB reliably.
> > > > >
> > > > > Do you plan to rebase the prerequisite series' this requires so that it
> > > > > can be merged?
> > > >
> > > > Here's my understanding of where things are:
> > > >
> > > > 1. You rejected the membuf series and my replies to try to resolve
> > > > that haven't gone anywhere yet. So your tree doesn't have any tests
> > > > for that code and still has the old naming.
> > >
> > > https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not
> > > gratuitous summary of why the series as it stands is a step in the wrong
> > > direction. Tests are good. They're not a reason to pull an otherwise bad
> > > series. This series should be rebased to not depend on that series. The
> > > tests from the other series should be split out.
> >
> > It's not a bad series, unfortunately. I replied with my own comments
> > and I stand by them.
> >
> > I don't mind if you want to drop the #ifdef (which shows how a flag
> > could be used and the code-size impact). But other than that, I am
> > firm on this for now. I've already applied it to my tree and a membuf
> > implementation with tests and without a power-of-two limitation is
> > important for my current work on distros and expo.
>
> Well, you need to rebase this series without that then as I'm not going
> to take something another long time project contributor said was wrong
> and offered lots of constructive feedback on.

It doesn't affect this series. It is for future work.

We'll see if the LTPC replies to my concerns.

>
> > > > 2. I sent the first part of the PXE series so you could apply that.
> > >
> > > Yes, I should be applying that next week.
> > >
> > > > 3. You rejected the second part of this series because it didn't
> > > > include support for lwip without cmdline. I offered to handle that
> > > > case later but I'm pretty sure you rejected that too.
> > >
> > > That's not how I would characterize it, no. I said you should probably
> > > focus on sandbox + lwip, since you're the sandbox guru and ask Jerome to
> > > do the net_loop-alike thing, since he's one of the network custodians
> > > and the lwip person. I was trying to direct you to where your efforts
> > > might be most useful but if you insist on instead doing the
> > > net_loop-alike part and Jerome ack's it, that's fine.
> >
> > As you know there have been many arguments from the EFI guys about
> > sandbox and you have already rejected my sandbox-focussed EFI-memory
> > series for your tree. If I were actually a guru, that wouldn't have
> > happened.
> >
> > I see that Jerome has created some tests, which is good.
> >
> > So really, you should consider applying the full PXE series so that
> > Jerome can build on that and add support for non-CMDLINE PXE in lwip
> > in a way that you would like.
>
> I saw that Jerome posted sandbox for lwip as well and was pleased. You
> can pickup whatever is left and move forward once both your current
> series and his have been merged.

For now I've just applied it to my tree. I believe my offer of adding
non-CMDLINE lwip immediately after you applied it was a good
compromise, but not good enough, so for now I've decided to just move
on.

>
> > > > 4. This series is now marked 'changes requested' but the only feedback
> > > > I see is in the RFC patch.
> > >
> > > Yes, rebase to something that can be applied is a change I've requested.
> > > Because my feedback was "Do you plan to rebase the prerequisite series'
> > > this requires so that it can be merged?". I would have otherwise merged
> > > it by now.
> >
> > OK I sent a PR.
>
> Eh? v4 as-is needs to be rebased to mainline. That you didn't make it
> against mainline but instead your tree is why this wasn't merged
> already.

I sent a PR for the test series, to try to get that landed in your
tree. At least that will help reduce the diff with new tests. The PR
is the only prereq for v5 of this series (Ubuntu test).

>
> > > Patchwork reflects mainline status.
> >
> > OK. I am finding it more and more slow and painful. Since we are
> > talking about Patchwork, I noticed some patches assigned to me in
> > there, so I've assigned them to you. I'll try to look there more
> > often.
>
> I guess you missed the email where I told you what was assigned to you
> in patchwork and could easily be put in a pull request by you to me to
> get to mainline.

Well let's see how things go over the next few days.

Regards,
SImon