coreboot April 2019

coreboot@coreboot.org

56 participants
48 discussions

Fwd: Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS
by Kinky Nekoboi 18 Apr '19

18 Apr '19

-------- Weitergeleitete Nachricht -------- Betreff: Re: [coreboot] Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS Datum: Thu, 18 Apr 2019 11:38:16 +0200 Von: Kinky Nekoboi <kinky_nekoboi(a)nekoboi.moe> An: Mike Banon <mikebdp2(a)gmail.com> CPU : A8-6600K [ 1.271514] microcode: CPU0: patch_level=0x0600110f [ 1.271521] microcode: CPU1: patch_level=0x0600110f [ 1.271532] microcode: CPU2: patch_level=0x0600110f [ 1.271538] microcode: CPU3: patch_level=0x0600110f [ 1.271583] microcode: Microcode Update Driver: v2.2. i compiled from the master tree, build on 16. April 2019 no microcode was included in that build. next step i will try if, the problems occur again if i remove microcode updates via llinux kernel. here is cbmem output as attachment Am 18.04.19 um 06:08 schrieb Mike Banon: >> also it seems that IOMMU is working now... > Congratulations with these amazing news! Please tell, what version of > coreboot you've currently installed? Also, have you used this > microcode updating patch from DangerousPrototypes page before building > your current coreboot build? > >> maybe cause i have microcode updates in the kernel included this time ? > By the way, the microcode updates provided by Linux are _older_ than > what this "microcode updating patch" is providing : simply because AMD > has shared their latest update with some proprietary UEFI makers but > didn't share them with the opensource world (and so we had to get them > by manually extracting). But if the kernel sees that a newer microcode > version is loaded, it doesn't replace it. Please, could you check and > tell, what microcode version do you see as installed?

2 2

disabling Intel iGPU on Skylake/Kaby Lake CPU
by Maxim Poliakov 18 Apr '19

18 Apr '19

Hi all! I have a problem with disabling the internal Intel GPU in the coreboot for the Skylake/Kaby Lake processor. If I understand correctly, in order to disable the iGPU, I must to set "InternalGfx" to 0 in UPD options for Intel FSP. https://github.com/coreboot/coreboot/blob/master/src/soc/intel/skylake/roms… But, in this case, the loading of the coreboot stops after running the FSP-S in ramstage. Please see logs: https://drive.yadro.com/s/3ocCtS3EemjyT5f I ran the coreboot image with iGPU turned off on the following boards: - Asrock H110M-DVS board (i5-6600 desktop CPU), coreboot: 4.9-1254-gadde497; - Intel KBL-R U RVP board (i5-8350u mobile processor), coreboot: 4.9-55-g04a7ce7. In both cases it doesn`t work. I think that it is not enough to change only InternalGfx. Any ideas on this? Has anyone tested Сhromebooks or other motherboards with Skylake/Kaby Lake processor when iGPU is turned off? Thanks. // Regards, // Max

2 2

Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS
by Kinky Nekoboi 18 Apr '19

18 Apr '19

hello coreboot bois and girlz,i have succesfully booted my system with the Richland CPU installed with a Nvidia GT210 card. also it seems that IOMMU is working now... maybe cause i have microcode updates in the kernel included this time ? so i have to change my bugreport as it seems that this coreboot port + Seabios has somehow problems with Radeon Cards .... both the IGPU and addon cards will feed your with extra news. your kinky nekoboi Am 17.04.19 um 11:23 schrieb Kinky Nekoboi: > i have tried builds for F2A85M since version 4.8 dating back to mid 2018, > > AMD-A8 5500 works properly with IOMMU enabled, still some stabilty > problems (full system freezes). > > AMD A8-6600K shows the described behavior > > I also tried that manual microcode update in the past, didnt change > anything there, i could retry it for the current build. > > Serial output gives no information about malfunctioning IOMMU or > something, the strugle begins as without IOMMU the system is notable to > initialize add-on videocards or the iGPU. > > Am 17.04.19 um 10:50 schrieb Mike Banon: >> On Tue, Apr 16, 2019 at 11:23 PM Kinky Nekoboi >> <kinky_nekoboi(a)nekoboi.moe> wrote: >>> Amd-Vi loopback errors at linux-boot, >>> several peripherie is not working. >>> >>> Surely it needs only minor changes... is there anybody working at this >>> port at the moment? >>> >> Hi there Nekoboy (sorry if I'm repeating my older questions, I >> forgot). Please tell: >> >> 1) IOMMU - did it ever work on F2A85M board? If you're unsure, could >> you try building the older coreboot just to check it? >> 2) Have you installed the unofficial microcode patches? If not, please >> run this ./ucode.sh script at your coreboot directory: >> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_upda… >> to conveniently and securely patch your cloned coreboot with these >> updated microcodes, then try running Linux and tell what microcode >> version do you see (confirmation of successful microcode install) and >> check if IOMMU got fixed by it. >> >> Step "2)" should be tried both for the latest coreboot and some older >> version. Yes, a bit time consuming, but hopefully you could test it >> well. By the way, I got A88XM-E which is not merged to coreboot yet >> but is based on F2A85M port, however I have a lot of parallel projects >> and didn't have time to even test if my new (actually used) board is >> working, so you'll have to rely on your own for a while. >> >> Best regards, >> Mike Banon >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

2 1

lewisburg GPIO
by ron minnich 18 Apr '19

18 Apr '19

I need some gpio experts. On an (e.g.) lewisburg, how does one enumerate the GPIOs and make them visible in sysfs as one does on ARM? Is the info in ACPI in some magic spot? thanks

2 1

Re: Fwd: F2A85M IOMMU still not working for RIchland CPUS
by Mike Banon 17 Apr '19

17 Apr '19

Kinky Nekoboi wrote: > i have tried builds for F2A85M since version 4.8 dating back to mid 2018, > > AMD-A8 5500 works properly with IOMMU enabled, still some stabilty > problems (full system freezes). > > AMD A8-6600K shows the described behavior > Kinky Nekoboi wrote: > Serial output gives no information about malfunctioning IOMMU or > something, the strugle begins as without IOMMU the system is notable to > initialize add-on videocards or the iGPU. That's very strange, considering that Trinity and Richland are very similar to each other. Well, my A10-6700 should be even more similar to your A8-6600K - so, if there's a common problem, we would be in the same boat. Kinky Nekoboi wrote: > I also tried that manual microcode update in the past, didnt change > anything there, i could retry it for the current build. > My fault was that I didn't ask you to confirm through Linux the microcode version that you see. (btw, for some reason your message is not visible at the mailing list and reached only some of the recepients, luckily my friend resent it to me) Best regards, Mike Banon

1 0

F2A85M IOMMU still not working for RIchland CPUS
by Leon Gehling 17 Apr '19

17 Apr '19

Amd-Vi loopback errors at linux-boot, several peripherie is not working. Surely it needs only minor changes... is there anybody working at this port at the moment? best regards

3 3

Intel APL: calculating CBFS master header position
by Christian Gmeiner 16 Apr '19

16 Apr '19

I am trying to understand how I can calculate the position of CBMEM in e.g. u-boot. Here are some facts about my device - it is Intel apollolake based and uses the following fmd file. FLASH 16M { SI_DESC@0x0 0x1000 IFWI@0x1000 0x300000 FMAP@0x301000 0x800 COREBOOT(CBFS)@0x301800 0xB8D800 CONSOLE@0xE8F000 0x20000 RW_MRC_CACHE@0xEAF000 0x10000 BIOS_UNUSABLE@0xEBF000 0x40000 DEVICE_EXTENSION@0xeff000 0x100000 UNUSED_HOLE@0xfff000 0x1000 } FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 39500 none cpu_microcode_blob.bin 0x9b40 microcode 46080 none fallback/ramstage 0x14fc0 stage 76490 none config 0x27b00 raw 272 none revision 0x27c80 raw 682 none fspm.bin 0x27f80 fsp 364544 none default_bootline 0x80fc0 raw 92 none filename_mcore 0x81080 raw 11 none filename_mos 0x81100 raw 9 none version_min 0x81180 raw 14 none (empty) 0x81200 null 1432 none fsps.bin 0x817c0 fsp 172032 none fallback/postcar 0xab800 stage 20508 none fallback/dsdt.aml 0xb0880 raw 5693 none fallback/payload 0xb1f40 simple elf 243523 none (empty) 0xed6c0 null 11108568 none bootblock 0xb857c0 bootblock 32768 none File build/coreboot.rom is 16777216 bytes Peculiar firmware descriptor, assuming Ibex Peak compatibility. Flash Region 0 (Flash Descriptor): 00000000 - 00000fff Flash Region 1 (BIOS): 00001000 - 00efefff Flash Region 2 (Intel ME): 07fff000 - 00000fff (unused) Flash Region 3 (GbE): 07fff000 - 00000fff (unused) Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused) Flash Region 5 (Reserved): 00eff000 - 00ffefff Flash Region 6 (Reserved): 07fff000 - 00000fff (unused) Flash Region 7 (Reserved): 07fff000 - 00000fff (unused) Flash Region 8 (EC): 07fff000 - 00000fff (unused) FMAP: area COREBOOT found @ 301800 (12113920 bytes) CBFS @ 301800 size b8d800 CBFS: 'IAFW Locator' located CBFS at [301800:e8f000) CBFS: Locating 'fallback/dsdt.aml' CBFS: Found @ offset b0880 size 163d Lets have a look at this nice ascii art: https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/apollolake… Lets give it a naive try: 4GiB - 256KiB - bios_mapped_size (Flash Region 1 size == size returned by fast_spi_get_bios_region(..)): 0x100000000 - 0x40000 - 0xEFE000 --> 0xFF0C2000 => md 0xFF0C2000 ff0c2000: ffffffff ffffffff ffffffff ffffffff ................ ff0c2010: ffffffff ffffffff ffffffff ffffffff ................ ff0c2020: ffffffff ffffffff ffffffff ffffffff ................ ff0c2030: ffffffff ffffffff ffffffff ffffffff ................ ff0c2040: ffffffff ffffffff ffffffff ffffffff ................ ff0c2050: ffffffff ffffffff ffffffff ffffffff ................ ff0c2060: ffffffff ffffffff ffffffff ffffffff ................ ff0c2070: ffffffff ffffffff ffffffff ffffffff ................ ff0c2080: ffffffff ffffffff ffffffff ffffffff ................ ff0c2090: ffffffff ffffffff ffffffff ffffffff ................ ff0c20a0: ffffffff ffffffff ffffffff ffffffff ................ ff0c20b0: ffffffff ffffffff ffffffff ffffffff ................ ff0c20c0: ffffffff ffffffff ffffffff ffffffff ................ ff0c20d0: ffffffff ffffffff ffffffff ffffffff ................ ff0c20e0: ffffffff ffffffff ffffffff ffffffff ................ ff0c20f0: ffffffff ffffffff ffffffff ffffffff ................ Looks wrong - but lets move on... 0xFF0C2000 + cbfs offset --> 0xFF0C2000 + 0x301800 --> 0xFF3C3800 => md 0xFF3C3800 ff3c3800: ffffffff ffffffff ffffffff ffffffff ................ ff3c3810: ffffffff ffffffff ffffffff ffffffff ................ ff3c3820: ffffffff ffffffff ffffffff ffffffff ................ ff3c3830: ffffffff ffffffff ffffffff ffffffff ................ ff3c3840: ffffffff ffffffff ffffffff ffffffff ................ ff3c3850: ffffffff ffffffff ffffffff ffffffff ................ ff3c3860: ffffffff ffffffff ffffffff ffffffff ................ ff3c3870: ffffffff ffffffff ffffffff ffffffff ................ ff3c3880: ffffffff ffffffff ffffffff ffffffff ................ ff3c3890: ffffffff ffffffff ffffffff ffffffff ................ ff3c38a0: ffffffff ffffffff ffffffff ffffffff ................ ff3c38b0: ffffffff ffffffff ffffffff ffffffff ................ ff3c38c0: ffffffff ffffffff ffffffff ffffffff ................ ff3c38d0: ffffffff ffffffff ffffffff ffffffff ................ ff3c38e0: ffffffff ffffffff ffffffff ffffffff ................ ff3c38f0: ffffffff ffffffff ffffffff ffffffff ................ Nope After some try and error I found the real start of the bios region: 0xFF102000 => md 0xFF102000 ff102000: 000055aa 0001000d 00000000 00000000 .U.............. ff102010: 00010003 08e8003c 00000009 00000000 ....<........... ff102020: 00000000 0000000a 00000200 00000010 ................ ff102030: 00000005 00149000 000ff000 00000001 ................ ff102040: 000c3000 0000a000 0000000c 00000000 .0.............. ff102050: 00000000 0000000d 00000000 00000000 ................ ff102060: 00000011 00000210 00000108 00000004 ................ ff102070: 00001000 000be000 00000000 000bf000 ................ ff102080: 00004000 0000000e 000cd000 00010000 .@.............. ff102090: 00000002 000dd000 00061000 00000003 ................ ff1020a0: 0013e000 00009000 0000000b 00147000 .............p.. ff1020b0: 00002000 ffffffff ffffffff ffffffff . .............. ff1020c0: ffffffff ffffffff ffffffff ffffffff ................ ff1020d0: ffffffff ffffffff ffffffff ffffffff ................ ff1020e0: ffffffff ffffffff ffffffff ffffffff ................ ff1020f0: ffffffff ffffffff ffffffff ffffffff ................ 0xFF102000 + 0x301800 = 0xFF403800 => md 0xFF403800 ff403800: 448bc3ff 408b0424 244489f4 ffd1e904 ...D$..@..D$.... ff403810: 8353ffff 448b18ec 548d2824 5c8b0824 ..S....D$(.T$..\ ff403820: 44892024 448b0824 44892c24 438d0c24 $ .D$..D$,.D$..C ff403830: fec0e808 c289ffff 85ffc883 8b1d74d2 .............t.. ff403840: 0fc08503 508bc344 2474ff04 2474ff0c ....D..P..t$..t$ ff403850: 2474ff0c 52ff502c 10c48308 5b18c483 ..t$,P.R.......[ ff403860: 835356c3 448b14ec 748b2c24 5c8b2024 .VS....D$,.t$ .\ ff403870: 44892824 448d0c24 5c890824 8d500824 $(.D$..D$..\$.P. ff403880: e850f846 fffffe42 c085595a 5e2b1874 F.P.B...ZY..t.+^ ff403890: 245c89f8 f4468b28 20244489 5b14c483 ..\$(.F..D$ ...[ ff4038a0: ff6ce95e c483ffff ffc88314 53c35e5b ^.l.........[^.S ff4038b0: 8b18ec83 8d282444 8b082454 8920245c ....D$(.T$..\$ . ff4038c0: 8b082444 892c2444 8d0c2444 23e80843 D$..D$,.D$..C..# ff4038d0: 89fffffe ffc883c2 2674d285 d285138b ..........t&.... ff4038e0: 8bd3440f 488b0442 ffc8830c 1274c985 .D..B..H......t. ff4038f0: 0c2474ff 0c2474ff 2c2474ff 83d1ff52 .t$..t$..t$,R... Still looks wrong - If I subtract an other kb I get the CBFS master header. => md 0xFF402800 ff402800: 4352414c 45564948 20000000 02000000 LARCHIVE... .... ff402810: 00000000 38000000 73666263 73616d20 .......8cbfs mas ff402820: 20726574 64616568 00007265 00000000 ter header...... ff402830: 00000000 00000000 4342524f 32313131 ........ORBC1112 ff402840: 00f0e800 04000000 40000000 00183000 ...........@.0.. ff402850: ffffffff 00000000 ffffffff ffffffff ................ ff402860: ffffffff ffffffff ffffffff ffffffff ................ ff402870: ffffffff ffffffff ffffffff ffffffff ................ ff402880: 4352414c 45564948 4c9a0000 10000000 LARCHIVE...L.... ff402890: 00000000 38000000 6c6c6166 6b636162 .......8fallback ff4028a0: 6d6f722f 67617473 00000065 00000000 /romstage....... ff4028b0: 00000000 00000000 00000000 fef20000 ................ ff4028c0: 00000000 fef20000 00000000 00009a30 ............0... ff4028d0: 00009a30 0003ffe8 4800bc00 31fcfef0 0..........H...1 ff4028e0: 5900b9c0 50bffef0 29fef056 83abf3f9 ...Y...PV..).... ff4028f0: 84e8f0e4 eb00004f 909066fe 0030001f ....O....f....0. I am not sure whats wrong here :( I hope that somebody can push me into the right direction. The end goal is to be able to use u-boot's cbfs to access some files stored there. -- thanks -- Christian Gmeiner, MSc https://christian-gmeiner.info

1 0

Bios problem. Will not boot
by Enkelena Haxhiu 16 Apr '19

16 Apr '19

Hi everyone, I have a problem. I had flashed my bios last year into coreboot by a raspberry pi. Now, I changed the hard disk of that laptop, and put another one with windows on it, but it does not boot there. Every key that I press it gets me to booting from hard disk, and again the process repeats. Is there any way I can fix it? What do you think if I put again the last disk and boot into that to make it start normally and then download files to flash the bios into lenovo's default bios? Will this work? Regards, Enkelena

3 7

Re: ONIE EEPROM format
by Zaolin 16 Apr '19

16 Apr '19

Hey Hannah, Not yet. On 15.04.19 22:05, hannah.williams(a)dell.com wrote: > ONIE EEPROM

1 0

ONIE EEPROM format
by hannah.williams＠dell.com 16 Apr '19

16 Apr '19

Is there code in coreboot to parse data in ONIE EEPROM format ?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2019