Questions about kernel driver for Radeon r7 m265
Hello, I have a laptop that is using the NetBSD9.2 amd64 system. The laptop has a radeon r7 m265 graphics card on it. I am trying to revise the code for the kernel driver for the radeon graphics card that I have on my laptop. I have a question regarding the bus_space_* functions. Would this be the appropriate list to ask? Regards, Riza Dindir
Trying to access the Expansion ROM of a video card
Hello,
I am using NetBSD 9.2 (amd64). I have a laptop that has a radeon r7
m265 video card (vendor 0x1002, product 0x6604). The system does not
recognize this card. It fails with this message:
kern error:
[drm:(/export/netbsd/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_bios.c:725)radeon_get_bios]
*ERROR* Unable to locate a BIOS ROM
radeon0: autoconfiguration error: error: Fatal error during GPU init
radeon0: autoconfiguration error: unable to attach drm: 22
I wanted to see if I can read the bios of that card and added some
test functions to the file mentioned above. The code is as such:
pci_conf_capture(rdev->pdev->pd_pa.pa_pc, rdev->pdev->pd_pa.pa_tag,
&conf);
address = PCI_MAPREG_ROM_ADDR(conf.reg[12]);
size = PCI_MAPREG_ROM_SIZE(address);
DRM_INFO("rom addr: %x, rom size: %lu\n", address, size);
result = bus_space_map(rdev->pdev->pd_pa.pa_memt,
PCI_MAPREG_ROM_ADDR(address),
size, BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE, &romh);
DRM_INFO("result of bus_space_map(): %d\n", result);
bios = (uint8_t *)bus_space_vaddr(rdev->pdev->pd_pa.pa_memt,
romh);
DRM_INFO("bios: %p\n", bios);
if (bios != NULL) {
DRM_INFO("bios[0]: %X, bios[1]: %X\n", bios[0], bios[1]);
} else {
DRM_INFO("bios was NULL\n");
}
The bus_space_map function returns code 35. Maybe I am doing something
wrong in the code when I try to read the "expansion rom" of the pci
card. Anyone has an idea? How should I read the "expansion rom" of a
PCI card?
Best Regards,
Riza Dindir
Re: Trying to access the Expansion ROM of a video card
Hello Michael,
On Thu, Oct 21, 2021, 19:55 Michael wrote:
> Hello,
>
> On Wed, 20 Oct 2021 08:26:25 +0000
> Riza Dindir wrote:
>
> > I am using NetBSD 9.2 (amd64). I have a laptop that has a radeon r7
> > m265 video card (vendor 0x1002, product 0x6604). The system does not
> > recognize this card. It fails with this message:
> >
> > kern error:
> [drm:(/export/netbsd/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_bios.c:725)radeon_get_bios]
> > *ERROR* Unable to locate a BIOS ROM
> > radeon0: autoconfiguration error: error: Fatal error during GPU init
> > radeon0: autoconfiguration error: unable to attach drm: 22
> >
> > I wanted to see if I can read the bios of that card and added some
> > test functions to the file mentioned above. The code is as such:
> >
> > pci_conf_capture(rdev->pdev->pd_pa.pa_pc, rdev->pdev->pd_pa.pa_tag,
> > &conf);
> >
> > address = PCI_MAPREG_ROM_ADDR(conf.reg[12]);
> > size = PCI_MAPREG_ROM_SIZE(address);
> > DRM_INFO("rom addr: %x, rom size: %lu\n", address, size);
> >
> > result = bus_space_map(rdev->pdev->pd_pa.pa_memt,
> > PCI_MAPREG_ROM_ADDR(address),
> > size, BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE, &romh);
> > DRM_INFO("result of bus_space_map(): %d\n", result);
> >
> > bios = (uint8_t *)bus_space_vaddr(rdev->pdev->pd_pa.pa_memt,
> > romh);
> > DRM_INFO("bios: %p\n", bios);
> > if (bios != NULL) {
> > DRM_INFO("bios[0]: %X, bios[1]: %X\n", bios[0], bios[1]);
> > } else {
> > DRM_INFO("bios was NULL\n");
> > }
> >
> > The bus_space_map function returns code 35. Maybe I am doing something
> > wrong in the code when I try to read the "expansion rom" of the pci
> > card. Anyone has an idea? How should I read the "expansion rom" of a
> > PCI card?
>
> Is there something sensible in the ROM BAR? If it's NULL the
>
The rom bar register has a value of fffe. That means the rim decoder is
not enabled i think.
bus_space_map() would fail. It also needs to be enabled in the BAR,
> which it may or may not be already. Then pray that your chip has
>
You mean the first bit (bit 0) should be 1 to enable the rom. Right?
If the address is the address i gave above and the rom decoder enable is
set to true (or 1), then the bus_space_map must succeed. Will try that.
separate decoders for ROM and regular BARs - the specs allow them to
> share one which would mean you can not access the rest of the card if
> the ROM is enabled - you're meant to turn it on, copy the ROM's
> content, turn it off and run the BIOS from RAM.
> Finally, I've seen laptops with no separate graphics BIOS at all...
>
> have fun
> Michael
>
Re: Trying to access the Expansion ROM of a video card
Hello Matthew
On Sat, Oct 23, 2021 at 4:11 AM matthew green wrote:
>
> > I am using NetBSD 9.2 (amd64). I have a laptop that has a radeon r7
> > m265 video card (vendor 0x1002, product 0x6604). The system does not
> > recognize this card. It fails with this message:
>
> are you booting uefi or bios?
I am using UEFI.
>
> sometimes modern systems don't work properly with bios and gpus,
> not being configured properly. can you try booting uefi if not
> already?
>
> if that doesn't work, can you try booting a -current kernel?
>
> a full dmesg might also be useful -- might help identify what
> else has mapped this. (perhaps vga@something.)
Tha is probably I did not hava a bus_space_unmap in my code. And since
the system finds two radeon devices one is (0x1002, 0x1309) and the
other is (0x1002, 0x6604) it is passing the first one and failing in
the second one.
Now based on that piece of information, I have changed the code to this.
pci_conf_capture(rdev->pdev->pd_pa.pa_pc, rdev->pdev->pd_pa.pa_tag,
&conf);
address = PCI_MAPREG_ROM_ADDR(conf.reg[12]);
size = PCI_MAPREG_ROM_SIZE(address);
DRM_INFO("rom addr: %x, rom size: %lu\n", address, size);
pci_conf_write(rdev->pdev->pd_pa.pa_pc,
rdev->pdev->pd_pa.pa_tag, PCI_MAPREG_ROM,
address | PCI_MAPREG_ROM_ENABLE);
result = bus_space_map(rdev->pdev->pd_pa.pa_memt,
PCI_MAPREG_ROM_ADDR(address),
size, BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE, &romh);
if (result != 0) {
DRM_INFO("result of bus_space_map(): %d\n", result);
return;
}
bios = (uint8_t *)bus_space_vaddr(rdev->pdev->pd_pa.pa_memt,
romh);
DRM_INFO("bios: %p\n", bios);
if (bios != NULL) {
DRM_INFO("bios[0]: %x, bios[1]: %x\n", bios[0], bios[1]);
}
bus_space_unmap(rdev->pdev->pd_pa.pa_memt, romh, size);
This does map the bus space (to the pci devices memt bus_space_tag,
and gets a virtual address to the rom. But the data I read is 0xff,
0xff. I also read the first 256 bytes in that address and was getting
0xff.
The address returned is 0xe000 and the size is 113072 (128K). I
enable the rom decoder, by setting the 0th bit in the address to 1 and
writing this to the ROM BAR. Then map the bus space using the memt tag
to get a handle to the rom, which I get. After that I am getting the
virtual address using the rom handle.
Is using rdev->pdev->pd_pa.pa_memt incorrect when mapping the bus space?
What address should I write to the ROM BAR?
What address should I use with the bus_space_map call?
Is using BUS_SPACE_MAP_PREFETCHABLE in the flags in the bus_space_map
call correct? I saw this in the code for pci_map_rom, and thought that
it might need that?
>
>
> .mrg.
Regards,
Riza
Re: Trying to access the Expansion ROM of a video card
Hello Matthew, On Sat, Oct 23, 2021 at 7:44 PM matthew green wrote: > > > > a full dmesg might also be useful -- might help identify what > > > else has mapped this. (perhaps vga@something.) > > > > Tha is probably I did not hava a bus_space_unmap in my code. And since > > the system finds two radeon devices one is (0x1002, 0x1309) and the > > other is (0x1002, 0x6604) it is passing the first one and failing in > > the second one. > > you say "passing the first"? does vga@pci attach instead? > that is very likely the reason it is double mapped, and it > may be that the PCI BARs for the other are not setup for > one or the other device. I am sorry for not being clear on that. I mean the test code that I have in the radeon_bios.c (I have a couple of functions in there to test reading from the ROM), I was not doing bus_space_unmap(). And when the kernel was getting the other radeon (it finds two radeon devices) the bus_space_map() call was failing and returning code 35, which would explain why it was thinking that it had mapped that bus space. I also could not find anything regarding vga. All the vga references in the dmesg below are related to acpi. > > a dmesg would be really useful -- even if just the parts for > both radeon cards. This will be a bit long here. But here we go... The "stock kernel" when booted without disabling the radeon device is as such: Oct 24 07:28:37 mercury syslogd[211]: restart Oct 24 07:28:37 mercury /netbsd: [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, Oct 24 07:28:37 mercury /netbsd: [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, Oct 24 07:28:37 mercury /netbsd: [ 1.000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved. Oct 24 07:28:37 mercury /netbsd: [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 Oct 24 07:28:37 mercury /netbsd: [ 1.000] The Regents of the University of California. All rights reserved. Oct 24 07:28:37 mercury /netbsd: Oct 24 07:28:37 mercury /netbsd: [ 1.000] NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021 Oct 24 07:28:37 mercury /netbsd: [ 1.000] mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Oct 24 07:28:37 mercury /netbsd: [ 1.000] total memory = 15306 MB Oct 24 07:28:37 mercury /netbsd: [ 1.000] avail memory = 14834 MB Oct 24 07:28:37 mercury /netbsd: [ 1.000] WARNING: module error: module `msdos' pushed by boot loader already exists Oct 24 07:28:37 mercury /netbsd: [ 1.000] rnd: seeded with 256 bits Oct 24 07:28:37 mercury /netbsd: [ 1.000] timecounter: Timecounters tick every 10.000 msec Oct 24 07:28:37 mercury /netbsd: [ 1.000] Kernelized RAIDframe activated Oct 24 07:28:37 mercury /netbsd: [ 1.000] running cgd selftest aes-xts-256 aes-xts-512 done Oct 24 07:28:37 mercury /netbsd: [ 1.000] RTC BIOS diagnostic error 0x80 Oct 24 07:28:37 mercury /netbsd: [ 1.000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 Oct 24 07:28:37 mercury /netbsd: [ 1.030] efi: systbl at pa 8f6bef18 Oct 24 07:28:37 mercury /netbsd: [ 1.030] Acer Aspire E5-551G (V1.08) Oct 24 07:28:37 mercury /netbsd: [ 1.030] mainbus0 (root) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: RSDP 0x8FBFE014 24 (v02 ACRSYS) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: XSDT 0x8FBFE120 C4 (v01 ACRSYS ACRPRDCT 0001 0113) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: FACP 0x8FBFC000 00010C (v05 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: DSDT 0x8FBEB000 00C377 (v01 ACRSYS ACRPRDCT F000 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: FACS 0x8FB65000 40 Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: UEFI 0x8FBFD000 000236 (v01 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: HPET 0x8FBFB000 38 (v01 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: APIC 0x8FBFA000 90 (v03 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: MCFG 0x8FBF9000 3C (v01 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: ASF! 0x8FBF8000 A5 (v32 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: BOOT 0x8FBEA000 28 (v01 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: WDRT 0x8FBE9000 47 (v01 ACRSYS ACRPRDCT 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: WDAT 0x8FBE8000 0001AC (v01 ACRSYS ACRPRDCT 0001 1025 0004) Oct 24 07:28:37 mercury /netbsd: [ 1.030] ACPI: FPDT 0x8FBE6000 44 (v01 ACRSYS ACRPRD
Re: Trying to access the Expansion ROM of a video card
Hello All,
As you know I have a laptop that has amd radeon r7 m265 graphics
device (it seems there are two actually; 0x1002/0x1309 and
0x1002/0x6604). My kernel panics when I do enable radeon, not finding
any ROM.
I am using netbsd 9.2 amd64 and am using UEFI boot.
After reading kern/49964 (which had the same panic with my system -
radeon_get_bios does not find a bios) I did some testing. Here is what
I have so far.
The memory at 0xC (size 131072) starts with 0xff 0xff. So this
means that there is no valid expansion ROM here. This is what I have
done to get this dump (dd if=/dev/mem of=/tmp/bios bs=1 iseek=786432
count=131072) and to view it I used (hexdump -C /tmp/bios). If there
is anything that looks wrong let me know.
Then I have dumped the data on the two PCI devices mentioned above. To
arrive at these I did use (pcictl pci0 dump -d 1 -f 0 and pcictl pci1
dump -d 0 -f 0). Here is the outcome.
The device on pci0:1:0 is as such
PCI configuration registers:
Common header:
0x00: 0x13091002 0x0017 0x0300 0x00800010
Vendor Name: ATI Technologies (0x1002)
Device ID: 0x1309
Command register: 0x0007
.
Type 0 ("normal" device) header:
0x10: 0xe00c 0x 0xf00c 0x
0x20: 0x4001 0xf0b0 0x 0x08641025
0x30: 0xfffe0001 0x0048 0x 0x0100
Base address register at 0x10
type: 64-bit prefetchable memory
base: 0xe000
Base address register at 0x18
type: 64-bit prefetchable memory
base: 0xf000
Base address register at 0x20
type: I/O
base: 0x4000
Base address register at 0x24
type: 32-bit nonprefetchable memory
base: 0xf0b0
Cardbus CIS Pointer: 0x
Subsystem vendor ID: 0x1025
Subsystem ID: 0x0864
Expansion ROM Base Address Register: 0xfffe0001
base: 0xfffe
Expansion ROM Enable: on
Validation Status: Validation not supported
Validation Details: 0x0
Capability list pointer: 0x48
Reserved @ 0x38: 0x
Maximum Latency: 0x00
Minimum Grant: 0x00
Interrupt pin: 0x01 (pin A)
Interrupt line: 0x00
and for the device on pci1:0:0 has this information
PCI configuration registers:
Common header:
0x00: 0x66041002 0x0017 0x0380 0x0010
Vendor Name: ATI Technologies (0x1002)
Device ID: 0x6604
Command register: 0x0007
...
Type 0 ("normal" device) header:
0x10: 0xd00c 0x 0xf0a4 0x
0x20: 0x3001 0x 0x 0x086a1025
0x30: 0xfffe 0x0048 0x 0x0100
Base address register at 0x10
type: 64-bit prefetchable memory
base: 0xd000
Base address register at 0x18
type: 64-bit nonprefetchable memory
base: 0xf0a0
Base address register at 0x20
type: I/O
base: 0x3000
Base address register at 0x24
not implemented
Cardbus CIS Pointer: 0x
Subsystem vendor ID: 0x1025
Subsystem ID: 0x086a
Expansion ROM Base Address Register: 0xfffe
base: 0xfffe
Expansion ROM Enable: off
Validation Status: Validation not supported
Validation Details: 0x0
Capability list pointer: 0x48
Reserved @ 0x38: 0x
Maximum Latency: 0x00
Minimum Grant: 0x00
Interrupt pin: 0x01 (pin A)
Interrupt line: 0x00
The ROM in the pci0:1:0 has the PCI ROM enabled but the ROM address is
not correct i think. Would you have any ideas on where the expansion
ROM might be found? Whereelse might I look? Since I am using UEFI, can
this ROM be located in the UEFI boot directories somewhere? Any
pointers, any information or any ideas would be appreciated.
Thanks in advance.
Best Regards,
Riza Dindir
Re: Trying to access the Expansion ROM of a video card
73 2c 20 49 6e 63 2e 00
41 54 4f 4d 42 49 4f 5342 4b 2d 41 4d 44 20 56
45 52 30 31 35 2e 30 3431 2e 30 30 30 2e 30 30
32 2e 30 34 35 33 39 3900 42 52 34 35 33 39 39
2e 30 30 31 20 00 31 3031 34 31 33 31 20 00 32
It looks like this has a bios in it, with the magic header. I tried to
find the acpi_get_table_with_size and acpi_get_table in order to use
these, but could not find the headers that have these. But could not
find these.
Is there documentation on how to read these tables from the ACPI system?
Regards,
Riza
On Fri, Nov 5, 2021 at 2:56 AM Riza Dindir wrote:
>
> Hello All,
>
> As you know I have a laptop that has amd radeon r7 m265 graphics
> device (it seems there are two actually; 0x1002/0x1309 and
> 0x1002/0x6604). My kernel panics when I do enable radeon, not finding
> any ROM.
>
> I am using netbsd 9.2 amd64 and am using UEFI boot.
>
> After reading kern/49964 (which had the same panic with my system -
> radeon_get_bios does not find a bios) I did some testing. Here is what
> I have so far.
>
> The memory at 0xC (size 131072) starts with 0xff 0xff. So this
> means that there is no valid expansion ROM here. This is what I have
> done to get this dump (dd if=/dev/mem of=/tmp/bios bs=1 iseek=786432
> count=131072) and to view it I used (hexdump -C /tmp/bios). If there
> is anything that looks wrong let me know.
>
> Then I have dumped the data on the two PCI devices mentioned above. To
> arrive at these I did use (pcictl pci0 dump -d 1 -f 0 and pcictl pci1
> dump -d 0 -f 0). Here is the outcome.
>
> The device on pci0:1:0 is as such
>
> PCI configuration registers:
> Common header:
> 0x00: 0x13091002 0x0017 0x0300 0x00800010
>
> Vendor Name: ATI Technologies (0x1002)
> Device ID: 0x1309
> Command register: 0x0007
> .
> Type 0 ("normal" device) header:
> 0x10: 0xe00c 0x 0xf00c 0x
> 0x20: 0x4001 0xf0b0 0x 0x08641025
> 0x30: 0xfffe0001 0x0048 0x 0x0100
>
> Base address register at 0x10
> type: 64-bit prefetchable memory
> base: 0xe000
> Base address register at 0x18
> type: 64-bit prefetchable memory
> base: 0xf000
> Base address register at 0x20
> type: I/O
> base: 0x4000
> Base address register at 0x24
> type: 32-bit nonprefetchable memory
> base: 0xf0b0
> Cardbus CIS Pointer: 0x
> Subsystem vendor ID: 0x1025
> Subsystem ID: 0x0864
> Expansion ROM Base Address Register: 0xfffe0001
> base: 0xfffe
> Expansion ROM Enable: on
> Validation Status: Validation not supported
> Validation Details: 0x0
> Capability list pointer: 0x48
> Reserved @ 0x38: 0x
> Maximum Latency: 0x00
> Minimum Grant: 0x00
> Interrupt pin: 0x01 (pin A)
> Interrupt line: 0x00
>
> and for the device on pci1:0:0 has this information
>
> PCI configuration registers:
> Common header:
> 0x00: 0x66041002 0x0017 0x0380 0x0010
>
> Vendor Name: ATI Technologies (0x1002)
> Device ID: 0x6604
> Command register: 0x0007
> ...
> Type 0 ("normal" device) header:
> 0x10: 0xd00c 0x 0xf0a4 0x
> 0x20: 0x3001 0x 0x 0x086a1025
> 0x30: 0xfffe 0x0048 0x 0x0100
>
> Base address register at 0x10
> type: 64-bit prefetchable memory
> base: 0xd000
> Base address register at 0x18
> type: 64-bit nonprefetchable memory
> base: 0xf0a0
> Base address register at 0x20
> type: I/O
> base: 0x3000
> Base address register at 0x24
> not implemented
> Cardbus CIS Pointer: 0x
> Subsystem vendor ID: 0x1025
> Subsystem ID: 0x086a
> Expansion ROM Base Address Register: 0xfffe
> base: 0xfffe
> Expansion ROM Enable: off
> Validation Status: Validation not supported
> Validation Details: 0x0
> Capability list pointer: 0x48
> Reserved @ 0x38: 0x
> Maximum Latency: 0x00
> Minimum Grant: 0x00
> Interrupt pin: 0x01 (pin A)
> Interrupt line: 0x00
>
> The ROM in the pci0:1:0 has the PCI ROM enabled but the ROM address is
> not correct i think. Would you have any ideas on where the expansion
> ROM might be found? Whereelse might I look? Since I am using UEFI, can
> this ROM be located in the UEFI boot directories somewhere? Any
> pointers, any information or any ideas would be appreciated.
>
> Thanks in advance.
>
> Best Regards,
> Riza Dindir
ACPI API
Hello I am trying to use some of the ACPI tables inside a kernel driver. Is there any documentation on the ACPI API? I would appreciate any help, or pointer to any documentation. Thanks in advance. Regards, Riza
Graphics driver and CONFIG_ACPI
Hello, I am trying to make the radeonr7 m265 display device to work on NetBSD 9.2 (amd64). In the radeon_bios.c file there is a definition used, named CONFIG_ACPI. Some functions are using this definition. I want to enable this. Where can I do this? In the configuration file (GENERIC for instance) or someplace else? Regards Riza
kaveri_mec2.bin file missing
Hello I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work. In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c", there is a reference to a kaveri_mec2.bin file. But this file is not present in the "src/sys/dev/microcode/radeon/" directory. Is it possible to comment out the reference to kaveri_mec2.bin? Regards, Riza
Re: kaveri_mec2.bin file missing
Thanks, I will copy both files to "src/sys/dev/microcode/radeon/" on my system. Although "kaveri_mec.bin". Regards Riza On Sun, Nov 21, 2021 at 12:29 AM matthew green wrote: > > Riza Dindir writes: > > Hello > > > > I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work. > > > > In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c", > > there is a reference to a kaveri_mec2.bin file. But this file is not > > present in the "src/sys/dev/microcode/radeon/" directory. Is it > > possible to comment out the reference to kaveri_mec2.bin? > > copy this out of the upstream "linux-firmware" package: > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > we're planning on updating these files for netbsd-10, but for > now this is the right process. > > > .mrg.
Re: kaveri_mec2.bin file missing
Hello, Here is what I try to accomplish. I could not find the bios for the 0x1002/0x6604 device. So I thought that I could just disable this device, and use the Kaveri device (0x1002/0x1309), since I have that bios. I have put the two files listed above (by RVP) to the "src/sys/dev/microcode/radeon/" directory. I also changed the configuration to only include the radeon device that is the 0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was missing). But this failed to load the microcode. It does fail in the function "cik_init_microcode". I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't this the correct path to put these bin files in? Are the file names in this directory case-sensitive? Although in the "src/sys/dev/microcode/radeon/" directory all the bin files begin with capital letters (KAVERI_mec.bin for instance). Also in the file radeon_cik.c there are MODULE_FIRMWARE declarations/definitions that have both KAVERI_*.bin files and kaveri_*.bin files. And the KAVERI_mec2.bin file was missing in that list, in which all the files start with KAVERI (with capital letters). Should this entry not be there? Although I tried it both ways. Adding KAVERI_mec2.bin in the MODULE_FIRMWARE definitions. And tried it also by removing that entry. It did not change anything. I might have not put these files in the correct directory maybe. Am I missing something? On Sun, Nov 21, 2021 at 9:20 AM Riza Dindir wrote: > > Thanks, I will copy both files to "src/sys/dev/microcode/radeon/" on > my system. Although "kaveri_mec.bin". > > Regards > Riza > > On Sun, Nov 21, 2021 at 12:29 AM matthew green wrote: > > > > Riza Dindir writes: > > > Hello > > > > > > I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work. > > > > > > In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c", > > > there is a reference to a kaveri_mec2.bin file. But this file is not > > > present in the "src/sys/dev/microcode/radeon/" directory. Is it > > > possible to comment out the reference to kaveri_mec2.bin? > > > > copy this out of the upstream "linux-firmware" package: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > > > we're planning on updating these files for netbsd-10, but for > > now this is the right process. > > > > > > .mrg.
Re: kaveri_mec2.bin file missing
Hello All, Finally... I was able to enable and use my Kaveri device (0x1002/0x1309), at the end. It is using the external monitor and is using the correct 1440x900 resolution. This is very nice. There is one thing that I would like to ask. There is a "CONFIG_ACPI" definition that is being used in the radeon_bios file. I looked for this definition in the sources and found that "sys/external/bsd/drm2/dist/drm/i915/i915_drv.h" has this definition (that is the only place). I wanted to copy or do something similar in the radeon driver. But I was not sure. Then I checked at runtime definitions CONFIG_ACPI and NACPICA (as used in the i915 driver). The NACPICA has a value and is > 0. And CONFIG_ACPI is not defined, as seen below. [10.911949] kern info: [drm] CONFIG_ACPI not set [10.920577] kern info: [drm] NACPICA > 0 Do you have any ideas on why CONFIG_ACPI is not defined in radeon? (Maybe this is not the correct place to ask this question). If I were to submit patches, how can I submit these, where? Best Regards, Riza Dindir On Sun, Nov 21, 2021 at 2:40 PM Riza Dindir wrote: > > Hello, > > Here is what I try to accomplish. I could not find the bios for the > 0x1002/0x6604 device. So I thought that I could just disable this > device, and use the Kaveri device (0x1002/0x1309), since I have that > bios. > > I have put the two files listed above (by RVP) to the > "src/sys/dev/microcode/radeon/" directory. I also changed the > configuration to only include the radeon device that is the > 0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the > MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was > missing). But this failed to load the microcode. It does fail in the > function "cik_init_microcode". > > I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't > this the correct path to put these bin files in? > > Are the file names in this directory case-sensitive? Although in the > "src/sys/dev/microcode/radeon/" directory all the bin files begin with > capital letters (KAVERI_mec.bin for instance). > > Also in the file radeon_cik.c there are MODULE_FIRMWARE > declarations/definitions that have both KAVERI_*.bin files and > kaveri_*.bin files. And the KAVERI_mec2.bin file was missing in that > list, in which all the files start with KAVERI (with capital letters). > Should this entry not be there? Although I tried it both ways. Adding > KAVERI_mec2.bin in the MODULE_FIRMWARE definitions. And tried it also > by removing that entry. It did not change anything. > > I might have not put these files in the correct directory maybe. Am I > missing something? > > On Sun, Nov 21, 2021 at 9:20 AM Riza Dindir wrote: > > > > Thanks, I will copy both files to "src/sys/dev/microcode/radeon/" on > > my system. Although "kaveri_mec.bin". > > > > Regards > > Riza > > > > On Sun, Nov 21, 2021 at 12:29 AM matthew green wrote: > > > > > > Riza Dindir writes: > > > > Hello > > > > > > > > I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work. > > > > > > > > In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c", > > > > there is a reference to a kaveri_mec2.bin file. But this file is not > > > > present in the "src/sys/dev/microcode/radeon/" directory. Is it > > > > possible to comment out the reference to kaveri_mec2.bin? > > > > > > copy this out of the upstream "linux-firmware" package: > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > > > > > we're planning on updating these files for netbsd-10, but for > > > now this is the right process. > > > > > > > > > .mrg.
Re: Graphics driver and CONFIG_ACPI
Hello again, I am having trouble getting information on how to have CONFIG_ACPI defined? I have been working on getting my radeon devices (Kaveri and OPAL XT) to work with NetBSD (9.2 - amd64). I have been successful in making the Kaveri device work on my system. I have found the bios in the ACPI tables. I also have revised the radeon_acpi_vfct_bios() function. But this function only works when CONFIG_ACPI is set/defined. So I have moved that function out of the CONFIG_ACPI condition. I am thinking that this might not be the correct way of doing this. I do not know where to define CONFIG_ACPI. It is not being defined (as it seems) for radeon, but for the i915 device it is being defined. I could do the same thing as it is done in the i915 driver code, but again, I am not sure about that either. Does anybody have an idea on where this definition (CONFIG_ACPI) should be defined, for radeon? Would appreciate any help you can provide. Thanks in advance. Regards, Riza On Sat, Nov 20, 2021 at 6:00 AM Riza Dindir wrote: > > Hello, > > I am trying to make the radeonr7 m265 display device to work on NetBSD > 9.2 (amd64). In the radeon_bios.c file there is a definition used, > named CONFIG_ACPI. Some functions are using this definition. I want to > enable this. Where can I do this? In the configuration file (GENERIC > for instance) or someplace else? > > Regards > Riza
Re: kaveri_mec2.bin file missing
Hello Sorry for the late reply. It landed in spam for some reason. I apologize. On Sun, Nov 21, 2021 at 5:54 PM Robert Swindells wrote: > > > Riza Dindir wrote: > >I have put the two files listed above (by RVP) to the > >"src/sys/dev/microcode/radeon/" directory. I also changed the > >configuration to only include the radeon device that is the > >0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the > >MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was > >missing). But this failed to load the microcode. It does fail in the > >function "cik_init_microcode". > > > >I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't > >this the correct path to put these bin files in? > > It is the correct source directory for Radeon microcode files, unless > you have added something to the Makefile they won't get copied to > the destination directory which is /libdata/firmware/radeon. I have done that but they did not get copied to the /libdata directory. I do not know when the makefile in the src/sys/dev/microcode/radeon directory is being invoked. > > You could just copy files from the linux-firmware tree to > /libdata/firmware/radeon to test things. Yes I manually copied these files and it worked. > > >Are the file names in this directory case-sensitive? Although in the > >"src/sys/dev/microcode/radeon/" directory all the bin files begin with > >capital letters (KAVERI_mec.bin for instance). > > The filenames are case sensitive, you can see that the files are not the > same. > > % diff -b KAVERI_me.bin kaveri_me.bin > Binary files KAVERI_me.bin and kaveri_me.bin differ > > I would expect to use either the KAVERI* or the kaveri* files as a set. On examining the radeok_cik.c file in the cik_init_microcode() function (or something like that) it looks for the KAVERI*, then the kaveri* files. As far as I can tell the kaveri* files are the new firmware. You have to have all the kaveri* files in the libdata directory, so that it will use all the new firmware, otherwise it complains that old and new firmware is being mixed. Thanks for the response. Riza
Re: kaveri_mec2.bin file missing
Hello On Thu, Nov 25, 2021 at 8:22 PM matthew green wrote: > > Riza Dindir writes: > > Hello All, > > > > Finally... I was able to enable and use my Kaveri device > > (0x1002/0x1309), at the end. It is using the external monitor and is > > using the correct 1440x900 resolution. This is very nice. > > > > There is one thing that I would like to ask. > > > > There is a "CONFIG_ACPI" definition that is being used in the > > radeon_bios file. I looked for this definition in the sources and > > found that "sys/external/bsd/drm2/dist/drm/i915/i915_drv.h" has this > > definition (that is the only place). > > > > I wanted to copy or do something similar in the radeon driver. But I > > was not sure. Then I checked at runtime definitions CONFIG_ACPI and > > NACPICA (as used in the i915 driver). The NACPICA has a value and is > > > 0. And CONFIG_ACPI is not defined, as seen below. > > > > [10.911949] kern info: [drm] CONFIG_ACPI not set > > [10.920577] kern info: [drm] NACPICA > 0 > > > > Do you have any ideas on why CONFIG_ACPI is not defined in radeon? > > (Maybe this is not the correct place to ask this question). > > the ACPI code in the drm code base requires porting to netbsd, > for both the radeon and the nouveau drivers. it's been a while > since i was looking at it (i had nouveau compiling at some > point). ie, it's not enabled because it doesn't compile there, > it is only enabled on i915 because it does there. I see. Might try defining CONFIG_ACPI. > > > If I were to submit patches, how can I submit these, where? > > sending patches to this list is good. > > (there's also tech-x11@ but this stuff is relevant for the > console and other operations that don't need X, and is about > the kernel side..) Yes I will do. The code boiled down to using some functions defined in the acpica.h files in the netbsd code (AcpiGetTable). Although the new porting efforts use the new linux kernel code, which has acpi_get_table, which might even work without modifications, given that CONFIG_ACPI is defined. > > thanks. > > > .mrg. Regards Riza
Re: Graphics driver and CONFIG_ACPI
Hello, On Fri, Nov 26, 2021 at 11:09 AM Taylor R Campbell wrote: > > > Date: Fri, 26 Nov 2021 05:19:57 + > > From: Riza Dindir > > > > I do not know where to define CONFIG_ACPI. It is not being defined (as > > it seems) for radeon, but for the i915 device it is being defined. I > > could do the same thing as it is done in the i915 driver code, but > > again, I am not sure about that either. > > > > Does anybody have an idea on where this definition (CONFIG_ACPI) > > should be defined, for radeon? > > Since there's not a lot of upstream code using CONFIG_ACPI but it > tends to require manual effort to port (the Linux acpica API > is...annoyingly different from everyone else's, like changing the case > of every name and using structs instead of unions or vice versa so > it's not a simple matter of adding some typedefs and wrapper > functions), what I've done is just define it conditionally based on > NACPICA in the places where I have made the necessary adjustments. > > In this case, I'd probably just put it in radeon.h: > > #include "acpica.h" > #if NACPICA > 0 > #define CONFIG_ACPI 1 > #endif > > It's not a great system but it serves for now. If it starts getting > out of hand we can find another way to do it. Will do that. Was not sure of doing that. > > FYI: Current development on the kernel graphics stack is happening at > https://github.com/riastradh/netbsd-src in the re4drm56 branch (which > is kind of messy and is rebased and squashed often, so be prepared for > forced updates, although might be merged soon). For radeon there's > not many differences because new upstream development is mostly > happening on amdgpu, but you might want to work on re4drm56 to avoid > duplicating effort. OK. I will be checking out that code, and try building the kernel, and go from there. Regards, Riza
Radeon R7
Hello,
I have been trying to make my radeon graphics devices work on NetBSD
9.2. Because the brightness can not be adjusted with the GOP driver.
My system has 2 radeon devices. One is the Kaveri R7 Graphics
(0x1002/0x1309) and the other is the OpalXT R7 M265 (0x1002/0x6604).
And the system is using NetBSD 9.2 (amd64).
My kernel driver was not finding the bios for these devices and was
stopping with a kernel panic. I was able to find the bios for the
Kaveri device in the ACPI tables (FVCT table) and could make the
Kaveri device load and be able to use the system using my external
monitor.
I tried to follow Taylor's suggestion and define CONFIG_ACPI in the
radeon.h header. But this on the other hand made the kernel build fail
in the radeon_ci_dpm.c. This requires me to investigate more, which I
will be doing in the comming days, trying to put as much time as I
can. I will also be researching on how to enable the OpalTX (R7 M265)
and find the bios for that device.
But for now, in the hope that others may find this useful, I am
sending my diff (obtained with "cvs -q diff -u"). The patch/diff
follows below.
Regards,
Riza
? arch/amd64/compile/GENERIC_RADEON_GENFB
? arch/amd64/conf/GENERIC_RADEON_GENFB
Index: dev/pci/pcireg.h
===
RCS file: /cvsroot/src/sys/dev/pci/pcireg.h,v
retrieving revision 1.147.4.2
diff -u -r1.147.4.2 pcireg.h
--- dev/pci/pcireg.h19 Mar 2020 19:05:34 -1.147.4.2
+++ dev/pci/pcireg.h7 Dec 2021 02:43:17 -
@@ -487,6 +487,8 @@
#definePCI_MAPREG_ROM_ADDR(mr)\
((mr) & PCI_MAPREG_ROM_ADDR_MASK)
+#definePCI_MAPREG_ROM_SIZE(mr)\
+(PCI_MAPREG_ROM_ADDR(mr) & -PCI_MAPREG_ROM_ADDR(mr))
#definePCI_MAPREG_ROM_VALID_STAT __BITS(3, 1) /* Validation Status */
#definePCI_MAPREG_ROM_VSTAT_NOTSUPP0x0 /* Validation not supported */
#definePCI_MAPREG_ROM_VSTAT_INPROG0x1 /* Validation in Progress */
Index: external/bsd/drm2/dist/drm/radeon/radeon_bios.c
===
RCS file: /cvsroot/src/sys/external/bsd/drm2/dist/drm/radeon/radeon_bios.c,v
retrieving revision 1.6
diff -u -r1.6 radeon_bios.c
--- external/bsd/drm2/dist/drm/radeon/radeon_bios.c27 Aug 2018
13:55:59 -1.6
+++ external/bsd/drm2/dist/drm/radeon/radeon_bios.c7 Dec 2021 02:43:23 -
@@ -34,10 +34,12 @@
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
+#include "atombios.h"
#include
#include
#include
+
/*
* BIOS.
*/
@@ -649,6 +651,82 @@
return legacy_read_disabled_bios(rdev);
}
+//
**
+// HACK
+
+/*
+ * This code is experimental and is written to make the driver work
on the system
+ * for the radeon r7 m265 device.
+ *
+ * Problems:
+ *
+ * Do not know why CONFIG_ACPI is not defined.
+ *
+ * Revisions:
+ *
+ *v3: Made the code resemble the original (ACPI based) using goto's.
+ *v2: Revised code to use the atom bios structures defined in
netbsd (atombios.h).
+ * v1: Have used the structures from the openbsd/linux atomfirmware.h file.
+ * Reusing the acpi_table_header defined in the netbsd acpica
framework.
+ */
+
+#ifndef CONFIG_ACPI
+static bool _radeon_acpi_vfct_bios(struct radeon_device *rdev)
+{
+bool ret = false;
+AMD_ACPI_DESCRIPTION_HEADER *hdr;
+ULONG tbl_size;
+UEFI_ACPI_VFCT *vfct;
+GOP_VBIOS_CONTENT *vbios;
+VFCT_IMAGE_HEADER *vhdr;
+
+ if (!ACPI_SUCCESS(AcpiGetTable("VFCT", 1, (ACPI_TABLE_HEADER**)&hdr))) {
+return false;
+ }
+
+ tbl_size = hdr->TableLength;
+
+if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
+DRM_ERROR("ACPI VFCT table present but broken (too short #1)\n");
+goto out_unmap;
+}
+
+vfct = (UEFI_ACPI_VFCT *)hdr;
+if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
+DRM_ERROR("ACPI VFCT table present but broken (too short #2)\n");
+goto out_unmap;
+}
+
+vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
+vhdr = &vbios->VbiosHeader;
+DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size %d\n",
+vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
+vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
+
+if (vhdr->PCIBus != rdev->pdev->bus->number ||
+vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
+vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
+vhdr->VendorID != rdev->pdev->vendor ||
+vhdr->DeviceID != rdev->pdev->device) {
+DRM_INFO("ACPI VFCT table is not for this card\n");
+goto out_unmap;
+}
+
+if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) +
vhdr->ImageLength > tbl_size) {
+DRM_ERROR("ACPI VFCT image truncated\n");
+goto out_unmap;
+}
+
+rdev->bios = kmemdup(&vbios->VbiosConten
