Re: [Xen-users] Fw: booting

[IAN DELANEY <della5@xxxxxxxxxxxx>]

On Thu, 6 Feb 2014 11:42:26 +0000
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

right I remembered to CC this time.  That was quick Ian thx.  It will
take me a good while to digest and tinker with this generous response
of valuable tips and snippets.  I shall just do a reply to the few
points I have some data for, the remainder I shall work tomorrow,
afresh.

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

This makes it awkward.  Steev the gentoo arm dev himself is urging me
to acquire a usb adaptor so as to get a serial console.  I've tried
twice now with a local supplier and Perth/Australia it appears just
doesn't have 'em!!!!!  Can't even source a supplier, any supplier.
They're around $10 U.S. ordered online and would then take a few weeks
for delivery.  By monitor, I mean the screen of the AOC or Samsung
SyncMaster226BWW, plugged into the video input in the tower (the case)
housing my amd64 motherboard, which is I believe VGA/HDMI output.
Welcome to Perth W.A., aka endsville! :) /me would really like a serial
console!!!

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

strooth

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

for tomorrow.

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

Well, either or.   It's your suggestion to cut out the xen.gz and just
go for the kernel.  As I say, it appears to be booting since the green
diode comes on and stays on.  A flashing of green or blue indicates, I
believe, something has pulled up and failed.  Blind without a serial
console output.  You text following here I will pursue tomorrow.

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

I see, not a range at all.  the '-' made it look like a range which AI
never thought a sane kind of entry.

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

right. @ gentoo we do without initrds so it's one layer nicely taken
out.

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

stay with email for now.  Thx for your extensive tips.  As Wallace
would say; that's just grand!

> Ian.
> 



-- 
kind regards

Ian Delaney

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