Re: [coreboot] memtest86 reading 0k memory

On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: That's a pretty old memtest86+. Also, memtest86+ prefers linuxbios/coreboot memory map to e820. This becomes a problem when SeaBIOS sets up a USB

Re: [coreboot] Unifying IO accessor macros

On Wed, Feb 18, 2015 at 10:49 AM, Alexandru Gagniuc mr.nuke...@gmail.com wrote: On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote: As I have noted on http://review.coreboot.org/#/c/7924/ it's very short sighted to go this route. In assembling a coreboot stack (which includes

Re: [coreboot] Unifying IO accessor macros

On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc mr.nuke...@gmail.com wrote: On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote: You still haven't made any counter-argument to the practicalness of being compatible with the software systems where coreboot gets contribution. And

Re: [coreboot] Unifying IO accessor macros

On Wed, Feb 18, 2015 at 9:16 AM, Aaron Durbin adur...@google.com wrote: On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc mr.nuke...@gmail.com wrote: On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote: The x86 was recently fixed to take in void *. The order of arguments was

Re: [coreboot] Unifying IO accessor macros

On Wed, Feb 18, 2015 at 10:35 AM, Patrick Georgi pgeo...@google.com wrote: 2015-02-18 17:23 GMT+01:00 Vadim Bendebury vben...@chromium.org: kernel, u-boot, etc. They all have the write(val, addr) semantics. I see no good reason to artificially erect an ever present barrier for integrating code

Re: [coreboot] GCC update broke AMD Fam10h boot

On Thu, Mar 19, 2015 at 7:53 PM, Julius Werner jwer...@chromium.org wrote: 145a8a: 83 c3 14add$0x14,%ebx Okay, sorry, I didn't know you looked that closely into this. That's quite unrefuteable. The only question that I still have is then WTF the compiler was

Re: [coreboot] GCC update broke AMD Fam10h boot

On Thu, Mar 19, 2015 at 7:21 PM, Julius Werner jwer...@chromium.org wrote: That said, I went back and looked at the assembly dump. It was using 0x14 as the size of the structure when sequencing through the entries. 001465dc R _bs_init_begin 001465e0 r cbmem_bscb 00146600 r gcov_bscb

Re: [coreboot] cbmem console broken on Intel hardware since ec5e5e0

On Tue, Apr 21, 2015 at 9:54 AM, Aaron Durbin adur...@chromium.org wrote: On Mon, Apr 20, 2015 at 9:29 PM, Matt DeVillier matt.devill...@gmail.com wrote: On 4/20/2015 3:29 PM, Aaron Durbin wrote: On Mon, Apr 20, 2015 at 9:23 AM, Matt DeVillier matt.devill...@gmail.com wrote: On 4/20/2015

Re: [coreboot] QEMU build failure in master

On Wed, May 6, 2015 at 9:41 AM, Aaron Durbin adur...@google.com wrote: On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 06:54 AM, Patrick Georgi wrote: 2015-05-05 21:49 GMT+02:00 Timothy Pearsontpear...@raptorengineeringinc.com: While

Re: [coreboot] QEMU build failure in master

On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 11:41 AM, Aaron Durbin wrote: That's probably my fault. I was under the impression monotonic_timer was a first class citizen now (I at least recall someone doing that) I thought wrong? You

Re: [coreboot] QEMU build failure in master

On Wed, May 6, 2015 at 9:36 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 06:54 AM, Patrick Georgi wrote: 2015-05-05 21:49 GMT+02:00 Timothy Pearsontpear...@raptorengineeringinc.com: While working on the test system earlier today I noticed that QEMU builds are

Re: [coreboot] QEMU build failure in master

On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 11:46 AM, Aaron Durbin wrote: On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 11:41 AM, Aaron Durbin wrote: That's probably my

Re: [coreboot] QEMU build failure in master

On Wed, May 6, 2015 at 9:54 AM, Aaron Durbin adur...@google.com wrote: On Wed, May 6, 2015 at 9:51 AM, Timothy Pearson tpear...@raptorengineeringinc.com wrote: On 05/06/2015 11:46 AM, Aaron Durbin wrote: On Wed, May 6, 2015 at 9:45 AM, Timothy Pearson tpear...@raptorengineeringinc.com

Re: [coreboot] [poll] device_t

On Thu, May 7, 2015 at 3:42 PM, Patrick Georgi via coreboot coreboot@coreboot.org wrote: 2015-05-07 22:00 GMT+02:00 Stefan Reinauer stefan.reina...@coreboot.org: With our current bootblock concept, it is never going away on x86 (for bootblock usage) Which isn't that much of a problem once we

Re: [coreboot] [poll] device_t

On Fri, May 8, 2015 at 12:16 PM, Patrick Georgi pgeo...@google.com wrote: 2015-05-08 17:31 GMT+02:00 Aaron Durbin adur...@google.com: In romstage *both* struct device and device_t are present but are completely different types. It's the romstage, ramstage, and smm overlap that is large and

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure

On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot Test Stand no-re...@raptorengineeringinc.com wrote: The QEMU x86_64 Q35 fails verification as of commit 0a50d9b35334d03f13b38e21497ba0aae8b16712 The following tests failed: ACPI_DSDT_ACCESS_FAILURE

Re: [coreboot] QEMU x86_64 Q35 Automated Test Failure

On Wed, May 13, 2015 at 9:54 AM, Aaron Durbin adur...@google.com wrote: On Wed, May 13, 2015 at 9:02 AM, Raptor Engineering Automated Coreboot Test Stand no-re...@raptorengineeringinc.com wrote: The QEMU x86_64 Q35 fails verification as of commit 0a50d9b35334d03f13b38e21497ba0aae8b16712 The

Re: [coreboot] ASUS KGPE-D16 Automated Test Failure

On Mon, Jan 4, 2016 at 12:19 PM, Raptor Engineering Automated Coreboot Test Stand wrote: > The ASUS KGPE-D16 fails verification as of commit > 77133afe3142096cc7ea7755bfc727f59f2282f9 > > The following tests failed: > CBMEM_TIMESTAMP_ACCESS_FAILURE Why is the

Re: [coreboot] commit messages and their suitability for coreboot.org

On Tue, Dec 22, 2015 at 7:12 PM, Alex G. wrote: > There's a trend I've been noticing about commit messages which is to > follow google's format for everything coreboot. Please stop this. > > Here's why google's format is not suitable in many respects. For the > sake of

Re: [coreboot] Payload that can do mmio32/pciserial UART on x86

On Wed, Nov 18, 2015 at 7:49 PM, Alex G. wrote: > Is there such a payload? Seabios is stuck with IO UARTs. Not sure if > grub can handle it (and if so, how). Depthcharge is out of the question > because it is unbelievably difficult to build outside chromium os's >

Re: [coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

On Fri, Nov 20, 2015 at 7:30 AM, Ben Gardner wrote: > Hi Aaron, > > That patch didn't make a difference that I could see. The console > buffer is still filled with garbage that cbmemc_reinit() copies into > the final buffer. > The issue was also with the timestamps, so

Re: [coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

On Thu, Nov 19, 2015 at 4:07 PM, Ben Gardner wrote: > Hi, > > I've narrowed down where the CBMEM console is getting corrupted and > found a work around that gets it working again. > It is getting corrupted in the FSP Early Init function. So in the > Intel blob, not

Re: [coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

On Thu, Nov 19, 2015 at 4:17 PM, Martin Roth wrote: > Hi Ben, I'm still trying to get to this. I don't know if you saw how > different the fsp cbmem route is from other platforms. The fsp copies the > contents of the car stack to the top of memory when it tears down the cache

Re: [coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

On Sat, Nov 21, 2015 at 10:14 PM, Ben Gardner wrote: > I think I found the issue, but won't be able to test for another week. > > car_get_var_ptr() assumes that the migrated base is the same as > _car_data_start. > On FSP 1.0, that isn't true. _car_data_start is 0x0c00

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

On Fri, Jun 3, 2016 at 7:04 AM, Patrick Rudolph wrote: > Hello, > I want to start a discussion about PCI MMIO size that hit me a couple of > times using coreboot. > I'm focused on Intel Sandybridge, but I guess this topic applies to all > x86 systems. > > On most Intel systems

Re: [coreboot] What purpose this IC(eeprom)?

On Fri, Jun 3, 2016 at 10:35 AM, ron minnich wrote: > Given its name (SPD) it sure seems like SPD. > > As to your not being able to address it, a lot of times this can happen if > there is an SMBUS mux on the board and it's not set up on POR so you can > see that device. >

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

whether to use it? >> >> Has just reserving 2 GiB as a hard and fast rule hurt anyone yet? >> >> thanks >> >> ron >> >> On Fri, Jun 3, 2016 at 11:25 PM Patrick Rudolph <s...@das-labor.org> >> wrote: >>> >>> On 2016-06-0

Re: [coreboot] fmaptool: fmap_config.h: Base offset missing

On Thu, Jun 16, 2016 at 8:55 AM, Rolf Evers-Fischer wrote: > Hello, > my ApolloLake board was not able to find the "romstage" in the SPI memory, > because it searched in the wrong part of the memory. > > ___FMAP__COREBOOT_BASE was set to the relative offset within the

Re: [coreboot] [regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h)

On Mon, Jan 11, 2016 at 7:33 AM, Aaron Durbin wrote: > On Sun, Jan 10, 2016 at 4:40 AM, Paul Menzel > wrote: >> Dear coreboot folks, >> >> >> on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes >> longer to appear. And

Re: [coreboot] [regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h)

On Sun, Jan 10, 2016 at 4:40 AM, Paul Menzel wrote: > Dear coreboot folks, > > > on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes > longer to appear. And looking at the logs board status [1], the time > stamps stored in CBMEM confirm this. >

Re: [coreboot] how to route IRQ4 (COM1) on LPC bus for bayleybay_fsp

On Fri, Jan 15, 2016 at 1:44 PM, benoit wrote: > Hi, > > As explained in my post, I am not using the UART located in the Baytrail > SOC. > I used an SIO for serial line connected to the LPC bus. > So to have the IRQs of these serial lines, I obviuosly need to SERIRQ. >

Re: [coreboot] how to route IRQ4 (COM1) on LPC bus for bayleybay_fsp

On Tue, Jan 12, 2016 at 2:32 PM, benoit wrote: > Hi all, > > I am currently running coreboot + fsp on a E3837 cpu based platform. > My platform has serial line in a LPC device. > Firstly, I activated the SERIRQ in continous mode. SERIRQ has nothing to do w/ COM1. SERIRQ

Re: [coreboot] Linux kernel as payload?

On Sun, Jan 17, 2016 at 9:23 AM, Kitestramuort wrote: > Hello, > I am preparing to flash coreboot on a Thinkpad X230. Currently I use UEFI > and systemd to boot Linux as the only operating system and I wish to change > my configuration as little as possible. The most

Re: [coreboot] Linux kernel as payload?

On Thu, Jan 21, 2016 at 11:49 AM, Kitestramuort <kitestramu...@autistici.org> wrote: > On Thu, 21 Jan, 2016 at 4:08 PM, Aaron Durbin via coreboot > <coreboot@coreboot.org> wrote: >> >> >> >> You can always kexec() into your new kernel. The one sitting in f

Re: [coreboot] How to add an offset at the coreboot creation ?

On Tue, Jan 26, 2016 at 8:49 AM, Jean Francois TRAP wrote: > Hello, > > I have a flash memory 16M. > > I would like coreboot position in the last 256K of memory. address : > 0xFC > > Here is my current coreboot.rom > > > > Coreboot.rom 16384 kB, bootblocksize 18487,

Re: [coreboot] [HEADS-UP] Rebuild cbmem for correct time stamps

On Mon, Mar 14, 2016 at 4:40 PM, Paul Menzel wrote: > Dear coreboot folks, > > > please make sure to rebuild the utility cbmem with commit 08e920e5 > (util/cbmem: Scale time stamp values correctly) [1]. There was a > regression present for some months, causing

Re: [coreboot] coreboot convention, june 13-16, san francisco

On Sun, Apr 10, 2016 at 1:07 PM, ron minnich wrote: > This is a reminder about some details of the upcoming coreboot convention. > > Early registration ends May 15, and registration costs will be higher past > that date. What is the process for registering? > > We've been

Re: [coreboot] coreboot specific ACPI table

On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer <stefan.reina...@coreboot.org> wrote: > 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 ramo

Re: [coreboot] coreboot specific ACPI table

On Sun, Apr 24, 2016 at 5:02 PM, Peter Stuge <pe...@stuge.se> wrote: > Aaron Durbin via coreboot wrote: >> I feel like we likely want to define a ACPI table which has the >> coreboot specific data we care about: >> 1. coreboot tables base address and size. > > Yes,

Re: [coreboot] coreboot specific ACPI table

On Fri, Apr 22, 2016 at 2:38 PM, ron minnich <rminn...@gmail.com> wrote: > Wait, I thought it had to be 4 characters. Yes. I cannot count. :/ CRBT > > ron > > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot > <coreboot@coreboot.org> wrote: >> >&g

Re: [coreboot] coreboot specific ACPI table

. I cannot count. :/ CRBT >> > >> > ron >> > >> > On Fri, Apr 22, 2016 at 2:36 PM Aaron Durbin via coreboot >> > <coreboot@coreboot.org> wrote: >> >> >> >> On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie <dlau...@chromium.or

Re: [coreboot] coreboot specific ACPI table

On Fri, Apr 22, 2016 at 2:00 PM, Duncan Laurie wrote: > On Tue, Apr 19, 2016 at 6:49 AM, Aaron Durbin wrote: >> >> On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner >> wrote: >> > I think we should only export the coreboot table

Re: [coreboot] Microcode problem with Braswell CPU

On Thu, Apr 28, 2016 at 1:38 AM, Alexander Böcken wrote: > 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

Re: [coreboot] Coreboot ARM

On Fri, Apr 29, 2016 at 5:55 AM, daoud yessine wrote: > Hi > > How bootblock can relocate CBFS to load romstage in ARM SOCs ? > the same thing for romstage to load ramstage and ramstage to load payload ? > what's the name of structure or pointer to refer to it to

Re: [coreboot] coreboot specific ACPI table

On Mon, Apr 25, 2016 at 10:13 AM, Aaron Durbin <adur...@google.com> wrote: > On Fri, Apr 22, 2016 at 9:35 PM, Stefan Reinauer > <stefan.reina...@coreboot.org> wrote: >> On 04/22/2016 02:35 PM, Aaron Durbin via coreboot wrote: >>> 1. coreboot tables base addr

Re: [coreboot] Unable to build coreboot with Intel FSP debug binary on BayleyBay

On Fri, May 6, 2016 at 12:39 AM, Kathappan E wrote: > Hi all, > > > > I am able to build Coreboot with FSP Baytrail release > binary(BAYTRAIL_FSP_GOLD_004_22-MAY-2015.fd). > > > > But I am unable to build with FSP Baytrail debug binary >

Re: [coreboot] coreboot specific ACPI table

in the coreboot table as noted originally. You could just keep bounds in the ACPI table and subsequently parse the entries. That's the base case of "walked to identify those specific entries". > > --vb > > On Mon, Apr 18, 2016 at 8:45 AM, Aaron Durbin via coreboot > &l

Re: [coreboot] coreboot specific ACPI table

On Mon, Apr 18, 2016 at 8:18 PM, ron minnich wrote: > So we would submit new ACPI table types to the standards guys? Could we get > names like > CORE > BOOT > CBFS We just need one table, and we can put whatever we want into it. It's the equivalent of an HPET table, e.g. > >

Re: [coreboot] coreboot specific ACPI table

On Mon, Apr 18, 2016 at 10:17 PM, Julius Werner 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

[coreboot] coreboot specific ACPI table

Hi Folks, There was a CL going around internal to chromium (https://chromium-review.googlesource.com/#/c/339121) to expose the coreboot table address proper through ACPI. However, it was put in the GNVS of a few SoCs. There are different mechanisms for firmware console and ramoops (pstore for

Re: [coreboot] ASUS KGPE-D16 Automated Test Failure [master]

Kyosti, this looks in the area of your recent patches. amdmct_cbmem_store_info: Storing AMDMCT configuration in CBMEM CBFS: 'Master Header Locator' located CBFS at [100100:1fffc0) CBFS: Locating 'cmos_layout.bin' CBFS: Checking offset 0 CBFS: File @ offset 0 size 20 CBFS: Unmatched 'cbfs master

[coreboot] PAYLOAD_SEGMENT_BSS not getting cleared in selfboot.c

Hello, I have a historical question regarding the current selfboot.c implementation surrounding PAYLOAD_SEGMENT_BSS. Documentation/cbfs.txt indicates that PAYLOAD_SEGMENT_BSS should be cleared: "PAYLOAD_SEGMENT_BSS0x20535342 The memory speicfied by the segment should be zeroed" And we

Re: [coreboot] PAYLOAD_SEGMENT_BSS not getting cleared in selfboot.c

On Mon, Jul 11, 2016 at 3:19 PM, Aaron Durbin wrote: > Hello, > > I have a historical question regarding the current selfboot.c > implementation surrounding PAYLOAD_SEGMENT_BSS. > > Documentation/cbfs.txt indicates that PAYLOAD_SEGMENT_BSS should be cleared: > >

Re: [coreboot] Does the 62xx Series Opteron work *securely* without microcode?

On Wed, Jan 25, 2017 at 11:24 AM, Timothy Pearson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/24/2017 10:55 PM, taii...@gmx.com wrote: >> I know the 63xx has a very fatal NMI exploit, but according to the >> libreboot (oh no) website the 62xx

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 9:36 AM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > > Still not enough information. Good luck with your problem. > > I have no problem that you believe to INTEL IOTG 100x more than me. ;-) > That has nothing to do with it. You have not presented enough

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 9:25 AM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > Not possible to share with you the details of my .config, until you > understand that you need to investigate this problem as well. :-) > I'm not sure I understand what you are saying. You are asking

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

On Fri, Feb 24, 2017 at 5:04 AM, wrote: > Yes, this die() is what i mean. Try to get maybe some functionality is i > think better then just stopping there and providing zero functionality. > > I also know, that there is a message when the CPUID is not known. Its about

Re: [coreboot] Dont filter supported CPUs on a mainboard by the CPUID

On Thu, Feb 23, 2017 at 2:39 AM, Nico Huber wrote: > On 23.02.2017 00:07, i1w5d7gf38...@tutanota.com wrote: > >> There is a Filter to stop booting when the CPUID is not in a list of >> supported CPUs. This filter does not make sense in the real world usage. > > It's not a filter.

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 9:08 AM, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > You mean, this one (in *RED*)? > > [user@localhost coreboot]$ cat .config | grep SPI > CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0 > # CONFIG_TPM_ON_FAST_SPI is not set > # CONFIG_SPI_FLASH_INCLUDE_ALL_DRIVERS

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 1:12 AM, Zoran Stojsavljevic wrote: > Hello to community, > > I finally, after 3 days of additional very hard struggle, found out why I > have (while I am in the last stage of building CBFS) nonsense while building > APL-I Coreboot

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 10:18 AM, Zoran Stojsavljevic wrote: > Aaron, > > Not that I am trying to be pest/bad guy. Please, believe me on this. Just > about the simple logic, which SHOULD NOT be deniable! > > I did what I know about Coreboot, hands on, from 3.3 years

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 9:56 AM, Nico Huber wrote: > On 22.02.2017 08:12, Zoran Stojsavljevic wrote: >> Hello to community, >> >> I finally, after 3 days of additional very hard struggle, found out why I >> have (while I am in the last stage of building CBFS) nonsense

Re: [coreboot] [VERY IMPORTANT] Announcement regarding Apollo Lake Coreboot building

On Wed, Feb 22, 2017 at 10:01 AM, Zoran Stojsavljevic wrote: > I can admit my errors: > > This is what I have: > > user@localhost FspBin]$ pwd > /home/user/projects/coreboot/coreboot/APL-I_FSP/ApolloLakeFspBinPkg/FspBin > [user@localhost FspBin]$ ls -al > total 672

Re: [coreboot] Add coreboot storage driver

On Tue, Feb 14, 2017 at 11:56 AM, ron minnich wrote: > Just a reminder about times past. This discussion has been ongoing since > 2000. In my view the questions come down to how much the ramstage does, how > that impacts code complexity and performance, and when the ramstage

Re: [coreboot] Add coreboot storage driver

On Mon, Feb 13, 2017 at 9:32 PM, ron minnich wrote: > andrey, great questions. If you're really concerned about those issues, then > yes, maybe a space sharing solution is the right one. > > I really would rather not see people implementing schedulers at this point. > If we're

Re: [coreboot] Add coreboot storage driver

On Mon, Feb 13, 2017 at 8:43 PM, Andrey Petrov wrote: > Hi, > > On 02/13/2017 12:31 PM, ron minnich wrote: >> >> Another idea just popped up: Performing "background" tasks in udelay() >> / mdelay() implementations ;) >> >> >> that is adurbin's threading model. I

Re: [coreboot] Add coreboot storage driver

On Mon, Feb 13, 2017 at 5:28 PM, Julius Werner wrote: > +1 for preferring a single-core concurrency model. This would be much more > likely to be reusable for other platforms, and much simpler to maintain in > the long run (way less platform-specific details to keep track of

Re: [coreboot] Add coreboot storage driver

On Mon, Feb 13, 2017 at 1:16 PM, Nico Huber wrote: > On 13.02.2017 08:19, Andrey Petrov wrote: >> For example Apollolake is struggling to finish firmware boot with all >> the whistles and bells (vboot, tpm and our friendly, ever-vigilant TXE) >> under one second. > Can you provide

Re: [coreboot] Add coreboot storage driver

On Mon, Feb 13, 2017 at 8:05 AM, Peter Stuge wrote: > Andrey Petrov wrote: >> We are considering adding early parallel code execution in coreboot. >> We need to discuss how this can be done. > > No - first we need to duscuss *if* this should be done. > > >> Nowadays we see

Re: [coreboot] Add coreboot storage driver

On Tue, Feb 14, 2017 at 1:07 PM, Patrick Georgi <pgeo...@google.com> wrote: > 2017-02-14 17:12 GMT+01:00 Aaron Durbin via coreboot <coreboot@coreboot.org>: >> For an optimized bootflow >> all pieces of work that need to be done pretty much need to be closely >&g

Re: [coreboot] Add coreboot storage driver

On Tue, Feb 14, 2017 at 1:06 PM, Nico Huber wrote: > On 14.02.2017 18:56, ron minnich wrote: >> At what point is ramstage a kernel? I think at the point we add file >> systems or preemptive scheduling. We're getting dangerously close. If we >> really start to cross that boundary,

Re: [coreboot] Problem of compiling the new architecture

On Thu, Feb 9, 2017 at 6:49 AM, Maxim Gusev via coreboot wrote: > Hello! > > Please help to solve one problem... > When I am trying to compile the sources of my specific architecture, my > compiler tries to build "src/cpu/x86/lapic/boot_cpu.c". > > "CC

Re: [coreboot] Understand vboot logic to select FW_B

On Wed, Feb 15, 2017 at 11:38 AM, <ttu...@codeaurora.org> wrote: > On 2017-02-15 07:46, Aaron Durbin via coreboot wrote: >> >> On Tue, Feb 14, 2017 at 8:26 PM, <ttu...@codeaurora.org> wrote: >>> >>> >>> Folks, >>> I'm working on core

Re: [coreboot] Understand vboot logic to select FW_B

On Tue, Feb 14, 2017 at 8:26 PM, wrote: > > Folks, > I'm working on coreboot on ARMv8 architecture and recently attempted to > verify FW_B can be selected if FW_A is corrupted. > > In reviewing the code-path through coreboot vboot wrapper and > vboot_reference library I'm

Re: [coreboot] Understand vboot logic to select FW_B

On Wed, Feb 15, 2017 at 3:20 PM, <ttu...@codeaurora.org> wrote: > On 2017-02-15 09:45, Aaron Durbin via coreboot wrote: >> >> On Wed, Feb 15, 2017 at 11:38 AM, <ttu...@codeaurora.org> wrote: >>> >>> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote

Re: [coreboot] Some errors by compiling romstage (I am a newbie)

On Thu, Mar 2, 2017 at 7:24 AM, Maxim Gusev via coreboot wrote: > Hi everbody! > > I have a question. Very hope for your help. > > When I am compiling the romstage there are 2 errors by the linker: > Undefined refference to 'bootmem_add_range' > Undefined refference to

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Wed, Oct 5, 2016 at 6:25 PM, Trammell Hudson wrote: > On Wed, Oct 05, 2016 at 03:19:11PM -0500, Aaron Durbin wrote: >> On Wed, Oct 5, 2016 at 3:08 PM, Trammell Hudson wrote: >> > CBFS: 'Master Header Locator' located CBFS at [a00100:c0) >> > CBFS:

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Wed, Oct 5, 2016 at 1:20 PM, Trammell Hudson wrote: > On Skylake with no verstage and FSP 1.1 there is no car_stage_entry > function, only a weak symbol with an infinite loop in > src/arch/x86/assembly_entry.S, and as a result coreboot hangs after > jumping into the romstage.

Re: [coreboot] Skylake FSP 1.1 without verstage?

On Wed, Oct 5, 2016 at 3:08 PM, Trammell Hudson wrote: > On Wed, Oct 05, 2016 at 01:59:08PM -0500, Aaron Durbin wrote: >> > Does the car stage code exist somewhere else in the tree? >> >> Try this? [...] >> >> -romstage-$(CONFIG_SEPARATE_VERSTAGE) += romstage_after_verstage.S >>

Re: [coreboot] Intel Braswell FSP graphics init

On Tue, Nov 8, 2016 at 11:44 AM, Andreas Galauner wrote: > Hi all, > > I'm currently porting coreboot to a new Board with an Intel Braswell on it. > I finally managed to get to a point where Coreboot wants to load a > payload, so all the basic hardware initialization tasks

Re: [coreboot] Intel Braswell FSP graphics init

On Tue, Nov 8, 2016 at 1:02 PM, Andreas Galauner wrote: > On 08.11.2016 19:07, Aaron Durbin wrote: >> Do you have CONFIG_GOP_SUPPORT enabled? > > Yes. That's enabled. > I can also see a pointer to the VBT data being passed to the FSP and the > data looks valid. > > That's why

Re: [coreboot] Skip CAR setup in FSP?

On Thu, Nov 17, 2016 at 4:32 PM, Mason M <09mmann...@gmail.com> wrote: > Hi coreboot people, > > I noticed the option in soc/intel/skylake/Kconfig called SKIP_FSP_CAR, which > based on the description, it sounds like the intention is to simply skip the > TempRamInit portion of FSP. However, from

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 4:25 PM, Trammell Hudson <hud...@trmm.net> wrote: > On Mon, Dec 12, 2016 at 03:08:53PM -0600, Aaron Durbin via coreboot wrote: >> What about the SSDT? With the patch I think the device is in the SSDT >> -- not DSDT. > > Whups, forgot to include it

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 2:58 PM, Trammell Hudson <hud...@trmm.net> wrote: > On Mon, Dec 12, 2016 at 01:14:58PM -0600, Aaron Durbin via coreboot wrote: >> Can you provide the isal -d dumps of before and after for your board? >> I think in one they'll be in SSDT and the other

Re: [coreboot] Disassembly of coreboot binaries

On Wed, Dec 14, 2016 at 3:11 AM, Chauhan, Himanshu wrote: > Hi, > > I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. > While things were fine a while back, it has stopped working. I see that my > hypervisor can't handle address 0xFC while

Re: [coreboot] TPM device has gone missing

On Mon, Dec 12, 2016 at 1:12 PM, Trammell Hudson wrote: > On Mon, Dec 12, 2016 at 11:37:30AM -0700, Trammell Hudson wrote: >> My x230's TPM has gone missing somewhere between 4.5 and the current head. >> CONFIG_LPC_TPM is still set, but neither coreboot nor the Linux payload >>

Re: [coreboot] Building 4.5 from release sources

On Thu, Jan 5, 2017 at 1:45 PM, Peter Stuge wrote: > Trammell Hudson wrote: >> When I build coreboot 4.5 from the release sources it is necessary >> to download the coreboot-blobs-4.5.tar.xz file and it looks like there >> might be a dependency now on the 3rdparty/vboot tree as

Re: [coreboot] Building 4.5 from release sources

On Thu, Jan 5, 2017 at 3:26 PM, Peter Stuge <pe...@stuge.se> wrote: > Aaron Durbin via coreboot wrote: >> This was discussed around a month ago on #coreboot, iirc. > > That's not really good enough, IMHO. I was providing background on a recent discussion related to the topic

Re: [coreboot] logical error for smm hander in coreboot.

On Tue, Jan 3, 2017 at 6:37 AM, Nico Huber wrote: > Hi Tank, > > On 03.01.2017 04:20, Tang Tank wrote: >> >> Hi all, >> >> >>For smm handler (func smm_handler_start) in >> coreboot/src/cpu/x86/smm/smm_module_handler.c, >> there may be a logical error. >> >>If I

Re: [coreboot] 答复: logical error for smm hander in coreboot.

On Tue, Jan 3, 2017 at 7:39 PM, Tang Tank wrote: > Hi Nico , Aaron, Zoran, > >Thank you for your help! >Smi_sts will been cleared after southbridge_smi_handler runs. >I am working for intel apollake now, need to do a thermal feature named > DTS(Digital

Re: [coreboot] 答复: 答复: logical error for smm hander in coreboot.

On Wed, Jan 4, 2017 at 7:12 PM, Tang Tank wrote: > Hi Nico, > >The MSRs can access and modify at any time. But DTS feature need to done > in smm. >I need to check this msr 0x19b/0x19c and set the trigger temperature > dynamically in smm. > I will set a

Re: [coreboot] Building 4.5 from release sources

On Thu, Jan 5, 2017 at 3:28 PM, Trammell Hudson wrote: > On Thu, Jan 05, 2017 at 06:34:42AM -0700, Trammell Hudson wrote: >> When I build coreboot 4.5 from the release sources it is necessary >> to download the coreboot-blobs-4.5.tar.xz file and it looks like there >> might be a

Re: [coreboot] Disassembly of coreboot binaries

On Mon, Dec 19, 2016 at 9:55 AM, Chauhan, Himanshu wrote: > On Mon, Dec 19, 2016 at 9:09 PM, Aaron Durbin wrote: >> On Sun, Dec 18, 2016 at 11:04 PM, Chauhan, Himanshu >> wrote: >>> On Mon, Dec 19, 2016 at 12:40 AM, Aaron

Re: [coreboot] Disassembly of coreboot binaries

On Sun, Dec 18, 2016 at 11:04 PM, Chauhan, Himanshu wrote: > On Mon, Dec 19, 2016 at 12:40 AM, Aaron Durbin wrote: >> On Sun, Dec 18, 2016 at 9:37 AM, Chauhan, Himanshu >> wrote: >>> Hi Aaron, >>> >>> I figured out the crash.

Re: [coreboot] Disassembly of coreboot binaries

On Sun, Dec 18, 2016 at 9:37 AM, Chauhan, Himanshu wrote: > Hi Aaron, > > I figured out the crash. It wan't because wrong load of the ROM image > (thanks to the nifty post_code which I could trap on IO). I see that > the page fault I am getting is in following code: >

Re: [coreboot] Disassembly of coreboot binaries

On Mon, Dec 19, 2016 at 11:18 AM, Chauhan, Himanshu wrote: > On Mon, Dec 19, 2016 at 10:03 PM, Aaron Durbin wrote: >> On Mon, Dec 19, 2016 at 9:55 AM, Chauhan, Himanshu >> wrote: >>> On Mon, Dec 19, 2016 at 9:09 PM, Aaron

Re: [coreboot] [coreboot-gerrit] Change in coreboot[master]: KBL: Update FSP headers - upgrade to FSP.2.0.0

Why can't I access this CL on gerrit, but I'm getting emails for it? On Tue, Mar 28, 2017 at 10:10 AM, Subrata Banik (Code Review) wrote: > Subrata Banik has posted comments on this change. ( > https://review.coreboot.org/19023 ) > > Change subject: KBL: Update FSP headers

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB

On Thu, Mar 30, 2017 at 4:53 AM, Goetz Salzmann wrote: > Dear Toan, > >> I tried as your suggestion: flashed an 8 MB Intel-provided image, read >> back from SPI chip right after flashing, got a 16 MB file (since SPI >> chip is 16 MB size). >> The first 8 MB of 2 files are

Re: [coreboot] Group demographics

On Tue, Mar 28, 2017 at 3:20 PM, wrote: > On 2017-03-24 17:42, Julius Werner wrote: >>> >>> * Google's recovery manifest (from linux_recovery.sh) can pull a >>> recovery image for a specific product, I have yet to find >>> depthcharge as a payload >>> * Obviously I haven't

Re: [coreboot] Group demographics

On Fri, Mar 24, 2017 at 10:39 AM, wrote: > On 2017-03-24 08:23, ron minnich wrote: >> >> On Fri, Mar 24, 2017 at 8:14 AM wrote: >> >>> Q.1) Are questions related to Coreboot + Payload that boots a >>> Chromebook >>> appropriate for this list or a

  1   2   >