ARM "thumb-only" binaries - binary

is there a source on the net for ARM ELF binaries that only use thumb (thumb-1, no thumb-2) instructions?
(Yes, I came to read that Linux is not capable of running on thumb-only processors.)
The content of the binaries should otherwise be as "normal" as possible, I want to use them as training data for a classifier.

Related

Setting mem configure option in TCL build script

I need to build Activestate TCL for Ubuntu 18.04 with memory option enabled, "--enable-symbols=mem flag to the configure script" but there is no configure script in my download, only these, which don't have a "configure" line in them.
license-at8.6-thread.
update_check
komodo_download
payload
README-8.6-thread.txt
pdemos
install_welcome.txt
install.tcl
install.sh
install_lib.tcl
install_images
MANIFEST_at8.6.txt
install_data.tcl
Can someone describe how to add the switch described above for Ubuntu?
.
In order to set the mem option, you'll need to compile Tcl from source. To do that you'll need to get a C build chain (especially a C compiler such as gcc or clang, and make to act as a build orchestrator) and the Tcl (and Tk) source code for the version you want to build. The official location for releases of Tcl sources is on SourceForge:
https://sourceforge.net/projects/tcl/files/Tcl/
Pick the version you need and the download package you prefer (ZIP or compressed Tar archive).
Once you've downloaded and unpacked the Tcl code, change into the appropriate directory within the distribution (e.g., unix for Linux builds) and run the configure script inside; it's that script that you pass the --enable-symbols=mem option to.
ActiveTcl is essentially built the same way (except without symbols at all; it's a production distribution after all). It's main distinguishing feature is that it is set up with access to lots of extra packages to go with it. The same goes for most Linux distributions' own tcl packages. They're all production distributions and aren't configured for memory debugging precisely because that adds a lot of overhead to the code (both time and space).

What's the difference between "arm-linux-user" and "armeb-linux-user"?

When compile QEMU from source code, I find in file configure, option --target-list supports arm-linux-user and **armeb-linux-user". I know xx-linux-user is for User Emulation. What is the difference between "arm-linux-user" and "armeb-linux-user"?
armeb-linux-user is for big-endian Linux ARM binaries, and arm-linux-user is for little-endian ARM binaries. If you don't know you want big-endian then you don't want it. (The usual setup for user-mode QEMU uses the host-kernel's binfmt-misc support so it can automatically pick the right -linux-user QEMU binary to run for the guest executable anyway.)

Re-using Caffe files after building it

I succesfully builded Caffe on Windows 10 by following https://github.com/BVLC/caffe/tree/windows.
Then, after copying C:\Projects\caffe\python\caffe folder to my Python site_packages folder, I can use "import caffe" in Python.
My question is that if I want to use Caffe on other computers without building Caffe from the beginning, do I just need to copy the files in C:\Projects\caffe\python\caffe folder to the other computers' site_packages folder?
Actually, I am not familiar with 'build' and 'compile' and I don't know what 'build' is doing during the Caffe installation.
You can do the copy provided that the destination computer uses the same support libraries (for software linkage to your Python and Caffe) and has bit-compatible hardware (to support the binary code).
I do this regularly, within a controlled cluster. All the nodes have the same OS configuration. I build on one node, and then copy the entire directory to the same place on the other nodes. Then I run multi-node applications on the result.
If you switch to a different core processor, or a different OS implementation, your attempts to use the result will likely crash. I've tried that one, too. :-)

Is it possible to run/debug a bios rom file in an emulator, And if so how?

What I am trying todo is find a way to observe the execution flow of the BIOS rom file without having to flash it to the motherboard because I don't know of a way to debug or step through it during the bootup process.
The motherboard in question is a P6T7 WS Supercomputer as seen here.
This directory contains my research into the bios itself. It has rom files both downloaded from Asus's website above and ripped from my motherboard. The bin files came from the mmtool and the report.txt is a cpu-z report file with personally identifying information removed.
I want to learn how it runs so i can possibly write my own OROM file and or add UEFI support to the BIOS. This is a legacy bios which asus seems to have stopped supporting so no more updates will come out for it.
I have radare2 and ida pro available however I dont know how to use them on the bios rom file since it seems to contain this
DECIMAL HEXADECIMAL DESCRIPTION
----------------------------------------
73152 0x11DC0 Microsoft executable, portable (PE)
224736 0x36DE0 Microsoft executable, portable (PE)
717691 0xAF37B CRC32 polynomial table, little endian
1842624 0x1C1DC0 Microsoft executable, portable (PE)
1994208 0x1E6DE0 Microsoft executable, portable (PE)
output is from binwalk.

mips gnu toolchain with glibc_2.13

I am trying to load few modules onto Tizen on my MIPS-based platform. Currently, I am using sourcery codebench gnu linux compiler. The libc.so files it uses have version 2.17 which libc.so file on my platform has version 2.13. I need a toolchain which has a version less than or equal to 2.13 and supports MIPS.
Thanks,
Atchyut Sreekar
few options:
talk to the Tizen people to see if they have pre-compiled toolchains that match your system
build the code directly on the device
use crosstool-ng to build a new cross-compiler but with an old glibc version
upgrade your system because glibc-2.13 (and glibc-2.17 for that matter) are ridiculously old and have a large number of known security vulnerabilities including remote exploits. developing & deploying anything based on those glibc versions is a terrible terrible mistake.