https://en.m.wikipedia.org/wiki/Kibibyte

Code/analyzeLoxoneExtensionUpdates.py

@@ -161,8 +161,6 @@ def stm32_crc32(bytes_arr):
   return crc
 
 def analyzeUpdatefile(filename):
-#  if filename != '10000924_RoomsensorTree.upd':
-#    return
   f = open(filename, "rb")
   try:
       buffer = f.read()

LoxoneLinkHardware.md

@@ -11,13 +11,13 @@ I will talk about four different device types in this document:
 
 There are four known CPUs used in Loxone Link devices. They are technically very similar, but because TI no longer recommends their Stellaris CPUs for new designs, Loxone switched to the ST32 architecture for newer designs. The only exception is the Miniserver, which uses an Atmel ARM CPU.
 
-They all support reprogramming of their flash, which allows easy software updates without additional hardware. All extensions have a 2kb-8kb boot loader. The boot loader launches the code and also validates and installs a software update, if available.
+They all support reprogramming of their flash, which allows easy software updates without additional hardware. All extensions have a 2KiB-8KiB boot loader. The boot loader launches the code and also validates and installs a software update, if available.
 
 - Atmel AT91SAM9G20 from Microchip
-This one is only used by the Miniserver. It is a 400MHz ARM926 with 32kb internal SRAM and 64kb internal ROM. The server has two SD RAM chips (H57V2562GTR from SK Hynix) as additional memory with 256MBit each adding another 64MB of memory. The actual software is on an SD card, it is therefore not limited to the internal FLASH of the chip. It is loaded into the SD RAM by the boot loader. The serial number of the Miniserver is its Ethernet MAC address. The CPUs costs 7-8 €.
+This one is only used by the Miniserver. It is a 400MHz ARM926 with 32KiB internal SRAM and 64KiB internal ROM. The server has two SD RAM chips (H57V2562GTR from SK Hynix) as additional memory with 256MBit each adding another 64MiB of memory. The actual software is on an SD card, it is therefore not limited to the internal FLASH of the chip. It is loaded into the SD RAM by the boot loader. The serial number of the Miniserver is its Ethernet MAC address. The CPUs costs 7-8 €.
 
 - Stellaris (LM3S2678) from TI
-This is a 32-bit ARM Cortex M3 CPU with 128kb Flash and 32kb SRAM. It has a built-in CAN bus controller. While it can be clocked up to 50MHz, it seems to be only clocked at 8MHz. The CPUs costs around 6 €.
+This is a 32-bit ARM Cortex M3 CPU with 128KiB Flash and 32KiB SRAM. It has a built-in CAN bus controller. While it can be clocked up to 50MHz, it seems to be only clocked at 8MHz. The CPUs costs around 6 €.
 
     Examples are:
 
@@ -31,21 +31,21 @@ This is a 32-bit ARM Cortex M3 CPU with 128kb Flash and 32kb SRAM. It has a buil
     - Fröling Extension
     - DMX Extension
     - 1-Wire Extension
-    - IR Extension (not sure about this one, it clearly has a smaller boot loader - only 4kb, instead of 8kb)
+    - IR Extension (not sure about this one, it clearly has a smaller boot loader - only 4KiB, instead of 8KiB)
 
     The memory layout is as follows:
-    - `0x00000000-0x00001FFF` : FLASH 8kb boot loader
-    - `0x00002000-0x0000FFFF` : FLASH 56kb firmware area (contained in the `*.upd` files)
+    - `0x00000000-0x00001FFF` : FLASH 8KiB boot loader
+    - `0x00002000-0x0000FFFF` : FLASH 56KiB firmware area (contained in the `*.upd` files)
     - `0x00010000-0x00011FFF` : FLASH configuration variables
     - `0x00012000-0x0003FFFF` : FLASH firmware update area
     - `0x01000000-0x01002BFF` : TI Stellaris Factory ROM
-    - `0x20000000-0x20007FFF` : 32kb SRAM
+    - `0x20000000-0x20007FFF` : 32KiB SRAM
     - `0x40000000-0x43FFFFFF` : Peripherals
     - `0xE0000000-0xE0040FFF` : ARM special area
 
 
 - STM32F3 (STM32F302CCT6) from ST
-This is a 32-bit ARM Cortex M4 CPU with 256kb Flash and 40kb SRAM. It also has a built-in CAN bus controller, which means an external MCP2515 is not required. While it can be clocked up to 72MHz, it is also only clocked at 8MHz (devices, DI Extension, AI Extension, AO Extension) or 64Mhz (the Tree Extension). The CPUs costs less than 2.5 €. The integrated CAN bus controller saves another 1.5 € (MCP2515 price), resulting in significant cost savings by using the STM32. I would guess that any of the small extensions cost less than 10 € in material.
+This is a 32-bit ARM Cortex M4 CPU with 256KiB Flash and 40KiB SRAM. It also has a built-in CAN bus controller, which means an external MCP2515 is not required. While it can be clocked up to 72MHz, it is also only clocked at 8MHz (devices, DI Extension, AI Extension, AO Extension) or 64Mhz (the Tree Extension). The CPUs costs less than 2.5 €. The integrated CAN bus controller saves another 1.5 € (MCP2515 price), resulting in significant cost savings by using the STM32. I would guess that any of the small extensions cost less than 10 € in material.
 
     Examples are:
 
@@ -59,20 +59,20 @@ This is a 32-bit ARM Cortex M4 CPU with 256kb Flash and 40kb SRAM. It also has a
     - All Tree devices
 
     The memory layout is as follows:
-    - `0x08000000-0x080007FF` : FLASH 2kb boot loader (contains the serial number and hardware type)
-    - `0x08000800-0x0801D7FF` : FLASH 116kb firmware area (contained in the `*.upd` files)
+    - `0x08000000-0x080007FF` : FLASH 2KiB boot loader (contains the serial number and hardware type)
+    - `0x08000800-0x0801D7FF` : FLASH 116KiB firmware area (contained in the `*.upd` files)
     - `0x0801D800-0x0801DFFF` : FLASH old location of configuration variables? Now unused.
     - `0x0801E000-0x0803AFFF` : FLASH firmware update area
     - `0x0803B000-0x0803B7FF` : FLASH configuration variables (page 1)
     - `0x0803B800-0x0803BFFF` : FLASH configuration variables (page 2)
     - `0x0803C000-0x0803FFFF` : FLASH unused
     - `0x1FFFF800-0x1FFFD7FF` : Option bytes and System memory
-    - `0x20000000-0x20009FFF` : 40kb SRAM
+    - `0x20000000-0x20009FFF` : 40KiB SRAM
     - `0x40000000-0x500007FF` : Peripherals
     - `0xE0000000-0xFFFFFFFF` : ARM special area
 
 - ZWIR4502 from ZMDI/IDT
-The module is a secure low-power wireless IPv6 communication module supporting the 868/915 MHz frequency bands. It is based on the STM32 (specifically the STM32F103RC) and is a 32-bit ARM Cortex M3 CPU with 256kb Flash and 48kb SRAM. They are clocked at 8Mhz. <https://www.idt.com/products/interface-connectivity/ipv6-modules/zwir4512-secure-low-power-wireless-ipv6-module> It costs between 15-20 €, depending on the number of units.
+The module is a secure low-power wireless IPv6 communication module supporting the 868/915 MHz frequency bands. It is based on the STM32 (specifically the STM32F103RC) and is a 32-bit ARM Cortex M3 CPU with 256KiB Flash and 48KiB SRAM. They are clocked at 8Mhz. <https://www.idt.com/products/interface-connectivity/ipv6-modules/zwir4512-secure-low-power-wireless-ipv6-module> It costs between 15-20 €, depending on the number of units.
 
     Examples are:
 
@@ -81,15 +81,15 @@ The module is a secure low-power wireless IPv6 communication module supporting t
     - All Air devices
 
     The memory layout is as follows:
-    - `0x08000000-0x08000FFF` : FLASH boot loader (4kb)
-    - `0x08001000-0x0801DFFF` : FLASH 116kb firmware area (contained in the `*.upd` files)
+    - `0x08000000-0x08000FFF` : FLASH boot loader (4KiB)
+    - `0x08001000-0x0801DFFF` : FLASH 116KiB firmware area (contained in the `*.upd` files)
     - `0x0801E000-0x0803AFFF` : FLASH firmware update area
     - `0x0803B000-0x0803B7FF` : FLASH configuration variables (page 1)
     - `0x0803B800-0x0803BFFF` : FLASH configuration variables (page 2)
     - `0x0803C000-0x0803F7FF` : FLASH unused
     - `0x0803F800-0x0803FFFF` : FLASH factory configuration
     - `0x1FFFF800-0x1FFFD7FF` : Option bytes and System memory
-    - `0x20000000-0x2000BFFF` : 48kb SRAM
+    - `0x20000000-0x2000BFFF` : 48KiB SRAM
     - `0x40000000-0x500007FF` : Peripherals
     - `0xE0000000-0xFFFFFFFF` : ARM special area
 

LoxoneMiniserverGoHardware.md

@@ -4,7 +4,7 @@ The Loxone Miniserver Go is build around the same hardware, as the regular Minis
 
 - [Atmel SAM9G20 ARM CPU][1]
 - serial interface Flash memory ([AT25SF041][1b] from Adesto Technologies)
-- Two [256MB SDRAM][3] chips, providing 64MB of RAM to the Miniserver
+- Two [256MBit SDRAM][3] chips, providing 64MiB of RAM to the Miniserver
 - [4-megabit FLASH memory][2]
 - [Ethernet][4]
 - [Real-Time Clock][5]
@@ -16,12 +16,12 @@ Details about them can be found in my description of the Loxone Miniserver hardw
 The power supply is using a Micro-USB connector, generating the 3.3V needed for the board.
 
 Missing are most of the inputs and outputs:
+
 - no KNX port
-- no digital ins
+- no Digital In
 - no Relays / Digital Out
 - no Analog In
 - no Analog Out
-- no Digital In
 
 ## Air Base Extension in Miniserver Go
 

LoxoneMiniserverHardware.md

@@ -2,7 +2,7 @@
 
 I'd like to explain some technical details of the Loxone Miniserver and the Loxone Miniserver Go. The Miniserver (as well as all extensions) are ARM based, just like all modern mobile phones. It is clocked at just 8MHz.
 
-The Miniserver is ARM based. The CPU is booting from a 512kb flash memory. This code then loads the actual operating system from the SD Card into the additional 64MB of memory and executes it from there.
+The Miniserver is ARM based. The CPU is booting from a 512KiB flash memory. This code then loads the actual operating system from the SD Card into the additional 64MiB of memory and executes it from there.
 
 ## Hardware id
 
@@ -12,19 +12,19 @@ There are several different versions of Miniserver hardware:
 - ` 60000` - KNX and Ethernet changes with different reset support
 - ` 80000` - unknown changes
 - ` a0000` - some SD card change, new Ethernet chip, [KSZ8081RNB][4b]
-- ` c0000` - 128MB of SRAM (twice the amount of older versions)
+- ` c0000` - 128MiB of SRAM (twice the amount of older versions)
 - `100000` - Miniserver Go (based on the `a0000` Miniserver)
 
 
 ## CPU, Flash Memory, SRAM
 
-The CPU is an Atmel [AT91SAM9G20][1] from Microchip. It is a 3,3V 400MHz ARM926 with 32kb internal SRAM and 64kb internal ROM. It is paired with a serial interface Flash memory ([AT25DF041A][2] from Adesto Technologies), which is updatable by Loxone – it is one of two chips mounted on the back of the board. This flash memory also contains non-volatile memory used by the Miniserver, like encryption keys, which are not stored on the SD card. The other important chips are two SD RAM chips ([H57V2562GTR][3] from SK Hynix) as additional memory with 256MBit each adding another 64MB of memory.
+The CPU is an Atmel [AT91SAM9G20][1] from Microchip. It is a 3,3V 400MHz ARM926 with 32KiB internal SRAM and 64KiB internal ROM. It is paired with a serial interface Flash memory ([AT25DF041A][2] from Adesto Technologies), which is updatable by Loxone – it is one of two chips mounted on the back of the board. This flash memory also contains non-volatile memory used by the Miniserver, like encryption keys, which are not stored on the SD card. The other important chips are two SD RAM chips ([H57V2562GTR][3] from SK Hynix) as additional memory with 256MBit each adding another 64MiB of memory.
 
 ## Function of the AT25 FLASH memory
 
 The FLASH memory contains the boot firmware for the CPU, which reads the Miniserver firmware from the MicroSD card into the RAM and launches it.
 
-And while it is 512kb large it only uses about 12kb of its capacity. 10.25kb are reserved for the boot loader, followed by 256 bytes for an XML file with the hardware serial numbers and a 1.5kb area with the private encryption key.
+And while it is 512KiB large it only uses about 12KiB of its capacity. 10.25KiB are reserved for the boot loader, followed by 256 bytes for an XML file with the hardware serial numbers and a 1.5KiB area with the private encryption key.
 
 The XML contains the SSDP `modelNumber` as the `Type`; the UUID, also used for SSDP; the MAC or serial number of the Miniserver and the production date.
 

LoxoneSDCardFormat.md

@@ -40,7 +40,7 @@ The wrapping file system on the SD card is ignored by the Miniserver, it only lo
 | -----: | :---------- |
 | 0x1CC  | base sector pointing to the begining of the `LOXONE_SD` file. |
 | 0x1D0  | number of reserved sectors, they are ignored, typically a value like 5. |
-| 0x1D4  | number of sectors reserved for the firmware image. Typically `0x10005` (ca. 64MB), which feels like a bug, because the additional 5 is not needed and already part of the reserved sectors, but it also doesn't harm. |
+| 0x1D4  | number of sectors reserved for the firmware image. Typically `0x10005` (ca. 64MiB), which feels like a bug, because the additional 5 is not needed and already part of the reserved sectors, but it also doesn't harm. |
 | 0x1D8  | offset behind the filesystem relative to the filesystem start. This value *minus* the one in `0x1D4` is the size of the filesystem in sectors. |
 | 0x1DC  | unknown, the value seems to be `0x20`. Might be the number of sectors per cluster, but this is hardcoded in the filesystem and this value is not used. |
 | 0x1E0  | mode for the transaction cache, typically 0. More to that below at the transaction record. |
@@ -54,12 +54,12 @@ Note: a sector is *always* 512 bytes.
 The 3 areas in the image are as follows:
 
 1. A 5 sector reserved area at the beginning. The first sector of the file has a copy of the *FS Information Sector*, the rest is filled with zeros.
-2. The firmware image area, about 32MB in size.
+2. The firmware image area, about 32MiB in size.
 3. The writeable file system
 
 ## Firmware image area
 
-This area contains three full copies of the firmware at sector `0x0000`, `0x4000` and `0x8000` within this area. The allows up to 8MB for the firmware data. And while the firmware is about 11MB large, it is compressed only about 1/3 of that, so the current firmware versions do fit comfortably.
+This area contains three full copies of the firmware at sector `0x0000`, `0x4000` and `0x8000` within this area. The allows up to 8MiB for the firmware data. And while the firmware is about 11MiB large, it is compressed only about 1/3 of that, so the current firmware versions do fit comfortably.
 
 The firmware data starts with one header sector, which only uses a few words:
 
@@ -114,7 +114,7 @@ It only supports files and directories. Links, file attributes, access rights, e
 
 ### Clusters
 
-Note: The system combines 32 sectors into one cluster. This means the smallest size of a non-zero file is 16kb. Addressing of data however is always done via sector numbers, relative to the beginning of the file system. Clusters are only used for managing which sectors are used and which ones are empty.
+Note: The system combines 32 sectors into one cluster. This means the smallest size of a non-zero file is 16KiB. Addressing of data however is always done via sector numbers, relative to the beginning of the file system. Clusters are only used for managing which sectors are used and which ones are empty.
 
 A cluster can contain either system records or raw file data.
 
@@ -147,8 +147,8 @@ Regular file data is written as raw data to disk. No duplication, no checksums,
 
 | Type | Name | Description |
 | ---- | ---- | :---------- |
-| LXFF | File | First record of a file, allows up to 1.3MB large files. |
-| LXFE | File Extension | Additional records to add up to 1.9MB to a file. |
+| LXFF | File | First record of a file, allows up to 1.3MiB large files. |
+| LXFE | File Extension | Additional records to add up to 1.9MiB to a file. |
 | LXFD | Directory | First record of a directory with up to 44 entries. |
 | LXFC | Directory Extension | Additional records to add up to 61 entries to a directory |
 | LXFT | Transaction | Double sectors used to track transactions |
@@ -164,12 +164,12 @@ Regular file data is written as raw data to disk. No duplication, no checksums,
 | 0x084-0x087 | creation timestamp | Loxone timestamp of the creation date/time of this file, like a UNIX timestamp, but starting at 1.1.2009 |
 | 0x088-0x08B | modification timestamp | Loxone timestamp of the last modification date/time of this file. Set on close. |
 | 0x08C-0x08F | file size     | Size of the file in bytes |
-| 0x090-0x093 | maximum file size | This is the maximum size, before additional clusters need to be allocated. It is typically – but not necessarily – the file size rounded up to the next 16kb |
+| 0x090-0x093 | maximum file size | This is the maximum size, before additional clusters need to be allocated. It is typically – but not necessarily – the file size rounded up to the next 16KiB |
 | 0x094-0x1EC | cluster list  | List of up to 86 sectors pointing to the start of clusters containing the actual file data |
 
 ### File extension record
 
-If a file is too large, extension records are added. They are linked via the link sector at offset `0x0C` to the file record. Because a file record is stored in a cluster, a file typically has 16KB/2 (duplication sectors) minus 1 (the file record) == 15 file extension records, which is enough for almost 30mb large files. But it can be extended by allocating additional clusters for file extension records and linking them to the file record.
+If a file is too large, extension records are added. They are linked via the link sector at offset `0x0C` to the file record. Because a file record is stored in a cluster, a file typically has 16KiB/2 (duplication sectors) minus 1 (the file record) == 15 file extension records, which is enough for almost 30MiB large files. But it can be extended by allocating additional clusters for file extension records and linking them to the file record.
 
 |      Offset |          Name | Description |
 | ----------- | ------------- | :---------- |
@@ -214,13 +214,13 @@ The system needs to keep track, which clusters are used and which ones are avail
 | 0x000-0x003 | available clusters | available clusters in this record |
 | 0x004-0x1EB | bitmap        | 122 32-bit values used as a bitmap |
 
-One record can store the state of 32 * 122 = 3904 clusters or 61MB. The number of records needed depend on the size of the file system. The allocation record always starts at sector 64 and extends from there. For a 2GB disk image it is 64 sectors large.
+One record can store the state of 32 * 122 = 3904 clusters or 61MiB. The number of records needed depend on the size of the file system. The allocation record always starts at sector 64 and extends from there. For a 2GB disk image it is 64 sectors large.
 
 The available clusters field is an optimization, which counts the zero bits in the bitfield. It allows to quickly find allocation records with available space.
 
 The number of allocation records is depended on the size of the volume, because it needs to store the status for all possible clusters. In the above example the number of sectors is 0x3AAB00. To calculate the cluster number we have to do this:
 
-    sectorcount * 512 (bytes per sector) / 16kb (size of a cluster) / (122*32) (number of bits in the allocation record) + 1 (rounding up)
+    sectorcount * 512 (bytes per sector) / 16KiB (size of a cluster) / (122*32) (number of bits in the allocation record) + 1 (rounding up)
     clustercount = (2 * sectorcount + 31) / 32
 
 For 0x3AAB00 sectors we need 31 allocation records and 2 clusters. Twice the sectors because every sector in the allocation table is stored twice on disc and `+31)/32` to round up, not down. 32 sectors are in a cluster. So, in this example 2 clusters after the root directory are reserved for the allocation table. Unnecessary sectors (because of rounding) in this clusters are simple empty (all zeros).