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.

ATA Operations

Access ATA registers.

PC/AT ports information:
http://stanislavs.org/helppc/ports.html

// Get Taskfile cylinder high register value
#include 
#define kinp(p)      inp(p)
#define ide_cyh0     ((U16)0x01f5) /* cylinder high register */

cyl_high = (U8)kinp(ide_cyh0);

DMA Access

DMA setting up is via BIOS interrupt call:
http://en.wikipedia.org/wiki/BIOS_interrupt_call

__asm {
    mov ax, 0xB10B
    mov bh, Base_B_Number
    mov bl, Base_DF_Number
    mov di, 0x48
    mov cl, hcl
    int 0x1A

Sequence of w/r DMA transfer:
  - Setup PRD table ( http://wiki.osdev.org/ATA/ATAPI_using_DMA ) 
  - Config DMA resigsers
  - Set IDE PRD table address to IDE port
  - Interrupt config
  - Sent out command to ide status/command port
  - Polling status port to wait for the command ends

A Bug of ARM Compiler Error

Log an ARM compiler error.
Be careful bit field in the structure.
Good case, to write a the bit field, read/modify/write operation is done: do 4 bytes ready, update 3 bytes, write 4 bytes back.

 
 // With this structure  
 typedef __packed struct{  
   mUINT_32 nvSecSetIndex : 24;
   mUINT_32 dummy : 16;
 }mtNV_SEC_SET; 
 
 // We get compile result  
 nvSecSetIndex = setIndex;  
 00139a 9001         STR   r0,[sp,#4]  
 00139c f7fffffe     BL    __aeabi_uread4  
 0013a0 f3650017     BFI   r0,r5,#0,#24  
 0013a4 9901         LDR   r1,[sp,#4]  
 0013a6 f7fffffe     BL    __aeabi_uwrite4   

NG case, do 4 bytes write directly. This will overwrites the memory of address ((int)&(p->nvSecSetIndex) + 3). Happens when the structure has only one bit field.

  
 // With this structure  
 typedef __packed struct{  
   mUINT_32 nvSecSetIndex : 24;   
 }mtNV_SEC_SET;  

 // We get compile result  
 nvSecSetIndex = setIndex;  
 00139a 4628         MOV   r0,r5  
 00139c f7fffffe     BL    __aeabi_uwrite4   

Compiler

http://stackoverflow.com/questions/1669/learning-to-write-a-compiler

ARM Data Abortion

Example handle an data abortion exception
----------------
R14 value is 0x0000021e
0x0000021e - 8 = 0x00000216.
The instruction which caused the exception is at address 0x00000216

Reference
----------------
http://www.keil.com/support/docs/3080.htm

ARM Function Call in Assembly

Quotation:
This calling convention causes a "typical" ARM subroutine to:
- In the prolog, push r4 to r11 to the stack, and push the return address in r14, to the stack. (This can be done with a single STM instruction).
- copy any passed arguments (in r0 to r3) to the local scratch registers (r4 to r11).
- allocate other local variables to the remaining local scratch registers (r4 to r11).
- do calculations and call other subroutines as necessary using BL, assuming r0 to r3, r12 and r14 will not be preserved.
- put the result in r0
- In the epilog, pull r4 to r11 from the stack, and pulls the return address to the program counter r15. (This can be done with a single LDM instruction).


Reference:
http://en.wikipedia.org/wiki/Calling_convention#ARM
http://omappedia.org/wiki/Writing_ARM_Assembly#EABI_Calling_conventions
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf