On 04/12/2017 09:04 PM, Vitaly Andrianov wrote:
> On 04/12/2017 02:16 PM, Ralf Ramsauer wrote:
>> Hi Vitaly,
>>
>> On 04/12/2017 07:54 PM, Vitaly Andrianov wrote:
>>>
>>> On 04/12/2017 11:11 AM, Jan Kiszka wrote:
>>>> Hi Vitaly,
>>>>
>>>> On 2017-04-12 16:57, Vitaly Andrianov wrote:
>>>>> Hi Jan,
>>>>>
>>>>> Most of inmate configurations for ARM platform has RAM .virt_start =
>>>>> 0x0. Is that a requirement?
>>>>
>>>> The reset vector is 0x0, so there should be some code at that location
>>>> when the inmate wants to start. Can be a fraction of the RAM, though,
>>>> just to carry some bootstrap page if you prefer.
>>>>
>>>>>
>>>>> A while ago I tried to make an inmate with .virt_start = 0x80000000
>>>>> and
>>>>> couldn't load the inmate. I wondering if that is an issue with my
>>>>> configuration or a Jailhouse limitation. I'm working on porting a
>>>>> AM572x
>>>>> TI-RTOS based application to run as inmate and for me that is a big
>>>>> limitation (if that is a real limitation but not my bug). A typical
>>>>> TI-RTOS application has MMU enabled with identical one-to-one
>>>>> mapping of
>>>>> the entire DDR (0x80000000-0xffffffff). And the binary entry is
>>>>> somewhere at the beginning of that range.
>>>>>
>>>>> I saw couple of linux-demo configuration files with .virt_start !=
>>>>> 0x0.
>>>>> Does jailhouse care the .virt_start != 0x0 in some special way? Or I
>>>>> just have some issue with my configuration?
>>>>
>>>> In case of Linux, you can see that there is always at least one small
>>>> region at virt_start 0 as well. That is were our linux-loader.bin is
>>>> put. It does not need identity mapping as it does not do any DMA.
>>>>
>>>> Jan
>>>>
>>> Hi Jan,
>>>
>>> Sorry, I'm confused. From Ralf's reply I understood that I can link my
>>> inmate to not zero address (in my case I use beginning of the DDR -
>>> 0x80000000) and set .virt_start to the same address. Also I placed
>>> vector table to the beginning of the image, so the entry point is the
>>> start of the binary. I understood that configuration should work.
>> Sorry for the confusion, Jan is right, please let me amend:
>>
>> Currently, relocating inmates is not sufficent, their entry point or
>> reset vector would have to be changed as well. Jailhouse currently jumps
>> to guest-phys 0x0.
>>
>> Ralf
> Ralf,
>
> Let's say I have a binary linked to the address 0x80000000 and entry
> point 0x8000xxxx. I'll create one page code linked to the 0x0. At the
> beginning of that page I have only one instruction:
>
> "b 0x8000xxxx"
>
> I'll concatenate that page and my binary into inmate.bin and create
> inmate cell configuration with something like:
What you mean by concatenate? Just concatenating them to one single blob
won't work.
You have to load two separate binaries: Your tiny loader that is loaded
to 0x0, and your actual inmate that is loaded to the 0x80000000.
So in the end, the load command will look like:
jailhouse cell load foo loader.page -a 0x0 inmate.bin -a 0x80000000
This *should* work. (I think it might be possible to use the
linux-loader for that special case as well)
Ralf
>
> .mem_regions = {
> /* RAM */ {
> .phys_start = phys_memory_reserved_for_inmate
> .virt_start = 0,
> .size = 0x1000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE |JAILHOUSE_MEM_LOADABLE,
> },
> /* RAM */ {
> .phys_start = phys_memory_reserved_for_inmate + 0x1000,
> .virt_start = 0x80000000,
> .size = 0x1000000,
> .flags = JAILHOUSE_MEM_READ | JAILHOUSE_MEM_WRITE |
> JAILHOUSE_MEM_EXECUTE | JAILHOUSE_MEM_DMA |
> JAILHOUSE_MEM_LOADABLE,
> },
> . . . .
>
> Will it work?
>
> Thanks,
> -Vitaly
>
>>>
>>> From your reply I understood that I have to make at least a small
>>> section located at the virt_start = 0x0 address. Is that really
>>> necessary?
>>>
>>> Thanks,
>>> Vitaly
>>>
>>>
>>>
>>>
>
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.