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 will I be able to field upgrade my application once the system is in the field?

Field upgrades can be performed locally or remotely.  Locally would require updates to be performed 
using the 'USB autoflash' mechanism.  Remote updates would require the image files to be copied to 
the appliance's RAM or SD card and then flashed to its internal flash using the 'warploader' tool.

How do I return the appliance due to hardware failure?

Please refer to the RMA procedure outlined on the Pika website.  


What kind of tracing (developer) and logging (service technican) exists?

All traditional Linux logging mechanisms are generally available here. The logs themselves can be 
sent several places - for example over ethernet using syslogd to a remote pc or to SD card. 
Finally, during development our telephony functionality has full logging capabilities. 

What kind of remote interface for maintenance purposes is provided for analog and digital trunks ?

Maintenance through network access via SSH is possible. However there is no built in 
modem functionality allowing maintenance of units without network connection (for 
example, PPP).  One alternative could be to add a usb modem. 

For deployment how do I burn multiple boxes?

There are many options here.  

However likely the easiest method is the autoflash mechanism.  The autoflash mechanism allows 
users to insert a USB key (or SD card) and automatically re-burn their appliance.  
To give more details, using the autoflash mechanism users have a USB key with new software 
image files and a 'autorun' script.  The autoflash mechanism automatically runs a script 'autorun' 
(if present) on any USB flash key plugged in to the appliance. This 'autorun' script typically triggers 
the burning of the image files on the USB key automatically for users. An example of this script can 
be found at '/package/autoflash/autorun'. For more information on this mechanism 
please refer to the PADS User Guide and search the term 'Flash NAND from USB key'. 

The PADS User Guide document can be located at www.pikatech.com/appliancedownloads 

Pika can alternatively load images on Warp appliances and ship them.  However this option is only available to customers shipping in large volumes and there would typically be a fee associated with this.  Please contact your sales rep for details.  

What are some remote upgrade considerations?

The largest consideration is ensuring remote access to the appliance.  If using a remote updating 
mechanism the installer should ensure that the appliance can be accessed externally.  For example, 
does the router block certain ports that are used for updating?  

The workaround to this problem is largely up to the developer.  Ports used for accessing the appliance 
can be opened.  Alternatively, one common method is to install an appliance which then breaks 
through the on-site firewall to a central server and then sets up a VPN.

How do I ensure that customers do not change the software on the unit?

The designer of the solution should ensure the complete security of the unit.  

However the appliance is however is well suited to remaining static for customers due to 
its large portion of read-only memory which largely stunts users from changing files.

Is there a way to set a Warp back to factory defaults?

There is no button sequence to revert the Warp back to defaults.  


You can revert the Warp back to defaults by re-burning prepared image files available 
at www.pikatech.com/appliancedownloads.  

This can be done remotely by putting the prepared image files on a USB stick along with a 'autorun' 
script and take advantage of the 'autorun' capabilities.  For more information on this 
mechanism please refer to the PADS User Guide and search the term 'Flash NAND from USB key'. 

The PADS User Guide document can be located at www.pikatech.com/appliancedownloads 


Unfortunately, the only way to recover from a kernel that will not boot is to re-flash the unit via 
uboot/serial cable. To do this: 

1) You will first need to have a tftp server setup on your development PC. Consult the 'PADS 
User Guide' under the section 'Development System Setup and Configuration' > 'Setting up TFTP' 
to see how to set this up in Linux or on web to see how to set this up in Windows.

2) Copy the image files (ie. cuImage.warp, uRamdisk and image.jffs2 files) to the tftp folder on 
your development machine. For example, usually '/tftpboot' in Linux.

3) In uboot on the appliance, set up the appropriate 'ipaddr', 'gatewayip', 'netmask' variables to 
help identify your appliance on the network. As well, set the 'serverip' variable to point the appliance 
to the ip address of your development PC.

4) When tftp is properly setup you can then begin to burn new images to the appliance. This can 
be done in uboot using the 'update' command. See 'help update' for examples or see below:

update kernel cuImage.warp
update ramdisk uRamdisk
update persistent image.jffs2

(You don't necessarily have to reboot in between each of these commands.)

This should hopefully restore your system. 

Is there a limit on how many times I can burn images to my warp?

Theoretically you can burn images to the Warp up to 100,000 times.  

How can I communicate and transfer files to Warps in the field? Is encryption available?

Transfers are typically done via Internet.  The Pika API does have some modem 
options however transfer speeds are slow and the modems are not necessarily 
the common ones you would expect.  For example, v90 is not supported.  

If the transfer is done via Internet then you have several options for encryption 
as there are various open source packages and options available to be loaded onto 
the appliance.  Certainly the basics like SCP through SSH and FTP is available as 
well as some more advanced packages such as 'vtun' for encrypted tunneling.  
All of these are available as integrated PADS packages.  However, the appliance is 
a programmable development platform so many software packages can be added.  
Really the only limitation in the regard of secure transfers is CPU processing power 
to handle heavy encryption algorithms.

How do I tell the SD card is inserted correctly?

The SD card can be tricky to insert properly as it is spring loaded and requires to 
be recessed into the unit.  To verify that it has been properly inserted you can use 
the following command 'cat /proc/driver/pikasd'

Also to note, the SD card will automount when inserted.  Both ext2 and fat cards will 
be recognized.  It is also important to remember to perform a 'sync' and 'umount' of 
the SD card (like done in /etc/rc.0) before physically removing it so no data corruption 

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.