Julram's 개발 낙서장

1. interrupts 체크

# cat /proc/interrupts | grep mmc
 45:        160          0          0          0     GIC-0 161 Level     mmc0
 46:          0          0          0          0     GIC-0 159 Level     mmc1
 47:       1223          0          0          0     GIC-0 157 Level     mmc2

2. debugfs 활용 (mount -t debugfs none /sys/kernel/debug)

# cat /sys/kernel/debug/mmc0/ios 
clock:          50000000 Hz
vdd:            21 (3.3 ~ 3.4 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      2 (4 bits)
timing spec:    7 (sd uhs DDR50)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

# cat /sys/kernel/debug/mmc2/ios 
clock:          100000000 Hz
vdd:            7 (1.65 - 1.95 V)
bus mode:       2 (push-pull)
chip select:    0 (don't care)
power mode:     2 (on)
bus width:      3 (8 bits)
timing spec:    9 (mmc HS200)
signal voltage: 1 (1.80 V)
driver type:    0 (driver type B)

- XMODEM

XMODEM은 시리얼 통신 매체를 활용하여 CP/M 플로피 디스크에 사용된 기본 블록 크기인 128Byte를 채택해 128byte의 데이터 단위 전송 및 프로토콜 규약으로 당시 모뎀을 통한 파일 전송을 보다 쉽게 만들기 위해 탄생했습니다.

XMODEM은 간단하면서도 신뢰성 있는 데이터 전송방식을 제공하여, 이후 YMODEM, ZMODEM 같은 확장 프로토콜이 탄생할 수 있는 기초가 되었습니다.

대부분의 파일 전송 프로토콜과 같이 XMODEM은 원래의 데이터를 일련의 패킷으로 쪼개어 수신자에게 보내며 여기에 추가 정보를 담고 있어서 수신자가 어느 패킷을 올바르게 받았는지를 결정할 수 있게 합니다.

128Byte 프로토콜에서 1Kbyte 형태로 발전하기도 했으며, Checksum 이외에 CRC16 형태로 확장되기도 하여 각 상황 및 설정에 맞춰 통신을 할 수 있도록 설계되어야 합니다.

이번 글에서는 XMODEM 프로토콜의 작동 방식과 패킷 구조, 전송 흐름을 알아보겠습니다.

- XMODEM 프로토콜의 기본 개념

XMODEM은 양방향 통신을 기반으로 하는 오류 검출 방식을 채택하여 데이터를 전송합니다.

특히 종단 간 오류 제어를 위해 체크섬(Checksum) 방식이 사용됩니다.

데이터 전송 시 오류가 발생하면 수신 측에서 오류 패킷을 다시 요청하여 재전송하는 방식으로 파일의 신뢰성을 유지합니다.

XMODEM은 전송 중 패킷 손실이나 손상된 데이터를 감지할 수 있어 당시 모뎀 환경에서 매우 유용했습니다.

- Data Packet Structure

XMODEM 패킷은 128바이트 크기의 고정된 데이터 블록으로 이루어져 있습니다.

각 패킷은 다음과 같은 형식으로 구성됩니다.

1. SOH (Start of Header): 1바이트, 패킷의 시작을 나타내며 ASCII 코드 0x01로 표시됩니다.
2. 블록 번호: 1바이트, 현재 패킷의 순서를 표시합니다. 0부터 시작하여 1씩 증가하며, 255를 넘어가면 다시 0으로 돌아갑니다.
3. 블록 번호의 보수: 1바이트, 블록 번호의 보수를 저장하여 오류를 검증하는 데 사용됩니다.
4. 데이터: 128바이트의 실제 데이터 내용입니다. 파일의 마지막 패킷에서는 부족한 바이트를 0x1A(EOF 문자)로 채웁니다.
5. 체크섬: 1바이트, 오류 검출을 위한 값으로, 데이터 필드의 모든 바이트의 합을 1바이트로 나타냅니다.

Checksum 과 CRC16 프로토콜의 차이는 Data Packet 이후 에러 검출을 위하여 Checksum 1 byte 또는 CRC16의 2 byte 에 따른 데이터 끝부분의 차이가 존재합니다.

- 기본 패킷(Checksum)

- CRC16 패킷

- Transfer flow

XMODEM 프로토콜은 간단하지만 규칙적인 전송 과정을 따릅니다. 송신 측과 수신 측이 데이터를 주고받는 과정을 단계별로 살펴보겠습니다.

1. 전송 시작 신호: 수신 측이 준비되면 ASCII 코드 0x15(NAK) 또는 0x43(C)을 송신 측으로 보내 파일 전송을 시작합니다. 이를 통해 송신 측은 수신 측이 준비되었음을 알 수 있습니다.
2. 데이터 패킷 전송: 송신 측은 각 데이터 블록을 패킷 구조에 맞추어 순차적으로 전송합니다.
3. ACK/NAK 확인: 수신 측은 패킷을 수신한 후 체크섬을 확인합니다. 오류가 없는 경우 ACK(0x16) 신호를, 오류가 있는 경우 NAK 신호를 송신 측에 보냅니다. NAK(0x15) 신호를 받으면 송신 측은 해당 패킷을 다시 전송합니다.
4. 파일 전송 완료: 모든 데이터 패킷 전송이 완료되면 송신 측은 EOT(End of Transmission) 신호를 보내 파일 전송을 마무리합니다. 수신 측이 EOT(0x04) 신호를 확인하면 전송이 끝났음을 인지하게 됩니다.

아래의 표와 같이 위에 설명한 수신 측에서 CRC의 경우 0x43('C')를 전송하여 전송측에 전송 요청을 보내어 통신 시작 및 싱크를 맞춰 진행합니다.

CRC 방식이 아닌 Checksum의 경우 0x15(NAK)를 보내어 시작합니다. 

전송 측으로 전달된 첫 패킷을 수신측에서 제대로 수신할 수 없는 경우 Checksum에서는 0x15(NAK)를 보내지만 CRC의 경우 0x43('C') 값을 보내야 합니다.

해당 상황에서 CRC 전송에서 첫 패킷에 0x15(NAK)를 보내게 될 경우 Tera Term 등의 프로토콜에서는 자동으로 Checksum으로 전환되니 해당 시퀀스에 대해 주의해야 합니다.

전송 시작 이후 SOH 와 각 Data Format에 맞춰 파일 데이터를 수신하며 Checksum 또는 CRC 패킷을 통해 Data 오류 검출 및 정합성을 확인하여 파일 데이터를 수신하고 EOT를 수신하게 되면 통신이 모두 종료되게 됩니다.

결론

XMODEM은 초기 파일 전송 프로토콜로서 통신 기술 발전에 중요한 기여를 했습니다.

이 프로토콜은 기본적인 오류 검출 기능을 통해 파일 전송의 신뢰성을 보장하며, 데이터 통신의 기초 개념을 잘 보여줍니다.

XMODEM을 이해하면, 이후 발전한 다양한 프로토콜의 배경과 원리를 쉽게 이해할 수 있습니다.

이상으로 XMODEM의 개념과 작동 방식을 알아보았습니다.

Virtualbox 사용 시 윈도우와 서로 파일을 주고 받기 편하기 위해 공유 폴더를 설정 할 수 있습니다.

하지만, 아래의 그림처럼 설정을 완료하고 사용하려 해도 권한 문제가 발생한다.

자동 마운트 되는 경로는 '/media' 내에 모두 디렉토리가 생성되어 마운트 되어 있을 것이다.

아래의 그림과 같이 'media' 경로 안에서 'ls -al' 명령어를 통해 확인해 보면 그룹 권한이 'vboxsf' 로 되어 있다.

위의 상황에서 간단한 해결 방법은 내가 사용하는 유저를 'vboxsf' 그룹에 포함 시켜주어야 한다.

위의 그림과 같이 'sudo gpasswd -a USER_ID vboxsf' 명령을 통해 그룹 등록을 진행해주어야 한다.

주의해야 할 점은 그룹 등록이 완료되었다 하더라도 이미 로그인된 세션에는 해당 권한이 적용되지 않으므로

재부팅 또는 로그아웃을 진행해주어야 한다.

RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.

Git 및 Git LFS 등을 사용하여 빌드되는 경우 큰 파일 또는 TLS 값 에러가 발생하는 경우는 파일 수령 시 파일 크기가 Git 설정보다 클 경우 깨지게 된다.

해당 부분을 해결 또는 회피하기 위하여 Git File Buffer 사이즈를 늘려 큰 파일을 받는데 문제가 없도록 수정해야 한다.

하기의 Config 를 참고로 버퍼 크기를 수정하도록 한다.

ex) git config --global http.postBuffer 1048576000

     또는 SSL Verify false --> git config http.sslVerify false 까지 추가

svn Repository 내에서 git 으로 이전 시 사용 되는 명령 내용 정리

git remote add origin (git 주소)

git svn clone svn://(svn 주소) -A users.txt --username (user id) --no-metadata

git push --set-upstream origin master --force

--no-metadata --> git-svn-id 태그 생성 막음

svn users.txt

user_id = user_name <user_id@email.com>

일반적인 리눅스 환경 및 Server에서는 history 명령 및 설정에 의해 각 경로의 .bash_history에 명령 내용이 저장되고 부팅 시 불려지게 된다.

임베디드 환경이나 설정이 정상적으로 되어있지 않은 경우에는 정상적으로 저장되지 못하는 경우가 발생하는데,

이를 해결 하기 위해서 하기의 명령어들을 설정해 주어야 한다.

크게 3가지로 하기의 환경변수를 /etc/profile 또는 유저 디렉토리 내의 .bash_profile에 내용을 추가해준다.

1. HISTFILE : history 명령 및 shell command 내용을 기록할 파일
                 대부분의 경우에는 export HISTFILE=/home/$USER/.bash_history 로 설정된다.

2. HISTFILESIZE 또는 HISTSIZE : HISTFILESIZE의 경우에는 파일의 크기를 나타내며, 후자의 경우는 라인수를 지정한다.

       HISTSIZE의 경우 default 값은 500 이다.

       export HISTSIZE=500 또는 HISTFILESIZE=1000

3. 명령행 실행 시 저장 관련 :  export PROMPT_COMMAND="history -a; history -c; history -r; ${PROMPT_COMMAND}"

위 명령을 추가하여 쉘을 통해 명령 실행 시 저장될 수 있도록 지정해준다.

위 내용들이 정상적으로 적용되어 있는지 경로가 맞는지 확인은 쉘에서 echo ${env} 하여 확인하여 설정을 확인 한다.

ex)

echo $HISTFILE

echo $HISTFILESIZE or $HISTSIZE

echo $PROMPT_COMMAND