#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
http://virtualbox.org/.
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
executable.
The relevant files are
{{{
src/VBox/Devices/PC/DevPcBios.cpp
bldprogs/bin2c.c
}}}
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>
coreboot <http://www.coreboot.org/>
On 10.02.2014 23:47, David Hendricks wrote:
> On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel
> <paulepanter(a)users.sourceforge.net
> <mailto:paulepanter@users.sourceforge.net>> 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.
Example output:
The following PCI devices support a USB debug port (says lspci):
0000:00:1d.7
The following PCI devices support a USB debug port (says the kernel):
0000:00:1d.7
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.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
#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
| patch
-------------------------------------------+-------------------------------
Hi,
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:
GEN generated/romstage.ld
LINK cbfs/fallback/romstage.debug
build/ec/google/chromeec/ec.romstage.o: In function
`google_chromeec_early_init':
/home/suporte/coreboot/src/ec/google/chromeec/ec.c:117: undefined
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>
coreboot <http://www.coreboot.org/>
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:
PCI: 00:18.4
PCI: 00:18.5
Done allocating resources.
BS: BS_DEV_RESOURCES times (us): entry 0 run 1095130 exit 0
POST: 0x74
Enabling resources...
Fam16 - domain_enable_resources: AmdInitMid.
agesawrapper_amdinitmid
^@^@^@^@§H¨Hh½É<95><89>½½Ñµ4.0-5169-g9d1d740 Tue Feb 4 16:46:38 PST
2014 starting...
Any help with this would be greatly appreciated. Full serial debug
output then .config are attached below.
Best regards,
Mark Mason
Engineering Design Team
#202: Error building coreboot for Samsung Exynos5 Google Snow
------------------------------------+----------------------------------
Reporter: bluestore.logmein@… | Owner: stepan@…
Type: defect | Status: new
Priority: major | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patch Status: there is no patch
------------------------------------+----------------------------------
Hi,
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:
GEN generated/romstage.ld
LINK cbfs/fallback/romstage.debug
build/ec/google/chromeec/ec.romstage.o: In function
`google_chromeec_early_init':
/home/suporte/coreboot/src/ec/google/chromeec/ec.c:117: undefined
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/202>
coreboot <http://www.coreboot.org/>
Hi list(s),
Here's my second attempt at routing the previously mailed png of my schema.
It was a lot trickier to route then my previous version, but I think it
worked out!
As mentioned, S1 and S2 need to be shorted if U3 is to be omitted. RN1
should be 10k or ideally 100k, as Peter mentioned earlier.
Hopefully there's no obvious mistakes and can start working on
alternative layouts (so it is insert-able in different angles).
DRC Check fails on S1, S2 and U3. It thinks the distance is to shallow.
That said, DRC check passes when I set the copper width/distance to
7mil's instead of the current 8 mils.
I'm planning on having these PCB's manufactured by Seeed studio and
their minimal width is much smaller.
Minimum trace width: 6mil
Minimum trace/vias/pads space : 6mil
Minimum silkscreen width : 4mil
Minimum silkscreen text size : 32mil
I've used a grid size of 10mil and distances of 8 mils, as I didn't want
to rely on the minimum of seed. The silkscreen I positioned using a grid
size of 5 mil's however. Not sure what they mean with a 'minimum
silkscreen text size' however.
Anyhow, feedback greatly appreciated, so I can start working on
alternative layouts :)
Am 2014-02-25 09:37, schrieb Stojsavljevic, Zoran:
> Then to do minimalistic configuration of EDK2, and practically to
> assemble Quark FSP. And to extract this FSP (SEC and PEI phases, which
> is not easy at all) as source code from Quark EDK2 source code.
> Incorporate this into Coreboot as Quark FSP source code.
One problem is that in coreboot development we care about style
(although there will be disagreement to which degree).
And not just in a formal way (which indent could solve), but I'd rather
not see things like
(BIT31 | BIT30 | BIT29 | .. all the way down to .. | BIT 1 | BIT 0)
in our tree.
While looking terribly enterprisey, it's just terrible.
Intel code, at least as far as it is public and not part of the Linux
kernel, manages to collect all the horrible code standards in a single
place.
> Rest supposed to be straight forward... As Sage did it for IVB (using
> IVB FSP as binary blob), similar idea for Quark, as then it complies
> to Coreboot model, with all done by source code (strange to read this
> for INTEL, isn't it!).
"Luckily", Intel being Intel, the boot code is signed, so it's not as
simple as it sounds.
> Other idea is old one, from this thread, to incorporate the whole EDK2
> into Coreboot, but then, EDK2 is UEFI compliant BIOS, as my best
> understanding is (why then to run Coreboot, instead from UEFI BIOS to
> transition to legacy GRUB 0.97 with some security features
> incorporated)!
Indeed. There is no need to bloat coreboot by factor 6. I measured.
Regards,
Patrick