#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/
#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/>
#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/>
> -----Original Message-----
> From: Marc Jones [mailto:marcj303@gmail.com]
> Sent: Tuesday, October 18, 2011 10:39 AM
> To: Stefan Reinauer
> Cc: She, Kerry; coreboot
> Subject: Re: [coreboot] how to delete symbol link created at compile time
>
> On Mon, Oct 17, 2011 at 4:44 PM, Stefan Reinauer
> <stefan.reinauer(a)coreboot.org> wrote:
> > * Marc Jones <marcj303(a)gmail.com> [111016 10:10]:
> >> >> > I have created 2 devicetree file :
> >> >> >
> >> >> > devicetree_f15.cb for platform with family 15 CPU
> >> >> >
> >> >> > devicetree_f10.cb for platform with family 10 CPU
> >> >> >
> >> >> >
> >> >> >
> >> >> > I changed the makefile to create a symbol link "devicetree.cb"
> link to
> >> >> > devicetree_f10.cb or devicetree_f15.cb at compile time.
> >> >> >
> >> >> > The problem is that I can't delete the symbol link when make
> >> >> > clean/distclean.
> >> >
> >> > Please fix the problem by using one device tree for both platforms.
> >
> >> Stefan,
> >>
> >> Can you explain your thoughts on how that would work? Can we put a #if
> >> in the devicetree.cb? It uses the c precompiler? It requires different
> >> CPU files/device locations. We can try it next week.
> >
> > Usually the way this is handled in coreboot is that there is one socket
> > that binds together all CPU types. Then in the device tree only the
> > socket type is specified, and code for both CPUs is pulled in.
> > Maybe we need something like a socket for northbridge code, since the
> > northbridge now lives in the CPU?
> >
> > It seems like a bad idea to have to recompile your BIOS because you
> > change the CPU. We did a lot of nastyness with K8 and Fam10, but we
> > should find a better way to do this for future chipsets/CPUs.
>
>
> Yes, we are discussing how the AGESA code would work. The socket
> decision is rather complicated as we need a way to handle multiple
> calls with the same names (function point tables etc). I think that
> there may be a solution within AGESA, but the device tree may still be
> a problem as the CPUs have different HT link numbering. This makes it
> hard to have the same device tree layout for the same socket.
Because of the function name conflict, put cpu code of 2 families together would not compile.
We need to dig into AGESA more to figure out a solution.
As for the devicetree problem, following text is the devicetree difference in detail:
--- devicetree_fam10.cb 2011-08-15 15:00:14.426692437 +0800
+++ devicetree_fam15.cb 2011-08-15 15:00:14.426692437 +0800
@@ -16,19 +16,17 @@
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
#
-chip northbridge/amd/agesa/family10/root_complex
+chip northbridge/amd/agesa/family15/root_complex
device lapic_cluster 0 on
- chip cpu/amd/agesa/family10
- device lapic 0x10 on end
+ chip cpu/amd/agesa/family15
+ device lapic 0x20 on end
end
end
device pci_domain 0 on
subsystemid 0x15d9 0xab11 inherit #SuperMicro
- chip northbridge/amd/agesa/family10 # CPU side of HT root complex
- device pci 18.0 on end # link 0
- device pci 18.0 on end # link 1
- device pci 18.0 on end # link 2
- device pci 18.0 on # link 3, SB on socket0 link 2, on internal Node0 Link 3
+ chip northbridge/amd/agesa/family15 # CPU side of HT root complex
+ device pci 18.0 on end # Link 0
+ device pci 18.0 on # Link 1, IO-HUB on socket0 link 2(internal Node0 Link 1)
chip northbridge/amd/cimx/rd890 # Southbridge PCI side of HT Root complex
device pci 0.0 on end # HT Root Complex 0x9600
I have and old HP Pavillion with an Asus M2N68-LA Narra 2 mother board. Coreboot hasn't been ported to it. Not asking for it either.
I just want to know the northbridge and southbridge it has.
Well My electrical engineering knowledge does not reach as far that I
would know where to connect what :) I can read a schematic and solder
based on that, but those pictures from the wiki that I linked,
http://www.coreboot.org/Developer_Manual/Tools/Dual_Flash has a small
PCB, with 2 flash chips on it, but I can't figure out where to connect what.
I do think it's a great idea, and maybe it would be an idea to draw the
PCB in kicad/geda or the like, and actually have small batches made. I
know dangerousprototypes.com has loads of small PCB's made for a few
bux. Having a few on hand of these, and be able to send them to people
would be great! Stuff one in an envelope and mail it out for the price
of a stamp.
On 06-03-12 09:55, Peter Stuge wrote:
> Oliver Schinagl wrote:
>> Oh wow, that's some nice work there, unfortunatly I only have 1 bios
>> socket on my motherboard(s) and would use have to 'stack' the bios
>> chips.
> It works fine if you keep the switch wires very short.
>
> Or you can build a transistor-based or IC-based switch circuit which
> stays very close by, and then gets remote controlled by a switch on a
> long cable.
>
>
> //Peter
>I bought an M5A88-v Motherboard (
>http://www.newegg.com/Product/Product.aspx?Item=N82E16813131733&Tpk=m5a88-v
>) and an amd FX-4170 (
>http://www.newegg.com/Product/Product.aspx?Item=N82E16819106009 )
>
>I use Fedora 16 on this machine. Compiled coreboot with a vga bios
>from my board, flashed it, and in doing managed to brick the board. I
>have another computer I was able to use to flash a vendor bios onto
>the rom chip. Compiled again without video bios, and used a
>pci-express graphics card. Still no luck. I'm running the machine with
>stock firmware, but I'd love to be able to try out coreboot and
>seabios.
>
>With Coreboot on it, The machine powered on and the fans spun up.
>That's about it. No HD activity beyond power being applied. Ethernet
>port never powered, screen never came out of power save. Seems to have
>been bricked.
>
>Any ideas?
>
>Jonathan Bennett
Jonathan-
I'm very new to Coreboot myself, but high on the list of things to acquire I'd put a second flash chip and a serial crossover cable.
I'm playing with one of the E350M1 boards with an 8-pin DIP SPI ROM onboard, and I have a laptop next to it running Windows. By running a header cable from the E350M1 to a serial Null Modem cable, then into a serial-to-USB adapter plugged into the Windows machine you can monitor the full progress of the Coreboot load. This makes it significantly easier to understand what is (or is not) happening during the boot process. Highly recommended.
Before messing with the BIOS I got Linux up and running on the E350M1. Booting the board to the factory 4MB ROM allows me to build and flash the replacement 8MB ROM. The nice thing about using a ROM chip that is larger than factory is that flashrom -w verifies the coreboot.rom will fit on the chip so you don't accidentally try to flash the wrong ROM chip. It's saved me once already!
Just a couple of pointers from someone in a similar situation. Mine boots now (yay!).
One thing I have noticed - at least on my board - is that I cannot flash the ROM when I have booted from Coreboot. I MUST boot from the factory ROM to sucessfully flash the chip. I haven't yet looked into that, but plan to as time is available.
Good luck
-Todd
