coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

Re: [coreboot] [announce] coreboot for the 21st century
by mrnuke 22 Mar '14

22 Mar '14

On Friday, March 21, 2014 11:19:42 PM ron minnich wrote: > If you're going to make big changes to what happens at coreboot.org, > you have to get buyin from the folks who do all the work. > If we're going to refactor the development model, I insist we do it right. Patrick was discussing gitlab as a possible alternative to gerrit. I think it's time to closely evaluate our options. > I'm not the right person to propose this to :-) I think I CC'd the ML. Yup, I did. > Put simply, it's above my pay grade. > Ran out of $0.02 on this? :) Alex

1 0

Re: [coreboot] [announce] coreboot for the 21st century
by mrnuke 22 Mar '14

22 Mar '14

On Friday, March 21, 2014 09:18:07 PM ron minnich wrote: > On Fri, Mar 21, 2014 at 6:52 PM, Alex G. <mr.nuke.me(a)gmail.com> wrote: > > The bad-ness or good-ness of motives is relative. Note that I'm not > > > > using "bad" in the sense of "evil". Let's look at the six gatekeeper idea: > > * Easier for commercial entities to upstream code, therefore faster > > progress for coreboot (good motive). (a) > > * Easier for commercial entities to upstream code, therefore we can get > > lazy even if code quality drops (bad motive). (b) > > That's not the intent. The way you are stating this has a lot of > built-in assumptions, and you're mixing some things up. That's our > fault; the old rule is, that if someone did not understand what you > said, it's your fault, not theirs. So, speaking as one of the guys who > reviewed the email, I'm sorry it was not clearer. > Let's be honest. Upstreaming contributions from Google has been a long and tedious O(n^2) process. Even though we've improved a bit in terms of jenkins build time (optimizations to abuild et. cetera) so that we don't have to wait one week for a bomb to verify, the workflow of one review per patch is still sub-optimal. > So, first, the intent of the six gatekeeper idea is, in part, to be > sure we're being very careful about what goes in. > [...] Six seems a very arbitrary, even number. > [...] > > So it's not about "Easier for commercial entities to upstream code" -- > it's about not having to do the full review process *twice*, given > that the code has been picked to pieces by experienced long-time > coreboot coders, most of whom (no offense intended) are better > qualified to review the code than almost anyone else. That's why I > claim what you are saying as not quite right. > I think we need to restart this discussion without the implicit assumption that gerrit is a part of the workflow. We can do what Linux does. Different individuals maintain different sub-somethings of the coreboot tree. I'm not trying to establish any criteria for maintainer status. Short answer: 1* Google team (*) assigns a coreboot representative 2* Rep decides it's time to merge some good branch 3* Rep takes internal branch, and works on top of branch 4* Rep makes branch mergeable 5* Rep submits pull/merge request to maintainer (**) of touched code 6* Maintainer reviews branch as one unit and requests changes 7* Rep applies changes on top of branch 8* Repeat 6 and 7 as needed 9* Maintainer likes what he's seeing, merges branch to his tree (*) They're still welcome to hang on IRC, ML, and/or submit individual patches. (**) Maintainer and rep must be different persons, preferably not from the same team and/or not from teams working on the same thing. This process eliminates the *twice* review. Individual patches are no longer reviewed upstream; however, a review is still done, and corrections are still applied. Since a logical change is a branch rather than a patch, the overhead is reduced significantly without eliminating the "community scrutiny" phase. You keep all the goodies and reduce review complexity from O(n^2) to O(1). Sound good so far? But wait! There's more! As a bonus, considering that individual patches are no longer altered, we have the hashes of shipping firmware. So, why is this better than the gatekeepers idea? * We don't bottleneck patches by limiting number of submitters/maintainers * Maintainers can focus on the part of tree matching their expertise * Reduces patch bikeshedding as maintainers have the final word Take this a step further: maintainer trees are not the master tree. Maintainers still have to periodically get their branches merged with master. > Finally, a simple question here: how many gatekeepers are there for > the final full released version of each version of the Linux kernel? > Do you want me to answer that in binary, ternary, octal, or hexadecimal? Those gatekeeprs don't deal with individual patches, do they? > My $.02 anyway. > Keep on sending them. A few hundred more of them, and I'll have enough for a cigar. Alex

2 1

Re: [coreboot] [announce] coreboot for the 21st century
by ron minnich 22 Mar '14

22 Mar '14

On Fri, Mar 21, 2014 at 4:50 PM, David Hubbard <david.c.hubbard+coreboot(a)gmail.com> wrote: > I've been thinking about it all day and it seems Vladimir is pretty much > spot on, "The proposition of gatekeepers would essentially kill community > effort." There's just something I'm clearly not understanding here. For the first year or so of linuxbios, I was the gatekeeper. Nobody but me could push into the repo. We had lots of involvement. For many open source projects I've been contributing to, there's always a set of gatekeepers, and there's tons of community involvement. E.G., Go has a restricted set of people who can let a patch go into the upstream, and there is no shortage of people contributing. When I worked on FreeBSD, I was never one of the people who could push a patch into the repo, but my changes were accepted. It never bothered me much; those were the rules and I thought they made sense. So what is the issue again? I'm trying to understand. Is it the limited number? Is it the existence of gatekeepers at all? ron

1 0

Re: [coreboot] [announce] coreboot for the 21st century
by Alex G. 22 Mar '14

22 Mar '14

On 03/21/2014 05:28 PM, ron minnich wrote: > On Fri, Mar 21, 2014 at 1:33 PM, mrnuke <mr.nuke.me(a)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 temporarily use the cache as SRAM? > > when we did the first real CAR work MTRRs were not needed. I'm not > sure if they would be on the vortex. We might want to test the very > early CAR code and see how it goes. It's actually quite simple. > It would be nice to make sure modern hardware uses modern infrastructure. > Also, let's just take it a little easy here. These are proposals, > nothing is ever perfect on first release, the world is not ending, > Google is not showing up at coreboot.org in skimasks and unmarked > uniforms ... > Damn! I was hoping to steal some ski gear from them. > I think a fork would harm everyone Sure, if you stab the person hard enough. > and would be destructive of our > common goals. Please remember that we are all trying to do the right > thing, and our different situations give us different perspectives. > When Stefan sounds so serious, it's hard to tell whether he is just proposing, or announcing changes. Remember, he's the guy that can port a new board with his eyes closed [1]. People take him too seriously sometimes. > Nobody is coming in here with bad motives. We're just trying to muddle > our way through the many demands of different stakeholders now that > coreboot, thanks to the efforts of some pretty dedicated people, has > become a runaway success. > The bad-ness or good-ness of motives is relative. Note that I'm not using "bad" in the sense of "evil". Let's look at the six gatekeeper idea: * Easier for commercial entities to upstream code, therefore faster progress for coreboot (good motive). (a) * Easier for commercial entities to upstream code, therefore we can get lazy even if code quality drops (bad motive). (b) So, in your 15 years of doing this, which option should prevail? Alex [1] http://www.coreboot.org/Coreboot_Developer_Facts

2 1

Re: [coreboot] [announce] coreboot for the 21st century
by David Hubbard 22 Mar '14

22 Mar '14

On Fri, Mar 21, 2014 at 4:28 PM, ron minnich <rminnich(a)gmail.com> wrote: > On Fri, Mar 21, 2014 at 1:33 PM, mrnuke <mr.nuke.me(a)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 temporarily use the cache as SRAM? > > when we did the first real CAR work MTRRs were not needed. I'm not > sure if they would be on the vortex. We might want to test the very > early CAR code and see how it goes. It's actually quite simple. > > Also, let's just take it a little easy here. These are proposals, > nothing is ever perfect on first release, the world is not ending, > Google is not showing up at coreboot.org in skimasks and unmarked > uniforms ... > > I think a fork would harm everyone, and would be destructive of our > common goals. Please remember that we are all trying to do the right > thing, and our different situations give us different perspectives. > > Nobody is coming in here with bad motives. We're just trying to muddle > our way through the many demands of different stakeholders now that > coreboot, thanks to the efforts of some pretty dedicated people, has > become a runaway success. > I've been thinking about it all day and it seems Vladimir is pretty much spot on, "The proposition of gatekeepers would essentially kill community effort." Was Stefan's governance change discussed at any level before announcement? Will he discuss it now? Here's to hoping we can work together. I might be able to contribute to that IOAPIC thorn you've got. David

1 0

ioapic dump tool
by ron minnich 22 Mar '14

22 Mar '14

anybody know of a tool to dump all apics/ioapics from user mode? I'm having a Very Stupid Problem with a research OS in that we can't get the apic's and or iopiac's working. I suck at these things. We can't tell what we've got wrong.I'm hoping a register dump would help us. ron

1 0

Re: [coreboot] Changes to the coreboot Project Structure
by David Hendricks 21 Mar '14

21 Mar '14

On Fri, Mar 21, 2014 at 11:52 AM, David Hendricks <dhendrix(a)google.com>wrote: > > > > On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger < > c-d.hailfinger.devel.2006(a)gmx.net> wrote: > >> Hi Stefan, >> >> streamlining development and maintenance is definitely absoutely >> worthwhile. Getting rid of unmaintained code is also a good thing. The >> guidelines presented in your mail look mostly good IMHO, but I'd like to >> comment on a few things. >> >> Am 20.03.2014 22:55 schrieb Stefan Reinauer: >> > * Significantly reduce number of submitters >> > To ensure consistency, scalability and conformity with the general >> > coreboot strategy, we need to define a clear committer structure that >> > defines the original project structure of having a benevolent dictator >> > aka project leader (Stefan Reinauer) and gatekeepers in place. The >> > suggested structure will need to value both community interests and >> > corporate interests equally and hence a good setup would be to have a >> > final amount of six developers with submit rights, three community >> > representatives and three corporate representatives (on from each >> major >> > stakeholder): >> >> I see a huge bottleneck in restricting the number of committers to six. >> - Corporate committers will be primarily obliged to get the stuff of >> their own employer committed, but if they are ill or on vacation, >> someone else would have to take over. This would either be another >> corporate committer (in which case their own employer would have to >> authorize spending time for a different company) or a community committer. >> > > Companies that "get" open-source development don't operate that way, > thankfully. > > >> - Community committers are not paid, and commit in their spare time. >> Spare time is not necessarily abundant all year round. Speaking from >> experience, the flashrom project has no shortage in developers or >> submitted patches, but a real and painful shortage in >> reviewers/committers. The flashrom project patch backlog is huge due to >> this. > > > Flashrom's problems run a lot deeper than that. Rather than regurgitate > old discussion, I'll point to this thread: > http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html > > >> Doing a commit is easy, but making sure that a commit follows >> certain guidelines is a huge time sink with none of the fun of writing >> code. >> - New contributors (corporate or community) would have to find a >> "sponsor" to actually commit their code. With a large committer base, >> this can happen rather quickly. With only six committers facing their >> own deadlines or other shortages of time, this could take quite a while. > > >> AFAICS the reason to reduce the number of coreboot committers is to have >> gatekeepers who actually enforce guidelines by looking at patches before >> they commit them. That essentially introduces an additional review step. >> > > Anybody can review a patch and give it a score. AFAICT gatekeepers are > necessarily tasked with scrutinizing code, > s/are/are NOT > and in fact that will be impossible in many cases where documentation for > a new chip isn't public. The way I read it, a committer ensures that > patches meet quality/consistency guidelines, adds additional > reviewers/stakeholders when appropriate, and can optionally do a more > thorough review, with the intention of helping authors to navigate the > review process effectively. > > How many times have community members sent their patches for review only > to have them bitrot for days, weeks, or even months? There have been many > occasions where Stefan and Ron spend a weekends hanging out in a coffee > shop and just going thru stale patches on gerrit to try to reduce the > backlog. I doubt the intention is to make the review process more > bureaucratic or increase the backlog. > > While such a step may be desirable, it would have to be made clear whose >> obligation it is to carry out commit+review step for new contributors, >> and how any fallback/failover mechanisms are implemented. >> > > MAINTAINERS file? > > Having gerrit automatically add reviewers would be tremendously helpful > too. > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

GSoC-2014 Coreboot project
by Allen Yan 21 Mar '14

21 Mar '14

Hi, everyone, I've sent a preliminary proposal about "Tianocore as coreboot payload". https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014… I'd like to get more feedback about the goal and the test environment. Thanks! Regards! Jinyi Yan

1 0

Re: [coreboot] [announce] coreboot for the 21st century
by Stefan Reinauer 21 Mar '14

21 Mar '14

* ron minnich <rminnich(a)gmail.com> [140320 22:37]: > I like this, I just wish we could remove more boards :-) I was surprised that the number of boards still using ROMCC for romstage was so low. We could also remove the revF and Fam10 boards because the use non-standardized cache as ram implementation. Are any boards in particular making progress hard? Stefan

3 2

Re: [coreboot] GSoC 2014
by David Hendricks 21 Mar '14

21 Mar '14

This is a great start :-) On Thu, Mar 20, 2014 at 1:56 PM, Allen Yan <lexkde(a)gmail.com> wrote: > Hi, > coreboot+seabios running in QEMU > output: > > coreboot-4.0-5656-gb34739b Thu Mar 13 10:37:43 CST 2014 starting... > CBMEM region 3fee0000-3fffffff (cbmem_check_toc) > CBMEM region 3fee0000-3fffffff (cbmem_initialize_empty) > Adding CBMEM entry as no. 1 > Adding CBMEM entry as no. 2 > Trying CBFS ramstage loader. > CBFS: loading stage fallback/coreboot_ram @ 0x100000 (180280 bytes), > entry @ 0x100000 > QEMU debugcon not found [port 0x402] > coreboot-4.0-5656-gb34739b Thu Mar 13 10:37:43 CST 2014 booting... > Enumerating buses... > Show all devs...Before device enumeration. > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > APIC: 00: enabled 1 > DOMAIN: 0000: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:01.1: enabled 1 > PCI: 00:01.3: enabled 1 > Compare with tree... > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > APIC: 00: enabled 1 > DOMAIN: 0000: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:01.1: enabled 1 > PCI: 00:01.3: enabled 1 > scan_static_bus for Root Device > CPU_CLUSTER: 0 enabled > DOMAIN: 0000 enabled > CPU_CLUSTER: 0 scanning... > QEMU: firmware config interface detected > QEMU: max_cpus is 1 > CPU: APIC: 00 enabled > DOMAIN: 0000 scanning... > PCI: pci_scan_bus for bus 00 > PCI: 00:00.0 [8086/1237] ops > PCI: 00:00.0 [8086/1237] enabled > PCI: 00:01.0 [8086/7000] bus ops > PCI: 00:01.0 [8086/7000] enabled > PCI: 00:01.1 [8086/7010] ops > PCI: 00:01.1 [8086/7010] enabled > PCI: 00:01.3 [8086/7113] bus ops > Wakeup from ACPI sleep type S5 (PMCNTRL=0000) > PCI: 00:01.3 [8086/7113] enabled > PCI: 00:02.0 [1013/00b8] ops > PCI: 00:02.0 [1013/00b8] enabled > PCI: 00:03.0 [8086/100e] enabled > scan_static_bus for PCI: 00:01.0 > scan_static_bus for PCI: 00:01.0 done > scan_static_bus for PCI: 00:01.3 > scan_static_bus for PCI: 00:01.3 done > PCI: pci_scan_bus returning with max=001 > scan_static_bus for Root Device done > done > found VGA at PCI: 00:02.0 > Setting up VGA for PCI: 00:02.0 > Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 > Setting PCI_BRIDGE_CTL_VGA for bridge Root Device > Allocating resources... > Reading resources... > Root Device read_resources bus 0 link: 0 > CPU_CLUSTER: 0 read_resources bus 0 link: 0 > APIC: 00 missing read_resources > CPU_CLUSTER: 0 read_resources bus 0 link: 0 done > QEMU: 5 files in fw_cfg > QEMU: etc/boot-fail-wait [size=4] > QEMU: genroms/kvmvapic.bin [size=9216] > QEMU: etc/system-states [size=6] > QEMU: etc/pvpanic-port [size=2] > QEMU: bootorder [size=0] > QEMU: cmos: 1024 MiB RAM below 4G. > QEMU: cmos: 0 MiB RAM above 4G. > QEMU: reserve ioports 0x0510-0x0511 [firmware-config] > QEMU: reserve ioports 0x5658-0x5658 [vmware-port] > QEMU: reserve ioports 0xae00-0xae0f [pci-hotplug] > QEMU: reserve ioports 0xaf00-0xaf1f [cpu-hotplug] > QEMU: reserve ioports 0xafe0-0xafe3 [piix4-gpe0] > CBMEM region 3fee0000-3fffffff (cbmem_late_set_table) > DOMAIN: 0000 read_resources bus 0 link: 0 > DOMAIN: 0000 read_resources bus 0 link: 0 done > Root Device read_resources bus 0 link: 0 done > Done reading resources. > Show resources in subtree (Root Device)...After reading. > Root Device child on link 0 CPU_CLUSTER: 0 > CPU_CLUSTER: 0 child on link 0 APIC: 00 > APIC: 00 > DOMAIN: 0000 child on link 0 PCI: 00:00.0 > DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags > 40040100 index 10000000 > DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff > flags 40040200 index 10000100 > DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags > e0004200 index a > DOMAIN: 0000 resource base c0000 size 3ff40000 align 0 gran 0 limit > 0 flags e0004200 index b > DOMAIN: 0000 resource base 510 size 2 align 0 gran 0 limit ffff > flags e0000100 index c > DOMAIN: 0000 resource base 5658 size 1 align 0 gran 0 limit ffff > flags e0000100 index d > DOMAIN: 0000 resource base ae00 size 10 align 0 gran 0 limit ffff > flags e0000100 index e > DOMAIN: 0000 resource base af00 size 20 align 0 gran 0 limit ffff > flags e0000100 index f > DOMAIN: 0000 resource base afe0 size 4 align 0 gran 0 limit ffff > flags e0000100 index 10 > DOMAIN: 0000 resource base fec00000 size 100000 align 0 gran 0 limit > ffffffff flags e0000200 index 2 > DOMAIN: 0000 resource base fee00000 size 10000 align 0 gran 0 limit > ffffffff flags e0000200 index 3 > PCI: 00:00.0 > PCI: 00:01.0 > PCI: 00:01.0 resource base 0 size 1000 align 0 gran 0 limit ffff > flags c0000100 index 1 > PCI: 00:01.0 resource base ff800000 size 800000 align 0 gran 0 > limit 0 flags d0000200 index 2 > PCI: 00:01.1 > PCI: 00:01.1 resource base 0 size 10 align 4 gran 4 limit ffff > flags 100 index 20 > PCI: 00:01.3 > PCI: 00:01.3 resource base e400 size 40 align 0 gran 0 limit ffff > flags d0000100 index 1 > PCI: 00:01.3 resource base f00 size 10 align 0 gran 0 limit ffff > flags d0000100 index 2 > PCI: 00:02.0 > PCI: 00:02.0 resource base 0 size 2000000 align 25 gran 25 limit > ffffffff flags 1200 index 10 > PCI: 00:02.0 resource base 0 size 1000 align 12 gran 12 limit > ffffffff flags 200 index 14 > PCI: 00:02.0 resource base 0 size 10000 align 16 gran 16 limit > ffffffff flags 2200 index 30 > PCI: 00:03.0 > PCI: 00:03.0 resource base 0 size 20000 align 17 gran 17 limit > ffffffff flags 200 index 10 > PCI: 00:03.0 resource base 0 size 40 align 6 gran 6 limit ffff > flags 100 index 14 > PCI: 00:03.0 resource base 0 size 20000 align 17 gran 17 limit > ffffffff flags 2200 index 30 > DOMAIN: 0000 compute_resources_io: base: 0 size: 0 align: 0 gran: 0 limit: > ffff > PCI: 00:03.0 14 * [0x0 - 0x3f] io > PCI: 00:01.1 20 * [0x40 - 0x4f] io > DOMAIN: 0000 compute_resources_io: base: 50 size: 50 align: 6 gran: 0 > limit: ffff done > DOMAIN: 0000 compute_resources_mem: base: 0 size: 0 align: 0 gran: 0 > limit: ffffffff > PCI: 00:02.0 10 * [0x0 - 0x1ffffff] prefmem > PCI: 00:03.0 10 * [0x2000000 - 0x201ffff] mem > PCI: 00:03.0 30 * [0x2020000 - 0x203ffff] mem > PCI: 00:02.0 30 * [0x2040000 - 0x204ffff] mem > PCI: 00:02.0 14 * [0x2050000 - 0x2050fff] mem > DOMAIN: 0000 compute_resources_mem: base: 2051000 size: 2051000 align: > 25 gran: 0 limit: ffffffff done > avoid_fixed_resources: DOMAIN: 0000 > avoid_fixed_resources:@DOMAIN: 0000 10000000 limit 0000ffff > avoid_fixed_resources:@DOMAIN: 0000 10000100 limit ffffffff > constrain_resources: DOMAIN: 0000 > constrain_resources: PCI: 00:00.0 > constrain_resources: PCI: 00:01.0 > constrain_resources: PCI: 00:01.1 > constrain_resources: PCI: 00:01.3 > constrain_resources: PCI: 00:02.0 > constrain_resources: PCI: 00:03.0 > avoid_fixed_resources2: DOMAIN: 0000@10000000 limit 0000ffff > lim->base 00005659 lim->limit 0000adff > avoid_fixed_resources2: DOMAIN: 0000@10000100 limit ffffffff > lim->base 40000000 lim->limit febfffff > Setting resources... > DOMAIN: 0000 allocate_resources_io: base:5659 size:50 align:6 gran:0 > limit:adff > Assigned: PCI: 00:03.0 14 * [0x5800 - 0x583f] io > Assigned: PCI: 00:01.1 20 * [0x5840 - 0x584f] io > DOMAIN: 0000 allocate_resources_io: next_base: 5850 size: 50 align: 6 > gran: 0 done > DOMAIN: 0000 allocate_resources_mem: base:fc000000 size:2051000 > align:25 gran:0 limit:febfffff > Assigned: PCI: 00:02.0 10 * [0xfc000000 - 0xfdffffff] prefmem > Assigned: PCI: 00:03.0 10 * [0xfe000000 - 0xfe01ffff] mem > Assigned: PCI: 00:03.0 30 * [0xfe020000 - 0xfe03ffff] mem > Assigned: PCI: 00:02.0 30 * [0xfe040000 - 0xfe04ffff] mem > Assigned: PCI: 00:02.0 14 * [0xfe050000 - 0xfe050fff] mem > DOMAIN: 0000 allocate_resources_mem: next_base: fe051000 size: 2051000 > align: 25 gran: 0 done > Root Device assign_resources, bus 0 link: 0 > DOMAIN: 0000 assign_resources, bus 0 link: 0 > PCI: 00:01.1 20 <- [0x0000005840 - 0x000000584f] size 0x00000010 gran 0x04 > io > PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] size 0x02000000 gran > 0x19 prefmem > PCI: 00:02.0 14 <- [0x00fe050000 - 0x00fe050fff] size 0x00001000 gran 0x0c > mem > PCI: 00:02.0 30 <- [0x00fe040000 - 0x00fe04ffff] size 0x00010000 gran 0x10 > romem > PCI: 00:03.0 10 <- [0x00fe000000 - 0x00fe01ffff] size 0x00020000 gran 0x11 > mem > PCI: 00:03.0 14 <- [0x0000005800 - 0x000000583f] size 0x00000040 gran 0x06 > io > PCI: 00:03.0 30 <- [0x00fe020000 - 0x00fe03ffff] size 0x00020000 gran 0x11 > romem > DOMAIN: 0000 assign_resources, bus 0 link: 0 > Root Device assign_resources, bus 0 link: 0 > Done setting resources. > Show resources in subtree (Root Device)...After assigning values. > Root Device child on link 0 CPU_CLUSTER: 0 > CPU_CLUSTER: 0 child on link 0 APIC: 00 > APIC: 00 > DOMAIN: 0000 child on link 0 PCI: 00:00.0 > DOMAIN: 0000 resource base 5659 size 50 align 6 gran 0 limit adff > flags 40040100 index 10000000 > DOMAIN: 0000 resource base fc000000 size 2051000 align 25 gran 0 > limit febfffff flags 40040200 index 10000100 > DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags > e0004200 index a > DOMAIN: 0000 resource base c0000 size 3ff40000 align 0 gran 0 limit > 0 flags e0004200 index b > DOMAIN: 0000 resource base 510 size 2 align 0 gran 0 limit ffff > flags e0000100 index c > DOMAIN: 0000 resource base 5658 size 1 align 0 gran 0 limit ffff > flags e0000100 index d > DOMAIN: 0000 resource base ae00 size 10 align 0 gran 0 limit ffff > flags e0000100 index e > DOMAIN: 0000 resource base af00 size 20 align 0 gran 0 limit ffff > flags e0000100 index f > DOMAIN: 0000 resource base afe0 size 4 align 0 gran 0 limit ffff > flags e0000100 index 10 > DOMAIN: 0000 resource base fec00000 size 100000 align 0 gran 0 limit > ffffffff flags e0000200 index 2 > DOMAIN: 0000 resource base fee00000 size 10000 align 0 gran 0 limit > ffffffff flags e0000200 index 3 > PCI: 00:00.0 > PCI: 00:01.0 > PCI: 00:01.0 resource base 0 size 1000 align 0 gran 0 limit ffff > flags c0000100 index 1 > PCI: 00:01.0 resource base ff800000 size 800000 align 0 gran 0 > limit 0 flags d0000200 index 2 > PCI: 00:01.1 > PCI: 00:01.1 resource base 5840 size 10 align 4 gran 4 limit adff > flags 60000100 index 20 > PCI: 00:01.3 > PCI: 00:01.3 resource base e400 size 40 align 0 gran 0 limit ffff > flags d0000100 index 1 > PCI: 00:01.3 resource base f00 size 10 align 0 gran 0 limit ffff > flags d0000100 index 2 > PCI: 00:02.0 > PCI: 00:02.0 resource base fc000000 size 2000000 align 25 gran 25 > limit febfffff flags 60001200 index 10 > PCI: 00:02.0 resource base fe050000 size 1000 align 12 gran 12 > limit febfffff flags 60000200 index 14 > PCI: 00:02.0 resource base fe040000 size 10000 align 16 gran 16 > limit febfffff flags 60002200 index 30 > PCI: 00:03.0 > PCI: 00:03.0 resource base fe000000 size 20000 align 17 gran 17 > limit febfffff flags 60000200 index 10 > PCI: 00:03.0 resource base 5800 size 40 align 6 gran 6 limit adff > flags 60000100 index 14 > PCI: 00:03.0 resource base fe020000 size 20000 align 17 gran 17 > limit febfffff flags 60002200 index 30 > Done allocating resources. > Enabling resources... > PCI: 00:00.0 cmd <- 00 > PCI: 00:01.0 cmd <- 00 > PCI: 00:01.1 cmd <- 01 > PCI: 00:01.3 cmd <- 00 > PCI: 00:02.0 cmd <- 03 > PCI: 00:03.0 cmd <- 03 > done. > Initializing devices... > Root Device init > CPU_CLUSTER: 0 init > Initializing CPU #0 > CPU: vendor Intel device 633 > CPU: family 06, model 03, stepping 03 > CPU #0 initialized > PCI: 00:00.0 init > Keyboard init... > Assigning IRQ 10 to 0:1.3 > i8259_configure_irq_trigger: current interrupts are 0x0 > i8259_configure_irq_trigger: try to set interrupts 0x400 > Assigning IRQ 11 to 0:3.0 > i8259_configure_irq_trigger: current interrupts are 0x400 > i8259_configure_irq_trigger: try to set interrupts 0xc00 > PCI: 00:01.0 init > RTC Init > PCI: 00:01.1 init > IDE: Primary IDE interface: on > IDE: Secondary IDE interface: on > IDE: Access to legacy IDE ports: off > PCI: 00:02.0 init > PCI: 00:03.0 init > Devices initialized > Show all devs...After init. > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > APIC: 00: enabled 1 > DOMAIN: 0000: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:01.1: enabled 1 > PCI: 00:01.3: enabled 1 > PCI: 00:02.0: enabled 1 > PCI: 00:03.0: enabled 1 > CPU: 00: enabled 1 > CBMEM region 3fee0000-3fffffff (cbmem_check_toc) > Adding CBMEM entry as no. 3 > Moving GDT to 3fee0600...ok > Finalize devices... > Devices finalized > Copying Interrupt Routing Table to 0x000f0000... done. > Adding CBMEM entry as no. 4 > Copying Interrupt Routing Table to 0x3fee0800... done. > PIRQ table: 128 bytes. > Adding CBMEM entry as no. 5 > ACPI: Writing ACPI tables at 3fee1800. > ACPI: * HPET > ACPI: added table 1/32, length now 40 > ACPI: * MADT > ACPI: added table 2/32, length now 44 > ACPI: * MCFG > ACPI: added table 3/32, length now 48 > ACPI: * FACS > ACPI: * DSDT @ 3fee1b20 Length fa0 > ACPI: * FADT > ACPI: added table 4/32, length now 52 > ACPI: * SSDT > Found 1 CPU(s). > ACPI: added table 5/32, length now 56 > current = 3fee2c00 > ACPI: done. > ACPI tables: 5120 bytes. > Adding CBMEM entry as no. 6 > smbios_write_tables: 3feecc00 > Root Device (Emulation QEMU x86 i440fx/piix4) > CPU_CLUSTER: 0 (QEMU Northbridge i440fx) > APIC: 00 (unknown) > DOMAIN: 0000 (QEMU Northbridge i440fx) > PCI: 00:00.0 (QEMU Northbridge i440fx) > PCI: 00:01.0 (Intel 82371FB/SB/MX/AB/EB/MB Southbridge) > PCI: 00:01.1 (Intel 82371FB/SB/MX/AB/EB/MB Southbridge) > PCI: 00:01.3 (Intel 82371FB/SB/MX/AB/EB/MB Southbridge) > PCI: 00:02.0 (unknown) > PCI: 00:03.0 (unknown) > CPU: 00 (unknown) > SMBIOS tables: 438 bytes. > Adding CBMEM entry as no. 7 > Adding CBMEM entry as no. 8 > Writing table forward entry at 0x00000500 > Wrote coreboot table at: 00000500, 0x10 bytes, checksum ebdf > Table forward entry ends at 0x00000528. > ... aligned to 0x00001000 > Writing coreboot table at 0x3ffed400 > rom_table_end = 0x3ffed400 > ... aligned to 0x3fff0000 > 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES > 1. 0000000000001000-000000000009ffff: RAM > 2. 00000000000c0000-000000003fedffff: RAM > 3. 000000003fee0000-000000003fffffff: CONFIGURATION TABLES > 4. 00000000ff800000-00000000ffffffff: RESERVED > Wrote coreboot table at: 3ffed400, 0x1f0 bytes, checksum 9a59 > coreboot table: 520 bytes. > FREE SPACE 0. 3fff5400 0000ac00 > CAR GLOBALS 1. 3fee0200 00000200 > ROMSTAGE 2. 3fee0400 00000200 > GDT 3. 3fee0600 00000200 > IRQ TABLE 4. 3fee0800 00001000 > ACPI 5. 3fee1800 0000b400 > SMBIOS 6. 3feecc00 00000800 > ACPI RESUME 7. 3feed400 00100000 > COREBOOT 8. 3ffed400 00008000 > CBFS: located payload @ fffdadb8, 52477 bytes. > Loading segment from rom address 0xfffdadb8 > code (compression=1) > New segment dstaddr 0xe6b30 memsize 0x194d0 srcaddr 0xfffdadf0 filesize > 0xccc5 > (cleaned up) New segment addr 0xe6b30 size 0x194d0 offset 0xfffdadf0 > filesize 0xccc5 > Loading segment from rom address 0xfffdadd4 > Entry Point 0x000fc7a8 > Bounce Buffer at 3fe87000, 360560 bytes > Loading Segment: addr: 0x00000000000e6b30 memsz: 0x00000000000194d0 > filesz: 0x000000000000ccc5 > lb: [0x0000000000100000, 0x000000000012c038) > Post relocation: addr: 0x00000000000e6b30 memsz: 0x00000000000194d0 > filesz: 0x000000000000ccc5 > using LZMA > [ 0x000e6b30, 00100000, 0x00100000) <- fffdadf0 > dest 000e6b30, end 00100000, bouncebuffer 3fe87000 > Loaded segments > Jumping to boot code at 000fc7a8 > CPU0: stack: 00127000 - 00128000, lowest used address 00127b3c, stack > used: 1220 bytes > entry = 0x000fc7a8 > lb_start = 0x00100000 > lb_size = 0x0002c038 > buffer = 0x3fe87000 > Start bios (version rel-1.7.2.1-0-g88cb66e-20140313_103801-lexkde-desktop) > Found mainboard Emulation QEMU x86 i440fx/piix4 > Ram Size=0x3fee0000 (0x0000000000000000 high) > Relocating low data from 0x000e73e0 to 0x000ef790 (size 2153) > Relocating init from 0x000e7c49 to 0x3fec6070 (size 40555) > Found CBFS header at 0xfffffc30 > CPU Mhz=2674 > Found 6 PCI devices (max PCI bus is 00) > Found 1 cpu(s) max supported 1 cpu(s) > Copying PIR from 0x3fee0800 to 0x000fdb70 > Copying ACPI RSDP from 0x3fee1800 to 0x000fdb40 > Copying SMBIOS entry point from 0x3feecc00 to 0x000fdb20 > Scan for VGA option rom > Running option rom at c000:0003 > Turning on vga text mode console > SeaBIOS (version rel-1.7.2.1-0-g88cb66e-20140313_103801-lexkde-desktop) > Found 1 lpt ports > Found 1 serial ports > ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9) > ATA controller 2 at 170/374/0 (irq 15 dev 9) > ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (8000 MiBytes) > Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0 > DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD] > Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0 > PS2 keyboard initialized > All threads complete. > Scan for option roms > Running option rom at c900:0003 > pmm call arg1=1 > pmm call arg1=0 > pmm call arg1=1 > pmm call arg1=0 > Searching bootorder for: /pci@i0cf8/*@3 > > Press F12 for boot menu. > > Searching bootorder for: HALT > drive 0x000fdad0: PCHS=16253/16/63 translation=lba LCHS=1019/255/63 > s=16384000 > Space available for UMB: 000ca000-000ee800 > Returned 65536 bytes of ZoneHigh > e820 map has 6 items: > 0: 0000000000000000 - 000000000009fc00 = 1 RAM > 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED > 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > 3: 0000000000100000 - 000000003fee0000 = 1 RAM > 4: 000000003fee0000 - 0000000040000000 = 2 RESERVED > 5: 00000000ff800000 - 0000000100000000 = 2 RESERVED > enter handle_19: > NULL > Booting from DVD/CD... > Device reports MEDIUM NOT PRESENT > scsi_is_ready returned -1 > Boot failed: Could not read from CDROM (code 0003) > enter handle_18: > NULL > Booting from Hard Disk... > Booting from 0000:7c00 > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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