#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, 5 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/
4 years, 12 months
#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, 8 months
#135: Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E)
by coreboot
#135: Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E)
---------------------------------+------------------------------------------
Reporter: Jan@… | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
Component: flashrom | Version: v2
Keywords: | Dependencies:
Patchstatus: there is no patch |
---------------------------------+------------------------------------------
I've tried updating the BIOS of a Tomcat n3400B (S2925-E). The update
itself worked fine, but the MAC addresses of the onboard NVidia-Gigabit
Ethernet chips were set to bogus values (66:55:44:33:22:11 or something
like that) afterwards. Restoring the old flash backup worked. This does
not happen with the official update tool from Tyan.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/135>
coreboot <http://www.coreboot.org/>
7 years, 2 months
Set top box update
by Gregg Levine
Hello!
Amazon tells me that there are now two people selling their Akimbo
boxes. Perhaps I'll definitely buy one.
And Joe here is the linked page which contains a reference to the STB
kit from Intel:
http://cerberus.teamhackaday.com/?p=3
It turns out that it comes up right below the description for the
device. It seems the only thing nonstandard about it is the crappy
BIOS that Akimbo insisted on.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
7 years, 2 months
MSI P35 Neo (MS-7360) motherboard
by Fred .
Files attached.
MSI P35 Neo (MS-7360)
Intel P35 chipset.
Fintek F71882FG/F71883FG super i/o.
ICH9 southbridge.
$ dmidecode
$ dmidecode --dump
$ hardinfo
$ lshw
$ lspci -n
$ lspci -tvnn
$ lspci -v
$ superiotool -dV
Hope it helps.
7 years, 5 months
#162: Move SYSTEM_TYPE to Kconfig
by coreboot
#162: Move SYSTEM_TYPE to Kconfig
----------------------------+-----------------------------------------------
Reporter: oxygene | Owner: oxygene
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patchstatus: there is no patch
----------------------------+-----------------------------------------------
SYSTEM_TYPE is used to tell coreboot if the board is "server", "desktop"
or "laptop". It's only used for AMD for now, but could also be used
elsewhere to tweak configuration (and there's a flag in some table, maybe
ACPI, that tells the OS about the system type, too).
It's defined for some boards, there's a default defined somewhere in the
code, that looks a lot like a good match for Kconfig.
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/162>
coreboot <http://www.coreboot.org/>
7 years, 6 months
Re: [coreboot] [PATCH] SECC Pentium 2/3 users are gonna love this
by Keith Hui
>
> Please don't gzip patches, it lowers the chance of someone reviewing
> them to zero ;-)
I figured if we're coding at this level, gzip won't be a hurdle. I
announced it up front, didn't I? :p
>
> There is 65x microcode in the model_67x directory, and it's not split up
> into single files as for the other CPUs.
>
The microcodes are static and are not supposed to change, our CPU
drivers are grouped by family, and the microcodes are going to be
included one after another in one place anyway even when made
separate, so why have 5 files for 5 microcodes in the 67x family for
example when one will do? Of course I retained the comments therein
that marks the microcodes and the processors they're intended for.
To put things in perspective, the microcode data we get from Intel has
hundreds of them all in one file.
> + if (cpuid_res.ebx != 0x756e6547 || cpuid_res.edx != 0x49656e69 ||
> cpuid_res.ecx != 0x6c65746e) {
> + printk(BIOS_INFO, "Not 'GenuineIntel' Processor");
> + return 0;
> + }
>
> This is not necessary. When model_6**_init() is executed, it's clear
> already that this is an intel cpu.
I'm not sure if the check for choosing the CPU driver to execute is on
these CPUID signatures, or through some other fields. This check is
carried from v1. I agree we can take a chance and take it out; we'll
revisit when something breaks. :D
>
> +/* if (signature & 0x1000) {
> + printk(BIOS_DEBUG,"Overdrive chip no L2 cache configuration\n");
> + return 0;
> + }
> +
> + if (signature < 0x630 || signature >= 0x680) {
> + printk(BIOS_DEBUG,"L2 cache on CPUID %x does not require
> configuration\n", signature);
> + return 0;
> + }*/
>
> I think this code should just be dropped
That may change when (IF) we manage to get coreboot on a socket 8
board on which a Pentium II OverDrive processor sits.
Again this piece is from the original code from v1. I agree the second
signature check is not needed.
>
> Is it generally possible to move p6_configure_l2_cache to a generic
> place, maybe to cpu/x86/cache ?
>
> +/*--- End L2 init code from corebbot v1 ---*/
>
> I think this kind of comment is not needed.
>
That's a marker to help preserve my sanity. :-p
> +static inline void strcpy(char *dst, char *src)
> +{
> + while (*src) *dst++ = *src++;
> +}
>
> I know I am the idiot who introduced this in a model_xxx_init.c file,
> but maybe we should move it to lib/strcpy.c ?
Well, 63x and 67x don't even need this; they don't support the
processor brand string that 6bx do. Same with the
fill_processor_name() function. I'll just take them out entirely.
>
> +static struct cpu_device_id cpu_table[] = {
> + { X86_VENDOR_INTEL, 0x0650 },
> + { X86_VENDOR_INTEL, 0x0651 },
> + { X86_VENDOR_INTEL, 0x0652 },
> + { X86_VENDOR_INTEL, 0x0653 },
> + { X86_VENDOR_INTEL, 0x0671 },
> + { X86_VENDOR_INTEL, 0x0672 },
> + { X86_VENDOR_INTEL, 0x0673 },
> + { 0, 0 },
> +};
>
> Instead of using a common driver, can two drivers use a common set of
> shared functions instead?
>
It's already partially done. src/cpu/intel/model_67x/l2_cache.c (new
in this patch) is linked in by model_65x driver too.
Next prime suspect: fill_processor_name() in 6bx and a few other CPU
models I'm no expert of.
But 65x and 67x really are so similar that one driver can do both. Now
is our end goal here to spin off model_63x/65x/66x/67x/68x/6ax/6bx all
into their own CPU drivers when most of what's being done is
duplicating code from model_6xx which is what they collectively once
were? What's the rationale behind this need for split? I think a split
should only be done when different initialization sequence are needed,
eg. the special L2 initialization sequence for these SECC P6s.
Same with motherboard models. When P2B-LS support matures I'd probably
use the same directory for P2B-L and P2B-S support. They share the
same circuit board anyway, and a -LS can emulate both by moving two
jumpers.
> +ifeq ($(CONFIG_USE_DCACHE_RAM),y)
> +cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc
> +endif
>
> This will break all targets except the ones you worked on.
>
I read this and thought, "I gotta run abuild." So I did. The errors I
saw all seems to be k8/k10 targets and/or ACPI related. Even the
entire P2B family that is in the tree passed abuild with this patch
applied. Oh they haven't been migrated to CAR yet.
Thanks
Keith
8 years, 2 months
Re: [coreboot] [RFC] ACPI for ASUS P2B/P2B-LS (Intel 440BX/82371EB)
by Keith Hui
Hi all,
Based on Idwer's RFC I tried adding ACPI to P2B-LS plus completing the
rest of the PIIX4 function 3 initialization.
This is a summary of what I did:
* I used the DSDT table from the final vendor BIOS. Not provided here
for obvious reasons, but I can tell you how to extract it.
* I also replicated the content of the PIIX4 function 3 config space
after booting with vendor BIOS, as below:
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00: 86 80 13 71 03 00 80 02 02 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 e4 00 00 00 00 00 20 1e 30 00 01 00 00 00 00
50: 00 58 19 00 c0 c8 3b 02 37 40 40 03 00 00 00 00
60: 90 02 e7 00 00 00 00 10 04 e4 11 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 01 e8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00
One exception is 0x90-0x91 which has the SMBus host base address. I
kept it as 0x0f00.
* Idwer is trying to build ACPI 4.0 (!) tables. Since P2B-LS is
shipped when ACPI was still at 1.0, that's what I did. For booting XP,
even ACPI 2.0 compliance is sufficient.
This is a summary of what happens:
* I can no longer get POST codes on the PCI bus. POST codes still
appear on the ISA bus. Glad I picked a POST card that works on both
buses.
* Power off does not work. The last POST code to show before complete
kernel shutdown and hard drive spinning down is 0xF5.
* I don't how how to enter soft suspend in Linux (silly me -_-! ), so
I have not tested it.
* the sensor appears on ISA bus port 0x290, just like vendor BIOS.
* My SB AWE64 ISA card still got initialized and driver loaded, but no
sound. In fact ALSA can't even do I/O to the card. That apparently is
because PIIX4 needs to be configured to forward certain I/O port
ranges to ISA, and some of those port ranges can be further
configured. This would require detecting in runtime what ISA cards are
installed, what are they, and what I/O port ranges they would use.
Where in the source tree should I place such code? Southbridge?
The changes I made are described in two attached patches, one to
southbridge/intel/i82371eb, one to mainboard/asus/p2bls. My coreboot
and linux boot log is also attached.
This is also RFC and is not signed off at this point, but comments are welcome.
Regards
Keith
8 years, 6 months
