On Fri, 2004-02-27 at 23:07, Michael Schmitz wrote: > > scratch. It's not simple, it's probably undreds of magic values to > > blast in specific non documented chip registers in the right sequence, > > difficult to do without some support from ATI... Or a way to re-run > > the OF f-code driver. > > What would it take to do just that - assuming the OF init code can be > accessed after kernel init, and all access to the chip can be blocked by > e.g. staying on the dummy fb console until after re-init? > > It's a sick idea, though ..
Not that sick, I've been considering it quite seriously :) It requires an F-code interpreter with enough dictionary support to grok those drivers, which isn't actually far from what we already have, either in OpenBIOS or via another source I may not disclose yet. Part of the problem is getting to this f-code. For "slot" based cards, it's easy to read it from the card's PCI ROM. For laptops & iMacs, it's buried deep into Apple's main ROM, compressed etc... I know somebody who knows how to "crack" the ROM to extract the driver, I don't know at this point if he'll accept to document the method. Just for completeness, double check that OF isn't putting something in the device-tree with the f-code already :) I doubt it, but since linux "skips" too large properties when copying the device-tree during boot, it might actually be there and not visible in linux... Ben.
