This is not all boards yet, but I send them out so I can go to bed :-)
Here's one for all boards.
Signed-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/mainboard/amd/dbm690t/acpi_tables.c
===
---
On 4/8/10 7:07 PM, Myles Watson wrote:
Here's one for all boards.
Signed-off-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com
Acked-by: Stefan Reinauer ste...@coresystems.de
Index: svn/src/mainboard/amd/dbm690t/acpi_tables.c
On Thu, Apr 8, 2010 at 5:03 PM, Stefan Reinauer ste...@coresystems.dewrote:
On 4/8/10 7:07 PM, Myles Watson wrote:
Here's one for all boards.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Stefan Reinauer ste...@coresystems.de ste...@coresystems.de
Rev. 5384
Index:
I'll ack that.
This is not all boards yet, but I send them out so I can go to bed :-)
ping
I think I missed your patch. I sent one out for review, too.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 3/25/10 11:46 PM, Stefan Reinauer wrote:
On 3/25/10 11:07 PM, Myles Watson wrote:
@@ -273,8 +273,10 @@
acpi_create_facs(facs);
dsdt = (acpi_header_t *) current;
-current += AmlCode.length;
-memcpy((void *) dsdt, AmlCode, AmlCode.length);
+memcpy((void *) dsdt,
On 3/25/10 3:47 PM, Myles Watson wrote:
On 3/24/10 11:02 PM, repository service wrote:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right thing with gcc?
I am told that AmlCode is defined as array of
On Thu, Mar 25, 2010 at 8:52 AM, Stefan Reinauer ste...@coresystems.dewrote:
On 3/25/10 3:47 PM, Myles Watson wrote:
On 3/24/10 11:02 PM, repository service wrote:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right
On Thu, Mar 25, 2010 at 7:56 AM, Myles Watson myle...@gmail.com wrote:
It seems like others must have this problem of needing to force a binary
blob into a struct.
Hi, I've only been following this at a distance. I assume this all
happens after memory is turned on. Why not just have a function
On Thu, Mar 25, 2010 at 7:56 AM, Myles Watson myle...@gmail.com wrote:
It seems like others must have this problem of needing to force a binary
blob into a struct.
Hi, I've only been following this at a distance. I assume this all
happens after memory is turned on. Why not just have a
On 3/25/10 5:18 PM, Myles Watson wrote:
On Thu, Mar 25, 2010 at 7:56 AM, Myles Watson myle...@gmail.com wrote:
It seems like others must have this problem of needing to force a binary
blob into a struct.
Hi, I've only been following this at a distance. I assume this all
On Thu, Mar 25, 2010 at 10:39 AM, Stefan Reinauer ste...@coresystems.dewrote:
On 3/25/10 5:18 PM, Myles Watson wrote:
On Thu, Mar 25, 2010 at 7:56 AM, Myles Watson myle...@gmail.com
wrote:
It seems like others must have this problem of needing to force a
binary
blob into a struct.
On 3/25/10 5:45 PM, Myles Watson wrote:
The reason I object to the void* method was that it just masked the
problem so that gcc couldn't spot it. Casting to void* and back to a
struct seems equivalent to just having it declared two different ways.
I don't think it's masking the problem. It
On Thu, Mar 25, 2010 at 11:53 AM, Stefan Reinauer ste...@coresystems.dewrote:
On 3/25/10 5:45 PM, Myles Watson wrote:
The reason I object to the void* method was that it just masked the problem
so that gcc couldn't spot it. Casting to void* and back to a struct seems
equivalent to just
On 3/25/10 7:54 PM, Myles Watson wrote:
A (maybe too obvious) variant would be to create a binary dsdt
instead of a C file and pack that into CBFS. It would reduce
coreboot size and allow to copy/decompress it right to cbmem
This would be fine with me. It's quite a bit more
On Thu, Mar 25, 2010 at 1:00 PM, Stefan Reinauer ste...@coresystems.dewrote:
On 3/25/10 7:54 PM, Myles Watson wrote:
A (maybe too obvious) variant would be to create a binary dsdt instead of
a C file and pack that into CBFS. It would reduce coreboot size and allow to
copy/decompress it
It seems like others must have this problem of needing to force a binary
blob into a struct.
Just memcpy() it from the blob to the struct. If I remember your
code correctly, you copy it later anyway, so might as well do it
in one step.
Segher
--
coreboot mailing list:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right thing with gcc?
I am told that AmlCode is defined as array of (unsigned) char in
some other file. Declaring it as some other type here is not
valid C, and *will* break
On 3/25/10 10:43 PM, Segher Boessenkool wrote:
It seems like others must have this problem of needing to force a binary
blob into a struct.
Just memcpy() it from the blob to the struct. If I remember your
code correctly, you copy it later anyway, so might as well do it
in one step.
On 3/25/10 10:47 PM, Segher Boessenkool wrote:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right thing with gcc?
I am told that AmlCode is defined as array of (unsigned) char in
some other file.
I changed one as an example now...
I guess we could optimize to not copy the header twice, but the header
is really small, so i didn't care to make the code uglier.
I agree.
@@ -273,8 +273,10 @@
acpi_create_facs(facs);
dsdt = (acpi_header_t *) current;
-current +=
I am told that AmlCode is defined as array of (unsigned) char in
some other file. Declaring it as some other type here is not
valid C, and *will* break with GCC, with some options (-combine
or LTO at least) -- it will not compile.
The biggest worry for me is incorrect execution. If
On 3/25/10 11:07 PM, Myles Watson wrote:
I changed one as an example now...
I guess we could optimize to not copy the header twice, but the header
is really small, so i didn't care to make the code uglier.
I agree.
@@ -273,8 +273,10 @@
acpi_create_facs(facs);
dsdt
On 3/25/10 11:07 PM, Myles Watson wrote:
@@ -273,8 +273,10 @@
acpi_create_facs(facs);
dsdt = (acpi_header_t *) current;
-current += AmlCode.length;
-memcpy((void *) dsdt, AmlCode, AmlCode.length);
+memcpy((void *) dsdt, AmlCode, sizeof(acpi_header_t));
+int len =
I am told that AmlCode is defined as array of (unsigned) char in
some other file. Declaring it as some other type here is not
valid C, and *will* break with GCC, with some options (-combine
or LTO at least) -- it will not compile.
The biggest worry for me is incorrect execution. If
Author: myles
Date: Wed Mar 24 23:02:53 2010
New Revision: 5286
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5286
Log:
Get rid of type-punned pointer errors.
Defining AmlCode differently in different source files is a bit ugly...
Creating a void * to do the casting is not exactly
On 3/24/10 11:02 PM, repository service wrote:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right thing with gcc?
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 3/24/10 11:02 PM, repository service wrote:
-extern unsigned char AmlCode[];
+extern const acpi_header_t AmlCode;
And we're positive, this always does the right thing with gcc?
I am told that AmlCode is defined as array of (unsigned) char in
some other file. Declaring it as some other
27 matches
Mail list logo
