coreboot October 2009

coreboot@coreboot.org

63 participants
534 discussions

Re: [coreboot] How do I turn on display with RS690 ?
by Kevin O'Connor 31 Oct '09

31 Oct '09

On Mon, Oct 19, 2009 at 03:30:41PM +0900, 유택연 wrote: > I do not solved this problem. > > I already tried with named 'pci1002,791f.rom' for vbios file. > But it can not help. > > I acquired this vbios file from AMD which is customized for my mainboard. >From the original report: > Searching CBFS for prefix vgaroms/ > Found CBFS file fallback/payload > Found CBFS file fallback/coreboot_ram > Found CBFS file vgaroms/radeon.rom > Copying data 55296@0xfff20678 to 196608@0x000c0000 > Checking rom 0x000c0000 (sig aa55 size 108) > Running option rom at c000:0003 > fail handle_15XX:294(86): > a=00004e08 b=00000080 c=00000000 d=0000c000 ds=c000 es=f000 ss=0000 > si=0000abc8 di=0000b0b6 bp=00000000 sp=000079f2 cs=c000 ip=2cc2 f=0046 > fail handle_15XX:294(86): > a=07ff4e08 b=00000005 c=00004e17 d=0000c002 ds=c000 es=f000 ss=0000 > si=00002d58 di=0000b0b6 bp=000079d6 sp=000079f2 cs=c000 ip=2c5f f=0046 > fail handle_15XX:294(86): > a=00004e08 b=00000000 c=0000a401 d=00000080 ds=c000 es=f000 ss=0000 > si=0000abc8 di=0000b0b6 bp=000079d6 sp=000079f0 cs=c000 ip=2c19 f=0046 > Searching CBFS for prefix vgaroms/ It appears that the vga bios is trying to call some custom function of the main bios. This may prevent SeaBIOS from running the rom. Maybe with documentation on what "int 0x15 ah=4e" did on your board you could implement the logic in seabios. -Kevin

1 0

[v2] r4901 - /
by svn＠coreboot.org 31 Oct '09

31 Oct '09

Author: stepan Date: 2009-10-31 10:09:00 +0100 (Sat, 31 Oct 2009) New Revision: 4901 Added: tags/ Log: add tags directory Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de>

1 0

Re: [coreboot] SeaBIOS and USB UHCI keyboard support
by Mansoor 30 Oct '09

30 Oct '09

Hi kevin, Today I tested SeaBIOS USB support in my board. Unfortunately it didn't work I connected a Dell keyboard. Here is the error log Starting SeaBIOS (version pre-0.4.3-20091009_174432-localhost.localdomain) init usb UHCI init on dev 00:1d.0 (io=f000) ebda moved from 9f400 to 9f000 config_usb: 0x000fdf80 1 uhci_control 7000000 Timeout on wait_qh 0x0009fff0 Please let me know if you any other information Regards Mansoor -----Original Message----- From: Mansoor [mailto:mansoor@iwavesystems.com] Sent: Wednesday, September 30, 2009 12:31 PM To: 'Kevin O'Connor'; 'Stefan Reinauer' Cc: 'coreboot' Subject: RE: [coreboot] SeaBIOS and USB UHCI keyboard support Its really a great news!!!. I will test this on my hardware (Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset) A dumb question here... Why SeaBIOS have constrains? Can't we elaborate SeaBIOS as a driver part of coreboot? I mean a legacy BIOS interrupts part(with constrains) + a driver section (includes support for various drivers like USB keyboard USB mouse USB CDROM Hard disk etc) without any constrains so that we can make use of current implementations from Linux or other open source Do you have any plan to support USB CD-ROM ? -----Original Message----- From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Kevin O'Connor Sent: Wednesday, September 30, 2009 6:24 AM To: Stefan Reinauer Cc: coreboot Subject: Re: [coreboot] SeaBIOS and USB UHCI keyboard support Hi Stefan, On Tue, Sep 29, 2009 at 04:47:04PM +0200, Stefan Reinauer wrote: > Kevin O'Connor wrote: > > The latest SeaBIOS git has preliminary support for USB keyboards. > > I've tested this on qemu and on my epia-cn. > > Would it not make sense to pack USB keyboard functionality into our GSoC > project instead, and use one common USB stack for all our projects? > Especially since this renders usbrom completely unusable; no two USB > stacks can operate the hw reliably at the same time. > > I'm a bit surprised by such action. I'm sorry you were surprised. I sent a note last month that I was going to look at this. I am truly sorry for the surprise and for any disappointment. SeaBIOS needs USB support in order to be usable on many platforms. I want SeaBIOS to be a "turn key" solution - that is, I want a vendor to be able to boot up coreboot+seabios and say, "hey, this 'just works'". I would prefer to pull in an external solution than implement a new one. Unfortunately, there isn't an external solution that works today. I looked closely at the libpayload code; I felt it would not work well in the constrained environment that SeaBIOS runs in. I believe libpayload could be extended to support that constrained environment, but I worry that would be an unnecessary burden on the other users of libpayload (which aren't so constrained). The support in SeaBIOS is currently 1029 lines of code - it is a direct, no nonsense, just make it work implementation. >Are you planning to add USB MSC > support as well? Should we stop the OHCI efforts too and wait for your > approach on that? If someone steps forward with a solution that "just works", then I will happily defer to that person. Otherwise, I will continue to add new features as I get time. The next thing I am planning to look at is basic ohci keyboard support, and then fleshing out the current keyboard support (eg, auto-repeat, keyboard leds). -Kevin -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot ---------------------------------------------------------------------------- --- DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ---------------------------------------------------------------------------- -- ------------------------------------------------------------------------------- DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation. ------------------------------------------------------------------------------

2 1

Fast booting: coreboot versus optimized UEFI
by Ken.Fuchs＠bench.com 30 Oct '09

30 Oct '09

Are there some hard numbers for coreboot initialization and bootloader payload time (from power-up/reset to the start of the OS kernel load)? Non-optimized UEFI starts up very slowly, in some cases slower than a legacy BIOS, but some optimized UEFI frameworks start up quite quickly and can begin booting within a few seconds of power on/reset. However, I suspect that even optimized UEFI is 2-3 slower than coreboot and a bootloader payload. Are there boards with both coreboot and UEFI support where the respective boot times are compared and published on the Internet? Sincerely, Ken Fuchs

3 2

#147: 8385traleftingvamte88 1747
by coreboot 30 Oct '09

30 Oct '09

#147: 8385traleftingvamte88 1747 ---------------------------------+------------------------------------------ Reporter: abotheber | Type: defect Status: new | Priority: major Component: code | Version: v2 Patchstatus: there is no patch | ---------------------------------+------------------------------------------ -- Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/147> coreboot <http://www.coreboot.org/>

1 0

[PATCH] We're not just version 2 anymore
by Stefan Reinauer 30 Oct '09

30 Oct '09

I know some people will claim this hurts. But it will hurt the same way when the version number is up to 4, so we better do it now than later: (This just renames coreboot-v2 to coreboot-devel in the tree) svn mv svn://coreboot.org/repos/trunk/coreboot-v2 \ svn://coreboot.org/repos/trunk/coreboot-devel Alternatively: (this moves all sudirectories of coreboot-v2 to trunk and wipes the coreboot-v2 directory as soon as it's empty. Then the directory hierarchy would be more similar to, e.g. flashrom) svn mv svn://coreboot.org/repos/trunk/coreboot-v2/{COPYING,Makefile,NEWS,README,do… \ svn://coreboot.org/repos/trunk/ svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{ADLO,abuild,analysis,cbfst… \ svn://coreboot.org/repos/trunk/util svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{kbuildall,kconfig,lbtdump,… \ svn://coreboot.org/repos/trunk/util svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{romcc,sconfig,vgabios,x86e… \ svn://coreboot.org/repos/trunk/util svn rm svn://coreboot.org/repos/trunk/coreboot-v2/ Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> PS: If you Ack, please let me know which of the alternatives. :-) All the best, Stefan

6 16

[PATCH] Remove warnings
by Myles Watson 30 Oct '09

30 Oct '09

These three patches get rid of a few more warnings for me. abuild tested. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> PS. It looks like part of the reason we have so many warnings is the misuse of #define __ROMCC__ to mean "early code before the device tree is available" __ROMCC__ is also used to get rid of prototypes because romcc doesn't support them. What's the right thing to do here? Maybe we should split the meanings so that we test for __GNUC__ when we mean "not romcc", and we test for __ROMCC__ (renamed, of course, later) when we mean early init? Thanks, Myles

4 11

Kontron AG extends rugged product portfolio with acquisition of DIGITAL-LOGIC AG
by Peter Stuge 30 Oct '09

30 Oct '09

http://emea.kontron.com/about-kontron/news-events/kontron+ag+extends+rugged… //Peter

1 0

Re: [coreboot] [v2] r4862 - trunk/coreboot-v2/src/lib
by Peter Stuge 30 Oct '09

30 Oct '09

svn(a)coreboot.org wrote: > +++ trunk/coreboot-v2/src/lib/cbfs.c 2009-10-26 17:15:53 UTC (rev 4862) .. > entry = stage->entry; > -// return (void *) ntohl((u32) stage->entry); > + // entry = ntohl((u32) stage->entry); > + > return (void *) entry; > } Why not just remove the commented code? It will still be there in history. //Peter

1 0

Re: [coreboot] [v2] r4892 - trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg
by Carl-Daniel Hailfinger 30 Oct '09

30 Oct '09

On 30.10.2009 14:10, svn(a)coreboot.org wrote: > Author: uwe > New Revision: 4892 > > trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg/auto.c > Log: > Fix, um... a typo. > Aww man. This comment was a great example of early opensource programming tradition before political correctness started to suck all the fun out of code comments and messages. Regards, Carl-Daniel -- Developer quote of the week: "We are juggling too many chainsaws and flaming arrows and tigers."

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
54
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2009