coreboot-gerrit May 2020

coreboot-gerrit@coreboot.org

1 participants
2588 discussions

Change in coreboot[master]: soc/intel/jasperlake: Add Sata related UPDs configuration
by Ronak Kanabar (Code Review) 07 May '20

07 May '20

Ronak Kanabar has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41029 ) Change subject: soc/intel/jasperlake: Add Sata related UPDs configuration ...................................................................... Patch Set 8: (3 comments) https://review.coreboot.org/c/coreboot/+/41029/4//COMMIT_MSG Commit Message: https://review.coreboot.org/c/coreboot/+/41029/4//COMMIT_MSG@11 PS4, Line 11: it can be set as per each board's requirement. > here in this we are changing FSP UPD value as per board's requirement. […] can I mark it resolved ? https://review.coreboot.org/c/coreboot/+/41029/6/src/soc/intel/jasperlake/f… File src/soc/intel/jasperlake/fsp_params.c: https://review.coreboot.org/c/coreboot/+/41029/6/src/soc/intel/jasperlake/f… PS6, Line 139: dev->enabled > Ack. will change this. changed. can i mark it resolved? https://review.coreboot.org/c/coreboot/+/41029/6/src/soc/intel/jasperlake/f… PS6, Line 140: SataEnable > Ack. added all upds. can i mark it resolved ? -- To view, visit https://review.coreboot.org/c/coreboot/+/41029 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I4f7e7508b8cd483508293ee3e7b760574d8f025f Gerrit-Change-Number: 41029 Gerrit-PatchSet: 8 Gerrit-Owner: Ronak Kanabar <ronak.kanabar(a)intel.com> Gerrit-Reviewer: Aamir Bohra <aamir.bohra(a)intel.com> Gerrit-Reviewer: Karthik Ramasubramanian <kramasub(a)google.com> Gerrit-Reviewer: Maulik V Vaghela <maulik.v.vaghela(a)intel.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Subrata Banik <subrata.banik(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Furquan Shaikh <furquan(a)google.com> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Comment-Date: Thu, 07 May 2020 12:43:35 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Furquan Shaikh <furquan(a)google.com> Comment-In-Reply-To: Paul Menzel <paulepanter(a)users.sourceforge.net> Comment-In-Reply-To: Ronak Kanabar <ronak.kanabar(a)intel.com> Gerrit-MessageType: comment

1 0

Change in coreboot[master]: util/sconfig: Drop use of ref_count for chip_instance
by Furquan Shaikh (Code Review) 07 May '20

07 May '20

Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41007 ) Change subject: util/sconfig: Drop use of ref_count for chip_instance ...................................................................... util/sconfig: Drop use of ref_count for chip_instance chip_instance structure currently uses a ref_count to determine how many devices hold reference to that instance. If the count drops to zero, then it is assumed that the chip instance is a duplicate in override tree and has a similar instance that is already overriden in base device tree. ref_count is currently decremented whenever a device in override tree matches the one in base device tree and the registers from the override tree instance are copied over to the base tree instance. On the other hand, if a device in override tree does not match any device in base tree under a given parent, then the device is added to base tree and all the devices in its subtree that hold pointers to its parent chip instance are updated to point to the parent's chip instance in base tree. This is done as part of update_chip_pointers. However, there are a couple of issues that this suffers from: a) If a device is present only in override tree and it does not have its own chip (i.e. pointing to parent's chip instance), then it results in sconfig emiiting parent's chip instance (which can be the SoC chip instance) in static.c even though it is unused. This is because update_chip_pointers() does not call delete_chip_instance() before reassigning the chip instance pointer. b) If a device is added under root device only in the override tree and it does not have its own chip instance (i.e. uses SoC chip instance), then it results in sconfig emitting a copy of the SoC chip instance and setting that as chip_ops for this new device in the override tree. In order to fix the above issues, this change drops the ref_count field from chip_instance structure and instead adds a forwarding pointer `base_chip_instance`. This is setup as per the following rules: 1. If the instance belongs to base devicetree, base_chip_instance is set to NULL. 2. If the instance belongs to override tree, then it is set to its corresponding chip instance in base tree (if present), else set to NULL. State of base_chip_instance is then used when emitting chips and devices using the following rules: 1. If a chip_instance has non-NULL base_chip_instance, then that chip instance is not emitted to static.c 2. When emitting chip_ops for a device, base_chip_instance is used to determine the correct chip instance name to emit. BUG=b:155549176 TEST=Verified that the static.c file generated for base/override tree combination is correct when new devices without chips are added only to override tree. Change-Id: Idbb5b34f49bf874da3f30ebb6a6a0e2d8d091fe5 Signed-off-by: Furquan Shaikh <furquan(a)google.com> --- M util/sconfig/main.c M util/sconfig/sconfig.h 2 files changed, 30 insertions(+), 89 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/07/41007/1 diff --git a/util/sconfig/main.c b/util/sconfig/main.c index 951ad6d..186eedb 100644 --- a/util/sconfig/main.c +++ b/util/sconfig/main.c @@ -128,7 +128,6 @@ static struct chip_instance mainboard_instance = { .id = 0, .chip = &mainboard_chip, - .ref_count = 2, }; /* This is the parent of all devices added by parsing the devicetree file. */ @@ -337,54 +336,6 @@ return instance; } -static void delete_chip_instance(struct chip_instance *ins) -{ - - if (ins->ref_count == 0) { - printf("ERROR: ref count for chip instance is zero!!\n"); - exit(1); - } - - if (--ins->ref_count) - return; - - struct chip *c = ins->chip; - - /* Get pointer to first instance of the chip. */ - struct chip_instance *i = c->instance; - - /* - * If chip instance to be deleted is the first instance, then update - * instance pointer of the chip as well. - */ - if (i == ins) { - c->instance = ins->next; - free(ins); - return; - } - - /* - * Loop through the instances list of the chip to find and remove the - * given instance. - */ - while (1) { - if (i == NULL) { - printf("ERROR: chip instance not found!\n"); - exit(1); - } - - if (i->next != ins) { - i = i->next; - continue; - } - - i->next = ins->next; - break; - } - - free(ins); -} - /* * Allocate a new bus for the provided device. * - If this is the first bus being allocated under this device, then its id @@ -504,7 +455,6 @@ new_d->hidden = (status >> 1) & 0x01; new_d->mandatory = (status >> 2) & 0x01; new_d->chip_instance = chip_instance; - chip_instance->ref_count++; set_new_child(parent, new_d); @@ -780,6 +730,13 @@ struct chip_instance *chip_ins = ptr->chip_instance; int has_children = dev_has_children(ptr); + /* + * If the chip instance of device has base_chip_instance pointer set, then follow that + * to update the chip instance for current device. + */ + if (chip_ins->base_chip_instance) + chip_ins = chip_ins->base_chip_instance; + if (ptr == &base_root_dev) fprintf(fil, "DEVTREE_CONST struct device %s = {\n", ptr->name); else @@ -993,8 +950,14 @@ chip_id = 1; instance = chip->instance; while (instance) { - instance->id = chip_id++; - emit_chip_instance(fil, instance); + /* + * Emit this chip instance only if there is no forwarding pointer to the + * base tree chip instance. + */ + if (instance->base_chip_instance == NULL) { + instance->id = chip_id++; + emit_chip_instance(fil, instance); + } instance = instance->next; } } @@ -1082,29 +1045,6 @@ } /* - * Walk through the override subtree in breadth-first manner starting at node to - * see if chip_instance pointer of the node is same as chip_instance pointer of - * override parent that is passed into the function. If yes, then update the - * chip_instance pointer of the node to chip_instance pointer of the base - * parent. - */ -static void update_chip_pointers(struct device *node, - struct chip_instance *base_parent_ci, - struct chip_instance *override_parent_ci) -{ - struct queue_entry *q_head = NULL; - - enqueue_tail(&q_head, node); - - while ((node = dequeue_head(&q_head))) { - if (node->chip_instance != override_parent_ci) - continue; - node->chip_instance = base_parent_ci; - add_children_to_queue(&q_head, node); - } -} - -/* * Add resource to device. If resource is already present, then update its base * and index. If not, then add a new resource to the device. */ @@ -1287,6 +1227,12 @@ } /* + * Update base_chip_instance member in chip instance of override tree to forward it to + * the chip instance in base tree. + */ + override_dev->chip_instance->base_chip_instance = base_dev->chip_instance; + + /* * Now that the device properties are all copied over, look at each bus * of the override device and run override_devicetree in a recursive * manner. The assumption here is that first bus of override device @@ -1312,9 +1258,6 @@ override_bus = override_bus->next_bus; base_bus = base_bus->next_bus; } - - delete_chip_instance(override_dev->chip_instance); - override_dev->chip_instance = NULL; } /* @@ -1359,14 +1302,6 @@ * as a new child of base_parent. */ set_new_child(base_parent, override_child); - /* - * Ensure all nodes in override tree pointing to - * override parent chip_instance now point to base - * parent chip_instance. - */ - update_chip_pointers(override_child, - base_parent->dev->chip_instance, - override_parent->dev->chip_instance); } override_child = next_child; diff --git a/util/sconfig/sconfig.h b/util/sconfig/sconfig.h index a76506d..2603904 100644 --- a/util/sconfig/sconfig.h +++ b/util/sconfig/sconfig.h @@ -56,10 +56,16 @@ struct chip_instance *next; /* - * Reference count - Indicates how many devices hold pointer to this - * chip instance. + * Pointer to corresponding chip instance in base devicetree. + * a) If the chip instance belongs to the base devicetree, then this pointer is set to + * NULL. + * b) If the chip instance belongs to override tree, then this pointer is set to its + * corresponding chip instance in base devicetree (if it exists), else to NULL. + * + * This is useful when generating chip instances and chip_ops for a device to determine + * if this is the instance to emit or if there is a base chip instance to use instead. */ - int ref_count; + struct chip_instance *base_chip_instance; }; struct chip { -- To view, visit https://review.coreboot.org/c/coreboot/+/41007 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idbb5b34f49bf874da3f30ebb6a6a0e2d8d091fe5 Gerrit-Change-Number: 41007 Gerrit-PatchSet: 1 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

3 4

Change in coreboot[master]: mb/clevo/n141cu: Add new Comet Lake mainboard
by Angel Pons (Code Review) 07 May '20

07 May '20

Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40581 ) Change subject: mb/clevo/n141cu: Add new Comet Lake mainboard ...................................................................... Patch Set 31: (3 comments) https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/ramstage.c: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 11: Make M.2 port configurable (SATA <> > have a look at intel flex i/o. […] It usually boils down to configuring a GPIO properly https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/romstage.c: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 22: 0 Any reason to disable ECT? https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/variants/n141cu/devicetree.cb: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 35: subsystemid 0x1558 0x1403 you can inherit that -- To view, visit https://review.coreboot.org/c/coreboot/+/40581 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I9f83fab64e4cc9036698ca0fdd5edbb677d77eb9 Gerrit-Change-Number: 40581 Gerrit-PatchSet: 31 Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michael Niewöhner Gerrit-Comment-Date: Thu, 07 May 2020 12:31:35 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Michael Niewöhner Gerrit-MessageType: comment

1 0

Change in coreboot[master]: mb/clevo/n141cu: Add new Comet Lake mainboard
by Michael Niewöhner (Code Review) 07 May '20

07 May '20

1 0

Change in coreboot[master]: mb/clevo/n141cu: Add new Comet Lake mainboard
by Michael Niewöhner (Code Review) 07 May '20

07 May '20

Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/40581 ) Change subject: mb/clevo/n141cu: Add new Comet Lake mainboard ...................................................................... Patch Set 31: (7 comments) https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/Kconfig: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 18: select ONBOARD_VGA_IS_PRIMARY does it really have ga? https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 38: default "clevo/cml-u" : : config VARIANT_DIR : default "n141cu" : : config MAINBOARD_FAMILY : default "Comet Lake" : hmm, are there multiple latops that are expected to be mostly idenatical or at least very similar? https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/board_info.txt: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 2: Board name: cml-u that's not the board/laptop name, is it? https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/ramstage.c: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 11: Make M.2 port configurable (SATA <> have a look at intel flex i/o. that should be possible to be handled outmagically if they didn't mess it up 😊 https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/variants/n141cu/devicetree.cb: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 169: register "deep_s3_enable_ac" = "0" you can drop the 0 values, since they are default https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/variants/n141cu/gma-mainboard.ads: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 13: P1, : DP2, : DP3, : HDMI1, : HDMI2, : HDMI3, : eDP, : others so many ports? https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… File src/mainboard/clevo/cml-u/variants/n141cu/include/gpio_table.h: https://review.coreboot.org/c/coreboot/+/40581/31/src/mainboard/clevo/cml-u… PS31, Line 91: 0x04000201 this will trigger an error "gpio_pad_reset_config_override: Logical to Chipset mapping not found" due to the reset mapping; replace 0x0... with 0xc... -- To view, visit https://review.coreboot.org/c/coreboot/+/40581 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I9f83fab64e4cc9036698ca0fdd5edbb677d77eb9 Gerrit-Change-Number: 40581 Gerrit-PatchSet: 31 Gerrit-Owner: Felix Singer <felixsinger(a)posteo.net> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michael Niewöhner Gerrit-Comment-Date: Thu, 07 May 2020 12:24:09 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in coreboot[master]: util/sconfig: Move chip instance id assignment to emit_chips()
by Furquan Shaikh (Code Review) 07 May '20

07 May '20

Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41006 ) Change subject: util/sconfig: Move chip instance id assignment to emit_chips() ...................................................................... util/sconfig: Move chip instance id assignment to emit_chips() This change moves the assignment of id for chip instance from new_chip_instance() to emit_chips(). This is similar to the previous change for moving dev id assignment to happen much later. It allows chips to use same ids when enabling override trees for a mainboard. BUG=b:155549176 Change-Id: I3efa9af5ed91123675be42bce1cb389bad19cb62 Signed-off-by: Furquan Shaikh <furquan(a)google.com> --- M util/sconfig/main.c 1 file changed, 3 insertions(+), 7 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/06/41006/1 diff --git a/util/sconfig/main.c b/util/sconfig/main.c index 27fca44..951ad6d 100644 --- a/util/sconfig/main.c +++ b/util/sconfig/main.c @@ -30,12 +30,6 @@ */ static struct chip chip_header; -/* - * This is intentionally shared between chip and device structure ids because it - * is easier to track the order of parsing for chip and device. - */ -static int count = 0; - typedef enum { UNSLASH, SPLIT_1ST, @@ -336,7 +330,6 @@ struct chip *chip = get_chip(path); struct chip_instance *instance = S_ALLOC(sizeof(*instance)); - instance->id = ++count; instance->chip = chip; instance->next = chip->instance; chip->instance = instance; @@ -987,6 +980,7 @@ { struct chip *chip = chip_header.next; struct chip_instance *instance; + int chip_id; emit_chip_headers(fil, chip); @@ -996,8 +990,10 @@ if (!chip->chiph_exists) continue; + chip_id = 1; instance = chip->instance; while (instance) { + instance->id = chip_id++; emit_chip_instance(fil, instance); instance = instance->next; } -- To view, visit https://review.coreboot.org/c/coreboot/+/41006 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I3efa9af5ed91123675be42bce1cb389bad19cb62 Gerrit-Change-Number: 41006 Gerrit-PatchSet: 1 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

2 3

Change in coreboot[master]: util/sconfig: Drop id from struct device maintained by sconfig
by Furquan Shaikh (Code Review) 07 May '20

07 May '20

Furquan Shaikh has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/41005 ) Change subject: util/sconfig: Drop id from struct device maintained by sconfig ...................................................................... util/sconfig: Drop id from struct device maintained by sconfig This change drops the id field from struct device as used by sconfig. It was primarily used for generating unique device names. This was maintained within device structure so that the order in which the device tree entries were parsed is clear. Since the ids are assigned in parsing order, it is problematic when a device is moved from base devicetree to override tree. The entire parsing order changes which makes it really difficult to compare what really changed in static.c file. By moving the dev name assignment to happen later when doing pass0 of static.c generation, the difference in static.c file is minimized when adding support for override trees. BUG=b:155549176 Change-Id: I31870ace5a2fd7d5f95ab5e30d794c3bc959ed46 Signed-off-by: Furquan Shaikh <furquan(a)google.com> --- M util/sconfig/main.c M util/sconfig/sconfig.h 2 files changed, 7 insertions(+), 14 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/05/41005/1 diff --git a/util/sconfig/main.c b/util/sconfig/main.c index b48f992..27fca44 100644 --- a/util/sconfig/main.c +++ b/util/sconfig/main.c @@ -98,7 +98,6 @@ static struct device base_root_dev = { .name = "dev_root", - .id = 0, .chip_instance = &mainboard_instance, .path = " .type = DEVICE_PATH_ROOT ", .parent = &base_root_bus, @@ -113,7 +112,6 @@ static struct device override_root_dev = { .name = "override_root", - .id = 0, /* * Override tree root device points to the same mainboard chip instance * as the base tree root device. It should not cause any side-effects @@ -429,7 +427,6 @@ { struct device *dev = S_ALLOC(sizeof(*dev)); - dev->id = ++count; dev->parent = parent; dev->subsystem_vendor = -1; dev->subsystem_device = -1; @@ -510,10 +507,6 @@ new_d->path_a = path_a; new_d->path_b = path_b; - char *name = S_ALLOC(10); - sprintf(name, "_dev%d", new_d->id); - new_d->name = name; - new_d->enabled = status & 0x01; new_d->hidden = (status >> 1) & 0x01; new_d->mandatory = (status >> 2) & 0x01; @@ -699,12 +692,18 @@ static void pass0(FILE *fil, FILE *head, struct device *ptr, struct device *next) { + static int dev_id; + if (ptr == &base_root_dev) { fprintf(fil, "STORAGE struct bus %s_links[];\n", ptr->name); return; } + char *name = S_ALLOC(10); + sprintf(name, "_dev%d", dev_id++); + ptr->name = name; + fprintf(fil, "STORAGE struct device %s;\n", ptr->name); if (ptr->res) fprintf(fil, "STORAGE struct resource %s_res[];\n", diff --git a/util/sconfig/sconfig.h b/util/sconfig/sconfig.h index 60842f1..a76506d 100644 --- a/util/sconfig/sconfig.h +++ b/util/sconfig/sconfig.h @@ -43,10 +43,7 @@ struct chip; struct chip_instance { - /* - * Monotonically increasing ID for each newly allocated - * node(chip/device). - */ + /* Monotonically increasing ID for each chip instance. */ int id; /* Pointer to registers for this chip. */ @@ -98,9 +95,6 @@ }; struct device { - /* Monotonically increasing ID for the device. */ - int id; - /* Indicates device status (enabled / hidden or not). */ int enabled; int hidden; -- To view, visit https://review.coreboot.org/c/coreboot/+/41005 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I31870ace5a2fd7d5f95ab5e30d794c3bc959ed46 Gerrit-Change-Number: 41005 Gerrit-PatchSet: 1 Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-MessageType: newchange

2 2

Change in coreboot[master]: soc/intel/xeon_sp: make CPX ramstage.h common for CPX, SKX
by Michael Niewöhner (Code Review) 07 May '20

07 May '20

Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41116 ) Change subject: soc/intel/xeon_sp: make CPX ramstage.h common for CPX, SKX ...................................................................... Patch Set 4: (2 comments) https://review.coreboot.org/c/coreboot/+/41116/3//COMMIT_MSG Commit Message: https://review.coreboot.org/c/coreboot/+/41116/3//COMMIT_MSG@9 PS3, Line 9: [1] > I do not see the reference? Done https://review.coreboot.org/c/coreboot/+/41116/3//COMMIT_MSG@9 PS3, Line 9: CB:41106 revealed > well, it was late .... […] Done -- To view, visit https://review.coreboot.org/c/coreboot/+/41116 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I9cd25edd167ec71ee98c7ffa4fa6f95ca73a75e9 Gerrit-Change-Number: 41116 Gerrit-PatchSet: 4 Gerrit-Owner: Michael Niewöhner Gerrit-Reviewer: Andrey Petrov <andrey.petrov(a)gmail.com> Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com> Gerrit-Reviewer: Johnny Lin Gerrit-Reviewer: Jonathan Zhang <jonzhang(a)fb.com> Gerrit-Reviewer: Maxim Polyakov <max.senia.poliak(a)gmail.com> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 07 May 2020 11:00:56 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Paul Menzel <paulepanter(a)users.sourceforge.net> Comment-In-Reply-To: Michael Niewöhner Gerrit-MessageType: comment

1 0

Change in coreboot[master]: soc/amd/picasso: fix iomap for ACPI_PM
by Paul Menzel (Code Review) 07 May '20

07 May '20

Paul Menzel has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41128 ) Change subject: soc/amd/picasso: fix iomap for ACPI_PM ...................................................................... Patch Set 2: (1 comment) https://review.coreboot.org/c/coreboot/+/41128/2//COMMIT_MSG Commit Message: https://review.coreboot.org/c/coreboot/+/41128/2//COMMIT_MSG@9 PS2, Line 9: offsets for ACPI_PM are incorrectly configured for picasso SoC. Any idea why? Error in the datasheet? Why do you know, that yours are correct? -- To view, visit https://review.coreboot.org/c/coreboot/+/41128 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I6adf71479c30f5b6751a21edc4bfa311ddbef5ec Gerrit-Change-Number: 41128 Gerrit-PatchSet: 2 Gerrit-Owner: Kangheui Won <khwon(a)chromium.org> Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Raul Rangel <rrangel(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Comment-Date: Thu, 07 May 2020 10:59:57 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in coreboot[master]: mainboard(s): drop redundant entries from Makefiles
by Michael Niewöhner (Code Review) 07 May '20

07 May '20

Michael Niewöhner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/41107 ) Change subject: mainboard(s): drop redundant entries from Makefiles ...................................................................... Uploaded patch set 7: New patch set was added with same tree, parent, and commit message as Patch Set 6. -- To view, visit https://review.coreboot.org/c/coreboot/+/41107 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I1961646c5ed4ae6a1308ce0e8e15792970da4e0d Gerrit-Change-Number: 41107 Gerrit-PatchSet: 7 Gerrit-Owner: Michael Niewöhner Gerrit-Reviewer: Alexander Couzens <lynxis(a)fe80.eu> Gerrit-Reviewer: Christian Walter <christian.walter(a)9elements.com> Gerrit-Reviewer: David Guckian <david.guckian(a)intel.com> Gerrit-Reviewer: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Martin Roth <martinroth(a)google.com> Gerrit-Reviewer: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: Philipp Hug <philipp(a)hug.cx> Gerrit-Reviewer: Piotr Król <piotr.krol(a)3mdeb.com> Gerrit-Reviewer: Tristan Corrick <tristan(a)corrick.kiwi> Gerrit-Reviewer: Vanessa Eusebio <vanessa.f.eusebio(a)intel.com> Gerrit-Reviewer: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Reviewer: Wim Vervoorn <wvervoorn(a)eltan.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Reviewer: ron minnich <rminnich(a)gmail.com> Gerrit-Comment-Date: Thu, 07 May 2020 10:54:55 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit May 2020