-----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
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-----
On 01/10/2016 10:23 AM, ron minnich wrote:
> One thing I think you'd enjoy doing is building the qemu target, setting
> up qemu with gdb, and just watching what happens, instruction by
> instruction, as the system boots.
One exercise I liked doing was to rewrite the entire boot flow, from
reset vector to protected mode entry. Tested on qemu, put it on
hardware, nothing burned.
Alex
> ron
>
> On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
> <rafaelrodrigues.machado(a)gmail.com
> <mailto:rafaelrodrigues.machado@gmail.com>> wrote:
>
> Hi Peter and Rudolf.
> Thanks for the answers and tips. They are realy helpfull !
> I'll take a look.
>
> Rafael R. Machado
>
>
> Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz
> <mailto:r.marek@assembler.cz>> escreveu:
>
> Hi,
>
> I guess your question is more general than the coreboot related
> right?
>
> If you have a firmware image dump of the flash (not the file you
> download from
> board vendor) then yes, first location to be executed is the
> instruction located
> 16 bytes before end of the image.
>
> In coreboot see in build/ bootblock_inc.S which also has
> reset16.inc and
> entry16.inc which is a real start. Consult the Intel or AMD
> manual to see the
> CPU state after reset. The CPU starts in real mode, but CS base
> is shifted to
> last 64KB before end of 4GB address space. In general your CPU
> starts in
> compatible mode with 8086 manufactured in 1978.
>
> Thanks
> Rudolf
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
Hello everyone,
I am currently a computing student at the University of Abertay in
Scotland and I would like to take part in this year GSOC.
The proposal that I want to submit concerns the coreboot panic room idea
since it looks like something that could really benefit the project as a
whole and also because it seems like a really interesting technical
challenge.
I already digged through the blog and the mail exchanges of the previous
developer working on this, Tadas Slotkus, and took a look at the patches
that he wrote so I already have a general understanding of their aim.
I would like to concentrate most of my efforts towards improving and
upstreaming the previous efforts, implementing a way to easily access
the recovery mode when needed and further the integration between
coreboot, serialICE and flashrom for this use-case.
Regarding the existing patches I would like to know if they would need
to stay romc-compatible or should the scope be limited to CAR boards?
Any suggestions on how to tackle this project or GSOC in general?
Thanks in advance.
Hi,
I was wondering why my Lenovo X200 had such a short battery lifetime when running Libreboot/Coreboot, so I did a few measurements using the following hardware configuration:
X200 with P8700 CPU
8GB RAM
LED Display (yes, one of the rare ones)
OCZ Trion SSD (unused, just idling)
Wifi and WWAN removed
Battery removed
Ubuntu MATE 16.04 Live running from an USB thumb drive
No tweaking with powertop or such
I kept this configuration unchanged except for the BIOS and waited 5 minutes after booting, so the system could settle. Then I measured power consumption both at full brightness and at minimum brightness using a conventional power meter (EKM 365) which was plugged between the AC adapter and the power socket in the wall.
I obtained the following numbers:
Vendor BIOS: 7,5W (lowest) to 10W (highest)
Libreboot 20150518 (using the precompiled binary binary): 13,3W (lowest) to 16,1W (highest)
Latest Coreboot, config attached (80a3df260767a6d9ad34b61572d483579c21476c): 10,4W (lowest) to 13,4W (highest)
While Libreboot performs much worse than Coreboot, Coreboot still eats around 3W extra when compared with the vendor BIOS. In other words: Coreboot consumes around 30-40% more juice than the vendor BIOS which is a very sad result for an ultraportable notebook.
Is this a known issue? Has someone else tried the same and obtained different numbers?
Cheers, Daniel
On Fri, Apr 29, 2016 at 5:55 AM, daoud yessine <yessine.daoud.92(a)gmail.com>
wrote:
> Hi
>
> How bootblock can relocate CBFS to load romstage in ARM SOCs ?
> the same thing for romstage to load ramstage and ramstage to load payload ?
> what's the name of structure or pointer to refer to it to relocate CBFS ?
> Because coreboot is different from an ARM soc to another in firmware level.
>
>
What do you mean relocate? Relocate the loaded program at runtime? There is
a relocatable module support in coreboot for doing this, but many of the
ARM platforms statically link all the stages in payload. Ensuring that they
don't overlap is done manually for all the components.
> thx
> ᐧ
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
Hello Zoran,
read_microcode_rev() returns 0,
msr.lo is 0xFFE68430,
msr.hi is 0
These values are all good, as far as I can tell.
However, I had to dump these as post codes, because printk is not available in this early stage in bootblock.
Hi
How bootblock can relocate CBFS to load romstage in ARM SOCs ?
the same thing for romstage to load ramstage and ramstage to load payload ?
what's the name of structure or pointer to refer to it to relocate CBFS ?
Because coreboot is different from an ARM soc to another in firmware level.
thx
ᐧ
