I successfully compiled and loaded custom Linux kernel into Android emulator (Eclair). Now I want to compile kernel for real Android device (Samsung Galaxy 5, Android 2.1 (Eclair)).
It seems that the same kernel image that was compiled for emulator, can't be used with real device. There is no much clear information given on how to do this.
Can someone tell what steps need to be changed to get kernel image for real android phone.
You are probably using the MSM kernel tree (for Qualcomm MSM processors), but the Samsung Galaxy S has a Samsung Hummingbird processor and thus needs the Samsung kernel tree, found here.
I don't know if the kernel tree includes a defconfig for the Galaxy S specifically, but you could probably use the "herring_defconfig" (make herring_defconfig). Herring is the code name for the Nexus S, but the Galaxy S is quite similar.
If you are building the Android framework as well (not just the kernel), you'll likely need to extract binary drivers (for the camera, bluetooth, WiFi, radio, etc.) from the existing phone images and add them to your system build.
Related
I just managed to install successfully the SyCL ComputeCpp + OpenCL (from CUDA) and running cmake to generate the samples VS2019 sln, successfully.
I've tried to run the matrix_multiply example ONLY, for now.
It ran successfully using the Intel FPGA emulator as a default device.
Changing the devices to the Device CPU worked well as well.
Choosing the host device, took ages without exiting.
When I tried to change the device to the nVidia, the GeForce GTX 1650 Ti.
I got this expection error from there ComputeCpp:RT0100, etc etc.
Googling a bit, I found I'd probably have to output the PTX instead of the SPIR.
So I regenerated the sln using -DCOMPUTECPP_BITCODE=ptx64
After doing that, the kernel ran successfully on the nVidia GPU.
My first question is: is that needed since nVidia does NOT support spir yet at the time of this writing, but only PTX?
However this broke the other devices, which are now reporting:
[ComputeCpp:RT0107] Failed to create program from binary
This happens now for all devices: Intel GPU, Device CPU, Device FPGA (While were formerly working)
Inspecting the .sycl I found now SYCL_matrix_multiply_cpp_bin_nvptx64[].
My question is: how to support nVidia with ptx and "normal" devices with spir altogether in the same exe? I did a menù from which the user can choose to play with, but now it's working only for nVidia.
What am I doing wrong, please?
I would expect to be able to run the same .sycl code for all the devices despite it contains ptx or spir. How to manage for that?
EDIT: I just tried to retarget the bitcode to spirv64, since the computecpp_info told me all my devices are supposed to support it.
However, now no device is anymore working with that setting :-(
Problem
I'm looking for a way to flash an ESP32 module's memory without installing the whole IDF software suite.
Why
Because I want to integrate ESP32 onto a custom board along with a low-performance ARM-powered CPU which runs a tiny Linux distro (based on Debian), and I want to flash ESP32 from this tiny Linux distro.
I know I could use the bootloader, but who will upload the initial bootloader? I don't want to do extra steps, so my idea is to embed the ESP32 module onto my custom board, and let the Linux to flash it from factory-state (when it's flash is empty, ie. no preloaded bootloader). Or is the serial bootloader always preinstalled on all ESP32 modules (like on ESP-WROOM-32)?
Why I don't want to use IDF? Because I don't want to build or debug anything, I just want to flash myprogram.bin onto ESP32. Also, as the board is low-performance, it would take ages to download everything for running IDF.
Current state
The ESP32 module is now visible via UART (RX,TX,GND), and if I held low the GPIO0, it runs the bootloader (my current module is embedded onto a NodeMCU - but there is no USB connected, this is raw UART!):
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Could I expect the same behavior (controlling GPIO0 for running the bootloader) for all ESP32 modules, or this works just because guys at NodeMCU preprogrammed already some bootloader onto it?
I'm looking for a way to flash this ESP32 preferrably without any python script.
The ESP32 has a first-stage bootloader in ROM capable of writing to Flash - that's what's printing your output. You can talk to it if you know the protocol - this is implemented by the Python scripts in ESP IDF. If you don't want to use the official implementation because it's too heavy, you'll have to write your own implementation of this protocol which scratches your specific itch. Fortunately it's more or less documented and you can likely reverse engineer any missing knowledge from official Python scripts.
Actually Espressif also provides a nice and small binary for flashing ESPs:
https://github.com/espressif/esp-serial-flasher
Serial flasher component provides portable library for flashing Espressif SoCs (ESP32, ESP32-S2, ESP8266) from other host microcontroller. Espressif SoCs are normally programmed via serial interface (UART). Port layer for given host microcontroller has to be implemented, if not available.
One more (but very important) addition:
You have to modify this repo to make it work correctly, and also you might have to upload not just your binary, but also bootloader and partition_table.
I am new to Android and to Kernel development, but I would like to test some things. I just finished compiling the first version of my modified kernel, and put it in a phone. Obviously, it doesn't work. How can I debug the kernel on the mobile phone?
I'm working over a Nexus 5 (MSM architecture, Linux 3.4.0 based). The .config used is the one by default (hammerhead_defconfig). When the kernel is booted, it only shows the Google screen, and stops there, forever.
I tried (with a working boot image) changing the 'console' parameter when generating the image with mkbootimg (tty, tty0, ttyHSL0), and I tried with different .config options as MSM_SERIAL_DEBUGGER (compilation error), FIQ_DEBUGGER (compilation error) and SERIAL_MSM (compiled, but no difference, no new devices in /dev on my computer). I tried with kgdb, following this, but I could not make the patches work for my architecture. Any idea?
I finally found a way to debug direcly over hardware:
http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ [Link down! Mirror at archive.org]
In Nexus 5 you need 3.3V instead of 3V of input, but it works like a charm.
When developing an application for Windows Phone 8 on ARM, is there a way to simulate or emulate the app if it has ARM NEON assembly? I.e., is the code compiled for x86 and run natively, or is it there a way to actually emulate an ARM NEON machine?
The Windows Phone 8 emulator is an x86 environment, so ARM code isn't going to work.
There's no emulator, but there's a free remote device access service, courtesy of Nokia, at http://rda.cellulardata.com/devices . You can't debug, but you can watch it run. Bake in some visible reporting into your app, publish it as a beta, download to a device and enjoy.
Since it's a beta, it won't be available via store search; you'd have to type in a URL. A link shortening service or a forward page on your own web space would come in handy here.
You have to explicitly designate your own Live ID as a beta tester account for a beta project. The Store doesn't recognize the "I'm downloading my own app" situation.
...let me add that the Phone devices are still ARM, so if you want to run on both device and emulator, you'll need to compile your native code for both ARM and x86.
I am new to android and wish to play around with the emulator.
What I want to do is to create my own piece of virtual hardware that can collect OpenGL commands and produce OpenGL graphics.
I have been told that in order to do this I will need to write a linux kernal driver to enable communication with the hardware. Additionally, I will need to write an Android user space library to call the kernal driver.
To start with I plan on making a very simple piece of hardware that only does, say 1 or 2, commands.
Has anyone here done something like this? If so, do you have any tips or possible links to extra information?
Any feedback would be appreciated.
Writing a hardware emulation is a tricky task and by no means easy. So if you really want to do this, I'd not start from scratch. In your case I'd first start with some simpler (because many of the libraries are already in place on guest and the host side): Implementing a OpenGL passthrough for ordinary Linux through qemu. What does it take:
First you add some virtual GPU into qemu, which also involves adding a new graphics output module that uses OpenGL (so far qemu uses SDL). Next you create DRI/DRM drivers in the Linux kernel, that will run on the guest (Android uses its own graphics system, but for learning DRI/DRM are fine), as well as in Mesa. On the host side you must translate what comes from qemu in OpenGL calls. Since the host side GPU is doing all the hard work your DRI/DRM part will be quite minimal and just build a brigde.
The emulator that comes with Android SDK 23 already runs OpenGL, you can try this out with the official MoreTeapots example: https://github.com/googlesamples/android-ndk/tree/a5fdebebdb27ea29cb8a96e08e1ed8c796fa52db/MoreTeapots
I am pretty sure that it is hardware accelerated, since all those polygons are rendering at 60 FPS.
The AVD creation GUI from Studio has a hardware acceleration option, which should control options like:
==> config.ini <==
hw.gpu.enabled=yes
hw.gpu.mode=auto
==> hardware-qemu.ini <==
hw.gpu.enabled = true
hw.gpu.mode = host
hw.gpu.blacklisted = no
in ~/.android/avd/Nexus_One_API_24.a/.