coreboot

coreboot@coreboot.org

6 participants
39687 discussions

arm-trusted-firmware mirror seems to have stopped syncing
by Julius Werner 13 May '21

13 May '21

Hi Patrick, Martin, The coreboot.org mirror of the arm-trusted-firmware repo (https://review.coreboot.org/admin/repos/arm-trusted-firmware) seems to be half a year out of date. According to the description (although that may be out of date) it's still syncing from the old GitHub location (https://github.com/ARM-software/arm-trusted-firmware.git). The Trusted Firmware project switched a while ago to their own hosting solution and I probably forgot to let you know. The new upstream repository this should sync from is at: https://review.trustedfirmware.org/TF-A/trusted-firmware-a Then again, it looks like the GitHub location is still kept up to date as a read-only mirror (https://github.com/ARM-software/arm-trusted-firmware/commits/master), so maybe this isn't the real source of the problem? Anyway, can you please take a look and figure out how to fix the syncing? (Or is this supposed to be done manually somehow?) Thanks, Julius

2 1

New on blogs.coreboot.org: Announcing coreboot 4.14
by blogs.coreboot.org 10 May '21

10 May '21

1 0

[RFC] How should we manage tree-wide changes?
by Patrick Georgi 10 May '21

10 May '21

Hi everybody, In our leadership meeting[1] we discussed how we should deal with tree-wide changes (ranging from "new file header" to "some API is gone now"). The concern was that right now, anything can change at any time, making local development harder. There have been a few ideas but nothing definite yet: One idea was to declare some interfaces (e.g. those used by src/mainboards/**), with varying stability horizons (e.g. "only change right after a release"), or backward compatibility guarantees (although the details still seemed hazy on how that could work in practice.) Another idea brought up was to require that such changes come with documentation and, ideally, migration support in the form of scripts and the like. We had something like this in the past[2] and I created a proposal[3] to establish it as a rule and build a culture around documenting sweeping changes. One doesn't exclude the other, and there may be other approaches on how to make development easier without calcifying our codebase. Or maybe people don't see a problem that needs fixing? In any case, I wanted to bring it up in a larger forum to make sure that we find rough consensus across the community before a decision is made on how to proceed here. Regards, Patrick [1] minutes at https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [2] http://web.archive.org/web/20130315025026/http://www.coreboot.org/Flag_Days [3] https://review.coreboot.org/c/coreboot/+/52576 -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

6 21

Default-timings in Designware I2C driver
by Zeh, Werner 10 May '21

10 May '21

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-designwa…

3 6

Releasing coreboot 4.14 (on Monday)
by Patrick Georgi 07 May '21

07 May '21

Hi everybody, I still plan to do the coreboot release on Monday (or, if things are really bad, on Tuesday), even though I'm somewhat behind on our checklist. This means we are at the https://doc.coreboot.org/releases/checklist.html#week-prior-to-release stage. Therefore, if you have hardware and the ability to flash and recover, please test our current code on it, and report back if there are problems. If you think a feature you worked on since 4.13 was released deserves a shout-out in our release notes and it isn't already there, create a change that adds it to Documentation/releases/coreboot-4.14-relnotes.md Thanks, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

ACPI SSDT Help
by Rocky Phagura 07 May '21

07 May '21

Hello, Looking for some recommendations here. I have a situation where I would like to compile ACPI ASL code into its own definition block and load it dynamically based on some features present in the HW. For example, the code below has its own definition block. Today all of the projects in Coreboot seem to be using only 1 definition block (in dsdt.asl) and the whole thing is loaded at once. I'm looking to create a second definition block and load it dynamically. The SSDT table in Coreboot is mostly derived from C code generating asl code. I prefer iasl compile the asl code. The code I have below functions correctly using the SSDT method. My issue is that it doesn't work well with the existing make system. Right now I have to use a 2 step approach. (1) compile the asl code manually, iasl -tc ras.asl (2) compile Coreboot and include the newly generated hex file (iasl generates c code include file, ras.hex) which links with c code that creates an SSDT table at runtime just like all other tables are added (madt, hpet, etc). While the above 2 step process works, its not clean. I think there is a better way and I'm looking for the Coreboot community's help. Any recommendations are welcome. Thank you, DefinitionBlock ( "ras.aml", "SSDT", 2, "Test", "Test", 0x1000 ) { Scope (\_GPE) { //#include <acpi/acpi.h> OperationRegion (PMIO, SystemIO, 0x500, 0xFF) Field (PMIO, ByteAcc, NoLock, Preserve) { Offset(0x34), /* 0x34, SMI/SCI STS*/ , 9, SGCS, 1, /* SWGPE STS BIT */ Offset(0x40), /* 0x40, SMI/SCI_EN*/ , 17, SGPC, 1, /* SWGPE CTRL BIT */ Offset(0x8C), /* 0x8C, General Purpose Event 0 Status [127:96] */ , 2, SGPS, 1, /* SWGPE STATUS */ Offset(0x9C), /* 0x9C, General Purpose Event 0 Enable [127:96] */ , 2, SGPE, 1 /* SWGPE ENABLE */ } Device (RAS) { Name (_HID, EisaId ("PNP0C33")) Name (_UID, 0) Name (_DDN, "RAS Error Device Controller") Store(" Initialized RAS Device PNP0C33", Debug) } Method(_L62, 0) { Store(" SWGPE Method _L62", Debug) Store(0, SGPC) // clear SWGPE enable Store(1, SGPS) // clear SWGPE Status Notify(RAS, 0x80) } } }

2 2

Re: [coreboot] Re: Only Garbarge Data On Serial Port Protectli FW6C
by lain 05 May '21

05 May '21

I tried two different firmware roms but both with HAP bit set. Could this affect the serial connectivity ( as SuperIO in PCH or smth ? On Monday, May 03, 2021 14:39 CEST, "lain" <lain(a)datenwanderung.de> wrote: Hi Michal, I tired 2 Different USBto RS232 Converts, and a SerialPort on an Thinkpad x60 dock, also flow control. The Very same DB9 RJ45 cable works on a sun ultra. Also tried Power unplug. Maybe something firmware realted or faulty connector i would say On Monday, May 03, 2021 14:27 CEST, Michał Żygowski <michal.zygowski(a)3mdeb.com> wrote: Hi Iain, On 5/3/21 2:20 PM, lain via coreboot wrote: > Does somebody has trouble with the Serial Port on an Protectli FW6C / > Yangling device ? > I am getting only Garbage ( yes i have checked the serial settings ) > > How likely is a faulty connector ? I would check two things: 1. Faulty RS232 converter 2. Enabled hardware flow control. Such issue sometimes happened with the FW6 platform during the firmware development and the above were the main reasons. Don't forget to keep the hardware flow control off when opening the serial port in your terminal emulator. Please also try different RS232 converter if possible. I also encountered faulty samples of such converters which did not work reliably (I have a bunch of converters of the same model and vendor, but 1 out of 20 was simply not working). Alternatively you may unplug the converter from any power to let it reset, just in case the converter caught some escape sequence in a wrong moment. Very unlikely that something is wrong with FW6C platform. > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org Best regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com _______________________________________________ coreboot mailing list -- coreboot(a)coreboot.org To unsubscribe send an email to coreboot-leave(a)coreboot.org

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 04 May '21

04 May '21

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 11 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1452916: Null pointer dereferences (FORWARD_NULL) /util/sconfig/main.c: 453 in new_fw_config_field() ________________________________________________________________________________________________________ *** CID 1452916: Null pointer dereferences (FORWARD_NULL) /util/sconfig/main.c: 453 in new_fw_config_field() 447 } 448 449 /* Check that each field is within 64 bits. */ 450 tmp = bits; 451 while (tmp) { 452 if (tmp->start_bit > tmp->end_bit || tmp->end_bit > 63) { >>> CID 1452916: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "field". 453 printf("ERROR: fw_config field %s has invalid range %u-%u\n", field->name, 454 tmp->start_bit, tmp->end_bit); 455 exit(1); 456 } 457 458 /* Check for overlap with an existing field. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

Only Garbarge Data On Serial Port Protectli FW6C
by lain 03 May '21

03 May '21

Does somebody has trouble with the Serial Port on an Protectli FW6C / Yangling device ? I am getting only Garbage ( yes i have checked the serial settings ) How likely is a faulty connector ?

2 1

Duplicate BIOS flash mapping - ITE EC RAM
by Github User 03 May '21

03 May '21

Hi All, I try port an old AMD Fam15h KaveriPI board to Coreboot, and to enable the EC properly (proprietary IT8586e, with its own FW stored in E-Flash - similar to IT5570) the EC would need to map its internal RAM to 0xff000000 in host memory. However, currently this (host) RAM region is occupied by CB despite the fact, that normally - considering a 8MB flash size - CB flash image should be mapped to 0xff800000 only. The whole CB image of course is also mapped to that address (reading via DD from /dev/mem), but why do I have this duplicate mapping? More interestingly if I use a 4MB flash chip and image size (CB normally mapped to 0xffc00000) I see the CB image mapped four times (at addresses 0xff00.. 0xff40.., 0xff80.., 0xffc0..). Any thoughts why this redundant mapping could there be and how to eliminate? PS: the EC provides some kind of flexibility to relocate its RAM to host ram mapping via LDN=0xf, SMFI registers (within 0xfexx.. - 0xffxx.. region in host), but despite trying to reserve any 4K region within that range in CB (+setting Hudson LPC to decode + reserve this memory region also in ACPI) - there are only empty data (0xff) visible in host memory. Thanks, Githubhun

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot