Hi community,
I'm trying to get coreboot running on a Braswell CPU but it hangs when updating the microcode. I'm stuck in bootblock before CAR and could pin down the problem to the intel_microcode_load_unlocked function in src/cpu/intel/microcode.c where coreboot writes the microcode base address to the IA32_BIOS_UPDT_TRIG register (0x79).
outb(0xF7, 0x80);
msr.lo = (unsigned long)m + sizeof(struct microcode);
msr.hi = 0;
wrmsr(0x79, msr);
outb(0xF8, 0x80);
The outb calls have been added by me, and F7 is just the last post code I see, a few seconds before the CPU reboots. It never reaches F8. So I checked the microcode that I've received from Intel and everything seems fine. The microcode signature matches the CPUID, the platform flags match, the checksum correctly yields to zero, and the base address is aligned on a 16-byte boundary. Some checks are also done by coreboot at runtime. I just can't figure out what the problem is here.
Some more Info:
$ build/cbfstool build/coreboot.rom print
Performing operation on 'COREBOOT' region...
Name Offset Type Size
cbfs master header 0x0 cbfs header 32
fallback/romstage 0x80 stage 30660
fallback/ramstage 0x78c0 stage 63482
fallback/payload 0x17100 payload 61118
config 0x26000 raw 439
revision 0x26200 raw 575
cmos_layout.bin 0x26480 cmos_layout 1128
fallback/dsdt.aml 0x26940 raw 17603
payload_config 0x2ae80 raw 1563
payload_revision 0x2b500 raw 233
(empty) 0x2b640 null 248856
cpu_microcode_blob.bin 0x68280 microcode 68608
(empty) 0x78f00 null 683928
fsp.bin 0x11fec0 fsp 296960
(empty) 0x168700 null 489368
mrc.cache 0x1dfec0 mrc_cache 65536
(empty) 0x1eff00 null 63960
bootblock 0x1ff900 bootblock 1424
$ cat ".config" | grep "MICROCODE"
# CONFIG_USES_MICROCODE_HEADER_FILES is not set
CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
# CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER is not set
# CONFIG_CPU_MICROCODE_CBFS_NONE is not set
# CONFIG_CPU_MICROCODE_MULTIPLE_FILES is not set
CONFIG_CPU_MICROCODE_CBFS_LEN=0x10C00
CONFIG_CPU_MICROCODE_CBFS_LOC=0xFFE68400
# CONFIG_HAVE_ROMSTAGE_MICROCODE_CBFS_SPINLOCK is not set
I really appreciate any hints.
Alex
https://chromium.googlesource.com/chromiumos/platform/ec
Hi, Stafan & All,
I am trying to build a platform which uses AMD APU + EC.
My goal is let EC
1. give the power sequencing logic to APU
2. play as a generic EC which has features like keyboard, UART.
Currently, I don't have plan to boot chrome OS yet.
So I need you guys give me some advice.
Does chromeOS-EC meet my requirement?
Is it OK if I don't boot chromeOS? Is chromeOS-EC hard to master?
Zheng
Hi folks!
We're planning to update the coreboot reference toolchain very soon now,
right after the coreboot 4.4 release which will roughly happen at the
end of this month.
We have fixed a few issues with the new toolchain already, and I am
building and running coreboot images with the new toolchain daily, but
we need more testing from all of you and for all of your coreboot
systems. So please: Build the new toolchain and build and run coreboot
images with it during the next week!
The patch for updating the toolchain is here:
https://review.coreboot.org/#/c/14227/
How to build the new toolchain
$ cd coreboot/
$ git fetch https://review.coreboot.org/coreboot
refs/changes/27/14227/11 && git cherry-pick FETCH_HEAD
$ rm -r util/crossgcc/xgcc
$ make crossgcc CPUS=4 # replace with your number of CPU cores
<wait for a while, have lunch or coffee>
$ rm .xcompile
Stefan
The FSP is rebased with the Intel BCT tool, not the FITC tool.
> On Apr 8, 2016, at 7:38 AM, Martin Roth <gaumless(a)gmail.com> wrote:
>
> Not knowing which platform this is makes it a little harder to
> determine what's locked in place. We'd also need to know if this is
> getting built from the top of the coreboot.org tree, an old
> coreboot.org commit or an private repo with many changes from
> coreboot.org.
>
> Microcode should be able to be placed in any area for most of the FSP
> platforms, but it might need to be changed in Kconfig or the Makefile
> so that the system knows where it is. You might also want to look at
> just including the necessary microcode patches for your particular
> board if possible. Many of the FSP platforms include all available
> microcode back to some pre-production parts by default.
>
> The mrc cache can be moved at build time, but needs to be on the
> correct boundary, and CANNOT have anything else in the same sector on
> the flash. The cache gets erased, so moving it to an odd boundary or
> putting other things in the same sector will cause interesting issues.
>
> The FSP itself can also be moved, but it needs to be rebased with
> intel's FITC tool, and coreboot needs to know the location at build
> time.
>
> Finally, you might want to look at leaving out the small or
> non-essential files, and add them after the build completes to make
> sure that there is contiguous space for your essential components:
> bootsplash.img, config, fspd.bin and cmos_layout.bin
>
> Martin
>
> On Fri, Apr 8, 2016 at 4:29 AM, Patrick Georgi via coreboot
> <coreboot(a)coreboot.org> wrote:
>> 2016-04-08 11:17 GMT+02:00 Nico Huber <nico.huber(a)secunet.com>:
>>> you also stripped:
>>>
>>> fallback/payload 0x1b140 payload 769955
>>>
>>> I guess he means that a fresh build with a bigger (865KiB instead of
>>> 752KiB) payload fails.
>> Of course you're right. I misunderstood the original issue.
>>
>> It's hard to tell how locked down various files are. There's at least
>> some alignment going on for cpu_microcode_blob.bin, mrc.cache,
>> uefi_nvs.bin and fsp.bin, but there may be more to it.
>>
>> Tweaking -position and -align values for mrc.cache and uefi_nvs.bin
>> should provide enough space for a larger payload.
>> Given that uefi_nvs.bin is not mentioned in current master, I have no
>> idea how that came to be.
>>
>>
>> Patrick
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
Hi everyone. I've just sent out an email to everyone who is currently
registered for the coreboot conference. If you believe that you are
registered and did not get the email, please check with me.
Please remember that fees for registration go up $50 after May 1.
Additionally, because Apple is having their annual developer
conference in San Francisco the same week as the coreboot conference,
we would recommend that anyone who plans on attending book their hotel
rooms as soon as possible.
Sign up here: http://goo.gl/forms/f8uqHHFL2S
The conference schedule: https://goo.gl/WF9al6
All of the information about the conference can be found on the coreboot wiki:
https://www.coreboot.org/coreboot_conference_San_Francisco_2016
Martin
> On 04/18/2016 08:17 PM, Julius Werner wrote:
>> For comparison, the coreboot device tree interface on ARM
>> (https://lkml.org/lkml/2014/6/16/622, unfortunately never picked up by
>> the maintainers but still used on Chromebooks today) only exports
>> start address and size of the coreboot table and the whole CBMEM area,
>> so maybe ACPI should just match that. (I guess if CBMEM is referenced
>> by the coreboot table like Aaron said, we could also drop that part.)
>>
> Did you get other feedback than the one mail by Rob Herring?
> We should keep pushing this.
No, I just never heard from them again (as I so often do trying to
work with upstream Linux), got frustrated and gave up. Maybe we should
try again... another two years of Chromebooks shipped with that
interface might now convince them that there's no point bikeshedding
the tiniest naming details anymore.
>>> Here's the 1 million dollar question: Do we want to get rid of coreboot
>>> table and only have a coreboot> specific table?
I don't know enough about how ACPI tables look like to comment on the
technical aspects for this, but please also keep the legacy support
costs in mind when considering to change the whole format. There are
millions of Chromebooks out there which still produce the old tables
(they could be updated, but that would probably not be worth the
effort), so the kernel driver and the cbmem utility would probably
need to be able to detect and parse the old format anyway. At that
point, haven't we just made it more complicated without really gaining
anything?
> This is somewhat orthogonal, but the coreboot tables are not really
> defined all that well. There's no specific endianness for each of the
> fields aside from whatever the endianness the CPUs was in during the
> time of the write. The structs used are also not marked as packed so
> there's not much of a guarantee on field alignment -- especially as
> they are allocated one after another within the table itself.
I think the alignment is actually standardized by C (both start and
size get aligned to the largest-width data type in the struct). Since
it looks like we always used explicit-width types and always wrote the
structs in a way that avoids any need for padding, it should be pretty
well-defined and match the reader's expectation. We just need to
continue paying attention to that when we add entry types... marking
the structs as packed shouldn't change anything but reduce
performance. (There are a few hazards for unaligned uint64_t values,
but we're already making sure our architectures can handle that for
CBFS anyway.)
For the endianness issue, I would suggest to just declare that all the
fields which aren't explicit right now should be little-endian (both
in the coreboot tables and CBFS), and reflect that in the code the
next time we try to add a big-endian architecture. It's unfortunate
that some of the CBFS fields started out locked to the wrong
endianness (and maybe we could even change that at some point), but
little-endian rules the world these days and it's easiest to just use
it throughout.
Hi,
I just wanted to report bug regarding memory initialization on the F2A85-M, but it looks like the issue tracker is down:
502 Bad Gateway
nginx/1.4.6 (Ubuntu)
Cheers, Daniel
Hello,
> From reading the Makefile in payloads/external/SeaBIOS,
> both CONFIG_CONSOLE_SERIAL and CONFIG_DRIVERS_UART_8250IO need to be
> set. However, I can't seem to find which config file I need to modify
> to properly set these variables. Additionally, CONFIG_TTYS0_BASE
> needs to be set as well.
>
> I've also attempted to manually build SeaBIOS with serial output
> enabled, but that didn't seem to have any impact on the result.
From what I know you will have to slightly modify the coreboot source
to be able to personalize your seabios configuration.
https://pelican.craoc.fr/coreboot.html#seabios_1
--
Regards
Maxime de Roucy
FWIW RISCV is looking at this issue and I've talked to them about just
using text-based tables. Since the kernel always has to interpret the table
anyway there's no real advantage to binary formats.
We've even discussed using text protobufs.
ron
On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote:
> 1. coreboot tables base address and size.
> 2. console base address and size.
> 3. ramoops info.
Since ramoops already has its own object in the DSDT, do we want to
mention it here?
What about other cbmem entries? coverage, timestamps...?
Do we want a pointer to cbmem in there, instead?
Here's the 1 million dollar question: Do we want to get rid of coreboot
table and only have a coreboot
specific table? For a non-ACPI OS it's not much harder to read a
(non-DSDT) ACPI table than the current
coreboot table approach. For ACPI OSes it might make things a bit easier
(and counter the argument that
coreboot requires "support for non-standard tables")
> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlaurie(a)chromium.org> wrote:
>> On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin <adurbin(a)google.com> wrote:
>>> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner <jwerner(a)chromium.org>
>>> wrote:
>>>> I think we should only export the coreboot table location and size
>>>> through ACPI and then read everything else from there. That way we can
>>>> share almost all of the kernel driver code with ARM and just need a
>>>> tiny platform-specific stub to look up the table location first. If we
>>>> add all the information into an actual ACPI table, we're building an
>>>> x86-only solution again. (A generic, platform-independent coreboot
>>>> driver could just as easily export the stuff we want into sysfs.)
>>>>
>>> That's fine. The only thing I was concerned about was implementing an
>>> ACPI table proper or try to do some ACPI device shenanigans like the
>>> ramoops device. coreboot doesn't currently have a ACPI ID assigned to
>>> it. If we go with a ACPI device coreboot should apply for an ACPI ID.
>>> I personally think the coreboot ACPI table seems more straight
>>> forward, but I was wondering if people knew of any downsides to going
>>> that route.
>>>
>>
>> The official tables are all defined in the ACPI spec while the related
>> tables are also linked to from the spec, so we'd need to convince the UEFI
>> forum to at least reserve the signature for us (and then link to our table
>> definition) since they intend to act as gatekeepers to avoid collisions in
>> table signatures:
I like the idea of having a separate table rather than an object.
>>
>> "Requests to reserve a 4-byte alphanumeric table signature should be sent to
>> the email address info(a)acpi.info and should include the purpose of the table
>> and reference URL to a document that describes the table format."
>>
>> An easier path would be to define a specific device in the DSDT and populate
>> it with the various data we want to be there on every system. That would
>> allow us to control the format and be able to alter it in the future if we
>> want to expose new information.
>>
>> As you note a Device would need a valid unique HID, and that needs an ID
>> prefix if it wants to be official. In theory we could request something
>> like "CORE" as an official APCI ID from
>> http://www.uefi.org/PNP_ACPI_Registry
> OK. Time for bikeshedding:
>
> 1. CORE
This one is it!
> 2. CBOOT
Would end up as CBOO... dunno.
> 3. ... ?
We could try just "BOOT" (Drop the core, it's cleaner!)
> Stefan, we'll likely need you to request the HID w/ your coreboot.org email.
Can't wait to do it, this is exciting. But we should come up with a
reasonable data structure first, and document it (as Duncan quoted the
standard)
>> I suppose the real difference between the two is whether we need this data
>> early in boot before there is an AML interpreter available in the OS.
> I don't think we need it that early. Right now the current usage (at
> least on x86) is all very late since we're doing AML evaluation. We
> could go w/ the ACPI device first. Just need to request that HID.
A driver could merge our log with dmesg if it ran early enough.
>> -duncan
Stefan
