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 <tr...@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
signature.asc
Description: PGP signature
