Radeon R7

2021-12-06 Thread Riza Dindir
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** {
+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 = >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(>VbiosContent, 

Re: Graphics driver and CONFIG_ACPI

2021-11-26 Thread Riza Dindir
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


Re: kaveri_mec2.bin file missing

2021-11-26 Thread Riza Dindir
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: kaveri_mec2.bin file missing

2021-11-26 Thread Riza Dindir
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: Graphics driver and CONFIG_ACPI

2021-11-25 Thread Riza Dindir
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

2021-11-23 Thread Riza Dindir
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: kaveri_mec2.bin file missing

2021-11-21 Thread Riza Dindir
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

2021-11-20 Thread Riza Dindir
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.


kaveri_mec2.bin file missing

2021-11-20 Thread Riza Dindir
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


Graphics driver and CONFIG_ACPI

2021-11-19 Thread Riza Dindir
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


ACPI API

2021-11-13 Thread Riza Dindir
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


Re: Trying to access the Expansion ROM of a video card

2021-11-12 Thread Riza Dindir
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


Re: Trying to access the Expansion ROM of a video card

2021-11-04 Thread Riza Dindir
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

2021-10-24 Thread Riza Dindir
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 

Re: Trying to access the Expansion ROM of a video card

2021-10-23 Thread Riza Dindir
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,
  );

  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, );
  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

2021-10-22 Thread Riza Dindir
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,
> >   );
> >
> >   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, );
> >   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
>


Trying to access the Expansion ROM of a video card

2021-10-19 Thread Riza Dindir
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,
  );

  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, );
  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


Questions about kernel driver for Radeon r7 m265

2021-10-16 Thread Riza Dindir
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