[U-Boot] commit "powerpc: Remove warm reset entry point" does not work on mpc83xx
My board has a problem with this change. I added it manually to my tree and now it wont boot at all(only with BDI2000 connected). It seems like my board uses the warm start vector at all times. Padding with 4 nop's after the _start symbol fixes the problem. It might be due to a somewhat peculiar reset design but I cannot understand why. Does this work for everyone else using 83xx?
Jocke
On Tue, 2010-10-19 at 12:07 +0200, Joakim Tjernlund wrote:
My board has a problem with this change. I added it manually to my tree and now it wont boot at all(only with BDI2000 connected).
Just to clarify, it won't boot with or without the BDI2000 connected, correct?
It seems like my board uses the warm start vector at all times. Padding with 4 nop's after the _start symbol fixes the problem. It might be due to a somewhat peculiar reset design but I cannot understand why. Does this work for everyone else using 83xx?
Odd... I don't have an 83xx board to test on unfortunately. Nothing jumps out as being obviously wrong in the assembly:
===== Pre-commit (works): fe000100 <_start>: fe000100: 3a a0 00 01 li r21,1 fe000104: 60 00 00 00 nop fe000108: 48 00 00 10 b fe000118 <boot_cold> fe00010c: 00 00 00 00 .long 0x0
fe000110 <_start_warm>: fe000110: 3a a0 00 02 li r21,2 fe000114: 48 00 00 0c b fe000120 <boot_warm>
fe000118 <boot_cold>: fe000118: 3c 80 ff 40 lis r4,-192 fe00011c: 60 00 00 00 nop
fe000120 <boot_warm>: fe000120: 7c a0 00 a6 mfmsr r5 fe000124: 48 00 00 05 bl fe000128 <boot_warm+0x8> fe000128: 7c e8 02 a6 mflr r7
===== Post-commit (doesn't work): fe000100 <_start>: fe000100: 3c 80 ff 40 lis r4,-192 fe000104: 60 00 00 00 nop fe000108: 7c a0 00 a6 mfmsr r5 fe00010c: 48 00 00 05 bl fe000110 <_start+0x10> fe000110: 7c e8 02 a6 mflr r7
It'll be interesting to hear if the change affects other boards in the same way.
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 2010/10/19 17:51:11:
On Tue, 2010-10-19 at 12:07 +0200, Joakim Tjernlund wrote:
My board has a problem with this change. I added it manually to my
tree
and now it wont boot at all(only with BDI2000 connected).
Just to clarify, it won't boot with or without the BDI2000 connected, correct?
It will only boot WITH the BDI2000. That is because my BDI sets the PC before execute.
It seems like my board uses the warm start vector at all times. Padding with 4 nop's after the _start symbol fixes the problem. It might be due to a somewhat peculiar reset design but I cannot understand why. Does this work for everyone else using 83xx?
Odd... I don't have an 83xx board to test on unfortunately. Nothing jumps out as being obviously wrong in the assembly:
The difference is that I suspect execution starts at 0xXXXXXX110 rather than 0xXXXXXX100. BTW, I have my reset vector at 0x0
What causes a warm reset?
Jocke
It seems like my board uses the warm start vector at all times. Padding with 4 nop's after the _start symbol fixes the problem. It might be due to a somewhat peculiar reset design but I cannot understand why. Does this work for everyone else using 83xx?
Odd... I don't have an 83xx board to test on unfortunately. Nothing jumps out as being obviously wrong in the assembly:
The difference is that I suspect execution starts at 0xXXXXXX110 rather than 0xXXXXXX100. BTW, I have my reset vector at 0x0
What causes a warm reset?
My understanding is that a warm reset on the 8xxx CPUs isn't really a hardware reset - its just when code explicitly jumps to the warm reset entry point. For example, this board used to jump to _start_warm when "reset" was ran in U-Boot: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3792d7436e2bf881b6abdede5a48...
During normal use I thought that the reset entry point was always 0xXXXXX100 and a warm reset would never occur.
What is the power on reset process like on your board?
Best, Peter
Peter Tyser ptyser@xes-inc.com wrote on 2010/10/19 20:39:41:
It seems like my board uses the warm start vector at all times. Padding with 4 nop's after the _start symbol fixes the problem. It might be due to a somewhat peculiar reset design but I cannot understand why. Does this work for everyone else using 83xx?
Odd... I don't have an 83xx board to test on unfortunately. Nothing jumps out as being obviously wrong in the assembly:
The difference is that I suspect execution starts at 0xXXXXXX110
rather
than 0xXXXXXX100. BTW, I have my reset vector at 0x0
What causes a warm reset?
My understanding is that a warm reset on the 8xxx CPUs isn't really a hardware reset - its just when code explicitly jumps to the warm reset entry point. For example, this board used to jump to _start_warm when "reset" was ran in U-Boot:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3792d7436e2bf881b6abdede5a48...
During normal use I thought that the reset entry point was always 0xXXXXX100 and a warm reset would never occur.
I am not so sure about this. Perhaps the Freescale guys can set us straight?
What is the power on reset process like on your board?
A bit fuzzy ATM, will have to look at that.
Dear Joakim Tjernlund,
In message OFBC383CCF.86B567D6-ONC12577C1.006A80D5-C12577C1.006AA773@transmode.se you wrote:
During normal use I thought that the reset entry point was always 0xXXXXX100 and a warm reset would never occur.
I am not so sure about this. Perhaps the Freescale guys can set us straight?
Originally U-Boot (well, PPCBoot, to be more precise) had this notion of a "warm start", but I quickly learned that this makes little sense in a boot loader. When we execute the "reset" command,. we usually want to _really_ reset the system into operational mode, including not only the CPU itself but also co-processors (which might be running some form of microcode or DMA), external controllers (to stop them from doing DMA or other data transfers), NOR flash (to make sure it is in read mode so we can execute code from it), etc.
Whenever this was not possible (usually due to hardware design "features") this almost always was experienced as a "bug in U-Boot" because there were situations where the board could only be reset through full power cycle.
My recommendation is: stop thinking of "warm boot"; either perform a "reset" (and that be a real, hard reset of the CPU core and all peripherals), or just continue to run ;-)
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/10/19 22:04:17:
Dear Joakim Tjernlund,
In message <OFBC383CCF.86B567D6-ONC12577C1.006A80D5-C12577C1. 006AA773@transmode.se> you wrote:
During normal use I thought that the reset entry point was always 0xXXXXX100 and a warm reset would never occur.
I am not so sure about this. Perhaps the Freescale guys can set us straight?
Originally U-Boot (well, PPCBoot, to be more precise) had this notion of a "warm start", but I quickly learned that this makes little sense in a boot loader. When we execute the "reset" command,. we usually want to _really_ reset the system into operational mode, including not only the CPU itself but also co-processors (which might be running some form of microcode or DMA), external controllers (to stop them from doing DMA or other data transfers), NOR flash (to make sure it is in read mode so we can execute code from it), etc.
Whenever this was not possible (usually due to hardware design "features") this almost always was experienced as a "bug in U-Boot" because there were situations where the board could only be reset through full power cycle.
My recommendation is: stop thinking of "warm boot"; either perform a "reset" (and that be a real, hard reset of the CPU core and all peripherals), or just continue to run ;-)
We do. Even have a HRESET button and it still doesn't work. There is one thing though: At address 0x100(and 0x110) we have a branch to where the boot is really located. This is because we have small sectors in the beginning of the flash and we want to use those as environment etc.
Jocke
Dear Joakim Tjernlund,
In message OF7EBFC833.2F0E9C3D-ONC12577C1.00737E7A-C12577C1.0073EC18@transmode.se you wrote:
There is one thing though: At address 0x100(and 0x110) we have a branch to where the boot is really located. This is because we have small sectors in the beginning of the flash and we want to use those as environment etc.
Why don't you use the rest of this sector for code? All you need to do is adapt the linker script a bit...
Without that - where is your exception handler code? This is supposed to be there, too...
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 2010/10/19 23:13:59:
Dear Joakim Tjernlund,
In message <OF7EBFC833.2F0E9C3D-ONC12577C1.00737E7A-C12577C1. 0073EC18@transmode.se> you wrote:
There is one thing though: At address 0x100(and 0x110) we have a branch to where the boot is really located. This is because we have small sectors in the beginning of the flash and we want to use those as environment etc.
Why don't you use the rest of this sector for code? All you need to do is adapt the linker script a bit...
Without that - where is your exception handler code? This is supposed to be there, too...
ah, this is only during the early steps. The flash gets mapped to 0xf0000000 and RAM is mapped to 0x0
participants (3)
-
Joakim Tjernlund -
Peter Tyser -
Wolfgang Denk