[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