Renesas R-Car Gen3 SoCs earlyprintk support.

Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

These patches add SCIF earlyprintk support as well as a configuration 
suitable for R-Car Gen3 SoCs based development boards.

 [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk
 [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

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

[PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

[Andrii Anisov]

From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>

Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.

Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 xen/arch/arm/arm64/debug-scif.inc | 51 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 xen/arch/arm/arm64/debug-scif.inc

diff --git a/xen/arch/arm/arm64/debug-scif.inc b/xen/arch/arm/arm64/debug-scif.inc
new file mode 100644
index 0000000..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 <oleksandr.tyshchenko@globallogic.com>
+ * Iurii Konovalenko <iurii.konovalenko@globallogic.com>
+ * Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
+ * 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 <asm/scif-uart.h>
+
+/* 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) */
+        tst    w\c, #SCFSR_TDFE          /* Check TDFE bit */
+        beq    1b                        /* 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.7.4


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

[PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
boards, like:
 - Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
 - M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
 - H3ULCB [http://elinux.org/R-Car/Boards/H3SK]

Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 docs/misc/arm/early-printk.txt | 1 +
 xen/arch/arm/Rules.mk          | 1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
index 41b528b..a7a3d94 100644
--- a/docs/misc/arm/early-printk.txt
+++ b/docs/misc/arm/early-printk.txt
@@ -39,6 +39,7 @@ the name of the machine:
   - fastmodel: printk on ARM Fastmodel software emulators
   - juno: printk with pl011 on Juno platform
   - lager: printk with SCIF0 on Renesas R-Car H2 processors
+  - rcar3: printk with SCIF2 on Renesas R-Car H3 processors
   - midway: printk with the pl011 on Calxeda Midway processors
   - omap5432: printk with UART3 on TI OMAP5432 processors
   - seattle: printk with pl011 for AMD Seattle processor
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 569a0ba..9c1cb74 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel      := pl011,0x1c090000,115200
 EARLY_PRINTK_exynos5250     := exynos4210,0x12c20000
 EARLY_PRINTK_juno           := pl011,0x7ff80000
 EARLY_PRINTK_lager          := scif,0xe6e60000
+EARLY_PRINTK_rcar3          := scif,0xe6e88000
 EARLY_PRINTK_midway         := pl011,0xfff36000
 EARLY_PRINTK_omap5432       := 8250,0x48020000,2
 EARLY_PRINTK_seattle        := pl011,0xe1010000
-- 
2.7.4


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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

Hi,

Please CC relevant maintainers on those patches.

On 05/07/17 17:29, Andrii Anisov wrote:
> These patches add SCIF earlyprintk support as well as a configuration
> suitable for R-Car Gen3 SoCs based development boards.
>
>  [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk
>  [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

I'd like to have my comments (see the discussion on "Xen Community Call 
21/07/16 meeting minutes") before considering acking those two patches.

Cheers,

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

Julien,


On 05.07.17 19:34, Julien Grall wrote:
> I'd like to have my comments (see the discussion on "Xen Community 
> Call 21/07/16 meeting minutes") before considering acking those two 
> patches.
Its clear. It is just the first step.

Taking all discussed actions will take more time.

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

On 05/07/17 17:41, Andrii Anisov wrote:
> Julien,

Hi Andrii,

> On 05.07.17 19:34, Julien Grall wrote:
>> I'd like to have my comments (see the discussion on "Xen Community
>> Call 21/07/16 meeting minutes") before considering acking those two
>> patches.
> Its clear. It is just the first step.
>
> Taking all discussed actions will take more time.

Yocto aside, I think updating the wiki pages don't take too long. It is 
just adding:

    * Adding a point of contact in 
https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
    * Make sure Salvator-X webpage is accurate and doesn't contain 
non-upstream pointer (i.e dropping this yocto link contain security flaw).

I am not really willing to ack it without at least that done.

Cheers,

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

On 05.07.17 19:50, Julien Grall wrote:
> Yocto aside, I think updating the wiki pages don't take too long. It 
> is just adding:
>
>    * Make sure Salvator-X webpage is accurate and doesn't contain 
> non-upstream pointer (i.e dropping this yocto link contain security 
> flaw).
I suppose that will not work.
BSP with mentioned layer will do SMC due to OP-TEE integration and will 
not boot.

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

Hi Andrii,

On 05/07/17 18:00, Andrii Anisov wrote:
> On 05.07.17 19:50, Julien Grall wrote:
>> Yocto aside, I think updating the wiki pages don't take too long. It
>> is just adding:
>>
>>    * Make sure Salvator-X webpage is accurate and doesn't contain
>> non-upstream pointer (i.e dropping this yocto link contain security
>> flaw).
> I suppose that will not work.
> BSP with mentioned layer will do SMC due to OP-TEE integration and will
> not boot.

I prefer to say: "This is not supported today because of XXX. With the 
following patches, it is possible to boot.". Rather than "This is 
supported if you download from this github, I don't give Xen version and 
don't even mention the patches on top...".

The wiki page gives the false impression that Xen upstream is fully 
supported on Renesas, whilst from what you said this is not true and 
change are required in the BSP.

Cheers,

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

On 05.07.17 20:18, Julien Grall wrote:
> I prefer to say: "This is not supported today because of XXX. With the 
> following patches, it is possible to boot.". Rather than "This is 
> supported if you download from this github, I don't give Xen version 
> and don't even mention the patches on top...".
Actually statements "Xen is fully supported" and "changes are required 
in the BSP" do not contradict each other, if we treat those changes 
(disabling OP-TEE) as a matter of BSP configuration (which they are). Do 
you agree?

> The wiki page gives the false impression that Xen upstream is fully 
> supported on Renesas, whilst from what you said this is not true and 
> change are required in the BSP.
I would say in different words: XEN upstream is fully supported on 
Renesas, but due to XEN functionality gaps the BSP should be adjusted 
appropriately.

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

Hi Andrii,

On 06/07/17 12:31, Andrii Anisov wrote:
>
> On 05.07.17 20:18, Julien Grall wrote:
>> I prefer to say: "This is not supported today because of XXX. With the
>> following patches, it is possible to boot.". Rather than "This is
>> supported if you download from this github, I don't give Xen version
>> and don't even mention the patches on top...".
> Actually statements "Xen is fully supported" and "changes are required
> in the BSP" do not contradict each other, if we treat those changes
> (disabling OP-TEE) as a matter of BSP configuration (which they are). Do
> you agree?

Well, I would expect no changes in either in the BSP, kernel, 
device-tree when you run with Xen.

For all the platform currently supported, we can boot Xen with the 
device-tree provided by the firmware or from Linux upstream. The Linux 
kernel is not modified but recompiled with XEN options enabled.

Xen should take care of the missing mappings and/or disabling device not 
supported.

So I don't see how the Renesas board should be different here. If you 
need to modify the device-tree or Linux. Then there is missing pieces in 
Xen or the BSP is not doing the right thing (i.e auto-detect support).

>
>> The wiki page gives the false impression that Xen upstream is fully
>> supported on Renesas, whilst from what you said this is not true and
>> change are required in the BSP.
> I would say in different words: XEN upstream is fully supported on
> Renesas, but due to XEN functionality gaps the BSP should be adjusted
> appropriately.

You can't say in the same sentence, the board is fully supported and 
there are missing functionality that requires change in the BSP. They 
are incompatible.

I agree that we are able to boot Xen on Renesas (not sure to which 
extend without modification). But you can't claim it is fully supported 
until all those gaps are fixed.

Anyway, we should at least list the gaps on the wiki page for helping 
potential users.

Cheers,

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

On 06.07.17 14:43, Julien Grall wrote:
> Well, I would expect no changes in either in the BSP, kernel, 
> device-tree when you run with Xen.
Even without adding XEN specific chosen node? Or you do not count it as 
a devtree change?

>>> The wiki page gives the false impression that Xen upstream is fully
>>> supported on Renesas, whilst from what you said this is not true and
>>> change are required in the BSP.
>> I would say in different words: XEN upstream is fully supported on
>> Renesas, but due to XEN functionality gaps the BSP should be adjusted
>> appropriately.
>
> You can't say in the same sentence, the board is fully supported and 
> there are missing functionality that requires change in the BSP. They 
> are incompatible.
>
> I agree that we are able to boot Xen on Renesas (not sure to which 
> extend without modification). But you can't claim it is fully 
> supported until all those gaps are fixed.
Well...
Do you say that calls to ARM TEE from XEN domains works for all 
supported boards? And smc trapping is somehow Renesas specific?
Or you state that TEE is never provided as a part of BSP for supported 
boards? So nobody mention the gap?
Maybe you claim BSP of all supported boards goes out of bootloader in 
Hypervisor mode/EL2? So no changes to FW/bootloader should be ever done 
for supported boards?

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

Hi Andrii,

On 06/07/17 13:24, Andrii Anisov wrote:
> On 06.07.17 14:43, Julien Grall wrote:
>> Well, I would expect no changes in either in the BSP, kernel,
>> device-tree when you run with Xen.
> Even without adding XEN specific chosen node? Or you do not count it as
> a devtree change?

I don't count the chosen node. This could be done via the u-boot command 
line, so no need to load a separate DT.

>
>>>> The wiki page gives the false impression that Xen upstream is fully
>>>> supported on Renesas, whilst from what you said this is not true and
>>>> change are required in the BSP.
>>> I would say in different words: XEN upstream is fully supported on
>>> Renesas, but due to XEN functionality gaps the BSP should be adjusted
>>> appropriately.
>>
>> You can't say in the same sentence, the board is fully supported and
>> there are missing functionality that requires change in the BSP. They
>> are incompatible.
>>
>> I agree that we are able to boot Xen on Renesas (not sure to which
>> extend without modification). But you can't claim it is fully
>> supported until all those gaps are fixed.
> Well...
> Do you say that calls to ARM TEE from XEN domains works for all
> supported boards? And smc trapping is somehow Renesas specific?

I am not aware of any board we currently support requiring to issue SMC 
calls.

We used to have one in the past, but this has been fixed in the BSP to 
avoid issuing SMC when it is not allowed.

> Or you state that TEE is never provided as a part of BSP for supported
> boards? So nobody mention the gap?

You are the first person looking actively at TEE with Xen upstream. I 
personally don't have any board that is using TEE.

Are you saying TEE will not be detected via the Device Tree and the BSP 
will always assume it is present?

> Maybe you claim BSP of all supported boards goes out of bootloader in
> Hypervisor mode/EL2? So no changes to FW/bootloader should be ever done
> for supported boards?

If the bootloader does not leave you in EL2, then it is a bug in the 
bootloader that should be fixed in the official BSP. Not in a separate 
repository just for Xen.

My point is we should work with Renesas to get the official BSP to 
support Xen rather than forking the BSP and carry all the changes.

This is more sustainable and less overhead for everyone in the future.

Cheers,

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

Dear Julien,


On 06.07.17 15:35, Julien Grall wrote:
> I don't count the chosen node. This could be done via the u-boot 
> command line, so no need to load a separate DT.
I looked through all available manuals.
Most of them imply significant amount of manual actions to start the 
system. From one hand it is good for understanding of the required 
changes, from other hand - to play with the system one will reinvent the 
wheel to automate those actions.
Our approach is to hide all details under the hood to provide a system 
to play with.
Also, as I know, Renesas does not provide any prebuilts, the yocto build 
is the only way to get binaries, so IMHO providing meta-layer over their 
pack is pretty natural.
>>>>> The wiki page gives the false impression that Xen upstream is fully
>>>>> supported on Renesas, whilst from what you said this is not true and
>>>>> change are required in the BSP.
>>>> I would say in different words: XEN upstream is fully supported on
>>>> Renesas, but due to XEN functionality gaps the BSP should be adjusted
>>>> appropriately.
>>>
>>> You can't say in the same sentence, the board is fully supported and
>>> there are missing functionality that requires change in the BSP. They
>>> are incompatible.
>>>
>>> I agree that we are able to boot Xen on Renesas (not sure to which
>>> extend without modification). But you can't claim it is fully
>>> supported until all those gaps are fixed.
>> Well...
>> Do you say that calls to ARM TEE from XEN domains works for all
>> supported boards? And smc trapping is somehow Renesas specific?
>
> I am not aware of any board we currently support requiring to issue 
> SMC calls.
>
> We used to have one in the past, but this has been fixed in the BSP to 
> avoid issuing SMC when it is not allowed.
>> Or you state that TEE is never provided as a part of BSP for supported
>> boards? So nobody mention the gap?
>
> You are the first person looking actively at TEE with Xen upstream. I 
> personally don't have any board that is using TEE.
>
> Are you saying TEE will not be detected via the Device Tree and the 
> BSP will always assume it is present?
Yep, it is. At the moment it seems to be weird.

> If the bootloader does not leave you in EL2, then it is a bug in the 
> bootloader that should be fixed in the official BSP. 
In Renesas'es case, that is a matter of configuration. ATFW by default 
is built without the option to run bootloader in EL2.

> Not in a separate repository just for Xen.
At least here [1] it is described in such a way.

> My point is we should work with Renesas to get the official BSP to 
> support Xen rather than forking the BSP and carry all the changes.
It is fair enough. We are working with Renesas to put required changes 
to the official BSP. But this directly depends on what Volodymyr Babchuk 
does for SMC.

> This is more sustainable and less overhead for everyone in the future.
I do apologize for being too expressive.
I just want to understand how to claim R-Car Gen3 support in XEN with 
what we have now. With known limitations and patches to the BSP.
Having required changes in the official BSP will take much more time.

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Bootloader

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Julien Grall]

On 07/07/17 11:47, Andrii Anisov wrote:
> Dear Julien,
>
>
> On 06.07.17 15:35, Julien Grall wrote:
>> I don't count the chosen node. This could be done via the u-boot
>> command line, so no need to load a separate DT.
> I looked through all available manuals.
> Most of them imply significant amount of manual actions to start the
> system. From one hand it is good for understanding of the required
> changes, from other hand - to play with the system one will reinvent the
> wheel to automate those actions.

Not really, you can modify the U-boot environment and save it...

> Our approach is to hide all details under the hood to provide a system
> to play with.
> Also, as I know, Renesas does not provide any prebuilts, the yocto build
> is the only way to get binaries, so IMHO providing meta-layer over their
> pack is pretty natural.
>>>>>> The wiki page gives the false impression that Xen upstream is fully
>>>>>> supported on Renesas, whilst from what you said this is not true and
>>>>>> change are required in the BSP.
>>>>> I would say in different words: XEN upstream is fully supported on
>>>>> Renesas, but due to XEN functionality gaps the BSP should be adjusted
>>>>> appropriately.
>>>>
>>>> You can't say in the same sentence, the board is fully supported and
>>>> there are missing functionality that requires change in the BSP. They
>>>> are incompatible.
>>>>
>>>> I agree that we are able to boot Xen on Renesas (not sure to which
>>>> extend without modification). But you can't claim it is fully
>>>> supported until all those gaps are fixed.
>>> Well...
>>> Do you say that calls to ARM TEE from XEN domains works for all
>>> supported boards? And smc trapping is somehow Renesas specific?
>>
>> I am not aware of any board we currently support requiring to issue
>> SMC calls.
>>
>> We used to have one in the past, but this has been fixed in the BSP to
>> avoid issuing SMC when it is not allowed.
>>> Or you state that TEE is never provided as a part of BSP for supported
>>> boards? So nobody mention the gap?
>>
>> You are the first person looking actively at TEE with Xen upstream. I
>> personally don't have any board that is using TEE.
>>
>> Are you saying TEE will not be detected via the Device Tree and the
>> BSP will always assume it is present?
> Yep, it is. At the moment it seems to be weird.
>
>> If the bootloader does not leave you in EL2, then it is a bug in the
>> bootloader that should be fixed in the official BSP.
> In Renesas'es case, that is a matter of configuration. ATFW by default
> is built without the option to run bootloader in EL2.
>
>> Not in a separate repository just for Xen.
> At least here [1] it is described in such a way.

The bootloader section is not Xen specific. It points to the official 
sunxi bootloader.

>
>> My point is we should work with Renesas to get the official BSP to
>> support Xen rather than forking the BSP and carry all the changes.
> It is fair enough. We are working with Renesas to put required changes
> to the official BSP. But this directly depends on what Volodymyr Babchuk
> does for SMC.
>
>> This is more sustainable and less overhead for everyone in the future.
> I do apologize for being too expressive.
> I just want to understand how to claim R-Car Gen3 support in XEN with
> what we have now. With known limitations and patches to the BSP.

You can say it is supported and listing known limitations, not saying it 
is fully supported. As you said, there is a long way to end up fully 
support.

Cheers,

> Having required changes in the official BSP will take much more time.
>
> [1]
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner#Bootloader
>
>

-- 
Julien Grall

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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

On 07.07.17 13:55, Julien Grall wrote:
> You can say it is supported and listing known limitations, not saying 
> it is fully supported. As you said, there is a long way to end up 
> fully support.
Got it.

-- 

*Andrii Anisov*



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

Re: Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

Hello Julien,

On 05.07.17 19:50, Julien Grall wrote:
> Yocto aside, I think updating the wiki pages don't take too long. It 
> is just adding:
>
>    * Adding a point of contact in 
> https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
>    * Make sure Salvator-X webpage is accurate and doesn't contain 
> non-upstream pointer (i.e dropping this yocto link contain security 
> flaw).
I've updated the wiki [1]. Point of contact in [2] was updated earlier.

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X
[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results

-- 

*Andrii Anisov*


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

Re: [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

[Andrii Anisov]

+ Stefano as a maintainer.

Dear all,

Any objections on this patch?


On 05.07.17 19:29, Andrii Anisov wrote:
> From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>
> Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
>
> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
> ---
>   xen/arch/arm/arm64/debug-scif.inc | 51 +++++++++++++++++++++++++++++++++++++++
>   1 file changed, 51 insertions(+)
>   create mode 100644 xen/arch/arm/arm64/debug-scif.inc
>
> diff --git a/xen/arch/arm/arm64/debug-scif.inc b/xen/arch/arm/arm64/debug-scif.inc
> new file mode 100644
> index 0000000..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 <oleksandr.tyshchenko@globallogic.com>
> + * Iurii Konovalenko <iurii.konovalenko@globallogic.com>
> + * Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
> + * 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 <asm/scif-uart.h>
> +
> +/* 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) */
> +        tst    w\c, #SCFSR_TDFE          /* Check TDFE bit */
> +        beq    1b                        /* 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:
> + */

-- 

*Andrii Anisov*



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

Re: [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

[Andrii Anisov]

+ Stefano as a maintainer.

Dear all,

Any objections on this patch?


On 05.07.17 19:29, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
>
> Introduce an earlyprintk configuration for R-Car Gen3 SoC based development
> boards, like:
>   - Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
>   - M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
>   - H3ULCB [http://elinux.org/R-Car/Boards/H3SK]
>
> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
> ---
>   docs/misc/arm/early-printk.txt | 1 +
>   xen/arch/arm/Rules.mk          | 1 +
>   2 files changed, 2 insertions(+)
>
> diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt
> index 41b528b..a7a3d94 100644
> --- a/docs/misc/arm/early-printk.txt
> +++ b/docs/misc/arm/early-printk.txt
> @@ -39,6 +39,7 @@ the name of the machine:
>     - fastmodel: printk on ARM Fastmodel software emulators
>     - juno: printk with pl011 on Juno platform
>     - lager: printk with SCIF0 on Renesas R-Car H2 processors
> +  - rcar3: printk with SCIF2 on Renesas R-Car H3 processors
>     - midway: printk with the pl011 on Calxeda Midway processors
>     - omap5432: printk with UART3 on TI OMAP5432 processors
>     - seattle: printk with pl011 for AMD Seattle processor
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 569a0ba..9c1cb74 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel      := pl011,0x1c090000,115200
>   EARLY_PRINTK_exynos5250     := exynos4210,0x12c20000
>   EARLY_PRINTK_juno           := pl011,0x7ff80000
>   EARLY_PRINTK_lager          := scif,0xe6e60000
> +EARLY_PRINTK_rcar3          := scif,0xe6e88000
>   EARLY_PRINTK_midway         := pl011,0xfff36000
>   EARLY_PRINTK_omap5432       := 8250,0x48020000,2
>   EARLY_PRINTK_seattle        := pl011,0xe1010000

-- 

*Andrii Anisov*



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

Re: [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

[Julien Grall]

On 26/07/17 16:25, Andrii Anisov wrote:
> + Stefano as a maintainer.
>
> Dear all,
>
> Any objections on this patch?

I would have appreciated to be CC as well...

 >
>
> On 05.07.17 19:29, Andrii Anisov wrote:
>> From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>>
>> Add support for a SCIF compatible UART found in Renesas R-Car Gen3 SoCs.
>>
>> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
>> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
>> ---
>>   xen/arch/arm/arm64/debug-scif.inc | 51
>> +++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 51 insertions(+)
>>   create mode 100644 xen/arch/arm/arm64/debug-scif.inc
>>
>> diff --git a/xen/arch/arm/arm64/debug-scif.inc
>> b/xen/arch/arm/arm64/debug-scif.inc
>> new file mode 100644
>> index 0000000..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 <oleksandr.tyshchenko@globallogic.com>
>> + * Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>> + * Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
>> + * 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 <asm/scif-uart.h>
>> +
>> +/* SCIF UART wait UART to be ready to transmit

Coding style.

>> + * rb: register which contains the UART base address

Wrong name

>> + * rc: scratch register

Ditto

>> + */
>> +.macro early_uart_ready xb c
>> +1:
>> +        ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
>> register) */
>> +        tst    w\c, #SCFSR_TDFE          /* Check TDFE bit */
>> +        beq    1b                        /* Wait for the UART to be
>> ready */
>> +.endm
>> +
>> +/* SCIF UART transmit character

Ditto

>> + * rb: register which contains the UART base address

Ditto

>> + * rt: register which contains the character to transmit

Ditto

>> + */
>> +.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:
>> + */
>

Cheers,

-- 
Julien Grall

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

Re: [PATCH 2/2] xen:arm: earlyprintk configuration for R-Car Gen3 boards

[Julien Grall]

Hi,

On 26/07/17 16:25, Andrii Anisov wrote:
> + Stefano as a maintainer.
>
> Dear all,
>
> Any objections on this patch?


Same as patch #1 here.

>
> On 05.07.17 19:29, Andrii Anisov wrote:
>> From: Andrii Anisov <andrii_anisov@epam.com>
>>
>> Introduce an earlyprintk configuration for R-Car Gen3 SoC based
>> development
>> boards, like:
>>   - Salvator-X [http://elinux.org/R-Car/Boards/Salvator-X]
>>   - M3ULCB [http://elinux.org/R-Car/Boards/M3SK]
>>   - H3ULCB [http://elinux.org/R-Car/Boards/H3SK]
>>
>> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
>> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
>> ---
>>   docs/misc/arm/early-printk.txt | 1 +
>>   xen/arch/arm/Rules.mk          | 1 +
>>   2 files changed, 2 insertions(+)
>>
>> diff --git a/docs/misc/arm/early-printk.txt
>> b/docs/misc/arm/early-printk.txt
>> index 41b528b..a7a3d94 100644
>> --- a/docs/misc/arm/early-printk.txt
>> +++ b/docs/misc/arm/early-printk.txt
>> @@ -39,6 +39,7 @@ the name of the machine:
>>     - fastmodel: printk on ARM Fastmodel software emulators
>>     - juno: printk with pl011 on Juno platform
>>     - lager: printk with SCIF0 on Renesas R-Car H2 processors
>> +  - rcar3: printk with SCIF2 on Renesas R-Car H3 processors

Please follow alphabetical order

>>     - midway: printk with the pl011 on Calxeda Midway processors
>>     - omap5432: printk with UART3 on TI OMAP5432 processors
>>     - seattle: printk with pl011 for AMD Seattle processor
>> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
>> index 569a0ba..9c1cb74 100644
>> --- a/xen/arch/arm/Rules.mk
>> +++ b/xen/arch/arm/Rules.mk
>> @@ -34,6 +34,7 @@ EARLY_PRINTK_fastmodel      := pl011,0x1c090000,115200
>>   EARLY_PRINTK_exynos5250     := exynos4210,0x12c20000
>>   EARLY_PRINTK_juno           := pl011,0x7ff80000
>>   EARLY_PRINTK_lager          := scif,0xe6e60000
>> +EARLY_PRINTK_rcar3          := scif,0xe6e88000

Ditto

>>   EARLY_PRINTK_midway         := pl011,0xfff36000
>>   EARLY_PRINTK_omap5432       := 8250,0x48020000,2
>>   EARLY_PRINTK_seattle        := pl011,0xe1010000
>

Cheers,

-- 
Julien Grall

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

Re: [PATCH 1/2] xen:arm64: Add SCIF UART support for earlyprintk

[Andrii Anisov]

Hello Julien,

On 26.07.17 18:33, Julien Grall wrote:
>
>
> On 26/07/17 16:25, Andrii Anisov wrote:
>> + Stefano as a maintainer.
>>
>> Dear all,
>>
>> Any objections on this patch?
>
> I would have appreciated to be CC as well...
Somewhy I though you are in the thread of this patch as well.
Sorry for my miss.

> >
>>
>> On 05.07.17 19:29, Andrii Anisov wrote:
>>> From: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>>>
>>> Add support for a SCIF compatible UART found in Renesas R-Car Gen3 
>>> SoCs.
>>>
>>> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>>> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
>>> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
>>> ---
>>>   xen/arch/arm/arm64/debug-scif.inc | 51
>>> +++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 51 insertions(+)
>>>   create mode 100644 xen/arch/arm/arm64/debug-scif.inc
>>>
>>> diff --git a/xen/arch/arm/arm64/debug-scif.inc
>>> b/xen/arch/arm/arm64/debug-scif.inc
>>> new file mode 100644
>>> index 0000000..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 <oleksandr.tyshchenko@globallogic.com>
>>> + * Iurii Konovalenko <iurii.konovalenko@globallogic.com>
>>> + * Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com>
>>> + * 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 <asm/scif-uart.h>
>>> +
>>> +/* SCIF UART wait UART to be ready to transmit
>
> Coding style.
>
>>> + * rb: register which contains the UART base address
>
> Wrong name
>
>>> + * rc: scratch register
>
> Ditto
>
>>> + */
>>> +.macro early_uart_ready xb c
>>> +1:
>>> +        ldrh   w\c, [\xb, #SCIF_SCFSR]   /* <- SCFSR (status
>>> register) */
>>> +        tst    w\c, #SCFSR_TDFE          /* Check TDFE bit */
>>> +        beq    1b                        /* Wait for the UART to be
>>> ready */
>>> +.endm
>>> +
>>> +/* SCIF UART transmit character
>
> Ditto
>
>>> + * rb: register which contains the UART base address
>
> Ditto
>
>>> + * rt: register which contains the character to transmit
>
> Ditto
>
>>> + */
>>> +.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:
>>> + */
>>
>
> Cheers,
>
Yep, will cleanup.

-- 

*Andrii Anisov*



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