I have not found one tool that can obtain the fadt.c and dsdt.c from the machine trough /proc/acpi/fadt and /proc/acpi/dsdt
I have write the two utitilities, if one needs it.
Urbez.
NOTE: you can compile the tools simply written "make genfadt" and "make gendsdt"
Urbez Santana Roma wrote:
I have not found one tool that can obtain the fadt.c and dsdt.c from the machine trough /proc/acpi/fadt and /proc/acpi/dsdt
I have write the two utilities, if one needs it.
Urbez.
NOTE: you can compile the tools simply written "make genfadt" and "make gendsdt"
Cool! Can you repost them with a copyright header and Signed-off-by: line (http://www.coreboot.org/Development_Guidelines)? Then I can give them a permanent home in the repos. I'll try them out in a few minutes.
Question to others, do we want this to be grabbed by externals, in one repo or the other, or just leave in /utils as a separate checkout (with a wiki page)?
Thanks, Corey
On Sun, Jan 27, 2008 at 06:56:09PM -0500, Corey Osgood wrote:
Question to others, do we want this to be grabbed by externals, in one repo or the other, or just leave in /utils as a separate checkout (with a wiki page)?
Isn't utils already externaled into both v2 and v3?
//Peter
Peter Stuge wrote:
On Sun, Jan 27, 2008 at 06:56:09PM -0500, Corey Osgood wrote:
Question to others, do we want this to be grabbed by externals, in one repo or the other, or just leave in /utils as a separate checkout (with a wiki page)?
Isn't utils already externaled into both v2 and v3?
//Peter
Afaik, just the individual utilities are, so we can pick and choose which utilities we want with each repo.
-Corey
On Sun, Jan 27, 2008 at 07:08:10PM -0500, Corey Osgood wrote:
Question to others, do we want this to be grabbed by externals,
Isn't utils already externaled into both v2 and v3?
Afaik, just the individual utilities are, so we can pick and choose which utilities we want with each repo.
Oh - I think that was mostly to be able to exclude some utils that we don't want but don't want to drop.
If mptable and getpir are in, these two might as well be too.
//Peter
Corey Osgood wrote:
Urbez Santana Roma wrote:
I have not found one tool that can obtain the fadt.c and dsdt.c from the machine trough /proc/acpi/fadt and /proc/acpi/dsdt
I have write the two utilities, if one needs it.
Urbez.
NOTE: you can compile the tools simply written "make genfadt" and "make gendsdt"
Cool! Can you repost them with a copyright header and Signed-off-by: line (http://www.coreboot.org/Development_Guidelines)? Then I can give them a permanent home in the repos. I'll try them out in a few minutes.
Ok, just a couple little nuances, but it seems to work fine:
fprintf(w,"#include <string.h>\n"); fprintf(w,"#include <arch/acpi.h>\n\n"); fprintf(w,"void acpi_create_fadt(acpi_fadt_t *fadt,acpi_facs_t*facs,void *dsdt){\n"); fprintf(w," acpi_header_t *header=&(fadt->header);\n\n");
Extra newline at the start of this line please, makes it much clearer.
fprintf(w," memset((void *)fadt,0,sizeof(acpi_fadt_t));\n"); print_acpi_header(w,"fadt->header",FADT.header); fprintf(w,"\nfadt->firmware_ctrl=facs;\n"); fprintf(w,"fadt->dsdt=dsdt;\n\n");
These 2 lines don't tab in like the rest do.
print_u8(w,"fadt->res1",FADT.res1); print_u8(w,"fadt->preferred_pm_profile",FADT.preferred_pm_profile);
[...]
fprintf(w,"\nfadt->x_firmware_ctl_l=facs;\n"); fprintf(w,"fadt->x_firmware_ctl_h=0;\n"); fprintf(w,"fadt->x_dsdt_l=dsdt;\n"); fprintf(w,"fadt->x_dsdt_h=0;\n\n");
Same with these 4.
Thanks for these, it should make the case where we can't distribute factory ACPI tables much easier to deal with.
-Corey
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
El lun, 28-01-2008 a las 10:41 +0100, Rudolf Marek escribió:
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
Yes, i can try, but i have a ugly 'English', :))))
Must i complete the generated *.c files with a line of the follow type???
/*Not distribute this file if you haven't permission.*/
I must add too if us will include these simple tools in the coreboot, the preamble license.
Urbez Santana Roma wrote:
El lun, 28-01-2008 a las 10:41 +0100, Rudolf Marek escribió:
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
Yes, i can try, but i have a ugly 'English', :))))
Must i complete the generated *.c files with a line of the follow type???
/*Not distribute this file if you haven't permission.*/
I must add too if us will include these simple tools in the coreboot, the preamble license.
Perhaps something more along the lines of
/* The content of this file is the intellectual property of its respective owner. * Do not distribute without the permission of the copyright holder. */
-Corey
Ok. The changes are done. Here the attachments. I start yet learning how to write in the wiki :)
Urbez.
El lun, 28-01-2008 a las 12:47 -0500, Corey Osgood escribió:
Urbez Santana Roma wrote:
El lun, 28-01-2008 a las 10:41 +0100, Rudolf Marek escribió:
Hi Urbez,
Please can you add some notes on wiki?
http://www.coreboot.org/ACPI_in_coreboot
Thanks,
Rudolf
Yes, i can try, but i have a ugly 'English', :))))
Must i complete the generated *.c files with a line of the follow type???
/*Not distribute this file if you haven't permission.*/
I must add too if us will include these simple tools in the coreboot, the preamble license.
Perhaps something more along the lines of
/* The content of this file is the intellectual property of its respective owner.
- Do not distribute without the permission of the copyright holder. */
-Corey
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
Regards, Carl-Daniel
For me is good in the unique directory gen_dt, but that isn't for the people important :)))
Urbez.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On 29.01.2008 14:30, urbez@linuxupc.upc.edu wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
For me is good in the unique directory gen_dt, but that isn't for the people important :)))
Do we want to call the merged utility gen_acpi_table or something like that? Together with the SSDT stuff Rudolf is working on, we could maybe combine all of this into one utility.
Regards, Carl-Daniel
Hi,
On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
I'd personally merge them into one tool as they're very small programs. Then invoke the different functionalities with two --foo / --bar switches.
A more descriptive name than gen_dt would also be nice.
Uwe.
On Jan 29, 2008 9:37 AM, Uwe Hermann uwe@hermann-uwe.de wrote:
Hi,
On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
I'd personally merge them into one tool as they're very small programs. Then invoke the different functionalities with two --foo / --bar switches.
Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and also the fadt.c/dsdt.c. No switches yet, but I think we can just add all that stuff later. I've also tried to clean everything up, tabs, etc, etc. I've changed the dsdt line comments to use /**/ style, so the output can be compared with iasl's, but to get a meaning full diff you need to run iasl with optimizations disabled.
On Feb 6, 2008 12:08 AM, Corey Osgood corey.osgood@gmail.com wrote:
On Jan 29, 2008 9:37 AM, Uwe Hermann uwe@hermann-uwe.de wrote:
Hi,
On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
I'd personally merge them into one tool as they're very small programs. Then invoke the different functionalities with two --foo / --bar switches.
Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and also the fadt.c/dsdt.c. No switches yet, but I think we can just add all that stuff later. I've also tried to clean everything up, tabs, etc, etc. I've changed the dsdt line comments to use /**/ style, so the output can be compared with iasl's, but to get a meaning full diff you need to run iasl with optimizations disabled.
And now for the attachment! I also haven't added myself as a copyright holder, since all I did was cleanup and add a trivial function. Here's a sign-off anyway: Signed-off-by: Corey Osgood corey.osgood@gmail.com
On 06.02.2008 06:10, Corey Osgood wrote:
On Feb 6, 2008 12:08 AM, Corey Osgood corey.osgood@gmail.com wrote:
On Jan 29, 2008 9:37 AM, Uwe Hermann uwe@hermann-uwe.de wrote:
On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
I'd personally merge them into one tool as they're very small programs. Then invoke the different functionalities with two --foo / --bar switches.
Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and
I'd like to avoid the hardcode. That way, you can work on copies of these virtual files. This is especially useful if you can't run genacpi on the machine you want to dump.
also the fadt.c/dsdt.c. No switches yet, but I think we can just add all that stuff later. I've also tried to clean everything up, tabs, etc, etc. I've changed the dsdt line comments to use /**/ style, so the output can be compared with iasl's, but to get a meaning full diff you need to run iasl with optimizations disabled.
And now for the attachment! I also haven't added myself as a copyright holder, since all I did was cleanup and add a trivial function. Here's a sign-off anyway: Signed-off-by: Corey Osgood corey.osgood@gmail.com
Thanks for working on the merge! A few comments:
/*
- This file is part of the coreboot project.
- Copyright (C) 2008 Urbez Santana urbez@linuxupc.upc.edu
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <stdio.h> #include <string.h>
typedef unsigned char u8; typedef unsigned long u32;
unsigned long is 64bit on 64bit architectures. You either want unsigned int or you do something like this: typedef uint32_t u32;
typedef unsigned short u16;
typedef struct acpi_gen_regaddr { u8 space_id; u8 bit_width; u8 bit_offset; u8 resv; u32 addrl; u32 addrh; } __attribute__ ((packed)) acpi_addr_t;
/* Generic ACPI Header, provided by (almost) all tables */
typedef struct acpi_table_header /* ACPI common table header */ { char signature [4]; /* ACPI signature (4 ASCII characters) */\ u32 length; /* Length of table, in bytes, including header */\ u8 revision; /* ACPI Specification minor version # */\ u8 checksum; /* To make sum of entire table == 0 */\ char oem_id [6]; /* OEM identification */\ char oem_table_id [8]; /* OEM table identification */\ u32 oem_revision; /* OEM revision number */\ char asl_compiler_id [4]; /* ASL compiler vendor ID */\ u32 asl_compiler_revision; /* ASL compiler revision number */ } __attribute__ ((packed)) acpi_header_t;
typedef struct acpi_fadt { struct acpi_table_header header; u32 firmware_ctrl; u32 dsdt; u8 res1; u8 preferred_pm_profile; u16 sci_int; u32 smi_cmd; u8 acpi_enable; u8 acpi_disable; u8 s4bios_req; u8 pstate_cnt; u32 pm1a_evt_blk; u32 pm1b_evt_blk; u32 pm1a_cnt_blk; u32 pm1b_cnt_blk; u32 pm2_cnt_blk; u32 pm_tmr_blk; u32 gpe0_blk; u32 gpe1_blk; u8 pm1_evt_len; u8 pm1_cnt_len; u8 pm2_cnt_len; u8 pm_tmr_len; u8 gpe0_blk_len; u8 gpe1_blk_len; u8 gpe1_base; u8 cst_cnt; u16 p_lvl2_lat; u16 p_lvl3_lat; u16 flush_size; u16 flush_stride; u8 duty_offset; u8 duty_width; u8 day_alrm; u8 mon_alrm; u8 century; u16 iapc_boot_arch; u8 res2; u32 flags; struct acpi_gen_regaddr reset_reg; u8 reset_value; u8 res3; u8 res4; u8 res5; u32 x_firmware_ctl_l; u32 x_firmware_ctl_h; u32 x_dsdt_l; u32 x_dsdt_h; struct acpi_gen_regaddr x_pm1a_evt_blk; struct acpi_gen_regaddr x_pm1b_evt_blk; struct acpi_gen_regaddr x_pm1a_cnt_blk; struct acpi_gen_regaddr x_pm1b_cnt_blk; struct acpi_gen_regaddr x_pm2_cnt_blk; struct acpi_gen_regaddr x_pm_tmr_blk; struct acpi_gen_regaddr x_gpe0_blk; struct acpi_gen_regaddr x_gpe1_blk; } __attribute__ ((packed)) acpi_fadt_t;
struct acpi_fadt FADT;
char strn[64]; char *stri(int i, const char *str) { strncpy(strn, str, i); strn[i] = 0; return strn; }
void print_u8(FILE *w, char *name, u8 val) { fprintf(w, " %s = 0x%02x;\n", name, (int)val); }
void print_u16(FILE *w,char *name, u16 val) { fprintf(w, " %s = 0x%04x;\n", name, (int)val); }
void print_u32(FILE *w, char *name, u32 val) { fprintf(w, " %s = 0x%08lx;\n", name, val); }
void print_acpi_gen_regaddr(FILE *w, char *name, acpi_addr_t val) { char name2[256]; sprintf(name2, "%s.space_id", name); print_u8(w, name2, val.space_id); sprintf(name2, "%s.bit_width", name); print_u8(w, name2, val.bit_width); sprintf(name2, "%s.bit_offset", name); print_u8(w, name2, val.bit_offset); sprintf(name2, "%s.resv", name); print_u8(w, name2, val.resv); sprintf(name2, "%s.addrl", name); print_u32(w, name2, val.addrl); sprintf(name2, "%s.addrh", name); print_u32(w, name2, val.addrh); }
void print_acpi_header(FILE *w,char *name,acpi_header_t val)
Space after comma? Same in other places.
{ char name2[256]; fprintf(w, " memcpy(header->signature, "%s", 4);\n", stri(4, val.signature)); fprintf(w, " header->length = 0x%08x;\n", val.length); fprintf(w, " header->revision = 0x%02x;\n", (int)val.revision); fprintf(w, " memcpy(header->oem_id, "%s", 6);\n", stri(6, val.oem_id)); fprintf(w, " memcpy(header->oem_table_id, "%s", 8);\n", stri(8, val.oem_table_id)); fprintf(w, " header->oem_revision = 0x%08x;\n", val.oem_revision); fprintf(w, " memcpy(header->asl_compiler_id, "%s", 4);\n", stri(4,val.asl_compiler_id)); fprintf(w, " header->asl_compiler_revision = 0x%08x;\n", val.asl_compiler_revision); }
int genfadt(void) { FILE *r,*w; int len; int off; int i; unsigned char buf[8];
r = fopen("/proc/acpi/fadt", "rb"); if(!r) { printf("Could not open /proc/acpi/dsdt, are you root?\n");
You mean fadt here.
return 0;} w = fopen("fadt.c", "wb"); if(!w) { printf("Could not write fadt.c\n"); return 0; } fprintf(w, "/* Intel ACPI Component Architecture\n" " * File generated by genfadt\n" " * The content of this file is the intellectual property of its \n" " * respective owner.\n" " * Do not distribute without the permission of the copyright holder.\n" " */\n\n\n"); len = fread(&FADT, 1, sizeof(FADT), r);
fprintf(w, "#include <string.h>\n"); fprintf(w, "#include <arch/acpi.h>\n\n"); fprintf(w, "void acpi_create_fadt(acpi_fadt_t *fadt,acpi_facs_t *facs,void *dsdt) {\n\n"); fprintf(w, " acpi_header_t *header = &(fadt->header);\n\n"); fprintf(w, " memset((void *)fadt, 0, sizeof(acpi_fadt_t));\n");
print_acpi_header(w, "fadt->header", FADT.header); fprintf(w, "\n fadt->firmware_ctrl = facs;\n"); fprintf(w, " fadt->dsdt = dsdt;\n\n"); print_u8(w, "fadt->res1", FADT.res1); print_u8(w, "fadt->preferred_pm_profile", FADT.preferred_pm_profile); print_u16(w, "fadt->sci_int", FADT.sci_int); print_u32(w, "fadt->smi_cmd", FADT.smi_cmd); print_u8(w, "fadt->acpi_enable", FADT.acpi_enable); print_u8(w, "fadt->acpi_disable", FADT.acpi_disable); print_u8(w, "fadt->s4bios_req", FADT.s4bios_req); print_u8(w, "fadt->pstate_cnt", FADT.pstate_cnt); print_u32(w, "fadt->pm1a_evt_blk", FADT.pm1a_evt_blk); print_u32(w, "fadt->pm1b_evt_blk", FADT.pm1b_evt_blk); print_u32(w, "fadt->pm1a_cnt_blk", FADT.pm1a_cnt_blk); print_u32(w, "fadt->pm1b_cnt_blk", FADT.pm1b_cnt_blk); print_u32(w, "fadt->pm2_cnt_blk", FADT.pm2_cnt_blk); print_u32(w, "fadt->pm_tmr_blk", FADT.pm_tmr_blk); print_u32(w, "fadt->gpe0_blk", FADT.gpe0_blk); print_u32(w, "fadt->gpe1_blk", FADT.gpe1_blk); print_u8(w, "fadt->pm1_evt_len", FADT.pm1_evt_len); print_u8(w, "fadt->pm1_cnt_len", FADT.pm1_cnt_len); print_u8(w, "fadt->pm2_cnt_len", FADT.pm2_cnt_len); print_u8(w, "fadt->pm_tmr_len", FADT.pm_tmr_len); print_u8(w, "fadt->gpe0_blk_len", FADT.gpe0_blk_len); print_u8(w, "fadt->gpe1_blk_len", FADT.gpe1_blk_len); print_u8(w, "fadt->gpe1_base", FADT.gpe1_base); print_u8(w, "fadt->cst_cnt", FADT.cst_cnt); print_u16(w, "fadt->p_lvl2_lat", FADT.p_lvl2_lat); print_u16(w, "fadt->p_lvl3_lat", FADT.p_lvl3_lat); print_u16(w, "fadt->flush_size", FADT.flush_size); print_u16(w, "fadt->flush_stride", FADT.flush_stride); print_u8(w, "fadt->duty_offset", FADT.duty_offset); print_u8(w, "fadt->duty_width", FADT.duty_width); print_u8(w, "fadt->day_alrm", FADT.day_alrm); print_u8(w, "fadt->mon_alrm", FADT.mon_alrm); print_u8(w, "fadt->century", FADT.century); print_u16(w, "fadt->iapc_boot_arch", FADT.iapc_boot_arch); print_u8(w, "fadt->res2", FADT.res2); print_u32(w, "fadt->flags", FADT.flags); print_acpi_gen_regaddr(w, "fadt->reset_reg", FADT.reset_reg); print_u8(w, "fadt->reset_value", FADT.reset_value); print_u8(w, "fadt->res3", FADT.res3); print_u8(w, "fadt->res4", FADT.res4); print_u8(w, "fadt->res5", FADT.res5); fprintf(w, "\n fadt->x_firmware_ctl_l = facs;\n"); fprintf(w, " fadt->x_firmware_ctl_h = 0;\n"); fprintf(w, " fadt->x_dsdt_l = dsdt;\n"); fprintf(w, " fadt->x_dsdt_h = 0;\n\n"); print_acpi_gen_regaddr(w, "fadt->x_pm1a_evt_blk", FADT.x_pm1a_evt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1b_evt_blk", FADT.x_pm1b_evt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1a_cnt_blk", FADT.x_pm1a_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1b_cnt_blk", FADT.x_pm1b_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm2_cnt_blk", FADT.x_pm2_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm_tmr_blk", FADT.x_pm_tmr_blk); print_acpi_gen_regaddr(w, "fadt->x_gpe0_blk", FADT.x_gpe0_blk); print_acpi_gen_regaddr(w, "fadt->x_gpe1_blk", FADT.x_gpe1_blk);
fprintf(w, "\n header->checksum = acpi_checksum((void *)fadt, sizeof(acpi_fadt_t));\n}\n");
fclose(w); fclose(r); return 1; }
int gendsdt(void) { FILE *r,*w; //r = /proc/.. w = dsdt.c int len; int off; int i; unsigned char buf[8];
r = fopen("/proc/acpi/dsdt", "rb"); if(!r) { printf("Could not open /proc/acpi/dsdt, are you root?\n"); return 0; } w = fopen("dsdt.c", "wb"); if(!w) { printf("Could not write dsdt.c\n"); return 0; }
fprintf(w, "/* Intel ACPI Component Architecture\n" " * File generated by gendsdt\n" " * The content of this file is the intellectual property of its \n" " * respective owner.\n" " * Do not distribute without the permission of the copyright holder.\n" " */\n\n\n"); fprintf(w, "unsigned char AmlCode[] =\n{\n"); off = 0; while(!feof(r)) { len = fread(buf, 1, 8, r); if (len <= 0) break; fprintf(w, " "); for (i = 0; i < len; i++) fprintf(w, "0x%02x,", (int)buf[i]); fprintf(w, " /* %08x "", off); for (i = 0; i < len; i++) fprintf(w, "%c", (buf[i] >= 32 && buf[i] < 127) ? buf[i] : '.'); fprintf(w, "" */\n"); off += len; } fprintf(w, "};\n"); fclose(w); fclose(r); return 1; }
int main(void) { if(!gendsdt()) return 0; if(!genfadt()) return 0; }
Regards, Carl-Daniel
Corey? I'd like to commit this in the next few days to make sure the code does not get lost.
Regards, Carl-Daniel
On 06.02.2008 14:12, Carl-Daniel Hailfinger wrote:
On 06.02.2008 06:10, Corey Osgood wrote:
On Feb 6, 2008 12:08 AM, Corey Osgood corey.osgood@gmail.com wrote:
On Jan 29, 2008 9:37 AM, Uwe Hermann uwe@hermann-uwe.de wrote:
On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
On 28.01.2008 23:16, Urbez Santana Roma wrote:
Ok. The changes are done. Here the attachments.
Great, thanks! I'd like to have them committed as soon as possible.
Where do we want to store these utilities? util/gen_dt or separate directories for both of them?
I'd personally merge them into one tool as they're very small programs. Then invoke the different functionalities with two --foo / --bar switches.
Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and
I'd like to avoid the hardcode. That way, you can work on copies of these virtual files. This is especially useful if you can't run genacpi on the machine you want to dump.
also the fadt.c/dsdt.c. No switches yet, but I think we can just add all that stuff later. I've also tried to clean everything up, tabs, etc, etc. I've changed the dsdt line comments to use /**/ style, so the output can be compared with iasl's, but to get a meaning full diff you need to run iasl with optimizations disabled.
And now for the attachment! I also haven't added myself as a copyright holder, since all I did was cleanup and add a trivial function. Here's a sign-off anyway: Signed-off-by: Corey Osgood corey.osgood@gmail.com
Thanks for working on the merge! A few comments:
/*
- This file is part of the coreboot project.
- Copyright (C) 2008 Urbez Santana urbez@linuxupc.upc.edu
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <stdio.h> #include <string.h>
typedef unsigned char u8; typedef unsigned long u32;
unsigned long is 64bit on 64bit architectures. You either want unsigned int or you do something like this: typedef uint32_t u32;
typedef unsigned short u16;
typedef struct acpi_gen_regaddr { u8 space_id; u8 bit_width; u8 bit_offset; u8 resv; u32 addrl; u32 addrh; } __attribute__ ((packed)) acpi_addr_t;
/* Generic ACPI Header, provided by (almost) all tables */
typedef struct acpi_table_header /* ACPI common table header */ { char signature [4]; /* ACPI signature (4 ASCII characters) */\ u32 length; /* Length of table, in bytes, including header */\ u8 revision; /* ACPI Specification minor version # */\ u8 checksum; /* To make sum of entire table == 0 */\ char oem_id [6]; /* OEM identification */\ char oem_table_id [8]; /* OEM table identification */\ u32 oem_revision; /* OEM revision number */\ char asl_compiler_id [4]; /* ASL compiler vendor ID */\ u32 asl_compiler_revision; /* ASL compiler revision number */ } __attribute__ ((packed)) acpi_header_t;
typedef struct acpi_fadt { struct acpi_table_header header; u32 firmware_ctrl; u32 dsdt; u8 res1; u8 preferred_pm_profile; u16 sci_int; u32 smi_cmd; u8 acpi_enable; u8 acpi_disable; u8 s4bios_req; u8 pstate_cnt; u32 pm1a_evt_blk; u32 pm1b_evt_blk; u32 pm1a_cnt_blk; u32 pm1b_cnt_blk; u32 pm2_cnt_blk; u32 pm_tmr_blk; u32 gpe0_blk; u32 gpe1_blk; u8 pm1_evt_len; u8 pm1_cnt_len; u8 pm2_cnt_len; u8 pm_tmr_len; u8 gpe0_blk_len; u8 gpe1_blk_len; u8 gpe1_base; u8 cst_cnt; u16 p_lvl2_lat; u16 p_lvl3_lat; u16 flush_size; u16 flush_stride; u8 duty_offset; u8 duty_width; u8 day_alrm; u8 mon_alrm; u8 century; u16 iapc_boot_arch; u8 res2; u32 flags; struct acpi_gen_regaddr reset_reg; u8 reset_value; u8 res3; u8 res4; u8 res5; u32 x_firmware_ctl_l; u32 x_firmware_ctl_h; u32 x_dsdt_l; u32 x_dsdt_h; struct acpi_gen_regaddr x_pm1a_evt_blk; struct acpi_gen_regaddr x_pm1b_evt_blk; struct acpi_gen_regaddr x_pm1a_cnt_blk; struct acpi_gen_regaddr x_pm1b_cnt_blk; struct acpi_gen_regaddr x_pm2_cnt_blk; struct acpi_gen_regaddr x_pm_tmr_blk; struct acpi_gen_regaddr x_gpe0_blk; struct acpi_gen_regaddr x_gpe1_blk; } __attribute__ ((packed)) acpi_fadt_t;
struct acpi_fadt FADT;
char strn[64]; char *stri(int i, const char *str) { strncpy(strn, str, i); strn[i] = 0; return strn; }
void print_u8(FILE *w, char *name, u8 val) { fprintf(w, " %s = 0x%02x;\n", name, (int)val); }
void print_u16(FILE *w,char *name, u16 val) { fprintf(w, " %s = 0x%04x;\n", name, (int)val); }
void print_u32(FILE *w, char *name, u32 val) { fprintf(w, " %s = 0x%08lx;\n", name, val); }
void print_acpi_gen_regaddr(FILE *w, char *name, acpi_addr_t val) { char name2[256]; sprintf(name2, "%s.space_id", name); print_u8(w, name2, val.space_id); sprintf(name2, "%s.bit_width", name); print_u8(w, name2, val.bit_width); sprintf(name2, "%s.bit_offset", name); print_u8(w, name2, val.bit_offset); sprintf(name2, "%s.resv", name); print_u8(w, name2, val.resv); sprintf(name2, "%s.addrl", name); print_u32(w, name2, val.addrl); sprintf(name2, "%s.addrh", name); print_u32(w, name2, val.addrh); }
void print_acpi_header(FILE *w,char *name,acpi_header_t val)
Space after comma? Same in other places.
{ char name2[256]; fprintf(w, " memcpy(header->signature, "%s", 4);\n", stri(4, val.signature)); fprintf(w, " header->length = 0x%08x;\n", val.length); fprintf(w, " header->revision = 0x%02x;\n", (int)val.revision); fprintf(w, " memcpy(header->oem_id, "%s", 6);\n", stri(6, val.oem_id)); fprintf(w, " memcpy(header->oem_table_id, "%s", 8);\n", stri(8, val.oem_table_id)); fprintf(w, " header->oem_revision = 0x%08x;\n", val.oem_revision); fprintf(w, " memcpy(header->asl_compiler_id, "%s", 4);\n", stri(4,val.asl_compiler_id)); fprintf(w, " header->asl_compiler_revision = 0x%08x;\n", val.asl_compiler_revision); }
int genfadt(void) { FILE *r,*w; int len; int off; int i; unsigned char buf[8];
r = fopen("/proc/acpi/fadt", "rb"); if(!r) { printf("Could not open /proc/acpi/dsdt, are you root?\n");
You mean fadt here.
return 0;} w = fopen("fadt.c", "wb"); if(!w) { printf("Could not write fadt.c\n"); return 0; } fprintf(w, "/* Intel ACPI Component Architecture\n" " * File generated by genfadt\n" " * The content of this file is the intellectual property of its \n" " * respective owner.\n" " * Do not distribute without the permission of the copyright holder.\n" " */\n\n\n"); len = fread(&FADT, 1, sizeof(FADT), r);
fprintf(w, "#include <string.h>\n"); fprintf(w, "#include <arch/acpi.h>\n\n"); fprintf(w, "void acpi_create_fadt(acpi_fadt_t *fadt,acpi_facs_t *facs,void *dsdt) {\n\n"); fprintf(w, " acpi_header_t *header = &(fadt->header);\n\n"); fprintf(w, " memset((void *)fadt, 0, sizeof(acpi_fadt_t));\n");
print_acpi_header(w, "fadt->header", FADT.header); fprintf(w, "\n fadt->firmware_ctrl = facs;\n"); fprintf(w, " fadt->dsdt = dsdt;\n\n"); print_u8(w, "fadt->res1", FADT.res1); print_u8(w, "fadt->preferred_pm_profile", FADT.preferred_pm_profile); print_u16(w, "fadt->sci_int", FADT.sci_int); print_u32(w, "fadt->smi_cmd", FADT.smi_cmd); print_u8(w, "fadt->acpi_enable", FADT.acpi_enable); print_u8(w, "fadt->acpi_disable", FADT.acpi_disable); print_u8(w, "fadt->s4bios_req", FADT.s4bios_req); print_u8(w, "fadt->pstate_cnt", FADT.pstate_cnt); print_u32(w, "fadt->pm1a_evt_blk", FADT.pm1a_evt_blk); print_u32(w, "fadt->pm1b_evt_blk", FADT.pm1b_evt_blk); print_u32(w, "fadt->pm1a_cnt_blk", FADT.pm1a_cnt_blk); print_u32(w, "fadt->pm1b_cnt_blk", FADT.pm1b_cnt_blk); print_u32(w, "fadt->pm2_cnt_blk", FADT.pm2_cnt_blk); print_u32(w, "fadt->pm_tmr_blk", FADT.pm_tmr_blk); print_u32(w, "fadt->gpe0_blk", FADT.gpe0_blk); print_u32(w, "fadt->gpe1_blk", FADT.gpe1_blk); print_u8(w, "fadt->pm1_evt_len", FADT.pm1_evt_len); print_u8(w, "fadt->pm1_cnt_len", FADT.pm1_cnt_len); print_u8(w, "fadt->pm2_cnt_len", FADT.pm2_cnt_len); print_u8(w, "fadt->pm_tmr_len", FADT.pm_tmr_len); print_u8(w, "fadt->gpe0_blk_len", FADT.gpe0_blk_len); print_u8(w, "fadt->gpe1_blk_len", FADT.gpe1_blk_len); print_u8(w, "fadt->gpe1_base", FADT.gpe1_base); print_u8(w, "fadt->cst_cnt", FADT.cst_cnt); print_u16(w, "fadt->p_lvl2_lat", FADT.p_lvl2_lat); print_u16(w, "fadt->p_lvl3_lat", FADT.p_lvl3_lat); print_u16(w, "fadt->flush_size", FADT.flush_size); print_u16(w, "fadt->flush_stride", FADT.flush_stride); print_u8(w, "fadt->duty_offset", FADT.duty_offset); print_u8(w, "fadt->duty_width", FADT.duty_width); print_u8(w, "fadt->day_alrm", FADT.day_alrm); print_u8(w, "fadt->mon_alrm", FADT.mon_alrm); print_u8(w, "fadt->century", FADT.century); print_u16(w, "fadt->iapc_boot_arch", FADT.iapc_boot_arch); print_u8(w, "fadt->res2", FADT.res2); print_u32(w, "fadt->flags", FADT.flags); print_acpi_gen_regaddr(w, "fadt->reset_reg", FADT.reset_reg); print_u8(w, "fadt->reset_value", FADT.reset_value); print_u8(w, "fadt->res3", FADT.res3); print_u8(w, "fadt->res4", FADT.res4); print_u8(w, "fadt->res5", FADT.res5); fprintf(w, "\n fadt->x_firmware_ctl_l = facs;\n"); fprintf(w, " fadt->x_firmware_ctl_h = 0;\n"); fprintf(w, " fadt->x_dsdt_l = dsdt;\n"); fprintf(w, " fadt->x_dsdt_h = 0;\n\n"); print_acpi_gen_regaddr(w, "fadt->x_pm1a_evt_blk", FADT.x_pm1a_evt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1b_evt_blk", FADT.x_pm1b_evt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1a_cnt_blk", FADT.x_pm1a_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm1b_cnt_blk", FADT.x_pm1b_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm2_cnt_blk", FADT.x_pm2_cnt_blk); print_acpi_gen_regaddr(w, "fadt->x_pm_tmr_blk", FADT.x_pm_tmr_blk); print_acpi_gen_regaddr(w, "fadt->x_gpe0_blk", FADT.x_gpe0_blk); print_acpi_gen_regaddr(w, "fadt->x_gpe1_blk", FADT.x_gpe1_blk);
fprintf(w, "\n header->checksum = acpi_checksum((void *)fadt, sizeof(acpi_fadt_t));\n}\n");
fclose(w); fclose(r); return 1; }
int gendsdt(void) { FILE *r,*w; //r = /proc/.. w = dsdt.c int len; int off; int i; unsigned char buf[8];
r = fopen("/proc/acpi/dsdt", "rb"); if(!r) { printf("Could not open /proc/acpi/dsdt, are you root?\n"); return 0; } w = fopen("dsdt.c", "wb"); if(!w) { printf("Could not write dsdt.c\n"); return 0; }
fprintf(w, "/* Intel ACPI Component Architecture\n" " * File generated by gendsdt\n" " * The content of this file is the intellectual property of its \n" " * respective owner.\n" " * Do not distribute without the permission of the copyright holder.\n" " */\n\n\n"); fprintf(w, "unsigned char AmlCode[] =\n{\n"); off = 0; while(!feof(r)) { len = fread(buf, 1, 8, r); if (len <= 0) break; fprintf(w, " "); for (i = 0; i < len; i++) fprintf(w, "0x%02x,", (int)buf[i]); fprintf(w, " /* %08x "", off); for (i = 0; i < len; i++) fprintf(w, "%c", (buf[i] >= 32 && buf[i] < 127) ? buf[i] : '.'); fprintf(w, "" */\n"); off += len; } fprintf(w, "};\n"); fclose(w); fclose(r); return 1; }
int main(void) { if(!gendsdt()) return 0; if(!genfadt()) return 0; }
Regards, Carl-Daniel
On Thu, 2008-02-28 at 00:45 +0100, Carl-Daniel Hailfinger wrote:
Corey? I'd like to commit this in the next few days to make sure the code does not get lost.
Regards, Carl-Daniel
Here's a new version that I hope takes care of everything except the hardcode, which I don't have the time/patience to take care of atm.
Signed-off-by: Corey Osgood corey.osgood@gmail.com
On 06.02.2008 14:12, Carl-Daniel Hailfinger wrote:
On 06.02.2008 06:10, Corey Osgood wrote:
On Feb 6, 2008 12:08 AM, Corey Osgood corey.osgood@gmail.com wrote:
Here's a very dumb combination of the two utilities, it hardcodes /proc/acpi/xxx, since I can't think of any reason they'd be different, and
I'd like to avoid the hardcode. That way, you can work on copies of these virtual files. This is especially useful if you can't run genacpi on the machine you want to dump.
On 28.02.2008 08:55, Corey Osgood wrote:
On Thu, 2008-02-28 at 00:45 +0100, Carl-Daniel Hailfinger wrote:
Corey? I'd like to commit this in the next few days to make sure the code does not get lost.
Regards, Carl-Daniel
Here's a new version that I hope takes care of everything except the hardcode, which I don't have the time/patience to take care of atm.
New version without hardcode attached.
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
We may want to rewrite genfadt in a way where all constant members of fadt are initialized at compile time instead of at run time. This probably even decreases the size of the binary and improves speed at run time.
Regards, Carl-Daniel
On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:
On 28.02.2008 08:55, Corey Osgood wrote:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
We may want to rewrite genfadt in a way where all constant members of fadt are initialized at compile time instead of at run time. This probably even decreases the size of the binary and improves speed at run time.
The more I look at the code, the less I believe the two tools with completely different purposes should be in one file. If you look at flashrom and superiotool and their modular multi-file structure even though they have only one purpose, the merging of genfadt and gendsdt is really the wrong thing to do.
I hereby retract my signoff until we have discussed whether the merge makes sense for any reason besides disliking small utilities.
Regards, Carl-Daniel
On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:
On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:
On 28.02.2008 08:55, Corey Osgood wrote:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
We may want to rewrite genfadt in a way where all constant members of fadt are initialized at compile time instead of at run time. This probably even decreases the size of the binary and improves speed at run time.
The more I look at the code, the less I believe the two tools with completely different purposes should be in one file. If you look at
Maybe not one file (but I think it's fine too), but definately one project/directory and one binary (which can be invoked with multiple switches). Any ACPI-related functionality should we hack up should be in one tool IMO.
I hereby retract my signoff until we have discussed whether the merge makes sense for any reason besides disliking small utilities.
It does IMO. Also, why should we keep them separate? There's no advantage in doing that, it only needlessly increases the number of small tools coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
Uwe.
On 28.02.2008 21:22, Uwe Hermann wrote:
On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:
On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:
On 28.02.2008 08:55, Corey Osgood wrote:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
We may want to rewrite genfadt in a way where all constant members of fadt are initialized at compile time instead of at run time. This probably even decreases the size of the binary and improves speed at run time.
The more I look at the code, the less I believe the two tools with completely different purposes should be in one file. If you look at
Maybe not one file (but I think it's fine too), but definately one project/directory and one binary (which can be invoked with multiple switches). Any ACPI-related functionality should we hack up should be in one tool IMO.
One directory is OK with me. util/gen_acpi or something like that. However, the approach to have every possible acpi-related function in one binary is definitely a non-starter for me. Remember the Unix style of small tools doing small things? sed and grep are definitely related, but nobody (except maybe busybox folks) would argue to have them in one binary. In fact, sed and grep functionality is overlapping more than genfadt and gendsdt. Then again, having "stringtool --grep", "stringtool --sed" and "stringtool --cut" instead of grep, sed and cut would surely be fun.
I hereby retract my signoff until we have discussed whether the merge makes sense for any reason besides disliking small utilities.
It does IMO. Also, why should we keep them separate? There's no advantage in doing that, it only needlessly increases the number of small tools coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
See above. Plus, "gen_acpi --dsdt" is not simpler than "gendsdt". If you really want to make this conform to your definition of simple, merge genacpi and gendsdt into iasl and be happy. Maybe merge flashrom and superiotool as well. Or merge superiotool into dtc.
Apologies for changing your argument from above, but it fits nicely: Also, why should we merge them together? There's no advantage in doing that, it only needlessly increases the number of command line switches coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
Regards, Carl-Daniel
On Thu, Feb 28, 2008 at 3:40 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 28.02.2008 21:22, Uwe Hermann wrote:
On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:
On 28.02.2008 12:52, Carl-Daniel Hailfinger wrote:
On 28.02.2008 08:55, Corey Osgood wrote:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Signed-off-by: Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006@gmx.net>
We may want to rewrite genfadt in a way where all constant members of fadt are initialized at compile time instead of at run time. This probably even decreases the size of the binary and improves speed at run time.
The more I look at the code, the less I believe the two tools with completely different purposes should be in one file. If you look at
Maybe not one file (but I think it's fine too), but definately one project/directory and one binary (which can be invoked with multiple switches). Any ACPI-related functionality should we hack up should be in one tool IMO.
One directory is OK with me. util/gen_acpi or something like that. However, the approach to have every possible acpi-related function in one binary is definitely a non-starter for me. Remember the Unix style of small tools doing small things? sed and grep are definitely related, but nobody (except maybe busybox folks) would argue to have them in one binary. In fact, sed and grep functionality is overlapping more than genfadt and gendsdt. Then again, having "stringtool --grep", "stringtool --sed" and "stringtool --cut" instead of grep, sed and cut would surely be fun.
I hereby retract my signoff until we have discussed whether the merge makes sense for any reason besides disliking small utilities.
It does IMO. Also, why should we keep them separate? There's no advantage in doing that, it only needlessly increases the number of small tools coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
See above. Plus, "gen_acpi --dsdt" is not simpler than "gendsdt". If you really want to make this conform to your definition of simple, merge genacpi and gendsdt into iasl and be happy. Maybe merge flashrom and superiotool as well. Or merge superiotool into dtc.
Apologies for changing your argument from above, but it fits nicely: Also, why should we merge them together? There's no advantage in doing that, it only needlessly increases the number of command line switches coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
Regards, Carl-Daniel
This was how I'd envisioned it: genacpi - make both tables, with hardcoded paths genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional parameters fadt works the same way.
Call me crazy, but I'd be willing to be 90% of coreboot users, especially non-developers, just want both tables in one simple step, that's why that's what I focused on. Most of the advanced users will probably still use iasl anyways, since gendsdt/fadt/acpi provides absolutely NO optimizations (read: bigger) nor does it do any checking of whether or not the ACPI tables it creates are anywhere near valid.
-Corey
On 29.02.2008 06:23, Corey Osgood wrote:
On Thu, Feb 28, 2008 at 3:40 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 28.02.2008 21:22, Uwe Hermann wrote:
On Thu, Feb 28, 2008 at 06:18:04PM +0100, Carl-Daniel Hailfinger wrote:
One directory is OK with me. util/gen_acpi or something like that. However, the approach to have every possible acpi-related function in one binary is definitely a non-starter for me. Remember the Unix style of small tools doing small things? sed and grep are definitely related, but nobody (except maybe busybox folks) would argue to have them in one binary. In fact, sed and grep functionality is overlapping more than genfadt and gendsdt. Then again, having "stringtool --grep", "stringtool --sed" and "stringtool --cut" instead of grep, sed and cut would surely be fun.
I hereby retract my signoff until we have discussed whether the merge makes sense for any reason besides disliking small utilities.
It does IMO. Also, why should we keep them separate? There's no advantage in doing that, it only needlessly increases the number of small tools coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
See above. Plus, "gen_acpi --dsdt" is not simpler than "gendsdt". If you really want to make this conform to your definition of simple, merge genacpi and gendsdt into iasl and be happy. Maybe merge flashrom and superiotool as well. Or merge superiotool into dtc.
Apologies for changing your argument from above, but it fits nicely: Also, why should we merge them together? There's no advantage in doing that, it only needlessly increases the number of command line switches coreboot users are confronted with. Let's make it simpler for users rather than more confusing.
This was how I'd envisioned it: genacpi - make both tables, with hardcoded paths genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional parameters fadt works the same way.
Can we at least agree on the name of the directory where the tool(s) should live? Should we call it gen_acpi or genacpi? I'd say you decide on the name, add a signoff to the act of directory creation and I'll ack and commit (the directory creation). That will allow us to pull the directory into v2 and v3 with svn:externals and we at least have the infrastructure in place.
Call me crazy, but I'd be willing to be 90% of coreboot users, especially non-developers, just want both tables in one simple step, that's why that's what I focused on. Most of the advanced users will probably still use iasl anyways, since gendsdt/fadt/acpi provides absolutely NO optimizations (read: bigger) nor does it do any checking of whether or not the ACPI tables it creates are anywhere near valid.
Please note that iasl can't perform any of the functions of gendsdt/genfadt and vice versa. The inner workings of genfadt also differ from those of gendsdt: gendsdt just creates a file containing a char array with the AML DSDT (and we probably should rename it to embed_dsdt or include_dsdt), while genfadt generates code modifying the FADT at runtime. If you really want to have genfadt and gendsdt in one binary, let's at least keep the source files separate. And there's one really interesting question: How should we integrate the tool Rudulf is writing at the moment? His tool generates the powernow part of the DSDT, but it outputs ASL, not a char array containing AML.
Regards, Carl-Daniel
On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
This was how I'd envisioned it: genacpi - make both tables, with hardcoded paths genacpi -d/--dsdt [INFILE] [OUTFILE] - make the dsdt, with optional parameters fadt works the same way.
Can we at least agree on the name of the directory where the tool(s) should live? Should we call it gen_acpi or genacpi? I'd say you decide
genacpi sounds good.
Uwe.
On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
Please note that iasl can't perform any of the functions of gendsdt
dumping the dsdt to a file, then iasl -d and iasl -tc will produce the same thing, but with some sort of optimizations. Disabling the optimizations, with -oa should produce exactly the same output as gendsdt, except for whitespace, the copyright header, and some dsdt header info (compiler, etc). You're entirely correct about genfadt vs iasl though, and now you've got me thinking that two utiliities is a better idea.
On Fri, Feb 29, 2008 at 2:56 PM, Uwe Hermann uwe@hermann-uwe.de wrote:
On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
Can we at least agree on the name of the directory where the tool(s) should live? Should we call it gen_acpi or genacpi? I'd say you decide
genacpi sounds good.
Uwe.
Ack. Here's a sign-off to make it with:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
-Corey
On 01.03.2008 07:40, Corey Osgood wrote:
On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
Please note that iasl can't perform any of the functions of gendsdt
dumping the dsdt to a file, then iasl -d and iasl -tc will produce the same thing, but with some sort of optimizations. Disabling the optimizations, with -oa should produce exactly the same output as gendsdt, except for whitespace, the copyright header, and some dsdt header info (compiler, etc).
Sorry, my bad, I didn't know that. Then I vote to drop gendsdt and require use of iasl (plus a sed script/whatever to modify the headers) instead. We need iasl anyway for the stuff Rudolf is working on.
You're entirely correct about genfadt vs iasl though, and now you've got me thinking that two utiliities is a better idea.
At last! I admit I was really stubborn, though you were nice enough to correct me where I was wrong. Thanks!
On Fri, Feb 29, 2008 at 2:56 PM, Uwe Hermann uwe@hermann-uwe.de wrote:
On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
Can we at least agree on the name of the directory where the tool(s) should live? Should we call it gen_acpi or genacpi? I'd say you decide
genacpi sounds good.
Ack. Here's a sign-off to make it with:
Signed-off-by: Corey Osgood corey.osgood@gmail.com
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
and committed in r3120.
Regards, Carl-Daniel
On Sat, Mar 1, 2008 at 10:33 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 01.03.2008 07:40, Corey Osgood wrote:
On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
Please note that iasl can't perform any of the functions of gendsdt
dumping the dsdt to a file, then iasl -d and iasl -tc will produce the
same
thing, but with some sort of optimizations. Disabling the optimizations, with -oa should produce exactly the same output as gendsdt, except for whitespace, the copyright header, and some dsdt header info (compiler,
etc).
Sorry, my bad, I didn't know that. Then I vote to drop gendsdt and require use of iasl (plus a sed script/whatever to modify the headers) instead. We need iasl anyway for the stuff Rudolf is working on.
I'll second that. If you want to make it happen, I'll ack it. I'd do it myself, but I'm trying to get the cn700 back on track.
-Corey
-
Carl-Daniel Hailfinger -
Corey Osgood -
Peter Stuge -
Rudolf Marek -
Urbez Santana Roma -
urbez＠linuxupc.upc.edu
-
Uwe Hermann