I have followed the build_and_run_inception_hexagon.sh and generated the hexagon_graph_execution executable. Now instead of using a real device I would like to test inception model with hexagon-sim available at SDK 3.0. So there is no need to use adb push commands as the SDK can simulate HVX device with hexagon-sim.
I have put the run-time libraries and the inception model plus the image at the same folder. After execution It gives me this error:
~/Qualcomm/HEXAGON_Tools/7.2.12/Tools/bin/hexagon-sim ./hexagon_graph_execution "/home/aashouri/Qualcomm/Hexagon_SDK/3.0/test/common/inception"
Error: Unsupported machine type 0x0 in ELF image "./hexagon_graph_execution" - exiting.
Can anyone comment on this?
Hexagon-readelf:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0xc8c9c
Start of program headers: 52 (bytes into file)
Start of section headers: 39944896 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 36
Section header string table index: 35
XXD info:
0000000: 7f45 4c46 0101 0100 0000 0000 0000 0000 .ELF............
0000010: 0300 2800 0100 0000 9c8c 0c00 3400 0000 ..(.........4...
0000020: c082 6102 0000 0005 3400 2000 0800 2800 ..a.....4. ...(.
0000030: 2400 2300 0600 0000 3400 0000 3400 0000 $.#.....4...4...
0000040: 3400 0000 0001 0000 0001 0000 0400 0000 4...............
0000050: 0400 0000 0300 0000 3401 0000 3401 0000 ........4...4...
0000060: 3401 0000 1300 0000 1300 0000 0400 0000 4...............
0000070: 0100 0000 0100 0000 0000 0000 0000 0000 ................
0000080: 0000 0000 ece6 2a01 ece6 2a01 0500 0000 ......*...*.....
0000090: 0010 0000 0100 0000 20eb 2a01 20fb 2a01 ........ .*. .*.
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
This binary was not built by hexagon-clang. You must have accidentally built it with the ARM toolchain -- the "Machine" field would say "Qualcomm Hexagon" if it had been built for the hexagon DSP.
Related
Trying to detect an iBeacon setup on raspberry PI using the android beacon library (with xamarin bindings)
Wondering what Im doing wrong here:
sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 E2 0A 39 F4 73 F5 4B C4 A1 2F 17 D1 AD 07 A9 61 00 01 00 00 C8 00
And setting up Beacon Parser like so
beaconManager.BeaconParsers.Add(new BeaconParser().SetBeaconLayout("m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"));
I can detect this beacon with for example "BeaconScope" on Android but I can not get it detected using the android beacon library.
I can see the following output from debug
[BeaconParser] Processing pdu type FF: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000 with startIndex: 5, endIndex: 29
[BeaconParser] Ignoring pdu type 06
[BeaconParser] This is not a matching Beacon advertisement. (Was expecting be ac. The bytes I see are: 02011a1aff4c000215e20a39f473f54bc4a12f17d1ad07a96100010000c80000000000000000000000000000000000000000000000000000000000000000
Setting up as AltBeacon works!
sudo hcitool -i hci0 cmd 0x08 0x0008 1F 02 01 1A 1B FF 18 01 BE AC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 C5 01
This one the library detects.
What am I missing?
I detect a RadButton setup as iBeacon but can not get it to work from raspberry PI
Try changing this:
"m:0-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
to this:
"m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"
Note the first digit is a 2 instead of a 0
There is a similar question:
What is the path of OAT file in Android 5.0
But Android 7, in the same path:
/data/dalvik-cache/<ARCH>/
I can't find the user-installed app, but only the system ones.
Where can I find the oat file generated by the normal installation of an app?
I found the oat file generated by the normal installation of an app in:
/data/app/<PACKAGE_NAME>/oat/<ARCH>/base.odex
And I verified that is an oat file running (on my machine, not in Android) the command:
$ readelf -e base.odex
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 3928128 (bytes into file)
Flags: 0x5000000, Version5 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 9
Section header string table index: 8
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .rodata PROGBITS 00001000 001000 34f000 00 A 0 0 4096
[ 2] .text PROGBITS 00350000 350000 06c3f4 00 AX 0 0 4096
[ 3] .bss NOBITS 003bd000 000000 034604 00 A 0 0 4096
[ 4] .dynstr STRTAB 003f2000 3bd000 00003d 00 A 0 0 4096
[ 5] .dynsym DYNSYM 003f2040 3bd040 000060 10 A 4 0 4
[ 6] .hash HASH 003f20a0 3bd0a0 000024 04 A 5 0 4
[ 7] .dynamic DYNAMIC 003f3000 3be000 000038 08 A 4 0 4096
[ 8] .shstrtab STRTAB 00000000 3bf000 00003d 00 0 0 4096
...
because it contains the .rodata and .text headers as described in: http://newandroidbook.com/files/Andevcon-ART.pdf
I tried to encode Android camera preview frame to h264, and mux to mp4 container.
I can created mp4 file successfully. But the mp4 format seems corrupted.
Use the ffprobe, I got the following error.
$ ffprobe o.mp4
[h264 # 0x209fe50] non-existing PPS 0 referenced
[h264 # 0x209fe50] decode_slice_header error
[h264 # 0x209fe50] no frame!
[mov,mp4,m4a,3gp,3g2,mj2 # 0x209ea60] decoding for stream 0 failed
[mov,mp4,m4a,3gp,3g2,mj2 # 0x209ea60] Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 568x320, 505 kb/s): unspecified pixel format
Then I use mp4info tool to see if the information is correct. I found this.
$ mp4info o.mp4
mp4info version 2.0.0
o.mp4:
ReadProperties: atom 'avcC' is too small; overrun at property: configurationVersion (src/mp4atom.cpp,386)
mp4info: can't open o.mp4
By hexdump the content of file, I got this
$ xxd o.mp4 |grep -A 5 -B 5 avcC
0039170: 6331 0000 0000 0000 0001 0000 0000 0000 c1..............
0039180: 0000 0000 0000 0000 0000 0238 0140 0048 ...........8.#.H
0039190: 0000 0048 0000 0000 0000 0001 0000 0000 ...H............
00391a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00391b0: 0000 0000 0000 0000 0000 0000 0018 ffff ................
00391c0: 0000 0008 6176 6343 0000 0020 7374 7473 ....avcC... stts
00391d0: 0000 0000 0000 0002 0000 004f 0000 0ea6 ...........O....
00391e0: 0000 0001 0000 0000 0000 0058 7374 7373 ...........Xstss
00391f0: 0000 0000 0000 0012 0000 0001 0000 0005 ................
0039200: 0000 000a 0000 000f 0000 0014 0000 0019 ................
0039210: 0000 001e 0000 0023 0000 0028 0000 0029 .......#...(...)
If I didn't add global header to AVCodecContext,
if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER) {
// oc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
}
ffprobe can detect the format without error, also ffplay can play it. But the avcC atom still not correct. Other player cannot play it.
Why the muxer didn't write the correct avcC atom?
How can I solve it?
You must set the extradata field in the codec context. The format is referenced here: Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream
Solved. This problem only happened in the new version ffmpeg.
When call ffmpeg api avformat_write_header/av_write_tailer, it uses the data in AVStream->codecpar since AVStream->codec was marked deprecated.
And the extra data is filled after avcodec_open2, so I need to copy extra data back to AVStream->codecpar.
stream->codecpar->extradata = av_malloc(oc_ctx->extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
stream->codecpar->extradata_size = oc_ctx->extradata_size;
memcpy(stream->codecpar->extradata, oc_ctx->extradata, oc_ctx->extradata_size);
Similar code snippet also can be found in ffmpeg project ffmpeg.c
if (!ost->st->codecpar->extradata && avctx->extradata) {
ost->st->codecpar->extradata = av_malloc(avctx->extradata_size + FF_INPUT_BUFFER_PADDING_SIZE);
if (!ost->st->codecpar->extradata) {
av_log(NULL, AV_LOG_ERROR, "Could not allocate extradata buffer to copy parser data.\n");
exit_program(1);
}
ost->st->codecpar->extradata_size = avctx->extradata_size;
memcpy(ost->st->codecpar->extradata, avctx->extradata, avctx->extradata_size);
}
I am receiving the following error every time I make a modified Nexus 6 kernel and use Peter Batard's mkbootimg tools (https://github.com/pbatard/bootimg-tools) to create a bootable image:
android#ubuntu:~/android-sdk-linux/platform-tools$ ./fastboot boot myboot3.img
downloading 'boot.img'...
OKAY [ 1.219s]
booting...
FAILED (remote failure)
finished. total time: 1.282s
I have booted off of the stock and Franco bootable images which worked. However, unpacking those bootable images and replacing the kernel with my modified zImage from the msm source (I also tried Franco's Shamu kernel source as well) will result in that same error.
When unpacking the boot.img I receive the mkbootimg command line instructions:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x00008000 --ramdisk_offset 0x0000000b --second_offset 0x00f00000 --tags_offset 0x0000000b --cmdline 'console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=shamu msm_rtb.filter=0x37 ehci-hcd.park=3 utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags utags.backup=/dev/block/platform/msm_sdcc.1/by-name/utagsBackup coherent_pool=8M' --kernel kernel --ramdisk ramdisk.cpio.gz -o /home/android/Desktop/shamu-lmy47z/boot.img
The only change to this I make is replacing kernel with the newly created zImage and changing the output name to something like myboot.img. I have been able to unpack the stock image and repack it without making any modifications and it has worked fine. Is it possible that one of the parameters in the mkbootimg command needs to be modified?
-- EDIT --
I ran unmkbootimg from this thread Error with repacking boot.img (Android). Which gave the following information:
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0x000080F5
OFF_RAMDISK_ADDR is 0x00000100
OFF_SECOND_ADDR is 0x00F000F5
Please modify mkbootimg.c using the above values to build your image.
****************
This still resulted in a failed boot.img.
Here are the beginning of the respective files:
boot.img (from the factory build of the LMY47Z Nexus 6 system).
android#ubuntu:~/Desktop/shamu-lmy47z$ xxd -l 320 boot.img
0000000: 414e 4452 4f49 4421 cdc5 6d00 0080 0000 ANDROID!..m.....
0000010: dff2 0a00 0b00 0000 0000 0000 0000 f000 ................
0000020: 0b00 0000 0008 0000 0000 0000 0000 0000 ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000040: 636f 6e73 6f6c 653d 7474 7948 534c 302c console=ttyHSL0,
0000050: 3131 3532 3030 2c6e 3820 616e 6472 6f69 115200,n8 androi
0000060: 6462 6f6f 742e 636f 6e73 6f6c 653d 7474 dboot.console=tt
0000070: 7948 534c 3020 616e 6472 6f69 6462 6f6f yHSL0 androidboo
0000080: 742e 6861 7264 7761 7265 3d73 6861 6d75 t.hardware=shamu
0000090: 206d 736d 5f72 7462 2e66 696c 7465 723d msm_rtb.filter=
00000a0: 3078 3337 2065 6863 692d 6863 642e 7061 0x37 ehci-hcd.pa
00000b0: 726b 3d33 2075 7461 6773 2e62 6c6b 6465 rk=3 utags.blkde
00000c0: 763d 2f64 6576 2f62 6c6f 636b 2f70 6c61 v=/dev/block/pla
00000d0: 7466 6f72 6d2f 6d73 6d5f 7364 6363 2e31 tform/msm_sdcc.1
00000e0: 2f62 792d 6e61 6d65 2f75 7461 6773 2075 /by-name/utags u
00000f0: 7461 6773 2e62 6163 6b75 703d 2f64 6576 tags.backup=/dev
0000100: 2f62 6c6f 636b 2f70 6c61 7466 6f72 6d2f /block/platform/
0000110: 6d73 6d5f 7364 6363 2e31 2f62 792d 6e61 msm_sdcc.1/by-na
0000120: 6d65 2f75 7461 6773 4261 636b 7570 2063 me/utagsBackup c
0000130: 6f68 6572 656e 745f 706f 6f6c 3d38 4d00 oherent_pool=8M.
myboot.img (built w/ mkbootimg and zImage made from msm source)
android#ubuntu:~/Desktop/shamu-lmy47z$ xxd -l 320 myboot.img
0000000: 414e 4452 4f49 4421 4016 6a00 0080 0000 ANDROID!#.j.....
0000010: dff2 0a00 0b00 0000 0000 0000 0000 f000 ................
0000020: 0b00 0000 0010 0000 0000 0000 0000 0000 ................
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000040: 636f 6e73 6f6c 653d 7474 7948 534c 302c console=ttyHSL0,
0000050: 3131 3532 3030 2c6e 3820 616e 6472 6f69 115200,n8 androi
0000060: 6462 6f6f 742e 636f 6e73 6f6c 653d 7474 dboot.console=tt
0000070: 7948 534c 3020 616e 6472 6f69 6462 6f6f yHSL0 androidboo
0000080: 742e 6861 7264 7761 7265 3d73 6861 6d75 t.hardware=shamu
0000090: 206d 736d 5f72 7462 2e66 696c 7465 723d msm_rtb.filter=
00000a0: 3078 3337 2065 6863 692d 6863 642e 7061 0x37 ehci-hcd.pa
00000b0: 726b 3d33 2075 7461 6773 2e62 6c6b 6465 rk=3 utags.blkde
00000c0: 763d 2f64 6576 2f62 6c6f 636b 2f70 6c61 v=/dev/block/pla
00000d0: 7466 6f72 6d2f 6d73 6d5f 7364 6363 2e31 tform/msm_sdcc.1
00000e0: 2f62 792d 6e61 6d65 2f75 7461 6773 2075 /by-name/utags u
00000f0: 7461 6773 2e62 6163 6b75 703d 2f64 6576 tags.backup=/dev
0000100: 2f62 6c6f 636b 2f70 6c61 7466 6f72 6d2f /block/platform/
0000110: 6d73 6d5f 7364 6363 2e31 2f62 792d 6e61 msm_sdcc.1/by-na
0000120: 6d65 2f75 7461 6773 4261 636b 7570 2063 me/utagsBackup c
0000130: 6f68 6572 656e 745f 706f 6f6c 3d38 4d00 oherent_pool=8M.
First of all I suggest using mkboot(look for it in github) for unpacking and packing boot images.
Very few actual devices use the vanilla mkbootimg, instead they customize it. Marvel and MTK are notorious for modifying the bootloader to load their ugly proprietary boot images.
I would also check if the DTS in the boot image comes as a separate part. If thats the case then you need to make sure you unpack and repack it. I dont think you are doing it now.
I am trying to send a URL in a NDEF Message from my Computer and ACR 122 to a phone.
To Achieve that, I use SNEP.
The thing is that it works perfectly with Android and Blackberry, but not with any Windows Phone.
These are the commands I send using the java library Smartcardio, and the responses I got from the phone (android or Windows)
Command 1 : (configure PN532 as Target)
FF 00 00 00 2D D4 8C 00 08 00 12 34 56 40 01 FE0100000000000000000000000000FFFF01FE01000000000000000646666D01011000
Response Android : D5 8D 25 1E D4 00 D5 65 D7 84 0E 59 F9 CF B2 BA 00 00 00 32 46 66 6D 01 01 11 03 02 00 13 04 01 96 90 00
Response Windows Phone : D5 8D 05 22 D4 00 C2 65 AD 78 F4 3D 81 F8 72 8F 00 00 00 32 46 66 6D 01 01 11 02 02 03 80 03 02 00 01 04 01 64 90 00
Command 2 : (tg get data)
FF00000002 D486
Response Android : D5870000009000
Response WP : D5870000009000
Command 3 : (tg set data, ndef with "urn:nfc:sn:snep")
FF00000015 D48E 0520060F 75726E3A6E66633A736E3A736E6570
Response Android : D58F009000
Reponse WP : D58F009000
Command 4 : (tg get data)
FF00000002 D486
Response Android : D587 000000 9000
Response WP : D587 00 05 20 02 02 03 80 050105060F75726E3A6E66633A736E3A736E6570 9000
Command 5 : (tg set data)
FF00000004D48E 0000
Response Android : D5 8F 00 9000
Response WP : D5 8F 00 9000
Command 6 : (tg get data)
FF00000002 D486
Response Android : D587 00 8184 9000
Response WP : D587 00 8184 02020380050105 9000
Command 7 : (tg set data, ndef with url "journaldugeek.com")
FF00000021 D48E 132000100200000016 D1 01 12 55 01 6A6F75726E616C64756765656B2E636F6D
Response Android : D58F 00 9000
Response WP : D58F 00 9000
Command 8 : (tg get data)
FF00000002D486
Response Android : D587 00 83 44 01 9000
Response WP : D587 00 83 44 01 9000
Command 9 : (tg set data)
FF00000004D48E0000
Response Android : D58F009000
Response WP : D58F009000
Command 10 : (tg get data)
FF00000002D486
Response Android : D587 00830401108100000000 9000
Response WP : D587 00830401108100000000 9000
Command 11 : (tg set data)
FF00000005 D48E 136001
Response Android : D58F009000
Response WP : D58F009000
Command 12 : (tg get data)
FF00000002D486
Response Android : D5870000009000
Response WP : D5870000009000
Command 13 : disconnect?
FF00000004D48E1160
Response Android : D58F009000
Response WP : D58F009000
Command 14 : disconnect?
FF00000002D486
Response Android : D587 0081C400 9000
Response WP : D587 0081C400 9000
You can see that only Command 6 is different for Android and Windows Phone, however the other ones are the sames. The WP basically send a OK Message, but the url is not displayed in a browser on the phone. Does anybody know why, and know if there is another way to do SNEP with APDU Commands so that it works for Android, WP and Blackberry ?