Lenovo T410 Coreboot
by A. Veek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
5 months, 1 week
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-----
2 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
> >
2 years, 4 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.
2 years, 9 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
>>
>
>
>
2 years, 9 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.
>
2 years, 9 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
2 years, 9 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
2 years, 9 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
2 years, 9 months
