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

Re: [Xen-users] Fw: booting



On Thu, 2014-02-06 at 18:35 +0800, IAN DELANEY wrote:
[...]

I've put the list CC back on the assumption that you were again caught
out by the lack of a reply-to on these lists.

> 1. I shall try to drop off the xen hypervisor and just boot the 3.13-rc4
> kernel as you suggest.  Currently it appears to boot, but the output
> isn't making it to the monitor in the sunxi-next kernel.  It's a
> console tty thingy or something.

When you say "monitor" do you mean the VGA/HDMI output? I've never used
that -- all my experience is with the serial console for which
"console=ttyS0,115200" on the kernel command line is sufficient IME.

I'm not sure of the GFX stuff is supported by mainstream kernels or not.

> 2. The fellow gentoo dev is still giving the occasional tip.  Between
> the 2 of you, I should 'get there'.  He has given me a second boot.cmd
> for the second kernel. As I said, by rights  HE as the arm expert
> ought acquire and boot it especially since the 3.4 is now old, however
> he works from home (remotely like many seem to these days) plus does
> gentoo.  I can't tread on his toes and say stay there and boot this
> thing.  He's a volunteer like me.  I shall next try tweaking it on the
> newer kernel though I think it prudent to keep to the zImage / bootz.
> The uImage and zImage appear to be too far apart from one another and
> aren't interchangeable.

Right. 

bootz == zImage
bootm == uImage (which in turn is a wrapper around zImage)

uImage is a uboot specific thing and IMHO is "legacy", zImage is a
standard Linux thing and bootz is what should be used these days (all
IMHO).

> 3. Can you double check this for me?
> # Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
> bootz ${xen_addr_r} - ${fdt_addr}
> 
> My limited understanding makes me think it ought be
> bootz ${kernel_addr_r} - ${fdt_addr}

Is this in the context of booting Xen or Linux?

If you want to boot Xen then "bootz ${xen_addr_r}..." is correct, and
${kernel_addr_r} should be put in the /chosen/module@0 reg DTB property.

If you want to boot Linux directly without Xen then "bootz
${kernel_addr_r} ..." is correct.

Or more generally the first argument to bootz should be the address of
the thing you would like to boot.

If you want to boot Linux direct then the various *_addr_r given on the
Xen wiki page may not work, since Linux is a bit more picky about load
addresses not being too high up (they need to be below 128MB from the
start of RAM IIRC, RAM starts at 0x40000000 (AKA 1GB) on these
platforms). For booting Linux I use:
        setenv fdt_addr      0x43000000
        setenv kernel_addr_r 0x47000000
        setenv ramdisk_addr_r 0x48000000
        setenv fdt_high      0xffffffff # Load fdt in place instead of 
relocating
        setenv initrd_high   0xffffffff

(the last two stop u-boot relocating those things to stupid broken
addresses, which Linux cannot cope with)

> since xen_addr_r appears to be dealt with 
> 
> # Load xen/xen to ${xen_addr_r}

Note that this comment is supposed to be a placeholder for calling
something to perform the load, via tftp, fat etc etc, as described in
the next few sections. But I can see now how confusing that is
(especially without whitespace between it and the following setenv) so I
think I'll add "e.g. tftp or fatload etc, see below" or something to
each of these.

> setenv bootargs "console=dtuart dtuart=/soc@01c00000/serial@01c28000
> dom0_mem=128M"
> 
> though this is merely an assignment of the bootargs var if I read
> correctly.

Correct. This will be propagated by u-boot to the dtb /chosen/bootargs
property as part of boot[mz], from where it will be consumed by either
Xen or the kernel, depending on which one you called into.

> Is;   ${xen_addr_r} - ${fdt_addr} 
> saying from this address to that address as in a range?
> I think ${xen_addr_r} is arg1. the '-' arg2. correct?

'-' is arg2, which is the address of the initial ramdisk, - means
"none", it's there as a placeholder so you can give the fdt as the arg3.

If you do want an initrd then with bootz you need to give the initrd
size here too, which means that you need to load the initrd last so that
${filesize} (which *load set) is correct then do:
        bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}

(or if booting Xen, "bootz ${xen_addr_r} ${ramdisk.......")

> I find it difficult to fathom you got xen_addr_r mixed up with
> kernel_addr_r so it's more likely my lack og current understanding.

The instance of bootz on
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Allwinner looks 
correct to me, did you spot another one which you think might be wrong? It's 
also possible I misspoke somewhere in this email thread.

BTW, you are welcome on #xenarm on freenode, although TBH with the
timezone difference email might be better.

Ian.


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


 


Rackspace

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