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-----
1 month
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-----
1 year, 12 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
Linux 4.7 kernel payload with CoreBoot 4.4
by Trammell Hudson
The Linux 4.7 kernel payload crashes early in the boot process
with CoreBoot 4.4. I traced it to these instructions that are
finding a safe spot to decompress the rest of the kernel and
patched around it with a hard coded location:
diff -u --recursive /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S ./linux-4.7/arch/x86/boot/compressed/head_64.S
--- /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S 2016-07-24 15:23:50.000000000 -0400
+++ ./linux-4.7/arch/x86/boot/compressed/head_64.S 2016-08-05 12:07:11.399854225 -0400
@@ -340,9 +357,15 @@
1:
/* Target address to relocate to for decompression */
+#if 0
movl BP_init_size(%rsi), %ebx
subl $_end, %ebx
addq %rbp, %rbx
+#else
+ // coreboot does not populate the init_size boot param?
+ // fake it with a hard coded value
+ movl $0x97b000, %ebx
+#endif
/* Set up the stack */
leaq boot_stack_end(%rbx), %rsp
It seems that the Linux kernel bzImage is supposed to set this value,
rather than coreboot, so my comment is likely incorrect.
Dumping linux-4.7/arch/x86/boot/header.o, it looks like init_siez
is supposed to be 0xcf5000, so I wonder if %rsi is pointing to the
wrong location.
In 4.6.4 the computed address was hardcoded:
movl $LOAD_PHYSICAL_ADDR, %ebx
/* Target address to relocate to for decompression */
addl $z_extract_offset, %ebx
3e: bb 00 00 00 01 mov $0x1000000,%ebx
43: 81 c3 00 00 00 00 add $0x0,%ebx
--
Trammell
2 years, 1 month
FOSDEM 2017
by Carl-Daniel Hailfinger
Hi,
FOSDEM 2017 deadlines are soon.
Do we want to have a full developer room, a talk or just a stand?
Unfortunately I won't be able to attend, so someone else will have to be
the formal contact for organizing our stand/devroom/talk. I will help
with submitting proposals if this is desired by the person organizing
our stand/devroom/...
Who is willing to take care of our FOSDEM 2017 presence?
https://fosdem.org/2017/news/2016-07-20-call-for-participation/
Deadlines:
Developer Rooms: 9 September
Main Track Talks: 10 October
Stands: 31 October
Lightning talks: 25 November
Regards,
Carl-Daniel
2 years, 1 month
xHCI support for x86
by Pitrolle Jean-Jacques
Hello *,
I try to integrate coreboot *libpayload usb stack* in a custom binary
for x86.
I already succeed integration of *ehci* for *qemu* and *core 2 duo*
platforms.
But things seems to be not so easy for *xhci*.
When I try to run coreboot master branch (with hash 8bf3f7a) on qemu
(version 2.7.0)
with following line :
% qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -drive
if=none,id=usbstick,file=/tmp/qemu_usb.disk -usb -device
nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=usbstick
I get these output lines concerning xHCI controller (nec-usb-xhci) :
8<---
[..]
00:04.0 0194:1033.0 xHCI controller
xhci_init: regbase: 0xfe070000
xhci_init: caplen: 0x40
xhci_init: rtsoff: 0x1000
xhci_init: dboff: 0x2000
xhci_init: hciversion: 0.0
xhci_init: Unsupported xHCI version
[..]
--->8
The same result is reached with qemu-system-i386...
Is it the expected result on qemu?
I don't have any motherboard supported by coreboot, so I try a custom
binary on
a *Xeon* processor (processor D-1500).
The xHCI version is supported (hciversion: 1.0) but things turn bad when
starting
xHCI controller i.e xhci->opreg->usbcmd |= USBCMD_RS in *xhci_start* :
the program hangs...
The registers usbcmd and usbsts before this command seems to have proper
values (a usb key
is connected.)
8<---
[..]
xhci_start - usbcmd:0 - usbsts:11
[..]
--->8
This seems to be related to interrupter configuration. When I comment
out the two lines
in *xhci_reinit*
8<---
[..]
xhci->hcrreg->intrrs[0].erstba_lo = virt_to_phys(xhci->ev_ring_table);
xhci->hcrreg->intrrs[0].erstba_hi = 0;
[..]
--->8
xhci_start works as expected i.e not hangs.
But the sequence following with *NOOP* to test command ring and event
ring mechanism fails.
8<---
[..]
NOOP run #0
Transfer TRB (@0x8051700):
PTR_L 0x00000000
PTR_H 0x00000000
STATUS 0x00000000
CNTRL 0x00005c00
TL 0x0000
TDS 0x0000
C 0x0000
ISP 0x0000
CH 0x0000
IOC 0x0000
IDT 0x0000
TT 0x0017
DIR 0x0000
Command 23 (@0x8051700)
Warning: Timed out waiting for TRB_EV_CMD_CMPL.
Command ring is running
[..]
--->8
As I understand it is mandatory to have the first interrupter configure
to manage
at least one event ring (4.9.4 Event Ring Management - eXtensible Host
Controller Interface
Revision 1.1).
Does someone succeed with xHCI support for x86 board?
Did I miss something concerning xHCI configuration?
Thanks.
Have a nice day.
--
Jean-Jacques PITROLLE
Phone: +33 1 30 09 12 70
SYSGO S.A.S
2 years, 1 month
Re: [coreboot] [RFC] Explicitly use C11/GNU11
by Paul Menzel
Dear Julius,
Am Dienstag, den 29.11.2016, 14:20 -0800 schrieb Julius Werner:
> > A lot of the GNU extensions are used in our codebase, so if somebody
> > feels strongly about moving away from GNU11 to C11, the code needs to
> > be cleaned up. But that should be done in a different patch set.
>
> I'd like to explicitly object to that. There are many GNU extensions
> which are simply necessary to write sane, readable and performant code
> (e.g. to implement non-double-evaluating MIN()/MAX() macros, to
> cleanly control linking into particular sections, to get performant
> code generated for IO accessor functions, etc.). The C standard by
> itself is simply insufficient to support all systems programming use
> cases, and if we forbade GNU extensions we'd have to rewrite
> significant parts of coreboot in pure assembly and add weird, hardly
> readable workarounds for many code patterns. I don't see how this
> would be worth it just to try to get compatibility with compilers
> nobody wants to use anyway, or for some theoretical goal of "standards
> compliance" with no practical benefit. (Note that many GNU extensions
> are implicitly available even without -std=gnuXX, some of them even if
> you also enable -Werror=pedantic. But that doesn't not make them GNU
> extensions, and there'd be no reason to treat them differently from
> ones that require the -std flag. Ditching GNU extensions would mean
> that every __attribute__, every __builtin and every extended asm
> becomes illegal.)
Thank you for the elaborate explanation. I never intended to take on
that task, but if I had, you would have convinced me.
I hope using GNU11 suits everyone.
Thanks,
Paul
2 years, 1 month
Re: [coreboot] Rettungsboot
by ron minnich
OK, then someone just asked me: how long does it take to rewrite that 128
MiB vs. the 512 byte sector on the floppy. :-)
On Wed, Nov 30, 2016 at 1:18 PM ron minnich <rminnich(a)gmail.com> wrote:
> amusement value:
>
> The 512 bytes used for MBR is about .04% of the 8" floppy disk that
> shipped with the original IBM PC. For 128 MB to be that fraction of a new
> disk, the disk would have to be 256 GiB. That's about $40 worth of disk.
>
> Geez.
>
>
> On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
> zoran.stojsavljevic(a)gmail.com> wrote:
>
>> > Or do you want to do the full EFI "let's waste 128MB of *every** disk*
>> on
>> > a special FAT32 partition" madness (which still requires bootloaders to
>> > include one specific FS driver they might otherwise not want)?
>>
>> YES, you do. Accent on: "every disk" .
>>
>> Zoran
>> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner(a)chromium.org>
>> wrote:
>>
>> > To sum it up, I want something that is lean and clean enough so it could
>> be added to any bootloader. Even if that boot loader is not of the
>> let's build a tiny OS type.
>>
>> I don't really see how you could reach this goal with anything that
>> requires reading a file from the boot media? There are billions of
>> different file systems out there... do you want to require your
>> "minimal" bootloader to include drivers for all of them? (There are
>> bootloaders that don't contain any file system drivers at all, like
>> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
>> every disk on a special FAT32 partition" madness (which still requires
>> bootloaders to include one specific FS driver they might otherwise not
>> want)?
>>
>> I think if you want to do anything truly minimal and compatible with
>> everything, you can't rely on files (and you should try to rely on
>> partitions as little as possible, e.g. no full GPT parsing). Which
>> probably means putting it in the first sector. And once you have that,
>> you can create some fancy text-based format (or Go source file /
>> node.js script / whatever the cool kids use these days) to describe
>> the target sector, load address etc. of the fallback kernel... but
>> you're really just exemplifying the XKCD Igor mentioned because you've
>> just reinvented the MBR. (And let's face it... no coreboot bootloader
>> has the pull to sufficiently promote adoption of some completely new
>> fallback boot descriptor format right now, even if it doesn't require
>> a Go compiler in your bootloader.)
>>
>> So, really, I think what you want is just the MBR. It is the deadest
>> simple design possible (just load a sector and jump), it is as
>> infinitely flexible as code itself, and it coexists perfectly with all
>> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
>> software interrupt BIOS interface, but if the recovery kernel code is
>> cleverly written you really only need the disk access part (and you
>> know your bootloader already has that driver because that's how it
>> loaded the MBR in the first place). And yes, on x86 it requires real
>> mode (for non-x86 I'd just make up an as equivalent as possible system
>> with your software interrupt solution of choice), but that's a small
>> price you pay with a few files worth of shim code in exchange for
>> automatic compatibility with 35 years worth of existing BIOSes. I'd
>> say that's a better deal than any new dead-on-arrival scheme you could
>> make up out of thin air.
>>
>> (If you really can't stand the idea of BIOS interrupts and real mode,
>> I think your next best option would be to try to cram an
>> as-small-as-possible binary recovery descriptor and the real mode code
>> to parse/load/execute it together into the 446 bytes of MBR space you
>> have. This way, your new payloads can just find and parse/load/execute
>> the descriptor itself without having to provide any BIOS interface,
>> but the thing is still compatible with existing legacy BIOSes as
>> well.)
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
2 years, 1 month
