| Message ID | 20161108142054.23017-1-iurii.mykhalskyi@globallogic.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <iurii.konovalenko@globallogic.com> > > Add support for the "Salvator-X" development board based on R-Car H3 SoC > which has SCIF compatible UART. > > Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com> > Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com> > --- > 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,0x1c090000,115200 > EARLY_PRINTK_exynos5250 := exynos4210,0x12c20000 > EARLY_PRINTK_juno := pl011,0x7ff80000 > EARLY_PRINTK_lager := scif,0xe6e60000 > +EARLY_PRINTK_salvator := scif,0xe6e88000 > EARLY_PRINTK_midway := pl011,0xfff36000 > EARLY_PRINTK_omap5432 := 8250,0x48020000,2 > EARLY_PRINTK_seattle := pl011,0xe1010000 > 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: > + */ >
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 <iurii.konovalenko@globallogic.com> >> >> Add support for the "Salvator-X" development board based on R-Car H3 >> SoC >> which has SCIF compatible UART. >> >> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com> >> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com> >> --- >> 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,0x1c090000,115200 >> EARLY_PRINTK_exynos5250 := exynos4210,0x12c20000 >> EARLY_PRINTK_juno := pl011,0x7ff80000 >> EARLY_PRINTK_lager := scif,0xe6e60000 >> +EARLY_PRINTK_salvator := scif,0xe6e88000 >> EARLY_PRINTK_midway := pl011,0xfff36000 >> EARLY_PRINTK_omap5432 := 8250,0x48020000,2 >> EARLY_PRINTK_seattle := pl011,0xe1010000 >> 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: >> + */ >> >
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 <dirk.behme@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 >> >> >> On 08/11/2016 14:20, Iurii Mykhalskyi wrote: >> >>> From: Iurii Konovalenko <iurii.konovalenko@globallogic.com> >>> >>> Add support for the "Salvator-X" development board based on R-Car H3 >>> SoC >>> which has SCIF compatible UART. >>> >>> Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com> >>> Signed-off-by: Iurii Mykhalskyi <iurii.mykhalskyi@globallogic.com> >>> --- >>> 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,0x1c090000,115200 >>> EARLY_PRINTK_exynos5250 := exynos4210,0x12c20000 >>> EARLY_PRINTK_juno := pl011,0x7ff80000 >>> EARLY_PRINTK_lager := scif,0xe6e60000 >>> +EARLY_PRINTK_salvator := scif,0xe6e88000 >>> EARLY_PRINTK_midway := pl011,0xfff36000 >>> EARLY_PRINTK_omap5432 := 8250,0x48020000,2 >>> EARLY_PRINTK_seattle := pl011,0xe1010000 >>> 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: >>> + */ >>> >>> >> >
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.
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 <dirk.behme@gmail.com > <mailto:dirk.behme@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 > <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 > <https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg00130.html> > >
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,
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
Hello Dirk, On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme <dirk.behme@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. > 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
On 10.11.2016 10:25, Iurii Mykhalskyi wrote: > Hello Dirk, > > On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme <dirk.behme@de.bosch.com > <mailto:dirk.behme@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
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 <dirk.behme@de.bosch.com> wrote: > On 10.11.2016 10:25, Iurii Mykhalskyi wrote: > >> Hello Dirk, >> >> On Thu, Nov 10, 2016 at 8:54 AM, Dirk Behme <dirk.behme@de.bosch.com >> <mailto:dirk.behme@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 > > >
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
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.
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 <andrii.anisov@gmail.com> 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. > >
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 <andrii.anisov@gmail.com>
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 <andrii.anisov@gmail.com>
> 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, 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.
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 <iurii.mykhalskyi@globallogic.com> 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 <andrii.anisov@gmail.com> > 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 <andrii.anisov@gmail.com> >> 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
Dear Andrii and all, On Wed, Nov 23, 2016 at 4:15 PM, Andrii Anisov <andrii.anisov@gmail.com> 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
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 > <https://github.com/qbeeukraine/meta-platform-xen> > [2] https://lists.xen.org/archives/html/xen-devel/2015-12/msg00137.html > <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 > <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 > <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 > <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
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.
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 <andrii.anisov@gmail.com> 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. >
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,0x1c090000,115200 EARLY_PRINTK_exynos5250 := exynos4210,0x12c20000 EARLY_PRINTK_juno := pl011,0x7ff80000 EARLY_PRINTK_lager := scif,0xe6e60000 +EARLY_PRINTK_salvator := scif,0xe6e88000 EARLY_PRINTK_midway := pl011,0xfff36000 EARLY_PRINTK_omap5432 := 8250,0x48020000,2 EARLY_PRINTK_seattle := pl011,0xe1010000 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: + */