| Message ID | 1390144742-4953-2-git-send-email-agraf@suse.de |
|---|---|
| State | Changes Requested |
| Delegated to: | York Sun |
| Headers | show |
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? 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. -Scott
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
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. - k
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
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
On Thu, 2014-03-06 at 09:56 -0600, Kumar Gala wrote: > On Mar 6, 2014, at 9:50 AM, Scott Wood <scottwood@freescale.com> wrote: > > > 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). e6500 does not have fixed IVORs. I'm not sure why it would matter even if it did. An OS should know whether it is running on a chip with fixed IVORs and behave appropriately, rather than assuming the bootloader fixes things up on older chips to look like newer chips. -Scott
diff --git a/arch/powerpc/cpu/mpc85xx/fixed_ivor.S b/arch/powerpc/cpu/mpc85xx/fixed_ivor.S index ebbb8c0..635a97e 100644 --- a/arch/powerpc/cpu/mpc85xx/fixed_ivor.S +++ b/arch/powerpc/cpu/mpc85xx/fixed_ivor.S @@ -36,17 +36,25 @@ SET_IVOR(14, 0x1e0) /* Instruction TLB Error */ SET_IVOR(15, 0x040) /* Debug */ -/* e500v1 & e500v2 only */ -#ifndef CONFIG_E500MC + /* Check for CPU */ + mfpvr r3 + srwi r3, r3, 16 + /* Compare with e500mc PVR major number */ + li r4, 0 + ori r4, r4, 0x8023 + cmpw r3, r4 + + /* e500v1 & e500v2 only */ + bge 1f SET_IVOR(32, 0x200) /* SPE Unavailable */ SET_IVOR(33, 0x220) /* Embedded FP Data */ SET_IVOR(34, 0x240) /* Embedded FP Round */ -#endif +1: SET_IVOR(35, 0x260) /* Performance monitor */ -/* e500mc only */ -#ifdef CONFIG_E500MC + /* e500mc only */ + blt 2f SET_IVOR(36, 0x280) /* Processor doorbell */ SET_IVOR(37, 0x2a0) /* Processor doorbell critical */ SET_IVOR(38, 0x2c0) /* Guest Processor doorbell */ @@ -54,6 +62,8 @@ SET_IVOR(40, 0x300) /* Hypervisor system call */ SET_IVOR(41, 0x320) /* Hypervisor Priviledge */ +#ifndef CONFIG_QEMU_E500 + /* QEMU guests runs in guest mode and can't access GIVORs */ SET_GIVOR(2, 0x060) /* Guest Data Storage */ SET_GIVOR(3, 0x080) /* Guest Instruction Storage */ SET_GIVOR(4, 0x0a0) /* Guest External Input */ @@ -61,3 +71,4 @@ SET_GIVOR(13, 0x1c0) /* Guest Data TLB Error */ SET_GIVOR(14, 0x1e0) /* Guest Instruction TLB Error */ #endif +2:
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. Signed-off-by: Alexander Graf <agraf@suse.de> --- arch/powerpc/cpu/mpc85xx/fixed_ivor.S | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)