headers
Patrick Georgi | 1 Nov 2011 08:48
Favicon

New patch to review for coreboot: 2c703c1 libpayload: Fix OHCI some more

Patrick Georgi (patrick <at> georgi-clan.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/365

-gerrit

commit 2c703c13954fcef101135ffd7113889f4c22e3ca
Author: Patrick Georgi <patrick.georgi <at> secunet.com>
Date:   Thu Oct 27 13:08:13 2011 +0200

    libpayload: Fix OHCI some more

    OHCI works when USB_DEBUG is disabled, but not, when disabled.
    This is because the controller requires some more time after a
    schedule has finished.

    Also improve compliance with the OHCI spec.

    Change-Id: I4685cc485ff9c52b489fbaa352ab889671cff876
    Signed-off-by: Patrick Georgi <patrick.georgi <at> secunet.com>
---
 payloads/libpayload/drivers/usb/ohci.c |   14 ++++++++------
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/payloads/libpayload/drivers/usb/ohci.c b/payloads/libpayload/drivers/usb/ohci.c
index 290f782..ef33bd9 100644
--- a/payloads/libpayload/drivers/usb/ohci.c
+++ b/payloads/libpayload/drivers/usb/ohci.c
 <at>  <at>  -27,7 +27,7  <at>  <at> 
  * SUCH DAMAGE.
  */
(Continue reading)

Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 10:00
Favicon

Re: #162: Move SYSTEM_TYPE to Kconfig

#162: Move SYSTEM_TYPE to Kconfig
----------------------------------+------------------------
    Reporter:  oxygene            |         Owner:  oxygene
        Type:  enhancement        |        Status:  new
    Priority:  minor              |     Milestone:
   Component:  coreboot           |    Resolution:
    Keywords:                     |  Dependencies:
Patch Status:  there is no patch  |
----------------------------------+------------------------

Comment (by christophg+cb <at> …):

 AFAIK there are two spots where the system type is given to the OS:
 in the DMI table (chassis type) and in the ACPI FADT table
 (Preferred_PM_Profile)

 I don't know where (or even if) coreboot writes the DMI table, and
 currently the FADT PM profile is hardcoded in the mainboards' fadt.c.

 I also think, SYSTEM_TYPE should be moved to Kconfig, be combined with DMI
 chassis type (if applicable) and also an option for the preferred PM
 profile should be added (of course defaulting to the SYSTEM_TYPE if not
 changed by user)

 IMHO there are various advantages:
 * users can change the reported system/chassis type dependant on the real
 usage of the board without meddling with the mainboards C code
 * the PM profile could be equally changed (hardcoding this for a board
 type IMO is absurd as it equally depends on the mainboard and the real
 usage)
(Continue reading)

Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 10:01
Favicon

Re: #178: linux kernel hang while boot from SATA SSD on EPIA CN

#178: linux kernel hang while boot from SATA SSD on EPIA CN
----------------------------------+-------------------------
    Reporter:  ryzhovsergey <at> …     |         Owner:  stepan <at> …
        Type:  defect             |        Status:  new
    Priority:  major              |     Milestone:
   Component:  coreboot           |    Resolution:
    Keywords:  SATA SSD EPIA CN   |  Dependencies:
Patch Status:  there is no patch  |
----------------------------------+-------------------------

Comment (by ryzhovsergey <at> …):

 Is any news here ?

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/178#comment:1>
coreboot <http://www.coreboot.org/>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 10:04
Favicon

Re: #5: Add license header to all source files

#5: Add license header to all source files
----------------------------------+---------------------------------------
    Reporter:  uwe                |         Owner:  uwe
        Type:  task               |        Status:  new
    Priority:  blocker            |     Milestone:  Resolve license issues
   Component:  coreboot           |    Resolution:
    Keywords:                     |  Dependencies:
Patch Status:  there is no patch  |
----------------------------------+---------------------------------------

Comment (by oxygene):

 One of our lint tests ("make lint") looks for proper license headers.

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/5#comment:8>
coreboot <http://www.coreboot.org/>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 10:07
Favicon

Re: #177: Not compiling coreBoot

#177: Not compiling coreBoot
----------------------------------+---------------------------
    Reporter:  darkshvein <at> …       |         Owner:  stepan <at> …
        Type:  defect             |        Status:  closed
    Priority:  major              |     Milestone:
   Component:  coreboot           |    Resolution:  worksforme
    Keywords:  compile error      |  Dependencies:
Patch Status:  there is no patch  |
----------------------------------+---------------------------
Changes (by oxygene):

 * status:  new => closed
 * resolution:   => worksforme

Comment:

 We should have fixed all such issues by now.

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/177#comment:1>
coreboot <http://www.coreboot.org/>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 11:00
Favicon

Re: #179: Coreboot on GigaByte GA-8IEXP ver. 1.2

#179: Coreboot on GigaByte GA-8IEXP ver. 1.2
----------------------------------+---------------------------------
    Reporter:  BlackSheep0 <at> …      |         Owner:  stepan <at> …
        Type:  enhancement        |        Status:  closed
    Priority:  minor              |     Milestone:  Going mainstream
   Component:  coreboot           |    Resolution:  invalid
    Keywords:                     |  Dependencies:
Patch Status:  there is no patch  |
----------------------------------+---------------------------------
Changes (by oxygene):

 * status:  new => closed
 * resolution:   => invalid

Comment:

 First, "do that for me" won't work without access to the hardware.

 Second, "do that for me" is quite a request when porting to a board can
 take an experienced developer up to 6 months (or more, if the developer
 faces extraordinary problems)

 Third, Dual BIOS usually don't help because we completely strip the
 recovery routines (though Gigabyte might have some hardware circuit using
 a watchdog, or something)

 Due to all this, closed as invalid.

--

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/179#comment:1>
(Continue reading)

Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 11:12
Favicon

Re: #169: ASUS P4PE-X/SE.

#169: ASUS P4PE-X/SE.
----------------------------------+--------------------------------
    Reporter:  anonymous          |         Owner:  stepan <at> …
        Type:  defect             |        Status:  closed
    Priority:  major              |     Milestone:
   Component:  coreboot           |    Resolution:  invalid
    Keywords:  ASUS P4PE-X/SE.    |  Dependencies:  ASUS P4PE-X/SE.
Patch Status:  there is no patch  |
----------------------------------+--------------------------------
Changes (by oxygene):

 * status:  new => closed
 * resolution:   => invalid

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/169#comment:2>
coreboot <http://www.coreboot.org/>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
coreboot | 1 Nov 2011 11:36
Favicon

Re: #170: Need coreboot for ASUS P4PE_X/SE

#170: Need coreboot for ASUS P4PE_X/SE
---------------------------------------+-------------------------
    Reporter:  aav <at> …                   |         Owner:  stepan <at> …
        Type:  defect                  |        Status:  closed
    Priority:  major                   |     Milestone:
   Component:  coreboot                |    Resolution:  invalid
    Keywords:  corebootASUS P4PE_X/SE  |  Dependencies:
Patch Status:  there is no patch       |
---------------------------------------+-------------------------
Changes (by oxygene):

 * status:  new => closed
 * resolution:   => invalid

Comment:

 Don't dump board support requests on us. Boards are done when people step
 up to implement support for them.

-- 
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/170#comment:2>
coreboot <http://www.coreboot.org/>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
Kyösti Mälkki | 1 Nov 2011 14:02
Picon

Re: Trouble with cbfstool when attempting dualboot

On Mon, 2011-10-31 at 15:20 +0100, Patrick Georgi wrote: 
> Am Montag, 31. Oktober 2011 07:32:50 schrieb Kyösti Mälkki:
> > If my new normal/romstage is built with GCC for Cache-As-Ram, the same
> > alignment does not apply and on boot it halts before any serial output.
> Does it "halt" or is it just _very_ slow (several minutes until the 
> first life sign on serial)? The latter would indicate wrong MTRR setup, 
> while the former is a more fundamental problem.
> 

It isn't only slow. I did experience the slow version with bad MTRR
setup when I did the big->tiny bootblock switch and MTRR setup missed
one ~.

My Cache-As-Ram boot enters intel/car/cache_as_ram.inc but never reaches
LogicalAP_SIPINotdone in it. I found a note in this file saying LAPIC ID
logic works only for processors with two threads, so does a dual Xeon
P4/HT setup require re-writing this logic? The car.inc was earlier used
for Tyan s2735 that is also dual-Xeon board with same socket.

I happen to have normal/romstage that does not cross CONFIG_XIP_ROM_SIZE
boundary. I think it is a bug in cbfstool that normal/romstage placement
is unaligned, since early_mtrr_init does not cover cases where
normal/romstage crosses said boundary. One would witness the very slow
boot effect then, too.

Updated image with normal/romstage compiled with ROMCC: 

coreboot.rom: 512 kB, bootblocksize 978, romsize 524288, offset 0x0
Alignment: 64 bytes
(Continue reading)

Permalink | Reply | 1 comment |
headers
Patrick Georgi | 1 Nov 2011 18:27
Picon

Re: Trouble with cbfstool when attempting dualboot

Am 01.11.2011 14:02, schrieb Kyösti Mälkki:
> My Cache-As-Ram boot enters intel/car/cache_as_ram.inc but never reaches
> LogicalAP_SIPINotdone in it. I found a note in this file saying LAPIC ID
> logic works only for processors with two threads, so does a dual Xeon
> P4/HT setup require re-writing this logic?
Possibly. Comparing the code to the datasheets will give you a 
definitive answer.
> I happen to have normal/romstage that does not cross CONFIG_XIP_ROM_SIZE
> boundary. I think it is a bug in cbfstool that normal/romstage placement
> is unaligned,
It is aligned...
>   since early_mtrr_init does not cover cases where
> normal/romstage crosses said boundary.
... which is why this works.

Patrick

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |

Gmane