In our project we get ramdumps from other teams which is generated in case of a system crash and need further investigation. I am working on an utility which keeps some board specific data in the ram , which can be later utilized for debugging purpose. In order to better understand the environment/process in which my utility will be used I am trying to figure this information out.
Till now I understand there will be watchdog running (software/hardware), which will get triggered when fed in a particular timeout duration. Once it is triggered it will perform the system reset through some System registers.
Now I am little fuzzy on when the ramdumps are generated , is it before/after reset, or it needs some other tool connected to the board through which ramdumps are captured.
I understand once the ramdumps are available we can run parsers to extract the useful information or can use it in debugger like gdb to further analyse the state leading to the crash.
There are plenty of tools to analyse the ramdump, in other words physical memory dump.
Just imagine after reset what is the condition of RAM. In general, you don't dump the memory after reset you do it before reset in-order to do the memory analysis.
In detail about the RAM-dump in Linux system
Is divided into three sections based on how ramdump is generated, transferred and stored.
The Support in the kernel to enter into ramdump mode when kernel crashes or freezes.
Support in boot-loader to detect ramdump, wait for a host tool to initiate ramdump and send the data to host.
A host tool which can receive data from device and save it on host PC file system.
Later you need to have bootloader support as well, it makes the decision whether to enter into ramdump mode not boot Linux normally.
Ramdump generation during the crash
The kernel panic notifier registered from the ramdump driver will be called by kernel. Ramdump driver do,
Invoke cache sycn api to make sure all the content the ram is coherent.(flush_cache_all(), outer_flush_all())
save core registers to ram
save MMU registers
write MAGIC_CRASH to SRAM regiter.
Then do a reboot. Now boot-loader finds the MAGIC_CRASH in SRAM register and goes to ramdump mode.
Very detailed information about Ramdump Linux inspection.
You can try something like this in fly
$ cat /proc/[your_pid]/maps and the use gdb to inspect
$ gdb --pid [your_pid]
Some tools that can help you.
Go through these lists you will find the information about (FATKit) Foresnic Analysis toolkit.Foriana, etc.
Linux memory analysis tools
How to dump Linux memory?
Related
Guys.
I am trying to study virtual memory management on Nexus 6P(An Old Android Smartphone)
Because the default kernel in AOSP didn't turn CONFIG_FUNCITON_TRACER on, and I can't use function tracer to study memory management related functions.
So I downloaded android kernel source code, turn on config_function_tracer and the other configs its depends, rebuilt kernel. Then I put the rebuilt kernel image file into aosp, rebuilt boot image , and flash the building output images into the phone.
the phone can boot normally, everything is ok but I can't 'cat /sys/kernel/debug/tracing/available_filter_functions' normally, it prompts "no such device".
I checked the selinux label, and I turn off the selinux by command 'setenforce permissive', it can't help.
can anyone help me to fix this problem?
C:\Users\dvdface>adb shell
angler:/ # cd /sys/kernel/debug/tracing/
angler:/sys/kernel/debug/tracing # ls
README dyn_ftrace_total_info per_cpu set_ftrace_pid tracing_cpumask
available_events enabled_functions printk_formats set_graph_function tracing_on
available_filter_functions events saved_cmdlines trace tracing_thresh
available_tracers free_buffer saved_tgids trace_clock
buffer_size_kb instances set_event trace_marker
buffer_total_size_kb max_graph_depth set_ftrace_filter trace_options
current_tracer options set_ftrace_notrace trace_pipe
angler:/sys/kernel/debug/tracing # cat available_filter_functions
cat: available_filter_functions: No such device
I know why I got that error.
When building kernel with CONFIG_FUNCTION_TRACER, that need turn CONFIG_STRICT_MEMORY_RWX off
in this document (https://source.android.google.cn/devices/tech/debug/ftrace)
in the chapter Using dynamic ftrace, it says to turn it off.
after I turn it off, everything is okay.
config STRICT_MEMORY_RWX
bool "restrict kernel memory permissions as much as possible"
help
If this is set, kernel text will be made RX, kernel data and stack
RW, rodata R (otherwise all of the kernel 1-to-1 mapping is
made RWX).
The tradeoff is that several sections are padded to
2M boundaries (because their permissions are different and
splitting the 2M pages into 4K ones causes TLB performance
problems), wasting memory.
I am studying the camera bring up process in Android with Qualcomm platform. I have searched many bring up tutorial but I just can't figure out one thing: most of the tutorial would focus on the .dtsi setting and the driver porting. But I just can't find out where is the camera sensor boot setting. I can see the i2c booting sequence when I log the kernel message, but where the setting be recorded in BSP? Thanks a lot!
Kernel log of camera sensor booting
If the kernel logs those lines, then the kernel sends the settings to the sensor. Which makes sense: initializing a device is supposed to be done by the device driver, and in Linux device drivers are supposed to be in the kernel.
Looking at your log, it seems like a file named msm_camera_cci_i2c.c does it.
After a basic online search, it looks like it comes from an Android kernel, and that msm_camera_cci_i2c.c is just a utility file whoes functions are used by your actual driver. Thus look into your driver, the initialization data should live there.
To know which driver is being used you can look either in your devicetree or navigate through the /sys directory, e.g. in /sys/bus/i2c/devices/.
I am trying to do some low level performance testing related to device processor cores through adb which I feel it is affected by Android background services and system stuff.
As I know that the Android boot sequence stages are as follow:
Execute Boot ROM code.
Execute the boot loader.
Load the Linux kernel.
Launch Zygote, which initializes the Dalvik VM.
System server which loads the Android system.
So my question is how can I interrupt this sequence to force it stop on stage 3 to load Linux kernel. This can help me implement my intermediary performance testings before loading again Android system.
Does Fastboot or Clockworkmod recovery can help here and load my device to a kind of Linux kernel?
Any hint will be appreciated.
Thanks.
Change init parameter in kernel bootargs to something like init=/bin/sh. Usually it can be done somewhere on step 2.
Looking in the android source for the reboot command we find the following line:
__reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, \
LINUX_REBOOT_CMD_RESTART2, argv[optind]);
Which is the standard Linux system call to reboot the system with a specific command, see Unix System Call Reboot.
In Android this command is used to tell the bootloader to start either the kernel in recovery mode or to go to the fastboot mode within the bootloader.
My question is: How does the bootloader pick up the command? And is this functionality implemented in U-Boot? (I am unable to find it searching either through Google or in the U-Boot source.)
Additionally it seems this is not specific to Android, but is the way Linux performs a "reboot with a command". Any information on how this is "normally" handled/used in Linux?
When the system is rebooted using LINUX_REBOOT_CMD_RESTART2, the supplied command string is passed to all of the notifiers registered with register_reboot_notifer(), and finally to machine_restart() - the architecture-specific function that actually performs system restart.
Most architectures ignore the passed command entirely - for an example of one that doesn't, see SPARC. The SPARC implementation of machine_restart() passes the supplied string to the boot command of the PROM.
The ARM implementation of machine_restart() ends up passing the supplied command to arch_reset() which is implemented separately on each ARM platform - from what I can see, most if not all of those implementations ignore the passed command, at least in the upstream kernel. This may not be the droid you're looking for.
Write "boot-recovery" command in MSC partiton. The bootloader reads the string from MSC partition and loads the recovery kernel. This was the way the recovery kernel was loaded in Froyo and before. The same approach can be followed in GB/HC/ICS.
Another method is to carve out some memory and pass some flag which is read from he bootloader. The only issue is that the DRAM contents might get lost during reboot unless you put SDRAM in self refesh mode. So during restart this needs to be taken care of.
First method is useful when the power goes off during the update process. In this case the device need to go into recovery kernel again. In that case MSC partition must be cleared only after whole update process is successful.
I have no clue how they do it in Android, but on our systems where we use u-boot as well we have a similar mechanism.
We reserve a very small memory portion that is reserved for "communication" from bootloader to kernel and the opposite direction as well. If this memory can survive a reboot (put the RAM in self-refresh mode before rebooting, or in Flash), it's then easy to read the value in the bootloader start and to determine if you have to start the kernel and then your system usually or you want to go to a special mode of the bootloader.
On some ARM processors the running kernel sets a flag in one of the CPU registers which is then read by UBOOT keep in mind this stuff if very hardware specific.
I bought a very weak netbook that comes preinstalled with android 2.0 which
I want to replace with another linux distro like puppy or damnSmallLinux.
the netbook has no bios menu with "boot from SD card" option so that and when I inserted an SD card or USB key with grub/lilo it still didn't bot from it.
I wasn't able to find no key sequence to enter android debugging mode so that I don't have root for the android system.
is there an android-internal way to specify boot from another media?
is there a "das-uboot" way to force android boot from another device?
thanks!
I'm not familiar with netbooks running android so here's my experience with embedded devices.
To my best knowledge there is no "android-internal" way. Android takes over after u-boot and rarely(read never) does it modify to u-boot environment partition.
To cut the long story short it's nearly impossible and it's too much effort for nothing.
Also for starters You'll need a debug serial console attached to the board or an ADB shell. It's just guess work without a shell.
For a general algorithm:
get a shell working
Get to know the system( cpu type, partition table, ...)
Now just research what you can do with the things you know.
Or the 'all or nothing' - reverse engineer the firmware upgrade and the firmware images and try to boot with your own.
Long story:
For sd_card boot you have 2 options:
use the bootloaders on the board and load the kernel and the rootfs from the sdcard
boot from sd_card
Load kernel and fs from sd_card:
There is no general u-boot way to change the boot device without changing the u-boot environment . The u-boot environment most of the time resides in a nand partition.
There may be some way coded by the manufacturer, which may be guessed by the offline firmware upgrade procedure. This is probably your best bet for a quick solution.
Try to reverse engineer that.
Boot From sd_card:
Most platforms have SYSCONFIG registers or hardware pins, operated by jumpers on development platforms and mostly hardwired on production ones.
SYSCONFIG controls the boot devices. It can be configured for NAND only or SD_CARD only, etc...
If the system is indeed configured to load from an sd_card there are a few more problems:
Some of the times the SD card has to be formated in a specific way(for ex: http://www.omappedia.org/wiki/SD_Configuration ).
Other times the first stage loader has to be signed. And it's hard figuring out what the first stage bootloader is (x-loader, or something other) and the signing part is kind of tricky :)
you have to know the exact platform configuration to build u-boot and x-loader