Hello
Last weekend I successfully booted seabios from grub2 with native video
support.
This had been previously reported on
www.coreboot.org/pipermail/coreboot/2014-February/077306.html
If you want to do the same:
- get the latest seabios, no need for a specific branch anymore (I'm using
3aa31d7d6375303fc88438021aad485f50bb1e39)
git clone git://git.seabios.org/seabios.git seabios
- configure it with the attached configuration file, or at least
enable CONFIG_COREBOOT
and CONFIG_VGA_COREBOOT as per the original instructions (
http://www.coreboot.org/pipermail/coreboot/2014-February/077245.html)
- add seabios.elf and its vga rom to the CBFS payload (supposing you
cloned seabios into ../payloads) with:
cbfstool coreboot.rom add -f ../payloads/seabios/out/bios.bin.elf -n
elf/seabios.elf -t raw && cbfstool coreboot.rom add -f
../payloads/seabios/out/vgabios.bin -n vgaroms/vgabios.bin -t raw
The add -t raw seems to be important. I had boot problems that required a
reflash after using add-payload and a few other experimental settings.
Since I was investigating other issues, I did not try to explore that and
return to a working setup instead.
- add to your grub.cfg
menuentry '2: SeaBios' {
insmod cbfs
chainloader (cbfsdisk)/elf/seabios.elf
}
That's it! I could successfully start an old grub from the hard drive, but
not its memtest86 menu entry. Likewise, bootable USB stick or a windows
partition can not be started. I'm still investigating.
Any help or suggestion would be appreciated!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
So far we have workarounds (idle=halt or processor.max_cstate=2 kernel
parameter, or 'powertop --auto-tune').
I am fully aware that these are workarounds, not solutions.
A libreboot user also reported that the following programme can be
used (in the same way as powertop):
https://wiki.archlinux.org/index.php/TLP
Might be worth looking into.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTzmktAAoJEP9Ft0z50c+UhT8H/2xXUdcJANCmZkauI6iy5ZeO
DGdPp5aDoDIDP5MOkju4dMQG4tziMkdiRUcA+ZwIDND4wB3s3rmt4Q+B/h2wyF9L
hCXR2u5Zv5CjXntcoNbBxO7Lcl8zyc/f9o4o1JopKkO5e1W1TTCk0bDyegD7zqAy
pLQXHOhFBhbtIFkfgi8XTUVqMy0+8umXn/NcHpRxrw9s85ntY372DIbYnoVq6Gz9
Pt1b9+VtQ+ERCaaJa7nZCsSuS3FYv594FRnDLkIJiSf5hViBOQqe7JIYNca4cvi6
5phTpYp0aSeRuyOWcKneiP5/wCGRB0OYzBGfxi8gMsz4Y2QtiGs3A2HqmUz3BIo=
=t9yl
-----END PGP SIGNATURE-----
On Wed, 23 Jul 2014 11:27:37 +0100
WANG FEI <wangfei.jimei(a)gmail.com> wrote:
> Tom, I'm not an expert of AMD products, I just have a quick search on
> the Device IDs in your mail, your platform's southbridge is SB800,
> which is already supported by coreboot, AMD's processor/northbridge
> is definitely supported by coreboot, but I dont believe the mainboard
> is supported by coreboot.
>
>
> On Wed, Jul 23, 2014 at 10:54 AM, Peter Stuge <peter(a)stuge.se> wrote:
>
> > Tom wrote:
> > > Hello I own an ASUS M5A97 R2.0 and I would like to know if
> > > coreboot is supported.
> >
> > The simple answer is that if the mainboard is listed as supported on
> > the coreboot.org webpage then it might work, and in all other cases
> > it will certainly not work, and you will need to spend weeks to
> > years on education and implementation for the board - how much
> > depends on your background.
> >
> >
> > //Peter
> >
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> >
So I'm guessing that there is no development going on for this specific
board either? I suppose I just struck out of luck this time
around.
Hi,
ruiktest ~ # /tmp/acpidump
Could not get ACPI tables, AE_BAD_HEADER
It seems there is a bug in ACPICA, coreboot is using revision 0 (ACPI 1.0) if
there is no XSDT. But ACPICA expect always ACPI 2.0 style which have a len
record. This is bit more complicated, coreboot creates a header with revision 0,
but provides all other fields as it would be ACPI 2.0, but SeaBIOS correctly
strips that.
I created a bug report at ACPICA:
https://bugs.acpica.org/show_bug.cgi?id=1097
Thanks
Rudolf
i'll summarize my off-list discussion with ruik here.
i've slightly, or moderately, edited some of my previous answers to
ruik. in this email i've updated, corrected and integrated various
information i gave.
On 07/17/2014 06:04 PM, Rudolf Marek wrote:
> Hi Andrew,
>
> I seen also some freezes and I investigate what it could be. In the
> meanwhile I fixed the errata #712 (this is related to freeze due to
> the problem in VGA powermanagement)
awesome!
> I have also seen some freezes which ends up as soft lockup. I
> noticed that the microcode is not updateting to the version 061119 on
> the CPU.
i've also seen some strange lockups. i've done tests by leaving some
machines idle over night.
one of the configurations i tested had a 10de:01d3 nvidia card, without
a vga option rom. it was mostly unresponsive after ~13 hours. ssh worked
for a while, but the 3rd ssh command or so did not complete.
> So now I'm waiting for Sage to release a microcode update to
> coreboot.
great!
> Strangely the freeze problem do not occur on my test system which has
> different APU.
i've been using a8-5600K processors. does your test system use the
a10-5800k or the a10-5700? if so, i'd like to test it as well.
> Please can you try with the latest coreboot to see if the fix for
> errata #712 fixed that?
i've been using builds which include that commit. i'll do future tests
based off of today's git head.
a wheezy install without the vga option rom did well; it was up for ~28
hours. a wheezy machine with the internal graphics + the 6402 vga rom
lasted ~40 hours. it's hard to see a clear pattern here, as there are
very short up times for both configurations as well.
> I would like to know also what is your microcde revision in the cpu
> (after linux microcode patch is applied)
i've attached microcode info. it's version 20130710, installed through
debian sid.
a test using an external graphics card and updated microcode lasted over
2.5 days before someone rebooted it. other tests were all over the
place, lasting less than an hour, or 9.5 hours, for instance.
interestingly enough, a version of coreboot from the fall of 2013,
compiled by someone else, allegedly works quite well for someone using
an external nvidia card and a trisquel install. their system only needs
hard resetting about once every four days or so; when using internal
graphics, they hard reset about once per day. i'm not sure if this is a
best case scenario, or normal behavior.
it's very unlikely that they're using microcode; they use the same
coreboot build when using internal and external graphics.
> I dont know what VGA rom I'm using, I just extracted some random at
> the beginning. Those roms are most likely just patched with the
> proper ID so depending on your VGA ID we can try to compare them.
>
> What is your VGA PCI ID? Mine are 9901 and 9993 I think.
the a8-5600k internal graphics pciid is 9904.
thanks for hacking on coreboot! :-D
> Thanks Rudolf
-------- Forwarded Message --------
Subject: Re: f2a85-m vga binary revision
Date: Tue, 22 Jul 2014 16:44:25 +0200
From: Rudolf Marek <r.marek(a)assembler.cz>
To: Andrew Engelbrecht <sudoman(a)ninthfloor.org>
Hi
I did some decompression of the BIOS images and found that there are
only two versions and two kinds of ROMs:
ATOMBIOSBK-AMD VER015.022.000.000.000000 which is present up to BIOS
5202 from that there is a newer version: VER015.031.000.000.000000
I think I used 15 22 0 in my tests. The EFI version has only atombios
tables and no legacy x86 BIOS code (except for jmp blabla ... blabla: retf)
I also checked the dumped version from dd from system and it is
different not only by the PCI IDs but also perhaps some atomtables are
patched in runtime.
BIOS VERSION: F2A85-M-ASUS-5016
2f34e ATOMBIOSBK-AMD VER015.022.000.000.000000
ed66 ATOMBIOSBK-AMD VER015.022.000.000.000000
BIOS VERSION: F2A85-M-ASUS-5018
2f34e ATOMBIOSBK-AMD VER015.022.000.000.000000
ed66 ATOMBIOSBK-AMD VER015.022.000.000.000000
BIOS VERSION: F2A85-M-ASUS-5104
2f34e ATOMBIOSBK-AMD VER015.022.000.000.000000
ed66 ATOMBIOSBK-AMD VER015.022.000.000.000000
BIOS VERSION: F2A85-M-ASUS-5107
2f34e ATOMBIOSBK-AMD VER015.022.000.000.000000
ed66 ATOMBIOSBK-AMD VER015.022.000.000.000000
BIOS VERSION: F2A85-M-ASUS-5202
2f34e ATOMBIOSBK-AMD VER015.022.000.000.000000
ed66 ATOMBIOSBK-AMD VER015.022.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6004
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6102
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6402
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6404
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6501
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6502
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
BIOS VERSION: F2A85-M-ASUS-6506
2f34e ATOMBIOSBK-AMD VER015.031.000.000.000000
2206 ATOMBIOSBK-AMD VER015.031.000.000.000000
Thanks
Rudolf
ron minnich wrote:
> wrong
> right
It's way too early for that Ron. At this point nobody even
understands wtf is causing the problem. Someone competent
needs to research that before a discussion about the solution.
//Peter
Am 2014-07-22 00:18, schrieb WANG FEI:
> I dont notice this issue one week before (I update my coreboot source
> code one a week), does anyone have the same issue?
There weren't any issues in the area I'd suspect would be responsible
(src/arch/x86/Makefile.inc).
You could try to use git bisect (see
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search)
to pin down the revision that introduced the broken behaviour.
Regards,
Patrick
