Re: [coreboot] ThinkPad X230 alternative flash chips?

[Thierry Laurion]

The x230 has two rom chips. One that has 4mb that boots the system, and one
that is 8mb that holds ME. http://osresearch.net/ planned on using freed
space in the ME after deactivating it, but I haven't seen usage of that
freed space yet.

Le ven. 14 avr. 2017 à 21:15, Marek Behun  a écrit :

> > It looks like the X230 already has a large flash chip
> > (BOARD_ROMSIZE_12288?). How big were you thinking? The main issue
> > would be that chips bigger than 16MB use 4-byte addresses and the SPI
> > controller in Ivy Bridge probably only supports 3-byte addresses.
>
> I have ordered two 32 MB Macronix chips, with the hope to have 64 MB of
> space. If what you say is true, they won't work :(
>
> Marek
> --
> 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] ThinkPad X230 alternative flash chips?

[Marek Behun]

> It looks like the X230 already has a large flash chip
> (BOARD_ROMSIZE_12288?). How big were you thinking? The main issue
> would be that chips bigger than 16MB use 4-byte addresses and the SPI
> controller in Ivy Bridge probably only supports 3-byte addresses.

I have ordered two 32 MB Macronix chips, with the hope to have 64 MB of
space. If what you say is true, they won't work :(

Marek


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

[coreboot] BeagleBone Black [Master/Slave] Connection

[Haleigh Novak]

​Hello All, 

I am trying to connect a BBB (setup properly for ehci debugging) to a machine 
that was designed here at my work [well call it '(Cust)' for simplicity] I also 
have the running 'model' machine [lets call this one '(Orig)'] that the custom 
one was designed to mimic. I'm hoping that through this email I will reach 
enough people who have used the BeagleBone Black [BBB] to answer these 
questions based on the information below the questions. (Forgive me if the 
question is badly worded, its complicated to explain without visuals - let me 
know if you need a better explanation.)

0) Is there a way to tell 100% for certain (a query or status of some sort) 
which device is considered the Master/Host and which device is considered the 
Slave/Peripheral in a usb connection between two fully functional stand alone 
machines? 

1) For proper use does the BBB have to be classified as the Master/Host in the 
usb connection?

2) For proper use does the BBB require the connected machine (the one that ehci 
debugging info is desired from) to be a Master/Host, or a Slave/Peripheral 
device, or does it not matter; to allow successful ehci debugging?

[The above questions I have been Goggling, I have not found a strait forward, 
verified/well explained answer.]

3) The conversion cord I am using I strongly suspect is an OTG, and therefore 
as it is connected, defines the (Cust) to be the Master/Host - would this cause 
a 'fight' for Master/Host status that the BBB looses and is as a result 
classified as a Peripheral/Slave device and rendered non-functional for my 
needs? [p.s - I know this conversion cord works because I can plug it into 
(Cust) and on the other end have a peripheral (usb flash, mouse, keyboard - all 
tested) plugged in and utilize the peripheral without any issue.]

4) If (1) is yes, (2) is doesn't matter or slave/peripheral; is there a way to 
force the usb to reclassify? Say force (Cust) to be a Slave/Peripheral device 
and the BBB to be the Master/Host?

The BBB connects to an ehci capable port (for ehci debugging) via a MINI B 
connector in the BBB and a full sized usb to connect to the debug machine. Now 
(Orig) has full sized usb ports to which I can connect the BBB directly to and 
I successfully get the echi debugging information. However (Cust) only has 
MICRO B connectors - so I have to use a conversion cable on the end of the BBB 
cable to get the proper size. The ports on the respective 'debug' machines are 
verified ehci capable ports, both machines have coreboot - exactly the same 
except for the VGA Device IDs. However (Cust) will not recognize the BBB 
properly, and sets it up as an ohci device - rendering the BBB virtually 
useless. Below is the dmesg on both machines of removing and re-inserting the 
BBB debug cable from the equivalent port.

# DMESG addition on (Orig) after removing and re-inserting the BBB usb into the 
same port
usb 1-3: USB disconnect, device number 2
usb 1-3: new high speed USB device number 3 using ehci_hcd
usb 1-3: unable to read config index 0 descriptor/start: -32
usb 1-3: chopping to 0 config(s)
usb 1-3: New USB device found, idVendor=0525, idProduct=c0de
usb 1-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-3: no configuration chosen from 0 choices

# DMESG addition on (Cust) after removing and re-inserting the BBB usb into the 
same port
usb 4-1: USB disconnect, device number 2
usb 1-1: new high speed USB device number 6 using ehci_hcd
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new high speed USB device number 7 using ehci_hcd
usb 1-1: device descriptor read/64, error -71
usb 1-1: device descriptor read/64, error -71
usb 1-1: new high speed USB device number 8 using ehci_hcd
usb 1-1: device not accepting address 8, error -71
usb 1-1: new high speed USB device number 9 using ehci_hcd
usb 1-1: device not accepting address 9, error -71
hub 1-0:1.0: unable to enumerate USB device on port 1
usb 4-1: new full speed USB device number 3 using ohci_hcd
usb 4-1: unable to read config index 0 descriptor/start: -32
usb 4-1: chopping to 0 config(s)
usb 4-1: New USB device found, idVendor=0525, idProduct=c0de
usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 4-1: no configuration chosen from 0 choices

 Thank you for taking the time to read this. If anyone has any other 
suggestions as to what might be causing my issue I welcome any thoughts :).

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

Re: [coreboot] ThinkPad X230 alternative flash chips?

[David Hendricks]

It looks like the X230 already has a large flash chip (BOARD_ROMSIZE_12288?). 
How big were you thinking? The main issue would be that chips bigger than 16MB 
use 4-byte addresses and the SPI controller in Ivy Bridge probably only 
supports 3-byte addresses.


From: coreboot  on behalf of Marek Behun 

Sent: Tuesday, April 11, 2017 8:09:10 AM
To: coreboot@coreboot.org
Subject: [coreboot] ThinkPad X230 alternative flash chips?

Hello, does someone know if it is possible to solder a bigger flash
chip onto ThinkPad X230? Would it work? It would be awesome if I could
fit a bigger kernel as a payload...

MB

--
coreboot mailing list: coreboot@coreboot.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_coreboot=DwICAg=5VD0RTtNlTh3ycd41b3MUw=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM=fwGcQuv6bsJwdWqVoIJDOxENuPpRIT-gK8s3eV8CciA=XDfJBptdMHCCzgWh6H7qLS-abCur8Bym4re96dF01r0=
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] List of my changes to merge for coreboot 4.6

[Paul Menzel via coreboot]

Dear coreboot folks,


It’d be great if the small changes below could be reviewed and
submitted before coreboot 4.6 is released.

   1. https://review.coreboot.org/18907/
   2. https://review.coreboot.org/18906/
   3. https://review.coreboot.org/18794/
   4. https://review.coreboot.org/18829/


Thanks,

Paul

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] [RFH] Please test current code on your devices before coreboot 4.6 release

[persmule]

Marek,

Your could check the newist me_cleaner
(https://github.com/corna/me_cleaner/). I will attach my flash layout
file to ease your hacking.

Persmule

在 2017年04月14日 22:59, Marek Behun 写道:
>> The ME region has been cleansed and shrinked to minimal size with
>> me_cleaner (0ac4b4bfd).
> You have also shrinked the ME region? What is it's size now? I would
> like to have more space for the payload, so if I could shrink the ME
> region from current 5 MB, that would be great. How can this be done?
>
> Marek
:0fff fd
0001b000:00bf bios
3000:0001afff me
1000:2fff gbe
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] Please test current code on your devices before coreboot 4.6 release

[Marek Behun]

> The ME region has been cleansed and shrinked to minimal size with
> me_cleaner (0ac4b4bfd).

You have also shrinked the ME region? What is it's size now? I would
like to have more space for the payload, so if I could shrink the ME
region from current 5 MB, that would be great. How can this be done?

Marek


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

Re: [coreboot] [RFH] Please test current code on your devices before coreboot 4.6 release

[Paul Menzel via coreboot]

Dear persmule,


Am Freitag, den 14.04.2017, 21:59 +0800 schrieb persmule:
> 在 2017年04月14日 07:48, Paul Menzel via coreboot 写道:
> > And if you notice a regression, please send a message to the list or
> > create an issue in the issue tracker [1].

Thank you for testing coreboot on the Lenovo X230.

> On a0729d9a56, if the first boot after flash is done on dock 433615W
> (http://www.thinkwiki.org/wiki/ThinkPad_Dock_Series_3#ThinkPad_Series_3_Docking_Stations_with_USB_3.0),
> it will highly possibly fail to light the screen when trying to resume
> from suspension.

Interesting. Please report that to the issue tracker. It’d be great if
you could get the Linux messages during resume with `drm.debug=0xe`.

> Besides, if usb 3.0 ports are used before suspension,
> the screen nearly always fails to resume after suspension.

I never heard of that. An issue with the corresponding logs would be
helpful too.

> The ME region has been cleansed and shrinked to minimal size with
> me_cleaner (0ac4b4bfd).
> 
> My board status has been uploaded via commit 201b7eeb0 of its own
> repository.

Thank you!

> The tpm on my x230 seems fine.

Interesting. Linux 4.9.13 and 4.9.18 seem to be able to detect the TPM
on the Lenovo X230.

```
+[5.155247] tpm_tis 00:06: 1.2 TPM (device-id 0x0, rev-id 78)
+[5.259246] tpm tpm0: A TPM error (6) occurred attempting to read a pcr 
value
+[5.259291] tpm tpm0: TPM is disabled/deactivated (0x6)
```

`device-id 0x0` looks strange though, and the Linux driver says it’s
deactivated.

I wouldn’t think that’s expected, but I am not sure about that.


Thanks,

Paul

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] [RFH] Please test current code on your devices before coreboot 4.6 release

[persmule]

在 2017年04月14日 07:48, Paul Menzel via coreboot 写道:
> And if you notice a regression, please send a message to the list or
> create an issue in the issue tracker [1].
>
On a0729d9a56, if the first boot after flash is done on dock 433615W
(http://www.thinkwiki.org/wiki/ThinkPad_Dock_Series_3#ThinkPad_Series_3_Docking_Stations_with_USB_3.0),
it will highly possibly fail to light the screen when trying to resume
from suspension. Besides, if usb 3.0 ports are used before suspension,
the screen nearly always fails to resume after suspension.

The ME region has been cleansed and shrinked to minimal size with
me_cleaner (0ac4b4bfd).

My board status has been uploaded via commit 201b7eeb0 of its own
repository.

The tpm on my x230 seems fine.


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

Re: [coreboot] How to flash Coreboot on a Thinkpad T430s

[Dima Ursu]

The "s" series are quite finiky when flashing; I flashes recently a T400s, so 
I'd assume your laptop also has a WSON8 chip. The pinout and the flashing 
procedure is the same;  you only need to solder thin wires to the chip - there 
is no clip available for them. I'd suggest you also tape the raspberry and the 
T430s boards together  - if the boards move around, there's a high risk you 
will rip the pads from the motheboard/chip.


On April 9, 2017 7:58:35 PM GMT+03:00, kitestramuort 
 wrote:
>The T430s is supported by coreboot, however there's very little
>documentation on the flashing procedure itself. I couldn't even
>identify the BIOS chip on the motherboard. From what I've read the chip
>is not SOIC8, unlike those on the non-S T430 and X230, therefore the
>raspberry pi method should not be applicable. Is desoldering the chip
>the only way to install Coreboot on this machine? Is there a
>guide/howto somewhere?
>
>Thanks
>
>-- 
>coreboot mailing list: coreboot@coreboot.org
>https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

On Thu, 13 Apr 2017 17:17:03 -0500
Timothy Pearson  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > 
> > Unfortunately, I had the option already enabled when using the 
> > "config-unreliable" in my initial posting. So it looks like this setting is 
> > not effective in stopping the hangs.
> > 
> > Cheers, Daniel
> 
> After further external analysis once the KGPE-D16 was placed on our test
> stand for OpenBMC development, the intermittent hang resulting in hard
> system lockup (requiring a full standby power cycle) appears to be fixed
> in this patch series on Gerrit:
> 
> https://review.coreboot.org/#/c/19280/
> 
> Can you please test and confirm?
> 
> Thanks!
> 

Sure thing: I applied the patch on top of current coreboot-master and compiled 
the ROM using the "config-unreliable" from my initial posting.  Then I did a 
series of five warm reboots and watched the output on the serial console. 
Result: No more hangs! (Previously, it took like 20 attempts to get even one 
successful boot)

Great job, and many thanks!

Cheers, Daniel

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

[coreboot] ASUS KGPE-D16 Automated Test Failure [master]

[Raptor Engineering Automated Coreboot Test Stand]

The ASUS KGPE-D16 fails verification for branch master as of commit 
f13e2501525f0025b03f4b2ee3487999bb0ade2b

The following tests failed:
BOOT_FAILURE

Commits since last successful test:


See attached log for details

This message was automatically generated from Raptor Engineering's ASUS 
KGPE-D16 test stand
Want to test on your own equipment?  Check out 
https://www.raptorengineering.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit 
https://www.raptorengineering.com for more information

Please contact Timothy Pearson at Raptor Engineering 
 regarding any issues stemming from this 
notification


1492158805-3-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot