Hi Simon,
On Tue, Apr 28, 2020 at 11:06 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 27 Apr 2020 at 20:42, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Apr 28, 2020 at 10:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 27 Apr 2020 at 19:30, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Apr 28, 2020 at 1:02 AM Simon Glass sjg@chromium.org wrote:
Move the alignment code into acpi_setup_base_tables() so that test and production code are in alignment.
This brings x86/master into line with patch series v8.
Signed-off-by: Simon Glass sjg@chromium.org
arch/x86/lib/acpi_table.c | 5 ----- lib/acpi/acpi_table.c | 7 ++++++- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c index 600bde2f5f..13f1409de8 100644 --- a/arch/x86/lib/acpi_table.c +++ b/arch/x86/lib/acpi_table.c @@ -375,11 +375,6 @@ ulong write_acpi_tables(ulong start_addr) debug("ACPI: Writing ACPI tables at %lx\n", start_addr);
acpi_setup_base_tables(ctx, start);
/** Per ACPI spec, the FACS table address must be aligned to a 64 byte* boundary (Windows checks this, but Linux does not).*/acpi_align64(ctx); debug("ACPI: * FACS\n"); facs = ctx->current;diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c index 5abf1cad50..1c253af3bf 100644 --- a/lib/acpi/acpi_table.c +++ b/lib/acpi/acpi_table.c @@ -145,7 +145,7 @@ int acpi_add_table(struct acpi_ctx *ctx, void *table) }
if (i >= entries_num) {
debug("ACPI: Error: too many tables\n");
log_err("ACPI: Error: too many tables\n"); return -E2BIG; }@@ -256,4 +256,9 @@ void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start) acpi_write_rsdp(ctx->rsdp, ctx->rsdt, ctx->xsdt); acpi_write_rsdt(ctx->rsdt); acpi_write_xsdt(ctx->xsdt);
/** Per ACPI spec, the FACS table address must be aligned to a 64 byte* boundary (Windows checks this, but Linux does not).*/acpi_align64(ctx);}
Could you please point out which commit in u-boot-x86/master should squash in this patch to fix the build error on sandbox?
It might be easier to pick up v8 in that case. I think there are three patches that need to change because of conflicts caused by the first one.
So can you pick up the v8 patches? Also you do need to rebase on master because of the str_to_upper patches.
But v8 is a complete new series for part B? I think we'd better re-tag v8 as v1. It's quite confusing.
No I mean the part A series. Let's get that applied and then we will be in a brave new world.
Is the v8 this one? http://patchwork.ozlabs.org/user/todo/uboot/?series=172777
The part A series are already applied, but it has a build error as I mentioned.
I could resent part B as v1 if you like, but note that it has some reviewed-by tags and some v3, etc. comments. The patches languished for quite a while which is why I decided to try to split them up.
Regards, Bin