coreboot August 2016

coreboot@coreboot.org

53 participants
132 discussions

Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot
by Mayuri Tendulkar 04 Aug '16

04 Aug '16

Hi Zoran Thanks for your inputs. I am checking on Ubuntu. As per minnowmax, devicetree.cb file, below like says default will be EHCI. How we should change it at runtime, what is the setting? device pci 14.0 on end # 8086 0F35 - USB XHCI - Onboard & HSEC - Enabling both EHCI and XHCI will default to EHCI if not changed at runtime device pci 1d.0 on end # 8086 0F34 - USB EHCI - Enabling both EHCI and XHCI will default to EHCI if not changed at runtime regards Mayuri From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: 04 August 2016 01:06 To: Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot Hello Mayuri, Some of us (at least me) know that INTEL USB 3.0 implementations have here and there mortal problems for years, as well as in CORE, also in ATOM families. There are lists of problems, but most of them are closed Intellectual Properties, INTEL Inside. I had yesterday terrible problem to set CANON PIXMA MG3650 home printer edition I bought in Saturn to pair over USB with my mobile i5-4300 INTEL Inside HSW laptop (CPUID 0x40561), so I needed 4 hours to investigate and find the interim solution for INTEL buggy embedded USB 3.0 root port (it is consumers' QA issue with INTEL design, so INTEL should take care of this, my best guess)... :-(( In this lieu I will advise you the two way approach. One is to contact/to engage with your INTEL FAE/representative, and ask him about the problems which are well described in internal INTEL documents (BYT wise). The other approach is to work out these problems yourself. So, there are several facts about the USB 3.0. There are (my best guess) some BYT USB fixes done by other people in Coreboot. I'll let these people to speak for themselves. If? You can also try to bring some Linux distros (Fedora for example) and try to see what is going on while you bring up the system (dmesg log). Also you can do the following commands: lsusb -v lsusb -t At least, you can do lsusb --h to see options which can help you to start debugging this issue. Zoran On Wed, Aug 3, 2016 at 11:23 AM, Mayuri Tendulkar <mayuri.tendulkar(a)aricent.com<mailto:mayuri.tendulkar@aricent.com>> wrote: Hi I am facing issue in enumerating USB3.0 device on baytrail processor with coreboot with seabios. Is there any setting in coreboot where we need to enable this separately. Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] USB3.0 enumeration in Baytrail E3845 with coreboot
by Zoran Stojsavljevic 03 Aug '16

03 Aug '16

Hello Mayuri, Some of us (at least me) know that INTEL USB 3.0 implementations have here and there mortal problems for years, as well as in CORE, also in ATOM families. There are lists of problems, but most of them are closed Intellectual Properties, INTEL Inside. I had yesterday terrible problem to set CANON PIXMA MG3650 home printer edition I bought in Saturn to pair over USB with my mobile i5-4300 INTEL Inside HSW laptop (CPUID 0x40561), so I needed 4 hours to investigate and find the interim solution for INTEL buggy embedded USB 3.0 root port (it is consumers' QA issue with INTEL design, so INTEL should take care of this, my best guess)... :-(( In this lieu I will advise you the two way approach. One is to contact/to engage with your INTEL FAE/representative, and ask him about the problems which are well described in internal INTEL documents (BYT wise). The other approach is to work out these problems yourself. So, there are several facts about the USB 3.0. There are (my best guess) some BYT USB fixes done by other people in Coreboot. I'll let these people to speak for themselves. If? You can also try to bring some Linux distros (Fedora for example) and try to see what is going on while you bring up the system (dmesg log). Also you can do the following commands: lsusb -v lsusb -t At least, you can do lsusb --h to see options which can help you to start debugging this issue. Zoran On Wed, Aug 3, 2016 at 11:23 AM, Mayuri Tendulkar < mayuri.tendulkar(a)aricent.com> wrote: > Hi > > > > I am facing issue in enumerating USB3.0 device on baytrail processor with > coreboot with seabios. > > > > Is there any setting in coreboot where we need to enable this separately. > > > > Regards > > Mayuri > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for loss or damage arising > from the use of the information transmitted by this email including damage > from virus." > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] re-enabling boot for ChromeOS
by Matt DeVillier 03 Aug '16

03 Aug '16

Julius, wouldn't he also need gbb_utility to set the flags, in addition to (CrOS) flashrom to be able to read/write just the GBB region? That's why I suggested he use my ChromeOS Firmware Utility Script, since it would automatically download the required binaries as well as ensure the flags were set to a sane value. But as you, no need to change the flags as set to boot ChromeOS cheers, Matt On 7/20/2016 5:56 PM, Julius Werner wrote: > set_gbb_flags.sh is just a bash script and will run on any system that > has flashrom installed (which it calls). > > With the 0x489 flags you should still see the Chrome OS firmware > screen ("OS verification is turned off") for 2 seconds on boot. Just > press CTRL+D during those two seconds to boot Chrome OS in developer > mode from the internal SSD. >

3 3

Extracting EC firmware from EFI firmware
by Łukasz Dobrowolski 03 Aug '16

03 Aug '16

Hi! I'm trying to port Coreboot to ThinkPad X120e. With help from guys from CCCB we figured that EC (ITE IT8518E) is constantly talking to BIOS connected on SPI (Winbound 25Q16). Which prevented in system programming of the flash. I've build a Coreboot image coping (and tweaking a little bit) motherboard configuration from a desktop motherboard(asrock/e350m1) that has the same APU(AMD E350). The mb looks completely dead when using this image. Since the EC is always talking to flash chip i suspect that it has it's program on the same flash chip. I've tried to use binwalk. And found a lot of "Microsoft portable executable" regions. I don't know how to put them on the Coreboot rom. Maybe I should just use dd to cut and join them (doesn't seem like a good idea to me.)? Am I going in the right direction? Maybe I should try to use oscilloscope to observe the mb with vendor BIOS and with my cb rom? Maybe I should try to sniff the communication on the SPI flash chip? I've bought a miniPCI-E POST card. It works with vendor BIOS (interestingly only in one of the slots). It doesn't display anything when using my Coreboot rom.

1 0

Re: [coreboot] MMIO UART driver on OS
by Nico Huber 03 Aug '16

03 Aug '16

Hi, On 31.07.2016 17:07, Zheng Bao wrote: > Hi, All, > > I want to add support MMIO UART support on OS. > > I checked the file pnp_uart.asl. > > For IO UART, a device with EisaId("PNP0501") is added into DSDT, the windows can detect the COM port in device manager. > > I am wondering if MMIO UART also have that convinient feature. in theory (I've just checked the code, never tried) the Linux driver supports MMIO UARTs too if you give it the same entry (PNP0501) with a memory resource instead of the io ports. Maybe this works in other OS' too? Nico > > Or I need to build a driver for each OS? > > Thanks. > > > Joe

2 1

Re: [coreboot] ARM Trusted Firmware build issue
by Stefan Reinauer 03 Aug '16

03 Aug '16

On 20-Jul-16 16:19, Julius Werner wrote: > Well... honestly, isn't it our fault for uprevving to a buggy > toolchain? If there was a way to write this code such that it will > result in the binary output ARM wants and works on all versions, > submitting a patch to them would be reasonable... but otherwise I can > kinda understand that they don't want to use an inferior solution > because we insist on using an assembler that doesn't know how to > assemble stuff correctly. Isn't the best solution to only uprev archs > that really need new compiler features until the GCC guys manage to > produce a stable version? Yes, I was wrong. After reading the other threads and talking with Martin, it indeed seems to be a toolchain issue. However, the new toolchain had many advantages over the previous one, and the code was not in (our) ARM TF at the time we uprevved. The maintenance burden of keeping different versions of toolchains supported for different architectures as part of the reference toolchain is imho almost always significantly higher than actually fixing the issues. (Especially if they are not time critical) Martin produced a binutils fix for the issue. Whether the binutils people will find it to be the "right" fix is still to be found out, but it seems to allow compiling the latest, unmodified ARM TF. Stefan

3 2

Re: [coreboot] buildgcc certs and signature hashes
by Zaolin 03 Aug '16

03 Aug '16

Checkout my commit. Today I will upload a new version of it. https://review.coreboot.org/#/c/15170/ On 08/03/2016 03:52 PM, Trammell Hudson wrote: > It looks like the util/crossgcc/buildgcc script disables HTTPS cert > checks and doesn't have a way to verify the signatures or hashes of the > files that it receives. > > download_showing_percentage() { > url=$1 > printf " ..${red} 0%%" > wget --no-check-certificate $url 2>&1 | while read line; do > printf "${red}" > echo $line | grep -o "[0-9]\+%" | awk '{printf("\b\b\b\b%4s", $1)}' > printf "${NC}" > done > } > > > I'm worried that this introduces a minor, but potential security > issue for the build process. >

1 0

buildgcc certs and signature hashes
by Trammell Hudson 03 Aug '16

03 Aug '16

It looks like the util/crossgcc/buildgcc script disables HTTPS cert checks and doesn't have a way to verify the signatures or hashes of the files that it receives. download_showing_percentage() { url=$1 printf " ..${red} 0%%" wget --no-check-certificate $url 2>&1 | while read line; do printf "${red}" echo $line | grep -o "[0-9]\+%" | awk '{printf("\b\b\b\b%4s", $1)}' printf "${NC}" done } I'm worried that this introduces a minor, but potential security issue for the build process. -- Trammell

2 1

ASUS KFSN4-DRE (K8) Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand 03 Aug '16

03 Aug '16

The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 1cfb555e713f57b86d6ae779704e2861e654b25c The following tests failed: BOOT_FAILURE Commits since last successful test: 1cfb555 fsp_broadwell_de: Add DMAR table to ACPI 5407310 cbfstool: Check for excessive arguments 9ade717 cbfstool: Check arguments to strtoul() where appropriate f641a27 Makefile.inc: Strip output of `wc` 21a5bff ACPI: Add code to create root port entry in DMAR table <7 commits skipped> 9671faa drivers/intel/fsp2_0: FSP driver handles all FSP errors 52d0c68 drivers/intel/fsp2_0: Verify HOBs returned by FspMemoryInit ac3b0a6 drivers/intel/fsp2_0: Add display HOB support e6f2f74 drivers/intel/fsp2_0: Add UPD display support 0a38b22 drivers/intel/fsp2_0: Monitor FSP setting of MTRRs See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

USB3.0 enumeration in Baytrail E3845 with coreboot
by Mayuri Tendulkar 03 Aug '16

03 Aug '16

Hi I am facing issue in enumerating USB3.0 device on baytrail processor with coreboot with seabios. Is there any setting in coreboot where we need to enable this separately. Regards Mayuri "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2016