[SeaBIOS] ohci bulk?

[Stefan Berger]

On 11/20/2010 01:28 PM, Kevin O'Connor wrote:
> On Sat, Nov 20, 2010 at 01:18:18PM -0500, Stefan Berger wrote:
>> On 11/20/2010 01:05 PM, Kevin O'Connor wrote:
>>> Is it something like stacks.c:call32() or is it via SMM?
>>>
>> The way it works is that there is a jumptable with entries to the
>> function in the 'high bios'. That jumptable along with all the other
>> 32 bit code gets relocated to upper memory and in the 'lower BIOS' I
>> keep a pointer to the jumptable in the 'high bios' for the upcall
>> code to see. It's basically similar to what I have previously
>> contributed to Bochs BIOS in Xen, just that the upcall code can deal
>> with parameter passed via registers or a limited number on the
>> stack.
>>
>> http://xenbits.xensource.com/xen-4.0-testing.hg?file/e9156d9d996b/tools/firmware/rombios/32bitgateway.c
> That looks to be doing the same thing that stacks.c:call32() does.
As it looks, this function allows no parameters to be passed. What I 
would be adding is a function allowing transitioning from 16 bit to 32 
bit with >3 parameters (6 currently). There's some nastiness involved 
due to the 'ret + n' of functions being called with stack parameters, 
which starts with 4 parameters, and which does need explicit code in the 
transitioning function to fix up the stack as the caller expects it. As 
said, I am using a call table for transitioning that but calls are 
rather invisible from the C code perspective due to some tricks with 
#defines.

  The assumption that the BIOS would fill up is not given yet, as was 
the case for Bochs... but it's rather easy now to support the extension 
into 32 bit space.

    Stefan

>>> BTW, are you reserving the relocated code or are you only doing this
>>> during the init phase?
>> The 'high bios' functions should be accessible all the time
>> basically. So, the relocated code needs to be marked as
>> e820-reserved memory -- I suppose that should do the trick then?
> Yes, but of course that means the OS can't use the memory then.  Why
> does the code need to be in high memory - why not just have it in the
> f-segment?
>
> -Kevin