In that case, I'd also like to point you to the deadline for submitting
main track talks which is tomorrow(!).
Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
could you submit something or do you have someone in mind who can do that?
There's also lightning talks, deadline is a bit later.
OK, I'm submitting a request for a stand. I need a backup contact for
the stand. Who is willing to do that? AFAICS we can still change the
backup contact later if life happens.
On 02.11.2018 20:48, David Hendricks wrote:
> On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> <linuxboot(a)googlegroups.com <mailto:email@example.com>> wrote:
> I"m leaning to yes, by which I mean if you do it, I'll show up.
> I can't believe I said that.
> On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
> <mailto:firstname.lastname@example.org>> wrote:
> > Hi!
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
> Same as what Ron said. I think someone from FB can be there to talk
> about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Dne 30.5.2018 v 16:06 Mike Banon napsal(a):
> Hi Rudolf,
> Regarding this part:
> " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. "
> what command do I need to use to check this?
sudo setpci -s 14.3 40.b
Despite command name, it will print the value.
I’m new at the board porting game but I’m interested in making a port for a single board computer that is running very similar hardware to the Librem 13 laptop and the Google Pixel 2015.
It seems this board is also rather close to Intel’s own Eval Kit hardware setup, both in hardware and software regard (almost bare defaults AMI Aptio firmware).
Looking at the coreboot archives, this board might have been mentioned before: https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html <https://mail.coreboot.org/pipermail/coreboot/2018-July/087050.html> but that was HTML formatted in an attachment for some reason.
- CPU: i5-5250U
- SuperIO: IT8784E-I
- HDA: ALC662
- Flash: 8MByte Winbond SPI SOIC8 (but flashrom detects it as opaque when using internal programmer on-device, works correctly using external SPI flasher)
- 4x Intel I211 Ethernet controllers
more specifically, inteltool sees:
CPU: ID 0x306d4, Processor Type 0x0, Family 0x6, Model 0x3d, Stepping 0x4
Northbridge: 8086:1604 (5th generation (Broadwell family) Core Processor ULT)
Southbridge: 8086:9cc3 (unknown)
IGD: 8086:1626 (unknown)
Linux itself sees it as Wildcat Point-LP and Broadwell-U which makes sense.
It has a running ME, but there is an unpopulated header (ME1) which when shorted seems to kill it or put it in manufacturing mode (soldered in a pin header and plugged in a jumper):
MEI found: [8086:9cba] Wildcat Point-LP MEI Controller #1
ME Status : 0x1e040185
ME Status 2 : 0x10522106
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 : Security Override via Jumper
ME: Error Code : No Error
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : 0x52
When not using the jumper, flashrom can’t read anything using the internal programmer mode, but when plugging the jumper in, it can read it. Output is not the same as reading the SPI flash chip offline externally, so some of the flash it probably still hidden by the PCH as it always does.
There are exposed pads near the Realtek ALC chip which makes it really easy to pull GPIO33 to DVDD and disable flash descriptor security.
So far so good, the hardware has easy-to-reach points to get to the flash, ME jumper and PCH straps. The firmware isn’t very custom, and neither is the board (except the four ethernet controllers/ports).
My next steps were: cp -R the Purism directory to Qotom, remove all the Librem15 stuff, rename the Librem13 to Q3XXG4 and remove the EC references as this board doesn’t have an EC.
At this point, I’m not sure what to do next, besides the text in board_info.txt (both the vendor directory and the variant directories) I’ll probably have to make sure:
- acpi_tables.c has the correct tables, unless I can use the (generic looking) contents the Librem 13 uses, which doe acpi_init_gnvs, and acpi_create_madt_lapics + acpi_create_madt_ioapic
- there is fadt.c which seems rather generic as well.
- gpio.h is probably depending on the PCH used? Seems to be generic for this PCH as well
- hda_verb.c seems to relate to the audio system, but I don’t care about it all that much at this time. The Librem 13 uses the ALC269 which has some differences to the ALC662, configuring it wrong probably just makes the chip sad and audio pin routing not work
- mainboard.c contains mainboard_enable and some calls for the GMA chip (install_intel_vga_int15_handler and some constants), probably the same accross this broadwell series
- romstage.c initialises the GPIOs does some PEI data copy/memset and then romstage_common (which probably is around or before the CAR stage?)
- acpi/mainboard.asl is empty, not sure what part of the existing ACPI I should dump in there
I turned the board into a variant, because Qotom has a number of boards that mostly differ in i3 vs i5 and more ethernet ports vs. more serial ports models. I named the variant q3xxg4 but I think we can do better as the PCB has a revision number printed on it, indicating more variants.
It looks like I’ll need to build some sort of devicetree.cb, perhaps by hand or converted from a ACPI dump from a running system? Then there is pei_data.c which seems to set the specifics for the hardware, the labels and locations.
While it is pretty close to the Librem 13 there as well (USB3 ports, USB2 ports) some of the locations need to be changed, and the camera, bluetooth, and speakers removed). Not sure how this relates to what is in the device tree and any *.asl files.
The old wiki and it’s porting guide isn’t up to date as far as I know, but I haven’t found a new guide or set of docs that shows how to read/source information from a running system and write it into a new mainboard definition.
I’ll probably need to get the GbE region from the old firmware, ME too, but what other parts of data (ACPI tables? PEI data?)I need to get and how to fill out that data into the mainboard definition isn’t very clear to me.
This device has a GPIO header, and two serial ports (one external DB9, one internal header), so getting debug data out should be possible, but just randomly building an image and flashing it in to the SPI chip probably gets me nothing until I have at least configured the serial port for coreboot to spit out debug data. I’m not sure if I need to get the FSP from Intel or if I should extract the one from the current firmware.
Any guidance would be appreciated.
Sorry but I think that relying on Intel RNG is a _Terrible_ idea
regarding the security and not sure you should be pursuing it. If you
really want a hardware RNG that is also secure, why not take a look at
some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted
recently! ) Wikipedia comparison page -
- You can check it to find the best price/performance USB TRNG dongle
which is also open hardware
вт, 27 нояб. 2018 г. в 22:50, Grant Grundler <grantgrundler(a)gmail.com>:
> On Tue, Nov 27, 2018 at 4:10 AM Nico Huber <nico.huber(a)secunet.com> wrote:
> > Hi Grant,
> > I don't know how it is supposed to work on Haswell, but can give you
> > some pointers anyway.
> > tl;dr I don't think you are looking for a PCI device.
> If intel-rng support is required, a PCI device will be advertised
> because of how the linux kernel binds PCI devices to drivers. See
> "alias" field of "modinfo intel-rng" as an example.
> One of the search results pointed at a response that said "load
> intel-rng driver" as the solution to this problem... that's the only
> reason I'm exploring this path.
> > Am 27.11.18 um 08:11 schrieb Grant Grundler:
> > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to
> > > have a HW Random Number Generator:
> > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cac...
> > >
> > > (Intel calls it Secure Key)
> > >
> > > But "modprobe intel-rng" is failing with "No such device" (Debian
> > > 4.18.0-2-amd64 kernel).
> > This driver is for very old Firmware Hub (FWH) hardware which would
> > be controlled through the LPC PCI device. You have such a PCI device
> > (00:1f.0) but there's no FWH to be expect with Haswell.
> Hrm. OK. But that would explain why intel-rng driver only binds with
> PCI devices.
> > What you are probably looking for is the RDRAND instruction. I don't
> > know if it can be controlled by the firmware, but would check first if
> > your OS is prepared to make use of it.
> Linux kernel has supported RDRAND for a long time. There is even a
> public debate about *excluding* RDRAND use since some people were
> hypothesizing that RDRAND was "compromised" by Intel so "goverment
> agencies" could break encrypted traffic which used RDRAND exclusively
> to generate encryption keys. Linux kernel does NOT exclusively use
> RDRAND and Ted Tyso made compelling arguments that RDRAND would still
> add "entropy" to key generation.
> What I don't know is how linux figures out it can or should use
> RDRAND. RDRAND appears to be a "CPU feature":
> arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND
> ( 4*32+30) /* RDRAND instruction */
> And as notedin original email, Intel says this CPU (Celeron 2995U)
> supports "Secure Key" which is the new marketing name for HW RNG
> support (could be only via RDRAND now).
> > > Why do I care about HW RNG?
> > > Because of this:
> > > ...
> > > [ 8.560270] r8169 0000:01:00.0 enp1s0: link up
> > > [ 8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready
> > > [19039.712644] random: crng init done
> > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting
> > > [19044.485625] wlp2s0: authenticate with ...
> > > ...
> > >
> > > Yes, several *hours* until the crng was initialized and then
> > > wpa_supplicant could start talking on WIFI. :(
> > >
> > > The length of the delay varies...shortest was 7 minutes.
> > Well, even without a hardware rng, I wouldn't expect that.
> Exactly. I didn't either. My NUC5 completes typically in 3 second from
> the time the kernel is loaded. But this is a different CPU (Intel Core
> i5 6260) and completely different firmware (If Coreboot was available
> for this, I'd prefer Coreboot).
> > With antennas
> > available, I would say after 10s for the paranoid there should be enough
> > entropy available. But that's probably just how I'd do OS development
> > (and depends on what the wifi driver can do).
> I don't know if the kernel has access to any radios (or antennas)
> until the 80211 link is brought up... which in turn won't happen until
> wpa_supplicant is running. So something else is wrong here. My
> suspicion is still on Coreboot not providing something that tells the
> linux kernel a quick method to generate random numbers.
> I saw Matt DeVillier's response as well and I'll follow up once I've
> updated the SeaBIOS firmware, installed rng-tools5, and determined
> which CPU features are advertised by both Panther and NUC CPUs. For
> some reason my "phone home" (SSH) is getting rejected right now. :(
> > Nico
> coreboot mailing list: coreboot(a)coreboot.org
-----BEGIN PGP SIGNED MESSAGE-----
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
ok the problems start when i try to merge the patch found on
into a coreboot master clone ...
any guide? i am not that advanced in git
Am 08.11.18 um 17:40 schrieb Mike Banon:
> Go to review.coreboot.org, search for the recently updated T410
> patches and apply them to your locally cloned coreboot, then build and
> test it. Let us know if you have a trouble at any step
> On Thu, Nov 8, 2018 at 7:35 PM kinky_nekoboi
> <kinky_nekoboi(a)bluetardis.de> wrote:
>> I have hardware to test,
>> T410 with intel gpu + little flashing tool collection.
>> i am waiting for instructions
>> Am 8. November 2018 17:30:00 MEZ schrieb Peter Lemenkov <lemenkov(a)gmail.com>:
>>> чт, 8 нояб. 2018 г. в 10:50, Angel Pons <th3fanbus(a)gmail.com>:
>>>> Hello nekoboi,
>>>> On Thu, Nov 8, 2018, 10:39 kinky_nekoboi <kinky_nekoboi(a)bluetardis.de wrote:
>>>>> is there any work going on in the T410 Port ?
>>>>> Hardware is simular to X201
>>>>> I heard some people succesfully flashed x201 roms.
>>>> I recall seeing a gerrit patch for it, though it is old. I would work on it but I don't have any Thinkpad (let alone a T410).
>>> Btw I've updated recently both t410 and t410s patches from gerrit
>>> according to the recent coreboot changes, but I've got the same story
>>> - I don't have hardware to test.
>> coreboot mailing list: coreboot(a)coreboot.org
I was trying to upgrade my Kontron 986LCD-M setup to AMD Radeon RX460
and I've found the vendor BIOS lack support for the video BIOS (RX460
requires UEFI). This incompatibility leads to x16 PCIe slot disable and
no graphics in linux at all.
I was able to re-enable the PCIe slot until now when I tried to upgrade
to 2+2 GiB DDR2 modules (little more MB and dual channel). The RAM space
is shared with PCI space and limited by 32bit so the top part of RAM is
eaten by the regions of PCI devices. Problem is when vendor BIOS
disables the card's slot it doesn't leave a hole for my GPU and it sets
the TOLUD register (top of used RAM). This causes kernel to crash in GPU
There is probably no way to fix TOLUD (and ACPI tables, SMI and other
stuff) or force vendor's BIOS to reserve region for GPU, so I'm
considering to switch to coreboot.
My question is: does anybody know advanced information about TPM and SPI
connectors? In the Kontron 986LCD-M datasheet (sections 4.16 and 4.17)
there are only pin names and caption "unsupported". I understand these
signals are likely buses from chipset, but it would be nice to know more
details. Namely if the default LPC flash chip needs to be disconnected
when using these busses and which pins of the chipset are connected to
SPI pins BOOT0 and BOOT1 (I suppose they are LPC/SPI/PCI priority?).
Thanks for any help.
Is there an external superio on your board?
At the moment I am trying to solve the problem of initializing the external superio chip for the SOC Baytrail processor, but so far without success.
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
Cheers and see you at FOSDEM!
Paul Kocialkowski, developer of free digital technology and hardware
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/