Re: [coreboot] RFC: coding style: "standard" defines

On 02/08/2016 11:29 AM, Julius Werner wrote: >>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: 2016-02-04 10:35 GMT+01:00 Patrick Georgi : > during the review of some commits that are in the process of being > upstreamed from Chrome OS, people noticed

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines

On 02/01/2016 11:36 AM, Martin Roth wrote: > What I don't read in that blog post is anything about the > coreboot project being a democracy. I'd normally find such a statement very disappointing, but I'm pretty certain you're off on that one. I'm not sure how involved you've been in coreboot

Re: [coreboot] RFC: coding style: "standard" defines

Hi there, This seems pretty simple. On 02/04/2016 01:35 AM, Patrick Georgi via coreboot wrote: > Hi all, > > during the review of some commits that are in the process of being > upstreamed from Chrome OS, people noticed that chipset drivers like to > define their own TRUE/FALSE defines

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines

On 01/30/2016 11:30 AM, ron minnich wrote: > The change to the guidelines is hence a codification of a practice that > goes back to the project's beginnings. I find that statement inaccurate. This practice had not been an issue in the past, on patches that you yourself approved. Mixed syntaxes

Re: [coreboot] [RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only

On 01/22/2016 08:21 AM, Patrick Georgi wrote: > I'm uneasy > with recommending that when not strictly necessary (I'd consider a > project that's based on "or later" licensing to be such a case). I'm not sure if you mean "something I'm uneasy about", or "an example I'd consider" when you say

[coreboot] [RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only

I think this would be a good move for interoperability, so that GPLv3 projects (e.g. SeaBIOS) may take code from coreboot where needed (e.g. device drivers). I'm strictly talking about listing the preferred license; it's still up to contributors whether they want v2 or v2+. [1] Listed GPLv2+ as

Re: [coreboot] romcc issue with loop execution?

On 01/20/2016 09:23 AM, Andrey Korolyov wrote: > Hello, > > during initial bootstrap of an ancient Geode board I found that the > romstage hangs at After observing several issues with romcc, when the same code worked as expected with GCC, our team decided to discontinue use of ROMCC. It was

Re: [coreboot] X86 considered harmfull vs Coreboot

On 01/19/2016 12:46 PM, NTPT wrote: > Hi all > > I found a paper > Intel x86 considered harmful > Joanna Rutkowska She's screaming, and screaming, louder and louder, yet sadly very few people are actually paying attention. There isn't much we can do from a firmware point of view when the

Re: [coreboot] Where is the first instrucion?

On 01/10/2016 10:23 AM, ron minnich wrote: > One thing I think you'd enjoy doing is building the qemu target, setting > up qemu with gdb, and just watching what happens, instruction by > instruction, as the system boots. One exercise I liked doing was to rewrite the entire boot flow, from reset

Re: [coreboot] HP M6-1035dx vga bios option rom

On 01/02/2016 01:47 PM, Peter Stuge wrote: > KR Tejeda wrote: >> I cannot seem to restore the stock bios rom from the HP site in any >> reasonable way. I've tried flashing it via flashrom, and I've also >> tried extracting the contents of the stock rom with no luck. > > What did you try, exactly?

Re: [coreboot] [RFC] Prepending *Original* to tags from other repositories

On 12/31/2015 08:53 AM, Paul Menzel wrote: > change set #12804 [1] proposes the following addition to the file > `Documentation/gerrit_guidelines.md`. > > Unfortunately, I do not fully understand the reasoning yet. The core idea is to have a record of what happened where, and accountability.

Re: [coreboot] CBFS file format changed but documentation not updated

Hi Kevin, Please accept our apologies for this oversight. This should have been caught during review, but it was missed. I'll try to get a patch together to update the documentation. Alex On 11/17/2015 12:36 PM, Kevin O'Connor wrote: > I noticed that commit 0d618afc modified the CBFS file

[coreboot] commit messages and their suitability for coreboot.org

There's a trend I've been noticing about commit messages which is to follow google's format for everything coreboot. Please stop this. Here's why google's format is not suitable in many respects. For the sake of example, I will pick on a RABDOM commit message which follows the format: commonlib:

Re: [coreboot] baytrail + fsp_baytrail

Gerrit is open for business 24/7 On 12/14/2015 08:08 PM, Peter Stuge wrote: > ron minnich wrote: nobody cared enough to really do the work >>> >>> That's the problem - not the solution. Don't build infrastructure to >>> support complacency, build infrastructure to support desirable activity.

Re: [coreboot] baytrail + fsp_baytrail

On 12/07/2015 07:55 AM, Martin Roth wrote: > Here are my suggested steps: > 1) Look for commonalities between baytrail and other chipsets and move > pieces things into soc/intel/common A word of caution about soc/intel/common: it's a misnomer. It's very specific to FSP 1.1. Alex -- coreboot

Re: [coreboot] baytrail + fsp_baytrail

On 12/07/2015 06:34 PM, Alex G. wrote: > On 12/07/2015 07:55 AM, Martin Roth wrote: >> Here are my suggested steps: >> 1) Look for commonalities between baytrail and other chipsets and move >> pieces things into soc/intel/common > > A word of caution about soc/in

Re: [coreboot] baytrail + fsp_baytrail

On 12/06/2015 08:18 AM, Alexander Couzens wrote: > hi, > > baytrail and fsp_baytrail shares a lot of code. > Any ideas how we can merge these? That's not a very good idea. There are different sets of interest which use those two code paths, and trying to unify that will only get people stepping

Re: [coreboot] Payload that can do mmio32/pciserial UART on x86

Hi Patrick, Thanks! Someone else had also suggested this in a private email. I have one thing to say, and one thing only: AW YEAAA! Alex On 11/19/2015 12:12 AM, Patrick Georgi wrote: > 2015-11-19 4:49 GMT+01:00 Alex G. <mr.nuke...@gmail.com>: >> So, is there so

[coreboot] Payload that can do mmio32/pciserial UART on x86

Is there such a payload? Seabios is stuck with IO UARTs. Not sure if grub can handle it (and if so, how). Depthcharge is out of the question because it is unbelievably difficult to build outside chromium os's uber-cumbersome build system. So, is there something? Alex -- coreboot mailing list:

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

This is something I'd be interested in: Making a 501(c) (tax-deductible) contribution towards this goal. Is there a way to make this happen? Can the FSF get involved in this somehow? (they have 501(c)(3) status). Alex On 11/09/2015 07:50 PM, Francis Rowe wrote: > > > On 09/11/15 21:44, Timothy

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

On 11/06/2015 02:11 AM, Vladimir wrote: > * Did you know that Lenovo G505S is still widely available at some parts > of the world? (e.g. in Russia, 50+ online shops are still selling it) Yeah, I wrote most of the code for that. > * Did you know that Francis Rowe, head Libreboot developer, has

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

On 11/07/2015 09:23 AM, ron minnich wrote: > Can we calm down? Vladimir, your note came out after I -2'ed Alex's > proposal and we have made it clear that the proposal to "Remove" AGESA > is just that -- a proposal. It's not going to happen. Please, let me troll on this one. I'm having so much

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

On 11/07/2015 06:12 AM, Vladimir wrote: > That is why Francis suggested adding it to coreboot LTS Candidates list, > not to Libreboot list - because, while Lenovo G505S seems to be a great > coreboot LTS Candidate , it is still not ready for Libreboot. LTS requirements were meant to weed in

Re: [coreboot] setting up a bug tracker

On 11/04/2015 12:10 AM, Patrick Georgi wrote: > So, redmine? Let's try it. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rebuilding coreboot image generation

On 11/05/2015 09:55 PM, Julius Werner wrote: > HOST_FIRMWARE@0xff80 8M { > SI_ALL 2M { > SI_DESC 4K > SI_ME 0x1ff000 > } > SI_BIOS { > RW_A 0xf { > VBLOCK_A 64K >

Re: [coreboot] Rebuilding coreboot image generation

My main concern with this is that we're introducing another language, with something that may just as well end up being cmos.layout 2.0. I see where the manifest language is coming from. It's sort of like a FMAP dts, but then it really isn't. I understand that we don't want to use a per-board

Re: [coreboot] A case for branching AGESA

On 11/01/2015 12:49 AM, Patrick Georgi wrote: > Just a note: the only reason why current Intel fares better I didn't say Intel fares better. FSP is on my (rather long) hitlist, but that's not within the scope of this discussion. >> 7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed

[coreboot] A case for branching AGESA

AGESA is a very heavy beast, at over one and a half million lines of code. Although contributions to the AGESA codebase (boards and supporting chipset/cpu code) have slowed down significantly over the years, we still rebuild this behemoth for every version of a patch. This causes quite a bit of

Re: [coreboot] coreboot binary policy

On 10/29/2015 09:48 AM, Marc Jones wrote: > Hello coreboot, Hi Marc > Please limit comments to specific items in this version. If you have > additions for the next version (if needed), the draft document is open > for comment. > >

Re: [coreboot] Document for review: coreboot Gerrit Etiquette and Guidelines

On 10/29/2015 09:28 PM, ron minnich wrote: > It's a CL. Ooh, I thought it was a coreboot policy change that attempted to solve long-standing issues within coreboot. My bad. > It would be very helpful if you want to propose specific changes. I did. Refresh the page :) Alex -- coreboot mailing

Re: [coreboot] Document for review: coreboot Gerrit Etiquette and Guidelines

Hi Martin, It seems that the first part of your document ("Summary", and "More detail") is written in direct response to the removal of FSP 1.0 a month or so ago. As such, it's very situation-centric, and fails to address some more fundamental issues. The concept of a "maintainer" is central to

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

On 10/28/2015 07:00 AM, Peter Stuge wrote: > Patrick Georgi wrote: >> branches are where commits are pushed to die. > > Yes, this is a very important point, and is why I don't support Alex' > proposal of moving some things to live only on a branch, and not on master. So, tagging and removing

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

On 10/27/2015 01:36 PM, Vladimir wrote: > Although I agree with you that AMD is not innocent as well, if you would > check a "Binary situation" page at coreboot's wiki, you would see that > Intel is in three times more evil Probably "evil" is a bad term. I doubt that there's an ill intent. There

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 04:22 PM, Nico Huber wrote: > What I care about is that we shouldn't serialize in the first place if > we can avoid it. That makes sense, assuming we have access to internal data representation of the raminit code. For FSP and MRC (the biggest consumers of on-board SPD-less DRAM),

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 08:32 AM, ron minnich wrote: > Build the tool in go. Not everybody knows or wants to learn go. > It's trivial. If you have an idea how it ought to > work I can set it up in the playground in a few minutes. > > ron > > On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 01:59 PM, Nico Huber wrote: > Thanks for the support. One remark: I would really prefer serializing > during runtime Why waste runtime cycles (and code space) doing something you can already do at build time? > over compiling a C struct to a binary. We're not doing that either.

Re: [coreboot] SPD binaries in coreboot

On 10/23/2015 12:54 PM, Aaron Durbin wrote: > Do people realize these binaries sit in cbfs? Are we going to compile > random c files into object files then objcopy them? Then add to cbfs? > Also, the SPD format is quite silly as it is w.r.t. values crossing > multiple fields in a byte, etc.

Re: [coreboot] GPL license headers

bility. I don't really see any NEED to get rid of the second >> paragraph. >> >> Are there any other thoughts either way on getting rid of the second >> paragraph? >> >> Martin >> >> >> >> On Tue, Oct 20, 2015 at 6:47

Re: [coreboot] GPL license headers

On 10/21/2015 12:11 AM, Patrick Georgi wrote: > One issue brought up the last time we had this discussion was that > lawyers prefer to have their tools (eg. license scanners) continue to > work, which is why we shouldn't reduce the length too much Do those tools do the following? if

Re: [coreboot] GPL license headers

On 10/20/2015 10:54 AM, ron minnich wrote: > Eben Moglen, who ought to know, guided us on the release rules for the > Plan 9 GPL release. > > Here is what he told us could go in each file: > /* > * This file is part of the UCB release of Plan 9. It is subject to the > license > * terms in the

Re: [coreboot] GPL license headers

On 10/19/2015 11:44 AM, Patrick Georgi wrote: > Hi all, > > we recently removed the FSF addresses from license headers in our > files to avoid the maintenance of updating them every time the FSF > decides to move their office. +2 > Now we also added checkpatch.pl that comes from Linux to

[coreboot] Possible work from home coreboot developer position

I got a call yesterday from a staffing company about a coreboot position with AMD's Austin, Texas office. It's a work-from-home, 12 month contract with something to do with "AMD embedded processors". That's all I know. I turned down the guy, because I've got my own plate full of exciting coreboot

Re: [coreboot] Rangeley SoC FSP and Mohon Peak board support

l also be maintainer for FSP1.1. > > Thanks. > David. > > -Original Message- > From: Alex G. [mailto:mr.nuke...@gmail.com] > Sent: Tuesday, October 13, 2015 5:14 AM > To: Guckian, David; coreboot@coreboot.org; gauml...@gmail.com > Subject: Re: Rangeley SoC FSP and Moho

Re: [coreboot] Rangeley SoC FSP and Mohon Peak board support

Hi David, We had some chats today with CSG and IOTG teams, and from what I understood Huang Jin, and York Yang wanted to be the maintainers. If that changed, that's fine. We've started the process [1] of re-merging Rangeley [1], but we need confirmation on who the maintainers [2] are going to be.

Re: [coreboot] RFC: draft policy for accepting blob contributions to 3rdparty/blobs

Hi all, I like that we're talking about a policy, but I really feel the policy, as written right now, is specific to ISA blobs, and some of the points do not map very well to non-ISA blobs. I've made some inline comments om that. A point about ISA blobs and their licensing, is that whatever

Re: [coreboot] STACK_SIZE pcengines apu1

> In either case it's in AGESA. Of course it's AGESA. Good job on figuring out which part of AGESA (this is usually the hard part). Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unifying IO accessor macros

On 02/18/2015 12:52 PM, Julius Werner wrote: FWIW I sightly prefer write32(a, v) Then go for it. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFH] ACPI testers needed! -- free food*

On 02/11/2015 11:41 AM, Timothy Pearson wrote: All, I have recently updated the coreboot ACPI autogeneration code to generate valid processor _PSS objects when more than 10 cores are installed in one system. Unfortunately this required a rather large update to multiple boards in order to

[coreboot] Fwd: Re: New interface for I2C in coreboot

I knew there was something wrong to typing that from an Android phone. It didn't get sent to the list. Forwarded Message On Feb 10, 2015 2:19 AM, Patrick Georgi wrote: Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc: That's actually the way I2C is designed to work, and

Re: [coreboot] updating coreboot SeaBIOS on an Acer C720

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/08/2015 01:03 PM, Matthias Apitz wrote: Hello, I'm new to this list and do not even know if it is the right place to ask my question. So please be patient and/or forgive me. I'm running FreeBSD 11-HEAD on an Acer C720 Chromebook,

Re: [coreboot] Changes to the coreboot Project Structure

David, When you go out of line with a private email, expect to find yourself on a public list. Alex On 03/23/2014 05:04 AM, David Hubbard wrote: On Sun, Mar 23, 2014 at 1:26 AM, mrnuke mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On Sunday, March 23, 2014 07:34:32 AM

Re: [coreboot] [announce] coreboot for the 21st century

On 03/21/2014 05:28 PM, ron minnich wrote: On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke...@gmail.com wrote: On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote: Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :( Is there any way whatsoever to

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

On 02/09/2014 07:34 AM, Paul Menzel wrote: Sorry, no idea. I thought there were some. At least not all boards have been tested to my knowledge. Please stop just throwing half-thoght proposals out there when you have no idea (your words, not mine). Alex -- coreboot mailing list:

Re: [coreboot] Pavilion Chromebook 14 (Butterfly) QA session

On 01/20/2014 01:36 PM, David Hubbard wrote: Is this a typo? Did you mean the SATA is speed limited to 3Gbps? Yeah. SATA speed is limited to 3 (three) Gbps. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Systemagent hangs on PCH init with H61 chipset

Is there anything special that systemagent needs before it will actually do something useful. I've tried to run it on a board with a H61 chipset, and it just hangs at System Agent: Initializing PCH. I remember Damien had a similar problem a few months back. Alex coreboot-4.0-5198-g2588498-dirty

Re: [coreboot] Are any Chromebooks able to run fully libre?

On 12/27/2013 04:43 AM, Oliver Schinagl wrote: That said, how is A13, A20 support for coreboot? Non-existent. On A10, we're still figuring out how to read from MMC (partially working with code stolen from uboot), and how to init DRAM (hangs with code stolen from uboot). We don't have an

Re: [coreboot] Are any Chromebooks able to run fully libre?

On 12/27/2013 01:29 PM, David Hendricks wrote: Just to clarify a couple things... We don't have an infrastructure for block devices, let alone MMC. Up until now this has been considered the work of the payload. The existing ARM platforms supported in coreboot use SPI ROM to store the

Re: [coreboot] Are any Chromebooks able to run fully libre?

On 12/22/2013 11:45 PM, Olliver Schinagl wrote: It is 9k and has no RAM access and as far as we can tell not invoked after u-boot (sorry no coreboot (yet?) :p) takes over. I must have missed the memo about no coreboot. Alex -- coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] Are any Chromebooks able to run fully libre?

On 12/24/2013 07:31 PM, Gregg Levine wrote: Hello! He's complaining about a missing memo regarding Coreboot and such like. [...] I must have missed the memo about no coreboot. Fancy unpacking that statement for those of us who prefer less cryptic expression? :) Guys! This is getting

Re: [coreboot] BadBIOS Thoughts

On 11/20/2013 09:23 AM, ron minnich wrote: I've got a student coming in January and he's going to work on ChromeOS on AMD CPUs, starting with the Gizmo. If, at that time, someone has a suggestion for an AMD laptop which might be suitable, let me know. Would you care to elaborate on that? As

Re: [coreboot] BadBIOS Thoughts

On 11/20/2013 08:57 AM, Oliver Schinagl wrote: On 20-11-13 10:48, mrnuke wrote: On 11/20/2013 03:19 AM, Oliver Schinagl wrote: What happened to decline the EULA and demand your money back? Nobody does that anymore? Did YOU ever do it? I haven't bought (nor used at home) a windows

Re: [coreboot] Petition to Google: Please produce a midrange Chromebook

On 11/20/2013 10:13 PM, ron minnich wrote: Alex, you are of course free to submit such a petition. And, anyone who wishes can sign it. I've received an off-list request from one of our other enthusiasts (i.e. not a company or from a company) to remind you that you are not in a position to

Re: [coreboot] BadBIOS Thoughts

On 11/17/2013 03:45 PM, ron minnich wrote: I've tried before with some of those guys They're not going to help because they are not designers. Below a fairly high level, they don't know what's in their systems. Sure, it's a nice shiny skin. But all the real work is done by the ODM. Then

Re: [coreboot] Generate microcode from tree not working

On 07/15/2013 05:39 AM, Alec Ari wrote: Hello! Someone recently contacted me directly about my MA785GM-US2H coreboot port, and they weren't able to get the microcode to generate: HOSTCC cbfstool/cbfstool (link) LD cpu_microcode_blob.o

Re: [coreboot] Supported laptops (again), treacherous computing

On 07/22/2013 01:25 PM, Denis 'GNUtoo' Carikli wrote: On Mon, 15 Jul 2013 08:14:22 -0700 ron minnich rminn...@gmail.com wrote: I don't see how excluding the new, fixed version from coreboot helps anything. Further, it means you don't have bug-fixed microcode, which seems bad. It is at

Re: [coreboot] Best Supported Laptop

On 06/04/2013 12:36 AM, David Hendricks wrote: On Mon, Jun 3, 2013 at 1:57 PM, Alex G. mr.nuke...@gmail.com wrote: On 06/03/2013 03:10 PM, Oliver Schinagl wrote: On 06/03/13 16:03, Denis 'GNUtoo' Carikli wrote: Hi, On Sun, 2 Jun 2013 20:54:04 -0500 slhac tivistslhactiv...@gmail.com wrote

Re: [coreboot] Best Supported Laptop

On 06/03/2013 03:10 PM, Oliver Schinagl wrote: On 06/03/13 16:03, Denis 'GNUtoo' Carikli wrote: Hi, On Sun, 2 Jun 2013 20:54:04 -0500 slhac tivistslhactiv...@gmail.com wrote: Which supported laptop is the most free? The Lenovo X60. Strange that an Intel Part has the best support. I

[coreboot] Hijacking (was Trying to get coreboot running on VIA EPIA-M (lzma: Decoding error = 1) )

On 05/20/2013 10:16 AM, Marius Schäfer wrote: Hello, I just want to play around with coreboot on my old VIA EPIA-M, as it should be supportet and a good place to start. I just followed the Build HOWTO. But I always end up with 'lzma: Decoding error = 1'. I clonded coreboot from git, in

[coreboot] Rebasing a 2009 branch on current master (VX900 anyone?)

Hi, I am that guy that never seems to get VX900 working properly. I've recently received some code[1] for the VX900 from VIA. It is based on a coreboot fork from about 2009. Rather than try to continue my own VX900 effort, I think it is better to use the code provided by VIA, and clean that one

[coreboot] Microsoft Antitrust behaviour

To the United States Department of Justice, I would like to bring to your attention a matter of anticompetitive behaviour, which, in my honest opinion, will have a deep negative impact on the personal computer (PC) market. == What are the names of companies, individuals, or organizations that

Re: [coreboot] new Trinity APUs supported?

On 09/28/2012 03:47 AM, Rudolf Marek wrote: Hi all I'm considering to buy FM2 A10 CPU Asus F2A85-V PRO (or some cheaper variant) http://www.asus.com/Motherboards/AMD_Socket_FM2/F2A85M_PRO/ (looks it has also serial port). The CPU is I think family 12h. I checked the coreboot sources

[coreboot] Fwd: Microsoft Antitrust behaviour

What are your thoughts? Do you think any action will be taken? Alex Original Message Subject: Microsoft Antitrust behaviour Date: Mon, 24 Sep 2012 14:39:19 -0500 From: Alex G. mr.nuke...@gmail.com To: antitrust.complai...@usdoj.gov To the United States Department of Justice

Re: [coreboot] Support for a desired Motherboard

On 09/16/2012 12:58 PM, g...@habmalnefrage.de wrote: Hallo, I am interested in buying a new motherboard: ASUS Sabertooth 990FX or Gigabyte GA-990FXA-UD7 and wanted to use coreboot on it. In the released supported boards-List is none of them mentioned. Are there any further plans for one

Re: [coreboot] git commit problem

We need the complete git command(s) and complete git output. Alex On 09/04/2012 12:33 AM, Wang, SiYuan wrote: Hi, there is problem when I use git commit to commit changes. the message says: test failed: 'build/.../static.c build/.../static.c build/.../static.ramstage.o

Re: [coreboot] drivers/generic/ioapic enable_dev not called

IIRC: CPU - K8M890 == HT bus K8M890 - VT8237x == VIA V4 bus Since your problems come from the devices in VT8237x, I doubt HT is the offender. HT and PCI code uses very similar algorithms to locate and sort devices. Don't convince yourself that HT is the issue, or that _this_ code is the issue

Re: [coreboot] drivers/generic/ioapic enable_dev not called

On 08/28/2012 05:18 PM, Rudolf Marek wrote: Hi all, Just an update to this problem. It was missing scan_static_bus in parent device. Thanks goes to MrNuke ;) I have now another problem related to that work. For some reason HT bus thinks there are some left over devices: Capability:

Re: [coreboot] drivers/generic/ioapic enable_dev not called

For some reason, it seems that coreboot cannot find devices at those devfn. Normally, I'd say are you sure you aren't setting/unsetting a bit that disables those devices but there are just too many leftover devices. As a first step, pci_scan_get_dev() seems to be the offender. I would put a

Re: [coreboot] drivers/generic/ioapic enable_dev not called

Hi Rudolf, You need to have the ioapic driver compiled in. select DRIVERS_GENERIC_IOAPI In your mainboard's Kconfig should do the trick. Alex On 08/17/2012 09:30 AM, Rudolf Marek wrote: Hi all, I'm working on ioapic_irq support on M2V-MX SE. While at it, I wanted to factor out SB and NB

[coreboot] Documenting the process of Timestamp collection during romstage

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The idea of collecting timestamps during romstage is awesome. the only problem is that the code that does that is completely undocumented. Some stuff you figure out by looking at the code. Then there's timestamp_init(tsc_t), whose argument is read by

Re: [coreboot] User interface on coreboot

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2012 03:09 AM, Lap Ngo Doan wrote: Hi all, As you may know, when we enter to BIOS, we can use the keyboard to change some settings such as : enable/disable something, change boot devices priority It is kind of user interface on

[coreboot] Moving gerrit to an separate mailing list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've brought this up today on IRC. My main argument is that the coreboot mailing list should be a place for discussion, for newcomers asking for help, talking about the future of the project, etc. Definitely more for discussion and less for patch

[coreboot] Help needed on VX900 port

I have been working on a VIA VX900 port for over a year. Main problem is, I can't get the memory running properly. If you have a VX900 board, I would definitely appreciate some help. The datasheet for the VX900 is available from http://linux.via.com.tw/. I also have some code provided by VIA,

Re: [coreboot] potentially wrong uses of ifdef/if defined

On 04/19/2011 04:33 AM, Stefan Reinauer wrote: ./src/northbridge/amd/amdk8/coherent_ht.c:#ifndef CONFIG_K8_HT_FREQ_1G_SUPPORT #ifndef CONFIG_K8_HT_FREQ_1G_SUPPORT #define CONFIG_K8_HT_FREQ_1G_SUPPORT 0 #endif ./src/northbridge/amd/amdk8/coherent_ht.c:#ifndef

Re: [coreboot] where can i ask detailed technical questions about hardware?

On 04/06/2011 02:19 PM, Peter Stuge wrote: ali hagigat wrote: Is there any active site to discuss Intel data sheets? Not really. :\ Well, now and then there might be some people on #coreboot that have a nibble of extra knowledge on a specific topic, but nothing that would sum up to the end

Re: [coreboot] where can i ask detailed technical questions about hardware?

If you can redistribute those datasheets, I assume they are not under NDA, which means they are the public datasheets available on Intel's site. If they are public datasheets, you can simply reference the link and the page number. If they are not public, but you have the right to quote them, you

Re: [coreboot] [RFC][PATCHv2]add WIP_ARM config entry

P.S. Can I use git diff to generate the patch? Why not? It isn't _that_ difficult to patch -p1 instead of -p0. :) I've seen a few git diff patches flying around, and no one complained. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC][PATCHv2]add WIP_ARM config entry

On 04/06/2011 05:25 PM, Paul Menzel wrote: PPS: Is this a good time to move to Git altogether? A mirror already exists. ;-) Since I am not doing any development, I am not the one to make that call. It's nice to have a git mirror, but contributors shouldn't be forced to use git, especially

Re: [coreboot] [PATCH 2/2] BUILD: preprocess devicetree

On 03/27/2011 01:02 PM, Sven Schnelle wrote: pass devicetree.cb trough cpp before parse it with sconfig. This has the advantage that we can use Kconfig variables in devicetree.cb. Signed-off-by: Sven Schnelle sv...@stackframe.org --- I like the idea. If abuild doesn't complain, then

Re: [coreboot] [PATCH 1/2] BUILD: add config.h dependency

On 03/27/2011 01:02 PM, Sven Schnelle wrote: Signed-off-by: Sven Schnelle sv...@stackframe.org --- Acked-by: Alexandru Gagniuc mr.nuke...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Conflicting default options - option ROM exec and SeaBIOS

Right now, the default options in Kconfig are to pull SeaBIOS stable, AND enable option ROM execution. This leaves people with a system that has option ROMs executing twice. As you might have imagined, this results in undefined behavior. Some people are lucky and their systems still run, while

Re: [coreboot] [PATCH 1/7] SuperMicro H8SCM support (AMD SR5650)

On 03/23/2011 08:56 AM, Bao, Zheng wrote: Add AMD SR56x0 support. Signed-off-by: Zheng Bao zheng@amd.com Socket C32. Thank you! Thanked-by: Alexandru Gagniuc mr.nuke...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Support for Core i3 and better

On 03/11/2011 12:19 PM, Oleg Gvozdev wrote: Hello Could you, please, advise what motherboard I should use with coreboot to support Core i3, i5 or i7 CPU ? Yes. And if any of these CPUs is not supported for now, where they will be supported? In their momma's gusset. As an alternative: do

Re: [coreboot] Support for Core i3 and better

On 03/11/2011 01:50 PM, Oleg Gvozdev wrote: I look now at Gygabyte GA-MA785GMT-UD2H and AM3 socket. And this is the board I would have suggested. It's the only officially suppported board with AM3 and DDR3. http://www.coreboot.org/GIGABYTE_GA-MA785GMT-UD2H The problem with this board is that

Re: [coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

On 03/12/2011 01:19 AM, Stefan Reinauer wrote: The S2735 is a dual Xeon server board. While I am pretty sure that this one worked nicely at some point, I don't think that this suggests that we should enable the same CAR code on all other socket 604 boards without testing. Umh, the same CAR

Re: [coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

On 03/12/2011 03:02 AM, Stefan Reinauer wrote: * Alex G. mr.nuke...@gmail.com [110312 00:32]: Umh, the same CAR code is used for all supported Intel CPUs. No, it's not. It just happens to live in a directory that seems to imply this. There are quire a number of Intel CPUs that don't work

[coreboot] [The 604 CAR crusades][Master Yoda style] Preludium

Hi everyone, The Tyan S2735 a Socket 604 (Intel) board it is which CAR it uses I found. Why care I should? yourself you ask. Because eight boards which socket 604 use, ROMCC they are. dell/s1850 intel/jarrell intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g supermicro/x6dhe_g2

[coreboot] [PATCH] [1/4] [The 604 CAR crusades] Episode I - The Superio Menace

See patch. Enable the NSC PC87427 early_init to be used with CAR boards. The regular coompiler will complain about unused variables or unused functions. Remove unused variables, and only include unused functions if __ROMCC__ is defined. Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com

[coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

While the previous two patches were innocently trivial and abuild tested, this one _will_ break the build for several Socket 604 boards. We want the build to be broken until we can port those to CAR. See patch for verbosity. The Tyan s2735 is a Socket 604 board that uses CAR. cache_as_ram.inc is

[coreboot] [PATCH][2/4][The 604 CAR crusades] Episode II - The Northbridge Wars

See patch. We need to do two things to allow the intel e7520 to be used by CAR boards. Remove unused variables. Add a declaration for sdram_initialize(). Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com Index: src/northbridge/intel/e7520/raminit.c

[coreboot] [PATCH] [4/4] [The 604 CAR crusades] Episode IV - A new board

See patch. Fixes the build errors that occur when compiling the Supermicro X6DHE-G2 as a CAR board. Unused variables are removed, and unused functions are excluded with #if/#endif Signed-off-by: Alexandru Gagniuc mr/nuke...@gmail.com Index: src/mainboard/supermicro/x6dhe_g2/Kconfig

  1   2   >