This is an MIT-licensed library for reading and writing v7 format
tar files. The version here is my fork, which fixes security issues
in the original code (it hasn't been updated in 4 years, probably
abandoned by the author).
Change-Id: I86d41423dacc46e9fa0514b4fc7386a96c216e86
- Removed unnecessary layers of generic code
- Software ECC is gone since we don't need it now (and maybe not ever)
- Removed bounce buffering, so callers must now align buffers
Change-Id: I33fbac9d9d12a4657980b8618c7d62bfa91e2ea0
temp loader allows some lua requires to be loaded and
later garbage collected unfortunately the module needs to be formatted
in such a way to pass back a call table in order to keep the functions
within from being garbage collected too early
BE AWARE this bypasses the module loader which would allow code reuse
so if you aren't careful this memory saving tool could spell disaster
for free RAM if you load the same code multiple times
Change-Id: I0b6f81e481b8c779edbd620c8403794f8353926f
bring custom keyboard layouts to lua
conversion to the proper format requires create_kbd_layout.lua
just pass a lua string with your desired layout
Change-Id: I14a392410846311a4f3cf8dda0e88d39834d0418
Works from any playlist saving operation accessed from the
While Playing Screen, all other playlist saving operations
are unchanged.
Now a user-selectable setting! Located in
General Settings -> Playlists -> Current Playlist ->
Reload After Saving (Yes/No)
Change-Id: I5085c3f4c56c518a812d5ee015d15cc4dca19a28
'Bugfix' mono_bitmap_part reads ahead in the buffer,
if the height is <= char bit pixels other memory gets read
found with [Address Sanitizer]
also g#3332 since this is clearly a problem across the code
instead place the check for height < 8 in the lcd_mono_bitmap_part function
Change-Id: I917cbbd568fd5474b76a98c8919467e2538e0f0c
updated example script and renamed some functions as well
fixed bug in printtable cursor position if greater than maxlines for the
screen would reset to item 1
now we move the list start and select it
(and try to center it on the screen)
fixed a few bugs in the add_menu code
Change-Id: I01dead0481ef2e925af8b4cc6c14e36c2859dbba
This overwrote the first 2 instructions of crt0 in the bootloader!
I'm really not sure how this *didn't* cause a fatal exception.
This address isn't special as far as I know, so just move it to the
TCSM by making it a static variable.
Change-Id: I58e1486804aeb2b68325e8de2aa1874c97abef19
allows menus + submenus + context menus all with simple tables
menu_t which is a table of strings
func_t which are the corresponding functions to go with those strings
see lua_scripts/submenu_demo.lua
Change-Id: I907b74b4abef0ecbe49f181d0ced6e6d20e94de5
The abiflags data is only used to communicate ABI information to a
program loader -- you can see what info is stored with readelf -A.
Dropping it shaves 24 bytes off of every binary (including plugins).
Change-Id: Iae78eeffe5c840ff67717707fb94821d24aac8ec
It never worked, and hasn't compiled in something like a decade, Given
the HW capabilities (limited onboard flash, no expandability) there's
really no point in trying to fix/complete it.
Change-Id: I7d175089840396f8891645bd10010d730dd5bfdc
They were never finished, never saw any release ever, and haven't
compiled for the better part of a decade. Given their HW capabilities [1],
they are not worth trying to fix.
[1] 1-2MB RAM, ~256MB onboard flash, no expandability
Change-Id: I7b2a5806d687114c22156bb0458d4a10a9734190
There's absolutely no way for gpio_config() to get called from two
different threads due to the co-operative threading model, and it
is unsafe to call from IRQ context no matter what we do.
Change-Id: I58f7d1f68c7a414610bb020e26b774cb1015a3b0
Using a macro to put each function in its own .icode-based section
allows us to put the functions in IRAM _and_ have linker GC. This
removes a troublesome #ifdef BOOTLOADER_SPL on the X1000 target.
Change-Id: Ia7b59778f5c36b7970dee4280547e434a1f4fc5a
This menu serves no useful purpose anymore. I plan on adding an
improved version of this functionality to the bootloader instead.
Change-Id: I6a93625789f7192031eb6cee6708f9a867318622
After continued reports of corruption using iFlash adapters, I went
digging for more clues, and this combination of changes seemed to
solve data corruption with the iFlash adapters on the ipod video:
1) Instead of SLEEP, use STANDBY_IMMEDIATE when we detect drive
as an SSD or CFA-compliant device. The latter is technically higher
power than the former, but what this means in practice is unclear.
2) Don't check ATA powermanagement flag prior to issuing powermgmt
commands. This reverts the previous "workaround" for the FC1307A --
and PM is a mandatory part of the ATA spec for any CFA device.
3) Prior to issuing SLEEP/STANDBY_IMMEDIATE, issue FLUSH CACHE. The
ATA spec says this is redundant for the latter, but says nothing
about the former. Either way it is always safe to call first.
4) Delete all other FC1307A_WORKAROUND code related to powermgmt flags.
Change-Id: I492d06664c097d9bbd5cccfb9f5b516da165b1ee
Code in cpu.h is correct, so just disable -Wmisleading-indentation for
the specific sections that matter.
Change-Id: I378f3a6fef117ac73edb0d8ce998ef3a818be22e
Convert both instances of the apple stop sign constant
to char array instances. This ensures sizeof will work
as expected when applied to the constant.
Change-Id: I8599f7b0a00031e944e654b12a0bc59309926807
Although data transfer is reliable with DMA, it seems to cause hangs
and lockups during the early stages of connection and it's not clear
what the cause might be.
Change-Id: I9a83089c31d28309f0534dcdedf3c8c8348e6e3d
This only required a minor patch to the usb-designware driver due
to DMA requiring physical addresses -- on the X1000, these differ
from virtual addresses so we have to do the usual conversion.
Both the mass storage and HID drivers work, but there are a few
issues so this can't be considered 100% stable yet.
- Mass storage might not be detected properly on insertion,
and USB has to be replugged before it shows up
- HID driver may occasionally panic or hang the machine
Change-Id: Ia3ce7591d5928ec7cbca7953abfef01bdbd873ef
- Added register names to reduce usage of magic numbers
- Added function to control max charging current, needed for USB
- Corrected comment about axp173, since FiiO M3K has an axp192
Change-Id: I6604ce8d44e5a2ee84061cf042d17ccc4734ac57
The #if statement didn't reflect all menu items in the battery
menu, so if the USB charging enable setting was the only one
present, the entire menu would be hidden.
Change-Id: I17a4ed626debf1f61ca140d67d477bdbd52ca180
add stylized lines to lua
the exported do_menu has a severe limitation of 64 items
it also requires double the memory
put_line is the way rockbox builds menus
update printtable
user config from core -- done
code cleanup
fixed for 1-bit screens
changed button behavior
fixed for 2-bit screens
Change-Id: I4de55e42685aa1d2f53a33bc8e980827864e810b
After conducting some simplistic tests, I found that the power usage
did not appear to be affected by the CPU frequency.
I tested by playing back a 44.1 KHz FLAC file on single track repeat,
and measured current with the AXP173's battery discharge current ADC.
The button and LCD backlights were set to always on. Headphones were
unplugged and the volume was muted to eliminate any influence from
the headphone amp.
On average the current usage was between 78-81 mA at 1008 MHz, 252 MHz,
and 112 MHz. If anything, 1008 MHz drew _less_ current than the lower
frequencies, by about 1-3 mA.
A possible explanation for this, assuming it's not just a bias of the
test, is that the CPU idle state saves so much power that it's better
to maximize the real time that the CPU spends idling. More systematic
testing is needed to confirm this.
Change-Id: I527473e8c4c12bc1e94f8d4e849fecc108022abe
There's no point including this in normal builds: the stats are not
used for anything, they are not really of interest to anyone except
developers, and add a small overhead to the kernel tick.
Change-Id: I1b4f67cc62d11d634a8cec279dca513dd10eea96
Initializing the clocks in the SPL brings Rockbox in line with
how the FiiO M3K's original SPL works. It's likely other X1000
devices do this too.
There was a logic error in the previous setup: the code falsely
assumed that DDR memory would always be running from MPLL, but
it would be switched to APLL by the bootloader. Rockbox would
then try to re-init APLL, albeit with the same parameters. Maybe
this was the cause of the boot hang on some units.
Change-Id: I64064585e491bbdf1e95fe9428c91a9314f2a917
What we really want is to avoid any interrupts being generated
before the drivers which handle them are properly initialized.
Intead of trashing all GPIOs, search for the problem pins and
fix them, leaving the others alone.
This fixes the M3K's button light flickering on boot and should
stop the M3K from entering a potentially confusing "dead" state
where all the lights are off but the CPU is still on.
Change-Id: I13a6da0f0950190396bff5d6e8c343c668e8fea1
At present, this is just a command line tool for Linux only.
Integrating this with the Rockbox utility and porting to other
platforms should be straightforward; the README contains more
information.
Change-Id: Ie66fc837a02ab13c878925360cabc9805597548a
SPL is now designed so core X1000 code is in control of the boot,
under the reasonable assumption that the device boots from flash.
It should not be too hard to adapt to other X1000 ports.
The biggest functional change is that the SPL can now read/write
the flash, under the control of a host computer. The SPL relies
on the boot ROM for USB communication, so the host has to execute
the SPL multiple times following a protocol.
Change-Id: I3ffaa00e4bf191e043c9df0e2e64d15193ff42c9
'Bugfix' mono_bitmap_part reads ahead in the buffer,
if the height is <= char bit pixels other memory gets read
Change-Id: I6e0d7a9017e1f9c371ffbd56af149ac20cb82341
It turns out that aa_cache.buf, used to store decoded album art during
background scanning, was not correctly allocated and overlapped with
memory allocated for buflib. This was what caused all the segfaults.
Also fixed a logic error in read_pfraw(), which returns a buflib handle
on success, but also returned 0 on failure -- since 0 is a valid buflib
handle, it should return -1 on failure instead.
Change-Id: Ifaa1c02ec19b0859e43c40c0462ed7738d07fec3
Tested on eros q, everything measured from line out,
open circuit.
- volume steps were approximately double the dB they
were labelled as, so "-2 dB" would result in a change
of about -4 dB from maximum (0, +6.2dBV)
- maximum volume defining the line out volume only
changed every 10 values, and then was not close
to correct- "-10 dB" resulted in -2.5 dB from maximum
This gets the volume dB approximately correct, and
maximum volume correctly sets the line out volume.
I was unable to get odd values in the max volume
to work, so set the step size to 2 instead of one.
For "consumer level" (-10dBV), set to -16.
For "Pro level" (+4dBu -> ~1.8dBV), set to -4.
Change-Id: I898b85d768153579a893b23551019af88f865d21
