> -----Original Message----- > From: Scott Wood [mailto:scottw...@freescale.com] > Sent: Monday, September 20, 2010 11:44 PM > To: Chen, Tiejun > Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud > Subject: Re: Generating elf kernel ? > > On Sun, 19 Sep 2010 09:40:15 +0800 > "tiejun.chen" <tiejun.c...@windriver.com> wrote: > > > Scott Wood wrote: > > > On Fri, 17 Sep 2010 09:58:41 +0800 > > > "tiejun.chen" <tiejun.c...@windriver.com> wrote: > > > > > >> Scott Wood wrote: > > >>> The guest OS *is* the same as native Linux, as far as > TLB handling > > >>> is concerned. > > >> Looks you means the TLB exception handler should be same between > > >> the native and the guest OS. Right? > > > > > > Yes. > > > > I don't think so. The HY should assist the guest OS on MMU since I > > already point the guest OS have no authority to create a > real TLB directly as I previously said. > > Of course the hypervisor assists, when a trap is taken. That > doesn't mean the code is any different in the guest.
This should be depend on the hypervisor design implementation. I think your option should be based on the Freescale hypervisor. > > > > Yes, of course. But that's not the point. I was just > using it as a > > > convenient example because that's what I've recently done ELF > > > loading with... There's no reason U-Boot couldn't do the same if > > > its ELF loader were updated to support device trees. Currently > > > U-Boot loads bootwrapperless uImages to physical address zero. > > > > I never doubt the U-boot can do this for uImage. But I think we're > > always talking about vmlinux, a bare Image. > > uImage is pretty much a bare image. It just has a header > with a checksum and some info like OS/architecture, kernel > version, build date, etc. Yes. But it also inlcude load address and entry point used to u-boot. > > There would be *no* problem doing this with vmlinux in U-Boot > if someone put in the code to pass a device tree. This is just I always emphasize previously. Cheers Tiejun > > -Scott > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
