qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runti


From: Scott Wood
Subject: Re: [Qemu-ppc] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime
Date: Thu, 6 Mar 2014 09:50:38 -0600

On Thu, 2014-03-06 at 09:48 -0600, Kumar Gala wrote:
> On Jan 23, 2014, at 6:11 AM, Alexander Graf <address@hidden> wrote:
> 
> > 
> > On 21.01.2014, at 03:25, Scott Wood <address@hidden> wrote:
> > 
> >> On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote:
> >>> With the qemu-ppce500 machine type we can run the same board with
> >>> either an e500v2 or an e500mc core plugged in.
> >>> 
> >>> This means that the IVOR setup can't be based on compile time decisions,
> >>> so instead we have to do a runtime check which CPU generation we're
> >>> running on.
> >> 
> >> Is this really the only place where you ran into this?
> > 
> > Yup. At least the only place where the difference actually matters for a VM.
> > 
> >> Also consider that you'll be adding extra size, and some of our 85xx
> >> targets are pretty close to the limit as is (though at least this code
> >> isn't used in SPLs).
> >> 
> >> I guess nobody ever bothered to set IVORs for e6500-specific exceptions.
> >> 
> >> For that matter, I don't see why we need this code at all.  These aren't
> >> the addresses that U-Boot keeps its exception vectors at; it's setting
> >> them up for the OS, apparently trying to imitate some other type of
> >> book3e chip that has fixed ivors.  Apparently U-Boot has done this only
> >> since 2009 (commit 26f4cdba6b51deab4ec99d60be381244068ef950), so it's
> >> not even something that an OS could depend on (and certainly Linux
> >> doesn't).  So I don't see the point.
> > 
> > Kumar, do you remember why you put this in? Was it only for prototyping 
> > purposes?
> > 
> > I certainly wouldn't mind removing the whole thing altogether.
> > 
> > 
> > Alex
> 
> 
> I feel like we did have some support for timer & external interrupts in 
> u-boot.  Its been a while since I looked.

This has nothing to do with U-Boot's own exception handlers -- this is
what U-Boot is currently doing just prior to entering the OS.

-Scott





reply via email to

[Prev in Thread] Current Thread [Next in Thread]