[okl4-developer] elfweaver with several IO regions per server

[Geoffrey Lee]

On Thu, Jun 19, 2008 at 05:06:41PM +0200, Lukas HANEL wrote:


Hi Lukas

> Hi Geoffrey,
>
> concerning this problem, I want to better understand the issue and ask  
> you whether there is no work-around.
>
> As I understand, in the old driver framework, drivers would use  
> hardware_back_memsection to get access to a physical page.
>
> In the new version, I cannot find a call to this function anywhere.  
> Neither in the driver implementation, nor in the virtual server, nor in  
> some library.
> (arm-linux-objdump -x build/iguana/bin/vserial |grep  
> hardware_back_memsection --> empty)
>
> I conclude that the build system is creating some permission map  
> (bootinfo?) which is then interpreted by the kernel or iguana bootup.  
> Using this map every driver server gets the IO region mapping it needs.
> Is is like this?
>
> Is there a way to assign IO resoures to other VMs? E.g. OKLinux?
>
> Or will a call to hardware_back_memsection still work?

In OKL4 2.1 the normal way for OKL4 drivers to obtain device
mappings is indeed via the build system.  The mappings are then
done when the system bootstraps.

You can, however, still call hardware_back_memsection().  
There is no assignment of I/O resources to legacy OSes like 
OK Linux at build time.  OK Linux relies on hardware_back_memsection()
to work.  Similarly, you can call utilize the hardware_back_memsection() 
call to map device memory.




>
> thanks,
> Lukas Hänel

	-gl

>
> Geoffrey Lee wrote:
>> On Thu, Jun 12, 2008 at 10:33:59AM +0200, Lukas HANEL wrote:
>>> Hi,
>>
>> Hi Lukas
>>
>> Thanks for looking further into the problem.  Your analysis about the
>> fact that you cannot have multiple memory mapped i/o regions
>> is correct, and I am able to reproduce the problem from my end.
>> This appears to be an unfortunate limitation in the build system right 
>> now.
>>
>> I'll tag this into our bug report database and keep tracking it.
>> Rest assured that it will be fixed in a future release.
>>
>> Again, thanks for the detailed bug report.
>>
>> 	-gl
>>
>

--