SOHO Server

Small Office / Home Office (SOHO) Server

2021/10/29 06:18 · m


2021/10/29 06:18 · m

How to Flash the Firmware

What to do if you erased all your flash?

The methods are described in chinese manuals under the 'firmware update' or similar directories. The SN9866x series chip supports flashing u-boot and hw-settings directly from sd card. Note that 60x series doesn't support this feature. All you need is to prepare an sd card with the first partition formatted to FAT32, obtain FIRMWARE_660R_F.bin file from the build system and put it on the first partition of sd card. Hold the reset button of the device and power it on. You can see in the terminal window connected to the serial line that update is started. Alternatively, you can hold ESC key in your terminal while powering the device on. You should see the BROM's prompt: >>. Then type s.

There is a method to flash u-boot over a serial line using ymodem but I were not successful with it. See Notes on Ymodem

See Building a Self-Burninig Firmware Image for more information.

I had succesfully flashed FIRMWARE_660R_F.bin that comes with SN986_1.50_P2P_TUTK_043a_20160308_1000 sdk. The hw-settings of this firmware are exactly the same as in stock rom.

Vendor's Firmware Image Structure

Structure of the U-Boot Image

This is how U-Boot is stored in the packed fw file and in the flash:

<offset>  <size>   <desccription>
00000000  4B     - 32-bit unsigned, size of (u-boot + padding + crc16)
00000004  ~258K  - u-boot.bin, original image produced by u-boot make
000xxxxx  <16B   - padding, filled w/ 0xff, sizeof(u-boot.bin+padding)%16==0
000xxxyy  4B     - 32-bit unsigned, crc16/modbus of (u-boot.bin+padding)
2021/10/29 06:18 · m

iSC5 Camera PCB wiring

Table of Contents

  • Sensor Board and GPIO_MS1[6]
  • Powering the Speaker
  • Powering the WiFi Module

Sensor Board and GPIO_MS1[6]

In the stock firmware there is the following code in the '/etc/init.d/rcS' file:

#power on sensor
/bin/gpio_ms1 -n 6 -m 1 -v 1

'gpio_ms1' binary when compiled with '-DSN9866X' flag maps gpio_ms1[7]…gpio_ms1[3] on aud[4]…aud[0]. In other words for each call with '-n X' flag where X is a number from 3 to 7 it internally calls 'gpio_aud' binary with argument 'Y' where Y is X minus 3. So that the line above means that aud[3] is set to high.

aud[3] line of the SOC is going to pin24 on the camera board connector. The line from the pin goes to the seat for a resistor which is left unsoldered. There are may be other vias under the socket however but the fact that even without setting aud[3] high the sensor works well.

Powering the Speaker

The speaker is driven by the SGM4895 power amp. The shutdown controlling line “nSHDN” of the speaker is connected to aud[4] line of the SoC. So that you need to set aud[4] gpio to high in order to play sound.

Powering the WiFi Module

The 3V3 bus of the wifi module is sourced from the p-channel MOSFET WP3401 (sot23, mark WP1J). The gate of the transistor is pulled down by a resistor and connected to the line gpio[6] of the SoC. If you need to hard-reset the wifi module then you should kill all networking software, unload the driver and set gpio[6] to high for a few seconds.

2021/10/29 06:18

Notes on SD Card

The camera fails to work with some SD cards. I tried to use two identical micro SD cards by Transcend and in both cases U-Boot failed to properly load my kernel to the RAM. U-Boot complained that the CRC sum of uImage did not match in 90 percent of attempts. Well, there were a few successful tries actually but they were very rare.

Here is what a boot log looks like on a failed attempt:

U-Boot 2011.09 (Sep 21 2018 - 10:14:17)

DRAM:  64 MiB
MMC:   MMC: 0
In:    serial
Out:   serial
Err:   serial
GPIO[2] is high
Hit any key to stop autoboot:  0 
reading uImage

2986304 bytes read
reading initramfs.cpio.gz

533651 bytes read
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2986240 Bytes = 2.8 MiB
   Load Address: 00008000
   Entry Point:  00008040
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
loadkernel 0x00007FFC 0x1;bootm 0x00008000
Wrong Image Format for bootm command
ERROR: can't get kernel image!
firmware backup support fail....

The card that I tried to use was a 16GB microSDHC I, C10, U1 class card, Transcend TS16GUSD300S.

However an older 8GB Transcend card with only C6 capability worked perfectly. Also 16GB Kingston C10 cards work as well.

2021/10/29 06:18

Debugging Programs

Vendor SDK provides a 'gdb' and 'gdbserver' tools. See the last section in 'sn9866_series_linux_environment_user_guide_v1_00.pdf' documents for more information.

The version of 'gcc' provided by vendor SDK is '4.5.2'. This version supports an output of debug information in formats 'dwarf' up to 'dwarf-4' and 'stabs'.

The version of 'gdb' and 'gdbserver' is '6.8'. This version supports an output of debug information in formats 'dwarf' up to 'dwarf-2' and 'stabs'.

When debugging programs written in pure C you are free to choose any format supported by both compiler and debugger. In this case it enough just to add '-g' option to CFLAGS and LDFLAGS. By default it enables 'dwarf-2' format. In order to choose different format use instead '-gdwarf-4' or '-gstabs' for example.

Troubles arise when you want to debug a C++ programs that contain non-POD C++ classes or namespaces. To be a non-POD (POD stands for plain old data) C++ class should contains for example an explicit constructor. The issue is that DWARF-2 does not support C++ namespaces. Support for C++ namespaces was first added in DWARF-3 format. However, to compile program with '-gdwarf-3' does not solve the issue because vendor's 'gdb' does not support this format. The actual solution is to compile and link C++ programs with '-gstabs+' flag. '-gstabs+' enables 'stabs' format plus some GNU-specific extensions which are incompatible with others debuggers but may be helpful when dealing with gdb.


Suppose your program is called 'rtsp_server' and it should be executed with arguments '-W 640 -H 480 -Q 10 -b 4096 -a'. Suppose you have a local copy of your target's root filesystem in '~/sdk/rootfs' directory on the host machine and toolchan in '~/sdk/toolchain' directory. In order to debug program from the remote host machine you should start gdbserver on the target machine:

# gdbserver :2000 rtsp_server -W 640 -H 480 -Q 10 -b 4096 -a

run gdb on the host side and connect to the target:

$ export PATH="~/sdk/toolchain/bin:$PATH"
$ arm-linux-gdb --args rtsp_server -W 640 -H 480 -Q 10 -b 4096 -a
> set sysroot '~/sdk/rootfs'
> target remote
> breakpoint main.cc:main
> continue

One can automate previous steps by creating gdb init script file called '.gdbinit' in the current (working) directory on the host side:

$ cat > .gdbinit <<-EOF 
set sysroot '~/sdk/rootfs'
target remote
2021/10/29 06:18

How to Compile and Configure the Latest Busybox for SN986

Here is what I did to compile 1.29:

tar xf busybox-1.22.1.tar.bz2
tar xf busybox-1.29.1.tar.bz2
cd busybox-1.22.1/configs
cp ~/develop/xiaofang/sdk/SN986_1.60_QR_Scan_019a_20160606_0951/snx_sdk/filesystem/busybox-1.22.1/src/configs/sn9866x_defconfig .
export PATH="/home/student/develop/xiaofang/sdk/SN986_1.60_QR_Scan_019a_20160606_0951/snx_sdk/toolchain/crosstool-4.5.2/bin:$PATH"
make CROSS_COMPILE=arm-linux- sn9866x_defconfig
cd ../busybox-1.29.1/
cp ../busybox-1.22.1/.config .
make CROSS_COMPILE=arm-linux- oldconfig
make CROSS_COMPILE=arm-linux- menuconfig
make CROSS_COMPILE=arm-linux- -j5
diff -ru busybox-1.22.1 ~/develop/xiaofang/sdk/SN986_1.50_P2P_TUTK_043a_20160308_1000/snx_sdk/filesystem/busybox-1.22.1/src/ > diff_1.22.1_snx.txt
2021/10/29 06:18


This is a list of applications which are ready to be run on the camera. Basically these applications are known programs configured and compiled by someone for the Xiaofang camera.

2021/10/29 06:18

Notes on Ymodem

Minicom Ymodem Issue

Source: https://axixmiqui.wordpress.com/2008/05/16/minicom-ymodem-issue/

May 16, 2008
Andrew Hahn

This was a simple fix, but took a while to figure out because of less than
informative error messages. While trying to transfer a file (a Linux kernel)
using minicom and ymodem we got a protocol failed error when using one machine
(my laptop) and it worked on another. After checking versions of minicom,
serial adapter drivers, ymodem config, etc… we noticed that minicom is setup to
use /usr/bin/rb and /usr/bin/sb for ymodem comm. Turns out, they weren’t
installed! On Debian (*buntu) the lrzsz package is what is needed. A quick
apt-get install lrzsz and we were up and running.

Gotta love cryptic error messages!
2021/10/28 04:06 · m

Notes on uClibc

How to Get a uClibc Version

The following command prints the version numbers of uClibc library in use:

$ printf '#include <features.h>\n__UCLIBC_MAJOR__ __UCLIBC_MINOR__ __UCLIBC_SUBLEVEL__\n' | ./crosstool-4.5.2/bin/arm-linux-gcc -E - | tail -1
2021/10/28 04:06 · m

Building a Self-Burninig Firmware Image


2021/10/28 04:06 · m

Building a Custom Firmware for the SN986-based Wifi Camera

Table of Contents
  • Device
  • SDK
  • SD Card
  • Toolchain
  • U-Boot
  • Initramfs
  • Boot Process
  • Busybox
  • Kernel
  • Driver for RTL8188EU
  • LEDs
  • Self-Burning Firmware


  • Mijia Xiaofang iSC5 Smart Camera (but NOT '1S' version)
  • aka Wyze Cam v1
  • aka iSmartAlarm (…)


SDK is a software development kit provided by the vendor of processor. SDK for our chip contains patched bootloader, Linux kernel w/ drivers and userspace libraries and programs. I took source code for bootloader and kernel for my firmware from such SDK.

Strings that could be extracted from the camera's boot log and binaries show that the name (SDK version, branch, tag) of the stock firmware is: 'SN986_1.50_P2P_TUTK_050a_20160921_1712'

The latest file you can obtain from the internet which contains SDK with a similar branch is 'SN986_1.50_P2P_TUTK_043a_20160308_1000.tgz'

Google for it literally.

All SDKs for the SN986 series processors which are available on the internet are stripped. That means that they don't contain source code for vendor drivers, just binaries. Nevertheless they contain full patched source code for u-boot, kernel, busybox, multiple userspace programs, toolchain.


Actually you could find the source code for some drivers. From different SDKs and folders provided by the same persons who provide SDKs, I were lucky to find sources for the following modules:

  • gpio
  • video stack: isp2, isp3, sc2035 (but NOT sc2135)
  • gadget ucd
  • usb-wifi (rtl8188eu v4.3.24 by realtek)
  • gpio, pwm, uart, watchdog (extracted from 1.10 and 1.20 branches, it's NOT for Linux but FreeRTOS)

SD Card

Main article: Notes on an SD Card

In order to use ext4 filesystem with 2.6.25 kernel you need to disable few ext4 features:

tune2fs -O ^metadata_csum /dev/sdc2
tune2fs -O ^huge_file /dev/sdc2
tune2fs -O ^64bit /dev/sdc2

When running the commads above you might be asked to run

e2fsck -f /dev/sdc2


resize2fs -s /dev/sdc2

it's OK, just run it.


The toolchain used in the original SDK is the following set of binaries: 'snx_sdk/toolchain/crosstool-4.5.2/bin/arm-linux-*'

The key variables are: 'ARCH' needs to be set to 'arm', 'CROSS_COMPILE' to 'arm-linux-' and the 'PATH' variable needs to be prepended with the absolute path of 'toolchain/crosstool-4.5.2/bin'.

When building kernel, the variable 'AUTOCONF_DIR' needs to be set to the absolute path of 'buildscript/include' directory and passed along with the 'ARCH' and 'CROSS_COMPILE' variables to the kernel's make.

Boot Process

The following paragraph describes the boot stages of my temporary firmware which uses spi flash as boot device and SD card as a kernel and root primary storage.

  1. SoC ROM code
    • checks gpio2 state (fw update trigger)
    • initializes spi flash and mmc
    • reads hardware-settings (hws) from the first 4K block of spi flash
      • commands in hws specify load addresses, size and jump addresses
      • commands in hws initialize SDRAM and some other controllers
    • loads u-boot from flash to SDRAM
    • jumps to u-boot
  2. U-Boot
    • reinitializes controllers
    • loads uImage from mmc 0:1
    • loads initramfs.cpio.gz from mmc 0:1
    • extracts kernel from uImage
    • jumps to kernel
  3. Kernel
    • reinitializes controllers
    • extracts and mounts initramfs as '/'
    • executes '/init' as pid 1
  4. '/init' of initramfs
    • loads snx_sd SD card driver
    • populates '/dev'
    • mounts SD card second partition 'mmcblk0p2' as '/mnt/root'
    • switches root to '/mnt/root'
    • executes '/linuxrc' of the new root as pid 1
  5. '/linuxrc' on mmcblk0p2
    • mounts sysfs, proc, dev, run…
    • executes busybox's sysv init '/sbin/init' as pid 1
  6. Busybox's SysV Init '/sbin/init'
    • does system run state stuff (?)
    • reads inittab
    • executes '/etc/init.d/rcS'
  7. '/etc/init.d/rcS'
    • loads vendor kernel modules
    • executes '/etc/init.d/rc.local'
  8. '/etc/init.d/rc.local'
    • sets up hostname and network interfaces
    • calls wpa_supplicant, udhcpcd, dropbear
    • does other local user stuff

Boot ROM code & Hardware Settings

Main article: Hardware Settings Explained

Hardware settings are stored in the first erase block (4096 bytes) of the spi flash. Hardware settings is a sequence of bytes which represent commands to the SoC BROM interpreter and their arguments plus some header and footer.

The syntax of commands is described at the end of document 'sn9866_series_datasheet_standard_160930.pdf' (this is the name that I gave it in my BSP, the original one was 'SN98660+series-CG-SZZD-160930.pdf').

The registers with addresses 0xFFFFxxxx are not explained in vendor documents. Howewer one may find hints to the meaning of some of them in the source files in vendor sdk.




Main article: Initramfs


Main article: How to Compile and Configure the Latest Busybox for SN986

The latest busybox (busybox-1.29.1) compiled with SDK's toolchain runs without issues on the target. When it compiled as a dynamically linked binary ensure that 'ld-uClibc.so.0', 'libc.so.0' and 'libm.so.0' are present in the '/lib' directory.


Busybox'es switch_root does not move or unmount filesystems other than '/' unlike what a util-linux'es switch_root do. See extensive commentaries in the busybox'es switch_root source code about what it actually do. You may also want to read the discussion at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001>


Prior to compile kernel from SDK you should run 'make sn98660_402mhz_sf_defconfig' in the 'buildscript' directory. This will generate some config files under the 'buildsctipt/include' directory. These files will be used when compiling some vendor kernel code.

It also needs to install some build tools like perl modules. See SDK's documentation.

Once you have installed necessary perl modules the kernel should compile without any issues. One thing you need to do is to erase obsolete 'defined' keyword in the 'kernel/timeconst.pl' file. You can use my '0001_erase_defined_keyword.patch' for this purpose.


With the same config as for SDK branch 'P2P_TUTK_1.50', kernel from SDK branch '1.60' failed to load snx_nvram driver with a segfault/core dump error. The toolchain and config both are from 1.50 SDK. It needs to compare kernel source tree to resolve this.


The basic things need to be changed in the menuconfig are

  • enable all of the options for EXT4 filesystem
  • enable INITRAMFS
  • disable ETHERNET
  • enable EMBEDDED config and make sure that HOTPLUG is enabled
  • (opt) enable proc/config.gz
  • (?) switch platform from SN98600 to SN98660

If you do not use my config from bootstrap directory, ensure that my 'build.mk' or default Makefile substitutes actual cpu frequency after generating default config. Actual cpu frequency is taken by the 'kernel/linux-*/Makefile' from 'buildscript/include/config/snx_/config/snx_sdk.conf'.

It's necessary to set the variable AUTOCONF_DIR to the absolute path of the 'buildscript/include' directory and pass it to the kernel make command along with the ARCH and CROSS_COMPILE variables. Otherwise the kernel build will unable to find some generated headers.

Driver for RTL8188EU

The version string of the driver as reported by the stock firmware is 'RTL871X: rtl8188eu v4.3.24_16705.20160509'.

In the source code of the driver the version string is stored in the header file 'include/wrt_version.h'.

Source code with exactly the same version as a stock firmware has can be downloaded from the github repo (my access date: Jul 29'18): 'https://github.com/hi35xx/rtl8188eu'

Alternatively, the version from SDK 'rtl8188EUS_v4.3.15_13239_simpleconfig' works as well.

Before compiling the driver's source code make sure that necessary kernel options are enabled:


There is also the staging driver 'rtl8188eu' in the latest kernel source tree. Kernel options listed above are taken from its Kconfig.

You should patch the Makefile of the v4.3.24 driver in order to compile for SNX986 platform. You can refer to the SDK driver's Makefile or just apply my patch. The tip is to search for the references of 'CONFIG_PLATFORM_ARM_SONIX926' variable. Note that naming of variables in my patched makefile differ from that in makefile of vendor usb-wifi drivers. I use realtek's Makefile names directly (KVER, KSRC, MODDESTDIR), while vendor makefile set them from another variables (vKERNEL, KERNELDIR, INSTALLDIR).

The driver configuration is done in the file '<rtl8188eu src>/include/autoconf.h'. There is an option 'CONFIG_AUTOCFG_CP' in the Makefile which determines whether to use alternative configuration. If this option is set to 'y' then Makefile will look for 'autoconf_autoconf_rtl8188e_usb_linux.h' in the root of its source tree and copy it to 'include/autoconf.h'. There are several debug options in the end of 'autoconf.h' which you may want to change.

The driver is to be compiled as kernel module and some parts of the vendor kernel code are used when building. Because of that you should set or export AUTOCONF_DIR variable pointing to 'buildscript/include' directory along with other variables.

Once Makefile is patched the whole command set for building .ko file is the following (if you are building the driver from SDK, you should name the variable KERNELDIR instead of KSRC):

export PATH=/home/student/develop/xiaofang/sdk/SN986_1.50_P2P_TUTK_043a_20160308_1000/snx_sdk/toolchain/crosstool-4.5.2/bin:$PATH
export AUTOCONF_DIR=/home/student/develop/xiaofang/sdk/SN986_1.50_P2P_TUTK_043a_20160308_1000/snx_sdk/buildscript/include/
make CROSS_COMPILE=arm-linux- KSRC=/home/student/develop/xiaofang/sdk/SN986_1.50_P2P_TUTK_043a_20160308_1000/snx_sdk/kernel/linux- -j5

Note that driver should be recompiled every time the kernel recompiled with different (networking) options. Otherwise segfaults and core dumps may appear.

After me had succesfully installed driver on the target and started ssh connection I noticed that ssh shell is a little bit laggy. Then I tested a ping response time and it was about stable 2ms when ping from target to the router and a regular spikes from 2ms up to 100-200ms on every 2nd packet when ping from router to the target (I have a console access to the router). I had recompiled the driver with debug printing enabled and saw that the driver constantly switching power management mode from 0 to 2 and backward. The driver attempts to go to sleep but every new ping packet woke it up again. So I completely disabled power management by adding a driver option to the driver loading call:

modprobe 8188eu rtw_power_mgnt=0

Note that for some unknown reason the driver completely ignores any changes made to files in the '/sys/module/8188eu/parameters' directory. So actually those exposed module parameters are only for information purposes at the moment. I also disabled the power management on my laptop (the ping was about stable 60ms from the router to laptop and ~2ms in other direction) so that now I have a total ping of ~3ms between the laptop and the target.


There are two LEDs connected to the gpio controller. One is orange and other is blue. The orange one is connected to gpio3, the blue one to gpio4. They are connected such way that during a reset when all gpios are set to floating state the orange led is switched on while the blue one is off. That means that the orange led's source is pulled up and it's enough to set direction of the gpio3 to 'out' to switch it off (when gpio ditection is set to 'out' the default voltage level is 0). Otherwise, the blue led's sink is pulled up and it's enough to set gpio4's direction to output to switch it on.

Self-Burning Firmware

2021/10/28 04:06 · m

Notes on a JFFS2


A whole partition should be erased before an jffs2 image is written to it. See https://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/p/587759/2160573

Normally clean markers should be written after erasing. When we erase from a bootloader or a bare-metal flasher which doesn't have an ability to write clean markers we could just leave partition empty. In this case the kernel jffs2 driver will write markers for us. See http://www.linux-mtd.infradead.org/faq/jffs2.html


A minimum erase block size that mkfs.jffs2 supports without patching is 8KiB. The sector erase size of SPI flash that is reported by MTD driver as an erase size is 4KiB.

See https://patchwork.ozlabs.org/patch/131822/ and this thread http://lists.infradead.org/pipermail/linux-mtd/2011-June/036498.html

Workaround for an 8K erase size limit

In the stock firmware the erase size of jffs2 that drives /etc partition is 4K and it seems to work.

On the device side

It can be achieved by first erasing the whole partition with the following call

flash_eraseall -j /dev/mtd6

and then by mounting an empty partition:

mount -t jffs2 /dev/mtdblock6 /etc

It makes a clean jffs2 with an erase block of 4K mounted over an /etc directory.

On the host side

In order to make an image file of jffs2 on the host machine one should patch the mkfs.jffs2 program. Clone the git repository of mtd user-space tools and make it

git clone git://git.infradead.org/mtd-utils.git
cd mtd-utils
make -j5


vim jffsX-utils/mkfs.jffs2.c

and comment out the following lines

/* If it's less than 8KiB, they're not allowed */
if (erase_block_size < 0x2000) {
    fprintf(stderr, "Erase size 0x%x too small. Increasing to 8KiB minimum\n",
    erase_block_size = 0x2000;

Creating a JFFS2 Partition Image

So that after patching a mkfs.jffs2 tool the command to make a jffs2 image is

../toolchain/mtd-utils/mkfs.jffs2 --little-endian --pagesize=0x1000 --eraseblock=0x1000 --pad --root=filesystem/etc --output=etc.jffs2
2021/10/28 04:06 · m


Using uInitramfs

In order to use uInitramfs (an initramfs with an U-Boot header) you should add the line


to the U-Boot source file u-boot/src/include/configs/sn9866x.h and recompile U-Boot.

Then tell U-boot to load the uInitramfs file and to pass it as an ATAG enrty to the kernel:

  fatload mmc 0:1 0x01000000 uImage
  fatload mmc 0:1 0x01A00000 uInitramfs
  bootm 0x01000000 0x01A00000

Using initramfs.cpio.gz

Or, alternatively, you could use initramfs.cpio.gz without an U-Boot wrapper and pass a boot argument initrd=<address_hex>,<size_in_bytes_decimal> to the kernel cmdline:


and add a command for loading initramfs image to the u-boot bootcmd:

fatload mmc 0:1 0x01A00000 initramfs.cpio.gz

In both cases the 'root=' kernel cmdline argument is not used by the kernel but you could use it by yourself in the /init and /linuxrc scripts in order to extract a name of appropriate flash partition.

See https://www.kernel.org/doc/html/latest/admin-guide/initrd.html
and https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
for more information.

2021/10/28 04:06 · m

Hardware Settings Explained

This document contains explanation of some bytes that are stored in the first 4K block of spi flash boot device.

How to Rewrite a Single Byte/Number in a Binary File

printf '\x00\x00\x00\x00' | dd conv=notrunc bs=1 of=hws.bin seek=80

HWS Listing

The listing below is an output of the following commands:

# dd if=/dev/mtdblock0 of=hws bs=4K count=1
# hexdump -ve '"%08_ax    " 1/4 "%08x" "\n"' hws

My comments are prepended with '#' sign.


# address   # data

# size of (commands+padding+crc), 32-bit unsigned integer
00000000    00000600

# this is an address(?) that one can also find in the file
# 'toolchain/image-tool/hw_setting.main.txt.d'
# However in that file it's prefixed with tag 'b' (branch or bypass?)
# but here it is just left alone
# see also an output of sysparser.pl:
# ``
# muti_bypass_mode_val = ffff
# muti_bypass_addr_val = 8000400
# ``
# image-tool reads the text file 'hw_setting.main.txt.d' and translates
# it to the binary file 'hw_setting.main.d'.
00000004    0000ffff
00000008    08000400

# These are 4 offsets of multi-hws parts (me do not knows what the purpose
# of _multi_ hws)
# see sysparser.pl, function fun_uboot
# They are offsets for multi_f00, multi_f01, multi_f02, multi_end data from
# the beginning of the image
# 0x5C4 = 1476 = 1456 (size of multi_main) - 8 bytes (strip bypass) + 28 bytes
# where 28 bytes = 8 bytes (put back bypass) + 4 bytes (size field at the
#     beginning of image) + 4x4 bytes (these addresses: f00, f01, f02, end)
# f00, f01, f02 are actually empty in this build
# but the 'end' section contains one write and one poll instructions,
# see 'hw_setting.image.end.d'
0000000c    000005c4
00000010    000005c4
00000014    000005c4
00000018    000005c4

# see explanation of command codes in
# 'sn9866_series_datasheet_standard_160930.pdf' on the last pages
# see explanation of some registers in
# 'sn9866_series_datasheet_with_registers_v1_04.pdf'

# This is a block of registers located in ITCM memory.
# See Documentation/arm/tcm.txt for the explanation of what is ITCM.

# I do not know anything about the following two registers
0000001c    00000077 # cmd: write
00000020    ffff6094 # arg: register
00000024    00000000 # arg: value

00000028    00000077
0000002c    ffff609c
00000030    00000000

# jmp address
# in RAM (VIRTUAL) memory
# see 'toolchain/image-tool/sysparser.pl:579'
00000034    00000077
00000038    ffff6090
0000003c    01d00000

# load address
# in PHYSICAL memory
# see 'bootloader/u-boot-2011-09/src/common/cmd_update.c'
# see 'toolchain/image-tool/sysparser.pl:579'
# Note that the jump address is just a load address plus 4 (bytes)
# (we need to skip size field in the u-boot image)
00000040    00000077
00000044    ffff601c
00000048    11cffffc

# u-boot address
0000004c    00000077
00000050    ffff60f8
00000054    00003000

# u-boot size
# this is a total size of the u-boot partition on SERIAL FLASH
00000058    00000077
0000005c    ffff6020
00000060    0007b000

# **Documented** registers:
00000064    00000077
00000068    98100008
0000006c    00000001
00000070    00000077
00000074    98100000
00000078    00000001
0000007c    00000077
00000080    90900038
00000084    00000006
00000088    00000077
0000008c    90900034
00000090    00000006
00000094    00000077
00000098    90600000
0000009c    8b000500
000000a0    00000077
000000a4    98000000
000000a8    ece180a0
000000ac    00000077
000000b0    98000004
000000b4    80840222
000000b8    00000077
000000bc    9800001c
000000c0    80000014
000000c4    0000006e
000000c8    00100000
000000cc    00000077
000000d0    90300000
000000d4    00000400
000000d8    0000007a
000000dc    90300004
000000e0    00000001
000000e4    00000077
000000e8    90300008
000000ec    020139c2
000000f0    00000077
000000f4    9030000c
000000f8    00c800a1
000000fc    00000077
00000100    90300010
00000104    00040a00
00000108    00000077
0000010c    90300014
00000110    18050202
00000114    00000077
00000118    90300018
0000011c    13060413
00000120    00000077
00000124    9030001c
00000128    00050204
0000012c    00000077
00000130    90300020
00000134    03036dd0
00000138    00000077
0000013c    90300024
00000140    00070600
00000144    00000077
00000148    90300028
0000014c    020d0101
00000150    00000077
00000154    9030002c
00000158    00000006
0000015c    00000077
00000160    90300030
00000164    00002b01
00000168    00000077
0000016c    90300034
00000170    00000c39
00000174    00000077
00000178    90300038
0000017c    00020002
00000180    00000077
00000184    9030003c
00000188    00c80008
0000018c    00000077
00000190    90300040
00000194    0000002f
00000198    00000077
0000019c    90300044
000001a0    03000001
000001a4    00000077
000001a8    90300048
000001ac    00000003
000001b0    0000007a
000001b4    9030004c
000001b8    00000004
000001bc    00000077
000001c0    9030005c
000001c4    000c5200
000001c8    00000077
000001cc    90300060
000001d0    00000002
000001d4    0000007a
000001d8    90300064
000001dc    00000001
000001e0    00000077
000001e4    90300068
000001e8    01000000
000001ec    00000077
000001f0    9030006c
000001f4    00000001
000001f8    0000007a
000001fc    90300070
00000200    00000002
00000204    00000077
00000208    90300078
0000020c    0a010101
00000210    00000077
00000214    9030007c
00000218    0101ffff
0000021c    00000077
00000220    90300080
00000224    01010101
00000228    00000077
0000022c    90300084
00000230    00010301
00000234    00000077
00000238    90300088
0000023c    00000100
00000240    00000077
00000244    9030008c
00000248    00010000
0000024c    0000007a
00000250    90300090
00000254    0000000a
00000258    00000077
0000025c    903000b8
00000260    03000000
00000264    00000077
00000268    903000bc
0000026c    00000003
00000270    00000077
00000274    903000c0
00000278    00000200
0000027c    0000007a
00000280    903000c4
00000284    00000001
00000288    00000077
0000028c    903000c8
00000290    0f0f0000
00000294    00000077
00000298    903000cc
0000029c    0f0f0f0f
000002a0    00000077
000002a4    903000d0
000002a8    0f0f0f0f
000002ac    00000077
000002b0    903000d4
000002b4    0f0f0f0f
000002b8    00000077
000002bc    903000d8
000002c0    03000303
000002c4    00000077
000002c8    903000dc
000002cc    03030003
000002d0    00000077
000002d4    903000e0
000002d8    00030300
000002dc    00000077
000002e0    903000e4
000002e4    03000303
000002e8    00000077
000002ec    903000e8
000002f0    03030003
000002f4    00000077
000002f8    903000ec
000002fc    00030300
00000300    00000077
00000304    903000f0
00000308    03000303
0000030c    00000077
00000310    903000f4
00000314    03030003
00000318    00000077
0000031c    903000f8
00000320    010f0300
00000324    00000077
00000328    903000fc
0000032c    00010f00
00000330    00000077
00000334    90300100
00000338    0f00010f
0000033c    00000077
00000340    90300104
00000344    010f0001
00000348    00000077
0000034c    90300108
00000350    00010f00
00000354    00000077
00000358    9030010c
0000035c    0f00010f
00000360    00000077
00000364    90300110
00000368    010f0001
0000036c    00000077
00000370    90300114
00000374    00010f00
00000378    00000077
0000037c    90300118
00000380    0000010f
00000384    0000007a
00000388    9030011c
0000038c    00000001
00000390    00000077
00000394    90300120
00000398    00000700
0000039c    00000077
000003a0    90300124
000003a4    00187200
000003a8    00000077
000003ac    90300128
000003b0    02000200
000003b4    00000077
000003b8    9030012c
000003bc    02000200
000003c0    00000077
000003c4    90300130
000003c8    00001872
000003cc    00000077
000003d0    90300134
000003d4    00007a3a
000003d8    00000077
000003dc    90300138
000003e0    01020405
000003e4    00000077
000003e8    9030013c
000003ec    0f0f0103
000003f0    00000077
000003f4    90300140
000003f8    03030f0f
000003fc    00000077
00000400    90300144
00000404    00030300
00000408    00000077
0000040c    90300148
00000410    0f00010f
00000414    00000077
00000418    9030014c
0000041c    00000001
00000420    0000007a
00000424    90300150
00000428    00000010
0000042c    00000077
00000430    90300200
00000434    04120412
00000438    00000077
0000043c    90300204
00000440    04140414
00000444    00000077
00000448    90300208
0000044c    60010060
00000450    00000077
00000454    9030020c
00000458    00000044
0000045c    00000077
00000460    90300210
00000464    00750024
00000468    00000077
0000046c    90300214
00000470    40284028
00000474    0000007a
00000478    90300218
0000047c    0000000a
00000480    00000077
00000484    90300240
00000488    04120412
0000048c    00000077
00000490    90300244
00000494    04140414
00000498    00000077
0000049c    90300248
000004a0    60010060
000004a4    00000077
000004a8    9030024c
000004ac    00000044
000004b0    00000077
000004b4    90300250
000004b8    00750024
000004bc    00000077
000004c0    90300254
000004c4    40284028
000004c8    0000007a
000004cc    90300258
000004d0    0000000a
000004d4    00000077
000004d8    90300280
000004dc    04120412
000004e0    00000077
000004e4    90300284
000004e8    04140414
000004ec    00000077
000004f0    90300288
000004f4    60010060
000004f8    00000077
000004fc    9030028c
00000500    00000044
00000504    00000077
00000508    90300290
0000050c    00750024
00000510    00000077
00000514    90300294
00000518    40284028
0000051c    0000007a
00000520    90300298
00000524    0000000a
00000528    00000077
0000052c    903002c0
00000530    04120412
00000534    00000077
00000538    903002c4
0000053c    04140414
00000540    00000077
00000544    903002c8
00000548    60010060
0000054c    00000077
00000550    903002cc
00000554    00000044
00000558    00000077
0000055c    903002d0
00000560    00750024
00000564    00000077
00000568    903002d4
0000056c    40284028
00000570    0000007a
00000574    903002d8
00000578    0000000a
0000057c    00000077
00000580    90300300
00000584    00004005
00000588    0000007a
0000058c    90300304
00000590    00000001
00000594    00000077
00000598    90300308
0000059c    00020002
000005a0    00000077
000005a4    9030030c
000005a8    00020002
000005ac    00000077
000005b0    90300310
000005b4    00020002
000005b8    0000007a
000005bc    90300314
000005c0    00000003
000005c4    00000077
000005c8    90300000
000005cc    00000401
000005d0    00000070
000005d4    90300090
000005d8    00000008
000005dc    00000008
000005e0    00100000

# padding:
000005e4    ffffffff
000005e8    ffffffff
000005ec    ffffffff
000005f0    ffffffff
000005f4    ffffffff
000005f8    ffffffff
000005fc    ffffffff

# crc16/modbus of (settings+padding)
# (!) the size field at the beginnig is not included
00000600    00005de1

# empty space - erased bytes
# to the end of hws 4K block
00000604    ffffffff
00000ffc    ffffffff
2021/10/28 04:06 · m

Creating a cramfs File System


I haven't had any issues when creating and flashing a cramfs image according to description in the links above.

mkfs.cramfs -b 4096 -N little filesystem/rootfs rootfs.cramfs
2021/10/28 04:06 · m

What is Memex?

Memex is the name of the hypothetical electromechanical device that Vannevar Bush described in his 1945 article “As We May Think”. Bush envisioned the memex as a device in which individuals would compress and store all of their books, records, and communications, “mechanized so that it may be consulted with exceeding speed and flexibility”. The individual was supposed to use the memex as an automatic personal filing system, making the memex “an enlarged intimate supplement to his memory”.

The Garden and the Stream: A Technopastoral by Mike Caulfield.

2021/10/16 03:08 · m
index.txt · Last modified: 2021/11/09 09:53 by m