[U-Boot-Users] [PATCH][FOR 1.3.4] 85xx: Don't move interrupt vector to low memory
Moving the interrupt vectors to low memory can cause issues if the code gets overwritten via some image loading command (tftp, boot*, etc.) and interrupts (like the decrementer are enabled).
On 85xx there is no reason to copy the interrupt vectors to low memory since we can run them in high memory since we are a Book-E core.
Signed-off-by: Kumar Gala galak@kernel.crashing.org ---
This is a fix for 1.3.4.
- k
cpu/mpc85xx/start.S | 19 +++++-------------- 1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S index 10fe936..9c8b2a1 100644 --- a/cpu/mpc85xx/start.S +++ b/cpu/mpc85xx/start.S @@ -936,13 +936,6 @@ trap_init: bgelr /* return if r7>=r8 - just in case */
mflr r4 /* save link register */ -1: - lwz r0,0(r7) - stw r0,0(r9) - addi r7,r7,4 - addi r9,r9,4 - cmplw 0,r7,r8 - bne 1b
/* * relocate `hdlr' and `int_return' entries @@ -973,9 +966,6 @@ trap_init: cmplw 0,r7,r8 blt 2b
- lis r7,0x0 - mtspr IVPR,r7 - mtlr r4 /* restore link register */ blr
@@ -983,13 +973,14 @@ trap_init: * Function: relocate entries for one exception vector */ trap_reloc: - lwz r0,0(r7) /* hdlr ... */ + lwzx r0,r3,r7 /* hdlr ... */ add r0,r0,r3 /* ... += dest_addr */ - stw r0,0(r7) + stwx r0,r3,r7
- lwz r0,4(r7) /* int_return ... */ + addi r7,r7,4 + lwzx r0,r3,r7 /* int_return ... */ add r0,r0,r3 /* ... += dest_addr */ - stw r0,4(r7) + stwx r0,r3,r7
blr
In message Pine.LNX.4.64.0808060127560.20220@blarg.am.freescale.net you wrote:
Moving the interrupt vectors to low memory can cause issues if the code gets overwritten via some image loading command (tftp, boot*, etc.) and interrupts (like the decrementer are enabled).
Oops? This is expected and normal behaviour. Did anybody complain about this?
On 85xx there is no reason to copy the interrupt vectors to low memory since we can run them in high memory since we are a Book-E core.
High memory means leave them in flash?
Then you will probably see nice crashes as soon as you erase U-Boot for example to install a new version.
All references to flash memory must be relocated to RAM, including the exception vectors, of course.
Signed-off-by: Kumar Gala galak@kernel.crashing.org
This is a fix for 1.3.4.
I don't think so. Seems to introduce a bug.
Best regards,
Wolfgang Denk
On Aug 6, 2008, at 1:50 AM, Wolfgang Denk wrote:
In message <Pine.LNX. 4.64.0808060127560.20220@blarg.am.freescale.net> you wrote:
Moving the interrupt vectors to low memory can cause issues if the code gets overwritten via some image loading command (tftp, boot*, etc.) and interrupts (like the decrementer are enabled).
Oops? This is expected and normal behaviour. Did anybody complain about this?
Real, any reason why? I understand on classic PPC this might be the case but I see no reason for it to be so on book-e parts.
On 85xx there is no reason to copy the interrupt vectors to low memory since we can run them in high memory since we are a Book-E core.
High memory means leave them in flash?
No I leave them at the relocated location in DDR.
Then you will probably see nice crashes as soon as you erase U-Boot for example to install a new version.
All references to flash memory must be relocated to RAM, including the exception vectors, of course.
Any they are. I'm just removing a second relocation that is a hold over from how 6xx PPC exception vectors work.
Signed-off-by: Kumar Gala galak@kernel.crashing.org
This is a fix for 1.3.4.
I don't think so. Seems to introduce a bug.
I disagree with that. It resolved a bug when I did. 'setenv autostart no; bootm'
- k
In message 41F2F68F-34F5-4D3B-8AA1-294589B48033@kernel.crashing.org you wrote:
Oops? This is expected and normal behaviour. Did anybody complain about this?
Real, any reason why? I understand on classic PPC this might be the case but I see no reason for it to be so on book-e parts.
Well, one reason might be to have identical code for all PPC systems ?
High memory means leave them in flash?
No I leave them at the relocated location in DDR.
Ah, I see.
All references to flash memory must be relocated to RAM, including the exception vectors, of course.
Any they are. I'm just removing a second relocation that is a hold over from how 6xx PPC exception vectors work.
Not only 6xx. Actually all PPC.
I don't think so. Seems to introduce a bug.
I disagree with that. It resolved a bug when I did. 'setenv autostart no; bootm'
That might be a problem only when using your broken autostart patches.
We will fix this by backing out that patch ;-)
Best regards,
Wolfgang Denk
On Wed, Aug 06, 2008 at 04:42:51PM +0200, Wolfgang Denk wrote:
In message 41F2F68F-34F5-4D3B-8AA1-294589B48033@kernel.crashing.org you wrote:
Oops? This is expected and normal behaviour. Did anybody complain about this?
It's hit me before when I foolishly try to load something at address zero -- why do we put u-boot at the end of RAM, and put up with the relocation weirdness, if not to allow loading things at zero?
Real, any reason why? I understand on classic PPC this might be the case but I see no reason for it to be so on book-e parts.
Well, one reason might be to have identical code for all PPC systems ?
It's already 85xx-specific code.
Any they are. I'm just removing a second relocation that is a hold over from how 6xx PPC exception vectors work.
Not only 6xx. Actually all PPC.
No, not all PPC. Book-E exceptions are different.
-Scott
Scott Wood wrote:
On Wed, Aug 06, 2008 at 04:42:51PM +0200, Wolfgang Denk wrote:
In message 41F2F68F-34F5-4D3B-8AA1-294589B48033@kernel.crashing.org you wrote:
Oops? This is expected and normal behaviour. Did anybody complain about this?
It's hit me before when I foolishly try to load something at address zero -- why do we put u-boot at the end of RAM, and put up with the relocation weirdness, if not to allow loading things at zero?
Real, any reason why? I understand on classic PPC this might be the case but I see no reason for it to be so on book-e parts.
Well, one reason might be to have identical code for all PPC systems ?
It's already 85xx-specific code.
Any they are. I'm just removing a second relocation that is a hold over from how 6xx PPC exception vectors work.
Not only 6xx. Actually all PPC.
No, not all PPC. Book-E exceptions are different.
-Scott
One nice thing about not relocating the exception vectors to 0 is that it would allow us to recover from a failed bootm all the way up to the jump to linux (or whomever) rather than having to reset the board to recover from a failure late in the bootm sequence.
Unfortunately, it would be Book-E specific and probably not worth coding Yet Another Special Case in the already overcomplex bootm code.
Best regards, gvb
In message 20080806193205.GA3975@ld0162-tx32.am.freescale.net you wrote:
It's hit me before when I foolishly try to load something at address zero -- why do we put u-boot at the end of RAM, and put up with the relocation weirdness, if not to allow loading things at zero?
We want to free as much memory as possible. But low RAM cannot be made available on all systems.
Well, one reason might be to have identical code for all PPC systems ?
It's already 85xx-specific code.
Good point. Why don't we factor this out and make it common code for all PPC?
Not only 6xx. Actually all PPC.
No, not all PPC. Book-E exceptions are different.
Maybe. But then, these can use exception vectors at low mem, too, right?
For me the chance to have common code (and identical behaviour) for all PowerPC processors is much more important that being able to use 16 kB additional memory on one specific family of processors.
Best regards,
Wolfgang Denk
On Aug 6, 2008, at 2:46 PM, Wolfgang Denk wrote:
In message 20080806193205.GA3975@ld0162-tx32.am.freescale.net you wrote:
It's hit me before when I foolishly try to load something at address zero -- why do we put u-boot at the end of RAM, and put up with the relocation weirdness, if not to allow loading things at zero?
We want to free as much memory as possible. But low RAM cannot be made available on all systems.
Well, one reason might be to have identical code for all PPC systems ?
It's already 85xx-specific code.
Good point. Why don't we factor this out and make it common code for all PPC?
Because the relocation is specific to the various interrupt types. Book-E will need different code for handing IVPR/IVORs than classic.
Not only 6xx. Actually all PPC.
No, not all PPC. Book-E exceptions are different.
Maybe. But then, these can use exception vectors at low mem, too, right?
They can, but it has to be setup.
For me the chance to have common code (and identical behaviour) for all PowerPC processors is much more important that being able to use 16 kB additional memory on one specific family of processors.
- k
In message 9D199630-11FA-4028-8EE6-CBC59F6F67A0@kernel.crashing.org you wrote:
Good point. Why don't we factor this out and make it common code for all PPC?
Because the relocation is specific to the various interrupt types. Book-E will need different code for handing IVPR/IVORs than classic.
Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too?
Maybe. But then, these can use exception vectors at low mem, too, right?
They can, but it has to be setup.
What is Linux doing?
Best regards,
Wolfgang Denk
On Aug 6, 2008, at 3:17 PM, Wolfgang Denk wrote:
In message <9D199630-11FA-4028-8EE6- CBC59F6F67A0@kernel.crashing.org> you wrote:
Good point. Why don't we factor this out and make it common code for all PPC?
Because the relocation is specific to the various interrupt types. Book-E will need different code for handing IVPR/IVORs than classic.
Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too?
the copying bit should be do-able in generic code.
74xx_7xx/mpc512x/mpc5xx/mpc8xx/mpc8220/mpc824x/mpc83xx/mpc86xx:
copy from [_start, _end_of_vectors] to 0x100
4xx/85xx:
copy from [_start_of_vectors, _end_of_vectors] to 0x100
Maybe. But then, these can use exception vectors at low mem, too, right?
They can, but it has to be setup.
What is Linux doing?
don't follow the question.. what is linux doing with what?
- k
In message D5CA3AB9-3AE3-439C-A169-F8CD26D4A320@kernel.crashing.org you wrote:
Book-E will need different code for handing IVPR/IVORs than classic.
Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too?
the copying bit should be do-able in generic code.
74xx_7xx/mpc512x/mpc5xx/mpc8xx/mpc8220/mpc824x/mpc83xx/mpc86xx:
copy from [_start, _end_of_vectors] to 0x100
4xx/85xx:
copy from [_start_of_vectors, _end_of_vectors] to 0x100
OK, that's what I exoected. So we should plan to factor out this part of code one day.
Maybe. But then, these can use exception vectors at low mem, too, right?
They can, but it has to be setup.
What is Linux doing?
don't follow the question.. what is linux doing with what?
Where is Linux setting up exception vectors on these systems?
Best regards,
Wolfgang Denk
On Aug 6, 2008, at 3:41 PM, Wolfgang Denk wrote:
In message <D5CA3AB9-3AE3-439C-A169- F8CD26D4A320@kernel.crashing.org> you wrote:
Book-E will need different code for handing IVPR/IVORs than classic.
Umm... the exception code itself may be different, but does this imply that the code used to copy / relocate the exception handlers to low mem must be different, too?
the copying bit should be do-able in generic code.
74xx_7xx/mpc512x/mpc5xx/mpc8xx/mpc8220/mpc824x/mpc83xx/mpc86xx:
copy from [_start, _end_of_vectors] to 0x100
4xx/85xx:
copy from [_start_of_vectors, _end_of_vectors] to 0x100
OK, that's what I exoected. So we should plan to factor out this part of code one day.
Maybe. But then, these can use exception vectors at low mem, too, right?
They can, but it has to be setup.
What is Linux doing?
don't follow the question.. what is linux doing with what?
Where is Linux setting up exception vectors on these systems?
they are at 0 for 6xx/8xx/40x systems. They can be anywhere on 85xx/ 44x (and we take advantage of this).
- k
participants (4)
-
Jerry Van Baren -
Kumar Gala -
Scott Wood -
Wolfgang Denk