Is there a straightforward way to get an IMB-A180 to boot with a single
DIMM in slot 0? It boots fine in slot 1. I've looked through the code
at length, and thought it configures the dimm, it fails in
coreboot/src/vendorcode/amd/agesa/Proc/Mem/Main/KB/mmflowKB.c
//----------------------------------------------------
// If there is no dimm on the system, do fatal exit
//----------------------------------------------------
if (NBPtr[BSP_DIE].RefPtr->SysLimit == 0) {
PutEventLog (AGESA_FATAL, MEM_ERROR_NO_DIMM_FOUND_ON_SYSTEM, 0, 0,
0, 0, &(MemMainPtr->MemPtr->StdHeader));
return AGESA_FATAL;
}
Even though it has detected and configured the dimm in slot 0.
Again, this does work with slot 1.
Many thanks,
Mark Mason
Engineering Design Team
Am 28.05.2014 16:36, schrieb WANG FEI:
> XHCI support is what I want, currently what's payload have a better XHCI
> support? Seabios or U-Boot?
There are also FILO and depthcharge (both using the libpayload XHCI driver)
Patrick
Hi,
HP and other laptop vendors claim to use an AMD A76M chipset in some of
their machines. I have been unable to find any info about (or even
confirm the existence of) the A76M on the AMD website or any other
reliable source.
https://en.wikipedia.org/wiki/Comparison_of_AMD_chipsets is also silent,
but the numbers there suggest the A76M might be a Bolton chipset.
Does anyone know if there are public docs for the A76M (possibly under
another name), and how feasible it is to drive it with current public
(or to-be-released) AGESA?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
The 1.7.5 version of SeaBIOS has now been released. For more
information on the release, please see:
http://seabios.org/Releases
New in this release:
* Support for obtaining SMBIOS tables directly from QEMU.
* XHCI USB controller fixes for real hardware (now tested on several boards)
* SeaVGABIOS improvements
* New driver for "coreboot native vga" support
* Improved detection of older x86emu versions with incorrect emulation.
* Several bug fixes and code cleanups
For information on obtaining SeaBIOS, please see:
http://seabios.org/Download
I have a problem on Intel DQ77KB board. I have two the same boards and
on every board Memtest86 reports a problem at 2990.8MB. That problem
occur only if I use 4 or 8GB memory. With 2GB memory everything is OK.
What may be causing errors in Test2 "Address test, own address,
Parallel" in Memtest86?
http://www.memtest86.com/technical.htm
Chris
Gents,
What I'm doing is to avoid PCI enumeration code
allocating/setting/configuring resource to a specific PCI device
(Bus:Device:Function), is there a mechanism in coreboot to achieve this?
I've achieved this by setting this specific PCI device's read_resources to
NULL, just wondering what's the best way to get this done.
Many thanks,
-Fei
Hi all ( but Martin in particular! )
I can see support for Baytrail and Bayley Bay going in at the moment. I'm interested in this board, and was wondering what the timeline for support might be - is there much more to do? And when will we see it?
Thanks,
Mike.
I've received a few reports of people having problems building seabios
within the coreboot build system. In my investigation I've uncovered
at least two problems:
1 - on my machine, (with CONFIG_ANY_TOOLCHAIN=y) I can't build seabios
from corebooat at all because of the LD definition. The .xcompile
file gets created with:
LD_x86_32:=ld.bfd -b elf32-i386 -melf_i386
and this gets passed to SeaBIOS as:
make -C payloads/external/SeaBIOS [...] LD="ld.bfd -b elf32-i386 -melf_i386"
unfortunately, the seabios build expects the LD variable to be a
program - not the combination of a program and parameters. This
breaks the build. (This also seems to happen with AS="as --32".)
2 - others are reporting problems with python3 even on seabios master
(when using coreboot's build chain). This is actually a symptom of a
much larger issue - for some reason section names are being corrupted
by the tool chain. Here's a quick test case:
echo 'int Foo __attribute__((section( ".data.varfseg." __FILE__ "." "123" )));' > foo.c ; gcc -c foo.c -o foo.o ; objdump -x foo.o | grep varfseg
this should show section names like ".data.varfseg.foo.c.123", but on
impacted machines the section names are actually showing up as
".data.varfseg.". This truncation of the section names results in
SeaBIOS not being able to weed out unneeded content from the final
binary, and it results in the seabios build getting confused on build
options.
-Kevin
