Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Carl-Daniel Hailfinger
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
3 months, 4 weeks
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
4 months, 2 weeks
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
4 months, 4 weeks
Lenovo T410 Coreboot
by A. Veek
-----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-----
5 months, 1 week
FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski
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/
5 months, 3 weeks
Re: [coreboot] Will a KCMA-D8 boot without the 8pin EPSV12 cable if you are using a 35W CPU?
by Nico Huber
On 10/18/18 3:16 PM, Angel Pons wrote:
> I believe the power traces are different, so the CPU VRM feeds only through
> the EPS12V connector. However, if your PicoPSU is large enough, I guess a
> EPS12V cable can be attached to it.
Probably not for a 35W CPU, but generally: Using adapters for the
EPS12V connector is dangerous. They have more than two pins for a
simple reason: The electrical current through each pin/connection must
not get too high. There are adapters that route the whole current
through a single pin on the other end (e.g. a single old-school PATA
drive connector). Never use these unless you know they can take the
current you expect! (e.g. not much more than 3A for a 35W TDP, that
might be ok for a single pin, but you should read each connectors
specs)
Same applies to the tiny connectors for (hard)-drives on the PicoPSU,
if the current goes through less pins on the PicoPSU side, don't do it
(unless you know what you are doing).
There are PicoPSUs that have a 4-pin EPS12V connector btw. So I'm not
sure what the original question was; would it work w/o full 8 pins? or
would it work w/o any? The former likely yes, the latter likely no.
Nico
6 months, 1 week
Re: [coreboot] Hardware diagnostic
by Peter Stuge
yanvasilij yan wrote:
> I have two Intel Atom E3800 based boards. The first one is older version,
> which woks properly,
..
> The second one is modernized version, we added 89HPES5T5 PCIe I/O
> expansion switch. And WGI210IT based Ethernet ports are connected
> to switch.
So the good news is that your log clearly shows the PCIe switch
working correctly and both NICs behind reachable by software.
> Further we rebuild a bit a power up circuit of the E3800 SOC.
This is quite possibly the root cause, but I wouldn't exclude any
other possibilities.
> Launching stops when starts payload loading. The launch log of this board
> see in attached “not_working_board_log.txt”.
The log is very clear about why: (down near the end)
--8<--
SELF segment doesn't target RAM: 0x00800000, 4259840 bytes
-->8--
Looking at the coreboot table a little further up, we see:
--8<--
Writing coreboot table at 0x3add3000
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000e00000-0000000000e39fff: RAMSTAGE
2. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES
3. 00000000feb00000-00000000fec00fff: RESERVED
4. 00000000fed01000-00000000fed01fff: RESERVED
5. 00000000fed03000-00000000fed03fff: RESERVED
6. 00000000fed05000-00000000fed05fff: RESERVED
7. 00000000fed08000-00000000fed08fff: RESERVED
8. 00000000fed0c000-00000000fed0ffff: RESERVED
9. 00000000fed1c000-00000000fed1cfff: RESERVED
10. 00000000fef00000-00000000feffffff: RESERVED
-->8--
Compare that with your working board:
--8<--
Writing coreboot table at 0x3add3000
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000dfffff: RAM
4. 0000000000e00000-0000000000e39fff: RAMSTAGE
5. 0000000000e3a000-000000003ad9dfff: RAM
6. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES
7. 000000003ae00000-000000003fffffff: RESERVED
8. 00000000e0000000-00000000efffffff: RESERVED
9. 00000000feb00000-00000000fec00fff: RESERVED
10. 00000000fed01000-00000000fed01fff: RESERVED
11. 00000000fed03000-00000000fed03fff: RESERVED
12. 00000000fed05000-00000000fed05fff: RESERVED
13. 00000000fed08000-00000000fed08fff: RESERVED
14. 00000000fed0c000-00000000fed0ffff: RESERVED
15. 00000000fed1c000-00000000fed1cfff: RESERVED
16. 00000000fee00000-00000000fee00fff: RESERVED
17. 00000000fef00000-00000000feffffff: RESERVED
-->8--
The new board ends up with no RAM regions in the coreboot table.
That results in the payload loader not finding RAM where the payload is
to be loaded, so boot stops.
Why are there no RAM regions? I don't know.
Looking near the beginning of the log about FSP memory init:
--8<--
Memory Down Data Existed : Enabled
- Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 1
- Type (0: DDR3, 1: DDR3L) : 1
- DIMM0 : Enabled
- DIMM1 : Disabled
- Width : x16
- Density : 2Gbit
- BudWidth : 64bit
- Rank # : 1
- tCL : 0B
- tRPtRCD : 0B
- tWR : 0C
- tWTR : 06
- tRRD : 06
- tRTP : 06
- tFAW : 14
Using 1066 MHz DDR3 settings.
1 GB Minnowboard Max detected.
romstage_main_continue status: 0 hob_list_ptr: 3ae20000
FSP Status: 0x0
PM1_STS = 0x1 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808
romstage_main_continue: prev_sleep_state = S0
Baytrail Chip Variant: Bay Trail-I (ISG/embedded)
MRC v0.102
1 channels of DDR3 @ 1066MHz
-->8--
It appears OK - but do check that those numbers actually match the
DRAM chips assembled on the board. Are DRAM parts identical between
old and new?
Were there *any* hardware changes between SoC and RAM?
That's worth checking, but..
> nico_h in the IRC chat noticed that in non-working board appears a starnge
> device with vid/did PCI: 00:00.0 [8086/0000].
The 0000 is a HUGE red sign, screaming to be thoroughly investigated.
This also hints that the power up changes may be the problem.
It's VERY unlikely that Intel has suddenly released a variant of this
particular SoC with PCI DID=0000 when it used to be DID=0f00. In fact
it's really unlikely that 0000 would be used in correct operation at all.
Very likely on the other hand is that the SoC isn't being powered on
correctly, and so it ends up in some half-initialized state, with the
memory controller not working, and while some part of coreboot seems
to notice (because no RAM regions in coreboot table) clearly that
isn't causing a fatal error, which I think is a bug. Oh well.
If you go through every single powerup hardware change together with
a hardware engineer, starting with the previous circuit and manually
applying one change at a time, maybe you can find one or even more
changes causing that device ID symptom. It depends on how many changes
you have there, but with a good hardware engineer you could perhaps go
through them all in a couple days, which would be really fast results
for a problem like this.
Maybe even simpler, hack this into some early part of the code, maybe
even console_init() works, if pci_early is available there.
while (1)
if (0x0f00 == pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID))
printk(BIOS_INFO, "PASS\n");
else
printk(BIOS_INFO, "FAIL: want 0f00 is %04x\n", pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID));
Then hardware engineering can do analysis on their own. But make sure
to confirm that your test is reliable, using the hardware you have
(old and new) before you give a flash image to them.
Oh, and test on multiple new boards, a single unit in a new batch isn't
representative. New PCB; potentially the process has to be tuned. I don't
know how early in bringup you are.
Good luck and have fun! :)
//Peter
6 months, 3 weeks
Matrix instead (or additionally to) IRC
by Philipp Stanner
Hey,
have you guys already heard of Matrix?
https://matrix.org/blog/home/
It's some sort of modern IRC, using JSON to format messages. It's more
modern than IRC. Features are:
* Source code formatting and highlighting in messages
* multiple devices
* history + history synchronization between multiple devices
* possible E2C encryption
and many more.
In theory it will be a decentralized protocol, but there aren't that
many servers yet and actually only one working server-software
Many projects, especially tech-based ones like the Rust programming
language already use the service.
Personally I think it's an enormous progress to IRC. I would give it a
chance if I were you :)
P.
6 months, 3 weeks
There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8)
by Taiidan＠gmx.com
(This is the firmware storage module required to use OpenBMC on the
KGPE-D16/KCMA-D8 boards - with it at last one can have feature
equivalency with a proprietary system)
Great opportunity if you need but don't have one - they appear to be
brand new.
Raptor says either the ASMB4 or the ASMB5 will work.
While the facebook version of OpenBMC is stripped down (they used that
one for smaller firmware size afaik) and not as nice as the IBM OpenBMC
found on the various OpenPOWER machines it is still secure and much
nicer than the exploit filled default BMC firmware from ASUS.
6 months, 3 weeks
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
by Jose Trujillo
Lance:
I followed your advice and fetched coreboot master today and now entered into the payload domain "0xF8"....
Still have problems because tianocore does not load the operating system and other issues but this is another story for tomorrow.
Thank you,
Jose.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 31, 2018 4:08 AM, Lance Zhao <lance.zhao(a)gmail.com> wrote:
> Feels like CoffeeLake RVP11 still been actively uploaded with newer changes. But at least your coreboot code seems to be outdated, all of those coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. I will suggest you to sync up your code base and try again.
>
> Lance
>
> On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot <coreboot(a)coreboot.org> wrote:
>
>> Hello coreboot engineers:
>>
>> I am using the "coffeelake RVP11" to test the code on my "non RVP" system.
>> The payload doesn't load.
>>
>> I found several errors in the attached log:
>>
>> 1.- Device ID's of the system are still not existant in coreboot.
>> 2.- Misconfigured # of MAX CPU CORES.
>> 3.- Maybe memory is still not properly initialized because RVP platform uses LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD channel.
>>
>> Please help me to identify the root of the problem that causes RAM "Failed Segment"....
>> Thank you in advance.
>> Jose Trujillo.
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
6 months, 3 weeks
