librecore-org / librecore Goto Github PK

Tested primarily with different Kingston ValueRAM (KVR800) DIMM's.

Sometimes the board locks up with artifacts all over the screen, so it's probably video RAM / raminit related. This does not seem to happen with 667MHz Micron modules.

Memtest86+ does not show any errors with the KVR800 DIMM's. There is also no useable debug output when the system locks up. This bug is quite hard to trigger.

When testing an NVIDIA GeForce GT220 on any of my four ga-945gcm-s2l's, the system locks up hard quickly after setting mode (usually during the Plymouth boot screen).

I also get errors from the audio codec when a PCI Express card is present, for some reason.

snd_hda_intel: azx_get_response timeout

I have tested this with both FSB800 and FSB1066 cpu's on different distro's (at least with kernels 3.16, 4.4 and 4.8).

Sometimes, doing a hot reset after a lock up will result in a working system, but the next reboot will crash it again.

The card itself came from a working system. I don't have any Radeon cards to test, but I think it's related to the PCI Express code and not the card itself.

ADD2 cards, on the other hand, work fine in the same slots.

Sometimes, when one would expect a login screen, the display remains black (with a green-ish tone). This happens after the kernel sets mode. SeaBIOS does give normal output when this happens.

Short-pressing the power button will shut down the system, so it isn't locked up.

This could well be related to #7, or maybe to the GPU being clocked lower than normal. Or maybe both. I have been able to trigger this issue both with PC2-6400 DIMM's and PC2-5300 DIMM's.

The ga-945gcm-s2l is very unstable with an FSB800 chip, such as the E4600. Memtest reports hundreds of errors and running stress-ng --cpu 2 --vm 2 results in many kernel oopses. Some DIMM's even crash immediately after logging in to a composited desktop (artifacts, hard lockup).

Using the same board and the same DIMM's with an FSB1066 chip, such as the E7500, everything is fine and stable for hours.

Some DIMM's do work on FSB800 without issue though. But very few do.

The PWM frequency of the inverters on GM45 ThinkPads is hard-coded to a value that's pretty much always wrong.

CCFL's and LED's need completely different values, and even different screen types often differ slightly.

• bug 18918
• bug 31576

For reasons unknown, the GRUB payload is very laggy.

Keypresses are not always registered, and there is a lot of input lag within GRUB.

The main cause of slowdowns seems to be the loading of the kernel and initramfs after the OS grub.cfg is loaded. There is no serial console output at this point.

The average boot time (from pressing the power button to the GDM login screen) is ~55 seconds. The actual kernel boot time is usually ~6 seconds according to dmesg. It takes coreboot+GRUB ~49 seconds to get to the point of booting a kernel.

This is more long-term, but we should probably think about internationalization so that librecore has more accessibility.

Tested on both the ga-g41m-es2l and the ga-945gcm-s2l.

If I understand correctly, these NIC's have to be reset, which hard-codes a MAC address. This is not really ideal. Although the workaround is relatively easy ('spoof' the real MAC), it would be nice if this would just work.

The typedef was a stupid solution to the original problem and has now become like a cancer that has spread across the tree. Push the problem out the tree starting from the outside working our way in.

On the ga-g41m-es2l, reboot requires a hard reset. This drops the PSU's 5V rail, while storage devices expect it to remain on. This is a bug in raminit code for x4x.

SSD controllers may lie about cache flushes and corrupt data. Hard disks will do emergency retracts, which may damage them eventually.

I have tested this with many different storage devices (SSD's and HDD's), and data corruption occurs only on some, but not all. Kingston SSDNow V300's fail the most.

The undock button on the left side of the X200 Ultrabase does not respond to keypresses.

Fn + F9 does work as intended though, so the undocking process itself is not broken.

While DisplayPort works fine in GNU/Linux, the external monitor remains black in GRUB.
It would be nice if GRUB would also output to an external DP monitor when docked.

This probably shares code with issue #13.

It breaks the crossgcc target

When docking an X200 with an external DisplayPort monitor, the latter isn't automatically attached. udevadm monitor doesn't show a single drm-related event.

Wten undocking an X200 with an external DisplayPort monitor, the latter isn't automatically detached either. udevadm monitor doesn't show a single drm-related event.

After (un)docking, one has to run xrandr to force detection of the DisplayPort output. Luckily, this can be bound to a hotkey as it works as a regular user.

However, with Wayland, xrandr no longer works at all..

I have found that running echo detect > /sys/class/drm/card0-HDMI-A-2/status as root forces re-detection of the DP link state, but this can't be run easily, and certainly not as a hotkey command.

Ideally, the (un)docking ACPI code should trigger drm udev events so the kernel automatically enables and disables DisplayPort output. This is much needed with Wayland at least.

    [    0.240311] mtrr: your CPUs had inconsistent fixed MTRR settings
    [    0.240313] mtrr: your CPUs had inconsistent variable MTRR settings
    [    0.240314] mtrr: your CPUs had inconsistent MTRRdefType settings
    [    0.240316] mtrr: probably your BIOS does not setup all CPUs.
    [    0.240317] mtrr: corrected configuration.

I'm unsure if this is related to issue #3, or if it is fixed by adding MAX_CPUS=4 to Kconfig.

Regardless of the DIMM (i.e. even with PC2-6400 or PC2-8500 modules), the RAM frequency never exceeds 667MHz. Up to 800MHz should be supported, as is printed on the board.

When you remove 3rdparty, you get these kinds of errors building coreboot

    CC         bootblock/arch/x86/mmap_boot.o
In file included from src/include/cbfs.h:19:0,
                 from src/arch/x86/mmap_boot.c:17:
src/commonlib/include/commonlib/cbfs.h:21:21: fatal error: vb2_api.h: No such file or directory
compilation terminated.

I have a stash of Silicon Image Orion ADD2 cards. These work fine in GNU/Linux (both on i945 and g41), but remain black in coreboot, both in SeaBIOS and in GRUB.

It would be really nice if these cards would work in coreboot as well.

This is more of a suggestion for the future: to leave Github for a more decentralized service. Maybe a self-hosted gogs/gitlab instance would work too.

https://notabug.org/

On the Lenovo T400 and T500, the Advanced Mini Dock hardly works. Only charging and VGA / DVI work, but USB and RS232 do nothing. I haven't tested ethernet yet, but it probably doesn't work either.

The eject button also doesn't work, nor does the LED indicator.

The remaining issues are here:

librecore]$ git grep '\#include' src/*bridge | grep -E '\.c("|>)'
src/northbridge/amd/agesa/family12/northbridge.c:#include "amdfam12_conf.c"
src/northbridge/amd/agesa/family14/northbridge.c:#include "amdfam14_conf.c"
src/northbridge/amd/amdfam10/amdfam10.h:#include "inline_helper.c"
src/northbridge/amd/amdfam10/bootblock.c:#include "northbridge/amd/amdfam10/early_ht.c"
src/northbridge/amd/amdk8/bootblock.c:#include "northbridge/amd/amdk8/early_ht.c"
src/northbridge/amd/amdk8/raminit_f.c:#include "f_pci.c"
src/northbridge/amd/amdk8/raminit_f.c:#include "raminit_f_dqs.c"
src/northbridge/amd/amdk8/raminit_f.c:#include "exit_from_self.c"
src/northbridge/amd/amdk8/raminit_test.c:#include "console/console.c"
src/northbridge/amd/amdk8/raminit_test.c:#include "raminit.c"
src/northbridge/amd/amdk8/raminit_test.c:#include "../../../lib/generic_sdram.c"
src/northbridge/intel/i82830/raminit.c:#include "lib/debug.c"
src/northbridge/intel/i945/raminit.c:#include "rcven.c"
src/northbridge/intel/nehalem/raminit.c:#include "raminit_fake.c"
src/northbridge/intel/nehalem/raminit.c:#include "raminit_tables.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/translator_ddr2_init.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/early_smbus.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/early_serial.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/dram_util.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/detection.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/freq_setting.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/timing_setting.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/drdy_bl.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/driving_setting.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/clk_ctrl.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/dev_init.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/rank_map.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/dqs_search.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/final_setting.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/uma_ram_setting.c"
src/northbridge/via/vx800/raminit.c:#include "northbridge/via/vx800/dram_init.c"
src/southbridge/amd/agesa/hudson/reset.c:#include <northbridge/amd/amdk8/reset_test.c>
src/southbridge/amd/agesa/hudson/sm.c:#include "smbus.c"
src/southbridge/amd/amd8111/reset.c:#include "../../../northbridge/amd/amdk8/reset_test.c"
src/southbridge/amd/pi/hudson/reset.c:#include <northbridge/amd/amdk8/reset_test.c>
src/southbridge/amd/pi/hudson/sm.c:#include "smbus.c"
src/southbridge/amd/sb600/early_setup.c:#include "smbus.c"
src/southbridge/amd/sb600/reset.c:#include <northbridge/amd/amdk8/reset_test.c>
src/southbridge/amd/sb600/sm.c:#include "smbus.c"
src/southbridge/amd/sb800/early_setup.c:#include "smbus.c"
src/southbridge/amd/sb800/reset.c:#include <northbridge/amd/amdk8/reset_test.c>
src/southbridge/amd/sb800/sm.c:#include "smbus.c"
src/southbridge/broadcom/bcm5785/reset.c:#include "../../../northbridge/amd/amdk8/reset_test.c"
src/southbridge/nvidia/ck804/reset.c:#include "../../../northbridge/amd/amdk8/reset_test.c"
src/southbridge/nvidia/mcp55/reset.c:#include "../../../northbridge/amd/amdk8/reset_test.c"
src/southbridge/sis/sis966/reset.c:#include "../../../northbridge/amd/amdk8/reset_test.c"

Standardize on using uint8_t, uint16_t and uint32_t over the mixture of them and u8, u16 and u32 usage. Also stop using char as a uint8_t.

When suspending a 945GC board, all goes well. But resuming results in a double reset followed by a cold boot, which may or may not hang.

It would be nice if we could either fix this, or avoid suspend from being used in the first place (tell the kernel S3 is unsupported).

When using the GRUB payload on the ga-945gcm-s2l, ATA disks aren't detected at all. Running ls only shows USB devices.

Probably GRUB misses a required module for this board.

A hybrid driver was merged to handle all Lenovo laptops with hybrid graphics, but it fails to configure the display mux correctly on gm45 laptops with hybrid graphics. https://review.coreboot.org/12896

The results is that neither in coreboot/payload, nor in Linux the display works. This a potential fix but I can't test it due to the lack of actual hardware: https://review.coreboot.org/16354. (Hardware needs to have an Ati card)

According to @ArthurHeymans in issue #17, unlike 945gc (where it doesn't work), resume from S3 isn't implemented at all on x4x. We should try to get this to work eventually.

Tested on both the ga-g41m-es2l and the ga-945gcm-s2l: The fan runs at a fixed level, no matter the system load.

According to Gigabyte, the vendor BIOS is able to overclock the FSB to 1333MHz. If coreboot can do the same, we would be able to use Core 2 Duo E8xxx chips on these boards.

800MHz fsb does not work on gm45, which causes SU (ultra low voltage?) CPU on x200s and x200t to not boot. Fixing this would also allow the (very high end) thinkpad x301 to be ported, which exclusively uses SU CPUs.

A possible test setup for this would be a lenovo T400, fix the dock code so that the SIO can be used / just use EHCI debug. Find a crappy cheap 800MHz fsb CPU that fits the socket and do the usual raminit debugging.
Fixing the dock would be more interesting since this would allow to use SerialICE.