| Message ID | 1467615113-31790-1-git-send-email-dirk.behme@de.bosch.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
(CC Wei for the release part) Hi Dirk, On 04/07/16 07:51, Dirk Behme wrote: > Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Thank you for adding support of a new board in Xen. During the last hackathon, we discussed about improving pre-release testing on ARM hardware [1] and helping users to boot Xen on supported board. This patch is the first board officially supported since then, so I would like to start applying what was discussed (I will put on a wiki page later). Below the list of things that I would like to see when a new board is added: - Create a wiki page to explain the requirements to boot Xen on the board (e.g new firmware if not supported out of box, linux version,...); - Add a link to the new page in [2]; - Add the contact details in [3] of someone who would could test pre-release and help out users to boot Xen on the board. I do not expect the latter point to be time consuming. It is basically checking if Xen boots before each release and possibly update the requirements of the board. For the part helping users, it will mostly be question related to booting Xen on the hardware. Others may not be able to answer because they do not have the board on their desk. In the future, I would like to see Xen tested before each release on all the boards officially supported. If it was not tested, we will consider the board as not supported. [...] > diff --git a/xen/arch/arm/platforms/rcar3.c b/xen/arch/arm/platforms/rcar3.c > new file mode 100644 > index 0000000..5a53f15 > --- /dev/null > +++ b/xen/arch/arm/platforms/rcar3.c > @@ -0,0 +1,41 @@ > +/* > + * xen/arch/arm/platforms/rcar3.c > + * > + * Renesas R-Car Gen3 specific settings > + * > + * Dirk Behme <dirk.behme@de.bosch.com> > + * > + * based on Renesas R-Car Gen2 specific settings > + * Iurii Konovalenko <iurii.konovalenko@globallogic.com> > + * > + * 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/platform.h> > + > +static const char const *rcar3_dt_compat[] __initdata = > +{ > + "renesas,salvator-x", > + NULL > +}; > + > +PLATFORM_START(rcar3, "Renesas R-Car Gen3") > + .compatible = rcar3_dt_compat, Your platform does not seem to require specific bring-up code, so this file can be dropped. > +PLATFORM_END > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * indent-tabs-mode: nil > + * End: > + */ Regards, [1] http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03683.html [2] http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#Hardware [3] http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
Also CC Lars. On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: > (CC Wei for the release part) > > Hi Dirk, > > On 04/07/16 07:51, Dirk Behme wrote: > >Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> > > Thank you for adding support of a new board in Xen. > > During the last hackathon, we discussed about improving pre-release testing > on ARM hardware [1] and helping users to boot Xen on supported board. > > This patch is the first board officially supported since then, so I would > like to start applying what was discussed (I will put on a wiki page later). > Below the list of things that I would like to see when a new board is added: > > - Create a wiki page to explain the requirements to boot Xen on the board > (e.g new firmware if not supported out of box, linux version,...); > - Add a link to the new page in [2]; > - Add the contact details in [3] of someone who would could test > pre-release and help out users to boot Xen on the board. > > I do not expect the latter point to be time consuming. It is basically > checking if Xen boots before each release and possibly update the > requirements of the board. For the part helping users, it will mostly be > question related to booting Xen on the hardware. Others may not be able to > answer because they do not have the board on their desk. > FWIW having some wiki pages, and most importantly contact details, would be a good starting point. Can we also have a section in MAINTAINERS for different boards (or a dedicated file?) so that we can easily gather all contact and send emails in a batch when the release is near? Wei.
> On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: > > Also CC Lars. > > On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: >> (CC Wei for the release part) >> >> Hi Dirk, >> >> On 04/07/16 07:51, Dirk Behme wrote: >>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> >> >> Thank you for adding support of a new board in Xen. >> >> During the last hackathon, we discussed about improving pre-release testing >> on ARM hardware [1] and helping users to boot Xen on supported board. >> >> This patch is the first board officially supported since then, so I would >> like to start applying what was discussed (I will put on a wiki page later). >> Below the list of things that I would like to see when a new board is added: >> >> - Create a wiki page to explain the requirements to boot Xen on the board >> (e.g new firmware if not supported out of box, linux version,...); >> - Add a link to the new page in [2]; >> - Add the contact details in [3] of someone who would could test >> pre-release and help out users to boot Xen on the board. >> >> I do not expect the latter point to be time consuming. It is basically >> checking if Xen boots before each release and possibly update the >> requirements of the board. For the part helping users, it will mostly be >> question related to booting Xen on the hardware. Others may not be able to >> answer because they do not have the board on their desk. >> > > FWIW having some wiki pages, and most importantly contact details, would > be a good starting point. I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results > Can we also have a section in MAINTAINERS for different boards (or a > dedicated file?) so that we can easily gather all contact and send > emails in a batch when the release is near? I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) Lars
On 07/07/16 13:43, Lars Kurth wrote: > >> On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: >> >> Also CC Lars. >> >> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: >>> (CC Wei for the release part) >>> >>> Hi Dirk, >>> >>> On 04/07/16 07:51, Dirk Behme wrote: >>>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> >>> >>> Thank you for adding support of a new board in Xen. >>> >>> During the last hackathon, we discussed about improving pre-release testing >>> on ARM hardware [1] and helping users to boot Xen on supported board. >>> >>> This patch is the first board officially supported since then, so I would >>> like to start applying what was discussed (I will put on a wiki page later). >>> Below the list of things that I would like to see when a new board is added: >>> >>> - Create a wiki page to explain the requirements to boot Xen on the board >>> (e.g new firmware if not supported out of box, linux version,...); >>> - Add a link to the new page in [2]; >>> - Add the contact details in [3] of someone who would could test >>> pre-release and help out users to boot Xen on the board. >>> >>> I do not expect the latter point to be time consuming. It is basically >>> checking if Xen boots before each release and possibly update the >>> requirements of the board. For the part helping users, it will mostly be >>> question related to booting Xen on the hardware. Others may not be able to >>> answer because they do not have the board on their desk. >>> >> >> FWIW having some wiki pages, and most importantly contact details, would >> be a good starting point. > > I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See > http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test > http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results > >> Can we also have a section in MAINTAINERS for different boards (or a >> dedicated file?) so that we can easily gather all contact and send >> emails in a batch when the release is near? > > I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) I think a file in the repository would be more formal than a wiki page. However, the MAINTAINERS file may not be the right place because some board will not have any specific code/file in Xen (e.g the RCAR-3 only add earlyprintk). But we would still want to keep track of them for testing purpose and advertising the board supported. I was thinking to add a file board under docs/misc/arm/boards.txt with the list of board and a contact associated I would add some words about the "responsibility" of the contact such as: - Testing - Answering questions related to the board I would also keep the wiki page [1] (+ a link in the file) to log the testing result per release. Finally, we may want to track whether the board is "supported", "obsolete", "untested"... I will try to write a concrete proposal. Cheers, [1] http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
> On 7 Jul 2016, at 14:14, Julien Grall <julien.grall@arm.com> wrote: > > > > On 07/07/16 13:43, Lars Kurth wrote: >> >>> On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: >>> >>> Also CC Lars. >>> >>> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: >>>> (CC Wei for the release part) >>>> >>>> Hi Dirk, >>>> >>>> On 04/07/16 07:51, Dirk Behme wrote: >>>>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> >>>> >>>> Thank you for adding support of a new board in Xen. >>>> >>>> During the last hackathon, we discussed about improving pre-release testing >>>> on ARM hardware [1] and helping users to boot Xen on supported board. >>>> >>>> This patch is the first board officially supported since then, so I would >>>> like to start applying what was discussed (I will put on a wiki page later). >>>> Below the list of things that I would like to see when a new board is added: >>>> >>>> - Create a wiki page to explain the requirements to boot Xen on the board >>>> (e.g new firmware if not supported out of box, linux version,...); >>>> - Add a link to the new page in [2]; >>>> - Add the contact details in [3] of someone who would could test >>>> pre-release and help out users to boot Xen on the board. >>>> >>>> I do not expect the latter point to be time consuming. It is basically >>>> checking if Xen boots before each release and possibly update the >>>> requirements of the board. For the part helping users, it will mostly be >>>> question related to booting Xen on the hardware. Others may not be able to >>>> answer because they do not have the board on their desk. >>>> >>> >>> FWIW having some wiki pages, and most importantly contact details, would >>> be a good starting point. >> >> I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See >> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test >> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results >> >>> Can we also have a section in MAINTAINERS for different boards (or a >>> dedicated file?) so that we can easily gather all contact and send >>> emails in a batch when the release is near? >> >> I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) > > I think a file in the repository would be more formal than a wiki page. > > However, the MAINTAINERS file may not be the right place because some board will not have any specific code/file in Xen (e.g the RCAR-3 only add earlyprintk). But we would still want to keep track of them for testing purpose and advertising the board supported. > > I was thinking to add a file board under docs/misc/arm/boards.txt with the list of board and a contact associated I would add some words about the "responsibility" of the contact such as: > - Testing > - Answering questions related to the board > > I would also keep the wiki page [1] (+ a link in the file) to log the testing result per release. > > Finally, we may want to track whether the board is "supported", "obsolete", "untested"... > > I will try to write a concrete proposal. Sounds sensible. Please CC me. You may also want to CC Andy Cooper as he has been doing something similar for some features Lars
On 07/07/16 14:17, Lars Kurth wrote: >> On 7 Jul 2016, at 14:14, Julien Grall <julien.grall@arm.com> wrote: >> >> >> >> On 07/07/16 13:43, Lars Kurth wrote: >>>> On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: >>>> >>>> Also CC Lars. >>>> >>>> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: >>>>> (CC Wei for the release part) >>>>> >>>>> Hi Dirk, >>>>> >>>>> On 04/07/16 07:51, Dirk Behme wrote: >>>>>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> >>>>> Thank you for adding support of a new board in Xen. >>>>> >>>>> During the last hackathon, we discussed about improving pre-release testing >>>>> on ARM hardware [1] and helping users to boot Xen on supported board. >>>>> >>>>> This patch is the first board officially supported since then, so I would >>>>> like to start applying what was discussed (I will put on a wiki page later). >>>>> Below the list of things that I would like to see when a new board is added: >>>>> >>>>> - Create a wiki page to explain the requirements to boot Xen on the board >>>>> (e.g new firmware if not supported out of box, linux version,...); >>>>> - Add a link to the new page in [2]; >>>>> - Add the contact details in [3] of someone who would could test >>>>> pre-release and help out users to boot Xen on the board. >>>>> >>>>> I do not expect the latter point to be time consuming. It is basically >>>>> checking if Xen boots before each release and possibly update the >>>>> requirements of the board. For the part helping users, it will mostly be >>>>> question related to booting Xen on the hardware. Others may not be able to >>>>> answer because they do not have the board on their desk. >>>>> >>>> FWIW having some wiki pages, and most importantly contact details, would >>>> be a good starting point. >>> I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See >>> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test >>> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results >>> >>>> Can we also have a section in MAINTAINERS for different boards (or a >>>> dedicated file?) so that we can easily gather all contact and send >>>> emails in a batch when the release is near? >>> I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) >> I think a file in the repository would be more formal than a wiki page. >> >> However, the MAINTAINERS file may not be the right place because some board will not have any specific code/file in Xen (e.g the RCAR-3 only add earlyprintk). But we would still want to keep track of them for testing purpose and advertising the board supported. >> >> I was thinking to add a file board under docs/misc/arm/boards.txt with the list of board and a contact associated I would add some words about the "responsibility" of the contact such as: >> - Testing >> - Answering questions related to the board >> >> I would also keep the wiki page [1] (+ a link in the file) to log the testing result per release. >> >> Finally, we may want to track whether the board is "supported", "obsolete", "untested"... >> >> I will try to write a concrete proposal. > Sounds sensible. Please CC me. You may also want to CC Andy Cooper as he has been doing something similar for some features +10 for something in the docs/ tree. It is far easier to keep up to date, and easy to mandate "patches for new boards are not accepted without an update to that document". ~Andrew
On Thu, 7 Jul 2016, Andrew Cooper wrote: > On 07/07/16 14:17, Lars Kurth wrote: > >> On 7 Jul 2016, at 14:14, Julien Grall <julien.grall@arm.com> wrote: > >> > >> > >> > >> On 07/07/16 13:43, Lars Kurth wrote: > >>>> On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: > >>>> > >>>> Also CC Lars. > >>>> > >>>> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: > >>>>> (CC Wei for the release part) > >>>>> > >>>>> Hi Dirk, > >>>>> > >>>>> On 04/07/16 07:51, Dirk Behme wrote: > >>>>>> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> > >>>>> Thank you for adding support of a new board in Xen. > >>>>> > >>>>> During the last hackathon, we discussed about improving pre-release testing > >>>>> on ARM hardware [1] and helping users to boot Xen on supported board. > >>>>> > >>>>> This patch is the first board officially supported since then, so I would > >>>>> like to start applying what was discussed (I will put on a wiki page later). > >>>>> Below the list of things that I would like to see when a new board is added: > >>>>> > >>>>> - Create a wiki page to explain the requirements to boot Xen on the board > >>>>> (e.g new firmware if not supported out of box, linux version,...); > >>>>> - Add a link to the new page in [2]; > >>>>> - Add the contact details in [3] of someone who would could test > >>>>> pre-release and help out users to boot Xen on the board. > >>>>> > >>>>> I do not expect the latter point to be time consuming. It is basically > >>>>> checking if Xen boots before each release and possibly update the > >>>>> requirements of the board. For the part helping users, it will mostly be > >>>>> question related to booting Xen on the hardware. Others may not be able to > >>>>> answer because they do not have the board on their desk. > >>>>> > >>>> FWIW having some wiki pages, and most importantly contact details, would > >>>> be a good starting point. > >>> I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See > >>> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test > >>> http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results > >>> > >>>> Can we also have a section in MAINTAINERS for different boards (or a > >>>> dedicated file?) so that we can easily gather all contact and send > >>>> emails in a batch when the release is near? > >>> I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) > >> I think a file in the repository would be more formal than a wiki page. > >> > >> However, the MAINTAINERS file may not be the right place because some board will not have any specific code/file in Xen (e.g the RCAR-3 only add earlyprintk). But we would still want to keep track of them for testing purpose and advertising the board supported. > >> > >> I was thinking to add a file board under docs/misc/arm/boards.txt with the list of board and a contact associated I would add some words about the "responsibility" of the contact such as: > >> - Testing > >> - Answering questions related to the board > >> > >> I would also keep the wiki page [1] (+ a link in the file) to log the testing result per release. > >> > >> Finally, we may want to track whether the board is "supported", "obsolete", "untested"... > >> > >> I will try to write a concrete proposal. > > Sounds sensible. Please CC me. You may also want to CC Andy Cooper as he has been doing something similar for some features > > +10 for something in the docs/ tree. > > It is far easier to keep up to date, and easy to mandate "patches for > new boards are not accepted without an update to that document". I agree with Andrew. It is difficult to request a change in the wiki in order to commit a patch. Better to do everything with git.
On Thu, Jul 07, 2016 at 02:14:53PM +0100, Julien Grall wrote: > > > On 07/07/16 13:43, Lars Kurth wrote: > > > >>On 7 Jul 2016, at 12:28, Wei Liu <wei.liu2@citrix.com> wrote: > >> > >>Also CC Lars. > >> > >>On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote: > >>>(CC Wei for the release part) > >>> > >>>Hi Dirk, > >>> > >>>On 04/07/16 07:51, Dirk Behme wrote: > >>>>Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> > >>> > >>>Thank you for adding support of a new board in Xen. > >>> > >>>During the last hackathon, we discussed about improving pre-release testing > >>>on ARM hardware [1] and helping users to boot Xen on supported board. > >>> > >>>This patch is the first board officially supported since then, so I would > >>>like to start applying what was discussed (I will put on a wiki page later). > >>>Below the list of things that I would like to see when a new board is added: > >>> > >>> - Create a wiki page to explain the requirements to boot Xen on the board > >>>(e.g new firmware if not supported out of box, linux version,...); > >>> - Add a link to the new page in [2]; > >>> - Add the contact details in [3] of someone who would could test > >>>pre-release and help out users to boot Xen on the board. > >>> > >>>I do not expect the latter point to be time consuming. It is basically > >>>checking if Xen boots before each release and possibly update the > >>>requirements of the board. For the part helping users, it will mostly be > >>>question related to booting Xen on the hardware. Others may not be able to > >>>answer because they do not have the board on their desk. > >>> > >> > >>FWIW having some wiki pages, and most importantly contact details, would > >>be a good starting point. > > > >I did actually create these pages during the Hackathon and sent it out to the list, but they were not populated by anyone. See > >http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test > >http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results > > > >>Can we also have a section in MAINTAINERS for different boards (or a > >>dedicated file?) so that we can easily gather all contact and send > >>emails in a batch when the release is near? > > > >I am not in principle against this, but a concrete proposal would need to be made. In fact that may be better than using the wiki (given the lack of traction around it) > > I think a file in the repository would be more formal than a wiki page. > > However, the MAINTAINERS file may not be the right place because some board > will not have any specific code/file in Xen (e.g the RCAR-3 only add > earlyprintk). But we would still want to keep track of them for testing > purpose and advertising the board supported. > > I was thinking to add a file board under docs/misc/arm/boards.txt with the > list of board and a contact associated I would add some words about the > "responsibility" of the contact such as: > - Testing > - Answering questions related to the board > > I would also keep the wiki page [1] (+ a link in the file) to log the > testing result per release. > > Finally, we may want to track whether the board is "supported", "obsolete", > "untested"... > > I will try to write a concrete proposal. > > Cheers, > > [1] http://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results > Having a file under docs/misc/arm is a very good idea. Wei. > -- > Julien Grall
diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt index 41b528b..20acbc7 100644 --- a/docs/misc/arm/early-printk.txt +++ b/docs/misc/arm/early-printk.txt @@ -41,6 +41,7 @@ the name of the machine: - lager: printk with SCIF0 on Renesas R-Car H2 processors - midway: printk with the pl011 on Calxeda Midway processors - omap5432: printk with UART3 on TI OMAP5432 processors + - salvator-x: printk with SCIF2 on Renesas R-Car H3 processors - seattle: printk with pl011 for AMD Seattle processor - sun6i: printk with 8250 on Allwinner A31 processors - sun7i: printk with 8250 on Allwinner A20 processors diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 93304be..3003e7b 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -36,6 +36,7 @@ EARLY_PRINTK_juno := pl011,0x7ff80000 EARLY_PRINTK_lager := scif,0xe6e60000 EARLY_PRINTK_midway := pl011,0xfff36000 EARLY_PRINTK_omap5432 := 8250,0x48020000,2 +EARLY_PRINTK_salvator-x := scif,0xe6e88000 EARLY_PRINTK_seattle := pl011,0xe1010000 EARLY_PRINTK_sun6i := 8250,0x01c28000,2 EARLY_PRINTK_sun7i := 8250,0x01c28000,2 diff --git a/xen/arch/arm/arm64/debug-scif.inc b/xen/arch/arm/arm64/debug-scif.inc new file mode 100644 index 0000000..ff91c32 --- /dev/null +++ b/xen/arch/arm/arm64/debug-scif.inc @@ -0,0 +1,54 @@ +/* + * xen/arch/arm/arm64/debug-scif.inc + * + * SCIF specific debug code + * + * Based on xen/arch/arm/arm32/debug-scif.inc by + * Oleksandr Tyshchenko <oleksandr.tyshchenko@globallogic.com> + * Copyright (C) 2014, Globallogic. + * + * Port to AARCH64 by + * Dirk Behme <dirk.behme@de.bosch.com> + * Copyright (C) 2016, Robert Bosch Car Multimedia + * + * 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: + */ diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile index 3689eec..01c8ebc 100644 --- a/xen/arch/arm/platforms/Makefile +++ b/xen/arch/arm/platforms/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_ARM_32) += midway.o obj-$(CONFIG_ARM_32) += omap5.o obj-$(CONFIG_ARM_32) += sunxi.o obj-$(CONFIG_ARM_32) += rcar2.o +obj-$(CONFIG_ARM_64) += rcar3.o obj-$(CONFIG_ARM_64) += seattle.o obj-$(CONFIG_ARM_64) += xgene-storm.o obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o diff --git a/xen/arch/arm/platforms/rcar3.c b/xen/arch/arm/platforms/rcar3.c new file mode 100644 index 0000000..5a53f15 --- /dev/null +++ b/xen/arch/arm/platforms/rcar3.c @@ -0,0 +1,41 @@ +/* + * xen/arch/arm/platforms/rcar3.c + * + * Renesas R-Car Gen3 specific settings + * + * Dirk Behme <dirk.behme@de.bosch.com> + * + * based on Renesas R-Car Gen2 specific settings + * Iurii Konovalenko <iurii.konovalenko@globallogic.com> + * + * 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/platform.h> + +static const char const *rcar3_dt_compat[] __initdata = +{ + "renesas,salvator-x", + NULL +}; + +PLATFORM_START(rcar3, "Renesas R-Car Gen3") + .compatible = rcar3_dt_compat, +PLATFORM_END + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 08973cf..703a311 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -45,7 +45,7 @@ config HAS_OMAP config HAS_SCIF bool default y - depends on ARM_32 + depends on ARM help This selects the SuperH SCI(F) UART. If you have a SuperH based board, say Y.
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> --- docs/misc/arm/early-printk.txt | 1 + xen/arch/arm/Rules.mk | 1 + xen/arch/arm/arm64/debug-scif.inc | 54 +++++++++++++++++++++++++++++++++++++++ xen/arch/arm/platforms/Makefile | 1 + xen/arch/arm/platforms/rcar3.c | 41 +++++++++++++++++++++++++++++ xen/drivers/char/Kconfig | 2 +- 6 files changed, 99 insertions(+), 1 deletion(-) create mode 100644 xen/arch/arm/arm64/debug-scif.inc create mode 100644 xen/arch/arm/platforms/rcar3.c