True cold restart

Another one. Very annoying.
I still run into troubles when rebooting my PandaBoard. Not always, but sometimes, especially after the use of some specific software.

It seems that memory and hardware is not reseted. Proof: time is still the right one, without RTC and network :)
Problem is that the Pandaboard refuses to boot, or boots, then applications crash.

Is there a way to create a tool that would be used at reboot (when clicking on the dialog or when calling reboot swi), to clear all memory and caches? It could be cool too to wait a few seconds, just to be sure that temperature is OK. OMAP goes very hot when inactive, but still powered (a strange bug). Then firmware can block the reboot. Of course, the timer could depend of current temperature (wait for 60° then reboot, or reboot after 10 sec.). It will be good for the OMAP lifetime.

I still run into troubles when rebooting my PandaBoard. Not always, but sometimes, especially after the use of some specific software.

Glad you mentioned that as I’ve been suspecting the same issue on the Pi. I now power it off instead of warm booting, as after a reboot software doesn’t always behave the same as you’ve noticed.

I was under the impression memory is cleared on boot, but the boot sequence does have subtle differences between soft boots – DHCP randomly failing, errors about files existing, random hangs at the desktop as apps are loading. I just put it down to the combination of running nightlies and using it as a dev machine, and have never used an RC to get a meaningful comparison.

Time I believe is stored in the ROM to keep it between boots – not quite sure why it does that as it’s still wrong until it syncs with an NTP source. LOL – I spent an hour the other day trying to figure out why code I was copying across wasn’t updating, it was days out – only to realise the time hadn’t synced and FTPc was stamping the files with the current time and not the original file time!

Issues I’ve noticed between warm boots include:

1. You randomly can’t copy files over the top of each other without deleting the original first, it refuses to copy as if the original is protected
2. Random hanging at the desktop
3. FTPc connection issues – could be an issue in FTPc though as PING seems to work

Yes, many of my files are now stamped with a 2100 date. A problem for updates.
With wrong date, SSL will be a problem too.

IMHO, it’s really important to fire the network stack first, then to synchronise time… the two before everything else.
If no network, to be able to change the date and time before other boot operations would be great too.

It seems that memory and hardware is not reseted. Proof: time is still the right one, without RTC and network :)

The PandaBoard does have an RTC, but it doesn’t have a battery fitted by default (in fact I’m not even sure if the PCB design allows for you to fit one?). Even if there’s no battery, RISC OS will use the RTC, because it is a handy way of making sure the time is correct if you reboot.

Apart from the problem with it not liking some SD cards, the only reboot issue I know of with OMAP4 is that it will sometimes turn off instead of reboot. Possibly we could fix it by changing the reboot method we’re using – it’s possible to create scripts which run on the power management chip and control the timing of the reset signals, power supplies, etc.

I can’t say I’ve noticed any issues on the Raspberry Pi – although I think most of the time I just pull the power, whether the machine has hard-locked or not. Not sure if that’s due to paranoia or laziness (probably paranoia – I’ll pull the power before removing the SD card to write a new ROM)

RISC OS will use the RTC, because it is a handy way of making sure the time is correct if you reboot.

Hum, I see…

the only reboot issue I know of with OMAP4 is that it will sometimes turn off instead of reboot.

After big problems on RISC OS, most time, there are still here after a reboot, as if still somewhere in memory :)
Basically, clean system reboots to clean system, and crashed / partially crashed system reboots to the same state.
The same on my 3 PandaBoards.

For this time, the problem was not exactly the kernel. Believe me or not, but with a cold boot, WebJames needs less memory. Probably because there are no people knocking on the socket door (or something like this). So with hot reboot, abort and data transfer are present, if I don’t wait several minutes between reboots. A massive grow of the Wimpslot of WebJames (1000 > 8000 KB) solves the problem. I also change buffers (1024 → 4096 KB) and caches (4096 → 262144 KB). I hope it will speed up things a bit.