Tag Archives: arm 

How to Solve Valgrind 3.14 error on ARM 64

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

This is a bug in this version. Upgrading to the latest version can solve this problem.

valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).

Just install a GDB. apt install gdb.

How to Solve Keil Error: error: #29: expected an expression

About the solution of error: #29: expected an expression

Recently, a keil project was created, and an error occurred during compilation: #29: expected an expression

This problem is because keil MDK uses C90 by default. You need to modify the configuration to support C99 to solve this problem.

The specific solutions are as follows:

Magic Wand --> C/C++ --> Check 'C99 Mode' on the right to confirm  

Finally, recompile:

- 0 Error(s), 0 Warning(s).

[Solved] Error calling ICU Library: libicudata.so.51: internal error

I recently ported a front-end that depends on the icu library, and after successful compilation I got the following error
error while loading shared libraries: /usr/lib/libicudata.so.51: internal error
I thought it was a problem with icu version, and tried various versions without success.
I finally found the problem after a long day of searching, the config should add –with-data-packaging=files
The original config configurationICU_CONF_OPT = –with-cross-build=$(HOST_ICU_DIR)/source –disable-samples \
–disable-tests
New Configuration:
ICU_CONF_OPT =     –host=arm-linux-gnueabihf \
–with-cross-build=$(HOST_ICU_DIR)/source \
–prefix=$(STAGING_DIR)/usr  \
–with-data-packaging=files \
–disable-samples \
–disable-tests

line 1: syntax error: unexpected “(“ [How to Solve]

An error occurred while executing the executable on the development board: Line 1: syntax error: unexpected “(”

View the architecture of the executable file with the command objdump – a automiclinux. It is found that it is not the arm architecture

Re cross-compile and transplant it to the development board for execution. It is found that it can run

NDK Version Clang++: error: unknown argument: ‘-static-openmp‘

Cmakelists.txt file compiles ncnn and CPP and runs normally on the other two Ubuntu machines.

Similarly, the source code is configured, the project is loaded, and the gradle initialization is correct, but there is an error in compiling APK.

clang++: error: unknown argument: ‘-static-openmp’

After searching for a long time, I can’t see the wrong configuration. I doubt the gradle version. The problem remains after the upgrade; Upgrade the as version, and the problem still occurs.

Open settings, SDK configuration, check SDK tools, and reinstall SDK. The latest SDK 23.0 is installed at once. The error disappears, but there is still a problem with the compilation. It is reduced to SDK 20.0, and the error occurs again.

High or low, choose ndk21.3 and cmake3.10.2. Finally, the compilation is normal and the debugging is passed.

Error: l6242e: cannot link object arm_ cos_ f32.o as its attributes are incompat

report errors

I use AC6 as the compiler in keil MDK. I report an error when I transplant DSP library to F4. I configure it according to the online tutorial and report an error after compiling

Error: L6242E: Cannot link object arm_common_tables.o as its attributes are incompatible with the image attributes.
Error: L6242E: Cannot link object arm_cos_f32.o as its attributes are incompatible with the image attributes.

After searching on the Internet for a circle, I found no result. If I see a similar problem, I can’t try to solve it.
https://blog.csdn.net/crown133/article/details/103333704

solve

Finally, we found the answer on arm’s official developer website

in the end https://developer.arm.com/documentation/ka003983/latest
In short, AC5 and 6 wchar_ The default size of T is not the same

according to the solution of the official website, you can open this option here

if you encounter problems in the future, you still need to find answers through official channels

【arm】arm-assembly-print-register-value-in-decimal

Date: 2018-7-15


1. Reference:
https://stackoverflow.com/questions/2370942/arm-assembly-print-register-value-in-decimal
2. Arm register printing
Since the ARM register print is always in hexadecimal, it seems to be a bit of a struggle. Therefore, we have been exploring the relatively convenient method of arm register printing recently, and now there are two methods for reference.
Method one:

print_decimal:
        stmfd   sp!, {
  r4,r5,lr}

        cmp     r0, #0
        moveq   r0, #'0'
        bleq    putchar
        beq     done

        mov     

Introduction to the principle of Mali tile based rendering

comes first

a little in-depth understanding of Mali’s architecture, compare the basic process of the existing GPU with that of Mali, and propose the advantages and disadvantages of the GPU. The original address: https://developer.arm.com/graphics/developer-guides/tile-based-rendering
Traditional GPU

the architecture of a traditional GPU is generally called the Immediate mode GPU. The main process is vertex shader and fragment shader executed sequentially. The pseudocode is:

for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        for fragment in primitive:
            execute_fragment_shader(fragment)

The

data stream looks like this:

Advantages of


The main advantage of

is that the output from vertex stays on the chip and can be read directly and quickly in the next stage.

shortcomings

if there are large graphics (mostly triangles) that need to be rendered, then the framebuffer will be very large. For example, rendering the color of the entire screen or deep rendering will consume a lot of storage resources, but there are no such resources on the chip, so the DDR will be read frequently. Many operations related to the current frame (such as blending, depth testing or stencil testing) all need to read this working set, so the bandwidth required is huge and the energy consumption is also high. For mobile devices, this way is not conducive to the operation of the device.

Tile-based GPU

so Mali’s GPU proposed the Tile-based concept, which is to divide the image into 16*16 pieces. Rendering in small chunks and writing to DDR solves this problem by reducing the frequency of reading and writing to DDR. But chunking requires knowing the geometry of the entire image, so the operation is broken down into two steps:

  1. first step to perform geometry related operations, and generate tile list.
  2. second step to execute fragment operation on each tile, after completion, write memory

The

pseudocode is as follows:

# Pass one
for draw in renderPass:
    for primitive in draw:
        for vertex in primitive:
            execute_vertex_shader(vertex)
        append_tile_list(primitive)

# Pass two
for tile in renderPass:
    for primitive in tile:
        for fragment in primitive:
            execute_fragment_shader(fragment)

data flow as follows:

Advantages of

obviously solves the bandwidth problem of the traditional model, because the fragment shader reads a small fragment every time and puts it on the fragment. There is no need to read the memory frequently until the last operation is finished, and then write to the memory. You can even further reduce reads and writes to memory by compressing tiles. In addition, when some areas of the image are fixed, the function is called to determine whether tiles are the same, so as to reduce repeated rendering.

shortcomings

is used to write the output geometry to the DDR after the vertex phase, and then to be read by fragment shader. This is the balance between the overhead of tile writing DDR and the overhead of fragment Shader rendering reading DDR. Another operation, such as Tessellation, is not suitable for the Tile-based GPU.

summary

now the resolution of the screen is getting bigger and bigger from 1080p to 1440p to 4K, you can see, Mali’s architecture will be used on a large scale in the future.

but there are some pitfalls that developers need to avoid. The first is to properly set the Render Pass to take advantage of the features of the architecture; The second is to understand the benefits of this geometric division.

Android studio simulator architecture choose arm or x86 to solve the problem of missing libraryexception

first of all, if your APP can be installed normally including third-party or self-compiled, then use x86, because the architecture of the virtual machine is very fast; If, like me, the so in the compiled APK is ARM, then an ARM-architecture virtual machine is required, otherwise the following error will be reported. X86 compatibility is not enough, many apps can not be installed or installed to play. Most emulators on the market are x86, so if you can’t install them, consider the reason why they don’t support the x86 architecture. Google official emulator, Intel x86 system mirror, opened KVM acceleration, the result installed several applications failed, such as qq various versions, jingdong client, touch input method, etc. The message is Failure [INSTALL_FAILED_NO_MATCHING_ABIS], presumably because these applications are not compatible with x86 devices. Baidu Takeaway and X-Plore were installed successfully.

after using the simulator to install the application software to run today, an error was found as follows:

MissingLibraryException: lib/x86/libgnustl_shared. So

02-07 02:53:39.122 7607-7639/com.gala.video E/AndroidRuntime: FATAL EXCEPTION: jobmanager-5-12
Process: com.gala.video, PID:>

02-07 02:53:39. 7607
com. Getkeepsafe. Relinker. MissingLibraryException: Lib/x86/libgnustl_shared. So
the at com. Getkeepsafe. Relinker. ApkLibraryInstaller. InstallLibrary (ApkLibraryInstaller. Java: 85)
the at Com. Getkeepsafe. Relinker. ReLinkerInstance. LoadLibraryInternal (ReLinkerInstance. Java: 180)
the at com. Getkeepsafe. Relinker. ReLinkerInstance. LoadLibrary (ReLinkerInstance. Java: 136)
the at com.getkeepsafe.relinker.ReLinkerInstance.loadLibrary(ReLinkerInstance.java:92)

my emulator is the default Android studio configuration when it was created and is an x86 architecture emulator. Why is the system an emulator of this architecture by default?Before Windows installed virtual machines, we had to turn on the BIOS virtual device switch: HAXM was needed to speed up the AVD emulator on an Intel CPU host.

  • step 1: enter the BIOS to enable VT (Virtualization Technology) option; Step 2: download Intel x86 Emulator Accelerator(HAXM install)

from the SDK Manager of Android studio

after we create an emulator, the default configuration is the x86 architecture, which has the advantage of fast speed. However, it has a big disadvantage of insufficient compatibility, which results in many applications compiled with ARM architecture cannot be installed, or the boot error is reported after installation. The above error means that the emulator you have turned on is x86, so the relevant SO library in your APP is also x86. However, in your packaged APP, only the SO library of ARM was found, so the error was reported. So what we’re going to do is create an ARM architecture virtual machine:

we configure an ARM processor architecture virtual machine as shown in the figure below:

select ARM virtual machine, lower right corner will prompt, this is more than 10 times slower than x86, pro test, may be more than 10 times slower.

of course you can increase the virtual machine memory a little bit:

after the above completion, start our ARM virtual machine, try to install apk can