Split WM1A/WM1Z because they don't have the same KAS. On newer devices, the KAS
is actually 64 bytes, not 60. The strange thing is that "get_dnk_nvp kas" returns
60 bytes whereas "get_dnk_prop kas" returns 64, not sure why.
Change-Id: I944d3d838209ba58388439af0cdf5d7c74f1f7fc
This is one of those fancy gold-plated devices. Of course it breaks my scripts
that were nicely expecting every device to start with NW.
Change-Id: I161320f620f65f4f92c2650d192b26a9831eeb9d
There is something weird going on: the Sony website has two different entries:
- NW-ZX300/NW-ZX300A/NW-A45/NW-A47/NW-A45HN/NW-A46HN
- NW-ZX300,NW-ZX300A update(20181004)/NW-ZX300G
with slightly different nvp entries, but it is impossible to tell whether
an NW-ZX300(A) belong to one or the other. Since the diff is very small,
I am adding this as nw-zx300g but treat all devices as nz-zx300 since the
destination node is the same and that is the main usage of the tool anyway.
Change-Id: I3dc2fdec52650f938d568bed578184f6bc43d130
We still miss the model IDS for those device so scsitool won't be able to
recognize them automatically.
Change-Id: I17ae0f0d95c011cea8e289def63c7673b6c4b667
SUPPORTED SERIES:
- NWZ-E450
- NWZ-E460
- NWZ-E470
- NWZ-E580
- NWZ-A10
NOTES:
- bootloader makefile convert an extra font to be installed alongside the bootloader
since sysfont is way too small
- the toolsicon bitmap comes from the Oxygen iconset
- touchscreen driver is untested
TODO:
- implement audio routing driver (pcm is handled by pcm-alsa)
- fix playback: it crashes on illegal instruction in DEBUG builds
- find out why the browser starts at / instead of /contents
- implement radio support
- implement return to OF for usb handling
- calibrate battery curve (NB: of can report a battery level on a 0-5 scale but
probabl don't want to use that ?)
- implement simulator build (we need a nice image of the player)
- figure out if we can detect jack removal
POTENTIAL TODOS:
- try to build a usb serial gadget and gdbserver
Change-Id: Ic77d71e0651355d47cc4e423a40fb64a60c69a80
I am unsure about the names of the player, the manual says A36HN and A37HN but
at the same time there is a A35 and A35HN with the same ID, and Sony does not
usually put the "HN" in its device list.
Change-Id: Idbf32970aa334b30f1b8947a78b8eebd524b193b
* make gen_db.py work on Windows/Python 2
- use hashlib module instead of md5sum, also don't rely on / for file path
matching
- don't use 'file' for a variable name
* fix parse_nvp_header.sh for older kernels
pre-emmc kernel sources use a slightly different #define format; adjust
regexp to catch it.
* add nwz-x1000 series NVP layout (from icx1087_nvp.h)
some new tags have no description, alas the driver doesn't have
them :/
* minor fixes to nvp/README
fixed typos/wording
Change-Id: I77d8c2704be2f2316e32aadcfd362df7102360d4
We don't know the encryption method, the KAS is completely different but it
might be useful to record it anyway for future purposes. MID extracted from
device, Japanese NW-A35.
Change-Id: I4c4bb5b063da99003b5c316061d8c490b77428a4
It is Android based and despite the fact that Sony wrote an NVP driver for it,
experiments suggest it is unused because it returns ff all the time...
Change-Id: I37750b659e341b21bed5ebaccf60f9f5fe569f64
There must be an evil genius in Sony's Walkman division. Someone who made sure
that each model is close enough to the previous one so that little code is needed
but different enough so that an educated guess is not enough.
Each linux-based Sony player has a model ID (mid) which is a 32-bit integer.
I was able to extract a list of all model IDs and the correspoding name of
the player (see README). This gives us 1) a nice list of all players (because
NWZ-A729 vs NWZ-A729B, really Sony?) 2) an easy way to find the name of player
programatically. It seems that the lower 8-bit of the model ID gives the storage
size but don't bet your life on it. The remaining bytes seem to follow some kind
of pattern but there are exceptions.
From this list, I was able to build a list of all Sony's series (up to quite
recent one). The only safe way to build that is by hand, with a list of series,
each series having a list of model IDs. The notion of series is very important
because all models in a series share the same firmware.
A very important concept on Sony's players is the NVP, an area of the flash
that stores data associated with keys. The README contains more information but
basically this is where is record the model ID, the destination, the boot flags,
the firmware upgrade flags, the boot image, the DRM keys, and a lot of other stuff.
Of course Sony decided to slightly tweak the index of the keys regularly over time
which means that each series has a potentially different map, and we need this map
to talk to the NVP driver. Fortunately, Sony distributes the kernel for all its
players and they contain a kernel header with this information. I wrote a script
to unpack kernel sources and parse this header, producing a bunch of nw-*.txt
files, included in this commit. This map is very specific though: it maps Sony's
3-letter names (bti) to indexes (1). This is not very useful without the
decription (bti = boot image) and its size (262144). This information is harder
to come by, and is only stored in one place: if icx_nvp_emmc.ko drivers, found
on the device. Fortunately, Sony distributes a number of firmware upgrade, that
contain the rootfs, than once extracted contain this driver. The driver is a
standard ELF files with symbols. I wrote a parsing tool (nvptool) that is able
to extract this information from the drivers. Using that, I produced a bunch
of nodes-nw*.txt files. A reasonable assumption is that nodes meaning and
size do not change over time (bti is always the boot image and is always
262144 bytes), so by merging a few of those file, we can get a complete picture
(note that some nodes that existed in older player do not exists anymore so
we really need to merge several ones from different generations).
The advantage of storing all this information in plain text files, is that it
now makes it easy to parse it and produce whatever format we want to use it.
I wrote a python script that parses all this mess and produces a C file and
header with all this information (nwz_db.{c,h}).
Change-Id: Id790581ddd527d64418fe9e4e4df8e0546117b80
