search

parallella / parallella-issues

Internal issue manager for Parallella
1 stars 1 forks source link

Boot process hangs with penguins displaying on screen #2

Open aolofsson opened 10 years ago

aolofsson commented 10 years ago

We are seeing some intermittent issues during the boot process. The board will get stuck at the penguins. This rarely (if ever) happens when the serial cable is plugged in, perhaps suggesting (according to Peter and Michael) that there could be a grounding issue.

Also per their suggestions, can we output some of the initial boot messages on the screen to allow for debugging without having the serial port connected?

kgugala commented 10 years ago

I did some research in that field and it seems that the Ubuntu init process hangs or fails during boot process. I have tested that using fake init program which was printing debug message before running original Ubuntu init. When the hangs occur I was seeing message and penguins but no more. I wasn't able to reproduce the problem when the console was set to tty1 (the one on the framebuffer) instead of ttyS2 (serial console). Maybe this is the solution - but it still needs more tests.

I'va added the devicetree source and blob with console set to tty1 to this repo. Please check it with your boards.

Fred3 commented 10 years ago

I've poked around with this too. Initially I thought it might have to do with crosstalk from TX into the open RX line, there is a significant amount of signal that comes back around at the J2 pins, but I could not see this when looking after the U5 receiver. Connecting only the TX->Laptop side of the link, leaving RX floating, shows the output from the boot process but it still fails regularly after the display is initialized (penguins) and before the boot messages should start to appear on the screen.

The only thing that seems to make a difference (without resorting to changing the console as above) is to drive the RX input high during boot. Not sure why this matters or why, if it does matter, it is not consistent. Note that 'high' at that pin is the normal idle condition, having the RX input pulled low as it is drives a "break" condition on the interface which could maybe cause an unexpected interrupt?? Just guessing here, but it seems something doesn't like that break.

Tying the RX input low with a jumper does not help, but it is possible to jumper the TX and RX together and it will boot reliably. However this is not clean because the console is then talking to itself like two kids: "Stop repeating everything I say" ... "Stop repeating everything I say" ad infinitum. Maybe this is harmless but it doesn't seem right. Removing this RX-TX jumper after boot works.