04-23-2018, 10:15 AM
(This post was last modified: 04-26-2018, 06:06 PM by pfeerick.
Edit Reason: Merge note
)
Hi
Any clues about rock64 stuck after applying soft reboot from shell?
Code: reboot: Restarting system
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 2, parent_node -1, State ON (0x0)
INFO: Domain Node : Level 1, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x0, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x1, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x2, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x3, parent_node 1, State ON (0x0)
Booted the system
Logged in as root
reboot
Stuck at the above log.
Strangely, if I booted as rock64 user, if I do the sudo reboot, there is no issue of stuck after the above mentioned log.
I am searching on google, I found the following link with the same issue, but they closed it as resolved.
https://github.com/Kwiboo/linux-rockchip/issues/14
Can you anybody faced the same issue? and are there any solutions to solve this issue?
Hi,
The rock64 (1G with using 0.5.15-136 version) got stuck after applying the soft reboot. This issue is observed only when we reboot with root credentials, not with rock64 credentials. Not sure why.
The system stuck at the following log
Code: reboot: Restarting system
INFO: PSCI Power Domain Map:
INFO: Domain Node : Level 2, parent_node -1, State ON (0x0)
INFO: Domain Node : Level 1, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: Domain Node : Level 0, parent_node 0, State ON (0x0)
INFO: CPU Node : MPID 0x0, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x1, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x2, parent_node 1, State ON (0x0)
INFO: CPU Node : MPID 0x3, parent_node 1, State ON (0x0)
I searched online for older issues of the same, found the following, but this issue was already resolved.
https://github.com/Kwiboo/linux-rockchip/issues/14
Any advises about how to resolve this issue? Infact I observed this issue only on one unit.
Thanks,
Ramprasad
Moderator note: Merged and moved thread. Please refrain from posting the same question multiple times and in the wrong product forums.
I can't say I've uncounted this issue on the rock64, but I don't think I've ever tried to reboot when logged in as root either. I'll try on a newer image (0.6.x) and then I'll write a 0.5.15 if I find some time.
Using a Rock64 with 4G on version 0.5.15-136 and it'll reboot just fine even if logged in as root (only time I've ever tries this though).
04-28-2018, 06:58 PM
(This post was last modified: 04-28-2018, 07:00 PM by rontant.)
No problem for me either doing the soft reboot using root account. You don't need to use "sudo" when logged in as "root".
Code: Linux rock64 4.4.120-rockchip-ayufan-209 #1 SMP Mon Apr 2 16:05:07 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
This is not happening 100% of the time.
To debug this issue, I would like to understand what makes the rock64 stuck after dumping PSCI Power Domain Map? It may not be generalized rock64 issue, but we are using 1G rock64 units adding some more hardware to it, which is the power source to rock64. Is there any way to enable POST (power on self test) before starting the reboot (may PSCI Power Domain Map related to POST).
Appreciate your help/advises and proposes to debug this issue? would like to identify the root cause.
Thanks,
Ramprasad
If you are connecting a serial console to "ROCK64"
"Rock64 Boot-up Bug with Serial Console Cable"
https://forum.pine64.org/showthread.php?tid=5008
See the above thread.
Because "ROCK64" itself has individual differences,
Although it is not necessarily said that this condition inevitably occurs,
That possibility is high.
Because I experienced similar symptoms,
In my case, the following measures were taken to avoid this problem.
To connect the serial console (TX / RX) and "ROCK64", insert the Device:"74HC4050".
Basically, it is the same as the countermeasure introduced above.
- -
*) There is no input clamp-protection diode in "74HC4050".
*) Get power of "74HC4050" from "VCC_IO@ROCK64".
*) As a result of the above, isolation can be obtained even when the power of "ROCK64" is OFF.
(04-30-2018, 09:46 PM)t4_4t Wrote: To connect the serial console (TX / RX) and "ROCK64", insert the Device:"74HC4050". Nice one. Like the use of a buffer instead of a diode! 
If I have issues which I suspect are related to the usb-serial and I see that dimly lit power light I just unplug the usb serial for a second or two to make sure the rock64 has fully powered down / reset. Can't say I remember any issues I can directly attribute to the usb-serial... but doesn't mean it hasn't happened (or won't!)!
ramprasad Wrote:Is there any way to enable POST (power on self test) before starting the reboot (may PSCI Power Domain Map related to POST).
When I logged in as the root user - full login, not via su - on 0.6.25 xenial-containers, it rebooted just fine (other than a kernel autotune related panic with auto-reboot)... did it two or three more times, and also as a sudo user, and couldn't get anything different to happen. I have seen that "INFO: PSCI Power Domain Map:" info before, I'm not sure what the difference was though. Are you on debian stretch? As far as any POST stuff, you'd probably have to implement that yourself, as that is something that the ARM architecture doesn't have.
Code: [ OK ] Reached target Unmount All Filesystems.
[ OK ] Stopped target Local File Systems (Pre).
[ OK ] Stopped Create Static Device Nodes in /dev.
[ OK ] Stopped Remount Root and Kernel File Systems.
[ OK ] Reached target Shutdown.
[1061865.715205] reboot: Restarting system
DDR version 1.06 20170424
In
SRX
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT
(05-01-2018, 04:16 AM)pfeerick Wrote: (04-30-2018, 09:46 PM)t4_4t Wrote: To connect the serial console (TX / RX) and "ROCK64", insert the Device:"74HC4050". Nice one. Like the use of a buffer instead of a diode!
If I have issues which I suspect are related to the usb-serial and I see that dimly lit power light I just unplug the usb serial for a second or two to make sure the rock64 has fully powered down / reset. Can't say I remember any issues I can directly attribute to the usb-serial... but doesn't mean it hasn't happened (or won't!)!
ramprasad Wrote:Is there any way to enable POST (power on self test) before starting the reboot (may PSCI Power Domain Map related to POST).
When I logged in as the root user - full login, not via su - on 0.6.25 xenial-containers, it rebooted just fine (other than a kernel autotune related panic with auto-reboot)... did it two or three more times, and also as a sudo user, and couldn't get anything different to happen. I have seen that "INFO: PSCI Power Domain Map:" info before, I'm not sure what the difference was though. Are you on debian stretch? As far as any POST stuff, you'd probably have to implement that yourself, as that is something that the ARM architecture doesn't have.
Code: [ OK ] Reached target Unmount All Filesystems.
[ OK ] Stopped target Local File Systems (Pre).
[ OK ] Stopped Create Static Device Nodes in /dev.
[ OK ] Stopped Remount Root and Kernel File Systems.
[ OK ] Reached target Shutdown.
[1061865.715205] reboot: Restarting system
DDR version 1.06 20170424
In
SRX
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT
Yes, I am using Debian stretch. I also suspected that it could be serial cable connected. But when I connected the WiFi dongle, log-in with SSH as rock64 user and then to the root. Still I could reproduce this issue.
I wonder, why the above log doesn't show the "INFO: PSCI Power Domain Map:". Does it change between different OS (Debian/Xaniel etc..).?
(05-08-2018, 02:44 PM)ramprasad Wrote: (05-01-2018, 04:16 AM)pfeerick Wrote: (04-30-2018, 09:46 PM)t4_4t Wrote: To connect the serial console (TX / RX) and "ROCK64", insert the Device:"74HC4050". Nice one. Like the use of a buffer instead of a diode!
If I have issues which I suspect are related to the usb-serial and I see that dimly lit power light I just unplug the usb serial for a second or two to make sure the rock64 has fully powered down / reset. Can't say I remember any issues I can directly attribute to the usb-serial... but doesn't mean it hasn't happened (or won't!)!
ramprasad Wrote:Is there any way to enable POST (power on self test) before starting the reboot (may PSCI Power Domain Map related to POST).
When I logged in as the root user - full login, not via su - on 0.6.25 xenial-containers, it rebooted just fine (other than a kernel autotune related panic with auto-reboot)... did it two or three more times, and also as a sudo user, and couldn't get anything different to happen. I have seen that "INFO: PSCI Power Domain Map:" info before, I'm not sure what the difference was though. Are you on debian stretch? As far as any POST stuff, you'd probably have to implement that yourself, as that is something that the ARM architecture doesn't have.
Code: [ OK ] Reached target Unmount All Filesystems.
[ OK ] Stopped target Local File Systems (Pre).
[ OK ] Stopped Create Static Device Nodes in /dev.
[ OK ] Stopped Remount Root and Kernel File Systems.
[ OK ] Reached target Shutdown.
[1061865.715205] reboot: Restarting system
DDR version 1.06 20170424
In
SRX
LPDDR3
786MHz
Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB
ddrconfig:7
OUT
Yes, I am using Debian stretch. I also suspected that it could be serial cable connected. But when I connected the WiFi dongle, log-in with SSH as rock64 user and then to the root. Still I could reproduce this issue.
I wonder, why the above log doesn't show the "INFO: PSCI Power Domain Map:". Does it change between different OS (Debian/Xaniel etc..).?
Hi pfeerick,
We have contacted the Longsys (FORSEE eMMC support company) regarding this issue and provided the FORSEE eMMC model (NCEMAD6B-16G - from Pine64 website). The LONGSYS responded that this model was End of Life and it may be signal compatibility issue and was asked to change the MODE to SDR50. Can you please somebody provide some pointers how to change the mode. I observed the mmc command in uboot to set several parameters, but not the MODE. Also checked the documentation (/Documentation/devicetree/bindings/mmc/mmc.txt) provided a parameter (sd-uhs-sdr50) in .dtsi file. But I am not sure about correct procedure. Can somebody provide some info about how to change and achieve this.
And one more information is that LONGSYS recommended another model of eMMC recommended (NCEMAD9D-16G) and I am not sure about that we need to change the MODE for this model too. I requested the same info with LONGSYS, I will share more details once I received the response.
Thanks,
Ramprasad
06-20-2018, 04:47 PM
(This post was last modified: 06-21-2018, 01:14 AM by pfeerick.
Edit Reason: reply was lost in quote
)
(06-15-2018, 08:26 AM)ramprasad Wrote: Hi pfeerick,
We have contacted the Longsys (FORSEE eMMC support company) regarding this issue and provided the FORSEE eMMC model (NCEMAD6B-16G - from Pine64 website). The LONGSYS responded that this model was End of Life and it may be signal compatibility issue and was asked to change the MODE to SDR50. Can you please somebody provide some pointers how to change the mode. I observed the mmc command in uboot to set several parameters, but not the MODE. Also checked the documentation (/Documentation/devicetree/bindings/mmc/mmc.txt) provided a parameter (sd-uhs-sdr50) in .dtsi file. But I am not sure about correct procedure. Can somebody provide some info about how to change and achieve this.
And one more information is that LONGSYS recommended another model of eMMC recommended (NCEMAD9D-16G) and I am not sure about that we need to change the MODE for this model too. I requested the same info with LONGSYS, I will share more details once I received the response.
Thanks,
Ramprasad
Any pointers to change eMMC bus speed mode?
|
