coreboot September 2011

coreboot@coreboot.org

40 participants
224 discussions

Re: [coreboot] ARM SoC ID
by David Hendricks 12 Sep '11

12 Sep '11

On Sun, Sep 11, 2011 at 3:53 PM, tiho taskov <tihokibertron(a)gmail.com>wrote: > I want to know what stance the coreboot community is taking on the > issue with identifying basic initialization parameters for a > pre-compiled linux kernel booting on a random SoC. > >From Coreboot's perspective, this sort of thing should be handled in the payload / bootloader (SeaBIOS, GRUB/GRUB2, etc). FWIW, there have also been discussions about using U-Boot as a payload for Coreboot: http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/ . One advantage of the U-Boot approach is that U-Boot supports the Flattened Device Tree (FDT) which is useful for passing init parameters, device topology, etc. to Linux. AFAIK, this is the standard approach for PowerPC, is gaining popularity for ARM, and can also be applied to x86. Here are some additional resources if this interests you: 2011 Linux Plumbers Conference talk: http://linuxplumbersconf.org/ocw/proposals/47 2010 Embedded Linux Conference talk: http://elinux.org/images/b/b6/ARM_Device_Tree_Status_Report.pdf -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

barbarians at the gates
by Peter Schmidt 12 Sep '11

12 Sep '11

Hi, seems like more and more dongle-functionality is going into UEFI: http://www.h-online.com/security/news/item/Windows-8-to-include-secure-boot… http://vr-zone.com/articles/the-upgrade-path-to-ivy-bridge-might-be-blocked… Since their "Next-Gen" "Trusted Computing" "Deep Shit" was an utter failure, one could expect, that sooner or later they would be at the gates again with this, "functionality". Besides spreading the word around, that there IS an alternative to UEFI, what else can I as a customer do, to ensure there will always be at least a few mainboards which run fully stable (and maybe even out-of-the-box) with coreboot (+SeaBIOS/GRUB) ? 1. Preferring hardware with such support? Sure. This filter here http://gh.de/?cat=mbson&sort=p allows me to filter for all sorts of stuff, but not, for coreboot support. That is just sad. Only by accident do I know, that this http://gh.de/610927 IS already supported by coreboot. I stumbled upon the information in the http://www.coreboot.org/Supported_Motherboards but really only accidentally, because I did not search, because I did not expect that new (= currently purchasable) boards are supported by coreboot! That is why me thinks, spreading the word, is not such a bad idea, and quite necessary. How to do that, without sounding like a zealot? The decision for coreboot, is not so much about today, is also about the products available in 5 or 10 years from now on! 2. Actually buying that hardware. Definitely! Probably for Christmas I am going to set up a HTPC, I'll use a mainboard with coreboot support. **But** how do I make it crystal clear to the seller/manufacturer that the coreboot-support is the reason that make me buy this particular product and not all the marketing bla bla? Any ideas? I do not want to write some lame e-mail claiming or demanding something. The moment I give him my money in exchange for the product, I really would like him to understand, that is is the coreboot support I am after. All mainboards have PCIe and DRAM banks, but the one I am buying, has coreboot support.

4 5

I am reading the source code of coreboot, how do I understand the functions
by Jianmin Pan 12 Sep '11

12 Sep '11

I am a newbie to coreboot, I am wondering is there an easy approach to understand the functions. For instance, when I am reading fallback_boot.c, it's very difficult for me to understand such functions as inb(), outb(),RTC_PORT(). The method I am using now is to grep the function name and find out which file it is in. Then read it. However, I still feel inconvenient. I am used to use vim. So, anybody have good suggestions?

1 0

Patch merged into coreboot/master: 936fb7f inteltool: added more device IDs
by gerrit＠coreboot.org 12 Sep '11

12 Sep '11

the following patch was just integrated into master: commit 936fb7f5689917bbed45a9e21eda6685b27d0f9a Author: Ruud Schramp <schramp(a)holmes.nl> Date: Mon Apr 4 07:53:19 2011 +0200 inteltool: added more device IDs Change-Id: I6f2272ae4071025e671638e83bade6a96aac658b Signed-off-by: Ruud Schramp <schramp(a)holmes.nl> Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> See http://review.coreboot.org/185 for details. -gerrit

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 12 Sep '11

12 Sep '11

1 0

Patch set updated for coreboot: 936fb7f inteltool: added more device IDs
by Patrick Georgi 12 Sep '11

12 Sep '11

Patrick Georgi (patrick(a)georgi-clan.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/185 -gerrit commit 936fb7f5689917bbed45a9e21eda6685b27d0f9a Author: Ruud Schramp <schramp(a)holmes.nl> Date: Mon Apr 4 07:53:19 2011 +0200 inteltool: added more device IDs Change-Id: I6f2272ae4071025e671638e83bade6a96aac658b Signed-off-by: Ruud Schramp <schramp(a)holmes.nl> Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> --- util/inteltool/inteltool.c | 2 ++ util/inteltool/inteltool.h | 2 ++ util/inteltool/memory.c | 2 ++ util/inteltool/pcie.c | 6 ++++++ 4 files changed, 12 insertions(+), 0 deletions(-) diff --git a/util/inteltool/inteltool.c b/util/inteltool/inteltool.c index a416106..93169d3 100644 --- a/util/inteltool/inteltool.c +++ b/util/inteltool/inteltool.c @@ -80,6 +80,8 @@ static const struct { { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH0, "ICH0" }, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH, "ICH" }, { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371XX, "82371AB/EB/MB" }, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_X44, "82X38/X48" }, + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_32X0, "3200/3210" }, }; #ifndef __DARWIN__ diff --git a/util/inteltool/inteltool.h b/util/inteltool/inteltool.h index ca8066f..bddd17c 100644 --- a/util/inteltool/inteltool.h +++ b/util/inteltool/inteltool.h @@ -78,6 +78,8 @@ #define PCI_DEVICE_ID_INTEL_82Q35 0x29b0 #define PCI_DEVICE_ID_INTEL_82G33 0x29c0 #define PCI_DEVICE_ID_INTEL_82Q33 0x29d0 +#define PCI_DEVICE_ID_INTEL_X44 0x29e0 +#define PCI_DEVICE_ID_INTEL_32X0 0x29f0 #define PCI_DEVICE_ID_INTEL_GS45 0x2a40 #define PCI_DEVICE_ID_INTEL_X58 0x3405 #define PCI_DEVICE_ID_INTEL_SCH_POULSBO 0x8100 diff --git a/util/inteltool/memory.c b/util/inteltool/memory.c index 256204c..9230419 100644 --- a/util/inteltool/memory.c +++ b/util/inteltool/memory.c @@ -109,6 +109,8 @@ int print_mchbar(struct pci_dev *nb, struct pci_access *pacc) printf("This northbridge does not have MCHBAR.\n"); return 1; case PCI_DEVICE_ID_INTEL_GS45: + case PCI_DEVICE_ID_INTEL_X44: + case PCI_DEVICE_ID_INTEL_32X0: mchbar_phys = pci_read_long(nb, 0x48) & 0xfffffffe; mchbar_phys |= ((uint64_t)pci_read_long(nb, 0x4c)) << 32; break; diff --git a/util/inteltool/pcie.c b/util/inteltool/pcie.c index 1ca57b6..4913150 100644 --- a/util/inteltool/pcie.c +++ b/util/inteltool/pcie.c @@ -45,6 +45,8 @@ int print_epbar(struct pci_dev *nb) case PCI_DEVICE_ID_INTEL_82Q35: case PCI_DEVICE_ID_INTEL_82G33: case PCI_DEVICE_ID_INTEL_82Q33: + case PCI_DEVICE_ID_INTEL_X44: + case PCI_DEVICE_ID_INTEL_32X0: case PCI_DEVICE_ID_INTEL_GS45: case PCI_DEVICE_ID_INTEL_ATOM_DXXX: case PCI_DEVICE_ID_INTEL_ATOM_NXXX: @@ -104,6 +106,8 @@ int print_dmibar(struct pci_dev *nb) case PCI_DEVICE_ID_INTEL_82Q35: case PCI_DEVICE_ID_INTEL_82G33: case PCI_DEVICE_ID_INTEL_82Q33: + case PCI_DEVICE_ID_INTEL_X44: + case PCI_DEVICE_ID_INTEL_32X0: case PCI_DEVICE_ID_INTEL_GS45: case PCI_DEVICE_ID_INTEL_ATOM_DXXX: case PCI_DEVICE_ID_INTEL_ATOM_NXXX: @@ -167,6 +171,8 @@ int print_pciexbar(struct pci_dev *nb) case PCI_DEVICE_ID_INTEL_82Q35: case PCI_DEVICE_ID_INTEL_82G33: case PCI_DEVICE_ID_INTEL_82Q33: + case PCI_DEVICE_ID_INTEL_X44: + case PCI_DEVICE_ID_INTEL_32X0: case PCI_DEVICE_ID_INTEL_GS45: case PCI_DEVICE_ID_INTEL_ATOM_DXXX: case PCI_DEVICE_ID_INTEL_ATOM_NXXX:

1 0

Patch merged into coreboot/master: 0e277fb Add acpi_get_sleep_type() to i82371eb and P2B _PTS/_WAK methods
by gerrit＠coreboot.org 12 Sep '11

12 Sep '11

the following patch was just integrated into master: commit 0e277fb131ed9eee75c1b1c6641b2ac7c2635165 Author: Tobias Diedrich <ranma+coreboot(a)tdiedrich.de> Date: Mon Dec 13 22:39:46 2010 +0100 Add acpi_get_sleep_type() to i82371eb and P2B _PTS/_WAK methods Build fix for src/arch/i386/boot/acpi.c if !CONFIG_SMP Also check for acpi_slp_type 2 in acpi_is_wakeup, since S2 uses the same acpi wakeup vector as S3. Add _PTS/_WAK methods to turn off/on the CPU/case fans and blink the power LED while sleeping. acpi_get_sleep_type() is in a seperate file i82371eb_wakeup.c because it is used in both romstage and ramstage after patch 3/3, whereas i82371eb_early_pm.c is used only in romstage. I used the name acpi_get_sleep_type instead of acpi_is_wakeup_early because I think acpi_is_wakeup_early is a bit misleading as a name since it doesn't return a boolean value. Other chipsets so far only ever set acpi_slp_type to 0 and 3, so the added check for acpi_slp_type == 2 (resume from S2) should not change behaviour of other boards: northbridge/intel/i945/northbridge.c:256:extern u8 acpi_slp_type; northbridge/intel/i945/northbridge.c:263: acpi_slp_type=0; northbridge/intel/i945/northbridge.c:267: acpi_slp_type=3; northbridge/intel/i945/northbridge.c:271: acpi_slp_type=0; southbridge/intel/i82801gx/i82801gx_lpc.c:171:extern u8 acpi_slp_type; southbridge/via/vt8237r/vt8237r_lpc.c:149:extern u8 acpi_slp_type; southbridge/via/vt8237r/vt8237r_lpc.c:238: acpi_slp_type = ((tmp & (7 << 10)) >> 10) == 1 ? 3 : 0 ; southbridge/via/vt8237r/vt8237r_lpc.c:239: printk(BIOS_DEBUG, "SLP_TYP type was %x %x\n", tmp, acpi_slp_type); Change-Id: I13feff0b8f49aa988e5467cdbef02981f0a6be8a Signed-off-by: Tobias Diedrich <ranma+coreboot(a)tdiedrich.de> Signed-off-by: Patrick Georgi <patrick(a)georgi-clan.de> See http://review.coreboot.org/188 for details. -gerrit

1 0

Re: [coreboot] Patrick, ARM SoC
by tiho taskov 12 Sep '11

12 Sep '11

Well, I heard that a possible solution would be including a standard formatted device ID string in silico. Would coreboot be useful for implementing this by passing it as a boot parameter?

1 0

Patch merged into coreboot/master: c2b6a77 Miscellaneous AMD F14 warning fixes
by gerrit＠coreboot.org 12 Sep '11

12 Sep '11

the following patch was just integrated into master: commit c2b6a778ca9c1b3a3cdee18b8d60c35891123d9e Author: efdesign98 <efdesign98(a)gmail.com> Date: Thu Aug 4 16:18:16 2011 -0600 Miscellaneous AMD F14 warning fixes This commit adds in some more fixes to AMD F14 compile warnings. The change in the mtrr.c file is in prep- aration for changes yet to com, but it is currently innocuous. Change-Id: I6b204fe0af16a97d982f46f0dfeaccc4b8eb883e Signed-off-by: Frank Vibrans <frank.vibrans(a)amd.com> Signed-off-by: efdesign98 <efdesign98(a)gmail.com> See http://review.coreboot.org/133 for details. -gerrit

1 0

ARM SoC ID
by tiho taskov 11 Sep '11

11 Sep '11

I want to know what stance the coreboot community is taking on the issue with identifying basic initialization parameters for a pre-compiled linux kernel booting on a random SoC.

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
23
Older →

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 September 2011