Xen Dom0 Boot Stucked in ***LOADING DOMAIN 0*** (on Orange Pi PC 2)

[cr33d...@gmail.com]

Hi Everyone!,

During my process of get Xen running on the Orange Pi PC 2, i run into a deadlock (in case of my knowledge).
 
Normally:

- Build Xen -> put on sd card
- Modify Boot.scr
- Boot Xen (without anything)
- Build Dom0 -> put on sd card
- Boot Xen which then boots Dom0

However, in my Case i try to boot Dom0 without any kind of success.

What i've tried so far:

- Rebuild/Reconfigure Xen
- Rebuild/Reconfigure Dom0
- Rename binarys/Images
- and various combinations of those

If someone has got any suggestions on whats going wrong here, or what might be missing, please let me know.
I hope i got all necessary information in the APPENDIX below. If not, i will provide it by request.

Thanks,
Jonny

#=======APPENDIX=======#

XEN Version: xen-4.11 unstable (from xenbits.xen.org)
Dom0: Armbian (linux -mainline 4.14y from https://github.com/armian/build)
Boot.scr (params) :
______________________________________________________________

# DO NOT EDIT THIS FILE
#
# Please edit /boot/armbianEnv.txt to set supported parameters
#

# default values
setenv kernel_addr_r "0x50000000"
setenv load_addr "0x45000000"
setenv fdt_addr_r "0x46000000"
setenv xenaddr    "0x48000000"
setenv ramdisk_addr_r "0x4E000000"

...

#setenv xen_bootargs "loglvl=all console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M iommu=true"
setenv xen_bootargs "console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M"
setenv dom0_bootargs "console=hvc0 root=/dev/mmcblk0p1 clk_ignore_unused"

...

load ${devtype} 0 ${ramdisk_addr_r} ${prefix}uInitrd
setenv ramdisk_size 0x${filesize}
load ${devtype} 0 ${kernel_addr_r} ${prefix}Image
setenv kernel_size 0x${filesize}
load ${devtype} 0 ${xenaddr} ${prefix}xen-4.11

fdt chosen

fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt set /chosen xen,xen-bootargs \"${xen_bootargs}\"
fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
fdt set /chosen linux,initrd-start <${ramdisk_addr_r}>
fdt set /chosen linux,initrd-end <0x4E500000>
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <${kernel_addr_r} ${kernel_size}>

#booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

#booti ${kernel_addr_r} - ${fdt_addr_r}

booti ${xenaddr} - ${fdt_addr_r}

# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
______________________________________________________________

Output:(UART Serial 115200)
--------------------------------------------------------------
U-Boot 2017.11-armbian (Jan 30 2018 - 17:36:47 +0100) Allwinner Technology

CPU: Allwinner H5 (SUN50I)
Model: OrangePi PC 2
DRAM: 1 GiB
MMC: SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment
...
U-boot loaded from SD
Boot script loaded from mmc
165 bytes read in 163 ms (1000 Bytes/s)
29826 bytes read in 428 ms (67.4 KiB/s)
4179 bytes read in 426 ms (8.8 KiB/s)
Applying kernel provided DT fixup script (sun50i-h5-fixup.scr)
## Executing script at 45000000
5428313 bytes read in 563 ms (9.2 MiB/s)
## load dom0 linux kernel ("Image")
20118016 bytes read in 1095 ms (17.5 MiB/s)
## Load xen binary ("xen-4.11")
852304 bytes read in 253 ms (3.2 MiB/s)
Image lacks image_size field, assuming 16MiB
## Flattened Device Tree blob at 46000000
 Booting using the fdt blob at 0x46000000
 reserving fdt memory region: addr=46000000 size=6d000
 Loading Device Tree to 0000000049f90000, end 0000000049ffffff ... OK
...
Starting kernel ...

- UART enabled -
- CPU 00000000 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) Initrd 000000004e000000-000000004e500000
(XEN) RAM: 0000000040000000 - 000000007fffffff
(XEN) 
(XEN) MODULE[0]: 0000000049f90000 - 0000000049f98000 Device Tree 
(XEN) MODULE[1]: 000000004e000000 - 000000004e500000 Ramdisk 
(XEN) MODULE[2]: 0000000050000000 - 000000005132fa00 Kernel 
(XEN) RESVD[0]: 0000000046000000 - 000000004606d000
(XEN) RESVD[1]: 0000000049f90000 - 0000000049f98000
(XEN) 
(XEN) Command line: loglvl=all console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M
(XEN) Placing Xen at 0x000000007fe00000-0x0000000080000000
(XEN) Update BOOTMOD_XEN from 0000000040080000-000000004019ad81 => 000000007fe00000-000000007ff1ad81
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: Allwinner ARMv8
(XEN) Looking for dtuart at "/soc/serial@01c28000", options ""
(XEN) Automatic baud rate determination was requested, but a baud rate was not set up
 Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (build-one@) (aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609) debug=y Tue Feb 27 17:04:21 CET 2018
(XEN) Latest ChangeSet: Fri Feb 23 14:25:54 2018 +0100 git:a823a52
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN) Processor Features: 0000000000002222 0000000000000000
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN) Debug Features: 0000000010305106 0000000000000000
(XEN) Auxiliary Features: 0000000000000000 0000000000000000
(XEN) Memory Model Features: 0000000000001122 0000000000000000
(XEN) ISA Features: 0000000000011120 0000000000000000
(XEN) 32-bit Execution:
(XEN) Processor Features: 00000131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 03010066
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10201105 40000000 01260000 02102211
(XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using PSCI-0.2 for SMP bringup
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 24000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=0000000001c81000
(XEN) gic_cpu_addr=0000000001c82000
(XEN) gic_hyp_addr=0000000001c84000
(XEN) gic_vcpu_addr=0000000001c86000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 224 lines, 4 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 32 KiB.
(XEN) Bringing up CPU1

...

(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) I/O virtualisation disabled
(XEN) build-id: 8539192c192bf97346d61bbb1a982566f5935f2b
(XEN) alternatives: Patching with alt table 00000000400bcf50 -> 00000000400bd430
(XEN) grant_table.c:1680:IDLEv0 Expanding d0 grant table from 0 to 1 frames
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0000000050000000
(XEN) Loading ramdisk from boot module @ 000000004e000000
(XEN) Allocating 1:1 mappings totalling 256MB for dom0:
(XEN) BANK[0] 0x00000060000000-0x00000070000000 (256MB)
(XEN) Grant table range: 0x0000007fe00000-0x0000007fe40000
(XEN) Loading zImage from 0000000050000000 to 0000000060080000-00000000613afa00
(XEN) Loading dom0 initrd from 000000004e000000 to 0x0000000068200000-0x0000000068700000
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x0000000068000000-0x00000000680070ae
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) ..done.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 276kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER20
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER24
(XEN) d0v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0
(XEN) vsysreg.c:211:d0v0 msr 2, 3, c0, c5, 0 <= x2 @ 0xffffff8008ec81e0
(XEN) vsysreg.c:213:d0v0 unhandled 64-bit sysreg access 0x20c00a

--------------------------------------------------------------
=> Stucked here.

[André Przywara]

On 25/03/18 18:41, cr33d...@gmail.com wrote:
> Hi Everyone!,
>
> During my process of get Xen running on the Orange Pi PC 2, i run into a
> deadlock (in case of my knowledge).

I guess you just don't see any output, really.
What is your kernel config? Did you enable the Xen options?
Check for CONFIG_HVC_XEN=y and CONFIG_XEN_DOM0=y, for a start.
make defconfig should have everything on arm64.

Where do those load addresses come from? Please don't try to redefine
them (or is that from Armbian?), unless you know what you do.
At least I would load Xen at the same place the kernel gets loaded
normally. Also I tend to load the Dom0 kernel at $ramdisk_addr_r and
avoid an initrd. But you can load one, just make sure you don't
overwrite anything.

Here is what works for me on the OrangePi PC2:

=> setenv xen_addr_r $kernel_addr_r
=> setenv kernel_addr_r $ramdisk_addr_r
=> setenv ramdisk_addr_r 0x58000000
=> dhcp
=> tftpboot $xen_addr_r xen-arm64-4.11-pre
=> tftpboot $kernel_addr_r Image-4.16-rc5
=> setenv kernel_size 0x${filesize}
=> tftpboot $ramdisk_addr_r debian-inst.img
=> tftpboot $fdt_addr_r $fdtfile
=> fdt addr $fdt_addr_r
=> fdt resize
=> setenv xen_bootargs "console=dtuart dtuart=/soc/serial@1c28000
dom0_mem=256M"
=> setenv dom0_bootargs "console=hvc0 root=/dev/mmcblk0p2 clk_ignore_unused"
=> fdt set /chosen \#address-cells <1>
=> fdt set /chosen \#size-cells <1>
=> fdt set /chosen xen,xen-bootargs \"${xen_bootargs}\"
=> fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
=> fdt set /chosen linux,initrd-start <$ramdisk_addr_r>
=> fdt set /chosen linux,initrd-end <0x5c000000>
=> fdt mknod /chosen module@0
=> fdt set /chosen/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
=> fdt set /chosen/module@0 reg <${kernel_addr_r} ${kernel_size}>
=> booti ${xen_addr_r} - ${fdt_addr_r}

Kernel is a defconfig one, Xen also normally compiled.
Boots for me into the Dom0 prompt (if you have hvc0 configured as a
console).

> #setenv xen_bootargs "loglvl=all console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M iommu=true"
> setenv xen_bootargs "console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M"

Newer DTs don't have the leading 0 in the serial address anymore. Not
sure that matters, as you seem to get output from Xen, though.

> setenv dom0_bootargs "console=hvc0 root=/dev/mmcblk0p1 clk_ignore_unused"
>
> ...
>
> load ${devtype} 0 ${ramdisk_addr_r} ${prefix}uInitrd

Have you tried loading a non U-Boot image initrd (no leading "u")? I use
raw initrds, normally. For bare metal boots this requires to give the
size after a colon:
=> booti $kernel_addr_r $ramdisk_addr_r:0x$filesize $fdt_addr_r
Not sure if Xen can deal with U-Boot packaged initrds, so loading a raw
initrd might help. But the kernel should complain in either case.

> setenv ramdisk_size 0x${filesize}
> load ${devtype} 0 ${kernel_addr_r} ${prefix}Image
> setenv kernel_size 0x${filesize}
> load ${devtype} 0 ${xenaddr} ${prefix}xen-4.11
>
> fdt chosen
>
> fdt set /chosen \#address-cells <1>
> fdt set /chosen \#size-cells <1>
> fdt set /chosen xen,xen-bootargs \"${xen_bootargs}\"
> fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
> fdt set /chosen linux,initrd-start <${ramdisk_addr_r}>
> fdt set /chosen linux,initrd-end <0x4E500000>

So this limits your initrd to 5MiB, but your particular one (see below)
is bigger. Not sure how picky Xen actually is in this regard, though.
You can be rather generous here, it shouldn't hurt to give a much bigger
value.

^^^^^^^ > 5MiB.

Cheers,
Andre.

> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to linux-sunxi...@googlegroups.com
> <mailto:linux-sunxi...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[cr33d...@gmail.com]

First of all thank you for your fast reply!

Am Montag, 26. März 2018 01:24:44 UTC+2 schrieb André Przywara:

On 25/03/18 18:41, cr33d...@gmail.com wrote:
> Hi Everyone!,
>
> During my process of get Xen running on the Orange Pi PC 2, i run into a
> deadlock (in case of my knowledge).

I guess you just don't see any output, really.
What is your kernel config? Did you enable the Xen options?
Check for CONFIG_HVC_XEN=y and CONFIG_XEN_DOM0=y, for a start.
make defconfig should have everything on arm64.

 

 So Andre, What i did was the following:

• I cloned the armbian/build  & do ./compile.sh
• During compilation, i selected the orange pi pc 2 and the configuration while compilation option
• I went through the config and enabled all needed options including the HVC. The Dom0 option did not appear in that state.
• I saved the config, ended the compilation and found my xen.config file in: ../linux-mainline/linux-4.14y/kernel/config/xen.config
• I manually set the dom0 option to =y
  
• I go back to linux-4.14y and execute: sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
  
• Then i ended up with the image in the folder ../linux-4.14y/arch/arm64/Image

So - nothing with an defconfig (not sure if i missed s.th. though)

These Addresses where provided by this Blog http://vadion.com/getting-started-with-xen-hypervisor-on-orangepi-pc2-allwinner-h5/

Would you send me your boot.cmd that i can test if this would work?
Actually im not sure what the memory addresses depend on.
Which linux image did you use as initial base, before implement xen binary to the kernel?
 

Kernel is a defconfig one, Xen also normally compiled.
Boots for me into the Dom0 prompt (if you have hvc0 configured as a
console).

So you did s.th. like: ?
cd linux
make ARCH=arm64 defconfig
cp <path to config file>/linux-sun50i-dev.config .config

 

> #setenv xen_bootargs "loglvl=all console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M iommu=true"
> setenv xen_bootargs "console=dtuart dtuart=/soc/serial@01c28000 dom0_mem=256M"

Newer DTs don't have the leading 0 in the serial address anymore. Not
sure that matters, as you seem to get output from Xen, though.

> setenv dom0_bootargs "console=hvc0 root=/dev/mmcblk0p1 clk_ignore_unused"
>
> ...
>
> load ${devtype} 0 ${ramdisk_addr_r} ${prefix}uInitrd

Have you tried loading a non U-Boot image initrd (no leading "u")? I use
raw initrds, normally. For bare metal boots this requires to give the
size after a colon:
=> booti $kernel_addr_r $ramdisk_addr_r:0x$filesize $fdt_addr_r
Not sure if Xen can deal with U-Boot packaged initrds, so loading a raw
initrd might help. But the kernel should complain in either case.

No - didn't tried that. Always thought u-boot where the only opportunity to boot xen and dom0.
Do i achieve this, by simply remove the u in the boot.scr?

 

> setenv ramdisk_size 0x${filesize}
> load ${devtype} 0 ${kernel_addr_r} ${prefix}Image
> setenv kernel_size 0x${filesize}
> load ${devtype} 0 ${xenaddr} ${prefix}xen-4.11
>
> fdt chosen
>
> fdt set /chosen \#address-cells <1>
> fdt set /chosen \#size-cells <1>
> fdt set /chosen xen,xen-bootargs \"${xen_bootargs}\"
> fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
> fdt set /chosen linux,initrd-start <${ramdisk_addr_r}>
> fdt set /chosen linux,initrd-end <0x4E500000>

So this limits your initrd to 5MiB, but your particular one (see below)
is bigger. Not sure how picky Xen actually is in this regard, though.
You can be rather generous here, it shouldn't hurt to give a much bigger
value.

Would i achieve this by set an higher initrd-end? like 0x4EA00000
 

Unfortunately im fairly new to this topic so some questions might seem to be a little bit dump.

Thanks,
Jonny

> <mailto:linux-sunxi+unsub...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

> <mailto:linux-sunxi+unsub...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

> <mailto:linux-sunxi+unsub...@googlegroups.com>.

[Andre Przywara]

Hi,

On 28/03/18 10:08, cr33d...@gmail.com wrote:
> First of all thank you for your fast reply!
>
> Am Montag, 26. März 2018 01:24:44 UTC+2 schrieb André Przywara:
>

> On 25/03/18 18:41, cr33d...@gmail.com <javascript:> wrote:
> > Hi Everyone!,
> >
> > During my process of get Xen running on the Orange Pi PC 2, i run
> into a
> > deadlock (in case of my knowledge).
>
> I guess you just don't see any output, really.
> What is your kernel config? Did you enable the Xen options?
> Check for CONFIG_HVC_XEN=y and CONFIG_XEN_DOM0=y, for a start.
> make defconfig should have everything on arm64.
>
>  
>  So Andre, What i did was the following:
>

> * I cloned the armbian/build  & do ./compile.sh
> * During compilation, i selected the orange pi pc 2 and the
> configuration while compilation option
> * I went through the config and enabled all needed options including

> the HVC. The Dom0 option did not appear in that state.

> * I saved the config, ended the compilation and found my xen.config
> file in: ../linux-mainline/linux-4.14y/kernel/config/xen.config
> * I manually set the dom0 option to =y
> * I go back to linux-4.14y and execute: sudo make ARCH=arm64
> CROSS_COMPILE=aarch64-linux-gnu-
> * Then i ended up with the image in the folder

> ../linux-4.14y/arch/arm64/Image
>
> So - nothing with an defconfig (not sure if i missed s.th. though)

Well, this is the Armbian way of doing things, which mixes up several
steps and hides a lot of complexity, at the cost of loosing flexibility.
If you want to break it down, you could just compile the firmware yourself:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64
or pick an image I provided for convenience here:
https://github.com/apritzel/pine64/raw/master/images/orangepi-pc2_firmware-20180316.img.xz
This one comes with a proper .dtb included, just use $fdtcontroladdr
instead of loading a .dtb.

defconfig was referring to the kernel compile, see below.

> > Normally:
> > - Build Xen -> put on sd card
> > - Modify Boot.scr
> > - Boot Xen (without anything)
> > - Build Dom0 -> put on sd card
> > - Boot Xen which then boots Dom0
> >
> > However, in my Case i try to boot Dom0 without any kind of success.
> >
> > What i've tried so far:
> >
> > - Rebuild/Reconfigure Xen
> > - Rebuild/Reconfigure Dom0
> > - Rename binarys/Images
> > - and various combinations of those
> >
> > If someone has got any suggestions on whats going wrong here, or what
> > might be missing, please let me know.
> > I hope i got all necessary information in the APPENDIX below. If
> not, i
> > will provide it by request.
> >
> > Thanks,
> > Jonny
> >
> > #=======APPENDIX=======#
> >
> > XEN Version: xen-4.11 unstable (from xenbits.xen.org

> <http://xenbits.xen.org>)

> > Dom0: Armbian (linux -mainline 4.14y from

> https://github.com/armian/build <https://github.com/armian/build>)

> > Boot.scr (params) :
> > ______________________________________________________________
> >
> > # DO NOT EDIT THIS FILE
> > #
> > # Please edit /boot/armbianEnv.txt to set supported parameters
> > #
> >
> > # default values
> > setenv kernel_addr_r "0x50000000"
> > setenv load_addr "0x45000000"
> > setenv fdt_addr_r "0x46000000"
> > setenv xenaddr    "0x48000000"
> > setenv ramdisk_addr_r "0x4E000000"
>
> Where do those load addresses come from? Please don't try to redefine
> them (or is that from Armbian?), unless you know what you do.
> At least I would load Xen at the same place the kernel gets loaded
> normally. Also I tend to load the Dom0 kernel at $ramdisk_addr_r and
> avoid an initrd. But you can load one, just make sure you don't
> overwrite anything.
>
>
> These Addresses where provided by this Blog
> http://vadion.com/getting-started-with-xen-hypervisor-on-orangepi-pc2-allwinner-h5/

I see. In general we spent some time in working out reasonable standard
load addresses, which comply with all requirements and don't overlap:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=671f9ad8aa61

Well, that's basically the file. Just paste this into an editor and
remove the prompts. But you need to adjust this to your file names and
ways of loading it anyway.

> Actually im not sure what the memory addresses depend on.
> Which linux image did you use as initial base, before implement xen
> binary to the kernel?

I am not sure what you mean with "implement xen binary to the kernel",
but as mentioned before the kernel was mainline with defconfig, see below.

> Kernel is a defconfig one, Xen also normally compiled.
> Boots for me into the Dom0 prompt (if you have hvc0 configured as a
> console).
>
> So you did s.th. like: ?
> cd linux
> make ARCH=arm64 defconfig
> cp <path to config file>/linux-sun50i-dev.config .config

What is this last line about? "make defconfig" puts the default
configuration settings into .config already.

So I do:
$ export ARCH=arm64
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make defconfig
$ make -j8 -s Image

> > #setenv xen_bootargs "loglvl=all console=dtuart
> dtuart=/soc/serial@01c28000 dom0_mem=256M iommu=true"
> > setenv xen_bootargs "console=dtuart dtuart=/soc/serial@01c28000
> dom0_mem=256M"
>
> Newer DTs don't have the leading 0 in the serial address anymore. Not
> sure that matters, as you seem to get output from Xen, though.
>
> > setenv dom0_bootargs "console=hvc0 root=/dev/mmcblk0p1
> clk_ignore_unused"
> >
> > ...
> >
> > load ${devtype} 0 ${ramdisk_addr_r} ${prefix}uInitrd
>
> Have you tried loading a non U-Boot image initrd (no leading "u")? I
> use
> raw initrds, normally. For bare metal boots this requires to give the
> size after a colon:
> => booti $kernel_addr_r $ramdisk_addr_r:0x$filesize $fdt_addr_r
> Not sure if Xen can deal with U-Boot packaged initrds, so loading a raw
> initrd might help. But the kernel should complain in either case.
>
> No - didn't tried that. Always thought u-boot where the only opportunity
> to boot xen and dom0.

It is, more or less, but you don't necessarily need to wrap initrds as
U-Boot *image files*.

> Do i achieve this, by simply remove the u in the boot.scr?

The "u" prefix indicates that this file has a U-Boot header prepended,
which tells U-Boot the size and load address, mostly:
https://www.denx.de/wiki/DULG/UBootImages

You can remove this header by removing the first 64 bytes:
$ dd if=uInitrd bs=64 skip=1 of=Initrd

> > setenv ramdisk_size 0x${filesize}
> > load ${devtype} 0 ${kernel_addr_r} ${prefix}Image
> > setenv kernel_size 0x${filesize}
> > load ${devtype} 0 ${xenaddr} ${prefix}xen-4.11
> >
> > fdt chosen
> >
> > fdt set /chosen \#address-cells <1>
> > fdt set /chosen \#size-cells <1>
> > fdt set /chosen xen,xen-bootargs \"${xen_bootargs}\"
> > fdt set /chosen xen,dom0-bootargs \"${dom0_bootargs}\"
> > fdt set /chosen linux,initrd-start <${ramdisk_addr_r}>
> > fdt set /chosen linux,initrd-end <0x4E500000>
>
> So this limits your initrd to 5MiB, but your particular one (see below)
> is bigger. Not sure how picky Xen actually is in this regard, though.
> You can be rather generous here, it shouldn't hurt to give a much
> bigger
> value.
>
> Would i achieve this by set an higher initrd-end? like 0x4EA00000

Well, this is where it gets hairy, as you have to make sure you don't
end up overwriting something else. That's why using the default
addresses is mostly a better idea.
But in this case it should work, yes.

Cheers,
Andre.

> > an email to linux-sunxi...@googlegroups.com <javascript:>
> > <mailto:linux-sunxi...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> Am Montag, 26. März 2018 01:24:44 UTC+2 schrieb André Przywara:
>

> <http://xenbits.xen.org>)

> > Dom0: Armbian (linux -mainline 4.14y from

> https://github.com/armian/build <https://github.com/armian/build>)

> > an email to linux-sunxi...@googlegroups.com <javascript:>
> > <mailto:linux-sunxi...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> Am Montag, 26. März 2018 01:24:44 UTC+2 schrieb André Przywara:
>

> <http://xenbits.xen.org>)

> > Dom0: Armbian (linux -mainline 4.14y from

> https://github.com/armian/build <https://github.com/armian/build>)

> > an email to linux-sunxi...@googlegroups.com <javascript:>
> > <mailto:linux-sunxi...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to linux-sunxi...@googlegroups.com

> <mailto:linux-sunxi...@googlegroups.com>.