[U-Boot] [RFC] mx28: Fix reboot from the kernel
When running Linux on a mx28evk and issuing a 'reboot'command the following behaviour is observed:
root@freescale /$ reboot starting pid 329, tty '': '/etc/rc.d/rcS stop' root@freescale /$ Stopping inetd: Terminated Unmounting filesystems umount: tmpfs busy - remounted read-only chown: /home/user/.rhosts: Read-only file system chown: /home/user: Read-only file system chown: /home/user: Read-only file system cat: can't open '/proc/devices': No such file or directory The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 24.240000] Restarting system.
U-Boot 2011.12-06887-g586ab2f-dirty (Jan 24 2012 - 12:58:50)
Freescale i.MX28 family DRAM: 0
, and then U-boot hangs.
Calling mx28_power_init() prior to mxs_iomux_setup_multiple_pads() fixes the problem and make U-boot to re-start succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com --- This patch fixes the reboot issue, but I am not able to provide a good explanation for it, so I am marking it as RFC.
arch/arm/cpu/arm926ejs/mx28/spl_boot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c index dfb8309..0e57252 100644 --- a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c +++ b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c @@ -49,8 +49,8 @@ void early_delay(int delay) void mx28_common_spl_init(const iomux_cfg_t *iomux_setup, const unsigned int iomux_size) { - mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_power_init(); + mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_mem_init(); mx28_power_wait_pswitch(); }
When running Linux on a mx28evk and issuing a 'reboot'command the following behaviour is observed:
root@freescale /$ reboot starting pid 329, tty '': '/etc/rc.d/rcS stop' root@freescale /$ Stopping inetd: Terminated Unmounting filesystems umount: tmpfs busy - remounted read-only chown: /home/user/.rhosts: Read-only file system chown: /home/user: Read-only file system chown: /home/user: Read-only file system cat: can't open '/proc/devices': No such file or directory The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 24.240000] Restarting system.
U-Boot 2011.12-06887-g586ab2f-dirty (Jan 24 2012 - 12:58:50)
Freescale i.MX28 family DRAM: 0
, and then U-boot hangs.
Calling mx28_power_init() prior to mxs_iomux_setup_multiple_pads() fixes the problem and make U-boot to re-start succesfully.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
This patch fixes the reboot issue, but I am not able to provide a good explanation for it, so I am marking it as RFC.
arch/arm/cpu/arm926ejs/mx28/spl_boot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c index dfb8309..0e57252 100644 --- a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c +++ b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c @@ -49,8 +49,8 @@ void early_delay(int delay) void mx28_common_spl_init(const iomux_cfg_t *iomux_setup, const unsigned int iomux_size) {
- mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_power_init();
- mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_mem_init(); mx28_power_wait_pswitch();
}
Can you explain why this patch fixes anything ? It's hard to understand why doing this would fix it.
On Tue, Jan 24, 2012 at 9:48 PM, Marek Vasut marek.vasut@gmail.com wrote:
Can you explain why this patch fixes anything ? It's hard to understand why doing this would fix it.
Yes, I agree and that's why I marked it as RFC and please also see my comments below the --- line.
I don't understand the reason for the fix as well. Matthias' patch for adding the boot mode information in mx28 magically fixed the reboot issue and playing with his patch I realized that any instruction prior to mxs_iomux_setup_multiple_pads "fixes" the reboot problem.
Regards,
Fabio Estevam
On Tue, Jan 24, 2012 at 9:48 PM, Marek Vasut marek.vasut@gmail.com wrote:
Can you explain why this patch fixes anything ? It's hard to understand why doing this would fix it.
Yes, I agree and that's why I marked it as RFC and please also see my comments below the --- line.
I don't understand the reason for the fix as well. Matthias' patch for adding the boot mode information in mx28 magically fixed the reboot issue and playing with his patch I realized that any instruction prior to mxs_iomux_setup_multiple_pads "fixes" the reboot problem.
Now that IS CREEPY. You mean like ... just anything ? Or does the code executed before need to be exactly long or longer than something ?
M
Regards,
Fabio Estevam
On Tue, Jan 24, 2012 at 11:25 PM, Marek Vasut marek.vasut@gmail.com wrote:
Now that IS CREEPY. You mean like ... just anything ? Or does the code executed before need to be exactly long or longer than something ?
Yes, my tests show that anything prior to mxs_iomux_setup_multiple_pads makes reboot to work.
I added more details here: http://marc.info/?l=u-boot&m=132741813307150&w=2
That´s a very strange behaviour.
Regards,
Fabio Estevam
On Tue, Jan 24, 2012 at 11:25 PM, Marek Vasut marek.vasut@gmail.com wrote:
Now that IS CREEPY. You mean like ... just anything ? Or does the code executed before need to be exactly long or longer than something ?
Yes, my tests show that anything prior to mxs_iomux_setup_multiple_pads makes reboot to work.
Your @G jabber is botched, can you try pushing through on the other side? :-(
I added more details here: http://marc.info/?l=u-boot&m=132741813307150&w=2
That´s a very strange behaviour.
Let's hope UPS works on time as the weather forecast in Back to the Future II, if that's the case, I'd be able to test myself on thursday :-)
Regards,
Fabio Estevam
On 24.01.2012 17:23, Fabio Estevam wrote:
When running Linux on a mx28evk and issuing a 'reboot'command the following behaviour is observed:
root@freescale /$ reboot starting pid 329, tty '': '/etc/rc.d/rcS stop' root@freescale /$ Stopping inetd: Terminated Unmounting filesystems umount: tmpfs busy - remounted read-only chown: /home/user/.rhosts: Read-only file system chown: /home/user: Read-only file system chown: /home/user: Read-only file system cat: can't open '/proc/devices': No such file or directory The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 24.240000] Restarting system.
U-Boot 2011.12-06887-g586ab2f-dirty (Jan 24 2012 - 12:58:50)
Freescale i.MX28 family DRAM: 0
, and then U-boot hangs.
Calling mx28_power_init() prior to mxs_iomux_setup_multiple_pads() fixes the problem and make U-boot to re-start succesfully.
Hmm, I did not observe that issue on my board.
Signed-off-by: Fabio Estevam fabio.estevam@freescale.com
This patch fixes the reboot issue, but I am not able to provide a good explanation for it, so I am marking it as RFC.
arch/arm/cpu/arm926ejs/mx28/spl_boot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c index dfb8309..0e57252 100644 --- a/arch/arm/cpu/arm926ejs/mx28/spl_boot.c +++ b/arch/arm/cpu/arm926ejs/mx28/spl_boot.c @@ -49,8 +49,8 @@ void early_delay(int delay) void mx28_common_spl_init(const iomux_cfg_t *iomux_setup, const unsigned int iomux_size) {
- mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_power_init();
- mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size); mx28_mem_init(); mx28_power_wait_pswitch();
}
Without an explanation I woutld not accept this patch.
So when adding "some" instructions before mx28_mem_init() you could check for the first steps in that function are and if really delaying the first instructions or same later stuff helps. Perhaps this brings us a clue.
I will see if your reordering has any impact on my "USB recovery boot issue".
Matthias
On 24/01/2012 17:23, Fabio Estevam wrote:
When running Linux on a mx28evk and issuing a 'reboot'command the following behaviour is observed:
Hi Fabio,
Calling mx28_power_init() prior to mxs_iomux_setup_multiple_pads() fixes the problem and make U-boot to re-start succesfully.
This does not explain why it hangs, and why it does not hangs on M28....apparently, checking both functions there is no evident reason why they should be called in a certain order. I think we have to dig more deeply inside this strange behavior.
Best regards, SWtefano Babic
participants (5)
-
Fabio Estevam -
Fabio Estevam -
Marek Vasut -
Matthias Fuchs -
Stefano Babic