Intel DRM trouble on N3160

I seem to be having troubles on FreeBSD 14.3-RELEASE with N3160 and Intel DRM. Both drm-515-kmod and drm-61-kmod.

It seems to act like Baytrail Graphics which also bomb out on newer versions of FreeBSD.
Installed gpu-firmware-kmod.

Xorg.0.log snip:
Code:
[   162.270] (II) modeset(0): Modeline "640x480"x75.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[   162.270] (II) modeset(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[   162.270] (II) modeset(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[   162.270] (II) modeset(0): Modeline "720x400"x70.1   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[   162.270] (II) modeset(0): EDID for output DP-2
[   162.274] (II) modeset(0): EDID for output HDMI-2
[   162.274] (II) modeset(0): Output eDP-1 connected
[   162.274] (II) modeset(0): Output DP-1 disconnected
[   162.274] (II) modeset(0): Output HDMI-1 connected
[   162.274] (II) modeset(0): Output DP-2 disconnected
[   162.274] (II) modeset(0): Output HDMI-2 disconnected
[   162.274] (II) modeset(0): Using spanning desktop for initial modes
[   162.274] (II) modeset(0): Output eDP-1 using initial mode 1366x768 +0+0
[   162.274] (II) modeset(0): Output HDMI-1 using initial mode 1920x1080 +1366+0
[   162.274] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[   162.274] (==) modeset(0): DPI set to (96, 96)
[   162.274] (II) Loading sub module "fb"
[   162.274] (II) LoadModule: "fb"
[   162.274] (II) Module "fb" already built-in
[   162.274] (II) UnloadModule: "scfb"
[   162.274] (II) Unloading scfb
[   162.274] (II) UnloadModule: "vesa"
[   162.274] (II) Unloading vesa
[   162.295] (EE)
Fatal server error:
[   162.295] (EE) Caught signal 6 (Abort trap). Server aborting
[   162.295] (EE)
[   162.295] (EE)
Please consult the The X.Org Foundation support
     at http://wiki.x.org

I am wondering if it is just me? I even made a config file with PCI address after it failed to auto work.

I thought N3060 was Intel Braswell Gen4 and newer than Baytrail and would work.
Code:
vgapci0@pci0:0:2:0:    class=0x030000 rev=0x35 hdr=0x00 vendor=0x8086 device=0x22b1 subvendor=0x8086 subdevice=0x7270
    vendor     = 'Intel Corporation'
    device     = 'Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller'
    class      = display
    subclass   = VGA
I manually load the i915drm driver and it changes to frambuffer fine and gets new resolution. No errors on load.
It just fails startx with a modesetting error. Same message as Baytrail Graphics show on newer versions.
 
Do you have kld_list="${kld_list} i915kms " in your /etc/rc.conf?
Or do you have a line starting with kld_list= and including i915kms in your /etc/rc.conf?

If you're sure whichever is, aren't there any typo?
 
I have a feeling this generation of Intel has been swept away. The docs say SandyBridge and greater but that is not accurate from my findings.

I had been starting manually because of prior problems. Nice to see loading of module.
kldload i915kms

I will include the module in rc.conf and see if it changes anything.

Next I am quickly going to try 13.5-RELEASE which I bet works OOB.

I wonder about stuff like EDID and might try another monitor. Maybe it don't like 1366x768 of my test monitor.
I snipped earlier but handshake looks good and monitor is found ok in Xorg.0.log

I might try another monitor for kicks. Maybe something so simple.
 
I installed 13.5-RELEASE and drm-510-kmod and I have Openbox running.
There are defiantly some older chips not working above drm-510-kmod.
Not Intel Core chips though. I have other Gen4 working. Just some of the budget ones it seems.
My take is Atoms and Celerons. 2013-2016 are not working right with newer drm.
scfb works fine though.
 
Reading my Xorg log over and over trying various things with drm-515-kmod & drm-61-kmod I could help to nail it down to this::

Intel Mode-Setting is being setup OK but there comes a stage where it unloads scfb and then vesa module because not needed and then it crashes.

You can see it in the above Xorg snippet.
 
I tried all kind of iterations of conf files.
/usr/local/etc/X11/xorg.conf.d/20-intel.conf

Handbook says driver = intel and that is outdated. You want driver = modesetting
driver = intel does work with xf86-video-intel installed but it uses llvm pipe and scores same as scfb. Software rendering.

Also played with adding PCI bus address with no avail.

scfb works but requires a conf file because Xorg bombing on drm. That might work if I deleted drm driver.
 
Fatal server error: [ 162.295] (EE) Caught signal 6 (Abort trap). Server aborting
Same error after upgrading to FreeBSD 15.0 using generic Intel card when attempting to start xdm.

kldstat showed my drm video drivers loaded, and that part worked with the consle.
You want driver = modesetting
driver = intel does work with xf86-video-intel installed but...
Installing x11-drivers/xf86-video-intel worked as well for my Intel card to get xdm & Xorg running.

Also, for anyone who updated to FreeBSD 15.0 or any other version.
 
Is the firmware matching your GPU loaded?
If you're not sure enough, does fwget(8) fetch and install matching firmware?
As for mine, fwget:
No firmware packages to install
That's after removing my drm kmod driver to check. Perhaps this might work with GPU hardware which needs newer and dedicated drivers, which the newer drivers have flavors for each hardware.

graphics/drm-515-kmod is the one that works for generic Intel video drivers on FreeBSD 15.0.
 
I think you may have reached the issue. There is no firmware that has every been needed on these chips from what I understand.
Like I mentioned earlier on 13.5-RELEASE they work fine with drm-510-kmod. No GPU firmware driver package installed at all.
Nothing past drm-510-kmod version works.

When you do a new FreeBSD installation on 14.3 the system detects Graphics Card and offers to download a firmware. Same as Wifi.
But on Baytrail+ N3xxx it does not show any video firmware available to download.
 
I would like to point to a fix made to the graphics/drm-510-kmod port in 2023.
Down at bottom COMMIT HISTORY:

5.10.163_7

But notice the fix.
Code:
graphics/drm-510-kmod: Update to drm_v5.10.163_6

- Fix i915kms on Baytrail/Valleyview hardware

Sponsored by:    Beckhoff Automation GmbH & Co. KG
MFH:        2023Q2

Fix i915kms on Baytrail/Valleyview hardware

I bet these N3060,N3150, N3160 are all ValleyView.
I knew Baytrail was broke after drm-510 but was surprised to see next gen N3xxx broke too.

I looked up Valleyview series. I see a reference to ValleyView2 and I think that is it. The N3xxx were V2 of the BYT run.
It looks like the name was early and dropped. If you look at the first batch of Baytrail.

Some places state ValleyView was graphics core codename.

Gentoo has a great chart showing versions. Footnotes valuable.
So we are lumped with GEN7 IvyCreek it seems.

From Wikipedia there are several different graphics cores involved with N3XXX Mobile Processor Braswell series chips. HD Graphics 400 and HD Graphics Braswell.

Its interesting dangling at EOL... No doubt they are old...Still useful without X11.
What was manu@ fix for drm-510 and was that the end of the road....
I would like to buy him a beer and hear his life stories...
 
I forgot to look at the ports patch file. It is not large or hard to read.
I do wonder what part fixed Baytrail/Vallview problems. Maybe all of it.

/usr/ports/grraphics/drm-510-kmod/files
Code:
--- drivers/gpu/drm/drm_os_freebsd.c.bak    2022-11-05 15:37:52.826643000 -0400
+++ drivers/gpu/drm/drm_os_freebsd.c    2022-11-05 15:38:25.740620000 -0400
@@ -202,11 +202,15 @@
 #if __FreeBSD_version >= 1301505
 #if __FreeBSD_version >= 1400058
 DRIVER_MODULE(iicbus, drmn, iicbus_driver, NULL, NULL);
+#if defined(__amd64__) || defined(__aarch64__) || defined(__i386__)
 DRIVER_MODULE(acpi_iicbus, drmn, acpi_iicbus_driver, NULL, NULL);
+#endif
 #else
 DRIVER_MODULE(iicbus, drmn, iicbus_driver, iicbus_devclass, NULL, NULL);
+#if defined(__amd64__) || defined(__aarch64__) || defined(__i386__)
 DRIVER_MODULE(acpi_iicbus, drmn, acpi_iicbus_driver, iicbus_devclass, NULL,
     NULL);
+#endif
 #endif
 MODULE_DEPEND(drmn, iicbus, IICBUS_MINVER, IICBUS_PREFVER, IICBUS_MAXVER);
 MODULE_DEPEND(drmn, iic, 1, 1, 1);
 
I understand the frustration. I was so excited about the new 32-bit EFI support because I have a Baytrail convertible tablet that uses a 32-bit EFI with a 64-bit CPU. But after installing I realized that GPU support had been dropped. So now I can install FreeBSD but the graphic performance is very limited. Before I was using OpenBSD and playing UrbanTerror and it worked smashingly. We gotta get that Baytrail support back! :(
 
That was why I was looking at the patch. See what was changed and see if it (hand) applies to newer DRM drivers.

I guess its time to put this problem in writing with a PR. See what evadot says
 
Back
Top