-----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-----
Hi Iru,
we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it,
because it's "recommended" by intel - as we dont recommend it.
Also there isn't yet a test script for Intel Boot Guard.
Can you post a link to that forum post?
I would like to look into a x240 flash image. If you have such board it would be nice
if you can send me a copy of the flash image via private mail.
Cheers,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
Over the past week or so, I've been working to get Libreboot running on
the latest ARM Chromebook: the C201, manufactured by Asus (codename
veyron_speedy). The laptop is running with a RK3288 SoC and ships with
Google's version of Coreboot preinstalled. It should require no
proprietary code nor any proprietary firmware load or microcode update
to boot, thus it would be a good fit for Libreboot, as a fully free
distribution of Coreboot.
In addition to that, the device's embedded controller (that handles
aspects of power management as well as the keyboard and a few other
things) is a microcontroller that is also running free software: the
free embedded controller firmware from Google.
Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot
be removed) that has a free driver but requires to load a proprietary
firmware on the chip. However, it is easy to work around that issue and
not use that chip at all, e.g. using an ath9k_htc dongle on one of the
two USB ports.
The GPU is a Mali T764, on which Luc has been doing some early work to
have free software support for it. It is uncertain[0] how long it will
take to have an usable free replacement for it, but now that there is
that hardware available, free graphics for Mali T GPUs would mean having
a recent laptop running fully free software, down to the firmware level,
without losing any major hardware feature, something that has hardly
ever been achieved yet. Thus, I believe it is of the utmost importance
to back Luc up on this, even if big players like ARM are trying hard to
make Lima not happen and to make it difficult for Luc to keep going.
Another aspect that I still have to look at in-depth is the ability to
use hardware video encoding/decoding. The RK3288 has an auxiliary
processor for that task, but it is unclear whether it can be used with
free software or not, though the first indications that I've gathered
are positive.
At this point, I've been able to boot up Debian on the device, and the
xfce4 interface is quite usable. It even runs big programs like
Iceweasel/Firefox and LibreOffice without inconveniences.
However, it cannot run desktop environments that depend on GL
acceleration, such as gnome-shell, which is a shame since those would be
a good fit for it. The CPU is simply too slow for offering a decent
experience with software rendering (llvmpipe).
Overall, I truly hope this device creates an incentive to free the last
remaining parts that can only work with proprietary software to this
day. Its potential would be huge, especially since it's a good fit for
travellers. With the security model inherited from Chromium OS, this
would be one of the safest laptops to be used by journalists or
activists. If Tails was to be ported to it, it would become easy to have
a secure and anonymous setup.
I have successfully fixed and compiled Coreboot and all the necessary
bits and pieces for the C201, so I'll be spending the next few days
sending patches, discussing how to integrate it to Libreboot and getting
the actual work done.
I also plan on documenting all my findings (especially things like how
to access UART, how to remove the SPI flash's write protect, how to
reflash it externally, etc) on my coding blog, for now.
Cheers!
References:
[0]: http://libv.livejournal.com/27461.html
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
All,
I have successfully ported coreboot to the relatively modern ASUS
KGPE-D16 server board (dual AMD socket G34, 16 DDR3 DIMMs,
https://www.asus.com/us/Commercial_Servers_Workstations/KGPED16/)! This
port uses native Family 10h initialization (_not_ AGESA or CIMX).
The Libreboot folks will be interested to know that this board can run
blob-free and still retain full functionality!
Port specifications:
CPU: Dual AMD G34 Magny-Cours (Family 10h)
RAM: 16 DDR3 DIMM slots with ECC support (tested with x4 4G DDR3-1333
unbuffered DIMMs)
Peripherals:
PCIe slots: all functional
PCI slot: functional
RS-232: functional
PS/2: expected to function, not tested (on SuperIO)
ASpeed VGA device: functional (text mode, see below)
IEEE1394: functional
On-board USB: functional
On-board NICs: functional
ASUS PIKE SAS controller: functional
PCIe ROMs: functional
Power management:
DDR3 voltage set: functional
ACPI/APIC: functional
Suspend/resume: broken
Other:
cbmem console: partial support (log truncated)
cbmem timestamps: functional
nvram: functional
BIOS recovery jumper: functional
ASpeed VGA:
The ASpeed VGA device initialises in text mode via its (new) coreboot
driver, however this initialisation is incomplete, leading to distorted
but quite usable VGA output. When Linux boots and engages the graphical
framebuffer all distortion disappears.
This port was not trivial. Almost every device used was broken and
required debugging/repair, with the notable exception of the SuperIO
chip. The AMD DDR3 controller was severely broken to the point where
large rewrites were needed in order to bring it in line with the BKDG.
Even after the various component drivers were repaired
Due to the labor-intensive nature of the port and the extensive changes
throughout the entire source tree, it is not economically feasible to
merge this port upstream at this time (I estimate upward of 30
independent patches would be required just to get the board booting!).
Raptor Engineering will, however, be continuing to maintain this port
internally, and I am currently looking into adding native Family 15h
support on top of this internal tree. Additionally, while it was not a
priority for the initial port, I will be attempting to enable
suspend/resume functionality as I have time.
If there is sufficient interest from the community in adding this board
to coreboot I would consider merging the changes in exchange for a
one-time contract payment in the vicinity of $35,000 USD. When
considering this offer please bear in mind that this is a fully
functional blobless board with a wide range of peripherals and expansion
options available, and that once these large changes are merged I will
continue to enhance coreboot functionality as before (e.g. with the
KFSN4-DRE and the T400). I would also be willing to add this board to
the test stand as the only fully supported 4-way Opteron board (socket
G34 Magny-Cours CPUs contain two separate CPUs in one package, making
this 2-socket board a 4-way system from a HyperTransport perspective).
Please let me know if you have any questions!
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
Hi Guys,
Coolstar Organisation wants to do his Windows thang with one of the
Broadwell Chromebooks, so I'm trying to build a working ROM with
chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-yuna...
to give him a hand. Luckily USB debug works with this, so here is what
I'm getting. What could I do next?
Incidentally, if I flash back my backup, it goes into recovery mode now
every time I boot (flags are 0x489), I've tried pulling the battery to
no avail. If anyone has a trick to get around that, I'd appreciate it,
as the Acer is my main machine.
-John.
coreboot-5cbe3a8-dirty romstage Sun Aug 23 12:18:55 BST 2015
starting...
PM1_STS: 8910
PM1_EN: 0000
PM1_CNT: 00000000
TCO_STS: 0000 0000
GPE0_STS: 1ef82df0 187d4fdf 0005f240 00000000
GPE0_EN: 00000000 00000000 00000000 00000000
GEN_PMCON: 0200 2024 520b
Previous Sleep State: S5
CPU: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz
CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d
CPU: AES supported, TXT NOT supported, VT supported
MCH: device id 1604 (rev 09) is Broadwell F0
PCH: device id 9cc5 (rev 03) is Broadwell U Base
IGD: device id 1616 (rev 09) is Broadwell U GT2
CPU: frequency set to 2000 MHz
SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1)
SPD: module type is DDR3
SPD: module part is HMT425S6AFR6A-PB
SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
SPD: device width 16 bits, bus width 64 bits
SPD: module size is 2048 MB (per channel)
Boot Count incremented to 8
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : NO
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode : Normal
ME: Error Code : No Error
ME: Progress Phase : BUP Phase
ME: Power Management Event : Pseudo-global reset
ME: Progress Phase State : Waiting for DID BIOS message
ME: HSIO Version : 8705 (CRC 0xfbc2)
No FMAP found at ffe10000.
FMAP: area RW_MRC_CACHE not found
No MRC cache found.
Starting Memory Reference Code
Initializing Policy
Installing common PPI
MRC: Starting...
Initializing Memory
MRC: Done.
MRC Version 2.6.0 Build 0
memcfg DDR3 clock 1600 MHz
memcfg channel assignment: A: 0, B 1, C 2
memcfg channel[0] config (00780008):
enhanced interleave mode on
rank interleave on
DIMMA 2048 MB width x16 single rank, selected
DIMMB 0 MB width x16 single rank
memcfg channel[1] config (00780008):
enhanced interleave mode on
rank interleave on
DIMMA 2048 MB width x16 single rank, selected
DIMMB 0 MB width x16 single rank
CBMEM: root @ 7cfff000 254 entries.
MRC data at ff7d0d9c 6246 bytes
Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes)
create cbmem for dimm information
Dear all:
I can boot in Linux with default machine use :
qemu-system-x86_64 -bios [ Path to coreboot with FILO ] -hda [ Path to
Linux image ] -nographic
when I use Q35 machine :
qemu-system-x86_64 *-M q35* -bios [ Path to coreboot with FILO ] -hda [
Path to Linux image ] -nographic
the FILO would tell us that "IDE channel 0 not found",and not boot in Linux
how can I fix this problem ?
Thank you ~
G,day all
I just made an order on PCB cart for the OpenBiosprog_spi.
As a result of mild brain damage on my part; I went ahead and ordered
200 boards.
So in light of the above I am happy to mail out as many boards as anyone
might want for the low low price of $1.20 AUD plus postage. Spread the word!
http://keithtronics.tictail.com/
On 29.08.2015 21:58, ron minnich wrote:
> If people feel strongly enough about this then we can do an external repo
> for now.
Either way around, we would have to learn how to best integrate SPARK
code in coreboot. There would still be some steps to go from linking
with an adalib, to SPARK beeing a first class citizen of our build
system.
> Nico, do you want to set up a github repo and we can work out procedures
> people use to try this out? As you know I'm more interested in Muen as a
> replacement for the ramstage but this is a good first step.
I guess, I'll just push things to gerrit, when the code is ready.
Nico
Ron,
ron minnich wrote:
> I think this could prove to be a very important new direction for coreboot,
I agree.
> and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a
subdirectory lost somewhere in the already too big coreboot repository.
libsparkhw needs to live in its own repository, and be pulled into
coreboot as well as other consumers (e.g. FILO as Nico mentioned) as
a submodule.
But putting the submodule under 3rdparty isn't a great fit, because
the library is very much from the 1stparty, namely from the coreboot
community. So it should be somewhere else, I suggest in
lib/[lib]sparkhw.
License-wise, in order to be maximally compatible and reusable
together with libpayload I would welcome and support a simplified
BSD license.
I haven't ever used Ada, but used lots of Pascal long long ago. Fun!
//Peter
