coreboot March 2016

coreboot@coreboot.org

43 participants
117 discussions

HEADS UP GSoC: students need to publish their proposals in the next ~30 hours
by Patrick Georgi 24 Mar '16

24 Mar '16

Hi all, if you're considering to apply for a project at this year's GSoC: Proposals need to be pushed into the system (summerofcode.withgoogle.com) within the next day or so ("ends 25 March, 2016 at 19:00 UTC" according to https://developers.google.com/open-source/gsoc/faq#when_can_students_apply_…). Not a draft, not a Google doc somewhere, but a real published "PDF proposal" (as they call it on my dashboard). Based on previous experience, the GSoC team is quite adamant in enforcing the deadlines with no exceptions (unless they screw up somehow; I wouldn't count on that), so make sure your proposal is in good standing in time. Don't wait for the last minute either, their system may be a bit crowded then. If things go wrong for you at this point, there's nothing we (coreboot GSoC project admins and mentors) can do about it. Regards, 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

1 0

Fwd: Upstream coreboot on Broadwell/samus
by Huimin Zhang 24 Mar '16

24 Mar '16

---------- Forwarded message ---------- From: Huimin Zhang <thehobn(a)gmail.com> Date: Wed, Mar 23, 2016 at 2:22 PM Subject: Re: [coreboot] Upstream coreboot on Broadwell/samus To: Patrick Georgi <pgeorgi(a)google.com> coolstar's ROM turns out to be working for samus with some minor issues, so I will be studying his patches to see what the regressions are. Thanks for your comments on my proposal by the way, Min On Wed, Mar 23, 2016 at 2:26 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2016-03-22 9:35 GMT+01:00 Huimin Zhang <thehobn(a)gmail.com>: > > I was under the impression that coreboot support for the Broadwell > > Chromebooks such as the new Chromebook Pixel was upstreamed but I am > having > > trouble getting it to work. > Everything should be upstreamed, yes. However there isn't any > automated testing for upstream on Chromebook devices at this time, so > things may break down the road. > > > unintentional error can be ruled out. Perhaps I am missing some small > detail > > regarding the build settings specific to Broadwell? > It's hard to say what exactly goes wrong with your setup. I can test > (since I have a samus with servo header around), but in general, the > first requirement to debug coreboot issues is to grab its console > somehow. > > > 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 >

1 0

Re: [coreboot] Logs storage? Was: Target candidate: Dell Latitude E4300
by Denis 'GNUtoo' Carikli 24 Mar '16

24 Mar '16

On Thu, 17 Mar 2016 15:27:56 -0600 Martin Roth <gaumless(a)gmail.com> wrote: > I think that having OEM BIOS logs from supported boards does make a > lot of sense, but when I talked to Stefan about it before, he didn't > want to add unsupported boards. His thinking was that we didn't want > to be the world's largest lspci database Right, I didn't think about this issue. Given the amount of effort needed to port coreboot to new chipsets, how big would such database be, if we limit it to chipsets we support. For instance northbridges and southbridges (if it applies). We could also want to only whitelist specific chipset combinations beforehand. Example1: We might want some information on Lenovo Thinkpad laptops with supported northbridge and southbridge. Example2: Someone is looking for hardware with specific requirements to do a port. In both examples, the submission script will whitelist that combination. Denis.

1 0

How to repair Pomona clips, Was: Good source for SOIC clips
by Denis 'GNUtoo' Carikli 24 Mar '16

24 Mar '16

On Sat, 19 Mar 2016 20:19:00 +0100 thomasg <thomas(a)gstaedtner.net> wrote: > These are certainly much cheaper than the expensive ones available in > the "west" - though I don't know if the quality is adequate. > Should you order some it would probably be interesting to give > feedback on that. I've a SOIC-8 Pomona clip. I used it very extensively when I was working on replacing the VGA option ROM for the Lenovo X60. The Pomona clip I have is composed of plastic and long metallic pins. After my extensive use, the metallic pins are now bent, that prevents them from reaching the SOIC-8 chip. You can easily detect that when trying to connect the Pomona clip: the clip tend not to stay in place anymore, and you have a very hard time preventing it from being disconnected from the chip. My solution was, to disassemble the clip, that means removing the metal part in the middle that keeps everything together. Then inside, at some point, pins are bent at 90 degrees (that's normal) but they didn't stick to the plastic. Good state: ----------- Connection +----------------- SOIC-8 chip pin to the external | flasher ------------+ Bad state: ---------- Connection +--------------- SOIC-8 chip pin to the external / flasher ----------+ So here just pushing the pin from the "Connection to the external flasher" side, near the 90 degree bending, with a needle or a screwdriver did the trick. Then at some point it bends again, so you repair it again and so on. After a while the pins, on the SOIC-8 side start detaching themselves from the plastic. So I glued them. I can still use my clip, even if it's way harder to use it right than before, positioning it is harder, and you might need to keep it in place with one hand, while typing the flashing commands with the other hand. Solution: --------- You probably don't need to externally reflash that often: Assuming you work on code that makes your board not boot, just use the normal/fallback mechanism. Since it's not human-error proof, you still need an external flasher in case something goes wrong. Also an external flasher is very useful if you have no other way to reflash coreboot/libreboot when running the stock BIOS. It is also mandatory if you want to make sure that the image you intended to flash was really flashed unmodified on the flash chip. SMM/SMI and various southbridges makes it way too easy to implement rootkits that modifies what is read or written from the flash, on the fly: such southbridge can be programmed to emit an SMI interrupt when the flash is accessed. Then whatever code that is running in SMM, can potentially modify what is being read or flashed, before the CPU returns to its previous context. Denis.

1 0

Re: [coreboot] [GSoC 2016] Proposal review
by ron minnich 24 Mar '16

24 Mar '16

Actually, this seems a pretty good proposal in its current state, but not my one comment. thanks ron On Wed, Mar 23, 2016 at 12:14 PM ron minnich <rminnich(a)gmail.com> wrote: > Thanks, now I understand, and I will try to get to this tonight. Sorry to > be causing your worries. > > ron > > On Wed, Mar 23, 2016 at 12:09 PM Yurii Shevtsov <ungetch(a)gmail.com> wrote: > >> I'm not complaining. I'm just worrying, only two days left till >> submission deadline, and, who knows, maybe people forget. I'll be patient >> >> 2016-03-23 20:55 GMT+02:00 ron minnich <rminnich(a)gmail.com>: >> >>> you need to be patient. All the reviewers have day jobs and there is a >>> lot of work in all this. >>> >>> There's no advantage to you or your proposal in complaining about the >>> reviewers, I think. >>> >>> >> Thanks for you reply. I'm not complaining. I'm just worrying, only two >> days left till submission deadline, and, who knows, maybe people forget. >> >>> ron >>> >>> >>> >>

1 0

Re: [coreboot] [GSoC 2016] Proposal review
by ron minnich 24 Mar '16

24 Mar '16

Thanks, now I understand, and I will try to get to this tonight. Sorry to be causing your worries. ron On Wed, Mar 23, 2016 at 12:09 PM Yurii Shevtsov <ungetch(a)gmail.com> wrote: > I'm not complaining. I'm just worrying, only two days left till submission > deadline, and, who knows, maybe people forget. I'll be patient > > 2016-03-23 20:55 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > >> you need to be patient. All the reviewers have day jobs and there is a >> lot of work in all this. >> >> There's no advantage to you or your proposal in complaining about the >> reviewers, I think. >> >> > Thanks for you reply. I'm not complaining. I'm just worrying, only two > days left till submission deadline, and, who knows, maybe people forget. > >> ron >> >> >> >

1 0

Re: [coreboot] [GSoC 2016] Proposal review
by Yurii Shevtsov 24 Mar '16

24 Mar '16

I'm not complaining. I'm just worrying, only two days left till submission deadline, and, who knows, maybe people forget. I'll be patient 2016-03-23 20:55 GMT+02:00 ron minnich <rminnich(a)gmail.com>: > you need to be patient. All the reviewers have day jobs and there is a lot > of work in all this. > > There's no advantage to you or your proposal in complaining about the > reviewers, I think. > > Thanks for you reply. I'm not complaining. I'm just worrying, only two days left till submission deadline, and, who knows, maybe people forget. > ron > > >

1 0

Re: [coreboot] [GSoC 2016] Proposal review
by ron minnich 24 Mar '16

24 Mar '16

you need to be patient. All the reviewers have day jobs and there is a lot of work in all this. There's no advantage to you or your proposal in complaining about the reviewers, I think. ron On Wed, Mar 23, 2016 at 11:37 AM Yurii Shevtsov <ungetch(a)gmail.com> wrote: > Seems like making draft public doesn't make any difference > > 2016-03-17 23:26 GMT+02:00 Yurii Shevtsov <ungetch(a)gmail.com>: > >> >> >> 2016-03-17 23:00 GMT+02:00 David Hendricks <dhendrix(a)google.com>: >> >>> >>> On Thu, Mar 17, 2016 at 1:39 PM, Yurii Shevtsov <ungetch(a)gmail.com> >>> wrote: >>> >>>> Hello. Three days passed, but unfortunately I haven't got any feedback >>>> on my draft yet. >>>> >>> >>> If you make the doc public then you might get more responses. >>> >> >> David, you convinced me. Thanks for your advice. Now it's public! >> >> https://docs.google.com/document/d/1rxKXzbaq9w4EthVIP2O5mqXaTJTzK3IKsnbVOWv… >> >>> >>> Martin and Ron are both very busy people and might simply have been too >>> busy with work this week. >>> >>> GSOC is all about open source coding and community engagement. Keeping >>> your doc private is not a good way to start... >>> >>> >>>> Although, I can see Martin Roth is watching my proposal. Also I'm still >>>> not assigned to any task. Spare me some time, please :-) >>>> Thanks in advance >>>> >>>> 2016-03-14 23:11 GMT+02:00 Yurii Shevtsov <ungetch(a)gmail.com>: >>>> >>>>> I know we haven't discussed project properly yet, and I understand my >>>>> vision of project may vary from yours. So feel free to point me on a right >>>>> way :-) >>>>> Here is the link: >>>>> >>>>> https://docs.google.com/document/d/1OWOYfKMUSZTi4tTHmGIIY27KAbM5MJVV0Ddirjp… >>>>> >>>>> I made my proposal draft private. As for now I shared it with Ron >>>>> Minnich and Martin Roth. If you part of a GSoC commission, I'll add you too >>>>> (head to the doc link). >>>>> >>>>> Unfortunately, I haven't submitted any patch yet. Please, assign me to >>>>> a task. >>>>> >>>> >>>> >>>> -- >>>> coreboot mailing list: coreboot(a)coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> >>> >>> -- >>> David Hendricks (dhendrix) >>> Systems Software Engineer, Google Inc. >>> >> >> >

1 0

Re: [coreboot] [GSoC 2016] Proposal review
by Yurii Shevtsov 24 Mar '16

24 Mar '16

Seems like making draft public doesn't make any difference 2016-03-17 23:26 GMT+02:00 Yurii Shevtsov <ungetch(a)gmail.com>: > > > 2016-03-17 23:00 GMT+02:00 David Hendricks <dhendrix(a)google.com>: > >> >> On Thu, Mar 17, 2016 at 1:39 PM, Yurii Shevtsov <ungetch(a)gmail.com> >> wrote: >> >>> Hello. Three days passed, but unfortunately I haven't got any feedback >>> on my draft yet. >>> >> >> If you make the doc public then you might get more responses. >> > > David, you convinced me. Thanks for your advice. Now it's public! > > https://docs.google.com/document/d/1rxKXzbaq9w4EthVIP2O5mqXaTJTzK3IKsnbVOWv… > >> >> Martin and Ron are both very busy people and might simply have been too >> busy with work this week. >> >> GSOC is all about open source coding and community engagement. Keeping >> your doc private is not a good way to start... >> >> >>> Although, I can see Martin Roth is watching my proposal. Also I'm still >>> not assigned to any task. Spare me some time, please :-) >>> Thanks in advance >>> >>> 2016-03-14 23:11 GMT+02:00 Yurii Shevtsov <ungetch(a)gmail.com>: >>> >>>> I know we haven't discussed project properly yet, and I understand my >>>> vision of project may vary from yours. So feel free to point me on a right >>>> way :-) >>>> Here is the link: >>>> >>>> https://docs.google.com/document/d/1OWOYfKMUSZTi4tTHmGIIY27KAbM5MJVV0Ddirjp… >>>> >>>> I made my proposal draft private. As for now I shared it with Ron >>>> Minnich and Martin Roth. If you part of a GSoC commission, I'll add you too >>>> (head to the doc link). >>>> >>>> Unfortunately, I haven't submitted any patch yet. Please, assign me to >>>> a task. >>>> >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> >> -- >> David Hendricks (dhendrix) >> Systems Software Engineer, Google Inc. >> > >

1 0

Re: [coreboot] [Xen-users] Enabling AMD-Vi IOMMU panics Xen
by 小太 24 Mar '16

24 Mar '16

On Tue, Mar 22, 2016 at 2:24 AM, Nick <nochristrequired(a)gmail.com> wrote: > Have you ever seen an IOAPIC (associated with a southbridge) that has a > PCI device id? > > I haven't seen one with a PCI device id... Although I only have experience > with older southbridges - in this case, they were mapped to some fixed > memory address (the range is probably configurable somewhere in the PCI > configuration space, depending on the chipset.) > No, and from the IOMMU spec I linked, it suggests that it's not enumerable. I'm not sure *why* the IOMMU needs a PCI device IDs for the IOAPICs yet, but the system definitely can't boot with interrupt remapping enabled without knowing the IOAPIC device IDs. That said, under normal usage (i.e., without the IOMMU on), they still are mapped to some fixed memory address. (Here's the full thread on the xen-users mailing list for context: http://xen.1045712.n5.nabble.com/Enabling-AMD-Vi-IOMMU-panics-Xen-td5731305… ) On the original issue, further investigation has shown that the non-northbridge (i.e., southbridge) IOAPIC is always mapped to 0xFEC00000 (Section 3.26.8 of the Family 16h Models 30h-3Fh BKDG), which from Xen's dmesg output would conclude it is IOAPIC[0] = IOAPIC #4, leaving the northbridge IOAPIC as IOAPIC[1] = IOAPIC #5. >From the information in the Linux and Xen source code, we know the southbridge's IOAPIC is at the device ID 00:14.0, so half of the problem has been solved (Though I'm still interested in how we know it's at 00:14.0 - the two AMD IOMMU maintainers I emailed haven't replied yet) I might try going through all the IDs that lspci lists on bus 00 to see if one works... P.S., I just realised that "device ID" could also refer to the vendor:device ID pair, but in this case, I mean the bus ID (i.e, the bus:device.function triplet), which is what the IOMMU spec uses when they say "device ID"

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2016