#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:email@example.com>> 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 wanted to know which physical port of my multiple USB controllers have
the debug capability. There was no way to find that easily, so I created
a tool which will do most of the work for the user.
The following PCI devices support a USB debug port (says lspci):
The following PCI devices support a USB debug port (says the kernel):
PCI device 0000:00:1d.7, USB bus 3, USB physical port 1
Currently connected high-speed devices:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
|__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
#201: Error building coreboot for Samsung Exynos5 Google Snow
Reporter: Pete <bluestore.logmein@…> | Owner: stepan@…
Type: defect | Status: new
Priority: major | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patch Status: there is no
I am trying to compile a coreboot rom for the Samsung chromebook Series 3
- Exynos5, i followed the instructions at http://www.coreboot.org/Exynos5
to compile the armv7a-eabi toolchain and evertyhing went ok. At the
menuconfig i selected Google MainBoard, model Snow, exit and save. It
starts to compile until it returns this error:
build/ec/google/chromeec/ec.romstage.o: In function
reference to `recovery_mode_enabled'
collect2: error: ld returned 1 exit status
make: *** [build/cbfs/fallback/romstage.debug] Error 1
Am i missing something?
Also tried make clean and make crossgcc, and even the built went fine,
when i run make always returns this error.
Thank you, Pete
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/201>
I'm new to coreboot, and I'm working to use it with an ASROCK IMB-A180,
the H version with the LVDS port.
I've read previous posts regarding the "IMB-A180 won't boot" on this group,
and tried the .config that was posted, but the result is the same.
The debugging output shows things progressing until agesawwrapper_amdinitmid
is called, then the boot restarts, then stops cold at the same point:
Done allocating resources.
BS: BS_DEV_RESOURCES times (us): entry 0 run 1095130 exit 0
Fam16 - domain_enable_resources: AmdInitMid.
^@^@^@^@§H¨Hh½É<95><89>½½Ñµ4.0-5169-g9d1d740 Tue Feb 4 16:46:38 PST
Any help with this would be greatly appreciated. Full serial debug
output then .config are attached below.
Engineering Design Team
I took the discussion to IRC, to avoid endless back-and-forth by mail.
The plan is to enable us to write romstage code with the expectation
that at least some RAM (through CAR) is available. (while bootblock is
expected to work without RAM of any kind, and ramstage has the full RAM
If someone wants to use romcc for romstage, that means working without
other object files (since romcc never emits a "call" instruction, except
when hand-assembled). Thus reusing other .c files in romcc means
"#include *.c" as it always did.
Proposal: If someone goes that route, and things break due to the .c
files of the coreboot core being too complex for romcc to handle, they
get to keep the pieces - it's unsupported.
I expect special cases like Vortex (or old chipsets like Via C3, if
someone has the interest and time to do the port) to have a simple
enough RAM initialization that they can be implemented as standalone C
code. That's still _much_ more comfortable than writing assembly, and
it'll work: it has one entry-point (like CAR code), one exit point
(calling into common C code to load the next stage), and everything
inbetween is compiled by romcc to work without RAM.
Should we find out that all the hundred ancient ram inits we get
contributed reimplement the same things over and over, we can still
consider moving those parts to src/lib/romcc, neatly separated from
regular romstage code.
Am 2014-03-27 14:00, schrieb Andrew Wu:
> So if I want to get rid of romcc, maybe I have to write DRAM init code
> in assembly, That is not very easy. :(
If you can make it compile in romcc without relying on coreboot base
libraries, we could keep Vortex86 RAM init building via romcc. As I
understand Stefan, his main motivation for this push is to clean out all
the romcc related special cases in coreboot's core.
I have a ThinkPad T60p 2007-CTO. Does anyone know the flash chip used and have a known working config file ? I know this model has been successfully flashed. Don't want to have to disassemble my laptop. That disassembly is required to identify the flash chip is going to slow coreboot adoption.