#95: Run coreboot in VirtualBox
by coreboot
#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/>
4 years, 7 months
EHCI debug port finder
by Carl-Daniel Hailfinger
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/
5 years, 1 month
Dual SPI Flash adapter attempt 2.0
by Oliver Schinagl
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 :)
5 years, 4 months
#186: 3com 3c905tx / gpxe boot problem
by coreboot
#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/>
5 years, 6 months
unsupported mb questions (amd fam10h)
by Roman Elshin
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);
-------------------------------------------------------------------------
6 years
#131: New flashrom motherboard support
by coreboot
#131: New flashrom motherboard support
---------------------------------+------------------------------------------
Reporter: anonymous | Owner: somebody
Type: enhancement | Status: new
Priority: trivial | Milestone: Going mainstream
Component: flashrom | Version: v2
Keywords: flashrom asus | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
Did not know where I should put this but the bugtracker seemed like the
right place.
I tried flashrom and it could not detect my chip on my ASUS P5ND2-SLI
Deluxe motherboard. The board has a SST49LF004B flash chip and after
enforcing the right chip flashrom seems to work fine.
{{{
# ./flashrom -V -f -r -c SST49LF004A/B test
Calibrating delay loop... 796M loops per second, 100 myus = 201 us. OK.
No coreboot table found.
WARNING: No chipset found. Flash detection will most likely fail.
Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x21, id2 0x5e,
id1 parity violation
No EEPROM/flash device found.
Force read (-f -r -c) requested, forcing chip probe success:
Probing for SST SST49LF004A/B, 512 KB: Found chip "SST SST49LF004A/B" (512
KB) at physical address 0xfff80000.
Force reading flash... done.
}}}
This should probably apply to the P5ND-SLI board, too.
What do you need from me for adding autodetection of this board/chip?
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/131>
coreboot <http://www.coreboot.org/>
6 years, 10 months
Fintek F81865 patch
by Juha Tuomala
Hi,
Below is a patch for Fintek f81865 superio register dump.
Datasheet: http://www.fintek.com.tw/files/productfiles/F81865_V028P.pdf
Patch url: http://tuju.fi/tmp/f81865.patch
diff --git a/util/superiotool/fintek.c b/util/superiotool/fintek.c
index fc1d3f2..8703f68 100644
--- a/util/superiotool/fintek.c
+++ b/util/superiotool/fintek.c
@@ -279,6 +279,54 @@ static const struct superio_registers reg_table[] = {
{0x00,NANA,NANA,NANA,NANA,NANA,EOT}},
{EOT}}},
{0x0407, "F81865F/F-I", {
+ {NOLDN, NULL,
+ {0x02,0x07,0x20,0x21,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2a-1,0x2a-2,0x2b,0x2c,0x2d,EOT},
+ {NANA,0x00,0x07,0x04,0x19,0x34,NANA,NANA,NANA,0x00,0x00,0x00,0x00,0x1f,0x00,0x08,EOT}},
+ {0x00, "FDC",
+ {0x30,0x60,0x61,0x70,0x74,0xf0,0xf2,0xf4,EOT},
+ {NANA,0x03,0xf0,NANA,NANA,NANA,NANA,NANA,EOT}},
+ {0x03, "LPT",
+ {0x30,0x60,0x61,0x70,0x74,0xf0,EOT},
+ {NANA,0x03,0x78,NANA,NANA,NANA,EOT}},
+ {0x04, "HWMON",
+ {0x30,0x60,0x61,0x70,EOT},
+ {NANA,0x02,0x95,NANA,EOT}},
+ {0x05, "KBC",
+ {0x30,0x60,0x61,0x70,0x72,0xfe,0xf0,EOT},
+ {NANA,0x00,0x60,NANA,NANA,NANA,0x71,EOT}},
+ {0x06, "GPIO",
+ {0x30,0x60,0x61,0x70,0xf1,0xf2,0xf3,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xe0,0xe1,0xe2,0xe3,0xef,0xd0,0xd1,0xd2,0xd3,0xc0,0xc1,0xc2,0xc3,0xb0,0xb1,0xb2,0xb3,0xa0,0xa1,0xa2,0xa3,0x90,0x91,0x92,0x93,EOT},
+ {NANA,0x00,0x60,NANA,0x00,NANA,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xff,NANA,0x00,NANA,0x00,0xff,NANA,0x00,0x00,0xff,NANA,0x00,0x00,0xff,NANA,0x00,0x00,0xff,NANA,0x00,NANA,NANA,NANA,NANA,EOT}},
+ {0x07, "WDT",
+ {0x30,0x60,0x61,0xf5,0xf6,0xfa,EOT},
+ {NANA,0x00,0x00,0x00,0x00,NANA,EOT}},
+ {0x08, "SPI",
+ {0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xfa,0xfb,0xfc,0xfd,0xfe,0xff,EOT},
+ {0x10,0x04,NANA,NANA,0x00,0x00,NANA,NANA,0x00,0x00,0x00,0x00,0x00,0x00,0x00,EOT}},
+ {0x0a, "PME & ACPI",
+ {0x30,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,EOT},
+ {NANA,NANA,NANA,NANA,NANA,0x06,NANA,0x00,EOT}},
+ {0x0b, "RTC",
+ {0x30,0x60,0x61,0x70,EOT},
+ {NANA,0x00,0x00,NANA,EOT}},
+ {0x10, "UART1",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
+ {0x11, "UART2",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
+ {0x12, "UART3",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
+ {0x13, "UART4",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
+ {0x14, "UART5",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
+ {0x15, "UART6",
+ {0x30,0x60,0x61,0x70,0xf0,0xf2,0xf4,0xf5,EOT},
+ {NANA,0x03,0xf8,NANA,NANA,NANA,0x00,0x00,EOT}},
{EOT}}},
{EOT}
};
Tuju
--
6 years, 10 months
Re: [coreboot] Coreboot with a Linux kernel and initramfs as payload.
by Patrick Georgi
Am 31.08.2012 16:41, schrieb ron minnich:
> It's been several years since I've done this. However, I don't believe
> mkelfimage is needed.
>
> You need to build a kernel image that contains the kernel, initramfs,
> and command line args. If my memory is correct, this is now possible
> with the standard kernel build process and it creates and ELF file.
> Since cbfstool can parse and ELF file, you should be able to use the
> standard coreboot flow.
That won't work since Linux still requires the "bootblock" at 0x7d000
(or whereever that was). You only get that when using a "linux" loader.
Still, mkelfimage isn't exactly a well thought out tool. Take an ELF
linux image and add the bootblock section and you avoid a copy on
runtime and lots of complication of mkelfimage (eg. that stub it adds).
Never found the time to implement that, though.
Patrick
6 years, 10 months
Re: [coreboot] Coreboot with a Linux kernel and initramfs as payload.
by ron minnich
It's been several years since I've done this. However, I don't believe
mkelfimage is needed.
You need to build a kernel image that contains the kernel, initramfs,
and command line args. If my memory is correct, this is now possible
with the standard kernel build process and it creates and ELF file.
Since cbfstool can parse and ELF file, you should be able to use the
standard coreboot flow.
I'm going to try to get this working anyway in a week or so so I'm
interested to hear how it goes for you.
ron
6 years, 10 months
