Hm... I have one Pi that does this. The very first Pi I bought, from the original first 10K batch.
I've tried the same SD card in other Pi's and the reboot fine, tried other SD cards in this Pi and it doesn't reboot fine, but almost always needs a power cycle.
That Pi was somewhat used and abused in the early days - over volted, overclocked... I tested its GPIO to past when I thought the magic black smoke ought to come out, (35mA out a single pin, rebooting it by shoting GPIO pins to 0v in output mode), accidentally fed 5v into the pins - maybe I've done somthing internally that causes it, who knows... The Pi still works fine, as does its GPIO, it just won't reboot most of the time and needs a power cycle.
Interesting. That may also explain a problem I had with a dual-boot desktop machine a couple of years ago. When switching from Linux to Windows Vista (or vice versa, I can't remember which) the sound would go dead if I did a software restart. A power off/power on cycle would cure the problem.
Moving to Windows 8.1 and/or Linux Mint 17 cured it.
Like Gordon Henderson's Pi this one is very old and has had some abuse. I suspect the DVB tuner stick's driver also.
That should mean that it expects *nothing* of the hardware. Unless there is a power on hardware reset, registers can assume any value on power on. If there is a power on reset, the soft reset needs to have a way to assert that reset. If that can't be done, the hardware is faulty and can't be counted on to ever soft reset properly.
I'm not clear about your point. There are any number of CPUs with a pin for reset that is bidirectional. It can be asserted by hardware on the board such as a reset controller, or it can be asserted by software in the CPU. That is my point, this is the right way to do a soft reset.
On the other hand, it has happened more than once that a chip has not been designed properly so that the reset does not fully reset all the internal state. In that case the portions that are lacking a power on reset need special consideration from the software if even that will fully reset the chip. It's called a bug and even hardware can have them... just not as often as the software.
I am wondering why you want to turn a discussion into a personal statement.
It can't. But when a CPU *can* reset itself from software the proper way to do it is to assert a hard reset.
What's your point..?
If the CPU is lost in the weeds there is *no* way to assert a soft reset, no? So what is your point?
You aren't making sense. You talk about being lost in the weeds and then talk about the CPU being able to perform a soft reset.
The point is that sometimes chips are not designed so that every FF can be accessed from the control interface. I have seen any number of boards that can not be fully reset from software because of problems with the chips and poor reset design. That is a fact.
Only a guess, but I suspect that "sudo reboot" shuts things down safely then zeros the program counter, restarting the OS. A power cycle is much cruder and doesn't shut anything down safely or otherwise. Have you tried the reset input?
It is correct what he wrote. E.g. a 68000 CPU has a RESET instruction that pulls down the RESET* for some time (100 clockcycles or so) and then executes the normal CPU reset sequence, what it also does when something external pulls down the RESET* line.
This instruction would be executed as part of a "reboot" systemcall in the operating system (it is of course a privileged instruction).
Doing it this way makes sure that all hardware gets a reset signal as well, and you don't have to rely on the BIOS and Driver code to be written very carefully for each device to be reset and initialized from a completely unknown state.
I don't know how the Raspberry Pi handles this form of reset, but it does have a watchdog. When you want to reboot you can arm the watchdog and not trigger it, and a few seconds later it gets a hard reset.
I will try if the Pi I have at home that will not survive "reboot" will recover when I reset it that way. I want to know, because I have a Pi in colocation that I don't dare to reboot now. (someone else who has a Pi there has done "reboot" two times now and two times had to call the operators to powercycle it)
Most (or maybe half?) of the rpi-updates I do result in non-responsive RPi on reboot, requiring a power cycle. When I look at the LEDs it seems to be all right except there just isn't an ethernet connection. Wondered if it was a power issue but same trouble after switching to a 2 A quality adapter. Sometimes, and I have no idea why, it requires TWO power cycles. So far, everything always worked again after at most two hard boots. So now I try & avoid rpi-update. But improvements listed at
do seem useful sometimes.
Maaaaaybe it's a router problem. AVM Fritzbox not exactly known for bug free firmware :(