Reset bug 09/04/12 ROM

With today’s ROM release (09/04/12), if the reset button is pressed the BB -xM won’t restart. I went back to the 06/04/12 release and this does restart on reset so this is a new issue.

I can’t seem to recreate the problem here. Is there anything in particular you’re doing before hitting the reset button?

Are you powering the board via USB or via an adapter? If it’s powered via USB, maybe running at 1GHz is pushing it over the limit a bit.

OK, I’ve seen it happen now. But it was the one time I didn’t have the serial terminal running so I could check the output. Doh!

It’s running from a 5V supply adapter, all else (HDD etc.) from a powered USB hub.

Once it’s in the desktop I just close down as usual from the task menu then press the reset button on the BB rather than the on-screen restart option. It fails to reach the orange display.

Hmm, that sounds like it could be a different issue. With the issue I’ve found it hangs after the orange screen, while initialising RO. And so far I haven’t had any luck recreating it from following your repro steps.

Maybe I should try different x-loader/u-boot versions. Do you know what versions you’ve got?

It’s the ones that came with my revision C BB -xM, if that helps. Otherwise I don’t know how to tell. They’re dated 19th April 2011.

Experimenting a little today I found I can get different reactions from the BB, though the results are seemingly random.
I held down the reset button for a few seconds and letting go got me to the orange screen but no further. I wasn’t able to repeat this.

I did find that after pressing the reset button usually the USR0 & USR1 LEDs lit together as expected but sometimes only USR0 lit or none at all. I don’t know if any of this is relevant but I wonder if there’s something marginal going on here, thus not in common. This is pressing the reset with the 9th April ROM in.

As I said, previous ROM versions up to 6th April work fine.

On Wednesday at the SAUG meeting, Andrew Conroy reminded me to try reset on my BBxM, which has the April 9th ROM. Reset did not succeed in booting. We tried it twice.

OK, thanks for the info. I did try using the 19th April x-loader/u-boot, but couldn’t recreate the issue, so I’m guessing it must be down to a difference between the rev A and rev C hardware. I’ll have a look through the docs and newsgroups to see if I can find anything that could explain it.

I’m using a revision C BB-xM and the ROM dated 10/04/2012.
I’ve tried resetting it several times and it’s worked each time.

My x-loader/u-boot is dated 19/04/2011.
I’m also using a CMOS Widget. (Not sure if this is relavant)

I’m also using a CMOS widget.

Tried a different SD card (I normally rotate so I can write from the BB) with the same result. Starts fine at power off/on but not reset.

Today’s ROM, 17th April, still suffers from the hard reset problem on my BB xM though it’s slightly different in behaviour. Now all LEDs light consistently and I get either a blank or orange display. So it still fails to start but does so in a more consistent way than the 9/4/12 version. As before, it will start normally on a power up.

[Edit] Not quite true. Further attempts show previous LED behaviour. Soft restart works fine.

Exit desktop causes the BB -xM to hang on a blank grey display. Pointer still working. CTRL-Break takes the BB back to the orange start up display where it hangs.

With the ROM from 6/4/12 the same thing happens except that CTRL-BRK takes the BB back to the orange display from which it boots normally.

I’m not entirely sure if this code is working properly, but try running this BASIC program and then seeing if the board will reset properly. It should configure the power management chip to reset itself when the reset button is pressed (the default state seems to be for it to do nothing – only the OMAP gets reset). If it works then I should be able to add the code to the ROM image.

Doesn’t seem to make any difference I’m afraid.

OK. I guess I’d better do some more research then.

I’ve uploaded a new program in the same location – can you give that one a shot? I found the bug that was stopping it from working, and tweaked it a bit more to make it follow the reset procedure that TI suggest.

I’m not sure, but I think you need to re-run it after each reset in order for resets to continue to function.

Yup, it works! I’ve reset the BB several times without re-running the program so only once is required. Cool.

No orange screen, blank then to boot. Is that normal? I can’t recall.

No orange screen, blank then to boot. Is that normal? I can’t recall.

It’s not the same behaviour as before, but I don’t think it’s anything to worry about. I guess it wouldn’t hurt for me to look into it though. Then I’ll start working on getting the new code added to the HAL.

It’s not the same behaviour as before, but I don’t think it’s anything to worry about.

No, everything else seems fine AFAICT. That’s why I wasn’t sure if there was an orange screen on reset before.

I’ve checked in the HAL changes that are needed to perform the “twlscript” functionality on boot. I did have a quick look through the x-loader and u-boot source for anything that might explain why the orange screen doesn’t come up after a reset, but I couldn’t find anything obvious, so for the moment that’s being left unfixed.

I think the autobuilder is down at the moment, so I’ve uploaded a new ROM here containing all the latest changes from CVS.

(Sorry if this is the wrong thread)…

The build you uploaded is the first 5.19 I’ve tried for a while – wanted to wait for the reset thing to be dealt with.

I’ve noticed a change in how it seems to boot up – still quite length despite the memory changes (at least for me).

Basically it seems longer before the monitor wakes up.

Previously, I’d power on, wait a while, then the keyboard would light up, and a couple of seconds later the monitor
would wake up, and gradually things would progress to the “RISC OS 512Mb” text. Then there would be a pause and boot
would start.

Now, I power on, and after a little while (maybe 10 seconds), the keyboard and mouse light up. Then they “go dark” for
a while. Then after another 10-15 secs they light up again, and shortly after the monitor comes on and the pre-desk is
flyingthrough.

Has something changed regarding the video init, and hence the monitor doesn’t wake til later?

Edit: Question – could the be anything to do with the fact that the rom images are now 2Mb not 4Mb? ie. is it
lighting up first once the ROM image is uncompressing?

Has something changed regarding the video init, and hence the monitor doesn’t wake til later?

Nothing’s been deliberately changed. In fact the optimisations mean that the monitor should come on a bit quicker than before. However while testing the reset fixes on my touchbook last night I noticed that the startup did seem to take a bit longer than I was expecting.

I’m tempted to blame the USB drivers; I think there’s quite a few delay loops in the device discovery/enumeration code where it waits for the prescribed amount of time after resetting each device. This was easy to spot with the hub I was using, where the lights on each occupied port were coming on one at a time, with a significant delay between each one. If I can work out how to split up that processing then that should result in a big reduction in boot time, especially since the enumeration gets performed twice (once for the keyboard scan, and again for the OS modules)

I also need to chase up Sprow to see what’s happening with the video driver; I want to fix the driver so that it enables the display straight away instead of on the first mode change. This should make it clearer that the machine hasn’t crashed on startup, and more importantly if a ROM module does crash on startup you should (hopefully) be able to see what the error was. But I think he said he was working on merging the OMAP3 and OMAP4 sources, so I don’t want to give him any merge conflicts to worry about.

Edit: Question – could the be anything to do with the fact that the rom images are now 2Mb not 4Mb? ie. is it lighting up first once the ROM image is uncompressing?

It’s true that the lights will first come on just before the ROM decompression starts, but ROM decompression is pretty quick (about 0.2s?), so that shouldn’t be the issue.

Yes, it may be telling that the machine in question had flash drive, DVD drive and SSD as well as external peripherals such as key/mouse.

Edit: Further findings – my personal machine which is a rev C xM, with an older hub, and 8Gb/CD setup seems to boot massively faster – no obvious “light up, light off, pause, light up” procedure. Instead, it just lit up and went. Most odd, and I’ll report more if I find it.

After looking at the USB driver sources it looks like there’ll be a minimum delay of 670ms per device. Considering that you’d usually have at least 5 devices (onboard hub, onboard LAN, keyboard, mouse, HDD) that adds up to quite a lot of time sat around doing nothing.

Luckily it’s only one function that’s responsible for 660ms of the delay, so it shouldn’t be too hard to split it up into several bits scheduled by OS_CallAfter. This will allow other things to get on with their initialisation while the USB devices are enumerated in the background.

Unluckily, the way the USB spec operates means that there might not be any way of allowing multiple devices to initialise at once. The problem is that when a device is first powered up by the hub, it will be responding to USB address 0, and will remain that way until the host assigns it a proper address to use. So if you have multiple devices which have just been powered on then there’s no way for the host to address them individually and assign unique addresses. I think the best I’d be able to manage would be to allow two devices to initialise at once if they’re on different host controllers.

We could also try reducing the durations of the delays (if we use USB spec timings we should only need to wait 122ms for each device), but that’s likely to be a far riskier game, as it will risk breaking any number of devices which aren’t fully compliant.