coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

Re: [coreboot] [Coreboot] About (re)flash BIOS utility
by Idwer Vollering 12 Mar '14

12 Mar '14

2014-03-12 11:23 GMT+01:00 yu chyuan fu <fuh0826(a)gmail.com>: > Hi All > > I am a novice with coreboot. I successfully build coreboot.rom follow > www.coreboot.org. > Now i want to burn it to flash chips. I tried using the vendors provide > flash utility write to flash chips, it's can write success. > The vendor BIOS bootblock was likely left intact/untouched. > I plug in 0x80 debug card to mainboard then power on, coreboot stop > working and debug card output code is 0x02. > My guess is that the vendor BIOS' bootblock shows that particular code. The files behind these links do not include POST code 0x02: http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=documentation/POS… and http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/conso… Did you compile crossgcc right before 'make menuconfig'? > I suspect vendors provide flash utility maybe not support coreboot when i > reference FAQ<http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F> page > describe how to flash the BIOS. > The FAQ page suggest use the universal flash utility called flashrom.So, > if i don't use flashrom utility write to flash chips , even my > coreboot.rom is good,it always can't work? > > Thanks!! > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] [Coreboot] About (re)flash BIOS utility
by Gelip 12 Mar '14

12 Mar '14

Please specify motherboard and flash chip.

1 0

[Coreboot] About (re)flash BIOS utility
by yu chyuan fu 12 Mar '14

12 Mar '14

Hi All I am a novice with coreboot. I successfully build coreboot.rom follow www.coreboot.org. Now i want to burn it to flash chips. I tried using the vendors provide flash utility write to flash chips, it's can write success. I plug in 0x80 debug card to mainboard then power on, coreboot stop working and debug card output code is 0x02. I suspect vendors provide flash utility maybe not support coreboot when i reference FAQ<http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F> page describe how to flash the BIOS. The FAQ page suggest use the universal flash utility called flashrom.So, if i don't use flashrom utility write to flash chips , even my coreboot.rom is good,it always can't work? Thanks!!

1 0

OT: Looking for commercial-friendly open-source hardware license
by David Hendricks 12 Mar '14

12 Mar '14

A bit off-topic, but I figured some people on this list may have experience in this subject. I'm looking for a permissive license akin to BSD that applies well to hardware projects (ie focuses more on patents than copyrights) and is commercial-friendly so anyone can manufacture and sell the original design as well as derivatives. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] qemu
by Vladimir 'φ-coder/phcoder' Serbinenko 11 Mar '14

11 Mar '14

@ron: please provide more information about your qemu: version, how built, options, patches,... Try -M pc-q35-1.7 and -M pc-i440fx-1.7. Try specifying --no-kvm and --enable-kvm. Speyifying -cpu may help as well. From my experience with GRUB, qemu has following flaws: - From version to version they sometimes do subtle changes which break firmware. - On some CPUs kvm bugs or behaves unexpectedly. On 10.03.2014 14:43, David Hubbard wrote: > On Sunday, March 09, 2014 08:26:05 PM you wrote: >> On Sunday, March 09, 2014 05:14:51 PM you wrote: >> > Story so far: >> > >> > 1. pick q35 chipset >> > 2. qemu -M q35 etc. etc. >> >> $ qemu-system-i386 -M q35 --bios build/coreboot.rom >> >> -ENOREPRODUCE >> >> > 1. pick i440fx chipset. >> > 2. qemu -M pc etc. etc. >> >> qemu-system-i386 --bios build/coreboot.rom >> >> -ENOREPRODUCE >> >> > Endless repetitions of >> > qemu: unsupported keyboard cmd cmd=0x00 >> > or 0x80 >> >> -ENOREPRODUCE >> >> Same with qemu-kvm. >> >> > This is with crossgcc. >> > I'm disappointed it's this fragile. I'm worried that feature push has >> > gotten ahead of reliability push. >> >> Or your qemu installation is b0rk3d. > > Perhaps if it is that easy to break the installation -- remember, he did > a clean checkout -- then there could be a broken dependency, or > something similar which involves digging deeply into the build system. > > In other words, even if what you say is true, we still need to have this > conversation. > > I feel like Coreboot is a bit fiddly to get set up right. To a degree, > that helps communicate that working with coreboot is hard stuff. But > still, we should implement some better quality controls, imho. > > Hopefully we can figure out what Ron ran into. That would be a good start. > > David > >

1 0

GSoC-2014 Project for Coreboot
by Naman Govil 11 Mar '14

11 Mar '14

Hi! I am Naman, a junior year college undergrad with interest in Open Source Hardware-Software Development. I have been actively participating in coreboot community (mainly through the irc) for more than a month now, and have had lots of discussions with community mentors, while setting up coreboot on QEMU. I have had success working with basic payloads like the SeaBIOS and FILO. After having a basic understanding about coreboot, I was fascinated to work and learn more. I searched and found a project that I would like to do and began to draft my proposal for it. I am planning to pursue the project "Infrastructure for Accessing Block Devices on ARM SoCs" as a part of GSoC-2014. I have had encouraging support from Marc and other community mentors for this. Currently, I am in the process of drafting my proposal, and wanted some assistance on the same. I have been able define the goal for the project: a generic interface for accessing block devices on ARM SoCs so that coreboot could launch its stages from the block devices (an MMC for example). After discussions with Alex (mrnuke), I learnt about the existing support for coreboot on cubieboard, and hence will use this to test the interface. I needed some assistance on methods for developing the block device interface. One possibility is to work on the customizing uboot to our needs. (i.e do something like this: http://linux-sunxi.org/U-Boot#SD_Card) and create a simple API which would act as a MMC driver. I wanted to know how could I improve upon this. Or if there are other ways to accomplish this? I also wanted to ask whether I need to widen the goal of the project? And include some other functionalities? If yes, can I have some suggestions for the same? Some possibilities could be to have the API such that it can work in any stage (including bootblock), etc. Hope to get a feedback on this. :) Regards, Naman Govil

1 0

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by Rudolf Marek 11 Mar '14

11 Mar '14

Hi all, I checked the BKDG on AMD website and there is not much register differences between those CPUs: 42300 Rev 3.10 - June 04, 2013 BKDG for AMD Family 15h Models 10h-1Fh Processors: 1.5.4 Changes For Revision RL-A1 • Changes that may result in BIOS modifications. • Added 2.5.9.1 [Hybrid Boost] • Added D0F0xBC_x1F428[HybridBoostEn] • Other changes • Added D0F0xBC_x1F8EC It is just related to hybridboost enable. The only thing which might really need an update is a SMU firmware. It would be interesting to try with original BIOS if some other SMU firmware is used when trinity or richland CPU is used. Do you own also Trinity CPU? As for the errata, I think I have seen somewhere that the processors share the lists. I wrote just a note to the board wiki page about Richland, maybe we can do some #ifdef config option which would enable this hack via configuration option. We would also need some more sane error handling code in AGESA. I guess we can fix it with some patch. Any takers? Thanks Rudolf

2 1

Re: [coreboot] I've turned on paging as a test
by Rudolf Marek 11 Mar '14

11 Mar '14

Hi all, 1) As for NULL checkes I did something similar years ago: http://www.coreboot.org/pipermail/coreboot/2011-July/065792.html > Here is a PoC of NULL pointer dereference checking in coreboot x86. It is > surprisingly easy to implement. > > It uses strange expand down segments, making a data segment from 4KB-4GB (with > base 0). It should catch most NULL derefence symbols. Unfortunately we access > 0x500 while placing the coreboot tables. The hack in the patch just swaps the ds > selector work arounding that. > > More advanced method would use paging and PAE, first 4MB with 4KB pages rest > with 4MB pages identity mapped. We could even mark other than coreboot RAM range > as "missing" allowing more fine grained tests what is where accessed. > > Even the segment hack above could be used to check the stack overflows, but I > think we will need in IDT instead of interrupt gate a task gate and set there a > exception stack, otherwise it will end very badly while CPU is trying to safe > stack yet again during the exception. 2) There is a performance impact if you map first 2MB/4MB of RAM via ONE PAE page It is described in intel manual, but I don't recall on which page. I don't know how big the impact is. (there is a impact because of MTRR regions for 0-1MB), so one might use 4KB pages for first 1MB... 3) To solve a problem with legit BDA stuff... Just add some function to remap parts to some other and use virtual address to do that. We might eventually define some region like D-seg to be on 0x0000 instead on 0xd0000 and "problem solved" 4) some processors have bugs in PAT, mainly with WC override. Linux says: /* * There is a known erratum on Pentium III and Core Solo * and Core Duo CPUs. * " Page with PAT set to WC while associated MTRR is UC * may consolidate to UC " * Because of this erratum, it is better to stick with * setting WC in MTRR rather than using PAT on these CPUs. * * Enable PAT WC only on P4, Core 2 or later CPUs. */ if (c->x86 > 0x6 || (c->x86 == 6 && c->x86_model >= 15)) return; pat_disable("PAT WC disabled due to known CPU erratum."); return; Thanks Rudolf

1 0

Re: [coreboot] I've turned on paging as a test
by Aaron Durbin 11 Mar '14

11 Mar '14

On Mon, Mar 10, 2014 at 9:02 PM, ron minnich <rminnich(a)gmail.com> wrote: > Looking at the table, it seems to me that one can set an MTRR for a very > large area, to WB, and then have very fine control (4k boundaries, or 2M, or > 1G [I've used 1G before]) over the types of caching actually used as well as > protections. See figure 11-7, and see what you think. > > If this were true, then it might make our MTRR life a whole lot easier. That's definitely possible. One just needs to ensure that paging is always enabled if you were going to employ this approach. > > ron > > > On Mon, Mar 10, 2014 at 5:36 PM, Aaron Durbin <adurbin(a)google.com> wrote: >> >> On Mon, Mar 10, 2014 at 5:32 PM, ron minnich <rminnich(a)gmail.com> wrote: >> > I'm *pretty* *sure* that you can use the PATs as an alternative to >> > MTRRs. I >> > am going to dig a bit. It would sure make our life easier if we could >> > live >> > without all this MTRR fuss. We keep having to tweak the code and it's >> > never >> > been fun. >> > >> > And I like the idea of write-protecting coreboot code. >> >> In Intel manuals, there's a table named "Effective Page-Level Memory >> Types for Pentium III and More Recent Processor Families." There's a >> table that lists the combination of PAT and MTRR. It's not a an >> alternative. It describes how those settings interact. >> >> Anyway, depending on what exactly you want to solve there may be other >> solutions to your problem. >> >> -Aaron > >

1 0

Re: [coreboot] I've turned on paging as a test
by ron minnich 11 Mar '14

11 Mar '14

Looking at the table, it seems to me that one can set an MTRR for a very large area, to WB, and then have very fine control (4k boundaries, or 2M, or 1G [I've used 1G before]) over the types of caching actually used as well as protections. See figure 11-7, and see what you think. If this were true, then it might make our MTRR life a whole lot easier. ron On Mon, Mar 10, 2014 at 5:36 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Mon, Mar 10, 2014 at 5:32 PM, ron minnich <rminnich(a)gmail.com> wrote: > > I'm *pretty* *sure* that you can use the PATs as an alternative to > MTRRs. I > > am going to dig a bit. It would sure make our life easier if we could > live > > without all this MTRR fuss. We keep having to tweak the code and it's > never > > been fun. > > > > And I like the idea of write-protecting coreboot code. > > In Intel manuals, there's a table named "Effective Page-Level Memory > Types for Pentium III and More Recent Processor Families." There's a > table that lists the combination of PAT and MTRR. It's not a an > alternative. It describes how those settings interact. > > Anyway, depending on what exactly you want to solve there may be other > solutions to your problem. > > -Aaron >

1 0

← Newer
1
...
10
11
12
13
14
15
16
17
18
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 March 2014