Get backtrace

This the place holder for all the investigation made about how to get back trace information at run time.

I have a embedded system running a tiny proprietary real time OS which can handle few tasks. When the system is stopped at debugger break point, from debugger it is easy to find out stack trace of the task get stopped ( or OS kernel ), but I have no way to get other task's stack trace.  ARM's debugging toolchain has little help on this since everything is proprietary.

http://www.dwarfstd.org/doc/DWARF4.pdf
https://github.com/eliben/pyelftools/wiki/User's-guide
http://eli.thegreenplace.net/2011/02/07/how-debuggers-work-part-3-debugging-information/

My girl's math home work

Here is the python script to generate it, she must hate to have a father as a programmer.

DMA Transfer to User Space

http://stackoverflow.com/questions/5539375/linux-kernel-device-driver-to-dma-from-a-device-into-user-space-memory
http://stackoverflow.com/questions/3333959/mapping-dma-buffers-to-userspace
https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt

ATA in Linux

SG_IO
The scsi-core (also known as the "mid level") contains the core of scsi support.
scsi generics driver (sg.o) represent the upper level drivers.

A significant addition in sg v3 is an ioctl() called SG_IO which is functionally equivalent to a write() followed by a blocking read(). In certain contexts the write()/read() combination have advantages over SG_IO (e.g. command queuing) and continue to be supported.

SG_IO call path, the IO request was put to block layer's queue, it is queue handlers responsibility to actually handle the request.

sd_ioctl
scsi_cmd_blk_ioctl
scsi_cmd_ioctl
sg_io
blk_execute_rq
blk_execute_rq_nowait
blk_mq_insert_request

sd_ioctl is registered as ioctl of block_device_operations, which will be registered to system via add_disk(), in function sd_probe_async().


And Here is the queue handling part:

scsi_queue_rq (queue_rq, registered as a blk_mq_ops)
scsi_dispatch_cmd
ata_scsi_queuecmd ( queuecommand )
__ata_scsi_queuecmd
ata_scsi_translate
ata_qc_issue


Zone ATA Command
sd_ioctl
_report_zones_ioctl
blk_zoned_report
blk_cmd_with_sense
blk_cmd_execute
blk_execute_rq



ATA Command Definition
include/linux/ata.h



LibATA
http://linuxmafia.com/faq/Hardware/sata.html

This is the newer ATA driver set for selected SATA chipsets only, maintained by Jeff Garzik, leveraging the kernel's well-tested SCSI layer. Garzik developed it in the 2.6 kernel series. 2.4 support was available only with a backported patch until libata's inclusion in 2.4.27 and later.

libata causes each SATA port appear as a new SCSI bus. There are individual low-level drivers for the individual SATA chipsets, e.g., ahci, pdc_adma, ata_piix, sata_nv, sata_mv, sata_promise, sata_qstor, sata_sil, sata_sil24, sata_sis, sata_sx4, sata_uli, sata_svw, sata_via, sata_vsc.


http://ftp.dei.uc.pt/pub/linux/kernel/people/jgarzik/libata/libata.pdf
struct ata_port_operations is defined for every low-level libata hardware driver, and it controls how the low-level driver interfaces with the ATA and SCSI layers.

ARM Soc Tracing

How It Work
The external debug software configures the trace and debug components through the DAP. The ROM table contains a unique identification code for the SoC and the base addresses of the components connected to the debug APB. The trace stream from the ETM-R4 is replicated to provide on-chip storage using the CoreSight ETB or output off-chip using the TPIU.

Configuring the Trace Data Output Mode on SoC
After a single ATB trace stream is formed through TF, it goes through the Trace Port Interface Unit (TPIU) to reach the trace data pins, TEST[7:0], and trace clock output pin, TEST[8], while in parallel ETM mode
The TPIU formats the ATB trace stream to generate the formatted data output to the SOC pins, which are connected to TPA.
TPA ( Trace Port Analyser ) is a module in sider in DSTREAM.

About IO Access Ordering

Saw an interesting discussion at
https://groups.google.com/forum/#!topic/linux.kernel/AlYdjqXOJCs



> You can find this info in ARMv7 ARM spec[1] named
> "DDI0406B_arm_architecture_reference_manual_errata_markup_8_0.pdf", on
> page A3-45. There is a para that goes:
>
> "Accesses must arrive at any particular memory-mapped peripheral or
> block of memory in program order, that is, A1 must arrive before A2.
> There are no ordering restrictions about when accesses arrive at
> different peripherals or blocks of memory, provided that the accesses
> follow the general ordering rules given in this section."

That is news to me.  My DDI0406B does not have this paragraph, so it's
something that ARM has sprung upon us without telling *anyone* about it.
It's not unreasonable or even unexpected.  That is exactly the same
condition which applies on buses like PCI due to write posting on bridges
downstream of the CPU, and issuing memory barriers will not help with
that.

Consider two PCI devices each behind their own P2P bridge.  Device A's
bridge is really lazy and takes time to empty its write post buffer.
Device B's bridge is really fast at getting writes.  If you write to
device A then device B, they'll arrive at device B before device A.
Again, let me stress that memory barriers will not allow you to solve
this problem.

The only way to solve this is to read back from the device, because reads
to device memory can not bypass writes to device memory, otherwise the
system is unpredictable.  With PCI, it's recommended to read back from
the exact same address which you've written to _provided_ there's no
side effects from doing so.  If there are, you have to find some other
solution to it.

ARM Scatter Loading Info

Image$$ execution region symbols
The following table shows the symbols that the linker generates for every execution region present in the image. All the symbols refer to execution addresses after the C library is initialized.

Table 4. Image$$ execution region symbols 

Symbol	Description
Image$$region_name$$Base	Execution address of the region.
Image$$region_name$$Length	Execution region length in bytes excluding ZI length.
Image$$region_name$$Limit	Address of the byte beyond the end of the non-ZI part of the execution region.
Image$$region_name$$RO$$Base	Execution address of the RO output section in this region.
Image$$region_name$$RO$$Length	Length of the RO output section in bytes.
Image$$region_name$$RO$$Limit	Address of the byte beyond the end of the RO output section in the execution region.
Image$$region_name$$RW$$Base	Execution address of the RW output section in this region.
Image$$region_name$$RW$$Length	Length of the RW output section in bytes.
Image$$region_name$$RW$$Limit	Address of the byte beyond the end of the RW output section in the execution region.
Image$$region_name$$ZI$$Base	Execution address of the ZI output section in this region.
Image$$region_name$$ZI$$Length	Length of the ZI output section in bytes.
Image$$region_name$$ZI$$Limit	Address of the byte beyond the end of the ZI output section in the execution region.