0xdeadbeef Posted March 20, 2009 Share Posted March 20, 2009 And I'm a little confused here about whether just running the card BIOS got it POSTed or you have to additionaly running ATOM init functions to get job done? Without int10, there is also another problem of accessing the video BIOS as it's not located at 0xC0000 (already used by primary card) and you got no idea where it will be (maybe not in system memory at all). Without access to the BIOS image, there is no way to call ATOM init functions. Maybe you can get all that info by calling IOACPIPlatformDevice methods: _ROM (Get ROM data) _GPD (Get POST Device) _SPD (Set POST Device) See pages 576..578 of the ACPI Spec Although if this can be done from a display driver I have no idea. I do know that ATY_* framebuffers call IOACPIPlatformDevice->_DSS (Device Set State) Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111034 Share on other sites More sharing options...
np_ Posted March 20, 2009 Share Posted March 20, 2009 here is more info http://www.x.org/docs/AMD/ http://www.x.org/wiki/radeonhd what you need to do is new iokit driver who loads before any ati***.kext ( something like natit ) mapping ATI mem base IO ( check docs for correct registers, they are almost same for any ati card ) and you can read/write anywhere in card mem space , that include to read EDID , card bios ..etc getting correct info you can push it into ioregs without no problem at all just note - avoid to hard code EDID info data into ioregs or any data copied from real mac's ioregs, it will cause in most situation black screen or even put video card in funny moods Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111171 Share on other sites More sharing options...
netkas Posted March 20, 2009 Share Posted March 20, 2009 dong, the bios you can always get from ioreg, for r6xx+ cards its there under name ATY,bin_image and here is what radeonhd x86 does (from rhd_atombios.c) if (unposted) { /* run AsicInit */ if (!rhdAtomASICInit(handle)) xf86DrvMsg(scrnIndex, X_WARNING, "%s: AsicInit failed. Won't be able to obtain in VRAM " "FB scratch space\n",__func__); static Bool rhdAtomASICInit(atomBiosHandlePtr handle) { ASIC_INIT_PS_ALLOCATION asicInit; AtomBiosArgRec data; RHDFUNC(handle); RHDAtomBiosFunc(handle->scrnIndex, handle, GET_DEFAULT_ENGINE_CLOCK, &data); asicInit.sASICInitClocks.ulDefaultEngineClock = data.val / 10;/*in 10 Khz*/ RHDAtomBiosFunc(handle->scrnIndex, handle, GET_DEFAULT_MEMORY_CLOCK, &data); asicInit.sASICInitClocks.ulDefaultMemoryClock = data.val / 10;/*in 10 Khz*/ data.exec.dataSpace = NULL; data.exec.index = GetIndexIntoMasterTable(COMMAND, ASIC_Init); data.exec.pspace = &asicInit; xf86DrvMsg(handle->scrnIndex, X_INFO, "Calling ASIC Init\n"); atomDebugPrintPspace(handle, &data, sizeof(asicInit)); if (RHDAtomBiosFunc(handle->scrnIndex, handle, ATOMBIOS_EXEC, &data) == ATOM_SUCCESS) { xf86DrvMsg(handle->scrnIndex, X_INFO, "ASIC_INIT Successful\n"); return TRUE; } xf86DrvMsg(handle->scrnIndex, X_INFO, "ASIC_INIT Failed\n"); return FALSE; } Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111424 Share on other sites More sharing options...
netkas Posted March 20, 2009 Share Posted March 20, 2009 ah well, framebuffer already has _atom_ASIC_Init function, it called on wakeup. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111448 Share on other sites More sharing options...
dong Posted March 20, 2009 Author Share Posted March 20, 2009 netkas, I checked your natit code, you're still getting BIOS ROM from the legacy address 0xC0000 if the ROM is not present in plist file. It won't work for a secondary ATI card. So, do you want to modify the native driver some way to make it execute atom_ASIC_Init at initialization time? Or a tiny driver is still needed to do this job? Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111488 Share on other sites More sharing options...
netkas Posted March 20, 2009 Share Posted March 20, 2009 i get it from 0xc0000 only if binimage wasnt found in plist, that;s answer well. i modified motmot that way, and it's attitude changed when card run in vga mode, not vesa, but still isnt perfect. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1111702 Share on other sites More sharing options...
dong Posted March 21, 2009 Author Share Posted March 21, 2009 Netkas, I put rhdAtomInit related stuff together. It's compiled ok but not tested yet. If it does not do its job or causes KP for some reason, don't blame me. In the probe function, I assume BIOS can be read from IOPCIDevice's "ATY,bin_image". You have to make sure Natit load before this and set that to IOPCIDevice. Now if BIOS can not be read from "ATY,bin_image", the BIOS at legacy address will be used instead. Adding this is because I don't have a "ATY,bin_image" to debug the code. Find it in thanoulas's post in this topic if you want to download. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1112183 Share on other sites More sharing options...
netkas Posted March 22, 2009 Share Posted March 22, 2009 seems like you forgot to add some sources to it kld(): Undefined symbols: _DelayMicroseconds _DelayMilliseconds _ReadIndReg32 _ReadPCIReg16 _ReadPCIReg32 _ReadPCIReg8 _ReadReg32 _ReadSysIOReg16 _ReadSysIOReg32 _ReadSysIOReg8 _WriteIndReg32 _WritePCIReg16 _WritePCIReg32 _WritePCIReg8 _WriteReg32 _WriteSysIOReg16 _WriteSysIOReg32 _WriteSysIOReg8 I attached corrected info.plist, the default one doesnt work. http://rapidshare.de/files/46265563/Info.plist.html Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1112650 Share on other sites More sharing options...
dong Posted March 22, 2009 Author Share Posted March 22, 2009 My bad, didn't even test it with kextload. The undefined symbols is caused by atombios compiling macros. All the sources are already there. To solve this, In CD_hw_services.h, add a line at the beginning, i.e., add #define ENABLE_ALL_SERVICE_FUNCTIONS right after #include "CD_Structs.h" You may also add the line at the beginning of hwserv_drv.c, all the function implementations are there. The ENABLE_ALL_SERVICE_FUNCTIONS definition will enable them. The whole project in my last post is also updated. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1112776 Share on other sites More sharing options...
netkas Posted March 22, 2009 Share Posted March 22, 2009 panics in atomSaveRegisters function Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1112871 Share on other sites More sharing options...
dong Posted March 22, 2009 Author Share Posted March 22, 2009 panics in atomSaveRegisters function Don't know exactly what caused it, possibly the memory allocation/deallocation stuff. And I do not see how useful can this function be, it seems only backup the registers each time when there is a writing but I do not find out where they are used to restore the values. So a simple suggestion to avoid this panic is to comment out all occasions of atomSaveRegisters in the code. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1112942 Share on other sites More sharing options...
netkas Posted March 23, 2009 Share Posted March 23, 2009 Sorry, i was a bit lazy to analize backtrace last time so made wrong assumption, so getting rid of saveregisters functions made no difference panic was in __RHDRegWrite │ 1950 ! mov edx, eax │ 1952 ! mov eax, [ebp+offset_10] │ 1955 ! mov [edx], eax │ 1957 ! leave │ 1958 ! ret EIP - 1955 edx - a030 , eax - 0x02 Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1113503 Share on other sites More sharing options...
dong Posted March 23, 2009 Author Share Posted March 23, 2009 Just a quick response, I suddenly remember that I forgot to add a "device->setMemoryEnable(true)" in ATY_Init.cpp. I will try to debug further by myself, but you may give another try. Update: after adding that, it now works for me, though the screen goes into a strange state. Here is the log: dong/project/ATY_Init/build/Debug; USER=root; COMMAND=/sbin/kextload -t ATY_Init.kext Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 97 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,16) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister© = 1ca Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 16 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,96) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(c,1ca) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 96 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,9c) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(c,1a) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 9c Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,27) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister© = 24a Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 27 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,a7) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(c,24a) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = a7 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,28) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister© = 28a Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 28 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,a8) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(c,28a) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL(26) = 17 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(26,13) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL(1e) = 17 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(1e,13) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL(1d) = 17 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(1d,13) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(574,1) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(570) = 0 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(570,0) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(580,c000000) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(4cc,1f000000) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL( = 100fac8f Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(b,100fac8f) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL( = 100fac8f Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(b,100fac13) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = 8b Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8, Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister© = 100fac13 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(8) = b Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(8,8b) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(c,100fac8f) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadPLL( = 100fac8f Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWritePLL(b,100fac8f) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReleaseMemory Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReadATIRegister(10) = 40000 Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: atomSaveRegisters Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailWriteATIRegister(10,40000) Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: CailReleaseMemory Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: ParseTable said: CD_SUCCESS Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: ASIC_INIT Successful Mar 23 11:49:49 myLenovo kernel[0]: ATY_Init: Card initialize completed I do not comment out atomSaveRegisters yet, but it's better to remove them since the memory allocated in it is not freed in the project. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1113622 Share on other sites More sharing options...
LeoMark Posted March 25, 2009 Share Posted March 25, 2009 Hi, netkas and dong, congratulations for the project! I am a user ati mobility hd2400, I have followed the work of you and I'm anxious for news, some hope for the LVDS connector? sorry for english, I'm Brazilian Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1114928 Share on other sites More sharing options...
netkas Posted March 28, 2009 Share Posted March 28, 2009 latest still panics for me O.o Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1117869 Share on other sites More sharing options...
LeoMark Posted March 31, 2009 Share Posted March 31, 2009 Hey guys ... do you think the project will not have a solution? the project will continue or is this the end of the ATI Mobility ... Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1119957 Share on other sites More sharing options...
dong Posted March 31, 2009 Author Share Posted March 31, 2009 latest still panics for me O.o I don't have a later ATI card to test the code. The _RHDReadMC and _RHDWriteMC are different for my x1400 compared to later cards, maybe panic here? Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1120809 Share on other sites More sharing options...
thanoulas Posted April 5, 2009 Share Posted April 5, 2009 I don't have a later ATI card to test the code. The _RHDReadMC and _RHDWriteMC are different for my x1400 compared to later cards, maybe panic here? Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to. Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks. Specifically, kernel panicks in rhd_init.c, function: void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) { *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value; } CARD16 offset was 544c, CARD32 value was 8 _RHDRegRead previously returned 0 for the offset 544c Hope it helps Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1124782 Share on other sites More sharing options...
super_engine Posted April 5, 2009 Share Posted April 5, 2009 Hi I am one of hundrends laptop users with an ATI Mobility card (X1350) Please can attach a compiled file in this thread. So we, no developers, can test it ??? thank you in advance. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1124933 Share on other sites More sharing options...
dong Posted April 6, 2009 Author Share Posted April 6, 2009 Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to. Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks. Specifically, kernel panicks in rhd_init.c, function: void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) { *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value; } CARD16 offset was 544c, CARD32 value was 8 _RHDRegRead previously returned 0 for the offset 544c Hope it helps Thanks for your interest and effort. A roughly search of 0x544C did not give any results from radeonHD or ati open source. I then looked at the binary code of ATY_MegaLodon. It turns out the register address is visited in the procedures of PCIE_Gen1_Enable and PCIE_Gen2_Enable. Below is the disemblyed code of PCIE_Gen2_Enable: OSStatus PCIE_Gen2_Enable(DriverGlobal *aDriverRecPtr) { UInt32 value, value1; pciepw32(aDriverRecPtr, 0xA2, pciepr32(aDriverRecPtr, 0xA2) & ~(1 << 13)); value = pciepr32(aDriverRecPtr, 0xA2); if (value & (1 << 9)) pciepw32(aDriverRecPtr, 0xA2, ((((value | (1 << 10)) & ~7) | ((value & 0x70) >> 4)) | (1 << 8)) & ~(1 << 7)); else pciepw32(aDriverRecPtr, 0xA2, value | (1 << 13)); value = pciepr32(aDriverRecPtr, 0xA4); if ((value & (1 << 23)) && (value & (1 << 24))) { regw32(aDriverRecPtr, 0x5488, regr32(aDriverRecPtr, 5488) & ~(1 << 25)); regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~(1 << 28)); regw32(aDriverRecPtr, 0x5404, regr32(aDriverRecPtr, 5404) | (1 << 25)); regw32(aDriverRecPtr, 0x5484, regr32(aDriverRecPtr, 5484) & ~0xF; regw32(aDriverRecPtr, 0x5410, regr32(aDriverRecPtr, 5410) | (1 << 23)); regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~0x1E); value = (value | 1) & ~2; value1 = pciepr32(aDriverRecPtr, 0xA1); if (value1 & (1 << 6)) pciepw32(aDriverRecPtr, 0xA1, value1 & ~0x40); pciepw32(aDriverRecPtr, 0xA4, ((((value & ~0x300) | 0x300) & ~0x3C000) & ~0x40) | 0x20); regw32(aDriverRecPtr, 0x541C, regr32(aDriverRecPtr, 541C) | (1 << 3)); regw32(aDriverRecPtr, 0x544C, 8); regw32(aDriverRecPtr, 0x4088, (regr32(aDriverRecPtr, 4088) & ~0xF) | 2); regw32(aDriverRecPtr, 0x544C, 0); } return noErr; } However, I could not find out why it could cause a kernel panic. Hope someone else could give an answer. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1125254 Share on other sites More sharing options...
thanoulas Posted April 6, 2009 Share Posted April 6, 2009 Thanks for your interest and effort.A roughly search of 0x544C did not give any results from radeonHD or ati open source. I then looked at the binary code of ATY_MegaLodon. It turns out the register address is visited in the procedures of PCIE_Gen1_Enable and PCIE_Gen2_Enable. Below is the disemblyed code of PCIE_Gen2_Enable: OSStatus PCIE_Gen2_Enable(DriverGlobal *aDriverRecPtr) { UInt32 value, value1; pciepw32(aDriverRecPtr, 0xA2, pciepr32(aDriverRecPtr, 0xA2) & ~(1 << 13)); value = pciepr32(aDriverRecPtr, 0xA2); if (value & (1 << 9)) pciepw32(aDriverRecPtr, 0xA2, ((((value | (1 << 10)) & ~7) | ((value & 0x70) >> 4)) | (1 << 8)) & ~(1 << 7)); else pciepw32(aDriverRecPtr, 0xA2, value | (1 << 13)); value = pciepr32(aDriverRecPtr, 0xA4); if ((value & (1 << 23)) && (value & (1 << 24))) { regw32(aDriverRecPtr, 0x5488, regr32(aDriverRecPtr, 5488) & ~(1 << 25)); regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~(1 << 28)); regw32(aDriverRecPtr, 0x5404, regr32(aDriverRecPtr, 5404) | (1 << 25)); regw32(aDriverRecPtr, 0x5484, regr32(aDriverRecPtr, 5484) & ~0xF; regw32(aDriverRecPtr, 0x5410, regr32(aDriverRecPtr, 5410) | (1 << 23)); regw32(aDriverRecPtr, 0x548C, regr32(aDriverRecPtr, 548C) & ~0x1E); value = (value | 1) & ~2; value1 = pciepr32(aDriverRecPtr, 0xA1); if (value1 & (1 << 6)) pciepw32(aDriverRecPtr, 0xA1, value1 & ~0x40); pciepw32(aDriverRecPtr, 0xA4, ((((value & ~0x300) | 0x300) & ~0x3C000) & ~0x40) | 0x20); regw32(aDriverRecPtr, 0x541C, regr32(aDriverRecPtr, 541C) | (1 << 3)); regw32(aDriverRecPtr, 0x544C, 8); regw32(aDriverRecPtr, 0x4088, (regr32(aDriverRecPtr, 4088) & ~0xF) | 2); regw32(aDriverRecPtr, 0x544C, 0); } return noErr; } However, I could not find out why it could cause a kernel panic. Hope someone else could give an answer. Well I do have another hackbook that I can use to debug the kext with the kernel debug kit. I'll give it a try and tell you what happens. Another interesting (maybe?) thing is that I skipped the 544c offset and now it panics at the exact same address that is next in the Megalodon fb, 0x4088. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1125497 Share on other sites More sharing options...
ridgeline Posted April 8, 2009 Share Posted April 8, 2009 oh for the love of OSX thank you guys for not giving up on this project Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1127293 Share on other sites More sharing options...
Slice Posted April 16, 2009 Share Posted April 16, 2009 Hi there. This is my first post in these forums and i'm really interested in the development of the ATY_HD Framebuffer. I'm a developer myself, so i could lend a hand if you'd like to. Anyway, i've tested out the ATY_Init code in my hackbook with a mobility HD3650 (M86) and I can verify that it panicks. Specifically, kernel panicks in rhd_init.c, function: void _RHDRegWrite(RHDPtr rhdPtr, CARD16 offset, CARD32 value) { *(volatile CARD32 *)((CARD8 *)(rhdPtr->IObase) + offset)) = value; } CARD16 offset was 544c, CARD32 value was 8 _RHDRegRead previously returned 0 for the offset 544c Hope it helps Bad offset can't cause kernel panic! Kernel panic can be caused by bad rhdPtr. Check! Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1134208 Share on other sites More sharing options...
dong Posted April 16, 2009 Author Share Posted April 16, 2009 Bad offset can't cause kernel panic! Kernel panic can be caused by bad rhdPtr. Check! If it was the case, somehow IOmap was read wrong for those cards. People can try change two lines in ATY_Init.cpp from IOmap = device->mapDeviceMemoryWithIndex(RHD_MMIO_BAR); to IOmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress2); and from FBmap = device->mapDeviceMemoryWithIndex(RHD_FB_BAR); to FBmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); "mapDeviceMemoryWithRegister" is used by native drivers and I think it should found the correct map. Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1134598 Share on other sites More sharing options...
thanoulas Posted April 16, 2009 Share Posted April 16, 2009 If it was the case, somehow IOmap was read wrong for those cards. People can try change two lines in ATY_Init.cpp fromIOmap = device->mapDeviceMemoryWithIndex(RHD_MMIO_BAR); to IOmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress2); and from FBmap = device->mapDeviceMemoryWithIndex(RHD_FB_BAR); to FBmap = device->mapDeviceMemoryWithRegister(kIOPCIConfigBaseAddress0); "mapDeviceMemoryWithRegister" is used by native drivers and I think it should found the correct map. I'll check that and report back ASAP Link to comment https://www.insanelymac.com/forum/topic/156279-new-ati-framebuffer-xcode-project-to-start-from/page/2/#findComment-1134722 Share on other sites More sharing options...
Recommended Posts