coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

[announce] flashrom 1.0-rc2
by Nico Huber 29 Dec '17

29 Dec '17

Hey folks, we've just tagged a release candidate for flashrom-1.0. It seems very stable; though, testing of this specific revision was rather limited [1]. So please test! especially if you use a rare setup (e.g. non-Linux / non-x86). If you don't use Git, you can find a tarball here: https://review.coreboot.org/cgit/flashrom.git/snapshot/flashrom-1.0-rc2.tar… Nico [1] Beside being used by developers, it's currently build tested on the following OS's (mostly thanks to Docker multiarch images): NetBSD 7.1 amd64 NetBSD 7.1 i386 alpine:amd64-v3.6 alpine:amd64-v3.7 alpine:i386-v3.6 alpine:i386-v3.7 centos:7.2-amd64-clean centos:7.3-aarch64-clean centos:7.3-amd64-clean debian-debootstrap:amd64-sid debian-debootstrap:amd64-stretch debian-debootstrap:armhf-stretch debian-debootstrap:i386-sid debian-debootstrap:i386-stretch debian-debootstrap:mips-stretch debian-debootstrap:mipsel-stretch debian-debootstrap:powerpc-sid debian-debootstrap:ppc64el-stretch fedora:24-x86_64 fedora:25-aarch64 fedora:25-ppc64le fedora:25-x86_64 ubuntu-debootstrap:amd64-xenial ubuntu-debootstrap:amd64-zesty ubuntu-debootstrap:arm64-xenial ubuntu-debootstrap:i386-xenial ubuntu-debootstrap:i386-zesty

2 1

Re: [coreboot] smd work
by Peter Stuge 29 Dec '17

29 Dec '17

Alberto Bursi wrote: > Basically you blob solder on all pins to have the thing heat up all > the pins together so you can then remove the chip. I would not recommend this method to a beginner reworking a consumer PCB. For an SO chip I would recommend buying a pair of fine tip pliers, e.g. Piergiacomi TR 20 or TR 25, and cutting all SO chip pins flush with the chip body. The chip body is then loose and can simply be removed, leaving only individual soldered pins. Pins can then be removed one at a time by simply touching the the solder pad with the soldering iron. Get a soldering iron with a fine flat tip (something like 2mm x 1mm is good) and ideally no less than 30 W, in order to ease rework of the ground pin. > Solder wick is magic stuff. Very recommended for any fine soldering job. It takes getting use to. Successfully using wick requires more heat, ie. a more powerful soldering station. Do use desoldering wick to clean solder off the pads after removing the pins one by one, but don't overdo it. Only rework each pad ONCE! Commerical PCBs can't be relied upon to tolerate very much heat beyond the original assembly - so rework should be swift. Once the wick has pulled most solder off the pad move on to the next pad, repeating for all pads. When soldering the new chip in, heat one pad and apply some solder onto the pad. Keep heating the pad and then place the chip with one pin into the flowed solder, with all pins aligned to the pads. Then solder the pin opposite to the first one for mechanical stability. Then solder the remaining pins. Use solder with a flux core. //Peter

1 0

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 29 Dec '17

29 Dec '17

Hi David, Thanks for your information. I still have same issue even tried to comment out the 1f.3 device in ./src/mainboard/intel/camelbackmountain_fsp/devicetree.cb then rebuild coreboot. Could you let me know how to do that? -Hilbert From: David Hendricks [mailto:david.hendricks@gmail.com] Sent: Friday, December 29, 2017 9:46 AM To: Hilbert Tu(杜睿哲_Pegatron) Cc: coreboot(a)coreboot.org Subject: Re: [coreboot] BDX-DE PCI init fail Hi Hilbert, Have you had any luck? I have a board with a similar problem. Commenting out the entry for device 1f.3 in devicetree.cb seemed to help (I copied src/mainboard/intel/camelbackmountain_fsp for my project). On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com<mailto:Hilbert_Tu@pegatroncorp.com>> wrote: Hi, I am porting coreboot on Intel BDX-DE platform and it gets stuck when init PCI 00:1f.3. This device should be SMBus, serial management bus. But I don’t know why this happened. Does anyone can give me some hint? Attached is my boot up log. Thanks in advance. -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(a)coreboot.org<mailto:coreboot@coreboot.org> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 29 Dec '17

29 Dec '17

Hello Peter, Peter Stuge wrote: >If you can handle the cost then you could design a (read-only, e.g. USB- attached flash memory appearing as a CD-ROM) medium *into* your hardware, which stores the source code corresponding to the object code which is in boot flash. I find that ideal. What you suggest is very much what I was thinking when I originally considered a microSD to house the source. My thought was to attach the microSD permanently to our system in such a way that our OS could read it (not the host PC OS). Then, from our Windows Control Panel application for our device, on an About tab, say, a user could click a button and get the source for the actual image used to boot the system, which of course would include the license and all other content needed to satisfy GPL. This would completely protect the microSD from write because we would not allow any means to write to it (though, we would probably allow removal for advanced users who really wanted to get directly to the drive - and GPLv3 might even require us to allow this). This is definitely doable, but, after some review of what we would need to do to make this work, it is more engineering work that I would really like to put into this, at least for a first-cut product. Still, this may be the only way we can move forward. Even with this, I am a bit concerned about whether this really meets the requirements of the license, but it seems very close. My main concern is about whether this kind of setup really meet the "conspicuous" requirement on presenting the license. You seem to think it would, which is encouraging. But, I remain a bit worried about the issue. Your specific suggestion of a USB connected Flash drive setup is also possible, and probably a bit less work for us - we would just need a built-in USB to USB hub or PCIe to USB host controller to allow for our device and the Flash drive to coexist on the same cable, but most flash USB drives are too physically big to work for us (resolvable, but probably not without adding more engineering effort - the USB connector alone is almost too big, and that means we might need to go to a board-mount drive - one more complication). And, there is a bit of a mess here under Windows because the Flash drive, if not controlled by our software, would just show up in Windows as a drive every time someone plugged in our device. This is fine from the point of view of meeting GPL requirements. But, at the least, this could be a real nuisance for users. And, it seems like it could also be quite confusing (I plugged in a measurement device and now I have a new drive. Where did that come from?). In any case, thank you for all of your suggestions and taking the time to reply to my query in detail. I need to spend some time on the technical issues of this kind of solution, and talk with some people here to see whether we can make sense of this kind of arrangement from the point of view of our customers. If that works, then I get to see whether I can convince legal that, what we intend to do technically, actually works to meet our interpretation of our legal obligations under the license. Ian

1 0

Re: [coreboot] BDX-DE PCI init fail
by David Hendricks 29 Dec '17

29 Dec '17

Hi Hilbert, Have you had any luck? I have a board with a similar problem. Commenting out the entry for device 1f.3 in devicetree.cb seemed to help (I copied src/mainboard/intel/camelbackmountain_fsp for my project). On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron) < Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi, > > > > I am porting coreboot on Intel BDX-DE platform and it gets stuck when init > PCI 00:1f.3. This device should be SMBus, serial management bus. But I > don’t know why this happened. Does anyone can give me some hint? Attached > is my boot up log. Thanks in advance. > > > > -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(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

ThinkPad X201 compile error
by Federico Amedeo Izzo 29 Dec '17

29 Dec '17

Hello, I wanted to update coreboot on my X201 from the Feb 2017 source (commit 068edc1c52cb1e5b6376ba7f296ef8797a24cd5f) to current master (commit f2e7b37c52cac5e7825d0e01b3c45c1506e99253) But when compiling it gives the following error ``` src/northbridge/intel/nehalem/gma.c: In function 'gma_func0_init': src/northbridge/intel/nehalem/gma.c:1066:5: error: implicit declaration of function 'intel_gma_init' [-Werror=implicit-function-declaration] intel_gma_init(conf, res2mmio(gtt_res, 0, 0),``` Now it's configured to load a VGA blob, if I enable "native graphics init" instead, the compile error goes away, but the resulting image does not boot (beep and flashing leds) I attached the configuration that gives the compilation error. Do you have any suggestions? Thanks, Federico

2 5

Re: [coreboot] smd work
by Alberto Bursi 28 Dec '17

28 Dec '17

If it's a one-off thing, then soldering iron with small tip (and possibly some temperature control), solder, thin solder wick, then watch some youtube videos to see how to use them for smd work. Basically you blob solder on all pins to have the thing heat up all the pins together so you can then remove the chip. For soldering you solder without caring too much about bridging pins with solder, then apply solder wick and soldering iron to suck up any excess solder. You basically waste a ton of solder. Solder wick is magic stuff. Very recommended for any fine soldering job. If you want to do this more than a few times, then get a hot air rework station, which is a box with an air pump connected to a tool with a tube (many also have a temperature-controlled soldering iron with a small tip) or hot air desoldering gun. SMD rework tools with hot air must have some kind of temperature control for their airflow, that's what makes them different from DIY-oriented hot air guns (those used to strip paint). Without temperature control on the airflow it will likely burn the board or the components. Again watching youtube videos helps, as you will have to heat up well the part, and don't pull with any real strenght, if some pin isn't fully unsoldered you will ruin the trace on the board and then it will get fun to try to fix that. -Alberto On 12/28/2017 06:47 PM, ron minnich wrote: A friend of mine wants to do some SPI rework. He wants a 16M part in his chromebook, not 8M. (hmm, so do I). Given the huge expertise of this group, I wonder if you have advice about equipment he should get. Soldering irons? hot air guns? magic wands? thanks ron

1 0

Re: [coreboot] smd work
by Alvaro G [Andor] 28 Dec '17

28 Dec '17

As Matt says: A small soldering iron, some flux and (de)soldering wick can get you trough. With an air gun will be much easier, but that depends on how much you wanna spend, and how many times will you do it :) On Thu, 28 Dec 2017 17:47:54 +0000 ron minnich <rminnich(a)gmail.com> wrote: > A friend of mine wants to do some SPI rework. He wants a 16M part in > his chromebook, not 8M. (hmm, so do I). Given the huge expertise of > this group, I wonder if you have advice about equipment he should get. > > Soldering irons? hot air guns? magic wands? > > thanks > > ron

1 0

Re: [coreboot] smd work
by Matt DeVillier 28 Dec '17

28 Dec '17

I've replaced SOIC-8 SPI chips with just a 15W soldering iron - the biggest issue is ensuring that the new chip has same voltage requirements as the old chip / board is providing. Many of the 8MB parts are 3.3v and most of the 16MB ones I've seen (at least in Chromebooks) are 1.8v On Thu, Dec 28, 2017 at 11:47 AM, ron minnich <rminnich(a)gmail.com> wrote: > A friend of mine wants to do some SPI rework. He wants a 16M part in his > chromebook, not 8M. (hmm, so do I). Given the huge expertise of this group, > I wonder if you have advice about equipment he should get. > > Soldering irons? hot air guns? magic wands? > > thanks > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

smd work
by ron minnich 28 Dec '17

28 Dec '17

A friend of mine wants to do some SPI rework. He wants a 16M part in his chromebook, not 8M. (hmm, so do I). Given the huge expertise of this group, I wonder if you have advice about equipment he should get. Soldering irons? hot air guns? magic wands? thanks ron

1 0

← Newer
1
2
3
4
5
6
7
...
18
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 December 2017