Overview

Target: Using Hexo to create Embux FAQ & Documentation website.

Note: Hexo is a fast, simple and powerful blog framework. You write posts in Markdown (or other languages) and Hexo generates static files with a beautiful theme in seconds.

Installation

Quick Guideline

• Pre-requirement: Node.js and Git

• Install Hexo $ npm install -g hexo-cli

• fix git deploy error
  npm install hexo-deployer-git –save

• hexo full text search
  npm install hexo-generator-search –save

Refer:

• Hexo: Getting Started - Overview for detail information and installation steps.
• Hexo FAQ

Setup

• Initialize Hexo

1
2
3

$ hexo init <folder>  
$ cd <folder>
$ npm install

Note: , target folder to store the hexo website

Once the initialization complete, the folder structure will like

1
2
3
4
5

├──  _config.yml  # the major config file
├──  package.json # application data
├──  scaffolds    # for each new post, Hexo bases the new file on it
├──  source		  # where the document 
└──  themes       # theme contents

Refer to Hexo: Getting Started - Setup for detail information.

Configuration

Modify site settings in _config.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# Site
title: EMBUX

# URL
permailnk: :title/    # change to remove date&time folder type

# Writing
filename_case: 1      # use lower case for file naming

# Extensions
theme: embux	         # change to custom theme

# Deployment
deploy:
  type: git
  repo: https://github.com/embux/embux.github.io.git
  branch: master

Refer to Hexo: Getting Started - Configuration for detail information.

Commands

• init: $ hexo init <folder>
• new: $ hexo new [layout] <title>
  • layout: using “draft” for imcomplete article
• generate: $ hexo g
• publish: $ hexo p # publish a draft
• server: $ hexo s -p 4000 # start a local server for preview
• deploy: hexo d # deploy web-site to pre-defined(_config.yml) web-site
• clean: hexo clean # clean the cache file

Refer to Hexo: Getting Started - Commands for detail information.

Customization

Rss

npm install hexo-generator-feed --save

change themes/XXX/_config.yml

rss: /atom.xml

Sitemap

npm install hexo-generator-sitmap --save

refer: Original link

Tethering means sharing the Internet connection of an Internet-capable mobile phone with other devices. This sharing can be offered over a wireless LAN (Wi-Fi), or over Bluetooth, or by physical connection using a cable (Tethering).

Our focus in this article will be the USB tethering.
Your Android mobile phone can behave as an external network interface usbN, connected via the USB infrastructure. The usbN interface is in turn connected to the mobile phone LAN, providing dhcp server, DNS server, gateway and so on.
That’s how your mobile phone can provide an Internet connection to another device.

Android phones are already equipped to provide this functionality. Simply connect the USB cable and go to Settings -> Wireless settings -> Tethering -> Tethering USB.

What you need is some kernel and network configuration on the other side (e.g. your laptop).

Contents

1
2
3
4
5
6
7
8

1 Kernel configuration
2 Tested Devices
3 Testing
4 Connecting
    4.1 Manually
    4.2 Permanent configuration
    4.3 Checks
5 Advanced network settings

Kernel configuration

KERNEL .config 3.0.6-gentoo

1
2
3
4
5
6
7
8
9
10
11

General setup  --->
    [*] Prompt for development and/or incomplete code/drivers
Device Drivers --->
    [*] Network device support --->
        USB Network Adapters --->
            [*] Multi-purpose USB Networking Framework
                <M> CDC Ethernet support
                <M> CDC EEM support
                <M> Simple USB Network Links (CDC Ethernet subset)
                <M>   Host for RNDIS and ActiveSync devices
            [*] Embedded ARM Linux links

KERNEL .config 3.12.21-gentoo-r1

1
2
3
4
5
6
7
8

Device Drivers --->
    [*] Network device support --->
        USB Network Adapters --->
            [M] Multi-purpose USB Networking Framework
                <M> CDC Ethernet support
                <M> CDC EEM support
                [M] Simple USB Network Links (CDC Ethernet subset)
                    [*] Embedded ARM Linux links

You can either build the options in the kernel or leave them as module.

Note. The RNDIS option seems to be needed in some situation only. See this thread to learn more.

Tested Devices

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Google Nexus One (Android 2.3.6 build GRK39F)
Google Nexus 4 (Android 4.3 build JWR66Y - uses rndis_host)
HTC One M7 (Sense 5.5, Android 4.3, Software number 3.62.401.1,HTC SDK API level 5.65 - I used rndis_host, cdc_ether and usbnet modules ONLY to get it to work)
LG P350 (Android 2.2.1 build FRG83)
LG E400 (Android 2.3.6 build GRK39F)
LG L7 P705 (Android 4.1.2 build JZO54K)
Motorola Defy (Android 2.3.7 Cyanogenmod 7)
Motorola Moto G 4G 2013 (1st Gen) (Android 5.1) -- needed rndis_host module -- User:mercuriete
Samsung Galaxy S i9000
Samsung Galaxy Nexus i9250 (Android 4.0.1 ITL41D)
Samsung Galaxy S2
Samsung Galaxy S3 (GT-I9300 Android 4.3 Stock Rom)
Sony Xperia Go (St27i Android 4.1.2 Stock Rom build no 6.2.A.1.100 -- needed rndis_host module for me - User:LordVan )
HTC Desire HD (Android 2.3.6 Stock Rom build and Android 4.4.4 (unofficial CyanogenMod 11) -- needed rndis_host module for both Roms)
Huawei Honor 4x (unofficial CyanogenMod 11 / Android 4.4.4, works great) -- needed rndis_host module AleiPhoenix (talk) 13:57, 3 July 2015 (UTC)
Samsung Galaxy S4 Mini Duos (GT-I9192, unofficial CyanogenMod 12.1 / Android 5.1) -- needed rndis_host module

Testing

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

root #dmesg

usb 1-7: New USB device found, idVendor=18d1, idProduct=4e13
usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-7: Product: Nexus One
usb 1-7: Manufacturer: Google, Inc.
usb 1-7: SerialNumber: HT9CSP803294
usb 1-7: usb_probe_device
usb 1-7: configuration #1 chosen from 1 choice
usb 1-7: adding 1-7:1.0 (config #1, interface 0)
rndis_host 1-7:1.0: usb_probe_interface
rndis_host 1-7:1.0: usb_probe_interface - got id
rndis_host 1-7:1.0: usb0: register 'rndis_host' at usb-0000:00:1d.7-7, RNDIS device, ea:61:37:88:a2:e5
usb 1-7: adding 1-7:1.1 (config #1, interface 1)
drivers/usb/core/inode.c: creating file '004'
hub 1-0:1.0: state 7 ports 8 chg 0000 evt fe80
uhci_hcd 0000:00:1d.0: reserve dev 2 ep81-INT, period 8, phase 4, 93 us
usb 1-7: link qh32-0001/ffff88021aa4bc80 start 1 [1/0 us]
usb0: no IPv6 routers present

root #ifconfig -a

If you see usb0 (or whatever number you’ll get) you are all set.

Connecting

Since the mobile phone LAN changes its addresses, you need a DHCP client to configure the usbN device.

If you are on a laptop, you probably have a DHCP client. If not, emerge net-misc/dhcpcd.

root #emerge --ask net-misc/dhcpcd

Manually

Simply run dhcpcd after plug/mobile activation.

root #dhcpcd usb0

Permanent configuration

Edit your /etc/conf.d/net to have a permanent, automatic activation of the interface.

root #echo "config_usb0=\"dhcp\"" >> /etc/conf.d/net

Once plugged in and activated on the mobile phone side, the usb0 will be up and configured.

Checks

Run the usual checks to verify your connection.

1
2
3

root #ifconfig usb0
root #route
root #cat /etc/resolv.conf

Advanced network settings

The DHCP is very quick, but the default settings don’t give you as much freedom as you may want.

A possible scenario is that you are in a corporate, protected LAN context that doesn’t give you the Internet connection but where you need to stay connected to have access to some Intranet resource.
Or maybe you have a free but limited connection (a public wifi allowing http only, an evil firewall, etc.). Since mobile connections could be expensive, you could want to save your money up using the tethering only when needed.
Here is a handful of examples about the DHCP usage.

If you want to limit the information set by DHPC, you can fine-tune its behaviour.

E.g.:
root #dhcpcd --nogateway --nohook resolv.conf --nohook hostname usb0

This will let your default gateway, resolv.conf and hostname as they are, letting you provide extra info by hand.

E.g.:
root #route add -host my_sshd_remote_host_IP dev usb0

Finally, you can permanently configure your USB network interface.
E.g.

1
2
3
4
5
6
7
8
9
10
11

FILE /etc/conf.d/net

config_usb0="dhcp"
dhcpcd_usb0="--nogateway --nohook resolv.conf --nohook hostname"
# Special hosts
postup()
{
    if [[ "usb0" == ${IFACE} ]]; then
        route add -host my_sshd_remote_host_IP dev usb0
    fi
}

Generally, you can avoid every DHCP setting (see the man page) but gather them with

root #dhcpcd -U usb0

Then you can set what you want in the postup hook.

refer: Original link

ref: http://landley.net/writing/docs/cross-compiling.html

Host vs Target

A compiler is a program that turns source code into executable code. Like all programs, a compiler runs on a specific type of computer, and the new programs it outputs also run on a specific type of computer.[^1]

The computer the compiler runs on is called the host, and the computer the new programs run on is called the target. When the host and target are the same type of machine, the compiler is a native compiler. When the host and target are different, the compiler is a cross compiler.[^2]

Why cross-compile?

In theory, a PC user who wanted to build programs for some device could get the appropriate target hardware (or emulator), boot a Linux distro on that, and compile natively within that environment. While this is a valid approach (and possibly even a good idea when dealing with something like a Mac Mini), it has a few prominent downsides for things like a linksys router or iPod:

• Speed - Target platforms are usually much slower than hosts, by an order of magnitude or more. Most special-purpose embedded hardware is designed for low cost and low power consumption, not high performance. Modern emulators (like qemu) are actually faster than a lot of the real world hardware they emulate, by virtue of running on high-powered desktop hardware.[^3]

• Capability - Compiling is very resource-intensive. The target platform usually doesn’t have gigabytes of memory and hundreds of gigabytes of disk space the way a desktop does; it may not even have the resources to build “hello world”, let alone large and complicated packages.

• Availability - Bringing Linux up on a hardware platform it’s never run on before requires a cross-compiler. Even on long-established platforms like Arm or Mips, finding an up-to-date full-featured prebuilt native environment for a given target can be hard. If the platform in question isn’t normally used as a development workstation, there may not be a recent prebuilt distro readily available for it, and if there is it’s probably out of date. If you have to build your own distro for the target before you can build on the target, you’re back to cross-compiling anyway.

• Flexibility - A fully capable Linux distribution consists of hundreds of packages, but a cross-compile environment can depend on the host’s existing distro from most things. Cross compiling focuses on building the target packages to be deployed, not spending time getting build-only prerequisites working on the target system.

• Convenience - The user interface of headless boxes tends to be a bit crampled. Diagnosing build breaks is frustrating enough as it is. Installing from CD onto a machine that hasn’t got a CD-ROM drive is a pain. Rebooting back and forth between your test environment and your development environment gets old fast, and it’s nice to be able to recover from accidentally lobotomizing your test system.

Why is cross-compiling hard?

Portable native compiling is hard.

Most programs are developed on x86 hardware, where they are compiled natively. This means cross-compiling runs into two types of problems: problems with the programs themselves and problems with the build system.

The first type of problem affects all non-x86 targets, both for native and for cross-builds. Most programs make assumptions about the type of machine they run on, which must match the platform in question or the program won’t work. Common assumptions include:

• Word size - Copying a pointer into an int may lose data on a 64 bit platform, and determining the size of a malloc by multiplying by 4 instead of sizeof(long) isn’t good either. Subtle security flaws due to integer overflows are also possible, ala “if (x+y < size) memset(src+x,0,y);”, which results in a 4 gigabyte memset on 32-bit hardware when x=1000 and y=0xFFFFFFF0…

• Endianness - Different systems store binary data iternally in different ways, which means that block-reading int or float data from disk or the network may need translation. Type “man byteorder” for details.

• Alignment - Some platforms (such as arm) can only read or write ints from addresses that are an even multiple of 4 bytes, otherwise they segfault. Even the ones that can handle arbitrary alignments are slower dealing with unaligned data (they have to fetch twice to get both halves), so the compiler will often pad structures to align variables. Treating structures as a lump of data that can be sent to disk or across the network thus requires extra work to ensure a consistent representation.

• Default signedness - Whether the “char” data type defaults to signed or unsigned varies from platform to platform (and in some cases from compiler to compiler), which can cause some really surprising bugs. The easy workaround for this is to provide a compiler argument like “-funsigned-char” to force the default to a known value.

• NOMMU - If your target platform doesn’t have a memory management unit, several things need to change. You need vfork() instead of fork(), only certain types of mmap() work (shared or read only, but not copy on write), and the stack doesn’t grow dynamically.

Most packages aim to be portable when compiled natively, and will at least accept patches to fix any of the above problems (with the possible exception of NOMMU issues) submitted to the appropriate development mailing list.

And then there’s cross-compiling.

In addition to the problems of native compiling, cross-compiling has its own set of issues:

• Configuration issues - Packages with a separate configuration step (the “./configure” part of the standard configure/make/make install) often test for things like endianness or page size, to be portable when natively compiled. When cross-compiling, these values differ between the host system and the target system, so running tests on the host system gives the wrong answers. Configuration can also detect the presence of a package on the host and include support for it, when the target doesn’t have that package or has an incompatible version.

• HOSTCC vs TARGETCC - Many build processes require compiling things to run on the host system, such as the above configuration tests, or programs that generate code (such as a C program that creates a .h file which is then #included during the main build). Simply replacing the host compiler with a target compiler breaks packages that need to build things that run during the build itself. Such packages need access to both a host and a target compiler, and need to be taught when to use each one. [^4]

• Toolchain Leaks - An improperly configured cross-compile toolchain may leak bits of the host system into the compiled programs, resulting in failures that are usually easy to detect but which can be difficult to diagnose and correct. The toolchain may #include the wrong header files, or search the wrong library paths at link time. Shared libraries often depend on other shared libraries which can also sneak in unexpected link-time references to the host system.

• Libraries - Dynamically linked programs must access the appropriate shared libraries at compile time. Shared libraries to the target system need to be added to the cross-compile toolchain so programs can link against them.

• Testing - On native builds, the development system provides a convenient testing environment. When cross-compiling, confirming that “hello world” built successfully can require configuring (at least) a bootloader, kernel, root file system, and shared libraries.

[^1]: The most prominent difference between types of computers is what processor is executing the programs, but other differences include library ABIs (such as glibc vs uClibc), machines with configurable endianness (arm vs armeb), or different modes of machines that can run both 32 bit and 64 bit code (such as x86 on x86-64).

[^2]: When building compilers, there’s a third type called a “canadian cross”, which is a cross compiler that doesn’t run on your host system. A canadian cross builds a compiler that runs on one target platform and produces code for another target machine. Such a foreign compiler can be built by first creating a temporary cross compiler from the host to the first target, and then using that to build another cross-compiler for the second target. The first cross-compiler’s target becomes the host the new compiler runs on, and the second target is the platform the new compiler generates output for. This technique is often used to cross-compile a new native compiler for a target platform.

[^3]: Modern desktop systems are sufficiently fast that emulating a target and natively compiling under the emulator is actually a viable strategy. It’s significantly slower than cross compiling, requires finding or generating a native build environment for the target (often meaning you have to set up a cross-compiler anyway), and can be tripped up by differences between the emulator and the real hardware to deploy on. But it’s an option.

[^4]: This is why cross-compile toolchains tend to prefix the names of their utilities, ala “armv5l-linux-gcc”. If that was simply called “gcc” then the host and native compiler couldn’t be in the $PATH at the same time.

工程師最常說的一句話, by Mark

測試二號

This article introduce the device storage partitions. There are three topics: device compatibility, partition description and create steps.

1. Compatibility

1.1 Hardware Device

1. ICM/ICS-2010
2. ICM/ICS-2011

1.2 OS

1. Yocto 1.6.2 (U-boot 2014.04, Kernel 3.10.53)
2. Ubuntu 12.04 (U-boot 2014.04, Kernel 3.10.53)

2. Partition Description

The layout of the MMC/SD/TF card for device is shown below:

• [Partition type/index] is which defined in the MBR.
• [Name] is only meaningful in Android. You can ignore it when creating these partitions.
• [Start Offset] shows where partition is started, unit in MB.

3. Steps

3.1 Requirement

An SD/MMC card reader, like a USB card reader, is required. It will be used to transfer the boot loader and kernel images to initialize the partition table and copy the root file system. To simplify the instructions, it is assumed that a 8GB SD/MMC card is used.

To identify the device node assigned to the SD/MMC card, enter the command:

$ cat /proc/partitions
major minor  #blocks  name
   8     0   78124000 sda 
   8     1   75095811 sda1  
   8     2          1 sda2 
   8     5    3028221 sda5 
   8    32   43232323 sdb1 
   8    18    3905535 sdc1
1
2
3
4
5
6

In this example, the device node assigned is /dev/sdc (a block is 512B large).

### 3.2 Create Partition

To create a partition, at offset 16384 (in sectors of 512 bytes) enter the following command:


$ sudo fdisk /dev/sdb

u       [switch the unit to sectors instead of cylinders]
d       [repeat this until no partition is reported by the 'p' command ]
n       [create a new partition]
p       [create a primary partition]
1       [the first partition]
16384   [starting at offset sector #16384, i.e. 8MB, which leaves enough space for thekernel, the boot loader and its configuration data]
<enter>     [using the default value will create a partition that spans to the last sector of the medium]
w         [ this writes the partition table to the medium and fdisk exits]

The file system format ext3 or ext4 is a good option for removable media due to the built- in journaling. Run the following command to format the partition:

$ sudo mkfs.ext3 /dev/sdb1

Or

$ sudo mkfs.ext4 /dev/sdb1

More info: Reference

This article introduce the device storage partitions. There are three topics: device compatibility, partition description and create steps.

1. Compatibility

1.1 Hardware Device

1. ICM/ICS-2010
2. ICM/ICS-2011

1.2 OS

1. Yocto 1.6.2 (U-boot 2014.04, Kernel 3.10.53)
2. Ubuntu 12.04 (U-boot 2014.04, Kernel 3.10.53)

2. Partition Description

The layout of the MMC/SD/TF card for device is shown below:

• [Partition type/index] is which defined in the MBR.
• [Name] is only meaningful in Android. You can ignore it when creating these partitions.
• [Start Offset] shows where partition is started, unit in MB.

3. Steps

3.1 Requirement

An SD/MMC card reader, like a USB card reader, is required. It will be used to transfer the boot loader and kernel images to initialize the partition table and copy the root file system. To simplify the instructions, it is assumed that a 8GB SD/MMC card is used.

To identify the device node assigned to the SD/MMC card, enter the command:

$ cat /proc/partitions
major minor  #blocks  name
   8     0   78124000 sda
   8     1   75095811 sda1  
   8     2          1 sda2
   8     5    3028221 sda5
   8    32   43232323 sdb1
   8    18    3905535 sdc1
1
2
3
4
5
6

In this example, the device node assigned is /dev/sdc (a block is 512B large).

### 3.2 Create Partition

To create a partition, at offset 16384 (in sectors of 512 bytes) enter the following command:


$ sudo fdisk /dev/sdb

u       [switch the unit to sectors instead of cylinders]
d       [repeat this until no partition is reported by the 'p' command ]
n       [create a new partition]
p       [create a primary partition]
1       [the first partition]
16384   [starting at offset sector #16384, i.e. 8MB, which leaves enough space for thekernel, the boot loader and its configuration data]
<enter>     [using the default value will create a partition that spans to the last sector of the medium]
w         [ this writes the partition table to the medium and fdisk exits]

The file system format ext3 or ext4 is a good option for removable media due to the built- in journaling. Run the following command to format the partition:

$ sudo mkfs.ext3 /dev/sdb1

Or

$ sudo mkfs.ext4 /dev/sdb1

More info: Reference