coreboot July 2016

coreboot@coreboot.org

47 participants
135 discussions

by A. Veek

2 years, 6 months

Re: [coreboot] No VGA output on e350m1 after flashing. what to do?

by Reiner Luett

Hi! On 30.06.2013 19:28, Christian Weinz wrote: > Maybe I didn't include the VGA option in the make menuconfig process. > How can I solve this problem? You need to add the VGA Option ROM (VGA BIOS -> Add VGA BIOS image). I've extracted it from the UEFI, but you also could use these: http://www.coreboot.org/index.php?title=ASRock_E350M1&oldid=11114 at the end of the page or you also may be able to use the default AMD fam14 (Persimmon) vbios. You will need to agree to the click through: http://wwwd.amd.com/support/vbioslic.nsf/userverify?openform http://www.coreboot.org/AMD_DB-FT1_PERSIMMON It's a pity, that bios_extract didn't work for now. You could use the AMI Aptio EFI MMTool with wine: http://win-lite.de/benutzer/fernando/BIOS-Tools/AMI_Aptio_EFI_MMTool_v4.50.… You need to extract OntarioEFIVbios with PCI ID 1002,9802 as Option ROM. Regards, Reiner --

3 years, 9 months

ASUS KCMA-D8 workstation board port offer

by Timothy Pearson

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, After reviewing some of the comments on the ASUS KGPE-D16 being essentially too large of a system and too expensive for many people, and the fact that modern, blob-free systems are not really available in the mid-range arena, Raptor Engineering would like to offer to create a native initalization blob-free port for the ASUS KCMA-D8, which is essentially the KGPE-D16's ATX-compatible "little brother". We would be asking $15,000 for the port, including upstreaming to the master coreboot tree. We already have extensive experience with these Family 10h/15h boards, and would be able to create a port of similar quality to the existing KGPE-D16 source in terms of both code quality and overall functionality. If this is something you might be interested in please let me know. We are able to accept multiple payments from various sources for the same project (within limits), so if this is something your local Linux groups or similar might be interested in we should be able to keep the cost on any one individual or organization to a reasonable level. Thank you for your consideration, - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWQROpAAoJEK+E3vEXDOFbR2cH/3FTqGFH+cU/HVrBUPcoKjii h9OC7SGeXdyoLZvob/YayG+g47Yppkg2um4pAC7dmGl/OXtkGh13hlsrQ8BNiYcz g0kQUdNKYh9dmBC3YnlxU6a7psh473TdyuLILrl7/8WgI8DZnRtjy62Oo5k6XAKW jfYb/bGC8I3tArYrgQDmFxz2dOejuTZit56I+mbWNtvbuQov2BDmrPPMLRuEvG3M QHCAo/Pjaajzl4rmtrgu0GHcxHsgAnJcnrcPkFYeSDKt7QxSTNOB6NqhcnYdh1SY RiA5Z/3enuDs+XNhS+6qMeKOcrEuf+Ccs7sGsgq5tWm20JA+bBoByvrXhHqVUxU= =DKfR -----END PGP SIGNATURE-----

4 years, 4 months

Re: [coreboot] F2A-85M: Different VGA BIOS needed after CPU Upgrade?

by Daniel Kulesz

Hi John, > It sounds to me as though the PCI id's of the graphics card for the > upgraded CPU may be different (I could be totally wrong about that, so I > defer to others on the list if I'm barking up the wrong tree) and your > coreboot image may need to be updated accordingly. Of course, it could > also be the video BIOS that's the problem as you've suggested. Thank you for the hint. I inspected that, but the PCI-IDs actually look the same: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993] (A4-5300) and 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8670D] (prog-if 00 [VGA controller]) (A10-6700) Looks like the VGA BIOS is really different: # diff vgabios_a4-5300.bin vgabios_a10_6700.bin Binary files vgabios_a4-5300.bin and vgabios_a10_6700.bin differ Guess I will have to to "update" the VGA BIOS then. Cheers, Daniel > > Hi Daniel, > > > Kind Regards, > > John. > > > On 28/06/16 09:24, Daniel Kulesz via coreboot wrote: > > Hi folks, > > > > I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 (Richland). The board had Coreboot installed before with the VGA BIOS extracted from the A4-5300. However, I did not get any video output when trying to boot after the upgrade, so I replaced the flash chip with a backup with the vendor BIOS that works. > > > > Is it likely that the A10-6700 needs a different VGA BIOS or does this this rather look like a different issue? I don't want to experiment too much because the BIOS chips are hardware-wise pretty fragile (even when using the extractor tool). > > > > Cheers, Daniel > >

4 years, 5 months

Porting coreboot on ASUS M5A78L-M LX3

by Алексей Боровиков

Hi! I need help to porting coreboot Asus M4a785m on Asus M5a78l-m lx3. I'm trying to porting coreboot on the motherboard Asus M5a78l-m lx3 (rs780l/sb710). I cannot find documentation for the northbridge rs780l. My configuration: cpu - Athlon 2 x2 220 (K10), memory - 2 + 2 Gb DDR3, video - Asus GT520, sata segate hdd 500Gb, sata asus dvd-rw. I have a positive result for the configuration with memory 2Gb and external video card Asus GT520. I can load Linux kernel 2.6. But, i have two problems: 1. I cannot load coreboot with internal graphics card (hd 3000). Coreboot stops loading and to print on console "Calling option ROM…". May be the problems with gfx configuration? 2. I cannot run Linux with memory 4Gb. Coreboot is loading, SeaBios is loading too, but Linux stop load on usb3-2 and ata1 setup. May be the problems with memory map? Please, help me. I can provide all the necessary information from the log coreboot, SeaBios and Linux. Thanks.

4 years, 10 months

Re: [coreboot] w83627 uart port is not workable with coreboot in linux

by Nico Huber

Hi Cheng, On 25.07.2016 04:33, cheng yichen wrote: > Hi all > > After i follow kontron/ktqm77 setting. I can't solve the issue. > I try to change iqr(for com1) to 5 or 6. but system can't print linux > message and minicom is not workable. Can you confirm that you see the full coreboot log on your UART? With log level >= debug, it should end with lines about loading the payload, containing a line starting with "Jumping to boot code at". If you see this line, it's unlikely to be a coreboot issue. If not, please provide a full log with highest log level. Also the output of `lspci -xxx`, `cbmem -c` and your devicetree.cb might be helpful. Another way to test the UART is to use Linux' earlycon driver, e.g. with earlycon=uart8250,io,0x3f8,115200n8 in your kernel command line. This driver is simpler than the serial8250 (it doesn't use interrupts and is closer to what coreboot's driver does). Nico > > > > dump from superiotool > Found Winbond W83627DHG-P/-PT (id=0xb0, rev=0x73) at 0x2e > Register dump: > idx 02 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > val ff b0 73 ff 00 42 00 00 ff 50 80 00 00 eb 21 00 ff > def 00 b0 NA ff 00 MM 00 MM RR 50 00 00 RR e2 21 00 00 > LDN 0x00 (Floppy) > idx 30 60 61 70 74 f0 f1 f2 f4 f5 > val 01 03 f0 06 02 8e 00 ff 00 00 > def 01 03 f0 06 02 8e 00 ff 00 00 > LDN 0x01 (Parallel port) > idx 30 60 61 70 74 f0 > val 01 03 78 07 04 3f > def 01 03 78 07 04 3f > LDN 0x02 (COM1) > idx 30 60 61 70 f0 > val 01 03 f8 04 40 > def 01 03 f8 04 00 > LDN 0x03 (COM2) > idx 30 60 61 70 f0 f1 > val 01 02 f8 03 40 00 > def 01 02 f8 03 00 00 > LDN 0x05 (Keyboard) > > > dump from dmesg > > home# dmesg | grep -i tty > [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic > root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1 > console=ttyS0,115200n8 quiet splash vt.handoff=7 > [ 0.000000] Kernel command line: > BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic > root=UUID=b2b7f7fa-b1db-4e97-941f-8aaee291f3dc ro console=tty1 > console=ttyS0,115200n8 quiet splash vt.handoff=7 > [ 0.000000] console [tty1] enabled > [ 0.000000] console [ttyS0] enabled > [ 1.637664] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [ 1.658835] serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) > is a 16550A > [ 3.412478] fbcon: Remapping primary device, fb1, to tty 1-63 > [ 44.378835] systemd[1]: Created slice system-serial\x2dgetty.slice. > [ 44.380198] systemd[1]: Created slice system-getty.slice. > > > > > > 2016-07-22 20:24 GMT+08:00 Kyösti Mälkki <kyosti.malkki(a)gmail.com>: > >> On Fri, Jul 22, 2016 at 1:14 PM, cheng yichen <blessyichen(a)gmail.com> >> wrote: >>> Hi all >>> >>> My platform is braswell SOC with W83627dhg superIO. In post stage I can >> get >>> debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart >>> port is not woarkable. I test the function by minicom but I can't receive >>> and send data. I can get uart information by dmesg command. >>> How to initial it in corebooot? >> >> Does not sound like a coreboot issue to me. >> >> Do you have CTS/RTS hardware handshake disabled in minicom >> configuration? If you directed kernel console to serial port, you >> should not (cannot) use the port for user apps. >> >> HTH, >> Kyösti >> > > >

4 years, 10 months

Re: [coreboot] re-enabling boot for ChromeOS

by Matt DeVillier

Julius, wouldn't he also need gbb_utility to set the flags, in addition to (CrOS) flashrom to be able to read/write just the GBB region? That's why I suggested he use my ChromeOS Firmware Utility Script, since it would automatically download the required binaries as well as ensure the flags were set to a sane value. But as you, no need to change the flags as set to boot ChromeOS cheers, Matt On 7/20/2016 5:56 PM, Julius Werner wrote: > set_gbb_flags.sh is just a bash script and will run on any system that > has flashrom installed (which it calls). > > With the 0x489 flags you should still see the Chrome OS firmware > screen ("OS verification is turned off") for 2 seconds on boot. Just > press CTRL+D during those two seconds to boot Chrome OS in developer > mode from the internal SSD. >

4 years, 10 months

Re: [coreboot] MMIO UART driver on OS

by Nico Huber

Hi, On 31.07.2016 17:07, Zheng Bao wrote: > Hi, All, > > I want to add support MMIO UART support on OS. > > I checked the file pnp_uart.asl. > > For IO UART, a device with EisaId("PNP0501") is added into DSDT, the windows can detect the COM port in device manager. > > I am wondering if MMIO UART also have that convinient feature. in theory (I've just checked the code, never tried) the Linux driver supports MMIO UARTs too if you give it the same entry (PNP0501) with a memory resource instead of the io ports. Maybe this works in other OS' too? Nico > > Or I need to build a driver for each OS? > > Thanks. > > > Joe

4 years, 10 months

Re: [coreboot] ARM Trusted Firmware build issue

by Stefan Reinauer

On 20-Jul-16 16:19, Julius Werner wrote: > Well... honestly, isn't it our fault for uprevving to a buggy > toolchain? If there was a way to write this code such that it will > result in the binary output ARM wants and works on all versions, > submitting a patch to them would be reasonable... but otherwise I can > kinda understand that they don't want to use an inferior solution > because we insist on using an assembler that doesn't know how to > assemble stuff correctly. Isn't the best solution to only uprev archs > that really need new compiler features until the GCC guys manage to > produce a stable version? Yes, I was wrong. After reading the other threads and talking with Martin, it indeed seems to be a toolchain issue. However, the new toolchain had many advantages over the previous one, and the code was not in (our) ARM TF at the time we uprevved. The maintenance burden of keeping different versions of toolchains supported for different architectures as part of the reference toolchain is imho almost always significantly higher than actually fixing the issues. (Especially if they are not time critical) Martin produced a binutils fix for the issue. Whether the binutils people will find it to be the "right" fix is still to be found out, but it seems to allow compiling the latest, unmodified ARM TF. Stefan

4 years, 10 months

MMIO UART driver on OS

by Zheng Bao

Hi, All, I want to add support MMIO UART support on OS. I checked the file pnp_uart.asl. For IO UART, a device with EisaId("PNP0501") is added into DSDT, the windows can detect the COM port in device manager. I am wondering if MMIO UART also have that convinient feature. Or I need to build a driver for each OS? Thanks. Joe

4 years, 10 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2016