Adds boot data to as3525 devices Sansa C200v2 E200v2 Clip Clipv2 Clip+ ClipZip
fuze, fuzev2 m200v4
Adds boot_data to features.txt
default arm crt0.s now had boot data if HAVE_BOOTDATA is defined
Change-Id: I614a556696540511a69fc12a4520b01c268bf8a9
Bootdata is a special location in the Firmware marked by a magic header
The bootloader is able to copy information to the firmware by locating
this struct and passing data to the firmware when it is loaded but
before it is actually executed
Data is verified by a crc of the bootdata
Change-Id: Ib3d78cc0c3a9d47d6fe73be4747a11b7ad6f0a9e
This call was not needed in the first place, but was causing crashes in
sgt-puzzles. Removing it fixes the crashes.
Change-Id: I1149d5600e1c97e0e848fdd34bf65d54c930adab
This should make it build cleanly under -Wcast-align, which should
hopefully avoid any alignment issues on ARM.
Change-Id: Ie147323d2d8cb980dcbb94710387b7ee80826c4d
This adds colored font rendering, as well as a workaround for font
loading while zoomed. Additionally, the frontend has been modified to
match the new upstream API.
Change-Id: I8c3fe57e6854f176485bf792cf4778cd54a21674
Playing AAC-HE files resulted in a race condition between
audio/codec/buffering for set_cpu_frequency
Change-Id: I35e1c1fd18db623e2990c305acdca03f57184d0d
This adds a "Zoom In" option to the pause menu of each puzzle, which
displays the puzzle at triple size (subject to change). This should
help with tiny screens, modulo memory concerns associated with
allocating the temporary framebuffer to which drawing operations are
redirected. Coincidentally, there's an upstream bug with Map that
causes the cursor's positioning to be incorrectly displayed when
zoomed.
Change-Id: Ic8b7c2942acf558e295f4271dd7dc458cd336895
* Editing a bunch of drivers' thread routines in order to
implement a new feature is tedious.
* No matter the number of storage drivers, they share one thread.
No extra threads needed for CONFIG_STORAGE_MULTI.
* Each has an event callback called by the storage thread.
* A default callback is provided to fake sleeping in order to
trigger idle callbacks. It could also do other default processing.
Changes to it will be part of driver code without editing each
one.
* Drivers may sleep and wake as they please as long as they give
a low pulse on their storage bit to ask to go into sleep mode.
Idle callback is called on its behalf and driver immediately put
into sleep mode.
* Drivers may indicate they are to continue receiving events in
USB mode, otherwise they receve nothing until disconnect (they
do receive SYS_USB_DISCONNECTED no matter what).
* Rework a few things to keep the callback implementation sane
and maintainable. ata.c was dreadful with all those bools; make
it a state machine and easier to follow. Remove last_user_activity;
it has no purpose that isn't served by keeping the disk active
through last_disk_activity instead.
* Even-out stack sizes partly because of a lack of a decent place
to define them by driver or SoC or whatever; it doesn't seem too
critical to do that anyway. Many are simply too large while at
least one isn't really adequate. They may be individually
overridden if necessary (figure out where). The thread uses the
greatest size demanded. Newer file code is much more frugal with
stack space. I barely see use crack 50% after idle callbacks
(usually mid-40s). Card insert/eject doesn't demand much.
* No forcing of idle callbacks. If it isn't necessary for one or
more non-disk storage types, it really isn't any more necessary for
disk storage. Besides, it makes the whole thing easier to implement.
Change-Id: Id30c284d82a8af66e47f2cfe104c52cbd8aa7215
The encryption definitely uses some standard elliptic curve encryption over
binary fields (163 and 233 bits, standard polynomials). It is still unclear
how this is used in the actual encryption, the key authentification and
derivation do not look standard.
Change-Id: I6b9180ff7e6115e1dceca8489e986a02a9ea6fc9
Now print list of devices immediately even if the rest of the command line
is empty (ie 'scsitool -s ?' works, whereas before one would need an actual
device to even get a list). Add more information in the help_us command:
print kas, lyr and fpi.
Change-Id: Icfeeaeebe28c774a74ca54661357fafa25c3d114
One mustn't assume a plugin will only call plugin_get_audio_buffer one
time or that the buffer_size pointer is always non-NULL. At least one
plugin, pacbox, will call it each time it (re)starts audio, with a NULL
param (which is intentional because it only wants to kill audio
playback), and leak away all the RAM because the handle gets clobbered
by further calls and the memory can't be released.
Change-Id: Ic5b94dbc0277c42964ea85b4e9d0302a7c6f1fe4
Most importantly is surround shouldn't operate in mono mode. Have it
watch and (de)activate itself on relevant format changes as it should.
Other changes to better handle buffer allocation failure.
PBE was set internally at 100 by default; SBZ.
Change-Id: I328e0b674e56751a255eae817d7892d685796b06
We don't really know what those are supposed to do. They seem to change the
volume curve but it is not very clear what is the intended purpose.
Change-Id: I65f5d18aba139844c23df092277ba17ee8518f96
Playlist was CRC-ing the path from the id3, which may have been
modified to remove "bogus dirs". This would cause a CRC mismatch
in the resume information.
Now, just use the current playlist's current index and call
playlist_get_filename_crc32() to get the original path when
updating resume info.
While technically correct, if this causes any issue(s) it's just
a one-line change and painless to revert.
Change-Id: Ie595ef6c40349c342bd7acac8c542829f9cd5d76
sonynwz: quirk for cpufreq broken driver
There was some redundancy between frequency_linux(cpu, true) and
current_scaling_frequency(), also I see no reason to compile the cpuinfo stuff
unconditionally and the scaling info only on DX since it was already printed
some partial scaling info anyway. Thus compile all the code unconditionally
and simplify the logic in the debug menu. Also avoid putting buffers of size
PATH_MAX on stack since it can be quite big and we only requires 64 bytes
for those paths.
On Sony NWZ, the cpu driver reports frequency in MHz instead of kHz thus we need
to make the cpuinfo code aware of that bug.
Change-Id: I61af45ab5f179ecc909b4841b9137a915a60193a
The tool now provides more useful information for developers when the device
is not supported. Is also has a new verb "help_us" that also prints all this
information (notably the device info and model ID).
Change-Id: I04baec8fff23eb83a0408add6296b5d42e9aa8e7
We still miss the model IDS for those device so scsitool won't be able to
recognize them automatically.
Change-Id: I17ae0f0d95c011cea8e289def63c7673b6c4b667
Simply extends the current isqrt() to be able to do fractional bits
and improves the initial estimate using clz(). iqrt() itself is
no more and is equivalent to fp_sqrt(x, 0). The original also had
a small bug where the guess comparision should have been >=, not >.
Uses no large integer math or division and is very accurate
(simply returns a truncated fraction).
Change-Id: I2ae26e6505df1770dc01e56220f7385369f90ae9
Aims to provide a lib/keymaps.h for plugins needing simple button
functionality beyond that provided by PLA. Currently used by puzzles
and xworld.
Change-Id: Icb3493aaf176d401762de834dd48fc76a3824c5a
The bug is due to a stupid make misfeature. The article [1] contains much more
information but in a nutshell, the following code:
a b: c
bla
is equivalent to:
a: c
bla
b: c
bla
This is bad because in parallel runs (make -j typically), "bla" can be run
TWICE and even worse, twice in PARALLEL. Obviously the result will be
completely unexpected. This is a real bummer because on the other hand,
the following code:
%.c %.h: %:in
bla
actually expresses the fact that bla produces two files. For some reasons,
pattern rules work differently from implicit rules.
This commit attempts to fix the problem with lang.h by rewriting (simplified):
lang.c lang.h: lang.in
genlang
as
lang.h: lang.in
genlang
lang.c: lang.h
This works (it correctly expresses the dependency chain and ensures genlang runs
once) but as one drawback: if one manually removes lang.c, then genlang will not
re-run since the second rule does nothing. This is minor drawback since no one
ever removes lang.c manually and "clean" removes lang.h which triggers a rebuild.
[1]: https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html
Change-Id: Ic0bf7c7c203dc599b00fde457946d2316c70474e