[Xen-users] Fw: Fw: booting

[IAN DELANEY <della5@xxxxxxxxxxxx>]

Begin forwarded message:

Date: Thu, 6 Feb 2014 18:35:30 +0800
From: IAN DELANEY <della5@xxxxxxxxxxxx>
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-users] Fw: booting


On Wed, 5 Feb 2014 12:26:29 +0000
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

> 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.
> 

CCing but adding something I forgot. 
"source 0x41000000"

In the boot.cmd for Booting via PXE you put this like so;
/boot.scr;source 0x41000000

The sentence out on its own like that I don't know where and how to put
it. i.e. a context.  The way it reads, I boot with the boot.xen
boot.scr, and once booted, then enter source 0x41000000 once logged
into a console, which doesn't really make sense because it doesn't work
in my amd64 tower, combined with that I can't yet actually boot into a
tty for login.  Are you implying that one adds it to perhaps

bootz ${xen_addr_r} - ${fdt_addr}

?  Is this why the booting either stalls or hangs?

> > > 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.
> 

ok thanks fellow Ian.  I've tried a few further tweaks with kind of
mixed results.   A few points;

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.
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.
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}

since xen_addr_r appears to be dealt with 

# Load xen/xen to ${xen_addr_r}
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.

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?

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


thx again.


-- 
kind regards

Ian Delaney


-- 
kind regards

Ian Delaney

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