Boot process hangs about 33% of the time.

[nmontmarquette]

I am using the A20 in my project booted from a micro SD card with the Debian many of you use. I'm using the following kernel:

Linux 3.4.67+ #6 SMP PREEMPT Fri Nov 1 17:32:40 EET 2013 armv7l

Recently added extra gears, the Olimex A20 won't boot about 33% of the time. I've narrowed down to either ttyS1 or ttyS2 although I didn't confirmed exactly which of the the two.

Using the ttyS0 debug port, it seems that many of the locked-up-boots occur around 20-25 seconds, right after initialization of the Mali video driver ( although I doubt it's actually related )

The service that uses ttyS1/ttyS2 starts before rc.local talks to the S1 and S2 serial ports. I didn't noticed any anomalies from using those two ports from post boot operations, although they they cause lock-ups at boot.  I could simply make a  patch to ensure I'm not interacting with S1 or S2 until the system is fully booted but I would like to get to the bottom of this issue.

Also, is the root FS I have, rc.local contains the following lines which I don't fully understand but feel they might be related to my problem:

chmod 777 /dev/disp /dev/cedar_dev /dev/ump /dev/mali
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 408000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

[MBR]

Also, is the root FS I have, rc.local contains the following lines which I don't fully understand but feel they might be related to my problem:

chmod 777 /dev/disp /dev/cedar_dev /dev/ump /dev/mali
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 408000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

The first line adjusts permisions on varisous files related to GPU. BTW, it's a quick&dirty way, the better would be to write udev rules.

The second and third lines are adjusting frequencies for the dynamic scalling, the second adjusts the maximium, the third the minimum. See man cpufreq-info and man cpufreq-set.

[BMK]

I had an A20 behave this way, Turned out to be a supply voltage problem. Power supply current rating was too low. Once the LCD comes up, the current draw would increase enough to cause a voltage drop and crash.

[MBR]

If is it really a supply voltage problem and you cannot change your power supply for a better one, try the approach described in my older post, see https://www.olimex.com/forum/index.php?topic=3737.msg15806#msg15806.