The tool still lacks some feature of the proprietary one but
can create files with all the basic features.
Change-Id: Ib0c91210940ca829291ce70945f88dc510a49974
The PWM code was for testing only the Zen X-Fi and should be
present in general because it could touch pins by error and
without producing any result.
Change-Id: Id20e2940cd7a057941d241254d0a867f5451e2db
It appears that all devices based on the Sigmaltel SDK support a
common vendor specific SCSI interface when in UMS mode. This
applies to the STMP36xx and the STMP37xx. This interface supports
many operations:
- get device info
- get device paritionning
- get janus/drm info
- read/write/allocate/erase any partition
- reset (chip or to updater and/or recovery)
This includes the ability to do a firmware upgrade by rewriting
the firmware partition. The tool currently does mostly nothing
but will be enhanced depending on the reverse engineering efforts
and the use of it. It has been tested on the Fuze+ and the Zen
X-Fi2/3.
Change-Id: Ibd4b2ad364c03ada4f9001573ef4cc87cfb041d1
The new tool fwcrypt can create a firmware image with a specified
model, version, region and so on.
Change-Id: I0e90e9ab905398a3e7ae3f4fb8b8bbfb2d12d703
Samsung provides many firmware upgrade in the format of a .dat
file, at least for nearly all YP's (checked for Q2, R0, T10, Z5).
This is a simple cyclic xor which a fixed key, a md5 sum and a
header specifying the model/version/region.
Change-Id: Ib0461a74196383189fd2d8162da444a85a229c60
This tool is very preliminary but could be use for whatever
purpose since the format of the rsrc sections is now known.
By the way it appears that this format is the same as the
one use by the stmp36xx for its resources.
Change-Id: Idd7057f5cdce5af9726904169bb100c8bacb0981
While elf simplification is a powerful tool it can be useful to
prevent it from happening for debug purposes. Also add a missing
switch description in usage() and missing static.
Change-Id: I80a1904dc4340c412bd3de1c124a2e38d6ac11a2
This is less useful is most cases because sb2 doesn't have the
size restritions but some elf are produced with one section per
file and still yield dozens or hundreds of sections. And this free
anyway so we can do it.
Change-Id: Ia5ca83a8375063ecc7052d1ea73b2b21c00be730
Load, fill and call/jump instructions are extracted as elf files
like for sb2. Because of the size limitations of the sb1
instructions, the resulting elf files can easily have hundreds of
sections. The (currently) implemented elf simplification method
will hopefully reduce this to a few sections only
Change-Id: I8fd6ed935ac3128f244bbd71c782e2a0a1c6d44a
Implement actual loading of a sb1 file to a structure in full
generality. Also implement dumping for debug purpose
Change-Id: I320035ea628719480a79aaccb05dce9a83256927
The STMP36xx series also uses .sb files but with a different
format. The main differences are the encryption and the lack of
sections, making it basically a list of commands: fill, load,
call, jump, switch mode, set sdram settings. Currently only the
sbtoelf has support for the sb1 and can only dump the list of
commands. Actual support for elf creation will come later.
Change-Id: I1f2e0230c91ac64efd0e8430e0c5212098c599fd
The hwemul tool is a small binary blob running on the device
that can received commands over USB. It is mainly intended to be
loaded using the recory mode and allows to read/write registers,
memory, use the OTP device, ... The tool is split into three
parts: dev/ contains the actual blob (which handles both imx233
and stmp3700), lib/ contains the communication library and can
also use the register description produced by the regtools/
to ease register by name, tools/ contains an interactive tool
to send commands to the device when running the blob.
Change-Id: Ie8cb32e987f825d8ed750d48071e43415b4dacb3
These files were produced by parsing some linux and/or sigmatel
provided headers and later tweaked by hand or by programs.
Each file describes one or more soc. A soc has a list of devices.
Each device can either be unique or have several copies at
different addresses. Each device has a list of registers which
can either be unique or indexed. Each register can further have
a list of fields. Registers with a SCT variant are also handled.
Change-Id: Ib50bb3fda268b6d5713f81bd8961de7978a5815e
These tools allow one to read a register description in a XML
file and to produce something useful out of it. Three example
programs are written:
- tester which simply prints the register tree
- headergen which produces a set of headers with the #define
- hwemulgen which produces something for the hwemul tool (to come)
Change-Id: I52573688b29d5faeaf64ce7c5ffe08ee8db3d33c
There is a vendor specific command to read the NVP of the device,
including the KAS. The trick is that the data is randomly
scrambled using a so-called para_noise array of random values.
There seems to be a problem when retrieving large entries (>1000
bytes typically) which causes sg_pt do behave strangely.
Change-Id: Iefa6140df78ab9c7dcf7ac34cb1170979123ecd7
This tool can send vendor specific scsi commands to sony nwz
players such as getting serial number, model id, device info,
and others. It can potentially be used to get some private keys
stored on the device but probably not the KAS used to encrypt
firmware upgrades images(UPG).
Change-Id: Ia49c1edf8d421b20c4e9afeb1192e00e06eb6047
This tool is specific to the em1/mp200 sony based players. In
deals with raw emmc images (which is possible but hard to get).
This tool is also useful as a documentation of the underlying
emmc format used for a future port.
Change-Id: I66c9b0e47351e5d89f6a404aa62038e00fdc1093
The raw encode mode allows to use the raw encode_page routine on
any file which proved to be useful. The guessed fields of the
headers are based on some rk2918 headers which leaked. They are
mainly informative though (date, version, chip).
Change-Id: I139ea0c40f76b6dde041c448bbf3e7ecf9cab24a
If no output prefix is specified, a default is picked:
- filename with extension replaced by .afi for FWU files
- filename with extension replaced by .fw/ for AFI files
- filename without extension and with / for FW files
Change-Id: I6497b8f4a49f1238e5db738429f687cad3ae8a5a
The update_extract tool works by finding the compressed size and
the compressed data in the updater. This is problematic since
without the uncompressed size, inflate can produce extra bytes
at end. This is not a problem for our tools but the device will
plain reject it if sent by MTP/sendfirm for example.
Workaround this issue by reading and rewriting the archive
after decompression so that only the meaningfull data is written.
Change-Id: I117f434b92a56d93d269af49c3e426cd8cc0c7e4
In the case of encrypted SB files without any key match, it is
still possible to dump the section headers. The force option
allows one to do so. It also allows to dump unencrypted sections
of encrypted files if there are some.
Change-Id: I36280230679ac5903f9c451c68c276f5c6959536
I finally found a sensible format for the executable files.
The tool now can output the loading entry to elf files. Some
disassembly and analysis suggest the phys/virt addresses are
correct. However the entries are somehow linked and it is
still unclear how (are there "calls" to the code ? when ?).
Change-Id: Ied38b5bb297176c5755b5ecb3309f4a259c18cd4
I found out that the file has a number of "entries", in
3 categories. The third category seem to contain bootable files.
In the RKnano firmware file I have, these entries are named
"NandBoot1" and "NandBoot2". They seem to use the same format as
the stage3 of the RKnanoFW format but we do not understand this
format precisely for now anyway.
Change-Id: I72d77e609cdeeb802af793c010d6788bf36cd7e2
