#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 :)
#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/>
Hello,
some time (> 1 year?) ago I asked on flashrom about support for the T60
and the attached patch was sent as part of the answer. The other part of
the answer was that whoever sent this patch was not happy with it.
Unfortunately I didn't keep the mail(s) and have forgotten the reason
for this. Google also didn't really help. What I found was a similar but
not identical mail on coreboot:
http://www.coreboot.org/pipermail/coreboot/2010-December/062303.html
As the T60 is one of the few Laptop models that are supported by coreboot
and I'd like to update to it I have two requests:
1) would someone be willing to update the patch to the current flashrom
codebase (I tried this and was able to read, but I don't trust it as
the change was done without understanding what the changes did).
2) if possible integrate this into flashrom to make using coreboot easier.
3) (of 2) would it be useful to integrate bucts into flashrom or move it
to coreboot/utils/?
Thanks
Jörg
--
Joerg Mayer <jmayer(a)loplof.de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
> -----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
Hi
I did not find this method of bypassing the mainboard flash chip and
booting from PCI add-on card documented or discussed before. The nice
think in this is that neither mainboard or its flash needs to be
modified. Good news in the case of a soldered flash and this method may
work with mini-PCI slots on laptops too.
For pre-ICH6 the key is in subtractive PCI decode. This has been
supported in 82801 chipset from the early days and is briefly documented
in ICH3 datasheet [1], see 5.1.1. PCI Bus interface. This decode mode is
on by default and there is no documentation of a hw bootstrap that could
disable it.
For ICH7 onwards there are HW bootstraps to select between LPC/SPI/PCI.
If you don't know where the bootstraps are, go with SPI and forget about
this PCI add-on boot.
To try this, I have modified a PCI PATA-RAID card as follows: I cut the
PCI RST# signal from card edge to controller, put a jumper to close it
for normal boots and placed a weak 10kOhm pull-up to Vio on the chip
side.
With this I have succesfully done the following on a ICH4 based
mainboard:
1. I built SerialICE as usual and programmed the option ROM of the
modified PCI card with it.
2. I set the PCI config BAR for that option ROM as 0xfffe0000. I had
this hacked in flashrom, setpci might work as well. This was 128kB
region while my flash was actually 64kB.
3. Reset the machine, but not the PCI card. I simply removed the jumper
on the RST# signal on the PCI card before giving reboot command.
4. I got into SerialICE prompt.
Should go without saying: Code run from option ROM must not switch from
subtractive to positive PCI decode. I also think the PCI slot used must
be directly on the southbridge PCI bus and not behind some other PCI
bridge.
To use this on cold boots and as a recovery method some means to default
that config BAR for option ROM on cold power-on is required. Custom PCI
FPGA can do that for sure, other ideas are welcome.
Kyösti
[1]
http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-...
Dear coreboot folks,
I cloned the source tree,
$ git describe
4.0-2410-g92ff934
did `make crossgcc` and run `make menuconfig`.
I chose ASRock E350M1 and SeaBIOS master.
At the end I got the following.
$ make
[…]
Checking out SeaBIOS revision origin/master
Switched to branch 'master'
Deleted branch coreboot (was 347f294).
Branch coreboot set up to track remote branch master from origin.
Switched to a new branch 'coreboot'
CONFIG SeaBIOS origin/master
Working around non-functional -combine
Build default config
#
# configuration written to /home/joe/coreboot/build/seabios/.config
#
MAKE SeaBIOS origin/master
Working around non-functional -combine
Build Kconfig config file
/home/joe/coreboot/build/seabios/.config:89:warning: override: reassigning to symbol COREBOOT
/home/joe/coreboot/build/seabios/.config:90:warning: override: reassigning to symbol DEBUG_SERIAL
/home/joe/coreboot/build/seabios/.config:95:warning: override: reassigning to symbol VGAHOOKS
#
# configuration written to /home/joe/coreboot/build/seabios/.config
#
Compiling whole program /home/joe/coreboot/build/seabios/out/ccode32flat.o
Compiling whole program /home/joe/coreboot/build/seabios/out/code32seg.o
Compiling whole program /home/joe/coreboot/build/seabios/out/ccode16.o
Compiling to assembler /home/joe/coreboot/build/seabios/out/asm-offsets.s
Generating offset file /home/joe/coreboot/build/seabios/out/asm-offsets.h
Compiling (16bit) /home/joe/coreboot/build/seabios/out/romlayout.o
Building ld scripts
fatal: No names found, cannot describe anything.
* Version: -20120524_211503-asrock-e350m1
Fixed space: 0xe05b-0x10000 total: 8101 slack: 10 Percent slack: 0.1%
16bit size: 38848
32bit segmented size: 2307
32bit flat size: 17309
32bit flat init size: 40928
Lowmem size: 2144
Linking /home/joe/coreboot/build/seabios/out/rom16.o
Stripping /home/joe/coreboot/build/seabios/out/rom16.strip.o
Linking /home/joe/coreboot/build/seabios/out/rom32seg.o
Stripping /home/joe/coreboot/build/seabios/out/rom32seg.strip.o
Linking /home/joe/coreboot/build/seabios/out/rom.o
Prepping /home/joe/coreboot/build/seabios/out/bios.bin
[…]
I guess it has to do with cloned SeaBIOS git tree.
Thanks,
Paul
