Stumped on Ryzen 2400G on FreeBSD 12-STABLE

D

drussell

Hi, folks....

I'm mystified on this one since I know it is possible to get the GPU on these working now... Any suggestions?

This is on 12-STABLE, compiled from source, most recently about 48 hours ago (upgrade from 11.2-PRERELEASE, before VEGA graphics were supported with the 4.16 drm merge), rebuilt all ports, etc. Although I am willing to entertain the possibility that there is something wrong with the install, everything else seems to work flawlessly in 12-STABLE, I just still can't seem to get the GPU online properly.

I'm currently downloading the 12-STABLE 20190404 snapshot to do a fresh install to another disk for additional testing.

The board is an ASUS Prime B350-PLUS, which I have tried with the last few BIOS versions up to and including the latest from 3 days ago with the latest microcode updates. Memory speed has been backed off from the perfectly stable 3200 to stock 2133. I have twiddled every knob I can think of in the BIOS to no avail, although I suspect either I must be missing something or this is a faulty BIOS implementation somehow.

The original install was on a GPT-partitioned Intel SSD, booting EFI. I know about the issues with amdgpu on EFI boots, so of course I tried disabling the console via the hw.syscons.disable=1 loader.conf tunable and while it does disable the console, as soon as the screen would normally clear to start the kernel boot messages (where I just have the EFI framebuffer debug info still on the screen,) the top few lines of the screen go yellow, then patterns, then yellow.... then I get nothing further from the console, regardless of whether I try to kldload amdgpu later or not. (I can usually still wait for it to boot and then SSH in, although every few boots it just crashes and reboots.)

OK, I think, "must be something with virtualization or IOMMU...." so I disable in the BIOS... No change.

The latest BIOS has an option to set the framebuffer size... OK, set manually... No change

OK, screw EFI, this is supposed to Just Work on a legacy boot, so I try to force legacy mode in the BIOS, but of course it can't boot due to it having been set up GPT... Grrrr.... :)

OK, grab another different disk, MBR partition it, boot0... do a dump -0 -f - / | restore rf - onto new disk...

Surely this will work, right? ...
Boot legacy VT(vga) and it doesn't work either!! Double GRRRRR.... :)

No joy.... (Even with console enabled or disabled) even my legacy, non-EFI mode boot, when starting amdgpu, it just goes like this:
(cough... sputter...wheeze...)
Code: 
Apr  7 12:47:08 some-hostname kernel: [drm] amdgpu kernel modesetting enabled.
Apr  7 12:47:08 some-hostname kernel: drmn0: <drmn> on vgapci0
Apr  7 12:47:08 some-hostname kernel: vgapci0: child drmn0 requested pci_enable_io
Apr  7 12:47:08 some-hostname syslogd: last message repeated 1 times
Apr  7 12:47:08 some-hostname kernel: [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1043:0x876B0xC6).
Apr  7 12:47:08 some-hostname kernel: [drm] register mmio base: 0xFCC00000
Apr  7 12:47:08 some-hostname kernel: [drm] register mmio size: 524288
Apr  7 12:47:08 some-hostname kernel: [drm] PCI I/O BAR is not found.
Apr  7 12:47:09 some-hostname kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_gpu_info.bin
Apr  7 12:47:09 some-hostname kernel: [drm] probing gen 2 caps for device 1022:15db = 700d03/e
Apr  7 12:47:09 some-hostname kernel: [drm] probing mlw for device 1002:15dd = 400d03
Apr  7 12:47:09 some-hostname kernel: [drm] VCN decode is enabled in VM mode
Apr  7 12:47:09 some-hostname kernel: [drm] VCN encode is enabled in VM mode
Apr  7 12:47:09 some-hostname kernel: [drm] BIOS signature incorrect 0 0
Apr  7 12:47:09 some-hostname kernel: ATOM BIOS: 113-RAVEN-113
Apr  7 12:47:09 some-hostname kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment sizeis 9-bit
Apr  7 12:47:09 some-hostname kernel: drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
Apr  7 12:47:09 some-hostname kernel: drmn0: GTT: 1024M 0x000000F500000000 - 0x000000F53FFFFFFF
Apr  7 12:47:09 some-hostname kernel: Successfully added WC MTRR for [0xe0000000-0xefffffff]: 0;
Apr  7 12:47:09 some-hostname kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Apr  7 12:47:09 some-hostname kernel: [drm] RAM width 128bits UNKNOWN
Apr  7 12:47:09 some-hostname kernel: [drm:amdgpu_ttm_global_init] Failed setting up TTM memory accounting subsystem.
Apr  7 12:47:09 some-hostname kernel: [drm:amdgpu_device_ip_init] sw_init of IP block <gmc_v9_0> failed -12
Apr  7 12:47:09 some-hostname kernel: drmn0: amdgpu_device_ip_init failed
Apr  7 12:47:09 some-hostname kernel: drmn0: Fatal error during GPU init
Apr  7 12:47:09 some-hostname kernel: [drm] amdgpu: finishing device.
Apr  7 12:47:09 some-hostname kernel: vgapci0: child drmn0 requested pci_disable_io
Apr  7 12:47:09 some-hostname syslogd: last message repeated 1 times
Apr  7 12:47:09 some-hostname kernel: device_attach: drmn0 attach returned 12

The last thing actually on the actual screen of the console when it is enabled is the line:
"Apr 7 12:47:08 some-hostname kernel: [drm] PCI I/O BAR is not found."
Things like "BIOS signature incorrect 0 0" make me suspect that either the modules with the firmware are wrong somehow (I have tried the binary versions using pkg install for both the drm kmod and the firmware ports in case it was something with my source trees... No change.) causing the GPU firmware to not load or initialize properly or something in the BIOS of the machine is gibbled and not setting up the GPU's memory ranges, etc. correctly or whatnot.

I'm trying a fresh 12-STABLE install now, will update with any progress.
I'm tearing my hair out on this one...

Any bright ideas?
 
UPDATE: Apparently even more sleuthing will be required...

On a legacy MBR-style installation of the 20190404 snapshot, I now get slightly different behavior.

It looks like the module loads "more" correctly when I kldload amdgpu after booting, but as soon as it loads, I lose my console, the screen goes blank, and my ssh session slows to a crawl, then closes after about a minute, forcing a hard reset to be necessary to recover. (There is still some intermittent disk activity according to the HDD light but even a power switch click does not cause a shutdown even when left for 5+ minutes and I don't have cables for a serial console close at hand right this moment... if that would even help me... :) )

The amdgpu loading messages from the test snapshot installation:
Code: 
Apr  7 08:43:29 test su[925]: drussell to root on /dev/ttyv2
Apr  7 08:44:16 test pkg-static[937]: pkg-1.10.5_5 installed
Apr  7 08:44:47 test pkg[949]: gpu-firmware-kmod-g20190219 installed
Apr  7 08:44:47 test pkg[949]: drm-fbsd12.0-kmod-4.16.g20190305 installed
Apr  7 08:46:28 test kernel: [drm] amdgpu kernel modesetting enabled.
Apr  7 08:46:28 test kernel: drmn0: <drmn> on vgapci0
Apr  7 08:46:28 test kernel: vgapci0: child drmn0 requested pci_enable_io
Apr  7 08:46:28 test syslogd: last message repeated 1 times
Apr  7 08:46:28 test kernel: [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1043:0x876B 0xC6).
Apr  7 08:46:28 test kernel: [drm] register mmio base: 0xFCC00000
Apr  7 08:46:28 test kernel: [drm] register mmio size: 524288
Apr  7 08:46:28 test kernel: [drm] PCI I/O BAR is not found.
Apr  7 08:46:29 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_gpu_info.bin
Apr  7 08:46:29 test kernel: [drm] probing gen 2 caps for device 1022:15db = 700d03/e
Apr  7 08:46:29 test kernel: [drm] probing mlw for device 1002:15dd = 400d03
Apr  7 08:46:29 test kernel: [drm] VCN decode is enabled in VM mode
Apr  7 08:46:29 test kernel: [drm] VCN encode is enabled in VM mode
Apr  7 08:46:29 test kernel: [drm] BIOS signature incorrect 0 0
Apr  7 08:46:29 test kernel: ATOM BIOS: 113-RAVEN-113
Apr  7 08:46:29 test kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
Apr  7 08:46:29 test kernel: drmn0: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used)
Apr  7 08:46:29 test kernel: drmn0: GTT: 1024M 0x000000F500000000 - 0x000000F53FFFFFFF
Apr  7 08:46:29 test kernel: Successfully added WC MTRR for [0xe0000000-0xefffffff]: 0;
Apr  7 08:46:29 test kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Apr  7 08:46:29 test kernel: [drm] RAM width 128bits UNKNOWN
Apr  7 08:46:29 test kernel: [TTM] Zone  kernel: Available graphics memory: 16461836 kiB
Apr  7 08:46:29 test kernel: [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
Apr  7 08:46:29 test kernel: [TTM] Initializing pool allocator
Apr  7 08:46:29 test kernel: [drm] amdgpu: 512M of VRAM memory ready
Apr  7 08:46:29 test kernel: [drm] amdgpu: 3072M of GTT memory ready.
Apr  7 08:46:29 test kernel: i_size_write unimplemented
Apr  7 08:46:29 test kernel: [drm] GART: num cpu pages 262144, num gpu pages 262144
Apr  7 08:46:29 test kernel: [drm] PCIE GART of 1024M enabled (table at 0x000000F400800000).
Apr  7 08:46:30 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_asd.bin
Apr  7 08:46:30 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_pfp.bin
Apr  7 08:46:30 test kernel: Timeout initializing vt_vga
Apr  7 08:46:31 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_me.bin
Apr  7 08:46:31 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_ce.bin
Apr  7 08:46:31 test kernel: Timeout initializing vt_vga
Apr  7 08:46:32 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_rlc.bin
Apr  7 08:46:32 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_mec.bin
Apr  7 08:46:33 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_mec2.bin
Apr  7 08:46:33 test kernel: i_size_write unimplemented
Apr  7 08:46:33 test syslogd: last message repeated 9 times
Apr  7 08:46:33 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_sdma.bin
Apr  7 08:46:33 test kernel: [drm] use_doorbell being set to: [true]
Apr  7 08:46:33 test kernel: i_size_write unimplemented
Apr  7 08:46:34 test kernel: drmn0: successfully loaded firmware image with name: amdgpu/raven_vcn.bin
Apr  7 08:46:34 test kernel: [drm] Found VCN firmware Version: 1.73 Family ID: 18
Apr  7 08:46:34 test kernel: i_size_write unimplemented
Apr  7 08:46:34 test syslogd: last message repeated 2 times
Apr  7 08:46:34 test kernel: [drm:construct] construct: Invalid Connector ObjectID from Adapter Service for connector index:2! type 0 expected 3
Apr  7 08:46:34 test kernel: [drm] Display Core initialized with v3.1.27!
Apr  7 08:46:34 test kernel: [drm] Connector HDMI-A-1: get mode from tunables:
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.modes.HDMI-A-1
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 08:46:34 test kernel: [drm] Connector DVI-D-1: get mode from tunables:
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.modes.DVI-D-1
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 08:46:34 test kernel: [drm] SADs count is: -2, don't need to read it
Apr  7 08:46:34 test kernel: [drm] Connector DP-1: get mode from tunables:
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.modes.DP-1
Apr  7 08:46:34 test kernel: [drm]   - kern.vt.fb.default_mode
Apr  7 08:46:34 test kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Apr  7 08:46:34 test kernel: [drm] Driver supports precise vblank timestamp query.
Apr  7 08:47:21 test kernel: [drm:amdgpu_ring_write] amdgpu: writing more dwords to the ring than expected!
 
roccobaroccoSC said:
If you just want to install the OS, use 12.0-RELEASE and not STABLE.
Click to expand...

I've been using FreeBSD since the 1.1 days on a 386 with no math co-processor.

I'm well aware of the branch structure and the appropriate uses for -RELEASE, -STABLE and -CURRENT.
Believe me, I use them all in various places. ;)

I think it was the day that I first downloaded 1.1.5.1 that I went to the dealer and got my first 486 board to actually have a co-processor while it was busy downloading at 28.8k from wcarchive. :)
Also, I have a tutorial made for Threadripper 1 + Radeon RX 580. The thread is here, maybe you'll find something useful for your case: https://forums.freebsd.org/threads/rx-580-supported.65905/#post-396194
I am not aware if VEGA has already support in FreeBSD. Last year when I researched the topic it seemed unsupported so I did not buy one and went for RX 580.
Click to expand...

Indeed, that thread of yours was one of the ones that I was following last summer when it first became possible to make it work. It now (as of very recently) usually, hopefully, basically just works out-of-the-box on the recent builds and the appropriate graphics/drm-fbsd11.2-kmod, graphics/drm-fbsd12.0-kmod and graphics/drm-current-kmod ports available in the ports tree.

The matrix is actually quite nice and green now! :) as per the link below:

For example, this success report, just yesterday here on the forum:
Thread are-raven-ridge-ryzen-5-2400g-graphics-supported-on-freebsd.70273

I'm just confused as to why I cannot get it to work in this particular case.
I've been trying to get this one to work properly for several days to no avail.

All suggestions are appreciated! Thanks!
 
Sure, 1 I don't know you so I could not have known about your experience ;). 2 I saw you were trying to bring a VEGA Raven to life and you want to get the latest and greatest, so I wanted to edit my initial response but my Internet connection died :). So sorry for the misplaced response.

Regarding the new support matrix - COOL! Kudos to FreeBSD. I have not looked there for more than 6 months to be honest, but WOW! Great work! Last year much of it was in progress.

And a suggestion maybe - why don't you respond to Asdew in his or her thread? They'll get a notification and would probably share the installation steps and configuration? Your system is quite similar, if I see correctly.
 
Just a quick UPDATE:

- Success with the same 2400G and original installation in an ASUS ROG STRIX B450-F GAMING.

(As an aside, I am purposely using this same chip because this may be a very early variant of the 2400G, as I had pre-ordered it even before the Ryzen 2xG release just for this customer's workstation. This is the daily driver machine for a gentleman in his 70s. It is here in the shop for service. Apparently he's now a FreeBSD desktop convert, as he never even seems to load his Windows 7 VM anymore. According to the file dates, the VM hadn't even been loaded in over 6 months! :) )

Much more detail to follow, many red herrings including some kind of strange failure mode on the B350-PLUS. We may have to start a thread with a list of known good hardware and horrible failure wall of shame, although I have still not ruled out the possibility of getting it running on the B350-PLUS. I'm currently running quite an old BIOS version on the B450-F GAMING.

I will post MUCH more detail as soon as I have a moment to collect and collate all the relevant information.
 
drussell hey, any news? I'm trying to get that driver working on Athlon 200GE and GIGABYTE B450M S2H with no luck (see this thread)
Just getting black screen after modules are loaded.. any help will be appreciated!
 
For posterity, in case any Google pilgrim finds this thread when stumped by Ryzen / Vega issues:
Aorus B450 ITX with a Ryzen 2400G, using the baked-in Vega GPU.
Booting in BIOS mode, 13.0-CURRENT works flawlessly with DRM kmod built from /usr/ports/graphics/drm-devel-kmod (drm-devel-kmod-5.0.g20200320)
As things stand right now, I've been doing some random testing with DRM / ZFS etc, and things are running smoothly with just a bit of spam to the console related to AMDGPU / DRM features not currently implemented. I'll be reporting back in the next 24hrs or so, free time permitting, to see what success I may have in full UEFI mode.
Relevant *.conf's
/boot/loader.conf
hw.syscons.disable=1
kern.vty=vt
hw.vga.textmode=1

/etc/rc.conf
kld_list="/boot/modules/amdgpu.ko"
(you can opt for just "amdgpu" as well, instead of the full path. This is just to make sure it initially loads the correct specific module)

Edit: I can CONFIRM that all works well when booted in UEFI mode. Not that it should matter, but installed either to M.2 NVMe PCIe / SATA *or* to any SATA port, all is well. The slight bit of spam to the console, regarding implemented / unimplemented 'features' persists, but hardly a bother.
As a bonus: switching to a Aorus X570 ITX board with this same CPU, has resulted in the same perfectly functional setup.

Eyecandy:
FreeBSD-13.0-CURRENT-Ryzen.2400G.png


FreeBSD-13.0-CURRENT-Ryzen.2400G-2.png

Toodles!
 
Last edited:
You must log in or register to reply here.
Back
Top