Access GitHub Page by Own Domain Name

https://blog.csdn.net/yucicheung/article/details/79560027

fastly
nonssl.global.fastly.net
185.199.108.153 

Linux Kernal Module Exported Symbol

How LKM A can call functions exported by LKM B? 

When LKM B is loaded, Exported symbols are registered to system symbol table in Linux kernel.
When LKM A is loaded,  system do binary search in system symbol table and other modules' symbol table to resolve symbols referenced by LKM A.

Reference
https://www.slideshare.net/shimosawa/nlkb20150221

GNU's LMA and VMA

What is LMA and VMA
Every loadable or allocatable output section has two addresses. The first is the VMA, or virtual memory address. This is the address the section will have when the output file is run. The second is the LMA, or load memory address. This is the address at which the section will be loaded. In most cases the two addresses will be the same. An example of when they might be different is when a data section is loaded into ROM, and then copied into RAM when the program starts up (this technique is often used to initialize global variables in a ROM based system). In this case the ROM address would be the LMA, and the RAM address would be the VMA.

You can see the sections in an object file by using the objdump program with the -h option.

Configure LMA/VMA in Linker Script
The full description of an output section looks like this:
   

section [address] [(type)] : [AT(lma)]
  {
    output-section-command
    output-section-command
    ...
  } [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp]

Generating Binary Image (to burn to Flash)
objcopy can be used to generate a raw binary file by using an output target of `binary' (e.g., use `-O binary'). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file.


Move LMA to VMA
GNU toolchain does not have scattering mechanism like that in ARM toolchain. so BSS (zero init) part needs to be init by startup code.  no library to do that.

How to find out the .bss part?  via __bss_start__ and __bss_end__

_cstartup:

    /* Relocate .fastcode section (copy from ROM to RAM) */

    LDR     r0,=__fastcode_load

    LDR     r1,=__fastcode_start

    LDR     r2,=__fastcode_end


    .fastcode : {

        __fastcode_load = LOADADDR (.fastcode);

        __fastcode_start = .;


        *(.glue_7t) *(.glue_7)

        *isr.o (.text.*)

        *(.text.fastcode)

        *(.text.Blinky_dispatch)

        /* add other modules here ... */


        . = ALIGN (4);

        __fastcode_end = .;

    } >RAM AT>ROM

Reference
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/scripts.html#BASIC-SCRIPT-CONCEPTS

https://www.embedded.com/design/mcus-processors-and-socs/4007119/Building-Bare-Metal-ARM-Systems-with-GNU-Part-1--Getting-Started
http://www.delorie.com/gnu/docs/binutils/ld_19.html
http://www.delorie.com/gnu/docs/binutils/ld_33.html
https://ftp.gnu.org/old-gnu/Manuals/binutils-2.12/html_chapter/binutils_3.html

Install Old Kernel In Ubuntu

In Synaptics

Find below packets to install.
linux-headers-4.4.0-XX
linux-headers-4.4.0-XX-generic
linux-image-4.4.0-XX-generic
linux-image-extra-4.4.0-XX-generic
linux-signed-image-4.4.0-XX-generic 

Windows Blue Screen: ATTEMPTED_SWITCH_FROM_DPC

While debugging my windows driver, I got a blue screen with error code ATTEMPTED_SWITCH_FROM_DPC,

MS doc says one cannot wait in a DPC:

A wait operation, attach process, or yield was attempted from a DPC routine. This is an illegal operation.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xb8--attempted-switch-from-dpc

I think it relates to locking a resource with WdfWaitLockAcquire(), which is called in a completion function of a IO request.

MS doc says:

If the driver services the I/O request by creating I/O activity on the device, the driver typically calls WdfRequestComplete from its EvtInterruptDpc or EvtDpcFunc callback function.

https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/completing-i-o-requests

So the completion function could be called in the DPC context. 


I can use spin lock though:

On the other hand, they can acquire and release a driver's executive spin lock with KeAcquireSpinLockAtDpcLevel and KeReleaseSpinLockFromDpcLevel, which run faster than KeAcquireSpinLock and KeReleaseSpinLock.

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/guidelines-for-writing-dpc-routines

Program Loading Pratice on ARM Platform

The GNU toolchain and ARM toolchain have different approaches for handling the program's linking and loading.

A program have several sections for code and data.  Normally in ARM embedded system,  before invoking a program's "main" function, code/data sections needs to be located at exact position of the memory as specified in the linking time.

An simple example explaining what is happening at the early phase of program running
- A program image is loaded in to DRAM, each sections in the image are in their loading address now. The ARM toolchain call it loading address, GNU toolchain call it LMA(loading memory address), I will call it LMA now on.
-  The next step is to make each section in the image to be relocated to their execution address as specified in the linking time. ARM toolchain calls it execution address. GNU toolchain call it VMA(virtual memory address), I will call it VMA from now on.

ARM toolchain using Scatter-loading mechanism to get section from LMA to VMA.  For details, see http://wikigu.blogspot.jp/2017/01/arm-scatter-file-explain.html
One thing needs to be noted here is that, each section in ARM toolchain generated AXF file(ELF format) has the same LMA and VMA.  The actually LMA/VMA mapping information is in linker generated InRoot$$Section. When ARM library function "__main" function is called, the section are copied from LMA to VMA according to info in InRoot$$Section.

GNU toolchain does not have similar Scattering-loading mechanism as the ARM. The LMA and VMA specified in the linker file are actually put in the ELF's header information. The LMA information is actually in the ELF's programmer's p_paddr.  

The startup code of the image is responsible for copying the section from the LMA to VMA. There is no library function call provided by toolchain to do that. 
Below is a good example.
https://www.embedded.com/design/mcus-processors-and-socs/4026075/Building-Bare-Metal-ARM-Systems-with-GNU-Part-2
https://www.embedded.com/design/mcus-processors-and-socs/4026080/Building-Bare-Metal-ARM-Systems-with-GNU-Part-3

Handling of Data Section In Image

ARM Linker

RW section is compressed in image the decompressed at loading.

http://www.keil.com/support/man/docs/armlink/armlink_pge1362065930871.htm

RW data areas typically contain a large number of repeated values, such as zeros, that makes them suitable for compression.
RW data compression is enabled by default to minimize ROM size.
The linker compresses the data. This data is then decompressed on the target at run time.