Hi,
Thanks for the support. I think I solved the problem partially.
@Andrii
> So I guess you see the abort on access to a peripheral missing on r8a7796
> but described in a device tree for r8a7795.
>
You were right. I commented out &sata and &rcarsound nodes from the device
tree created for xen and made some other modifications. The Dom0 now boots
without crash.
@Oleksandr
> PFA the DTS I use for M3ULCB board
Thank you very much. I used it for reference. I got a bit lucky because of
the fact that H3 and M3 are similar.
Still the framebuffer is not coming up. I will try to update with the logs
Thanks and regards,
George
On Mon, Feb 27, 2017 at 4:25 PM, Oleksandr Andrushchenko <andr2...@gmail.com
> wrote:
> Hi,
>
> PFA the DTS I use for M3ULCB board
>
>
>
> On 02/27/2017 12:48 PM, Oleksandr Tyshchenko wrote:
>
>> Hi.
>>
>> On Mon, Feb 27, 2017 at 12:29 PM, George John <georgeeldhoj...@gmail.com>
>> wrote:
>>
>>> Hi,
>>> Thanks for the reply,
>>> I am using Linux version 4.6.
>>> The memory nodes were already squashed. When I have used a different
>>> version
>>> of Xen, it booted to dom0. but still the crash occurs as shown in the log
>>> below.
>>>
>>> I have also noticed that for salvator x M3 board(r8a7796) the dtb file
>>> used
>>> was r8a7795-salvator-x-dom0.dtb
>>> Is it ok?
>>>
>> I don't know about M3 board.
>> CC my colleague who plays with M3 board. Hope, that he can shed some
>> lights.
>>
>> regards,
>>> George
>>>
>>> On Fri, Feb 24, 2017 at 8:43 PM, Oleksandr Tyshchenko <
>>> olekst...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Not 100% sure, but anyway...
>>>>
>>>> Can you recheck after squashing all memory nodes to a single one.
>>>>
>>>> ---
>>>> I guess, you have following in your device tree:
>>>>
>>>> memory@48000000 {
>>>> device_type = "memory";
>>>> /* first 128MB is reserved for secure area. */
>>>> reg = <0x0 0x48000000 0x0 0x38000000>;
>>>> };
>>>>
>>>> memory@500000000 {
>>>> device_type = "memory";
>>>> reg = <0x5 0x00000000 0x0 0x40000000>;
>>>> };
>>>>
>>>> memory@600000000 {
>>>> device_type = "memory";
>>>> reg = <0x6 0x00000000 0x0 0x40000000>;
>>>> };
>>>>
>>>> memory@700000000 {
>>>> device_type = "memory";
>>>> reg = <0x7 0x00000000 0x0 0x40000000>;
>>>> };
>>>>
>>>> ---
>>>> Try to make next:
>>>>
>>>> memory@48000000 {
>>>> device_type = "memory";
>>>> /* first 128MB is reserved for secure area. */
>>>> reg = <0x0 0x48000000 0x0 0x38000000>,
>>>> <0x5 0x00000000 0x0 0x40000000>,
>>>> <0x6 0x00000000 0x0 0x40000000>,
>>>> <0x7 0x00000000 0x0 0x40000000>;
>>>> };
>>>>
>>>>
>>>>
>>>> On Fri, Feb 24, 2017 at 4:53 PM, Julien Grall <julien.gr...@arm.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 21/02/17 12:03, George John wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>> I was trying out xen in salvator-X(M3 Board as described
>>>>>> in
>>>>>>
>>>>>> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization
>>>>>> _Extensions/Salvator-X
>>>>>>
>>>>>> I ran in to following error:
>>>>>>
>>>>>>
>>>>>> U-Boot 2015.04 (Feb 21 2017 - 14:24:48)
>>>>>>
>>>>>> CPU: Renesas Electronics R8A7796 rev 1.0
>>>>>> Board: Salvator-X
>>>>>> I2C: ready
>>>>>> DRAM: 3.9 GiB
>>>>>> MMC: sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2
>>>>>> In: serial
>>>>>> Out: serial
>>>>>> Err: serial
>>>>>> Net: Board Net Initialization Failed
>>>>>> No ethernet found.
>>>>>> Hit any key to stop autoboot: 0
>>>>>> 819584 bytes read in 89 ms (8.8 MiB/s)
>>>>>> 64927 bytes read in 23 ms (2.7 MiB/s)
>>>>>> 14038016 bytes read in 1188 ms (11.3 MiB/s)
>>>>>> 10319 bytes read in 19 ms (530.3 KiB/s)
>>>>>> ## Booting kernel from Legacy Image at 48080000 ...
>>>>>> Image Name: XEN
>>>>>> Image Type: AArch64 Linux Kernel Image (uncompressed)
>>>>>> Data Size: 819520 Bytes = 800.3 KiB
>>>>>> Load Address: 78080000
>>>>>> Entry Point: 78080000
>>>>>> Verifying Checksum ... OK
>>>>>> ## Flattened Device Tree blob at 48000000
>>>>>> Booting using the fdt blob at 0x48000000
>>>>>> Loading Kernel Image ... OK
>>>>>> Using Device Tree in place at 0000000048000000, end
>>>>>> 0000000048012d9e
>>>>>>
>>>>>> Starting kernel ...
>>>>>>
>>>>>> - UART enabled -
>>>>>> - CPU 00000000 booting -
>>>>>> - Current EL 00000008 -
>>>>>> - Xen starting at EL2 -
>>>>>> - Zero BSS -
>>>>>> - Setting up control registers -
>>>>>> - Turning on paging -
>>>>>> - Ready -
>>>>>> (XEN) Checking for initrd in /chosen
>>>>>> (XEN) RAM: 0000000048000000 - 000000007fffffff
>>>>>> (XEN) RAM: 0000000500000000 - 000000053fffffff
>>>>>> (XEN) RAM: 0000000600000000 - 000000063fffffff
>>>>>> (XEN) RAM: 0000000700000000 - 000000073fffffff
>>>>>> (XEN)
>>>>>> (XEN) MODULE[0]: 0000000048000000 - 0000000048010000 Device Tree
>>>>>> (XEN) MODULE[1]: 000000007a000000 - 000000007c000000 Kernel
>>>>>> (XEN) MODULE[2]: 000000007c000000 - 000000007c010000 XSM
>>>>>> (XEN) RESVD[0]: 0000000048000000 - 0000000048010000
>>>>>> (XEN)
>>>>>> (XEN) Command line: dom0_mem=512M console=dtuart dtuart=serial0
>>>>>> dom0_max_vcpus=1 bootscrub=0 flask_enforcing=1
>>>>>> (XEN) Placing Xen at 0x000000007fe00000-0x0000000080000000
>>>>>> (XEN) Update BOOTMOD_XEN from 0000000078080000-0000000078196e01 =>
>>>>>> 000000007fe00000-000000007ff16e01
>>>>>>
>>>>>
>>>>> Which kernel version is it?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> After this, it hangs. What could be the possible reason?
>>>>>>
>>>>>
>>>>> Xen will initialize the heap and then continue into the boot. I would
>>>>> add
>>>>> more debug around setup_mm to see where it failed.
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Julien Grall
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xen.org
>>>>> https://lists.xen.org/xen-devel
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Oleksandr Tyshchenko
>>>>
>>>
>>>
>>
>>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
