Re: [coreboot] Fwd: sony vaio pcg sr1k
I have an old motherboard, maybe I should start whit it first. I am really interested in those things you cited, like electronics, low level programming and so on. I think I should get some items like soldering iron etc. The most critical question on my mind is I feel that there is no end for a chip design so you may have to do it every time when you see a new chip. But, anyway, I will try it, since I want to learn it a lot :) On Tue, Jul 21, 2009 at 6:24 AM, Peter Stugepe...@stuge.se wrote: Hi Ahmet, ahmet alper parker wrote: Ok, I feel mad enough :) Is there a documentation/info/video that describes what I should do? An efficient firmware level developer has years of software and ideally also hardware education (autodidact, or otherwise) as well as development experience. That can't really be packaged in a video that can just be clicked on in a web browser. There is however a lot of documentation available online, and of course the source code can be used to learn a lot! There are several presentations about coreboot available online, but they are all somewhat introductory and overviewy, because it is difficult to go into all details in only 40 minutes. The better way to start is typically from the other end - learn all you can about lowlevel PC programming in general, and then focus on coreboot. coreboot isn't a great place to learn everything you need. It can certainly be done, but it will take a very long time. If you have already opened your laptop several times to do some hacking, and you figured out how to do it yourself, I think it could be really interesting to work on coreboot. You would learn about every single pin (there are a thousand or so) on the major chips in your laptop, you would get a soldering iron if you don't already have one and you would learn how to solder surface mount components on the laptop mainboard. You could also help yourself by learning about electronics, voltages and current, in order to turn your laptop (meant for users) into an embedded systems development board (good for firmware level development). This might mostly consist of mechanical (i.e. physical) hacks, to be able to run the system without the case, but that can be very tricky. Also, one more comment, in a previous attempt, I used some tool to enable the virtualization technology of the cpu with hacking it without the own menu of the original bios. I hope this has no harm on bios, correct? That's impossible to say without knowing exactly what the tool did. I would say that if your system still starts and runs, and you notice no problems while running the system, then your BIOS is still OK. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. I wonder what else could cause it to be so slow? It's especially surprising for the memset, which is pretty simple. Does it use movnti for that? We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? I guess I would: 1. Add some little benchmark loops reading/writing different areas a. read ROM time it b. read from RAM (cached area) and time it c. read from RAM (non-cached area) d. write to RAM (cached area) ... 2. disable MTRRs to see if it would go even slower. Sorry that's not much help, but I don't have a fam10 box to try things on. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] HIGH_TABLES support for lbtdump
util/lbtdump in the v2 tree hasn't been updated in a while and I think it may need adaptations for HIGH_TABLES and forwarding. Do we want to rename it to cbtdump or cbtabledump? Any takers? Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
On Tue, Jul 21, 2009 at 06:25:38AM -0600, Myles Watson wrote: Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. I wonder what else could cause it to be so slow? It's especially surprising for the memset, which is pretty simple. Does it use movnti for that? It's actually just a plain byte-by-byte assignment in c, see src/lib/memset.c. We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? Hmm, we tried adding it here src/cpu/amd/car/clear_init_ram.c in function set_init_ram_access, which already sets an mtrr. This gets called just before CAR is disabled I think. And then we found the mtrr set in src/cpu/amd/car/cache_as_ram.inc which looks like it *should* do the right thing. But that's assembler of course. I don't suppose there's a way to print debug info from right there? I guess I would: 1. Add some little benchmark loops reading/writing different areas a. read ROM time it b. read from RAM (cached area) and time it c. read from RAM (non-cached area) d. write to RAM (cached area) ... 2. disable MTRRs to see if it would go even slower. Sorry that's not much help, but I don't have a fam10 box to try things on. Thanks - will see if I can try some of these things. Thanks, Ward. -- Ward Vandewege w...@gnu.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [flashrom] [PATCH] external serial flasher protocol support
On 11.07.2009 00:56, Urja Rannikko wrote: On Sun, Jun 28, 2009 at 18:49, Urja Rannikkourja...@gmail.com wrote: Support for an external serial flasher protocol. Supports RS-232, USB serial converters (untested) and TCP streams. Signed-off-by: Urja Rannikko urja...@gmail.com Thank you for reworking the code multiple times in response to reviews. Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net and committed in r656. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] fam10/h8dmr: extreme slowness in CBFS memset /memcpy
On Tue, Jul 21, 2009 at 06:25:38AM -0600, Myles Watson wrote: Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly. I wonder what else could cause it to be so slow? It's especially surprising for the memset, which is pretty simple. Does it use movnti for that? It's actually just a plain byte-by-byte assignment in c, see src/lib/memset.c. It would be interesting to see if you make it 4 bytes at a time if it is 4x faster. We found out after adding an extra MTRR over the flash chip, which did not change anything. Did you disable and re-enable the cache so that the settings take effect? Hmm, we tried adding it here src/cpu/amd/car/clear_init_ram.c in function set_init_ram_access, which already sets an mtrr. I always wondered about that one. The thing that makes it hard to debug is that it will read back correctly even if it hasn't taken effect. Thanks - will see if I can try some of these things. Good luck, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HIGH_TABLES support for lbtdump
On 21.07.2009 14:41 Uhr, Carl-Daniel Hailfinger wrote: util/lbtdump in the v2 tree hasn't been updated in a while and I think it may need adaptations for HIGH_TABLES and forwarding. Do we want to rename it to cbtdump or cbtabledump? Any takers? I suggest we drop it, since nvramtool has the same functionality. -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] HIGH_TABLES support for lbtdump
Stefan Reinauer wrote: util/lbtdump in the v2 tree hasn't been updated in a while I suggest we drop it, since nvramtool has the same functionality. Acked-by: Peter Stuge pe...@stuge.se -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus M2V-MX SE enable MMConfig.
Hi all,
We did together some patch which makes finally a MMCONFIG workable in linux out
of the box. There were two problems. First was that the mmconfig ACPI structure
was empty because of cut and paste (PCI ID of K8M890 is different).
Second problem is now nicely solvable by add_region. Linux expects that the
mmconfig region is found as reserved memory. Otherwise it does not trust it.
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
Acked-by: Luc Verhaegen l...@skynet.be
Thanks to Luc for testing this patch,
Rudolf
diff --git a/src/mainboard/asus/m2v-mx_se/acpi_tables.c b/src/mainboard/asus/m2v-mx_se/acpi_tables.c
index 5c9c1db..6bb23ac 100644
--- a/src/mainboard/asus/m2v-mx_se/acpi_tables.c
+++ b/src/mainboard/asus/m2v-mx_se/acpi_tables.c
@@ -40,7 +40,7 @@ unsigned long acpi_fill_mcfg(unsigned long current)
device_t dev;
struct resource *res;
- dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_K8T890CE_5, 0);
+ dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_K8M890CE_5, 0);
if (!dev)
return current;
diff --git a/src/mainboard/asus/m2v-mx_se/mainboard.c b/src/mainboard/asus/m2v-mx_se/mainboard.c
index c68fe61..d25a8ed 100644
--- a/src/mainboard/asus/m2v-mx_se/mainboard.c
+++ b/src/mainboard/asus/m2v-mx_se/mainboard.c
@@ -22,9 +22,22 @@
#include device/pci_ids.h
#include boot/tables.h
#include chip.h
+#include ../../../southbridge/via/k8t890/k8t890.h
int add_mainboard_resources(struct lb_memory *mem)
{
+ device_t dev;
+
+ dev = dev_find_device(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_K8M890CE_5, 0);
+ if (dev) {
+ struct resource *res =
+ find_resource(dev, K8T890_MMCONFIG_MBAR);
+ if (res)
+ lb_add_memory_range(mem, LB_MEM_RESERVED, res-base,
+ res-size);
+ }
+
#if CONFIG_HAVE_ACPI_RESUME == 1
lb_add_memory_range(mem, LB_MEM_RESERVED,
CONFIG_RAMBASE, ((CONFIG_LB_MEM_TOPK10) - CONFIG_RAMBASE));
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4444 - trunk/coreboot-v2/src/northbridge/amd/amdk8
Author: myles Date: 2009-07-21 20:06:12 +0200 (Tue, 21 Jul 2009) New Revision: Modified: trunk/coreboot-v2/src/northbridge/amd/amdk8/northbridge.c Log: Remove a comment that no longer applies. Trivial. Signed-off-by: Myles Watson myle...@gmail.com Acked-by: Myles Watson myle...@gmail.com Modified: trunk/coreboot-v2/src/northbridge/amd/amdk8/northbridge.c === --- trunk/coreboot-v2/src/northbridge/amd/amdk8/northbridge.c 2009-07-20 19:42:15 UTC (rev 4443) +++ trunk/coreboot-v2/src/northbridge/amd/amdk8/northbridge.c 2009-07-21 18:06:12 UTC (rev ) @@ -475,11 +475,6 @@ report_resource_stored(dev, resource, buf); } -/** - * - * I tried to reuse the resource allocation code in amdk8_set_resource() - * but it is too diffcult to deal with the resource allocation magic. - */ #if CONFIG_CONSOLE_VGA_MULTI == 1 extern device_t vga_pri; // the primary vga device, defined in device.c #endif -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] some more i945 patches
Stefan Reinauer wrote:
See patches
All are:
Acked-by: Peter Stuge pe...@stuge.se
+++ src/pc80/i8259.c (working copy)
..
+void i8259_configure_irq_trigger(int int_num, int is_level_triggered)
..
+ /* Write new values */
+ printk_spew(%s: try to set interrupts 0x%x\n, __func__, int_bits);
+ outb((u8)(int_bits 0xff), ELCR1);
+ outb((u8)(int_bits 8), ELCR2);
+
+#ifdef PARANOID_IRQ_TRIGGERS
+ /* Try reading back the new values. This seems like an error but is not
... */
+ if (inb(ELCR1) != (int_bits 0xff)) {
+ printk_err(%s: lower order bits are wrong: want 0x%x, got
0x%x\n,
+ __func__, (int_bits 0xff), inb(ELCR1));
+ }
+
+ if (inb(ELCR2) != (int_bits 8)) {
+ printk_err(%s: lower order bits are wrong: want 0x%x, got
0x%x\n,
+ __func__, (int_bits8), inb(ELCR2));
+ }
+#endif
Copypaste right? Both of these are not the lower bits.
+++ src/boot/elfboot.c(working copy)
..
- * - After loading an ELF image copy coreboot to the upper half of the
+ * - After loading an ELF image copy coreboot to the top of the
* buffer.
Could fold buffer up onto the previous line.
- * - After loading an ELF image copy coreboot to the upper half of the
+ * - After loading an ELF image copy coreboot to the top of the
* buffer.
..and again. Is this the same code? Could it be reused?
+++ src/cpu/x86/lapic/apic_timer.c(.../trunk/coreboot-v2)
..
+/* NOTE: We use the APIC TIMER register is to hold flags for AP init during
+ * pre-memory init (ROMCC). Don't use init_timer() and udelay is redirected
+ * to udelay_tsc().
+ */
What? We use the .. is to hold flags for ? This text is confusing.
+++ src/arch/i386/boot/acpi.c (working copy)
..
+ memcpy(ssdt-asl_compiler_id, CORE, 4);
..
+ memcpy(header-asl_compiler_id, ASLC, 4);
Is this difference on purpose? Is one static and the other not?
Please explain?
+#define RSDP_NAMERSDP
+#define RSDT_NAMERSDT
+#define HPET_NAMEHPET
+#define MADT_NAMEAPIC
+#define MCFG_NAMEMCFG
+#define SRAT_NAMESRAT
+#define SLIT_NAMESLIT
+#define SSDT_NAMESSDT
+#define FACS_NAMEFACS
+#define FADT_NAMEFACP
+#define XSDT_NAMEXSDT
Does it really make sense to use defines for these names?
+// Misnomer, the NAME above is the 4 byte signature, this (TABLE) is the
+// OEM_TABLE_ID.
+//
+#define ACPI_TABLE_CREATOR COREBOOT
+#define RSDT_TABLE ACPI_TABLE_CREATOR
+#define HPET_TABLE ACPI_TABLE_CREATOR
+#define MCFG_TABLE ACPI_TABLE_CREATOR
+#define MADT_TABLE ACPI_TABLE_CREATOR
+#define SRAT_TABLE ACPI_TABLE_CREATOR
+#define SLIT_TABLE ACPI_TABLE_CREATOR
+#define XSDT_TABLE ACPI_TABLE_CREATOR
Seems even more wrong. Why use these defines?
+++ src/northbridge/intel/i945/early_init.c (working copy)
..
+ reg32 = DMIBAR32(0x224);
+ reg32 = ~(7 0);
+ reg32 |= (3 0);
+ DMIBAR32(0x224) = reg32;
How do you feel about making this a single function call?
-#if SETUP_PCIE_X16_LINK
+
Is this a part of the Config.lb system? Should it be removed from
there? Why was it there before and removed now? Is x16 never optional
on 945?
+++ src/northbridge/intel/i945/raminit.c (working copy)
..
+#if C2_SELF_REFRESH_DISABLE
Where is this set?
+ * However, the Kontron 986LCD-M does not like unused clock
+ * signals to be disabled.
(Do you know why? Just curious.)
+++ src/pc80/keyboard.c (.../trunk/coreboot-v2)
@@ -75,7 +81,11 @@
do {
if (!kbc_input_buffer_empty()) return 0;
No error here?
outb(command, 0x60);
- if (!kbc_output_buffer_full()) return 0;
+ if (!kbc_output_buffer_full()) {
+ printk_err(Could not send keyboard command %02x\n,
+ command);
+ return 0;
+ }
regval = inb(0x60);
--resend;
} while (regval == 0xFE resend 0);
//Peter
pgp5TseSDlPXH.pgp
Description: PGP signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] option rom new progress
Hi all Since a few days passed, the option rom have already got some new progress. 1) the size have already expanded to 127.5K 2) the rom can been run not only in segment 0xce00, all of the hardcode things have already been removed. 3) the init and int13 have already been improved within some details. my next progress is going to make the option rom init funciton can detect the usb devices -- Jason Wang Peking University -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] option rom new progress
Jason Wang wrote: Since a few days passed, the option rom have already got some new progress. .. That looks great! my next progress is going to make the option rom init funciton can detect the usb devices So now the real fun starts. :) I look forward to your next update - thanks a lot! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4445 - trunk/coreboot-v2/src/southbridge/ricoh/rl5c476
Author: stepan
Date: 2009-07-21 22:27:00 +0200 (Tue, 21 Jul 2009)
New Revision: 4445
Modified:
trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/chip.h
trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c
trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.h
Log:
* cleanup ricoh rl5c476 code:
- drop duplicate udelay function
- simplify code flow
- some cosmetics on comments
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Modified: trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/chip.h
===
--- trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/chip.h 2009-07-21
18:06:12 UTC (rev )
+++ trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/chip.h 2009-07-21
20:27:00 UTC (rev 4445)
@@ -5,7 +5,6 @@
struct southbridge_ricoh_rl5c476_config {
int enable_cf;
-
};
-#endif /* _SOUTHBRIDGE_RL5C476 */
+#endif /* _SOUTHBRIDGE_RICOH_RL5C476 */
Modified: trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c
===
--- trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-07-21
18:06:12 UTC (rev )
+++ trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-07-21
20:27:00 UTC (rev 4445)
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2004 Nick Barker nick.bark...@btinternet.com
+ * (C) Copyright 2004-2005 Nick Barker nick.bar...@btinternet.com
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -16,8 +16,6 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
* MA 02110-1301 USA
*/
-/* (C) Copyright 2005 Nick Barker nick.bar...@btinternet.com
- brought into line with the current architecture of coreboot */
#include arch/io.h
#include device/device.h
@@ -32,21 +30,13 @@
static int enable_cf_boot = 0;
static unsigned int cf_base;
-static void udelay(int i)
-{
- for(; i 0 ; i--)
- inb(0x80);
-}
-
static void rl5c476_init(device_t dev)
{
- //unsigned char enables;
pc16reg_t *pc16;
-
unsigned char *base;
/* cardbus controller function 1 for CF Socket */
- printk_debug(rl5c476 init\n);
+ printk_debug(Ricoh RL5c476: Initializing.\n);
printk_debug(CF Base = %0x\n,cf_base);
@@ -54,98 +44,120 @@
pci_write_config16(dev,0x82,0x00a0);
/* set up second slot as compact flash port if asked to do so */
- if( enable_cf_boot (PCI_FUNC(dev-path.pci.devfn) == 1)){
- /* make sure isa interrupts are enabled */
- pci_write_config16(dev,0x3e,0x0780);
+ if (!enable_cf_boot) {
+ printk_debug(CF boot not enabled.\n);
+ return;
+ }
+
+ if (PCI_FUNC(dev-path.pci.devfn) != 1) {
+ // Only configure if second CF slot.
+ return;
+ }
- /* pick up where 16 bit card control structure is (0x800 bytes
into config structure) */
- base = (unsigned char *)pci_read_config32(dev,0x10);
- pc16 = (pc16reg_t *)(base + 0x800);
+ /* make sure isa interrupts are enabled */
+ pci_write_config16(dev,0x3e,0x0780);
- /* disable memory and io windows and turn off socket power */
- pc16-pwctrl = 0;
+ /* pick up where 16 bit card control structure is
+* (0x800 bytes into config structure)
+*/
+ base = (unsigned char *)pci_read_config32(dev,0x10);
+ pc16 = (pc16reg_t *)(base + 0x800);
- /* disable irq lines */
- pc16-igctrl = 0;
+ /* disable memory and io windows and turn off socket power */
+ pc16-pwctrl = 0;
- /* disable memory and I/O windows */
- pc16-awinen = 0;
+ /* disable irq lines */
+ pc16-igctrl = 0;
- /* reset card, configure for I/O and set IRQ line */
- pc16-igctrl = 0x69;
+ /* disable memory and I/O windows */
+ pc16-awinen = 0;
- // set io window 0 for 1e0 - 1ef
- /* note this now sets CF up on a contiguous I/O window of 16
bytes, 0x1e0 to 0x1ef
- Be warned that this is not a standard IDE address as
automatically detected by the likes
- of Filo, and would need patching to recognise these
addresses as an IDE drive */
- /* an earlier version of this driver set up 2 io windows to
emulate the expected addresses
- for IDE2, however the pcmcia package within Linux then
could not re-initiailse the
- device as it tried to take control of it. So I belive it is
easier to patch Filo or the like
- to pick up this drive rather than playing silly games as
the kernel tries to boot.
- */
- pc16-iostl0 =
[coreboot] USB changes
Hi Patrick I have done the changes we discussed previously. Attached follows the patches. The 2 first patches are just few changes in the reg functions(*read/write*) so we can use the same functions in both OHCI and UHCI. The last patches are related to the changes I proposed to control function. I`m copying here the commit log message: Changed the usb API where the control function first parameter now is a pointer of endpoint_t instead of a pointer of usbdevice_t. The previous implementation assumed the first endpoint(index 0) as control, which is not true, we can have devices with more than a single control line. Since MSC device has always a single control endpoint I kept assuming that, and the changes to the drivers do exactly that, takes the first endpoint and passes it to control. I would like to keep those changes upstream already so it can be easily maintained. Please review and comment. PS: I`m cc`ing the coreboot mailing list, this way we can have more reviewers. Thanks in advance -- (°= Leandro Dorileo //\ldori...@gmail.com - http://www.dorilex.net V_/ Software is a matter of freedom. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB changes
On Tue, Jul 21, 2009 at 4:29 PM, Leandro Dorileoldori...@gmail.com wrote:
Hi Patrick
I have done the changes we discussed previously. Attached follows the
patches. The 2 first patches are just few changes in the reg
functions(*read/write*) so we can use the same functions in both OHCI
and UHCI.
The last patches are related to the changes I proposed to control
function. I`m copying here the commit log message:
Changed the usb API where the control function first parameter now
is a pointer of endpoint_t instead of a pointer of usbdevice_t.
The previous implementation assumed the first endpoint(index 0) as
control, which is not true, we can have devices with more than a
single control line.
Since MSC device has always a single control endpoint I kept assuming
that, and the changes to the drivers do exactly that, takes the first
endpoint and passes it to control.
I would like to keep those changes upstream already so it can be
easily maintained. Please review and comment.
PS: I`m cc`ing the coreboot mailing list, this way we can have more reviewers.
Thanks in advance
--
(°= Leandro Dorileo
//\ ldori...@gmail.com - http://www.dorilex.net
V_/ Software is a matter of freedom.
--
(°= Leandro Dorileo
//\ldori...@gmail.com - http://www.dorilex.net
V_/ Software is a matter of freedom.
From a2fc70e33689fe59e2321bbe3d9bbf25c107f59c Mon Sep 17 00:00:00 2001
From: Leandro Dorileo ldori...@gmail.com
Date: Mon, 29 Jun 2009 23:00:30 -0400
Subject: [PATCH 1/5] reg operations: moving
Moved the register functions from uhci.c to usb.h so every hci implementations
can beneffit. All the uhci_reg* were renamed to hci_reg*.
---
drivers/usb/uhci.h | 10 -
include/usb/usb.h | 57
2 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/uhci.h b/drivers/usb/uhci.h
index dd015ee..bde87ac 100644
--- a/drivers/usb/uhci.h
+++ b/drivers/usb/uhci.h
@@ -99,16 +99,6 @@ typedef struct {
0x12
} usbreg;
- void uhci_reg_write32 (hci_t *ctrl, usbreg reg, u32 value);
- u32 uhci_reg_read32 (hci_t *ctrl, usbreg reg);
- void uhci_reg_write16 (hci_t *ctrl, usbreg reg, u16 value);
- u16 uhci_reg_read16 (hci_t *ctrl, usbreg reg);
- void uhci_reg_write8 (hci_t *ctrl, usbreg reg, u8 value);
- u8 uhci_reg_read8 (hci_t *ctrl, usbreg reg);
- void uhci_reg_mask32 (hci_t *ctrl, usbreg reg, u32 andmask, u32 ormask);
- void uhci_reg_mask16 (hci_t *ctrl, usbreg reg, u16 andmask, u16 ormask);
- void uhci_reg_mask8 (hci_t *ctrl, usbreg reg, u8 andmask, u8 ormask);
-
typedef struct uhci {
flistp_t *framelistptr;
qh_t *qh_prei, *qh_intr, *qh_data, *qh_last;
diff --git a/include/usb/usb.h b/include/usb/usb.h
index d06e807..e7a5ae2 100644
--- a/include/usb/usb.h
+++ b/include/usb/usb.h
@@ -226,4 +226,61 @@ gen_bmRequestType (dev_req_dir dir, dev_req_type type, dev_req_recp recp)
void usb_detach_device(hci_t *controller, int devno);
int usb_attach_device(hci_t *controller, int hubaddress, int port, int lowspeed);
+
+void
+hci_reg_write32 (hci_t *ctrl, int reg, u32 value)
+{
+ outl (value, ctrl-reg_base + reg);
+}
+
+u32
+hci_reg_read32 (hci_t *ctrl, int reg)
+{
+ return inl (ctrl-reg_base + reg);
+}
+
+void
+hci_reg_write16 (hci_t *ctrl, int reg, u16 value)
+{
+ outw (value, ctrl-reg_base + reg);
+}
+
+u16
+hci_reg_read16 (hci_t *ctrl, int reg)
+{
+ return inw (ctrl-reg_base + reg);
+}
+
+void
+hci_reg_write8 (hci_t *ctrl, int reg, u8 value)
+{
+ outb (value, ctrl-reg_base + reg);
+}
+
+u8
+hci_reg_read8 (hci_t *ctrl, int reg)
+{
+ return inb (ctrl-reg_base + reg);
+}
+
+void
+hci_reg_mask32 (hci_t *ctrl, int reg, u32 andmask, u32 ormask)
+{
+ hci_reg_write32 (ctrl, reg,
+ (hci_reg_read32 (ctrl, reg) andmask) | ormask);
+}
+
+void
+hci_reg_mask16 (hci_t *ctrl, int reg, u16 andmask, u16 ormask)
+{
+ hci_reg_write16 (ctrl, reg,
+ (hci_reg_read16 (ctrl, reg) andmask) | ormask);
+}
+
+void
+hci_reg_mask8 (hci_t *ctrl, int reg, u8 andmask, u8 ormask)
+{
+ hci_reg_write8 (ctrl, reg,
+ (hci_reg_read8 (ctrl, reg) andmask) | ormask);
+}
#endif
--
1.6.3.3
From f34391d13ddb77c1b1ec0a463e9141c43254721a Mon Sep 17 00:00:00 2001
From: Leandro Dorileo ldori...@gmail.com
Date: Mon, 29 Jun 2009 23:03:08 -0400
Subject: [PATCH 2/5] reg functions: adaptation of uhci and uhci_rh
Adapting the uhci and uhci_rh drivers to accomplish the changes dones in the
commit 9359f55203c3c5e4422ee4bda46a11ea7a8cc6fb.
---
drivers/usb/uhci.c| 103 +++--
drivers/usb/uhci_rh.c | 28 +++---
2 files changed, 37 insertions(+), 94 deletions(-)
diff --git a/drivers/usb/uhci.c b/drivers/usb/uhci.c
index 198b6c0..8d5c9df 100644
--- a/drivers/usb/uhci.c
+++ b/drivers/usb/uhci.c
@@ -49,14 +49,14 @@ static u8* uhci_poll_intr_queue (void *queue);
static void
uhci_dump (hci_t *controller)
{
- printf (dump:\nUSBCMD:
[coreboot] build service results for r4445
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4445 to the coreboot repository. This caused the following changes: Change Log: * cleanup ricoh rl5c476 code: - drop duplicate udelay function - simplify code flow - some cosmetics on comments Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of via:epia-m has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4445device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] some more i945 patches
Peter Stuge wrote:
Stefan Reinauer wrote:
See patches
All are:
Acked-by: Peter Stuge pe...@stuge.se
Thank you!
+++ src/pc80/i8259.c (working copy)
..
+void i8259_configure_irq_trigger(int int_num, int is_level_triggered)
..
+/* Write new values */
+printk_spew(%s: try to set interrupts 0x%x\n, __func__, int_bits);
+outb((u8)(int_bits 0xff), ELCR1);
+outb((u8)(int_bits 8), ELCR2);
+
+#ifdef PARANOID_IRQ_TRIGGERS
+/* Try reading back the new values. This seems like an error but is not
... */
+if (inb(ELCR1) != (int_bits 0xff)) {
+printk_err(%s: lower order bits are wrong: want 0x%x, got
0x%x\n,
+__func__, (int_bits 0xff), inb(ELCR1));
+}
+
+if (inb(ELCR2) != (int_bits 8)) {
+printk_err(%s: lower order bits are wrong: want 0x%x, got
0x%x\n,
+__func__, (int_bits8), inb(ELCR2));
+}
+#endif
Copypaste right? Both of these are not the lower bits.
D'uh, yes, must be higher in the second case . I never got these
messages, so I neglected them.
+++ src/boot/elfboot.c (working copy)
..
- * - After loading an ELF image copy coreboot to the upper half of the
+ * - After loading an ELF image copy coreboot to the top of the
* buffer.
Could fold buffer up onto the previous line.
Agreed.
- * - After loading an ELF image copy coreboot to the upper half of the
+ * - After loading an ELF image copy coreboot to the top of the
* buffer.
..and again. Is this the same code? Could it be reused?
Agreed. Not sure if it's easy to reuse it.. I think Ron has still hopes
that we drop elfboot completely... Maybe it is indeed time for that.
+++ src/cpu/x86/lapic/apic_timer.c (.../trunk/coreboot-v2)
..
+/* NOTE: We use the APIC TIMER register is to hold flags for AP init during
+ * pre-memory init (ROMCC). Don't use init_timer() and udelay is redirected
+ * to udelay_tsc().
+ */
What? We use the .. is to hold flags for ? This text is confusing.
This code was taken from AMD, but the lapic timer code never worked in
ROMCC. (Nor does AMD pre-memory init) So I completely wiped the
paragraph for now.
+++ src/arch/i386/boot/acpi.c(working copy)
..
+memcpy(ssdt-asl_compiler_id, CORE, 4);
..
+memcpy(header-asl_compiler_id, ASLC, 4);
Is this difference on purpose? Is one static and the other not?
Please explain?
No, it should be the same.
+#define RSDP_NAME RSDP
+#define RSDT_NAME RSDT
+#define HPET_NAME HPET
+#define MADT_NAME APIC
+#define MCFG_NAME MCFG
+#define SRAT_NAME SRAT
+#define SLIT_NAME SLIT
+#define SSDT_NAME SSDT
+#define FACS_NAME FACS
+#define FADT_NAME FACP
+#define XSDT_NAME XSDT
Does it really make sense to use defines for these names?
No. But I didn't dare dropping them, in this run, either. Same goes for
the next set (OEM_TABLE_ID)
+// Misnomer, the NAME above is the 4 byte signature, this (TABLE) is the
+// OEM_TABLE_ID.
+//
+#define ACPI_TABLE_CREATOR COREBOOT
+#define RSDT_TABLE ACPI_TABLE_CREATOR
+#define HPET_TABLE ACPI_TABLE_CREATOR
+#define MCFG_TABLE ACPI_TABLE_CREATOR
+#define MADT_TABLE ACPI_TABLE_CREATOR
+#define SRAT_TABLE ACPI_TABLE_CREATOR
+#define SLIT_TABLE ACPI_TABLE_CREATOR
+#define XSDT_TABLE ACPI_TABLE_CREATOR
Seems even more wrong. Why use these defines?
They were in use before, and when I started on the code, I wanted to
somewhat clean it up, but not touch too many files. The best way would
be to use ACPI_TABLE_CREATOR directly wherever those tables are created.
We can give this a try, but I'm going to push these changes in first, or
it'll become too confusing.
+++ src/northbridge/intel/i945/early_init.c (working copy)
..
+reg32 = DMIBAR32(0x224);
+reg32 = ~(7 0);
+reg32 |= (3 0);
+DMIBAR32(0x224) = reg32;
How do you feel about making this a single function call?
For this part, or generally for this kind of construct?
-#if SETUP_PCIE_X16_LINK
+
Is this a part of the Config.lb system? Should it be removed from
there? Why was it there before and removed now? Is x16 never optional
on 945?
The chipset can do it, so the code should look if something is there.
There's a way to enable the links x16, then x1, then disable it, if none
of the link widths bring up a connection.
So, basically, always having this code there is safe. The downside is,
the code does not work yet, it doesn't detect the one graphics card I
have here.
+++ src/northbridge/intel/i945/raminit.c (working copy)
..
+#if C2_SELF_REFRESH_DISABLE
Where is this set?
Not at all yet. I think we're going to need this for S2R, but I'm not
sure how to fit the
[coreboot] [v2] r4446 - in trunk/coreboot-v2/src: config cpu/x86/lapic cpu/x86/tsc
Author: stepan
Date: 2009-07-21 23:19:06 +0200 (Tue, 21 Jul 2009)
New Revision: 4446
Added:
trunk/coreboot-v2/src/cpu/x86/lapic/apic_timer.c
Modified:
trunk/coreboot-v2/src/config/Options.lb
trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb
trunk/coreboot-v2/src/cpu/x86/lapic/lapic_cpu_init.c
trunk/coreboot-v2/src/cpu/x86/tsc/delay_tsc.c
Log:
* rework tsc based timer code to use inb instead of outb for calibration
* Add generic Local APIC based timer code. This timer does not need expensive
calibration and thus reduces the boot time by up to more than a second.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Modified: trunk/coreboot-v2/src/config/Options.lb
===
--- trunk/coreboot-v2/src/config/Options.lb 2009-07-21 20:27:00 UTC (rev
4445)
+++ trunk/coreboot-v2/src/config/Options.lb 2009-07-21 21:19:06 UTC (rev
4446)
@@ -928,6 +928,11 @@
export used
comment Implement udelay with x86 io registers
end
+define CONFIG_UDELAY_LAPIC
+ default 0
+ export used
+ comment Implement udelay with the x86 Local APIC
+end
define CONFIG_FAKE_SPDROM
default 0
export always
Modified: trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb
===
--- trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb 2009-07-21 20:27:00 UTC
(rev 4445)
+++ trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb 2009-07-21 21:19:06 UTC
(rev 4446)
@@ -1,3 +1,11 @@
+uses CONFIG_UDELAY_LAPIC
+
object lapic.o
object lapic_cpu_init.o
object secondary.S
+
+if CONFIG_UDELAY_LAPIC
+ default HAVE_INIT_TIMER=1
+ object apic_timer.o
+end
+
Added: trunk/coreboot-v2/src/cpu/x86/lapic/apic_timer.c
===
--- trunk/coreboot-v2/src/cpu/x86/lapic/apic_timer.c
(rev 0)
+++ trunk/coreboot-v2/src/cpu/x86/lapic/apic_timer.c2009-07-21 21:19:06 UTC
(rev 4446)
@@ -0,0 +1,67 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2007 Advanced Micro Devices, Inc.
+ * Copyright (C) 2009 coresystems GmbH
+ *
+ * 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; version 2 of the License.
+ *
+ * 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 stdint.h
+#include delay.h
+#include cpu/x86/msr.h
+#include cpu/x86/lapic.h
+
+/* NOTE: This code uses global variables, so it can not be used during
+ * memory init.
+ */
+
+#define FSB_CLOCK_STS 0xcd
+
+static u32 timer_fsb = 200; // default to 200MHz
+
+void init_timer(void)
+{
+ msr_t fsb_clock_sts;
+
+ /* Set the apic timer to no interrupts and periodic mode */
+ lapic_write(LAPIC_LVTT, (1 17) | (1 16) | (0 12) | (0 0));
+
+ /* Set the divider to 1, no divider */
+ lapic_write(LAPIC_TDCR, LAPIC_TDR_DIV_1);
+
+ /* Set the initial counter to 0x */
+ lapic_write(LAPIC_TMICT, 0x);
+
+ /* Set FSB frequency to a reasonable value */
+ fsb_clock_sts = rdmsr(FSB_CLOCK_STS);
+ switch ((fsb_clock_sts.lo 4) 0x07) {
+ case 0: timer_fsb = 266; break;
+ case 1: timer_fsb = 133; break;
+ case 2: timer_fsb = 200; break;
+ case 3: timer_fsb = 166; break;
+ case 5: timer_fsb = 100; break;
+ }
+}
+
+void udelay(u32 usecs)
+{
+ u32 start, value, ticks;
+ /* Calculate the number of ticks to run, our FSB runs at timer_fsb Mhz
*/
+ ticks = usecs * timer_fsb;
+ start = lapic_read(LAPIC_TMCCT);
+ do {
+ value = lapic_read(LAPIC_TMCCT);
+ } while((start - value) ticks);
+}
Modified: trunk/coreboot-v2/src/cpu/x86/lapic/lapic_cpu_init.c
===
--- trunk/coreboot-v2/src/cpu/x86/lapic/lapic_cpu_init.c2009-07-21
20:27:00 UTC (rev 4445)
+++ trunk/coreboot-v2/src/cpu/x86/lapic/lapic_cpu_init.c2009-07-21
21:19:06 UTC (rev 4446)
@@ -55,7 +55,7 @@
/* need to save it for RAM resume */
lowmem_backup_size = code_size;
lowmem_backup = malloc(code_size);
- lowmem_backup_ptr = (unsigned char *)start_eip;
+ lowmem_backup_ptr = (char *)start_eip;
if (lowmem_backup == NULL)
die(Out of
[coreboot] [v2] r4447 - in trunk/coreboot-v2/src: console include lib pc80
Author: stepan
Date: 2009-07-21 23:20:45 +0200 (Tue, 21 Jul 2009)
New Revision: 4447
Modified:
trunk/coreboot-v2/src/console/usbdebug_direct_console.c
trunk/coreboot-v2/src/include/usbdebug_direct.h
trunk/coreboot-v2/src/lib/usbdebug_direct.c
trunk/coreboot-v2/src/pc80/usbdebug_direct_serial.c
Log:
Some USB debug updates, mostly comments fixing, license header updates
and refactoring
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Acked-by: Peter Stuge pe...@stuge.se
Modified: trunk/coreboot-v2/src/console/usbdebug_direct_console.c
===
--- trunk/coreboot-v2/src/console/usbdebug_direct_console.c 2009-07-21
21:19:06 UTC (rev 4446)
+++ trunk/coreboot-v2/src/console/usbdebug_direct_console.c 2009-07-21
21:20:45 UTC (rev 4447)
@@ -1,3 +1,20 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * 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; version 2 of the License.
+ *
+ * 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 string.h
#include console/console.h
#include usbdebug_direct.h
@@ -3,15 +20,19 @@
#include pc80/mc146818rtc.h
-struct ehci_debug_info dbg_info;
+static struct ehci_debug_info dbg_info;
void set_ehci_base(unsigned ehci_base)
{
unsigned diff;
- if(!dbg_info.ehci_debug) return;
+
+ if (!dbg_info.ehci_debug)
+ return;
+
diff = dbg_info.ehci_caps - ehci_base;
dbg_info.ehci_regs -= diff;
dbg_info.ehci_debug -= diff;
dbg_info.ehci_caps = ehci_base;
}
+
void set_ehci_debug(unsigned ehci_debug)
{
@@ -21,39 +42,46 @@
unsigned get_ehci_debug(void)
{
- return dbg_info.ehci_debug;
+ return dbg_info.ehci_debug;
}
static void dbgp_init(void)
{
struct ehci_debug_info *dbg_infox;
- dbg_infox = (struct ehci_debug_info *)((CONFIG_LB_MEM_TOPK10) -
sizeof (struct ehci_debug_info)); //in RAM
- memcpy(dbg_info, dbg_infox, sizeof(struct ehci_debug_info) );
+
+ /* At this point, all we have to do is copy the fixed address
+* debug_info data structure to our version defined above. */
+
+ dbg_infox = (struct ehci_debug_info *)
+ ((CONFIG_LB_MEM_TOPK 10) - sizeof(struct ehci_debug_info));
+
+ memcpy(dbg_info, dbg_infox, sizeof(struct ehci_debug_info));
}
-static void dbgp_tx_byte(unsigned char data)
+static void dbgp_tx_byte(unsigned char data)
{
- if(dbg_info.ehci_debug)
- dbgp_bulk_write_x(dbg_info,data,1);
+ if (dbg_info.ehci_debug)
+ dbgp_bulk_write_x(dbg_info, data, 1);
}
-static unsigned char dbgp_rx_byte(void)
+static unsigned char dbgp_rx_byte(void)
{
unsigned char data = 0xff;
- if(dbg_info.ehci_debug)
- dbgp_bulk_read_x(dbg_info,data,1);
+
+ if (dbg_info.ehci_debug)
+ dbgp_bulk_read_x(dbg_info, data, 1);
+
return data;
}
-static int dbgp_tst_byte(void)
+static int dbgp_tst_byte(void)
{
return dbg_info.ehci_debug;
}
static const struct console_driver usbdebug_direct_console __console = {
- .init= dbgp_init,
- .tx_byte = dbgp_tx_byte,
- .rx_byte = dbgp_rx_byte,
+ .init = dbgp_init,
+ .tx_byte = dbgp_tx_byte,
+ .rx_byte = dbgp_rx_byte,
.tst_byte = dbgp_tst_byte,
};
-
Modified: trunk/coreboot-v2/src/include/usbdebug_direct.h
===
--- trunk/coreboot-v2/src/include/usbdebug_direct.h 2009-07-21 21:19:06 UTC
(rev 4446)
+++ trunk/coreboot-v2/src/include/usbdebug_direct.h 2009-07-21 21:20:45 UTC
(rev 4447)
@@ -1,3 +1,20 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * 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; version 2 of the License.
+ *
+ * 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
[coreboot] [v2] r4448 - trunk/coreboot-v2/util/newconfig
Author: stepan Date: 2009-07-21 23:22:40 +0200 (Tue, 21 Jul 2009) New Revision: 4448 Modified: trunk/coreboot-v2/util/newconfig/config.g Log: - Remove superfluous / from path - use make -C instead of workaround Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Modified: trunk/coreboot-v2/util/newconfig/config.g === --- trunk/coreboot-v2/util/newconfig/config.g 2009-07-21 21:20:45 UTC (rev 4447) +++ trunk/coreboot-v2/util/newconfig/config.g 2009-07-21 21:22:40 UTC (rev 4448) @@ -357,7 +357,7 @@ rel_base = base else: rel_base = re.sub(treetop, , os.path.join(dirstack.tos(), base)) - source = $(TOP)/ + rel_base + suffix + source = $(TOP) + rel_base + suffix if (rel_base[0] == '/'): rel_base = re.sub(^/, , rel_base) object = rel_base + '.o' @@ -2263,9 +2263,7 @@ file.write(include Makefile.settings\n\n) for i, o in romimages.items(): file.write(%s/coreboot.rom:\n % o.getname()) - file.write(\tif (cd %s; \\\n % o.getname()) - file.write(\t\t$(MAKE) coreboot.rom)\\\n) - file.write(\tthen true; else exit 1; fi;\n\n) + file.write(\t$(MAKE) -C %s coreboot.rom\n % o.getname()) file.write(clean: ) for i in romimages.keys(): file.write( %s-clean % i) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4449 - trunk/coreboot-v2/src/pc80
Author: stepan
Date: 2009-07-21 23:24:22 +0200 (Tue, 21 Jul 2009)
New Revision: 4449
Modified:
trunk/coreboot-v2/src/pc80/keyboard.c
Log:
Rewrite keyboard driver to actually wait time in ms as specified in the specs,
rather than doing inexact and slow idle loops.
Also improve error reporting in case of problems.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Modified: trunk/coreboot-v2/src/pc80/keyboard.c
===
--- trunk/coreboot-v2/src/pc80/keyboard.c 2009-07-21 21:22:40 UTC (rev
4448)
+++ trunk/coreboot-v2/src/pc80/keyboard.c 2009-07-21 21:24:22 UTC (rev
4449)
@@ -1,8 +1,9 @@
/*
* This file is part of the coreboot project.
*
+ * Copyright (C) 2009 coresystems GmbH
* Copyright (C) 2008 Advanced Micro Devices, Inc.
- * Copyright (C) Ollie Lo olli...@hotmail.com
+ * Copyright (C) 2003 Ollie Lo olli...@hotmail.com
*
* 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
@@ -23,16 +24,20 @@
#include pc80/keyboard.h
#include device/device.h
#include arch/io.h
+#include delay.h
+/* Wait 200ms for keyboard controller answers */
+#define KBC_TIMEOUT_IN_MS 200
+
static int kbc_input_buffer_empty(void)
{
u32 timeout;
- for(timeout = 100; timeout (inb(0x64) 0x02); timeout--) {
- inb(0x80);
+ for(timeout = KBC_TIMEOUT_IN_MS; timeout (inb(0x64) 0x02);
timeout--) {
+ mdelay(1);
}
if (!timeout) {
- printk_err(Unexpected Keyboard controller input buffer
full\n);
+ printk_warning(Unexpected Keyboard controller input buffer
full\n);
}
return !!timeout;
}
@@ -41,12 +46,12 @@
static int kbc_output_buffer_full(void)
{
u32 timeout;
- for(timeout = 100; timeout ((inb(0x64) 0x01) == 0); timeout--)
{
- inb(0x80);
+ for(timeout = KBC_TIMEOUT_IN_MS; timeout ((inb(0x64) 0x01) == 0);
timeout--) {
+ mdelay(1);
}
if (!timeout) {
- printk_err(Keyboard controller output buffer result
timeout\n);
+ printk_warning(Keyboard controller output buffer result
timeout\n);
}
return !!timeout;
}
@@ -55,7 +60,8 @@
static int kbc_cleanup_buffers(void)
{
u32 timeout;
- for(timeout = 100; timeout (inb(0x64) 0x03); timeout--) {
+ for(timeout = KBC_TIMEOUT_IN_MS; timeout (inb(0x64) 0x03);
timeout--) {
+ mdelay(1);
inb(0x60);
}
@@ -75,7 +81,11 @@
do {
if (!kbc_input_buffer_empty()) return 0;
outb(command, 0x60);
- if (!kbc_output_buffer_full()) return 0;
+ if (!kbc_output_buffer_full()) {
+ printk_err(Could not send keyboard command %02x\n,
+ command);
+ return 0;
+ }
regval = inb(0x60);
--resend;
} while (regval == 0xFE resend 0);
@@ -93,18 +103,21 @@
/* clean up any junk that might have been in the kbc */
if (!kbc_cleanup_buffers()) return;
- /* reset/self test 8042 - send cmd 0xAA, */
+ /* reset/self test 8042 - send cmd 0xAA */
if (!kbc_input_buffer_empty()) return;
outb(0xAA, 0x64);
- if (!kbc_output_buffer_full()) return;
+ if (!kbc_output_buffer_full()) {
+ printk_err(Could not reset keyboard controller.\n);
+ return;
+ }
/* read self-test result, 0x55 is returned in the output buffer (0x60)
*/
if ((regval = inb(0x60) != 0x55)) {
- printk_err(Keyboard Controller selftest failed: 0x%x\n,
regval);
+ printk_err(Keyboard Controller self-test failed: 0x%x\n,
regval);
return;
}
- /* Enable keyboard interface - No IRQ*/
+ /* Enable keyboard interface - No IRQ */
resend = 10;
regval = 0;
do {
@@ -112,8 +125,11 @@
outb(0x60, 0x64);
if (!kbc_input_buffer_empty()) return;
outb(0x20, 0x60); /* send cmd: enable keyboard */
- if ((inb(0x64) 0x01)) {
+ if (kbc_output_buffer_full()) {
regval = inb(0x60);
+ } else {
+ printk_info(Timeout while enabling keyboard. (No
keyboard present?)\n);
+ regval = inb(0x60); /* Better than 0 ? */
}
--resend;
} while (regval == 0xFE resend 0);
@@ -127,7 +143,11 @@
printk_err(Keyboard selftest failed ACK: 0x%x\n, regval);
return;
}
- if (!kbc_output_buffer_full())
Re: [coreboot] USB changes
Hi Leandro,
Leandro Dorileo wrote:
- uhci_reg_write16 (controller, USBCMD, 4);
+ hci_reg_write16 (controller, USBCMD, 4);
This change may not be a good idea.
Just changing the function names is not enough to abstract the code
for different HCIs. I would prefer if the function names remain until
a commit which actually covers one of OHCI and EHCI.
Subject: [PATCH 3/5] usb: API change, control receive endpoint_t
Changed the usb API where the control function first parameter now
is a pointer of endpoint_t instead of a pointer of usbdevice_t.
Changing the API like this is a good thing.
The previous implementation assumed the first endpoint(index 0) as
control, which is not true, we can have devices with more than a
single control line.
What do you mean by index 0 here? Is it the index in an array in the
USB stack? Is it the endpoint number?
Subject: [PATCH 4/5] uhci: control adaptations
Chaging the implementation of uhci_control function to match the api
changes done in the previous patch.
These two changes should be in the same commit, otherwise the code is
broken in between.
Subject: [PATCH 5/5] control users: change the callers of -control
This also belongs in the same commit as 3 and 4.
This patch introduces changes in the usb main program and msc driver
as well. It basically passes an endpoint_t instead of a usbdevice_t
to control function.
We are still assuming the first endpoint to be the control one. We
may need to change the functions in usb.c with a depper adaptation
to accommodate drivers for devices with more than a single control
endpoint but for now endpoint[0] should work.
How is this array populated?
The default pipe always accepts control transfers, but is it
automatically populated to index 0 in the endpoints array? Note that
the default pipe does not usually show up in any descriptor.
There are some issues in the following code:
@@ -109,7 +109,7 @@ set_feature (usbdev_t *dev, int endp, int feature, int
rtype)
+ dev-controller-control (dev-endpoints[endp], OUT, sizeof (dr), dr,
0, 0);
This is good. (Or is it? Is endp specified in the API to be the
index, and not the endpoint number?)
@@ -123,7 +123,7 @@ get_status (usbdev_t *dev, int intf, int rtype, int len,
void *data)
+ dev-controller-control (dev-endpoints[intf], IN, sizeof (dr), dr,
len, data);
Here an interface number is suddenly used as index in the endpoints
array. Please explain how that can be correct?
@@ -134,6 +134,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+endpoint_t *ep = dev-endpoints[langID];
Here langID is used as index in the endpoints array. That also seems
like it will be a problem.
@@ -141,7 +142,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ if (dev-controller-control (ep, IN, sizeof (dr), dr, 8, buf)) {
Where does this ep come from?
@@ -165,7 +166,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ control (ep, IN, sizeof (dr), dr, size, result)) {
Same one..
@@ -183,7 +184,7 @@ set_configuration (usbdev_t *dev)
+ dev-controller-control (dev-endpoints[0], OUT, sizeof (dr), dr, 0,
0);
Is index 0 in endpoints guaranteed to always be the default endpoint?
@@ -201,7 +202,7 @@ clear_stall (endpoint_t *ep)
+ dev-controller-control (ep, OUT, sizeof (dr), dr, 0, 0);
Good.
@@ -246,7 +247,7 @@ set_address (hci_t *controller, int lowspeed)
+ if (dev-controller-control (dev-endpoints[0], OUT, sizeof (dr),
dr, 0, 0)) {
Again with index 0. And it happens a few more times.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4450 - in trunk/coreboot-v2/src: boot include/console include/x86emu
Author: stepan Date: 2009-07-21 23:25:45 +0200 (Tue, 21 Jul 2009) New Revision: 4450 Modified: trunk/coreboot-v2/src/boot/hardwaremain.c trunk/coreboot-v2/src/include/console/console.h trunk/coreboot-v2/src/include/x86emu/x86emu.h Log: Example how simple it is to use printk instead of printk_something in coreboot ram stage. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/coreboot-v2/src/boot/hardwaremain.c === --- trunk/coreboot-v2/src/boot/hardwaremain.c 2009-07-21 21:24:22 UTC (rev 4449) +++ trunk/coreboot-v2/src/boot/hardwaremain.c 2009-07-21 21:25:45 UTC (rev 4450) @@ -25,7 +25,6 @@ * C Bootstrap code for the coreboot */ - #include console/console.h #include version.h #include device/device.h @@ -62,7 +61,7 @@ post_code(0x39); - printk_notice(coreboot-%s%s %s %s...\n, + printk(BIOS_NOTICE, coreboot-%s%s %s %s...\n, coreboot_version, coreboot_extra_version, coreboot_build, (boot_complete)?rebooting:booting); @@ -113,6 +112,6 @@ elfboot(lb_mem); #endif #endif - printk_err(Boot failed.\n); + printk(BIOS_ERR, Boot failed.\n); } Modified: trunk/coreboot-v2/src/include/console/console.h === --- trunk/coreboot-v2/src/include/console/console.h 2009-07-21 21:24:22 UTC (rev 4449) +++ trunk/coreboot-v2/src/include/console/console.h 2009-07-21 21:25:45 UTC (rev 4450) @@ -29,6 +29,8 @@ extern int console_loglevel; int do_printk(int msg_level, const char *fmt, ...) __attribute__((format(printf, 2, 3))); +#define printk(x...) do_printk(x) + #define printk_emerg(fmt, arg...) do_printk(BIOS_EMERG ,fmt, ##arg) #define printk_alert(fmt, arg...) do_printk(BIOS_ALERT ,fmt, ##arg) #define printk_crit(fmt, arg...)do_printk(BIOS_CRIT,fmt, ##arg) Modified: trunk/coreboot-v2/src/include/x86emu/x86emu.h === --- trunk/coreboot-v2/src/include/x86emu/x86emu.h 2009-07-21 21:24:22 UTC (rev 4449) +++ trunk/coreboot-v2/src/include/x86emu/x86emu.h 2009-07-21 21:25:45 UTC (rev 4450) @@ -49,7 +49,8 @@ /* FIXME: undefine printk for the moment */ #ifdef COREBOOT_VERSION #include console/console.h -#define printk printk_debug +#undef printk +#define printk(x...) do_printk(BIOS_DEBUG, x) #else #define printk printf #endif -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4451 - trunk/coreboot-v2/src/config
Author: stepan Date: 2009-07-21 23:31:36 +0200 (Tue, 21 Jul 2009) New Revision: 4451 Modified: trunk/coreboot-v2/src/config/Config.lb Log: Add more warnings to CFLAGS, and also add some to HOSTCFLAGS include ldoptions from ldscript.ld instead appending it. Not everyone was happy about the -Wmissing-prototypes in CFLAGS. I put it in there now anyways, so everyone can get an overview which parts of their code could use some cleanup. If it gets too ugly, we can still remove that flag again. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Modified: trunk/coreboot-v2/src/config/Config.lb === --- trunk/coreboot-v2/src/config/Config.lb 2009-07-21 21:25:45 UTC (rev 4450) +++ trunk/coreboot-v2/src/config/Config.lb 2009-07-21 21:31:36 UTC (rev 4451) @@ -10,17 +10,17 @@ makedefine GCC_INC_DIR := $(shell LC_ALL=C $(GCC) -print-search-dirs | sed -ne s/install: \(.*\)/\1include/gp) makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(CONFIG_ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) -makedefine CFLAGS := $(CONFIG_CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer +makedefine CFLAGS := $(CONFIG_CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer if CONFIG_ASSEMBLER_DEBUG makedefine DEBUG_CFLAGS := -g -dA -fverbose-asm end -makedefine HOSTCFLAGS:= -Os -Wall +makedefine HOSTCFLAGS:= -Os -Wall -Wstrict-prototypes -Wmissing-prototypes -Wredundant-decls -Wno-trigraphs -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow makerule ldscript.ld depends ldoptions $(LDSUBSCRIPTS-1) - action echo '/*ldoptions*/' $@; cat ldoptions $@ ; for file in $(LDSUBSCRIPTS-1) ; do echo /\* $$file \*/ $@; cat $$file $@ ; done + action echo 'INCLUDE ldoptions' $@; for file in $(LDSUBSCRIPTS-1) ; do echo /\* $$file \*/ $@; cat $$file $@ ; done end #makerule cpuflags -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4452 - in trunk/coreboot-v2/src: devices include/device include/pc80 pc80
Author: stepan
Date: 2009-07-21 23:36:41 +0200 (Tue, 21 Jul 2009)
New Revision: 4452
Modified:
trunk/coreboot-v2/src/devices/pci_device.c
trunk/coreboot-v2/src/devices/pci_ops.c
trunk/coreboot-v2/src/include/device/pci.h
trunk/coreboot-v2/src/include/pc80/i8259.h
trunk/coreboot-v2/src/pc80/i8259.c
Log:
Rewrite interrupt handling in coreboot to be more comprehensible and
more flexible. Also some minore device allocator cleanups that sneaked
in.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Modified: trunk/coreboot-v2/src/devices/pci_device.c
===
--- trunk/coreboot-v2/src/devices/pci_device.c 2009-07-21 21:31:36 UTC (rev
4451)
+++ trunk/coreboot-v2/src/devices/pci_device.c 2009-07-21 21:36:41 UTC (rev
4452)
@@ -50,6 +50,10 @@
#if CONFIG_CARDBUS_PLUGIN_SUPPORT == 1
#include device/cardbus.h
#endif
+#define CONFIG_PC80_SYSTEM 1
+#if CONFIG_PC80_SYSTEM == 1
+#include pc80/i8259.h
+#endif
u8 pci_moving_config8(struct device *dev, unsigned int reg)
{
@@ -110,10 +114,10 @@
unsigned pci_find_next_capability(struct device *dev, unsigned cap,
unsigned last)
{
- unsigned pos;
+ unsigned pos = 0;
unsigned status;
unsigned reps = 48;
- pos = 0;
+
status = pci_read_config16(dev, PCI_STATUS);
if (!(status PCI_STATUS_CAP_LIST)) {
return 0;
@@ -1193,86 +1197,62 @@
return max;
}
+#if CONFIG_PC80_SYSTEM == 1
/**
- * Tell the EISA int controller this int must be level triggered.
+ *
+ * @brief Assign IRQ numbers
*
- * THIS IS A KLUDGE -- sorry, this needs to get cleaned up.
- */
-void pci_level_irq(unsigned char intNum)
-{
- unsigned short intBits = inb(0x4d0) | (((unsigned)inb(0x4d1)) 8);
-
- printk_spew(%s: current ints are 0x%x\n, __func__, intBits);
- intBits |= (1 intNum);
-
- printk_spew(%s: try to set ints 0x%x\n, __func__, intBits);
-
- /* Write new values. */
- outb((unsigned char)intBits, 0x4d0);
- outb((unsigned char)(intBits 8), 0x4d1);
-
- /* This seems like an error but is not. */
- if (inb(0x4d0) != (intBits 0xff)) {
- printk_err(
- %s: lower order bits are wrong: want 0x%x, got
0x%x\n,
- __func__, intBits 0xff, inb(0x4d0));
- }
- if (inb(0x4d1) != ((intBits 8) 0xff)) {
- printk_err(
- %s: lower order bits are wrong: want 0x%x, got
0x%x\n,
- __func__, (intBits 8) 0xff, inb(0x4d1));
- }
-}
-
-/**
- * This function assigns IRQs for all functions contained within the
- * indicated device address. If the device does not exist or does not
- * require interrupts then this function has no effect.
+ * This function assigns IRQs for all functions contained within the indicated
+ * device address. If the device does not exist or does not require interrupts
+ * then this function has no effect.
*
* This function should be called for each PCI slot in your system.
*
- * pIntAtoD is an array of IRQ #s that are assigned to PINTA through PINTD of
- * this slot.
- *
- * The particular irq #s that are passed in depend on the routing inside
- * your southbridge and on your motherboard.
- *
- * -kev...@ispiri.com
- *
-*/
+ * @param bus
+ * @param slot
+ * @param pIntAtoD is an array of IRQ #s that are assigned to PINTA through
+ *PINTD of this slot. The particular irq #s that are passed in
+ *depend on the routing inside your southbridge and on your
+ *motherboard.
+ */
void pci_assign_irqs(unsigned bus, unsigned slot,
-const unsigned char pIntAtoD[4])
+ const unsigned char pIntAtoD[4])
{
- unsigned functNum;
- struct device *pdev;
- unsigned char line;
- unsigned char irq;
- unsigned char readback;
+ unsigned int funct;
+ device_t pdev;
+ u8 line;
+ u8 irq;
+ u8 readback;
- /* Each slot may contain up to eight functions. */
- for (functNum = 0; functNum 8; functNum++) {
- pdev = dev_find_slot(bus, (slot 3) + functNum);
+ /* Each slot may contain up to eight functions */
+ for (funct = 0; funct 8; funct++) {
+ pdev = dev_find_slot(bus, (slot 3) + funct);
- if (pdev) {
- line = pci_read_config8(pdev, PCI_INTERRUPT_PIN);
+ if (!pdev)
+ continue;
- /* PCI spec says all other values are reserved. */
- if ((line = 1) (line = 4)) {
- irq = pIntAtoD[line - 1];
+ line = pci_read_config8(pdev, PCI_INTERRUPT_PIN);
- printk_debug(Assigning IRQ %d to %d:%x.%d\n,
-irq,
[coreboot] [v2] r4453 - in trunk/coreboot-v2/src: arch/i386/boot arch/i386/include/arch include/boot mainboard/amd/dbm690t mainboard/amd/pistachio mainboard/amd/serengeti_cheetah mainboard/amd/serenge
Author: stepan
Date: 2009-07-21 23:38:33 +0200 (Tue, 21 Jul 2009)
New Revision: 4453
Modified:
trunk/coreboot-v2/src/arch/i386/boot/acpi.c
trunk/coreboot-v2/src/arch/i386/boot/coreboot_table.c
trunk/coreboot-v2/src/arch/i386/boot/tables.c
trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h
trunk/coreboot-v2/src/include/boot/coreboot_tables.h
trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c
trunk/coreboot-v2/src/mainboard/amd/pistachio/acpi_tables.c
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/acpi_tables.c
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c
trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/acpi_tables.c
trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/acpi_tables.c
trunk/coreboot-v2/src/mainboard/intel/xe7501devkit/acpi_tables.c
trunk/coreboot-v2/src/mainboard/iwill/dk8_htx/acpi_tables.c
trunk/coreboot-v2/src/mainboard/technexion/tim8690/acpi_tables.c
trunk/coreboot-v2/src/mainboard/tyan/s2891/acpi_tables.c
trunk/coreboot-v2/src/mainboard/tyan/s2892/acpi_tables.c
trunk/coreboot-v2/src/mainboard/tyan/s2895/acpi_tables.c
trunk/coreboot-v2/src/mainboard/via/epia-m/acpi_tables.c
trunk/coreboot-v2/src/mainboard/via/vt8454c/acpi_tables.c
Log:
This fixes a couple of issues with older Linux kernels (that expect an XSDT as
soon as there's an ACPI 2.0 or later table)
* add XSDT support
* add more table types
This patch will break at least the kontron (and possibly some new boards I
missed)
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Modified: trunk/coreboot-v2/src/arch/i386/boot/acpi.c
===
--- trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-21 21:36:41 UTC (rev
4452)
+++ trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-21 21:38:33 UTC (rev
4453)
@@ -41,29 +41,50 @@
* add an acpi table to rsdt structure, and recalculate checksum
*/
-void acpi_add_table(acpi_rsdt_t *rsdt, void *table)
+void acpi_add_table(acpi_rsdp_t *rsdp, void *table)
{
int i;
+ acpi_rsdt_t *rsdt;
+ acpi_xsdt_t *xsdt = NULL;
+
+ rsdt = (acpi_rsdt_t *)rsdp-rsdt_address;
+ if (rsdp-xsdt_address) {
+ xsdt = (acpi_xsdt_t *)((u32)rsdp-xsdt_address);
+ }
int entries_num = ARRAY_SIZE(rsdt-entry);
for (i=0; ientries_num; i++) {
if(rsdt-entry[i]==0) {
rsdt-entry[i]=(u32)table;
- /* fix length to stop kernel winging about invalid
entries */
+ /* fix length to stop kernel whining about invalid
entries */
rsdt-header.length = sizeof(acpi_header_t) +
(sizeof(u32) * (i+1));
/* fix checksum */
/* hope this won't get optimized away */
rsdt-header.checksum=0;
rsdt-header.checksum=acpi_checksum((u8 *)rsdt,
rsdt-header.length);
+
+ /* And now the same thing for the XSDT. We use the same
+* index as we want the XSDT and RSDT to always be in
+* sync in coreboot.
+*/
+ if (xsdt) {
+ xsdt-entry[i]=(u64)(u32)table;
+ xsdt-header.length = sizeof(acpi_header_t) +
+ (sizeof(u64) * (i+1));
+ xsdt-header.checksum=0;
+ xsdt-header.checksum=acpi_checksum((u8 *)xsdt,
+ xsdt-header.length);
+ }
- printk_debug(ACPI: added table %d/%d Length now
%d\n,i+1, entries_num, rsdt-header.length);
+ printk_debug(ACPI: added table %d/%d Length now %d\n,
+ i+1, entries_num, rsdt-header.length);
return;
}
}
- printk_warning(ACPI: could not add ACPI table to RSDT. failed.\n);
+ printk_err(ACPI: Error: Could not add ACPI table, too many tables.\n);
}
int acpi_create_mcfg_mmconfig(acpi_mcfg_mmconfig_t *mmconfig, u32 base, u16
seg_nr, u8 start, u8 end)
@@ -216,7 +237,7 @@
memcpy(ssdt-oem_id, OEM_ID, 6);
memcpy(ssdt-oem_table_id, oem_table_id, 8);
ssdt-oem_revision = 42;
- memcpy(ssdt-asl_compiler_id, GENAML, 4);
+ memcpy(ssdt-asl_compiler_id, CORE, 4);
ssdt-asl_compiler_revision = 42;
ssdt-length = sizeof(acpi_header_t);
@@ -376,16 +397,47 @@
/* fix checksum */
- header-checksum= acpi_checksum((void *)rsdt,
sizeof(acpi_rsdt_t));
+ header-checksum = acpi_checksum((void *)rsdt, sizeof(acpi_rsdt_t));
}
-void
[coreboot] [v2] r4454 - in trunk/coreboot-v2/src/cpu: intel intel/model_6ex intel/model_6fx intel/speedstep x86/smm
Author: stepan
Date: 2009-07-21 23:41:42 +0200 (Tue, 21 Jul 2009)
New Revision: 4454
Added:
trunk/coreboot-v2/src/cpu/intel/speedstep/
trunk/coreboot-v2/src/cpu/intel/speedstep/Config.lb
trunk/coreboot-v2/src/cpu/intel/speedstep/acpi.c
Modified:
trunk/coreboot-v2/src/cpu/intel/model_6ex/Config.lb
trunk/coreboot-v2/src/cpu/intel/model_6ex/model_6ex_init.c
trunk/coreboot-v2/src/cpu/intel/model_6fx/model_6fx_init.c
trunk/coreboot-v2/src/cpu/x86/smm/smmrelocate.S
Log:
add intel speedstep support and some PM fixes.
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Peter Stuge pe...@stuge.se
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Modified: trunk/coreboot-v2/src/cpu/intel/model_6ex/Config.lb
===
--- trunk/coreboot-v2/src/cpu/intel/model_6ex/Config.lb 2009-07-21 21:38:33 UTC
(rev 4453)
+++ trunk/coreboot-v2/src/cpu/intel/model_6ex/Config.lb 2009-07-21 21:41:42 UTC
(rev 4454)
@@ -11,4 +11,5 @@
dir /cpu/x86/smm
dir /cpu/intel/microcode
dir /cpu/intel/hyperthreading
+dir /cpu/intel/speedstep
driver model_6ex_init.o
Modified: trunk/coreboot-v2/src/cpu/intel/model_6ex/model_6ex_init.c
===
--- trunk/coreboot-v2/src/cpu/intel/model_6ex/model_6ex_init.c 2009-07-21
21:38:33 UTC (rev 4453)
+++ trunk/coreboot-v2/src/cpu/intel/model_6ex/model_6ex_init.c 2009-07-21
21:41:42 UTC (rev 4454)
@@ -111,30 +111,41 @@
#define PMG_CST_CONFIG_CONTROL 0xe2
#define PMG_IO_BASE_ADDR 0xe3
#define PMG_IO_CAPTURE_ADDR0xe4
-#define PMB0 0x510 /* analogous to P_BLK in cpu.asl */
-#define PMB1 0x0 /* IO port that triggers SMI once cores are in the same
state.
- See CSM Trigger, at PMG_CST_CONFIG_CONTROL[6:4] */
+
+/* MWAIT coordination I/O base address. This must match
+ * the \_PR_.CPU0 PM base address.
+ */
+#define PMB0_BASE 0x510
+
+/* PMB1: I/O port that triggers SMI once cores are in the same state.
+ * See CSM Trigger, at PMG_CST_CONFIG_CONTROL[6:4]
+ */
+#define PMB1_BASE 0x800
#define HIGHEST_CLEVEL 3
static void configure_c_states(void)
{
msr_t msr;
msr = rdmsr(PMG_CST_CONFIG_CONTROL);
- msr.lo |= (1 15); // Lock configuration
- msr.lo |= (1 10); // redirect IO-based CState transition requests to
MWAIT
+ msr.lo |= (1 15); // config lock until next reset.
+ msr.lo |= (1 10); // Enable I/O MWAIT redirection for C-States
msr.lo = ~(1 9); // Issue a single stop grant cycle upon stpclk
- msr.lo = ~7; msr.lo |= HIGHEST_CLEVEL; // support at most C3
// TODO Do we want Deep C4 and Dynamic L2 shrinking?
+
+ /* Number of supported C-States */
+ msr.lo = ~7;
+ msr.lo |= HIGHEST_CLEVEL; // support at most C3
+
wrmsr(PMG_CST_CONFIG_CONTROL, msr);
- // set P_BLK address
- msr = rdmsr(PMG_IO_BASE_ADDR);
- msr.lo = PMB0+4 | (PMB116);
+ /* Set Processor MWAIT IO BASE (P_BLK) */
+ msr.hi = 0;
+ msr.lo = ((PMB0_BASE + 4) 0x) | (((PMB1_BASE + 9) 0x)
16);
wrmsr(PMG_IO_BASE_ADDR, msr);
- // set C_LVL controls
- msr = rdmsr(PMG_IO_CAPTURE_ADDR);
- msr.lo = PMB0+4 | (HIGHEST_CLEVEL-2)16; // -2 because LVL0+1 aren't
counted
+ /* set C_LVL controls */
+ msr.hi = 0;
+ msr.lo = (PMB0_BASE + 4) | ((HIGHEST_CLEVEL - 2) 16); // -2 because
LVL0+1 aren't counted
wrmsr(PMG_IO_CAPTURE_ADDR, msr);
}
@@ -160,6 +171,19 @@
wrmsr(IA32_MISC_ENABLE, msr);
}
+#define PIC_SENS_CFG 0x1aa
+static void configure_pic_thermal_sensors(void)
+{
+ msr_t msr;
+
+ msr = rdmsr(PIC_SENS_CFG);
+
+ msr.lo |= (1 21); // inter-core lock TM1
+ msr.lo |= (1 4); // Enable bypass filter
+
+ wrmsr(PIC_SENS_CFG, msr);
+}
+
#if CONFIG_USBDEBUG_DIRECT
static unsigned ehci_debug_addr;
#endif
@@ -205,7 +229,8 @@
/* Configure Enhanced SpeedStep and Thermal Sensors */
configure_misc();
- /* TODO: PIC thermal sensor control */
+ /* PIC thermal sensor control */
+ configure_pic_thermal_sensors();
/* Start up my cpu siblings */
intel_sibling_init(cpu);
Modified: trunk/coreboot-v2/src/cpu/intel/model_6fx/model_6fx_init.c
===
--- trunk/coreboot-v2/src/cpu/intel/model_6fx/model_6fx_init.c 2009-07-21
21:38:33 UTC (rev 4453)
+++ trunk/coreboot-v2/src/cpu/intel/model_6fx/model_6fx_init.c 2009-07-21
21:41:42 UTC (rev 4454)
@@ -126,9 +126,16 @@
#define PMG_IO_BASE_ADDR 0xe3
#define PMG_IO_CAPTURE_ADDR0xe4
-#define PMB0_BASE 0x580
+/* MWAIT coordination I/O base address. This must match
+ * the \_PR_.CPU0 PM base address.
+ */
+#define PMB0_BASE 0x510
+
+/* PMB1: I/O port that triggers SMI once cores are in the same state.
+ * See CSM Trigger, at
[coreboot] build service results for r4446
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4446 to the coreboot repository. This caused the following changes: Change Log: * rework tsc based timer code to use inb instead of outb for calibration * Add generic Local APIC based timer code. This timer does not need expensive calibration and thus reduces the boot time by up to more than a second. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Build Log: Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4446device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4457 - trunk/coreboot-v2/src/cpu/x86/lapic
Author: stepan Date: 2009-07-21 23:57:11 +0200 (Tue, 21 Jul 2009) New Revision: 4457 Modified: trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb Log: this bug sneaked in during conversion Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb === --- trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb 2009-07-21 21:50:34 UTC (rev 4456) +++ trunk/coreboot-v2/src/cpu/x86/lapic/Config.lb 2009-07-21 21:57:11 UTC (rev 4457) @@ -5,7 +5,7 @@ object secondary.S if CONFIG_UDELAY_LAPIC - default HAVE_INIT_TIMER=1 + default CONFIG_HAVE_INIT_TIMER=1 object apic_timer.o end -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4458 - in trunk/coreboot-v2/src/mainboard/kontron/986lcd-m: . acpi
Author: stepan Date: 2009-07-21 23:58:20 +0200 (Tue, 21 Jul 2009) New Revision: 4458 Added: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/i945_pci_irqs.asl trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/ich7_pci_irqs.asl Removed: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/cpu.asl trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/globalnvs.asl trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/sleepstates.asl Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Options.lb trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi_tables.c trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/auto.c trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/cmos.layout trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/dsdt.asl trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/fadt.c trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/mainboard.c trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/mainboard_smi.c Log: Kontron updates, get board up to date with i945 and ich7 updates. Move interrupt routing to mainboard specific code. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb === --- trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb 2009-07-21 21:57:11 UTC (rev 4457) +++ trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb 2009-07-21 21:58:20 UTC (rev 4458) @@ -28,8 +28,10 @@ ## default CONFIG_USE_OPTION_TABLE = !CONFIG_USE_FALLBACK_IMAGE -## CONFIG_XIP_ROM_SIZE must be a power of 2. -default CONFIG_XIP_ROM_SIZE = 64 * 1024 +## +## Image size calculation +## + include /config/nofailovercalculation.lb ## @@ -175,7 +177,7 @@ register ide_legacy_combined = 0x1 register ide_enable_primary = 0x1 -register ide_enable_secondary = 0x0 +register ide_enable_secondary = 0x1 register sata_ahci = 0x0 device pci 1b.0 on end # High Definition Audio Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Options.lb === --- trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Options.lb 2009-07-21 21:57:11 UTC (rev 4457) +++ trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Options.lb 2009-07-21 21:58:20 UTC (rev 4458) @@ -80,8 +80,7 @@ uses CONFIG_MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID uses CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID # Timers -uses CONFIG_UDELAY_TSC -uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 +uses CONFIG_UDELAY_LAPIC # Console uses CONFIG_CONSOLE_SERIAL8250 uses CONFIG_TTYS0_BAUD @@ -131,10 +130,8 @@ ## ## Delay timer options -## Use timer2 ## -default CONFIG_UDELAY_TSC=1 -default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1 +default CONFIG_UDELAY_LAPIC=1 ## ## Build code to reset the motherboard from coreboot @@ -176,6 +173,7 @@ ## default CONFIG_HAVE_ACPI_TABLES=1 default CONFIG_HAVE_MAINBOARD_RESOURCES=1 +default CONFIG_HAVE_ACPI_RESUME=1 ## ## Build code to export a CMOS option table @@ -217,6 +215,13 @@ default CONFIG_USE_PRINTK_IN_CAR=1 ## +## Execute In Place settings +## + +default CONFIG_XIP_ROM_SIZE = 128 * 1024 +default CONFIG_XIP_ROM_BASE = ( CONFIG_ROMBASE - CONFIG_XIP_ROM_SIZE + CONFIG_ROM_IMAGE_SIZE ) + +## ## Build code to setup a generic IOAPIC ## default CONFIG_IOAPIC=1 @@ -232,12 +237,12 @@ ### ## CONFIG_ROM_IMAGE_SIZE is the amount of space to allow coreboot to occupy. -default CONFIG_ROM_IMAGE_SIZE = 65536 +default CONFIG_ROM_IMAGE_SIZE = 0x1 ## -## Use a small 8K stack +## Use a small 32K stack ## -default CONFIG_STACK_SIZE=0x2000 +default CONFIG_STACK_SIZE=0x8000 ## ## Use a small 32K heap Deleted: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/cpu.asl === --- trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/cpu.asl 2009-07-21 21:57:11 UTC (rev 4457) +++ trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi/cpu.asl 2009-07-21 21:58:20 UTC (rev 4458) @@ -1,51 +0,0 @@ -/* - * This file is part of the coreboot project. - * - * Copyright (C) 2007-2009 coresystems GmbH - * - * 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; version 2 of - * the License. - * - * 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;
[coreboot] [v2] r4459 - trunk/coreboot-v2/src/southbridge/ricoh/rl5c476
Author: stepan Date: 2009-07-22 00:01:21 +0200 (Wed, 22 Jul 2009) New Revision: 4459 Modified: trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c Log: Another include file slipped. This gets via/epia-m building again. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Modified: trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c === --- trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-07-21 21:58:20 UTC (rev 4458) +++ trunk/coreboot-v2/src/southbridge/ricoh/rl5c476/rl5c476.c 2009-07-21 22:01:21 UTC (rev 4459) @@ -24,6 +24,7 @@ #include device/pci_ids.h #include console/console.h #include device/cardbus.h +#include delay.h #include rl5c476.h #include chip.h -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB changes
Hi Peter
On Tue, Jul 21, 2009 at 5:24 PM, Peter Stugepe...@stuge.se wrote:
Hi Leandro,
Leandro Dorileo wrote:
- uhci_reg_write16 (controller, USBCMD, 4);
+ hci_reg_write16 (controller, USBCMD, 4);
This change may not be a good idea.
Just changing the function names is not enough to abstract the code
for different HCIs. I would prefer if the function names remain until
a commit which actually covers one of OHCI and EHCI.
The hci_reg_* functions use the reg_base in hci_t structure to
determine which port to write to/read from, this structure is used
both for OHCI, UHCI and will be for EHCI, so doesn`t matter if the
controller is UHCI or OHCI there will always be a reg_base, with that
I thought I could move it to usb.h and reuse it.
The changes you pointed are just in the caller, UHCI in the case.
Subject: [PATCH 3/5] usb: API change, control receive endpoint_t
Changed the usb API where the control function first parameter now
is a pointer of endpoint_t instead of a pointer of usbdevice_t.
Changing the API like this is a good thing.
The previous implementation assumed the first endpoint(index 0) as
control, which is not true, we can have devices with more than a
single control line.
What do you mean by index 0 here? Is it the index in an array in the
USB stack? Is it the endpoint number?
Sorry, I forgot the mention. usbdev structure has an array of its endpoints.
Subject: [PATCH 4/5] uhci: control adaptations
Chaging the implementation of uhci_control function to match the api
changes done in the previous patch.
These two changes should be in the same commit, otherwise the code is
broken in between.
Ok.
Subject: [PATCH 5/5] control users: change the callers of -control
This also belongs in the same commit as 3 and 4.
Ok.
This patch introduces changes in the usb main program and msc driver
as well. It basically passes an endpoint_t instead of a usbdevice_t
to control function.
We are still assuming the first endpoint to be the control one. We
may need to change the functions in usb.c with a depper adaptation
to accommodate drivers for devices with more than a single control
endpoint but for now endpoint[0] should work.
How is this array populated?
In the set_address, this function is called when a device is
attached, the function usb_attach_device calls set_address to
configure the new detected device. The array is populated based on
interface_descriptor_t which reports the bNumEndpoints(number of
endpoints) but before anything it does configure an endpoint[0].type =
CONTROL.
The default pipe always accepts control transfers, but is it
automatically populated to index 0 in the endpoints array? Note that
the default pipe does not usually show up in any descriptor.
Answered above.
There are some issues in the following code:
@@ -109,7 +109,7 @@ set_feature (usbdev_t *dev, int endp, int feature, int
rtype)
+ dev-controller-control (dev-endpoints[endp], OUT, sizeof (dr),
dr, 0, 0);
This is good. (Or is it? Is endp specified in the API to be the
index, and not the endpoint number?)
Yes sorry, maybe wrong. It should be [0].
@@ -123,7 +123,7 @@ get_status (usbdev_t *dev, int intf, int rtype, int len,
void *data)
+ dev-controller-control (dev-endpoints[intf], IN, sizeof (dr), dr,
len, data);
Here an interface number is suddenly used as index in the endpoints
array. Please explain how that can be correct?
Same here.
@@ -134,6 +134,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ endpoint_t *ep = dev-endpoints[langID];
Here langID is used as index in the endpoints array. That also seems
like it will be a problem.
Yes, same as above.
@@ -141,7 +142,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ if (dev-controller-control (ep, IN, sizeof (dr), dr, 8, buf)) {
Where does this ep come from?
From the declaration you commented above. :)
@@ -165,7 +166,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ control (ep, IN, sizeof (dr), dr, size, result)) {
Same one..
Same as above.
@@ -183,7 +184,7 @@ set_configuration (usbdev_t *dev)
+ dev-controller-control (dev-endpoints[0], OUT, sizeof (dr), dr,
0, 0);
Is index 0 in endpoints guaranteed to always be the default endpoint?
Yes, in fact it should be used in every call commented previously.
@@ -201,7 +202,7 @@ clear_stall (endpoint_t *ep)
+ dev-controller-control (ep, OUT, sizeof (dr), dr, 0, 0);
Good.
@@ -246,7 +247,7 @@ set_address (hci_t *controller, int lowspeed)
+ if (dev-controller-control (dev-endpoints[0], OUT, sizeof (dr),
dr, 0, 0)) {
Again with index 0. And it happens a few more times.
Ok, it should always be 0.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
[coreboot] [v2] r4460 - in trunk/coreboot-v2/src: arch/i386/boot arch/i386/include/arch mainboard/intel/eagleheights mainboard/kontron/986lcd-m mainboard/via/vt8454c
Author: stepan
Date: 2009-07-22 00:15:43 +0200 (Wed, 22 Jul 2009)
New Revision: 4460
Modified:
trunk/coreboot-v2/src/arch/i386/boot/acpi.c
trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h
trunk/coreboot-v2/src/mainboard/intel/eagleheights/acpi_tables.c
trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/acpi_tables.c
trunk/coreboot-v2/src/mainboard/via/vt8454c/acpi_tables.c
Log:
clean up acpi table strings, as discussed on the list
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/coreboot-v2/src/arch/i386/boot/acpi.c
===
--- trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-21 22:01:21 UTC (rev
4459)
+++ trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-21 22:15:43 UTC (rev
4460)
@@ -177,9 +177,9 @@
memset((void *)madt, 0, sizeof(acpi_madt_t));
/* fill out header fields */
- memcpy(header-signature, MADT_NAME, 4);
+ memcpy(header-signature, APIC, 4);
memcpy(header-oem_id, OEM_ID, 6);
- memcpy(header-oem_table_id, MADT_TABLE, 8);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_madt_t);
@@ -205,9 +205,9 @@
memset((void *)mcfg, 0, sizeof(acpi_mcfg_t));
/* fill out header fields */
- memcpy(header-signature, MCFG_NAME, 4);
+ memcpy(header-signature, MCFG, 4);
memcpy(header-oem_id, OEM_ID, 6);
- memcpy(header-oem_table_id, MCFG_TABLE, 8);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_mcfg_t);
@@ -232,7 +232,7 @@
{
unsigned long current=(unsigned long)ssdt+sizeof(acpi_header_t);
memset((void *)ssdt, 0, sizeof(acpi_header_t));
- memcpy(ssdt-signature, SSDT_NAME, 4);
+ memcpy(ssdt-signature, SSDT, 4);
ssdt-revision = 2;
memcpy(ssdt-oem_id, OEM_ID, 6);
memcpy(ssdt-oem_table_id, oem_table_id, 8);
@@ -289,9 +289,9 @@
memset((void *)srat, 0, sizeof(acpi_srat_t));
/* fill out header fields */
-memcpy(header-signature, SRAT_NAME, 4);
+memcpy(header-signature, SRAT, 4);
memcpy(header-oem_id, OEM_ID, 6);
-memcpy(header-oem_table_id, SRAT_TABLE, 8);
+memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_srat_t);
@@ -316,9 +316,9 @@
memset((void *)slit, 0, sizeof(acpi_slit_t));
/* fill out header fields */
-memcpy(header-signature, SLIT_NAME, 4);
+memcpy(header-signature, SLIT, 4);
memcpy(header-oem_id, OEM_ID, 6);
-memcpy(header-oem_table_id, SLIT_TABLE, 8);
+memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_slit_t);
@@ -343,7 +343,7 @@
/* fill out header fields */
memcpy(header-signature, HPET_NAME, 4);
memcpy(header-oem_id, OEM_ID, 6);
- memcpy(header-oem_table_id, HPET_TABLE, 8);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_hpet_t);
@@ -367,7 +367,7 @@
memset( (void *)facs,0, sizeof(acpi_facs_t));
- memcpy(facs-signature, FACS_NAME, 4);
+ memcpy(facs-signature, FACS, 4);
facs-length = sizeof(acpi_facs_t);
facs-hardware_signature = 0;
facs-firmware_waking_vector = 0;
@@ -383,9 +383,9 @@
acpi_header_t *header=(rsdt-header);
/* fill out header fields */
- memcpy(header-signature, RSDT_NAME, 4);
+ memcpy(header-signature, RSDT, 4);
memcpy(header-oem_id, OEM_ID, 6);
- memcpy(header-oem_table_id, RSDT_TABLE, 8);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_rsdt_t);
@@ -405,9 +405,9 @@
acpi_header_t *header=(xsdt-header);
/* fill out header fields */
- memcpy(header-signature, XSDT_NAME, 4);
+ memcpy(header-signature, XSDT, 4);
memcpy(header-oem_id, OEM_ID, 6);
- memcpy(header-oem_table_id, RSDT_TABLE, 8);
+ memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
header-length = sizeof(acpi_xsdt_t);
@@ -533,7 +533,7 @@
for (i = 0; ((char *) rsdt-entry[i]) end; i++) {
fadt = (acpi_fadt_t *) rsdt-entry[i];
- if (strncmp((char *)fadt, FADT_NAME, sizeof(FADT_NAME) - 1) ==
0)
+ if (strncmp((char *)fadt, FACP, 4) == 0)
break;
fadt = NULL;
}
Modified:
[coreboot] build service results for r4447
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4447 to the coreboot repository. This caused the following changes: Change Log: Some USB debug updates, mostly comments fixing, license header updates and refactoring Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4447device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB changes
Hi again Leandro,
Leandro Dorileo wrote:
The hci_reg_* functions use the reg_base in hci_t structure to
determine which port to write to/read from, this structure is used
both for OHCI, UHCI and will be for EHCI, so doesn`t matter if the
controller is UHCI or OHCI there will always be a reg_base, with
that I thought I could move it to usb.h and reuse it.
Right, but my point is that the different HCIs may not have the same
registers so just changing the names of the register acccess
functions may not be very useful?
We are still assuming the first endpoint to be the control one. We
may need to change the functions in usb.c with a depper adaptation
to accommodate drivers for devices with more than a single control
endpoint but for now endpoint[0] should work.
How is this array populated?
The array is populated based on interface_descriptor_t which reports
the bNumEndpoints(number of endpoints) but before anything it does
configure an endpoint[0].type = CONTROL.
Ok, but what about the endpoint address?
Is the array index guaranteed to always be the same as the endpoint
address sent on the bus?
Or is the endpoint address for each endpoint stored in the struct?
Note there can be two endpoints with the same address. (IN and OUT)
My point is that the default pipe is the endpoint with address 0, so
only if that is actually guaranteed by endpoint[0] then it's ok to
use endpoint[0]. Otherwise I guess there should be a function to look
up the default endpoint for the device.
@@ -109,7 +109,7 @@ set_feature (usbdev_t *dev, int endp, int feature, int
rtype)
+ dev-controller-control (dev-endpoints[endp], OUT, sizeof (dr),
dr, 0, 0);
This is good. (Or is it? Is endp specified in the API to be the
index, and not the endpoint number?)
Yes sorry, maybe wrong. It should be [0].
Hm, I don't know.
SET_FEATURE can be sent to either device (bmRequestType=0), interface
or endpoint. What is endp? Is it explicitly documented to be the
index of the endpoints array - or is it the endpoint address as
described in the USB spec?
Also, possibly the function should accept an intf argument. The same
issue with USB stack array index vs. actual number in hardware
applies to interfaces. Interfaces have a number in hardware, and
that's what I think applications calling libpayload should be using.
I realize this discussion is a little out of scope for your project,
because it is about libpayload USB in general, but I still think it
should be cleared up - I think libpayload USB will be more popular in
the future thanks to added HCI support.
@@ -123,7 +123,7 @@ get_status (usbdev_t *dev, int intf, int rtype, int
len, void *data)
+ dev-controller-control (dev-endpoints[intf], IN, sizeof (dr),
dr, len, data);
Here an interface number is suddenly used as index in the endpoints
array. Please explain how that can be correct?
Same here.
Again, I'm not sure.
GET_STATUS can also be sent to device, interface or endpoint. The
function should probably handle that somehow.
@@ -141,7 +142,7 @@ get_descriptor (usbdev_t *dev, unsigned char
bmRequestType, int descType,
+ if (dev-controller-control (ep, IN, sizeof (dr), dr, 8, buf)) {
Where does this ep come from?
From the declaration you commented above. :)
Right! Thanks! ;)
@@ -183,7 +184,7 @@ set_configuration (usbdev_t *dev)
+ dev-controller-control (dev-endpoints[0], OUT, sizeof (dr), dr,
0, 0);
Is index 0 in endpoints guaranteed to always be the default endpoint?
Yes,
Ok.
in fact it should be used in every call commented previously.
Well, see above..
@@ -201,7 +202,7 @@ clear_stall (endpoint_t *ep)
+ dev-controller-control (ep, OUT, sizeof (dr), dr, 0, 0);
Good.
Actually it isn't. CLEAR_FEATURE can be sent to device, interface or
endpoint just like SET_FEATURE and GET_STATUS.
Thanks a lot for reviewing.
No problem.
Maybe the whole API should be changed to match devices with more
than one control endpoint, but this is a first change.
Right. I think that's a good idea.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4448
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4448 to the coreboot repository. This caused the following changes: Change Log: - Remove superfluous / from path - use make -C instead of workaround Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Build Log: Compilation of gigabyte:m57sli has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4448device=m57slivendor=gigabytenum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4448device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4449
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4449 to the coreboot repository. This caused the following changes: Change Log: Rewrite keyboard driver to actually wait time in ms as specified in the specs, rather than doing inexact and slow idle loops. Also improve error reporting in case of problems. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4449device=m57slivendor=gigabytenum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4449device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4450
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4450 to the coreboot repository. This caused the following changes: Change Log: Example how simple it is to use printk instead of printk_something in coreboot ram stage. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4450device=m57slivendor=gigabytenum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4450device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4451
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4451 to the coreboot repository. This caused the following changes: Change Log: Add more warnings to CFLAGS, and also add some to HOSTCFLAGS include ldoptions from ldscript.ld instead appending it. Not everyone was happy about the -Wmissing-prototypes in CFLAGS. I put it in there now anyways, so everyone can get an overview which parts of their code could use some cleanup. If it gets too ugly, we can still remove that flag again. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4451device=m57slivendor=gigabytenum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4451device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4452
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4452 to the coreboot repository. This caused the following changes: Change Log: Rewrite interrupt handling in coreboot to be more comprehensible and more flexible. Also some minore device allocator cleanups that sneaked in. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4452device=m57slivendor=gigabytenum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4452device=epia-mvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4453
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4453 to the coreboot repository. This caused the following changes: Change Log: This fixes a couple of issues with older Linux kernels (that expect an XSDT as soon as there's an ACPI 2.0 or later table) * add XSDT support * add more table types This patch will break at least the kontron (and possibly some new boards I missed) Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4453device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4453device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4453device=986lcd-mvendor=kontronnum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4453device=epia-mvendor=vianum=2 Compilation of via:epia-m700 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4453device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [v2] r4461 - in trunk/coreboot-v2/src: arch/i386/boot arch/i386/include/arch mainboard/amd/serengeti_cheetah_fam10 mainboard/gigabyte/m57sli mainboard/intel/eagleheights mainboard/via/epia-
Author: stepan
Date: 2009-07-22 03:11:37 +0200 (Wed, 22 Jul 2009)
New Revision: 4461
Modified:
trunk/coreboot-v2/src/arch/i386/boot/acpi.c
trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c
trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb
trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/acpi_tables.c
trunk/coreboot-v2/src/mainboard/intel/eagleheights/acpi_tables.c
trunk/coreboot-v2/src/mainboard/via/epia-m700/acpi_tables.c
trunk/coreboot-v2/src/mainboard/via/epia-n/acpi_tables.c
trunk/coreboot-v2/src/northbridge/amd/amdfam10/amdfam10_acpi.c
Log:
Fix up the tree again...
* acpi_add_table requires a pointer to the RSDP, not the RSDT anymore, in order
to properly support XSDT generation.
* fix compilation the DSDT on gigabyte/m57sli
* drop a remaining, forgotten HPET_NAME for HPET
Signed-off-by: Stefan Reinauer ste...@coresystems.de
Acked-by: Stefan Reinauer ste...@coresystems.de
Modified: trunk/coreboot-v2/src/arch/i386/boot/acpi.c
===
--- trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-21 22:15:43 UTC (rev
4460)
+++ trunk/coreboot-v2/src/arch/i386/boot/acpi.c 2009-07-22 01:11:37 UTC (rev
4461)
@@ -341,7 +341,7 @@
memset((void *)hpet, 0, sizeof(acpi_hpet_t));
/* fill out header fields */
- memcpy(header-signature, HPET_NAME, 4);
+ memcpy(header-signature, HPET, 4);
memcpy(header-oem_id, OEM_ID, 6);
memcpy(header-oem_table_id, ACPI_TABLE_CREATOR, 8);
memcpy(header-asl_compiler_id, ASLC, 4);
Modified: trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h
===
--- trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h 2009-07-21 22:15:43 UTC
(rev 4460)
+++ trunk/coreboot-v2/src/arch/i386/include/arch/acpi.h 2009-07-22 01:11:37 UTC
(rev 4461)
@@ -389,7 +389,7 @@
#endif
-unsigned long acpi_add_ssdt_pstates(acpi_rsdt_t *rsdt, unsigned long current);
+unsigned long acpi_add_ssdt_pstates(acpi_rsdp_t *rsdp, unsigned long current);
#define ACPI_WRITE_MADT_IOAPIC(dev,id) \
do {\
Modified:
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c
===
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c
2009-07-21 22:15:43 UTC (rev 4460)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c
2009-07-22 01:11:37 UTC (rev 4461)
@@ -274,7 +274,7 @@
acpi_add_table(rsdp,ssdt);
printk_debug(ACPI:* SSDT for PState at %lx\n, current);
- current = acpi_add_ssdt_pstates(rsdt, current);
+ current = acpi_add_ssdt_pstates(rsdp, current);
#if CONFIG_ACPI_SSDTX_NUM = 1
Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb
===
--- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2009-07-21
22:15:43 UTC (rev 4460)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Config.lb 2009-07-22
01:11:37 UTC (rev 4461)
@@ -170,8 +170,8 @@
object acpi_tables.o
makerule dsdt.c
depends $(CONFIG_MAINBOARD)/dsdt.asl
- action iasl -p $(PWD)/dsdt -tc $(CONFIG_MAINBOARD)/dsdt.asl
- action mv dsdt.hex dsdt.c
+ action iasl -p dsdt -tc $(CONFIG_MAINBOARD)/dsdt.asl
+ action mv $(CURDIR)/dsdt.hex dsdt.c
end
object ./dsdt.o
end
Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/acpi_tables.c
===
--- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/acpi_tables.c
2009-07-21 22:15:43 UTC (rev 4460)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/acpi_tables.c
2009-07-22 01:11:37 UTC (rev 4461)
@@ -130,7 +130,7 @@
/* Clear all table memory. */
memset((void *) start, 0, current - start);
- acpi_write_rsdp(rsdp, rsdt);
+ acpi_write_rsdp(rsdp, rsdt, NULL);
acpi_write_rsdt(rsdt);
/* We explicitly add these tables later on: */
@@ -156,39 +156,39 @@
current += sizeof(acpi_fadt_t);
acpi_create_fadt(fadt, facs, dsdt);
- acpi_add_table(rsdt, fadt);
+ acpi_add_table(rsdp, fadt);
printk_debug(ACPI:* HPET\n);
hpet = (acpi_hpet_t *) current;
current += sizeof(acpi_hpet_t);
acpi_create_hpet(hpet);
- acpi_add_table(rsdt, hpet);
+ acpi_add_table(rsdp, hpet);
/* If we want to use HPET timers Linux wants an MADT. */
printk_debug(ACPI:* MADT\n);
madt = (acpi_madt_t *) current;
acpi_create_madt(madt);
current += madt-header.length;
- acpi_add_table(rsdt, madt);
+
[coreboot] build service results for r4454
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4454 to the coreboot repository. This caused the following changes: Change Log: add intel speedstep support and some PM fixes. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4454device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4454device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4454device=986lcd-mvendor=kontronnum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4454device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4454device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4455
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4455 to the coreboot repository. This caused the following changes: Change Log: * drop ich7 include * detect more i945 variants * raminit fixes * ACPI + PCIe updates Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4455device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4455device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4455device=986lcd-mvendor=kontronnum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4455device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4455device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4456
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4456 to the coreboot repository. This caused the following changes: Change Log: Intel ICH7 updates - code restructuring (move ich7 out of i945) - ACPI fixes - major SMI handler updates - make sure SMBus lives where we expect it - try to get usb debug working Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4456device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4456device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4456device=986lcd-mvendor=kontronnum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4456device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4456device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB changes
Hi Peter
On Tue, Jul 21, 2009 at 6:35 PM, Peter Stugepe...@stuge.se wrote:
Leandro Dorileo wrote:
The hci_reg_* functions use the reg_base in hci_t structure to
determine which port to write to/read from, this structure is used
both for OHCI, UHCI and will be for EHCI, so doesn`t matter if the
controller is UHCI or OHCI there will always be a reg_base, with
that I thought I could move it to usb.h and reuse it.
Right, but my point is that the different HCIs may not have the same
registers
Yes, sure and they don`t have the same registers.
so just changing the names of the register acccess
functions may not be very useful?
The reg_base is a u32 field which`s the base address for control
registers, it`s differently set for different Host Controller. For
example, on UHCI we do:
controller-reg_base = pci_read_config32 (controller-bus_address, 0x20) ~1;
but for OHCI we do:
controller-reg_base = pci_read_config32 (controller-bus_address, 0x10)
UHCI for example calls hci_reg_write32 with FLBASEADD reg offset(which
is not present on OHCI). Lets look at hci_reg_write32 function:
void
hci_reg_write32 (hci_t *ctrl, int reg, u32 value)
{
outl (value, ctrl-reg_base + reg);
}
Like I told you it`ll use the control base address to take to the
specific reg address, that may differ from Host Controller to Host
Controller. On OHCI code for example we do:
hci_reg_write32(controller, OHCI_REG_HCCA, \
(u32) virt_to_phys (OHCI_INST (controller)-hcca));
In the above snippet we use OHCI_REG_HCCA that`s the offset for HCCA
register, we don`t have this field on UHCI and the reg_base is set
with the proper control registers base address.
I understand it works exactly the same way to any Host Controller and
both drivers can use the same function(but configuring properly the
base control address and passing the correct offset to the wanted
register). The fact of having reg_base to determine the base address
of control registers makes me think I can use the save function for
both Host Controllers, they work exactly the same way.
We are still assuming the first endpoint to be the control one. We
may need to change the functions in usb.c with a depper adaptation
to accommodate drivers for devices with more than a single control
endpoint but for now endpoint[0] should work.
How is this array populated?
The array is populated based on interface_descriptor_t which reports
the bNumEndpoints(number of endpoints) but before anything it does
configure an endpoint[0].type = CONTROL.
Ok, but what about the endpoint address?
Is the array index guaranteed to always be the same as the endpoint
address sent on the bus?
Or is the endpoint address for each endpoint stored in the struct?
Note there can be two endpoints with the same address. (IN and OUT)
My point is that the default pipe is the endpoint with address 0, so
only if that is actually guaranteed by endpoint[0] then it's ok to
use endpoint[0]. Otherwise I guess there should be a function to look
up the default endpoint for the device.
Hum, I think I got your point here. Is there anything that guarantee
us the first endpoint will always be control one with address 0 and
direction.
Well, I couldn`t find some information about it on usb specification -
I`m almost sure it`s defined on class device specification. The MSC
specification states Every USB device also defines a Control endpoint
(Endpoint 0). This is the default endpoint ... but it may be
different to other classes.
Since we only support MSC and HID this should work. I think we`ll need
a small redesign addressing these issues whenever we get to support
other devices and surely a function to look up the default endpoint
will be needed(in the case the other devices can not behave like MSC
and HID regarding control endpoints).
@@ -109,7 +109,7 @@ set_feature (usbdev_t *dev, int endp, int feature,
int rtype)
+ dev-controller-control (dev-endpoints[endp], OUT, sizeof (dr),
dr, 0, 0);
This is good. (Or is it? Is endp specified in the API to be the
index, and not the endpoint number?)
Yes sorry, maybe wrong. It should be [0].
Hm, I don't know.
SET_FEATURE can be sent to either device (bmRequestType=0), interface
or endpoint. What is endp? Is it explicitly documented to be the
index of the endpoints array - or is it the endpoint address as
described in the USB spec?
it`s the endpoint address as described in the USB spec. I think your
point here is the endpoint address, if so the previous comments might
explain.
Also, possibly the function should accept an intf argument. The same
issue with USB stack array index vs. actual number in hardware
applies to interfaces. Interfaces have a number in hardware, and
that's what I think applications calling libpayload should be using.
It shouldn`t be using intf since all we need to control function is
the control endpoint. With the endpoint_t we can find the
[coreboot] build service results for r4457
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4457 to the coreboot repository. This caused the following changes: Change Log: this bug sneaked in during conversion Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4457device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4457device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4457device=986lcd-mvendor=kontronnum=2 Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4457device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4457device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4458
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4458 to the coreboot repository. This caused the following changes: Change Log: Kontron updates, get board up to date with i945 and ich7 updates. Move interrupt routing to mainboard specific code. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Peter Stuge pe...@stuge.se Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4458device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4458device=eagleheightsvendor=intelnum=2 Compilation of kontron:986lcd-m has been fixed Compilation of via:epia-m is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4458device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4458device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4459
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4459 to the coreboot repository. This caused the following changes: Change Log: Another include file slipped. This gets via/epia-m building again. Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4459device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4459device=eagleheightsvendor=intelnum=2 Compilation of via:epia-m has been fixed Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4459device=epia-m700vendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4460
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4460 to the coreboot repository. This caused the following changes: Change Log: clean up acpi table strings, as discussed on the list Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of amd:dbm690t has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=dbm690tvendor=amdnum=2 Compilation of amd:pistachio has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=pistachiovendor=amdnum=2 Compilation of amd:serengeti_cheetah has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=serengeti_cheetahvendor=amdnum=2 Compilation of amd:serengeti_cheetah_fam10 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=serengeti_cheetah_fam10vendor=amdnum=2 Compilation of asus:a8v-e_se has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=a8v-e_sevendor=asusnum=2 Compilation of asus:m2v-mx_se has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=m2v-mx_sevendor=asusnum=2 Compilation of gigabyte:m57sli is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=m57slivendor=gigabytenum=2 Compilation of intel:eagleheights is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=eagleheightsvendor=intelnum=2 Compilation of intel:xe7501devkit has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=xe7501devkitvendor=intelnum=2 Compilation of iwill:dk8_htx has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=dk8_htxvendor=iwillnum=2 Compilation of kontron:986lcd-m has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=986lcd-mvendor=kontronnum=2 Compilation of technexion:tim8690 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=tim8690vendor=technexionnum=2 Compilation of tyan:s2891 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=s2891vendor=tyannum=2 Compilation of tyan:s2892 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=s2892vendor=tyannum=2 Compilation of tyan:s2895 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=s2895vendor=tyannum=2 Compilation of via:epia-m has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=epia-mvendor=vianum=2 Compilation of via:epia-m700 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=epia-m700vendor=vianum=2 Compilation of via:vt8454c has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4460device=vt8454cvendor=vianum=2 If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] build service results for r4461
Dear coreboot readers! This is the automatic build system of coreboot. The developer stepan checked in revision 4461 to the coreboot repository. This caused the following changes: Change Log: Fix up the tree again... * acpi_add_table requires a pointer to the RSDP, not the RSDT anymore, in order to properly support XSDT generation. * fix compilation the DSDT on gigabyte/m57sli * drop a remaining, forgotten HPET_NAME for HPET Signed-off-by: Stefan Reinauer ste...@coresystems.de Acked-by: Stefan Reinauer ste...@coresystems.de Build Log: Compilation of amd:dbm690t has been fixed Compilation of amd:pistachio has been fixed Compilation of amd:serengeti_cheetah has been fixed Compilation of amd:serengeti_cheetah_fam10 has been fixed Compilation of asus:a8v-e_se has been fixed Compilation of asus:m2v-mx_se has been fixed Compilation of gigabyte:m57sli has been fixed Compilation of intel:eagleheights has been fixed Compilation of intel:xe7501devkit has been fixed Compilation of iwill:dk8_htx has been fixed Compilation of kontron:986lcd-m has been fixed Compilation of technexion:tim8690 has been fixed Compilation of tyan:s2891 has been fixed Compilation of tyan:s2892 has been fixed Compilation of tyan:s2895 has been fixed Compilation of via:epia-m has been fixed Compilation of via:epia-m700 has been fixed Compilation of via:vt8454c has been fixed If something broke during this checkin please be a pain in stepan's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
