#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/>
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/
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 :)
Hi,
andor reported a problem where flashrom does reproducibly not work with
coreboot but does with the vendor BIOS
http://paste.flashrom.org/view.php?id=1614
Apparently it is related to fast reads and/or the frequency.
We have forced the fastReadEnable bit in the SPI_Cntrl0 from 1 to 0 and
also set NormSpeed in SPI_Cntrl1 to 16.5 Mhz (previously was 0 i.e. 66
MHz) in flashrom and the problem vanished.
Coreboot hard codes the fast read setting in
src/southbridge/amd/cimx/sb800/bootblock.c:
static void enable_spi_fast_mode(void)
{
u8 byte;
u32 dword;
device_t dev = PCI_DEV(0, 0x14, 0x03);
// set temp MMIO base
volatile u32 *spi_base = (void *)0xa0000000;
u32 save = pci_io_read_config32(dev, 0xa0);
pci_io_write_config32(dev, 0xa0, (u32) spi_base | 2);
// early enable of SPI 33 MHz fast mode read
byte = spi_base[3];
spi_base[3] = (byte & ~(3 << 14)) | (1 << 14);
spi_base[0] = spi_base[0] | (1 << 18); // fast read enable
pci_io_write_config32(dev, 0xa0, save);
}
Marc suggested that this should be configurable in the devicetree or by
a kconfig setting. Also, the statements using "byte" do not make a lot
of sense to me. Shouldn't that be a u32 instead?
The public documentation of the fastReadEnable is lacking any detail
and I don't have access to the NDAed version of the RRG. Is my theory
correct that the controller uses the 0x0B opcode with a fixed frequency
(33 MHz?) instead of 0x03 with the frequency set by NormSpeed?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
#186: 3com 3c905tx / gpxe boot problem
-----------------------------------+----------------------------------
Reporter: jeroenkrabbendam@… | Owner: stepan@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: coreboot | Keywords: gpxe
Dependencies: | Patch Status: there is no patch
-----------------------------------+----------------------------------
Although (or: just because) novice in the field, I encountered some
problems with netbooting with coreboot.
Mobo's tried: Asus P2B, VTech with bios id ITE8671-2A69KV3IC-00. All
mobo's boot '''harddisk''' fine with Asus P2B / Gigabyte GA-6BX{CE}
respectively.
NIC ROM is started, and loads the kernel by tftp. This is vvvveeeerrrryyy
slow! Although loading, the kernel is never able to start itself. Same
kernel on HDU is no problem at all (GRUB2)
Note: the gpxe-image is on the nic, coreboot payload is seabios.
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/186>
coreboot <http://www.coreboot.org/>
On 11/20/2013 09:23 AM, ron minnich wrote:
> I've got a student coming in January and he's going to work on
> ChromeOS on AMD CPUs, starting with the Gizmo. If, at that time,
> someone has a suggestion for an AMD laptop which might be suitable,
> let me know.
Would you care to elaborate on that?
As much as I hate HP, they do seem to have some of the best AMD-based
laptops. I would look at the ProBook 655 G1 / 645 G1 or the HP ProBook
6475b.
Alex
P.S. One fornicating annoying downside is that HP's firmware really
sucks. Suspend-and-not-crash-and-overheat (TM) is sometimes working,
while Resume-and-not-defecate (TM) seems to be slightly more reliable.
Have any of you noticed this with the Pavilion 14 Chromebook? You take
it outside from the warm house, open the lid to resume, and the mouse
pointer moves heratically. It becomes impossible to co control, and the
only way to bring it back to sanity is to completely power off. When the
system comes back on, the issue is gone.
Alex
Hello Coreboot,
I would like to play around with Coreboot on a Lenovo X201i convertible
laptop.
According to http://www.coreboot.org/Supported_Motherboards#Laptops and
some wiki-entries Coreboot does do well on the X201. Does this imply
Coreboot will do on a X201i (<-note the "i"), as to my knowledge the only
difference between these two versions is that the latter one features a
multitouch touchscreen?
Thank you in advance!
Chris
Am Freitag, den 29.11.2013, 19:31 -0800 schrieb ron minnich:
> James, this is super helpful and, yes, I should have said 8169. Seems
> like the gizmo ought to work for my needs as well, then, if the
> ethernet IP is from the rtl8169?
On http://www.gizmosphere.org/why-gizmo/gizmoboard/ hold your mouse over
the PCB picture at the bottom, a bit below the VGA port. Somewhere
you'll mouse over "Realtek RTL8111DL Gigabit Ethernet controller (on
back)".
So It's actually a separate chip, since the AMD on-chip stuff seems to
be a not very useful broadcom chip. (see Jens' comments on gerrit:
http://review.coreboot.org/#/c/2581/)
Most AMD boards seem to use a separate chip, usually realtek, for that
reason.
Patrick
