Hello,
I made some improvements to this wiki page:
http://www.coreboot.org/Build_from_Windows
1) The prebuilt windows build environment now uses
util/crossgcc/buildgcc to build cross compilers. The
previous release uses a manually built cross compiler.
2) Both 4.4.4 and 4.5.0 cross compiler versions are included.
Version 4.5.0 is more tolerant of microsoft-isms found in
some snapshots of the next generation AMD reference code.
3) Now, all coreboot projects can build from this environment.
The previous release was missing libgcc.a, which is needed
by some of the projects.
4) The example now includes the steps for building seabios.
Thanks,
Scott
Hi,
I'm trying (again) to get my head around how the different pieces of
HT-enumeration interacts... Do we have any documentation on the
variables
HT_CHAIN_UNITID_BASE
HT_CHAIN_END_UNITID_BASE
SB_HT_CHAIN_ON_BUS0
SB_HT_CHAIN_UNITID_OFFSET_ONLY
and their intended/actual semantics? The H8QIi I'm working on has a
RS780 (or 890, but I'm working from the 780 code base) SB which expects
to find itself on unit 0. Both the existing code and the hardware seems
determined about this; rs780.c has this hard coded, and changing the
base unitid in the HT cap block appears to have no effect.
So, I'm trying to keep it there. However, processLink in h3finit wants
to shift the devies upwards in order to discover the ncht chain --
unless the AMD_CB_ManualBUIDSwapList callback is invoked. The
AMD_CB_ManualBUIDSwapList in ht_wrapper is only effective if
CONFIG_HT_CHAIN_UNITID_BASE is non-zero, though, which kindof makes it a
non-starter for me. (The callback also makes some assumptions about
which HT link the SB is on that seem unwarranted.)
I think perhaps the best solution is to override the BUIDSwapList
callback in ht_wrapper, but I'm not sure what the easiest way to do that
is. Should I just call amdHtInitialize without going through
amd_ht_init at all? Or should we make amd_ht_init merge mainboard
specific callbacks in some way? Thoughts welcome.
--
Arne.
Hi,
To determine whether the chip is in single or dual plane mode, you should read F3xA0[8]. If that bit is 1, the chip is operating in single plane mode and if it is 0, VDD and VDDNB are controlled separately through both the SVI and the PVI interfaces (the latter operating as an SVI). See section 2.4.2.1 of the BKDG. The rest of the section 2.4.2 is interesting reading as well.
FrankV
#164: Building Coreboot v4 r5555/5554 fails mysteriously on Debian lenny and
etch (x86)
----------------------------+-----------------------------------------------
Reporter: juhe@… | Owner: stepan@…
Type: defect | Status: new
Priority: major | Milestone:
Component: coreboot | Keywords: makefile, debian
Dependencies: | Patchstatus: there is no patch
----------------------------+-----------------------------------------------
I am trying to build Coreboot v4 from SVN with default settings, but I get
build failures. The build environment is Debian Linux on x86.
Process goes as follows:
{{{
- check out coreboot trunk from SVN as per wiki instructions
- run "make menuconfig", select QEMU hardware (default), ROM size either
256K or 1M
- run "make":
}}}
{{{
coreboot.r5554$ make
HOSTCC util/romcc/romcc (this may take a while)
ROMCC mainboard/emulation/qemu-x86/bootblock.inc
GEN bootblock/bootblock.c
CC mainboard/emulation/qemu-x86/bootblock.s
CC mainboard/emulation/qemu-x86/bootblock.o
GEN bootblock/ldscript.ld
LINK bootblock.elf
OBJCOPY coreboot.bootblock
HOSTCC cbfstool/common.o
[..cut..]
HOSTCC util/options/build_opt_tbl
OPTION option_table.h
GEN build.h
ROMCC romstage.inc
GEN romstage/crt0.S
CC mainboard/emulation/qemu-x86/crt0.s
CC mainboard/emulation/qemu-x86/crt0.initobj.o
make: *** No rule to make target `/optbuild/lib/uart8250.initobj.o',
needed by `build/coreboot.romstage'. Stop.
}}}
I have tried this on two separate Debian/lenny machines with the same
results. Is Debian somehow broken or Coreboot build scripts? Or am I
making some mistake? What is this directory /optbuild and why coreboot
build is trying to create/access it? I tried to grep "optbuild" from the
sources, but it does not seem to exist there.
Trying the same on Debian/etch (older release):
{{{
% make
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
mkdir: cannot create directory `/optbuild': Permission denied
ROMCC mainboard/emulation/qemu-x86/bootblock.inc
GEN bootblock/bootblock.c
CC mainboard/emulation/qemu-x86/bootblock.s
CC mainboard/emulation/qemu-x86/bootblock.o
GEN bootblock/ldscript.ld
LINK bootblock.elf
collect2: ld terminated with signal 11 [Segmentation fault]
make: *** [build/bootblock.elf] Error 1
}}}
This looks like broken ld in Debian, or something going wrong in the build
process.
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/164>
coreboot <http://www.coreboot.org/>
#167: Support for new ION2 (Intel NM10 chipset)
--------------------------------------+-------------------------------------
Reporter: niklas.lonn@… | Owner: stepan@…
Type: defect | Status: new
Priority: major | Milestone:
Component: coreboot | Keywords: NM10,ION2,Intel,Asus
Dependencies: | Patch Status: there is no patch
--------------------------------------+-------------------------------------
I have read that the ION platform is not supported because nVidia doesn't
release the datasheets in public, however, a new ION2 platform is
availabl, having an Intel NM10 north/south-bridge combo with open datashet
at:
http://www.intel.com/products/Internet_Device/Chipsets/NM10/NM10-technicald…
The motherboard of my interest is this one (Probably many others too):
http://www.asus.com/product.aspx?P_ID=iIZKMXSj0jZKiebE&templete=2
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/167>
coreboot <http://www.coreboot.org/>
#161: Improve USB debug port configuration
----------------------------+-----------------------------------------------
Reporter: oxygene | Owner: stepan@…
Type: enhancement | Status: new
Priority: trivial | Milestone:
Component: coreboot | Keywords:
Dependencies: | Patchstatus: there is no patch
----------------------------+-----------------------------------------------
Right now, the right port number is configured in DBGP_DEFAULT without
much documentation anywhere. It's even defined in boards that don't use
the value at all.
Maybe move it to Kconfig? Document it? Just clean up the copy&pasted
useless values?
--
Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/161>
coreboot <http://www.coreboot.org/>
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "uwe" checked in revision 5880 to
the coreboot repository. This caused the following
changes:
Change Log:
Forgot to 'svn add' src/cpu/x86/name (trivial).
Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de>
Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de>
Build Log:
Compilation of getac:p470 has been fixed
Compilation of ibase:mb899 has been fixed
Compilation of intel:d810e2cb has been fixed
Compilation of intel:d945gclf has been fixed
Compilation of intel:eagleheights has been fixed
Compilation of kontron:986lcd-m has been fixed
Compilation of rca:rm4100 has been fixed
Compilation of roda:rk886ex has been fixed
Compilation of thomson:ip1000 has been fixed
If something broke during this checkin please be a pain
in uwe's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
Best regards,
coreboot automatic build system