-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/19/2017 11:36 AM, Martin Roth wrote:
> Hey Merlin,
> I was taking and keeping track of the pledges for Talos, so I'd be
> happy to continue.
>
> Martin
I just wanted to bring this back up for discussion. Raptor is chipping
in funding for over half of the development work, and Martin is matching
pledges, so if there's interest in this port your contributions will go
a long way, but it still depends on community interest. Are you willing
to contribute to this development project? It is a limited time offer,
so the quicker we can reach the relatively low goal to get this work
underway the better. :-)
Thanks!
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJYijUnAAoJEK+E3vEXDOFbQKAIAKPqeHZylATs3aZXC2QeTmUG
p0bnwfU4G+0qkXEwApoYk+y8WRKEkhBsug5EvzEXw65fAAmwi4COVjUBvm2l9kUI
m3/51sfrZRpo+H8c1lXld0WiwomTGapm9FX3rqAjLZn354TOqnrfoGYoJQC+ovKm
0AYXCGN8fmWkr6nTj9Q1tWwxEXrRv48YudF8bDFZhbMjOswnagNzImQNTC6wLgnY
+7UyqBgpihc8vh3GoGuPQT1mNpAtUwv1PS8HFGnDO86zW9gWB7+xHEGBhMyy+Rys
CTNWkI15X4dy8pz6XIsqjuBNSUcgTnVVAelecdm1BfykpgSyPyOf/39JQc/O41M=
=HzeR
-----END PGP SIGNATURE-----
I am wondering as to:
* Why 6274 cpu refuses to turbo to the second turbo state with half of
the cores in use (it stops around 100mhz before the first turbo state)
* Is it possible to force enable second turbo state for all cpu cores,
assuming adequate cooling? Or is it controlled on the CPU itself?
Off topic but would rather not make another thread:
* Does NUMA ram alignment matter performance wise with only one physical
CPU? (RAM being split half and half per core set at the moment)
* Does anyone know where I could get a reasonably priced 6287SE or
6284SE? or (even better) an engineering model of 62xx?
Hi all,
Does Coreboot write to the flash chip it resides on? Can this be disabled?
Verify of the SPI bios chip fails once the unit has booted up at least once.
Best Regards,
Naveed
Naveed Ghori | Lead Firmware & Driver Engineer
DTI Group Ltd | Transit Security & Surveillance
31 Affleck Road, Perth Airport, Western Australia 6105, Australia
P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.ghori(a)dti.com.au<mailto:naveed.ghori@dti.com.au>
Visit our website www.dti.com.au<http://www.dti.com.au>
The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.
Dear coreboot folks,
Today I tried cbui [1], the new payload written by siro (Patrick) using
the single-header ANSI C GUI library *Nuklear* [2].
With QEMU there are problems when using qemu/q35, but trying it on the
Lenovo X60 it worked like a charm (I loaded it from GRUB). Please find
a picture attached.
In both halves there are some horizontal black lines. But I guess
that’s related to the native graphics initialization.
So, please test and send commits to siro.
Awesome job siro!
Thanks,
Paul
[1] https://github.com/siro20/coreboot/commits/cbui
[2] https://github.com/siro20/nuklear
Dear Julius,
Am Montag, den 27.02.2017, 13:32 -0800 schrieb Julius Werner:
> I don't think it's helpful to single out "corporate developers" as the
> black sheep that submit all the style violations. Every contributor, paid
> or hobby, new or long-time, needs to pay attention to the project
> guidelines equally. Everyone overlooks stuff some time, and it's normal
> especially for new contributors to not be quite that familiar with
> everything yet.
I certainly didn’t mean it that way. I didn’t want to single out anyone
as the black sheep. I apologize, if I offended anyone. I totally agree
with your view.
My focus on corporate developers was motivate by the following two
things.
1. Corporate developers certainly contribute most of the commits and
code.
2. I believe and assume corporations have *additional* ways to reach
“their” developers.
> Its our responsibility as reviewers (especially those of us with +2
> rights) to educate them and make sure the rules are followed before a
> patch can get submitted.
>
> That said, I do agree that we have a lot of potential in making this easier
> and more consistent for everyone involved. I think the best tool for that
> is more automated checking... like that recent idea to make Jenkins add the
> checkpatch result visibly to its Verified+1 message.
>
> I'm not sure if the "where" of the guidelines really makes much of a
> difference... maybe we should just make them more discoverable either way?
> Could we put a big orange "please ensure that this patch conforms to the
> style guidelines at ..." banner in Gerrit somewhere near the submit button?
Most people push the commits from the command line I guess, so that –
especially in the beginning – they won’t even access the Web interface?
For corporations the following ideas came to my mind. The assumption is
that in corporations people are higher to see the colleagues in person
or to be in the same building.
1. In each division there is some kind of QA person “holding the hands”
for the first commit.
2. Before somebody starts working on coreboot there is a small
introduction by a colleague already familiar with the guidelines.
3. Do for example Intel, Google or Siemens have documents (tutorials,
videos, presentations) they could share? Would it make sense to
create those?
[…]
Regarding improving the documentation, I guess everyone agrees (and
nobody wants/likes to do it). In my opinion the easiest way would be to
copy as much as possible from other project (like the Linux kernel).
Though that should be discussed separately.
Thanks,
Paul
Maybe to fix this PCIe GPU issue he just needs to edit a
./coreboot/src/device/Kconfig file?
./coreboot/src/device/Kconfig
change
config MULTIPLE_VGA_ADAPTERS
bool
default n
to
config MULTIPLE_VGA_ADAPTERS
bool
default y
and completely rebuild the coreboot
I enabled these options for my G505S laptop with both integrated/discrete
graphic, however I am not a gamer so can't notice if there is any positive
effect from this option. But maybe this option will significantly improve
the thread starter's eGPU experience? What do you think ?
