Hi Ivan,
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.
Regards,
Carl-Daniel
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
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
-----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-----
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
individuals.
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:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
Christian Gmeiner wrote:
> Most of the time the system works as expected but from time to rebooting
> the system fails completely.
Only ever when rebooting, or does cold boot also fail sometimes?
(Make a test system to cold boot your system in a loop.)
> there are two FPGAs connected via PCIe to the system where one is used
> to reset the system. The reset is done via SYS_RESET#.
Are the FPGAs also reset by that?
If yes, how long do they need to initialize to where HDL acts
correctly on PCIe?
If no, how long do they need to move from resetting the system to
where HDL acts correctly on PCIe for the newly resetted platform?
> Now I run into different kind of issues:
> - pcie link training fails from time to time
On both links, or only one of them? Can you tell?
> - looks like PLTRST# of the sunrisepoint pch holds the system in reset
> for minutes.
I don't know if there's enough PCH documentation to know exactly why
it would do that - but I can imagine that it holds reset as long as
some conditions are not met, I can also imagine that the FPGAs cause
some undefined PCIe behavior in the PCH which happens to get it stuck
in reset for a while.
> Are there any hints to debug my issues?
As always, try to isolate the problem.
Can you completely remove one or ideally both FPGAs from the equation?
You mention that one of them is used for reset. At least disable the
other one, destructively if need be.
//Peter
Ivan Ivanov wrote:
> If you've ever heard the spkmodem output, please could you try to
> decode this stuff if its' easy for you, or at least to tell if it
> sounds OK or not?
It sounds somehow like I remember spkmodem, but the file is very low
amplitude (too quiet) and I can't confirm whether the signal is the
correct speed.
I've only received spkmodem successfully with the microphone right
next to the speaker - moving the mic only a few cm lost signal.
Note that spkmodem-recv requires 48k s16le mono PCM.
I tried decoding, resampling and normalizing the ogg file without success
so I suggest increasing amplitude at the source; move the mic closer to
the speaker and use the parecord | spkmodem-recv command as documented
in spkmodem-recv.c. Make sure to set your mic input volume to 0dB (and
not higher!) so that you get the best possible signal, without attenuation.
//Peter
On 9/27/18 10:29 PM, Youness Alaoui wrote:
> Thanks everyone for the responses.
> So far my understanding on the task at hand is :
> - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide
> if we lock it on the resume path?)
Maybe no config at all, see discussion of PRR34_LOCKDN below. But if,
then only one config, IMO: On the resume path FLOCKDN should always be
set.
> - Remove the chipset_lockdown devicetree config and change the code to
> always assume it's LOCKDOWN_COREBOOT (this applies to all platforms,
> right?)
Yes, unless somebody objects. Please make sure to add the right
reviewers to this patch. I expect some resistance.
> - remove the call to fast_spi_pr_dlock() and fix the comment above
> that function to be more accurate
Please also check the tree for code that sets PRRs. IIRC, it is used
somewhere to protect the MRC cache. I would set the discrete lock
directly after writing the region.
> - Add .config CONFIG options or maybe optional devicetree configs for
> how to setup the registers so coreboot can prepare them (due to the
> resume path) ?
Hmm, I would add Kconfig options for this as well. I you want to match
the configuration of your payload, it definitely doesn't belong into the
devicetree. Note that "prepare" also implies to lock them on the resume
path.
>> AIUI, FLOCKDN always locks the PRRs.
> Actually from what I can see, the FLOCKDN will lock a few registers,
> among which it will lock the "discrete PR locks" register, and it will
> lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to
> separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN
> set, and in the payload, just set protected range in PRR3 or PRR4,
> then set the PRR34_LOCKDN. Unfortunately, I can't do that because the
> PRR3 and 4 were already locked with the discrete lock register (if I
> remove the call to fast_spi_pr_dlock(), it should be fine for my needs
> though I think, since you said swseq would also fail for protected
> ranges).
Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or
at least didn't remember it. In this case it seems best to always set
FLOCKDN in coreboot. The payload can then still protect additional
regions with PRR3/4. On the resume path, coreboot would set both FLOCKDN
and PRR34_LOCKDN, right?
>> Also note that swseq is not an option anymore since Skylake (IIRC, the
>> ME protects the flash-cycle go bit in its default configuration). With
>> only hwseq, you can only access the flash chip's first status register
>> which makes many security features unusable. So we have to rely on the
>> protected regions :-/ I hope Intel is going to fix that for future plat-
>> forms (or with an ME update if that could add more hwseq commands).
>
> Well, I saw the opmenu/optypes/etc.. registers still being set in
> skylake (their offsets were not in the datasheet though), so I figured
> swseq is still there, just undocumented. It might work on systems
> where the ME is disabled. I'd have to test. I was thinking of using
> swseq and add the write-register-2 opcode and use it to set SPR1 and
> lock the entire flash until it gets power cycled. I don't know if that
> would work during suspend, but if it does, it might help with the
> resume path at least (but would prevent updating flash after a reboot
> and would force user to shut down and boot). I guess I have some
> trial-error to do.
The tricky part is to get access to the flash chip's second status
register. I couldn't figure any way to do that with SKL (this cost
me some weeks of work once because FSP also locked empty flash pro-
tection).
> Actually, if status register remains the same through a
> reboot/suspend/resume, and swseq doesn't work on skylake at all, I
> could just set the protect bits and prevent writing to status register
> on resume path.
I don't understand, is there a lock to prevent status register writes
with hwseq? Also I though, you can't disable these status register bits
w/o a reset. Whether the flash chip is reset, depends on your board
design and power sequencing ofc.
>
>> One way would be to let coreboot decide, e.g. prepare the configuration
>> and don't lock it, and let the payload lock. The payload could validate
>> this configuration before locking (and issue a warning if coreboot
>> didn't set the expected bits).
>
> Thanks, that's a good idea, I forgot about the suspend/resume case.
> This implies I need coreboot to know about what config the payload
> will want to set. I'm not sure if that should go into a CONFIG or a
> devicetree config. Since it might be user-configured, it makes more
> sense for it to go into .config, right ?
Yes, Kconfig seems to be the right place.
Nico
Hello !
Thank to charlotteplusplus`s reddit post i have succesfully running
coreboot with a skrinked ME image on my W520. Everything works fine
exacpt the fact that the nvidia GPU is not reconnicest by any linux
distro. (not shown in lspci)
is here anyuser with an W520 and got coreboot running with the nvidia
GPU enabled?
Maybe somebody can send me their rom or help somehow.
Greetings
the kinky nekoboi
Hi Ivan,
On 9/28/18 11:50 PM, Ivan Ivanov wrote:
> Thank you for spkmodem comments, now I'm trying out a more reliable
> way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I
> plug it into the correct port - USB 2.0 at laptop's right side.
> However it doesn't print anything except this short test message:
> --- /* Perform a small write. */
> --- ret = dbgp_bulk_write_x(&pipe[DBGP_CONSOLE_EPOUT], "USB\r\n", 5);
> ------ line 322 of ./coreboot/src/drivers/usb/gadget.c
>
> Thinking that it breaks during the relocation from romstage to
> ramstage (migrate_ehci_debug function at ehci_debug.c ?) , I disabled
> CONFIG_USBDEBUG_IN_ROMSTAGE - but the results are the same: only "USB"
> message. I could see
> --- dprintk(BIOS_INFO, "Test write done\n");
> ------ line 328 of ./coreboot/src/drivers/usb/gadget.c
> at cbmem logs, but even that doesn't get copied to FT232H output.
the purpose of dprintk() here is to only print when EHCI debug is _not_
activated yet. Otherwise the code trying to print something would be
called recursively. But it might actually work at this early point,
with proper configuration (see below).
>
> Please could you take a look at my coreboot .config and cbmem logs,
> what if this FT232H dongle doesn't get selected as console output for
> some reason? CONFIG_CONSOLE_CBMEM is still enabled, but maybe I should
> disable it?
You are missing CONFIG_CONSOLE_USB.
Nico
