Hi Tom,
On Sat, 4 Jan 2025 at 03:26, Tom Rini trini@konsulko.com wrote:
On Fri, Jan 03, 2025 at 12:45:36PM +1300, Simon Glass wrote:
Hi Tom,
On Fri, 3 Jan 2025 at 03:44, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 02, 2025 at 11:08:46AM +1300, Simon Glass wrote:
The current UPL spec[1] has been tidied up and improved over the last year, since U-Boot's original UPL support was written.
This series addresses various issues, with a goal of having U-Boot boot EDK2.
There is still more work to do, but this series gets to the point (on QEMU) where the ACPI tables are required. Further work will be needed to relocate the tables out of the QEMU firmware-filesystem.
[1] git@github.com:UniversalPayload/spec.git commit 3f1450d
Since this is on top of your fork, and not mainline, and you aren't even noting that in your cover letter it's probably not worth the time of everyone you sent this to, to look at.
It applies to -next except for the QEMU script which you rejected. I can't do anything about that. So I think you may have the wrong end of the stick here.
The only thing I can think of is that the UPL series depends on Raymond's bloblist patch [1]. But I was assuming that would be applied at some point and I didn't want to resend someone else's patch. I don't have it in the sjg tree either yet, as I was hoping he would write a test. In fact I would very-much like people to write tests (and docs if needed) without needing to be asked.
Regards, Simon
[1] https://lore.kernel.org/u-boot/CAFLszTjSGqmk8yYYbXFEaFZWFhF8uhj_rNxZz7ship1-...
A 60 part series that includes changes to something that was rejected, and depends on a series from someone else that was changes requested, and is again, 60+ patches, is not at all helpful. Please stop doing this.
As I see it, my only alternatives were to:
a) resend Raymond's patch unchanged (with a note that it is merely for convenience), or b) not send it, knowing that his patch will likely be applied before this series
I chose b. The single, dependent patch is really not an issue, IMO.
I often send large series, e.g. [2]. Sometimes, as with UPL, there is just an enormous amount of work to get through. I really don't like combining patches just to reduce the patch count. But I can split of the pre-req patches (about 30) so I'll do that for v2. Honestly, I was just desperate to get some of the work sent out so it didn't die on the vine.
BTW, please reconsider your objections to the qemu script. I think it might make sense to convert it to Python at some point, but the complexity of building images and running QEMU for different use cases is such that a script makes a lot of sense.
Regards, Simon
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=364775&state=*