Here you can find answers to questions about how the board works. Use the links or search box below to find your way around.
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 => NOTES: 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: Ethernet: 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. Modules: 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.
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.
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 2.0.2.0 Secondly, ensure the module is correctly seated.
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/2.6.26.5-pika/kernel/drivers/char/pikabrie.ko': 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.
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: http://www.voip-info.org/wiki/view/Asterisk+standard+extensions 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
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
In the Asterisk CLI you can use the following command: pika show channels
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'.
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.
First, ensure that logging is disabled on the unit. Secondly, run 'top' to determine the CPU usage of the unit.
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 ------------------------------------------------------------ [logs] level=none api=0x18 ;(0x2 - system, 0x4 - group, 0x8 channel, 0x10 - call, 0x20 - conf) object.channel=0xffffffff object.call=0xffffffff product.channel=0xffffffff ;object.system=0xffffffff ;object.group=0xffffffff ;object.channel=0xffffffff ;object.call=0xffffffff ;object.conference=0xffffffff ;product.protocol=0xffffffff ;product.sipuser=0xffffffff ;product.board=0xffffffff ;product.dsp=0xffffffff ;product.span=0xffffffff ;product.conference=0xffffffff ------------------------------------------------------------- In /etc/pika/pikagp_aoh.cfg ------------------------------------------------------------- [logs] level=none api=0x4000000 ;(see pkh_log.h for the meaning of the bits) object.trunk=0xffffffff ;to log trunking actions ;object.system=0xffffffff ;object.queue=0xffffffff ;object.timer=0xffffffff ;object.mediastream=0xffffffff ;object.rtp=0xffffffff ;object.board=0xffffffff ;object.span=0xffffffff ;object.hdlc=0xffffffff ;object.process=0xffffffff ;object.conference=0xffffffff ;object.confmember=0xffffffff ;object.sip=0xffffffff ;object.isdn=0xffffffff ;object.phone=0xffffffff ------------------------------------------------------------- Pika logs can be disabled by setting the fields back to 'logs=none' and commenting out the subsections.
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: ... [fxs] gp_group=1 conf_ref=PHONE_26800250 extension=s accountcode=fxs_grp cancallforward=no callforwardon=*72 callforwardoff=*73 lcterm_fxs=yes callwaiting=no calltransfer=yes immediate=no mailbox= callerid= echocancel=yes echotaillength=64 echosuppression=yes comfortnoise=yes echologging=no usecallerid=yes faxdetection=yes musiconhold=default language=default amaflags=default canpark=no txgain=0 rxgain=0 useagc=no agc.in.enable=no agc.out.enable=no agc.in.targetLevel=-15.0 agc.out.targetLevel=-15.0 agc.in.minGain=-6 agc.out.minGain=-6 agc.in.maxGain=18 agc.out.maxGain=18 agc.in.attackRate=170 agc.out.attackRate=170 agc.in.decayRate=750 agc.out.decayRate=750 agc.in.speechLevel=-36 agc.out.speechLevel=-36 #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.
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'.
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).
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=SYSLOG to 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=SYSLOG to export PKX_LOGS_DIR= (something like /persistent2/logs for example) Reboot.
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.