Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-25 Thread Iurii Mykhalskyi 
Dear all,

Thanks for all your replies.

I'll keep them in mind while preparing next patch sets.

With the best regards,
Iurii Mykhalskyi

On Fri, Nov 25, 2016 at 11:13 AM, Andrii Anisov 
wrote:

> Dear Iurii,
>
> It was my mistake:
> > Following:
> >> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> >> build issue, described here [2]. I haven't found any better solution
> except
> >> this one.
> >
> > Is not needed.
> > The issue does not appear with the current master HEAD.
>
> With clean build I still face the issue described here:
> https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html.
>
> Sincerely,
> Andrii Anisov.
>



-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-25 Thread Andrii Anisov 
Dear Iurii,

It was my mistake:
> Following:
>> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
>> build issue, described here [2]. I haven't found any better solution except
>> this one.
>
> Is not needed.
> The issue does not appear with the current master HEAD.

With clean build I still face the issue described here:
https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html.

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Julien Grall 



On 23/11/16 14:00, Iurii Mykhalskyi wrote:

Dear all,


Hello Iurii,


Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6


Can you explain why you want to impose a specific version of Xen to the 
user of this board?


If Xen does not work out-of-box on this box, then you should work 
towards upstreaming the missing pieces.


Also, the way you wrote the page and hook into the main wiki page [6] 
will mislead the user because it gives the impression that you can boot 
xen upstream on the board without any change.


So the wiki page needs to be rewritten to make clear that you are not 
using Xen upstream nor Linux upstream but a custom one maintained by you.



Looks like used patches for Xen should be described more briefly:
1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  -
Early console introduction for Salvator-X board


Patch already posted and will be included in the next version.


2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
build issue, described here [2]. I haven't found any better solution
except this one.


Rather than carrying hack on Xen, I would highly recommend you to work 
with the community to fix them upstream. This is a win-win situation for 
everyone.



3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
compilation issue on arm64 platform. Looks like Andrii faces same
problem [3] [4].


We are working with Andrii to fix this.


4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is
not essential, but xsm might be usefull for some use-cases.


You impose the user a specific configuration with option that are not 
necessary. The wiki should compile the minimal way to use Xen on this 
platform, i.e:

- version of Xen
- version of Linux
- DTS used
- U-boot

If you want to use yocto, then fine. But you have to explain what is
done and how the user can modify it.


5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
Dom0 will be allocated at over 4GB space - DMA operation will fail.
According to xen-devel list [5], this patch planned to be included
in Xen 4.9.
6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of
box, but by default Xen traps such calls, so we have to allow such actions.


This patch allows all the guests to issue an SMC. Are you aware that you 
open a security hole for any user using your recipes to build Xen?


Regarding the limitation you pointed on the wiki page [7], you can use 
platform specific code (see specific_mapping and blacklist_dev) rather 
hacking the device tree. This is my preferred way and avoid the user to 
have to port the hack when upgrade the kernel if the DT needs some upgrade.


To conclude, it looks like to me that Xen is not yet ready to officially 
support this board.


I will be happy to review any of these patches when they will be sent 
upstream.


Regards,



[1] https://github.com/qbeeukraine/meta-platform-xen

[2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html

[3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html

[4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html

[5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html



[6] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
[7] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X#Known_limitations


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Iurii Mykhalskyi 
Dear Andrii and all,

On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov 
wrote:

> Iurii,
>
> About the following:
>
> > 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> > build issue, described here [2]. I haven't found any better solution
> except
> > this one.
>
> Please review this [1] thread.
>
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-
> 11/msg01921.html


I have made typos,  Description to 2 & 3 items should exchanged vise-versa.

But I don't agree with this patch - ACPI sould be enable only for ARM64
platforms - in your patch it can be enable for both platforms, depending on
CONFIG_ACPI flag state.

>
>
> Sincerely,
> Andrii Anisov.
>

Thanks for your comments.

With the best regards,
Iurii Mykhalskyi

-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Andrii Anisov 
Dear Iurii,

Following:
> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.

Is not needed.
The issue does not appear with the current master HEAD.

Sincerely,
Andrii Anisov.


On Wed, Nov 23, 2016 at 4:00 PM, Iurii Mykhalskyi
 wrote:
> Dear all,
>
> Andrii, thanks for the remark - I'll rework this patch.
>
> Julien, I have updated yocto layer [1] to use the most recent stable Xen
> version - Xen 4.8-rc6
>
> Looks like used patches for Xen should be described more briefly:
> 1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
> console introduction for Salvator-X board

> 3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
> compilation issue on arm64 platform. Looks like Andrii faces same problem
> [3] [4].
> 4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
> essential, but xsm might be usefull for some use-cases.
> 5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
> Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
> Dom0 will be allocated at over 4GB space - DMA operation will fail.
> According to xen-devel list [5], this patch planned to be included in
> Xen 4.9.
> 6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
> but by default Xen traps such calls, so we have to allow such actions.
>
> [1] https://github.com/qbeeukraine/meta-platform-xen
> [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
> [3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
> [4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
> [5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html
>
> In last email you have written:
>> Also, it is not clear to me why you need a specific device tree and hacked
>> DOM0 linux (see [2]) on this board for Xen. This would need some
>> documentation on the wiki.
>
> Yes, this need some explanation. I'll update related wiki page in few hours.
>
> Thanks for all of your comments.
>
> With the best regards,
> Iurii Mykhalskyi
>
>
>
> On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov 
> wrote:
>>
>> Well,
>>
>> > This patch
>> > https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> > Is a total mess.
>> It seems you've lost some code and related history during porting the
>> original patch.
>>
>> Sincerely,
>> Andrii Anisov.
>>
>> On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov 
>> wrote:
>>>
>>> Dear Iurii,
>>>
>>> This patch
>>> https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>>> arch_fixup_fdt() function, which, as per you idea, is not needed to be built
>>> for the XEN boot. You have no patch lines to introduce CONFIG_XEN so the
>>> code works.
>>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>>> to drop whole the function.
>>>
>>> But the problem in that piece of code still exists:
>>>
>>> u-boot updates the first memory node in the dtb with all memory banks it
>>> found in the board code, does not take into consideration other memory nodes
>>> as a result memory banks in device tree are duplicated
>>> unlike the kernel which tolerates that mess from u-boot, XEN does not
>>> accept memory banks are duplicated and crashes.
>>>
>>> Putting all memory banks into one memory node in the device tree is the
>>> simplest workaround.
>>> I'm not really sure where should be a proper fix. Should it be on u-boot
>>> or XEN side?
>>>
>>> Sincerely,
>>> Andrii Anisov.
>>>
>>
>
>
>
> --
>
> Iurii Mykhalskyi | Senior Software Engineer
> GlobalLogic
> P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Andrii Anisov 
Iurii,

About the following:

> 2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
> build issue, described here [2]. I haven't found any better solution except
> this one.

Please review this [1] thread.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg01921.html

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-23 Thread Iurii Mykhalskyi 
Dear all,

Andrii, thanks for the remark - I'll rework this patch.

Julien, I have updated yocto layer [1] to use the most recent stable Xen
version - Xen 4.8-rc6

Looks like used patches for Xen should be described more briefly:
1. 0001-arm64-renesas-Introduce-early-console-for-Salvator-X.patch  - Early
console introduction for Salvator-X board
2. 0002-libxl-Hack-fix-compilation-on-arm64.patch  - required by to fix
build issue, described here [2]. I haven't found any better solution except
this one.
3. 0003-HACK-Fix-compilation-issues.patch  - is a hack to avoid acpi
compilation issue on arm64 platform. Looks like Andrii faces same problem
[3] [4].
4. 0004-Enable-XSM.patch - enable XSM for arm64 build - this patch is not
essential, but xsm might be usefull for some use-cases.
5. 0005-xen-arm-domain_build-allocate-lowmem-for-dom0-as-muc.patch -
Salvator-X board has 4GB RAM, but has only 32bit DMA controller - so, if
Dom0 will be allocated at over 4GB space - DMA operation will fail.
According to xen-devel list [5], this patch planned to be included in
Xen 4.9.
6. 0006-Do-no-trap-smc-instructions.patch - Renesas use OP-TEE out of box,
but by default Xen traps such calls, so we have to allow such actions.

[1] https://github.com/qbeeukraine/meta-platform-xen
[2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html
[3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01903.html
[4] https://lists.xen.org/archives/html/xen-devel/2016-11/msg01930.html
[5] https://lists.xen.org/archives/html/xen-devel/2016-09/msg02561.html

In last email you have written:
> Also, it is not clear to me why you need a specific device tree and
hacked DOM0 linux (see [2]) on this board for Xen. This would need some
documentation on the wiki.

Yes, this need some explanation. I'll update related wiki page in few hours.

Thanks for all of your comments.

With the best regards,
Iurii Mykhalskyi



On Tue, Nov 22, 2016 at 1:20 PM, Andrii Anisov 
wrote:

> Well,
>
> > This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/
> minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/
> 0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> > Is a total mess.
> It seems you've lost some code and related history during porting the
> original patch.
>
> Sincerely,
> Andrii Anisov.
>
> On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov 
> wrote:
>
>> Dear Iurii,
>>
>> This patch https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/m
>> inimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-
>> arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
>> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
>> arch_fixup_fdt() function, which, as per you idea, is not needed to be
>> built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
>> the code works.
>> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right
>> to drop whole the function.
>>
>> But the problem in that piece of code still exists:
>>
>>- u-boot updates the first memory node in the dtb with all memory
>>banks it found in the board code, does not take into consideration other
>>memory nodes
>>- as a result memory banks in device tree are duplicated
>>- unlike the kernel which tolerates that mess from u-boot, XEN does
>>not accept memory banks are duplicated and crashes.
>>
>> Putting all memory banks into one memory node in the device tree is the
>> simplest workaround.
>> I'm not really sure where should be a proper fix. Should it be on u-boot
>> or XEN side?
>>
>> Sincerely,
>> Andrii Anisov.
>>
>>
>


-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-22 Thread Andrii Anisov 
Well,

> This patch
https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> Is a total mess.
It seems you've lost some code and related history during porting the
original patch.

Sincerely,
Andrii Anisov.

On Tue, Nov 22, 2016 at 12:59 PM, Andrii Anisov 
wrote:

> Dear Iurii,
>
> This patch https://github.com/qbeeukraine/meta-platform-xen/
> blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-
> boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
> Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
> arch_fixup_fdt() function, which, as per you idea, is not needed to be
> built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
> the code works.
> Also arch_fixup_fdt() not only mangles memory nodes, so it is not right to
> drop whole the function.
>
> But the problem in that piece of code still exists:
>
>- u-boot updates the first memory node in the dtb with all memory
>banks it found in the board code, does not take into consideration other
>memory nodes
>- as a result memory banks in device tree are duplicated
>- unlike the kernel which tolerates that mess from u-boot, XEN does
>not accept memory banks are duplicated and crashes.
>
> Putting all memory banks into one memory node in the device tree is the
> simplest workaround.
> I'm not really sure where should be a proper fix. Should it be on u-boot
> or XEN side?
>
> Sincerely,
> Andrii Anisov.
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-22 Thread Andrii Anisov 
Dear Iurii,

This patch
https://github.com/qbeeukraine/meta-platform-xen/blob/2.12/minimal/meta-rcar-gen3-xen/recipes-bsp/u-boot/u-boot/0002-arm-fdt-Don-t-touch-memory-node-from-full-U-Boot-in-.patch
Is a total mess. Somewhy you check defined CONFIG_XEN to introduce the
arch_fixup_fdt() function, which, as per you idea, is not needed to be
built for the XEN boot. You have no patch lines to introduce CONFIG_XEN so
the code works.
Also arch_fixup_fdt() not only mangles memory nodes, so it is not right to
drop whole the function.

But the problem in that piece of code still exists:

   - u-boot updates the first memory node in the dtb with all memory banks
   it found in the board code, does not take into consideration other memory
   nodes
   - as a result memory banks in device tree are duplicated
   - unlike the kernel which tolerates that mess from u-boot, XEN does not
   accept memory banks are duplicated and crashes.

Putting all memory banks into one memory node in the device tree is the
simplest workaround.
I'm not really sure where should be a proper fix. Should it be on u-boot or
XEN side?

Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-21 Thread Julien Grall 

Hello Iurii,

On 21/11/2016 17:12, Iurii Mykhalskyi wrote:

Hello guys,

I have created wiki page for Salvator-X board:
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X


Thank you for that.



And update related yocto layer:
https://github.com/qbeeukraine/meta-platform-xen

Please review & leave your comments.

I am planning to update this layer with Xen 4.8 support in nearly future.


I am a bit confused here. I like the idea of having yocto building 
everything for you, but at the same time you hide the fact that Xen is 
not an upstream version (you carry more patches [1]). Does it mean this 
patch (early console support) is not sufficient to get Xen working on 
the board?


Also, it is not clear to me why you need a specific device tree and 
hacked DOM0 linux (see [2]) on this board for Xen. This would need some 
documentation on the wiki.


Regards,

[1] 
https://github.com/qbeeukraine/meta-platform-xen/tree/2.12/minimal/meta-rcar-gen3-xen/recipes-extended/xen/xen
[2] 
https://github.com/qbeeukraine/meta-platform-xen/tree/2.12/minimal/meta-rcar-gen3-xen/recipes-kernel/linux/linux-renesas/patches


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-21 Thread Iurii Mykhalskyi 
Hello guys,

I have created wiki page for Salvator-X board:
https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X

And update related yocto layer:
https://github.com/qbeeukraine/meta-platform-xen

Please review & leave your comments.

I am planning to update this layer with Xen 4.8 support in nearly future.

With the best regards,
Iurii Mykhalskyi


On Thu, Nov 10, 2016 at 11:34 AM, Dirk Behme 
wrote:

> On 10.11.2016 10:25, Iurii Mykhalskyi wrote:
>
>> Hello Dirk,
>>
>> On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme > > wrote:
>>
>> On 09.11.2016 13:14, Julien Grall wrote:
>>
>> Hello,
>>
>> On 09/11/16 07:14, Dirk Behme wrote:
>>
>> On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
>>
>> Hello Dirk,
>>
>> I have made only single change - I recompile ATF to
>> leave CPU in EL2
>> mode and reflash it.
>>
>>
>>
>> Yes, this is what I meant with 'modifying firmware' ;)
>>
>> You are loading Xen with U-Boot running in EL2, then?
>>
>> With this modification, do all other use cases still work?
>> E.g. load and
>> boot U-Boot and native Linux kernel without Xen?
>>
>>
>> Yes, when Linux is booting from EL2, it will drop to EL1 (see
>> el2_setup). As Andre mentioned on the previous thread, U-boot is
>> running
>> at EL2 on various board (e.g pine64, juno).
>>
>> Modifying the firmware was the right way to go as there is no
>> solution
>> go boot at EL2 from EL1.
>>
>>
>>
>> Yes, correct, from general point of view :)
>>
>> My question to Iurii is more focused to this concrete board, if
>> there everything works fine, too. You know, sometimes the
>> implementation on a board might have bugs while it should work well
>> in theory ;)
>>
>> So I'm just interested if everything works fine for him switching
>> ATF to exit in EL2, or if additional fixes/patches are needed for
>> this board.
>>
>>
>> Looks like all basic functions working normally - I have successfully
>> load linux & rootfs without any additional patches for linux kernel.
>>
>
>
> Ok, thanks for this info :)
>
>
> As you ok with this - I will create Salvator-X board related page on Xen
>> wiki.
>> But first of all, I will update yocto layer mentioned by Andrii with
>> minimal setup, based on the latest Renesas & Xen releases.
>> This should be helpful for easier out of box board setup.
>>
>
>
> Ack
>
> Best regards
>
> Dirk
>
>
>


-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-10 Thread Dirk Behme 

On 10.11.2016 10:25, Iurii Mykhalskyi wrote:

Hello Dirk,

On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme mailto:dirk.be...@de.bosch.com>> wrote:

On 09.11.2016 13:14, Julien Grall wrote:

Hello,

On 09/11/16 07:14, Dirk Behme wrote:

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

I have made only single change - I recompile ATF to
leave CPU in EL2
mode and reflash it.



Yes, this is what I meant with 'modifying firmware' ;)

You are loading Xen with U-Boot running in EL2, then?

With this modification, do all other use cases still work?
E.g. load and
boot U-Boot and native Linux kernel without Xen?


Yes, when Linux is booting from EL2, it will drop to EL1 (see
el2_setup). As Andre mentioned on the previous thread, U-boot is
running
at EL2 on various board (e.g pine64, juno).

Modifying the firmware was the right way to go as there is no
solution
go boot at EL2 from EL1.



Yes, correct, from general point of view :)

My question to Iurii is more focused to this concrete board, if
there everything works fine, too. You know, sometimes the
implementation on a board might have bugs while it should work well
in theory ;)

So I'm just interested if everything works fine for him switching
ATF to exit in EL2, or if additional fixes/patches are needed for
this board.


Looks like all basic functions working normally - I have successfully
load linux & rootfs without any additional patches for linux kernel.



Ok, thanks for this info :)



As you ok with this - I will create Salvator-X board related page on Xen
wiki.
But first of all, I will update yocto layer mentioned by Andrii with
minimal setup, based on the latest Renesas & Xen releases.
This should be helpful for easier out of box board setup.



Ack

Best regards

Dirk



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-10 Thread Iurii Mykhalskyi 
Hello Dirk,

On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme  wrote:

> On 09.11.2016 13:14, Julien Grall wrote:
>
>> Hello,
>>
>> On 09/11/16 07:14, Dirk Behme wrote:
>>
>>> On 08.11.2016 16:41, Iurii Mykhalskyi wrote:
>>>
 Hello Dirk,

 I have made only single change - I recompile ATF to leave CPU in EL2
 mode and reflash it.

>>>
>>>
>>> Yes, this is what I meant with 'modifying firmware' ;)
>>>
>>> You are loading Xen with U-Boot running in EL2, then?
>>>
>>> With this modification, do all other use cases still work? E.g. load and
>>> boot U-Boot and native Linux kernel without Xen?
>>>
>>
>> Yes, when Linux is booting from EL2, it will drop to EL1 (see
>> el2_setup). As Andre mentioned on the previous thread, U-boot is running
>> at EL2 on various board (e.g pine64, juno).
>>
>> Modifying the firmware was the right way to go as there is no solution
>> go boot at EL2 from EL1.
>>
>
>
> Yes, correct, from general point of view :)
>
> My question to Iurii is more focused to this concrete board, if there
> everything works fine, too. You know, sometimes the implementation on a
> board might have bugs while it should work well in theory ;)
>
> So I'm just interested if everything works fine for him switching ATF to
> exit in EL2, or if additional fixes/patches are needed for this board.


Looks like all basic functions working normally - I have successfully load
linux & rootfs without any additional patches for linux kernel.


> Best regards
>
> Dirk
>


As you ok with this - I will create Salvator-X board related page on Xen
wiki.
But first of all, I will update yocto layer mentioned by Andrii with
minimal setup, based on the latest Renesas & Xen releases.
This should be helpful for easier out of box board setup.

Thank you.

With the best regards,
Iurii Mykhalskyi


-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467  S mad-nemoi
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-09 Thread Dirk Behme 

On 09.11.2016 13:14, Julien Grall wrote:

Hello,

On 09/11/16 07:14, Dirk Behme wrote:

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.



Yes, this is what I meant with 'modifying firmware' ;)

You are loading Xen with U-Boot running in EL2, then?

With this modification, do all other use cases still work? E.g. load and
boot U-Boot and native Linux kernel without Xen?


Yes, when Linux is booting from EL2, it will drop to EL1 (see
el2_setup). As Andre mentioned on the previous thread, U-boot is running
at EL2 on various board (e.g pine64, juno).

Modifying the firmware was the right way to go as there is no solution
go boot at EL2 from EL1.



Yes, correct, from general point of view :)

My question to Iurii is more focused to this concrete board, if there 
everything works fine, too. You know, sometimes the implementation on a 
board might have bugs while it should work well in theory ;)


So I'm just interested if everything works fine for him switching ATF to 
exit in EL2, or if additional fixes/patches are needed for this board.


Best regards

Dirk

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-09 Thread Julien Grall 

Hello,

On 09/11/16 07:14, Dirk Behme wrote:

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.



Yes, this is what I meant with 'modifying firmware' ;)

You are loading Xen with U-Boot running in EL2, then?

With this modification, do all other use cases still work? E.g. load and
boot U-Boot and native Linux kernel without Xen?


Yes, when Linux is booting from EL2, it will drop to EL1 (see 
el2_setup). As Andre mentioned on the previous thread, U-boot is running 
at EL2 on various board (e.g pine64, juno).


Modifying the firmware was the right way to go as there is no solution 
go boot at EL2 from EL1.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Dirk Behme 

Hi Iurii,

On 08.11.2016 16:41, Iurii Mykhalskyi wrote:

Hello Dirk,

I have made only single change - I recompile ATF to leave CPU in EL2
mode and reflash it.



Yes, this is what I meant with 'modifying firmware' ;)

You are loading Xen with U-Boot running in EL2, then?

With this modification, do all other use cases still work? E.g. load and 
boot U-Boot and native Linux kernel without Xen?




Looks like this way are the mostly "correct" approach for this board.

All changes are made in publicly available sources, based on official
Renesas H3 yocto layer - https://github.com/renesas-rcar/meta-renesas

If you don't mind - I can create & handle documentation page about board
setup and take ownership about further board support.



I'm fine with that. Thanks!


Best regards

Dirk




On Tue, Nov 8, 2016 at 5:22 PM, Dirk Behme mailto:dirk.be...@gmail.com>> wrote:

On 08.11.2016 15:30, Julien Grall wrote:

Hello Iurii,

Dirk (in CC) sent a similar patch few months ago to add support for
this board (see [1]).

I didn't ack the patch back then because I wanted to see
documentation
on the wiki to bring up Xen on this board (see [2] for the
requirements). I didn't see any follow-up since then for this board.

Can one of you write a documentation for this board



Yes, that would be nice.

As mentioned, I couldn't find an 'easy' way to load Xen without
modifying the firmware (U-Boot or ATF) or using a JTAG debugger.
Therefore I hesitated to write that documentation.

Maybe Iurii found an easier, more user compatible way?

Best regards

Dirk



and take

"ownership" on this board?

Regards,

[1]

https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html



[2]

https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html






___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Andrii Anisov 
Dirk,

IuriiK did great work at the beginning of the summer to bringup XEN on
Salvator-X in a short term.
Due to different reasons it was a bit hacky and was not exposed here,
but you can find the stuff here:
https://github.com/qbeeukraine/meta-platform-xen. I'm not really sure
if the final code was pushed there, but still consists of useful
things.

I'm really happy they decided to upstream it.

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Iurii Mykhalskyi 
Hello Dirk,

I have made only single change - I recompile ATF to leave CPU in EL2 mode
and reflash it.
Looks like this way are the mostly "correct" approach for this board.

All changes are made in publicly available sources, based on official
Renesas H3 yocto layer - https://github.com/renesas-rcar/meta-renesas

If you don't mind - I can create & handle documentation page about board
setup and take ownership about further board support.

With the best regards,
Iurii Mykhalskyi


On Tue, Nov 8, 2016 at 5:22 PM, Dirk Behme  wrote:

> On 08.11.2016 15:30, Julien Grall wrote:
>
>> Hello Iurii,
>>
>> Dirk (in CC) sent a similar patch few months ago to add support for
>> this board (see [1]).
>>
>> I didn't ack the patch back then because I wanted to see documentation
>> on the wiki to bring up Xen on this board (see [2] for the
>> requirements). I didn't see any follow-up since then for this board.
>>
>> Can one of you write a documentation for this board
>>
>
>
> Yes, that would be nice.
>
> As mentioned, I couldn't find an 'easy' way to load Xen without modifying
> the firmware (U-Boot or ATF) or using a JTAG debugger. Therefore I
> hesitated to write that documentation.
>
> Maybe Iurii found an easier, more user compatible way?
>
> Best regards
>
> Dirk
>
>
>
> and take
>
>> "ownership" on this board?
>>
>> Regards,
>>
>> [1]
>> https://lists.xenproject.org/archives/html/xen-devel/2016-07
>> /msg00315.html
>>
>> [2]
>> https://lists.xenproject.org/archives/html/xen-devel/2016-07
>> /msg00130.html
>>
>>
>> On 08/11/2016 14:20, Iurii Mykhalskyi wrote:
>>
>>> From: Iurii Konovalenko 
>>>
>>> Add support for the "Salvator-X" development board based on R-Car H3
>>> SoC
>>> which has SCIF compatible UART.
>>>
>>> Signed-off-by: Iurii Konovalenko 
>>> Signed-off-by: Iurii Mykhalskyi 
>>> ---
>>>  xen/arch/arm/Rules.mk |  1 +
>>>  xen/arch/arm/arm64/debug-scif.inc | 51
>>> +++
>>>  2 files changed, 52 insertions(+)
>>>  create mode 100644 xen/arch/arm/arm64/debug-scif.inc
>>>
>>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>>> index 569a0ba..7989634 100644
>>> --- a/xen/arch/arm/Rules.mk
>>> +++ b/xen/arch/arm/Rules.mk
>>> @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  :=
>>> pl011,0x1c09,115200
>>>  EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
>>>  EARLY_PRINTK_juno   := pl011,0x7ff8
>>>  EARLY_PRINTK_lager  := scif,0xe6e6
>>> +EARLY_PRINTK_salvator   := scif,0xe6e88000
>>>  EARLY_PRINTK_midway := pl011,0xfff36000
>>>  EARLY_PRINTK_omap5432   := 8250,0x4802,2
>>>  EARLY_PRINTK_seattle:= pl011,0xe101
>>> diff --git a/xen/arch/arm/arm64/debug-scif.inc
>>> b/xen/arch/arm/arm64/debug-scif.inc
>>> new file mode 100644
>>> index 000..1f4d657
>>> --- /dev/null
>>> +++ b/xen/arch/arm/arm64/debug-scif.inc
>>> @@ -0,0 +1,51 @@
>>> +/*
>>> + * xen/arch/arm/arm64/debug-scif.inc
>>> + *
>>> + * SCIF specific debug code
>>> + *
>>> + * Oleksandr Tyshchenko 
>>> + * Iurii Konovalenko 
>>> + * Iurii Mykhalskyi 
>>> + * Copyright (C) 2014-2016, Globallogic.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of the GNU General Public License as
>>> published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +
>>> +/* SCIF UART wait UART to be ready to transmit
>>> + * rb: register which contains the UART base address
>>> + * rc: scratch register
>>> + */
>>> +.macro early_uart_ready xb c
>>> +1:
>>> +ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
>>> register) */
>>> +tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
>>> +beq1b/* Wait for the UART to be
>>> ready */
>>> +.endm
>>> +
>>> +/* SCIF UART transmit character
>>> + * rb: register which contains the UART base address
>>> + * rt: register which contains the character to transmit
>>> + */
>>> +.macro early_uart_transmit xb wt
>>> +strb   \wt, [\xb, #SCIF_SCFTDR]  /* ->
>>> SCFTDR (data register) */
>>> +ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <-
>>> SCFSR (status register) */
>>> +and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear
>>> TEND and TDFE bits */
>>> +strh   \wt, [\xb, #SCIF_SCFSR]   /* ->
>>> SCFSR (status register) */
>>> +.endm
>>> +
>>> +/*
>>> + * Local variables:
>>> + * mode: ASM
>>> + * indent-tabs-mode: nil
>>> + * End:
>>> + */
>>>
>>>
>>
>


-- 

Iurii Mykhalskyi | Senior Software Engineer
GlobalLogic
P +38.044.492.9695x3664  M +38.096.311.5467

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Dirk Behme 

On 08.11.2016 15:30, Julien Grall wrote:

Hello Iurii,

Dirk (in CC) sent a similar patch few months ago to add support for
this board (see [1]).

I didn't ack the patch back then because I wanted to see documentation
on the wiki to bring up Xen on this board (see [2] for the
requirements). I didn't see any follow-up since then for this board.

Can one of you write a documentation for this board



Yes, that would be nice.

As mentioned, I couldn't find an 'easy' way to load Xen without 
modifying the firmware (U-Boot or ATF) or using a JTAG debugger. 
Therefore I hesitated to write that documentation.


Maybe Iurii found an easier, more user compatible way?

Best regards

Dirk


and take

"ownership" on this board?

Regards,

[1]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html

[2]
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html


On 08/11/2016 14:20, Iurii Mykhalskyi wrote:

From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3
SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51
+++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  :=
pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or
modify
+ * it under the terms of the GNU General Public License as
published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be
ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* ->
SCFTDR (data register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <-
SCFSR (status register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear
TEND and TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* ->
SCFSR (status register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */






___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Julien Grall 

Hello Iurii,

Dirk (in CC) sent a similar patch few months ago to add support for this 
board (see [1]).


I didn't ack the patch back then because I wanted to see documentation 
on the wiki to bring up Xen on this board (see [2] for the 
requirements). I didn't see any follow-up since then for this board.


Can one of you write a documentation for this board and take "ownership" 
on this board?


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00315.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html


On 08/11/2016 14:20, Iurii Mykhalskyi wrote:

From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3 SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51 +++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  := pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc 
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] arm64:renesas: Introduce early console for Salvator-X board

2016-11-08 Thread Iurii Mykhalskyi 
From: Iurii Konovalenko 

Add support for the "Salvator-X" development board based on R-Car H3 SoC
which has SCIF compatible UART.

Signed-off-by: Iurii Konovalenko 
Signed-off-by: Iurii Mykhalskyi 
---
 xen/arch/arm/Rules.mk |  1 +
 xen/arch/arm/arm64/debug-scif.inc | 51 +++
 2 files changed, 52 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..7989634 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel  := pl011,0x1c09,115200
 EARLY_PRINTK_exynos5250 := exynos4210,0x12c2
 EARLY_PRINTK_juno   := pl011,0x7ff8
 EARLY_PRINTK_lager  := scif,0xe6e6
+EARLY_PRINTK_salvator   := scif,0xe6e88000
 EARLY_PRINTK_midway := pl011,0xfff36000
 EARLY_PRINTK_omap5432   := 8250,0x4802,2
 EARLY_PRINTK_seattle:= pl011,0xe101
diff --git a/xen/arch/arm/arm64/debug-scif.inc 
b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 000..1f4d657
--- /dev/null
+++ b/xen/arch/arm/arm64/debug-scif.inc
@@ -0,0 +1,51 @@
+/*
+ * xen/arch/arm/arm64/debug-scif.inc
+ *
+ * SCIF specific debug code
+ *
+ * Oleksandr Tyshchenko 
+ * Iurii Konovalenko 
+ * Iurii Mykhalskyi 
+ * Copyright (C) 2014-2016, Globallogic.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+/* SCIF UART wait UART to be ready to transmit
+ * rb: register which contains the UART base address
+ * rc: scratch register
+ */
+.macro early_uart_ready xb c
+1:
+ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status register) */
+tstw\c, #SCFSR_TDFE  /* Check TDFE bit */
+beq1b/* Wait for the UART to be ready */
+.endm
+
+/* SCIF UART transmit character
+ * rb: register which contains the UART base address
+ * rt: register which contains the character to transmit
+ */
+.macro early_uart_transmit xb wt
+strb   \wt, [\xb, #SCIF_SCFTDR]  /* -> SCFTDR (data 
register) */
+ldrh   \wt, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status 
register) */
+and\wt, \wt, #(~(SCFSR_TEND | SCFSR_TDFE))   /* Clear TEND and 
TDFE bits */
+strh   \wt, [\xb, #SCIF_SCFSR]   /* -> SCFSR (status 
register) */
+.endm
+
+/*
+ * Local variables:
+ * mode: ASM
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.10.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel