Re: [coreboot] Current, BLOB free laptop available Europe?

[Paul Kocialkowski]

Hey,

Le lundi 05 juin 2017 à 18:20 +0300, Mike Banon a écrit :
> actually Lenovo G505S has more freedom in some relations, if compared
> to Chromebook R13 : for example, G505S does not require blobs for WiFi
> and Bluetooth if you replace its' preinstalled Broadcom half size mini
> PCI-e card with Atheros AR9462 (which has 2.4 GHz + 5 GHz + Bluetooth
> and is top-of-the-line ath9k card) and its' price is just $8-$10 with
> free shipping included ;)

Well, I don't think that Wi-Fi is really a big deal compared to having
coprocessors that can only run proprietary software, in addition to proprietary
graphics init along with a proprietary EC.

You can easily use an external ath9k_htc USB dongle on CrOS devices instead of
the internal one, which solves the Wi-Fi situation easily.

There's hope for the G505s though and I truly hope it can get close to the
current freedom status of ARM CrOS devices! (And I'm still working hard to
improve the EC situation.)

>  also there are some great technical
> opportunities which chromebooks do not have - e.g. you could replace
> WiFi mini pci-e card with double SATA ports RAID card, or you can
> install 16 GB of RAM because G505S RAM is not soldered ! Still could
> get G505S in good condition at many USA / European markets, e.g.
> yesterday at eBay I saw G505S based at USA which costs just $95, also
> UK-based in nearly mint condition ;) Also there are a lot of spare
> parts available, which helps to ensure the long lifetime of this great
> performance quad core laptop ( Chromebook is not even close at
> performance, as far as I know )

Yeah, those are definitely nice technical features (but they're not freedom-
related)! I also have a bit of a hard time with devices I can't replace broken
parts for, because they're all soldered onto the same board!

Cheers,

Paul

> On Wed, May 31, 2017 at 11:03 AM, Paul Kocialkowski  wrote:
> > Hi,
> > 
> > Le mardi 23 mai 2017 à 08:54 +0200, Paul Menzel a écrit :
> > > I am looking for a new portable device available in Europe.
> > > 
> > > Is it true, that the Acer Chromebook R 13 [1], is the only current BLOB
> > > free device? The device currently costs 400 €. Is MediaTek “a good
> > > citizen”, that means, do they provide datasheets and work on drivers?
> > 
> > The Chromebook R13 (elm) is very close to being able to boot without non-
> > free
> > blobs. The only remaining blobs are the MT8173 PCM firmwares[0] in ARM
> > Trusted
> > Firmware. I am working hard to liberate them and I'm very confident that it
> > will
> > happen pretty soon.
> > 
> > However, note that the kernel will require blobs for features such as:
> > * hardware video decoding
> > * Wi-Fi and bluetooth
> > * GPU support
> > 
> > I'm also not sure about the status of the PD (USB type-C controller) chip.
> > It
> > might also be running a proprietary firmware (maybe someone from the CrOS
> > team
> > can clarify this).
> > 
> > Also, note that as usual with laptops, there are lots of other non-free
> > components around that are preinstalled on the device, such as the webcam
> > firmware.
> > 
> > Note that ARMv7 CrOS devices (mainly RK3288 and Tegra K1) can also boot
> > blobless
> > and generally require less kernel blobs too. They also have much better
> > upstream
> > Linux support than the ARMv8 ones (which are more recent). For instance, I'm
> > running a mainline kernel on the Tegra K1 nyans, which is quite usable
> > despite
> > some issues that I have left to fix. There's also a very high chance that
> > the
> > GPU will work with nouveau and free firmwares eventually (I'll be working
> > with
> > nouveau developers to try and make this happen).
> > 
> > > The Samsung Chromebook Plus/Pro with RK3399 [2] are only available in
> > > the USA, right?
> > 
> > I am not aware of it being available in Europe. However, if you're fine with
> > a
> > qwerty layout, they work just as well in Europe ;)
> > 
> > RK3399 can currently already boot blobless but also requires kernel blobs.
> > However, it seems that the boot is currently broken with coreboot master and
> > ToT
> > depthcharge and vboot (I'll be investigating this soon).
> > 
> > Also, the Chromebook Plus (kevin) does have a free software PD firmware.
> > 
> > Finally, note that the Chromebook Pro is an Intel x86 device, so probably
> > not
> > very interesting given what you're looking for.
> > 
> > Cheers,
> > 
> > [0]: https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/m
> > ediatek/mt8173/drivers/spm/spm_mcdi.c
> > 
> > --
> > Paul Kocialkowski, developer of free digital technology and hardware support
> > 
> > Website: https://www.paulk.fr/
> > Coding blog: https://code.paulk.fr/
> > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog:

Re: [coreboot] Asus M2N-E

[Martin A]

Hi Mike,


I use Cutecom.

Why ?


Martin


De : Mike Banon 
Envoyé : lundi 5 juin 2017 17:03
À : Martin A
Objet : Re: [coreboot] Asus M2N-E

Hi Martin! Please tell: what tools are you using to receive this coreboot 
booting log?

On Wed, May 24, 2017 at 12:14 AM, Martin A 
mailto:tintinsansmi...@hotmail.com>> wrote:

Ok Timothy,


Thanks a lot for your help, really appreciate.


I tried try with a dual core Athlon 64 X2 and the boot log is an exact copy of 
the Opteron's.

So it has something to do with the mainboard.


Hope Uwe Hermann see this.


Martin.


De : Timothy Pearson 
mailto:tpear...@raptorengineering.com>>
Envoyé : mardi 23 mai 2017 19:56
À : Martin A
Cc : coreboot@coreboot.org
Objet : Re: [coreboot] Asus M2N-E

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/23/2017 03:37 AM, Martin A wrote:
>
>
> Sorry, here is the "not so perfect" boot log.
>
> Many weirds points, no ?
>
> Thank you very much
>
>
> Martin
>
>
> ---
>
> BSP overran lower stack boundary.  Undefined behaviour may result!



This is probably the issue right here.  This means a coreboot developer
(preferably with access to this hardware) needs to take a look at the
stack allocation for the 0xf Opteron chips to see why coreboot is
overrunning the stack space.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
Raptor Engineering::Home Page
www.raptorengineering.com
Let Raptor Engineering handle your next high-performance digital design! We 
offer consulting services in: Embedded systems design; Boot firmware 
development (e.g ...


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJZJHfKAAoJEK+E3vEXDOFbEl8H/1ZRYw1tQABpk/uhhuHY0R5G
97B6BaRW0PIJXUg0ekGCYfPEqXgtiSsr1K77VMY8wpov1aNkaGEMjRw300he4Dk2
sPqjUqwaHB57+qw1W9YYbYsDf3JGZEizNd9WapixHS1pXhEGDoR/g6NPL6LFyZMr
+RGjPnLIBq5yksGGnF4UMa9/VWmdBXzUDcrFAKYB1ptQe42sIvtE8KvMRtXZmYqr
bvS5WAksOPjZhmNntDPxopQE0HaxUyMZJINVALBVj+Hq20gFOWCwnNuB8m78zDPl
47ncYoHV82UKGEzklWlF1ohEKUAIKdI0NrbBqXxbk0zJabaYoEkIu3gVEKlgFKc=
=r7in
-END PGP SIGNATURE-

--
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] make crossgcc-i386 : ubsan.c error (with fix!) for GCC

[Paul Kocialkowski]

Hi,

Le dimanche 04 juin 2017 à 22:49 +, qma ster a écrit :
> Good day! While building the coreboot's toolchain by using GCC 7.1.1
> version, I am getting the following error:

[…]

> Found this solution here -
> https://patchwork.openembedded.org/patch/138884/ . Would be great if
> you could somehow import it to your code

I've had the very same issue when building crossgcc today.

Would you like to make a patch to coreboot for that? If not, I'll probably end
up doing it soon.

Cheers,

-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VT-d support

[Nico Huber]

On 05.06.2017 19:47, Zoran Stojsavljevic wrote:
>> If you are lucky, you only need to add 20~30 lines to your chipset's code.
> 
> Could you, please, show us an explicit example (of these 20 to 30 lines of
> code)?!

`src/northbridge/intel/sandybridge/iommu.c` and acpi_fill_dmar() in
`src/northbridge/intel/sandybridge/acpi.c`.

Nico


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

Re: [coreboot] VT-d support

[Zoran Stojsavljevic]

> If you are lucky, you only need to add 20~30 lines to your chipset's code.

Could you, please, show us an explicit example (of these 20 to 30 lines of
code)?!

Zoran

On Mon, Jun 5, 2017 at 7:34 PM, Nico Huber  wrote:

> Hi,
>
> On 05.06.2017 18:58, Himanshu Chauhan wrote:
> >
> >> On 05-Jun-2017, at 10:19 PM, ron minnich  wrote:
> >>
> >> The reason I ask about what you need is that on chromebooks the main
> >> coreboot support came down to 'don't disable anything’.
> >
> > I think its can’t just be disabled. Its just that kernel is not given
> > any knowledge about its existence. This is what I want to know. The
> > commercial BIOSes give an option of “enable VT-d” support. What do they
> > do when this option is selected? Can this be implemented in Coreboot?
> > This probably brings me to your next question of what is required. I
> > would spend some time to figure that out.
>
> First thing, the firmware doesn't have to support it. It's only that
> Intel chose _not_ to write per platform OS drivers and let the firm-
> ware do the abstraction instead (I know a kernel that works pretty well
> with VT-d even if there are no DMAR tables).
>
> coreboot already handles VT-d support on some chipsets (GM45, Sandy/
> Ivy Bridge come to mind). You can look how it's done there. If you are
> lucky, you only need to add 20~30 lines to your chipset's code.
>
> If your chipset needs special initialization, it's most probably docu-
> mented in the BIOS Writer's Guide (BWG) or BIOS Specification. Though,
> you need an NDA with Intel to get these.
>
> Nico
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] What does *intelblocks* mean?

[Banik, Subrata]

>> The reason 'intelblocks' is in the include path is because the include 
>> headers are namespaced. e.g. #include .

My +2 to Aaron's comment, that’s the only reason to create "intelblocks".

Thanks,
Subrata


-Original Message-
From: Aaron Durbin [mailto:adur...@google.com] 
Sent: Monday, June 5, 2017 9:11 PM
To: Paul Menzel 
Cc: Coreboot ; Banik, Subrata 
Subject: Re: [coreboot] What does *intelblocks* mean?

On Mon, Jun 5, 2017 at 2:48 AM, Paul Menzel  
wrote:
> Dear coreboot folks,
>
>
> In commit a554b0c5b7 (soc/intel/common/block: Add Intel XHCI driver
> support) [1] the directory
> `src/soc/intel/common/block/include/intelblocks` is created.
>
> Could somebody please help me, what *intelblocks* means here, and why
> *intel* is twice in the path?

It's common code to be used for intel SoCs. 'ipblock' would be more 
appropriate, but I think people didn't want to freak anyone out with the name 
'ip'. The reason 'intelblocks' is in the include path is because the include 
headers are namespaced. e.g. #include .


>
>
> Thanks,
>
> Paul
>
>
> [1] https://review.coreboot.org/18221/
>
> --
> 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] VT-d support

[ron minnich]

On Mon, Jun 5, 2017 at 10:33 AM Himanshu Chauhan 
wrote:

>
> > oh, really? Why do you think that? Have you looked at the relevant MSR
> and what is the basis of your claim?
>
> I was just guessing what it could be. :)
>
>
I think it's a ton easier if you study on some simple hypervisors written
for VMX, it's a lot easier to know than to guess.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VT-d support

[Himanshu Chauhan]

> On 05-Jun-2017, at 10:50 PM, ron minnich  wrote:
> 
> 
> 
> On Mon, Jun 5, 2017 at 9:58 AM Himanshu Chauhan  
> wrote:
> 
> I think its can’t just be disabled.
> 
> oh, really? Why do you think that? Have you looked at the relevant MSR and 
> what is the basis of your claim?

I was just guessing what it could be. :)

> 
> ron 


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

Re: [coreboot] VT-d support

[Nico Huber]

Hi,

On 05.06.2017 18:58, Himanshu Chauhan wrote:
> 
>> On 05-Jun-2017, at 10:19 PM, ron minnich  wrote:
>>
>> The reason I ask about what you need is that on chromebooks the main
>> coreboot support came down to 'don't disable anything’. 
> 
> I think its can’t just be disabled. Its just that kernel is not given
> any knowledge about its existence. This is what I want to know. The
> commercial BIOSes give an option of “enable VT-d” support. What do they
> do when this option is selected? Can this be implemented in Coreboot?
> This probably brings me to your next question of what is required. I
> would spend some time to figure that out.

First thing, the firmware doesn't have to support it. It's only that
Intel chose _not_ to write per platform OS drivers and let the firm-
ware do the abstraction instead (I know a kernel that works pretty well
with VT-d even if there are no DMAR tables).

coreboot already handles VT-d support on some chipsets (GM45, Sandy/
Ivy Bridge come to mind). You can look how it's done there. If you are
lucky, you only need to add 20~30 lines to your chipset's code.

If your chipset needs special initialization, it's most probably docu-
mented in the BIOS Writer's Guide (BWG) or BIOS Specification. Though,
you need an NDA with Intel to get these.

Nico

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

Re: [coreboot] VT-d support

[ron minnich]

On Mon, Jun 5, 2017 at 9:58 AM Himanshu Chauhan 
wrote:

>
> I think its can’t just be disabled.
>

oh, really? Why do you think that? Have you looked at the relevant MSR and
what is the basis of your claim?

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

Re: [coreboot] VT-d support

[Himanshu Chauhan]

> On 05-Jun-2017, at 10:19 PM, ron minnich  wrote:
> 
> The reason I ask about what you need is that on chromebooks the main coreboot 
> support came down to 'don't disable anything’. 

I think its can’t just be disabled. Its just that kernel is not given any 
knowledge about its existence. This is what I want to know. The commercial 
BIOSes give an option of “enable VT-d” support. What do they do when this 
option is selected? Can this be implemented in Coreboot? This probably brings 
me to your next question of what is required. I would spend some time to figure 
that out.

> 
> The DMAR requirements are not met on all platforms. But even after boot you 
> can insert DMAR tables into kernels. 
> 
> So there is a key distinction between required support and desired support, 
> and I wonder if you could figure out what is required and let us know what it 
> is.
> 
> 

BTW, Do we have core boot tested on Intel’s Atom based C3xxx family SoCs?

> 
> On Mon, Jun 5, 2017 at 9:39 AM Zoran Stojsavljevic 
>  wrote:
> > what support does it need?
> 
> Intel Virtualization Technology for Directed I/O" (VT-d). VT-d is a 
> virtualized IOMMU, so by using HYP type 1 there should be a VT-d driver 
> supporting VT-d HW extension (?), as my best understanding is
> 
> The practical implications are Graphics and Network Connectivity in Guests. 
> DMA Remapping is the feature of VT-d.
> 
> Good net pointer to read: 
> https://unix.stackexchange.com/questions/34428/do-virtualbox-or-vmware-use-the-intel-vt-d-feature
> 
> > Is anybody working on this?
> 
> Don't think so... If anything is done, I guess, it is done by simplistic 
> implementation of the feature called: pass-through (so guest by its own 
> drivers is using directly platform devices' HW bypassing HYP1, my best guess).
> 
> Zoran
> On Mon, Jun 5, 2017 at 6:11 PM, ron minnich  wrote:
> 
> 
> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan  
> wrote:
> Hi,
> 
> VT-d requires support from BIOS. Does coreboot support VT-d?
> 
> 
> 
> what support does it need?  
> 
> --
> 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] VT-d support

[ron minnich]

The reason I ask about what you need is that on chromebooks the main
coreboot support came down to 'don't disable anything'.

The DMAR requirements are not met on all platforms. But even after boot you
can insert DMAR tables into kernels.

So there is a key distinction between required support and desired support,
and I wonder if you could figure out what is required and let us know what
it is.



On Mon, Jun 5, 2017 at 9:39 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > what support does it need?
>
> Intel Virtualization Technology for Directed I/O" (VT-d). VT-d is a
> virtualized IOMMU, so by using HYP type 1 there should be a VT-d driver
> supporting VT-d HW extension (?), as my best understanding is
>
> The practical implications are Graphics and Network Connectivity in
> Guests. DMA Remapping is the feature of VT-d.
>
> Good net pointer to read:
> https://unix.stackexchange.com/questions/34428/do-virtualbox-or-vmware-use-the-intel-vt-d-feature
>
> > Is anybody working on this?
>
> Don't think so... If anything is done, I guess, it is done by simplistic
> implementation of the feature called: pass-through (so guest by its own
> drivers is using directly platform devices' HW bypassing HYP1, my best
> guess).
>
> Zoran
> On Mon, Jun 5, 2017 at 6:11 PM, ron minnich  wrote:
>
>>
>>
>> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan 
>> wrote:
>>
>>> Hi,
>>>
>>> VT-d requires support from BIOS. Does coreboot support VT-d?
>>>
>>>
>>>
>> what support does it need?
>>
>> --
>> 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] VT-d support

[Himanshu Chauhan]

> On 05-Jun-2017, at 10:02 PM, Zaolin  wrote:
> 
> You are asking for VT-d support. You are talking about Intel platforms ?

Yes. I am talking about intel platforms. All CPUs that have VT-d support need 
support from motherboards as well. So any setup with VT-d enabled CPU and a 
motherboards that assists it, is what I am talking about.

> 
> But for which specific platform you are asking for ? There are so many..
> 
> 
> Am 05.06.2017 um 10:24 schrieb Himanshu Chauhan:
>> 
>>> On 05-Jun-2017, at 9:41 PM, ron minnich  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan  
>>> wrote:
>>> Hi,
>>> 
>>> VT-d requires support from BIOS. Does coreboot support VT-d?
>>> 
>>> 
>>> 
>>> what support does it need?  
>> BIOS adds DMAR and other entries in the ACPI table. I am not quite sure how 
>> these entries are formed exactly though.
>> 
>> https://www.mjmwired.net/kernel/Documentation/Intel-IOMMU.txt
>> 
>> http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
>> 
>> Is anybody working on this?
>> 
>> Regards
>> Himanshu
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 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] VT-d support

[Zoran Stojsavljevic]

> what support does it need?

Intel Virtualization Technology for Directed I/O" (VT-d). VT-d is a
virtualized IOMMU, so by using HYP type 1 there should be a VT-d driver
supporting VT-d HW extension (?), as my best understanding is

The practical implications are Graphics and Network Connectivity in Guests.
DMA Remapping is the feature of VT-d.

Good net pointer to read: https://unix.stackexchange.com/questions/34428/do-
virtualbox-or-vmware-use-the-intel-vt-d-feature

> Is anybody working on this?

Don't think so... If anything is done, I guess, it is done by simplistic
implementation of the feature called: pass-through (so guest by its own
drivers is using directly platform devices' HW bypassing HYP1, my best
guess).

Zoran

On Mon, Jun 5, 2017 at 6:11 PM, ron minnich  wrote:

>
>
> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan 
> wrote:
>
>> Hi,
>>
>> VT-d requires support from BIOS. Does coreboot support VT-d?
>>
>>
>>
> what support does it need?
>
> --
> 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] VT-d support

[Zaolin]

You are asking for VT-d support. You are talking about Intel platforms ?

But for which specific platform you are asking for ? There are so many..


Am 05.06.2017 um 10:24 schrieb Himanshu Chauhan:
>
>> On 05-Jun-2017, at 9:41 PM, ron minnich  wrote:
>>
>>
>>
>> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan  
>> wrote:
>> Hi,
>>
>> VT-d requires support from BIOS. Does coreboot support VT-d?
>>
>>
>>
>> what support does it need?  
> BIOS adds DMAR and other entries in the ACPI table. I am not quite sure how 
> these entries are formed exactly though.
>
> https://www.mjmwired.net/kernel/Documentation/Intel-IOMMU.txt
>
> http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf
>
> Is anybody working on this?
>
> Regards
> Himanshu
>
>
>
>




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] VT-d support

[Himanshu Chauhan]

> On 05-Jun-2017, at 9:41 PM, ron minnich  wrote:
> 
> 
> 
> On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan  
> wrote:
> Hi,
> 
> VT-d requires support from BIOS. Does coreboot support VT-d?
> 
> 
> 
> what support does it need?  

BIOS adds DMAR and other entries in the ACPI table. I am not quite sure how 
these entries are formed exactly though.

https://www.mjmwired.net/kernel/Documentation/Intel-IOMMU.txt

http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/vt-directed-io-spec.pdf

Is anybody working on this?

Regards
Himanshu




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

Re: [coreboot] VT-d support

[ron minnich]

On Mon, Jun 5, 2017 at 9:00 AM Himanshu Chauhan 
wrote:

> Hi,
>
> VT-d requires support from BIOS. Does coreboot support VT-d?
>
>
>
what support does it need?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] VT-d support

[Himanshu Chauhan]

Hi,

VT-d requires support from BIOS. Does coreboot support VT-d?

Regards
Himanshu Chauhan




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

Re: [coreboot] What does *intelblocks* mean?

[Aaron Durbin via coreboot]

On Mon, Jun 5, 2017 at 2:48 AM, Paul Menzel
 wrote:
> Dear coreboot folks,
>
>
> In commit a554b0c5b7 (soc/intel/common/block: Add Intel XHCI driver
> support) [1] the directory
> `src/soc/intel/common/block/include/intelblocks` is created.
>
> Could somebody please help me, what *intelblocks* means here, and why
> *intel* is twice in the path?

It's common code to be used for intel SoCs. 'ipblock' would be more
appropriate, but I think people didn't want to freak anyone out with
the name 'ip'. The reason 'intelblocks' is in the include path is
because the include headers are namespaced. e.g. #include
.


>
>
> Thanks,
>
> Paul
>
>
> [1] https://review.coreboot.org/18221/
>
> --
> 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] Current, BLOB free laptop available Europe?

[Mike Banon]

actually Lenovo G505S has more freedom in some relations, if compared
to Chromebook R13 : for example, G505S does not require blobs for WiFi
and Bluetooth if you replace its' preinstalled Broadcom half size mini
PCI-e card with Atheros AR9462 (which has 2.4 GHz + 5 GHz + Bluetooth
and is top-of-the-line ath9k card) and its' price is just $8-$10 with
free shipping included ;) also there are some great technical
opportunities which chromebooks do not have - e.g. you could replace
WiFi mini pci-e card with double SATA ports RAID card, or you can
install 16 GB of RAM because G505S RAM is not soldered ! Still could
get G505S in good condition at many USA / European markets, e.g.
yesterday at eBay I saw G505S based at USA which costs just $95, also
UK-based in nearly mint condition ;) Also there are a lot of spare
parts available, which helps to ensure the long lifetime of this great
performance quad core laptop ( Chromebook is not even close at
performance, as far as I know )

Best regards,
Mike Banon


On Wed, May 31, 2017 at 11:03 AM, Paul Kocialkowski  wrote:
> Hi,
>
> Le mardi 23 mai 2017 à 08:54 +0200, Paul Menzel a écrit :
>> I am looking for a new portable device available in Europe.
>>
>> Is it true, that the Acer Chromebook R 13 [1], is the only current BLOB
>> free device? The device currently costs 400 €. Is MediaTek “a good
>> citizen”, that means, do they provide datasheets and work on drivers?
>
> The Chromebook R13 (elm) is very close to being able to boot without non-free
> blobs. The only remaining blobs are the MT8173 PCM firmwares[0] in ARM Trusted
> Firmware. I am working hard to liberate them and I'm very confident that it 
> will
> happen pretty soon.
>
> However, note that the kernel will require blobs for features such as:
> * hardware video decoding
> * Wi-Fi and bluetooth
> * GPU support
>
> I'm also not sure about the status of the PD (USB type-C controller) chip. It
> might also be running a proprietary firmware (maybe someone from the CrOS team
> can clarify this).
>
> Also, note that as usual with laptops, there are lots of other non-free
> components around that are preinstalled on the device, such as the webcam
> firmware.
>
> Note that ARMv7 CrOS devices (mainly RK3288 and Tegra K1) can also boot 
> blobless
> and generally require less kernel blobs too. They also have much better 
> upstream
> Linux support than the ARMv8 ones (which are more recent). For instance, I'm
> running a mainline kernel on the Tegra K1 nyans, which is quite usable despite
> some issues that I have left to fix. There's also a very high chance that the
> GPU will work with nouveau and free firmwares eventually (I'll be working with
> nouveau developers to try and make this happen).
>
>> The Samsung Chromebook Plus/Pro with RK3399 [2] are only available in
>> the USA, right?
>
> I am not aware of it being available in Europe. However, if you're fine with a
> qwerty layout, they work just as well in Europe ;)
>
> RK3399 can currently already boot blobless but also requires kernel blobs.
> However, it seems that the boot is currently broken with coreboot master and 
> ToT
> depthcharge and vboot (I'll be investigating this soon).
>
> Also, the Chromebook Plus (kevin) does have a free software PD firmware.
>
> Finally, note that the Chromebook Pro is an Intel x86 device, so probably not
> very interesting given what you're looking for.
>
> Cheers,
>
> [0]: 
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8173/drivers/spm/spm_mcdi.c
>
> --
> Paul Kocialkowski, developer of free digital technology and hardware support
>
> Website: https://www.paulk.fr/
> Coding blog: https://code.paulk.fr/
> Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> --
> 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] MRC Raminit

[Kory Maincent]

Hi,

I am working on an embedded board from Interface concept.

The chipset is intel QM67 (Cougar point) with a sandybridge Gen2 processor.

I think the board doesn’t have any spd because I get the error “Not a DDR3
SPD!” so I try to do the mrc raminit with the systemagent-r6.bin but I am
stuck on the initialization:

System Agent: Starting up...

System Agent: Initializing PCH

System Agent: Initializing PCH (SMBUS)

System Agent: Initializing PCH (USB)

System Agent: Initializing PCH (SA Init)

System Agent: Initializing PCH (Me UMA)

System Agent: Initializing Memory

System Agent: failed to locate restore data hob!

System Agent: Done.



Can you help me to understand how to do the raminit?



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

[coreboot] What does *intelblocks* mean?

[Paul Menzel]

Dear coreboot folks,


In commit a554b0c5b7 (soc/intel/common/block: Add Intel XHCI driver
support) [1] the directory
`src/soc/intel/common/block/include/intelblocks` is created.

Could somebody please help me, what *intelblocks* means here, and why
*intel* is twice in the path?


Thanks,

Paul


[1] https://review.coreboot.org/18221/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot