I am an android firmware developer.I clone AOSP source code from android.googlesource.com . I've found that in android phones there exist two processors : Application processor and base band processor. application processor runs android OS and is responsible for running framework code of android and user applications but base band processor runs software-defined radio protocols that implement protocol stack of GSM. base band processor is responsible for telecommunication operations and is connected to SIM card and RF antenna.
These two processors is connected to each other in some way that depends on phone SoC (System On Chip) and hardware structure.I am now working on Nexus 5x (bullhead) with SoC msm 8992 . I know there is a subsystem in android OS named RIL (Radio Interface Layer) that runs on application processor that handles all requests/responses to base band processor.For example when you want to send a SMS , RIL sends a command with appropriate data to base band processor and then software defined protocol stack processes your request and sends corresponding radio commands to antenna.These messages are named AT commands.
My questions are
How application processor and base band processor are connected to each other in Nexus 5x phone ? (serial link or shared memory or ...)
How can I send AT command to base band processor in android shell ?(via adb shell)
Which node(s) in /dev in android file system is used for communication to base band processor ?
There exists an open source version of base band that I can use for bullhead ?
Related
I try to debug and test a BMC over the I2C interface of an raspberry(4).
So I simply want to send IPMI commands over IPMB to a microcontroller for debugging.
I write the code for a BMC and there a great tool for testing the communication would be also great.
My idea was to use ipmitool which actually needs a IPMI/IPMB interface to communicate.
I tried to build a new Linux kernel with the needed modules but couldn't get a usable device under/dev/.
Now I've seen on the Kernel page that I'd need to load a devicetree with the IPMB interface over the I2C bus. Can someone tell me how to create a dts file for the I2C hardware?
But at all an other solution for debugging would also be helpfull.
Thanks!
I am new to embedded world and trying to understand the difference between a BSP (Board Support Package) and U-Boot utility. My understanding is that both of them reside on ROM area of the target board. When the board's power is turned ON then first the processor control goes to U-Boot that initializes the board peripherals as well provide boot parameters for the OS to boot-up.
When the OS is launched it needs the BSP to communicate to the board's peripherals.
Is this correct understanding or am I missing something here?
Das U-Boot is a bootloader. It is a piece of software which runs when you turn on the processor. It's job is to load the main software and get it ready to start.
A board support package is all the software that you need to run software on one particular board which is different from what you would need to run on a different board.
A BSP might include a boot loader and that boot loader might be u-boot. If the processor on the board does not need a bootloader or it is pre-programmed in ROM then the BSP might not include a boot loader.
The BSP will also include various other things such as header files or a device tree to tell you which peripherals are connected to which ports and pins, and maybe drivers for those peripherals.
In the last weeks I studied the UEFI spec, tianocore/edk2, and built + booted edk2/OVMF in QEMU. UEFI knows about UEFI applications (section 2.1.2 UEFI Application). I know that examples for UEFI applications are boot managers and (OS-specific) boot loaders, that benefit from the UEFI boot time services (very basic OS-like system, with allocator etc.).
I'd love to know: The regular end consumer understands UEFI as the "nice graphical settings interface where you can use your mouse and click around to change CPU clock settings, RAM timings, and other hardware information" on their (gaming PCs) mainboard.
From a technical aspect: Is this settings menu an UEFI application that uses UEFI boot time services?
Is there any example code for such an application on Github?
Yes these applications are UEFI applications following the specification, take a look at project mu for sample code.
I see GNU EFI is a tool chain to compile applications, but it doesn't seem to come with many libraries.
Tianocore EDK2 comes with a lot of code, with modules and drivers that I'm still figuring out. By default, it builds a full firmware image that I use as a BIOS.
What I need to do is, develop a network-capable application that will query a server for boot instructions, and then prepare the next steps. The idea is to control the boot process from the management server, so the client should be able to follow the instructions to boot from TFTP, or from local storage, or update local storage etc.
You have two main options for writing UEFI network applications.
Managed Network Protocol has the firmware trying to autoconfigure your network and download files as appropriate via TFTP/PXE or HTTPS.
Simple Network Protocol gives you raw access to a packet interface if you want to handle things yourself.
I am trying to create a wifi direct p2p Group owner using wpa_supplicant and wpa_cli. Once the group is create with p2p_group_add, how can we connect legacy wifi devices to the GO? I see the GO in Android mobile search, however I am not able to detect/find GO in legacy laptop with just wifi support. May I know if any configurations need to be done for supporting legacy devices like security type etc. Please suggest.
An autonomous GO should be detected by any legacy wifi device - no special configuration is necessary. The GO should be beaconing and responding to any probe requests, both of which allow a legacy wifi system to detect it (it will just ignore the special P2P IE).
I just tried the same scenario and both my Android phone and my Windows 7 laptop could see the GO running on my Linux laptop.
As your Android phone can see the GO then it is obviously responding to probe requests, so the fact your Windows machine cannot see it is likely to be an issue with the specific netcard used (either in your wpa_supplicant machine, or your Windows machine).
Some further debugging may be necessary to find the root cause, for example using wireshark, and if possible either upgrading the wifi netcard driver on your Windows machine, or swapping it out with a different vendor.