#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/>
#191: Coreboot:libpayload-size_t conflicting types compiler error
---------------------------+----------------------------------
Reporter: Pradish | Owner: uwe@…
Type: defect | Status: new
Priority: blocker | Milestone:
Component: libpayload | Keywords:
Dependencies: | Patch Status: there is no patch
---------------------------+----------------------------------
Hi
I have question related to libpayload, which I am trying to solve, but not
able to.
I have successfully build the coreboot.rom for QEMU x86.
Now when I try to build the libpayload project it throws error.
System configuration:
Virtual Box –Ubuntu 11.10 version
Building for X86 Paltform
Earlier I have run the cross toolchain using the command ‘make crossgcc’
and it was succcessfull
Error information:
/coreboot/payloads/libpayload$ make install
CC libpci/libpci.libpci.o
In File included from include/libpayload.h:54:0,
from libpci/libpci.c:30:
include/x86/arch/types.h:56:22: error: conflicting types for 'size_t'
In file included from include/libpayload.h:49:0,
from libpci/libpci.c:30:
/home/pradish/coreboot/util/crossgcc/xgcc/lib/gcc/i386-elf/4.7.2/include/stdded.h:213:23:
note: previous declaration of 'size_t' was here
make: ***[build/libpci/libpci.libpci.o] Error 1
pradish@pradish-VrtualBox:~/coreboot/paylaods/libpayload$
can you tell me, how to resolve this , I have not done any changes to the
source code. Just performed ‘make’
regards
pradish
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/191>
coreboot <http://www.coreboot.org/>
I try to get coreboot working with asrock 880g pro3 board.
First problem: spd eprom say that memory ddr1600 capable, but it is not
so, is there are right way to limit memory frequency at ddr1333?
Other problem, may be related as machine with broken memory are very
unpredictable: boot process stop with "It is not SB800 or SB810"
message. I try to enable sb850 by this patch, but looks like it is not
enough, most of time coreboot does not detect hdd. Sometimes in very
rare case it is possible to boot from sata. Are sb850 supported by
coreboot?
-----------------------------------------------------------------------
diff -urN a/src/southbridge/amd/sb800/early_setup.c
b/src/southbridge/amd/sb800/early_setup.c
--- a/src/southbridge/amd/sb800/early_setup.c 2012-07-14
19:00:40.000000000 +0400
+++ b/src/southbridge/amd/sb800/early_setup.c 2012-07-14
21:49:54.000000000 +0400
@@ -94,7 +94,10 @@
rev = REV_SB800_A11;
} else if (rev_id == 0x41) {
rev = REV_SB800_A12;
- } else {
+ } else if (rev_id == 0x42) {
+ rev = REV_SB800_A13;
+ }
+ else {
die("It is not SB800 or SB810\r\n");
}
diff -urN a/src/southbridge/amd/sb800/sb800.h
b/src/southbridge/amd/sb800/sb800.h
--- a/src/southbridge/amd/sb800/sb800.h 2012-07-14 19:00:40.000000000
+0400
+++ b/src/southbridge/amd/sb800/sb800.h 2012-07-14 21:49:10.000000000
+0400
@@ -48,7 +48,7 @@
#define REV_SB800_A11 0x11
#define REV_SB800_A12 0x12
-
+#define REV_SB800_A13 0x13
#ifdef __PRE_RAM__
void sb800_lpc_port80(void);
-------------------------------------------------------------------------
Idwer Vollering writes:
> Done.
Thanks for attaching the log for me.
Some recent commits to coreboot master seems to have solved my problem
with the pci scan hang. Now I don't have to hack around it any more.
However it still freezes after it's done (?) loading seabios.
I have uploaded my changes to https://github.com/DarkDefender/coreboot
if anyone want's to look at them.
I've tried to enable more debugging options in the "OptionsIds.h" for
AGESA but it doesn't seem to do anything.
The asserts are triggered druing boot are still the same as before.
I've tried to look at it but I didn't really understand what I should
change to solve them.
Dear coreboot folks,
since [1]
commit df729d7778a7e5878fac5545883f68e42372456a
Author: Jens Rottmann <JRottmann(a)LiPPERTembedded.de>
Date: Tue Feb 19 14:46:31 2013 +0100
AMD Fam14 boards: dimmSpd.c: Set `iobase` to `SMBUS0_BASE_ADDRESS` instead of `0xB00`
which I expanded to the ASRock E350M1, overlooking the new error
message, Linux complains about an already used base address index
region.
calling i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559
piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!
piix4_smbus: probe of 0000:00:14.0 failed with error -16
The address 0xb00 was used before and this should not have been changed
with the patch above. But it did. I looked through the code but could
not find where 0xcd6 comes from. Any pointers would be very much
appreciated.
Thanks,
Paul
[1] http://review.coreboot.org/2453
OK, I took a look at the code. Nice to see such a simple startup,
reminds of linuxbios v1 days. At least if this is the right one:
http://fossies.org/linux/misc/grub-2.00.tar.gz:a/grub-2.00/grub-core/boot...
I don't see a problem pulling this in to coreboot. We'd probably trim
some bits out and let ramstage take over, but for a first cut it could
be used as is. This code is very similar in how it works to many
linuxbios/coreboot platforms and hence should fit into the coreboot
structure with ease.
The first step remains the same: set up crossgcc. I talked to stefan
yesterday about incorporating extant loongson patches into a gcc build
and he mentioned that the utility is designed to allow you to specify
patches to be pulled at build time.
So, let's start with crossgcc for mips/loongson. This is a minimum requirement.
ron
