I'm building Android 9 with CPU x86_arm and compilation is successful. But when I run it on android emulator then it stuck on black screen and not booting.
Everytime I open emulator it shows me this error
emulator: WARNING: System image is writable
emulator: WARNING: encryption is off
My system details:
Ubuntu 22.04, x86_64 CPU, Ryzen 7 with Nvidia Graphics and 24 GB RAM.
AOSP details:
Repo branch: pie-gsi, building lunch aosp_x86_arm-userdebug.
Thanks
Related
I am a student and have been instructed by the college to use MCU 8051 IDE with SDCC for learning microcontroller programming. I installed this software successfully on many HP devices in college but when I am trying to use it on my home Dell Inspiron 15 3000 laptop following happens:
Starting compiler ...
cd "E:\\Embedded Systems Practical"
sdcc -mmcs51 --iram-size 256 --xram-size 0 --code-size 8192 --nooverlay --noinduction --verbose --debug -V --std-sdcc89 --model-small "prac4.c"
The IDE gets stuck here. Even after aborting the IDE freezes and needs to be restarted. I tried multiple fresh installs on my PC but nothing works.
I brought a pre-compiled version from the college PC to verify that the error is with SDCC and the simulation works perfectly fine.
Can someone help me how to resolve the unknown error?
System information
Linux Ubuntu 18.04
armv7 board
python3.6
question description
I trained a model on my linux server (ubuntu18.04，Intel(R) Xeon(R) W-2145 CPU) and exported it to tflite mode, and the model on the server (tflite-runtime=2.10.0) works fine.
Now I want to run the model on an armv7 development board of zynq7000. The operating system running on my board version is ubuntu18.04, and python3.6 and tflite-runtime=2.5.0 is installed (2.5.0 seems is the highest version I can get on armv7), but when I run interpreter = tflite.Interpreter(model_path=my_model), it throws Segmentation fault (core dumped) error.
After my test, if I downgrade the tflite-runtime on my linux server to version 2.5.0, the same error will be thrown. So I think the reason for the error may be that the version of tflite-runtime is too low.
But I can't get a higher version of tflite-runtime on armv7 board, does anyone know a solution please?
while building Multi-arch support on Docker Desktop for a react app, arm64 is taking 10x more time than amd64 for npm installation and build, please help me to figure out something that will reduce the time for arm64
I ran Gstreamer tutorial's example code in both my own 2 computers.
One PC was install Ubuntu 20.04.2, GPU Nvidia GTX 1050Ti
And the remain one (i.e laptop) was install Ubuntu 18.04.5, with NVIDIA GeForce GTX 950M
And the result when built successfully ./basic-tutorial-1 was:
the ubuntu 20 PC can show the video in the display.
but the ubuntu 18 laptop is not display anything, or even any error logs.
Is there any Gstreamer's problem relate to OS.
There might be an issue with installation:
try:
sudo apt install gstreamer1.0-tools
sudo apt install gstreamer1.0-plugins-base
I'm going through a course on gdb. In the later lessons the course covers debugging on ARM architecture, so I'm presented a setup that allows me to emulate such situation.
My current setup comprises:
Windows 10: physical host
Ubuntu 12.04.5 LTS: guest os via Oracle Virtual Box on Windows 10
Linux debian-armel 2.6.32-5-versatile: guest os via qemu 2.8.0 on Ubuntu
The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/
The image is launched with
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2222::22
I modified the sources.list and apt.conf to allow apt to work, since the distro is quite outdated. I updated and upgraded and installed gcc and gdb.
The problem arises when trying to debug; I can load executables in gdb:
root#debian-armel:~/video-11/video-11# file ./main
./main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
but when I try to run it inside gdb, I receive this message and the execution hangs, until I'm able to kill the gdb process from another console:
------------[ cut here ]------------
WARNING: at /build/linux-2.6-fIxTVd/linux-2.6-2.6.32/debian/build/source_armel_none/kernel/sched.c:2628 wake_up_process+0x2c/0x48()
Modules linked in: loop sg smc91x sr_mod mii cdrom psmouse evdev ext3 jbd mbcache sd_mod crc_t10dif sym53c8xx scsi_transport_spi scsi_mod
[<c002b068>] (unwind_backtrace+0x0/0xdc) from [<c0046f88>] (warn_slowpath_common+0x4c/0x80)
[<c0046f88>] (warn_slowpath_common+0x4c/0x80) from [<c00446f0>] (wake_up_process+0x2c/0x48)
[<c00446f0>] (wake_up_process+0x2c/0x48) from [<c0026930>] (arch_ptrace+0x214/0x4bc)
[<c0026930>] (arch_ptrace+0x214/0x4bc) from [<c00508d8>] (sys_ptrace+0x9c/0x164)
[<c00508d8>] (sys_ptrace+0x9c/0x164) from [<c0024ec0>] (ret_fast_syscall+0x0/0x28)
---[ end trace 98ab50bc781b314f ]---
How can I resolve this issue?
Not my answer, but to enable the question to be marked as closed:
This is likely a bug in the guest kernel (though not certainly so), so
I would start by trying with a more recent kernel than 2.6.32, which
is now nearly 8 years old. – Peter Maydell Mar 3 '17 at 13:14