AREA REL,PIC,READONLY,ALIGN=4
EXPORT text
EXPORT txttbl
NML EQU 1
ABNRHY EQU 2
BO EQU 4
ABN EQU 8
text
base
snf DCW 1
DCB 0
DCB " ",0
DCB "",0
ALIGN 1
spedanl DCW 2
DCB 0
DCB "** * * **",0
DCB "",0
ALIGN 1
sagspami DCW 3
DCB 0
DCB "*** ***",0
DCB "",0
ALIGN 1
stwlvw DCW 6
DCB 0
DCB " ",0
DCB "",0
ALIGN 1
ssr DCW 19
DCB NML
DCB " ",0
DCB " ",0
ALIGN 1
sarat DCW 20
DCB 0
DCB " ",0
DCB "",0
ALIGN 1
ALIGN 2
txttbl
DCW spedanl-base,sagspami-base,stwlvw-base,ssr-base,sarat-base
DCW snf-base
END
This is my .src file and my compiler options are arm-none-eabi-gcc with flags -c -fmessage-length=0 -fno-asm and assembler flags-c -x assembler-with-cpp.
I get the error bad instruction for every single line of code, the project is in C build for arm cortex m7
Related
I am trying to learn shell script and writing a simple script to increment Hex values in the loop.
Here is my script:
increment=0x0001
handle=0x0001
for((i=1;i<=20;i++))
do
echo $handle
handle=$(($handle + $increment))
handle=$(printf '%x' $handle)
done
Here is my output:
0x0001
2
3
4
5
6
7
8
9
a
1
2
3
4
5
6
7
8
9
a
It is working fine till 10th iteration but after that it is starting from 1 again.
Can any one let me know my mistake?
EDIT: After removing handle=$(printf '%x' $handle) line output is:
0x0001
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Actually I want output in HEX only.
It has to do with how you print the value try printf '%#x' or printf '%#X'
Just change the line you are using to print the content with a leading 0x as:-
handle=$(printf '%#x' $handle)
(or) to have leading hex-character as 0X
handle=$(printf '%#X' $handle)
With the changes, you get the output as below:-
$ ./script.sh
0x0001
0x2
0x3
0x4
0x5
0x6
0x7
0x8
0x9
0xa
0xb
0xc
0xd
0xe
0xf
0x10
0x11
0x12
0x13
0x14
0x15
0x16
0x17
0x18
0x19
0x1a
0x1b
0x1c
0x1d
0x1e
0x1f
0x20
For more formatting options check here:- http://wiki.bash-hackers.org/commands/builtin/printf (and) http://ss64.com/bash/printf.html
I am new to SCTP protocol and trying to figure out how to interpret the SCTP stats captured by /proc/net/sctp
The output shows something like this.
2016-04-26 07:21:17
ASSOC SOCK STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC wmema wmemq sndbuf rcvbuf
ce0f1800 cd7ede00 2 1 3 11661 1783 423 0 77 292723 36422 36423 10.205.8.71 <-> *10.205.8.72 3000 10 10 10 0 0 0 873 704 163840 163840
ca625800 cd7ec000 2 1 3 65210 1 0 0 77 10344 3223 36412 10.205.8.71 <-> *10.205.0.135 3000 2 2 10 0 0 3 1 0 163840 163840
ENDPT SOCK STY SST HBKT LPORT UID INODE LADDRS
ca511d80 cd7ec3c0 2 10 40 36422 77 10345 10.205.8.71
ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX START
10.205.8.72 1783 1 200 5 0 0
10.205.0.135 1 1 200 15 0 0
SctpCurrEstab 2
SctpActiveEstabs 21
SctpPassiveEstabs 1855
SctpAborteds 272
SctpShutdowns 1808
SctpOutOfBlues 0
SctpChecksumErrors 0
SctpOutCtrlChunks 79214
SctpOutOrderChunks 327396
SctpOutUnorderChunks 0
SctpInCtrlChunks 268038
SctpInOrderChunks 174268
SctpInUnorderChunks 0
SctpFragUsrMsgs 0
SctpReasmUsrMsgs 0
SctpOutSCTPPacks 406626
SctpInSCTPPacks 385959
SctpT1InitExpireds 0
SctpT1CookieExpireds 0
SctpT2ShutdownExpireds 0
SctpT3RtxExpireds 5
SctpT4RtoExpireds 0
SctpT5ShutdownGuardExpireds 0
SctpDelaySackExpireds 9869
SctpAutocloseExpireds 0
SctpT3Retransmits 5
SctpPmtudRetransmits 0
SctpFastRetransmits 14
SctpInPktSoftirq 384346
SctpInPktBacklog 1613
SctpInPktDiscards 0
SctpInDataChunkDiscards 0
Can some one help me understand this or provide the link where i can get some information.
Thanks,
Vishal
The linux man page for SCTP (http://linux.die.net/man/7/sctp) has most of them covered - for example:
SctpChecksumErrors
The number of SCTP packets received with an invalid checksum.
SctpOutCtrlChunks
The number of SCTP control chunks sent (retransmissions are not included). Control chunks are those chunks different from DATA.
SctpOutOrderChunks
The number of SCTP ordered data chunks sent (retransmissions are not included).
SctpOutUnorderChunks
If there is a particular one you were wondering about, maybe let us know?
It was really confusing to deal with hexdump command in linux.
Basically I am trying to get the output from the /proc/device-tree.
I tried to use the hexdump but ended up with confusion.
My dts contains
vvn = <0 0 2 2 0 0>;
I got a proc node under /proc/device-tree.
I tried the following command.
hexdump -v -e '4/1 "%x" " "' vvn ; echo
0000 0000 0002 0002 0000 0000
hexdump -v -e '1/4 "%x" " "' vvn ; echo
0 0 2000000 2000000 0 0
hexdump -v -e '4/1 "%x "' vvn ; echo
0 0 0 00 0 0 00 0 0 20 0 0 20 0 0 00 0 0 0
I got different output, I thought all will produce the same output.
Can anyone please explain me how to use the iterationcount and bytecount of the hexdump and what it's for and How to use the format too?
Iteration count controls how may times the format will be repeated.
Byte count indicates how many byte will be format for each iteration.
Format string is the same as that of printf.
'4/1 "%x" " "': iteration for 4 times: in each time, format 1 byte with "%x", and when the iteration finished, insert " ".
'1/4 "%x" " "': iteration for 1 time: in each time, format 4 byte with "%x", and when the iteration finished, insert " ". This is equal to '1/4 "%x "'
'4/1 "%x "': iteration for 4 times: in each time, format 1 byte with "%x "; when iteration finished, eats the last space, insert nothing.
I do know why hexdump eats the last space :(.
This is the ouput of the blktrace. I could not understand what is "N 0 (00 ..) [multipathd]". I'm testing the write IO performance of the FS.
I have 2 doubts,
N - is a action, but I dont find the usage of it in the blktrace.pdf.
What is the difference between IOSTAT and BLKTRACE.
blktrace o/p:
8,128 7 11 85.638053443 4009 I N 0 (00 ..) [multipathd]
8,128 7 12 85.638054275 4009 D N 0 (00 ..) [multipathd]
8,128 2 88 89.861199377 5210 A W 384 + 8 <- (253,0) 384
8,128 2 89 89.861199876 5210 Q W 384 + 8 [i_worker_0]
8,128 2 90 89.861202645 5210 G W 384 + 8 [i_worker_0]
8,128 2 91 89.861204604 5210 P N [i_worker_0]
8,128 2 92 89.861205587 5210 I WA 384 + 8 [i_worker_0]
8,128 2 93 89.861210869 5210 D WA 384 + 8 [i_worker_0]
8,128 2 94 89.861499857 0 C WA 384 + 8 [0]
8,128 2 95 99.845910681 5230 A W 384 + 8 <- (253,0) 384
8,128 2 96 99.845911148 5230 Q W 384 + 8 [i_worker_20]
8,128 2 97 99.845913846 5230 G W 384 + 8 [i_worker_20]
8,128 2 98 99.845915910 5230 P N [i_worker_20]
8,128 2 99 99.845917081 5230 I WA 384 + 8 [i_worker_20]
8,128 2 100 99.845922597 5230 D WA 384 + 8 [i_worker_20]
There is introduction to blktrace http://duch.mimuw.edu.pl/~lichota/09-10/Optymalizacja-open-source/Materialy/10%20-%20Dysk/gelato_ICE06apr_blktrace_brunelle_hp.pdf
difference between IOSTAT and BLKTRACE.
Check slides 5 and 6:
The iostat utility does provide information pertaining to request queues associated with
specifics devices
– Average I/O time on queue, number of merges, number of blocks read/written, ...
– However, it does not provide detailed information on a perI/O basis
Blktrace. Low-overhead, configurable kernel component which emits events for specific operations performed on each I/O entering the block I/O layer
So, iostat is generic tool to output statistics; and blktrace is tool to capture and output more information about all I/O requests served in the time when tool was active.
Slide 11 has some decoding intro
8,128 7 11 85.638053443 4009 I N 0 (00 ..) [multipathd]
maj/min cpu seq# timestamp_s.ns pid ACT RWBS blocks process
multipathd is kernel daemon, because its name is included into [] braces.
The default format is described in the blktrace.pdf (here is source of the pdf: http://git.kernel.org/cgit/linux/kernel/git/axboe/blktrace.git/tree/doc/blktrace.tex)
"%D %2c %8s %5T.%9t %5p %2a %3d "
%D Displays the event's device major/minor as: \%3d,\%-3d.
%2c CPU ID (2-character field).
%8s Sequence number
%5T.%9t 5-charcter field for the seconds portion of the
time stamp and a 9-character field for the nanoseconds in the time stamp.
%5p 5-character field for the process ID.
%2a 2-character field for one of the actions.
%3d 3-character field for the RWBS data.
Actions
C -- complete
D -- issued
I -- inserted
Q -- queued
B -- bounced
M -- back merge
F -- front merge
G -- get request
S -- sleep
P -- plug
U -- unplug
T -- unplug due to timer
X -- split
A -- remap
m -- message
RWBS
'R' - read,
'W' - write
'D' - block discard operation
'B' for barrier operation or
'S' for synchronous operation.
So, for multipathd we have "I" action = "inserted" and N for RWBS, and the N is strange. There is no N in the doc and even in the source: blkparse_fmt.c - fill_rwbs(). Why? Because it is old doc and old source.
In modern kernel, for example, 3.12 there is N in the fill_rwbs: http://sources.debian.net/src/linux/3.12.6-2/kernel/trace/blktrace.c?hl=1038#L1038
if (t->action == BLK_TN_MESSAGE) {
rwbs[i++] = 'N';
goto out;
}
And the blktrace_api.h declares BLK_TN_MESSAGE as
#define BLK_TN_MESSAGE (__BLK_TN_MESSAGE | BLK_TC_ACT(BLK_TC_NOTIFY))
* Trace categories
BLK_TC_NOTIFY = 1 << 10, /* special message */
* Notify events.
__BLK_TN_MESSAGE, /* Character string message */
So, 'N' is notify action with string message. I think the message is seen instead of "blocks" field. I was able to find the patch which added the TN_MESSAGE, but there was no update of the documentation (just as planned in bazaar-model like linux) http://lkml.org/lkml/2009/3/27/31 "[PATCH v2 6/7] blktrace: print out BLK_TN_MESSAGE properly" 2009
I have these two files myboot.asm and theirboot.asm (listed respectively):
;----------------------------------------------------------------------
; A Simple boot program that prints the string 'Hello World'
; Author: Matthew Hoggan 2012
;----------------------------------------------------------------------
Output db 'Hello',0x00 ; Output string for bios
org 0x7c00 ; This is where BIOS loads the bootloader
entry: ; Label to Signify entry to program
jmp short begin ; Jump over the DOS boot record data
; --------------------------------------------
; Boot program code begins here
; --------------------------------------------
begin: ; Label to Signify entry to program
mov si, Output ; Get pointer to string
loop: ; Top of loop to iterate over string
mov al, [si] ; Move contents of pointer to al
or al, al ; Check if character pointed to is Zero
jz hang ; Zero signifies end of string
call print_char ; Print current char in al
jmp loop ; Repeat
; --------------------------------------------
; Function to print char
; assume caller has placed char in al
; --------------------------------------------
print_char:
mov ah, 0x0e ; Function to print a character to the screen
mov bl, 7 ; color/style to use for the character
int 0x10 ; print the character
hang:
jmp hang ; just loop forever.
;---------------------------------------------
; Write Zeros up to end of program - 2 then boot signature
;---------------------------------------------
size equ $ - entry
times (512 - size - 2) db 0
db 0x55, 0xAA ;2 byte boot signature
;----------------------------------------------------------------------
; A Simple boot program that prints the string 'Hello World'
;----------------------------------------------------------------------
org 0x7c00 ; This is where BIOS loads the bootloader
entry: ; Label to Signify entry to program
jmp short begin ; Jump over the DOS boot record data
; --------------------------------------------
; Boot program code begins here
; --------------------------------------------
begin: ; Label to Signify entry to program
xor ax, ax ; Zero out ax
mov ds, ax ; Set data segment to base of RAM
mov si, msg ; Get pointer to string
call putstr ; Print the message
jmp hang ; Go to infinite loop
msg db 'Hello, World',0x00
putstr: ; Function to print the string
lodsb ; al = [DS:SI]
or al, al ; Set zero flag if al = 0
jz ret ; Jump to end of function if al = 0
mov ah, 0x0e ; Video function 0Eh (print char)
mov bx, 0x0007 ; Color
int 0x10
jmp putstr
ret:
retn
hang:
jmp hang ; just loop forever.
;---------------------------------------------
; Write Zeros up to end of program - 2 then boot signature
;---------------------------------------------
size equ $ - entry
times (512 - size - 2) db 0
db 0x55, 0xAA ;2 byte boot signature
Building both of these files running hexdump on them and listing the files in the directory to see their size reveals:
mehoggan#mehoggan-laptop:~/Code/play/asm$ nasm myboot.asm -f bin -o boot.bin && hexdump boot.bin && ls -l && echo "------" && nasm bootloader1.asm -f bin -o boot.bin && hexdump boot.bin && ls -l
0000000 6548 6c6c 006f 00eb 00be 8a7c 0804 74c0
0000010 e80c 0003 f4e9 b4ff b30e cd07 e910 fffd
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 0000 0000 aa55
0000206
total 20
-rw-r--r-- 1 mehoggan mehoggan 518 2012-02-29 21:57 boot.bin
-rw-r--r-- 1 mehoggan mehoggan 2290 2012-02-29 20:23 bootloader0.asm
-rw-r--r-- 1 mehoggan mehoggan 1661 2012-02-29 21:55 bootloader1.asm
-rw-r--r-- 1 mehoggan mehoggan 1786 2012-02-29 21:49 myboot.asm
-rw-r--r-- 1 mehoggan mehoggan 1065 2012-02-29 20:14 ourbootloader.asm
------
0000000 00eb c031 d88e 0fbe e87c 0010 1de9 4800
0000010 6c65 6f6c 202c 6f57 6c72 0064 08ac 74c0
0000020 b40a bb0e 0007 10cd f1e9 c3ff fde9 00ff
0000030 0000 0000 0000 0000 0000 0000 0000 0000
*
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55
0000200
total 20
-rw-r--r-- 1 mehoggan mehoggan 512 2012-02-29 21:57 boot.bin
-rw-r--r-- 1 mehoggan mehoggan 2290 2012-02-29 20:23 bootloader0.asm
-rw-r--r-- 1 mehoggan mehoggan 1661 2012-02-29 21:55 bootloader1.asm
-rw-r--r-- 1 mehoggan mehoggan 1786 2012-02-29 21:49 myboot.asm
-rw-r--r-- 1 mehoggan mehoggan 1065 2012-02-29 20:14 ourbootloader.asm
Why are the files sizes off by 6 bytes?
Check out the last little block of assembly code there:
size equ $ - entry
times (512 - size - 2) db 0
db 0x55, 0xAA ;2 byte boot signature
This block of code calculates how big the code is (from entry to the current location), then pads it out to a total of 512 bytes with zeroes and a signature 0x55 0xAA in the last two positions. That is:
entry: Some code
.
.
.
Some zeroes
.
.
.
0x55 0xAA
That little assembly block means the output size from the entry label to 0x55 0xAA is always 512 bytes. In your first example, there is a six byte string Hello\0 before entry. In your second example there's not. Therefore, the first program is six bytes longer than the second. You probably want to move that string to someplace after entry and before the padding block.
If you use hexump -C on your binaries, you'll see the string right up at the top of the first binary.