diff mbox

[Xen-devel] xen/arm64: Use __flush_dcache_area instead of __flush_dcache_all

Message ID 1413863725-27630-1-git-send-email-roy.franz@linaro.org
State New
Headers show

Commit Message

Roy Franz Oct. 21, 2014, 3:55 a.m. UTC 
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>

When booting with EFI, __flush_dcache_all does not correctly flush data.
According to Mark Rutland, __flush_dcache_all is not guaranteed to push
data to the PoC if there is a system-level cache as it uses Set/Way
operations.  Therefore, this patch switchs to use the "__flush_dcache_area"
mechanism, which is coppied from Linux.
Add flushing of FDT in addition to Xen text/data.
Remove now unused __flush_dcache_all and related helper functions.
Invalidate the instruction tlb before turning on paging
later on when starting Xen in EL2.

Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Roy Franz <roy.franz@linaro.org>
---
Changes since v2:
* Pass FDT size to efi_xen_start, flush exact FDT size rather than
  max FDT size.  (Max size could extend past end of DRAM.)

Changes since v1:
* Added flushing of FDT memory region
* Remove used __flush_dcache_all function, and related helper functions
* Fix typo in comment
* Properly set base address in __flush_dcache_area call.
* Add flush of instruction TLB

 xen/arch/arm/arm64/cache.S  | 89 +++++++++++----------------------------------
 xen/arch/arm/arm64/head.S   | 31 +++++++++++++---
 xen/arch/arm/efi/efi-boot.h |  4 +-
 3 files changed, 48 insertions(+), 76 deletions(-)

Comments

Roy Franz Oct. 21, 2014, 3:57 a.m. UTC | #1 
Argh..  Forgot to edit subject - this is v3 or this patch, for 4.5

On Mon, Oct 20, 2014 at 8:55 PM, Roy Franz <roy.franz@linaro.org> wrote:
> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>
> When booting with EFI, __flush_dcache_all does not correctly flush data.
> According to Mark Rutland, __flush_dcache_all is not guaranteed to push
> data to the PoC if there is a system-level cache as it uses Set/Way
> operations.  Therefore, this patch switchs to use the "__flush_dcache_area"
> mechanism, which is coppied from Linux.
> Add flushing of FDT in addition to Xen text/data.
> Remove now unused __flush_dcache_all and related helper functions.
> Invalidate the instruction tlb before turning on paging
> later on when starting Xen in EL2.
>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Signed-off-by: Roy Franz <roy.franz@linaro.org>
> ---
> Changes since v2:
> * Pass FDT size to efi_xen_start, flush exact FDT size rather than
>   max FDT size.  (Max size could extend past end of DRAM.)
>
> Changes since v1:
> * Added flushing of FDT memory region
> * Remove used __flush_dcache_all function, and related helper functions
> * Fix typo in comment
> * Properly set base address in __flush_dcache_area call.
> * Add flush of instruction TLB
>
>  xen/arch/arm/arm64/cache.S  | 89 +++++++++++----------------------------------
>  xen/arch/arm/arm64/head.S   | 31 +++++++++++++---
>  xen/arch/arm/efi/efi-boot.h |  4 +-
>  3 files changed, 48 insertions(+), 76 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/cache.S b/xen/arch/arm/arm64/cache.S
> index a445cbf..eff4e16 100644
> --- a/xen/arch/arm/arm64/cache.S
> +++ b/xen/arch/arm/arm64/cache.S
> @@ -20,80 +20,33 @@
>   */
>
>  /*
> - * Enable and disable interrupts.
> + * dcache_line_size - get the minimum D-cache line size from the CTR register.
>   */
> -       .macro  disable_irq
> -       msr     daifset, #2
> -       .endm
> -
> -       .macro  enable_irq
> -       msr     daifclr, #2
> -       .endm
> -
> -/*
> - * Save/disable and restore interrupts.
> - */
> -       .macro  save_and_disable_irqs, olddaif
> -       mrs     \olddaif, daif
> -       disable_irq
> -       .endm
> -
> -       .macro  restore_irqs, olddaif
> -       msr     daif, \olddaif
> +       .macro  dcache_line_size, reg, tmp
> +       mrs     \tmp, ctr_el0                   // read CTR
> +       ubfm    \tmp, \tmp, #16, #19            // cache line size encoding
> +       mov     \reg, #4                        // bytes per word
> +       lsl     \reg, \reg, \tmp                // actual cache line size
>         .endm
>
>  /*
> - *     __flush_dcache_all()
> + *     __flush_dcache_area(kaddr, size)
>   *
> - *     Flush the whole D-cache.
> + *     Ensure that the data held in the page kaddr is written back to the
> + *     page in question.
>   *
> - *     Corrupted registers: x0-x7, x9-x11
> + *     - kaddr   - kernel address
> + *     - size    - size in question
>   */
> -ENTRY(__flush_dcache_all)
> -       dmb     sy                              // ensure ordering with previous memory accesses
> -       mrs     x0, clidr_el1                   // read clidr
> -       and     x3, x0, #0x7000000              // extract loc from clidr
> -       lsr     x3, x3, #23                     // left align loc bit field
> -       cbz     x3, finished                    // if loc is 0, then no need to clean
> -       mov     x10, #0                         // start clean at cache level 0
> -loop1:
> -       add     x2, x10, x10, lsr #1            // work out 3x current cache level
> -       lsr     x1, x0, x2                      // extract cache type bits from clidr
> -       and     x1, x1, #7                      // mask of the bits for current cache only
> -       cmp     x1, #2                          // see what cache we have at this level
> -       b.lt    skip                            // skip if no cache, or just i-cache
> -       save_and_disable_irqs x9                // make CSSELR and CCSIDR access atomic
> -       msr     csselr_el1, x10                 // select current cache level in csselr
> -       isb                                     // isb to sych the new cssr&csidr
> -       mrs     x1, ccsidr_el1                  // read the new ccsidr
> -       restore_irqs x9
> -       and     x2, x1, #7                      // extract the length of the cache lines
> -       add     x2, x2, #4                      // add 4 (line length offset)
> -       mov     x4, #0x3ff
> -       and     x4, x4, x1, lsr #3              // find maximum number on the way size
> -       clz     w5, w4                          // find bit position of way size increment
> -       mov     x7, #0x7fff
> -       and     x7, x7, x1, lsr #13             // extract max number of the index size
> -loop2:
> -       mov     x9, x4                          // create working copy of max way size
> -loop3:
> -       lsl     x6, x9, x5
> -       orr     x11, x10, x6                    // factor way and cache number into x11
> -       lsl     x6, x7, x2
> -       orr     x11, x11, x6                    // factor index number into x11
> -       dc      cisw, x11                       // clean & invalidate by set/way
> -       subs    x9, x9, #1                      // decrement the way
> -       b.ge    loop3
> -       subs    x7, x7, #1                      // decrement the index
> -       b.ge    loop2
> -skip:
> -       add     x10, x10, #2                    // increment cache number
> -       cmp     x3, x10
> -       b.gt    loop1
> -finished:
> -       mov     x10, #0                         // swith back to cache level 0
> -       msr     csselr_el1, x10                 // select current cache level in csselr
> +ENTRY(__flush_dcache_area)
> +       dcache_line_size x2, x3
> +       add     x1, x0, x1
> +       sub     x3, x2, #1
> +       bic     x0, x0, x3
> +1:     dc      civac, x0                       // clean & invalidate D line / unified line
> +       add     x0, x0, x2
> +       cmp     x0, x1
> +       b.lo    1b
>         dsb     sy
> -       isb
>         ret
> -ENDPROC(__flush_dcache_all)
> +ENDPROC(__flush_dcache_area)
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 7650abe..9379dd1 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -736,20 +736,39 @@ ENTRY(lookup_processor_type)
>          ret
>  /*
>   *  Function to transition from EFI loader in C, to Xen entry point.
> - *  void noreturn efi_xen_start(void *fdt_ptr);
> + *  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>   */
>  ENTRY(efi_xen_start)
>          /*
> +         * Preserve x0 (fdt pointer) across call to __flush_dcache_area,
> +         * restore for entry into Xen.
> +         */
> +        mov   x20, x0
> +
> +        /* flush dcache covering the FDT updated by EFI boot code */
> +        bl    __flush_dcache_area
> +
> +        /*
> +         * Flush dcache covering current runtime addresses
> +         * of xen text/data. Then flush all of icache.
> +         */
> +        adrp  x1, _start
> +        add   x1, x1, #:lo12:_start
> +        mov   x0, x1
> +        adrp  x2, _end
> +        add   x2, x2, #:lo12:_end
> +        sub   x1, x2, x1
> +
> +        bl    __flush_dcache_area
> +        ic    ialluis
> +        tlbi alle2
> +
> +        /*
>           * Turn off cache and MMU as Xen expects. EFI enables them, but also
>           * mandates a 1:1 (unity) VA->PA mapping, so we can turn off the
>           * MMU while executing EFI code before entering Xen.
>           * The EFI loader calls this to start Xen.
> -         * Preserve x0 (fdf pointer) across call to __flush_dcache_all,
> -         * restore for entry into Xen.
>           */
> -        mov   x20, x0
> -        bl    __flush_dcache_all
> -        ic    ialluis
>
>          /* Turn off Dcache and MMU */
>          mrs   x0, sctlr_el2
> diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
> index 7abc059..d40d8b2 100644
> --- a/xen/arch/arm/efi/efi-boot.h
> +++ b/xen/arch/arm/efi/efi-boot.h
> @@ -7,7 +7,7 @@
>  #include <xen/libfdt/libfdt.h>
>  #include <asm/setup.h>
>
> -void noreturn efi_xen_start(void *fdt_ptr);
> +void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>
>  #define DEVICE_TREE_GUID \
>  {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
> @@ -343,7 +343,7 @@ static void __init efi_arch_pre_exit_boot(void)
>
>  static void __init efi_arch_post_exit_boot(void)
>  {
> -    efi_xen_start(fdt);
> +    efi_xen_start(fdt, fdt_totalsize(fdt));
>  }
>
>  static void __init efi_arch_cfg_file_early(EFI_FILE_HANDLE dir_handle, char *section)
> --
> 1.9.1
>
Ian Campbell Oct. 21, 2014, 8:17 a.m. UTC | #2 
On Mon, 2014-10-20 at 20:55 -0700, Roy Franz wrote:
[...]
> - *  void noreturn efi_xen_start(void *fdt_ptr);
> + *  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
>   */
>  ENTRY(efi_xen_start)
>          /*
> +         * Preserve x0 (fdt pointer) across call to __flush_dcache_area,
> +         * restore for entry into Xen.
> +         */
> +        mov   x20, x0
> +
> +        /* flush dcache covering the FDT updated by EFI boot code */

According to the above strictly speaking the length is in w1 rather than
x1. However I'm fairly certain (without having checked) that assigning
to wn clears the upper 32-bits so this is fine. Hence:
Acked-by: Ian Campbell <ian.campbell@citrix.com>
and applied.

If I'm misremembering about the writes to wn please holler ;-)

> +        ic    ialluis
> +        tlbi alle2

I added a space here to line up the alle2.

Ian.
Ian Campbell Oct. 21, 2014, 2:17 p.m. UTC | #3 
(trimming the CC list a bit)

On Tue, 2014-10-21 at 09:17 +0100, Ian Campbell wrote:
> and applied.

So with this in place I'm seeing a couple of remaining issues (running
on Juno). I've loaded xen.efi, Image, juno.dtb and a file called cfg
into NOR, cfg contains:

        [global]
        default=default
        
        [default]
        options=console=dtuart dtuart=serial0 conswitch=x
        kernel=Image console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda1
        dtb=juno
        
(nb the juno firmware strips the extensions, hence juno not juno.dtb)

I've used the boot manager to create a boot entry:
        [1] Linux from NOR Flash
        [2] Linux EFI TFTP
        [3] Xen from NOR Flash
        [4] Shell
        [5] Boot Manager
        Start: 5
        [1] Add Boot Device Entry
        [2] Update Boot Device Entry
        [3] Remove Boot Device Entry
        [4] Reorder Boot Device Entries
        [5] Update FDT path
        [6] Set Boot Timeout
        [7] Return to main menu
        Choice: 1
        [1] NOR Flash (63 MB)
        [2] Firmware Volume (63 MB)
        [3] Firmware Volume (63 MB)
        [4] VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)
        [5] VenHw(02118005-9DA7-443A-92D5-781F022AEDBB)
        [6] PXE on MAC Address: 00:02:F7:00:58:73
        [7] TFTP on MAC Address: 00:02:F7:00:58:73
        Select the Boot Device: 1
        File path of the EFI Application or the kernel: xen
        Is your application is an OS loader? [y/n] n
        Arguments to pass to the EFI Application: -cfg=cfg
        Description for this new Entry: Xen from NOR Flash (2nd try)
        
Then:
        [1] Linux from NOR Flash
        [2] Linux EFI TFTP
        [3] Xen from NOR Flash
        [4] Xen from NOR Flash (2nd try)
        [5] Shell
        [6] Boot Manager
        Start: 4
        Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
        No configuration file found.
        [1] Linux from NOR Flash
        [2] Linux EFI TFTP
        [3] Xen from NOR Flash
        [4] Xen from NOR Flash (2nd try)
        [5] Shell
        [6] Boot Manager
        Start:

But if I use the shell (fs2: is the NOR flash)

        Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
        Shell> fs2:
        FS2:\> dir
        Directory of: FS2:\
        00/00/0000  00:00           1,071,716  fip
        00/00/0000  00:00             755,472  xen
        00/00/0000  00:00           6,325,424  Image
        00/00/0000  00:00              10,185  juno
        00/00/0000  00:00                 172  cfg
        00/00/0000  00:00              12,296  bl1
                  6 File(s)   8,175,265 bytes
                  0 Dir(s)
        FS2:\> xen -cfg=cfg
        Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
        juno: 0x00000009fadf7000-0x00000009fadf97c9
        Image: 0x00000009fa405000-0x00000009faa0d4b0
        - UART enabled -
        - CPU 00000100 booting -
        - Current EL 00000008 -
        - Xen starting at EL2 -
        - Zero BSS -
        - Setting up control registers -
        - Turning on paging -
        - Ready -
        (XEN) Checking for initrd in /chosen
        (XEN) RAM: 0000000080000000 - 00000000dfffffff
        (XEN) RAM: 00000000e00f0000 - 00000000febcffff
        (XEN) RAM: 00000000febd7000 - 00000000feffffff
        (XEN) RAM: 0000000880000000 - 00000009fa404fff
        (XEN) RAM: 00000009fac05000 - 00000009fada9fff
        (XEN) RAM: 00000009fadab000 - 00000009fadf2fff
        (XEN) RAM: 00000009fadf7000 - 00000009fadf8fff
        (XEN) RAM: 00000009fadfd000 - 00000009faf6efff
        (XEN) RAM: 00000009fafaa000 - 00000009fe42afff
        (XEN) RAM: 00000009fe42b000 - 00000009fe918fff
        (XEN) RAM: 00000009fe919000 - 00000009fec4efff
        
So it works from the shell but not the boot manager. I wondered if it
might relate to UEFI's equivalent of $CWD at the point it loads xen vs
the point at which xen tries to read things, so I've tried various
things like -cfg=fs2:\cfg (with various combinations of /, \ and
nothing) in the boot mgmr with no luck.

The second issue is that sometimes:
        FS2:\> xen -cfg=cfg
        Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
        juno: 0x00000009fadf9000-0x00000009fadfb7c9
        Image: 0x00000009fa405000-0x00000009faa0d4b0
        Cannot obtain memory map: ErrCode: 0x8000000000000005

I'm not sure but this seems to correlate at least somewhat with trying
(unsuccessfully) trying to use the boot manager path before dropping to
the shell. It invariable works on a second attempt.

Anyone got any ideas on any of this?

Ian.
Roy Franz Oct. 22, 2014, 3:59 a.m. UTC | #4 
On Tue, Oct 21, 2014 at 7:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> (trimming the CC list a bit)
>
> On Tue, 2014-10-21 at 09:17 +0100, Ian Campbell wrote:
>> and applied.
>
> So with this in place I'm seeing a couple of remaining issues (running
> on Juno). I've loaded xen.efi, Image, juno.dtb and a file called cfg
> into NOR, cfg contains:
>
>         [global]
>         default=default
>
>         [default]
>         options=console=dtuart dtuart=serial0 conswitch=x
>         kernel=Image console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda1
>         dtb=juno
>
> (nb the juno firmware strips the extensions, hence juno not juno.dtb)
>
> I've used the boot manager to create a boot entry:
>         [1] Linux from NOR Flash
>         [2] Linux EFI TFTP
>         [3] Xen from NOR Flash
>         [4] Shell
>         [5] Boot Manager
>         Start: 5
>         [1] Add Boot Device Entry
>         [2] Update Boot Device Entry
>         [3] Remove Boot Device Entry
>         [4] Reorder Boot Device Entries
>         [5] Update FDT path
>         [6] Set Boot Timeout
>         [7] Return to main menu
>         Choice: 1
>         [1] NOR Flash (63 MB)
>         [2] Firmware Volume (63 MB)
>         [3] Firmware Volume (63 MB)
>         [4] VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)
>         [5] VenHw(02118005-9DA7-443A-92D5-781F022AEDBB)
>         [6] PXE on MAC Address: 00:02:F7:00:58:73
>         [7] TFTP on MAC Address: 00:02:F7:00:58:73
>         Select the Boot Device: 1
>         File path of the EFI Application or the kernel: xen
>         Is your application is an OS loader? [y/n] n
>         Arguments to pass to the EFI Application: -cfg=cfg
>         Description for this new Entry: Xen from NOR Flash (2nd try)
>
> Then:
>         [1] Linux from NOR Flash
>         [2] Linux EFI TFTP
>         [3] Xen from NOR Flash
>         [4] Xen from NOR Flash (2nd try)
>         [5] Shell
>         [6] Boot Manager
>         Start: 4
>         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
>         No configuration file found.
>         [1] Linux from NOR Flash
>         [2] Linux EFI TFTP
>         [3] Xen from NOR Flash
>         [4] Xen from NOR Flash (2nd try)
>         [5] Shell
>         [6] Boot Manager
>         Start:
>
> But if I use the shell (fs2: is the NOR flash)
>
>         Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
>         Shell> fs2:
>         FS2:\> dir
>         Directory of: FS2:\
>         00/00/0000  00:00           1,071,716  fip
>         00/00/0000  00:00             755,472  xen
>         00/00/0000  00:00           6,325,424  Image
>         00/00/0000  00:00              10,185  juno
>         00/00/0000  00:00                 172  cfg
>         00/00/0000  00:00              12,296  bl1
>                   6 File(s)   8,175,265 bytes
>                   0 Dir(s)
>         FS2:\> xen -cfg=cfg
>         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
>         juno: 0x00000009fadf7000-0x00000009fadf97c9
>         Image: 0x00000009fa405000-0x00000009faa0d4b0
>         - UART enabled -
>         - CPU 00000100 booting -
>         - Current EL 00000008 -
>         - Xen starting at EL2 -
>         - Zero BSS -
>         - Setting up control registers -
>         - Turning on paging -
>         - Ready -
>         (XEN) Checking for initrd in /chosen
>         (XEN) RAM: 0000000080000000 - 00000000dfffffff
>         (XEN) RAM: 00000000e00f0000 - 00000000febcffff
>         (XEN) RAM: 00000000febd7000 - 00000000feffffff
>         (XEN) RAM: 0000000880000000 - 00000009fa404fff
>         (XEN) RAM: 00000009fac05000 - 00000009fada9fff
>         (XEN) RAM: 00000009fadab000 - 00000009fadf2fff
>         (XEN) RAM: 00000009fadf7000 - 00000009fadf8fff
>         (XEN) RAM: 00000009fadfd000 - 00000009faf6efff
>         (XEN) RAM: 00000009fafaa000 - 00000009fe42afff
>         (XEN) RAM: 00000009fe42b000 - 00000009fe918fff
>         (XEN) RAM: 00000009fe919000 - 00000009fec4efff
>
> So it works from the shell but not the boot manager. I wondered if it
> might relate to UEFI's equivalent of $CWD at the point it loads xen vs
> the point at which xen tries to read things, so I've tried various
> things like -cfg=fs2:\cfg (with various combinations of /, \ and
> nothing) in the boot mgmr with no luck.

I ran into a similar issue when working on a LAVA test case - startup.nsh is run
with the CWD not set, and no files can be found.  The EFI boot code
uses the file path from the LOADED_IMAGE_PROTOCOL to look up the parent
directory, and then uses this to look for the configuration file.  For
the lava testing
I now cd to the location of xen before running it, and this resolves
the problem, so
it does seem to be CWD related. I had done my development work using the FVP
model semi-hosting, which avoided this problem, likely due to some of
the tricks it plays.
This logic is unchanged by my patches, and I haven't looked in detail as to
what it does.  I'm not sure what CWD should be set to for bootmenu items
or for startup.nsh - I don't know if EDK2 on arm64 is not setting this properly,
or if the logic in the EFI code is wrong.

>
> The second issue is that sometimes:
>         FS2:\> xen -cfg=cfg
>         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
>         juno: 0x00000009fadf9000-0x00000009fadfb7c9
>         Image: 0x00000009fa405000-0x00000009faa0d4b0
>         Cannot obtain memory map: ErrCode: 0x8000000000000005
>
> I'm not sure but this seems to correlate at least somewhat with trying
> (unsuccessfully) trying to use the boot manager path before dropping to
> the shell. It invariable works on a second attempt.
This I think I understand.  For ARM we get the map size, then allocate
memory for it (allocating some extra), then get the map into the
allocated buffer.
The problem is that while we allocate extra memory, we don't adjust the size
variable, so when we pass the size to the GetMemoryMap it is the exact
size required,
even though we have allocated more.  The error code is "BUFFER_TOO_SMALL".

I'll post a patch shortly which will hopefully fix this for you.

>
> Anyone got any ideas on any of this?
>
> Ian.
>
Ian Campbell Oct. 22, 2014, 8:47 a.m. UTC | #5 
(adding Jan)

On Tue, 2014-10-21 at 20:59 -0700, Roy Franz wrote:
> On Tue, Oct 21, 2014 at 7:17 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > (trimming the CC list a bit)
> >
> > On Tue, 2014-10-21 at 09:17 +0100, Ian Campbell wrote:
> >> and applied.
> >
> > So with this in place I'm seeing a couple of remaining issues (running
> > on Juno). I've loaded xen.efi, Image, juno.dtb and a file called cfg
> > into NOR, cfg contains:
> >
> >         [global]
> >         default=default
> >
> >         [default]
> >         options=console=dtuart dtuart=serial0 conswitch=x
> >         kernel=Image console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda1
> >         dtb=juno
> >
> > (nb the juno firmware strips the extensions, hence juno not juno.dtb)
> >
> > I've used the boot manager to create a boot entry:
> >         [1] Linux from NOR Flash
> >         [2] Linux EFI TFTP
> >         [3] Xen from NOR Flash
> >         [4] Shell
> >         [5] Boot Manager
> >         Start: 5
> >         [1] Add Boot Device Entry
> >         [2] Update Boot Device Entry
> >         [3] Remove Boot Device Entry
> >         [4] Reorder Boot Device Entries
> >         [5] Update FDT path
> >         [6] Set Boot Timeout
> >         [7] Return to main menu
> >         Choice: 1
> >         [1] NOR Flash (63 MB)
> >         [2] Firmware Volume (63 MB)
> >         [3] Firmware Volume (63 MB)
> >         [4] VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)
> >         [5] VenHw(02118005-9DA7-443A-92D5-781F022AEDBB)
> >         [6] PXE on MAC Address: 00:02:F7:00:58:73
> >         [7] TFTP on MAC Address: 00:02:F7:00:58:73
> >         Select the Boot Device: 1
> >         File path of the EFI Application or the kernel: xen
> >         Is your application is an OS loader? [y/n] n
> >         Arguments to pass to the EFI Application: -cfg=cfg
> >         Description for this new Entry: Xen from NOR Flash (2nd try)
> >
> > Then:
> >         [1] Linux from NOR Flash
> >         [2] Linux EFI TFTP
> >         [3] Xen from NOR Flash
> >         [4] Xen from NOR Flash (2nd try)
> >         [5] Shell
> >         [6] Boot Manager
> >         Start: 4
> >         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
> >         No configuration file found.
> >         [1] Linux from NOR Flash
> >         [2] Linux EFI TFTP
> >         [3] Xen from NOR Flash
> >         [4] Xen from NOR Flash (2nd try)
> >         [5] Shell
> >         [6] Boot Manager
> >         Start:
> >
> > But if I use the shell (fs2: is the NOR flash)
> >
> >         Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
> >         Shell> fs2:
> >         FS2:\> dir
> >         Directory of: FS2:\
> >         00/00/0000  00:00           1,071,716  fip
> >         00/00/0000  00:00             755,472  xen
> >         00/00/0000  00:00           6,325,424  Image
> >         00/00/0000  00:00              10,185  juno
> >         00/00/0000  00:00                 172  cfg
> >         00/00/0000  00:00              12,296  bl1
> >                   6 File(s)   8,175,265 bytes
> >                   0 Dir(s)
> >         FS2:\> xen -cfg=cfg
> >         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
> >         juno: 0x00000009fadf7000-0x00000009fadf97c9
> >         Image: 0x00000009fa405000-0x00000009faa0d4b0
> >         - UART enabled -
> >         - CPU 00000100 booting -
> >         - Current EL 00000008 -
> >         - Xen starting at EL2 -
> >         - Zero BSS -
> >         - Setting up control registers -
> >         - Turning on paging -
> >         - Ready -
> >         (XEN) Checking for initrd in /chosen
> >         (XEN) RAM: 0000000080000000 - 00000000dfffffff
> >         (XEN) RAM: 00000000e00f0000 - 00000000febcffff
> >         (XEN) RAM: 00000000febd7000 - 00000000feffffff
> >         (XEN) RAM: 0000000880000000 - 00000009fa404fff
> >         (XEN) RAM: 00000009fac05000 - 00000009fada9fff
> >         (XEN) RAM: 00000009fadab000 - 00000009fadf2fff
> >         (XEN) RAM: 00000009fadf7000 - 00000009fadf8fff
> >         (XEN) RAM: 00000009fadfd000 - 00000009faf6efff
> >         (XEN) RAM: 00000009fafaa000 - 00000009fe42afff
> >         (XEN) RAM: 00000009fe42b000 - 00000009fe918fff
> >         (XEN) RAM: 00000009fe919000 - 00000009fec4efff
> >
> > So it works from the shell but not the boot manager. I wondered if it
> > might relate to UEFI's equivalent of $CWD at the point it loads xen vs
> > the point at which xen tries to read things, so I've tried various
> > things like -cfg=fs2:\cfg (with various combinations of /, \ and
> > nothing) in the boot mgmr with no luck.
> 
> I ran into a similar issue when working on a LAVA test case - startup.nsh is run
> with the CWD not set, and no files can be found.  The EFI boot code
> uses the file path from the LOADED_IMAGE_PROTOCOL to look up the parent
> directory, and then uses this to look for the configuration file.  For
> the lava testing
> I now cd to the location of xen before running it, and this resolves
> the problem, so
> it does seem to be CWD related. I had done my development work using the FVP
> model semi-hosting, which avoided this problem, likely due to some of
> the tricks it plays.
> This logic is unchanged by my patches, and I haven't looked in detail as to
> what it does.  I'm not sure what CWD should be set to for bootmenu items
> or for startup.nsh - I don't know if EDK2 on arm64 is not setting this properly,
> or if the logic in the EFI code is wrong.

Since http://xenbits.xenproject.org/docs/unstable/misc/efi.html doesn't
mention any need to qualify paths with a disk: prefix I suppose x86
doesn't require anything like this. Jan can you confirm?

I'm a bit confused why -cfg=fs2:cfg (or fs2:/cfg or fs2:\cfg) doesn't
work, since they specify the disk directly, but maybe I just don't
understand this aspect of EFI and the application/stub needs to parse
that if it wants to support loading things from other volumes (and
doesn't, which is fine).

It's interesting that Linux on juno is correctly able to load the
dtb=juno from its command line. Is there some difference here between
the interfaces used by the Linux stub vs the Xen one?

Linux's handle_cmdline_files() helper is structured rather differently
to Xen's read_file() one, but it looks like the underlying EFI calls
(open_volume, file_read) are pretty similar. There's some path
manipulation stuff in both which I don't really grok.

> > The second issue is that sometimes:
[..]
> >         Cannot obtain memory map: ErrCode: 0x8000000000000005
[...]
> I'll post a patch shortly which will hopefully fix this for you.

Seen and acked, thanks!

Ian.
Jan Beulich Oct. 22, 2014, 9:51 a.m. UTC | #6 
>>> On 22.10.14 at 10:47, <Ian.Campbell@citrix.com> wrote:
> Since http://xenbits.xenproject.org/docs/unstable/misc/efi.html doesn't
> mention any need to qualify paths with a disk: prefix I suppose x86
> doesn't require anything like this. Jan can you confirm?

According to my own experience, the path used to invoke xen.efi
(no matter whether from the shell of a boot manager entry) is
sufficient to access all other files (which are getting resolved
relative to xen.efi's location). However, I don't think I ever tried
running something from the root of a file system. And of course I
have no idea how similar the code bases are your and my firmware
got built from.

> I'm a bit confused why -cfg=fs2:cfg (or fs2:/cfg or fs2:\cfg) doesn't

Out of those, afaik only the variant using a backslash is valid (the
first one being valid only if the current directory is the root of the
fs; I don't recall whether EFI maintains per-FS CWDs or just a
single global one).

Did you verify that your EFI binary got control passed at all (i.e.
whether it really is an issue with reading the config file)?

> work, since they specify the disk directly, but maybe I just don't
> understand this aspect of EFI and the application/stub needs to parse
> that if it wants to support loading things from other volumes (and
> doesn't, which is fine).
> 
> It's interesting that Linux on juno is correctly able to load the
> dtb=juno from its command line. Is there some difference here between
> the interfaces used by the Linux stub vs the Xen one?

Quite possible - ours is derived from code we had been using for an
abandoned OS project over ten years ago.

Jan
Ian Campbell Oct. 22, 2014, 10:45 a.m. UTC | #7 
On Wed, 2014-10-22 at 10:51 +0100, Jan Beulich wrote:
> >>> On 22.10.14 at 10:47, <Ian.Campbell@citrix.com> wrote:
> > Since http://xenbits.xenproject.org/docs/unstable/misc/efi.html doesn't
> > mention any need to qualify paths with a disk: prefix I suppose x86
> > doesn't require anything like this. Jan can you confirm?
> 
> According to my own experience, the path used to invoke xen.efi
> (no matter whether from the shell of a boot manager entry) is
> sufficient to access all other files (which are getting resolved
> relative to xen.efi's location). However, I don't think I ever tried
> running something from the root of a file system. And of course I
> have no idea how similar the code bases are your and my firmware
> got built from.

You are always running from (/boot/)EFI/$vendor/ or similar I suppose.

> > I'm a bit confused why -cfg=fs2:cfg (or fs2:/cfg or fs2:\cfg) doesn't
> 
> Out of those, afaik only the variant using a backslash is valid (the
> first one being valid only if the current directory is the root of the
> fs; I don't recall whether EFI maintains per-FS CWDs or just a
> single global one).

OK, that makes sense.

> Did you verify that your EFI binary got control passed at all (i.e.
> whether it really is an issue with reading the config file)?

It prints:
        Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader
        No configuration file found.
So I'm pretty sure xen.efi has been called.

> > work, since they specify the disk directly, but maybe I just don't
> > understand this aspect of EFI and the application/stub needs to parse
> > that if it wants to support loading things from other volumes (and
> > doesn't, which is fine).
> > 
> > It's interesting that Linux on juno is correctly able to load the
> > dtb=juno from its command line. Is there some difference here between
> > the interfaces used by the Linux stub vs the Xen one?
> 
> Quite possible - ours is derived from code we had been using for an
> abandoned OS project over ten years ago.

OK, so it probably is worth investigating what Xen does differently a
little then.

Ian.
Jan Beulich Oct. 22, 2014, 2:14 p.m. UTC | #8 
>>> On 22.10.14 at 12:45, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-10-22 at 10:51 +0100, Jan Beulich wrote:
>> >>> On 22.10.14 at 10:47, <Ian.Campbell@citrix.com> wrote:
>> > Since http://xenbits.xenproject.org/docs/unstable/misc/efi.html doesn't
>> > mention any need to qualify paths with a disk: prefix I suppose x86
>> > doesn't require anything like this. Jan can you confirm?
>> 
>> According to my own experience, the path used to invoke xen.efi
>> (no matter whether from the shell of a boot manager entry) is
>> sufficient to access all other files (which are getting resolved
>> relative to xen.efi's location). However, I don't think I ever tried
>> running something from the root of a file system. And of course I
>> have no idea how similar the code bases are your and my firmware
>> got built from.
> 
> You are always running from (/boot/)EFI/$vendor/ or similar I suppose.

Yes.

>> Did you verify that your EFI binary got control passed at all (i.e.
>> whether it really is an issue with reading the config file)?
> 
> It prints:
>         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) 
> EFI loader
>         No configuration file found.
> So I'm pretty sure xen.efi has been called.

Definitely. Did I overlook that being mentioned before?

>> > work, since they specify the disk directly, but maybe I just don't
>> > understand this aspect of EFI and the application/stub needs to parse
>> > that if it wants to support loading things from other volumes (and
>> > doesn't, which is fine).
>> > 
>> > It's interesting that Linux on juno is correctly able to load the
>> > dtb=juno from its command line. Is there some difference here between
>> > the interfaces used by the Linux stub vs the Xen one?
>> 
>> Quite possible - ours is derived from code we had been using for an
>> abandoned OS project over ten years ago.
> 
> OK, so it probably is worth investigating what Xen does differently a
> little then.

Or at least adding verbosity to the operations it does, to see when
which error code(s) get(s) returned. Since failure is being accounted
for (and recovered from), those error codes wouldn't normally make
sense to print out. But first of all - I suppose this NOR thing has a
proper file system (and hence a respective EFI protocol) on it? I ask
because iirc we can't currently handle being remote booted because
we expect a file system protocol, yet in that case it's a different one
that would need to be used. There simply was no-one to ask for
that functionality yet...

Jan
Ian Campbell Oct. 22, 2014, 2:24 p.m. UTC | #9 
On Wed, 2014-10-22 at 15:14 +0100, Jan Beulich wrote:

> >> Did you verify that your EFI binary got control passed at all (i.e.
> >> whether it really is an issue with reading the config file)?
> > 
> > It prints:
> >         Xen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) 
> > EFI loader
> >         No configuration file found.
> > So I'm pretty sure xen.efi has been called.
> 
> Definitely. Did I overlook that being mentioned before?

I think it had been trimmed by the time you were CCd.

> >> > work, since they specify the disk directly, but maybe I just don't
> >> > understand this aspect of EFI and the application/stub needs to parse
> >> > that if it wants to support loading things from other volumes (and
> >> > doesn't, which is fine).
> >> > 
> >> > It's interesting that Linux on juno is correctly able to load the
> >> > dtb=juno from its command line. Is there some difference here between
> >> > the interfaces used by the Linux stub vs the Xen one?
> >> 
> >> Quite possible - ours is derived from code we had been using for an
> >> abandoned OS project over ten years ago.
> > 
> > OK, so it probably is worth investigating what Xen does differently a
> > little then.
> 
> Or at least adding verbosity to the operations it does, to see when
> which error code(s) get(s) returned. Since failure is being accounted
> for (and recovered from), those error codes wouldn't normally make
> sense to print out.

Yes.

>  But first of all - I suppose this NOR thing has a
> proper file system (and hence a respective EFI protocol) on it? I ask
> because iirc we can't currently handle being remote booted because
> we expect a file system protocol, yet in that case it's a different one
> that would need to be used. There simply was no-one to ask for
> that functionality yet...

A proper filesystem is perhaps a bit of a stretch, you feed the lower
level firmware an index file mapping filenames to regions of flash and
it fakes up a filesystem, so it looks like a file system protocol to the
UEFI app I think.

It doesn't do subdirs (AFAIK) or any modern newfangled concepts like
that ;-)

Ian.
Jan Beulich Oct. 22, 2014, 2:31 p.m. UTC | #10 
>>> On 22.10.14 at 16:24, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-10-22 at 15:14 +0100, Jan Beulich wrote:
>>  But first of all - I suppose this NOR thing has a
>> proper file system (and hence a respective EFI protocol) on it? I ask
>> because iirc we can't currently handle being remote booted because
>> we expect a file system protocol, yet in that case it's a different one
>> that would need to be used. There simply was no-one to ask for
>> that functionality yet...
> 
> A proper filesystem is perhaps a bit of a stretch, you feed the lower
> level firmware an index file mapping filenames to regions of flash and
> it fakes up a filesystem, so it looks like a file system protocol to the
> UEFI app I think.

So maybe something isn't being done as we expect it (which isn't to
say that what we expect is necessarily right).

Jan
Roy Franz Oct. 23, 2014, 10:49 p.m. UTC | #11 
On Wed, Oct 22, 2014 at 7:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.10.14 at 16:24, <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2014-10-22 at 15:14 +0100, Jan Beulich wrote:
>>>  But first of all - I suppose this NOR thing has a
>>> proper file system (and hence a respective EFI protocol) on it? I ask
>>> because iirc we can't currently handle being remote booted because
>>> we expect a file system protocol, yet in that case it's a different one
>>> that would need to be used. There simply was no-one to ask for
>>> that functionality yet...
>>
>> A proper filesystem is perhaps a bit of a stretch, you feed the lower
>> level firmware an index file mapping filenames to regions of flash and
>> it fakes up a filesystem, so it looks like a file system protocol to the
>> UEFI app I think.
>
> So maybe something isn't being done as we expect it (which isn't to
> say that what we expect is necessarily right).
>
> Jan
>

I did some more investigation today, on both x86 and ARM regarding
starting from "startup.nsh".  Both x86 and ARM behave the same,
and do _not_ require a CWD to be set.  Xen can correctly find the
config file and module files from the directory that startup.nsh runs it from,
even if no CWD is set.  My earlier conclusions on regarding the CWD
were incorrect.
I have not had a chance to try starting Xen from the bootmenu yet to try to
reproduce the behavior Ian is seeing.

Roy
Roy Franz Oct. 25, 2014, 12:29 a.m. UTC | #12 
On Thu, Oct 23, 2014 at 3:49 PM, Roy Franz <roy.franz@linaro.org> wrote:
> On Wed, Oct 22, 2014 at 7:31 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 22.10.14 at 16:24, <Ian.Campbell@citrix.com> wrote:
>>> On Wed, 2014-10-22 at 15:14 +0100, Jan Beulich wrote:
>>>>  But first of all - I suppose this NOR thing has a
>>>> proper file system (and hence a respective EFI protocol) on it? I ask
>>>> because iirc we can't currently handle being remote booted because
>>>> we expect a file system protocol, yet in that case it's a different one
>>>> that would need to be used. There simply was no-one to ask for
>>>> that functionality yet...
>>>
>>> A proper filesystem is perhaps a bit of a stretch, you feed the lower
>>> level firmware an index file mapping filenames to regions of flash and
>>> it fakes up a filesystem, so it looks like a file system protocol to the
>>> UEFI app I think.
>>
>> So maybe something isn't being done as we expect it (which isn't to
>> say that what we expect is necessarily right).
>>
>> Jan
>>
>
> I did some more investigation today, on both x86 and ARM regarding
> starting from "startup.nsh".  Both x86 and ARM behave the same,
> and do _not_ require a CWD to be set.  Xen can correctly find the
> config file and module files from the directory that startup.nsh runs it from,
> even if no CWD is set.  My earlier conclusions on regarding the CWD
> were incorrect.
> I have not had a chance to try starting Xen from the bootmenu yet to try to
> reproduce the behavior Ian is seeing.
>
> Roy

Hi Ian,

I've had a chance to try using the bootmenu on both x86 (vmware), and
the FVP model,
and have reproduced your problems booting from the boot menu.
It works on x86, but not on ARM, and I suspect that this has to do
with differences in the
EDK2 "BDS" (boot device selection) code, and that something is not
being set up as expected
there.  Linaro (Leif) is working on using the Intel BDS for ARM, so I
don't think this is worth spending
much time on until the BDS unification is complete.

Roy
diff mbox

Patch

diff --git a/xen/arch/arm/arm64/cache.S b/xen/arch/arm/arm64/cache.S
index a445cbf..eff4e16 100644
--- a/xen/arch/arm/arm64/cache.S
+++ b/xen/arch/arm/arm64/cache.S
@@ -20,80 +20,33 @@ 
  */
 
 /*
- * Enable and disable interrupts.
+ * dcache_line_size - get the minimum D-cache line size from the CTR register.
  */
-	.macro	disable_irq
-	msr	daifset, #2
-	.endm
-
-	.macro	enable_irq
-	msr	daifclr, #2
-	.endm
-
-/*
- * Save/disable and restore interrupts.
- */
-	.macro	save_and_disable_irqs, olddaif
-	mrs	\olddaif, daif
-	disable_irq
-	.endm
-
-	.macro	restore_irqs, olddaif
-	msr	daif, \olddaif
+	.macro	dcache_line_size, reg, tmp
+	mrs	\tmp, ctr_el0			// read CTR
+	ubfm	\tmp, \tmp, #16, #19		// cache line size encoding
+	mov	\reg, #4			// bytes per word
+	lsl	\reg, \reg, \tmp		// actual cache line size
 	.endm
 
 /*
- *	__flush_dcache_all()
+ *	__flush_dcache_area(kaddr, size)
  *
- *	Flush the whole D-cache.
+ *	Ensure that the data held in the page kaddr is written back to the
+ *	page in question.
  *
- *	Corrupted registers: x0-x7, x9-x11
+ *	- kaddr   - kernel address
+ *	- size    - size in question
  */
-ENTRY(__flush_dcache_all)
-	dmb	sy				// ensure ordering with previous memory accesses
-	mrs	x0, clidr_el1			// read clidr
-	and	x3, x0, #0x7000000		// extract loc from clidr
-	lsr	x3, x3, #23			// left align loc bit field
-	cbz	x3, finished			// if loc is 0, then no need to clean
-	mov	x10, #0				// start clean at cache level 0
-loop1:
-	add	x2, x10, x10, lsr #1		// work out 3x current cache level
-	lsr	x1, x0, x2			// extract cache type bits from clidr
-	and	x1, x1, #7			// mask of the bits for current cache only
-	cmp	x1, #2				// see what cache we have at this level
-	b.lt	skip				// skip if no cache, or just i-cache
-	save_and_disable_irqs x9		// make CSSELR and CCSIDR access atomic
-	msr	csselr_el1, x10			// select current cache level in csselr
-	isb					// isb to sych the new cssr&csidr
-	mrs	x1, ccsidr_el1			// read the new ccsidr
-	restore_irqs x9
-	and	x2, x1, #7			// extract the length of the cache lines
-	add	x2, x2, #4			// add 4 (line length offset)
-	mov	x4, #0x3ff
-	and	x4, x4, x1, lsr #3		// find maximum number on the way size
-	clz	w5, w4				// find bit position of way size increment
-	mov	x7, #0x7fff
-	and	x7, x7, x1, lsr #13		// extract max number of the index size
-loop2:
-	mov	x9, x4				// create working copy of max way size
-loop3:
-	lsl	x6, x9, x5
-	orr	x11, x10, x6			// factor way and cache number into x11
-	lsl	x6, x7, x2
-	orr	x11, x11, x6			// factor index number into x11
-	dc	cisw, x11			// clean & invalidate by set/way
-	subs	x9, x9, #1			// decrement the way
-	b.ge	loop3
-	subs	x7, x7, #1			// decrement the index
-	b.ge	loop2
-skip:
-	add	x10, x10, #2			// increment cache number
-	cmp	x3, x10
-	b.gt	loop1
-finished:
-	mov	x10, #0				// swith back to cache level 0
-	msr	csselr_el1, x10			// select current cache level in csselr
+ENTRY(__flush_dcache_area)
+	dcache_line_size x2, x3
+	add	x1, x0, x1
+	sub	x3, x2, #1
+	bic	x0, x0, x3
+1:	dc	civac, x0			// clean & invalidate D line / unified line
+	add	x0, x0, x2
+	cmp	x0, x1
+	b.lo	1b
 	dsb	sy
-	isb
 	ret
-ENDPROC(__flush_dcache_all)
+ENDPROC(__flush_dcache_area)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 7650abe..9379dd1 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -736,20 +736,39 @@  ENTRY(lookup_processor_type)
         ret
 /*
  *  Function to transition from EFI loader in C, to Xen entry point.
- *  void noreturn efi_xen_start(void *fdt_ptr);
+ *  void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
  */
 ENTRY(efi_xen_start)
         /*
+         * Preserve x0 (fdt pointer) across call to __flush_dcache_area,
+         * restore for entry into Xen.
+         */
+        mov   x20, x0
+
+        /* flush dcache covering the FDT updated by EFI boot code */
+        bl    __flush_dcache_area
+
+        /*
+         * Flush dcache covering current runtime addresses
+         * of xen text/data. Then flush all of icache.
+         */
+        adrp  x1, _start
+        add   x1, x1, #:lo12:_start
+        mov   x0, x1
+        adrp  x2, _end
+        add   x2, x2, #:lo12:_end
+        sub   x1, x2, x1
+
+        bl    __flush_dcache_area
+        ic    ialluis
+        tlbi alle2
+
+        /*
          * Turn off cache and MMU as Xen expects. EFI enables them, but also
          * mandates a 1:1 (unity) VA->PA mapping, so we can turn off the
          * MMU while executing EFI code before entering Xen.
          * The EFI loader calls this to start Xen.
-         * Preserve x0 (fdf pointer) across call to __flush_dcache_all,
-         * restore for entry into Xen.
          */
-        mov   x20, x0
-        bl    __flush_dcache_all
-        ic    ialluis
 
         /* Turn off Dcache and MMU */
         mrs   x0, sctlr_el2
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 7abc059..d40d8b2 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -7,7 +7,7 @@ 
 #include <xen/libfdt/libfdt.h>
 #include <asm/setup.h>
 
-void noreturn efi_xen_start(void *fdt_ptr);
+void noreturn efi_xen_start(void *fdt_ptr, uint32_t fdt_size);
 
 #define DEVICE_TREE_GUID \
 {0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0}}
@@ -343,7 +343,7 @@  static void __init efi_arch_pre_exit_boot(void)
 
 static void __init efi_arch_post_exit_boot(void)
 {
-    efi_xen_start(fdt);
+    efi_xen_start(fdt, fdt_totalsize(fdt));
 }
 
 static void __init efi_arch_cfg_file_early(EFI_FILE_HANDLE dir_handle, char *section)