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

[Zeh, Werner]

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 load your 
8 MB image into the upper portion of the buffer
and hence your image will be flashed to the upper flash address range.

In regard to the Winbond flash we had issues that has shown the same behavior 
like your case.
The root cause in our case was the "security register" called region in the 
flash which resides above the 16 MB address range and
has a size of 0x300 bytes (on W25Q128FV for example). The original flash 
contents on the CRB contains some data
in that region and we were only able to boot the CRB after re-flashing if this 
region was transferred to the new flash completely.
To do so, you must tweak BeeProg a bit, there are special options to erase and 
program this security registers.

If you use a different flash type like N25Q128Ax1E, this issue is not visible 
because this flash type does not have
the security registers the Winbond one has. It seems like CSE checks the used 
flash type and uses different boot paths inside.

I hope that helps.
Werner

>Dear Goetz,
>
>Thanks for your reply. I'm trying to rebuild the image.
>Another question here: I had an 8 MB Intel-provided image. I'm using BeeProg2C 
>flashing device (with PG4UW software).
>Is there any "trick" forcing the flashing device to flash 8 MB image into 16 
>MB SPI chip? Something likes flash to the low-8MB of chip instead of high-8MB?


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Zeh, Werner]

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 this component contains 
open source software and how to find the details on the component. Further we 
have a chapter in the end-user manual which describes all the details about 
open source software and the licenses. This manual will be handed over to the 
end-customer by the OEM.

> Peter Stuge wrote:
> Please consider the risk associated with offloading distribution of source 
> code to a third party, be it upstream or anyone else.
Of course we keep the exact copy of the source code for every single release 
version internally. So we have any time the ability to provide the code by 
ourselves. And our customers are aware of this.
The upstream repo is just the first place to get the code from.

Werner



> Peter Stuge wrote:
> > Consider Section 3 a) "on a medium customarily used for software 
> > interchange" - a Control Panel snap-in arguably isn't such a
> medium.
> > What specific interface to use for delivery of source code probably depends 
> > on how your product works, and what you want to enable
> your customers to offer.
> Peter Stuge wrote:
> > Unlike David I'm not so sure about this. Requiring a special software to 
> > access the source code IMO does not satisfy "medium
> customarily used for software interchange" - while a virtual CD-ROM would, if 
> your product connects via USB in normal operation.
> > The Control Panel idea may be a good way to help your customers with being 
> > compliant, but I don't think it's very good for your own
> compliance, if that makes sense?
> Peter Stuge wrote:
> >Lewis, Ian (Microstar Laboratories) wrote:
> >> Still, the more I look at this, the more it sounds like we would meet
> >> our obligations if we provide an About tab in our control panel
> >> application...
> 
> > Mh - again, I don't think that's cool.
> 
> Would you consider this true - for our compliance - if we put a piece of 
> paper in the box that told you where to find the source code
> from your measurement device? If this point about the medium on which the 
> user obtains the source code is critical, then this option is
> probably not a good solution for us. But, I am still curious whether you 
> would consider us compliant if we had a piece of paper in the
> box that told the user that the source code for the Coreboot/SeaBIOS (if we 
> use SeaBIOS) firmware in their measurement instrument is
> available by opening our Control Panel application, going to the About tab, 
> and clicking the Get Firmware Source button (say).
> 
> I will note that it is impossible to use our device in any way unless our 
> driver and server are installed, the basic version of which is
> available to anyone for download from our web site. And, the installation of 
> these components always installs the Control Panel
> application. So, even if an OEM were to pre-configure a system with our 
> hardware, the Control Panel application would always be
> available to all potential users of our device.
> 
> Peter Stuge wrote:
> > Sorry, I wasn't clear enough. I meant to refer to flash memory which is 
> > *somehow* accessible via USB - but not neccessarily in the
> form of a "removable drive". A much better "look" would be a virtual CD-ROM, 
> which are per definition read-only.
> 
> I fully understood what you said in your original message. My point remains: 
> if we provide a virtual CD-ROM - which I still consider a
> "removable drive" even if it is read only - then plugging in our device, 
> which has nothing to do with a drive of any kind, you suddenly
> have a new drive letter taken under Windows for no obvious reason (for most 
> users). Taking up a drive letter can really mess things up
> for a user if they assume that letter is free for use, for example to attach 
> to a network share when they log into a network.
> 
> Of course, you do gain the nice feature that Windows will pop up a box on 
> first use telling you the new drive showed up. And, that
> would give you something that lets a user know something is going on that 
> might need their attention. And, as you say, a CD-ROM is
> clearly a " medium customarily used for software interchange".
> 
> Peter Stuge wrote:
> > This is actually quite common with USB cellphone network modems and with 
> > some other USB-connected devices as well.
> 
> Yes. We know how to do this, though I am not overly enthusiastic about 
> implementing it. I do not know much about USB cellphone
> modems, but it seems like the drive might make some sense to the user in this 
> case. It certainly does when you plug in a cell phone
> since the cell phone has storage you want to be able to access. With our 
> device, it would just be a spurious drive in most real
> installations. Of cours

Re: [coreboot] BDX-DE PCI init fail

[Zeh, Werner]

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 "CONFIG_MALLOC_UPPERMEMORY" in SeaBIOS config.
With this option set SeaBIOS has issues with USB on Broadwell-DE. It might help 
you, just check it and give it a try if not unset already.

Werner

> -Ursprüngliche Nachricht-
> Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von Zoran 
> Stojsavljevic
> Gesendet: Mittwoch, 10. Januar 2018 05:57
> An: Hilbert Tu(杜睿哲_Pegatron)
> Cc: Werner Zeh; David Hendricks; coreboot@coreboot.org; Leo5 
> Huang(黃儀祥_Pegatron)
> Betreff: Re: [coreboot] BDX-DE PCI init fail
> 
> > grub>
> 
> Yup, you have reached the GRUB2 shell. I have no idea what the underlying 
> system is yuo have done this? UEFI or Legacy?
> 
> If UEFI, this USB will NOT work for Coreboot + SeaBIOS. If Legacy, then I 
> have no idea why it does not work (it should)!?
> 
> If UEFI, then you might reconsider https://rufus.akeo.ie/ (5 minutes job to 
> create Legacy bootable USB):
> [1] Partition scheme MBR used on BIOS;
> [2] File System probably FAT32 (should work).
> 
> Good Luck!
> Zoran
> ___
> 
> On Wed, Jan 10, 2018 at 2:49 AM, Hilbert Tu(杜睿哲_Pegatron)
>  wrote:
> > Hi Zoran,
> >
> > I have my USB stick formatted with ext4fs and I am pretty sure the image 
> > inside is bootable.
> > What I mean to get a prompt shell is like following so that I can specify 
> > my commands.
> >
> > grub> linux (usb0,1)/bzImage console=ttyS1,115200 console=tty1
> > grub> root=/dev/ra
> > m ramdisk_size=102400
> > grub> initrd (usb0,1)/core-image-minimal-initramfs-mohonpeak64.cpio.gz
> > grub> boot
> >
> > But right now it just hangs there and I am looking into GIPO settings
> > or maybe I have some wrong settings in ACPI table:(
> >
> > -Hilbert
> >
> > This e-mail and its attachment may contain information that is confidential 
> > or privileged, and are solely for the use of the individual to
> whom this e-mail is addressed. If you are not the intended recipient or have 
> received it accidentally, please immediately notify the
> sender by reply e-mail and destroy all copies of this email and its 
> attachment. Please be advised that any unauthorized use,
> disclosure, distribution or copying of this email or its attachment is 
> strictly prohibited.
> > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件
> > 通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
> --
> coreboot mailing list: coreboot@coreboot.org 
> https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[Zeh, Werner]

Hi Hilbert.

> The SeaBIOS .config is always been reset when I recompile the coreboot. I am 
> trying to figure out how to avoid that.

Just cd into the seabios-folder and make menuconfig. Save your config after 
modification. Now copy the resulting .config file somewhere (your coreboot 
directory for example).
Now make menuconfig for coreboot and here, if you have selected SeaBIOS as 
payload, you can provide a .config file for SeaBIOS. Add the path to the saved 
.config file from SeaBIOS and you are good to go.

Werner


> -Ursprüngliche Nachricht-
> Von: Hilbert Tu(杜睿哲_Pegatron) [mailto:hilbert...@pegatroncorp.com]
> Gesendet: Donnerstag, 11. Januar 2018 04:32
> An: Zeh, Werner (DF MC MTS R&D HW 1); coreboot@coreboot.org
> Cc: David Hendricks; Leo5 Huang(黃儀祥_Pegatron); Zoran Stojsavljevic
> Betreff: RE: [coreboot] BDX-DE PCI init fail
> 
> Hi Werner,
> 
> The SeaBIOS .config is always been reset when I recompile the coreboot. I am 
> trying to figure out how to avoid that.
> 
> Hi Zoran,
> 
> I did not get grub2 prompt shell so I cannot do anything. I don't use UEFI or 
> Legacy. I just use grub2 as coreboot's payload and if there
> is a shell prompt, then I can bring my linux kernel up.
> 
> -Hilbert
> 
> -Original Message-
> From: Zeh, Werner [mailto:werner@siemens.com]
> Sent: Wednesday, January 10, 2018 1:34 PM
> To: Hilbert Tu(杜睿哲_Pegatron); coreboot@coreboot.org
> Cc: David Hendricks; Leo5 Huang(黃儀祥_Pegatron); Zoran Stojsavljevic
> Subject: AW: [coreboot] BDX-DE PCI init fail
> 
> 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 "CONFIG_MALLOC_UPPERMEMORY"
> in SeaBIOS config.
> With this option set SeaBIOS has issues with USB on Broadwell-DE. It might 
> help you, just check it and give it a try if not unset already.
> 
> Werner
> 
> > -Ursprüngliche Nachricht-
> > Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von
> > Zoran Stojsavljevic
> > Gesendet: Mittwoch, 10. Januar 2018 05:57
> > An: Hilbert Tu(杜睿哲_Pegatron)
> > Cc: Werner Zeh; David Hendricks; coreboot@coreboot.org; Leo5
> > Huang(黃儀祥_Pegatron)
> > Betreff: Re: [coreboot] BDX-DE PCI init fail
> >
> > > grub>
> >
> > Yup, you have reached the GRUB2 shell. I have no idea what the underlying 
> > system is yuo have done this? UEFI or Legacy?
> >
> > If UEFI, this USB will NOT work for Coreboot + SeaBIOS. If Legacy, then I 
> > have no idea why it does not work (it should)!?
> >
> > If UEFI, then you might reconsider https://rufus.akeo.ie/ (5 minutes job to 
> > create Legacy bootable USB):
> > [1] Partition scheme MBR used on BIOS; [2] File System probably FAT32
> > (should work).
> >
> > Good Luck!
> > Zoran
> > ___
> >
> > On Wed, Jan 10, 2018 at 2:49 AM, Hilbert Tu(杜睿哲_Pegatron)
> >  wrote:
> > > Hi Zoran,
> > >
> > > I have my USB stick formatted with ext4fs and I am pretty sure the image 
> > > inside is bootable.
> > > What I mean to get a prompt shell is like following so that I can specify 
> > > my commands.
> > >
> > > grub> linux (usb0,1)/bzImage console=ttyS1,115200 console=tty1
> > > grub> root=/dev/ra
> > > m ramdisk_size=102400
> > > grub> initrd
> > > grub> (usb0,1)/core-image-minimal-initramfs-mohonpeak64.cpio.gz
> > > grub> boot
> > >
> > > But right now it just hangs there and I am looking into GIPO
> > > settings or maybe I have some wrong settings in ACPI table:(
> > >
> > > -Hilbert
> > >
> > > This e-mail and its attachment may contain information that is
> > > confidential or privileged, and are solely for the use of the
> > > individual to
> > whom this e-mail is addressed. If you are not the intended recipient
> > or have received it accidentally, please immediately notify the sender
> > by reply e-mail and destroy all copies of this email and its attachment. 
> > Please be advised that any unauthorized use, disclosure,
> distribution or copying of this email or its attachment is strictly 
> prohibited.
> > > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆
> > > 郵件
> > > 通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Broadwell-DE hang in coreboot: mp_init.c

[Zeh, Werner]

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-boun...@coreboot.org] Im Auftrag von mark pleso 
>via coreboot
>Gesendet: Montag, 26. Februar 2018 23:40
>An: coreboot@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);
>}

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Default-timings in Designware I2C driver

[Zeh, Werner]

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.
Though I stumbled lately across a thing I wouldn't expect the way it is.

It is possible to define the speed one needs to operate the I2C bus on in 
devicetree by setting the .speed-value to one of the supported defines 
(I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or 
I2C_SPEED_FAST_ULTRA), e.g.:

register "common_soc_config" = "{
.i2c[0] = {
.speed = I2C_SPEED_STANDARD
 }
}"

If one just sets the .speed value, the driver will take care about the needed 
SCL clock rate and set it up to a default value. Yes, these values might be not 
the best for the current bus load but should at least provide a clock that 
matches the requested speed. 
This default values are defined in src/drivers/i2c/designware/dw_i2c.c as 
follows:
/* High and low times in different speed modes (in ns) */
enum {
/* SDA Hold Time */
DEFAULT_SDA_HOLD_TIME   = 300,
/* Standard Speed */
MIN_SS_SCL_HIGHTIME = 4000,
MIN_SS_SCL_LOWTIME  = 4700,
/* Fast Speed */
MIN_FS_SCL_HIGHTIME = 600,
MIN_FS_SCL_LOWTIME  = 1300,
/* Fast Plus Speed */
MIN_FP_SCL_HIGHTIME = 260,
MIN_FP_SCL_LOWTIME  = 500,
/* High Speed */
MIN_HS_SCL_HIGHTIME = 60,
MIN_HS_SCL_LOWTIME  = 160,
};

While these values do match the needed _minimum_ durations for the high and low 
period of the SCL signal according to the I2C-specification [1], they are not 
enough for the overall clock cycle to match the requested speed. Let's take 
standard speed for example:

MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs 
==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 
114,943 kHz instead of 100 kHz
The same applies to the other speeds as well.

As the driver is aware of the clock the IP is clocked with inside the 
Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. 
There is code already which computes the needed counter values for high and low 
period from the provided IP-clock, *LOWTIME and *HIGHTIME in 
dw_i2c_gen_speed_config():
...
if (speed >= I2C_SPEED_HIGH) {
/* High speed */
hcnt_min = MIN_HS_SCL_HIGHTIME;
lcnt_min = MIN_HS_SCL_LOWTIME;
} else if (speed >= I2C_SPEED_FAST_PLUS) {
/* Fast-Plus speed */
hcnt_min = MIN_FP_SCL_HIGHTIME;
lcnt_min = MIN_FP_SCL_LOWTIME;
} else if (speed >= I2C_SPEED_FAST) {
/* Fast speed */
hcnt_min = MIN_FS_SCL_HIGHTIME;
lcnt_min = MIN_FS_SCL_LOWTIME;
} else {
/* Standard speed */
hcnt_min = MIN_SS_SCL_HIGHTIME;
lcnt_min = MIN_SS_SCL_LOWTIME;
}
config->speed = speed;
config->scl_hcnt = ic_clk * hcnt_min / KHz;
config->scl_lcnt = ic_clk * lcnt_min / KHz;
config->sda_hold = ic_clk * DEFAULT_SDA_HOLD_TIME / KHz;
...

I tend to change the high and low values (MIN_{SS,FS,FPHS}_SCL_{HIGH,LOW}TIME) 
to match the needed minimum constraints while still fulfilling the overall 
clock cycle, e.g. by increasing the HIGHTIME.
But I would like to hear other opinions on that. Surely I am not aware of all 
the use cases out there.

And again: These default values can easily be overridden in the devicetree with 
something like this:
register "common_soc_config" = "{
.i2c[0] = {
.speed = I2C_SPEED_STANDARD,
.speed_config[0] = {
.speed = I2C_SPEED_STANDARD,
.scl_lcnt = 664,
.scl_hcnt = 657, /*This value is smaller due to the IP 
adding a count of 8 internally, see [2]*/
.sda_hold = 39
}
},
}"

But I would expect the driver to do it right in the default configuration.

Any input is highly welcome.

Werner

[1] https://www.nxp.com/docs/en/user-guide/UM10204.pdf
[2] 
https://dokumen.tips/documents/designware-dw-apb-i2c-databook-pudn-designware-dwapbi2c-databook-preface-preface.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Default-timings in Designware I2C driver

[Zeh, Werner]

In the meantime Kyösti provided a patch [1] where the clock timing is computed 
based on rise and fall times in the default case.
This results in a much more accurate timings which I was able to measure on 
mb/siemens/mc_apl6

Nevertheless, looking closer to the driver implementation, a few odds are in 
there.
First, the values 7 and 1 [2] (which actually should be 8 and 1 according to 
the Synopsis specification) are completely uncommented and therefore hard to 
understand from somebody without the specification in mind.
In addition, I still have not fully understood why the spike rejection counter 
value is subtracted from the count value for the high period as it is not 
described that way in the specification.

Further on, we easily can run into issues if the OS decides to switch the bus 
frequency from <= FULL_SPEED_PLUS to HIGH_SPEED on some platforms as e.g. on 
Apollo Lake there is a stronger output driver enabled internally for HIGH_SPEED 
mode which significantly changes the rise and fall times. So maybe the earlier 
implementation, where we had a set of parameters reported in ACPI for every 
implemented bus speed (removed with [3]), was not so bad in this regard.

Werner

[1] https://review.coreboot.org/c/coreboot/+/52723
[2] 
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/drivers/i2c/designware/dw_i2c.c#579
[3] https://review.coreboot.org/c/coreboot/+/34385


Von: Tim Wawrzynczak  
Gesendet: Dienstag, 27. April 2021 23:01
An: werner@siemens.com
Cc: coreboot 
Betreff: Re: [coreboot] Default-timings in Designware I2C driver

Hi Werner,

I agree we could probably do a little better than we do today (feel free to 
submit a patch ;)),
but speaking for what I have seen on bringing up Chrome OS devices, the ODMs 
ultimately 
end up having to tweak these values depending on the board design (bus load, 
etc.); e.g.

```
$
 git grep 'scl_lcnt' -- src/mainboard/google/*.cb | wc -l
72
```

One idea we've had is to implement a sysfs interface in the Linux kernel to 
expose
a way to change these registers at runtime, so they 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/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.
Though I stumbled lately across a thing I wouldn't expect the way it is.

It is possible to define the speed one needs to operate the I2C bus on in 
devicetree by setting the .speed-value to one of the supported defines 
(I2C_SPEED_STANDARD, I2C_SPEED_FAST, I2C_SPEED_FAST_PLUS, I2C_SPEED_HIGH or 
I2C_SPEED_FAST_ULTRA), e.g.:

register "common_soc_config" = "{
        .i2c[0] = {
                .speed = I2C_SPEED_STANDARD
                 }
        }"

If one just sets the .speed value, the driver will take care about the needed 
SCL clock rate and set it up to a default value. Yes, these values might be not 
the best for the current bus load but should at least provide a clock that 
matches the requested speed. 
This default values are defined in src/drivers/i2c/designware/dw_i2c.c as 
follows:
/* High and low times in different speed modes (in ns) */
enum {
        /* SDA Hold Time */
        DEFAULT_SDA_HOLD_TIME   = 300,
        /* Standard Speed */
        MIN_SS_SCL_HIGHTIME     = 4000,
        MIN_SS_SCL_LOWTIME              = 4700,
        /* Fast Speed */
        MIN_FS_SCL_HIGHTIME     = 600,
        MIN_FS_SCL_LOWTIME              = 1300,
        /* Fast Plus Speed */
        MIN_FP_SCL_HIGHTIME     = 260,
        MIN_FP_SCL_LOWTIME      = 500,
        /* High Speed */
        MIN_HS_SCL_HIGHTIME     = 60,
        MIN_HS_SCL_LOWTIME      = 160,
};

While these values do match the needed _minimum_ durations for the high and low 
period of the SCL signal according to the I2C-specification [1], they are not 
enough for the overall clock cycle to match the requested speed. Let's take 
standard speed for example:

MIN_SS_SCL_HIGHTIME = 4,0 us, MIN_SS_SCL_LOWTIME = 4,7 µs 
        ==> MIN_SS_SCL_HIGHTIME + MIN_SS_SCL_LOWTIME = 8,7 µs which equals to 
114,943 kHz instead of 100 kHz
The same applies to the other speeds as well.

As the driver is aware of the clock the IP is clocked with inside the 
Chipset/SoC (CONFIG_DRIVERS_I2C_DESIGNWARE_CLOCK_MHZ), it can be done right. 
There is code already which computes the needed counter values for high and low 
period from the provided IP-clock, *LOWTIME and *HIGHTIME in 
dw_i2c_gen_speed_config():
...
if (speed >= I2C_SPEED_HIGH) {
        /* High speed */
        hcnt_min = MIN_HS_SCL_HIGHTIME;
        lcnt_min = MIN_HS_SCL_LOWTIME;
} else if (speed >= I2C_SP

[coreboot] Re: Dropping the "cbfs master header" file

[Zeh, Werner]

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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Default-timings in Designware I2C driver

[Zeh, 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 given speed in coreboot 
and a speed switch to HIGH in OS (which can be done since the controller 
supports it and a very similar driver is used at OS-side) will lead to a 
different timing, worse case not matching the hardware circumstances and 
therefore ending up in violating the I2C spec.

Werner
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Default-timings in Designware I2C driver

[Zeh, Werner]

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 much of the information would be used by the 
kernel driver at all. But at least a valid reporting should be something 
coreboot delivers. The rest is up to the driver.

Werner

[1]: 
https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/drivers/i2c/designware/dw_i2c.c#750
[2]: https://review.coreboot.org/c/coreboot/+/34385
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: GDB stub & bootblock dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)

[Zeh, Werner]

Hi Jan.

The problem here is that the needed functions for GDB in console are not 
included in bootblock. In src/console/console.c you can see:

#if CONFIG(GDB_STUB) && (ENV_ROMSTAGE || ENV_RAMSTAGE)
void gdb_hw_init(void)
{
__gdb_hw_init();
}

void gdb_tx_byte(unsigned char byte)
{
__gdb_tx_byte(byte);
}

void gdb_tx_flush(void)
{
__gdb_tx_flush();
}

unsigned char gdb_rx_byte(void)
{
return __gdb_rx_byte();
}
#endif

In order to overcome this please give the attached patch a try. At least on my 
side it is able to compile with that patch.
What I am currently 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 dependencies (CONFIG_IDT_IN_EVERY_STAGE=y)
> 
> Hello,
> 
> I am currently developing on Intel TGLRVP-UP3, but this should be relevant for
> other TGL-based platforms and possibly all other that set
> CONFIG_IDT_IN_EVERY_STAGE=y:
> 
> When I try to use the GDB stub for my debug attempts on TGL
> (CONFIG_GDB_STUB=y), I get the following 'undefined reference' errors during
> the bootblock linkage process:
> 
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:225: undefined reference to `gdb_tx_byte'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:230: undefined reference to `gdb_tx_flush'
> src/arch/x86/exception.c:235: undefined reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: 
> undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: 
> undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: 
> undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:225: 
> undefined
> reference to `gdb_tx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: 
> undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: 
> undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: 
> undefined
> reference to `gdb_rx_byte'
> util/crossgcc/xgcc/bin/i386-elf-ld.bfd: src/arch/x86/exception.c:235: 
> undefined
> reference to `gdb_rx_byte'
> 
> The gdb_*() functions used in exception.c are defined in 
> src/console/console.c.
> Nevertheless, the problem with the functions in question is that they're 
> defined
> under '#if CONFIG(GDB_STUB) && (ENV_ROMSTAGE || ENV_RAMSTAGE)' which
> obviously doesn't allow them to be compiled into the bootblock code while
> they're unconditionally (there's only the IDT_IN_EVERY_STAGE condition)
> referenced in exception.c
> 
> Looking at src/arch/x86/Makefile.inc (filtering out only the lines of 
> interest), it's
> apparent that exception.c is linked in all stages when the IDT_IN_EVERY_STAGE
> option is set:
> 
> 76:  bootblock-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 111: verstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 148: romstage-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 187: postcar-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 229: ramstage-y += exception.c
> 291: smm-$(CONFIG_IDT_IN_EVERY_STAGE) += exception.c
> 
> The behavior appears in revision
> b90aba43c1405d3d2cb7cba05e68906e979dcda3 (master).
> 
> To reproduce,
> - run 'make menuconfig',
> - select 'Mainboard ->Mainboard Vendor': 'Intel',
> - select 'Mainboard -> Mainboard Model': 'Tiger Lake UP3 RVP',
> - select 'Debugging -> GDB debugging support': 'y'.
> - run 'make'.
> 
> What do you think would be the best approach to make the GDB stub work on
> these platforms?
> 
> P.S. My bug tracker registration is currently pending an approval, I could be 
> able
> to create a ticket afterwards.
> 
> Regards,
> Jan


gdb_stub_in_bootblock.patch
Description: gdb_stub_in_bootblock.patch
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Another year, another blob?

[Zeh, Werner]

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 decision is 
acceptable pretends that a silicon vendor is willing to start this discussion 
fully open at a time where he  by himself is not yet clear how the feature in 
question will finally look like (because once the vendor exactly know how it 
will look like it is set in stone [or silicon] already). Given this, 
communication on topics like this is very restricted, even inside a company. 
Everybody of us has experienced already that teams inside of a big company 
working on the same project but just on a different facet of it are often not 
aware of what is going on at the neighbors. Why is that? Well, this is IMHO 
because in our world more and more work is spread among viewer people. I do not 
see that this is evil-driven, it is just the lack of time the individuals have 
to get their job done in a fixed "24-hour-per-day-world". So I guess even if 
the companies would be willing to follow your approach to discuss things early 
we st
 ill will not get a perfect world. And discussing things implies that it will 
take some time to get to a consensus. Time, that (I must say unfortunately) is 
not there anymore since every one wants to have the latest and greatest toy to 
play with at best already yesterday.

You see how fast this discussion takes us away from technical stuff we all love 
to do and leads us into spheres where other factors rule the world.
Again, I do see your point and deep inside me I full agree with you. I just do 
not see it happening in the current scenario we have around.

Let's get back to your approach:
> > set of predefined, blob related questions (to be discussed) should be
> > answered.
Let's take it literally as you want. What if the answer to the question "Would 
the blob ever be open sourced?" is "No!"?
What would be the next action in your scenario triggered by this answer?

As Martin pointed out already, to me it sounds like "To many blobs with no open 
source in sight and we will reject this platform", too. But I might be wrong 
here simply because I internally answered the question above for me without it 
being answered by your approach directly. So, to be able to judge properly on 
the approach I miss the targeted outcome of your approach (I know that it is 
just a proposal to start the discussion, I just want to make my thoughts clear 
here). Because I don't believe that having a set of questions answered honestly 
by the poor guy, who currently is in charge of bringing in this particular new 
interface for the blob or the blob itself, will lead to a more open policy at a 
given vendor.
And yet again, answering this kind of questions is real work! Because the poor 
guy mentioned above now have to have meetings with various internal actors, 
describe the situation to them and hope that they will be able to provide the 
answers. In most cases, I guess, he can repeat the asking and explaining on the 
next linked person a few times. I am not sure if that guy will ever get the 
time for this relay run, especially if the outcome is not clear or guaranteed.

So yes, we need to stay in a close conversation with the vendors and keep them 
in a short loop. I am just not sure if we as coreboot alone can get that 
managed due to the lack of a business-model the vendor would be interested in. 
On the other hand I feel sorry for the poor guy mentioned here. Just because we 
are so upset with a particular vendor (due to the past issues we all may have 
experienced) we should behave correct when it comes to treatment of individual 
contributors, especially when those are quite new to the community. So instead 
of barking around on Gerrit and blocking stuff from being developed let us be 
constructive and provide helping hands and guides on Gerrit and on IRC. If I 
were the guy in question and I would be welcomed in the community the like, for 
sure I would feel sad.


Werner


> -Original Message-
> From: Nico Huber 
> Sent: Sunday, November 7, 2021 1:56 PM
> To: coreboot@coreboot.org
> Subject: [coreboot] Re: Another year, another blob?
> 
> Hi again,
> 
> originally, I was hoping for a more comprehensive discussion about possible
> solutions for the friction created by late, undiscussed additions of blob-
> support code. Alas, that didn't happen, and my own proposal below was
> misunderstood. So I'll try now to provide some rationale.
> 
> First of all, I have to say that what I write is meant literally.
> Please don't try to imagine something between the lines. But if you really
> feel like you have to, please just ask how it was meant.
> 
> On 20.10.21 14:24, Nico Huber wrote:
> > a recent yet-another-blob occurrence reminded me that I wanted to
> > write about the matter for a lo

[coreboot] Open letter to Intel regarding the PSE on Elkhart Lake

[Zeh, Werner]

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 ask Intel for open sourcing
the PSE code in order to avoid a new blob being introduced to coreboot.

I took this action item and reached out to Intel in this regard. As a result
I have had two meetings with the responsible people at Intel and they
started to look into this request. So as of now Intel is analyzing the code
to understand what needs to be done to open source it.

 

What has been mentioned by Intel to me is that up to now nobody else have
ever requested this for the PSE. Furthermore Intel let me know that it would
be easier to convince the management layer to spend work on open sourcing
the code if there would be more people from different companies requesting
the same. My first guess was: we can do this! Therefore I have drafted up an
open letter which I would like share with all of you:



https://openletter.earth/request-for-opening-the-source-code-for-the-pse-on-
elkhart-lake-26bad82a

 

The wording have now been reviewed for two days between different parties
and I would like to keep it as it is in order to get it done in time.

 

This is now the moment where you can raise your voice! Please have a look at
the open letter and sign it if you agree with the terms and if you support
this approach. The more people we get the higher are our chances to be
visible as an open source community. And it would be really helpful if we
could get this letter signed by companies, this will for sure increase the
traction of this request.

 

I will keep this letter in "signing" state until 2021-12-09 07:00 am German
time. Once we are there I will hand it over to Intel.

 

Thank you for your support in advance

 

Werner

 

[1]  
https://review.coreboot.org/c/coreboot/+/55367



smime.p7s
Description: S/MIME cryptographic signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Intel released first documentation on the PSE for Elkhart Lake SoC

[Zeh, Werner]

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 case requests.



Though it might be not fully complete it is a good starting point to dig into 
and get a wider understanding of the PSE and its internals.

There are other referenced documents mentioned in these two which are 
available, too. Just change the referenced doc number in the link and you will 
get the other docs as well.



Have fun

Werner



[1] https://cdrdv2.intel.com/v1/dl/getContent/636112

[2] https://cdrdv2.intel.com/v1/dl/getContent/636723



___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Elkhart Lake board bring up questions

[Zeh, Werner]

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 Linux we don't see devices 0:18.1 and 0:18.2. What else should we 
> do to enable CAN controllers?
There is a FSP-S parameter called 'PchPseCanEnable' which controls who (x86 or 
PSE) owns the CAN controllers. Make sure that you have assigned them to x86 
domain.
There is a devictree config for that called 'PseCanOwn' which provides a way to 
select the ownership on mainboard level.
In addition, make sure device 18.0 (PSE I2C7) is enabled as well as this is the 
function 0 of the 0x18 device which needs to be enabled to allow Linux to see 
the other functions of this device.

> 3) How do we enable eSPI in Coreboot and how it should be accessible 
> afterwards in Linux? We did:
>   device pci 1f.0 on   end # eSPI Interface

Once you did enabled the PCI device you should be able to see it in Linux as 
well. If this is the case, then you need a PCI driver to handle the controller, 
just like with all other PCI devices.

> 4) We have a TPM chip SLB9670 connected to FSPI, CS2.
> device pci 1f.5 on   end # PCH SPI (flash & TPM)
> ... and device 0:1f.5 is visible, but Linux kernel reports it couldn't find 
> any TPM chip. What do we need to do to get it working?

For your TPM to be visible to the OS you have to attach its driver to the eSPI 
PCI device in your devicetree as this is the one which actually handles the TPM 
transactions.
So add the following to your device tree and select the needed TPM Kconfig 
switches should do the trick:

device pci 1f.0 on  # eSPI Interface
chip drivers/pc80/tpm
device pnp 0c31.0 on end
end
end

> 5) We can't get audio to work.
> device pci 1f.3 on   end # cAVS/HDA
> ... and device 0:1f.3 is visible. This is output from kernel:
> $ dmesg | grep -i hda
> [5.559993] snd_hda_intel :00:1f.3: DSP detected with PCI 
> class/subclass/prog-if info 0x040100
> [5.560003] snd_hda_intel :00:1f.3: NHLT table not found
> [   66.698806] snd_hda_intel :00:1f.3: couldn't bind with audio component
> [   66.731030] snd_hda_codec_hdmi hdaudioC0D2: No i915 binding for Intel 
> HDMI/DP codec
> [   66.731465] snd_hda_intel :00:1f.3: Cannot probe codecs, giving up
> We think Linux should see (up to) 3 audio devices: HDMI, DisplayPort and 
> analog codec CS4207.

Looks like Linux misses the NHLT ACPI table.
Just have a look for 'NHLT' in the coreboot tree to get an idea what needs to 
be done for this table to be there.

Werner

From: Dubravko Moravski | Exor Embedded S.r.l. 

Sent: Thursday, April 7, 2022 1:23 PM
To: coreboot@coreboot.org
Subject: [coreboot] Elkhart Lake board bring up questions

Hello Coreboot,

I work for a company that makes a board containing an Elkhart Lake CPU and we 
use Coreboot to boot it.

We have started from Intel's document #626123 source files and document #641906 
for instructions. Release notes say "This is the main release of the coreboot 
Boot Loader Proof of Concept for the Elkhart Lake (EHL) series. Date: May 2021; 
revision: PR 1; description: PR 1 release"
We have already asked Intel for assistance, but they redirected us here.

The final Coreboot binary works, but we are having some issues that so far we 
were unable to solve on our own.
We are using latest Linux Mint x64 for most of our tests and soon we'll switch 
to Yocto.

1) There are roughly about 200 configurable pins on the CPU. We would like to 
use some as GPIOs. We can configure pin functionalities according to our needs 
in Coreboot source code (gpio.c, gpio_table[] definition), but Linux doesn't 
seem to know what to do with GPIO pins: in /sys/class/gpio we only see 
gpiochip445. To which of the EHL pins does 445 correspond? What should we do to 
see the rest of the pins? Some comments in the code suggest there can't be more 
than 32 pins per 'gpiochip'.
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 Linux we don't see devices 0:18.1 and 0:18.2. What else should we do 
to enable CAN controllers?
3) How do we enable eSPI in Coreboot and how it should be accessible afterwards 
in Linux? We did:
   device pci 1f.0 on   end # eSPI Interface
Device 0:1f.0 is visible. How should we access this bus in Linux or declare a 
device in SSDT table on this bus?
4) We have a TPM chip SLB9670 connected to FSPI, CS2.
device pci 1f.5 on   end # PCH SPI (flash & TPM)
... and device 0:1f.5 is visible, but Linux kernel reports it couldn't find any 
TPM chip. Wha

[coreboot] Re: Open letter to Intel regarding the PSE on Elkhart Lake

[Zeh, Werner]

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 the initiative out there.

Werner

[1]: https://github.com/intel/pse-fw



smime.p7s
Description: S/MIME cryptographic signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Open letter to Intel regarding the PSE on Elkhart Lake

[Zeh, Werner]

Hi Jay.

We do use a self written payload based on a Linux kernel with a userland
application which simply do a kexec to the next kernel.
With this payload we do boot into a Linux on an eMMC on one of our Elkhart
Lake designs.

With iPXE I do not have any experience on Elkhart Lake.

Werner

> 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 working on Elkhart Lake, can I inquire if you have
booted it to an OS via eMMC and/or iPXE using coreboot? If so, with which
payload?
>
> Thanks,
>
> - Jay
>
> From: ron minnich <mailto:rminn...@gmail.com> 
> Sent: Friday, April 22, 2022 7:02 PM
> To: Zeh, Werner <mailto:werner@siemens.com>
> Cc: coreboot <mailto:coreboot@coreboot.org>
> Subject: [coreboot] Re: Open letter to Intel regarding the PSE on Elkhart
Lake
>
> Nice job Werner, I'm completely shocked!
>
> On Thu, Apr 21, 2022, 10:24 PM Zeh, Werner <mailto:werner@siemens.com>
wrote:
> 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 the initiative out there.
>
> Werner
>
> [1]: https://github.com/intel/pse-fw
>
> ___
> coreboot mailing list -- mailto:coreboot@coreboot.org
> To unsubscribe send an email to mailto:coreboot-le...@coreboot.org


smime.p7s
Description: S/MIME cryptographic signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Open letter to Intel regarding the PSE on Elkhart Lake

[Zeh, Werner]

Dear coreboot community.

As I have written here Intel took care of our feedback and open sourced the
PSE code at github.
I have set up a "Thank you, Intel!" open letter [1].
Please do sign it as well to express that we honor the efforts Intel took
into this based on our feedback.

Thank 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 letter to Intel regarding the PSE on Elkhart
Lake
> 
> 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 the initiative out there.
> 
> Werner
> 
> [1]: https://github.com/intel/pse-fw


smime.p7s
Description: S/MIME cryptographic signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coreboot 4.18 release planned for October 5th

[Zeh, Werner]

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 features until we publish 4.18.

 

Thanks

Werner & Martin

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Further coreboot releases, setting new standards

[Zeh, Werner]

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 time based on chips from Intel.

I can understand the demand to keep the tree well-shaped. And yes, from time to 
time we need to get rid of old, bad or not at all maintained mainboards and 
even chipsets.
This need especially becomes more important if a deprecated code path prevents 
us from moving forward in the tree.
I do not see this demand that urgent if the new features have no hard 
dependencies on removal of old code.

Speaking of the two chipsets in question in this thread I do not see the real 
demand of getting rid of them yet. 
Why is coreboot not able to move forward if we keep fsp_baytrail and 
fsp_broadwell_de in the tree? 
Sure, we cannot expect to get all the fancy new features in them, but why 
should these chipsets stop working? What kind of source tree refactoring can 
hit theses chipsets that hard?

I am (or more precise: my company is), as Jay already pointed out, one of these 
users of both chipsets. We do have active boards based on Broadwell-DE 
(mc_bdx1) and Baytrail (mc_tcu3).
And this mainboards will not die that fast, we target our product availability 
to a range of >10 years as we are in the industry market (sure, we have hard 
dependencies on the chip availability).

We always have followed the policy of giving back. So every patch I do is 
reviewed on gerrit and gets merged once it is ready. This is the reason why you 
can build a working image for them on top of master.
So we do not have a branch we rely on. That will be needed if the chipsets will 
be dropped in the future. And this will increase my effort on maintenance.

I am completely with you Ron that it is a bad idea of keeping boards in the 
tree which are not relay tested on hardware for a long time.
And just because of this reason I have a test setup around where every of these 
boards it tested on real hardware several times a day with the latest master 
tree. 
This setup ensures that the mainboards can boot without issues into the OS. So 
the argument that the chipsets in question are not tested on real hardware is 
not valid now.

Don't get me wrong: If there is a need to tailor the code in order to get 
special features in or just for maintenance I will be glad to help. 
We currently are working together with Philipp on measured boot in coreboot 
where we maintain fsp_broadwell_de and fsp_baytrail. And I think we will 
continue doing so in the feature.
If we some time should hit the point where a special feature cannot be ported 
to one of this chipsets because of the boundaries that FSP1.0 dictates I will 
vote for keeping the chipsets nevertheless in the tree.
In the end this chips are working fine so far and I guess we can keep them 
working with a small effort. And I am willing to do whatever is needed to keep 
this chipsets in the tree...in the scope of FSP1.0 boundaries.

@Arthur: Thanks for providing the patches to implement postcar. I will test 
them on our mainboards next week and provide you the feedback in gerrit.

Werner

> -Ursprüngliche Nachricht-
> Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von Jay 
> Talbott
> Gesendet: Freitag, 30. November 2018 01:23
> An: 'Patrick Georgi'; mikeb...@gmail.com
> Cc: 'coreboot'
> Betreff: Re: [coreboot] Further coreboot releases, setting new standards
> 
> > From: Patrick Georgi [mailto:pgeo...@google.com]
> > Sent: Thursday, November 29, 2018 4:23 AM
> > To: mikeb...@gmail.com
> > Cc: Nico Huber; jaytalb...@sysproconsulting.com; coreboot
> > Subject: Re: [coreboot] Further coreboot releases, setting new
> > standards
> >
> > Am Do., 29. Nov. 2018 um 11:59 Uhr schrieb Mike Banon :
> > > I think, while Jay's board stays upstream it is benefiting from the
> > > "universal improvements": great commits to ./payloads/ ./util/ and
> > > also to the "not-MB-specific" parts of ./src .
> > And any of these changes (in particular to src) can break the board. It 
> > probably is already broken in master.
> >
> 
> I will attest that everything still builds/boots for the Broadwell-DE based 
> Camelback Mountain Intel reference board as of release 4.8.1.
> However, I can't speak for the status at the current head of the master 
> branch. For our particular current client projects that are using
> Broadwell-DE SoCs, we have branched off of master from 4.8.1 and have cherry 
> picked commits from master as needed. Many
> customizations we have made on our branch are not suitable for the general 
> masses since they are highly custom for this particular
> application, and thus are not suitable to upstream. But we may want to rebase 
> our branch someday to be branched off of a future release,
> so we would like to see continued support for the Broadwell-D

Re: [coreboot] Further coreboot releases, setting new standards

[Zeh, Werner]

> 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 yet whether to make anything mandatory, and on what schedule and 
> with what effect.
Sure, this is exactly the way I got it. I just wanted to depict my point of 
view without being afraid
that this will happen in the very near future. 

> So maybe people like you and Jay want to register yourselves as reviewers to 
> fsp_baytrail and
> fsp_broadwell_de, so you'll notice changes early and can test and comment on 
> them?
Yes, this is a really nice feature. Thank you for implementing it into gerrit 
Patrick!
I will add myself as reviewer for both platforms.

> So if we were to review changes to make these fsp 1.0 boards "somehow" 
> postcar-capable,
> you'd notice shortly after we checked them in if that broke anything?
Yes that is exactly what would happen. I got a few catches in the past already 
with that setup.
In the first glance I wanted to test even unmerged patches from gerrit but 
realized very soon that
my system will not be able to handle this amount. So for now I trigger the test 
setup every 4 hours
for a complete test which includes mc_tcu3, mc_bdx1 and since September even 
mc_apl1.

>Is publicly reporting which commits on master work on your boards something 
>you could do,
> or is that off-limits for some operational reason? 
Yes, I have that in mind for some time already. I simply hadn't the time yet to 
think about a way
on how to feed back this test results in detail.
Though it should be possible. If you have an idea of how we can reasonable feed 
back this test 
results let me know. I can think about implementing it in the spare time (once 
I will get some).

Werner


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: Fallback mechanisms on x86 with C_ENVIRONMENT_BOOTBLOCK

[Zeh, Werner]

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?

I have the case in mind where we need access to data other than stage-code  
like Siemens' HWInfo.
We need to access this configuration data from different stages.

Werner

> -Ursprüngliche Nachricht-
> Von: Julius Werner [mailto:jwer...@chromium.org]
> Gesendet: Donnerstag, 24. Januar 2019 00:01
> An: Aaron Durbin
> Cc: Julius Werner; Arthur Heymans; Coreboot
> Betreff: [coreboot] Re: Fallback mechanisms on x86 with 
> C_ENVIRONMENT_BOOTBLOCK
> 
> > For 1, this is attempting to protect physical attack. Obviously this 
> > particular problem can't be solved in isolation, but it's something to think
> about.
> 
> But isn't this something that per-file hashing would probably make easier to 
> protect against, not harder? I mean, right now we just hash the
> whole region once and then assume it stays good -- there is no protection. I 
> doubt this would really become easier to solve if you split the
> CBFS up into chunks... you'd have to somehow built a system where a whole 
> chunk is loaded into memory at once, verified there, and then
> every file we may want to access from it is accessed in that same stage from 
> that cached version in memory.
> 
> The file is the natural unit which is loaded at a time, so I'd think scoping 
> the verification to that would make it easiest to verify on load. I
> mean, on Arm we already always load whole files at a time anyway, so it's 
> really just a matter of inserting the verification step between load
> and decompression on the buffer we already have. (On
> x86 it may be a bit different, but it should still be easier to find space to 
> load a file at a time than to load a larger CBFS chunk at a
> time.)
> 
> > When discussing 2 from a practical matter, we need to pass on the metadata 
> > information across stages to help mitigate 1 and ensure
> integrity of the hashes are correct.
> 
> This is true -- but isn't this the same for all solutions? No matter how you 
> scope verification, if you want to verify things at load time then
> every stage needs to be able to run verification, and it needs some kind of 
> trust anchor passed in from a previous stage for that. I also don't
> think this should be a huge hurdle... we're already passing vboot workbuffer 
> metadata, this just means passing something more in there.
> (For per-file hashing, I'd assume you'd just pass the single hash covering 
> all the metadata, and then all the metadata is verified again on
> every CBFS walk.)
> 
> > Similarly, limiting complexity is also important. If we can group the 
> > assets together that are tied to the boot flow then it's conceptually
> easier to limit access to regions that haven't been checked yet or shouldn't 
> be accessed. I do think per-file metadata hashing brings a lot of
> complications in implementation. When in limited resource environments 
> chunking cbfs into multiple regions lends itself well to
> accomplishing that while also restricting access to data/regions that aren't 
> needed yet when thinking about limiting #1.
> 
> Fair enough. I agree limiting complexity is always important, I'm just not 
> ad-hoc convinced that a solution like you describe would really be
> less complex than per-file hashing. I think that while it makes the CBFS 
> access code itself a bit more complex, it would save complexity in
> other areas (e.g. if you have arbitrary chunks then something must decide 
> which chunk to use at what time and which file to pack into
> which chunk, all of which is extra code). Assuming we can "get it right 
> once", I think per-file hashing should be a solution that will "just work"
> for whatever future platform ports and general features want to put in CBFS 
> (whereas a solution where everyone who wants to put another
> file into CBFS must understand the verification solution well enough to make 
> an informed decision on which chunk to place something into
> may end up pushing more complexity onto more people).
> 
> Anyway, I didn't want to derail this thread into discussing CBFS 
> verification, I just wanted to mention that I still think the per-file 
> hashing is a
> good idea and worth discussing. We should have a larger discussion about the 
> pros and cons of possible approaches before we decide what
> we're planning to do (and then someone still needs to find time to do it, of 
> course ;) ).
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email 
> to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 4.9: FSP debug level (0-3)

[Zeh, Werner]

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 from UART log with own log levels.
In this scenario you can have a low level on UART which gives you boot time 
benefits while you can get the full log from CBMEM
once you made it into the OS. I admit that in this case you will lose the 
needed debug information once your board will not boot,
but this is a case which needs to be treated in a special way anyway.

Werner

> -Ursprüngliche Nachricht-
> Von: ron minnich [mailto:rminn...@gmail.com]
> Gesendet: Sonntag, 10. Februar 2019 20:20
> An: Zvi Vered
> Cc: Gregg Levine; coreboot
> Betreff: [coreboot] Re: 4.9: FSP debug level (0-3)
> Wichtigkeit: Hoch
> 
> I had a discussion once with Russ Cox, a fairly well known person in this 
> business :-), as he was reviewing some kernel code I'd written
> which was chock full of
> 
> #if DEBUG
> 
> as is the custom in so many kernels.
> 
> He really disliked the style and let me know so. His point was that in many 
> cases, cpp-based debug macros are abused. They turn off code
> not in the critical path, so there is not a real performance-based 
> justification for using them.
> In many cases, compiling out debug code means that, most of the time, when 
> you really needed it, it is not there -- as in this case.
> 
> Which gets to my question: why on earth are there debug builds of FSP?
> Why isn't debugging always on? Debug stuff should always be on IMHO.
> As we've discovered, a lot of UEFI debug code *won't compile any more* 
> because people got in the habit of leaving it out. You turn on
> debug macros and the UEFI build fails. We can imagine a day in which it's no 
> longer possible to build a debug FSP either.
> 
> I realize we have the same kind of "debug build' behavior in coreboot, but we 
> only ever enabled turning the debug level down in coreboot,
> ca.
> 2001, because FLASH space was tight -- this is why we have, e.g., the MAX 
> console log level stuff. But turning down debug prints in
> coreboot  was always a problem for me because, as always, the one time you 
> really needed those prints, you found they were compiled
> out! But don't we leave all that stuff enabled by default nowadays? That's 
> what I recall anyway ...
> 
> If anyone from Intel is reading this ... what's the reason for debug builds 
> of FSP vs. non-debug? That approach has not worked
> tremendously well in UEFI, why have it in FSP?
> 
> On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered  wrote:1FAFB2926
> 
> > C0.D0: SPD not present.
> > C1.D0: SPD not present.
> 
> oh boy. No SPD? Do you need to set up some fake SPD then?
> 
> ron
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email 
> to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 4.9: FSP debug level (0-3)

[Zeh, Werner]

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&D HW 1)
> Cc: Zvi Vered; Gregg Levine; coreboot
> Betreff: Re: [coreboot] Re: 4.9: FSP debug level (0-3)
> Wichtigkeit: Hoch
> 
> On Sun, Feb 10, 2019 at 10:46 PM Zeh, Werner  wrote:
> >
> > Hi Ron.
> >
> > For me the reason of decreasing the log level is boot time and not flash 
> > size.
> 
> Werner, this is a good reason to ensure that debug messages can be turned 
> off. This is why coreboot has console loglevel controls.
> 
> So it makes sense to be able to control the log level, no question.
> I'm not arguing that.
> 
> What I'm saying is that the concept of a 'debug build', which seems to derive 
> from windows practice (I'm not kidding!), is a bad idea for
> FSP. There should not be a debug build. There should always be one build, not 
> least because sometimes debug builds can fail in odd ways
> at build or boot time, due to design or programming errors. I've seen this in 
> practice in UEFI, where enabling debug messages breaks the
> UEFI build.
> 
> FSP should create a single build with a tunable console print level. I am 
> hoping someone from Intel will take note.
> 
> IMHO debug builds are a bad idea.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: hang in walkcbfs.S on skylake SP

[Zeh, Werner]

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 size you have set up for 
caching (VIRTUAL_ROM_SIZE). You can hit the same issue if you have used 32 MB 
for flash size in Kconfig. Then exact this can happen as x86 can only map 16 MB 
maximum into MMIO space and your next stage might be to far away from the 
bootblock.

Werner

> -Ursprüngliche Nachricht-
> Von: Nico Huber 
> Gesendet: Mittwoch, 13. Februar 2019 10:29
> An: Jonathan Zhang ; coreboot@coreboot.org
> Betreff: [coreboot] Re: hang in walkcbfs.S on skylake SP
> 
> Hi Jonathan,
> 
> On 13.02.19 08:31, Jonathan Zhang wrote:
> > Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass
> > with FSP 2.0. I have a strange issue that I hope to get some wisdom.
> > The boot hangs when executing this line "sub %ecx, %ebx" in
> > src/arch/x86/walkcbfs.S
> 
> I don't know what might cause it, but have two pointers:
> 
> 1. I was wondering why you would have to look at CBFS from assembly at all. 
> Do you have CONFIG_FSP_CAR set? Using the FSP CAR
> setup is probably not the best idea, as it is likely the least tested path. 
> Better select a native coreboot solution instead, in case.
> 
> 2. First idea that always jumps into mind when I see early instabili-
> ties: Do you have microcode updates *matching your CPU stepping* in your 
> coreboot.rom? It might also be worth to check if the FIT
> table points correctly to them (64 bytes from the top of the .rom should be a 
> pointer to the FIT, that should have an entry pointing to the
> updates). I don't know about Skylake, but generally, there may be steppings 
> that need an update really early.
> 
> Hope that helps,
> Nico
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email 
> to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: RFC: Replacing IS_ENABLED(CONFIG_XXX) with the shorter CONFIG(XXX)

[Zeh, Werner]

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 
> shorter CONFIG(XXX)
> 
> On Tue, 2019-03-05 at 17:52 -0800, Julius Werner wrote:
> > Hi folks,
> >
> > I'm proposing a small policy change for the way we refer to boolean
> > Kconfig variables in code. Right now, the directive is to always use
> > the IS_ENABLED() macro. I would like to replace this with a shorter
> > macro CONFIG() that also removes the need to type the CONFIG_ prefix
> > again. The idea is mostly to save some horizontal space and the
> > occasional extra line break for this boilerplate and make it a little
> > easier to type.
> >
> Sounds like a good plan. Please keep Documentation in sync:
> Documentation/core/Kconfig.md seems to cover the implementation details.
> 
> > It's a very simple change (patch train starts at
> > https://review.coreboot.org/c/coreboot/+/31773), but since it affects
> > pretty much all code in coreboot and payloads I wanted to send out a
> > quick FYI. Please let me know if anyone has any concerns with this.
> > ___
> > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an
> > email to coreboot-le...@coreboot.org
> --
> Patrick Rudolph
> 
> 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
> Email:  patrick.rudo...@9elements.com
> Phone:  +49 234 68 94 188
> 
> Sitz der Gesellschaft: Bochum
> Handelsregister: Amtsgericht Bochum, HRB 17519
> Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen 
> ___
> coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email 
> to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ramstage/x86emu doesn't build

[Zeh, Werner]

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 the code: x86emu currently (
0987e43aa05bfbafbfdd4952638b79a5084369f8 ) doesn't build:

In file included from src/device/oprom/x86emu/x86emui.h:65,
  from src/device/oprom/x86emu/debug.c:40:
src/device/oprom/x86emu/debug.c: In function 'x86emu_dump_regs':
src/device/oprom/x86emu/debug.h:46:22: error: implicit declaration of function 
'printk'; did you mean 'printf'? 
[-Werror=implicit-function-declaration]
  #define printf(x...) printk(BIOS_DEBUG, x)
   ^~
src/device/oprom/x86emu/debug.c:366:5: note: in expansion of macro 'printf'
  printf("\tAX=%04x  ", M.x86.R_AX );
  ^~


I append the config. Also, there's noone in MAINTAINER for it, and appearently 
it's not build-tested :(

thanks

  martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] cbfstool: CBFS alignment broken due to FMAP

[Zeh, Werner]

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 [mailto:coreboot-boun...@coreboot.org] Im Auftrag von Ben Gardner
Gesendet: Montag, 18. Januar 2016 21:54
An: Patrick Georgi
Cc: coreboot
Betreff: Re: [coreboot] cbfstool: CBFS alignment broken due to FMAP

Thank you. That worked.

On Mon, Jan 18, 2016 at 2:46 PM, Patrick Georgi  wrote:
> 2016-01-18 21:34 GMT+01:00 Ben Gardner :
>> Is there a work-around for this? For example, is there an option to 
>> pad the FMAP out to 4 KB?
> The workaround is indeed to increase the FMAP region's size to 4K.
>
> To do this, edit $(top)/Makefile.inc, line 708 (since you're on x86, 
> otherwise line 723):
> FMAP_FMAP_SIZE := 0x100
> to
> FMAP_FMAP_SIZE := 0x1000
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und 
> -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

--
coreboot mailing list: coreboot@coreboot.org 
http://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot 4.4 release coming soon

[Zeh, Werner]

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 [mailto:coreboot-boun...@coreboot.org] Im Auftrag von Martin Roth
Gesendet: Freitag, 15. April 2016 00:46
An: coreboot
Betreff: [coreboot] coreboot 4.4 release coming soon

Hi Everyone,
  We're planning on doing the coreboot 4.4 release in the next week or so.

We'd like to request some help with testing platforms both ahead of the release 
and when the release actually happens.  If you have a board in the coreboot 
tree, please try doing a build to help us verify what's working and to let us 
know about anything that isn't working.

- If your board is working, please either submit a board-status report or even 
just post a response to this email saying what board you tested and which 
commit id you tested on.

- If there's a problem with your board, filing a bug would be great, but an 
email describing the problem along with build and/or boot logs would be very 
helpful as well.

If anyone has features that they would like to get in before the next release, 
please respond to this email or contact me directly.

Martin

--
coreboot mailing list: coreboot@coreboot.org 
https://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot toolchain update after 4.4 release

[Zeh, Werner]

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
Betreff: [coreboot] coreboot toolchain update after 4.4 release

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  $ rm .xcompile

Stefan

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP failed

[Zeh, Werner]

Hi Jim.

According to  the Postcode it seems like you have no valid microcode for the 
used CPU.
In src/drivers/intel/fsp1_0/cache_as_ram.inc is the code which ends up in the 
endless loop while this code is shown.

Check which CPU you really use on your mainboard and add the right microcode to 
you configuration.
This should solve your issue.

Werner

Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von ???
Gesendet: Freitag, 1. Juli 2016 05:46
An: coreboot@coreboot.org
Betreff: [coreboot] Bring up Intel Camelback Mountain Board with coreboot+FSP 
failed

Dear Sir,

I just clone the latest coreboot source code from 
GIT and FSP from Intel FSP 
website.
Using " make crossgcc-i386 CPU=4 " to setup the compilation environment.
But the Camelback Mountain board could not bring up successfully,
it always hang with POST CODE = 0xCE.
From the Intel FSP spec 1.0, it seems that system halt before loading FSP.
Attached is my .config file, is there anyone hit the fail symptoms same as me 
and any idea to solve it?

Thanks a lot,
Jim

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] What is the best way to treat warnings reported by checkpatch.pl

[Zeh, Werner]

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 did that in the same style how other structures are defined in the same file 
(src/arch/x86/include/arch/acpi.h):

typedef struct dmar_atsr_entry {
u16 type;
u16 length;
u8 flags;
u8 reserved;
u16 segment;
} __attribute__ ((packed)) dmar_atsr_entry_t;

This change resulted in two warnings caused by util/lint/checkpatch.pl when I 
was trying to do a git commit:

WARNING: do not add new typedefs
#34: FILE: src/arch/x86/include/arch/acpi.h:288:
+typedef struct dmar_atsr_entry {

WARNING: __packed is preferred over __attribute__((packed))
#40: FILE: src/arch/x86/include/arch/acpi.h:294:
+} __attribute__ ((packed)) dmar_atsr_entry_t;

So the first warning tells me that I should not use "typedef" in my code.

The second one tells me not to use __attribute__ ((packed) but instead __packed!
If one take a closer look to the coreboot tree, one will not find a macro 
definition called __packed at all.

After a short discussion on IRC with Stefan it was clear that although we have 
this checkpatch.pl script in the tree and the git hook "pre-commit"
activates it, the script does not perfectly match current coreboot coding style.

So in the end there needs to be a change somewhere:

1. We can adapt the script to match current coreboot coding style

2. We can start to refactor the coreboot tree to match the demands of 
checkpatch.pl

3. We can align only new patches to the demands of the script

4. We can show warnings from the script but prevent them from aborting the 
git commit

While 1. would be the best, straight forward approach for the project, it might 
cause high effort for a person who knows the code base very well.
2. will lead to a lot of changes in the tree while the reason/goal is still 
questionable (at least to me).
3. will lead to different code style all over the tree (even in the same file) 
and in the end will result in fragmented code. I personally would not like it.
4. can be a short term solution while we are seeking for the best way to deal 
with this issue.

There may be other ways to go, too, which I have overseen now.

I just want to start this discussion officially as this is not the first time I 
ran into issues with checkpatch.pl.
What do you think about it, what would be the best way to handle this case?

Your ideas and thoughts are appreciated.

Werner
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] WG: What is the best way to treat warnings reported by checkpatch.pl

[Zeh, Werner]

>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 discussion to improve the situation with this script we 
currently have.

>I think we should try to do a little of option 1 within reason, not by forking 
>the script but rather by disabling more check steps that don't match the 
>coreboot code style (by >having our wrapper pass --ignore XXX flags to 
>checkpatch) and possibly upstreaming checkpatch.pl patches with new features 
>we need to the Linux kernel (to make the >detection more accurate or add a 
>more specific --ignore flag we can turn on). In the Chromium fork of coreboot 
>we're already using a bunch of those flags that we should >probably use in 
>upstream coreboot as well:
>
>--ignore C99_COMMENTS
>--ignore GLOBAL_INITIALISERS
>--ignore INITIALISED_STATIC
>--ignore LINE_SPACING
>--ignore NEW_TYPEDEFS
>--ignore PREFER_ALIGNED
>--ignore PREFER_PACKED
>--ignore PREFER_PRINTF
>--ignore SPLIT_STRING
>

If we really did not touch the contents of the script, I totally agree with 
you. We can disable warnings that do not match our coding style while updating 
the script from its origin from time to time. If we have already started 
tailoring this script, than we should do it the right way and end this 
tailoring process to match our needs. I admit that the later one will end up in 
more work if one wants to synchronize this script with origin again one day.

Werner
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB Support on Apollo Lake

[Zeh, Werner]

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 set and operational model.

What in turn should work is that "some of the BIOS" (which in coreboot-context 
is the payload like SeaBIOS) will handle all the
xHCI stuff and provide a legacy interface to the OS (and here GRUB acts as an 
OS) to just read mass storage devices using interrupts.

Beside that you are lost with GRUB2 and xHCI, sorry!

Werner

>Hi Experts,
>
>Does coreboot support USB port initialization in legacy mode on Apollo Lake as 
>some of the BIOS does so that grub or other payloads can use it as USB2.0?
>
>There is no USB2.0 port on this board and Grub2 doesn't support xhci so we 
>seems to be reaching to a dead end.
>
>I am trying to see if the dual role USB ports can be initialized in 
>coreboot/fsp so that they can act as USB2.0 for payloads.
>
>Thanks
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re: Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II

[Zeh, Werner via coreboot]

Hi Nico, Krystian.

This feature sounds in general quite nice as it will improve the user
experience for the
firmware update scenario and align with the standard scenarios available out
there nowadays.

>From the implementation point of view it looks a bit tricky to me:
We do weave two independent projects (coreboot and Tianocore) quite a lot
together in order to
accomplish this task. Though there might be justifications to do that
(coreboot owns SMM and
unrestricted flash access can most complete be done from SMM while EDK II is
the place to which the
OS communicates to in order to provide the capsule), we should be careful
doing so.
There is just this one configuration out there which uses this feature (both
sides, coreboot and Tianocore,
need to enable capsule update). How shall be make sure that either side
stays functional and will not
logically break when the independent projects are getting developed further
over the future?

Do you plan to add any kind of unit test to both projects so that it can be
guaranteed?
Because I otherwise fear that this feature can break quite easy without
being
noticed by both communities on time.

Is there a way forward to reduce the intersection between coreboot and
Tianocore by limiting the
task coreboot needs to serve, maybe to just temporarily disable the flash
write protection?
This way the update could be implemented mostly on Tianocore side reducing
the dependencies a lot.

Regards
Werner

>Hi Nico, 
>>On 11.07.24 13:17, Beata Skierka wrote:
>>>We are pleased to announce the launch of a project by 3mdeb aimed at
>>>integrating
>>>UEFI Capsule Update for coreboot with EDK II as a payload. This
>>>initiative aims
>>>to bring the capsule-based update method, providing an alternative to the
>>>traditional flashrom-based method, which becomes more and more difficult
to
>>>implement, due to the restricted OS-level access to the firmware storage.
>
>>I wonder if this is the only incentive? Because it seems like an
>>unfortunate myth :-/  You generally have these restrictions when
>>using the user-space drivers. However, there are also kernel dri-
>>vers and interfaces  (e.g. `spi-intel` and the MTD interface in
>>Linux). Flashrom and Flashprog both have a `linux_mtd` driver for
>>this.
>
>Those drivers can't handle all of the protection mechanisms, for example
>SMM BWP (BIOS Write Protection) can only be disabled by a reset (bugs
>like broken S3 resume or misconfigured GPIO that would allow accessing
>the pins directly to bit-bang raw commands don't count).
>>
>>So flash access shouldn't be a problem in general.  Of course it
>>needs to be secured, but that's independent of the way that gets
>>the actual update to the program that writes it to the flash.
>>
>>>One of the main goals is also to ease the integration and firmware update
>>>deployments via the fwupd for devices running open-source firmware
>>>(based on
>>>coreboot + EDK II).
>>>
>>Is fwupd still Linux only? Because on Linux flashing should be ea-
>>sier than in firmware. It may need some work on the kernel drivers
>>but that's probably far, far less effort.
>>Just because the update is performed by firmware doesn't mean that the
>>user has to interact with it directly. Flashing can be initialized from
>>OS, but it can also be done by UEFI app in case of lack of support for
>>capsules in OS.
>
>Yes, AFAICT fwupd is Linux only. However, this isn't the only software
>that uses capsules to perform the update, Windows also uses it (although
>this would require creating and distributing firmware as drivers through
>Windows Update, which is beyond the scope of this project). Linux can also
>be compiled with EFI_CAPSULE_LOADER [1] which exposes an interface for
>sending capsules to the firmware by a simple write to file. Can it really
>get easier than `cat firmware.bin > /dev/efi_capsule_loader` [2]? 
>
>>>For a detailed project outline, please visit our Dasharo documentation
>>>[1].
>>>
>>This left me wondering: Where in the process are signatures verified?
>>And which parts are signed? each chunk that is gathered from memory
>>individually? or only the coalesced data? If it's the latter, we'd
>>likely have a lot of code that is processing / influenced by untrusted
>>input. Then I would strongly recommend not to implement it in C. SPARK
>>would be the language of my choice. It integrates well with coreboot.
>>
>Signatures are verified by edk2, on coalesced data. There are decisions
>made earlier based on presence of data, not on it's content. This is why
>we will take care to not allow booting an OS with full access to flash
>enabled when edk2 decides that the capsule isn't valid.
>
>I doubt that SPARK integrates with edk2 as nicely as it does with coreboot.
>That said, we don't have any professional SPARK / Ada developers in our
>team (at least nobody mentioned it), which leaves us with C. 
>Another thing that I didn't get yet: Why is coreboot involved? Couldn't
>edk2 gather the capsule chunks from memory?
>Because