Coreboot build process with gcc 8.1
by Salvatore Bellizzi
Hi,
I have a question reguarding the build process.
Since crossgcc has been updated and gcc is now at version 8.1 I always
encounter an error when building coreboot:
coreboot/src/console/vtxprintf.c:102: undefined reference to
'__udivmoddi4'
Since coreboot uses crossgcc and its own libgcc libraries, I figured
that the __udivmoddi4 function has not yet been implemented.
Anyway I have incurred in this failure several times and even with the
latest 4.9 release. Shouldn't I be able to build at least this latest
release using unmodified crossgcc or am I missing something else?
thanks,
salvatore
6 days, 4 hours
Re: [coreboot] AMD IMC open source firmware replacement
by Rudolf Marek
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?
Try:
sudo setpci -s 14.3 40.b
Despite command name, it will print the value.
Thanks
Rudolf
1 week, 3 days
Please help me adapt coreboot to HiFive-Unleashed
by 王翔
I tried to adapt coreboot to HiFive-Unleashed and boot bbl with coreboot and run linux.
My changes are as follows:
https://github.com/hardenedlinux/coreboot-HiFiveUnleashed/tree/HiFive-Unl...
My code can run bbl, but it doesn't respond when bbl exits m-mode and enters linux.
I use freedom-u-sdk to compile bbl. In order not to conflict with the coreboot memory address, execute the following command.
riscv64-elf-objcopy --change-addresses 0x200000 work/riscv-pk/bbl ../coreboot/payload.elf
I don't know what I missed, what should I do, I hope to get your help.
------------------
王翔
安全研究员
广州市腾御安信息科技有限公司
广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024
1 week, 3 days
Update on Asus KGPE-D16 with coreboot 4.6 and Qubes 4
by petecb
Hi,
Season's greetings to everyone! :-)
I've been able to get my Asus KGPE-D16 running with coreboot 4.6 and Qubes 4 and I'm pleased to report it has been nice and stable over the holiday period, save for a few minor issues.
Suspend works fine on a fresh install of Qubes 4, however applying the latest updates then stops this from working. (It goes in to suspend but does not resume properly). I'm assuming this is now a Qubes issue.
My Intel Optane 900p NVME drive does not work reliably with Qubes 4. It initially appears fine but anywhere between 4-12 hours after boot the system will panic and switch to a read-only file system - you can't run any commands without an "Input/Output Error" even in Dom 0. The only course of action when this is encountered appears to be a hard reset. Unsurprisingly, getting any kind of logs about what is actually happening has proven fruitless so far :-(
I have therefore switched to a normal SATA drive for the last week and this has been nice and stable. I suspect my best course of action to get a higher performing filesystem is to move to 4 SATA SSDs in RAID 10. If anyone has any other suggestions to get faster drive access with this platform (particularly good random read/write performance for using lots of concurrent VMs in Qubes) or possible approaches to fix my NVME drive issue, they would be much appreciated.
My only other minor issue at the moment is lack of fan control. If I run "sudo pwmconfig" in dom0 I get the message "There are no pwm-capable sensor modules installed". I suspect I need to enable some additional modules, so if anyone can provide me some explicit directions on how to do this, it would again be much appreciated.
Kind regards,
Pete
2 weeks, 3 days
Status on Dell OptiPlex 7010 support
by Kumonie Williams
Hello there, I have a question regarding coreboot.
I was wondering if work was still being done to port coreboot to the Dell
OptiPlex 7010. I was looking at commit
882d3c3574cc24f1bcf16b71c5090cc71ef725a6, but it seems the board didn’t
boot at that stage in time. I have also not found much information
regarding 4f19f4a7ebe7783830343d5ffc917142266fabf9 either, so I was
wondering if work was still being done to port coreboot to the OptiPlex
7010, given its stock firmware doesn’t really work that great (I'd be happy
to elaborate), even at revision A29, so I wanted to replace it with
coreboot.
Thanks.
2 weeks, 4 days
Dell R610 Support
by Ed Hau
Hello,
I just started looking into adding support for the dell r610. This is
mostly because you can get them really cheap and they perform well for
my type of workloads. However looking at the wiki it looks like I have
my work cut out for me if I am able to do this at all. From the
following dump it looks like I have a currently unsupported chipset,
cpu, and superIO.
$ root@plex-8316f3de71:~# dmidecode -t 2
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 2.6 present.
Handle 0x0200, DMI type 2, 9 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0K399H
Version: A03
Serial Number: ..CN697029680164.
Asset Tag: Not Specified
$ root@plex-8316f3de71:~# superiotool -d
superiotool r6637
Found SMSC EMC2700LPC (id=0x67, rev=0x01) at 0x2e
No dump available for this Super I/O
$ root@plex-8316f3de71:~# inteltool
CPU: ID 0x106a5, Processor Type 0x0, Family 0x6, Model 0x1a, Stepping
0x5
Northbridge: 8086:3403 (unknown)
Southbridge: 8086:2918 (ICH9)
It looks like I will have to contact SMSC which was acquired by
microchip in 2012 so hopefully they are still able to give me the
datasheet. Additionally I will need to get the datasheet from intel for
CPU north/south bridge which from the docs sounds like it might take a
while if they will even give it to me at all.
Does this seem like a good place to start? I wasn't able to find much
outside of https://www.coreboot.org/Developer_Manual so figured I would
ask for a little bit of help getting started on the mailing list first.
Thanks for looking
2 weeks, 4 days
Re: Asus Chromebox Panther: no HW RNG?
by Grant Grundler
To close off this thread: installing rng-tools5 worked for me.
Per guidance in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898814#62
Though I tried, I couldn't verify the particular commit I pointed out
was the culprit: with and without that commit got the "crng init done"
in ~7.5 seconds repeatedly. And additional code changes in the kernel
corrected this issue for most users.
With rng-tools5 and debian linux-image-4.19.0-1-amd64 installed, "crng
init done" message shows up in 5.9s after booting.
cheers,
grant
On Sun, Dec 23, 2018 at 7:28 PM Grant Grundler <grantgrundler(a)gmail.com> wrote:
>
> On Sat, Dec 22, 2018 at 12:05 AM Angel Pons <th3fanbus(a)gmail.com> wrote:
> >
> > Hello,
> >
> > On Sat, Dec 22, 2018, 08:50 Grant Grundler <grantgrundler(a)gmail.com wrote:
> >>
> >> On Wed, Nov 28, 2018 at 1:51 AM Ivan Ivanov <qmastery16(a)gmail.com> wrote:
> >> >
> >> > Sorry but I think that relying on Intel RNG is a _Terrible_ idea
> >> > regarding the security and not sure you should be pursuing it.
> >>
> >> What I'm pursueing is a reasonable initialization time so
> >> wpa_supplicant can start. 555 seconds is not reasonable:
> >> [ 555.496678] random: crng init done
> >> [ 555.496678] random: crng init done
> >> [ 555.496684] random: 7 urandom warning(s) missed due to ratelimiting
> >> [ 560.265385] wlp2s0: authenticate with xx:xx:xx:xx:xx:xx
> >> [ 560.279395] wlp2s0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
> >> [ 560.281981] wlp2s0: authenticated
> >>
> >> intel-crng was proposed elsewhere as one solution to this problem but
> >> it's clear to me now that this is not an option with the panther
> >> chromebox.
> >>
> >> I don't recall seeing this with older kernels (have been running
> >> debian on this HW since early 4.x releases) and will look at the
> >> driver git logs.
>
> And I found one commit which I believe is likely the issue (need to
> confirm this still):
> commit dc12baacb95f205948f64dc936a47d89ee110117
> Author: Theodore Ts'o <tytso(a)mit.edu>
> Date: Wed Apr 11 14:58:27 2018 -0400
>
> random: use a different mixing algorithm for add_device_randomness()
>
> This change _could_ cause devices that don't have input or have
> wireless networking (which doesn't get initialized until
> wpa_supplicants gets a value back from /dev/random) to take a very
> long time for crng_init to increment and finally determine "random:
> crng init done" (in crng_reseed()).
>
> But I need to compare v4.17 behavior (where I think this was
> introduced) with v4.16 or just revert this with my own 4.18 kernel
> build.
>
> I'm using the following git commands to compare differences in releases:
> git diff v4.16..v4.17 -- drivers/char/random.c
> git diff v4.17..v4.18 -- drivers/char/random.c
>
> (same parameters with "log" instead of "diff" to see the corresponding
> commit messages)
>
> ...
> >> I experimented with attaching just an optical mouse and that didn't
> >> seem to help.
> >> Attaching a keyboard and just hitting <shift> key did seem to help
> >> ("crng init done" in about 10 seconds). I'm assuming the /dev/random
> >> driver is not seeing enough actiivity otherwise.
> >
> > I have observed the same behavior on Debian Sid, I would have to smash
> > my keyboard a few times to generate enough entropy. I don't see anything
> > similar with Arch Linux. Maybe it has to do with distro-specific packaging?
> > I haven't checked.
>
> Does Arch-Linux kernel include the CL above?
> ie Is Arch linux offering a 4.17 (or later) kernel?
>
> cheers,
> grant
>
> ps. I realize this is the wrong forum to discuss a fix ... just want
> to wrap up the conversation here to confirm my theory that this might
> be a coreboot issue is wrong.
2 weeks, 5 days
Porting Qotom Q355G4 SBC (similar to Librem 13)
by John Keates
Hi,
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.
Board specs:
- 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.
Regards,
John
2 weeks, 6 days
mailing list changes
by Patrick Georgi
Hi everybody,
I took the opportunity of the slow season to make some changes to the mail
server configuration: it's moved to another server and the mailing lists
are now driven by mailman3 (before: mailman2) with hyperkitty as mailing
list archive system (before: pipermail).
I'm still importing and otherwise handling the archives, but the mailing
list should work now. For you, I hope that the only impact will be that
mailman3 has a new user management concept that manages users on a
per-server basis and not per mailing list like mailman2 did. This means
that your mailman credentials are void and you'll have to request new ones.
If you notice anything odd with the mailing list, I'd appreciate a heads-up.
Thanks,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
3 weeks, 2 days
