coreboot July 2015

coreboot@coreboot.org

46 participants
98 discussions

Re: [coreboot] VT-d on Pixel 2015 (samus)
by Noah Vesely 26 Jul '15

26 Jul '15

Thanks Ron! Took bit to get back to you because a Xen hypervisor update in Qubes seemed to put me in a boot loop. I just installed an Arch derivative because Arch has good support for this machine and I needed some type of test environment to actually run this command. Anyway, `rdmsr 0x3a` (think this is what you meant to type) returns 0. I guess this means all 3 bits are not set in the IA32_FEATURE_CONTROL MSR. This doesn't immediately make sense to me because (1) the output here seems to be telling me VT-x is not activated and the vmx cpu flag is present =><= and (2) I wrote in because `xl info` in Xen was reporting VT-x, but not VT-d, was activated and I was interested in how I could activate the former--isn't 0x3a unrelated to VT-d? Hopefully you can clarify this for me. Noah On 07/24/2015 11:25 PM, ron minnich wrote: > what does rdmsr 0 0x3a show you? > > ron > > On Fri, Jul 24, 2015 at 10:06 PM Noah Vesely <fowlslegs(a)riseup.net> wrote: > >> I've been trying to get VT-d working on John Lewis's build for the 2015 >> Pixel (samus). You can see our conversation at >> https://plus.google.com/116173342884039282107/posts/TGA4EXYQMfq and I >> have also pasted it below. So far, I haven't got anywhere, so I thought >> I would try asking you all as well. >> >> Thanks, >> Noah >> >> &%$#&%$#&%$#&%$#&%$#&%$#&%$#&%$#&%$# >> >> Noah Vesely >> - Jul 16, 2015 >> >> Is it possible to get Intel VT-d working on the Chromebook Pixel 2/ >> Samus? The i7-5600U processor does support it. >> ARK | Intel® Core™ i7-5600U Processor (4M Cache, up to 3.20 GHz) >> ark.intel.com >> ARK | Intel® Core™ i7-5600U Processor (4M Cache, up to 3.20 GHz) quick >> reference guide including specifications, features, pricing, >> compatibility, design documentation, ordering codes, spec codes and more. >> John Lewis's profile photoNoah Vesely's profile photo >> 10 comments >> John Lewis >> Jul 18, 2015 >> >> >> >> >> AFAIK, none of the hardware VT extensions are disabled in the firmware >> on Samus. Have you tried it? >> Noah Vesely >> Jul 18, 2015 >> >> >> >> >> Yes. VT-x was enable while VT-d was not. >> John Lewis >> Jul 18, 2015 >> >> >> >> >> Clone >> >> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… >> and run menuconfig to see if there's an option for VT-d. >> Noah Vesely >> Jul 19, 2015 >> >> >> >> >> I can't figure out how to checkout this repository. I cloned the main >> third_part/coreboot repo then checked out the broadwell branch, but >> could not find the same directory you linked. Maybe my git fu could use >> some work. >> John Lewis >> Jul 20, 2015 >> >> >> >> >> Use the last chunk of the URL as the branch argument i.e. "-b >> firmware-samus-6300.B". >> Noah Vesely >> Jul 20, 2015 >> >> >> >> >> Nothing in menuconfig, however, I found the line `#define CONFIG_IOMMU >> 0` in ./build/config.h. I also found `#define CONFIG_ENABLE_VMX 0`. >> John Lewis >> Jul 21, 2015 >> >> >> >> >> VMX is already enabled in the firmware. IOMMU is unrelated. I would have >> to conclude that VT'd is either not supported by that CPU or something >> more needs to be done in coreboot to get it to work. >> Noah Vesely >> Jul 21, 2015 >> >> >> >> >> VT-d is supported by this CPU. See original link to Intel Ark. >> >> VT-d is Intel's specification for their IOMMU technology, so I don't see >> how it's unrelated. >> John Lewis >> Jul 21, 2015 >> >> >> >> >> Take a look at the .config from a shellball ROM (you can extract it >> using cbfstool). >> >> https://johnlewis.ie/extracting-the-shell-ball-rom-using-a-chromeos-image/ >> >> Noah Vesely >> 9:15 PM >> >> >> >> >> I don't see anything relevant to VT-d; no VT-d keywords (e.g., iommu, >> vt, vmx, hvm, and directio). >> >> http://paste.debian.net/hidden/08ac8494/ >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Thinkpad ECs (H8)
by Denis 'GNUtoo' Carikli 25 Jul '15

25 Jul '15

Hi, I just learned about (and watched) a presentation[1] that is about backdooring the Thinkpad ECs. This information might help with the task of writing a free software EC firmware[2]. The information is also very useful to get a better ideas of the threats due to having a non-free EC firmware. I for instance missed the EC ThinkLight issue, when thinking about the security of i945 Lenovo laptops: -> The EC code is non-free -> There is a long wire that goes from the EC to the ThinkLight (That's a potential antenna, according to the talk the Thinkpad EC microcontrollers speed is around 10Mhz so it seems doable) -> Since The i945 Thinkpads are often bought second hand, a broken EC light isn't suspicious if you don't know about this issue. The talk contains a link to an EC firmware dumper[3]. Unfortunately after cloning the it, the git repository contained no code at all. Maybe Ralf-Philipp could comment on that? In the QA, it is also said that it's possible to talk directly to the EC hardware to dump the fimrware (and not the EC firmware), from the computer. The IO addresses he's mentioning look like EC addresses. I then wonder if it's also possible to flash it in the same way. In that case the fimrware should better be able to power on the computer, else some sort of external flashing/recovery would be needed (as it is for coreboot). The talk also contained a link to the original firmware "commented assembly". I've no idea if it's safe to look at it, but it's better not to do it until we know for sure that's it's legally safe. The SFLC (Software Freedom Law Center) might help with that. The people who looks at it might be prevented from writing legal free software firmware for such EC if they do, so beware. The talk also mention that the H8(The Thinkpad EC) have good documentation. References: ----------- [1] 27c3-4174-en-the_hidden_nemesis.webm [2] http://blogs.coreboot.org/blog/tag/h8s/ [3] http://coderpunks.org/ecdumper Denis.

2 1

VT-d on Pixel 2015 (samus)
by Noah Vesely 25 Jul '15

25 Jul '15

I've been trying to get VT-d working on John Lewis's build for the 2015 Pixel (samus). You can see our conversation at https://plus.google.com/116173342884039282107/posts/TGA4EXYQMfq and I have also pasted it below. So far, I haven't got anywhere, so I thought I would try asking you all as well. Thanks, Noah &%$#&%$#&%$#&%$#&%$#&%$#&%$#&%$#&%$# Noah Vesely - Jul 16, 2015 Is it possible to get Intel VT-d working on the Chromebook Pixel 2/ Samus? The i7-5600U processor does support it. ARK | Intel® Core™ i7-5600U Processor (4M Cache, up to 3.20 GHz) ark.intel.com ARK | Intel® Core™ i7-5600U Processor (4M Cache, up to 3.20 GHz) quick reference guide including specifications, features, pricing, compatibility, design documentation, ordering codes, spec codes and more. John Lewis's profile photoNoah Vesely's profile photo 10 comments John Lewis Jul 18, 2015 AFAIK, none of the hardware VT extensions are disabled in the firmware on Samus. Have you tried it? Noah Vesely Jul 18, 2015 Yes. VT-x was enable while VT-d was not. John Lewis Jul 18, 2015 Clone https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… and run menuconfig to see if there's an option for VT-d. Noah Vesely Jul 19, 2015 I can't figure out how to checkout this repository. I cloned the main third_part/coreboot repo then checked out the broadwell branch, but could not find the same directory you linked. Maybe my git fu could use some work. John Lewis Jul 20, 2015 Use the last chunk of the URL as the branch argument i.e. "-b firmware-samus-6300.B". Noah Vesely Jul 20, 2015 Nothing in menuconfig, however, I found the line `#define CONFIG_IOMMU 0` in ./build/config.h. I also found `#define CONFIG_ENABLE_VMX 0`. John Lewis Jul 21, 2015 VMX is already enabled in the firmware. IOMMU is unrelated. I would have to conclude that VT'd is either not supported by that CPU or something more needs to be done in coreboot to get it to work. Noah Vesely Jul 21, 2015 VT-d is supported by this CPU. See original link to Intel Ark. VT-d is Intel's specification for their IOMMU technology, so I don't see how it's unrelated. John Lewis Jul 21, 2015 Take a look at the .config from a shellball ROM (you can extract it using cbfstool). https://johnlewis.ie/extracting-the-shell-ball-rom-using-a-chromeos-image/ Noah Vesely 9:15 PM I don't see anything relevant to VT-d; no VT-d keywords (e.g., iommu, vt, vmx, hvm, and directio). http://paste.debian.net/hidden/08ac8494/

2 1

No code in SMM handler address (0xa0000)
by Yu-Cheng Liu 24 Jul '15

24 Jul '15

hello, Here I have some questions in smi.c file (coreboot/src/southbridge/intel/i82801ix/smi.c) in smm_install function, one statement is to copy handler to SMRAM(0xa0000): 1.I can't find copy source data ( _binary_smm_start ),where is it write? I watch (_binary_smm_start) memory address,and it has value in it. 2.After execute the memcpy statement,there is nothing change in 0xa0000,the value in 65535 In smm_relocate function, the pointer goes in the " if " statement and then "return" , the relocation code did not copy to 0x38000: 3.How do I let the program go through and do the job below the " if " statement? thanks~

1 0

coreboot changelog - Week of 2015-07-13
by Patrick Georgi 22 Jul '15

22 Jul '15

(This covers commits 6cb3a59 (which is the 4.1 tag) up to commit 406effd5) This week brought the addition of one new chipset and four new mainboards: Welcome the Intel Skylake SoC, and the new mainboards google/cyan, intel/kunimitsu, intel/sklrvp, and intel/strago, which are Braswell or Skylake based. As for tools, the script that generated the 4.1 release was added to the tree. To aid with debugging build issues, buildgcc shows the URLs it uses to download the sources to the toolchain. The standard git hook now uses a customized version of Linux’s checkpatch.pl utility for better coding style compliance tests. The cbmem utility gained OpenBSD compatibility when reading timestamps. The USB host drivers in libpayload saw improvements both for USB3, supporting SuperSpeed hubs and showing more robustness in the presence of strangely behaving USB devices, and for DWC2 controllers, which now support LowSpeed devices behind HighSpeed hubs. coreboot also passes more information to libpayload on where to find the flash part as well as the parameters of the CBFS that was used during boot. The CBFS format is seeing new development: The default alignment for files is now hardcoded to 64 bytes, which was already the default. There are no known instances where this value was changed, and it simplifies development going forward. The change is forward compatible in that old users can still read new CBFS images. New CBFS consumers run into problems if they work on a CBFS image with a different alignment configuration. Furthermore there were discussions on how to extend the CBFS format compatibly. So far this led to numerous refactorings in cbfstool to simplify further development. Finally, there were a whole lot of bug fixes: ARM64, the code for Nvidia’s Tegra210 chipset and the google/foster and google/smaug boards saw lots of development, from making them boot again to various hardware enablement. AMD’s RS780 chipset was effectively disabled due to a typo in the build system. There’s an ongoing effort to bring AMD K8/Fam10h into shape again, which also positively affected HD Audio configuration. CBMEM timestamps are more complete than ever. There was also the usual bunch of cleanups that get rid of unused Kconfig symbols and configuration options, deal with wrong indentation, and replace magic numbers with meaningful names. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

New on blogs.coreboot.org: coreboot changelog - Week of 2015-07-13
by WordPress 22 Jul '15

22 Jul '15

1 0

New on blogs.coreboot.org: [GSoC] End user flash tool – week #6
by WordPress 22 Jul '15

22 Jul '15

1 0

coreboot on Qemu aarch64 - error while booting kernel
by Naman Govil 22 Jul '15

22 Jul '15

Hi, I am trying to boot off a coreboot kernel image on aarch64 (qemu-system-aarch64) [Currently under development]. I am sort of stuck with some qemu related issue (not as much of a coreboot issue) I have the compiled image which I am ran by using the command $qemu-system-aarch64 -machine type=virt -nographic -kernel ~/coreboot/build/coreboot.rom I was getting no output on serial (on the terminal) on doing this. For debugging purposes, I tried to get qemu monitor working first. This gave me then following : qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000008000000 R00=00000950 R01=ffffffff R02=44000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=40010010 R15=08000000 PSR=400001db -Z-- A und32 s00=00000000 s01=00000000 d00=0000000000000000 s02=00000000 s03=00000000 d01=0000000000000000 s04=00000000 s05=00000000 d02=0000000000000000 s06=00000000 s07=00000000 d03=0000000000000000 s08=00000000 s09=00000000 d04=0000000000000000 s10=00000000 s11=00000000 d05=0000000000000000 s12=00000000 s13=00000000 d06=0000000000000000 s14=00000000 s15=00000000 d07=0000000000000000 s16=00000000 s17=00000000 d08=0000000000000000 s18=00000000 s19=00000000 d09=0000000000000000 s20=00000000 s21=00000000 d10=0000000000000000 s22=00000000 s23=00000000 d11=0000000000000000 s24=00000000 s25=00000000 d12=0000000000000000 s26=00000000 s27=00000000 d13=0000000000000000 s28=00000000 s29=00000000 d14=0000000000000000 s30=00000000 s31=00000000 d15=0000000000000000 s32=00000000 s33=00000000 d16=0000000000000000 s34=00000000 s35=00000000 d17=0000000000000000 s36=00000000 s37=00000000 d18=0000000000000000 s38=00000000 s39=00000000 d19=0000000000000000 s40=000000 Abort trap: 6 I did some searching, this meant that the bootloader cannot be loaded. And realised maybe the ROM qemu is getting is not sufficient. The 'execute outside ram or rom' is usually a jump to somewhere that qemu does not recognize as ROM/RAM. In coreboot*, *Since we expect CONFIG_BOOTBLOCK_BASE is 0x10000 CONFIG_ROMSTAGE_BASE is 0x20000 CONFIG_SYS_SDRAM_BASE is 0x1000000 i.e ROM to start at 64k. So I ran qemu by giving a -m 2048M (for testing) and got something. A window popped out (qemu), I am unsure as to what this is. I am attaching the picture with this mail*.* What is this window? Is this just a serial monitor? If so, why does it pop out on doing just $qemu-system-aarch64 -machine type=virt -m 2048M -nographic -kernel ~/coreboot/build/coreboot.rom ? Why is there no output on the terminal? I would appreciate any help on this. Regards, Naman

1 0

How to trigger SMI and implement SMM
by Yu-Cheng Liu 21 Jul '15

21 Jul '15

Hello, I purpose to trigger SMI event and do something in SMM mode . I trace the coreboot source code and found that, during the coreboot environment setup, the file locate at *southbridge/intel/i82801ix/smi.c* will be excute. Is it enough for SMI/SMM operation? I didn’t see the code under cpu/smm be locate in the ramstage.debug symbol. What is the different purpose between *southbridge/intel/i82801ix/smi.c* and* /cpu/x86/smm*? How do I trigger the SMI event? (my platform is QEMU and Coreboot main board is “emulation”) Thanks for your kindly reply ~

1 0

Re: [coreboot] ACPI resource problem
by WANG Siyuan 20 Jul '15

20 Jul '15

Memory32Fixed(ReadWrite, 0xFEDC2000, 0x1000) reserves memory in asl. I tried to add DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, but not work. On Tue, Jul 7, 2015 at 7:22 PM WANG FEI <wangfei.jimei(a)gmail.com> wrote: > Siyuan, did you reserved 0xFEDC2000 - 0xFEDC2FFF in ASL file? what you've > done in your code is to reserve this MMIO area in E820 table, OS will not > take this area, but it's not enough for ACPI. > > Here is a sample to reserve MMIO area in asl file. > > // TPM Area (0xfed40000-0xfed44fff) > DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, > Cacheable, ReadWrite, > 0x00000000, 0xfed40000, 0xfed44fff, 0x00000000, > 0x00005000,,, TPMR) > > On Mon, Jul 6, 2015 at 12:31 PM, WANG Siyuan <wangsiyuanbuaa(a)gmail.com> > wrote: > >> Hi, >> I have a question about acpi resource. >> >> My device need the resource: >> Name(_CRS, ResourceTemplate() { >> IRQ(Edge, ActiveHigh, Exclusive) {3} >> Memory32Fixed(ReadWrite, 0xFEDC2000, 0x1000) >> }) >> In Win8's device manager, I got error "This device cannot find enough >> free resources that it can use." >> >> I reserve resource (0xFEDC2000 - 0xFEDC2FFF) using flag resource->flags = >> IORESOURCE_MEM | IORESOURCE_RESERVE | IORESOURCE_FIXED | IORESOURCE_STORED >> | IORESOURCE_ASSIGNED; I still got this error. >> >> I have 2 questions: >> 1) Do I need to reserve MMIO for (0xFEDC2000 - 0xFEDC2FFF)? >> 2) Do I need to do some thing for IRQ(Edge, ActiveHigh, Exclusive) {3}? >> >> Any replay is appreciated! >> >> Yours sincerely, >> WANG Siyuan >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> >

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2015