Re: [coreboot] latest greatest thinkpad with coreboot

[Charlotte Plusplus]

I see recommendations for a X230, but I disagree. If you really want the
best, it's a W520 or a W530.

In either, you can have 32G of Ram, and you can replace the default CPU
with a Intel i7 3940XM cpu. But only on the W520 you will have a full size
display port and (more important) an eSATAp connector.

On thinkpads, you can usually have 3 drives:
 - a normal 2.5" SSD
 - another 2.5" in the optibay
 - a mSata in the WWAN port

But with the eSATAp connector, you can have 4 drives, one of which will be
external - either connected to the side of the laptop or to the dock.
Useful for backups at proper SATA speeds.

About the screen, the dock has extra display port connectors, and the
internal LCD is 1920x1080, not high resolution but good enough. The CPU
support vt-x and vt-d, so external displays can be used with qemu vfio (I
don't have a dock yet, but I plan to do that soon)

If we are talking about CPU, in theory, a modern P70 is faster. But if you
overclock the 3940XM to 4.6 GHz, there is no faster thinkpad on the market.
Cf the results from:
https://thinkpad-forum.de/threads/199076-Projekt-quot-Das-Letzte-Thinkpad-quot
(it requires a shell script to change the TDP and Turbo multipliers)

The only issues with the W520 on coreboot is the power consumption, which I
hope to fix when I will understand better how to talk to the EC to properly
disable the NVidia GPU like the default bios does.

With only the integrated 9 cell battery, I get about 4h, while putting my
SSD into a similar W530 (same CPU) where I can do proper power management
on the default bios, I get 7h (don't know how much precisely)

Add a slice battery if you need more battery time (approx double)

Charlotte


On Thu, Dec 1, 2016 at 12:04 PM, ron minnich  wrote:

> what's the latest best one? What's the battery life like (can't be worse
> than this mac pro  that's always hot and now seems to have a life of 90
> minutes, always). How much dram/ssd can I jam in it?
>
> thanks
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Sam Kuper]

On 02/12/2016, Nico Huber  wrote:
> The T430 seems to be unsupported.
> Also I guess, it would only be one or two days of work

One or two days of work for whom? E.g. did you have in mind a specific
person (if so, who?), or a non-specific person with a specific skill
set (if so, which skill set?)?

Is anyone reading this planning to spend that time on the T430 or
T430s in the coming weeks?

Thanks :)

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

Re: [coreboot] latest greatest thinkpad with coreboot

[Nico Huber]

On 02.12.2016 10:18, kitestramuort wrote:
> On Thu, 2016-12-01 at 23:53 +0100, Klemens Nanni wrote:
>> On Thu, Dec 01, 2016 at 11:35:36AM -0700, Trammell Hudson wrote:
>>> The major drawback is the low res screen.  I've been considering
>>> trying
>>> these hacked x230 machines with 2560x1440 screens for 2559Y (about
>>> $400?):
>>>
>>> https://item.taobao.com/item.htm?id=43820633263=main
>>> http://forum.51nb.com/thread-1662397-1-1.html
>>
>> Interesting, I wonder how well these replacement screens would work
>> with
>> coreboot? I assume the proprietary VGA Option ROM won't work with
>> those
>> and native graphics initialisation still needs some work on the X230
>> either ways.
> 
> 
> I have one of those. The dock DP lane is "hijacked" to fit the FHD eDP
> screen. In the BIOS (and in Windows) the signal is duplicated between
> the non-existent LVDS and DP, consuming more power. However it works
> very well in Linux with a small patch to the i915 module that disables
> the LVDS lane and forces DP-3 to be detected as eDP.
> 
> I tried doing the same in coreboot, playing with the source code, but
> couldn't figure out how to. It would be great to have the setup working
> "natively"

There's C code only for LVDS (nb/intel/sandybridge) and eDP (mb/google
/link). No support for the PCH's DPs.

There's Ada code now, that supports quite a lot (3rdparty/libgfxinit).
It would require a small patch to make the panel power sequencing work
along with the DP. I can help you with that if you want to try.

Nico


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

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Nico Huber]

On 02.12.2016 19:53, ron minnich wrote:
> yeah I'm similarly confused about the t430 state but nico is giving me hope.

Um, I was just comparing specs, sorry. The T430 seems to be unsupported.
Also I guess, it would only be one or two days of work, I wouldn't con-
sider to buy it. It's basically just heavier than the T430s (and some
come with the shitty NVIDIA Optimus graphics).

> 
> On Fri, Dec 2, 2016 at 9:15 AM Sam Kuper  wrote:
> 
>> On 01/12/2016, Nico Huber  wrote:
>>> On 01.12.2016 18:50, Klemens Nanni wrote:
 On Thu, Dec 01, 2016 at 05:04:36PM +, ron minnich wrote:
> what's the latest best one?
>
 X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced
 (830K) ME

>>> Everything Klemens said about the X230 should also apply to the
>>> T430s. It's just 14" instead of 12".
>>
>> Has anyone here actually tried running Coreboot with a reduced ME on a
>> T430 or T430s?

I haven't tried (don't even have the system), but I wouldn't expect any
trouble with a reduced ME image. It's more chipset than board specific,
FWIW.

>>
>> The Coreboot wiki does not even have pages for those models...
>>
>> https://www.coreboot.org/Board:lenovo/t430
>>
>> https://www.coreboot.org/Board:lenovo/t430s

Perfect, I think you found the first board without outdated information
in the wiki :-D

Nico


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

Re: [coreboot] Anyone have a experence the u-boot on coreboot?(Rangeley platform)

[David Hendricks via coreboot]

Yep, probably more relevant to the U-Boot mailing list but nice to see it
here as well!

On Thu, Dec 1, 2016 at 11:43 PM, Yaroslav K.  wrote:

> Hello!
>
> I'm successfully using U-boot with Coreboot on the Rangeley platform
> with the attached dts file. I'm not sure if everything in it is needed
> and/or correct, but it works fine.
> serial1.dtsi was needed so that the second UART is used as stdout.
>
> Although, this question looks like more relevant to the U-boot mailing
> list than the Coreboot one.
>
> --
> Yaroslav
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] xHCI support for x86

[Julius Werner]

> Do i need to flush cache if event and command rings are located in "normal"
> memory?

All Intel chipsets I know of support full cache snooping for the
integrated XHCI controller, so you shouldn't need any cache
management. Or are you trying to use an external (e.g. PCIe) XHCI
controller? In that case I think(?) you should still be able to
configure it to cache snoop, but I'm not really an expert in x86
peripherals.

> I use a custom allocator and for now it is not possible to allocate memory as 
> "uncachable"

If your controller really can't cache snoop, then this is the only
supported mechanism to deal with it, sorry. You should be able to set
aside a separate memory region and configure it as uncacheable through
MTRRs or something. (Standard coreboot/libpayload does this by
configuring the memory region in coreboot and then informing
libpayload of it via the LB_TAB_DMA coreboot table entry.

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

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[ron minnich]

yeah I'm similarly confused about the t430 state but nico is giving me hope.



On Fri, Dec 2, 2016 at 9:15 AM Sam Kuper  wrote:

> On 01/12/2016, Nico Huber  wrote:
> > On 01.12.2016 18:50, Klemens Nanni wrote:
> >> On Thu, Dec 01, 2016 at 05:04:36PM +, ron minnich wrote:
> >>> what's the latest best one?
> >>>
> >> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced
> >> (830K) ME
> >>
> > Everything Klemens said about the X230 should also apply to the
> > T430s. It's just 14" instead of 12".
>
> Has anyone here actually tried running Coreboot with a reduced ME on a
> T430 or T430s?
>
> The Coreboot wiki does not even have pages for those models...
>
> https://www.coreboot.org/Board:lenovo/t430
>
> https://www.coreboot.org/Board:lenovo/t430s
>
> Thanks!
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Sam Kuper]

On 01/12/2016, Nico Huber  wrote:
> On 01.12.2016 18:50, Klemens Nanni wrote:
>> On Thu, Dec 01, 2016 at 05:04:36PM +, ron minnich wrote:
>>> what's the latest best one?
>>>
>> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced
>> (830K) ME
>>
> Everything Klemens said about the X230 should also apply to the
> T430s. It's just 14" instead of 12".

Has anyone here actually tried running Coreboot with a reduced ME on a
T430 or T430s?

The Coreboot wiki does not even have pages for those models...

https://www.coreboot.org/Board:lenovo/t430

https://www.coreboot.org/Board:lenovo/t430s

Thanks!

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

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2

[Grigore Lupescu via coreboot]

Restarting the config from scratch and setting Keep Vesa framebuffer I am
able to enter gfxterm in GRUB2.
Linux is also booting now, happy day :)

On Fri, Dec 2, 2016 at 3:24 PM, Grigore Lupescu  wrote:

> Hi Zoran,
>
> Thanks for your suggestions - it may not be vBIOS but it's most likely
> somewhere around there.
>
> I updated the VBIOS from Coreboot (~2014) with the newest one from AMD
> (~2015) with no impact on the behavior.
> At this point I think the Coreboot settings for the platform may cause
> this i.e. for some reason *vga_text* is chosen over *gfxterm* which is
> not even configured but barely exists.
>
> I have though managed to improve the status of the *vga_text* mode. So
> GRUB2 was restarting when reaching the end of the screen. I traced this to
> the *screen_read_char* which is issued when the *inc_y* == ROWS (this
> call would break GRUB2). I didn't go even further with the debug though. I
> just clear the screen and set grub_curr_pos.y to 0 and by using set pager=1
> I can browse with enter through all the output page by page. It's not ideal
> but it was fast and practical.
>
> Linux though still doesn't boot. I am currently looking why the vga_text
> mode is selected over gfxterm which is not even configured properly.
>
> Thanks,
> Grigore
>
> On Wed, Nov 30, 2016 at 7:15 PM, Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Hello Grigore,
>>
>> Did not abandon you ("Dr. House" lookalike, same age, same attitude). I
>> though about the issue... Gave it hard try/thought! At least, I have tried.
>> And here is what I came with...
>>
>> > Differences on GRUB2 environment:
>> > AMI BIOS + *GRUB2.02beta2-36ubuntu3.1* => terminal_output=*gfxterm*,
>> see USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works
>> > both on USB2.0 and USB3.0.
>> > Coreboot + *GRUB2.02beta3* => terminal_output=*vga_text*, see USB-SATA
>> SSD as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>>
>> So... Here are bullet points:
>> [1] Above: you are telling/writing to me that Coreboot has newest GRUB2
>> SW than Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic??? Question to
>> you: are you sure? Please, check again?
>> [2] *VERY/CRITICALLY important:* Are you sure that in BOTH cases above
>> you are using *THE SAME vBIOS *component?
>> In other words, you should go to:  https://ami.com/products/bios
>> -uefi-tools-and-utilities/bios-uefi-utilities/... And try to extract
>> vBIOS out of your AMI BIOS you are alternately using to test... And
>> replace/swap one (you are using currently) in Coreboot.
>>
>> Good luck! :-)
>> Zoran
>> ___
>>
>> On Tue, Nov 29, 2016 at 2:44 PM, Grigore Lupescu 
>> wrote:
>>
>>> Hello Zoran,
>>> First of all thank you very much for your feedback - any idea would be
>>> worth trying.
>>>
>>> I am sorry about the mixup by putting the 3.13 commands there (it was
>>> 4.4 actually). I use TAB press to get the actual version on the SSD drive
>>> (4.4.0-31) and those exact commands. So my bad on the last email, these are
>>> the actual ones:
>>>
>>> grub> set root=(hd0,gpt2)
>>> grub> linux /boot/vmlinuz-4.4...-generic root=/dev/sda2
>>> grub> initrd /boot/initrd.img-4.4...-generic
>>> grub> boot
>>>
>>> So I am trying to boot from an SSD with Linux connected to a USB port -
>>> why I am doing this ? :) because the board has a dedicated embedded style
>>> power supply and 1 SATA cable, hence even though I can connect the SSD
>>> directly I cannot power it - so I use a USB to SATA drive where I have the
>>> SSD plugged in (and legacy Ubuntu Linux x64 4.4 on it).
>>>
>>> Below are the full details of the AMI BIOS, Linux OS, Coreboot I am
>>> trying to boot over Coreboot (latest). So looking at these ++ previous ones
>>> it looks like vBIOS is in both.
>>>
>>> AMI BIOS 2.17.1246 Copyright 2015
>>> Core Version 4.6.5.4
>>> UEFI 2.3.1; PI 1.2
>>> Project Version 1ASNG 0.02 x64
>>> Chipset->GFX Configuration
>>> IGD VBIOS Version ATOMBIOSBK-AMD VERO15.042.000.002.000
>>> Advanced->CPU Configuration
>>> AGESA Version 1.0.0.5
>>> terminal_output: *gfxterm*
>>>
>>> Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic #50 Ubuntu SMP Wed Jul
>>> 13 UTC 2016 x86_64
>>> GNU GRUB 2.02~beta2-36ubuntu3.1
>>>
>>> Coreboot (latest branch)
>>> I have the latest Coreboot sources, have set config accordingly (e.g.
>>> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
>>> on HDMI and the GRUB2 payload is executing. In GRUB2 payload I seem to have
>>> an overflow issue possibly related to the *vga_text* mode.
>>> terminal_output: *vga_text*
>>> GRUB 2.02 beta3
>>>
>>> Differences on GRUB2 environment:
>>> AMI BIOS + GRUB2.02beta2-36ubuntu3.1 => terminal_output=*gfxterm*, see
>>> USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works both on USB2.0 and
>>> USB3.0.
>>> Coreboot + GRUB2.02beta3 => terminal_output=*vga_text*, see USB-SATA
>>> SSD as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>>>
>>> Thank you,
>>> Grigore
>>>
>>> On Mon, Nov 

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2

[Grigore Lupescu via coreboot]

Hi Zoran,

Thanks for your suggestions - it may not be vBIOS but it's most likely
somewhere around there.

I updated the VBIOS from Coreboot (~2014) with the newest one from AMD
(~2015) with no impact on the behavior.
At this point I think the Coreboot settings for the platform may cause this
i.e. for some reason *vga_text* is chosen over *gfxterm* which is not even
configured but barely exists.

I have though managed to improve the status of the *vga_text* mode. So
GRUB2 was restarting when reaching the end of the screen. I traced this to
the *screen_read_char* which is issued when the *inc_y* == ROWS (this call
would break GRUB2). I didn't go even further with the debug though. I just
clear the screen and set grub_curr_pos.y to 0 and by using set pager=1 I
can browse with enter through all the output page by page. It's not ideal
but it was fast and practical.

Linux though still doesn't boot. I am currently looking why the vga_text
mode is selected over gfxterm which is not even configured properly.

Thanks,
Grigore

On Wed, Nov 30, 2016 at 7:15 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Grigore,
>
> Did not abandon you ("Dr. House" lookalike, same age, same attitude). I
> though about the issue... Gave it hard try/thought! At least, I have tried.
> And here is what I came with...
>
> > Differences on GRUB2 environment:
> > AMI BIOS + *GRUB2.02beta2-36ubuntu3.1* => terminal_output=*gfxterm*,
> see USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works
> > both on USB2.0 and USB3.0.
> > Coreboot + *GRUB2.02beta3* => terminal_output=*vga_text*, see USB-SATA
> SSD as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>
> So... Here are bullet points:
> [1] Above: you are telling/writing to me that Coreboot has newest GRUB2 SW
> than Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic??? Question to you:
> are you sure? Please, check again?
> [2] *VERY/CRITICALLY important:* Are you sure that in BOTH cases above
> you are using *THE SAME vBIOS *component?
> In other words, you should go to:  https://ami.com/products/
> bios-uefi-tools-and-utilities/bios-uefi-utilities/... And try to extract
> vBIOS out of your AMI BIOS you are alternately using to test... And
> replace/swap one (you are using currently) in Coreboot.
>
> Good luck! :-)
> Zoran
> ___
>
> On Tue, Nov 29, 2016 at 2:44 PM, Grigore Lupescu 
> wrote:
>
>> Hello Zoran,
>> First of all thank you very much for your feedback - any idea would be
>> worth trying.
>>
>> I am sorry about the mixup by putting the 3.13 commands there (it was 4.4
>> actually). I use TAB press to get the actual version on the SSD drive
>> (4.4.0-31) and those exact commands. So my bad on the last email, these are
>> the actual ones:
>>
>> grub> set root=(hd0,gpt2)
>> grub> linux /boot/vmlinuz-4.4...-generic root=/dev/sda2
>> grub> initrd /boot/initrd.img-4.4...-generic
>> grub> boot
>>
>> So I am trying to boot from an SSD with Linux connected to a USB port -
>> why I am doing this ? :) because the board has a dedicated embedded style
>> power supply and 1 SATA cable, hence even though I can connect the SSD
>> directly I cannot power it - so I use a USB to SATA drive where I have the
>> SSD plugged in (and legacy Ubuntu Linux x64 4.4 on it).
>>
>> Below are the full details of the AMI BIOS, Linux OS, Coreboot I am
>> trying to boot over Coreboot (latest). So looking at these ++ previous ones
>> it looks like vBIOS is in both.
>>
>> AMI BIOS 2.17.1246 Copyright 2015
>> Core Version 4.6.5.4
>> UEFI 2.3.1; PI 1.2
>> Project Version 1ASNG 0.02 x64
>> Chipset->GFX Configuration
>> IGD VBIOS Version ATOMBIOSBK-AMD VERO15.042.000.002.000
>> Advanced->CPU Configuration
>> AGESA Version 1.0.0.5
>> terminal_output: *gfxterm*
>>
>> Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic #50 Ubuntu SMP Wed Jul
>> 13 UTC 2016 x86_64
>> GNU GRUB 2.02~beta2-36ubuntu3.1
>>
>> Coreboot (latest branch)
>> I have the latest Coreboot sources, have set config accordingly (e.g.
>> CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image
>> on HDMI and the GRUB2 payload is executing. In GRUB2 payload I seem to have
>> an overflow issue possibly related to the *vga_text* mode.
>> terminal_output: *vga_text*
>> GRUB 2.02 beta3
>>
>> Differences on GRUB2 environment:
>> AMI BIOS + GRUB2.02beta2-36ubuntu3.1 => terminal_output=*gfxterm*, see
>> USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works both on USB2.0 and
>> USB3.0.
>> Coreboot + GRUB2.02beta3 => terminal_output=*vga_text*, see USB-SATA SSD
>> as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>>
>> Thank you,
>> Grigore
>>
>> On Mon, Nov 28, 2016 at 10:40 PM, Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>> Grigore,
>>>
>>> Here are my comments to what you wrote to me:
>>>
>>> On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu 
>>> wrote:
>>>
 Hello Zoran,

 [1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel.

>>>
>>> 

Re: [coreboot] Anyone have a experence the u-boot on coreboot?(Rangeley platform)

[Yaroslav K.]

Hello!

I'm successfully using U-boot with Coreboot on the Rangeley platform
with the attached dts file. I'm not sure if everything in it is needed
and/or correct, but it works fine.
serial1.dtsi was needed so that the second UART is used as stdout.

Although, this question looks like more relevant to the U-boot mailing
list than the Coreboot one.

-- 
Yaroslav


mohonpeak.dts
Description: Binary data


serial1.dtsi
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] xHCI support for x86

[Pitrolle Jean-Jacques]

Hello *,
Sorry for delay, but i have to understand a lot things before answering (:

On 23/11/2016 14:25, Nico Huber wrote:

Hi,

On 23.11.2016 11:09, Pitrolle Jean-Jacques wrote:

Hello *,
I try to integrate coreboot *libpayload usb stack* in a custom binary
for x86.
I already succeed integration of *ehci* for *qemu* and *core 2 duo*
platforms.

But things seems to be not so easy for *xhci*.
When I try to run coreboot master branch (with hash 8bf3f7a) on qemu
(version 2.7.0)
with following line :
  % qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -drive
if=none,id=usbstick,file=/tmp/qemu_usb.disk -usb -device
nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=usbstick

I get these output lines concerning xHCI controller (nec-usb-xhci) :
8<---
[..]
00:04.0 0194:1033.0 xHCI controller
xhci_init: regbase: 0xfe07
xhci_init: caplen:  0x40
xhci_init: rtsoff:  0x1000
xhci_init: dboff:   0x2000
xhci_init: hciversion: 0.0
xhci_init: Unsupported xHCI version
[..]
--->8

The same result is reached with qemu-system-i386...

Is it the expected result on qemu?

it looks odd to me. We wrote the ancestor of this xHCI driver against
qemu but stopped testing it when we switched to real hardware. I would
have expected an hciversion around 0.9*. The libpayload driver currently
checks for hciversion > 0.96. The values above hciversion look sane, so
I suspect  qemu to tell a bad version.


The functions that access virtual xHCI only works for 4 bytes access.
For example, if i read capability register
  - access to offset 0, size access 4 bytes : 140
  - access to offset 2, size access 2 bytes : 00  *wrong value*
  - access to offset 2 and 3, size access 1 bytes: 0 - 0 *wrong value*
The 8bit/16bit reads are not properly honored.

Moreover, the previous *used* qemu (2.7.0) compiled by my own with 
custom configuration

seems to be broken (i don't go too deep in investigation right now)..
Everything is ok with *upstream* qemu (hash : 00227f - version : 2.7.91 
_ v2.8.0-rc1-dirty)

I don't have any motherboard supported by coreboot, so I try a custom
binary  on

How is this custom binary build? In which environment does it run? It's
hard to make assumptions about the driver without knowing the details.


a *Xeon* processor (processor D-1500).

So you are using the xHCI controller built into the SoC? or an extension
card?

I use xHCI controller built into SoC.

The xHCI version is supported (hciversion: 1.0) but things turn bad when
starting
xHCI controller i.e xhci->opreg->usbcmd |= USBCMD_RS in *xhci_start* :
the program hangs...
The registers usbcmd and usbsts before this command seems to have proper
values (a usb key
is connected.)
8<---
[..]
  xhci_start - usbcmd:0 - usbsts:11
[..]
--->8

This seems to be related to interrupter configuration. When I comment
out the two lines
in *xhci_reinit*
8<---
[..]
 xhci->hcrreg->intrrs[0].erstba_lo = virt_to_phys(xhci->ev_ring_table);

I'd suspect that the address returned by virt_to_phys() is wrong or not
accessible by the controller.

Hmm, seems not as it work properly with rigth qemu version.

 xhci->hcrreg->intrrs[0].erstba_hi = 0;

Are you sure it's a 32-bit address?

I used a 32 bits compiler, so i expect it..
Do i need to setup something else (in bios for example)?

[..]
--->8
xhci_start works as expected i.e not hangs.

But the sequence following with *NOOP* to test command ring and event
ring mechanism fails.
8<---
[..]
NOOP run #0
Transfer TRB (@0x8051700):
  PTR_L  0x
  PTR_H  0x
  STATUS 0x
  CNTRL  0x5c00
  TL 0x
  TDS0x
  C  0x
  ISP0x
  CH 0x
  IOC0x
  IDT0x
  TT 0x0017
  DIR0x
Command 23 (@0x8051700)
Warning: Timed out waiting for TRB_EV_CMD_CMPL.
Command ring is running
[..]
--->8

As I understand it is mandatory to have the first interrupter configure
to manage
at least one event ring (4.9.4 Event Ring Management - eXtensible Host
Controller Interface
Revision 1.1).

Does someone succeed with xHCI support for x86 board?
Did I miss something concerning xHCI configuration?

It's working in coreboot payloads in many production systems.
With values read from registers dboff (0x3000) and rtsoff (0x2000) and 
not values provided in
datasheet (*wrong values*) write to USBCMD register to start controller 
works as expected : there

is no weird hanging.
The problem came from *extended capability register* xCAP. In my case it 
is mandatory to release xHCI
controller from BIOS. "HC BIOS Owned Semaphore" must be set to 0 and "HC 
OS Owned Semaphore" must

be set to 1.

Nico

So things go ahead :
  - enumeration of a usb-key on *qemu* works properly.
  - *but* i still have a problem on Xeon (Broadwell-DE SoC).

The problem concerns event ring during enable slot command :
8<---
[..]
Command 9 (@0x8052240)
Transfer TRB (@0x8052240):
 PTR_L  0x
 PTR_H  0x
 STATUS 0x
 CNTRL  0x2400
 TL 0x
 TDS0x
 C  0x
 ISP 

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

47 new defect(s) introduced to coreboot found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 20 of 47 defect(s)


** CID 1366756:  Control flow issues  (DEADCODE)
/src/lib/spd_bin.c: 165 in get_spd_smbus()



*** CID 1366756:  Control flow issues  (DEADCODE)
/src/lib/spd_bin.c: 165 in get_spd_smbus()
159 get_spd(spd_data_ptr + i * CONFIG_DIMM_SPD_SIZE,
160 0xA0 + (i << 1));
161 blk->spd_array[i] = spd_data_ptr + i * 
CONFIG_DIMM_SPD_SIZE;
162 }
163 
164 for (j = i; j < CONFIG_DIMM_MAX; j++)
>>> CID 1366756:  Control flow issues  (DEADCODE)
>>> Execution cannot reach this statement: "blk->spd_array[j] = NULL;".
165 blk->spd_array[j] = NULL;
166 
167 update_spd_len(blk);

** CID 1366755:  Error handling issues  (CHECKED_RETURN)
/src/lib/spd_bin.c: 120 in get_spd_cbfs_rdev()



*** CID 1366755:  Error handling issues  (CHECKED_RETURN)
/src/lib/spd_bin.c: 120 in get_spd_cbfs_rdev()
114 int get_spd_cbfs_rdev(struct region_device *spd_rdev, u8 spd_index)
115 {
116 struct cbfsf fh;
117 
118 uint32_t cbfs_type = CBFS_TYPE_SPD;
119 
>>> CID 1366755:  Error handling issues  (CHECKED_RETURN)
>>> Calling "cbfs_boot_locate" without checking return value (as is done 
>>> elsewhere 10 out of 11 times).
120 cbfs_boot_locate(, "spd.bin", _type);
121 cbfs_file_data(spd_rdev, );
122 return rdev_chain(spd_rdev, spd_rdev, spd_index * 
CONFIG_DIMM_SPD_SIZE,
123 
CONFIG_DIMM_SPD_SIZE);
124 }
125 

** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()



*** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 831 in parse_subpart_dir()
825 memcpy(hdr.name, data + offset, sizeof(hdr.name));
826 offset += sizeof(hdr.name);
827 
828 validate_subpart_dir_without_checksum((struct subpart_dir 
*), name);
829 
830 assert(size > subpart_dir_size());
>>> CID 1361275:(TAINTED_SCALAR)
>>> Passing tainted variable "subpart_dir_size()" to a tainted sink.
831 alloc_buffer(subpart_dir_buf, subpart_dir_size(), "Subpart 
Dir");
832 memcpy(buffer_get(subpart_dir_buf), , 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = _dir->e[0];
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()
832 memcpy(buffer_get(subpart_dir_buf), , 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = _dir->e[0];
837 uint32_t i;
>>> CID 1361275:(TAINTED_SCALAR)
>>> Using tainted variable "hdr.num_entries" as a loop boundary.
838 for (i = 0; i < hdr.num_entries; i++) {
839 memcpy(e[i].name, data + offset, sizeof(e[i].name));
840 offset += sizeof(e[i].name);
841 offset = read_member(data, offset, sizeof(e[i].offset),
842  [i].offset);
843 offset = read_member(data, offset, sizeof(e[i].length),

** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)



*** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer()
711 {
712 struct bpdt_header bpdt_header;
713 assert((offset + BPDT_HEADER_SIZE) < size);
714 bpdt_read_header((uint8_t *)data + offset, _header, name);
715 
716 /* Buffer to read BPDT header and entries. */
>>> CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted variable "get_bpdt_size(_header)" to a tainted 
>>> sink.
717 alloc_buffer(b, get_bpdt_size(_header), name);
718 
719 struct bpdt *bpdt = buffer_get(b);
720 memcpy(>h, _header, BPDT_HEADER_SIZE);
721 
722 /*

** CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry()

Re: [coreboot] latest greatest thinkpad with coreboot

[kitestramuort]

On Fri, 2016-12-02 at 10:07 +, Peter Stuge wrote:
> kitestramuort wrote:
> > However it works very well in Linux with a small patch to the i915
> > module that disables the LVDS lane and forces DP-3 to be detected
> > as eDP.
> 
> Could you pass me a link to this patch please?

http://pastebin.com/WF6wdfpb


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

Re: [coreboot] latest greatest thinkpad with coreboot

[Peter Stuge]

kitestramuort wrote:
> However it works very well in Linux with a small patch to the i915
> module that disables the LVDS lane and forces DP-3 to be detected
> as eDP.

Could you pass me a link to this patch please?


Thanks a lot

//Peter

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

Re: [coreboot] latest greatest thinkpad with coreboot

[Peter Stuge]

Philipp Stanner wrote:
> By the way:
> 
> Is it true that coreboot consumes more power ( = shorter battery life)
> than vendor bios?

May be. coreboot supports a few hundred mainboards. It would be great
if you help collect some data.

It would be even greater if you find data points where coreboot *has*
worse power consumption and then help us by researching exactly why
that is.

And in the end the easy part, please send patches.


Thanks

//Peter

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

Re: [coreboot] latest greatest thinkpad with coreboot

[kitestramuort]

On Thu, 2016-12-01 at 23:53 +0100, Klemens Nanni wrote:
> On Thu, Dec 01, 2016 at 11:35:36AM -0700, Trammell Hudson wrote:
> > The major drawback is the low res screen.  I've been considering
> > trying
> > these hacked x230 machines with 2560x1440 screens for 2559Y (about
> > $400?):
> > 
> > https://item.taobao.com/item.htm?id=43820633263=main
> > http://forum.51nb.com/thread-1662397-1-1.html
> 
> Interesting, I wonder how well these replacement screens would work
> with
> coreboot? I assume the proprietary VGA Option ROM won't work with
> those
> and native graphics initialisation still needs some work on the X230
> either ways.


I have one of those. The dock DP lane is "hijacked" to fit the FHD eDP
screen. In the BIOS (and in Windows) the signal is duplicated between
the non-existent LVDS and DP, consuming more power. However it works
very well in Linux with a small patch to the i915 module that disables
the LVDS lane and forces DP-3 to be detected as eDP.

I tried doing the same in coreboot, playing with the source code, but
couldn't figure out how to. It would be great to have the setup working
"natively"

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

Re: [coreboot] latest greatest thinkpad with coreboot

[Peter Stuge]

Trammell Hudson wrote:
> Do we require any sort of VGA init if the payload has the kernel
> framebuffer and mode support?

As far as I know the answer for more recent kernels is "sortof".

It used to be that i915 in the kernel was completely independent. It
would initialize GPU and turn on the panel with native resolution.

At some point in 4.x there was a change in i915 to make it depend on
the VBT embedded into the VGA option ROM.

coreboot may or may not be able to generate a satisfactory VBT on its
own. In theory of course it could. I just don't expect the C code to
be complete.

I like Nico's approach a lot. I would not mind if we integrated that
as the graphics init for relevant platforms, looking ahead maybe even
expanding its coverage to further platforms.


//Peter

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