Hello,
I recently bought an Asus KGPE-D16 board, with an Opteron 6238 and 4
Micron MT18JSF25672PDZ-1G4F1DD modules.
Firstly I tried to boot with vendor BIOS but I don't get any output on VGA.
I have a PCI Post Card and it seems it arrives to 3E and then I think it
enters in a loop.
I flashed Coreboot with default settings just to try to get some more
useful logs. The result I think is more or less the same, it doesn't
arrive to payload.
Memory is installed in A2,B2,C2 and D2 slots.
I spent multiple hours trying to figure where is the problem.
Do you have any ideas?
I attach the console log.
Thanks in advance.
Best Regards,
- Eli
Hello
I'm trying to put together a step by step guide of building and flashing coreboot to a Chromebook C201.
If you look at the bugfixes part of my guide here (https://gist.github.com/markwylde/4061eab71fa1ec7a27c40a87499924c4#bugfixs), you'll see I've added two problems I had with the master branch of coreboot:
1. Depthcharge is not a payload. The `payloads/Kconfig` file doesn't have an option for Depthcharge. However if you add it and run menuconfig, selecting the new payload, everything works great (well apart from issues 2)
2. Coreboot/Depthcharge can't find a config file for veyron_speedy because `payloads/libpayload/configs/config.veyron_speedy` is not present. If I clone `payloads/libpayload/configs/config.veyron` then it works perfectly.
When you run make you are going to get an error message, something like below:
I'm almost certain my "fixes" aren't actually fixes, and I'm just doing something wrong, if you could correct me I'd be so grateful.
Otherwise, if this is correct I'd be more than happy to try and workout submitting a pull request.
Thanks a lot
Mark
On Sun, Feb 25, 2018 at 08:51:56PM +0300, Mike Banon wrote:
> >
> > Please see the developer documentation:
> >
>
> I am afraid this documentation does not answer why this build problem
> does not happen when I apply this patch to the standalone cloned seabios
> while it does happens when I apply it to the seabios built by a coreboot
The default seabios configuration is to build for qemu and not
coreboot. So, by default it would not include that code and would not
raise a compile time error. If you configured seabios to build for
coreboot and it didn't raise a compile time error then that seems like
a build defect.
-Kevin
Hi,
In case of Harcuvar CRB we have 16M SPI flash: first 8M for ME (which is outside of CBFS) and last 8M for coreboot.
We need to specify two things in coreboot config:
- ROM chip size – 16M – physical size of SPI flash (needed for correct flash offset calculations inside coreboot code)
- Size of CBFS filesystem in ROM – 8M (0x800000) or less
16M coreboot.rom file should be built with above config.
You need to manually inject 8M ME blob at offset 0 into ‘coreboot.rom’ file.
Or just flash last 8M from coreboot.rom into last 8M of SPI flash if ME blob is already there.
Mariusz
From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Sumo
Sent: Monday, February 26, 2018 9:15 PM
To: coreboot(a)coreboot.org
Subject: [coreboot] Atom c3000 Harcuvar and Intel ME
Hi,
In the coreboot build menu there is no option regarding the Intel ME integration.
The 'coreboot.rom' file is the full SPI flash image or this file is suitable to
replace the BIOS region of the SPI flash (0x00800000--0x00ffffff)?
(i.e. in the SPI flash we already have a region for Intel ME firmware)
Thanks,
Sumo
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
> Le 27 févr. 2018 à 13:42, Sumo <kingsumos(a)gmail.com> a écrit :
>
> > When configuring CB with menuconfig you have to select your platform
> > and type in the path to your ME-binary-blob.
>
> For the Harcuvar CRB there is no such configuration.
>
> This conf. is available to other mainboards (e.g. Intel "Little Plains" mainboard:
> menu "Chipset"->"Intel Firmware"->"Add Intel descriptor.bin file"->"Add Intel
> ME/TXE firmware"->"Path to management engine firmware").
>
> Maybe for the Harcuvar CRB the Intel ME FW is installed in the second
> SPI flash, therefore there is no need to add the ME blob in the coreboot
> build? I´m not sure about this, some board maintainer can confirm
> this?
No it’s in the same flash. Basically your first idea is what I am doing:
> replace the BIOS region of the SPI flash (0x00800000–0x00ffffff)
Or use intel fitc tool to build the final SPI image.
>
> Do we have any documentation regarding the coreboot port for Harcuvar?
Do you have access to intel support ? If yes there should be a document, but
I’m not even sure it has been updated when the support was upstreamed.
Hope this helps,
Julien VdG
>
> Thanks,
> Sumo
>
> 2018-02-26 19:42 GMT-03:00 Philipp Stanner <stanner(a)posteo.de <mailto:stanner@posteo.de>>:
> Am Montag, den 26.02.2018, 17:14 -0300 schrieb Sumo:
> > Hi,
> >
> > In the coreboot build menu there is no option regarding the Intel ME
> > integration.
> > The 'coreboot.rom' file is the full SPI flash image or this file is
> > suitable to
> > replace the BIOS region of the SPI flash (0x00800000--0x00ffffff)?
> > (i.e. in the SPI flash we already have a region for Intel ME
> > firmware)
>
> I'm not sure what the question is.
>
> When configuring CB with menuconfig you have to select your platform
> and type in the path to your ME-binary-blob. The later has to be
> provided by you; meaning you have to extract the BIOS from the flash,
> extract the ME-binary using coreboot/utils, clean it with ME-cleaner
> (optional) and then build coreboot with your blob.
>
> The toolchain takes care automatically about the correct placement of
> the ME in the right address-ranges.
>
> I hope this was helpful.
>
> > Thanks,
> > Sumo
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
--
Julien Viard de Galbert - jviarddegalbert(a)online.net
Online / Scaleway
Looking for an amazing job? Join us NOW ! https://careers.scaleway.com/
Am Montag, den 26.02.2018, 17:14 -0300 schrieb Sumo:
> Hi,
>
> In the coreboot build menu there is no option regarding the Intel ME
> integration.
> The 'coreboot.rom' file is the full SPI flash image or this file is
> suitable to
> replace the BIOS region of the SPI flash (0x00800000--0x00ffffff)?
> (i.e. in the SPI flash we already have a region for Intel ME
> firmware)
I'm not sure what the question is.
When configuring CB with menuconfig you have to select your platform
and type in the path to your ME-binary-blob. The later has to be
provided by you; meaning you have to extract the BIOS from the flash,
extract the ME-binary using coreboot/utils, clean it with ME-cleaner
(optional) and then build coreboot with your blob.
The toolchain takes care automatically about the correct placement of
the ME in the right address-ranges.
I hope this was helpful.
> Thanks,
> Sumo
Hi Mark.
I saw a very similar issue (similar because I have not analyzed it in detail due to missing time) with a 6 core Broadwell-DE. It hangs as well in SMM relocation.
Same mainboard and coreboot binary with a 4 core Broadwell-DE does not have this effect.
Werner
>Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von mark pleso via coreboot
>Gesendet: Montag, 26. Februar 2018 23:40
>An: coreboot(a)coreboot.org
>Betreff: [coreboot] Broadwell-DE hang in coreboot: mp_init.c
>
>Has anyone else seen a hang during coreboot booting on a Broadwell-DE? The issue appears to be in mp_init.c, in the function smm_do_relocation(). This is coreboot 4.7, but I think the issue exists in 4.6 >as well.
>
>Enabling the printk will stop the hang. Or, just adding a wbinvd() instruction will stop the hang, and things proceed normally. Code is below.
>
>Any help would be appreciated.
>
>btw - This not a commercial motherboard.
>
>coreboot/src/cpu/x86/mp_init.c
>static void asmlinkage smm_do_relocation(void *arg)
>{
> const struct smm_module_params *p;
> const struct smm_runtime *runtime;
> int cpu;
> uintptr_t curr_smbase;
> uintptr_t perm_smbase;
>
> p = arg;
> runtime = p->runtime;
> cpu = p->cpu;
> curr_smbase = runtime->smbase;
>
> if (cpu >= CONFIG_MAX_CPUS) {
> printk(BIOS_CRIT,
> "Invalid CPU number assigned in SMM stub: %d\n", cpu);
> return;
> }
>
> /*
> * The permanent handler runs with all cpus concurrently. Precalculate
> * the location of the new SMBASE. If using SMM modules then this
> * calculation needs to match that of the module loader.
> */
> perm_smbase = mp_state.perm_smbase;
> perm_smbase -= cpu * runtime->save_state_size;
>
> printk(BIOS_DEBUG, "New SMBASE 0x%08lx\n", perm_smbase);
>
> /* write cache to DRAM before calling relocation handler */ /* will stop hang */
> wbinvd(); /* <<=== OR NEW INSTRUCTION w/o printk STOPS HANG */
>
> /* Setup code checks this callback for validity. */
> mp_state.ops.relocation_handler(cpu, curr_smbase, perm_smbase);
>}
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/25/2018 02:18 AM, Mike Banon wrote:
>> Any particular reason those patches were not upstreamed?
>
> Because a person who submitted these patches did not fix some problems,
I'm aware of this. Upstreaming was never part of the original funding
effort and I haven't had any spare time to try to work on it; been
working on several other projects in what little spare time I have had
over the past year. If anyone else would like to apply the recommended
cleanups and resubmit I'm fine with that.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJako8TAAoJEK+E3vEXDOFbtikIALooPL3+eUeog+JWDYy6WmiR
UpzHFR8masKd33ae8+6Sfz3Xh3P0jXvMhVnXPT5QxT1OAMuiOsqRTlp2Tt0ErmJ1
y8FNYVEjBWzWAg8FIJD9IRUlumcVqXRCI2DTDNQJt9ckCtm7mFqaN5oB49TlL0D0
o30+5Gm0kSzXEgC5G9NgiQk/sD06R+l9UDlwJa51ysvl5b5tPMh9eT2jj5kn6uAE
h5BDhruEODJb6E7077wuzKREhZR/gEmUvBmdgUCuPWs2EHZyC6vkAYqIWhjBODtv
dBL5fyPsMnQRua+A+O7suKxt5ieNxx59BOsGwh5XWvubg/Gr7TIDVYDD5lK6Bms=
=tApG
-----END PGP SIGNATURE-----
Has anyone else seen a hang during coreboot booting on a Broadwell-DE? The issue appears to be in mp_init.c, in the function smm_do_relocation(). This is coreboot 4.7, but I think the issue exists in 4.6 as well.
Enabling the printk will stop the hang. Or, just adding a wbinvd() instruction will stop the hang, and things proceed normally. Code is below.
Any help would be appreciated.
btw - This not a commercial motherboard.
coreboot/src/cpu/x86/mp_init.cstatic void asmlinkage smm_do_relocation(void *arg)
{ const struct smm_module_params *p; const struct smm_runtime *runtime; int cpu; uintptr_t curr_smbase; uintptr_t perm_smbase;
p = arg; runtime = p->runtime; cpu = p->cpu; curr_smbase = runtime->smbase;
if (cpu >= CONFIG_MAX_CPUS) { printk(BIOS_CRIT, "Invalid CPU number assigned in SMM stub: %d\n", cpu); return; }
/* * The permanent handler runs with all cpus concurrently. Precalculate * the location of the new SMBASE. If using SMM modules then this * calculation needs to match that of the module loader. */ perm_smbase = mp_state.perm_smbase; perm_smbase -= cpu * runtime->save_state_size;
printk(BIOS_DEBUG, "New SMBASE 0x%08lx\n", perm_smbase);
/* write cache to DRAM before calling relocation handler */ /* will stop hang */ wbinvd(); /* <<=== OR NEW INSTRUCTION w/o printk STOPS HANG */
/* Setup code checks this callback for validity. */ mp_state.ops.relocation_handler(cpu, curr_smbase, perm_smbase);}
Hi,
In the coreboot build menu there is no option regarding the Intel ME
integration.
The 'coreboot.rom' file is the full SPI flash image or this file is
suitable to
replace the BIOS region of the SPI flash (0x00800000--0x00ffffff)?
(i.e. in the SPI flash we already have a region for Intel ME firmware)
Thanks,
Sumo
