Sony added extensions to the frambuffer interface. It is important to take them
into account since the OF uses them and might leave the framebuffer in an
unusual state which would make the dualboot not display anything. Also rework
the dualboot code so that it can boot rockbox (not doing anything at the moment),
display all tools or boot the OF.
Change-Id: Ia0f589c9ec8558f375270841503c0964aff07f0b
At the moment, the script install_duaboot does the following:
- rename SpiderApp to SpiderApp.of (unless it already exists)
- install payload as SpiderApp
- fixes permissions
Since SpiderApp is the main app, it will execute instead of the OF.
The current dualboot code (dualboot.c) is still a preliminary but the current
version displays an "all tools" menu to choose for. When exitting the menu
using BACK, it will run the OF.
With the modifications made by the install script, it should not be possible
to break the device. In the worst case scenario, the dualboot code crashes
and it restarted by the sysmgrd, or hangs. A safe way to recover is to plug
the USB cable and reset the device: the system manager will then start the
USB app and one can reflash the device if necessary.
Change-Id: Id9edab0347538ad2a8651a28aea7fd083feaa626
Unify series names: e46x -> e460 to be consistent with Sony' name. Add keys
for various players that were cracked using upgtools. The real KAS would need
to be extracted from a target but at least we can open/create firmware upgrades.
Change-Id: Id23a10e10170d7f6330c6699bf205c4df5ddebfe
This new tool (all_tools) embeds all the other tools and provides a menu to
choose which one to run.
Change-Id: I0e07864dd46559a7079b0f942c25155e6fa07112
Since the nwz_lib does not have any nvp code yet, it's quite of ugly hack
with hardcoded nvp node (11) for shipment information (shp). Thus I whitelisted
two series (NWZ-E460 and NWZ-A860) which I know for sure use this node ID.
Change-Id: I94c9b0db1f9d7ad764d2aa50576a911e710f25e1
This list can map from model id to device name. It was automatically extracted
from Sony's tools. In the future, we will probably generate it from a clean
database containing more useful information.
Change-Id: Ibe580edf25b60bf0bf4aef4a06f40dddd19c5404
This is useful because there is no easy way to get it except from Sony's tool,
unless one knows the npv node, but that requires to know the model already...
Change-Id: I202f7cdb2f7cf924cc5bdb53c17e34600d4bf153
The new search has two new features:
- it takes advantage of the fact that DES keys are only 56-bit long (and not 64)
- it is now multithreaded
As a proof of concept, I ran it on the A10 series firmware upgrade and was able
to find the key in a few seconds using 4 threads. The search is still limited
to ascii hex passwords (seems to work on all devices I have tried thus far).
Change-Id: Ied080286d2bbdc493a6ceaecaaadba802b429666
This is code is intended to development into a library of code for the NWZ that
will be useful to write the "bootloader" on those device. At the same time, it
comes with test programs that are easy to run in firmware upgrade mode and also
provide a great test bench for the library. At the moment, two test programs are
available:
- test_display: simply prints two messages using /usr/bin/lcdmsg
- test_keys: displays input key event
Change-Id: I9d214894ffc9127b528fcdd3eb5d6b61f4e657a7
The exec_file allows to embed a script/executable and run it on target. It takes
of unpacking, remounting contents rw and redirect output to exec.txt at the root
of the drive. More generally, rework how the makefile works.
Change-Id: Iec719227be96e80701ad8f5398d2d34389f4da9e
William Shipley sent this patch via mailing list. Original Message:
"There was a patch to rockboy in 2010 that fixed a problem where
the bottom tile row would be rendered at the top.
Here's the relevant issue from that time:
http://www.rockbox.org/tracker/11745
Note that Stummi openly admits it was a hack, not a true fix.
Sometime in the 6 years since, the root cause was fixed. Currently,
rockboy on the Clip+ and other 64px models shows the top of the gb
screen along the bottom of the display.
I confirmed that reversing this patch fixes the issue on my own
Clip+"
I don't have any of the mentioned targets, so someone else has to test.
Change-Id: Id29b78c4ece0af53ba1280029c18b76808a21da2
They did not compile anymore after the register hearder rework. This change
only fixes the syntax, the generated binaries are exactly identical.
Change-Id: Iec2347aa3deb1ddfe2ca36f0db1e481c4e2d329c
This clearly fixes recording on targets where the bias pin was wrong. It may
also improve recording on targets where the bias voltage was wrong. I was unable
to find those parameters on the ZEN Mozaic, which fallback to default values.
Change-Id: Ifb5f823c9cbd01f0d9a80fa5d49d93972c8b7cfe
For some reason, there was a mismatch between the setting (decibel) and the
audiohw code (centicel). This resulted in a gain divided by 10. This may
explain why some people experienced low volume with the mic on the fuze+.
Change-Id: I138ac18dd93c36f43a7dfce735efc826405c598c
The codec wasn't calling ci->set_offset() while decoding; as a result,
the saved offset in ci.id3->offset was only updated at the start of the
file and when seeking.
To reproduce the problem in the simulator or on a real device:
- Start playing an Opus file.
- Let it play until 15s, then turn the player off.
- Turn back on and resume playback. This'll resume correctly from 15s
(using time-based resume, I think, as the offset was 0?).
- Let it play until 30s, then turn the player off again.
- Turn back on and resume playback. This'll resume from 15s, based on
the initial position from last time, when it should resume from 30s.
I believe this will also fix FS#12799 ("Resuming opus file from bookmark
is not working correctly").
Change-Id: Iba67368e0029c968ef802693767e0722719bc38b
There was a lot of copy and paste, and the code was just crap. This commit tries
to clarify the code and also document the encryption procedure. Hopefully I didn't
break anything.
Change-Id: I257793010e7cf94f2b090b30bb8608359d3886e3
Also clarity parts of the code. The old code suffered from two defects:
- it was very unclear because it made changes to whole registers
(using as3514_write) instead of fields (using as3514_set/clear/write_masked).
Also the routing code was spread accross several functions which made it hard to
follow.
- it did not properly reroute audio on monitor changes. In particular, the following
could happen: when switching from DAC to radio, the code would fail to clear
SUM_off, resulting in a weird situation where the main mixer was off
(SUM_off) but the headphone where using the main mixer as input. Incredibly this
worked anyway (at least on AMSv2 and YP-R0) but resulted in strange volume gaps
between DAC and radio mode.
Change-Id: I7826835fdb59c21f6483b223883ca9289e85caca
