Big-endian/Little-endian, LSB/MSB

Least significant byte (LSB) Most significant byte (MSB)

Big-endian machines store the most-significant byte at the lowest-numbered address, with the other bytes following in decreasing order of significance. Little-endian machines store multi-byte numbers in the opposite order: from least-significant to most-significant.

Internet diagram is big-endian.  STM32 ARM-CM3 is little-endian.

这是从wiki的Example

如何用简单的方法检查是大端还是小端

uint8_t IsBigEndian(void)
{
   volatile uint32_t temp = 0x0a0b0c0d;
   return (*((uint8_t*)(&temp))) == 0x0a;
}

void EndianTest(void)
{
   if (IsBigEndian() == )
   {
      std::cout << "it is a big-endian" << std::endl;
   }
   else
   {
      std::cout << "it is a little-endian" << std::endl;

   }
}

从调试也可以看出内存地址和值, 注意0x0a是most-significant byte。

字节顺序其实就是说在计算机内存中怎么存储，是说从左到右，还是从右到左。对于在一个机器内的数据交互，那种字节顺序都没有关系。主要的问题是在不同机器上交互，比如你设计一个总线系统，那么你就要充分考虑你的通讯协议使用大端还是小端。比如说TCP/IP协议它就是是按照big-endian来设计的，因为你不知道网络系统的电脑，路由器，等等的字节顺序，所以在设计通讯协议时就要充分考虑到这一点。

在TCP/IP里有一系列的函数用于字节的转换如htons (covert host byte to network byte short 16bit), htonl (convert host byte to network byte long 32bit), ntohs (network byte to host byte short 16bit), ntohl (convert network byte to host byte long 32bit). 当你设计通讯协议时，这些函数你就要自己实现了。

说到TCP/IP，让我想起一个我们以前遇到的一个问题，我们的panel在客户那里每个星期二凌晨都会自动重启。后来分析是由于客户每个星期二IT部门会用nmap进行扫描，而TCP/IP字节数的问题造成系统死了，后由Watchdog重启。我把以前分析的一些简要内容放在这里(只有英语版)。

Problem Description

The field reports show that panel will lockup and then reboot while doing security port scan by nmap.

Root Cause

After analysis, this problem happens at all panel versions, standalone/networking panel, and happens at other scanning tools (e.g. Tenable Nessus).

The investigation shows that, the problem was caused by unaligned data access during TCP timestamps option parsing in Linux kernel. The reason can be summarized below:

1)      The ARMv5 or earlier MCU (likes panel MCU S3C44B0X ARM7TDMI is belong to ARMv4T), who had limited abilities to access memory that was not aligned on a word (four byte) boundary. According to S3C44B0 datasheet (see page 89 Address Alignment), the MCU is going to ABORT mode which cause the system crash.

2)      In Linux TCP option parsing, the handling did not consider the data unaligned in timestamp option, but TCP options are not guaranteed to be aligned at all.

According to the Linux debug output information when TCP package with timestamps options: The timestamps hold address (register: R8) is 0x0DB074E2, which is not multiple 4(word), the Linux kernel error information is: Unhandled fault: alignment exception (13).

1)      TCP package by nmap

2)      Linux debug output

Solution

The solution is get word value byte one byte when the address is unaligned, which is come from official Linux kernel patch (see appendix). The change is only applied for TCP/IP option parsing and without side effect. The solution had been successfully verified by prototype.

Purpose: for field panels, firmware upgraded is the recommended solution if the panel was be connected to internet or corporate network, and it is not need to upgrade firmware if the panel was not be connected to network.

Appendix

The patch is come from Linux official, the link is https://archive.org/details/git-history-of-linux.