The problem:
Through an Android app, be able to programmatically verify arduino flash contents to ensure it has not been changed (maliciously)
I am able to do that with avrdude using the command as below in the android adb shell
avrdude -C/data/data/com.myapp.avrdude/local/etc/avrdude.conf -v -patmega2560 -cstk500v2 -P/dev/ttyACM0 -b115200 -D -Uflash:v:firmware.hex:i
This works well with arduino, but the problem comes in when I want to do the same with a board that uses an FTDI chip. When it's connected to the android device it does not show up in /dev/ location.
On a linux machine the arduino device appears as /dev/ttyACM0, and the FTDI device is /dev/ttyUSB0. The problem is the FTDI device does not appear on android therefore the avrdude command above becomes useless.
I do not want to build the kernel driver for FTDI as specified here
The approach I want to go with which I think is most viable is to find/build a simple java wrapper for avrdude that interacts with the usb device at a higher level, this way I can make use of the FTDI java library to execute a command to verify flash.
Is this approach viable? If not, what is the best way to approach this problem?
Looking at the FTDI site, it looks as though there may be a driver for some FTDI ICs: FTDI Android Driver
You may then well be building avrdude again in java ha.
I have used avrdude often when using arduino...mainly to remote re-format/upgrade firmware on a 3D printer from a raspberrypi...
I'd go
1) Look into the Arduino Driver...
2) if fail...Maybe try down the avenue of running C programs in java? So you can package avrdude with your app?
3) XY Problem -> Why not look at other avenues...The only way to really pop malicious firmware on is with physical access to the device and with a user that has the prior source code (you can set lock bits to prevent reading EEPROM). Even a timestamped and UUID 1024bit AES token/JWT like thing could be used on startup to verify the build?
https://en.wikipedia.org/wiki/Java_Native_Interface
building for JNI won't help while avrdude wasn't built with FTDI support.
I've downloaded avrdude-6.3.tar.gz and ran ./configure --enable-linuxgpio:
Configuration summary:
----------------------
...
DON'T HAVE libftdi1
DON'T HAVE libftdi
...
when looking for it:
$ sudo yum whatprovides */libftdi1
it gives me:
libftdi-devel-1.1-4.el7.x86_64 : Header files and static libraries for libftdi
Filename : /usr/include/libftdi1
sudo yum install libftdi-devel also installs libconfuse. it also needs flex and bison.
there are even drivers for D2XX and FT4222H.
see AN_357 Android D2XX Demo Application for FT4222H.
and there are builds for ARM libft4222-linux-1.4.1.231.tgz
... which would go into the jniLibs/armeabi directory.
it depends which chipset it is, but the TN 134 FTDI Android D2XX Driver states:
To accompany the native D2XX library, FTDI have provided a Java class and a JNI wrapper which can be
easily included in an application. The class provides access to all of the classic D2XX functions including
EEPROM functions.
it even comes with a video install guide.
also found the Arduino build-script for avrdude.
I have an IMX7 board from TechNexion. This is the board linked from the Android Things website as a supported board. On unboxing the board, I cannot connect to the device via Fastboot. I can access the boot prompt and default/shipped linux installation via a serial connection. It also connects via ethernet. But no Fastboot. I'd like to install the latest Android Things OS.
fastboot devices returns nothing. adb devices returns nothing. Rebooting adb has no impact. I've also tried starting Fastboot from the U-Boot prompt.
=> fastboot
Unknown command 'fastboot' - try 'help'
The documentation implies it's installed on the device.
I'm running the latest Android platform tools (26.0.0) on a Mac (10.12.6).
I don't have much experience with Fastboot or hardware, but I have connected to a few other boards without any problem. Any ideas appreciated.
EDIT: below is the output as seen from the serial connection. This is the bootloader output, and then also the initial part of the Linux boot sequence.
MMC: FSL_SDHC: 0, FSL_SDHC: 1
No panel detected: default to MCIMX28LCD
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc1(part 0) is current device
Net: FEC0
Warning: FEC0 MAC addresses don't match:
Address in SROM is 00:1f:7b:86:2e:3f
Address in environment is 00:1f:7b:aa:01:32
Normal Boot
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1(part 0) is current device
switch to partitions #0, OK
mmc1(part 0) is current device
reading boot.scr
** Unable to read file boot.scr **
reading zImage
5726824 bytes read in 149 ms (36.7 MiB/s)
Booting from mmc ...
reading imx7d-pico_pi.dtb
44004 bytes read in 17 ms (2.5 MiB/s)
Kernel image # 0x80800000 [ 0x000000 - 0x576268 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Using Device Tree in place at 83000000, end 8300dbe3
Starting kernel ...
Booting Linux on physical CPU 0x0
Linux version 4.1.15-224683-gf3ba9d9 (tapani#triceratops) (gcc version 5.1.1 20150608 (Linaro GCC 5.1-2015.08) ) #4 SMP PREEMPT Tue Dec 20 17:50:41 HKT 2016
It looks like your board was not shipped with the fastboot bootloader necessary for Android Things, and instead has been pre-flashed with a Linux distro.
You will need to use the mfgtools package from NXP to re-flash your board with the proper bootloader to continue. The NXP Pico Quick Start Guide for Android Things describes where to get this tool (section 7.3) and how to use it to re-flash the bootloader with mfgtools (section 9.1).
After the bootloader has been updated, you should be able to follow the official flashing instructions to install Android Things using an image downloaded from the console.
Maybe try:
adb kill-server
It helped here Android Things - pico i.mx7 unable to connect
I am trying to run some ARM assembly codes on Snapdragon 810 development board to evaluate performance on Cortex-A53 and A57 processors. My codes are nothing to do with android applications and they are C/Assembly coeds. Moreover, I want to get remote access to the board preferably via SSH and run gcc commands. The board default OS in Android Lollipop and my first intention was to install Linux on it to make things work desirably. However, Qualcomm customer support informed me that Linux isn't supported by this board and I have to deal with Android.
I've already searched over various forums. Some of them suggest to root the Android device, install QuickSSHD or SSHDroid on the device and simply SSH to it. However, I am not sure if the provided console has the capability of running gcc commands, generating executable and running it. Others, suggest to generate executable using cross-compilation and push the executable via adb console and run it on the Android device. This approach makes more sense, but I need to have remote access via SSH to the board and edit my code on the device continuously.
My question is, what is the best and easiest approach to get remote access via SSH to this device, compile and run C/ARM Assembly code, transfer files and get the real timing of my codes?!
Cross compile is the easiest option to generate the executable. Else you will have to port GCC to the target first. Don't even bother.
And Adb is a lot better when dealing with Android devices as you need not install any additional applications/executables to get it working. Adb can work on TCP connection as well. So there is no need of SSH for the task. And if the device is rooted, "adb root" followed by "adb shell" would give you the root console.
I have a course project that involves setting up a device driver on Android. I have previously worked with device drivers in the Linux kernel and we used two commands to initialize the device and make a node: insmod and mknod
Now when I launched the emulator shell using adb shell, I was able to use insmod but mknod did not work. I have tried to find alternatives but was not lucky.
From what I know, mknod in the Linux kernel lists the device under the /dev directory and allows user programs to read/write to it by using its file ops.
So what is its alternative for Android?
Perhaps, the android device you're using don't have mknod command. It need to be supported from rootfs, usually Android rootfs are built using busybox. Most probably, mknod was dropped from busybox config. Possible option could be, use custom Android image where you've mknod installed.
First of all, I believe, it's not a duplicate question. I don't want to write a native app with NDK, I just want to use Android device as a cheap Linux server. Server, in this context, means a program, which has no UI. Also, the server is written in bare C++, but uses no libraries at all, so that's why should that question differ from others.
The story
We've written a small server for Linux, it has a webserver interface, so you connect to it with a vanilla browser, and you can play with it. We've compiled it to Linux/x86, Linux/ARM (GuruPlug), Linux/PPC (some kind of NAS), and Mac OS X Darwin platforms.
The Linux/ARM version also runs well on my Palm Pré smartphone. I've just copied the executable onto my phone (in webOS scene, there's no such thing like jailbreak, there's an official "developer mode", which if you activate by typing a secret key combination, you can log in to your phone with ssh or use local ssh app). So, our small server program (daemon, may say) is running on even the smallest Linux devices. (It's funny, when connect with your giga-powered desktop machine's browser to a smartphone server.)
The server program is designed to run on even the smallest Linux (as I said, it runs on NAS, router, smartphone), it requires only STDLIB and PTHREADS.
The question
What't the straight way to get that simple server program run on an Android device?
We have no Android device yet. But I assume, any ARM-based one will do. The server's memory footprint is so small, that it will be no problem.
I assume, the device must be rooted to copy executable to it and run.
I don't want to install a whole new Linux on the device. It should keep running Android, while our server works in the background. The Linux distribution which enough for Dalvik, is enough for our server, I'm pretty sure.
The server should use no external things (USB, touchscreen, audio, camera, mic - thanks, not) only a port for webserver (e.g. 8080), which is not allocated by Android.
I have ARM GCC toolchain, the installation of it is not the part of the question (except if there're tricks).
The installation of the program should be manual (scp, whatever). Also, I don't want to make a package or any automated deployment.
The problem of the launching of the server program is another question, we'd ignore now.
So, I want just do the same thing with an Android device (phone, tablet), just as I did on my webOS device: copy the server program and run on it. Computers are for that, running programs, aren't they? ;)
I have not really tried it, but it should be possible to use the ARM GCC compiler you have, or the one provided by the Android NDK to compile native application, the same as you would use it on your desktop.
If your application is small (not too many files), you can manage the compilation by hand (or in a simple Makefile). The following commands are from the LuaJIT compilation guide for Android:
/tmp$ cat test.c
#include <stdio.h>
int main() {
printf("Hello world!\n");
return 0;
}
/tmp$ NDK=/opt/ndk
/tmp$ NDKABI=8
/tmp$ NDKVER=$NDK/toolchains/arm-linux-androideabi-4.4.3
/tmp$ NDKP=$NDKVER/prebuilt/darwin-x86/bin/arm-linux-androideabi-
/tmp$ NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm"
/tmp$ ${NDKP}gcc $NDKF -o test test.c
/tmp$ file test
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Obviously, use linux-x86 instead of darwin-x86 if you are on Linux (not Mac OS X, also not sure about Windows), and change the path to NDK to where you installed it.
Now you have to move the compiled binary somewhere to your Android device, and run adb shell to see if it works:
/tmp$ ADB=/opt/sdk/platform-tools/adb
/tmp$ $ADB push test /data/
332 KB/s (3343 bytes in 0.009s)
/tmp$ $ADB shell
# /data/test
Hello world!
You definitely need a rooted android device.
I recommend that you install busybox to get a bunch of nice command line tools such as wget, tar, gzip and many more.
You can get shell access to your device by using adb shell and then su to get root access. You can either use adb push or wget to put your server on the device.
The /system partition is mounted as read only and depending on the manufacturer there are a lot of protections that restrict you from writing there so you should copy your server somewhere on the /data partition (e.g. mkdir /data/myserver). After this, everything should be pretty straight forward.
Perhaps the question is more a sysadmin issue (how to install your executable on your Android device) than a developer issue (how to cross compile a C program for Android)?
I have a chroot partition with my android galaxy phone. It is arm with floating point processor, so all kinds of compilers work. Warning to you: the busybox/android distro utils don't run as GNU software. Their tar have problem unpacking the first thing I tried. POSIX tar not supported. Their zip have problem with some field 1 or 8. Their mount works like somthing from space. Their partition itself that you will want to have software put on does not support sym link. After a few weeks working on the chroot partition, I start to feel that the whole android is just a new underlying BIOS, with lots of firmware.