Académique Documents
Professionnel Documents
Culture Documents
SmaRT
Architecture Design Specification
Bootloader SmaRT
Under Construction
PNB: /conversion/tmp/scratch/48505692.doc
Authors:
Role Name Department Date Signature
Author Thomas Eschenbacher evosoft GmbH 2008-03-13
Released by:
Role Name Department Date Signature
PL Kardas, Dario A&D AS RD DH F
PM
QA
Abstract
This document describes the function of the bootloader for OP73, OP77A, TP177, HT2, KTP400/600/1000/1500.
Table of Contents
1 Scope of this document...................................................................................................5
2 Startup Sequence..........................................................................................................5
2.1 Constraints...............................................................................................................6
2.2 Actions on startup...................................................................................................6
2.3 Main loop..................................................................................................................6
3 Image Processing..........................................................................................................7
3.1 Order of processing................................................................................................7
4 Image Header.................................................................................................................8
4.1.1 Image Header Structure............................................................................................................ 8
4.1.2 Usage of the Image Header Fields........................................................................................... 8
4.1.3 Image Types............................................................................................................................ 10
4.1.4 Image Attributes...................................................................................................................... 10
4.2 Extension of the Compression Algorithm to support Streaming....................11
4.3 Image Chaining / Fragments................................................................................12
4.3.1 Order of processing................................................................................................................ 12
4.3.2 Usage of dwImageAreaSize.................................................................................................... 12
4.4 CRC checks............................................................................................................12
4.5 Copy from Flash to Flash.....................................................................................13
4.6 Uncompress from Flash to Flash........................................................................13
4.7 Copy from Flash to RAM......................................................................................13
4.8 Uncompress from Flash to RAM..........................................................................13
4.9 Validity check.........................................................................................................14
4.10 Switch to Runtime or Hardware-Test..................................................................14
4.10.1 Passing Command Line Parameters to the Application......................................................14
4.10.2 MTD mapping per command line...........................................................................................15
4.10.3 Flash Directory........................................................................................................................ 15
4.10.4 Preconditions for starting an Operating System..................................................................16
5 Serial Transfer..............................................................................................................17
6 Serial Telegram............................................................................................................19
6.1 Available commands.............................................................................................19
6.2 Answers from device............................................................................................20
6.3 Error Correction.....................................................................................................21
6.4 Timing.....................................................................................................................21
6.5 Typical initial connection.....................................................................................21
6.6 Compression..........................................................................................................23
6.6.1 Compressed telegram-structure:...........................................................................................23
6.6.2 Compression algorithm:......................................................................................................... 23
7 Pointer to Hardware info and Flash Directory..........................................................25
7.1 Hardware Info.........................................................................................................25
7.2 Flash directory / Flash settings...........................................................................25
8 Device Specifica...........................................................................................................26
8.1 OP 73micro, OP73 micro-debug and OP 73........................................................26
8.2 OP 77A....................................................................................................................26
8.3 HT2..........................................................................................................................27
8.4 TP 177 family..........................................................................................................27
8.5 KTP1000 Basic / TP1500 Basic family................................................................28
8.6 KTP400 Basic / KTP600 Basic family.................................................................29
9 Examples of typical Image Headers..........................................................................30
9.1 Runtime under eCos.............................................................................................30
9.2 Hardware test for TP 177......................................................................................30
9.3 Linux Kernel for OP 77A.......................................................................................30
9.4 Root Filesystem for TP 177..................................................................................31
9.5 Configuration data for OP 73, stored in transfer area.......................................31
9.6 Abbreviations.........................................................................................................32
10 Bibliography...................................................................................................................32
History of Changes
Revision Date Changed parts and reason Name Department
0.1 2003-10-20 Initial issue Michael Frommberger sympat GmbH
0.3 2003-11-27 updates of protocol spec Michael Frommberger sympat GmbH
0.4 2004-03-18 added chapters about bootloader Th. Eschenbacher sympat GmbH
operation
0.5 2004-06-24 processing of images and fragements Th. Eschenbacher sympat GmbH
0.6 2004-10-11 special handling for HW-test Th. Eschenbacher sympat GmbH
0.7 2004-11-05 mtd partitioning per command line Th. Eschenbacher sympat GmbH
0.8 2005-08-01 support of error correction added Michael Frommberger sympat GmbH
0.9 2005-08-19 increment of package count on error Michael Frommberger sympat GmbH
added
0.9.1 2007-08-06 added XP179 and MAP1, removed Th. Eschenbacher evosoft GmbH
ISAC-73 and ISAC-73 TC, added
chapter for device specifica, added
XP179 and MAP1
0.9.2 2007-09-11 new device names: Th. Eschenbacher evosoft GmbH
- MAP1 4” → KTP400 Basic
- MAP1 6” → KTP600 Basic
- XP179 10” → KTP1000 Basic
- XP179 15” → KTP1500 Basic
0.9.3 2007-09-24 renamed R. Stiegler evosoft GmbH
KTP1500 Basic to TP1500 Basic
0.9.4 2007-12-17 added cmdline for MAP1 Th. Eschenbacher evosoft GmbH
0.9.5 2008-03-13 more cmdline parameters for MAP1 Th. Eschenbacher evosoft GmbH
Responsibility
Responsible for the coordinated contents are:
Name Department Location Tel Signature Date
Th. Eschenbacher evosoft GmbH Fürth 0911/978 - 3167
Distribution list
Distributed to: For attention:
This document describes the function of the bootloader for the all SmaRT devices. It also describes the serial
transfer and the compression algorithm used in it.
2 Startup Sequence
The following sections describe the actions that the bootloader performs.
power
on reset
initialize hardware
process HWI
main loop
process images
yes
reboot required ?
no
OS or app. no
present ?
yes
start OS or app.
2.1 Constraints
For the startup sequence, several constraints have to be met and some worst-case scenarios have to be
considered. These will be discussed below:
The bootloader ist the only place where all I/O-ports of the CPU and all peripheral units of the board
has to be done, no hardware initialization should be done later in the application.
The bootloader has to give a feedback to the user as soon as possible after the power-up, to show
that the board is “on”.
In case the whole flash of the board (except the bootloader itself) is erased or filled with invalid data,
it must provide a way to recover the device. Therefore the bootloader has to wait for a serial transfer
before it starts application code or evaluates the content of the flash.
In case the bootloader crashes while processing invalid or damaged flash content (images), it must
provide a way to recover. As a consequence, the bootloader has to wait for a remote transfer before
processing images from flash.
Before starting the application, all images in flash which need processing have to be processed.
1. eCos startup: Initialize all I/O-ports of the CPU (in ARM 32bit mode), switch to Thumb mode
(optionally), Initialize interrupt controller, system timer and enable cache (optional).
2. if it is the first startup, which is detected if hardware info (HW) is not valid:
a. unprotect the bootloader
b. create the common flash info (CFI)
c. create the hardware info
d. protect the bootloader
3. Initialize the display
1. If required: wait for a remote connection, switch to transfer mode if necessary. Timeout 6 seconds.
2. Process all images found in the flash, move them to different locations if necessary.
3. Check if a hardware test is present in the configuration area of the flash and start it if found.
4. Check if an operating system or application is present and start it if found.
3 Image Processing
Note: All portions of memory in the flash that require treatement, interpretation or execution, except the
bootloader itself and the settings storage (chunks) are called “image” in the context of the bootloader.
The following sections describe the basic operations and features that the bootloader provides for processing
images.
The search is using a fixed order and relies on the entries in the flash directory, using the given chunk name
as index, in the following order:
4 Image Header
For providing a certain compatibility with former SIEMENS applications, the current bootloader
implementation re-uses the same structure for image headers as for windows CE devices.
/**
* Structure for describing a CE (or smart) image.
*/
#pragma pack(1)
typedef struct
{
u_int32_t dwSignatur; // [0] Signature of the Structure
u_int16_t wDescVer; // [4] version number of the structure
u_int32_t dwRunAdr; // [6] start adress in RAM/Flash
u_int32_t dwStoreAdr; // [10] start adress in Flash
u_int32_t dwOrgLen; // [14] ungepacked image length
u_int32_t dwCompLen; // [18] packed image length
u_int16_t wOrgChkSum; // [22] CRC of the original image
u_int16_t wCompChkSum; // [24] CRC of the packed image
u_int16_t wVersionMajor; // [26] major part of image version,
u_int16_t wVersionMinor; // [28] minor part of image version
u_int32_t dwVersionImage; // [30] build, distinction of debug/release
u_int32_t dwVersionApp; // [34] version of application within image
u_int32_t dwEntryPoint; // [38] entry point for executable
u_int16_t wImageAttrib; // [42] attributes of image handling
struct ImageDesc *pNextDesc; // [44] pointer to next descriptor
u_int32_t dwImageAreaSize; // [48] length of packed image area
u_int32_t dwTypeImage; // [52] image-type
u_int16_t wTargetHW; // [56] target hardware for CE-image
u_int8_t reserved[CE_IMAGE_DESC_SIZE - 59]; // reserved for future use
u_int8_t byReboot; // image loaded, reboot neccassary
} ce_image_desc_t;
#pragma pack()
Table 1 CE image header
wDescVer: version number of the structure’s version. This is provided as a way of keeping
compatibility with newer versions of the structure which might have a different size or different
content (except these first two fields)
dwRunAdr: address where the content should be stored (or running), where the CPU expects the
image’s contents. If this address is different from the following field dwStoreAdr, this means that the
bootloader has to copy it to a different location before it can be used. If the target address is in RAM,
it specifies the start address of the content immediately following the image header. If the target
address is in flash, it specifies the address where the whole image, including the header has to be
copied.
dwStoreAdr: address where the content has to be laid within persistens storage. If this field does
contain an address that is different from the current position of the image header, the bootloader has
to copy/unpack the image to that position. If the target address is in flash, the content will not be
unpacked.
wOrgLen: length of the image, always including the size of the header
(even if IMAGE_OS_SPLIT is used).
wCompLen: length of the compressed image, always including the size of the header.
wOrgChkSum: CRC of the original image, not including the header. If the image is only a fragment
of a bigger image, only this current portion is used for the CRC calculation. Corresponds to wOrgLen
or wOrgLen, minus size of the header in case of a IMAGE_OS_SPLIT.
wCompChkSum: like before, CRC of the image after compression, corresponds to wCompLen.
dwEntryPoint: if the image is something that the bootloader has to execute, this specifies the
address (as seen by the CPU) where it should jump to. If this address is unused (e.g. for
configuration data), this address should be initialized with zero, which means “not specified / invalid”.
wImageAttrib: holds attributes that define which actions have to be performed by the bootloader
with this image. Will be explained in the following section. See section 4.1.4
pNextDesc: pointer to the start of next image header (address as seen by the CPU). This allows
chaining of images in different areas of the flash, which is described in section . If this is the only
image or the last image in a chain, this field must contain the special value 0x0000.0000.
dwImageAreaSize: holds the size of the whole, composed, image in case of a split image. In this
case it is the sum of all fragments. It should be present only in the first fragment. For all other
fragments in a chain or an unfragmented image it should be equal to the wOrgLen field.
dwTypeImage: defines the type of the image’s content. Possible types are “application”, “operating
system”, “hardware test” or “split/fragment”. See section 4.1.3
wTargetHW: bitfield for the supported hardware platforms on which this image can be used. For
Smart devices, this field always contains the special value 0x800F (Smart Device, unknown variant).
This is not interpreted by the bootloader and only checked to be non-zero. As we do not have
additional device information, it is up to the PC side to not provide any image that does not match the
device.
reserved: these fields are reserved for future use and are filled with 0xFF. They are not interpreted
by the booloader.
byReboot: If an image has set this byte to a non-zero value, the bootloader will reboot the device
after it has processed all images. All “byReboot” flags of all images that have been processed will be
logically “OR”ed.
/* img_type */
#define IMAGE_NONE 0x00000000 /**< image type none */
#define IMAGE_OS 0x00000001 /**< OS image */
#define IMAGE_OS_INPLAOS 0x00000002 /**< for demonstration only, not used! */
#define IMAGE_OS_SPLIT 0x00000040 /**< splitted part of os_image */
#define IMAGE_APP 0x00010000 /**< application (runtime) image */
#define IMAGE_HWT 0x80000000 /**< hardware-test */
#define IMAGE_OS_APP (IMAGE_OS | IMAGE_APP) /**< OS and App */
Table 2 Image Types
IMAGE_NONE: used for all images that are neither application/hardware-test nor operating-system.
It is also used for non-executable data, like configuration or receipt data.
IMAGE_OS: operating system image.
IMAGE_OS_SPLIT: splitted part / fragment of operating system.
Note: For SmaRT devices, it is also allowed to mark fragments of other image types. This flag is
needed by the bootloader to determine if it has to omit the copying of the image header in case of
the transfer of an image fragment (see discussion of chaining / fragments in section 4.3)
IMAGE_APP: application, runtime, or whatever is supposed to run on the device.
IMAGE_HWT : hardware-test, which has precedence over the application and/or operating system if
there are multiple possible images that could be executed.
IMAGE_OS_APP: combined image with operating system and application (e.g. runtime running with
eCos)
Unhappily the standard compression algorithm of the bootloader (and it’s implementation), is only suitable for
compressing blocks of memory, not continuous streams. As the bootloader does not have enough memory
to hold large buffers needed for transferring big images, there is the need for a way of compressing images
in units of small blocks and a scheme for decompressing streams.
s tr e a m w ith u n c o m p r e s s e d d a ta
1
5b
in b u ffe r in b u ffe r in b u ffe r
b lo c k s w ith 3 2 7 6 8 b y te s o f
a lr e a d y c o m p r e s s e d re s t
o r ig in a l d a ta
6
unused
pack pack pack pack
5a
2
o u tb u ffe r o u tb u ffe r o u tb u ffe r o u tb u ffe r
s tr e a m w ith c o m p r e s s e d d a ta
(o u tp u t, d e v ic e )
p a d d in g 5
c o m p re s s e d d a ta 4
le n g th o f c o m p r e s s e d d a ta 3
Figure 2 Algorithm for compressing streams
The first fragment (head) of a chain can have the IMAGE_OS_SPLIT flag in dwTypeImage set, but does not
need to, it depends on whether the header has to be copied or not. In case of an uncompressed image, the
dwImageAreaSize of the chain’s head can only reflect the size of the first fragment. In case of a compressed
image, the head contains the size of the whole image, which has been assembled from all it’s fragments.
The special handling of CRCs has to be taken into account, like described in chapter 4.4 !
When checking a compressed image, the length of the area to check is taken from dwCompLen and the
CRC from wCompChkSum is used. dwImagAreaSize and wOrgChkSum are ignored when checking the
compressed image, they only get their meaning when the uncompressed result has to be checked.
Consequences:
If the image was uncompressed but fragmented, the CRC would then only cover the first fragment,
and therefore it would be less secure than in case of an image that has been assembled out of
compressed fragments.
In case of compressed fragments, the CRC of the resulting image will span the whole image, over
the whole size from dwImageAreaSize, giving better security.
Conclusion: it is highly recommended to use compression at least for the first fragment of a chain,
even if this does not save space - but this increases security of the system!
By having (at least) the first fragment compressed, it is still possible to do a CRC check of the fragment itself
before processing, because the compressed CRC (wComChkSum) covers only the fragment itself. After
processing (uncompressing), the CRC (wOrgChkSum) will cover the whole image, including all previously
processed fragments.
It supports a mapping with read-only and read/write areas. Read-only areas are treated as “ROM” and read-
writeable areas are treated as “flash”.
mtdparts=<mtddef>[;<mtddef]
<mtddef> := <mtd-id>:<partdef>[,<partdef>]
<partdef> := <size>[@offset][<name>][ro]
<mtd-id> := unique id used in mapping driver/device, either “rom” or “flash”
<size> := size of the area in kB
<name> := '(' NAME ')'
Example:
mtdparts=rom:64k@0x0(@HWI)ro,448k@0x10000(@RT_)ro;flash:512k@0x00000000(@CFG), ...
For generating a command line with MTD mapping entries, the bootloader relies on a valid flash directory,
which is described in the following section.
One flash directory entry has four 32bit fields, which are encoded in the target’s CPU endianess:
1. The first entry must start at the start address of the flash device
2. Entries must be ordered by the start address, upwards
3. The list must not contain gaps. Gaps must be filled with spare entries “@SPA1...n”
4. The µClinux/Linux device numbers must be ordered and must not contain gaps.
5. The start address of area “N+1” must be the start address of area “N” + the size of area “N”
6. All addresses are referring to the bootloader’s address mapping. In non-MMU systems these are
equal to the physical address, in MMU systems the address mapping that the bootloader has set up
applies.
The consistency check is currently only implemented on a very basic/incomplete level. The filesystem type is
detected and checked as follows:
1. first 4 bytes are 0xFFFFFFFF
empty, not used, no filesystem, no further check (failed)
2. area starts with 0x30304543 (little endian, ASCII “CE00”)
SmaRT image header, check image integrity
3. area starts with ASCII string “-rom1fs-“
ROMFS, currently no further checks.
4. area starts with 0x28CD3D45 (CPU endianes)
CRAMFS, only checking for signature at offset 0x10 (ASCII string “Compressed ROMFS”),
currently no further checks
5. all other content, image address is zero or not 32-bit aligned
not valid
5 Serial Transfer
At start of the serial transfer the bootloader tries to establish a communication-link via RS485-interface to an
external client (baudrate: 9600 baud). If there is no response within the timout intervall, the image will be
loaded immediately if it is present and valid, otherwise the device keeps on waiting for a connection on the
serial port.
If the communication attempt with the default baudrate has been successfully established, the baudrate will
be increased by the client and the device detects the new transfer-speed. Afterwards the data is received,
the data from header and checksum separated und the commands are processed.
The bootloader ends when an OS image is started or the commands BOOT_CMD_END_BOOT_LOADER
or BOOT_CMD_CANCEL_BOOT_LOADER are received.
START
check state
of OS image
in flash
try to comm-
unicate with
client
comm. no
successfull
?
yes
detect load OS or
baudrate App from
flash
receive
telegram
do
command
no end of
telegram?
yes
END
6 Serial Telegram
Telegram-structure:
--- header
--- data
--- checksum
6.4 Timing
Receiving signature:
maximum time to get signature 100 ms
Normal communication:
Time to answer request 10 s
Connection established:
delay between packets tbd (depends on baudrate)
timout tbd
Example:
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 AA FF AA FF AA FF AA 55 ªÿªÿªÿªUªÿªÿªÿªU
AA FF AA FF AA FF AA 55 ªÿªÿªÿªU
AA FF AA FF AA FF ªÿªÿªÿ
port closed
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 ........
AA ª
10 00 01 00 EC FF FF 03 04 00 00 00 00 00 40 75 ....ìÿÿ.......@u
14 00 01 00 EC FF FF 03 04 00 00 00 01 00 00 00 ....ìÿÿ.........
04 00 36 37 ..67
10 00 01 00 00 00 04 00 80 00 00 00 01 00 B3 0F ........€.....³.
48 80 3E 00 90 00 0B 60 00 00 00 90 00 01 00 00 H€>...`.......
00 04 00 40 80 06 10 02 00 A5 01 C0 BF 01 00 08 ...@€....¥.À¿...
20 FF FF FF 40 04 20 0A 00 00 20 01 1A 10 67 08 ÿÿÿ@. ... ...g.
10 06 7F 30 11 10 03 10 06 40 0C A0 18 F0 18 30 ..0.....@. .ð.0
F0 30 03 10 00 5A 15 81 ð0...Z.
10 00 01 00 00 00 C1 BF 40 00 00 00 02 00 79 52 ......Á¿@.....yR
34 80 2A 00 50 00 50 F5 00 00 00 50 00 01 00 00 4€*.P.Põ...P....
00 C1 BF 40 40 06 10 03 00 C9 08 C9 08 C7 04 20 .Á¿@@....É.É.Ç.
04 20 C2 08 C2 0E 90 10 E0 10 E0 00 C9 08 C2 08 . Â.Â..à.à.É.Â.
C2 08 47 ED Â.Gí
6.6 Compression
1--------16--------32--------48--------64--------80----------------------------------------------------------------------length
--- header
--- data
1--4-----16-----24
--- length (< 15 + 2)
--- offset
--- length ( > 15 +2)
The information if a group is compressed or not is stored in the first byte (packmask). Bit 7 decodes the first
group, bit 6 the second etc. If the bit is 0 the length of the group is 1 Byte and the data is literal. If the bit is 1
the data is compressed.
Example:
Compressed:
48 80 3E 00 90 00 DF F1 00 00 00 90 00 01 00 00
00 04 00 40 80 06 10 02 00 A5 01 C0 BF 01 00 08
20 FF FF FF 40 04 20 0A 00 00 20 01 1A 10 67 08
10 06 7F 30 11 10 03 10 06 40 0C A0 18 F0 18 30
F0 30 03 10 00 5A 15 81
decompressed:
|------packmask-------| |----------------------------------------data-------------------------------------------------|
00 0000 0000 90 00 01 00 00 00 04 00
40 0100 0000 80 00 00 00 02 00 A5 01 C0 BF
01 0000 0001 00 08 20 FF FF FF 40 FF FF FF 40
0A 0000 1010 00 00 20 01 00 80 00 67 00 00 20 06
7F 0111 1111 30 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF
00 0000 0000 5A 15 81
To be compatible with i386 devices and older versions of ProSave, we also support reading the address of
the hardware info through reading at the i386 address 0x03FF.FFEC.
Important Note: the vector to the hardware info is not really located in the memory location at the offset
described above. Instead the bootloader/transfer software “fakes” the content of this memory location and
takes care of providing the real position of the hardware info.
8 Device Specifica
8.2 OP 77A
Makefile target: OP77A
Supported variants: -
Flash usage: 64 kB
Flash Sector size: 64 kB
Supported Flash Devices: AM29LV160, AM29LV320,
AM29DL161, AM29DL162, AM29DL163, AM29DL164
AM29DL322, AM29DL323, AM29DL324, AM29DL640
Location of the flash directory: 0x0101.0000
Supported Displays: S1D15714, 160x64 @ mono
Reserved RAM area: 0x0000.0000 – 0x0003.FFFF (256 kB)
Transfer Methods: serial transfer via RS485
OS Support: eCos and µCLinux
Command Line: R0 = pointer to string with MTD settings, see section
8.3 HT2
Makefile target: HT2
Supported variants: -
Flash usage: 256 kB
Flash Sector size: 64 kB
Supported Flash Devices: S29GL016A R2
Location of the flash directory: 0x3008.0000
Supported Displays: S6B0724, 128x64 @ mono, using a 6x8 pixel Font
Reserved RAM area: 0x0000.0000 – 0x003F.FFFF (4 MB)
Transfer Methods: ethernet transfer via TFTP (+ HT2 specific DHCP)
OS Support: eCos
Command Line: none, R0 is always zero
Note #1: This bootloader does not initialize the hardware, instead it uses the
hardware setup that is done by the BIOS.
Note #2: The bootloader binary has a CE image header.
Note #3: The bootloader uses a self-extractor stub to unpack itself into RAM.
Note #4: The DHCP implementation has SIEMENS/MC specific extensions.
dwRunAdr = 0x0108.0000
dwStoreAdr = 0x0108.0000
dwOrgLen = 0x0002.0000
dwCompLen = 0x0002.0000
wOrgChkSum = 0xCAFE
wCompChkSum = 0xCAFE
dwEntryPoint = 0x0108.0040
wImageAttrib = ATTR_INPLACE | ATTR_UNPACK
pNextDesc = 0x0000.0000
dwImageAreaSize = 0x0002.0000
dwTypeImage = IMAGE_OS_APP
9.6 Abbreviations
nu not used
tbd to be defined
OS Operation System
10 Bibliography
[1] Hardware-Info Windows-CE, G. Wenger, A&D PT1 D1, 21.10.2002 (?), version 1.5
(german)
[2] SmaRT flash services, sympat GmbH