On Mar 6, 2014, at 9:50 AM, Scott Wood scottwood@freescale.com wrote:
On Thu, 2014-03-06 at 09:48 -0600, Kumar Gala wrote:
On Jan 23, 2014, at 6:11 AM, Alexander Graf agraf@suse.de wrote:
On 21.01.2014, at 03:25, Scott Wood scottwood@freescale.com 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
Oh, right. Did e6500 move to fixed IVORs? If not this can probably be removed as I doubt there will be a new core from FSL that would require this. It was meant as a transition for any OS that cared (if my memory serves me).
- k