NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: GOP and using monitor
Hello RVP,
On Fri, Oct 8, 2021 at 11:10 PM RVP <rvp%sdf.org@localhost> wrote:
>
> On Fri, 8 Oct 2021, Riza Dindir wrote:
>
> > I taught that I will do the hack, but leave the configuration in tact as
> >
> > genfb* at pci? dev ? function ?
> >
> > Anyways I will do this again. The status of the genfb before the new kernel is this (at this stage the system uses the stock kernel,
> > which is the GENERIC kernel).
> >
> > [ 1.017054] genfb0 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00)
> > [ 1.017054] genfb0: framebuffer at 0xe0000000, size 1366x768, depth 32, stride 5632
> > [ 1.017054] genfb0: shadow framebuffer enabled, size 4224 KB
> > [ 1.017054] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
> > [ 1.017054] drm at genfb0 not configured
> > [ 1.017054] genfb1 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00)
> >
> > At this stage both the devices are not shown as "not configured".
> >
>
> genfb0 is configured. Only drm is not configured.
drm is not configured, because i do not have the radeon driver. That's
what I think.
>
> > I have done this in the renamed kernel configuration.
> >
> > #genfb* at pci? dev ? function ?
> > genfb0 at pci1 dev 0 function 0
> > genfb1 at pci0 dev 1 function 0
> >
>
> You can remove the genfb1 line.
If I remove that line, I think it will not configure the device on
pci0 dev 1 func 0. Will try.
>
> > I am in /usr/src/sys/arch/amd64/conf and configure the kernel using
> >
> > # config GENERIC_RADEON_GENFB
> > Build directory is ../compile/GENERIC_RADEON_GENFB
> > Don't forget to run "make depend"
> >
> > Then I do this to compile the kernel.
> >
> > # cd ../compile/GENERIC_RADEON_GENFB/
> > # make depend
> > # make
> >
>
> The build.sh method (also in the Guide) is simpler.
I tried the build.sh, but it gave me an error looking for /usr/obj or
a directory under /usr directly. So I settled with the manual method.
>
> > Here is the output for the genfb devices from the dmesg.
> >
> > [ 1.016985] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00)
> > [ 1.016985] genfb0: framebuffer at 0xe0000000, size 1366x768, depth 32, stride 5632
> > [ 1.016985] genfb0: shadow framebuffer enabled, size 4224 KB
> > [ 1.016985] wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation), using wskbd0
> > [ 1.016985] drm at genfb0 not configured
> > [ 1.016765] genfb1 at pci0 dev 1 function 0: vendor 1002 product 1309 (rev. 0x00)
> > [ 1.016765] genfb1: framebuffer at 0xe0000000, size 1366x768, depth 32, stride 5632
> > [ 1.016765] genfb1: shadow framebuffer enabled, size 4224 KB
> > [ 1.016765] wsdisplay0 at genfb1 kbdmux 1: console (default, vt100 emulation), using wskbd0
> > [ 1.016765] drm at genfb1 not configured
> > [ 1.016765] genfb0 at pci1 dev 0 function 0: vendor 1002 product 6604 (rev. 0x00)
> >
>
> This looks more like what we want. Just remove the genfb1 from the
> kernel config.
OK. Will do.
>
> > It does the correct thing and puts the 6604 on genfb0 device. This also does assign the same framebuffer to both genfb0 and genfb1.
> > Wouldn't this mean that both the monitor and the will use the same framebuffer memory, and so if everything works fine as we assume
> > (the VGA output is enabled), the monitor should display the same output as the laptop monitor?
> >
>
> On 9.2, the addresses printed are virtual addresses. If they were the
> _same_ physical addresses, then that would be a major bug.
>
Oh, I thought that it was the physical address. Alright.
> Since NetBSD uses only one graphics card, just remove genfb1.
Will do.
>
> -RVP
Riza
Home |
Main Index |
Thread Index |
Old Index