* Bump internal mix buffer size by 4x, to 1K frames (matching ALSA period)
* Handle an underrun that occurs when filling the audio buffer
* Log underruns and make them available in the debug info
Change-Id: I28d56dd35d88851fa167ad92368a5882937a758f
It's not large enough on some targets.
(this will be revisited when the USB insertion prompt stuff is moved
out of the USB helper and over to the main thread)
Change-Id: Iefed2cdf2fbb4ce92569fc5cacbdb479b7d24e61
It turns out the code for the firmware size validation was incorrectly
using the total length of the firmware file to check if it was too big
for the flash rom which caused it to incorrectly flag larger bootloaders
as too big even though they would still fit.
As it happens this situation can only really arise after mkboot has been
run on the decoded firmware image. Because mkboot writes the actual binary
size to the ESTFBINR header we will be using that to check if the firmware
image is too large for the flash rom.
Now because this information is embedded in the decrypted / encrypted
region we have to collect it as the region is processed so the validation
is also moved to after the data processing loop.
Change-Id: I8bfead73812fe4e59f08fbbe8956790604dcb4e2
It was short by a fair number of bytes which could be reached when
attempting to insert bootloaders near the maximum size of 64k. This
ensures even the largest acceptable bootloader will not overflow the
buffer.
Change-Id: I8fbc92d4e3452192bf47104d7a32b49248eefc0e
First, the way it was invoking mkboot was no longer correct so it
was not producing files used in the later commands.
Second, support for the H300 1.31k firmware was added sometime ago
but not to this script.
Change-Id: I0e9c74a3b9f83ade8d01df0bebfe06f4d3b92ce4
This removes all the pre-release bootloader of version 7 and
replaces them with production releases of version 8. The
pre-releases have their own problems and should be left
behind as they were never officially released.
Change-Id: If96531ba63cf4401d04133bda94735fe94ae4de1
Return status as int, not as string, and provide a separate function for
converting to string. This allows to filter based on the actual status,
not a (localized) status string, which is more robust.
Fix a regression that made players with missing status value show up as
retired.
Change-Id: I15f83ae0df484199b1b3b5b95069db8b4d425987
Allow constructing release candidate URL from configuration the same way
we construct the URL for releases.
Note that the server path used does not exist, taken from old release
candidate builds not available anymore.
Change-Id: I7332f08df05ed39724b4900556aaa1f5e0ba463b
Allow extracting release candidate version even if no URL is present.
Avoids a special case for version handling.
Change-Id: If496d30059c3181899ab9337a35a07b39eaef52e
Don't create our own in-memory map with server data. Instead use the
configuration file retrieved from the download server, and do the
resolve / replacement on the fly.
Simplifies things, and prepares for cleaner handling for different build
types.
Change-Id: Ifd027b21486e402fda3df9c2f7a30264651f733d
- Don't construct the URL directly. The ServerInfo already has it, use
that instead.
- Don't manually construct the output filename. ZipInstaller will use
the server filename automatically.
Change-Id: Ib44616daf5efc95b238418b6e699ccd56c40b011
- Further extend stubs, pull in less non-stubbed implementations.
- Change some test URLs to make sure the code actually uses the correct
ones.
Change-Id: Iac1d683748b5834e61aa4974d1b893b77f90b517
After reviewing the code awhile I realized that the failsafe and hold
switch have no impact on the boot process when the usb or charger is
connected. That makes no real sense to me. If these are connected then
neither will be used at all. The boot process will never revisit it
either once those other modes end and resume the boot process. It will
just continue to try to boot from disk as if these emergency settings
never existed.
I have decided it makes more sense for them to be evaluated once the
higher priority charge and disk mode have finished their roles. Given
how the code was originally written it seems to be they were not
intended to run prior to these at the very least since the logical
conditions preclude that possibility as they include the inverse of
the conditions that trigger the charge and disk modes.
Change-Id: I0531c97474572c573178f480c239c3c1659f9653
This fixes an early boot bug on the h300 where hold_status is
read before it has a chance to properly check whether the hold
switch is even active. This was accomplished by porting over
the method the h1x0 uses to perform the same check.
Change-Id: I04679d82f65a2edcbee4be9a146437c3988040a2
This saves a few bytes of precious space by consolidating paths where
they can be combined with no change to the underlying algorithm.
Change-Id: Ie6b7ead190a87d66fcbdcf2e351010bab751d952
The table is now gated by the FLASH_SIZE macro as any given
target will not have a known rom chip of a differing size
than the FLASH_SIZE. This will reduce the resulting code
a bit as well.
Change-Id: I06a283f9f44118080a106e1bcd410e81e0a48d92
The most major change here is the porting of the failsafe boot
menu and eeprom settings support from the h1x0 bootloader to the
h300 bootloader. This has been successfully tested already and
indeed works about the same as it does on the h1x0 bootloader.
The other major change is the addition of new code to both
bootloaders that will retry the flash boot function after
exitting disk mode. It still falls back to booting from disk
if this either fails or is not configured to boot from flash.
There were also various other modifications to bring the two
closer in sync so there are fewer differences.
Change-Id: I17a5724e03225b57e9d0071387294aa6cd025178
I discovered it was doing this on the H300 during longer operations
and I freaked out at first. This disables this feature until the
program is finished so as to not give anyone else an unnecessary
fright while using it. It will also cut down on frivilous reports.
Change-Id: I0db406912c7f71835576203a540aba8910afa849
- Split internal configuration into player specific and common parts.
Always require passing the player for player specific data instead of
implicitly assuming the currently selected one; only use the currently
selected one if the player name is explicitly passed as empty.
- Similarly adjust handling of server info data; prepare for splitting
into build type specific values so the naming becomes cleaner.
Change-Id: I894e694f83bd9fe2d22ad46b3f8f7df3e2c68033
First this removes most of the conditionals for the CPP as they
are always true for the targets that use the bootloader source.
Second this moves some global variable references around to reduce
some redundancy in the h1x0 bootloader source.
All of this is done to make it easier to compare the two bootloaders
as they are very heavily related to each other.
Change-Id: I7eb4a3106fb9fce6059797310d9e053a3d3ecf63
This enables USB charging when the bootloader is in charge mode or
disk mode. As a byproduct there is a small change in behavior where
charge mode is all that is available if it is triggered by the USB
cable insertion. Disk mode only becomes available if the user requests
to continue the boot process by pressing the power button. It had to be
done this way as there's no way to tell this early whether the user
wants to simply charge or trigger disk mode as well.
Change-Id: I32f29398b22a76e5e754efdc9beecae39dd122d5
This makes it so the thread cached variable is only read if building
the regular firmware. For bootloaders the data is now read directly.
This fixes the functions for bootloaders so they do not have to import
the power management code just so these functions will work when in
the bootloader.
Change-Id: Ic425b02c08b48df7a11a6c19c022b0e1cb316a85
v3: Add in config option
v4: Bugfixes
v5: Force a redraw upon exiting
v6: keypress-in-chargeonly mode enables mass storage (and vice versa)
v7: Fix bootloader builds
v8: Update manual, and have bootloader respect keypresses
v9: Change default to mass storage (ie no change in behavior)
todo:
* test-build dx50/dx90
* Switch from yes/no to proper menu?
* prevent WPS progress bar from drawing over us
Change-Id: I82e0ccb08497b7a5aa756ce77f1332ee963703a7
...
Change-Id: I7946cf240b18a4fa8ace5e25e1eb6e97b8b12d7c
it takes a lot of code to check validity and dereference a pointer for every numeric tag branch in get_token_value
apparently about 900 bytes actually
Change-Id: If463e755e9bbc73cbd4a02441572d22df9206121
