coreboot June 2016

coreboot@coreboot.org

43 participants
86 discussions

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86
by Patrick Rudolph 08 Jun '16

08 Jun '16

On 2016-06-06 09:58 PM, ron minnich wrote: > On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph <siro(a)das-labor.org> > wrote: > >> To summarize: >> The easy way is to use 2G. >> The preferred way would be to mimic mrc behaviour and reboot after >> finding the correct size. > > I'm not sure it's "easy vs. preferred" so much as > - simple that has no known failure cases (yet). > - best that requires that we have another variable we have to store in > flash > > At least to me, it's not as cut and dried as easy vs. preferred. The > preferred way adds a lot of moving runtime parts, and we'll need to > cover for the case that the stored variable gets damaged somehow. The > easy way is a runtime constant, which I kind of like. > > If the "easy" way always works, i.e. we never find a case where it > causes a problem, then it seems superior to me. > > ron There's a known failure case. If someone puts in multiple PCI cards that uses more than 2GB of mmio it'll break again. Most users won't reach this limit, but I'm wondering if I'm reaching it anytime soon. I want to use 2 PEG cards and the onboard intel card, which will be a good test-system. I've read this serveral times and wonder how a stored variable could get damaged ? There is a checksum to verify the mrc cache. How should anything go wrong ? In case something writes to the flash you might get unexpected behavior anyway, won't you ? Regards, Patrick

4 3

Re: [coreboot] [SeaBIOS] UEFI project ideas
by Laszlo Ersek 08 Jun '16

08 Jun '16

On 06/07/16 16:35, Zoran Stojsavljevic wrote: >> Note that you can build seabios as CSM for tianocore already. > > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), while > Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and Tiano Core > exclude each other (should not be used together -> wrong architecture). SeaBIOS can be built and used as a CSM with UEFI firmware built from tianocore/edk2. The projects themselves are not "opposites". The resultant firmware binary can boot OSes in UEFI mode or in legacy mode. I guess those boot modes can be called opposites. >> What is the point? You can just run tianocore as coreboot playload. > > The point is to make minimal Tiano Core (minimum for making FAT32 > partition/file system on HDD/SDD to create /boot/EFI/ directory, in > other words minimal UEFI compliant BIOS), Tiano Core as such is good to > be used/run for/on x86 architecture ONLY This is patently false. Several aarch64 platforms exist that run UEFI firmware based more or less directly on tianocore/edk2. In my living room I have an APM Mustang that has UEFI firmware, based on tianocore/edk2. The SBBR spec (Server Base Boot Requirements System Software on ARM ® Platforms) mandates UEFI. Of course, not all ARM platforms are required to conform to the SBBR, but the SBBR would be quite foolish to require a practically unfeasible thing. tianocore/edk2 is the open source reference implementation of PI (Platform Init) and UEFI. It's a separate question wheter specific aarch64 platform code lives directly within the edk2 tree, or in some external tree (open source or proprietary). > (and side effect is the > extended time for booting, since all these DXE drivers must be > installed, which will be later mostly replaced/run over with OS drivers, > except run time services). DXE drivers are supposed to drive peripherals only in the exceptional case. Most devices that are not integrated in the platform are supposed to be driven by UEFI drivers that conform to the UEFI Driver Model. The point of that driver model is that no compliant driver, when initially launched, starts to drive any kind of hardware. Instead, it installs only three callbacks (member functions of its driver binding protocol instance): supported, start, and stop. The supported callback is used as a very quick check by the system to see if a driver supports a given piece of hardware. The start and stop functions instruct the driver to actually bind (and unbind) the specified piece of hardware. The calls to the supported and bind functions are initiated by Platform BDS (Boot Device Selection). In other words, it is a platform decision to automatically bind this or that set of devices. In OVMF and ArmVirtPkg (running in QEMU, Xen, and possibly other virtual machines), we choose to automatically bind all possible devices, because in virt, that's generally the best approach (and it is even necessary for some QEMU boot order quirks that I'm not going to go into now). But, auto-binding all devices is nowhere mandated by the UEFI spec, or any other related spec. In fact, on some x86 platforms the vendor seeks to speed up the boot by not connecting USB keyboards even. (And then, if you want to use the USB keyboard before the OS is booted, for example for modifying firmware settings, you have to set a non-volatile UEFI variable from within the OS, sometimes displayed as "change firmware settings" or some such. Then at the next boot, the firmware will drop you into the setup TUI, with the keyboard (and possibly other devices) connected. The user can massage firmware settings then; e.g., if the platform vendor wants it too, the user may be able to add the USB keyboard to the set of auto-connected devices.) Other schemes exist too. The Platform Init specification (separate from the UEFI specification) defines the Boot Mode HOB (hand-off block). The HOB-producer phase of the firmware (usually: PEI, Pre-EFI Initialization) can produce this HOB, so that later phases of the firmware can key off of it. For example, dependent on platform hardware support, this HOB can tell the Boot Device Selection phase *not* to connect any other devices than the last time around, because the chassis has not been opened since. Otherwise, BDS might want to auto-connect everything (perhaps the user installed a new SSD, etc). > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be used > on ARM architectures too, thus making ARM HW platforms also > compatible/lookalike as x86 UEFI compliant BIOS. The UEFI specification already contains AArch32 and AArch64 bindings. It is already possible to implement UEFI on ARM platforms, and several vendors have. Boot performance, as far as it is affected by the set of devices automatically connected, is platform policy. > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW platform, >From last September, a blog post from one of my colleagues: https://marcin.juszkiewicz.com.pl/2015/09/21/aarch64-desktop-day-one/ > having coreboot + minimal Tiano Core + WIN 10 Boot Loader + WIN10 on it > (since WIN10 BL does see UEFI compliance, not knowing what is really > under the hood). ;-) For the record, I am definitely not arguing against coreboot, or u-boot, or even a stripped down platform firmware built purely from tianocore/edk2. Still for the record, I'm also not arguing that people should move to UEFI *at all*, unless they have specific reasons. But claiming that tianocore/edk2 is only good for x86 in its current shape and form, and implying that UEFI on ARM unconditionally needs a lower-level "shim", are just preposterous. Laszlo

2 1

Re: [coreboot] [SeaBIOS] UEFI project ideas
by Martin Roth 07 Jun '16

07 Jun '16

Here's a patch to build the UEFI coreboot payload package directly as a coreboot payload. https://review.coreboot.org/#/c/15057/ Martin On Tue, Jun 7, 2016 at 1:13 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > I fail to see what you are trying to tell me. > > I'm not sure you even know what a CSM is. > > I probably do not. ;-) > > > And what has all this to do with seabios? > > Did I ever mention SeaBIOS to play minimal TianoCore? > > Thank you, > Zoran > > On Tue, Jun 7, 2016 at 5:18 PM, Gerd Hoffmann <kraxel(a)redhat.com> wrote: > >> On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote: >> > > Note that you can build seabios as CSM for tianocore already. >> >> > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), >> > while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and >> > Tiano Core exclude each other (should not be used together -> wrong >> > architecture). >> >> I fail to see what you are trying to tell me. >> I'm not sure you even know what a CSM is. >> >> > > What is the point? You can just run tianocore as coreboot playload. >> >> > The point is to make minimal Tiano Core (minimum for making FAT32 >> > partition/file system on HDD/SDD to create /boot/EFI/ directory, in >> > other words minimal UEFI compliant BIOS), Tiano Core as such is good >> > to be used/run for/on x86 architecture ONLY (and side effect is the >> > extended time for booting, since all these DXE drivers must be >> > installed, which will be later mostly replaced/run over with OS >> > drivers, except run time services). >> >> > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be >> > used on ARM architectures too, thus making ARM HW platforms also >> > compatible/lookalike as x86 UEFI compliant BIOS. >> >> tianocore already runs on arm. >> seabios doesn't and it never will. >> >> > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW >> > platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader + >> > WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what >> > is really under the hood). ;-) >> >> And what has all this to do with seabios? >> >> confused, >> Gerd >> >> > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] [SeaBIOS] UEFI project ideas
by Gerd Hoffmann 07 Jun '16

07 Jun '16

On Di, 2016-06-07 at 16:35 +0200, Zoran Stojsavljevic wrote: > > Note that you can build seabios as CSM for tianocore already. > These are the opposites: SeaBIOS is CSM ON (emulates Leagcy BIOS), > while Tiano Core supposed to be CSM OFF (UEFI), Thus, SeaBIOS and > Tiano Core exclude each other (should not be used together -> wrong > architecture). I fail to see what you are trying to tell me. I'm not sure you even know what a CSM is. > > What is the point? You can just run tianocore as coreboot playload. > The point is to make minimal Tiano Core (minimum for making FAT32 > partition/file system on HDD/SDD to create /boot/EFI/ directory, in > other words minimal UEFI compliant BIOS), Tiano Core as such is good > to be used/run for/on x86 architecture ONLY (and side effect is the > extended time for booting, since all these DXE drivers must be > installed, which will be later mostly replaced/run over with OS > drivers, except run time services). > As such, Minimal Tiano Core (minimal UEFI compliant BIOS) could be > used on ARM architectures too, thus making ARM HW platforms also > compatible/lookalike as x86 UEFI compliant BIOS. tianocore already runs on arm. seabios doesn't and it never will. > In nutshell, then you can build PC/Laptop with ARM CPU/SoC HW > platform, having coreboot + minimal Tiano Core + WIN 10 Boot Loader + > WIN10 on it (since WIN10 BL does see UEFI compliance, not knowing what > is really under the hood). ;-) And what has all this to do with seabios? confused, Gerd

2 1

UEFI project ideas
by Rudolf Marek 07 Jun '16

07 Jun '16

Hi all, I noticed that seabios/libpayload could have interresting use cases and I want to share/discuss them. 1) Have a SeaBIOS be a UEFI application. This would benefit on UEFI platforms without CSM. 2) Provide a minimum UEFI environment. As I noticed u-boot started to have such support. In fact it has UEFI glue to u-boot drivers. As such it provides a minimal boot services + minimum runtime services. In seabios, it is almost there, only PE loader and filesystem support is missing. The 2) could be perhaps be some independent project utilizing the coreboot libpayload library. Maybe those can be done in next year GSoC. I guess 2) could be useful to boot future OSes without legacy support. Thanks Rudolf

4 4

New on blogs.coreboot.org: [GSoC] Multiple status register support, week #1 and #2
by WordPress 07 Jun '16

07 Jun '16

1 0

Re: [coreboot] PC Engines APU2 support
by Piotr Król 07 Jun '16

07 Jun '16

On Tue, Jun 07, 2016 at 09:40:59AM +0200, maxime de Roucy wrote: > Le 7 juin 2016 2:09 AM, "Piotr Król" <piotr.krol(a)3mdeb.com> a écrit : Hi Maxime, > > I'm working on support for PC Engines APU2 (AMD GX-412TC) board and I > > finally manage to boot Voyage Linux and run memtest86+. There some > > limitations and concerns that I have and hope you can advise how to > > proceed. > > I wrote a blog article about coreboot on apu1d. Maybe some informations can > help you with apu2. > https://pelican.craoc.fr/coreboot.html Thanks I will take a look at it. > > > 3. APU2 got only UART interface and to make it accept input character I > > had to port some changes from out of tree SeaBIOS. I managed to merge it > > with upstream version and it seems to work for APU2. Some of those > > changes are very specific to APU2. Code is here: > > https://github.com/pcengines/seabios/commits/apu2-support > > It seams the SeaBIOS prefer to use/promote sgabios instead of building it's own > serial input solution. > > http://www.seabios.org/pipermail/seabios/2016-May/010677.html > > I personaly also prefer sgabios as it allow the user to chainload non serial > aware solution. > See note about sgabios in this section : > https://pelican.craoc.fr/coreboot.html#seabios_1 End users seems to have problems with sgabios and that's why I was asked to remove sgabios support. It looks like using Google sgabios is design decision, so I will gather information about bugs/features they faced and then see what can be done to fix that. Where I should push patches for sgabios, if any ? > > > 4. I also had to modify memtest86plus because it hanged on code looking > > for SPD. This platform do not use memory modules, just chips soldered on > > board. At this point there is SPD_DISABLE define that disable SPD > > reading. I'm not sure if this is correct approach and if this should be > > pushed for review before proving it work ? > > https://github.com/pcengines/memtest86plus/commits/apu2 > > Did you use the coreboot memtest86plus repo ? > https://review.coreboot.org/gitweb/cgit/memtest86plus.git/ Yes I did. -- Best Regards, Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 1

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86
by Nico Huber 07 Jun '16

07 Jun '16

On 06.06.2016 23:40, Kyösti Mälkki wrote: > On Mon, Jun 6, 2016 at 10:36 PM, ron minnich <rminnich(a)gmail.com> wrote: >> I'm getting the sense here that reasonably modern CPUs can easily handle the >> 2G hole. From what I've seen, it would not cause trouble for older CPUs >> because they're most likely to be in small systems that are not likely to >> have more than 2G memory anyway (I'm thinking of the vortex). >> > > Not that I would particularly care, but was i945 able to reclaim > memory from below 4GiB to above 4GiB? There used to be a fair amount > of Lenovo T60/X60(s) users. I don't think we should use the 2GiB limit for all x86 platforms. It's more a question for those platforms that are actively maintained and at least support PAE, IMO. Regarding i945, I had a look at the code and there is a TOM register that's programmed to the total amount of DRAM. But sadly it's undocu- mented (at my level of NDA) and coreboot doesn't seem to advertise memory above 4GiB (I haven't tried it yet though). Nico

1 0

PC Engines APU2 support
by Piotr Król 07 Jun '16

07 Jun '16

Hi all, I'm working on support for PC Engines APU2 (AMD GX-412TC) board and I finally manage to boot Voyage Linux and run memtest86+. There some limitations and concerns that I have and hope you can advise how to proceed. 1. Platform doesn't show anything on UART after power off. It works fine when going through reset after flashing new firmware. It seems to do something because LEDs light up. Any idea what can be wrong or how to approach that ? 2. Platform boots only with AGESA <= 1.0.0.3. With newer version (>= 1.0.0.4) it hangs right after passing control to Linux (GRUB seems to work fine). Binary from master (1.0.0.A) reboots in the same place when it pass control or start testing memory. Anyone saw similar behavior ? If yes what is the approach to debug that ? Or maybe there known fixes for that ? 3. APU2 got only UART interface and to make it accept input character I had to port some changes from out of tree SeaBIOS. I managed to merge it with upstream version and it seems to work for APU2. Some of those changes are very specific to APU2. Code is here: https://github.com/pcengines/seabios/commits/apu2-support At this point, for testers (if any), I changed Makefiles to point to gihub repo, but wonder if pushing those changes make sense before merging APU2 support ? 4. I also had to modify memtest86plus because it hanged on code looking for SPD. This platform do not use memory modules, just chips soldered on board. At this point there is SPD_DISABLE define that disable SPD reading. I'm not sure if this is correct approach and if this should be pushed for review before proving it work ? https://github.com/pcengines/memtest86plus/commits/apu2 My changes to coreboot are under review here: https://review.coreboot.org/#/c/14138/ Any help appreciated. -- Best Regards, Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 1

Re: [coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver
by Naveed Ghori 07 Jun '16

07 Jun '16

Sorry I meant v36_15_0_1091 (x86) which is the latest on the Intel website that I can find. I cannot find v36.15.0.1127. I am quite sure the driver is OK but that there is something else fundamental causing the BSOD. I have used it on another system (non coreboot) with an E3845 processor. Regards, Naveed From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Tuesday, 7 June 2016 12:52 PM To: Naveed Ghori Cc: coreboot Subject: Re: [coreboot] BSOD Win7 x86 for Baytrail E3845 Dsplay Driver Hello Naveed, Little bit of google searching: http://wikifixes.com/en/errors/0x/0xC0000005/?gclid=CJDYx4WIlc0CFY9uGwodBrI…<https://linkprotect.cudasvc.com/url?a=http://wikifixes.com/en/errors/0x/0xC…> As I understood, you are using 36.15.0.1 (x86 aka 32b). This is very old one. The latest to use is: 36.15.0.1127 for x86 and 37.15.0.1127 for x86_64. Please, contact INTEL for these EMGD based WIN7/WIN 8.1 GFX drivers. Zoran On Tue, Jun 7, 2016 at 5:16 AM, Naveed Ghori <naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au>> wrote: Hi all, I have Windows Embedded Standard 7 x86 working in with SeaBIOS. If I install the graphics driver for it however I get a BSOD while Windows is booting up (screen flashes before the BSOD) As a Coreboot newbie it would be good to get an idea as to what may cause this. I am thinking video memory allocation. The error is below: *** STOP: 0x0000007E (0xC0000005, 0x8D58B437, 0x92717C04, 0x927177E0) *** igdkmd32.sys – Address 8D58B437 base at 8D423000, DateStamp, 53ac9002 The driver version is the Intel EMGD v 36.15.0.1. Thanks in advance. Naveed. Naveed Ghori | Lead Firmware & Driver Engineer DTI Group Ltd | Transit Security & Surveillance 31 Affleck Road, Perth Airport, Western Australia 6105, AU P +61 8 9373 2905<tel:%2B61%208%209373%202905>,151 | F +61 8 9479 1190<tel:%2B61%208%209479%201190> | naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au> Visit our website www.dti.com.au<https://linkprotect.cudasvc.com/url?a=http://www.dti.com.au&c=E,1,RfoxiFc-w…> The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments. -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot<https://linkprotect.cudasvc.com/url?a=https://www.coreboot.org/mailman/list…>

1 0

← Newer
1
2
3
4
5
6
7
8
9
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 June 2016