gmane.linux.bios

Re: Fixed the bug of rs780 gfx port A

David Hubbard — 2013-06-18T20:53:09

Hi,

Do a search for "RS780" on http://www.coreboot.org/Supported_Motherboards

You'll find these motherboards:

ASUS M4A785-M: contact Juhe
ASUS M4A785T-M: contact GNUtoo
ASUS M4A78LT-M: contact Idl0r
ASUS M4A78-EM: contact Juhe

Jetway A78VM5: I couldn't find a contact
AMD Tilapia and Mahogany: I couldn't find a contact

For the AMD boards, someone from Sage Engineering might be able to help you.

At this point, you should reach out to those developers for support testing
your patch.

David


On Tue, Jun 18, 2013 at 2:39 AM, <yili0568< at >gmail.com> wrote:

Re: Haswell support

朱晓元 — 2013-06-18T14:32:18

z87 chipset may work,but need some work on coreboot code.
use intel/wtm2 mobo.


2013/6/17 ron minnich <rminnich< at >gmail.com>

Fixed the bug of rs780 gfx port A

2013-06-18T08:39:28

I've tested it on loongson 3aserver mainboard, but
I don't have a x86 mainboard, is there anyone test
the patch for me on a x86 mainboard, thanks.

Re: Bricked Lenovo T60

Carl-Daniel Hailfinger — 2013-06-17T23:39:29

Hi,

Am 17.06.2013 23:25 schrieb Tim Zander:

Only partially.


No, probe_spi_res2 is correct.



The datasheet is clear on that: The RES ID is 2-byte.



Yes, that one indeed should have been spi_chip_write_1.

I'm sorry we didn't catch the usage of the wrong write function before
you reflashed.

Regards,
Carl-Daniel

Re: Bricked Lenovo T60

Tim Zander — 2013-06-17T21:25:50


I'm not sure what you did, but if this was you flashchips.c:

 > +                .model_id       = SST_SST25VF016B_T60,
 > +                .probe          = probe_spi_res2,
 > +                .read           = spi_chip_read,

then things were wrong:

Change the .probe field to probe_spi_res1
Change the .model_id field to the RES1 ID given in the datasheet of the 
flash chip
Change the .write field to spi_chip_write_1


Tim

Bricked Lenovo T60

Damien Zammit — 2013-06-16T23:23:37

Hi folks,

Thanks #coreboot for all your help with my laptop, I learnt a lot today
from you all.
Unfortunately my first attempt at installing coreboot has resulted in a
bricked laptop.

I tried to cheat by making an educated guess of the SPI chip model
without pulling my laptop to bits to verify.  However, it seemed right
according to the responses i was getting from flashrom -V for the failed
chips, since the manufacturer id and model id I was getting from
flashrom matched the datasheet specs for a particular chip.

I downloaded and compiled the crossgcc toolchain.

I created a patch for flashrom and proceeded to read my flash.
I got a successful read from flashrom and dumped my vgabios.

I compiled coreboot for T60 and followed the wiki grabbing the 3 patches
for Lenovo stuff and inserting my custom SMBIOS details in the config.

Once i felt happy with my coreboot.rom I followed exactly the procedure
on the coreboot Lenovo wiki to flash my laptop internally.
  
I have attached here the coreboot config i us

Re: coreboot project analysis request

ron minnich — 2013-06-17T17:29:46

coverity sounds good

Re: Welcome GSoC Students!

Marc Jones — 2013-06-17T16:52:27

Hello students and mentors:

I hope that you are all starting to engage your mentors and refine
your GSoC plans during the "get acquainted" phase. Students should be
exchanging emails with mentors and in IRC to participate in the
development process.

Thanks for the introductory blog posts. I really liked the posts from
kmalkki and mrnuke.

First blog post done:
Kyösti  (kmalkki)
Stefan (stefanct)
Alex G (mrnuke)



Need to do a blog post:
Alex
Ayush Sagar

Marc



--
http://se-eng.com

Re: coreboot project analysis request

Антон Кочков — 2013-06-17T08:45:10

Hello!
Sadly no answer from Klocwork...
Ok, what do you think about Coverity?
I mean this one http://scan.coverity.com/
It could be a good addition to this
https://www.google-melange.com/gsoc/project/google/gsoc2013/alex_animux/76001

Radare2 is already scanning by Coverity (a few days).
Best regards,
Anton Kochkov.


On Fri, Apr 12, 2013 at 1:32 PM, Антон Кочков <anton.kochkov< at >gmail.com> wrote:

Re: Haswell support

ron minnich — 2013-06-17T00:50:50

looking at the current tree, Z87 would appear to be in there.

What board are you looking at?

ron

Haswell support

Eric Sherouse — 2013-06-16T21:19:23

Per advice of the #coreboot channel, I will ask this question here.
Does coreboot support intel's haswell arch, specifically the z87 chipset?

Problem with coreboot+SeaBIOS on Samsung Chromebox(stumpy)

Robert Ou — 2013-06-16T01:17:31

Hello,

I tried to build and flash coreboot and SeaBIOS onto a Samsung Chromebox. I
built coreboot from master of the coreboot tree (no chromiumos patches). My
problem is that the Chromebox now only boots from a complete cold boot. In
other words, I need to unplug both the AC power and the RTC battery, then
plug in the AC power, and then push the power button. If I run "shut down"
from Ubuntu and try to press the power button, the board does not boot. If
I hold the power button until the box shuts off and push the power button
again, it also does not boot. If I suspend from Ubuntu, the box suspends
and the blue LED starts blinking. However, if I push the power, it doesn't
resume. One thing I observed is that all the boots that don't work involve
the power LED either never turning on or turning on instantly. The complete
cold boot that does work has the power LED blinking very briefly, turning
off for several seconds, and then turning back on. Does anybody know what
is going on here? Attached is a cbmem conso

Re: Management engine firmware

Vladimir 'φ-coder/phcoder' Serbinenko — 2013-06-14T23:32:02

Build failure is the best way to indicate that resulting image wouldn't
work and/or is dangerous. I feel like build failure without those files
would be intended.
Thing is that we still want Jenkins to be able to build for its build
tests. Can perhaps Jenkins disable an option "Add ME firmware" which
would be on by default? Or have some kind of define BUILD_TEST.

Re: Management engine firmware

Paul Menzel — 2013-06-14T22:18:36

Am Donnerstag, den 13.06.2013, 09:49 +0200 schrieb Vladimir 'φ-coder/phcoder' Serbinenko:

Isn’t a dummy ME viable to get a successful build though? Surely the
user should be warned, when such dummy files are used. (Like, you need
to extract the real files. Look at the coreboot Wiki how to do so.)


Thanks.

Paul

Re: i82801gx: SMI from "GPE0_STS: USB1"

Aaron Durbin — 2013-06-14T13:18:41

On Fri, Jun 14, 2013 at 7:16 AM, Константин Аладышев
<aladyshev< at >nicevt.ru> wrote:

I don't think it is a horrible hack. I think it's appropriate. My
reasoning is that the firmware doesn't handle those events so they
shouldn't be enabled. If the firmware was responsible for handling all
the things the OS could setup then the firmware would never be
future-proof.

As I noted before I think it's the OS/ACPI's responsibility to set
these registers back up the way it desires after resuming. I didn't
look anything up in the ACPI spec as I didn't feel like trying to find
something in that tome this morning.

-Aaron

Re: i82801gx: SMI from "GPE0_STS: USB1"

Константин Аладышев — 2013-06-14T12:16:49

Little addition to my last message:
Not even drop GPE0_EN initialization from coreboot, but add GPE0_EN reset to 
0x00000000. Cause coreboot gets it initializated from OS.
Should it be done this way, or it is terrible hack?

Re: i82801gx: SMI from "GPE0_STS: USB1"

Константин Аладышев — 2013-06-14T11:35:34

I droped GPE0_EN initialization from coreboot and now it works. I think OS 
gets GPE0_EN information from _PRW objects in ACPI tables.
So... Is there any reason to setup GPE0_EN register in coreboot?

Re: i82801gx: SMI from "GPE0_STS: USB1"

Aaron Durbin — 2013-06-13T13:09:31

On Thu, Jun 13, 2013 at 4:39 AM, Константин Аладышев
<aladyshev< at >nicevt.ru> wrote:

I think the OS will re-initialize the enable bits before going back to
sleep. Have you tried leaving it disabled?

Re: i82801gx: SMI from "GPE0_STS: USB1"

Константин Аладышев — 2013-06-13T09:39:27



Ok, i can disable USB1_EN, and it helps. But i want to enable it before jump 
to OS waking vector, to be able to resume from USB keyboard again.
And once i enable it, coreboot starts these endless SMIs.
How can i stop USB controller from asserting this event?

Re: Management engine firmware

Vladimir 'φ-coder/phcoder' Serbinenko — 2013-06-13T07:49:40

Coreboot send ME a message to tell it what to use for UMA.
ACPI (at least CPU temperature) also goes through ME even if you read it
from EC.
It will reboot or hard lock after 30 minutes
No, it's executed on coprocessor, it's in the same flash but coreboot
doesn't have to do anything to load it.

Re: Management engine firmware

Антон Кочков — 2013-06-13T05:19:08

Please, remember, that ME code is signed, so you can't just write
'dummy' ME firmware. You can try to boot without it, but, it is
unpredictable.
Best regards,
Anton Kochkov.


On Thu, Jun 13, 2013 at 5:41 AM, George Chriss <gschriss< at >gmail.com> wrote: