Re: [coreboot] Why is subsystemid required to find a uPD7020200

[Charlotte Plusplus]

Hello

No, I don't have this error anymore. I changed first the RCBA, to no
effect. It was only after I added the subsystemid that  the XHCI controller
was detected on linux and windows.

I use linux mostly, but I have a windows 10 for tests. USB3 works fine for
both, while previously it did not show up in the lspci of either.

Wat's interesting is that I do have some problems with the colormeter
(X-Rite) on windows. I will try to add the subsystemid to see if it helps
the driver.

Next on my list: getting native video init to work!

Thanks
Charlotte

On Tue, Nov 15, 2016 at 8:57 AM, Nico Huber  wrote:

> On 15.11.2016 03:03, Charlotte Plusplus wrote:
> > Hello
> >
> > The USB3 on a W520 is provided by a uPD7020200 on PCIe port 7, so I just
> > had in my device tree:
> > device pci 1c.6 on end
> >
> > Yet in the boot I was getting:
> >  PCI: Static device PCI: 00:1c.6 not found, disabling it.
>
> This error message is unrelated to the subsystem id. In this case, core-
> boot can't even set the id. It looks more like 00:1c.6 was (still?) dis-
> abled through the function disable (FD) register? I don't know if it
> gets cleared on every reboot.Do you still set it in early romstage?
>
> Nico
>
> >
> > After googlging about this, I found the x230 uses subsystemid
> >  device pci 1c.6 on subsystemid 0x17aa 0x21db end
> >
> > After trying that, I could get the USB3 to be detected and working
> > correctly on the W520.
> >
> > Nowhere else I need subsystemid, so I don't understand why it is needed
> > here.
> > I don't want to copy something I don't understand, especially if it may
> be
> > needed in other places.
> >
> > Could someone explain when subsystemid is required?
> >
> > Thanks
> > Charlotte
> >
> >
> >
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] native video init question

[Nico Huber]

Hi,

On 14.11.2016 06:43, Charlotte Plusplus wrote:
> Hello
> 
> Here is the current status of my W520:
>  - native video init gives a garbled image (picture available upon request
> lol). it may be due to the resolution of the screen being hardcoded
> somewhere, or more likely me using the wrong information since the W520
> uses 1980x1080
>  - non native video works fine

I've seen a garbled image, too, lately. When I built with native
raminit by chance but with a completely different gfx init code
(3rdparty/libgfxinit). So it might still be some problem in the
raminit. This was also on an Ivy Bridge system with four DIMMs,
btw. I suspected that the native raminit just wasn't tested in that
configuration.

>  - with native ram init, the memory tends to be unstable unless great care
> is used (basically blindly increasing SPD latencies and setting
> max_mem_clock_mhz=666)

>  - with native ram init, even with that sometimes the boots stop on:
> "discover timC write:
> CPB
> t123: 1048, 6000, 7620"

>  - with non native ram init, there is no video

>  - various dmaerr unless iommu is disabled

>  - the USB3 controller is not showing in lscpi, even if I am quite sure it
> is on the right PCIE (likely due to the RCBA32 I am using)

>  - the modem codec is not detected by snd-hda-intel even if the probe is
> forced

>  - some other unknown things may not work.
> 
> At the moment, I am trying to advance with native video first as it is a
> low hanging fruit: I'm quite sure the gfx.did or LVDS settings in my
> devicetree must be wrong.
> 
> How can I guess the right ones after booting with the videorom?

Well, I don't see any setting that could really break something. The
code might just be buggy. I'll go through the settings anyway, taking
src/mainboard/lenovo/t520/devicetree.cb as example:

> # IGD Displays
> register "gfx.ndid" = "3"
> register "gfx.did" = "{ 0x8100, 0x8240, 0x8410, 0x8410, 
> 0x0005 }"

That's about ACPI, let's not care (the last appendix in the ACPI spec if
you want to have a look).

> # Enable DisplayPort Hotplug with 6ms pulse
> register "gpu_dp_d_hotplug" = "0x06"

Not native gfx init related, I wonder why the firmware should set this
at all.

> # Enable Panel as LVDS and configure power delays
> register "gpu_panel_port_select" = "0"  # LVDS
> register "gpu_panel_power_cycle_delay" = "5"
> register "gpu_panel_power_up_delay" = "300" # T1+T2: 30ms
> register "gpu_panel_power_down_delay" = "300"   # T5+T6: 30ms
> register "gpu_panel_power_backlight_on_delay" = "2000"  # T3: 200ms
> register "gpu_panel_power_backlight_off_delay" = "2000" # T4: 200ms

Those are real register settings, you can dump the whole GMA MMIO
space with `inteltool -f` (hoping that your system doesn't hang). The
registers are described in [1, chapter 2.4].

> register "gfx.use_spread_spectrum_clock" = "1"

This is set in DPLL_CTL bits 15:13 (there are two registers, just boot
with only the internal display and read the first register, 0xc6014 [1,
2.3.1]).

> register "gfx.link_frequency_270_mhz" = "1"

This setting is only documented for Nehalem ([3, 2.10.1] the lowest
8 bits). Linux always assumes 270MHz for Sandy/Ivy Bridge (which con-
tradicts our setting for the MacBookAir4,2 but that might be wrong).

> register "gpu_cpu_backlight" = "0x1155"

Just wrong see [2, chapter 3.9.2], it must not be higher than the up-
per 16 bits in the next register.

> register "gpu_pch_backlight" = "0x06100610"

The upper 16 bits give a divisor for the backlight PWM [1, 2.5.2]. The
lower give the duty cycle, iff bit30 of register 0xc8250 is set, which
we do not set (i.e. the gpu_cpu_backlight value above is in charge).
So the lower 16 bits can be just zero.

Hope that helps,
Nico

[1]
https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf

[2]
https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part3.pdf

[3]
https://01.org/sites/default/files/documentation/ilk_ihd_os_vol3_part2r2.pdf

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

Re: [coreboot] TINT payload major update!

[Mike Banon]

Finally I found a way to commit this (after a few more changes, also
attaching a final version to this letter just in case) -
https://review.coreboot.org/#/c/17439/1

Problem with this commit is a false positive error generated by
lint.lint-stable-008-kconfig :

#! Error: IS_ENABLED() used on unknown value CONFIG_LP_USB at
payloads/external/tint/libpayload_tint.patch:378.
# 1 errors

despite that CONFIG_LP_USB is always defined by:
#ifndef CONFIG_LP_USB
#define CONFIG_LP_USB 1
#endif
and also in libpayload.

Please tell, how to suppress this error, or maybe there is a
workaround to make it disappear?

Best regards,
Mike Banon

On Mon, Nov 14, 2016 at 11:09 PM, Mike Banon  wrote:
> Please scroll down to the end of letter to download the attachments
> ("Non-text attachment was scrubbed..."), don't copy paste (because
> Google ate my tabs and broke the files)
>
>
> On Mon, Nov 14, 2016 at 10:50 PM, Mike Banon  wrote:
>> There are (were) five problems with a TINT payload:
>> 1) It is outdated: version 0.03b vs the latest 0.04+nmu1 . Two buffer
>> overflows have been fixed since that, as well as some other
>> improvements
>> 2) When you press 'p', "Paused - Press any key to continue" message is
>> not displayed - because there are no "refresh()" functions between
>> "out_printf" and "while" waiting cycle
>> 3) When you lose or quit, PC does not reboot - could only reboot by
>> the power button, really inconvenient. Meanwhile, coreinfo and
>> nvramcui payloads have a working reboot function "outb(0x6, 0xcf9);"
>> which could be borrowed
>> 4) libpayload_tint.patch is bloated - could reduce it in half for the
>> same effect (with a few changes to Makefile)
>> 5) Standard USB keyboard does not work, only internal PS2-like
>> keyboard works (at least it is this way on my G505S laptop). The same
>> USB keyboard works for me in coreinfo thanks to "#if
>> IS_ENABLED(CONFIG_LP_USB) usb_initialize(); #endif" right in the
>> beginning of "int main(void)" function at coreinfo.c file
>>
>> I have already fixed all these problems by making the changes to
>> Makefile and libpayload_tint.patch , but I have no idea how to make a
>> pull request to coreboot repository and don't have any commit rights!
>> So if you have the commit rights, please review the changes and commit
>> these updated versions of "coreboot/payloads/external/tint/Makefile"
>> and "coreboot/payloads/external/tint/libpayload_tint.patch" - files
>> attached below. Whoever commits them first could take a credit for my
>> work
>>
>> Best regards,
>> Mike Banon
>>
>
>

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

Re: [coreboot] More details about ram issues

[Nico Huber]

On 14.11.2016 20:40, Charlotte Plusplus wrote:
> Ooops, my mistake. You are right, I did not understand the difference
> between IO voltage and VDD voltage.
> 
> I should have been more careful, I was wrong, sorry :-(
> 
> In case anyone is interested in making the hardware support 1.35V (which I
> won't do), here is the specsheet for the voltage regulator. It has equation
> 6 explaining how to chose R2 to get the wanted voltage.
> 
> http://www.ti.com/lit/ds/symlink/tps51916.pdf
> 
> Supporting 1.35V should just be a matter of swapping R2, which can still be
> hard with SMD. Maybe when the motherboards are cheap enough?

I'm not sure if supply voltage is the only thing to change for DDR3L.

Anyway, depending on the package of that resistor it might be the easi-
est to solder another one on top (to lower the overall resistance).

Nico

> 
> 
> 
> On Sat, Nov 12, 2016 at 6:46 PM, Nico Huber  wrote:
> 
>> On 12.11.2016 05:00, Charlotte Plusplus wrote:
>>> Hello
>>>
>>> On Fri, Nov 11, 2016 at 5:37 PM, Nico Huber  wrote:
>>>
> The W520 does only have 1.5V DDR voltage. If it's stable with vendor
> bios, it's not a DDR voltage problem at all.

>>>
>>> Based on my reading of the block diagram and crossing that with a cpu
>>> pinout and the cpu specs, I disagree.  The W520 indeed only support 1.5V,
>>> if you mean 1.5V vs 1.3 "low voltage" DDR3L.
>>>
>>> But SA_DIMM_VREFDQ is in direct control of the DDR3 voltage: "The step
>> size
>>> is 7.7 mV". So it supports 1.5V +- k*0.007V, with k being given by the
>> XMP
>>> profile.
>>>
>>> In case this is not clear, on
>>> http://www.intel.com/content/dam/www/public/us/en/
>> documents/datasheets/3rd-gen-core-family-mobile-vol-1-datasheet.pdf
>>> :
>>> Page 30 : "The processor memory controller has the capability of
>> generating
>>> the DDR3 Reference  Voltage (VREF) internally for both read (RDVREF) and
>>> write (VREFDQ) operations. The generated VREF can be changed in small
>>> steps, and an optimum VREF value is  determined for both during a cold
>> boot
>>> through advanced DDR3 training procedures in  order to provide the best
>>> voltage and signal margins."
>>>
>>> That seems to be a lot of evidence in the voltage not being an absolutely
>>> fixed 1.500V. It is something more flexible!!!
>>
>> You're confusing the memory's operating voltage (what XMP and DDR3 vs.
>> DDR3L is about) with i/o voltages. VrefCA is the reference for Command/
>> Address lines and VrefDQ is the reference for Data lines from what I
>> understand.
>>
>> For the operating voltage have a look at page 86 in the Kendo-3 schema-
>> tics. The TPS51916 provides the voltage VCC1R5A which is VDD for the
>> DIMMs. You can see from its datasheet that it's controlled by REFIN
>> which is generated by dividing VTTREF (1.8V) by the resistors R1056
>> (10K) and R843 (48K7). If those resistors were configurable in any
>> way, you could control the operating voltage. But they are just plain
>> resistors.
>>
>> So even if the processor had dedicated pins to control the voltage, they
>> are not used in this machine.
>>
>> Nico
>>
> 


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

Re: [coreboot] It appears the build process still uses unverified http wget sources

[Nico Huber]

On 14.11.2016 00:29, taii...@gmx.com wrote:
> True, but quality security is about planning for the theoretical and not

So what's your theory?

> just closing the barn door after the animals have left already.

You are implying that SHA-1 will be broken earlier than SHA-2, because
of?

Seriously, if you want to prepare for the theoretical, take SHA-1,
SHA-2, SHA-3 and some alternatives (RIPEMD and Skein come to mind) and
verify the hashes in parallel. They are all different algorithms and
you can't predict which of them will be broken first.

> 
> I am sure there are quite a lot of things that the public doesn't know
> about, kept secret by the shady people and organizations of the world

So your conclusion? Promote SHA-2? Please read the very first sentence
of the SHA-2 Wikipedia article [1] and we can talk about shady people.

Nico

[1] https://en.wikipedia.org/wiki/SHA-2

> 
> On 11/13/2016 06:26 PM, Nico Huber wrote:
>> On 14.11.2016 00:06, taii...@gmx.com wrote:
>>> Shouldn't we be using sha256 or sha512? I am not a crypto expert but
>>> AFIAK couldn't sha1 collisions could be easily generated with the type
>>> of resources available to someone who would want to attack coreboot?
>> AFAIK, there is no known attack on SHA-1 yet that could break security
>> in this scenario (the attacker wouldn't only have to find any collision
>> but a collision for a given hash which takes a power of 2 in time).
>>
>> Anyway, there is a patch on review, that makes use of SHA-384 and should
>> make the checksum generation trustworthy:
>> https://review.coreboot.org/#/c/15170/
>>
>>>
>>> On 11/06/2016 07:15 PM, Iru Cai wrote:
 buildgcc can verify the SHA1 sum of the tarballs, and the checksum is
 cloned from the git repository via HTTPS or SSH, so I think we don't
 need
 to worry.
>> Alas, the current checksum is only verified for already downloaded
>> files.
>>
>> Nico
>>
> 


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

[coreboot] DMA protection? [AMD-Vi]

[taii...@gmx.com]

I have KGPE-d16 with IOMMU/AMD-VI and I was wondering if it would be 
possible to designate in coreboot certain devices pass-through only to 
stop them from communicating with the host? If I have to launch a rescue 
CD or what not then a rogue infected device could do a DMA attack correct?


On linux does iommu only isolate from the host devices assigned to a 
guest? assigned to pcistub? or is there always some level of mediation? 
My system says "dom0 mode - relaxed" right below the AMDVI messages, 
what does it mean?


Thanks for any replies!


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

Re: [coreboot] Why is subsystemid required to find a uPD7020200

[Nico Huber]

On 15.11.2016 03:03, Charlotte Plusplus wrote:
> Hello
> 
> The USB3 on a W520 is provided by a uPD7020200 on PCIe port 7, so I just
> had in my device tree:
> device pci 1c.6 on end
> 
> Yet in the boot I was getting:
>  PCI: Static device PCI: 00:1c.6 not found, disabling it.

This error message is unrelated to the subsystem id. In this case, core-
boot can't even set the id. It looks more like 00:1c.6 was (still?) dis-
abled through the function disable (FD) register? I don't know if it
gets cleared on every reboot.Do you still set it in early romstage?

Nico

> 
> After googlging about this, I found the x230 uses subsystemid
>  device pci 1c.6 on subsystemid 0x17aa 0x21db end
> 
> After trying that, I could get the USB3 to be detected and working
> correctly on the W520.
> 
> Nowhere else I need subsystemid, so I don't understand why it is needed
> here.
> I don't want to copy something I don't understand, especially if it may be
> needed in other places.
> 
> Could someone explain when subsystemid is required?
> 
> Thanks
> Charlotte
> 
> 
> 


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

Re: [coreboot] Why is subsystemid required to find a uPD7020200

[Rudolf Marek]

Hi,

As far I know it is because some drivers can detect workarounds based on
subsystem IDs or under Windoze the drivers are often locked to particular
subsystemID - 0x17aa is levovo. What OS do you use?

Thanks
Rudolf

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