Hi Ben.
Alternatively you can use your own flash map setup file where you modify
FMAP_FMAP_SIZE to your needs and point Kconfig to your modified fmd-file.
In this way you can leave Makefile.inc unchanged and get your image right as
well.
Werner
-Ursprüngliche Nachricht-
Von: coreboot
Hi Stefan.
I have updated my toolchain and use it now without any issues for
siemens/mc_tcu3.
Werner
-Ursprüngliche Nachricht-
Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von Stefan
Reinauer
Gesendet: Donnerstag, 21. April 2016 21:19
An: coreboot@coreboot.org
Hey Martin.
I have tested the mainboard siemens/mc_tcu3 with commit-ID
b3ee03c404e0a26dc338a26f7ce01ddb8dafaaec
and haven't found any issues. So consider this board as working for the
upcoming release.
Werner
-Ursprüngliche Nachricht-
Von: coreboot
>Does git commit --no-verify (or -n for short) allow you to commit?
>
Yes, one can go this way and I did it already earlier. But I just wanted to
point it out here.
We do not need a check script for every commit if we simply disable the check
when it comes to issues.
I wanted to start this
Hi community.
I recently ran into a blocked commit due to warnings reported by checkpatch.pl.
In this particular case I wanted to add the "ATSR" structure to the DMAR
tables. To do that, I need to define a new structure
which reflects the per specification needed layout of this table entry.
I
Hi Gailu.
I don't think that one can configure the xHCI to behave like an EHCI so that
GRUB2 can natively support it.
xHCI has different version number in the PCI space which will prevent the EHCI
driver in GRUB2 to use this controller at all.
Not speaking about the complete different register
Hi Toan.
On BeeProg you can select the offset inside the flash where your image should
be loaded to.
Just have a look at the lower section in your "load file" dialog box. There is
an entry called "Buffer offset for loading".
Select positive offset for binary formats and set to 8 MB. That will
杜睿哲_Pegatron) [mailto:hilbert...@pegatroncorp.com]
> Gesendet: Donnerstag, 11. Januar 2018 04:32
> An: Zeh, Werner (DF MC MTS R HW 1); coreboot@coreboot.org
> Cc: David Hendricks; Leo5 Huang(黃儀祥_Pegatron); Zoran Stojsavljevic
> Betreff: RE: [coreboot] BDX-DE PCI init fail
>
> Hi We
Hi Ian.
> Ian Lewis wrote:
> I do have one question: You clearly have no issue for your compliance. But,
> do you tell your OEM customers that they need to provide the GPL license to
> their customers as part of their product packaging,
We do have a sticker on each component which tells that
Hi Hilbert.
It might be nothing but if I have a look at your last attached log I can't see
SeaBIOS finding any USB devices. There is just one Error mentioned:
>ehci_wait_td error - status=80e42
So what is special with SeaBIOS and Broadwell-DE: you have to unset the config
switch called
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
Hey guys.
I have followed the discussion now for a while in the background. It seems to
be the time to step in.
For those of you who do not know me: My name is Werner Zeh and I am working for
Siemens AG.
I am an active coreboot developer for a few years now working on x86 systems,
most of the
> Arthur proposed making a number of features mandatory so that the bootflow
> becomes more
> predictable across chipsets and boards. Mandatory features imply that
> chipsets or boards that
> can't comply to these new requirements for whatever reason will be dropped.
> There was no
> decision
Sounds good to me, too.
Then we finally will avoid forgetting the CONIFG_ prefix.
Werner
> -Ursprüngliche Nachricht-
> Von: Patrick Rudolph
> Gesendet: Mittwoch, 6. März 2019 08:26
> An: Julius Werner ; Coreboot
> Betreff: [coreboot] Re: RFC: Replacing IS_ENABLED(CONFIG_XXX) with the
I had once a very similar case on Baytrail or Broadwell at the very beginning.
The root cause in my case was that walkcbfs was not able to find the next stage
(romstage IIRC) because the SPI flash address was not mapped properly into MMIO
space.
Check the size of your flash in Kconfig and the
Hi Ron.
For me the reason of decreasing the log level is boot time and not flash size.
As we dump the log over the slow UART, a default log level of 7 or even 8 would
mean several more seconds of boot time.
In the past I had thought a few times about it and had the idea of separating
CBMEM log
I agree Ron, there is no need of a debug build. It should be just one build.
Werner
> -Ursprüngliche Nachricht-
> Von: ron minnich [mailto:rminn...@gmail.com]
> Gesendet: Montag, 11. Februar 2019 16:20
> An: Zeh, Werner (DF MC MTS R HW 1)
> Cc: Zvi Vered; Gregg Levine; cor
Currently with the one CBFS containing all files it is easy and simple to
access every file in every stage.
Wouldn't this be harder if we chose to split the CBFS into several, stand-alone
CBFSes?
Or, on the other hand, wouldn't we end up in duplicating CBFS files just to
have them around handy?
Looks like console.h was removed in
https://review.coreboot.org/c/coreboot/+/32214
We had a few such "accidents" in the past few days.
@Elyes: want to fix?
Werner
-
Hi,
Before I dig in without knowing
Hi Peter.
> Does the coreboot code communicate something to the OS driver already?
Yes, there is an ACPI entry which reports current timings in
dw_i2c_acpi_write_speed_config() [1].
This code used to provide a report for all available speeds but was changed in
[2]. Though I am not sure how
Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in
src/drivers/i2c/designware.
It is used across multiple platforms and has a quite good configurability from
mainboard side. One can tweak everything needed and make it work with the
needed timing easily.
can be tuned, or add a
custom
module to our payload (depthcharge) to allow tuning these values in the CLI.
-Tim
On Tue, Apr 27, 2021 at 3:01 AM Zeh, Werner <mailto:werner@siemens.com>
wrote:
Hi everybody.
We do have a driver for a widely used I2C-controller from Designware in
src/dr
Hi Patrick, Arthur.
We do have a use case in our self-crafted linux where the CBFS master header is
used.
I need to dig into the code and find out what needs to be done there in order
to get rid of this dependency while still not break it for older builds.
Werner
Hi Tim.
CB:34385 does not break anything for me because we just use STANDARD speed in
our system. It just came to my attention once I had a deeper look at the driver
and its evolvement. I just wanted to mention that there are cases where the
calculated and reported timing can be suitable for a
Hi Nico.
I fully can understand your point of view in this discussion. Unfortunately, we
do live in a real world with real companies that are business-driven.
With this sidenote in context the world changes dramatically in this regard.
Your request for an early discussion whether this or that
Dear coreboot community.
As you know we are currently in discussion with Intel to get the PSE and its
documentation on the Elkhart Lake SoC publicly available.
Intel have now released some docs in this regard which can be accessed freely
(see [1] and [2]). Feel free to use them as your use
Dear coreboot community.
I guess the most of you have seen the tension that was introduced to the
community once Intel started to enable the Programmable Service Engine on
the new IOTG SoC called Elkhart Lake (for reference, please see [1]).
One of the outcome of this difficulties was to
urrently not sure about are the static buffers and how they will
work in bootblock
Werner
> -Original Message-
> From: Samek, Jan
> Sent: Thursday, July 22, 2021 6:15 PM
> To: coreboot@coreboot.org
> Cc: Zeh, Werner
> Subject: GDB stub & bootblock dependencie
Hi Dubravko.
> 2) We have enabled CAN controllers in devicetree.cb:
>device pci 18.1 on end # Intel
> Programmable Services Engine CAN0
>device pci 18.2 on end # Intel
> Programmable Services Engine CAN1
> ... but in
Hi everybody.
It has been a while now that we started the open letter to Intel regarding
open-sourcing the PSE firmware.
I am now happy to announce that all this effort was not worthless!
Intel pushed the PSE firmware sources yesterday to github [1]!
A big "Thank You!" to all the supporters of
> From: Jay Talbott
> Sent: Saturday, April 23, 2022 8:07 PM
> To: 'ron minnich' ; Zeh, Werner (DI MC MTS SP HW 1)
> Cc: 'coreboot'
> Subject: RE: [coreboot] Re: Open letter to Intel regarding the PSE on
Elkhart Lake
>
> Yes, nice job Werner!
>
> Since you've been wor
nk you all for supporting this.
Werner
[1]
https://openletter.earth/thank-you-for-opening-the-source-code-for-the-pse-o
n-elkhart-lake-005543c7
> -Original Message-----
> From: Zeh, Werner
> Sent: Friday, April 22, 2022 7:24 AM
> To: coreboot
> Subject: [coreboot] Re: Open
Dear coreboot community.
According to our schedule for releases we are a bit behind now and therefore
we would like to announce that the next release will happen in two weeks
from now on 5th October 2022.
So please test the current tree as much as you can do and avoid introducing
new heavy
33 matches
Mail list logo
