Re: [PATCH] MAINTAINERS: Update e-mail in Xen maintainership
Hi, Anastasiia On 19.01.22 22:49, Anastasiia Lukianenko wrote: > Changing e-mail because of leaving EPAM. > > Signed-off-by: Anastasiia Lukianenko Reviewed-by: Oleksandr Andrushchenko > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 64648c2921..9c2d6fe063 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1307,7 +1307,7 @@ F: arch/x86/ > F: cmd/x86/ > > XEN > -M: Anastasiia Lukianenko > +M: Anastasiia Lukianenko > M: Oleksandr Andrushchenko > S: Maintained > F: arch/arm/cpu/armv8/xen/
Re: [PATCH] MAINTAINERS: Update e-mail in Xen maintainership
On 10.12.21 12:19, Anastasiia Lukianenko wrote: > From: Anastasiia Lukianenko I think this needs to be fixed as you declare... > > Changing e-mail because of leaving EPAM. > > Signed-off-by: Anastasiia Lukianenko > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index e718ad2135..52c890edd8 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1280,7 +1280,7 @@ F: arch/x86/ > F: cmd/x86/ > > XEN > -M: Anastasiia Lukianenko > +M: Anastasiia Lukianenko ... this e-mail here > M: Oleksandr Andrushchenko > S: Maintained > F: arch/arm/cpu/armv8/xen/
Re: [PATCH v7 09/31] arm: xenguest_arm64: Add a empty devicetree file
Hi, Simon!
On 07.12.21 02:11, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
There is no such instruction exists as the device tree is built at run-time
by the hypervisor itself depending on virtual machine configuration:
I have already pointed that, e.g. U-boot is no different from any other
kernel/binary running in a virtual machine.
Thus I do not agree with the sentence above as it misleads.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v7:
> - Use 'empty' instead of 'fake'
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 000..d8734433763
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Empty devicetree file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a
> real
> + * devicetree.
ditto. I will not provide any instruction as this is internal to Xen
implementation
and may change depending on Xen version and virtual machine configuration.
If someone wants that she can dig into relevant Xen sources to see how the
device tree constructed. But this may be different between Xen versions and/or
virtual machine settings.
Please rephrase to reflect the dynamic nature of the device tree instead
Thank you,
Oleksandr
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig
> b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x4008
> CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x4000
> CONFIG_BOOTDELAY=10
[PATCH] MAINTAINERS: Remove Anastasiia Lukianenko from Xen entry
From: Oleksandr Andrushchenko Anastasiia Lukianenko's e-mail is now bouncing, so remove it from the maintainers list. Signed-off-by: Oleksandr Andrushchenko --- Cc: Anastasiia Lukianenko --- Anastasiia if instead of just removing your e-mail you still want to maintain Xen support in U-boot please please provide a new e-mail, so I can update. --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9045e509d737..4d80a6c282c5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1288,7 +1288,6 @@ F:arch/x86/ F: cmd/x86/ XEN -M: Anastasiia Lukianenko M: Oleksandr Andrushchenko S: Maintained F: arch/arm/cpu/armv8/xen/ -- 2.25.1
Re: [PATCH] MAINTAINERS: Remove Anastasiia Lukianenko from Xen entry
Great news! On 06.12.21 13:49, Nastya Vicodin wrote: > Hi all, > > I would like to maintain Xen part in U-boot, so I’ll update my email address > with a patch soon. > > Regards, > Anastasiia > > On Mon 6 Dec 2021 at 09:12, Oleksandr Andrushchenko > mailto:oleksandr_andrushche...@epam.com>> > wrote: > > Hi, all! > > Anastasiia has left EPAM, so now her e-mail bounces. > I can updated the e-mail if Anastasiia is still up to maintaining Xen > part in U-boot. > > Thank you, > Oleksandr > > On 06.12.21 09:09, Oleksandr Andrushchenko wrote: > > From: Oleksandr Andrushchenko <mailto:oleksandr_andrushche...@epam.com>> > > > > Anastasiia Lukianenko's e-mail is now bouncing, so remove it from > > the maintainers list. > > > > Signed-off-by: Oleksandr Andrushchenko > mailto:oleksandr_andrushche...@epam.com>> > > > > --- > > Cc: Anastasiia Lukianenko <mailto:vicooo...@gmail.com>> > > --- > > Anastasiia if instead of just removing your e-mail you still want to > > maintain Xen support in U-boot please please provide a new e-mail, so I > > can update. > > --- > > MAINTAINERS | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 9045e509d737..4d80a6c282c5 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -1288,7 +1288,6 @@ F: arch/x86/ > > F: cmd/x86/ > > > > XEN > > -M: Anastasiia Lukianenko <mailto:anastasiia_lukiane...@epam.com>> > > M: Oleksandr Andrushchenko <mailto:oleksandr_andrushche...@epam.com>> > > S: Maintained > > F: arch/arm/cpu/armv8/xen/ >
Re: [PATCH] MAINTAINERS: Remove Anastasiia Lukianenko from Xen entry
Hi, all! Anastasiia has left EPAM, so now her e-mail bounces. I can updated the e-mail if Anastasiia is still up to maintaining Xen part in U-boot. Thank you, Oleksandr On 06.12.21 09:09, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Anastasiia Lukianenko's e-mail is now bouncing, so remove it from > the maintainers list. > > Signed-off-by: Oleksandr Andrushchenko > > --- > Cc: Anastasiia Lukianenko > --- > Anastasiia if instead of just removing your e-mail you still want to > maintain Xen support in U-boot please please provide a new e-mail, so I > can update. > --- > MAINTAINERS | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 9045e509d737..4d80a6c282c5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1288,7 +1288,6 @@ F: arch/x86/ > F: cmd/x86/ > > XEN > -M: Anastasiia Lukianenko > M: Oleksandr Andrushchenko > S: Maintained > F: arch/arm/cpu/armv8/xen/
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 03.12.21 18:23, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 22:41, Oleksandr Andrushchenko > wrote: >> Hi, Simon! >> >> On 02.12.21 19:57, Simon Glass wrote: >>> Hi Oleksandr, >>> >>> On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko >>> wrote: >>>> Hi, Simon! >>>> >>>> Sorry for being late to the party >>>> >>>> On 02.12.21 17:59, Simon Glass wrote: >>>>> Add an empty file to prevent build errors when building with >>>>> CONFIG_OF_SEPARATE enabled. >>>>> >>>>> The build instructions in U-Boot do not provide enough detail to build a >>>>> useful devicetree, unfortunately. >>>> Xen guest doesn't use any built-in device trees as the guest's device tree >>>> is provided >>>> by the Xen hypervisor itself and is generated at the virtual machine >>>> creation time: it is >>>> populated with memory size, number of CPUs etc. based on [1]. >>>> So, even if we provide some device tree here it must not be used by U-boot >>>> at >>>> the end of the day. Thus, it might be a reasonable solution to provide an >>>> empty device >>>> tree as you do, but put a comment that it is not used. >>> OK we can go with an empty one if we have to, but where are the >>> instructions to create the DT that is used? >> You don't need to create the device tree yourself, but instead it is >> provided by Xen and generated at run-time while creating a >> virtual machine. So, it is up to Xen to provide one. >> There are cases [1] when you may want providing a so called >> partial device tree to better tune what a virtual machine gets. >> But again, it is used by Xen toolstack outside of the virtual machine >> and serves as a sort of overlay to the generated device tree. >> So, we can provide some device tree to be embedded in U-boot, >> but it will have no practical meaning and will make more harm than good >>> I'm not even sure how to run U-Boot with Xen? The in-tree instructions >>> don't help... >> This is just a virtual machine from Xen POV, so U-boot is nothing >> different here from Linux kernel or anything else. >> Thus no specific instructions are needed nor provided > I'd like to try it out. How?? Well, it can be tricky a bit. There are number of ARM64 platforms which have Xen running: Arm, Renesas, Xilinx, iMX8, Rpi4... You can probably start from QEMU, for example OP-TEE has a way to build Xen + QEMU, please see [1]. The build has Xen in it and a virtual machine [2]. You will need to tweak [3] and put U-boot instead of the Linux kernel. I never tried that build myself, but I know it is used for OP-TEE tests for Xen. Hope this helps, Oleksandr > > Regards, > Simon [1] https://github.com/OP-TEE/manifest/blob/master/qemu_v8.xml [2] https://github.com/OP-TEE/build/tree/master/qemu_v8/xen [3] https://github.com/OP-TEE/build/blob/master/qemu_v8/xen/guest.cfg#L1
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon! On 02.12.21 19:57, Simon Glass wrote: > Hi Oleksandr, > > On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko > wrote: >> Hi, Simon! >> >> Sorry for being late to the party >> >> On 02.12.21 17:59, Simon Glass wrote: >>> Add an empty file to prevent build errors when building with >>> CONFIG_OF_SEPARATE enabled. >>> >>> The build instructions in U-Boot do not provide enough detail to build a >>> useful devicetree, unfortunately. >> Xen guest doesn't use any built-in device trees as the guest's device tree >> is provided >> by the Xen hypervisor itself and is generated at the virtual machine >> creation time: it is >> populated with memory size, number of CPUs etc. based on [1]. >> So, even if we provide some device tree here it must not be used by U-boot at >> the end of the day. Thus, it might be a reasonable solution to provide an >> empty device >> tree as you do, but put a comment that it is not used. > OK we can go with an empty one if we have to, but where are the > instructions to create the DT that is used? You don't need to create the device tree yourself, but instead it is provided by Xen and generated at run-time while creating a virtual machine. So, it is up to Xen to provide one. There are cases [1] when you may want providing a so called partial device tree to better tune what a virtual machine gets. But again, it is used by Xen toolstack outside of the virtual machine and serves as a sort of overlay to the generated device tree. So, we can provide some device tree to be embedded in U-boot, but it will have no practical meaning and will make more harm than good > > I'm not even sure how to run U-Boot with Xen? The in-tree instructions > don't help... This is just a virtual machine from Xen POV, so U-boot is nothing different here from Linux kernel or anything else. Thus no specific instructions are needed nor provided Thank you, Oleksandr > > Regards, > Simon [1] https://xenbits.xen.org/docs/unstable/misc/arm/passthrough.txt
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon!
Sorry for being late to the party
On 02.12.21 17:59, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
Xen guest doesn't use any built-in device trees as the guest's device tree is
provided
by the Xen hypervisor itself and is generated at the virtual machine creation
time: it is
populated with memory size, number of CPUs etc. based on [1].
So, even if we provide some device tree here it must not be used by U-boot at
the end of the day. Thus, it might be a reasonable solution to provide an empty
device
tree as you do, but put a comment that it is not used.
Thank you,
Oleksandr
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 000..52d3b062248
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a
> real
> + * devicetree.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig
> b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x4008
> CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x4000
> CONFIG_BOOTDELAY=10
[1] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
Re: [PATCH v1] linux/compat.h: Remove debug() from spin_lock_irqsave()
Hi, Andy
On 11/19/20 10:21 PM, Andy Shevchenko wrote:
> Update Tom's address
>
> On Thu, Nov 19, 2020 at 9:26 PM Andy Shevchenko
> wrote:
>> It seems nobody tested the debug() option in spin_lock_irqsave().
>> Currently, when #define DEBUG, it spoils the compiler with
>>
>> In file included from drivers/usb/dwc3/gadget.c:18:
>> drivers/usb/dwc3/gadget.c: In function ‘dwc3_gadget_set_selfpowered’:
>> include/log.h:235:4: warning: ‘flags’ is used uninitialized in this function
>> [-Wuninitialized]
>>235 |printf(pr_fmt(fmt), ##args); \
>>|^~
>> drivers/usb/dwc3/gadget.c:1347:17: note: ‘flags’ was declared here
>> 1347 | unsigned long flags;
>>| ^
>>
>> and so on...
>> Drop useless debug() call to make compiler happy.
>>
>> Fixes: 0c06db598367 ("lib, linux: move linux specific defines to
>> linux/compat.h")
>> Cc: Heiko Schocher
>> Cc: Tom Rini
>> Signed-off-by: Andy Shevchenko
Reviewed-by: Oleksandr Andrushchenko
>> ---
>> include/linux/compat.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/compat.h b/include/linux/compat.h
>> index 38549baa251d..3d0acbd582ef 100644
>> --- a/include/linux/compat.h
>> +++ b/include/linux/compat.h
>> @@ -248,7 +248,7 @@ typedef int wait_queue_head_t;
>> #define spin_lock_init(lock) do {} while (0)
>> #define spin_lock(lock) do {} while (0)
>> #define spin_unlock(lock) do {} while (0)
>> -#define spin_lock_irqsave(lock, flags) do { debug("%lu\n", flags); } while
>> (0)
>> +#define spin_lock_irqsave(lock, flags) do {} while (0)
>> #define spin_unlock_irqrestore(lock, flags) do { flags = 0; } while (0)
>>
>> #define DEFINE_MUTEX(...)
>> --
>> 2.29.2
>>
>
Re: [RFC] serial: pl01x: add sbsa-uart favor
Hi, On 11/5/20 11:46 AM, AKASHI Takahiro wrote: > Hi Oleksandr, > > On Thu, Nov 05, 2020 at 09:18:39AM +, Oleksandr Andrushchenko wrote: >> Hello, >> >> On 11/4/20 7:24 AM, AKASHI Takahiro wrote: >>> sbsa-uart is a virtual UART device with a sub-set of PL011 functionality >>> which is described in SBSA (Server Base System Architecture)[1]. >>> >>> It mainly targets for server use, but sbsa-uart itself is useful in any >>> para-virtualized use cases, including Xen. >>> >>> At present, this patch is submitted as RFC because: >>> * for some reason, data cache must be turned off (in initr_dcache()) >> Can it be because of data cache maintenance is required? Please see [1] for >> >> more details, just a key note from there (Julien Grall): >> >> "Per the hypercall ABI (see include/public/arch-arm.h) all the buffers must >> reside in memory which is mapped as Normal Inner Write-Back Inner-Shareable. >> You are passing non-cacheable memory, so the behavior you see is expected." > Please note that, as far as this patch is concerned, no hypervisor call > is used. What is done here is that all the accesses to memory mapped > sbsa-uart registers are trapped and emulated by the hypervisor (in my case, > Xen's mmio handler). The only reason I mentioned [1] is that I think it could be related to what you see, e.g. you need to switch off D-cache completely which makes me think we violate the ABI somehow > >> Thank you, > BTW, what do you think of this patch? It is good when it works with D-cache ON ;) Thank you, Oleksandr > > -Takahiro Akashi > >> Oleksandr >> >>> * there is a prerequisite patch for Xen[2] >>> >>> The patch with xenguest_arm64_defconfig was tested on upstream Xen and >>> qemu-arm64. >>> (To work with xenguest_arm64_defconfig, minor and non-essential tweaks >>> are needed.) >>> >>> The output looks like: >>> U-Boot 2021.01-rc1-5-g3b8e3cde5345 (Nov 04 2020 - 13:54:44 +0900) >>> xenguest >>> >>> Xen virtual CPU >>> Model: XENVM-4.15 >>> DRAM: 128 MiB >>> PVBLOCK: Failed to read device/vbd directory: ENOENT >>> >>> In:sbsa-pl011 >>> Out: sbsa-pl011 >>> Err: sbsa-pl011 >>> xenguest# dm tree >>>Class Index Probed DriverName >>> --- >>>root 0 [ + ] root_driver root_driver >>>firmware 0 [ ] psci |-- psci >>>serial0 [ + ] serial_pl01x |-- sbsa-pl011 >>>pvblock 0 [ ] pvblock `-- pvblock >>> >>> [1] >>> https://urldefense.com/v3/__https://developer.arm.com/architectures/platform-design/server-systems__;!!GF_29dbcQIUBPA!k49FI4LUby7RffCuUHhIeq1ucvB2hhtch27HKXm3RBDLSY04ge4taCv7zqzDTat-6ZlDP1E68A$ >>> [developer[.]arm[.]com] >>> [2] >>> https://urldefense.com/v3/__https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg02122.html__;!!GF_29dbcQIUBPA!k49FI4LUby7RffCuUHhIeq1ucvB2hhtch27HKXm3RBDLSY04ge4taCv7zqzDTat-6ZlHuV_0Rg$ >>> [lists[.]xenproject[.]org] >>> >>> Signed-off-by: AKASHI Takahiro >>> --- >>>drivers/serial/Kconfig | 13 +++-- >>>drivers/serial/serial_pl01x.c | 16 +--- >>>include/dm/platform_data/serial_pl01x.h | 1 + >>>3 files changed, 25 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig >>> index b4805a2e4ea4..fb570174c577 100644 >>> --- a/drivers/serial/Kconfig >>> +++ b/drivers/serial/Kconfig >>> @@ -332,6 +332,15 @@ config DEBUG_UART_PL011 >>> work. The driver will be available until the real driver model >>> serial is running. >>> >>> +config DEBUG_UART_SBSA >>> + bool "sbsa-uart" >>> + depends on PL01X_SERIAL >>> + help >>> + Select this to enable a debug UART using the pl01x driver with the >>> + SBSA_UART type. You will need to provide parameters to make this >>> + work. The driver will be available until the real driver model >>> + serial is running. >>> + >>>config DEBUG_UART_PIC32 >>> bool "Microchip PIC32" >>> depends on PIC32_SERIAL >>> @@ -415,7 +424,7 @@ config DEBUG_UART_BASE >>> >>>config DEBUG_UART_CLOCK
Re: [RFC] serial: pl01x: add sbsa-uart favor
Hello,
On 11/4/20 7:24 AM, AKASHI Takahiro wrote:
> sbsa-uart is a virtual UART device with a sub-set of PL011 functionality
> which is described in SBSA (Server Base System Architecture)[1].
>
> It mainly targets for server use, but sbsa-uart itself is useful in any
> para-virtualized use cases, including Xen.
>
> At present, this patch is submitted as RFC because:
> * for some reason, data cache must be turned off (in initr_dcache())
Can it be because of data cache maintenance is required? Please see [1] for
more details, just a key note from there (Julien Grall):
"Per the hypercall ABI (see include/public/arch-arm.h) all the buffers must
reside in memory which is mapped as Normal Inner Write-Back Inner-Shareable.
You are passing non-cacheable memory, so the behavior you see is expected."
Thank you,
Oleksandr
> * there is a prerequisite patch for Xen[2]
>
> The patch with xenguest_arm64_defconfig was tested on upstream Xen and
> qemu-arm64.
> (To work with xenguest_arm64_defconfig, minor and non-essential tweaks
> are needed.)
>
> The output looks like:
> U-Boot 2021.01-rc1-5-g3b8e3cde5345 (Nov 04 2020 - 13:54:44 +0900) xenguest
>
> Xen virtual CPU
> Model: XENVM-4.15
> DRAM: 128 MiB
> PVBLOCK: Failed to read device/vbd directory: ENOENT
>
> In:sbsa-pl011
> Out: sbsa-pl011
> Err: sbsa-pl011
> xenguest# dm tree
> Class Index Probed DriverName
> ---
> root 0 [ + ] root_driver root_driver
> firmware 0 [ ] psci |-- psci
> serial0 [ + ] serial_pl01x |-- sbsa-pl011
> pvblock 0 [ ] pvblock `-- pvblock
>
> [1]
> https://urldefense.com/v3/__https://developer.arm.com/architectures/platform-design/server-systems__;!!GF_29dbcQIUBPA!k49FI4LUby7RffCuUHhIeq1ucvB2hhtch27HKXm3RBDLSY04ge4taCv7zqzDTat-6ZlDP1E68A$
> [developer[.]arm[.]com]
> [2]
> https://urldefense.com/v3/__https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg02122.html__;!!GF_29dbcQIUBPA!k49FI4LUby7RffCuUHhIeq1ucvB2hhtch27HKXm3RBDLSY04ge4taCv7zqzDTat-6ZlHuV_0Rg$
> [lists[.]xenproject[.]org]
>
> Signed-off-by: AKASHI Takahiro
> ---
> drivers/serial/Kconfig | 13 +++--
> drivers/serial/serial_pl01x.c | 16 +---
> include/dm/platform_data/serial_pl01x.h | 1 +
> 3 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index b4805a2e4ea4..fb570174c577 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -332,6 +332,15 @@ config DEBUG_UART_PL011
> work. The driver will be available until the real driver model
> serial is running.
>
> +config DEBUG_UART_SBSA
> + bool "sbsa-uart"
> + depends on PL01X_SERIAL
> + help
> + Select this to enable a debug UART using the pl01x driver with the
> + SBSA_UART type. You will need to provide parameters to make this
> + work. The driver will be available until the real driver model
> + serial is running.
> +
> config DEBUG_UART_PIC32
> bool "Microchip PIC32"
> depends on PIC32_SERIAL
> @@ -415,7 +424,7 @@ config DEBUG_UART_BASE
>
> config DEBUG_UART_CLOCK
> int "UART input clock"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_SBSA
> default 0 if DEBUG_UART_SANDBOX
> help
> The UART input clock determines the speed of the internal UART
> @@ -427,7 +436,7 @@ config DEBUG_UART_CLOCK
>
> config DEBUG_UART_SHIFT
> int "UART register shift"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_SBSA
> default 0 if DEBUG_UART
> help
> Some UARTs (notably ns16550) support different register layouts
> diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
> index 2772c25f1d2d..5ef4ae0c6a65 100644
> --- a/drivers/serial/serial_pl01x.c
> +++ b/drivers/serial/serial_pl01x.c
> @@ -84,6 +84,8 @@ static int pl01x_generic_serial_init(struct pl01x_regs
> *regs,
> /* disable everything */
> writel(0, >pl011_cr);
> break;
> + case TYPE_SBSA_UART:
> + break;
> default:
> return -EINVAL;
> }
> @@ -146,7 +148,8 @@ static int pl01x_generic_setbrg(struct pl01x_regs *regs,
> enum pl01x_type type,
> writel(UART_PL010_CR_UARTEN, >pl010_cr);
> break;
> }
> - case TYPE_PL011: {
> + case TYPE_PL011:
> + case TYPE_SBSA_UART: {
> unsigned int temp;
> unsigned int divider;
> unsigned int remainder;
> @@ -171,6 +174,9 @@ static int pl01x_generic_setbrg(struct pl01x_regs *regs,
> enum pl01x_type type,
> writel(fraction, >pl011_fbrd);
> }
>
> + if (type == TYPE_SBSA_UART)
> +
Re: [PATCH 1/2] hush: Remove default CONFIG_SYS_PROMPT_HUSH_PS2 setting from board files
Hi, On 10/26/20 10:31 AM, Patrick Delaunay wrote: > There is no reason to define default option for this macro which is > already done in common/cli_hush.c. > >87 #ifndef CONFIG_SYS_PROMPT_HUSH_PS2 >88 #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " >89 #endif > > Signed-off-by: Patrick Delaunay For the Xen bits: Acked-by: Oleksandr Andrushchenko Thank you, Oleksandr > --- > > see previous patches: > > https://urldefense.com/v3/__http://patchwork.ozlabs.org/project/uboot/patch/11b23b65581253f10905bcefc923aacb3c2ce85a.1529647987.git.michal.si...@xilinx.com/__;!!GF_29dbcQIUBPA!kuAr0IR41fGK-arwjDJjvrgCPSun2J2QhGuqL3jeWOp_bGAsPKrocOHClsfQvvlGete5ostLcw$ > [patchwork[.]ozlabs[.]org] > https://urldefense.com/v3/__https://lists.denx.de/pipermail/u-boot/2012-June/126510.html__;!!GF_29dbcQIUBPA!kuAr0IR41fGK-arwjDJjvrgCPSun2J2QhGuqL3jeWOp_bGAsPKrocOHClsfQvvlGetdcg8yzLQ$ > [lists[.]denx[.]de] > > > include/configs/apalis-imx8.h | 1 - > include/configs/colibri-imx8x.h | 1 - > include/configs/imx8mm_beacon.h | 1 - > include/configs/imx8mm_evk.h | 1 - > include/configs/imx8mn_evk.h | 1 - > include/configs/imx8mp_evk.h | 1 - > include/configs/imx8mq_evk.h | 1 - > include/configs/imx8mq_phanbell.h | 1 - > include/configs/s5p4418_nanopi2.h | 4 > include/configs/verdin-imx8mm.h | 1 - > include/configs/xenguest_arm64.h | 1 - > 11 files changed, 14 deletions(-) > > diff --git a/include/configs/apalis-imx8.h b/include/configs/apalis-imx8.h > index db4e9011c0..b474b2f522 100644 > --- a/include/configs/apalis-imx8.h > +++ b/include/configs/apalis-imx8.h > @@ -98,7 +98,6 @@ > #define PHYS_SDRAM_2_SIZE SZ_2G /* 2 GB */ > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE SZ_2K > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/colibri-imx8x.h b/include/configs/colibri-imx8x.h > index 29a37ed44f..fc2c191594 100644 > --- a/include/configs/colibri-imx8x.h > +++ b/include/configs/colibri-imx8x.h > @@ -132,7 +132,6 @@ > #define PHYS_SDRAM_2_SIZE 0x /* 0 GB */ > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE SZ_2K > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/imx8mm_beacon.h b/include/configs/imx8mm_beacon.h > index 3c9541187f..9a93dba1c5 100644 > --- a/include/configs/imx8mm_beacon.h > +++ b/include/configs/imx8mm_beacon.h > @@ -119,7 +119,6 @@ > #define CONFIG_MXC_UART_BASEUART2_BASE_ADDR > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE 2048 > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/imx8mm_evk.h b/include/configs/imx8mm_evk.h > index 83521ad401..92eb85553e 100644 > --- a/include/configs/imx8mm_evk.h > +++ b/include/configs/imx8mm_evk.h > @@ -120,7 +120,6 @@ > #define CONFIG_MXC_UART_BASEUART2_BASE_ADDR > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE 2048 > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/imx8mn_evk.h b/include/configs/imx8mn_evk.h > index a6333085fe..cda8fc2ef7 100644 > --- a/include/configs/imx8mn_evk.h > +++ b/include/configs/imx8mn_evk.h > @@ -124,7 +124,6 @@ > #define CONFIG_MXC_UART_BASEUART2_BASE_ADDR > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE 2048 > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/imx8mp_evk.h b/include/configs/imx8mp_evk.h > index 8253c6aa2f..92091dfd6b 100644 > --- a/include/configs/imx8mp_evk.h > +++ b/include/configs/imx8mp_evk.h > @@ -135,7 +135,6 @@ > #define CONFIG_MXC_UART_BASEUART2_BASE_ADDR > > /* Monitor Command Prompt */ > -#define CONFIG_SYS_PROMPT_HUSH_PS2 "> " > #define CONFIG_SYS_CBSIZE 2048 > #define CONFIG_SYS_MAXARGS 64 > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h > index 3f9a3bc100..96bfff749c 1
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
On 10/26/20 10:03 AM, takahiro.aka...@linaro.org wrote: > Oleksandr, > > It seems that we now stand on the same page. Great, hope all together we can make it happen > > On Mon, Oct 26, 2020 at 07:30:06AM +0000, Oleksandr Andrushchenko wrote: >> On 10/26/20 9:10 AM, takahiro.aka...@linaro.org wrote: >>> On Mon, Oct 26, 2020 at 06:54:29AM +, Oleksandr Andrushchenko wrote: >>>> On 10/26/20 8:50 AM, takahiro.aka...@linaro.org wrote: >>>>> On Mon, Oct 26, 2020 at 06:18:08AM +, Oleksandr Andrushchenko wrote: >>>>>> Hi, >>>>>> >>>>>> On 10/26/20 7:58 AM, takahiro.aka...@linaro.org wrote: >>>>>>> On Fri, Oct 23, 2020 at 08:50:56AM +, Anastasiia Lukianenko wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote: >>>>>>>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko >>>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote: >>>>>>>>>>> By using a hypervisor call, we can implement DEBUG_UART on xen. >>>>>>>>>>> This will allow us to see messages even earlier than >>>>>>>>>>> serial_init(). >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: AKASHI Takahiro >>>>>>>>>>> --- >>>>>>>>>>> drivers/serial/Kconfig | 14 +++--- >>>>>>>>>>> drivers/serial/serial_xen.c | 20 >>>>>>>>>>> 2 files changed, 31 insertions(+), 3 deletions(-) >>>>>>>>>>> >>>>>>>>>>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig >>>>>>>>>>> index e344677f91f6..536cf0641773 100644 >>>>>>>>>>> --- a/drivers/serial/Kconfig >>>>>>>>>>> +++ b/drivers/serial/Kconfig >>>>>>>>>>> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK >>>>>>>>>>> driver will be available until the real driver model >>>>>>>>>>> serial >>>>>>>>>>> is >>>>>>>>>>> running. >>>>>>>>>>> >>>>>>>>>>> +config DEBUG_UART_XEN >>>>>>>>>>> + bool "XEN Hypervisor Console" >>>>>>>>>>> + depends on XEN_SERIAL >>>>>>>>>>> + help >>>>>>>>>>> + Select this to enable a debug UART using the serial_xen >>>>>>>>>>> driver. You >>>>>>>>>>> + will not have to provide any parameters to make this work. >>>>>>>>>>> The driver >>>>>>>>>>> + will be available until the real driver-model serial >>>>>>>>>>> is >>>>>>>>>>> running. >>>>>>>>>>> + >>>>>>>>>>> endchoice >>>>>>>>>>> >>>>>>>>>>> config DEBUG_UART_BASE >>>>>>>>>>> hex "Base address of UART" >>>>>>>>>>> - depends on DEBUG_UART >>>>>>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>>>>>> help >>>>>>>>>>> This is the base address of your UART for >>>>>>>>>>> memory-mapped >>>>>>>>>>> UARTs. >>>>>>>>>>> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE >>>>>>>>>>> >>>>>>>>>>> config DEBUG_UART_CLOCK >>>>>>>>>>> int "UART input clock" >>>>>>>>>>> - depends on DEBUG_UART >>>>>>>>>>> + depends on DEBUG_UART &&
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
On 10/26/20 9:10 AM, takahiro.aka...@linaro.org wrote: > On Mon, Oct 26, 2020 at 06:54:29AM +0000, Oleksandr Andrushchenko wrote: >> On 10/26/20 8:50 AM, takahiro.aka...@linaro.org wrote: >>> On Mon, Oct 26, 2020 at 06:18:08AM +, Oleksandr Andrushchenko wrote: >>>> Hi, >>>> >>>> On 10/26/20 7:58 AM, takahiro.aka...@linaro.org wrote: >>>>> On Fri, Oct 23, 2020 at 08:50:56AM +, Anastasiia Lukianenko wrote: >>>>>> Hello, >>>>>> >>>>>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote: >>>>>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote: >>>>>>>>> By using a hypervisor call, we can implement DEBUG_UART on xen. >>>>>>>>> This will allow us to see messages even earlier than >>>>>>>>> serial_init(). >>>>>>>>> >>>>>>>>> Signed-off-by: AKASHI Takahiro >>>>>>>>> --- >>>>>>>>> drivers/serial/Kconfig | 14 +++--- >>>>>>>>> drivers/serial/serial_xen.c | 20 >>>>>>>>> 2 files changed, 31 insertions(+), 3 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig >>>>>>>>> index e344677f91f6..536cf0641773 100644 >>>>>>>>> --- a/drivers/serial/Kconfig >>>>>>>>> +++ b/drivers/serial/Kconfig >>>>>>>>> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK >>>>>>>>> driver will be available until the real driver model serial >>>>>>>>> is >>>>>>>>> running. >>>>>>>>> >>>>>>>>> +config DEBUG_UART_XEN >>>>>>>>> + bool "XEN Hypervisor Console" >>>>>>>>> + depends on XEN_SERIAL >>>>>>>>> + help >>>>>>>>> + Select this to enable a debug UART using the serial_xen >>>>>>>>> driver. You >>>>>>>>> + will not have to provide any parameters to make this work. >>>>>>>>> The driver >>>>>>>>> + will be available until the real driver-model serial >>>>>>>>> is >>>>>>>>> running. >>>>>>>>> + >>>>>>>>> endchoice >>>>>>>>> >>>>>>>>> config DEBUG_UART_BASE >>>>>>>>> hex "Base address of UART" >>>>>>>>> - depends on DEBUG_UART >>>>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>>>> help >>>>>>>>> This is the base address of your UART for memory-mapped >>>>>>>>> UARTs. >>>>>>>>> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE >>>>>>>>> >>>>>>>>> config DEBUG_UART_CLOCK >>>>>>>>> int "UART input clock" >>>>>>>>> - depends on DEBUG_UART >>>>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>>>> help >>>>>>>>> The UART input clock determines the speed of the internal >>>>>>>>> UART >>>>>>>>> @@ -427,7 +435,7 @@ config DEBUG_UART_CLOCK >>>>>>>>> >>>>>>>>> config DEBUG_UART_SHIFT >>>>>>>>> int "UART register shift" >>>>>>>>> - depends on DEBUG_UART >>>>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>>>> default 0 if DEBUG_UART >>>>>>>>> help >>>>>>>>> Some UARTs (notab
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
Hi, On 10/26/20 8:50 AM, takahiro.aka...@linaro.org wrote: > On Mon, Oct 26, 2020 at 06:18:08AM +0000, Oleksandr Andrushchenko wrote: >> Hi, >> >> On 10/26/20 7:58 AM, takahiro.aka...@linaro.org wrote: >>> On Fri, Oct 23, 2020 at 08:50:56AM +, Anastasiia Lukianenko wrote: >>>> Hello, >>>> >>>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote: >>>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote: >>>>>>> By using a hypervisor call, we can implement DEBUG_UART on xen. >>>>>>> This will allow us to see messages even earlier than >>>>>>> serial_init(). >>>>>>> >>>>>>> Signed-off-by: AKASHI Takahiro >>>>>>> --- >>>>>>>drivers/serial/Kconfig | 14 +++--- >>>>>>>drivers/serial/serial_xen.c | 20 >>>>>>>2 files changed, 31 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig >>>>>>> index e344677f91f6..536cf0641773 100644 >>>>>>> --- a/drivers/serial/Kconfig >>>>>>> +++ b/drivers/serial/Kconfig >>>>>>> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK >>>>>>> driver will be available until the real driver model serial >>>>>>> is >>>>>>> running. >>>>>>> >>>>>>> +config DEBUG_UART_XEN >>>>>>> + bool "XEN Hypervisor Console" >>>>>>> + depends on XEN_SERIAL >>>>>>> + help >>>>>>> + Select this to enable a debug UART using the serial_xen >>>>>>> driver. You >>>>>>> + will not have to provide any parameters to make this work. >>>>>>> The driver >>>>>>> + will be available until the real driver-model serial >>>>>>> is >>>>>>> running. >>>>>>> + >>>>>>>endchoice >>>>>>> >>>>>>>config DEBUG_UART_BASE >>>>>>> hex "Base address of UART" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>> help >>>>>>> This is the base address of your UART for memory-mapped >>>>>>> UARTs. >>>>>>> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE >>>>>>> >>>>>>>config DEBUG_UART_CLOCK >>>>>>> int "UART input clock" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>> help >>>>>>> The UART input clock determines the speed of the internal >>>>>>> UART >>>>>>> @@ -427,7 +435,7 @@ config DEBUG_UART_CLOCK >>>>>>> >>>>>>>config DEBUG_UART_SHIFT >>>>>>> int "UART register shift" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART >>>>>>> help >>>>>>> Some UARTs (notably ns16550) support different register >>>>>>> layouts >>>>>>> diff --git a/drivers/serial/serial_xen.c >>>>>>> b/drivers/serial/serial_xen.c >>>>>>> index ed191829f059..34c90ece40fc 100644 >>>>>>> --- a/drivers/serial/serial_xen.c >>>>>>> +++ b/drivers/serial/serial_xen.c >>>>>>> @@ -5,6 +5,7 @@ >>>>>>> */ >>>>>>>#include >>>>>>>#include >>>>>>> +#include >>>>>>>#include >>>>>>>#in
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
On 10/26/20 8:50 AM, takahiro.aka...@linaro.org wrote: > On Mon, Oct 26, 2020 at 06:18:08AM +0000, Oleksandr Andrushchenko wrote: >> Hi, >> >> On 10/26/20 7:58 AM, takahiro.aka...@linaro.org wrote: >>> On Fri, Oct 23, 2020 at 08:50:56AM +, Anastasiia Lukianenko wrote: >>>> Hello, >>>> >>>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote: >>>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote: >>>>>>> By using a hypervisor call, we can implement DEBUG_UART on xen. >>>>>>> This will allow us to see messages even earlier than >>>>>>> serial_init(). >>>>>>> >>>>>>> Signed-off-by: AKASHI Takahiro >>>>>>> --- >>>>>>>drivers/serial/Kconfig | 14 +++--- >>>>>>>drivers/serial/serial_xen.c | 20 >>>>>>>2 files changed, 31 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig >>>>>>> index e344677f91f6..536cf0641773 100644 >>>>>>> --- a/drivers/serial/Kconfig >>>>>>> +++ b/drivers/serial/Kconfig >>>>>>> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK >>>>>>> driver will be available until the real driver model serial >>>>>>> is >>>>>>> running. >>>>>>> >>>>>>> +config DEBUG_UART_XEN >>>>>>> + bool "XEN Hypervisor Console" >>>>>>> + depends on XEN_SERIAL >>>>>>> + help >>>>>>> + Select this to enable a debug UART using the serial_xen >>>>>>> driver. You >>>>>>> + will not have to provide any parameters to make this work. >>>>>>> The driver >>>>>>> + will be available until the real driver-model serial >>>>>>> is >>>>>>> running. >>>>>>> + >>>>>>>endchoice >>>>>>> >>>>>>>config DEBUG_UART_BASE >>>>>>> hex "Base address of UART" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>> help >>>>>>> This is the base address of your UART for memory-mapped >>>>>>> UARTs. >>>>>>> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE >>>>>>> >>>>>>>config DEBUG_UART_CLOCK >>>>>>> int "UART input clock" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART_SANDBOX >>>>>>> help >>>>>>> The UART input clock determines the speed of the internal >>>>>>> UART >>>>>>> @@ -427,7 +435,7 @@ config DEBUG_UART_CLOCK >>>>>>> >>>>>>>config DEBUG_UART_SHIFT >>>>>>> int "UART register shift" >>>>>>> - depends on DEBUG_UART >>>>>>> + depends on DEBUG_UART && !DEBUG_UART_XEN >>>>>>> default 0 if DEBUG_UART >>>>>>> help >>>>>>> Some UARTs (notably ns16550) support different register >>>>>>> layouts >>>>>>> diff --git a/drivers/serial/serial_xen.c >>>>>>> b/drivers/serial/serial_xen.c >>>>>>> index ed191829f059..34c90ece40fc 100644 >>>>>>> --- a/drivers/serial/serial_xen.c >>>>>>> +++ b/drivers/serial/serial_xen.c >>>>>>> @@ -5,6 +5,7 @@ >>>>>>> */ >>>>>>>#include >>>>>>>#include >>>>>>> +#include >>>>>>>#include >>>>>>>#in
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
Hi,
On 10/26/20 7:58 AM, takahiro.aka...@linaro.org wrote:
> On Fri, Oct 23, 2020 at 08:50:56AM +, Anastasiia Lukianenko wrote:
>> Hello,
>>
>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote:
>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko
>>> wrote:
Hi,
On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote:
> By using a hypervisor call, we can implement DEBUG_UART on xen.
> This will allow us to see messages even earlier than
> serial_init().
>
> Signed-off-by: AKASHI Takahiro
> ---
> drivers/serial/Kconfig | 14 +++---
> drivers/serial/serial_xen.c | 20
> 2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index e344677f91f6..536cf0641773 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK
> driver will be available until the real driver model serial
> is
> running.
>
> +config DEBUG_UART_XEN
> + bool "XEN Hypervisor Console"
> + depends on XEN_SERIAL
> + help
> + Select this to enable a debug UART using the serial_xen
> driver. You
> + will not have to provide any parameters to make this work.
> The driver
> + will be available until the real driver-model serial
> is
> running.
> +
> endchoice
>
> config DEBUG_UART_BASE
> hex "Base address of UART"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART_SANDBOX
> help
> This is the base address of your UART for memory-mapped
> UARTs.
> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE
>
> config DEBUG_UART_CLOCK
> int "UART input clock"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART_SANDBOX
> help
> The UART input clock determines the speed of the internal
> UART
> @@ -427,7 +435,7 @@ config DEBUG_UART_CLOCK
>
> config DEBUG_UART_SHIFT
> int "UART register shift"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART
> help
> Some UARTs (notably ns16550) support different register
> layouts
> diff --git a/drivers/serial/serial_xen.c
> b/drivers/serial/serial_xen.c
> index ed191829f059..34c90ece40fc 100644
> --- a/drivers/serial/serial_xen.c
> +++ b/drivers/serial/serial_xen.c
> @@ -5,6 +5,7 @@
>*/
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -15,11 +16,14 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> #include
>
> +#include
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> u32 console_evtchn;
> @@ -178,3 +182,19 @@ U_BOOT_DRIVER(serial_xen) = {
> .flags = DM_FLAG_PRE_RELOC,
> };
>
> +#if defined(CONFIG_DEBUG_UART_XEN)
> +static inline void _debug_uart_init(void) {}
> +
> +static inline void _debug_uart_putc(int c)
> +{
> +#if CONFIG_IS_ENABLED(ARM)
> + xen_debug_putc(c);
> +#else
> + /* the type cast should work on LE only */
> + HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *));
An error occurs during compilation:
drivers/serial/serial_xen.c: error: ‘ch’ undeclared (first use in
this
function); did you mean ‘c’?
HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *));
>>> Ah, yes. You're now using x86, right?
>> No, I just tried different options and accidentally discovered this
>> error.
> No?
> My code is protected with "if CONFIG_IS_ENABLED(ARM)", and so
> you have no chance of building "else" clause unless you use x86.
The question here is that if x86 is selected it won't compile. Another
question if we tested that with x86: no, we didn't. The reason we tried x86
part was that HYPERVISOR_console_io is a generic definition for all the
platforms,
so it was natural to try that as a way to debug things.
>
> Anyway,
>
>>> So what happens if you have made the fix above?
>>> Does it work in your environment?
>>> (I have confirmed that HYPERVISOR_console_io version works on
>>> arm(64).)
>> Unfortunately, nothing happened (there are no logs mentioned earlier).
> 1. Have you ever executed HYPERVISOR_console_io on your platform before?
Yes, we did that. You may have noticed that in [1] which I referred earlier
and the problems we faced with that.
> 2. If possible, please try to my code on qemu, as my patch intended, so that
> we can determine if your issue
Re: [PATCH 4/4] serial: serial_xen: add DEBUG_UART support
Hi,
On 10/26/20 8:02 AM, takahiro.aka...@linaro.org wrote:
> On Fri, Oct 23, 2020 at 08:53:52AM +, Anastasiia Lukianenko wrote:
>> Hi,
>>
>> On Thu, 2020-10-22 at 18:53 +0900, takahiro.aka...@linaro.org wrote:
>>> On Thu, Oct 22, 2020 at 09:19:41AM +, Anastasiia Lukianenko
>>> wrote:
Hi,
On Thu, 2020-10-15 at 13:25 +0900, AKASHI Takahiro wrote:
> By using a hypervisor call, we can implement DEBUG_UART on xen.
> This will allow us to see messages even earlier than
> serial_init().
>
> Signed-off-by: AKASHI Takahiro
> ---
> drivers/serial/Kconfig | 14 +++---
> drivers/serial/serial_xen.c | 20
> 2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> index e344677f91f6..536cf0641773 100644
> --- a/drivers/serial/Kconfig
> +++ b/drivers/serial/Kconfig
> @@ -401,11 +401,19 @@ config DEBUG_UART_MTK
> driver will be available until the real driver model serial
> is
> running.
>
> +config DEBUG_UART_XEN
> + bool "XEN Hypervisor Console"
> + depends on XEN_SERIAL
> + help
> + Select this to enable a debug UART using the serial_xen
> driver. You
> + will not have to provide any parameters to make this work.
> The driver
> + will be available until the real driver-model serial
> is
> running.
> +
> endchoice
>
> config DEBUG_UART_BASE
> hex "Base address of UART"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART_SANDBOX
> help
> This is the base address of your UART for memory-mapped
> UARTs.
> @@ -415,7 +423,7 @@ config DEBUG_UART_BASE
>
> config DEBUG_UART_CLOCK
> int "UART input clock"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART_SANDBOX
> help
> The UART input clock determines the speed of the internal
> UART
> @@ -427,7 +435,7 @@ config DEBUG_UART_CLOCK
>
> config DEBUG_UART_SHIFT
> int "UART register shift"
> - depends on DEBUG_UART
> + depends on DEBUG_UART && !DEBUG_UART_XEN
> default 0 if DEBUG_UART
> help
> Some UARTs (notably ns16550) support different register
> layouts
> diff --git a/drivers/serial/serial_xen.c
> b/drivers/serial/serial_xen.c
> index ed191829f059..34c90ece40fc 100644
> --- a/drivers/serial/serial_xen.c
> +++ b/drivers/serial/serial_xen.c
> @@ -5,6 +5,7 @@
>*/
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -15,11 +16,14 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> #include
>
> +#include
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> u32 console_evtchn;
> @@ -178,3 +182,19 @@ U_BOOT_DRIVER(serial_xen) = {
> .flags = DM_FLAG_PRE_RELOC,
> };
>
> +#if defined(CONFIG_DEBUG_UART_XEN)
> +static inline void _debug_uart_init(void) {}
> +
> +static inline void _debug_uart_putc(int c)
> +{
> +#if CONFIG_IS_ENABLED(ARM)
> + xen_debug_putc(c);
> +#else
> + /* the type cast should work on LE only */
> + HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *));
An error occurs during compilation:
drivers/serial/serial_xen.c: error: ‘ch’ undeclared (first use in
this
function); did you mean ‘c’?
HYPERVISOR_console_io(CONSOLEIO_write, 1, (char *));
>>> Ah, yes. You're now using x86, right?
>>>
>>> So what happens if you have made the fix above?
>>> Does it work in your environment?
>>> (I have confirmed that HYPERVISOR_console_io version works on
>>> arm(64).)
>>>
>> Sorry, I forgot to write in the last letter the question:
>> Why can't we simply use HYPERVISOR_console_io(CONSOLEIO_write, 1, (char
>> *)); for both ARM and Xen?
> Simply because the executed code on Xen side is quite simple.
> I assume that simpler it is, more chance of output.
This is true that the simpler the better. And we already have a proper platform
agnostic definition for that:
arch/arm/cpu/armv8/xen/hypercall.S:73:HYPERCALL3(console_io);
arch/arm/include/asm/xen/hypercall.h:16:int HYPERVISOR_console_io(int cmd, int
count, char *str);
include/xen/interface/xen.h:44:#define __HYPERVISOR_console_io 18
So, we are not only adding an ARM specific implementation in the patch, but
also add
#ifdef's in the code while we can simply avoid that. So, to me, it would make
much more sense if we use what we already have the way Xen has it rather than
adding
the code
Re: [RESEND PATCH v2 00/18] Add new board: Xen guest for ARM64
Ping On 8/6/20 12:42 PM, Anastasiia Lukianenko wrote: > From: Anastasiia Lukianenko > > This work introduces Xen [1] guest ARM64 board support in U-Boot with > para-virtualized (PV) [2] block and serial drivers: xenguest_arm64. > > This board is to be run as a virtual Xen guest with U-boot as its > primary bootloader. The rationale behind introducing this board is a > better and simpler decoupling of the guest from the initial > privileged domain which starts a guest’s virtual machine: there are > cross dependencies between the guest OS and initial privileged domain > (Domain-0) such as Domain-0 needs guest's kernel and may need its > device tree to boot it. These dependencies interfere if the kernel or > guest OS needs to be updated, thus having a unified bootloader in > Domain-0 allows resolving this: > 1. U-boot boot scripts, which are stored on the guest’s virtual disk, > are guest specific, so any change in the guest’s configuration can be > handled by the guest itself. > 2. Guest OS’ kernel can be updated if OS’ needs that without any help > from Domain-0. > 3. Using the Device Tree Overlay mechanism it is possible to customize > the device tree entries yet at bootloader stage inside the guest > itself, so the base device tree provided by Xen can be customized. > > Xen support for U-boot was implemented by introducing a new Xen guest > ARM64 board and porting essential drivers from MiniOS [3] as well as > some of the work previously done by NXP [4]: > 1. PV block device front driver with XenStore based device > enumeration, new UCLASS_PVBLOCK; > 2. PV serial console device front driver; > 3. Xen hypervisor support with minimal set of the essential headers > adapted from Linux kernel; > 4. grant table support; > 5. event channel support, without IRQ support, but polling; > 6. xenbus support; > 7. dynamic RAM size as defined in the device tree instead of > statically defined values; > 8. position-independent pre-relocation code is used as we cannot > statically define any start addresses at compile time which is up to > Xen to choose at run-time; > 9. new defconfig introduced: xenguest_arm64_defconfig. > > Please note, that due to the fact that para-virtualized serial driver > requires some of the Xen functionality available late not all the > printouts are available at the very start including U-Boot banner, > memory size etc. > > All the above was tested with block driver related commands > (info/part/read/write), FAT and ext4 operations work properly, the > Linux kernel can start. > > Thank you in advance, > Anastasiia Lukianenko, > Oleksandr Andrushchenko > > Changes since v1: > = > > 1. Added test for new lib sscanf function > 2. Fixed data cache maintenance process > 3. Added more comments and explanations > 4. Removed unnecessary code, which is not related to ARM64 architecture > 5. Added board documentation > 6. Coding style cleanup > 7. Added MIT License > > Anastasiia Lukianenko (7): >Add MIT License >xen: pvblock: Add initial support for para-virtualized block driver >xen: pvblock: Enumerate virtual block devices >xen: pvblock: Read XenStore configuration and initialize >xen: pvblock: Implement front-back protocol and do IO >xen: pvblock: Print found devices indices >doc: xen: Add Xen guest ARM64 board documentation > > Andrii Anisov (2): >board: Introduce xenguest_arm64 board >lib: sscanf: add sscanf implementation > > Oleksandr Andrushchenko (7): >xen: Add essential and required interface headers >xen: Port Xen hypervizor related code from mini-os >xen: Port Xen event channel driver from mini-os >linux/compat.h: Add wait_event_timeout macro >xen: Port Xen bus driver from mini-os >xen: Port Xen grant table driver from mini-os >board: xen: De-initialize before jumping to Linux > > Peng Fan (2): >Kconfig: Introduce CONFIG_XEN >serial: serial_xen: Add Xen PV serial driver > > Kconfig | 18 + > Licenses/README | 1 + > Licenses/mit.txt | 20 + > arch/arm/Kconfig | 9 + > arch/arm/cpu/armv8/Makefile | 1 + > arch/arm/cpu/armv8/xen/Makefile | 6 + > arch/arm/cpu/armv8/xen/hypercall.S| 79 ++ > arch/arm/cpu/armv8/xen/lowlevel_init.S| 33 + > arch/arm/include/asm/io.h | 4 + > arch/arm/include/asm/xen.h| 7 + > arch/arm/include/asm/xen/hypercall.h | 22 + > arch/arm/include/asm/xen/system.h | 88 +++ > board/xen/xenguest_arm64/Kconfig | 12 + > board/xen/xenguest_a
Re: [PATCH 03/17] board: Introduce xenguest_arm64 board
On 7/2/20 10:26 AM, Heinrich Schuchardt wrote: > On 02.07.20 09:18, Oleksandr Andrushchenko wrote: >> On 7/2/20 4:28 AM, Peng Fan wrote: >>>> Subject: [PATCH 03/17] board: Introduce xenguest_arm64 board >>>> >>>> From: Andrii Anisov >>>> >>>> Introduce a minimal Xen guest board running as a virtual machine under Xen >>>> Project's hypervisor [1], [2]. >>>> >>>> Part of the code is ported from Xen mini-os and also uses work initially >>>> done >>>> by different authors from NXP: please see relevant files for their >>>> copyrights. >>> This patch needs to be in the last, otherwise it might break git bisect. >> Not sure I understand why. This patch is a self-contained piece of work >> >> which introduces a new board. What's wrong with this? Why would it break? >> > We are running automated test in Gitlab CI and Travis CI. Once there is > a defconfig file we try to build the file. > > If building fails with only patches 1-3 merged, we have a problem. You both are absolutely right, we need to swap two patches, so they are in the following order: board: Introduce xenguest_arm64 board xen: Add essential and required interface headers Kconfig: Introduce CONFIG_XEN e.g. we add headers first and then the board. Thank you for pointing to it, Oleksandr > > Best regards > > Heinrich
Re: [PATCH 03/17] board: Introduce xenguest_arm64 board
On 7/2/20 4:28 AM, Peng Fan wrote: >> Subject: [PATCH 03/17] board: Introduce xenguest_arm64 board >> >> From: Andrii Anisov >> >> Introduce a minimal Xen guest board running as a virtual machine under Xen >> Project's hypervisor [1], [2]. >> >> Part of the code is ported from Xen mini-os and also uses work initially done >> by different authors from NXP: please see relevant files for their >> copyrights. > This patch needs to be in the last, otherwise it might break git bisect. Not sure I understand why. This patch is a self-contained piece of work which introduces a new board. What's wrong with this? Why would it break? > >> [1] >> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fxenbit__;JSUl!!GF_29dbcQIUBPA!kLvFHwcVni_hKobueMDuGiWwAyUqOyVghhe446DfQrocVMn84Rp1m4EWJM8nHzH0_vEGLuxcEg$ >> s.xen.org%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%7C61151b8230 >> c94f145ce408d81ddc04ee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0% >> 7C0%7C637292178110014498sdata=pgJ6Qf1iDW%2FjNWTcGBWFVYY >> SrG0MX%2FiTzbfzbyqkxsY%3Dreserved=0 >> [2] >> https://urldefense.com/v3/__https://eur01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwiki.xe__;JSUl!!GF_29dbcQIUBPA!kLvFHwcVni_hKobueMDuGiWwAyUqOyVghhe446DfQrocVMn84Rp1m4EWJM8nHzH0_vFUM7ad7A$ >> nproject.org%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%7C61151b8 >> 230c94f145ce408d81ddc04ee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C >> 0%7C0%7C637292178110014498sdata=x0gKBoJvFRQdX7YatAhgF%2Fc >> ovJ4kdrmbl2iUiXvCqww%3Dreserved=0 >> >> Signed-off-by: Andrii Anisov >> Signed-off-by: Oleksandr Andrushchenko >> >> Signed-off-by: Anastasiia Lukianenko >> --- >> arch/arm/Kconfig | 7 + >> arch/arm/cpu/armv8/Makefile | 1 + >> arch/arm/cpu/armv8/xen/Makefile | 6 + >> arch/arm/cpu/armv8/xen/hypercall.S| 78 +++ >> arch/arm/cpu/armv8/xen/lowlevel_init.S| 34 + >> arch/arm/include/asm/xen.h| 8 ++ >> arch/arm/include/asm/xen/hypercall.h | 45 +++ >> board/xen/xenguest_arm64/Kconfig | 12 ++ >> board/xen/xenguest_arm64/Makefile | 5 + >> board/xen/xenguest_arm64/xenguest_arm64.c | 153 >> ++ >> configs/xenguest_arm64_defconfig | 56 >> include/configs/xenguest_arm64.h | 45 +++ >> 12 files changed, 450 insertions(+) >> create mode 100644 arch/arm/cpu/armv8/xen/Makefile create mode >> 100644 arch/arm/cpu/armv8/xen/hypercall.S >> create mode 100644 arch/arm/cpu/armv8/xen/lowlevel_init.S >> create mode 100644 arch/arm/include/asm/xen.h create mode 100644 >> arch/arm/include/asm/xen/hypercall.h >> create mode 100644 board/xen/xenguest_arm64/Kconfig create mode >> 100644 board/xen/xenguest_arm64/Makefile create mode 100644 >> board/xen/xenguest_arm64/xenguest_arm64.c >> create mode 100644 configs/xenguest_arm64_defconfig create mode >> 100644 include/configs/xenguest_arm64.h >> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index >> e9ad716aaa..c469863967 100644 >> --- a/arch/arm/Kconfig >> +++ b/arch/arm/Kconfig >> @@ -1717,6 +1717,12 @@ config TARGET_PRESIDIO_ASIC >> bool "Support Cortina Presidio ASIC Platform" >> select ARM64 >> >> +config TARGET_XENGUEST_ARM64 >> +bool "Xen guest ARM64" >> +select ARM64 >> +select XEN >> +select OF_CONTROL >> +select LINUX_KERNEL_IMAGE_HEADER >> endchoice >> >> config ARCH_SUPPORT_TFABOOT >> @@ -1920,6 +1926,7 @@ source "board/xilinx/Kconfig" >> source "board/xilinx/zynq/Kconfig" >> source "board/xilinx/zynqmp/Kconfig" >> source "board/phytium/durian/Kconfig" >> +source "board/xen/xenguest_arm64/Kconfig" >> >> source "arch/arm/Kconfig.debug" >> >> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile >> index 2e48df0eb9..dd6c354d19 100644 >> --- a/arch/arm/cpu/armv8/Makefile >> +++ b/arch/arm/cpu/armv8/Makefile >> @@ -39,3 +39,4 @@ obj-$(CONFIG_S32V234) += s32v234/ >> obj-$(CONFIG_TARGET_HIKEY) += hisilicon/ >> obj-$(CONFIG_ARMV8_PSCI) += psci.o >> obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o >> +obj-$(CONFIG_XEN) += xen/ >> diff --git a/arch/arm/cpu/armv8/xen/Makefile >> b/arch/arm/cpu/armv8/xen/Makefile new file mode 100644 index >> 00..e3b4ae2bd4 >> --- /dev/null >> +++ b/arch/arm/cpu/armv8/xen/Makefile &g
Re: [PATCH] common/board_f: Respect original FDT size while relocating
On 6/19/20 8:51 PM, Tom Rini wrote:
> On Fri, Jun 19, 2020 at 03:19:21PM +0000, Oleksandr Andrushchenko wrote:
>> On 6/19/20 4:53 PM, Tom Rini wrote:
>>> On Fri, Jun 19, 2020 at 11:22:18AM +0300, Oleksandr Andrushchenko wrote:
>>>
>>>> From: Oleksandr Andrushchenko
>>>>
>>>> While relocating FDT we reserve some memory for the new FDT and
>>>> set the size of the FDT with that respect. But FDT may be placed
>>>> at the end of the RAM leading to memory access beyond it.
>>>> Fix this by copying exact FDT size bytes, not the reserved size.
>>>>
>>>> Signed-off-by: Oleksandr Andrushchenko
>>>> ---
>>>>common/board_f.c | 2 +-
>>>>1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/common/board_f.c b/common/board_f.c
>>>> index 01194eaa0e4d..aa1285e94999 100644
>>>> --- a/common/board_f.c
>>>> +++ b/common/board_f.c
>>>> @@ -670,7 +670,7 @@ static int reloc_fdt(void)
>>>>if (gd->flags & GD_FLG_SKIP_RELOC)
>>>>return 0;
>>>>if (gd->new_fdt) {
>>>> - memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
>>>> + memcpy(gd->new_fdt, gd->fdt_blob, fdt_totalsize(gd->fdt_blob));
>>>>gd->fdt_blob = gd->new_fdt;
>>>>}
>>>>#endif
>>> So, I think the problem is placing the fdt so close to the end of memory
>>> and we need to fix that.
>> Exactly
>>> With the above change, we won't copy past the
>>> end of memory
>> yes
>>>but gd->fdt_blob + gd->fdt_size will still point past it,
>>> yes?
>> Not really as the next op after the memcpy will set fdt_blob to the new
>> location
>>
>> and it is safe to access the memory in [gd->fdt_blob; gd->fdt_blob +
>> gd->fdt_size) range.
>>
>> We only ensure we are copying the fdt itself, not also the reserved memory
>> which
>>
>> doesn't exist past the original fdt addresses
> Ah, so I had something backwards then. We're fine because gd->new_fdt +
> gd->fdt_size is fine. Thanks!
>
Yes, that's right
Re: [PATCH] common/board_f: Respect original FDT size while relocating
On 6/19/20 4:53 PM, Tom Rini wrote:
> On Fri, Jun 19, 2020 at 11:22:18AM +0300, Oleksandr Andrushchenko wrote:
>
>> From: Oleksandr Andrushchenko
>>
>> While relocating FDT we reserve some memory for the new FDT and
>> set the size of the FDT with that respect. But FDT may be placed
>> at the end of the RAM leading to memory access beyond it.
>> Fix this by copying exact FDT size bytes, not the reserved size.
>>
>> Signed-off-by: Oleksandr Andrushchenko
>> ---
>> common/board_f.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/board_f.c b/common/board_f.c
>> index 01194eaa0e4d..aa1285e94999 100644
>> --- a/common/board_f.c
>> +++ b/common/board_f.c
>> @@ -670,7 +670,7 @@ static int reloc_fdt(void)
>> if (gd->flags & GD_FLG_SKIP_RELOC)
>> return 0;
>> if (gd->new_fdt) {
>> -memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
>> +memcpy(gd->new_fdt, gd->fdt_blob, fdt_totalsize(gd->fdt_blob));
>> gd->fdt_blob = gd->new_fdt;
>> }
>> #endif
> So, I think the problem is placing the fdt so close to the end of memory
> and we need to fix that.
Exactly
>With the above change, we won't copy past the
> end of memory
yes
> but gd->fdt_blob + gd->fdt_size will still point past it,
> yes?
Not really as the next op after the memcpy will set fdt_blob to the new location
and it is safe to access the memory in [gd->fdt_blob; gd->fdt_blob +
gd->fdt_size) range.
We only ensure we are copying the fdt itself, not also the reserved memory which
doesn't exist past the original fdt addresses
> Thanks!
>
[PATCH] common/board_f: Respect original FDT size while relocating
From: Oleksandr Andrushchenko
While relocating FDT we reserve some memory for the new FDT and
set the size of the FDT with that respect. But FDT may be placed
at the end of the RAM leading to memory access beyond it.
Fix this by copying exact FDT size bytes, not the reserved size.
Signed-off-by: Oleksandr Andrushchenko
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 01194eaa0e4d..aa1285e94999 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -670,7 +670,7 @@ static int reloc_fdt(void)
if (gd->flags & GD_FLG_SKIP_RELOC)
return 0;
if (gd->new_fdt) {
- memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
+ memcpy(gd->new_fdt, gd->fdt_blob, fdt_totalsize(gd->fdt_blob));
gd->fdt_blob = gd->new_fdt;
}
#endif
--
2.17.1
