Re: [Xen-users] Fw: booting

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-02-05 at 11:35 +0800, IAN DELANEY wrote:
> On Tue, 4 Feb 2014 15:16:12 +0000
> Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Tue, 2014-02-04 at 12:50 +0800, IAN DELANEY wrote:
> > 
> > I'm afraid that Xen on ARM is not yet aimed at the total newbie on
> > ARM.
> > 
> 
> Well, pity that.  My aim here is to attempt to do what has been made
> doable according to what I understand.   The release of xen-4.3 over 6
> months ago declared xen arm capable and equipped.

I think there may have been some miscommunication here -- Xen 4.3 had a
tech preview of ARM support which was limited to a quite small number of
platforms. It was described as "Early support" in the release notes and
as "tech preview" in the feature matrix. It's quite likely that that
messaging didn't make it to everywhere it should have done though.

Xen 4.4 (of which we've just had rc3) will introduce "proper" support
for ARM, although I still don't think I would say it would be for a
total newbie.

Are you still trying to use 4.3? Getting Xen 4.3 running even on the
platforms it supported involved a lot more hacking that with the
4.4-rcs, we've been removing references to those old hacks from the docs
since it made things even more confusing even than they are now, but of
course if you are trying to use 4.3 that just makes things worse for
you.

> [...] I love a challenge!

I think that's probably lucky ...

> > I appreciate that things are not as clear as they might be, I'm sorry
> > but at this stage I think it is not unreasonable to expect that people
> > try Xen on ARM are already somewhat familiar with Linux on ARM, which
> > means u-boot and some of the terms used here.  
> > 
> 
> > I have no idea what you've done here but Linux 3.4 just won't work
> > with Xen on ARM.
> > 
> 
> 1.  u-boot I gather is very low level and appears to require a
> significant climb of the learning curve to even begin to use it. 

Agreed.

It looks like 64-bit ARM servers will mostly be using UEFI, and even
grub so they will have a much more "x86-like" experience. It's unlikely
that this will happen for 32-bit ARM too though, and for embedded 64-bit
ARM it seems likely that u-boot will still be used by at least some
vendors.

> 2.  The 3.4-75 kernel is the one utilised by sunxi in the link in the
> wiki page(s).  The booting into the uImage of 3.4-75 is merely the
> u-boot booting process gone awry.  The zImage of the 3.13 was there
> and it was  seemingly missed.  The point is that the boot.xen ->
> boot.scr I edited from the wiki / prepared were ineffective.  But let's
> move past that one state, move on.2

I'll add a note that the sunxi kernel is not usable with Xen.

> 3.  The gentoo dev of the minor arch arm team has used only the
> specially equipped sunxi 3.4-75 kernel to boot the CB2.  Beyond that,
> he appears too occupied to take the next step and get it to boot off the
> xen equipped capable and adequately arm equipped sunxi 3.13-rc4 kernel. 
> Although he does provide the odd tip, he basically cut me loose by
> tapping out somethink like "that (booting xen) is way out of what my
> territory, you're on your own in irc.
> Pity that 
> 
> 4.  The technical point that appears to be tripping me appears to be
> the nominating of the load address of the kernel.  The 3.4 kernel that
> I boot uses fatload (the boot partition is vfat), a uImage and a
> bootm. 

fatload vs ext2load etc should be a pretty straight substitution
depending on the filesystem in use.

uImage is a u-boot specific wrapper for binaries. It includes in the
header a load address, on boot (with bootm) uboot will relocate the
image from wherever you loaded it with fatload to that address.

You could create a uImage of Xen, perhaps even giving it the same load
address as you are giving fatload (to make the reloc a nop) using the
"mkimage" tool but TBH there is no real reason to do this, you can just
use "bootz" with the raw Xen binary instead.

> 5. The boot.cmd I have to boot goes from a 4 line script to a boot.xen
> that switches everything.  uImage is out, bootm is out. In, we have
> zImage (never heard of it), bootz (ditto)

bootz is the command for booting Linux zImage format kernels, as opposed
to booting uboot images with bootm.

he Xen binary is compatible with this format, which is defined in the
booting.txt doc from the Linux source (referenced in the wiki I think).

> and a whole new scripting set (u-boot boot.cmd/boot.xen)

The script name/suffix doesn't matter, it's all just lists of u-boot
commands, which are executed with the "source" command.

> > I'm sorry
> > but at this stage I think it is not unreasonable to expect that people
> > try Xen on ARM are already somewhat familiar with Linux on ARM,
> 
> I have a better knowledge of arm than a fortnight ago, however, I'm
> sorry but all of the above make for a horrendously steep learning
> curve.  On the plus side, your tips provided already have already made
> some progress towards reducing its incline. 

Good.

> > > "This assumes that the kernel is <4MB, "
> > > 
> > > leaves me in the lurch because the zImage comes up over 4 mb. and I
> > > am not versed in hex maths so as to convert all these addresses,
> > > which leaves me vulnerable to making wrong data.
> > 
> > gnome-calculator speaks hex, as do many other tools.
> > 
> 
> I'll find one I think, though I don't use gnome

4mb doesn't seem so unreasonable for a kernel, but there seems to be no
harm in adjusting the defaults to, say, 8mb -- so I'll do that.

I'll also add in $ramdisk_addr_r since it will be clearer for those who
need it and the hole left if not is harmless.

> > > "console=hvc0 ro root=/dev/sda1 "
> > > 
> > > does this pertain to a usb boot?  Mine is actually from an SDHC
> > > card, once again making for uncertainty.
> > 
> > It can be whatever you would use to boot natively on this platform. I
> > suspect that means /dev/mmcblkN but I haven't been booting from that
> > so I don't know.
> > 
> 
> Yes; the (1st.) line for the boot.cmd that I have to boot the sunxi 3.4
> kernel is " setenv bootargs console=ttyS0,115200 root=/dev/mmcblk0p2
> rootwait panic=10 ${extra}"

That looks about right.

On boot with a dtb u-boot will propagate this to the device
tree's /chosen/bootargs property for you automatically.

You can also force this to happen sooner with "fdt chosen" -- which is
handy because then "fdt print" can be used to inspect what is going on.

The above is right for booting Linux but to boot Xen you would want the
Xen command line here and the Linux command line
in /chosen/module@0/bootargs (i.e. the dom0 kernel's bootargs, see
docs/misc/arm/device-tree/booting.txt for where the various command
lines can live).

For the dom0 command line you'll want to s/ttyS0,115200/hvc0/ and to add
"clk_ignore_unused" (wiki updated).

> > >  Parameters for the domain 0 kernel are passed using the
> > >  xen,dom0-bootargs
> > 
> > I don't see any reference to dom0-bootargs on the allwinner page.

FYI I spotted it later in the main page and cleaned that up too.

> > it is ready for interested devs to use.
> 
> Well, I'm a dev and I'm interested.  From what you say though I just
> get the impression that my attempts might be a touch premature. I'm
> reluctant to capitulate though.

I think it is doable for a dev who is already familiar with ARM/uboot
but coming in cold from an x86 background is a bit like jumping in at
the deep end. I'm glad you've chosen to stick at it though.

>   I can see it's doable and I'm just
> tryin' to do it.   In summary; xen is a monster package, building and
> equipping kernels is a heavy weight task, the arm (or any) arch is a
> broad and technically challenging field to take on, ditto u-boot.  And
> you can do them all.   Thumbs up.

FWIW I would strongly recommend getting a mainline kernel (probably the
sunxi-{next,devel} branch not actual mainline) booting natively (i.e.
without Xen) before trying to get Xen going -- that should at least cut
the learning curve into a few shorter chunks.

The sunxi 3.4 kernel has a load of android-ish stuff in it (which is a
little different in ways I don't understand) and won't work with Xen.

> > Anyway, we are trying to make this easier but it is clearly not ready
> > yet.
> 
> Yes I can see you are, and you're making progress for sure. Thumbs up.
> 
> Appreciation and thx for your input, fellow Ian.

No problem. Please do continue to point out places where the wiki is
confusing/incorrect/misleading etc. I think I've fixed what you pointed
out already in the wiki as well as correcting/expanding things as I
mentioned them above, but if I missed one please let me know.

Ian.


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