[coreboot] Fwd: SimNOW VGA int 1a

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Oct 17 00:28:03 CEST 2008


On 17.10.2008 00:09, ron minnich wrote:
> On Thu, Oct 16, 2008 at 3:07 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>   
>> On 16.10.2008 23:54, ron minnich wrote:
>>     
>>> On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>>
>>>
>>>       
>>>> If that's it, the solution is absolutely simple. And I mean totally simple.
>>>> 1. Backup old content
>>>> 2. Write ffffffff
>>>>
>>>>         
>>> at this point it is game over.
>>> The code that does this is in rom.
>>>
>>>       
>> Hm. Unshare only this function, maybe with another name?
>>     
>
> printk?
>   

Think of point 1-4 as one "atomic" operation. pci_conf1_read_config32
does not call any other function, so simply unshare that and be happy.


>>>> 3. Read back and save in a variable
>>>> 4. Restore old content.
>>>> Make sure no code blacked out by the decode is executed between 1 and 4
>>>> and you're safe. If you're feeling paranoid, do it as inline asm. Make
>>>> sure that short sequence is never ever run as XIP code in ROM (I can do
>>>> that checking right now).
>>>>
>>>> What am I missing?
>>>>
>>>>
>>>>         
>>> the big thing is that the problem code is a binary vga bios over which
>>> we have zero control. :-(
>>>
>>>       
>> Hmmm. Is it running in vm86? If yes, we can trap I/O port writes and
>> reads, so this is solvable. Same should apply to x86emu.
>>     
>
> this is getting kind of hideously complex. Let's think on it some more.
>   

I'm not completely getting this. Do we run the binary blob from inside
coreboot or does SeaBIOS perform that task?
If coreboot does it, we have some trapping code for BIOS emulation anyway.
If SeaBIOS does it, the problem is moot since SeaBIOS is independent and
completely in RAM.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the coreboot mailing list