Linux Stuff

ARMV8的spec.对device memory新引入了3个概念，分别是：Gathering, Reordering和Early Write acknowledge.下面从软件工程师的角度去阐述这三个概念。 Gathering The Gathering attribute determines whether it is permissible for either: • Multiple memory accesses of the same type, read or write, to the same memory location to be merged into a single transaction. • Multiple memory accesses of the same type, read or write, to different memory locations to be merged into a single memory transaction on an interconnect. 当某条load/store指令在pipeline的access memory阶段，发生cache miss(对于non-cacheable的memory就直接跳过，不过对于device memory一般都是non-cacheable的)后，需要将access memory请求发到总线上(例如AXI总线)，通过AXI总线访问device memory，这个通过总线访问memory的过程被称为一次transaction. 为了优化性能考虑，在core内，会引入一个Buffer, 当发生一个access memory请求后，会将这个请求信息丢到Buffer中，若某条指令和上一条指令共享同一个cache line或者是访问同一个地址,那么，该条指令便不会再向总线发送transaction了，它share上一条指令 读到buffer中的结果。这个share的过程称为gathering. 读到buffer中的数据，如果是cacheable的，会在某个时间内腾到cache中。 Reordering reordering也是针对device memory的transaction, that is, 某个devic...

DMB: Data memory barrier 理解DMB指令，先看下面例子，在core 0和core1上同时跑两个不同的指令（如下表所示） core 0 core 1 Write A; Write B; Load B; Load A; 这里core0在执行两个指令，写A B两个值的时候， 可能会发生乱序 也可能 Write A时发生Cache Miss ，那么就会导致在cache中 A的最新值更新慢于B的最新值。于是在core1中的指令Load B就会拿到新值，而Load A 就会拿到旧值。如果A与B有相互关系的话，便可能产生死锁等问题。这里有一个典型的例子： https://lkml.org/lkml/2012/7/13/123   于是，就有了下面的解决方法： core 0 core 1 Write A DMB; Write B Load B Load A 在core0所执行的两条指令之间加入一个DMB. 这样，若core1在Load B时，拿到了最新值。那么Load A 也一定拿到了最新值。这就是DMB的作用： DMB前面的LOAD/STORE读写的最新值的acknowledgement在时间上一定先于DMB之后的指令。 DSB 和DMB容易混淆。他们的区别在于：DMB可以继续执行之后的指令，只要这条指令不是内存访问指令。而DSB不管它后面的什么指令，都会强迫CPU等待它之前的指令执行完毕。其实在很多处理器设计的时候，DMB和DSB没有区别（DMB完成和DSB同样的功能）。他们以及ISB在arm reference中的解释如下[1]： A  Data Synchronization Barrier (DSB)  completes when all instructions before this instruction complete. A  Data Memory Barrier (DMB)  ensures that all explicit memory accesses before the DMB instruction complete before any explicit memory ac...

It’s known that there are many tools to debug crash Linux for X86 architecture, such as kdump, LKCD, etc. Although many debugging tools claim that they could support ARM architecture, they are unstable. Is there a reliable method for ARM SOC? Yes, this blog will show a stable method for debugging ARM Linux. There is a premise that you could dump the memory snapshot by some assistive hardware tools when crash happen. This premise is easy for ARM SOC company. This method for debugging ARM Linux is to compose a crash image and analyze the crash kernel with the aid of Crash Utility. Now I will explain this method by step. 1.        Build Linux Kernel for ARM SOC. Please make sure that the feature kexec and debug info are enable. ·          Boot options  --->  ·          [*] Kexec system call (EXPERIMENTAL) ·       ...

crashnote contains register status when crash happens. In kernel, this data is stored “note_buf_t __percpu *crash_notes”. include/linux/kexec.h typedef u32 note_buf_t[KEXEC_NOTE_BYTES/4]; crashnote is also one part of /proc/vmcore. At first, crashnotes[] address, got by reading sys/devices/system/cpu/cpu0/crash_notes, is stored as one program header, which could be got from “elfcorehdr”. Making crash_notes is done by crash_save_cpu(). crash_kexec->machine_crash_shutdown->crash_save_cpu: 1206 void crash_save_cpu(struct pt_regs *regs, int cpu) 1207 { 1208         struct elf_prstatus prstatus; 1209         u32 *buf; 1210 1211         if ((cpu < 0) || (cpu >= nr_cpu_ids)) 1212                 return; 1213 1214      ...

vmcoreinfo_note contains crash kernel general information, include os version, page size etc.. In kernel, vmcoreinfo_note is stored on vmcoreinfo_note[]. And, vmcoreinfo_note is one part of /proc/vmcore, which is used for debugging with capture kernel brings up. In blog " Understanding Kdump (Loading Part) ", one program header including vmcoreinfo_note's address and length was referenced, and this program header could be got from "elfcorehdr". vmcoreinfo_note[]'s address and length could be got by reading /sys/kernel/vmcoreinfo. When kexec is configured, this function will be triggered with kernel brings up. 1458 static int __init crash_save_vmcoreinfo_init(void) 1459 { 1460         VMCOREINFO_OSRELEASE(init_uts_ns.name.release); 1461         VMCOREINFO_PAGESIZE(PAGE_SIZE); 1462 1463         VMCOREINFO_SYMBOL(init_uts_ns); 1464   ...

Capture kernel brings up when panic happens. The specific location in source code and the routine will be analyzed in this blog. 69 void panic(const char *fmt, ...)  70 {  71         static DEFINE_SPINLOCK(panic_lock);  72         static char buf[1024];  73         va_list args;  74         long i, i_next = 0;  75         int state = 0;  76  77         /*  78          * It's possible to come here directly from a panic-assertion and  79          * not have preempt disabled. Some functions called from here want  80          * preempt to be ...