thop1544

@Suntor This has requested many times, but the consensus seems to be that, on account of no new features of note having apparently been introduced in A12 or A13, the answer is no. @svl7 Sorry to ask twice, but I didn't find an answer in any of the pages of this thread before or after last September (when I last mentioned it): is there a way to expose and control the AC adapter’s authentication handshake? Would this be possible using either the current A11 modified BIOS, or maybe with some (guided) modifications to it? I would do this myself if I knew what to look for, and would of course be able to test the changes to whatever BIOS was necessary. I'm on my second 240W AC adapter from Dell, and it recently quit working just like the last one did. I'm a few months out of warranty at this point though, which means having to pay about $65 USD to buy a third 240W, which is just as liable stop functioning properly in the same manner. I’ve used both Flextronics and Delta adapters, with two different motherboards, but still inevitably have the same issue. The BIOS no longer recognize it as a 240W adapter, and as such refuses to either charge the battery or run the CPU and GPU at full clocks. The problem seems to lie in a failure of a parasitically powered ID chip in the adapter itself (which is delivered by the middle pin visible when looking down the plug). I don’t know if the authentication is too much of a hardware-level thing unfortunately, but there is some information about how Dell’s ID chip works with these adapters here: 330 Watt power supply for Alienware M17x » imsolidstate 330W power supply for M17x update » imsolidstate http://forum.techinferno.com/alienware-m17x-aw-17/1948-240w-psu-id-chip-330w-psu-2.html http://web.archive.org/web/20130102101025/http://www.laptops-battery.co.uk/blog/dell-ac-power-adapter-type-cannot-be-determined-solution/

Yes, this is possible.

Thanks a lot for this, which is finally a good fix for the newer Enduro/UEFI/etc. enabled 7970m cards. FWIW though, at least on the xxx.022.xxx vBIOS the checksum bits start somewhat later in the file (0xFFFF) than where the OP's screenshots show and are formatted a little differently. Does anyone know what algo ATIWinFlash uses for generating the CRC though? I would rather not have to boot a Windows box each time I need to check that, just for the sake of a couple of bytes.

As far as I know, the not charging problem results from irregularitieswith a parasitically powered microchip in the AC adapter. I've hadtrouble with it too, but the best solution I've 'found' to work isplugging in the adapter, waiting for the blue ring to appear, thenunplugging and plugging back in the cord to the wall, fast enough tokeep the blue light on. Then connect it to the laptop, and it seemsto work. Dellwent to pretty exorbitant lengths to ensure that only an exact (Dell) adapter can be used for each laptop.

@bjrebo I think you should be able to use the USB recovery method to go back to A05. From there, just flash the official A11 and then follow the instructions in the OP to get the unlocked A11 working.

@svl7 Sorry if this has already been asked, but is there a way to expose the AC adapter authentication handshake? The ID chip in the 240W adapters doesn't always work perfectly, and so it would be a lot more reliable to just be able to force the motherboard to accept the brick as a Dell 240W explicitly.

I think .018 is a UEFI vBIOS, which means it won't work in an older 170em (and the vBIOS editor won't work with it).

He just answered that. A12 doesn't do anything important. I was a little curious about the product name enhancement mentioned at the top of that changelog though.

if the card came with a .017 vBIOS then you should just use the patcher against that older version; it doesn't work with anything newer. Though, if you're getting thermal shutdown at 0.950V without heightened clocks then you've likely got bigger issues. I'd suggest checking your paste, fans and heatsinks first, especially for dust and warping.

You'll have to grab the proprietary drivers, which is probably most easily done from their site. As things currently stand, "Nvidia's" FOSS drivers will never get close to what the AMD and Intel stacks offer, especially with acceleration: re-clocking is broken under nouveau.

Well running the latest Arch with the testing repos enabled, audio works properly (under ALSA) by simply plugging into the secondary headphones jack. I've yet to test this with pulseaudio. What's more troubling is how the 7970m has no s3tc/dxtn support in the radeonsi FOSS driver, and indeed no hardware acceleration at all unless using Glamor. I guess that's supposed to be merged with kernel 3.10 but be dependent on the next Mesa, which isn't going to be ready for about 5 months. I've opened some threads across the Arch and openSUSE forums detailing these issues, and I can point anyone there who is interested. There are some upstream bug reports open as well, by others.

I doubt too much would be gained from flashing a 8970m vBIOS in comparison to just flashing an overclocked one for the 7970m. The 8970m is just a clock bump; AMD is planning on outdoing their current GPUs (in the desktop area either) for the rest of the year.

Use the modified A11 bios, go into video (under the second 'Advanced' category) and set video mode to PEG. Go under internal graphics device and set it to disabled. This will force the M17x R4 to always use the dGPU, something which is independent of the OS's driver stack.

But how? I've had audio jack detection issues across multiple kernels / distros since the time of Ubuntu 12.04 LTS (which is just the first one I tried with this M17x R4). I'm currently dual-booting W8 with Arch running kernel 3.9.1 (from the testing repos) and KDE, to answer the OP, but the issues persist under Linux for me.

Only if the 7970m has a version .017 vBIOS. Voltage, UEFI revisions, etc. are preventing this with all the newer cards' vBIOS files at the moment.