Here you can find answers to questions about how the board works. Use the links or search box below to find your way around.

How to debug a hardware issue as shown by the red LED staying lit on the WARP.

Problem Description:
When a WARP boots up, the red LED stays on.

Problem Cause:
The red LED staying on signifies that one of the hardware tests during u-boot 
initialization failed.

Problem Diagnosis:
In order to see what piece of hardware is causing the error, you will need to 
have a serial connection to the WARP. With the serial connection ready, boot 
the WARP. When it gives you the option to interrupt the boot process, do so. 
At the command prompt, type the command log show. This will print a list of 
all the hardware tests performed, see below. Any test that fails will be clearly 
marked with an error as opposed to the word passed.

Hit any key to stop autoboot:  0
=> log show
<4>POST: cpu passed
<4>POST: i2c passed
<4>POST: cache passed
<4>POST: fpu passed
<4>POST: dma_lb passed
<4>POST: memtest passed
<4>POST: ethernet passed
<4>POST: onboard_fxs passed
<4>POST: audio_port passed
<4>POST: modules_test passed
<4>POST: temp_test passed
1.	Any information on failed u-boot tests is not logged or available in the Linux OS on the WARP. 
2.	The log data that is stored by u-boot is cleared once the WARP boots into the Linux OS on it.
3.	The log data that is stored by u-boot is cleared once the WARP is powered off.
4.	The log data that is stored by u-boot is NOT cleared by hitting the CPU reset button.

Problem Examples:

The failure on the Ethernet is usually caused by a missing or incorrect parameter 
in u-boot. In order to diagnose this problem review the network setting in the 
u-boot parameters. This is obtained by doing a printenv at the u-boot command 
prompt. Look at the output and ensure that the networking parameters are all there 
and contain reasonable values. If for example, the ipaddr variable is missing, then 
the Ethernet test will fail. Note this is only a boot up test failure though and when 
you enter the linux OS on the WARP, the Ethernet will likely be working perfectly.

This could be caused by a faulty module, but in all likelihood the module is just not 
seated correctly. Remove your modules and reseat them in the WARP, making sure 
to screw them in.

Can I use ‘ping’ in u-boot?

Pinging from uboot to a PC is possible as long as you ensure you have a 
valid IP address set.
However the IP stack is limited, so uboot does not respond to ICMP packets (ping); 
thus pinging an appliance stopped in uboot is not possible.

I plug my BRI module in and it is not detected. And it does not show up on the LCD.

First, ensure you are running the correct version of firmware.  You can do this by 
attaching the serial cable and noting the fpga version when the unit is booting.  It
must be 2.0.x.x or greater.

FPGA download … complete.

FPGA code revision

Secondly, ensure the module is correctly seated.

The pikabrie kernel module does not load and fails with an error.

The error that is being seen is the following:

pikabrie starting...
pikacore: registered 253.2
  BRI in module A
Unexpect id ff rev ff (0)
pikacore: remove 253.2
insmod: cannot insert
'/lib/modules/': No such device
modprobe: failed to load module pikabrie

We have seen this type of error in the past due to two possible reasons.  

1) First please ensure the module is properly seated.  Although the modules are 
keyed, in some instances we have seen that the keying gets pushed up and the 
modules can be plugged in off-set ("one pin off").

2) After confirming the modules seating, please ensure the module is screwed 
into the baseboard.

SIP hints does not work on my Warp.

By setting the call-limit value in users.conf is one requirement for hints to work. By default 
you can see the status change (using show hints) on the incoming SIP phone, but not the 
outgoing. Setting limitonpeers=yes in sip.conf general section however also makes this work.  

More details can be found here: 

Without limitonpeers set you get this:

warp*CLI> sip show inuse

* User name               In use          Limit
4007                      1               1
4006                      0               1

* Peer name               In use          Limit
4007                      0/0             1
4006                      1/1             1

and with it set

warp*CLI> sip show inuse

* User name               In use          Limit
4007                      0               1
4006                      0               1

* Peer name               In use          Limit
4007                      1/0             1
4006                      1/0             1

This assumes that hints have also been properly set in extensions.conf like the following:
exten => 100,hint,SIP/peername

Additional information can be found at http://www.voip-info.org/wiki/view/Asterisk+presence

Why do I not see anything on the LCD when I remove Asterisk?

A sample LCD implementation is included in the Pika channel driver intergrated into Asterisk.  

This implementation shows the telephony port status on the screen.  Pressing the toggle button
to the right of the LCD screen once will display the IP address of the unit.  Pressing the button 
three times in succession will reverse the orientation of the LCD 180 degrees.

When Asterisk is stopped or removed the code that controls the LCD is also stopped.  
However code using Pika's LCD API can be added to controlled and customized the
LCD outside of Asterisk.  A sample of this code can be found @ pikawarp.org

How can I determine the state of pika channels in Asterisk?

In the Asterisk CLI you can use the following command:

pika show channels

I am seeing low audio on my analog lines in Asterisk.

The first thing to try is enabling Adaptive Gain Control (AGC).  This can be done by setting 
'useagc' to 'yes' instead of 'no' in '/etc/asterisk/pika.conf'.

How can I tell if Pika's drivers are running properly?

First, you can do a 'lsmod' on the Linux command.  The result should look something like this:

Module                  Size  Used by
pkdummy                 3720  0
zaptel                192852  1 pkdummy
pikalcd                21296  0
pikataco               41996  0
pikahsp               433728  2 pkdummy,pikataco
pikacore                4496  3 pikalcd,pikataco,pikahsp

Secondly, you can ensure the device nodes are created by using the command 'ls -l /dev/pik*'

Finally, you can use 'dmesg' to see logs.

I am hearing choppy audio on my lines.

First, ensure that logging is disabled on the unit.  

Secondly, run 'top' to determine the CPU usage of the unit.

How do I turn on and off Pika logging?

Pika logs can be enabled by changing 'logs=none' to 'logs=debug' under the heading 
'[logs]' in the files '/etc/pika/pikagp.cfg' and '/etc/pika/pikagp_aoh.cfg'  

The resulting logs will appear in sub-folders in ‘/var/log/pika/’.
(Please note that logs on the Warp are capped at 1 Mb so it is typically a good idea to 
clean '/var/log' before debugging.)

However, be aware that enabling full logging for long durations or using mulitple active 
channels will be extremely CPU intensive and will likely result in poor audio quality so it 
is recommended that you selectively choose what logging areas you select.

To do this you can add the following lines to the specific configuration files and 
uncomment the area you would like to log:  A ';' character at the start of a line
represents a comment.

In /etc/pika/pikagp.cfg
api=0x18  ;(0x2 - system, 0x4 - group, 0x8 channel, 0x10 - call, 0x20 - conf)

In /etc/pika/pikagp_aoh.cfg
api=0x4000000  ;(see pkh_log.h for the meaning of the bits)
object.trunk=0xffffffff  ;to log trunking actions

Pika logs can be disabled by setting the fields back to 'logs=none' and commenting
out the subsections.  

How can I set individual caller id to fxs ports?

In general this explanation describes how to combat the pika.conf file from being 
overwritten and how to set individual caller id per fxs.  Below is the basic idea:

In /etc/asterisk/pika.conf:

#include pika_fxs_incl.conf

In /etc/asterisk/pika_fxs_incl.conf:

mailbox = 101
context =
callerid = "101" <101>
channel = 1

mailbox = 102
context =
callerid = "102" <102>
channel = 2

mailbox = 103
context =
callerid = "103" <103>
channel = 3

Additionally this requires modification to the startup scripts (like rc.local) to search on 
"channels" and "groups",  remove this and replace it with "#include pika_fxs_incl.conf".  As 
you can see this method bypasses the channel/group definitions portion of what pikacf 
produces.  It allows a clean way to overwrite the automatic creation of defaults.  As well, 
the most recent version of software (1.1) re-writes the port indices on hardware changes - 
like adding or removing a module.  The above method attempts to combat this by having the 
advantage of staying static if the hardware of the system changes.  
You could apply the same change to the 'fxo' definition in the pika.conf file.

When burning an image I get the message - 'No space left on disk'.

First, please note the location that you are copying your image files to.  If copying to 
'/tmp' please note this is mounted to tmpfs and is currently capped at 36 Mb.  Typing 'df' at 
the console will display this.  If copying to 'persistent' please observe how much room is 
left on this partition.

To workaround this a) the size of the image can be reduced or b) the location the image file 
is copied can be modified or c) tmpfs can be increased through '/etc/fstab'.

What do these NFS errors mean?

Some common errors:

If you receive an timeout error when running 'run net_nfs' followed by a 'Bad Magic Number'. 
Please ensure that your cuImage.warp is loaded into your tftp folder on the Host PC and tftp 
is started. 

'net_nfs' loads the core kernel image (cuImage.warp) from tftp and then mounts the ramdisk
from a mount point on the Host PC. 


If you receive something like ... "Root-NFS: Server returned error -13 while mounting 
/home/mark/pads/pre-ga2/builtVFS: Unable to mount root fs via NFS, trying floppy. 

Check your path to the mount point set in 'rootpath' in uboot as well as the path in your 
/etc/exports file on the Host PC (development machine).

How do I change where logs are produced?

By default, logs go into '/var/log'.  And keep in mind, there is only 1M of space in /var/log.

If you wish to change this, set the environment variables as described: 

In the file /persistent/autorun/S40hmp, change the following line: 


export PKH_LOGS_DIR=   (something like /persistent2/logs for example)

In the file /persistent/autorun/S44chan_pika, change the following line: 



export PKX_LOGS_DIR=   (something like /persistent2/logs for example)


I am receiving a Bad CRC error when booting.

Symptom: After loading a new image with warploader, the console displays the following:

## Loading RAMDisk Image at 02200000 ...
Image Name: PIKA Warp 1.0.0-222
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 44368879 Bytes = 42.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... Bad Data CRC
Cause: Uncompression size is most-likely too small or the image file is corrupted.

Possible Solution(s):

a) To resolve use the serial cable to access uboot.  In uboot, check the output of the 
following line and observe the last parameter:

printenv load_nand_ramdisk

It may be necessary increase the last value of this line to 3000000 (or 3400000) like below.
==> setenv load_nand_ramdisk nand read.jffs2 2200000 200000 3000000
==> saveenv
b) Try rebuilding the image.

Search FAQ

Select this option if you would like your search to look in the text of FAQ items as well as their titles.

Select an option here to specify how you would like your search query to be treated. 'Any words' will return the most numerous but possibly least relevant results, while 'Complete phrase' will return only results that contain exactly what you are searching for.