-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
#95: Run coreboot in VirtualBox
Reporter: uwe | Owner: somebody
Type: defect | Status: new
Priority: minor | Milestone:
Component: misc | Version:
Keywords: | Dependencies:
Patchstatus: there is no patch |
It would be nice if we could test coreboot images in VirtualBox, see
VirtualBox does not (yet) provide a simple mechanism to use a different
BIOS in their emulated machines (something like "-L" in qemu). Instead the
BIOS image (a custom bochs BIOS + LGPL'g VGABIOS) is converted to C code
(an array of bytes, or the like) and merged into the VirtualBox
The relevant files are
if someone want to hack VirtualBox to easily support using coreboot images
instead of their usual BIOS.
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/95>
On 10.02.2014 23:47, David Hendricks wrote:
> On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel
> <mailto:firstname.lastname@example.org>> wrote:
> Dear coreboot folks,
> currently no coreboot messages are stored for boards not supporting
> CBMEM console (or where this option is disabled (currently by default))
> or no coreboot *romstage* messages are stored for boards, where the data
> cannot be preserved (passed to ramstage).
> Using the serial (or USB) console all these messages can be captured
> with no problem, so I propose to just add these captured messages into
> the file `serial_console.txt`. Of course this file probably contains
> also the payload and (Linux) kernel log, but I think that is fine.
> SeaBIOS’ `readserial.py` should be used for capturing the messages as it
> adds time stamps.
> Scripting this is going to be hard, as the log is captured on a
> different system. So for now I propose to add it manually.
> I don't think the script itself should be responsible for collecting
> serial output. Instead, how about adding an argument to override the
> default behavior of running "cbmem -c" on the target so that the user
> can pass in a filename? The user will simply capture the serial output
> using whatever tool they like, dump the output to a text file, and run
> the script with an argument to use the file instead of calling "cbmem
> -c". Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 .
This requires user to do right manipulations. While keyboard and chair
are usually fine, the space between them exhibits strong bug-inducing
properties. The idea of the script is to reduce a possibility of user
error creating strange reports. In this case the common erro I expect is
using a stale file fom some other version. It's a particularly nasty one
as at first glance in may look fine but would be almost useless to track
how details changed from one submit to the next. If we let user supply
files at all, it should be added to report, not replace files, and it
should have some prefix to clearly indicate that user was involved in
creating them. E.g. user_serial_log.txt
> But in general I think I agree with Vladimir. CBMEM console should be
> supported and if not then that should be fixed.
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
I'm unable to use any USB devices connected to an XHCI controller to resume from S3 standby, as something causes all connected devices to disconnect just prior to entering standby, as per the output of dmesg.
I've traced the relevant sections in the southbridge and ACPI source for my device (a haswell-based ChromeOS device with an Intel lynxpoint southbridge), but have been unable to find the culprit.
CONFIG_FINALIZE_USB_ROUTE_XHCI is set, as this device only has USB3 ports (4x), but having it set either way doesn't make a difference. The usb_xhci_sleep_prepare() call doesn't seem to be the culprit, as commenting it out has no (positive) effect.
Resuming via the power switch or wake on lan work perfectly, so it's not a general resuming issue.
Appreciate any pointers on how to proceed
Charles Devereaux wrote:
> Could anyone provide instructions to checkout a version of coreboot
> with the native x60 video init
The idea is that the code isn't finished as long as it is not
available in coreboot.git master. Please know that in practice
this idea doesn't hold up at all. coreboot.git master has lots
of code which isn't at all finished.
If you can help with development by working on patches or by
testing them then that's a great contribution!
If not, I think you just have to wait. :\
Charles Devereaux wrote:
> what is the proper way to do it
cherry-pick and not checkout
> missing any important recent patch
Remember that patches aren't neccessarily complete or correct just
because they appear to work.
Thanks for testing!
(oops, looks like you hit "reply" instead of "reply-all" by accident)
On Fri, May 30, 2014 at 3:44 PM, Silkie Carlo <silkiecarlo(a)gmail.com> wrote:
> Thanks for responding.
> It doesn't matter - it just needs to *not* have advanced management
> technology / remote accessibility.
> Many thanks!
At the bottom of the "Supported Motherboards" page you'll see a listing of
boards with headings like "2014W22." That list is automatically generated
using boot logs that are uploaded by people who are actively using and
testing the boards. (Unfortunately the links to the logs don't work because
gitweb is disabled at the moment).
The Asus F2A85-M is for AMD chips and would be a great choice for a desktop
board. There's even a nice wiki page for it here:
There are a couple laptops listed on there as well. I haven't personally
tried the HP Pavilion m6-1035dx, but it uses an AMD chip.
There are also some ARM-based Chromebooks on the market; The Samsung
Chromebook 2 went on sale recently and sports some nice hardware. That
particular one uses u-boot instead of coreboot, but the firmware is open
source and there are no AMT-like shenanigans.
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.