Re: [coreboot] BDX-DE PCI init fail

[Zoran Stojsavljevic]

> I still have same issue even tried to comment out
> the 1f.3 device in ./src/mainboard/intel/camel-
> backmountain_fsp/devicetree.cb then rebuild coreboot.

You wrote that you submitted the log. Is this the full log? I doubt. I
do NOT see physical memory layout as well as MTRR layout.

Could you, please, submit the full/complete log?

Which payload are you using? SeaBIOS?

Thank you,
Zoran

On Fri, Dec 29, 2017 at 5:58 AM, Hilbert Tu(杜睿哲_Pegatron)
 wrote:
> 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.hendri...@gmail.com]
> Sent: Friday, December 29, 2017 9:46 AM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: coreboot@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)
>  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@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

ron minnich wrote
> how are you different in this case from Motorola, who had to put their linux 
> source on a web site? companies resold motorola phones. Or the many switch 
> vendors who sell network switches that run coreboot/linuxbios? or irobot, who 
> use it still on the packbot? 
> Or how are you different from just about every vendor that sells embedded ARM 
> boards that run u-boot? 
We are, because of the nature of our customers, very different from all of your 
example use cases, except perhaps the people who sell embedded ARM boards.

Motorola phone: They sell their product to people (well, companies) who set out 
to make GPL licensed products, typically for a large market. The customer of 
Motorola makes no modifications to the Motorola phone, or at least no 
significant modifications. There is no difficulty for such a prospective 
reseller of such a product to comply with GPL. There are lots of sales to cover 
the initial costs. But, most importantly, the Motorola reseller is typically 
not making a new product. They are reselling the Motorola product, perhaps as a 
private label, to an end user who will receive Motorola's packaging and 
notifications (at first boot, perhaps - I do not actually know how).

As far as I can see (well, guess), network switch purchasers are almost always 
end users (corporate or personal). And, it is my guess - after spending the 
past week and a half trying to understand GPL's implications - that there are 
many, many small resellers of network switches in complete systems that are out 
of compliance with GPL because they do not even think about the issue. As a 
side note, our customers are a bit like this kind of reseller of a complete 
system that happens to contain a network switch, though the analogy is not 
great because the network switch is in some sense a complete system, while what 
we make is not. Still, if I sell a network installation to a small shop, and I 
fail to give the recipient of my system that includes that switch the GPL 
license and a place to get the source code, I am in violation of GPL. I do not 
want this to happen to my customers.

iRobot is making an end use product, not a product that someone else is going 
to take and build into something very different from the iRobot product. Again, 
a lot like Motorola and their phone. If NewEgg sells an iRobot product, they 
just pass through the iRobot package - with everything in it - so (I think, 
though I am not quite sure) they are in compliance as long as iRobot was. I 
suspect that NewEgg just assumes that iRobot got their licensing right. My 
reading of GPL is that NewEgg actually has their own obligation under GPL 
separate from iRobot's, but I would guess they do not worry about it much. They 
are not making anything. They are just reselling.

ARM boards that run u-boot: The target customer base is aiming to take 
advantage of the ARM board to make a product at a low cost (typically), and 
most of them are well aware of GPL and its implications. This is somewhat like 
us. Some of the uses have very small markets - as most of our customers do. 
But, we do not have a customer base that is aware of GPL and intend to use it 
from the beginning.

A typical customer of ours might sell 50 systems in a year and consider that a 
very good year. They sell each system for a lot of money (typically) and they 
are not spending a lot of time thinking about licensing. Most (a guess) 
probably do not even have an in-house counsel, let alone a license management 
department.

Asking them to take on new licensing obligations is an impediment to adoption 
of our product. How many of our customers already easily deal with GPL, I do 
not know, but I doubt it is a big fraction. You may not see that as a big 
issue, and if you were our customer it would not be a big issue for you. But, 
many of our customers hardly even formally license their own products to their 
customers; they go install them. My point is that our market is not an end use 
market where the licensing almost does not matter once the end user has the 
product in hand. And, it is not a big OEM market where the licensing is a 
triviality. And, our market is not Makers, say, who know - and want to be - 
buying GPL licensed products so that they can hack around in them.

Our market is for small OEMs - or OEMs who work inside big companies, but with 
small customer bases, which is even worse because here there is a legal 
department, but our customer has next to no chance of getting their attention - 
who make low volume specialized products - an industrial turbine monitoring 
system, say - that typically sell infrequently for relatively high prices and 
they want our part of the system to just work with as little thought as 
possible. Their focus is on their application area. If we can help them without 
getting in their way, they may use us. If we look like a nuisance, they will go 
elsewhere (maybe to an ARM board and building their own 

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[ron minnich]

On Fri, Dec 29, 2017 at 5:20 PM Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

>
>
> The real problem comes with our potential OEM and VAR customers - the most
> valuable customers for our potential product from a turnover perspective.
> If we attempt to sell them a GPL licensed product, we oblige them to
> conform with GPL licensing to be able to sell their systems to their
> customers. I am about certain that, unless we make it trivially easy to
> conform, this will put off a good fraction of our prospective customers.
> Even if we make it trivially easy to conform, unless it is almost
> automatic, I am concerned that it may still put off too many potential
> OEM/VAR customers. And, our customers would not be behaving in an
> nonsensical way. Many of them employ no firmware engineers who they could
> use to determine whether they were actually in compliance with GPL, even if
> they did not mind the added licensing on their product.
>

how are you different in this case from Motorola, who had to put their
linux source on a web site? companies resold motorola phones. Or the many
switch vendors who sell network switches that run coreboot/linuxbios? or
irobot, who use it still on the packbot?

Or how are you different from just about every vendor that sells embedded
ARM boards that run u-boot?

Also, why do you mention GPL V3? Coreboot is 2 or later.

What about the many systems that run all kinds of GPL V2 embedded software?
What's different between you and them?

What I'm trying to say is that problem seems to have been solved. I get the
feeling you are new to dealing with this question, and are trying to solve
it yourself, without talking to people who have already solved it?

thanks

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

ron minnich wrote:
>> First we need to figure out whether we are willing/able to move forward with 
>> a product that includes GPL licensed code at all.
> this part I do not understand. There are so many embedded systems out there 
> with GPL code in firmware, what is the unique property of your product that 
> makes it impractical? 

The issue for us is that most of our customers are not end users. Well, 
actually, we have many, many more end use customers than reseller customers, 
but end use customers represent a small fraction of our product sales. The bulk 
of our products sales are to OEM (Original Equipment Manufacturer) or VAR 
(Value Added Reseller - that is, consultant) customers who resell a system of 
their own that contains our product as a component.

GPL creates no particular problem for us when we sell to a university - one of 
our main sources of end-use customers - that will use our device to perform 
specific experiments in their own lab. We would need no more than a piece of 
paper in the box plus a medium to carry the source code that corresponds to the 
firmware (or a website, for that matter). Since our end user in this case would 
build their setup and run it themselves and never distribute it, there would be 
next to no issue once we met our obligations under GPL. Though, even here I 
have a bit of a concern because I read GPLv3 to obligate us to provide our 
customer a way to replace the firmware, not just provide the source for it, and 
currently we do not have an external means to allow this on any of our 
products. Still, this is more of a technical issue than a legal or marketing 
one. We would most likely not lose a single end use customer sale because our 
product included a GPL license for a portion of the system. 

The real problem comes with our potential OEM and VAR customers - the most 
valuable customers for our potential product from a turnover perspective. If we 
attempt to sell them a GPL licensed product, we oblige them to conform with GPL 
licensing to be able to sell their systems to their customers. I am about 
certain that, unless we make it trivially easy to conform, this will put off a 
good fraction of our prospective customers. Even if we make it trivially easy 
to conform, unless it is almost automatic, I am concerned that it may still put 
off too many potential OEM/VAR customers. And, our customers would not be 
behaving in an nonsensical way. Many of them employ no firmware engineers who 
they could use to determine whether they were actually in compliance with GPL, 
even if they did not mind the added licensing on their product.

So, the root issue here is that - because of the nature of our customers - we 
are not just putting ourselves under GPL. We are putting our prospective 
customers under GPL too, and that will - I guarantee it - put off some fraction 
of our potential best customers. What I do not know is what fraction that would 
be and whether we want to find out. 

Ian

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[ron minnich]

On Fri, Dec 29, 2017 at 3:55 PM Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

>
>
>
> First we need to figure out whether we are willing/able to move forward
> with a product that includes GPL licensed code at all.
>

this part I do not understand. There are so many embedded systems out there
with GPL code in firmware, what is the unique property of your product that
makes it impractical?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] smd work

[Tim S]

Personally I like hot air reflow for multi-pin parts.

Something cheapish like an Ayoue works fine - I think Walmart has the 888A
hot-air/solder-iron station listed for <$70 (I use the Ayoue 852 myself at
home, because I have a very nice solder station already).  The trick with
hot air is not getting the air speed too high, do that and you'll start
blowing off small SMD resistors and caps all over your workspace.  Get it
too hot and you scorch the plastic packaged parts.

Can't beat hot air though for re-attaching parts, get some solder paste
from (anywhere really), and put the paste in a small modeling or plastic
gluing syringe, and under a decent magnification, you can apply solder
paste directly to the bare cold pads (don't drink coffee that day).  Drop
the part on the paste (just like a pick an place machine), and it'll stick
there with surface tension until you reflow (heat) the part.  IMHO the
nicest thing about this method is that even if you drop the part a bit off
alignment, the surface tension of the heated paste will pull the legs onto
the pads.  There are good YouTube videos for this method.

If you need to reattach a larger part like an IO controller or a
chipset/BGA, you'll want to heat both sides of the board so it doesn't
warp.  Also for holding things in place you don't intend to remove, get
some Kapton tape (the brownish-orange transparent stuff) and cover the
"keep out" areas.  Kapton sticks at temperatures up to 500°C is
non-conductive, just make sure you let the board cool down again before you
remove the tape, or you'll have tape covered in the parts you were trying
not to remove...

Get used to this stuff, the leg-less parts are becoming the norm in the
thinner form factors especially.

-Tim

Date: Thu, 28 Dec 2017 17:47:54 +
> From: ron minnich 
> To: coreboot 
> Subject: [coreboot] smd work
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Can someone submit a KCMA-D8 board status?

[taii...@gmx.com]

As it is almost identical to the KGPE-D16 I am sure it still works with 
the latest coreboot so I was wondering if someone could compile and 
submit a board status so that it doesn't get removed.

It would be pretty silly for a year old $15K board port to end up removed.

Thanks!


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[ron minnich]

suggestion: you might want to figure out what subset of the source you
actually use in your product, i.e. what files are used in your build, then
create a subset of the coreboot source tree containing only this files,
then lzma -9 that file.

I suspect it would be pretty small, but if you want to tell me what board
this is I'm willing to give it a try.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

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



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[杜睿哲_Pegatron]

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.hendri...@gmail.com]
Sent: Friday, December 29, 2017 9:46 AM
To: Hilbert Tu(杜睿哲_Pegatron)
Cc: coreboot@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) 
> 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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [flashrom] [announce] flashrom 1.0-rc2

[Michael Zhilin]

Hi,

Compilation on FreeBSD 12-current is fine, but could you please merge
https://patchwork.coreboot.org/patch/4498/ before release?

Thank you!

On Thu, Dec 28, 2017 at 6:23 PM, Nico Huber  wrote:

> 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/flash
> rom-1.0-rc2.tar.bz2
>
> 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
>
> ___
> flashrom mailing list
> flash...@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[my First name is Test And my last Name is iPation]

Yes, I know that, whether I use Clover or Grub2, they both use a small fat32 
EFI partition, which hold the same file /efi/boot/bootx64.efi in order to boot 
their OSes.

I think my first attempt Coreboot+TianoCore + macOS failed because of macOS 
lastest filesystem (APFS), which is for now a bit "exotic".

So, yes, I'll follow your hint, and first try Coreboot/TianoCore (on chip) + 
Grub2(EFI)/Ubuntu (on disk).

And if it works, I will try it with the traditional EFI/HFS (on disk) macOS way 
(without APFS).


Thanks Zoran.




From: Zoran Stojsavljevic 
Sent: Friday, December 29, 2017 8:37 PM
To: my First name is Test And my last Name is iPation
Cc: coreboot@coreboot.org; ron minnich
Subject: Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an 
Thinkpad X230 Hackintosh

Hello Fred,

> > So in such a case you would replace/overwrite (in flash) UEFI BIOS
> > with Coreboot + payload Tiano Core, which will boot GRUB 2.0 from
> > drive, them show GRUB 2.0 boot menu with MacOS as one of the entries).
>
> It's a good idea, I'll work on it. Thank you very much.

This is 100% duable: Coreboot + payload Tiano Core (flash), which will
boot GRUB 2.0 from drive, then show GRUB 2.0 boot menu with original
MacOS (if you can overwrite Clover with GRUB 2.0, not affecting
MacOS).

I'll give you here the hint: you should see, using stock UEFI BIOS,
/boot/efi directory, which is FAT32 formatted (if you can enter BIOS
UEFI shell), where you can see either Clover executable (cloverx64.efi
or similar name), either grubx64.efi, if you correctly have
overwritten Clover with GRUB 2.0.

If you do not have ability to enter UEFI shell on stock UEFI BIOS, you
can, using original MacOS probably see /boot. and find there efi/
directory, And inspect it yourself (maybe you can from MacOS overwrite
Clover with GRUB 2.0, and do inspection at the spot).

As the addendum, you should take your Ubuntu HDD/SSD, installed with
SeaBIOS as payload, then using Coreboot + payload Tiano Core in flash,
reinstall from scratch Ubuntu (making it UEFI compatible).

In such a case, your SINGLE Coreboot + Tiano Core flash FW will
satisfy all your needs, since you will use x230 with various UEFI
compatible OSes. Either as multiboot OS system on large HDD/SSD,
either swapping drives with UEFI compatible OSes. Your choice. :-)

Zoran

On Fri, Dec 29, 2017 at 7:58 PM, my First name is Test And my last
Name is iPation  wrote:
>
>
>
>
>
> From: Zoran Stojsavljevic 
> Sent: Friday, December 29, 2017 7:16 PM
> To: my First name is Test And my last Name is iPation
> Cc: coreboot@coreboot.org; ron minnich
> Subject: Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an
> Thinkpad X230 Hackintosh
>
>
>> Hi, I have a Thinkpad X230 with stock Bios,booting
>> macOS High Sierra, using Clover EFI boot loader.
>> And it's working great! Then I've went through the
>> process of installing Coreboot/Seabios + Ubuntu on
>> another disk, and it works like a charm too! However,
>> I would like to use Coreboot+payload instead of the
>> stock Bios, in order to boot Clover/macOS.
>
> Let me try to decipher this spaghetti mess... First/Last name + The
> Coreboot list!
>
> Sorry for the weird name.
>
>
> You have a Thinkpad X230 with Stock BIOS on your flash. This one
> worked well with your HDD/SSD, on which you have Clover EFI boot
> loader, booting MacOS.
>
> Yes.
>
>
> You recently made Coreboot + SeaBIOS, and programmed it to your flash,
> erasing/overwriting stock BIOS. Then you install on other HDD/SSD
> Ubuntu using Coreboot + SeaBIOS flash, and it worked like a charm.
>
> Yes.
>
>
> Now, when you return back your initial HDD/SSD with Clover EFI boot
> loader and MacOS, it does not boot. It does NOT. You are using
> (SeaBIOS) Legacy bootloader which could NOT boot UEFI (UEFI installed)
> based OS (in this case MacOS).
>
> No, I didn't returned back to my initial disk with macOS, because I know it
> wouldn't work.
>
>
>
>> I know there is TianoCore to boot UEFI systems.
>> Has anyone Tried something similar ?
>
> In order to make attempt to make your initial HDD/SSD (Clover EFI boot
> loader, booting MacOS) to work, you need to use Coreboot with Tiano
> Core payload. The problem here is how to pass Tiano Core thread of
> execution to Clover EFI boot loader (I have no slightest idea about
> that, and about Clover EFI bootloader).
>
> In the mean time, I've just tried Coreboot+TianoCore payload, in order to
> boot my Clover+macOS disk, it didn't work, just a black screen. But I didn't
> got my hopes up, I were just trying.
>
>
>
> My best guess it is similar to the problem if you had UEFI BIOS
> (programmed on flash) with GRUB 2.0 booting MacOS (I have no idea if
> this combination exists, I assume it does).
>
> Yes it does, with Grub compiled --with-platform=efi
>
>
>
> So in such a case you would replace/overwrite (in flash) UEFI BIOS
> 

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[Zoran Stojsavljevic]

Hello Fred,

> > So in such a case you would replace/overwrite (in flash) UEFI BIOS
> > with Coreboot + payload Tiano Core, which will boot GRUB 2.0 from
> > drive, them show GRUB 2.0 boot menu with MacOS as one of the entries).
>
> It's a good idea, I'll work on it. Thank you very much.

This is 100% duable: Coreboot + payload Tiano Core (flash), which will
boot GRUB 2.0 from drive, then show GRUB 2.0 boot menu with original
MacOS (if you can overwrite Clover with GRUB 2.0, not affecting
MacOS).

I'll give you here the hint: you should see, using stock UEFI BIOS,
/boot/efi directory, which is FAT32 formatted (if you can enter BIOS
UEFI shell), where you can see either Clover executable (cloverx64.efi
or similar name), either grubx64.efi, if you correctly have
overwritten Clover with GRUB 2.0.

If you do not have ability to enter UEFI shell on stock UEFI BIOS, you
can, using original MacOS probably see /boot. and find there efi/
directory, And inspect it yourself (maybe you can from MacOS overwrite
Clover with GRUB 2.0, and do inspection at the spot).

As the addendum, you should take your Ubuntu HDD/SSD, installed with
SeaBIOS as payload, then using Coreboot + payload Tiano Core in flash,
reinstall from scratch Ubuntu (making it UEFI compatible).

In such a case, your SINGLE Coreboot + Tiano Core flash FW will
satisfy all your needs, since you will use x230 with various UEFI
compatible OSes. Either as multiboot OS system on large HDD/SSD,
either swapping drives with UEFI compatible OSes. Your choice. :-)

Zoran

On Fri, Dec 29, 2017 at 7:58 PM, my First name is Test And my last
Name is iPation  wrote:
>
>
>
>
>
> From: Zoran Stojsavljevic 
> Sent: Friday, December 29, 2017 7:16 PM
> To: my First name is Test And my last Name is iPation
> Cc: coreboot@coreboot.org; ron minnich
> Subject: Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an
> Thinkpad X230 Hackintosh
>
>
>> Hi, I have a Thinkpad X230 with stock Bios,booting
>> macOS High Sierra, using Clover EFI boot loader.
>> And it's working great! Then I've went through the
>> process of installing Coreboot/Seabios + Ubuntu on
>> another disk, and it works like a charm too! However,
>> I would like to use Coreboot+payload instead of the
>> stock Bios, in order to boot Clover/macOS.
>
> Let me try to decipher this spaghetti mess... First/Last name + The
> Coreboot list!
>
> Sorry for the weird name.
>
>
> You have a Thinkpad X230 with Stock BIOS on your flash. This one
> worked well with your HDD/SSD, on which you have Clover EFI boot
> loader, booting MacOS.
>
> Yes.
>
>
> You recently made Coreboot + SeaBIOS, and programmed it to your flash,
> erasing/overwriting stock BIOS. Then you install on other HDD/SSD
> Ubuntu using Coreboot + SeaBIOS flash, and it worked like a charm.
>
> Yes.
>
>
> Now, when you return back your initial HDD/SSD with Clover EFI boot
> loader and MacOS, it does not boot. It does NOT. You are using
> (SeaBIOS) Legacy bootloader which could NOT boot UEFI (UEFI installed)
> based OS (in this case MacOS).
>
> No, I didn't returned back to my initial disk with macOS, because I know it
> wouldn't work.
>
>
>
>> I know there is TianoCore to boot UEFI systems.
>> Has anyone Tried something similar ?
>
> In order to make attempt to make your initial HDD/SSD (Clover EFI boot
> loader, booting MacOS) to work, you need to use Coreboot with Tiano
> Core payload. The problem here is how to pass Tiano Core thread of
> execution to Clover EFI boot loader (I have no slightest idea about
> that, and about Clover EFI bootloader).
>
> In the mean time, I've just tried Coreboot+TianoCore payload, in order to
> boot my Clover+macOS disk, it didn't work, just a black screen. But I didn't
> got my hopes up, I were just trying.
>
>
>
> My best guess it is similar to the problem if you had UEFI BIOS
> (programmed on flash) with GRUB 2.0 booting MacOS (I have no idea if
> this combination exists, I assume it does).
>
> Yes it does, with Grub compiled --with-platform=efi
>
>
>
> So in such a case you would replace/overwrite (in flash) UEFI BIOS
> with Coreboot + payload Tiano Core, which will boot GRUB 2.0 from
> drive, them show GRUB 2.0 boot menu with MacOS as one of the entries).
>
> It's a good idea, I'll work on it. Thank you very much.
>
> Fred
>
>
> I hope this helps... .. . I really do.
>
> Zoran
> ___
>
> On Fri, Dec 29, 2017 at 6:13 PM, my First name is Test And my last
> Name is iPation  wrote:
>> Hi, I have a Thinkpad X230 with stock Bios, booting macOS High Sierra,
>> using
>> Clover EFI boot loader. And it's working great!
>>
>> Then I've went through the process of installing Coreboot/Seabios + Ubuntu
>> on another disk, and it works like a charm too!
>>
>> However, I would like to use Coreboot+payload instead of the stock Bios,
>> in
>> order to boot Clover/macOS.
>>
>> I know there is TianoCore to boot UEFI systems. Has anyone Tried something
>> 

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[ron minnich]

Fred, thanks for the update. I was double checking because, believe it or
not, we have had a surprising number of people in the last 18 years ask how
they could install coreboot to run under linux ... :-)

nice work on getting the x230 as far as you have!
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[my First name is Test And my last Name is iPation]

From: Zoran Stojsavljevic 
Sent: Friday, December 29, 2017 7:16 PM
To: my First name is Test And my last Name is iPation
Cc: coreboot@coreboot.org; ron minnich
Subject: Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an 
Thinkpad X230 Hackintosh


> Hi, I have a Thinkpad X230 with stock Bios,booting
> macOS High Sierra, using Clover EFI boot loader.
> And it's working great! Then I've went through the
> process of installing Coreboot/Seabios + Ubuntu on
> another disk, and it works like a charm too! However,
> I would like to use Coreboot+payload instead of the
> stock Bios, in order to boot Clover/macOS.

Let me try to decipher this spaghetti mess... First/Last name + The
Coreboot list!


Sorry for the weird name.

You have a Thinkpad X230 with Stock BIOS on your flash. This one
worked well with your HDD/SSD, on which you have Clover EFI boot
loader, booting MacOS.

Yes.

You recently made Coreboot + SeaBIOS, and programmed it to your flash,
erasing/overwriting stock BIOS. Then you install on other HDD/SSD
Ubuntu using Coreboot + SeaBIOS flash, and it worked like a charm.


Yes.


Now, when you return back your initial HDD/SSD with Clover EFI boot
loader and MacOS, it does not boot. It does NOT. You are using
(SeaBIOS) Legacy bootloader which could NOT boot UEFI (UEFI installed)
based OS (in this case MacOS).


No, I didn't returned back to my initial disk with macOS, because I know it 
wouldn't work.


> I know there is TianoCore to boot UEFI systems.
> Has anyone Tried something similar ?

In order to make attempt to make your initial HDD/SSD (Clover EFI boot
loader, booting MacOS) to work, you need to use Coreboot with Tiano
Core payload. The problem here is how to pass Tiano Core thread of
execution to Clover EFI boot loader (I have no slightest idea about
that, and about Clover EFI bootloader).


In the mean time, I've just tried Coreboot+TianoCore payload, in order to boot 
my Clover+macOS disk, it didn't work, just a black screen. But I didn't got my 
hopes up, I were just trying.


My best guess it is similar to the problem if you had UEFI BIOS
(programmed on flash) with GRUB 2.0 booting MacOS (I have no idea if
this combination exists, I assume it does).


Yes it does, with Grub compiled --with-platform=efi


So in such a case you would replace/overwrite (in flash) UEFI BIOS
with Coreboot + payload Tiano Core, which will boot GRUB 2.0 from
drive, them show GRUB 2.0 boot menu with MacOS as one of the entries).


It's a good idea, I'll work on it. Thank you very much.

Fred


I hope this helps... .. . I really do.

Zoran
___

On Fri, Dec 29, 2017 at 6:13 PM, my First name is Test And my last
Name is iPation  wrote:
> Hi, I have a Thinkpad X230 with stock Bios, booting macOS High Sierra, using
> Clover EFI boot loader. And it's working great!
>
> Then I've went through the process of installing Coreboot/Seabios + Ubuntu
> on another disk, and it works like a charm too!
>
> However, I would like to use Coreboot+payload instead of the stock Bios, in
> order to boot Clover/macOS.
>
> I know there is TianoCore to boot UEFI systems. Has anyone Tried something
> similar ?
>
> Thanks.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot


coreboot Info Page
mail.coreboot.org
coreboot project mailing list. To see the collection of prior postings to the 
list, visit the coreboot Archives. Using coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[Zoran Stojsavljevic]

> Hi, I have a Thinkpad X230 with stock Bios,booting
> macOS High Sierra, using Clover EFI boot loader.
> And it's working great! Then I've went through the
> process of installing Coreboot/Seabios + Ubuntu on
> another disk, and it works like a charm too! However,
> I would like to use Coreboot+payload instead of the
> stock Bios, in order to boot Clover/macOS.

Let me try to decipher this spaghetti mess... First/Last name + The
Coreboot list!

You have a Thinkpad X230 with Stock BIOS on your flash. This one
worked well with your HDD/SSD, on which you have Clover EFI boot
loader, booting MacOS.

You recently made Coreboot + SeaBIOS, and programmed it to your flash,
erasing/overwriting stock BIOS. Then you install on other HDD/SSD
Ubuntu using Coreboot + SeaBIOS flash, and it worked like a charm.

Now, when you return back your initial HDD/SSD with Clover EFI boot
loader and MacOS, it does not boot. It does NOT. You are using
(SeaBIOS) Legacy bootloader which could NOT boot UEFI (UEFI installed)
based OS (in this case MacOS).

> I know there is TianoCore to boot UEFI systems.
> Has anyone Tried something similar ?

In order to make attempt to make your initial HDD/SSD (Clover EFI boot
loader, booting MacOS) to work, you need to use Coreboot with Tiano
Core payload. The problem here is how to pass Tiano Core thread of
execution to Clover EFI boot loader (I have no slightest idea about
that, and about Clover EFI bootloader).

My best guess it is similar to the problem if you had UEFI BIOS
(programmed on flash) with GRUB 2.0 booting MacOS (I have no idea if
this combination exists, I assume it does).

So in such a case you would replace/overwrite (in flash) UEFI BIOS
with Coreboot + payload Tiano Core, which will boot GRUB 2.0 from
drive, them show GRUB 2.0 boot menu with MacOS as one of the entries).

I hope this helps... .. . I really do.

Zoran
___

On Fri, Dec 29, 2017 at 6:13 PM, my First name is Test And my last
Name is iPation  wrote:
> Hi, I have a Thinkpad X230 with stock Bios, booting macOS High Sierra, using
> Clover EFI boot loader. And it's working great!
>
> Then I've went through the process of installing Coreboot/Seabios + Ubuntu
> on another disk, and it works like a charm too!
>
> However, I would like to use Coreboot+payload instead of the stock Bios, in
> order to boot Clover/macOS.
>
> I know there is TianoCore to boot UEFI systems. Has anyone Tried something
> similar ?
>
> Thanks.
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[my First name is Test And my last Name is iPation]

Yes I know, I didn't install Coreboot on disk. Ubuntu is installed on disk. 
Coreboot/Seabios are installed on my X230 chips (4MB - 8MB).



From: ron minnich 
Sent: Friday, December 29, 2017 6:17 PM
To: my First name is Test And my last Name is iPation
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an 
Thinkpad X230 Hackintosh



On Fri, Dec 29, 2017 at 9:15 AM my First name is Test And my last Name is 
iPation > wrote:


Then I've went through the process of installing Coreboot/Seabios + Ubuntu on 
another disk, and it works like a charm too!


this sentence makes no sense to me. You don't install coreboot on a disk?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[ron minnich]

On Fri, Dec 29, 2017 at 9:15 AM my First name is Test And my last Name is
iPation  wrote:

>
> Then I've went through the process of installing Coreboot/Seabios +
> Ubuntu on another disk, and it works like a charm too!
>


this sentence makes no sense to me. You don't install coreboot on a disk?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh

[my First name is Test And my last Name is iPation]

Hi, I have a Thinkpad X230 with stock Bios, booting macOS High Sierra, using 
Clover EFI boot loader. And it's working great!

Then I've went through the process of installing Coreboot/Seabios + Ubuntu on 
another disk, and it works like a charm too!

However, I would like to use Coreboot+payload instead of the stock Bios, in 
order to boot Clover/macOS.

I know there is TianoCore to boot UEFI systems. Has anyone Tried something 
similar ?

Thanks.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] smd work

[Sam Kuper]

On 28/12/2017, ron minnich  wrote:
> Soldering irons? hot air guns? magic wands?

I haven't used one so can't comment personally (and I don't have any
stake in it, either), but as it seems both to be incredibly popular
and to be suitable for single chip reworking, I'll mention the TS100,
which is a compact soldering iron with built-in thermostat and
microcontroller.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] smd work

[Peter Stuge]

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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot