coreboot December 2013

coreboot@coreboot.org

40 participants
108 discussions

Re: [coreboot] coreboot on amd A85 can't work

by 陈军根

hello,David: I turn on the debug message and save the message to file(minicom4.cap in attachment) ,I'm a newer with coreboot, and I can't find what's wrong with the DIMM,would you kindly look this document? And which type of CPU is in your booted ok mainboard? thank you very much ------------------ Original ------------------ From: "David Hubbard"<david.c.hubbard+coreboot(a)gmail.com>; Date: Tue, Dec 17, 2013 05:56 AM To: "Idwer Vollering"<vidwer(a)gmail.com>; Cc: "coreboot"<coreboot(a)coreboot.org>; "陈军根"<cjg(a)bolod.net>; Subject: Re: [coreboot] coreboot on amd A85 can't work I am also very familiar with that particular message. I had a failing CPU and I ended up replacing parts until it booted ok. Like Idwer said: it is not able to initialize any DDR3 RAM. There is a #define that will turn on verbose output about the DDR3 link training if the Vendor BIOS (from Asus) thinks the memory is ok. David

7 years, 9 months

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

by Carl-Daniel Hailfinger

Am 21.12.2013 00:37 schrieb David Hendricks: > On Fri, Dec 20, 2013 at 3:12 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> To expand on this answer, it's going to be just about impossible, >> going forward, to become blob-free on any popular platform. I can go >> into more detail if you want to know the particulars, but there's so >> many places in our systems containing blobs, far more than in 2000, >> and as fast as we seem to stamp them out, new blobs crop up. Indeed. A few years ago nobody could have predicted that all USB 3.0 controllers require firmware (arguably because the silicon is too crappy to work well in the real world). >> Not possible on any popular ARM products of which I am aware (e.g. >> most of chips have a ROM in the CPU mask which is closed and not >> replaceable); definitely not an option on anything new from Intel. And >> it's really a matter of a tradeoff. The Chromebooks come with blobs, >> it is true; but the EC is blob-free. This may be a dumb question, but is the Chromebook EC present in all Chromebooks, and is that particular EC also available for non-Chromebook production? I see some vendors offering both Chromebooks and AMD-based laptops. It would be interesting to check whether there is a possible synergy or cross-device pollination. >> You can get AMD-based laptops, >> maybe with coreboot, and they'll come with a closed EC with blobs. The >> wonderful work on the X60 and X201 has gone very far, but the EC blob >> remains. It's a really hard problem! > I think it's important to keep the scope of these blobs in mind. The BL1 > blob used on the Exynos5xxx chips (like on the Samsung XE303C12 > Chromebook), for example, is small (~8K) and mostly exists to just load the > next phase. Contrast that with the multi-megabyte management engine blob on > Intel platforms that runs on its own microcontroller and has unfettered > access to DRAM and networking resources. > > For ECs, the attack vector to worry about is key logging but at least that > can be mitigated if you can read the EC firmware and verify its contents > like we do on Chromebooks. But of course simply reading the EC firmware on > a typical laptop can be a challenge... The big question is why someone doesn't want to have blobs in the system: 1. Freedom: The FSF/Stallman say that ROMs are hardware and thus the "software" aspect of free software does not apply, i.e. closed source ROMs are OK. Some people only care about freedom if the code runs on the main CPU, others want all software to be free, including Wifi adapter firmware and DVD drive firmware. 2. Fixability: The ability to fix software and the ability to work around hardware bugs in software. 3. Information Security: Any blob is an undefined hole in the threat model / attack surface. Those undefined holes should be in places where they have the least impact on your security targets. I used to think that reasons 1+2 are key, but nowadays I know that reason 3 is where the big money is. The defense sector does not care about free software or fixability, but they do care very much about availability, confidentiality and integrity of the systems used in critical environments. Short summary of the impact of evil blobs from an information security perspective: For USB3/Wifi/DVD/graphics firmware on devices with DMA capability, an IOMMU is a reasonably simple, safe and sane way to lock them in. The remaining impact of an attack via those devices is mostly on availability. For CPU microcode, the usual argument is that it is very limited in size, making it very difficult to mess with things. Crypto-related instructions come to mind as possible target, and for that reason some certification bodies don't trust AES intrinsincs and certify only manually coded crypto. For EC firmware, it depends very much on whether the EC has access to system resources. An EC without DMA capability and without data access to any device can compromise availability (let the battery explode, switch off the machine or components). An EC managing keyboard/touchpad/mouse has the additional option of compromising integrity of keyboard/mouse input and (via a side channel) confidentiality of keyboard/mouse input. For devices with unrestricted DMA access to memory and/or control of the main CPU (Raspberry Pi graphics, Intel Management Engine), all bets are off. For the main CPU, running an evil blob at a high privilege level (e.g. as part of the firmware) compromises everything. >> I think the idea of creating blob-free systems continues to be a >> wonderful idea, one that I'd love to see happen some day. Quoting from another thread: > Am 20.11.2013 16:23 schrieb ron minnich: >> To do a laptop port you really need to interact with an EC. The EC has >> been a problem for years. >> If you want a sane EC (i.e. 32-bit, not some 8-bit POS emulating an >> 8051) and you want open source software for that EC and you want >> coreboot ... you're going to get a chromebook. And those three things, >> as we have learned many times, are pretty essential to a port, unless >> you want to spend 3 or more years on the port. >> >> 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. Is that offer still valid? I hope to have an AMD-based laptop model with long shelf life to recommend by early January. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 years, 9 months

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

by David Hendricks

On Fri, Dec 20, 2013 at 3:12 PM, ron minnich <rminnich(a)gmail.com> wrote: > To expand on this answer, it's going to be just about impossible, > going forward, to become blob-free on any popular platform. I can go > into more detail if you want to know the particulars, but there's so > many places in our systems containing blobs, far more than in 2000, > and as fast as we seem to stamp them out, new blobs crop up. > > Not possible on any popular ARM products of which I am aware (e.g. > most of chips have a ROM in the CPU mask which is closed and not > replaceable); definitely not an option on anything new from Intel. And > it's really a matter of a tradeoff. The Chromebooks come with blobs, > it is true; but the EC is blob-free. You can get AMD-based laptops, > maybe with coreboot, and they'll come with a closed EC with blobs. The > wonderful work on the X60 and X201 has gone very far, but the EC blob > remains. It's a really hard problem! > I think it's important to keep the scope of these blobs in mind. The BL1 blob used on the Exynos5xxx chips (like on the Samsung XE303C12 Chromebook), for example, is small (~8K) and mostly exists to just load the next phase. Contrast that with the multi-megabyte management engine blob on Intel platforms that runs on its own microcontroller and has unfettered access to DRAM and networking resources. For ECs, the attack vector to worry about is key logging but at least that can be mitigated if you can read the EC firmware and verify its contents like we do on Chromebooks. But of course simply reading the EC firmware on a typical laptop can be a challenge... > > At this point it's harder and harder to escape the Blob. It eats you > alive! http://www.youtube.com/watch?v=TdUsyXQ8Wrs > > I think the idea of creating blob-free systems continues to be a > wonderful idea, one that I'd love to see happen some day. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

7 years, 9 months

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

by ron minnich

To expand on this answer, it's going to be just about impossible, going forward, to become blob-free on any popular platform. I can go into more detail if you want to know the particulars, but there's so many places in our systems containing blobs, far more than in 2000, and as fast as we seem to stamp them out, new blobs crop up. Not possible on any popular ARM products of which I am aware (e.g. most of chips have a ROM in the CPU mask which is closed and not replaceable); definitely not an option on anything new from Intel. And it's really a matter of a tradeoff. The Chromebooks come with blobs, it is true; but the EC is blob-free. You can get AMD-based laptops, maybe with coreboot, and they'll come with a closed EC with blobs. The wonderful work on the X60 and X201 has gone very far, but the EC blob remains. It's a really hard problem! At this point it's harder and harder to escape the Blob. It eats you alive! http://www.youtube.com/watch?v=TdUsyXQ8Wrs I think the idea of creating blob-free systems continues to be a wonderful idea, one that I'd love to see happen some day. ron

7 years, 9 months

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

by Patrick Georgi

Am Freitag, den 20.12.2013, 17:17 +0000 schrieb Sam Kuper: > At the present time, are any of the Chromebooks operable (i.e. all > basic functions working, except 3D which I don't care about) without > the need for binary BLOBs in drivers or firmware? No.

7 years, 9 months

Are any Chromebooks able to run fully libre?

by Sam Kuper

Dear Coreboot folks, At the present time, are any of the Chromebooks operable (i.e. all basic functions working, except 3D which I don't care about) without the need for binary BLOBs in drivers or firmware? If so, which Chromebook(s)? Thank you, Sam P.S. I am new here, so if you feel this is the wrong place to ask my question, or if I have overlooked a resource that yields the answer straightforwardly, please set me straight.

7 years, 9 months

Overclocking AMD Trinity processors

by Prop 395

I want to adjust the bus/clock multiplier on a Trinity processor with Coreboot, has anyone had any experience with this or overclocking processors in general with Coreboot? Where would I start looking in the source to make these modifications? I'm sure I am not the first to want to do this with Coreboot :)

7 years, 9 months

Asus M2V-MX SE: Interrupt issues

by Paul Menzel

Dear coreboot folks, finally I was able to test coreboot (master with SeaBIOS) on my Asus M2V-MX SE. Unfortunately GNU/Linux does not get to the LUKS passphrase prompt. [ 0.010581] ACPI: Unable to load the System Description Tables pnp call arg1=0 [ 0.136009] PnPBIOS: dev_node_info: function not supported on this system [ 0.140001] PnPBIOS: Unable to get node info. Aborting. [ 0.734938] uhci_hcd 0000:00:10.0: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.0 setup! [ 0.736070] uhci_hcd 0000:00:10.0: init 0000:00:10.0 fail, -19 [ 0.740071] ehci-pci 0000:00:10.4: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.4 setup! [ 0.744062] ehci-pci 0000:00:10.4: init 0000:00:10.4 fail, -19 [ 0.761636] uhci_hcd 0000:00:10.1: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.1 setup! [ 0.764067] uhci_hcd 0000:00:10.1: init 0000:00:10.1 fail, -19 [ 0.772078] uhci_hcd 0000:00:10.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.2 setup! [ 0.776044] uhci_hcd 0000:00:10.2: init 0000:00:10.2 fail, -19 [ 0.793897] uhci_hcd 0000:00:10.3: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.3 setup! [ 0.796079] uhci_hcd 0000:00:10.3: init 0000:00:10.3 fail, -19 pnp call arg1=5 [ 31.841109] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 31.848224] ata4.00: failed command: READ DMA [ 31.852644] ata4.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 31.852644] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 31.867303] ata4.00: status: { DRDY } Passing `acpi=off` I got a little further but there are still SATA issues. Linux reports the following. [ 1.316609] sata_via 0000:00:0f.0: can't find IRQ for PCI INT B; please try using pci=biosirq [ 1.320966] via_rhine: v1.10-LK1.5.1 2010-10-09 Written by Donald Becker [ 1.324122] usbcore: registered new device driver usb [ 1.328938] sata_via 0000:00:0f.0: routed to hard irq line 0 [ 1.340738] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.344646] uhci_hcd: USB Universal Host Controller Interface driver [ 1.348418] ehci-pci: EHCI PCI platform driver [ 1.357184] ------------[ cut here ]------------ [ 1.360096] WARNING: CPU: 0 PID: 75 at /build/linux-tAcKXn/linux-3.11.10/drivers/ata/libata-core.c:6234 ata_host_activate+0xeb/0xf0 [libata]() [ 1.364064] Modules linked in: ehci_pci(+) uhci_hcd(+) ehci_hcd via_rhine(+) pata_via(+) sata_via(+) mii libata usbcore usb_common scsi_mod [ 1.380068] CPU: 0 PID: 75 Comm: modprobe Not tainted 3.11-2-686-pae #1 Debian 3.11.10-1 [ 1.384065] Hardware name: , BIOS [ 1.387697] 00000009 c13e5bc3 00000000 c1049d8e c14ac25c 00000000 0000004b f8478b20 [ 1.396066] 0000185a f84641fb f84641fb f75fd1cc f8471ed0 00000000 f8274560 c1049e4b [ 1.404317] 00000009 00000000 f84641fb f75fd1cc f7496000 c122854f f7707d1f 00000080 [ 1.412315] Call Trace: [ 1.414828] [<c13e5bc3>] ? dump_stack+0x3e/0x4e [ 1.416072] [<c1049d8e>] ? warn_slowpath_common+0x7e/0xa0 [ 1.420074] [<f84641fb>] ? ata_host_activate+0xeb/0xf0 [libata] [ 1.424074] [<f84641fb>] ? ata_host_activate+0xeb/0xf0 [libata] [ 1.428074] [<f8471ed0>] ? ata_bmdma_port_intr+0xf0/0xf0 [libata] [ 1.432071] [<c1049e4b>] ? warn_slowpath_null+0x1b/0x20 [ 1.436074] [<f84641fb>] ? ata_host_activate+0xeb/0xf0 [libata] [ 1.440072] [<c122854f>] ? pcibios_set_master+0x2f/0xb0 [ 1.444073] [<f8272734>] ? svia_init_one+0x2a4/0x5a7 [sata_via] [ 1.448073] [<c13ed7f6>] ? notifier_call_chain+0x46/0x60 [ 1.452074] [<c12dafc5>] ? __pm_runtime_resume+0x45/0x60 [ 1.456073] [<c122a083>] ? pci_device_probe+0x63/0xb0 [ 1.460073] [<c12d1c30>] ? __device_attach+0x30/0x30 [ 1.464072] [<c12d1a74>] ? driver_probe_device+0x54/0x1e0 [ 1.468073] [<c1229f5f>] ? pci_match_device+0xf/0xa0 [ 1.472073] [<c12d1ca1>] ? __driver_attach+0x71/0x80 [ 1.476073] [<c12d02ef>] ? bus_for_each_dev+0x3f/0x70 [ 1.480073] [<c12d1676>] ? driver_attach+0x16/0x20 [ 1.484074] [<c12d1c30>] ? __device_attach+0x30/0x30 [ 1.488074] [<c12d1357>] ? bus_add_driver+0x197/0x230 [ 1.492075] [<c1229e40>] ? store_new_id+0x110/0x110 [ 1.496075] [<c12d21c3>] ? driver_register+0x63/0x120 [ 1.500076] [<c108ecdd>] ? ktime_get+0x4d/0xe0 [ 1.504075] [<f82d9000>] ? 0xf82d8fff [ 1.508076] [<c100205a>] ? do_one_initcall+0x5a/0x150 [ 1.512075] [<f82d9000>] ? 0xf82d8fff [ 1.515879] [<c10428d8>] ? set_memory_nx+0x58/0x60 [ 1.516076] [<c10a0c04>] ? load_module+0x1924/0x2120 [ 1.520078] [<c10a1476>] ? SyS_init_module+0x76/0xa0 [ 1.524077] [<c13ea1d7>] ? syscall_call+0x7/0xb [ 1.528075] ---[ end trace ab2b1229e957e6e0 ]--- [ 1.539612] scsi0 : sata_via [ 1.540195] scsi1 : sata_via [ 1.551726] ata1: SATA max UDMA/133 cmd 0x28a0 ctl 0x28b0 bmdma 0x2880 [ 1.552083] ata2: SATA max UDMA/133 cmd 0x28a8 ctl 0x28b4 bmdma 0x2888 [ 1.566861] scsi2 : pata_via [ 1.572933] scsi3 : pata_via [ 1.575953] ata3: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0x2890 irq 14 [ 1.576085] ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x2898 irq 15 [ 1.586723] via-rhine 0000:00:12.0: can't find IRQ for PCI INT A; please try using pci=biosirq [ 1.588332] via-rhine 0000:00:12.0 eth0: VIA Rhine II at 0x12400, 00:00:de:ad:be:ef, IRQ 0 [ 1.596767] via-rhine 0000:00:12.0 eth0: MII PHY found at address 1, status 0x7949 advertising 0de1 Link 0000 [ 1.607921] uhci_hcd 0000:00:10.0: can't find IRQ for PCI INT A; please try using pci=biosirq [ 1.608087] uhci_hcd 0000:00:10.0: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.0 setup! [ 1.612084] uhci_hcd 0000:00:10.0: init 0000:00:10.0 fail, -19 [ 1.625665] ehci-pci 0000:00:10.4: can't find IRQ for PCI INT C; please try using pci=biosirq [ 1.628090] ehci-pci 0000:00:10.4: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.4 setup! [ 1.632084] ehci-pci 0000:00:10.4: init 0000:00:10.4 fail, -19 [ 1.654457] uhci_hcd 0000:00:10.1: can't find IRQ for PCI INT B; please try using pci=biosirq [ 1.656091] uhci_hcd 0000:00:10.1: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.1 setup! [ 1.660086] uhci_hcd 0000:00:10.1: init 0000:00:10.1 fail, -19 [ 1.681390] uhci_hcd 0000:00:10.2: can't find IRQ for PCI INT C; please try using pci=biosirq [ 1.684094] uhci_hcd 0000:00:10.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.2 setup! [ 1.688088] uhci_hcd 0000:00:10.2: init 0000:00:10.2 fail, -19 [ 1.692691] uhci_hcd 0000:00:10.3: can't find IRQ for PCI INT D; please try using pci=biosirq [ 1.696093] uhci_hcd 0000:00:10.3: Found HC with no IRQ. Check BIOS/PCI 0000:00:10.3 setup! [ 1.700089] uhci_hcd 0000:00:10.3: init 0000:00:10.3 fail, -19 [ 1.760100] ata1: SATA link down 1.5 Gbps (SStatus 0 SControl 300) [ 1.972108] ata2: SATA link up 1.5 Gbps (SStatus 123 SControl 300) [ 1.984117] Switched to clocksource tsc [ 2.140327] ata2.00: ATA-8: WDC WD20EARS-60MVWB0, 51.0AB51, max UDMA/100 [ 2.147082] ata2.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 0/32) [ 2.160322] ata2.00: configured for UDMA/100 [ 2.164788] scsi 1:0:0:0: Direct-Access ATA WDC WD20EARS-60M 51.0 PQ: 0 ANSI: 5 [ 2.337648] sd 1:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 2.345494] sd 1:0:0:0: [sda] 4096-byte physical blocks [ 2.351152] sd 1:0:0:0: [sda] Write Protect is off [ 2.356082] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA pnp call arg1=5 [ 32.453347] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05 [ 32.859471] ata2: lost interrupt (Status 0x50) [ 32.863997] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 32.871098] ata2.00: failed command: READ DMA [ 32.875513] ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 32.875513] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 32.890173] ata2.00: status: { DRDY } [ 32.895147] ata2: soft resetting link [ 33.131698] ata2.00: configured for UDMA/100 [ 33.136030] ata2.00: device reported invalid CHS sector 0 [ 33.141493] ata2: EH complete [ 63.882854] ata2: lost interrupt (Status 0x50) [ 63.887380] ata2.00: limiting speed to UDMA/66:PIO4 [ 63.892316] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 63.899421] ata2.00: failed command: READ DMA [ 63.903836] ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 63.903836] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 63.918498] ata2.00: status: { DRDY } [ 63.922224] ata2: soft resetting link [ 64.127077] ata2.00: configured for UDMA/66 [ 64.131321] ata2.00: device reported invalid CHS sector 0 [ 64.136786] ata2: EH complete [ 94.938232] ata2: lost interrupt (Status 0x50) [ 94.942740] ata2.00: limiting speed to UDMA/33:PIO4 [ 94.947672] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen [ 94.954771] ata2.00: failed command: READ DMA [ 94.959185] ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in [ 94.959185] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 94.973847] ata2.00: status: { DRDY } [ 94.977570] ata2: soft resetting link [ 95.198465] ata2.00: configured for UDMA/33 [ 95.202705] ata2.00: device reported invalid CHS sector 0 [ 95.208166] ata2: EH complete Please find the log files attached. Thanks, Paul

7 years, 9 months

Fwd: coreboot on amd A85 can't work

by Idwer Vollering

Forwarding the reply where 陈军根 <cjg(a)bolod.net> informed me of his findings, see below. ---------- Forwarded message ---------- From: 陈军根 <cjg(a)bolod.net> Date: 2013/12/17 Subject: Re: [coreboot] coreboot on amd A85 can't work To: Idwer Vollering <vidwer(a)gmail.com> Idwer: the vendor(ASUS) EFI software can detect the DIMM,and I power cycle after moving from EFI,to coreboot. I will try a kingston ddr3 1333 tomorrow. thank you very much ! ------------------ Original ------------------ From: "Idwer Vollering"<vidwer(a)gmail.com>; Date: Tue, Dec 17, 2013 05:00 AM To: "coreboot"<coreboot(a)coreboot.org>; Cc: "陈军根"<cjg(a)bolod.net>; Subject: Re: [coreboot] coreboot on amd A85 can't work 2013/12/13 陈军根 <cjg(a)bolod.net>: > Dear all: > I run coreboot in ASUS F2A85-MLE CPU is A10-5800k, kingston ddr3 > 1600(kvr1600d3n9/4g),coreboot halt at "assertion Failed:file > 'src/vendorcode/amd/agesa/f15tn/proc/mem/main/mmexcludedimm.c',line 236". I > don't know how to do, can anyone help me? > thanks very much! This means that agesa code can't find a ddr3 module, does the vendor EFI software detect the DIMM? Did you power cycle after moving from EFI to coreboot? >From the code in src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmExcludeDimm.c on and around line 236: // if all dimms on all nodes are excluded, do fatal exit if (RefPtr->SysLimit == 0) { PutEventLog (AGESA_FATAL, MEM_ERROR_NO_DIMM_FOUND_ON_SYSTEM, 0, 0, 0, 0, &NBPtr->MemPtr->StdHeader); SetMemError (AGESA_FATAL, NBPtr[BSP_DIE].MCTPtr); ASSERT (FALSE); }

7 years, 9 months

coreboot on amd A85 can't work

by 陈军根

Dear all: I run coreboot in ASUS F2A85-MLE CPU is A10-5800k, kingston ddr3 1600(kvr1600d3n9/4g),coreboot halt at "assertion Failed:file 'src/vendorcode/amd/agesa/f15tn/proc/mem/main/mmexcludedimm.c',line 236". I don't know how to do, can anyone help me? thanks very much!

7 years, 9 months

← Newer
1
2
3
4
5
6
7
...
11
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2013