-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
After reviewing some of the comments on the ASUS KGPE-D16 being
essentially too large of a system and too expensive for many people, and
the fact that modern, blob-free systems are not really available in the
mid-range arena, Raptor Engineering would like to offer to create a
native initalization blob-free port for the ASUS KCMA-D8, which is
essentially the KGPE-D16's ATX-compatible "little brother".
We would be asking $15,000 for the port, including upstreaming to the
master coreboot tree. We already have extensive experience with these
Family 10h/15h boards, and would be able to create a port of similar
quality to the existing KGPE-D16 source in terms of both code quality
and overall functionality.
If this is something you might be interested in please let me know. We
are able to accept multiple payments from various sources for the same
project (within limits), so if this is something your local Linux groups
or similar might be interested in we should be able to keep the cost on
any one individual or organization to a reasonable level.
Thank you for your consideration,
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
> It sounds to me as though the PCI id's of the graphics card for the
> upgraded CPU may be different (I could be totally wrong about that, so I
> defer to others on the list if I'm barking up the wrong tree) and your
> coreboot image may need to be updated accordingly. Of course, it could
> also be the video BIOS that's the problem as you've suggested.
Thank you for the hint. I inspected that, but the PCI-IDs actually look the same:
00:01.0 VGA compatible controller : Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8670D] (prog-if 00 [VGA controller])
Looks like the VGA BIOS is really different:
# diff vgabios_a4-5300.bin vgabios_a10_6700.bin
Binary files vgabios_a4-5300.bin and vgabios_a10_6700.bin differ
Guess I will have to to "update" the VGA BIOS then.
> Hi Daniel,
> Kind Regards,
> On 28/06/16 09:24, Daniel Kulesz via coreboot wrote:
> > Hi folks,
> > I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 (Richland). The board had Coreboot installed before with the VGA BIOS extracted from the A4-5300. However, I did not get any video output when trying to boot after the upgrade, so I replaced the flash chip with a backup with the vendor BIOS that works.
> > Is it likely that the A10-6700 needs a different VGA BIOS or does this this rather look like a different issue? I don't want to experiment too much because the BIOS chips are hardware-wise pretty fragile (even when using the extractor tool).
> > Cheers, Daniel
I need help to porting coreboot Asus M4a785m on Asus M5a78l-m lx3.
I'm trying to porting coreboot on the motherboard Asus M5a78l-m lx3 (rs780l/sb710). I cannot find documentation for the northbridge rs780l.
My configuration: cpu - Athlon 2 x2 220 (K10), memory - 2 + 2 Gb DDR3, video - Asus GT520, sata segate hdd 500Gb, sata asus dvd-rw.
I have a positive result for the configuration with memory 2Gb and external video card Asus GT520. I can load Linux kernel 2.6.
But, i have two problems:
1. I cannot load coreboot with internal graphics card (hd 3000). Coreboot stops loading and to print on console "Calling option ROM…". May be the problems with gfx configuration?
2. I cannot run Linux with memory 4Gb. Coreboot is loading, SeaBios is loading too, but Linux stop load on usb3-2 and ata1 setup. May be the problems with memory map?
Please, help me. I can provide all the necessary information from the log coreboot, SeaBios and Linux.
again, thanks for your clues to this problem. I don't think post code 0x52 is about memory configuration. The post code appears when I call TempRamInit which is supposed to enable Cache-as-RAM. Real memory is initialized at a later call to FspMemoryInit. coreboot supplies the location of the microcode and a cachable region to TempRamInit. Additionally, there are some settings that can be applied to the FSP image with Intel's Binary Configuration Tool. I don't know if these are used during TempRamInit, but I'll try and fiddle around with them.
I agree, it would be helpful to have a list of post codes that can be output by FSP. Otherwise it's all speculation as what is wrong.
On 01/10/2016 10:23 AM, ron minnich wrote:
> One thing I think you'd enjoy doing is building the qemu target, setting
> up qemu with gdb, and just watching what happens, instruction by
> instruction, as the system boots.
One exercise I liked doing was to rewrite the entire boot flow, from
reset vector to protected mode entry. Tested on qemu, put it on
hardware, nothing burned.
> On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
> <mailto:firstname.lastname@example.org>> wrote:
> Hi Peter and Rudolf.
> Thanks for the answers and tips. They are realy helpfull !
> I'll take a look.
> Rafael R. Machado
> Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz
> <mailto:email@example.com>> escreveu:
> I guess your question is more general than the coreboot related
> If you have a firmware image dump of the flash (not the file you
> download from
> board vendor) then yes, first location to be executed is the
> instruction located
> 16 bytes before end of the image.
> In coreboot see in build/ bootblock_inc.S which also has
> reset16.inc and
> entry16.inc which is a real start. Consult the Intel or AMD
> manual to see the
> CPU state after reset. The CPU starts in real mode, but CS base
> is shifted to
> last 64KB before end of 4GB address space. In general your CPU
> starts in
> compatible mode with 8086 manufactured in 1978.
> coreboot mailing list: coreboot(a)coreboot.org
In Linux it is possible to load an EDID externally. Coreboot can
currently not do this. Do you think it is worth implementing this
An EDID file is a bit to big (128 bytes) to fit in nvram so it would have to go in cbfs.
Where in the code do you think this setting should be implemented:
NB code, read_edid in drivers, decode_edid in lib, somewhere else?
How do you think this feature should be turned on: nvram option or build
Thank you for your comments
But I should still see 4GB without any patch. Right?
Windows only see 1.92GB as “Installed Memory (RAM)” in Control Panel->System.
I am happy for the system to see up to 4GB only.
From: Zoran Stojsavljevic [mailto:firstname.lastname@example.org]
Sent: Tuesday, 7 June 2016 1:13 PM
To: Naveed Ghori
Subject: Re: [coreboot] Windows only seeing 2GB of 4G (Seabios
For you to read: https://en.wikipedia.org/wiki/Physical_Address_Extension
Important: With PAE, IA-32<https://en.wikipedia.org/wiki/IA-32> architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits.
Then, after reading, this can/will help you: https://wj32.org/wp/2011/02/23/pae-patch-updated-for-windows-7-sp1/<https://linkprotect.cudasvc.com/url?a=https://wj32.org/wp/2011/02/23/pae-pa…>
On Tue, Jun 7, 2016 at 6:23 AM, Naveed Ghori <naveed.ghori(a)dti.com.au<mailto:email@example.com>> wrote:
I am booting a 32 bit Win 7 image (via Seabios).
Windows is detecting only 1.92GB (even though there is 8GB of memory available.
Being a 32 bit OS I would have expected it to see at least 4GB.
Coreboot logs shows:
Available memory below 4GB: 0x7ae00000 (1966M)
Available memory above 4GB: 6144M
What can cause the full 4GB to not be seen. Should I install only 4GB of memory instead of 4GB? I have ordered some to try in any case.
Naveed Ghori | Lead Firmware & Driver Engineer
DTI Group Ltd | Transit Security & Surveillance
31 Affleck Road, Perth Airport, Western Australia 6105, AU
P +61 8 9373 2905<tel:%2B61%208%209373%202905>,151 | F +61 8 9479 1190<tel:%2B61%208%209479%201190> | naveed.ghori(a)dti.com.au<mailto:firstname.lastname@example.org>
Visit our website www.dti.com.au<https://linkprotect.cudasvc.com/url?a=http://www.dti.com.au&c=E,1,J7GyvbswE…>
The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.
coreboot mailing list: coreboot(a)coreboot.org<mailto:email@example.com>
I am experimenting SMM/SMI on Minnowboard Max using the KMC (USB Legacy
Keyboard/Mouse Control) register. Per Baytrial datasheet, port60/64
read/write events would cause SMI if enabled. In Linux, I can see the status
bits set upon read/write port 60 or 64.
I am also able to enable SMI in KMC register in coreboot and verify the
settings in Linux. However, I am not sure whether the SMI handler is entered
when the events occur. The system would just hang, after writing to port 64
for example. None of my instrumented code in southbridge_smi_handler() in
soc/intel/fsp_baytrail/smihandler.c seems to be executed.
My minnowboard max coreboot build is based on
Am I missing something to hook up/relocate the SMI handler? Suggestions on
debugging approach would be much appreciated.