Opened 8 years ago

Last modified 8 months ago

#8457 new bug

Blank screen after boot on Radeon Mobility 4670 HD

Reported by: kvark Owned by: kallisti5
Priority: normal Milestone: R1
Component: Drivers/Graphics/radeon_hd Version: R1/Development
Keywords: blank radeon Cc:
Blocked By: #7662 Blocking:
Has a Patch: yes Platform: x86

Description

I'm running Haiku A3 on MSI EX625 laptop, which has Radeon Mobility 4670 HD on board. The PCIID for this card was added to radeon_hd driver listing very recently. I've built radeon_hd driver and the accelerator as of "hrev43937", and put them in places of the original files:
/system/add-ons/kernel/drivers/bin/radeon_hd
/system/add-ons/accelerants/radeon_hd.accelerant

With new radeon_hd I'm getting a bright garbage-looking screen on boot (screenshot to be attached). I can boot fine with fail-safe video mode (which forces VESA and disables radeon_hd).

It might be relevant that "connector_read_mode_lvds" sees my native resolution as 1400x900, where the actual screen resolution is 1366x768. However, I get the same white garbage if I try to boot with a forced 1024x768 resolution (via the boot option), which works fine with VESA driver.

Attachments (17)

listdev.txt (3.3 KB ) - added by kvark 8 years ago.
Device list
listimage_drv.txt (1.7 KB ) - added by kvark 8 years ago.
Driver image list
syslog.txt (512.0 KB ) - added by kvark 8 years ago.
System log
screenshot-1.jpg (519.2 KB ) - added by kvark 8 years ago.
Desktop right after the boot
screenshot-2.jpg (504.6 KB ) - added by kvark 8 years ago.
Desktop a minute after the boot
radeon_hd_bios_1002_9488_0.bin (128.0 KB ) - added by kvark 8 years ago.
Radeon AtomBIOS dump
linux-dmesg.log (53.7 KB ) - added by kvark 6 years ago.
Dmesg log of linux with 3.9 kernel
syslog-hrev45805.txt (399.7 KB ) - added by kvark 6 years ago.
Syslog from revision 45805
radeon_hd.accelerant (138.6 KB ) - added by kallisti5 6 years ago.
patched radeon_hd accelerant
radeon_hd (34.6 KB ) - added by kallisti5 6 years ago.
patched radeon_hd driver
syslog-patched.txt (208.3 KB ) - added by kvark 6 years ago.
Syslog with a patched radeon_hd
radeon_hd.2.accelerant (138.6 KB ) - added by kallisti5 6 years ago.
patched radeon_hd accelerant version 2
radeon_hd_lvds_ss.diff (2.3 KB ) - added by kallisti5 6 years ago.
patch
syslog-patched2.txt (295.2 KB ) - added by kvark 6 years ago.
Syslog with patched-2 accelerant
fix_vramBase_r1.diff (667 bytes ) - added by kallisti5 6 years ago.
patch to fix vram base? revision 1
edid_use_firstmonitor_r1.diff (1.6 KB ) - added by kallisti5 6 years ago.
try this one.
syslog-patch-edid-use-firstmonitor (382.4 KB ) - added by kvark 6 years ago.
Syslog taken with a patch that uses EDID of the first monitor

Change History (74)

by kvark, 8 years ago

Attachment: listdev.txt added

Device list

by kvark, 8 years ago

Attachment: listimage_drv.txt added

Driver image list

by kvark, 8 years ago

Attachment: syslog.txt added

System log

comment:1 by anevilyak, 8 years ago

Version: R1/alpha3R1/Development

Just for future reference, the list of resolutions in the boot loader only applies to fail-safe (aka VESA) video mode, it has no impact when an actual graphics driver is handling the display.

comment:2 by kvark, 8 years ago

Thank you anevilyak. It would be very useful if I could really force the resolution from the boot menu, regardless of the driver used. Also, the syslog attached is from the VESA-booted system. I'm not able to get the syslog from radeon_hd driven system. Please let me know If there is any way to get it saved.

comment:3 by kvark, 8 years ago

My mistake: the native resolution detected by "connector_read_mode_lvds" is 1400x1050. Also, I'm playing with radeon_hd accelerant code, and all the modes above the "native" one (which is not actually native) are marked BAD in the mode list, which is not the case for the original radeon_hd code. Sorry for the confusion.

by kvark, 8 years ago

Attachment: screenshot-1.jpg added

Desktop right after the boot

in reply to:  2 ; comment:4 by anevilyak, 8 years ago

Replying to kvark:

Thank you anevilyak. It would be very useful if I could really force the resolution from the boot menu, regardless of the driver used.

The reason it doesn't work that way is because it can't really. In the case of VESA the BIOS gives you a list of resolutions to choose based on an index value you pass in, and takes care of all the rest from there since it's all standardized. When using the actual driver, you no longer have the benefit of that, and consequently the driver has to actually compute the modelines, which entails computing constraints based on the monitor, etc., and consequently a lot more information potentially has to be supplied.

by kvark, 8 years ago

Attachment: screenshot-2.jpg added

Desktop a minute after the boot

in reply to:  4 comment:5 by kvark, 8 years ago

Replying to anevilyak:

The reason it doesn't work that way is because it can't really. In the case of VESA the BIOS gives you a list of resolutions to choose based on an index value you pass in, and takes care of all the rest from there since it's all standardized. When using the actual driver, you no longer have the benefit of that, and consequently the driver has to actually compute the modelines, which entails computing constraints based on the monitor, etc., and consequently a lot more information potentially has to be supplied.

No, of course, we do not want to compute the modelines. The driver generates a list of modes that are valid. All it needs to do is to find a mode in the list that matches the requested mode, if there is any.

comment:6 by kallisti5, 8 years ago

building the accelerant and driver and dropping into the folder may not be a good test... a lot has changed in the image since A3. Could you test the latest nightly from an iso or dd'ed onto a usb drive?

radeon_hd: connector_read_mode_lvds: 108000 1400 1444 1556 1684 1050 1051 1054 1066

That shows AtomBIOS is actually reporting a lvds mode of 1400x1050 for this card. Is 1400x1050 the correct native resolution? We pass that value back to Haiku as the preferred mode if a preferred mode is found.

in reply to:  6 comment:8 by kvark, 8 years ago

Replying to kallisti5:

building the accelerant and driver and dropping into the folder may not be a good test... a lot has changed in the image since A3. Could you test the latest nightly from an iso or dd'ed onto a usb drive?

Sure, I will do that and post in a moment.

That shows AtomBIOS is actually reporting a lvds mode of 1400x1050 for this card. Is 1400x1050 the correct native resolution? We pass that value back to Haiku as the preferred mode if a preferred mode is found.

As was mentioned before (here and on your blog), my native screen resolution is 1366x768. That is what WinXP, Win8, and Linux used to detect, at least. I have no idea why Haiku's LVDS queries give a different result.

comment:9 by kallisti5, 8 years ago

AAh... this looks like a stupid bug on my part...

http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/connector.cpp#n170 http://cgit.haiku-os.org/haiku/tree/src/add-ons/accelerants/radeon_hd/connector.cpp#n223

That memory allocated on 170 isn't guaranteed to exist after the function exits... consider it me not knowing any better.

I'm working on a fix and will push it shortly.

comment:10 by kallisti5, 8 years ago

Try again post hrev43982 :)

in reply to:  9 comment:11 by kvark, 8 years ago

Replying to kallisti5:

That memory allocated on 170 isn't guaranteed to exist after the function exits... consider it me not knowing any better. I'm working on a fix and will push it shortly.

Could you explain the fix for me? "timing" is a structure that was allocated on the stack:

display_timing timing;

Upon assignment to "mode->timing" the default copy operator will be called, and the memory will be copied. There is no memory leak here:

mode->timing = timing;

Hence, despite the fact there is a logic in your fix (why create a variable on the stack if you can fill the destination via a pointer), it does not change the functionality.

comment:12 by kvark, 8 years ago

Tried booting hrev43980 from CD - got the same blank screen.

by kvark, 8 years ago

Radeon AtomBIOS dump

comment:13 by kallisti5, 8 years ago

should be fixed in hrev44056 :D

Please test.

comment:14 by kvark, 8 years ago

Just booted ISO rev 44058. Haiku still shows garbage screen after loading, maybe a little different garbage, but very similar to screenshots I provided...

comment:15 by kallisti5, 8 years ago

Bah. Let me re-check the circumstances we pull the LVDS preferred mode... this just doesn't make sense. (That or this card has a known quirk)

comment:16 by kvark, 8 years ago

It would be great if you could take a look at the AtomBIOS dump I provided... Also, I assume there are logs from other OSes (like Linux, FreeBSD) that could be useful to investigate the case. If you have anything I can gather in mind, let me know.

comment:17 by kvark, 7 years ago

I've noticed 2 important messages in the syslog:

1) VESA knows about the native panel mode (1366x768), which is a single mode reported under additional modes section. I have a feeling that these additional (or "detailed") modes should be marked somehow on our end, because they are always relevant (in contrast to ones in the standard mode list).

2) radeon_hd does not even attempt to set the incorrectly detected mode (1400x1050). Instead, it tries to switch to 1024x768. As far as I got, it's the app_server that calls the accelerant to switch to this mode. I have no idea why that happens, and will look into that; however, it's all new to me, so the digging process is very slow :(

Any help and thoughts on the matter are very welcome!

comment:18 by kvark, 7 years ago

Blocking: 7662 added

comment:19 by kallisti5, 7 years ago

You may want to test again on hrev45325 or later.

A lot of stuff has changed recently and this issue may be resolved.

Thanks!

comment:20 by kvark, 7 years ago

I tested the hrev45325 anyboot image on USB, and the issue is clearly still unfixed.

comment:21 by kvark, 6 years ago

Tested on hrev45805 anyboot USB - not fixed still.

by kvark, 6 years ago

Attachment: linux-dmesg.log added

Dmesg log of linux with 3.9 kernel

comment:22 by kvark, 6 years ago

Please check the dmesg log from Linux-3.9 (attached). Some "drm" output may be useful, i.e. LVDS encoder id=21 (INTERNAL_UNIPHY2).

comment:23 by kallisti5, 6 years ago

Could you also grab a new set of logs from the Haiku machine?

Boot with radeon_hd, wait 30 seconds, then hold ctl+alt+delete for 5 seconds to reboot.

After you reboot, press space repeatedly before the haiku boot screen shows up and select "Failsafe video (vesa)"

finish booting, and grab /var/log/syslog.

Thanks!

-- Alex

by kvark, 6 years ago

Attachment: syslog-hrev45805.txt added

Syslog from revision 45805

comment:24 by kallisti5, 6 years ago

Thanks :)

These are mostly notes to myself..

based on radeon_atombios_get_lvds_info

  • check usage of lcd_misc
  • look into lcd patch table records (that we ignore for the moment)
    • LCD_FAKE_EDID_PATCH_RECORD_TYPE looks suspect

comment:25 by kallisti5, 6 years ago

Summary: Blank screen after boot on Radeon Mobility 4670 HDradeon_hd ignores lvds edid patch table resulting in incorrect lvds resolutions

comment:26 by kallisti5, 6 years ago

Seems like there is some kind of hidden EDID patch (cough hack) in the atombios tables we need to apply over what atombios *just* told us the lvds mode was. Likely not used often as not many people see this issue.

comment:27 by kallisti5, 6 years ago

Summary: radeon_hd ignores lvds edid patch table resulting in incorrect lvds resolutionsBlank screen after boot on Radeon Mobility 4670 HD

Ha.. this confirms i'm not crazy. If we disassemble (http://cgit.freedesktop.org/~mhopf/AtomDis/) the atombios you provided...

kallisti5@houvonglucka01 AtomDis :( $ ./atomdis ~/radeon_hd_bios_1002_9488_0.bin d 0006
Read 20000 bytes of data from /home/kallisti5/radeon_hd_bios_1002_9488_0.bin

data_table  0000acf0  #06  (LVDS_Info):

  Size         0036
  Format Rev.  01
  Param Rev.   00
  Content Rev. 02

  00000000:            302a 7805  1c01 1a04  1000 2c00        0*x.......,.
  00000010: 7000 0100  0300 0000  0000 0000  0600 0000    p...............
  00000020: 0000 2000  f401 0324  4d3c 0101  0000 0000    .. ....$M<......
  00000030: 0030 0000  0000                               .0....          

  0000:  ATOM_COMMON_TABLE_HEADER sHeader                    :
    0000:  USHORT usStructureSize                              = 0x0036     (54)
    0002:  UCHAR ucTableFormatRevision                         = 0x01       (1)
    0003:  UCHAR ucTableContentRevision                        = 0x02       (2)
  0004:  ATOM_DTD_FORMAT sLCDTiming                          :
    0004:  USHORT usPixClk                                     = 0x2a30     (10800)
    0006:  USHORT usHActive                                    = 0x0578     (1400)
    0008:  USHORT usHBlanking_Time                             = 0x011c     (284)
    000a:  USHORT usVActive                                    = 0x041a     (1050)
    000c:  USHORT usVBlanking_Time                             = 0x0010     (16)
    000e:  USHORT usHSyncOffset                                = 0x002c     (44)
    0010:  USHORT usHSyncWidth                                 = 0x0070     (112)
    0012:  USHORT usVSyncOffset                                = 0x0001     (1)
    0014:  USHORT usVSyncWidth                                 = 0x0003     (3)
    0016:  USHORT usImageHSize                                 = 0x0000     (0)
    0018:  USHORT usImageVSize                                 = 0x0000     (0)
    001a:  UCHAR ucHBorder                                     = 0x00       (0)
    001b:  UCHAR ucVBorder                                     = 0x00       (0)
    001c:  ATOM_MODE_MISC_INFO_ACCESS susModeMiscInfo          :
      001c:  (union) ATOM_MODE_MISC_INFO sbfAccess               :
               USHORT HorizontalCutOff:1                           = 0x0000     (0)
               USHORT HSyncPolarity:1                              = 0x0001     (1)
               USHORT VSyncPolarity:1                              = 0x0001     (1)
               USHORT VerticalCutOff:1                             = 0x0000     (0)
               USHORT H_ReplicationBy2:1                           = 0x0000     (0)
               USHORT V_ReplicationBy2:1                           = 0x0000     (0)
               USHORT CompositeSync:1                              = 0x0000     (0)
               USHORT Interlace:1                                  = 0x0000     (0)
               USHORT DoubleClock:1                                = 0x0000     (0)
               USHORT RGB888:1                                     = 0x0000     (0)
               USHORT Reserved:6                                   = 0x0000     (0)
      001c:  (union) USHORT usAccess                             = 0x0006     (6)
    001e:  UCHAR ucInternalModeNumber                          = 0x00       (0)
    001f:  UCHAR ucRefreshRate                                 = 0x00       (0)
  0020:  USHORT usExtInfoTableOffset                         = 0x0000     (0)
  0022:  USHORT usSupportedRefreshRate                       = 0x0020     (32)
  0024:  USHORT usOffDelayInMs                               = 0x01f4     (500)
  0026:  UCHAR ucPowerSequenceDigOntoDEin10Ms                = 0x03       (3)
  0027:  UCHAR ucPowerSequenceDEtoBLOnin10Ms                 = 0x24       (36)
  0028:  UCHAR ucLVDS_Misc                                   = 0x4d       (77)
  0029:  UCHAR ucPanelDefaultRefreshRate                     = 0x3c       (60)
  002a:  UCHAR ucPanelIdentification                         = 0x01       (1)
  002b:  UCHAR ucSS_Id                                       = 0x01       (1)
  002c:  USHORT usLCDVenderID                                = 0x0000     (0)
  002e:  USHORT usLCDProductID                               = 0x0000     (0)
  0030:  UCHAR ucLCDPanel_SpecialHandlingCap                 = 0x00       (0)
  0031:  UCHAR ucPanelInfoSize                               = 0x30       (48)
  0032:  UCHAR ucReserved                                [0] = 0x00       (0)
  0033:  UCHAR ucReserved                                [1] = 0x00       (0)

  Total data structure size:  0034

it definitely tells us:

usHActive = 0x0578 (1400) usVActive = 0x041a (1050)

Your LVDS_Info table is 1.2:

0006: acf0 Len 0036 Rev 01:02 (LVDS_Info) (struct size 0034)

Which means it shouldn't (and doesn't) contain a usModePatchTableOffset.

comment:28 by kvark, 6 years ago

Thanks for the info. I don't think the patch table needs to be looked into as it is not about usHActive or usVActive. What I think we should focus on is finding out how Linux/BSD gets the native mode.

comment:29 by kvark, 6 years ago

LCDPANEL_CAP_READ_EDID seems like it would be the answer, though the AtomBIOS dump shows ucLCDPanel_SpecialHandlingCap to be 0 :(

-//Definitions for ucLCDPanel_SpecialHandlingCap:
-
-//Once DAL sees this CAP is set, it will read EDID from LCD on its own instead of using sLCDTiming in ATOM_LVDS_INFO_V12. 
-//Other entries in ATOM_LVDS_INFO_V12 are still valid/useful to DAL 
-#define	LCDPANEL_CAP_READ_EDID                  0x1
-
-//If a design supports DRR (dynamic refresh rate) on internal panels (LVDS or EDP), this cap is set in ucLCDPanel_SpecialHandlingCap together
-//with multiple supported refresh rates@usSupportedRefreshRate. This cap should not be set when only slow refresh rate is supported (static
-//refresh rate switch by SW. This is only valid from ATOM_LVDS_INFO_V12
-#define	LCDPANEL_CAP_DRR_SUPPORTED              0x2
-
-//Use this cap bit for a quick reference whether an embadded panel (LCD1 ) is LVDS or eDP.
-#define	LCDPANEL_CAP_eDP                        0x4

comment:30 by kvark, 6 years ago

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

In case of my setup, that would be exactly 1366x768 that I need:

KERN: Additional Video Mode (1366x768@59Hz):
601	KERN: clock=72.33 MHz
602	KERN: h: (1366, 1414, 1446, 1526)
603	KERN: v: (768, 770, 775, 790)

It is going to be a workaround, which would at least allow me to work on Haiku comfortably, including finding the solution for radeonhd initialization.

in reply to:  29 ; comment:31 by kallisti5, 6 years ago

Replying to kvark:

LCDPANEL_CAP_READ_EDID seems like it would be the answer, though the AtomBIOS dump shows ucLCDPanel_SpecialHandlingCap to be 0 :(

Already looked at this.. the linux drm driver doesn't use that table.

Replying to kvark:

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

That seems like a fairly hacky hack. Wouldn't it be better to just boot from failsafe (vesa)?

I'd focus on the drm driver to try and figure out what it is doing different. I've reviewed the code and don't see anything different. Let me ping AMD and see what they think.

in reply to:  31 comment:32 by kvark, 6 years ago

I'm going to work on a patch that adds the following check box to the fail-safe video modes list in the boot menu: "Prefer additional VESA mode, if provided", checked by default.

That seems like a fairly hacky hack. Wouldn't it be better to just boot from failsafe (vesa)?

That's what I'm talking about. When booting with VESA as a fallback, people (like me) would still like to use their native resolution, and this resolution is exactly specified in the Additional VESA modes section, as far as I can see.

I'd focus on the drm driver to try and figure out what it is doing different. I've reviewed the code and don't see anything different. Let me ping AMD and see what they think.

That would be great. Thanks for your effort!

comment:33 by kallisti5, 6 years ago

Well, there ya go. Looks like a bug in your laptop's bios :)

We think DRM looks for an EDID from the LVDS panel before going to the LVDS_Into table. That is likely the difference.

21:08 <kallisti5> Good morning.  Super quick question.  Do you know the case to ignore the AtomBIOS LVDS_Info off the top of your head? 
21:09 <AMD> it should always be correct
21:09 <kallisti5> I have a user with a Radeon HD Mobility 4670. usHActive is 1400 and usVActice is 1050. however the native resolution of the lcd is 1366x768
21:09 <kallisti5> hmm
21:10 <AMD> is it a mac?
21:10 <kallisti5> I did see the LVDS patch table, but it doesn't seem to exist in the later table version (1.2)
21:10 <kallisti5> not that i'm aware of... good question though
21:10 <AMD> or did the user hack their system and install a non-standard panel?
21:10 <kallisti5> nope. "MSI EX625 laptop"
21:11 <kallisti5> well.. vesa has the correct perferred mode
21:11 <kallisti5> KERN: Additional Video Mode (1366x768@59Hz):
21:11 <AMD> if the panel has an EDID you can check that first
21:11 <kallisti5> I thought lvds didn't have edid?
21:11 <AMD> usually does
21:11 <AMD> only on really old laptops
21:12 <AMD> does it not
21:12 <AMD> the sbios usually patches the vbios LCDInfo table with the values from the EDID at boot
21:12 <kallisti5> ah. ok.  that helps :D  We can check for edid, else look for lvds_info
21:12 <AMD> which is how the values get there
21:12 <kallisti5> aah.  It maybe a quirk
21:13 <AMD> could be a funky oem bios
21:13 <kallisti5> 99% of the time it's been fine... just this one machine
21:13 <kallisti5> thanks :)
21:13 <AMD> np  

comment:34 by kallisti5, 6 years ago

Your LVDS panel does have a GPIO hardware pin:

KERN: radeon_hd: Connector #0)
2138	KERN: radeon_hd:  + connector:          LVDS Panel
2139	KERN: radeon_hd:  + gpio table id:      6
2140	KERN: radeon_hd:  + gpio hw pin:        0x96
2141	KERN: radeon_hd:  + gpio valid:         true
2142	KERN: radeon_hd:  + encoder:            LVDS
2143	KERN: radeon_hd:    - id:               33
2144	KERN: radeon_hd:    - type:             Internal Kaleidoscope UNIPHY2
2145	KERN: radeon_hd:    - enumeration:      1
2146	KERN: radeon_hd:    - is bridge:        false
2147	KERN: radeon_hd:    + external encoder: none
2148	KERN: radeon_hd:  + flags:
2149	KERN: radeon_hd:    * device LCD1 support

Your logs show we are jumping directly to the LVDS_Info table.

KERN: radeon_hd: detect_displays: connector(0): found LVDS preferred mode

So! The logic should be changed. Instead of jumping directly to that table, we should try to bit-bang an EDID from the LVDS gpio pin... if that fails to produce a valid EDID, use the LVDS_Info (if it is an LVDS panel)

I can make the change, it may be a few days though as my free time is short lately.

comment:35 by kvark, 6 years ago

That's awesome! When you are ready with the fix, please provide binaries as well, because I don't have the dev environment set up at this point. That in case you'd like to test it before submitting... Otherwise, I'll just wait for the nightly build.

comment:36 by kallisti5, 6 years ago

actually.. the fix was easier than I thought.. do you need gcc2 or gcc4 binaries to test?

comment:37 by kvark, 6 years ago

Nice! I'm using a nightly image, so "x86 GCC 2 Hybrid" binaries are needed.

by kallisti5, 6 years ago

Attachment: radeon_hd.accelerant added

patched radeon_hd accelerant

by kallisti5, 6 years ago

Attachment: radeon_hd added

patched radeon_hd driver

comment:38 by kallisti5, 6 years ago

gcc2 accelerant and driver attached. The only changes were in the accelerant, but update both to be safe.

comment:39 by kvark, 6 years ago

Thanks! I'll be able to test it in about 4 hours. I assume I can just overwrite these files under working Haiku and reboot.

comment:40 by kallisti5, 6 years ago

yeah. Should be able to without any issues. If you have any trouble, grab another syslog as it will show what the result of the ddc bit-banging was.

by kvark, 6 years ago

Attachment: syslog-patched.txt added

Syslog with a patched radeon_hd

comment:41 by kvark, 6 years ago

A patched system booted into a black screen. As if it wasn't powered on at all. Please see syslog-patched attachment for details. It did try the correct resolution (1366x768), so there must be some other bit missing.

comment:42 by kallisti5, 6 years ago

sigh... your laptop is buggy :P Partial fix applied in hrev45812

As for the black screen... I noticed the modeline calculations were a little odd.

KERN: radeon_hd: radeon_set_display_mode: pll 0 selected for connector 0
3290	KERN: radeon_hd: pll_setup_flags: CRTC: 0, PLL: 0
3291	KERN: radeon_hd: pll_setup_flags: Spread Spectrum is 8%
3292	KERN: radeon_hd: pll_setup_flags: using Spread Spectrum reference divider. refDiv was: 0, now: 98
3293	KERN: radeon_hd: pll_adjust: table 1.2
3294	KERN: radeon_hd: pll_adjust: was: 72330, now: 72330
3295	KERN: radeon_hd: pll_compute_post_divider: vco = 1200000
3296	KERN: radeon_hd: pll_compute_post_divider: postDiv = 16
3297	KERN: radeon_hd: pll_compute: using AtomBIOS reference divider
3298	KERN: radeon_hd: pll_compute: using AtomBIOS fractional feedback divider
3299	KERN: radeon_hd: pll_compute: pixel clock: 72330 gives: feedbackDivider = 2049.0; referenceDivider = 98; postDivider = 16
3300	KERN: radeon_hd: pll_compute: pixel clock 72330 was changed to 35282
3301	KERN: radeon_hd: display_crtc_ss
3302	KERN: radeon_hd: pll_set: table 1.3
3303	KERN: radeon_hd: pll_set: set adjusted pixel clock 35282 (was 72330)
3304	KERN: radeon_hd: display_crtc_set_dtd called to do 1366x768
3305	KERN: radeon_hd: display_crtc_fb_set: Framebuffer at: 0x0
3306	KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress High: 0x0
3307	KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress: 0x0
3308	KERN: radeon_hd: display_crtc_fb_set: fb: 1366x768 (32 bpp)
3309	KERN: radeon_hd: display_crtc_fb_set: fb pitch: 1376
3310	KERN: radeon_hd: display_crtc_fb_set: fb width aligned: 1376

This is the first time i've ever seen Spread Spectrum used. The feedbackDivider is changed into something really incorrect.

comment:43 by kallisti5, 6 years ago

*sigh* lvdsSpreadSpectrumID is populated by connector_read_mode_lvds. As we never call it... it never gets populated so we match incorrect SS data.

by kallisti5, 6 years ago

Attachment: radeon_hd.2.accelerant added

patched radeon_hd accelerant version 2

by kallisti5, 6 years ago

Attachment: radeon_hd_lvds_ss.diff added

patch

comment:44 by kallisti5, 6 years ago

Has a Patch: set

by kvark, 6 years ago

Attachment: syslog-patched2.txt added

Syslog with patched-2 accelerant

comment:45 by kvark, 6 years ago

With the second accelerant and an original kernel driver I'm getting the same picture as without patches at all - screen is corrupted. Please see syslog-patched2 attached. I noticed that the pitch is 1376, which doesn't match the width, though I'm not sure if that's the problem.

comment:46 by kvark, 6 years ago

Confirmed it's still broken on latest. Also, investigated my options on using VESA. Despite the fact EDID reports proper timings for 1366x768, this mode is not a valid VESA mode :(. Hence, we'll have to push radeon_hd into supporting it properly.

comment:47 by kvark, 6 years ago

Looking through the last attached syslog I found a lot of differences with the DRM log. Haiku:

KERN: radeon_hd: display_crtc_fb_set: Framebuffer at: 0x0 KERN: radeon_hd: display_crtc_fb_set: Set SurfaceAddress High: 0x0 KERN: radeon_hd: display_crtc_fb_set: fb pitch: 1376

Linux:

[drm] fb mappable at 0xD0142000 [drm] vram apper at 0xD0000000 [drm] size 4325376 [drm] pitch is 5632

Clearly, the framebuffer address is invalid (0x0), and the pitch is totally wrong. Firstly, because it doesn't take into account 4 bytes per pixel. Secondly, because of a smaller alignment (DRM's 5632 = 4 * 1408).

kallisti5, could you comment on that?

Last edited 6 years ago by kvark (previous) (diff)

comment:48 by kallisti5, 6 years ago

The vram start (vram appear per drm above) is actually provided by the card if it is flagged as IGP. fbAddress is set by gInfo->fb.vramStart which is set by radeon_gpu_mc_init.

The logic for that likely needs reviewed as most of the logs at hand have the fb_base at 0xD0000000 - 0xE0000000

comment:49 by kallisti5, 6 years ago

Try the patch attached. I just can't find the logic why I was checking for IGP before reading that register. Please give it a try and let me know.

This change has the potential to break cards, so if it works for you I need to do some testing.

by kallisti5, 6 years ago

Attachment: fix_vramBase_r1.diff added

patch to fix vram base? revision 1

comment:50 by kvark, 6 years ago

Thanks kallisti5, I'll test it in a couple of hours. I'm still convinced the pitch is not passed correctly though: Write32(CRT, regs->grphPitch, widthAligned);

Shouldn't it look like that instead?: Write32(CRT, regs->grphPitch, widthAligned * bytesPerPixel);

Also, the pitchMask computation should be changed to match this one: http://kerneldox.net/kdox-linux/d2/db3/radeon__fb_8c.html (look for radeon_align_pitch()) With this code it would produce widthAligned==1408, exactly like on DRM.

comment:51 by kvark, 6 years ago

The patch doesn't seem to affect anything, the framebuffer is still reported as 0x0.

comment:52 by kallisti5, 6 years ago

ok. I wouldn't use the patch then :D

I just remembered the reason for that check. Linux is reporting the framebuffer address from the point of view of the host. Haiku's framebuffer address is the location from the perspective of the GPU

comment:53 by kvark, 6 years ago

Ok I see... What about the pitch then?

by kallisti5, 6 years ago

try this one.

comment:54 by kvark, 6 years ago

No luck with this one either...

by kvark, 6 years ago

Syslog taken with a patch that uses EDID of the first monitor

comment:55 by kvark, 6 years ago

I also tried fixing the alignment and the pitch (to match DRM ones), but that didn't help.

comment:56 by kvark, 6 years ago

Checked on hrev46653, the system boots straight into VESA 1024x768, and I see no mentions of 'radeon' in the syslog. Is this expected?

comment:57 by waddlesplash, 8 months ago

Blocked By: 7662 added
Blocking: 7662 removed
Note: See TracTickets for help on using tickets.