On 04/17/2017 03:17 PM, Vitaly Andrianov wrote:
> On 04/12/2017 03:23 PM, Ralf Ramsauer wrote:
>> 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
>
> Hi Ralf,
>
> I tried what you proposed:
>
> root@am57xx-evm:~# jailhouse cell load 1 ./loader.bin -a 0 ./inmate.bin
> -a 0x80000000
> Cell "AM57XX-EVM-PDK-LED" can be loaded
> root@am57xx-evm:~# jailhouse cell start 1
> Started cell "AM57XX-EVM-PDK-LED"
>
> That didn't work for me.
>
> I debugged this using CCS debugger. I set a breakpoint to the address
> 0x80000000, and execution stressfully stopped at that address. But it
> looks like instruction cache is not invalidated.
> From the memory window I can see that the loader.bin and inmate.bin code
> are loaded to the memory. I see the correct code from all three views:
> physical, intermediate physical and CPU(virtual).
> But for Disassembly window I can see only loader.bin code is valid
> (address 0x0). Code at address 0x80000000 doesn't correspond to what I
> see at the memory window at the same address.
>
> Do you know what I could do wrong?
Hmm. Could you just give it a try to use the Linux loader?
jailhouse cell load 1 \
linux-loader.bin -a 0 \
-s "kernel=0x80000000" -a 0x100 \
inmate.bin -a 0x80000000
jailhouse cell start 1
Ralf
>
> Thanks,
> -Vitaly
>
>
>>>
>>> .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.
