[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Stuck trying to boot Xen 4.3 on Arm Midway



On 02.12.2013 16:24, Ian Campbell wrote:
> On Mon, 2013-12-02 at 15:59 +0100, Stefan Bader wrote:
>> I am trying to extract and combine the various pieces of information found in
>> [1] and its sub-pages and the Xen in-tree documentation in order to make xen
>> boot (potentially non-smp without some later changes). But since I am not
>> familiar enough with Arm I think I am stuck doing something wrong.
>>
>> I compiled the hypervisor with debug and early printk for midway and use the
>> xen.bin file (I could get no output at all when trying to create a uboot 
>> image
>> with mkimage from the uncompressed xen.gz).
> 
> What version are you using? xen.bin went away in July, the right file is
> now just "xen".

The released version of xen 4.3. At some point I might update to 4.3.1 (or
whatever stable is current then). This probably implies picking some additional
patches when I want to get it running on Midway. The xen.bin would not be
packaged right now but it had the right format to be used by bootz while xen.gz
(or xen after unpacking) would not be usable in uboot without converting and
that need some more address values which I could and likely do get wrong.

> 
>> My uboot sequence looks like this:
>>
>> mw.l 800000 0 10000
>> scsi scan
>> ext2load scsi 0 0x800000 xen.bin
>> ext2load scsi 0 0x1000000 vmlinuz
>> setenv kernsize $filesize
>> ext2load scsi 0 0x2000000 initrd.img
>> setenv initsize $filesize
>> # Tried dtuart=/soc/serial@fff36000 as well without
>> setenv bootargs "sync_console console=dtuart dtuart=serial"
>> fdt addr 0x1000
>> fdt resize
>> fdt set /chosen bootargs \"$bootargs\"
>> fdt mknod /chosen modules
>> # Tried with <1> and <2> for both as I was not sure wnether those numbers
>> # are related to number of modules
> 
> No, they are the number of u32s which are used for the address and size
> in the reg field, which contains address then size.
> 
> So <2> for both would need "<0x0 0x100000 0x0 $kernsize>" or something.
> 

Ah ok, thanks for that clarification. So 1 is ok.

>> fdt set /chosen/modules \#address-cells <1>
>> fdt set /chosen/modules \#size-cells <1>
>> fdt mknod /chosen/modules module@0
>> fdt set /chosen/modules/module@0 compatible xen,linux-zimage 
>> xen,multiboot-module
>> fdt set /chosen/modules/module@0 reg <0x1000000 $kernsize>
>> fdt set /chosen/modules/module@0 bootargs "console=hvc0 debug"
>> fdt mknod /chosen/modules module@1
>> fdt set /chosen/modules/module@1 compatible "xen,linux-initrd"
>> "xen,multiboot-module"
>> fdt set /chosen/modules/module@1 reg <0x2000000 $initsize>
>> bootz 0x800000 - 0x1000
>>
>> The memory locations are somewhat random (the one for the xen.img is used for
>> the kernel on normal installs). The boot produces the following:
>>
>> ## Flattened Device Tree blob at 00001000
>>    Booting using the fdt blob at 0x00001000
>>    reserving fdt memory region: addr=0 size=1000
>>    reserving fdt memory region: addr=1000 size=2000
>>    Using Device Tree in place at 00001000, end 00005fff
>>
>> Starting kernel ...
>>
>> - UART enabled -
>> - CPU 00000000 booting -
>> - Machine ID 00000000 -
>> - Started in Hyp mode -
>> - Zero BSS -
>> - Setting up control registers -
>> - Turning on paging -
>> - Ready -
>> RAM: 0000000000000000 - 00000000ff7fffff
>> RAM: 0000000200000000 - 00000002ffffffff
>>
>> MODULE[1]: 0000000001000000 - 0000000001471ae0 console=hvc0 debug
>> MODULE[2]: 0000000002000000 - 000000000223f08b
>> Placing Xen at 0x00000002ffe00000-0x0000000300000000
>> WARNING: Only using first bank of memory
>> Xen heap: 262144 pages  Dom heap: 784384 pages
>>
>> After that nothing. Maybe I am doing the bootargs wrong. I tried
>> xen,xen-bootargs and xen,dom0-bootargs and combinations without success. 
>> Maybe
>> the console argument is wrong. Although the full dtb path at least shows up 
>> as
>> that in a booted linux in /proc. What am I doing wrong here?
> 
> Your dtuart appears to be wrong, this is the point at which it would
> normally be expected to start with the proper (rather than early)
> console stuff.
> 
> The correct thing to use depends a bit on which version you are running,
> but if it is not recent xen.git master or staging then that's your first
> mistake ;-)

The one we (Ubuntu) shipped of course. And that's no mistake. :)

> 
> dtuart=/soc/serial@fff36000 is what I use. I've also attached my u-boot
> script. (my local scripts append -arm32 to the binary name, it is the
> "xen" file though)

Thanks, I will look through that later. One thin I noted is the dtb setup.
Examples out there often vary in having a modules sub-leaf or not. I would think
that from the early printk I am at least right to use the deeper nesting. At
least consistent with the in-source doc at that time/ release.
> 
> Ian.
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.