coreboot July 2017

coreboot@coreboot.org

54 participants
131 discussions

Re: [coreboot] x86: best approach to debug consumer hardware?
by Arthur Heymans 08 Jul '17

08 Jul '17

> > Thanks everyone, the explanation was pretty simple - the _CST package > generated for model 6ex does not fit this exact CPU (6e8), as soon as > stuff under CONFIG_ACPI_PROCESSOR has been loaded, system dies, > sometimes with visible screen mess. Workaround for now is to use > processor.nocst=1 and for Windows to use UP boot. > > For now, I may simply disable the _CST entirely leaving only frequency > scaling options, though this is far from being appropriate for the > public port. >From git logs it looks like configuring the clockgen was needed for the x60/t60 port for deeper c-states to work. I'd try to dump the clockgen configuration on smbus with block operations ('i2cdump #smbus 0x69 s') and configure it using block write operations either in romstage (look at thinkpad x201 romstage.c) or in ramstage like is done for the x60 (might need some tweaking). Kind regards -- Arthur Heymans

2 1

Any intro available for adding cbmem support to an old platform?
by Keith Hui 07 Jul '17

07 Jul '17

Hi (again) coreboot: My original question got lost in the list probably because of a bad subject, so I'm asking again with a better one. I read that after 4.7 we are going to drop older platforms without "cbmem support in romstage", and that includes one that I brought into coreboot. I am interested in bringing this platform up to standard. Where can I read up on adding this cbmem support? I just checked out the master from git in case they are part of the readings. Thanks Keith

1 0

ultimate VGABIOS extraction! +NEW working way for AMD laptop's discrete GPU
by Mike Banon 07 Jul '17

07 Jul '17

This page from coreboot's official wiki - [1] - describes 5 ways to extract VGABIOS. However, all these ways are either unsuitable for AMD AtomBIOS extraction at all - or do not work for laptop's discrete AMD GPU *** [1] https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios Let's review these 5 methods, and introduce a new method that REALLY works! (which is described at the end of this article, you can scroll to see it) 1) "RECOMMENDED: Extracting from your vendor bios image" Probably you remember my message - [2] - about InsydeH20 BIOS dev tools *** [2] https://mail.coreboot.org/pipermail/coreboot/2017-June/084569.html Using H20EZE I have extracted a lot of useful stuff from proprietary BIOS of Lenovo G505S coreboot-supported AMD laptop, most importantly: * 8 VGABIOS ROMs - 3 of which could be suitable for various G505S versions: ROMs for HD 8650G integrated graphics and for HD 8570M and R5 M230 discrete I call these extracted ROMs as "clean ROMs",- To separate them from "dirty" ROMs that have been extracted from booted PC after InsydeH20 BIOS startup So I built coreboot with these 3 "clean" AtomBIOS ROMs, tried to boot and - - O_O - discovered that laptop's screen backlight is not working! (but the image is OK) , exactly the same problem as someone had 2 years ago - [3] *** [3] https://mail.coreboot.org/pipermail/coreboot/2015-April/079632.html Initially I thought that maybe I have damaged LVDS cable - it has a lot of really tiny wires inside and is fragile. Luckily, with AtomDis tool [4]-[5] I have compared the "clean" and "dirty" AtomBIOSes for HD8650G (integrated GPU of A10-5750M APU, the main GPU at integrated+discrete graphics system), and have discovered that - compared to "clean" ROM, that "dirty" ROM had a lot of initialized variables and data structures, including: LVDS_Info, sLCDTiming, ucLVDS_Misc, ucLCDPanel_SpecialHandlingCap, PowerPlayInfo, usSpreadSpectrumPercentage *** [4] https://cgit.freedesktop.org/~mhopf/AtomDis/ *** [5] https://github.com/mikebdp2/AtomDis That's why laptop's backlight is not working with "clean" HD8650G ROM! I am even surprised that somehow laptop's screen is showing the (no-lit) picture Who has initialized this stuff at "dirty" ROM ? InsydeH20 BIOS, of course! Although AtomBIOS is capable of modifying itself, there are way too many changes and I am sure that AtomBIOS could not have done it all by itself. Most likely, it is just InsydeH20 BIOS has patched this ROM during startup As you see, "clean" AtomBIOS ROMs which I got with "RECOMMENDED" method - are useless, they are not initialized enough. Should be "NOT RECOMMENDED" ! 2) "UEFI Method" - is the same thing as "1)" and doesn't work either 3) "Retrieval via Linux kernel" - works ONLY for HD8650G integrated GPU, it does not work for discrete! There are a lot of Lenovo G505S versions - - [6] - which, in addition to HD8650G integrated graphics, have a discrete second GPU - either HD 8570M or R5 M230; and "3)" way can't get their ROM *** [6] https://mail.coreboot.org/pipermail/coreboot/2015-April/079643.html No matter what drivers/kernel version/debug PCI commands I am using, and no matter how I am enabling/disabling/crossfire'ing integrated and discrete GPUs, while trying to get a ROM of discrete GPU I am always getting this: /sys/devices/pci0000\:00/0000\:00\:02.0/0000\:01\:00.0/rom: Input/output error *** [7] https://superuser.com/questions/1223973/how-fglrx-extracts-vgabios-if-i-get… I have searched through the whole Internet and spammed many forums about this problem, e.g. [7] but no solution! Meanwhile, AMD's amdcccle utility - - successfully gets the information about VGABIOS from fglrx kernel driver, probably through ADL AMD proprietary API calls [8] , but fglrx is closed source: so without a lengthy reverse-engineering we can't know how it gets discrete GPU's VGABIOS (contacted AMD but they refused to tell). Also we can't get this info from AMD's opensource drivers: both radeonsi and AMDGPU cannot get VGABIOS at this hardware because there are still a lot of bugs at AMD open source drivers, e.g. 99 bugs at AMDGPU [9] - one of which is [10] - " *ERROR* Unable to locate a BIOS ROM ", the same bug as I am having *** [8] https://developer.amd.com/display-library-adl-sdk/ *** [9] https://community.amd.com/message/2808545 *** [10] https://bugs.freedesktop.org/show_bug.cgi?id=101473 4) "Extraction from mapped memory (if everything else fails)" - the same situation as with "3)": my mapped memory contains "Video ROM", but - only a ROM for integrated HD8650G graphics, there is no ROM for discrete graphics! 5) "Downloading" - even if we forget about the security concerns, it is impossible to find the "dirty" ROMs for this laptop's discrete graphics at the Internet - maybe because nobody could extract them by these known ways? As you see, from these 5 ways described at coreboot's wiki: 1) / 2) gives all the "clean" ROMs to you, but they are useless 3) - 4) gives you a "dirty" ROM - but ONLY for integrated graphics 5) - no ROMs found HOW to get a "dirty" properly-initialized ROM for g505s DISCRETE graphics ? If I can't do it with Linux, I must try to do it with Windows ! This is a fine approach, because (jumping ahead) two "dirty" ROMs for integrated GPU, while got at these very different OS, are exactly the same - and there is most likely the same situation for discrete graphics. So, aside from purely ethical concerns, it should not matter which OS you are using to extract (as long as Windows was never connected to the Internet and can't receive the instructions from evil MS command server to stealthily modify your ROM) There are a few tools for Windows which can extract VGABIOS but they fail: * TechPowerUp's GPU-Z - could extract ONLY for integrated graphics * AIDA64 Engineer Edition - could extract ONLY for integrated graphics * Ray Adams ATIWinFlash - too old, does not support these new AMD GPUs But, after a lot of researching, I have finally found this wonderful tool : " Belkasoft Live RAM Capturer is a tiny free forensic tool that allows to reliably extract the entire contents of computer’s volatile memory – even if protected by an active anti-debugging or anti-dumping system " https://belkasoft.com/ram-capturer This forensic software, used to investigate the PC's of crime suspects, can do more than its' name claims: instead of just dumping the RAM, indeed it dumps the whole computer's volatile memory - not just RAM ! My laptop has exactly 16384 MB of RAM, 0x400000000 bytes, some of which are shared with with discrete GPU - but the dumps created with Belkasoft Live RAM Capturer are 0x42F000000 bytes, 17136 MB so it dumps much more memory than just RAM After checking "clean" ROM headers as well as Radeon Control Center's Information, I learned: GPUs' AtomBIOS versions, build date and part number === discrete - HD 8570M Version - 015.032.000.000 , Date - 06/24/2013 , Part Number - BR44464.011 === discrete - R5 M230 Version - 015.041.000.000 , Date - 11/28/2013 , Part Number - BR45149.002 === integrated - HD 8650G Version - 015.031.000.000 , Date - 01/16/2013 , Part Number - 113-DVST-113 Also I knew the sizes of "dirty" ROMs - same as the sizes of "clean" ROMs: discrete - R5 M230 - 0x8000 , 32768 bytes discrete - HD 8570M - 0x8400 , 33792 bytes integrated - HD 8650G - 0xF200 , 61952 bytes Then I borrowed a second G505S from my friend with another discrete GPU, and dumped the whole memory with Live RAM Capturer at this new environment OS: clean install of Windows 7 Ultimate SP1 x64 without any spying updates (WiFi card removed before installation,and never connected to the Internet) RAM: 16 GB, because it affects how much RAM the integrated GPU is getting Before doing each dump I have shutdown a laptop, removed its' power adapter and battery, then tried to turn it on by holding a power button - to completely discharge its' motherboard and clear all the volatile memory. Even removed the CMOS batteries from both laptops to make completely sure Made 4 dumps in total: 1) G505S with R5 M230 - dual graphics (crossfire) disabled 2) G505S with R5 M230 - dual graphics (crossfire) enabled 3) G505S with HD 8570M - dual graphics (crossfire) disabled 4) G505S with HD 8570M - dual graphics (crossfire) enabled After searching these dumps for 113-DVST-113 , BR44464 and BR45149 : I found all these "dirty" VGABIOS ROMs and successfully extracted them! (their size is known,and beginning also - just look at "clean" ROMs header) !!! IMPORTANT !!! All the working ROMs which I have found - were at the very end of dumps, in my case, 16GB of RAM installed : they were at 0x42D000000 - 0x42F000000 At the lower memory area, from 0x0 to 0x42D000000 I have found the "ghosts" of integrated HD 8650G graphics ROM but they are broken! How to determine if a ROM is broken: 1) it has way too many zeros 2) bad output of AtomDis === ROM locations examples for 0x0 - 0x42F000000 dump made while 16GB RAM: 0x000512000 - broken integrated graphics ROM, first "ghost" 0x3250D9020 - broken integrated graphics ROM, second "ghost" 0x3578FB000 - broken integrated graphics ROM, third "ghost" 0x36B22A01C - broken integrated graphics ROM, fourth "ghost" 0x4122BD000 - broken integrated graphics ROM, fifth "ghost" 0x42D3B3000 - working integrated graphics ROM !!! 0x42D305020 - working discrete graphics ROM (first working copy, the same) 0x42E40DCD0 - working discrete graphics ROM (second working copy, the same) A bit later I will share all my "dirty" properly-initialized ROMs. Of course now you know how could obtain them by yourself, but it is very time consuming to dump and search through >17 GB of memory Happy hacking!

1 0

Discussion about fixing dead code / ACPI TRAP
by Patrick Rudolph 06 Jul '17

06 Jul '17

Hello community, I'll want to start a discussion about fixing dead code. How it all started: I tried to run docking code on Lenovo T400 and found it's not working. While investigation it turns out that the ACPI TRAP mechanism is being used, and that it doesn't start the SMM handler. The mechanism works fine on Lenovo X60 and T60 because they enable the IO TRAP in romstage. Fixing it: I found that every Intel southbridge has code to support ACPI TRAP, but doesn't enable the trap mechanism by default. The idea is to enable ACPI TRAP in southbridge depending on a Kconfig option. The fix is here [1] The problem: Nico pointed out that while the fix might be technically correct, it would touch a lot dead code. There are only a very few boards using the mechanism. The following questions came up: Should dead code be "fixed" at all ? Should the "dead" code be removed on platforms that do not use ACPI TRAP ? Developers that want to use the mechanism in the future will have to reimplement it. As it touches a lot "dead" code, it cannot be easily tested on some platforms. Should patches be accepted for those platforms ? Should we get rid of ACPI TRAP mechanism and reimplement everything in AML only ? Should we mark ACPI TRAP as bad and force future development to use AML only ? Regards, Patrick References: [1]: https://review.coreboot.org/#/c/20328/

4 4

Re: [coreboot] x86: best approach to debug consumer hardware?
by Andrey Korolyov 06 Jul '17

06 Jul '17

On Thu, Jul 6, 2017 at 8:47 PM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: >> The simplest and most obvious explanation turned out to be true, the >> register is encoded as multiples of 16MiB. > > You say (in other words) the following: Coreboot prepares the whole > populated 32 bit (physical layout) DRAM2 space for some OS, don't you? > > TOLUD = d0000000h, and the next 256MiB are reserved for MM PCI + MM PCIe > (Yonah is Y2006, so PCIe came in Y2004), so somewhere above there will be > PCI configuration space (minimum 64K x 256 = 16MiB, maybe more, since some > ports are PCIe), Then HSEG, after boot FLASH. > _______ > > Well, Andrey, if Nico is right, you have reduced options... Dracut stays as > one of very seldom options to try, don't you agree? > > Zoran > > On Thu, Jul 6, 2017 at 5:44 PM, Nico Huber <nico.h(a)gmx.de> wrote: >> >> On 06.07.2017 07:20, Zoran Stojsavljevic wrote: >> > Top of Low Usable RAM 00d0h??? Any explanation for that? >> >> The simplest and most obvious explanation turned out to be true, the >> register is encoded as multiples of 16MiB. >> >> Nico > > Thanks everyone, the explanation was pretty simple - the _CST package generated for model 6ex does not fit this exact CPU (6e8), as soon as stuff under CONFIG_ACPI_PROCESSOR has been loaded, system dies, sometimes with visible screen mess. Workaround for now is to use processor.nocst=1 and for Windows to use UP boot. For now, I may simply disable the _CST entirely leaving only frequency scaling options, though this is far from being appropriate for the public port.

1 0

Re: [coreboot] GRUB2 is not displaying Hard disk (hd0) partition
by Nico Huber 06 Jul '17

06 Jul '17

On 06.07.2017 16:53, Dhanasekar Jaganathan wrote: > Hi Nico, > >> You can get used to the (ahci*) numbering, or in case you need to sup- >> port both schemes with the same config file: My default `grub.cfg` >> generated by grub-mkconfig works around these differences with the >> `search` command (see `info grub search`). For instance, it can set the >> `root` variable to a partition found by its filesystem's UUID, e.g.: > >> search --no-floppy --fs-uuid --set=root >> ad4103fa-d940-47ca-8506-301d8071d467 > > Actually, I am installing ONIE through GRUB2. As per your suggestion, I > have changed all* (hd0)* to* (ahci4)* in ONIE's grub.cfg. Still, GRUB2 is > not finding (automatically) grub.cfg. GRUB as payload has one config file embedded that just loads the next file from coreboot's CBFS (etc/grub.cfg). You have to add such a file to your coreboot image. You can go on chainloading ONIE's grub.cfg from there. Supposedly something like: configfile (ahci4,1)/boot/grub/grub.cfg (I don't know the exact path ONIE uses). Put that into a new file and add it to your image, e.g. cbfstool coreboot.rom add -t raw -n etc/grub.cfg -f new-chainloading-grub.cfg or add it during the coreboot build, in "Payload" menu "Include GRUB2 runtime config file ...". Nico

1 0

Re: [coreboot] x86: best approach to debug consumer hardware?
by Nico Huber 06 Jul '17

06 Jul '17

On 06.07.2017 07:20, Zoran Stojsavljevic wrote: > Top of Low Usable RAM 00d0h??? Any explanation for that? The simplest and most obvious explanation turned out to be true, the register is encoded as multiples of 16MiB. Nico

2 1

Re: [coreboot] GRUB2 is not displaying Hard disk (hd0) partition
by Nico Huber 06 Jul '17

06 Jul '17

Hi Dhanasekar, On 05.07.2017 16:23, Dhanasekar Jaganathan wrote: > Hi All, > > In GRUB2 command prompt, I am not seeing hard disk partitions like *(hd0), > (hd0,msdos1),* Instead I am seeing* (ahci4), (ahci4,msdos1).* the (hd*) numbering refers to those disks the BIOS has enumerated and provides drivers for. You'd see them like this when you use SeaBIOS and let it load a GRUB built for i386-pc. > > Usually, GRUB2 will list all the drives that coreboot presents to it. I > think coreboot presenting drives in "AHCI" (not in "hd) format. So that > GRUB2 displaying drives in AHCI format. With GRUB as payload (I suppose that's your case), there is no BIOS that presents disks and coreboot doesn't do such thing. So GRUB does what an OS would do, load an AHCI driver and probe the disks by itself. > > Correct me, If I am wrong. > > Is there any changes to do in menuconfig? > Can you please help me to solve this issue?. > Please provide your comments. You can get used to the (ahci*) numbering, or in case you need to sup- port both schemes with the same config file: My default `grub.cfg` generated by grub-mkconfig works around these differences with the `search` command (see `info grub search`). For instance, it can set the `root` variable to a partition found by its filesystem's UUID, e.g.: search --no-floppy --fs-uuid --set=root ad4103fa-d940-47ca-8506-301d8071d467 Hope that helps, Nico

2 1

Re: [coreboot] Ethernet/Wifi not working with coreboot/seabios/me_cleaner on a Thinkpad x230
by Pavel Alyev 06 Jul '17

06 Jul '17

It's just an information string. Not an error. In first time root device mounted with options from kernel cmdline. You can see mounted device and options in first line. Next time (second line) it's remounted with options from /etc/fstab. Again: second line inform you, what root device remounted with option "errors=remount-ro". Not in ro mode. For example, from my dmesg: > [ 5.395258] EXT4-fs (md2): re-mounted. Opts: errors=remount-ro 06.07.2017 15:12, Zoran Stojsavljevic пишет: > John, > > You should join Ancient Greek philosophers: Plato, Aristotle, > Plutarch, Archimedes... The last one would be great Linux programmer, > if he lived in Modern World. > > This advice I gave (also) to lot of PEs in INTEL IOTG, while I was > there... Very handy advice. ;-) > _______ > > Pavel, > > Thank you very much for the insight. > > I see what you are saying (I did not know that), that the first mount > / attributes came out initrd. It probably happens while dracut > re-pivots initrd's / to hard drive's /. > > Anyway, it should be checked. It says: error, then it says that it > remounted sda1 with EXT4-fs as RO (I assume it is /). I do not see > very often this line in dmesg (but I see it as seldom occurrence), so > it must be some sort of race effect, or...?! > > Thank you, > Zoran > > On Thu, Jul 6, 2017 at 1:34 PM, John Lewis <jlewis(a)johnlewis.ie > <mailto:jlewis@johnlewis.ie>> wrote: > > Yes, as Pavel said, "remount-ro" is just what happens if the > filesystem encounters an error which presumably it hasn't, at this > point. :) > > > On 06/07/17 12:11, Pavel Alyev wrote: >> >> >> First line: mount without options from initrd. Second: remount >> "/" with options from fstab. >> >> It's not mean what it mounted in ro mode. >> >> >> 06.07.2017 13:59, Zoran Stojsavljevic пишет: >>> > If there are critical dmesg values that can be optimized, do not >>> hesitate to point them out! :) >>> >>> [user@localhost dungeon]$ cat marcelo_dmesg.log | grep EXT4 >>> [ 2.127239] EXT4-fs (sda1): mounted filesystem with ordered >>> data mode. Opts: (null) >>> */_[ 2.332115] EXT4-fs (sda1): re-mounted. Opts: >>> errors=remount-ro_/* >>> [user@localhost dungeon]$ >>> >>> Line in */_RED_/* is concerning me. Do you have / ro? >>> >>> Zoran >>> >>> On Thu, Jul 6, 2017 at 11:42 AM, Marcel Maci <elpinguino(a)gmx.ch >>> <mailto:elpinguino@gmx.ch>> wrote: >>> >>> >>> > By that time (Y2161) I'll look something like this (200Y >>> old man): >>> > >>> https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065… >>> <https://s-media-cache-ak0.pinimg.com/originals/b1/c9/8f/b1c98fb01833bdbd065…> >>> > >>> > There are other problems (as well) in your dmesg log. But >>> not to >>> > spoil the situation (KUDOS to John). If you find anything >>> else wrong, >>> > just scream! ;-) >>> > >>> > Zoran >>> >>> Thx for the photo - I see you are optimistic for the future >>> ... ;) >>> If there are critical dmesg values that can be optimized, do not >>> hesitate to point them out! :) >>> >>> Marcel >>> >>> >>> >>> >> >> -- >> With best regards, >> Pavel Alyev >> anotherhosting.net <http://anotherhosting.net> chief administrator > > -- With best regards, someone from somewhere...

2 1

Re: [coreboot] x86: best approach to debug consumer hardware?
by Zoran Stojsavljevic 06 Jul '17

06 Jul '17

Andrey (Korolev), You got all my points. Both of them. It is on you... What you'll do. But whatever you do, please, post results here. :-) Zoran On Thu, Jul 6, 2017 at 2:06 PM, Andrey Korolyov <andrey(a)xdel.ru> wrote: > On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: > > OK, both Andrjusas, > > > > I am a bit ignorant, and I read beginning of the Coreboot log: > > > > DIMM 0 side 0 = 1024 MB > > DIMM 0 side 1 = 1024 MB > > DIMM 2 side 0 = 1024 MB > > DIMM 2 side 1 = 1024 MB > > tRFC = 43 cycles > > Setting Graphics Frequency... > > FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz > > Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok > > Setting mode of operation for memory channels...Dual Channel Interleaved. > > Programming Clock Crossing...MEM=667 FSB=667... ok > > Setting RAM size... > > C0DRB = 0x40404020 > > C1DRB = 0x40404020 > > TOLUD = 0x00d0 <<==========??? > > > > 4GB (two channel) memory, in two slots out of 4... ?! > > > > Top of Low Usable RAM 00d0h??? Any explanation for that? > @Zoran > > Thanks, that could be the point, though it seem to be same low for > X/T60 [0]. I would check if reading PCI space in Linux would result to > same small address and may be this is the point (also I could quickly > run completely headless kernel to verify that). > > > > > Andy (Korolev), > > > > Did you manage to get to Linux emergency mode called Dracut? > > I think that you meant dracut-produced initrd and try it against SMP > kernel, right? If I could get your idea, you are possibly suggesting > to cut off every device from being initalized except SuperIO, get to > ramdisk and try to work things out from there? I didn`t tried this > yet, mainly because I don`t want to spend much time with blind efforts > on very old laptop whose support has almost no real value... If I am > wrong, please explain what you`ve suggested in there. > > > > > So you are after memory contents? Freeze DIMMS, turn off memory > scrambling > > and flash firmware that dumps memory contents. In essence, cold boot > attack. > > @Andrey > That`s what I meant under 'spending few days', getting memory access > during both cold-boot run and DMA-assisted run is a matter of tens of > minutes, but the analysis of the dump would take much more time. The > main problem is that I am losing dynamic picture for memory contents > if I would do only post-mortem analysis and (with cold-boot attack) > I`ll lose small portion of the memory state anyway, due to > bootloader`s needs to initialize PCI devices (though I could imagine > very slow and boring transfer using CAR and USB debug port and there`s > bit of code need to be written for that). The fastest way to get close > to the point of failure and see at least a dynamic stuff is, probably, > a timer-based non-preemptible hack within ieee1394 driver which would > literally freeze system to allow me to take snapshots without risk of > hitting crash in the middle. Anyway, this closes down to analysis of > what is going on within the dump and with Linux mm it`s not an easy > task if you are not searching for something specific like LUKS key :) > > 0. https://mail.coreboot.org/pipermail/coreboot/2014-October/078752.html >

1 0

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

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 July 2017